Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sat, 26 Jun 2010 21:57:33 +0200 Enrico Weigelt weig...@metux.de wrote: #2 One point i don't agree is the dont add -Werror rule. actually, i'm thinking of making -Wall and -Werror mandatory. if some package doenst build fine, it's simply broken. period. Uhm. No. Certain compilers will give you warnings for f(g(a), g(b)) if you -Wall. Warn on what exactly ? Which compilers do that ? I suggest you to try latest available dev-lang/icc (11.1.072). This thing is really paranoid: remark #2259: non-pointer conversion from int to unsigned char may lose significant bits unsigned char BlinkerPhase = 0; ... BlinkerPhase = (BlinkerPhase + 1) 3; remark #981: operands are evaluated in unspecified order (tons of them) return strcmp( left.c_str(), right.c_str() ) 0; -- Sergei
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
Le 26/06/2010 21:39, Enrico Weigelt a écrit : #2 One point i don't agree is the dont add -Werror rule. actually, i'm thinking of making -Wall and -Werror mandatory. if some package doenst build fine, it's simply broken. period. You're obviously new here... Just take a stroll through bugzilla to see how much we _fight_ against -Werror. Let's see why you obviously have not thought through this completely before writing this : We currently offer 11 different slots of GCC, 3 of gcc-apple, each with multiple versions, 3 versions of llvm-gcc, 2 versions of clang, 7 versions of icc, so in all 26 *major* versions. You do well know that each compiler prints out different warnings for the *same* code... We also offer 10 versions of glibc, 8 versions of uclibc, and 7 versions of klibc. Each version may have header bugs, so may trigger warnings for perfectly good code. And finally we offer 5 unmasked versions of binutils (newer ones even have a brand new linker - gold) and 5 versions of binutils-apple. Again, different tools, different warnings... If you want to make -Werror mandatory, you *MUST* test all combinations above as *THEY ARE ALL SUPPORTED*. Otherwise, packages will break for no good reason and users will hate us. -Werror is a perfectly fine *developer* feature. For example, Gnome autoconf macros enable it for development snapshots, but never ever enable it for stable releases. So please, if you want to write nonsense, don't write it in the name of Gentoo. Rémi PS, Diego (flameeyes) is already having enough issues with his tinderbox running *ONE* compiler/linker/libc combination...
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Nirbheek Chauhan nirbh...@gentoo.org schrieb: Or if they generate the tarball on-the-fly with no caching, which results in differing timestamps each time. Hence, each time you fetch it, you get a tarball with a different hash. Does portage check the timestamps ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb: On Sat, 26 Jun 2010 22:09:09 +0200 Enrico Weigelt weig...@metux.de wrote: Well, with git this works. (I'll yet have to run some automatic stress tests, but at all my manual tests worked really fine). You assume that, given the same input and program options, a compression program will always produce the same output. This is not the case. Well, at least for tar, I've experienced no problem here yet. But: true, it might change between tar versions. A more sophisticated approach, IMHO, would be: directly fetching from the VCS, but that would probably mean a major design change. (my Briegel buildsystem goes this way ... it doesnt even patch on itself anymore, thats done entirely in git) cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sun, 27 Jun 2010 12:34:44 +0200 Enrico Weigelt weig...@metux.de wrote: You assume that, given the same input and program options, a compression program will always produce the same output. This is not the case. Well, at least for tar, I've experienced no problem here yet. But: true, it might change between tar versions. The main offender is the compression program, not tar. A more sophisticated approach, IMHO, would be: directly fetching from the VCS Yes, upstreams are going to love you for that... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: FYI: Rules for distro-friendly packages
* Nikos Chantziaras rea...@arcor.de schrieb: Did it actually occur to anyone that warnings are not errors? You can have them for correct code. A warning means you might want to look at the code to check whether there's some real error there. It doesn't mean the code is broken. In my personal experience, most times a warning comes it, the code *is* broken (but *might* work in most situations). So, developers should always enable it and think ten times if some warning is acceptable. But: you all conviced me. These flags should be controlled by the distro buildsystem, not the individual package. Developers just should take care that there're no preventable warnings. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Sergei Trofimovich sly...@gentoo.org schrieb: I suggest you to try latest available dev-lang/icc (11.1.072). This thing is really paranoid: remark #2259: non-pointer conversion from int to unsigned char may lose significant bits unsigned char BlinkerPhase = 0; ... BlinkerPhase = (BlinkerPhase + 1) 3; In this case, the compiler is wrong: it should convert to int and back to char here ;-p remark #981: operands are evaluated in unspecified order (tons of them) return strcmp( left.c_str(), right.c_str() ) 0; I'm not sure if this really qualifies an warning, since - AFAIK - C spec never said, that there is an evaluation order for function parameters. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Rémi Cardona r...@gentoo.org schrieb: We currently offer 11 different slots of GCC, 3 of gcc-apple, each with multiple versions, 3 versions of llvm-gcc, 2 versions of clang, 7 versions of icc, so in all 26 *major* versions. You do well know that each compiler prints out different warnings for the *same* code... hmm, perhaps I'll hack some little scripts which create a jail/container for each compiler version and triggers emerge within them. We also offer 10 versions of glibc, 8 versions of uclibc, and 7 versions of klibc. Each version may have header bugs, so may trigger warnings for perfectly good code. Well, if there're header bugs, shouldn't they get fixed before these libs are stabelized ? ;-O And finally we offer 5 unmasked versions of binutils (newer ones even have a brand new linker - gold) and 5 versions of binutils-apple. Again, different tools, different warnings... Okay, adds *10 to the test matrix. Still not yet an too complex problem (still linear complexity). -Werror is a perfectly fine *developer* feature. For example, Gnome autoconf macros enable it for development snapshots, but never ever enable it for stable releases. Okay, aggreed. I've reworked my rule, now: package build systems MUST NOT enable -Wall -Werror (unless explicitly asked), but developers SHOULD use them for their test builds cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb: Well, at least for tar, I've experienced no problem here yet. But: true, it might change between tar versions. The main offender is the compression program, not tar. hmm, I'm exclusively using bzip2 and never had these problems yet. maybe it depends on the compressor type. A more sophisticated approach, IMHO, would be: directly fetching from the VCS Yes, upstreams are going to love you for that... Why ? Because of traffic ? Of course, distros should work from their own clones (yes, yes, I'm assuming modern VCS'es, not toys like svn ;-p) cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sun, 27 Jun 2010 13:08:58 +0200 Enrico Weigelt weig...@metux.de wrote: Well, at least for tar, I've experienced no problem here yet. But: true, it might change between tar versions. The main offender is the compression program, not tar. hmm, I'm exclusively using bzip2 and never had these problems yet. maybe it depends on the compressor type. Your problem is that you are thinking in terms of well I've not seen it break, not I can prove that it will always work. You may find the Compressed output may vary section of man 1 xz to be useful. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/27/2010 06:52 AM, Enrico Weigelt wrote: remark #981: operands are evaluated in unspecified order (tons of them) return strcmp( left.c_str(), right.c_str() ) 0; I'm not sure if this really qualifies an warning, since - AFAIK - C spec never said, that there is an evaluation order for function parameters. I could see how somebody might make that assumption (incorrectly), and get burned by this. However, creating local variables just to hold intermediate results so as to not embed them in function calls seems to be a lot of overhead - certainly in terms of readability, and I can't think of a situation where the compiler would have to do it on its own. I guess religiously doing this might make the code less likely to contain very subtle bugs, but perhaps it is a bit over the top for anybody who wouldn't be otherwise developing in ADA. Rich
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On 06/27/2010 01:47 PM, Enrico Weigelt wrote: * Nikos Chantziarasrea...@arcor.de schrieb: Did it actually occur to anyone that warnings are not errors? You can have them for correct code. A warning means you might want to look at the code to check whether there's some real error there. It doesn't mean the code is broken. In my personal experience, most times a warning comes it, the code *is* broken (but *might* work in most situations). That's the key to it: most times. Granted, without -Wall (or any other options that tweaks the default warning level) we can be very sure that the warning is the result of a mistake by the developer. But with -Wall, many warnings are totally not interesting (unused parameter) and some even try to outsmart the programmer even though he/she knows better (taking address of variable declared register). In that last example, fixing it would even be wrong when you consider the optimizer and the fuzzy meaning of register which the compiler is totally free to ignore.
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/27/10 13:02, Enrico Weigelt wrote: [snip] We also offer 10 versions of glibc, 8 versions of uclibc, and 7 versions of klibc. Each version may have header bugs, so may trigger warnings for perfectly good code. Well, if there're header bugs, shouldn't they get fixed before these libs are stabelized ? ;-O And there we have the thin line between actual bug and fuzzy specification. Sometimes things fail just because two people assumed something and thus the code disagrees in a really funny way. Or just the GNUisms that tend to leak in through glibc+gcc ... *shudder* And finally we offer 5 unmasked versions of binutils (newer ones even have a brand new linker - gold) and 5 versions of binutils-apple. Again, different tools, different warnings... Okay, adds *10 to the test matrix. Still not yet an too complex problem (still linear complexity). So just to keep up with the current package update speed in gentoo you'd be saturating about a dozen quadcore machines. For amd64 only. And that's not even checking all reverse dependencies of every single update (which can easily push it up by another factor of 100) Unless you have a strategic supply of gold bars it won't be possible to check all permutations (and we haven't even started toggling useflags for fun!) -Werror is a perfectly fine *developer* feature. For example, Gnome autoconf macros enable it for development snapshots, but never ever enable it for stable releases. Okay, aggreed. I've reworked my rule, now: package build systems MUST NOT enable -Wall -Werror (unless explicitly asked), but developers SHOULD use them for their test builds I'd say they can enable it, but SHOULD NOT If people want to run headfirst into a wall let them do it a few times, they'll learn ...
Re: [gentoo-dev] Re: FYI: Rules for distro-friendly packages
On Sun, Jun 27, 2010 at 02:56:33PM +0300, Nikos Chantziaras wrote: On 06/27/2010 01:47 PM, Enrico Weigelt wrote: * Nikos Chantziarasrea...@arcor.de schrieb: Did it actually occur to anyone that warnings are not errors? You can have them for correct code. A warning means you might want to look at the code to check whether there's some real error there. It doesn't mean the code is broken. In my personal experience, most times a warning comes it, the code *is* broken (but *might* work in most situations). That's the key to it: most times. Granted, without -Wall (or any other options that tweaks the default warning level) we can be very sure that the warning is the result of a mistake by the developer. But with -Wall, many warnings are totally not interesting (unused parameter) and some even try to outsmart the programmer even though he/she knows better (taking address of variable declared register). In that last example, fixing it would even be wrong when you consider the optimizer and the fuzzy meaning of register which the compiler is totally free to ignore. The compiler is not totally free to ignore the register keyword. Both the C and the C++ standards require that the compiler complain when taking the address of a register variable. Other compilers will issue a hard error for it. Fixing the code to not declare the variable as register would be the correct thing to do. Make sure you *understand* warnings, and then you can decide whether to fix the code, if there is anything to fix, or to ignore.
Re: [gentoo-dev] Re: FYI: Rules for distro-friendly packages
* Harald van D??k true...@gentoo.org schrieb: The compiler is not totally free to ignore the register keyword. Both the C and the C++ standards require that the compiler complain when taking the address of a register variable. Other compilers will issue a hard error for it. Fixing the code to not declare the variable as register would be the correct thing to do. BTW: is the register keyword still so useful nowadays ? Shouldn't a modern (optimizing) compiler be clever enough to find out when it can use registers instead of RAM ? Make sure you *understand* warnings, and then you can decide whether to fix the code, if there is anything to fix, or to ignore. hmm, is there a (portable) way to prevent a specific warning in an specific place ? (some kind of #pragma ?) cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sun, 27 Jun 2010 14:22:53 +0200 Enrico Weigelt weig...@metux.de wrote: Maybe it's time for a distributed build project: a generic container image, which gets distributed to dozens of machines and runs build tests coordinated by some server ... a bit like s...@home ;-) Enough CPU is available all around the world, just heavily distributed. PHP and mplayer both have 100 USE flags. There's not enough CPU power in the world. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: FYI: Rules for distro-friendly packages
On Sun, 27 Jun 2010 14:25:39 +0200 Enrico Weigelt weig...@metux.de wrote: hmm, is there a (portable) way to prevent a specific warning in an specific place ? (some kind of #pragma ?) No. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On 06/27/2010 03:23 PM, Harald van Dijk wrote:
On Sun, Jun 27, 2010 at 02:56:33PM +0300, Nikos Chantziaras wrote:
On 06/27/2010 01:47 PM, Enrico Weigelt wrote:
* Nikos Chantziarasrea...@arcor.de schrieb:
Did it actually occur to anyone that warnings are not errors?
You can have them for correct code. A warning means you might
want to look at the code to check whether there's some real
error there. It doesn't mean the code is broken.
In my personal experience, most times a warning comes it, the
code *is* broken (but *might* work in most situations).
That's the key to it: most times. Granted, without -Wall (or any
other options that tweaks the default warning level) we can be very
sure that the warning is the result of a mistake by the developer.
But with -Wall, many warnings are totally not interesting (unused
parameter) and some even try to outsmart the programmer even
though he/she knows better (taking address of variable declared
register). In that last example, fixing it would even be wrong
when you consider the optimizer and the fuzzy meaning of register
which the compiler is totally free to ignore.
The compiler is not totally free to ignore the register keyword.
Both the C and the C++ standards require that the compiler complain
when taking the address of a register variable. Other compilers will
issue a hard error for it. Fixing the code to not declare the
variable as register would be the correct thing to do.
No, it would not be the correct thing to do, because of the following.
(This is part of a discussion between me and someone quite smarter than
me, who explained the issue in detail.)
The basic issue is that the code takes the address of the variable in
question in expressions passed as parameters to certain function calls.
These function calls all happen to be in-linable functions, and it
happens that in each function, the address operator is always canceled
out by a '*' dereference operator - in other words, we have '*p', which
the compiler can turn into just plain 'p' when the calls are in-lined,
eliminating the need to actually take the address of 'p'.
A compiler is always free to ignore 'register' declarations *anyway*,
even if enregistration is possible. Therefore a warning that it's not
possible to obey 'register' is unnecessary, because it's explicit in the
language definition that 'register' is not binding. It simply is not
possible for an ignored 'register' attribute to cause unexpected
behavior. Warnings really should only be generated for situations where
it is likely that the programmer expects different behavior than the
compiler will deliver; in the case of an ignored 'register' attribute,
the programmer is *required* to expect that the attribute might be
ignored, so a warning to this effect is superfluous.
Now, I understand why they generate the warning - it's because the
compiler believes that the program code itself makes enregistration
impossible, not because the compiler has chosen for optimization
purposes to ignore the 'register' request. However, as we'll see
shortly, the program code doesn't truly make enregistration impossible;
it is merely impossible in some interpretations of the code. Therefore
we really are back to the compiler choosing to ignore the 'register'
request due to its own optimization decisions; the 'register' request is
made impossible far downstream of the actual decisions that the compiler
makes (which have to do with in-line vs out-of-line calls), but it
really is compiler decisions that make it impossible, not the inherent
structure of the code.
When a function is in-lined, the compiler is not required to generate
the same code it would generate for the most general case of the same
function call, as long as the meaning is the same.
For example, suppose we have some code that contains a call to a
function like so:
a = myFunc(a + 7, 3);
In the general out-of-line case, the compiler must generate some
machine-code instructions like this:
push #3
mov [a], d0
add #7, d0
push d0
call #myFunc
mov d0, [a]
The compiler doesn't have access to the inner workings of myFunc, so it
must generate the appropriate code for the generic interface to an
external function.
Now, suppose the function is defined like so:
int myFunc(int a, int b) { return a - 6; }
and further suppose that the compiler decides to in-line this function.
In-lining means the compiler will generate the code that implements the
function directly in the caller; there will be no call to an external
linkage point. This means the compiler can implement the linkage to the
function with a custom one-off interface for this particular invocation
- every in-line invocation can be customized to the exact context where
it appears. So, for example, if we call myFunc right now and registers
d1 and d2 happens to be available, we can put the parameters in d1 and
d2, and the generated function will refer to those registers for the
parameters rather
[gentoo-dev] Policy for late/slow stabilizations
Hi As many of you have already noticed, there are some arches that are quite slow on stabilizations. This leads to deprecated stabilizations e.g a package is stabilized after 60 days which makes that version of the specific package obsolete and not worth to stabilize anymore. I would suggest to introduce a new rule where a stabilization bug may close after 30 days. Arches that fail to stabilize it within this timeframe they will simply don't have this package stable for them. Moreover, slow arches introduce another problem as well. If a package is marked stabled for their arch, but this package is quite old, and they fail to stabilize a new version, we ( as maintainers ) can't drop the very old ( and obsolete ) version of this package because we somehow will break the stable tree for these arches. How should we act in this case? Keep the old version around forever just to say that hey, they do have a stable version for our exotic arch. Whilst I do understand that these arches are understaffed and they can't keep up with the increased stabilization load like x86/amd64 do, I still think that slow stabilization leads to an obsolete stable tree which I doesn't make sense to me after all. Thoughts? -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org pgpgbH30fWGeS.pgp Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On 06/27/10 17:04, Markos Chandras wrote: [snip] Whilst I do understand that these arches are understaffed and they can't keep up with the increased stabilization load like x86/amd64 do, I still think that slow stabilization leads to an obsolete stable tree which I doesn't make sense to me after all. Thoughts? I see two scenarios - either we get the slow arches enough cpu- and manpower, or we remove their stable keywords. If possible I think we should try to keep stable keywords. So how can we help? I'm not sure how I could help e.g. PPC - I don't have any hardware I can test on, and I'm not aware of remotely accessible dev boxen. So - how can we improve this situation?
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote: Moreover, slow arches introduce another problem as well. If a package is marked stabled for their arch, but this package is quite old, and they fail to stabilize a new version, we ( as maintainers ) can't drop the very old ( and obsolete ) version of this package because we somehow will break the stable tree for these arches. How should we act in this case? Keep the old version around forever just to say that hey, they do have a stable version for our exotic arch. I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then just drop the old ebuild. These arches will slowly lose stable keywords until their stable tree gets to a size that they can manage. And everyone will be winners. That said, when dropping the old keywords, you have to be careful to drop the stable keyword on all dependencies too so as to not drop break the tree for them. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, Jun 27, 2010 at 11:47:49AM -0400, Olivier Crête wrote: On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote: Moreover, slow arches introduce another problem as well. If a package is marked stabled for their arch, but this package is quite old, and they fail to stabilize a new version, we ( as maintainers ) can't drop the very old ( and obsolete ) version of this package because we somehow will break the stable tree for these arches. How should we act in this case? Keep the old version around forever just to say that hey, they do have a stable version for our exotic arch. I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then just drop the old ebuild. These arches will slowly lose stable keywords until their stable tree gets to a size that they can manage. And everyone will be winners. That said, when dropping the old keywords, you have to be careful to drop the stable keyword on all dependencies too so as to not drop break the tree for them. When dropping an old *stable* ebuild, which in most cases this will be the only stable ebuild that these arches will have for this packages, the next world update will be ugly since there will be no *stable * candidates for that package anymore. In this case, stable users will start filling package.keywords leading to ~testing migration. So I am not sure if this is the correct approach to deal with this but I can't think of anything else -- Olivier Crête tes...@gentoo.org Gentoo Developer -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org pgppLbUXeg0gx.pgp Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On 06/27/2010 06:47 PM, Olivier Crête wrote: On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote: Moreover, slow arches introduce another problem as well. If a package is marked stabled for their arch, but this package is quite old, and they fail to stabilize a new version, we ( as maintainers ) can't drop the very old ( and obsolete ) version of this package because we somehow will break the stable tree for these arches. How should we act in this case? Keep the old version around forever just to say that hey, they do have a stable version for our exotic arch. I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then just drop the old ebuild. These arches will slowly lose stable keywords until their stable tree gets to a size that they can manage. And everyone will be winners. That said, when dropping the old keywords, you have to be careful to drop the stable keyword on all dependencies too so as to not drop break the tree for them. +1
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 27 Jun 2010 18:04:45 +0300 Markos Chandras hwoar...@gentoo.org wrote: Whilst I do understand that these arches are understaffed and they can't keep up with the increased stabilization load like x86/amd64 do, I still think that slow stabilization leads to an obsolete stable tree which I doesn't make sense to me after all. Which does Gentoo care about more: slightly increased convenience for most developers, or considerably increased inconvenience for users of minority archs? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, Jun 27, 2010 at 5:04 PM, Markos Chandras hwoar...@gentoo.org wrote: Thoughts? If Gentoo doesn't seem to have time to maintain the stable tree, why have it in the first place? What really is the advantage of having a stable tree?
Re: [gentoo-dev] Re: FYI: Rules for distro-friendly packages
On Sun, Jun 27, 2010 at 05:46:28PM +0300, Nikos Chantziaras wrote: On 06/27/2010 03:23 PM, Harald van Dijk wrote: The compiler is not totally free to ignore the register keyword. Both the C and the C++ standards require that the compiler complain when taking the address of a register variable. Other compilers will issue a hard error for it. Fixing the code to not declare the variable as register would be the correct thing to do. No, it would not be the correct thing to do, because of the following. (This is part of a discussion between me and someone quite smarter than me, who explained the issue in detail.) [snip] That explanation seems to be written by someone who does not know that taking the address of a register variable is simply not allowed. OK, long read, but the the conclusion is that fixing the code to not declare the variable as register would be the correct thing to do it *not* the correct thing to do. The correct thing to do is to ignore the warning, which is not possible if warnings are turned into errors. And which is not possible if the warning is a hard error in the first place. You also mentioned that other compilers will issue a hard error for it. That sounds rather strange, and I wonder which compilers that might be; someone should file a bug report against them ;) Well, let's start with gcc; that's quite an important one for Gentoo...
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, Jun 27, 2010 at 06:53:56PM +0200, Auke Booij wrote: On Sun, Jun 27, 2010 at 5:04 PM, Markos Chandras hwoar...@gentoo.org wrote: Thoughts? If Gentoo doesn't seem to have time to maintain the stable tree, why have it in the first place? What really is the advantage of having a stable tree? What? I am talking about exotic arches and I didn't say to drop to entire stable tree. Just to shrink it in order to keep it up to date more easily -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org pgpRWyNntCEju.pgp Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, Jun 27, 2010 at 05:38:34PM +0100, Ciaran McCreesh wrote: On Sun, 27 Jun 2010 18:04:45 +0300 Markos Chandras hwoar...@gentoo.org wrote: Whilst I do understand that these arches are understaffed and they can't keep up with the increased stabilization load like x86/amd64 do, I still think that slow stabilization leads to an obsolete stable tree which I doesn't make sense to me after all. Which does Gentoo care about more: slightly increased convenience for most developers, or considerably increased inconvenience for users of minority archs? -- Ciaran McCreesh I don't follow you. Increased convenience just for the devs? How?All I want is to have packages stabled ~60 days after the initial commit on tree instead of ~5 months. If arches can't do that then I don't want to mark that obsolete package stable at all. Whats the point? Also I would prefer to be able to drop ancient stable packages from the tree even if that means that there wont be any other stable version for this package to use. I 'd prefer a working tiny stable tree than a huge ancient one -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org pgp4N7bomqPQa.pgp Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 27 Jun 2010 20:22:33 +0300 Markos Chandras hwoar...@gentoo.org wrote: Which does Gentoo care about more: slightly increased convenience for most developers, or considerably increased inconvenience for users of minority archs? I don't follow you. Increased convenience just for the devs? How? Not having to keep old versions around for a few archs is slightly more convenient for most people. Having to deal with dropped keywords is a huge inconvenience for users on minority archs. All I want is to have packages stabled ~60 days after the initial commit on tree instead of ~5 months. If arches can't do that then I don't want to mark that obsolete package stable at all. Whats the point? The point is for users of minor archs to have something that works. Also I would prefer to be able to drop ancient stable packages from the tree even if that means that there wont be any other stable version for this package to use. I 'd prefer a working tiny stable tree than a huge ancient one The problem with that is that presumably some minority arch users are using the packages you'd be dropping. When that happens, dropped keywords are a considerable cost to them. Which is the decision to make: make things very difficult for minority arch users, who get screwed over royally every time keywords are dropped, or make things slightly more inconvenient for developers, who have to keep some things around for longer. It's all down to whether you think happy users are more important than happy developers. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On 06/27/2010 08:14 PM, Harald van Dijk wrote: On Sun, Jun 27, 2010 at 05:46:28PM +0300, Nikos Chantziaras wrote: On 06/27/2010 03:23 PM, Harald van Dijk wrote: The compiler is not totally free to ignore the register keyword. Both the C and the C++ standards require that the compiler complain when taking the address of a register variable. Other compilers will issue a hard error for it. Fixing the code to not declare the variable as register would be the correct thing to do. No, it would not be the correct thing to do, because of the following. (This is part of a discussion between me and someone quite smarter than me, who explained the issue in detail.) [snip] That explanation seems to be written by someone who does not know that taking the address of a register variable is simply not allowed. It is allowed. Section 7.1.1, Paragraphs 2 and 3 of the C++ standard: The register specifier [...] specifies that the named variable has automatic storage duration (3.7.3). A variable declared without a storage-class-specifier at block scope or declared as a function parameter has automatic storage duration by default. A register specifier is a hint to the implementation that the variable so declared will be heavily used. [ Note: the hint can be ignored and in most implementations it will be ignored if the address of the variable is taken. This use is deprecated (see D.4). — end note ] OK, long read, but the the conclusion is that fixing the code to not declare the variable as register would be the correct thing to do it *not* the correct thing to do. The correct thing to do is to ignore the warning, which is not possible if warnings are turned into errors. And which is not possible if the warning is a hard error in the first place. You also mentioned that other compilers will issue a hard error for it. That sounds rather strange, and I wonder which compilers that might be; someone should file a bug report against them ;) Well, let's start with gcc; that's quite an important one for Gentoo... That code compiles just fine. I don't know of any GCC version that issues an error for this rather than just a warning.
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, Jun 27, 2010 at 06:43:30PM +0100, Ciaran McCreesh wrote: Which is the decision to make: make things very difficult for minority arch users, who get screwed over royally every time keywords are dropped, or make things slightly more inconvenient for developers, who have to keep some things around for longer. It's all down to whether you think happy users are more important than happy developers. -- Ciaran McCreesh Please explain me why keeping foobar-1.0 ( Released in 10/12/2009 ) is in favor of a ppc64 stable user when amd64/x86 has foobar-2.1.3 ( Released 60 days ago ) already stabled for them What if a foobar-1.0 bug pops up? What kind of support will that user get from the gentoo or upstream maintainer. The most frequent answer would be Please update to 2.1.3. 1.0 is 0ld. Yes, not droppping the keywords is convenient for users but in this case their stable tree gets obsolet and unsupported -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org pgpuZdOGtFKyb.pgp Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
2010-06-27 17:04:45 Markos Chandras napisał(a): Hi As many of you have already noticed, there are some arches that are quite slow on stabilizations. This leads to deprecated stabilizations e.g a package is stabilized after 60 days which makes that version of the specific package obsolete and not worth to stabilize anymore. I would suggest to introduce a new rule where a stabilization bug may close after 30 days. Arches that fail to stabilize it within this timeframe they will simply don't have this package stable for them. Moreover, slow arches introduce another problem as well. If a package is marked stabled for their arch, but this package is quite old, and they fail to stabilize a new version, we ( as maintainers ) can't drop the very old ( and obsolete ) version of this package because we somehow will break the stable tree for these arches. How should we act in this case? Keep the old version around forever just to say that hey, they do have a stable version for our exotic arch. Whilst I do understand that these arches are understaffed and they can't keep up with the increased stabilization load like x86/amd64 do, I still think that slow stabilization leads to an obsolete stable tree which I doesn't make sense to me after all. Thoughts? +1. The period of waiting might be extended to 60 days. This period should be counted from the first ignored stabilization request. Stabilizations of some packages are filed e.g. once per month and some architectures don't manage to stabilize older versions before stabilization requests of new versions. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On Sun, Jun 27, 2010 at 08:48:25PM +0300, Nikos Chantziaras wrote: ... It is allowed. Section 7.1.1, Paragraphs 2 and 3 of the C++ standard: ... Not in C. ISO/IEC 9899:1999 (aka C99), section 6.7.1, note 101: The implementation may treat any register declaration simply as an auto declaration. However, whether or not addressable storage is actually used, the address of any part of an object declared with storage-class specifier register cannot be computed, either explicitly (by use of the unary operator as discussed in 6.5.3.2) or implicitly (by converting an array name to a pointer as discussed in 6.3.2.1). Thus, the only operator that can be applied to an array declared with storage-class specifier register is sizeof.
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras hwoar...@gentoo.org wrote: What? I am talking about exotic arches and I didn't say to drop to entire stable tree. Just to shrink it in order to keep it up to date more easily But my question stands: what really is the advantage of having a stable tree, when you could better invest your time in keeping the testing tree up to date and working? Most production systems are running x86, right? Are stable versions of minority architecture installations really that much more stable than testing versions? PS: this is by no means a rhetorical question. PPS: bonus points for the person who can tell me a good opposite of rhetorical.
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 27 Jun 2010 19:01:13 +0100 Markos Chandras hwoar...@gentoo.org wrote: Please explain me why keeping foobar-1.0 ( Released in 10/12/2009 ) is in favor of a ppc64 stable user when amd64/x86 has foobar-2.1.3 ( Released 60 days ago ) already stabled for them Because it's known to work. That's the point of stable. What if a foobar-1.0 bug pops up? What kind of support will that user get from the gentoo or upstream maintainer. The most frequent answer would be Please update to 2.1.3. 1.0 is 0ld. Yes, not droppping the keywords is convenient for users but in this case their stable tree gets obsolet and unsupported When that happens, *then* stabling foobar can become a priority, and the user in question can help with it. However, given the finite amount of development time available, you need to bear in mind that foobar is nowhere near as special as you'd like to think, that Debian is still running foobar 0.0.1, and that something that is known to work is, for many users, better than something that might work. Which, again, is the point: to what extent do you care about users? If you're prepared to tell users to expect annoying breakages that take a lot of work to fix as things get keyworded every now and again because it makes things marginally easier for developers, then go ahead and unkeyword a package plus lots of deps. If you think users are the distribution's primary asset, however, then it's worth inconveniencing yourselves slightly every now and again to save them a lot of pain. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 2010-06-27 at 18:54 +0300, Markos Chandras wrote: On Sun, Jun 27, 2010 at 11:47:49AM -0400, Olivier Crête wrote: On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote: Moreover, slow arches introduce another problem as well. If a package is marked stabled for their arch, but this package is quite old, and they fail to stabilize a new version, we ( as maintainers ) can't drop the very old ( and obsolete ) version of this package because we somehow will break the stable tree for these arches. How should we act in this case? Keep the old version around forever just to say that hey, they do have a stable version for our exotic arch. I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then just drop the old ebuild. These arches will slowly lose stable keywords until their stable tree gets to a size that they can manage. And everyone will be winners. That said, when dropping the old keywords, you have to be careful to drop the stable keyword on all dependencies too so as to not drop break the tree for them. When dropping an old *stable* ebuild, which in most cases this will be the only stable ebuild that these arches will have for this packages, the next world update will be ugly since there will be no *stable * candidates for that package anymore. In this case, stable users will start filling package.keywords leading to ~testing migration. So I am not sure if this is the correct approach to deal with this but I can't think of anything else That's ok. That way those users will know that no one from the arch team maintains that packages and they will know it has a lower level of QA. And the users will be able to make a choice. Instead of pretending that it is maintained. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On 06/27/2010 09:10 PM, dev-ran...@mail.ru wrote: On Sun, Jun 27, 2010 at 08:48:25PM +0300, Nikos Chantziaras wrote: ... It is allowed. Section 7.1.1, Paragraphs 2 and 3 of the C++ standard: ... Not in C. ISO/IEC 9899:1999 (aka C99), section 6.7.1, note 101: The implementation may treat any register declaration simply as an auto declaration. However, whether or not addressable storage is actually used, the address of any part of an object declared with storage-class specifier register cannot be computed, either explicitly (by use of the unary operator as discussed in 6.5.3.2) or implicitly (by converting an array name to a pointer as discussed in 6.3.2.1). Thus, the only operator that can be applied to an array declared with storage-class specifier register is sizeof. Wasn't aware of the difference here. But anyway, the warning is issued by GCC for C++ too, not just C.
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sun, Jun 27, 2010 at 01:08:58PM +0200, Enrico Weigelt wrote: * Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb: Well, at least for tar, I've experienced no problem here yet. But: true, it might change between tar versions. The main offender is the compression program, not tar. hmm, I'm exclusively using bzip2 and never had these problems yet. maybe it depends on the compressor type. http://www.gentoo.org/proj/en/glep/glep-0025.html#the-problem-in-detail Note also that bzip2 had another change in output after that release- my memory is failing me a bit, but it was roughly a a reduction of their hash size to fix a CVE- either way, same thing, differing output. It happens, and further, is a well known potential for compressors. ~harring pgp3rTeFHDsRa.pgp Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote: As many of you have already noticed, there are some arches that are quite slow on stabilizations. This leads to deprecated stabilizations e.g a package is stabilized after 60 days which makes that version of the specific package obsolete and not worth to stabilize anymore. So you would suggest to be like Ubuntu and say we can not be bothered to support any minority architectures anymore. This effectively disbands all architecture teams except AMD64 and X86; it should be subject to the same scrutiny (I suggest a council vote) as a GLEP or EAPI change. Personally I would like to hear stronger reasons then it inconveniences me when a bug I file is open longer then a month to destroy the current diversity of supported architectures (be it PowerPC or a prefix installation on OS X). Regards, Tony V. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 2010-06-27 at 17:45 +0200, Patrick Lauer wrote: If possible I think we should try to keep stable keywords. So how can we help? I'm not sure how I could help e.g. PPC - I don't have any hardware I can test on, and I'm not aware of remotely accessible dev boxen. There are options, an older Playstation III with a faulty Blu-Ray drive is still usable as a PPC64 (32UL) test box. For developers that actively want to help, perhaps the arch teams can recommend hardware that is relatively easy to acquire and guaranteed to be supported/stable from a kernel point of view. I've done my best to supply an example. Regards, Tony V. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/27/10 20:33, Brian Harring wrote: On Sun, Jun 27, 2010 at 01:08:58PM +0200, Enrico Weigelt wrote: * Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb: Well, at least for tar, I've experienced no problem here yet. But: true, it might change between tar versions. The main offender is the compression program, not tar. hmm, I'm exclusively using bzip2 and never had these problems yet. maybe it depends on the compressor type. http://www.gentoo.org/proj/en/glep/glep-0025.html#the-problem-in-detail Note also that bzip2 had another change in output after that release- my memory is failing me a bit, but it was roughly a a reduction of their hash size to fix a CVE- either way, same thing, differing output. Are you thinking about bzip2 version 1.0.2 worked with huffman codes with a length of up to 20 bits. Unfortunately the Author of bzip2, Julian Seward, changed this in the new version 1.0.3 - it uses only a maximum length of 17 bits now. (Quoted from http://linux01.gwdg.de/~nlissne/bugsandproblems.html ) ?
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, Jun 27, 2010 at 07:37:39PM +0100, Tony Chainsaw Vroon wrote: On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote: As many of you have already noticed, there are some arches that are quite slow on stabilizations. This leads to deprecated stabilizations e.g a package is stabilized after 60 days which makes that version of the specific package obsolete and not worth to stabilize anymore. So you would suggest to be like Ubuntu and say we can not be bothered to support any minority architectures anymore. This effectively disbands all architecture teams except AMD64 and X86; it should be subject to the same scrutiny (I suggest a council vote) as a GLEP or EAPI change. Personally I would like to hear stronger reasons then it inconveniences me when a bug I file is open longer then a month to destroy the current diversity of supported architectures (be it PowerPC or a prefix installation on OS X). Regards, Tony V. Oh come on. I never said to stop supporting those arches. I just said to shrink their stable tree. What do you suggest? Pretend to have active exotic arches just to look shiny and pretty? -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org pgp3Hbx2jOLQE.pgp Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, Jun 27, 2010 at 08:15:32PM +0200, Auke Booij wrote: On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras hwoar...@gentoo.org wrote: What? I am talking about exotic arches and I didn't say to drop to entire stable tree. Just to shrink it in order to keep it up to date more easily But my question stands: what really is the advantage of having a stable tree, when you could better invest your time in keeping the testing tree up to date and working? Most production systems are running x86, right? Are stable versions of minority architecture installations really that much more stable than testing versions? Because a stable tree it is supposed to work. Testing tree on the other hand is vulnerable to breakages from time to time. We can't always ensure a working testing tree. We are people not machines. We tend to brake things and this is way we have the testing branch. -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org pgplQleYo6rPJ.pgp Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, Jun 27, 2010 at 02:21:13PM -0400, Olivier Crête wrote: That's ok. That way those users will know that no one from the arch team maintains that packages and they will know it has a lower level of QA. And the users will be able to make a choice. Instead of pretending that it is maintained. -- Olivier Crête tes...@gentoo.org Gentoo Developer +1. This is what I am trying to say -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org pgphgHkaF7wrL.pgp Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 27 Jun 2010 22:55:42 +0300 Markos Chandras hwoar...@gentoo.org wrote: Oh come on. I never said to stop supporting those arches. I just said to shrink their stable tree. What do you suggest? Pretend to have active exotic arches just to look shiny and pretty? Claiming to support an exotic arch but forcing people to run ~arch on it is not supporting it at all. One of the problems with exotic archs is that they are much more likely to show up bugs than things that are commonly used, and so knowing that something has been properly tested is a lot more important there. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, Jun 27, 2010 at 09:01:55PM +0100, Ciaran McCreesh wrote: On Sun, 27 Jun 2010 22:55:42 +0300 Markos Chandras hwoar...@gentoo.org wrote: Oh come on. I never said to stop supporting those arches. I just said to shrink their stable tree. What do you suggest? Pretend to have active exotic arches just to look shiny and pretty? Claiming to support an exotic arch but forcing people to run ~arch on it is not supporting it at all. One of the problems with exotic archs is that they are much more likely to show up bugs than things that are commonly used, and so knowing that something has been properly tested is a lot more important there. -- Ciaran McCreesh Ok then according to your definition that supported arches == stable tree, I can safely assume that we cannot support those arches -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org pgpdR14Vav09n.pgp Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, Jun 27, 2010 at 8:34 PM, Markos Chandras hwoar...@gentoo.org wrote: As many of you have already noticed, there are some arches that are quite slow on stabilizations. This leads to deprecated stabilizations e.g a package is stabilized after 60 days which makes that version of the specific package obsolete and not worth to stabilize anymore. I would suggest to introduce a new rule where a stabilization bug may close after 30 days. Arches that fail to stabilize it within this timeframe they will simply don't have this package stable for them. I disagree that just 30 days is enough to make a package obsolete and not worth stabilizing. Infact, I think you're suggesting the number in jest. GNOME for instance has a 6 month cycle, and we stabilize 1-4 months after the release (depending on the bugs, and our manpower). For instance, the current release is 2.30 (~arch, released in March '10, added to tree just a month ago), the previous release was 2.28 (stable, released in Sept '09), but the stable version on every arch except amd64/x86 is 2.26 (released in March '09). And that's OK since it got stable updates for a long time after release, and works wonderfully. In essence, GNOME packages don't become obsolete unless it's been 2 years since they were released. I'm saying that a 30 days rule is too strict for most packages and herds. I don't think such a rule will fly very far. Even a 90 day rule or a 6 month rule is too strict for GNOME packages. I personally empathize with the needs of users enough that I (and most of the gnome team) are willing to wait for arches that cannot handle stabilization bugs. We really don't want our users to have a bad experience because of *us*. We'll do whatever is in our power. Moreover, slow arches introduce another problem as well. If a package is marked stabled for their arch, but this package is quite old, and they fail to stabilize a new version, we ( as maintainers ) can't drop the very old ( and obsolete ) version of this package because we somehow will break the stable tree for these arches. How should we act in this case? Keep the old version around forever just to say that hey, they do have a stable version for our exotic arch. Now *this* is a problem. We have some bugs, some security bugs that have been completely ignored by some arches. Mips as usual is one, but recently hppa (and to a much lesser extent, ppc64) have become slow. To fix this, I suggest the following heuristic: * If an arch cannot stabilize *security bugs* after 3 months, the maintainers are free to drop the vulnerable version. * If an arch cannot stabilize versions which fix major bugs after 6 months, the maintainers are free to drop the broken version. * If an arch cannot stabilize a feature/minor bugfix stable request after 12 months, the maintainers can nuke stable keywords from their package. In all cases, the time is to be counted from the original stabilization request. Exceptions may be made in case newer stabilization requests add extra dependencies to be stabilized. Similar (but laxer) rules can be made for KEYWORDREQ bugs as well. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sun, Jun 27, 2010 at 4:05 PM, Enrico Weigelt weig...@metux.de wrote: * Nirbheek Chauhan nirbh...@gentoo.org schrieb: Or if they generate the tarball on-the-fly with no caching, which results in differing timestamps each time. Hence, each time you fetch it, you get a tarball with a different hash. Does portage check the timestamps ? I think you need to sit down and understand how tarballs are made, what they contain, and what a hash means, and how it's calculated. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Policy for late/slow stabilizations
On Mon, Jun 28, 2010 at 01:59:42AM +0530, Nirbheek Chauhan wrote: I'm saying that a 30 days rule is too strict for most packages and herds. I don't think such a rule will fly very far. Even a 90 day rule or a 6 month rule is too strict for GNOME packages. I personally empathize with the needs of users enough that I (and most of the gnome team) are willing to wait for arches that cannot handle stabilization bugs. We really don't want our users to have a bad experience because of *us*. We'll do whatever is in our power. The '30 days' was just an example. Any reasonable timeframe could do Moreover, slow arches introduce another problem as well. If a package is marked stabled for their arch, but this package is quite old, and they fail to stabilize a new version, we ( as maintainers ) can't drop the very old ( and obsolete ) version of this package because we somehow will break the stable tree for these arches. How should we act in this case? Keep the old version around forever just to say that hey, they do have a stable version for our exotic arch. Now *this* is a problem. We have some bugs, some security bugs that have been completely ignored by some arches. Mips as usual is one, but recently hppa (and to a much lesser extent, ppc64) have become slow. To fix this, I suggest the following heuristic: * If an arch cannot stabilize *security bugs* after 3 months, the maintainers are free to drop the vulnerable version. What if this version is the only one that is stabled for this arch. Can you imagine the possible breakage that this action might cause? The problem is exactly here. If a package has only one version stable for an exotic arch, you cannot drop it because: * you will break packages that depend on it * you will make users angry -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org pgp3gGTva4ojC.pgp Description: PGP signature
Re: [gentoo-dev] Policy for late/slow stabilizations
On Mon, Jun 28, 2010 at 3:08 AM, Markos Chandras hwoar...@gentoo.org wrote: On Mon, Jun 28, 2010 at 01:59:42AM +0530, Nirbheek Chauhan wrote: Now *this* is a problem. We have some bugs, some security bugs that have been completely ignored by some arches. Mips as usual is one, but recently hppa (and to a much lesser extent, ppc64) have become slow. To fix this, I suggest the following heuristic: * If an arch cannot stabilize *security bugs* after 3 months, the maintainers are free to drop the vulnerable version. What if this version is the only one that is stabled for this arch. Can you imagine the possible breakage that this action might cause? The problem is exactly here. If a package has only one version stable for an exotic arch, you cannot drop it because: * you will break packages that depend on it * you will make users angry I agree. I didn't mean to imply that these heuristics were in any way complete. I wrote them in a hurry; I only wanted to give an idea of what my opinion on the matter is. We can add the following: * For each arch, stable keywords are to be removed from vulnerable/broken versions one week after newer versions are stabilized on that arch. * If removing stable keywords will lead to a large cascading effect of reverse dependencies losing stable keywords, the 3 month wait should be extended to 6 months or 12 months depending on the brokenness and no. of packages that will get their keywords dropped. * Maintainers are free to wait as long as they wish for arches, the above guidelines merely give a lower bound to the wait time. * In extenuating circumstances (critical vulnerabilities, complete brokenness, etc), with the permission of the QA team, the wait can be shortened, but it should never be less than a month. This means that old broken/vulnerable ebuilds are not visible to any arches except those that are slow. And if an arch cannot take out the time to stabilized a vulnerable and/or badly broken version for a full year, there's nothing we can do. If this is a chronic problem, we should consider marking the arch as Experimental. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-06-27 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2010-06-27 23h59 UTC. Removals: dev-util/tkcvs 2010-06-21 09:59:20 jlec dev-util/subversion 2010-06-22 18:18:38 arfrever net-misc/neon 2010-06-22 20:13:06 arfrever sci-mathematics/octave-forge2010-06-24 17:17:42 bicatali net-nntp/knews 2010-06-27 11:10:37 ssuominen Additions: sys-cluster/resource-agents 2010-06-21 07:37:28 xarthisius dev-vcs/tkcvs 2010-06-21 09:52:13 jlec mail-client/claws-mail-geolocation 2010-06-22 08:01:16 fauli media-gfx/scantailor2010-06-22 11:57:56 ssuominen dev-vcs/subversion 2010-06-22 18:17:20 arfrever net-libs/neon 2010-06-22 19:58:23 arfrever app-text/pdf2djvu 2010-06-23 10:22:14 ssuominen dev-python/pygtkhelpers 2010-06-23 23:29:26 arfrever dev-python/anyvc2010-06-23 23:46:34 arfrever dev-python/markupsafe 2010-06-24 00:54:24 arfrever net-wireless/iwl6050-ucode 2010-06-25 19:39:01 mpagano media-libs/simage 2010-06-25 23:17:24 reavertm app-pda/syncevolution 2010-06-26 03:19:47 tester dev-python/gdmodule 2010-06-26 09:21:10 jlec net-fs/smbnetfs 2010-06-26 09:44:57 slyfox sys-cluster/openais 2010-06-26 16:32:39 xarthisius dev-perl/Test-Command 2010-06-27 00:10:03 ssuominen net-wireless/gobi_loader2010-06-27 12:49:12 polynomial-c app-vim/nerdtree2010-06-27 16:36:22 spatz -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-util/tkcvs,removed,jlec,2010-06-21 09:59:20 dev-util/subversion,removed,arfrever,2010-06-22 18:18:38 net-misc/neon,removed,arfrever,2010-06-22 20:13:06 sci-mathematics/octave-forge,removed,bicatali,2010-06-24 17:17:42 net-nntp/knews,removed,ssuominen,2010-06-27 11:10:37 Added Packages: sys-cluster/resource-agents,added,xarthisius,2010-06-21 07:37:28 dev-vcs/tkcvs,added,jlec,2010-06-21 09:52:13 mail-client/claws-mail-geolocation,added,fauli,2010-06-22 08:01:16 media-gfx/scantailor,added,ssuominen,2010-06-22 11:57:56 dev-vcs/subversion,added,arfrever,2010-06-22 18:17:20 net-libs/neon,added,arfrever,2010-06-22 19:58:23 app-text/pdf2djvu,added,ssuominen,2010-06-23 10:22:14 dev-python/pygtkhelpers,added,arfrever,2010-06-23 23:29:26 dev-python/anyvc,added,arfrever,2010-06-23 23:46:34 dev-python/markupsafe,added,arfrever,2010-06-24 00:54:24 net-wireless/iwl6050-ucode,added,mpagano,2010-06-25 19:39:01 media-libs/simage,added,reavertm,2010-06-25 23:17:24 app-pda/syncevolution,added,tester,2010-06-26 03:19:47 dev-python/gdmodule,added,jlec,2010-06-26 09:21:10 net-fs/smbnetfs,added,slyfox,2010-06-26 09:44:57 sys-cluster/openais,added,xarthisius,2010-06-26 16:32:39 dev-perl/Test-Command,added,ssuominen,2010-06-27 00:10:03 net-wireless/gobi_loader,added,polynomial-c,2010-06-27 12:49:12 app-vim/nerdtree,added,spatz,2010-06-27 16:36:22 Done.
[gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
Hello everyone, I'm sure at least half of you are thinking Oh no, not this again..., and I agree. However, I'm /also/ thinking Why the heck haven't we done this yet? We've been discussing this since 2008, and probably waaay before that too. The entire discussion about whether we should do this or not has already passed, there is NO NEED to have that again. This email is about discussion on what all is *left* before we can do $SUBJECT. What prompted this email? libpng-1.4 and many other upgrades that have left gentoo systems very very broken. We have to resort to random scripts to fix breakage, which reflects very badly on us. Even worse, a lot of users just give up and reinstall their system, or don't upgrade, or just move away from Gentoo. I understand that these kind of breakages are inevitable, but with as-needed, we can reduce their effect *drastically*. Instead of having to rebuild almost their entire system, the user would only need to rebuild packages that directly link(ed) to libpng. I honestly think that we cannot afford to expose our users to any more such upgrades without as-needed in the default linux profile. There's a tracker bug for this, and the problems still remaining are: http://bugs.gentoo.org/showdependencytree.cgi?id=129413hide_resolved=1 *Most* of the problems listed there are forced-as-needed problems, which need to be fixed no doubt, but should NOT block addition of --as-needed to LDFLAGS in make.defaults which will not trigger those build failures. What needs to be done now is for someone with lots of CPU power to grab the list of packages[1], and build them one-by-one (all versions), adding to a new list all the ebuilds that fail. How to test: LDFLAGS=-Wl,--as-needed emerge -v1 $atom Once we have the list that fails with normal as-needed, we can fix them, get the fix upstreamed (if possible), and switch the flag on. This action should probably be accompanied by a news item informing users about the change, and encouraging them to report the (rare) bug which might hit them. Let's try to make Gentoo less frustrating for our users. 1. http://dev.gentoo.org/~nirbheek/files/as-needed-failures.list -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 27 Jun 2010 11:47:49 -0400 Olivier Crête tes...@gentoo.org wrote: I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then just drop the old ebuild. These arches will slowly lose stable keywords until their stable tree gets to a size that they can manage. And everyone will be winners. That said, when dropping the old keywords, you have to be careful to drop the stable keyword on all dependencies too so as to not drop break the tree for them. +1 Dead arches need to be allowed to die. jer
