|
Home > Archive > Debian Developers > August 2004 > Sarge: GCC 3.4 in Sid
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Sarge: GCC 3.4 in Sid
|
|
| Jerome Warnier 2004-07-28, 6:23 pm |
| It seems several people uploaded packages to Sid recently which got
build with GCC 3.4. I guess those were not meant like this.
Take a look at the following to learn more:
http://bjorn.haxx.se/debian/testing.pl?waiting=gcc-3.4
Regards
--
Jerome Warnier <jwarnier@beeznest.net>
BeezNest s.a r.l.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Chris Cheney 2004-07-28, 6:23 pm |
| On Sun, Jul 25, 2004 at 07:46:07PM +0200, Jerome Warnier wrote:
> It seems several people uploaded packages to Sid recently which got
> build with GCC 3.4. I guess those were not meant like this.
> Take a look at the following to learn more:
> http://bjorn.haxx.se/debian/testing.pl?waiting=gcc-3.4
This is caused by libgcc1 coming from gcc-3.4 now (afaik).
Chris
| |
| Colin Watson 2004-07-28, 6:23 pm |
| On Sun, Jul 25, 2004 at 07:46:07PM +0200, Jerome Warnier wrote:
> It seems several people uploaded packages to Sid recently which got
> build with GCC 3.4. I guess those were not meant like this.
> Take a look at the following to learn more:
> http://bjorn.haxx.se/debian/testing.pl?waiting=gcc-3.4
This is expected. New libgcc1 comes from the gcc-3.4 source package.
Matthias cleared this with debian-release before uploading.
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Daniel Burrows 2004-07-28, 6:23 pm |
| Personally, I suspect a conspiracy to prevent any packages uploaded in
the last week or two from entering testing before the freeze ;-)
Daniel
--
/-------------------- Daniel Burrows <dburrows@debian.org> -------------------\
| Any sufficiently advanced magic is indistinguishable from technology. |
\------- (if (not (understand-this)) (go-to http://www.schemers.org)) --------/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Eduard Bloch 2004-07-28, 6:23 pm |
| #include <hallo.h>
* Daniel Burrows [Mon, Jul 26 2004, 09:40:59AM]:
> Personally, I suspect a conspiracy to prevent any packages uploaded in
> the last week or two from entering testing before the freeze ;-)
I don't think this is really funny. The current release scheme sucks,
the gradual freeze was a joke and I would not wonder if Sarge will be
released late in 2005. Honestly, I think we should freeze _Unstable_
short after amd64 has been added and not let anyone upload packages to
it before the RC count is down and Testing and Sid has an (almost) equal
set of packages.
Regards,
Eduard.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bdale Garbee 2004-08-02, 5:58 pm |
| edi@gmx.de (Eduard Bloch) writes:
> Honestly, I think we should freeze _Unstable_
Our current approach to release management came to be precisely because the
process of freezing unstable and trying to release it was such a hideous
mess, even when Debian was much smaller in scale.
What we have now isn't perfect, but taking a giant leap backwards isn't
likely to help.
Bdale
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Martin Michlmayr 2004-08-05, 5:56 pm |
| * Bdale Garbee <bdale@gag.com> [2004-08-02 11:24]:
>
> Our current approach to release management came to be precisely
> because the process of freezing unstable and trying to release it
> was such a hideous mess, even when Debian was much smaller in scale.
I don't think Eduard suggested freezing unstable and doing away with
testing, but keeping the testing model and freeze testing plus
unstable. If you only freeze testing, new packages can go into
unstable and when you need to make a update to testing you have to use
testing-proposed-updates rather than unstable (which leads to several
problems, such a less testing).
--
Martin Michlmayr
tbm@cyrius.com
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Michael Vogt 2004-08-05, 5:56 pm |
| On Thu, Aug 05, 2004 at 03:47:34PM +0100, Martin Michlmayr wrote:
> * Bdale Garbee <bdale@gag.com> [2004-08-02 11:24]:
>
> I don't think Eduard suggested freezing unstable and doing away with
> testing, but keeping the testing model and freeze testing plus
> unstable. If you only freeze testing, new packages can go into
> unstable and when you need to make a update to testing you have to use
> testing-proposed-updates rather than unstable (which leads to several
> problems, such a less testing).
I think this sounds like a interesting approach. Was this
discussed/tried before? If so, does anyone have pointers where I can
read about this?
Cheers,
Michael
--
The first rule of holes is: when you find yourself in one, stop digging. - PJ
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Eduard Bloch 2004-08-06, 7:51 am |
| #include <hallo.h>
* Martin Michlmayr [Thu, Aug 05 2004, 03:47:34PM]:
>
> I don't think Eduard suggested freezing unstable and doing away with
> testing, but keeping the testing model and freeze testing plus
Yup. I did never say "freeze for release", just freeze. Do not add new
packages to Unstable. Instead, create a small crew that decides which
package are allowed to enter Unstable (with which level of changes) and
which are not. "central" maintainers (eg. libtiff/gnutls11 maintainers)
can pass a list of "allowed" changes in dependent packages. My imaginary
task force (say, 9 people) would decide which changes should be allowed
and which not. When the package sets in Testing and FrozenSid look close
enough, Testing can be released and Sid "defrosted" again.
Why all this? I still see the current system as pure chaos and doing
Sysiphus work. And the technical committee needs to much time to find
a decission, so it would be more practical to decide less important
things elsewhere.
Regards,
Eduard.
--
<Zugschlus> fIPS: Wenn Du mich für so blöd hältst wie ich aussehe dann
hast du genau den richtigen vor Dir.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|