Re: [gentoo-dev] Re: Portage: missing pieces
On Sun, 9 Jul 2006 23:30:40 +0200 Molle Bestefich [EMAIL PROTECTED] wrote: Richard Fish wrote: The expectation here is that when a new version of gcc is stabilized, that users will upgrade to that in a reasonable amount of time, and use that (by selecting it with gcc-config) for compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th. I don't see how that information is conveyed to the user. It's conveyed by the fact that when updating, you see a new compiler version being installed. If you have done a world update, you already have the later compilers installed. Portage shouts about upgrading to a new profile from time to time, but it never tells anyone to upgrade GCC. Perhaps it should, if that's what the devs expect people to do. As has been explained before, as far as the gcc ebuilds are concerned their job is finished when the new compiler version is installed. It is up to the user to decide to change their system compiler. The gcc ebuild will switch between minor versions if USE=multislot isn't specified, and in that case will warn the user about ABI breakage if relevant, as it requires the user to rebuild lots of stuff. The devs can *not* be expected to verify that all software in portage builds with all versions of gcc in portage. Of course not. The alternative here is that old versions of gcc disappear from portage, but that causes a problem for those who need those versions for some reason, such as compiling non-gentoo software. Yes, ok. That's a bad alternative. Thus it seems that there's no appropriate mechanism to handle new GCC versions in Portage, which again makes sense wrt. the complaints. Portage and the ebuilds handle it fine. All that needs to happen is for users to accept the advice to read the gcc upgrading guide when they trip over problems that arise from issues with gcc versions. Nothing personal against Jakub Moc who probably has a lot to do, but the handling of relevant issues raised in the bugzilla is just unacceptable. What, exactly, do you find unacceptable in Your gcc version is outdated and unsupported? Nothing? I find it unacceptable that the bug is marked INVALID when it clearly describes a relevant issue. Don't take the bug marking as a personal attack - it's a marking for devs to understand what was the impact of the bug. Focus on the advice given, which from what I can see was succinct and correct. As far as I can tell, the complaints are about Portage being unable to handle GCC upgrades gracefully for end users. What exactly do you expect to happen? GCC updates don't switch major versions automatically, because in general it means changing ABI which means rebuilding everything. Where ABI breakage occurs between minor versions and the compiler is switched automatically, the ebuild issues a warning when ABI breakage occurs and advises what to do to rebuild affected packages. You could perhaps argue that the issue started out as why do I get this error message and ended up being why doesn't Portage handle GCC upgrades gracefully, which is of course a slightly different thing. But it should be clear to anyone reading the bug what the real issue is. I'm even willing to bet that if I create a new bug describing the Portage issue, with no mention of the specific xine ebuild, it will get closed as a duplicate of this bug anyway. I've got case studies proving that this is what happens, heh. If two bugs describe the same issue, regardless of the summary field one will get marked as a duplicate of the other. Again, this is not a personal attack but information for devs to understand whether different work is needed for the different bugs. I suppose portage could be enhanced to have a is_gcc_version_supported() check, but I'm not sure how useful that would be. If that would enable ebuild maintainers to flag xine as requiring 3.4 for compilation, then that would definitely solve the issue described in the bug. I'd say that's _very useful_ to the end user. The problem with having the xine ebuild check gcc version and aborting if a certain version is found active, is that if the gcc version is modified in the future such that xine would then build with it, that handling would have to come out again. Since the ebuild dies either way, the only difference is that some users may not realise that upgrading gcc will work - in which case they file a bug and they get told to upgrade gcc - job done. You could argue that only a couple of people has spent the time to create a bugzilla login and lodge a complaint in the bug, but there's probably more out there. We can count the duplicates in a couple of months and see ;-). And as newer GCC features are used throughout, the situation will probably happen more in the future. Another way of looking at it, is that there are a lot of people out there who are coping
Re: [gentoo-dev] Re: Portage: missing pieces
On Sun, 09 Jul 2006 15:27:14 -0700 Josh Saddler [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sun, 09 Jul 2006 22:10:48 +0200 Jakub Moc [EMAIL PROTECTED] wrote: | Not true. According to the 2006.0 x86 profile, for example, you're | required to have =sys-devel/gcc-3.3.4-r1. There is no requirement | that 3.4 be installed. | | Yeah, that's not what I've been talking about at all, what's your | point? I was saying that gcc-3.4 and better is stable everywhere | where it's needed. How does it change that 3.3 is dead as a nail in a | lamproom door and users should switch to something that we actually | can support? Tradition for toolchain stuff has always been that anything allowed by the profile is considered acceptable for general use. So, if users shouldn't be using 3.3, the profile should be changed to say so. Until then there's no obligation to upgrade. Then it seems like that 2006.0 x86 profile should be updated (without waiting for 2006.1 to be released). Dunno if other arches have to run such legacy gcc versions, but the logical thing is to point to 3.4.x instead on x86. I don't believe retro-actively modifying the 2006.0 profile is a good idea in general. The profile currently says that for x86, gcc must be =sys-devel/gcc-3.3.4-r1 - if you do # emerge =sys-devel/gcc-3.3.4-r1 on a current tree you'll get a much higher version. Still, it's up to releng if they wish to change it. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Portage: missing pieces
Kevin F. Quinn wrote: I don't believe retro-actively modifying the 2006.0 profile is a good idea in general. The profile currently says that for x86, gcc must be =sys-devel/gcc-3.3.4-r1 - if you do # emerge =sys-devel/gcc-3.3.4-r1 on a current tree you'll get a much higher version. Still, it's up to releng if they wish to change it. Even if you modify the profile to mask gcc-3.3.x, it won't force people to unmerge their existing gcc-3.3.x since it's slotted and they would already have gcc-3.4.x emerged, correct? And if we can't force them to unmerge it, we can't force them to switch which gcc version is active. Masking in the profile would have no effect if this is true. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new herd: vdr - topic reanimated
On Sun, 9 Jul 2006 19:17:09 +0200 Matthias Schwarzott [EMAIL PROTECTED] wrote: Hi! As the situation now has changed I would like to discuss this one more. Since one week we (hd_brummy and me) have changed our Gentoo VDR Project (http://www.gentoo.org/proj/en/desktop/video/vdr/index.xml) to an official subproject of desktop/video. Now the situation is as follows: Most packages have historically either a) one of us or b) both as a maintainer and the herd media-tv as fallback. c) The newest ebuilds have herd media-tv and [EMAIL PROTECTED] (projects mail-address) as maintainer. We now think that this should be unified. Our ideal would be having the concept of a sub-herd. The best realizable alternatives we can think of are: c) herd media-tv and [EMAIL PROTECTED] (projects mail-address) as maintainer. d) create an own herd vdr. A package can belong to more than one herd. So you could create a media-vdr herd, and have two herd tags in the metadata.xml for the vdr packages; media-tv and media-vdr (I suggest the media- prefix as it's not necessarily obvious what vdr means on its own). If you do this, make sure there's a maintainer tag. However (c) seems to be the most sensible approach. What do you think of that? Zzam -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] new herd: vdr - topic reanimated
On 7/10/06, Robin H. Johnson [EMAIL PROTECTED] wrote: On Mon, Jul 10, 2006 at 04:36:55AM +0200, Diego 'Flameeyes' Petten?? wrote: On Monday 10 July 2006 02:25, Luca Barbato wrote: c is simpler. I like it. Yes, of course if _all wranglers_ respected metadata, instead of stopping to herd tag and assigning to that even when a particular maintainer is listed. Actually, this isn't that simple at the moment. There are packages that directly list me as the maintainer, but I want bugs for them assigned to the herd by default - so that the other folk in the herd can find them quickly. Perhaps this could be alleviated with an explicit assign-to field in package metadata? At the same time, it should have an explicit cc-to field, for cases where the maintainer is not in the herd. My idea would actually be the contrary: that the package is assigned to its maintainer (who could not be in the herd) and the herd(s) are CCed. Uven if the maintainer is in the herd, this procedure should be followed, as it is easier for the maintainer to track down the package. -- Ioannis Aslanidis deathwing00[at]gentoo.org 0xB9B11F4E -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new herd: vdr - topic reanimated
Robin H. Johnson wrote: On Mon, Jul 10, 2006 at 04:36:55AM +0200, Diego 'Flameeyes' Petten?? wrote: On Monday 10 July 2006 02:25, Luca Barbato wrote: c is simpler. I like it. Yes, of course if _all wranglers_ respected metadata, instead of stopping to herd tag and assigning to that even when a particular maintainer is listed. Actually, this isn't that simple at the moment. There are packages that directly list me as the maintainer, but I want bugs for them assigned to the herd by default - so that the other folk in the herd can find them quickly. Perhaps this could be alleviated with an explicit assign-to field in package metadata? At the same time, it should have an explicit cc-to field, for cases where the maintainer is not in the herd. Well, that reminds me - just stick [EMAIL PROTECTED] (or whatever else) to maintainer field then and put it first, enough of a hint for me :) -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/9/06, Molle Bestefich [EMAIL PROTECTED] wrote: As far as I can tell, the complaints are about Portage being unable to handle GCC upgrades gracefully for end users. The thing is, that portage doesn't technically handle gcc upgrades. The user really needs to do that, and they (should) know to do that when they see the new version show up in an emerge -Duv world. Or on GWN. Ok, so some users are not getting that message. To be honest, I have no idea what to do about that. Having dozens (hundreds? all?) ebuilds check for a minimum version of gcc doesn't seem very effecient. I guess portage could check and warn about an unsupported version of gcc being selected for the system compiler, but then I we have to figure out exactly what the supported versions are, and exactly when a version becomes unsupported, as a matter of policy. But that won't even fix the problem. The version of xine-lib that this bug refers to is a ~x86 version. Should that be expected to compile with the stable gcc? Or only with the ~x86 gcc. What if the maintainer doesn't intend to stabilize the package until the ~x86 version of gcc goes stable? So I don't think the issue is as simple as either having xine-lib put out a warning about a particular gcc version, as that doesn't work in the general case. And putting the checks in portage doesn't seem to work very well either. The system as it is now actually seems to work about right...the vast majority of stable users upgrade to new versions of gcc as they come out, hopefully following the upgrade guide, and never see anything fail to build due to the gcc version. Others get informed via other means, and hopefully remember for the future. That won't be necessary. Things mostly works, and when they don't, users file a bug like the aforementioned one, which should result in that particular ebuild getting fixed, instead of the bug being marked INVALID. The thing is, this particular ebuild isn't actually broken. Or I guess if it is, then so are some_potentially_large_number other ebuilds in the tree, since they probably won't build with old gcc versions either. Ok, most would probably build with gcc 3.3. And maybe even gcc 3.1. But 2.95?? Handling this at the ebuild level is just not a good solution for the general case. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/9/06, Denis Dupeyron [EMAIL PROTECTED] wrote: 2) If yes, are there any other flags that ebuilds should die on ? My (user) opinion is that ebuilds should not die on CFLAGS, at least not until per-package CFLAGS are implemented. Now if someone is crazy enough to enable -ffast-math globally or specifically for python in that situation, well, die, spin the cpu fan backwards, melt the hard disk down and sell it for scrap, whatever you want! -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
Richard Fish wrote: That won't be necessary. Things mostly works, and when they don't, users file a bug like the aforementioned one, which should result in that particular ebuild getting fixed, instead of the bug being marked INVALID. The thing is, this particular ebuild isn't actually broken. Or I guess if it is, then so are some_potentially_large_number other ebuilds in the tree, since they probably won't build with old gcc versions either. Ok, most would probably build with gcc 3.3. And maybe even gcc 3.1. But 2.95?? Handling this at the ebuild level is just not a good solution for the general case. -Richard Well yeah, there's nothing broken w/ the ebuild. And xine-lib is _not_ the only thing that just bombs out on sucky compiler version, see fex. http://bugs.gentoo.org/show_bug.cgi?id=121501 There's no sane way to force users to switch their gcc version, so messing w/ ebuild deps, profiles or keywords of outdated gcc versions won't help... -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On Mon, 2006-07-10 at 01:34 -0700, Richard Fish wrote: On 7/9/06, Denis Dupeyron [EMAIL PROTECTED] wrote: 2) If yes, are there any other flags that ebuilds should die on ? My (user) opinion is that ebuilds should not die on CFLAGS, at least not until per-package CFLAGS are implemented. per pkg cflags are here already it would fall under the per pkg env variables. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
Denis Dupeyron [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 09 Jul 2006 23:24:24 +0200: In bug #139412, I ask Paul de Vriese why he thinks python should die on --fast-math instead of just filtering it. Here's his answer : Denis, quite simple. -ffast-math is broken and short-sighted for a global flag. Filtering gives the shortsighted message that it works globally, while it is not suited for any package not specifically tested for it. As it breaks python, dieing makes people understand that it does not work on python. It is better than the alternative of not looking for it at all. As a user active on the lists/groups (and the same would go for forums), and opposing both Ryan Hill's and Richard Fish's opinions, I absolutely agree with Paul on this! My reason for doing so is that I've seen users say they use it with no ill effects they can see on their system. Of course, we know that's because where it has caused problems enough to bug, it has been filtered, but obviously the users don't know that, or are *relying* on it, *not* a good idea IMO. If ebuilds start dying on it, those users will soon see how many things it /does/ break, and should quickly change their minds. This, for me, triggers 3 questions that are gentoo-dev@ material : 1) Should all ebuilds that currently filter --fast-math die on its presence instead of filtering it ? I'd say yes -- provided there's documentation (say a bug where removing it cured the bug) that it's an actual problem with that package. If a maintainer has put the filterflag in simply peremptorily, as I'd argue this particular flag might warrant, that's a different question. IMO, that would be counterproductive, since a user simply removing the die, redigesting, and continuing, would have likely convinced himself of the safety of that flag. 2) If yes, are there any other flags that ebuilds should die on ? I'd say very few, keeping in mind portage's non-interactive philosophy (as Ryan mentioned). Very few are /that/ profoundly stupid, and require someone hit the practitioner upside the head with a cluebat. 3) Suppose that -ftracer, for example, is one of those, and knowing that enabling -fprofile-use enables -ftracer, shouldn't ebuilds also die on use of -fprofile-use ? It's only an example, this situation will exist for other pairs of flags. Given the rarity of a flag as extreme as -ffast-math, I'd say that shouldn't normally be the case. Do note that -ffast-math is itself a meta-flag, enabling several others. I'd /not/ recommend dying on the individual flags, thereby giving those that would use -ffast-math /that/ way to do so if they /insist/ on it -- and have read the documentation well enough to know about it. The hidden question behind these three is : shouldn't we have a something that enables us to safely handle this kind of situations ? Like some kind of system- and/or architecture-wide flag mask that could be overriden by the ebuild and/or the user (at his own risk) ? This could potentialy reduce the number of bugs that poor old bugzie has to cope with, and simplify ebuild writing and maintenance. I'd favor a USE_EXPAND type flag that could take several I'm broken so don't file bugs type strings, which could be individually tested for in the various ebuilds (and/or profiles), while at the same time grouping them automatically for purposes of emerge --info and therefore bug reports. amd64 tests for such IM_BROKEN type vars in their development profiles (would be 2006.1 for example ATM), and I believe gcc tested for (and may still) a similar var during part of the 4.0 process, where users agreed not to file bugs unless they came with patches. Having these all in the same place, perhaps as individual values of a PORTAGE_I_DELIBERATELY_CHOOSE_TO_BE_BROKEN var or the like, where emerge --info would report it yet ebuilds/profiles could test for the presence of individual strings, would be a very good thing IMO. A function or two could then be added to eutils to aid in standardizing the testing for such strings and encourage use of the standard grouping. If that or a similar solution is chosen, then one such string could be created for -ffast-math. Once that was done, a test for that string could be set in profiles/base or the like, setting up the test for -ffast-math system-wide, whereupon it could be eliminated from the individual ebuilds. That would also provide a suitable single-shot environment based solution for the user, as well, in the case they wanted to override the system test for an individual ebuild. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
On 7/10/06, Ryan Hill [EMAIL PROTECTED] wrote: Ebuilds shouldn't die on anything according to the non-interactive portage philosophy. I don't know how official that philosophy is though. Correct me if I'm wrong, but this has nothing to do with being interactive or not. To me, an ebuild that dies (intentionally or due to a build error) isn't interactive at all. 1) Should all ebuilds that currently filter --fast-math die on its presence instead of filtering it ? No, that would be a major pain in the ass for anyone wanting to use -fast-math, which does have legitimate uses. If a package is known not to work with a certain flag, being able to emerge it won't change the fact that it doesn't run. Plus, if the solution is considered good for python, I don't understand why it wouldn't be good for any other package. Are you saying that Paul's proposition of having the python ebuild die on use of --fast-math isn't good ? If yes, why ? And what is your better idea ? 2) If yes, are there any other flags that ebuilds should die on ? There's a million, and they're constantly changing. For example, -frename-registers is generally safe on GCC 3.4, broken in 4.0, and enabled by default on 4.1. Which is exactly the reason why we could benefit of something that enables us to manage this in a clean and safe way. I'm not saying I have a candidate for that something, but I wanted to discuss if there was an interest in it. Let's take again the example of -ftracer which can be enabled by the -fprofile-use meta-flag. Imagine we have a mechanism somewhere (again, the reason I'm being vague is that my point isn't to discuss implementation just yet) that adds -fno-tracer to CFLAGS. In this case, you're covered wether -ftracer was added directly on indirectly by fprofile-use, which actually simplifies the number of flags that you need to blacklist. Thus ebuilds don't have to take care of it, bugs don't pour into bugzie, and Jakub can avoid overheating. Users playing with CFLAGS get to keep the pieces. Trying to dummy-proof the system doesn't help anyone but the dummies. ;) I'm one of those devs who care for our users. I think it's dangerous to try and categorize users in, for example, dummies and non-dummies, as you say. Who are we to judge this or that user is a dummy ? Plus, we all are the dummy of somebody else. Anyway, I was thinking more in terms of making the job of developers, bug wranglers, and poor old bugzilla easier, cleaner, safer. How many bugs do we have that are due to dangerous flags ? How much time and effort could we save if we didn't have those ? Also, I was thinking that if a good solution was found to deal with a dangerous flag in a certain package, maybe it was a good idea to extend this solution to other packages. And finally, if said solution becomes common, maybe it's a good idea to make it system-wide with a possibility to override the setting by the user or the ebuild. It seems we already have per-package CFLAGS, so part of this, at least, is already implemented. On 7/10/06, Richard Fish [EMAIL PROTECTED] wrote: My (user) opinion is that ebuilds should not die on CFLAGS, at least not until per-package CFLAGS are implemented. Why ? Stating your opinion without any justification isn't really constructive. And same as above : being able to emerge a package that won't run doesn't help you more. Now if someone is crazy enough to enable -ffast-math globally or specifically for python in that situation, well, die, spin the cpu fan backwards, melt the hard disk down and sell it for scrap, whatever you want! Same as above again, replace 'dummy' with 'crazy'. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
Denis Dupeyron wrote: This, for me, triggers 3 questions that are gentoo-dev@ material : 1) Should all ebuilds that currently filter --fast-math die on its presence instead of filtering it ? I don't think we should die on anything, if a user wants a particular CFLAG, generally the default should be to let them use it. A warning with a pause may also suffice. Currently the amd64 profiles do some testing for broken USE flags. If the user has flags that gcc will not accept (ie errors out with invalid command line option), our profile.bashrc will filter them out completely. If they have a flag that is on a list of pre-defined bad flags it will warn the user about the flag and sleep for 5 seconds. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
[ resending this, the original appears to have been eaten. ] On Sun, 9 Jul 2006 23:24:24 +0200 Denis Dupeyron [EMAIL PROTECTED] wrote: | 1) Should all ebuilds that currently filter --fast-math die on its | presence instead of filtering it ? http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-environment/index.html Basically, if you're using daft CFLAGS you're on your own. Some ebuilds might filter them, some ebuilds might die and some ebuilds might let them through. Developers are under no obligation to add code to save users from their own stupidity, but they might do so if you ask nicely. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On Sun, 9 Jul 2006 23:24:24 +0200 Denis Dupeyron [EMAIL PROTECTED] wrote: | 1) Should all ebuilds that currently filter --fast-math die on its | presence instead of filtering it ? http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-environment/index.html Basically, if you're using daft CFLAGS you're on your own. Some ebuilds might filter them, some ebuilds might die and some ebuilds might let them through. Developers are under no obligation to add code to save users from their own stupidity, but they might do so if you ask nicely. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On Mon, 10 Jul 2006 10:41:25 +0200 Jakub Moc [EMAIL PROTECTED] wrote: | There's no sane way to force users to switch their gcc version, so | messing w/ ebuild deps, profiles or keywords of outdated gcc versions | won't help... Messing with profiles will, however, give you grounds to close bugs as INVALID. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2.6.17 kernel stabilisation plan
Daniel Drake wrote: Hi, I'm hoping to be able to mark 2.6.17 stable on or around July 11th. I'll give around a weeks notice here when that is to happen. Hopefully we'll use this for the 2006.1 release too. It will be a little later than planned, but this is your 1 week notice that 2.6.17 will go stable on July 17th. There are a couple of packages to fix in the stable tree which I will do my best to see fixed before this happens. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/10/06, Ned Ludd [EMAIL PROTECTED] wrote: per pkg cflags are here already it would fall under the per pkg env variables. Please forgive my stupidity, but the only place I could see to set a env var per package was /etc/portage/bashrc. Is that what you are referring to? -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Fish wrote: On 7/10/06, Ned Ludd [EMAIL PROTECTED] wrote: per pkg cflags are here already it would fall under the per pkg env variables. Please forgive my stupidity, but the only place I could see to set a env var per package was /etc/portage/bashrc. Is that what you are referring to? You're close. There is now a per-package bashrc implementation included in $PORTDIR/profiles/base/profile.bashrc. It's kind of silly imo, when the user can simply put that same code in /etc/portage/bashrc, but this is how it is. :) Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEsolv/ejvha5XGaMRAkeoAJ95/lUC/pSZHeo09JOp/PCOx0HkxwCgoBVl zJW3/SnRt48YXixrIFxt+zo= =mg/P -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Kevin F. Quinn wrote: The expectation here is that when a new version of gcc is stabilized, that users will upgrade to that in a reasonable amount of time, and use that (by selecting it with gcc-config) for compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th. I don't see how that information is conveyed to the user. It's conveyed by the fact that when updating, you see a new compiler version being installed. If you have done a world update, you already have the later compilers installed. No, that's not true. It's not conveyed at all. It might install a new GCC, but it doesn't switch to it. It doesn't tell the user to switch to it, either. As has been explained before, as far as the gcc ebuilds are concerned their job is finished when the new compiler version is installed. It is up to the user to decide to change their system compiler. You seem to have missed the issue. Yes, ok. That's a bad alternative. Thus it seems that there's no appropriate mechanism to handle new GCC versions in Portage, which again makes sense wrt. the complaints. Portage and the ebuilds handle it fine. Same. All that needs to happen is for users to accept the advice to read the gcc upgrading guide when they trip over problems that arise from issues with gcc versions. There's no advice, instead Portage crashes during a system update. Nothing? I find it unacceptable that the bug is marked INVALID when it clearly describes a relevant issue. Don't take the bug marking as a personal attack I don't, it's not my bug ;-). it's a marking for devs to understand what was the impact of the bug. It's marked INVALID, while the issue is clearly valid. Focus on the advice given, which from what I can see was succinct and correct. It shouldn't even be _necessary_ to create bugs and receive advice from a living, breathing human being just to perform a system update. As far as I can tell, the complaints are about Portage being unable to handle GCC upgrades gracefully for end users. What exactly do you expect to happen? GCC updates don't switch major versions automatically, because in general it means changing ABI which means rebuilding everything. Ah, that's a good question. I think the proper reaction from Portage would be (both): a) Alert the user that the newest version of package XYZ cannot be merged because it needs a newer compiler than the currently selected one. b) Skip package XYZ, but continue updating the rest of the system. Package XYZ could also block the update, that would be OK. Again, this is not a personal attack but information for devs to understand whether different work is needed for the different bugs. Noone has mentioned personal attacks, so drop that train of thought. You misread my point. I was trying to say that bugs describing problems (with fx. Portage) in abstract will often get closed as a duplicate of a bug where someone has experienced a particular incarnation of the larger problem described. That's a good way to make sure that relevant end user issues never come into contact with the devs, which I'm sure is not what the devs want. I suppose portage could be enhanced to have a is_gcc_version_supported() check, but I'm not sure how useful that would be. If that would enable ebuild maintainers to flag xine as requiring 3.4 for compilation, then that would definitely solve the issue described in the bug. I'd say that's _very useful_ to the end user. The problem with having the xine ebuild check gcc version and aborting if a certain version is found active, I don't think anyone would implement it that way, since that's braindead ;-). Instead of checking a particular version, checking for a minimum version would be the default available functionality. is that if the gcc version is modified in the future such that xine would then build with it, that handling would have to come out again. In the (hysterically abstract) situation where someone revisits an old version of GCC and adds GCC-4 features, nothing would break. Users would still be told to upgrade to a newer version, and all would be well, despite the fact that the old GCC with the backported feature could now theoretically be used. (But it's just trolling anyway, you're really describing a non-issue, IMHO.) Another way of looking at it, is that there are a lot of people out there who are coping just fine with GCC upgrades as they are currently managed. Uh. What's your point? That you're one of those people who hates change just because it's change, or do you have something more relevant to say that I'm not catching? See https://bugs.gentoo.org/page.cgi?id=fields.html - as far as devs are concerned, The problem described is not a bug so INVALID is the correct resolution marking. Not a bug does not translate to Not an issue. You're practicing an extremely narrow view of what's a bug, and
[gentoo-dev] Removing dev-perl/Test-Builder-Tester
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This package was absorbed back into perl-core/Test-Simple as of the 0.62 release (which you have either via dev-lang/perl-5.8.8 or as the ebuild at this point). I'm package.mask'ing it and will be removing it from the tree in 30 days. Anything that used to dep Test-Builder-Tester has been updated to dep virtual/perl-Test-Simple-0.62, which is available on more arch's stable than T::B::T ever was. (incidently, this also resolves an upgrade/downgrade loop some folks face when emerge -De and emerge -Du are used, I can supply the relevant bug number if you are really super curious). ~mcummings - -- - -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E - -o()o-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEso2oq1ztTp5/Ti4RAu7vAJ0QuTAHlUuIeXGxobZPVtgaOrqJrwCgok0x 2vNpQGvQ9EO20ACjpDw3uL8= =AubO -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Richard Fish wrote: Having dozens (hundreds? all?) ebuilds check for a minimum version Probably just the ebuilds that happen to use new GCC features before the mass of the general public has changed to that version. But yes, a minimum version constraint could theoretically end up in a lot of packages. of gcc doesn't seem very effecient. I can't see why it would not be efficient? I don't think the issue is as simple as either having xine-lib put out a warning about a particular gcc version, as that doesn't work in the general case. Obviously any solution implemented should work for all ebuilds, not just xine-lib. And putting the checks in portage doesn't seem to work very well either. I fail to see how a test in the ebuild for the active GCC compiler version wouldn't work? The system as it is now actually seems to work about right... the vast majority of stable users upgrade to new versions of gcc as they come out Really? How do you gather? I'd think that most users hadn't even run into this problem (yet), because many source code maintainers strive to be able to compile with as old a version of GCC as possible.. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Removing www-servers/resin-ee
I've masked www-servers/resin-ee on 1 July, it will be removed from tree around friday (14 July) - it's old, binary and there's no version 3 of it. Please use www-servers/resin. -- Krzysiek Pawlik nelchael at gentoo.org key id: 0xBC51 desktop-misc, desktop-dock, desktop-wm, x86, java, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Portage: missing pieces
Molle Bestefich wrote: Kevin F. Quinn wrote: The expectation here is that when a new version of gcc is stabilized, that users will upgrade to that in a reasonable amount of time, and use that (by selecting it with gcc-config) for compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th. I don't see how that information is conveyed to the user. It's conveyed by the fact that when updating, you see a new compiler version being installed. If you have done a world update, you already have the later compilers installed. No, that's not true. It's not conveyed at all. It might install a new GCC, but it doesn't switch to it. Sigh. Because it would break your system! It doesn't tell the user to switch to it, either. You really need to research better if you insist on beating a dead horse over and over again. Kindly read the toolchain.eclass: snip einfo You should make sure to rebuild all your C++ packages when einfo upgrading between different versions of gcc. For example, einfo when moving to gcc-3.4 from gcc-3.3, emerge gentoolkit and run: einfo # revdep-rebuild --library libstdc++.so.5 echo einfo For more information on the steps to take when upgrading einfo from gcc-3.3 please refer to: einfo http://www.gentoo.org/doc/en/gcc-upgrading.xml; echo /snip -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Portage: missing pieces
Jakub Moc wrote: Sigh. Because it would break your system! You really need to research better if you insist on beating a dead horse over and over again. Kindly read the toolchain.eclass: You're misreading me. I was merely counter-arguing Kevin, who said that Portage provides plenty of information to the end user about GCC switches being necessary. I was not trying to convince anyone to make Portage switch GCC version automatically. That would probably be rather insane. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Linux World Expo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So who's planning on going? Basically I'd like to know who's planning on going. I'm still undecided about it honestly, and if I go it'd only be for a few days. Its also probably a good way to find a roomate to make the cost of rooms a bit less. We don't have enough dev's close enough to san fran to allow a whole bunch of us a floor to crash on as far as I know. If however you are, give us a shout with floor space ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEsp6zSENan+PfizARAubpAJ9/NtTBUuB2XRkfz0kb6vHoD5zDKgCfRVah WHNtV25i/a5VJnvc80EpmZc= =fUaW -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On Mon, 10 Jul 2006 19:23:54 +0200 Molle Bestefich [EMAIL PROTECTED] wrote: Kevin F. Quinn wrote: The expectation here is that when a new version of gcc is stabilized, that users will upgrade to that in a reasonable amount of time, and use that (by selecting it with gcc-config) for compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th. I don't see how that information is conveyed to the user. It's conveyed by the fact that when updating, you see a new compiler version being installed. If you have done a world update, you already have the later compilers installed. No, that's not true. It's not conveyed at all. It is clear that a new version of GCC is installed. It is also clear that it is not switched to (otherwise the upgrade would have to trundle off and rebuild everything - we'd be swamped with complaints if we did that!). It might install a new GCC, but it doesn't switch to it. By design. It doesn't tell the user to switch to it, either. Again by design. It's up to the user to switch to a different compiler, should they wish to. In other words, it's a user choice which compiler version they use. As has been explained before, as far as the gcc ebuilds are concerned their job is finished when the new compiler version is installed. It is up to the user to decide to change their system compiler. You seem to have missed the issue. Maybe, that wasn't my point. I'm telling you what the situation re. compiler installation actually is, and how it is designed to be. Yes, ok. That's a bad alternative. Thus it seems that there's no appropriate mechanism to handle new GCC versions in Portage, which again makes sense wrt. the complaints. Portage and the ebuilds handle it fine. Same. All that needs to happen is for users to accept the advice to read the gcc upgrading guide when they trip over problems that arise from issues with gcc versions. There's no advice, instead Portage crashes during a system update. The advice is to switch to a more recent compiler. Jakub has made that clear on the bug, and we've said it several times here. As a result, there is no change to be done to any ebuilds etc. Nothing? I find it unacceptable that the bug is marked INVALID when it clearly describes a relevant issue. Don't take the bug marking as a personal attack I don't, it's not my bug ;-). it's a marking for devs to understand what was the impact of the bug. It's marked INVALID, while the issue is clearly valid. OK; one more time. The bug does not lead to any change to anything in the tree. Therefore it is marked INVALID, in that it is not a valid issue with respect to the Gentoo tree. INVALID has the meaning ascribed to it on the bugzilla help page, not the meaning from an English dictionary. When a bug is fixed, something has to change for that fix to happen - if there's no change, either there's a bug that we won't fix (WONTFIX) or there's no bug. In this case there's no bug, in my opinion. Focus on the advice given, which from what I can see was succinct and correct. It shouldn't even be _necessary_ to create bugs and receive advice from a living, breathing human being just to perform a system update. You have to realise that being a constantly moving source distribution, it is impossible to ensure that all packages in all stable versions interoperate in all possible combinations. We don't guarantee that. We do go to some effort to ensure all latest stable versions interoperate when built sensibly, when it comes to a release - that's as far as we can go, realistically. As far as I can tell, the complaints are about Portage being unable to handle GCC upgrades gracefully for end users. What exactly do you expect to happen? GCC updates don't switch major versions automatically, because in general it means changing ABI which means rebuilding everything. Ah, that's a good question. I think the proper reaction from Portage would be (both): a) Alert the user that the newest version of package XYZ cannot be merged because it needs a newer compiler than the currently selected one. I explained above why this wouldn't be a good idea. b) Skip package XYZ, but continue updating the rest of the system. emerge --resume --skipfirst Package XYZ could also block the update, that would be OK. The problem with this is the same as with (a). Again, this is not a personal attack but information for devs to understand whether different work is needed for the different bugs. Noone has mentioned personal attacks, so drop that train of thought. You misread my point. I was trying to say that bugs describing problems (with fx. Portage) in abstract will often get closed as a duplicate of a bug where someone has experienced a particular incarnation of the larger problem described.
Re: [gentoo-dev] Re: Portage: missing pieces
On Mon, 10 Jul 2006 19:32:00 +0200 Molle Bestefich [EMAIL PROTECTED] wrote: Richard Fish wrote: Having dozens (hundreds? all?) ebuilds check for a minimum version Probably just the ebuilds that happen to use new GCC features before the mass of the general public has changed to that version. But yes, a minimum version constraint could theoretically end up in a lot of packages. of gcc doesn't seem very effecient. I can't see why it would not be efficient? Imagine checking over 11,000 packages (over 24,000 ebuilds) against all stable compiler versions in the tree, working out which versions of the compiler currently don't allow each package to build successfully and then adding the relevant code to the ebuild to handle that information. Now imagine updating a compiler version to fix an issue, then having to go through the whole tree looking for ebuilds that restrict against that compiler version, and checking them to see if the restriction can be lifted. It may be efficient for the user, but it creates mountains of work for the volunteer devs whose time is better spent focusing on latest stable versions. I don't think the issue is as simple as either having xine-lib put out a warning about a particular gcc version, as that doesn't work in the general case. Obviously any solution implemented should work for all ebuilds, not just xine-lib. And putting the checks in portage doesn't seem to work very well either. I fail to see how a test in the ebuild for the active GCC compiler version wouldn't work? It wouldn't work in that it's just not maintainable. There's more to a process working than just whether a particular piece of code functions correctly or not. The system as it is now actually seems to work about right... the vast majority of stable users upgrade to new versions of gcc as they come out Really? How do you gather? Suffice to say that many users track the latest stable versions of everything on their system. We don't know how many people stick to old versions or for how long they do so. However if many people remained on old versions of the compiler, I suspect we'd be seeing a lot of bugs related to that - and we're not seeing them. I'd think that most users hadn't even run into this problem (yet), because many source code maintainers strive to be able to compile with as old a version of GCC as possible.. That's unlikely to be true. Some upstream developers do maintain compatibility with a range of compiler versions. Some upstream developers only recommend one specific version. Many will be somewhere in between. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/10/06, Molle Bestefich [EMAIL PROTECTED] wrote: Richard Fish wrote: of gcc doesn't seem very effecient. I can't see why it would not be efficient? I think it is an inefficient use of developer time. Do we really want gentoo devs spending their time figuring out what the minimum gcc version is for their packages, and then having very similar code duplicated in every ebuild in the tree? Is the problem really so serious that it requires that much effort? I am not saying that there should never be a check for a minimum gcc version...maybe if a large enough population of users is having a problem with a particular package because of gcc, then that package _should_ have a check with an appropriate stop using obsolete gcc versions message. But it should only be done in response to bug filings, and at the discretion of the package maintainer. And let's remember that this is a ~arch package. The expectations of people using ~arch is higher than for the stable tree. Indeed, you would probably see a completely different response if this was a problem using the ~x86 gcc to build the ~x86 xine-lib. And putting the checks in portage doesn't seem to work very well either. I fail to see how a test in the ebuild for the active GCC compiler version wouldn't work? But that isn't putting a check in portage, it is adding it to the ebuilds. The system as it is now actually seems to work about right... the vast majority of stable users upgrade to new versions of gcc as they come out I'd think that most users hadn't even run into this problem (yet), Agreed... because many source code maintainers strive to be able to compile with as old a version of GCC as possible.. or alternatively, because most users upgrade gcc to the current version before running into such problems. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/10/06, Molle Bestefich [EMAIL PROTECTED] wrote: It shouldn't even be _necessary_ to create bugs and receive advice from a living, breathing human being just to perform a system update. It isn't necessary. -user, the forums, IRC, all are monitored by living, breathing human beings. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/10/06, Zac Medico [EMAIL PROTECTED] wrote: Richard Fish wrote: On 7/10/06, Ned Ludd [EMAIL PROTECTED] wrote: per pkg cflags are here already it would fall under the per pkg env variables. Please forgive my stupidity, but the only place I could see to set a env var per package was /etc/portage/bashrc. Is that what you are referring to? You're close. There is now a per-package bashrc implementation included in $PORTDIR/profiles/base/profile.bashrc. It's kind of silly imo, when the user can simply put that same code in /etc/portage/bashrc, but this is how it is. :) Ah, thanks, I see it now. I have to say I dislike allowing this backdoor method to set CFLAGS, as they won't show up in emerge --info or emerge -pv pkg. You'd have to see the actual build output to see the nasty flags, which you might not even think to ask for if a package builds fine but crashes randomly later. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
Richard Fish wrote: I have to say I dislike allowing this backdoor method to set CFLAGS, as they won't show up in emerge --info or emerge -pv pkg. You'd have to see the actual build output to see the nasty flags, which you might not even think to ask for if a package builds fine but crashes randomly later. Sounds like your after bug 95741: http://bugs.gentoo.org/show_bug.cgi?id=95741 -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/10/06, Simon Stelling [EMAIL PROTECTED] wrote: Sounds like your after bug 95741: http://bugs.gentoo.org/show_bug.cgi?id=95741 Yeah, that would be nice! :-) -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
Richard Fish wrote: I have to say I dislike allowing this backdoor method to set CFLAGS, as they won't show up in emerge --info or emerge -pv pkg. You'd have to see the actual build output to see the nasty flags, which you might not even think to ask for if a package builds fine but crashes randomly later. How about `cat /var/db/pkg/$category/$package-$version/CFLAGS`? You can't rely on emerge --info anyway, because it shows _current_ flags rather than flags the package was built with. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Pending Removal of $KV
maillog: 09/07/2006-17:17:59(+0100): John Mylchreest types I've tried to clarify my point fairly well above, but the dependancy is fairly strict by design. What in linux-mod except for my specific example above would continue to work if there were no kernel sources present? (I do of course know the answer but its rhetorical) To that end is the reason why the dependancy still exists. That said, I'm open to persuasion. I'm having trouble putting my thoughts in order, so I'll just throw them out, hoping it would make some sense. - if linux-sources is a dependency, then the package usually would need to be rebuilt if the kernel configuration/sources change (linux-mod already faciliates that for a good reason) - even if an ebuild is being smart and is only using linux-info to throw informational messages, the sources dependency is still there - an ebuild should specify the linux-sources dependency on its own if it really needs the sources Having said that, out of the 62 packages that inherit linux-info and do not inherit linux-mod: - 23 only make .config checks (should be non-fatal anyway) - 9 install kernel modules (so they should rather inherit linux-mod) - 8 need the kernel sources to build, so they should probably inherit linux-mod as well - 6 have a DEPEND=virtual/linux-sources already - 4 use linux-info to modify runtime behavior - 2 are obsolete This is only the easily classifiable stuff, but it certainly does seem that the linux-sources dependency can be pulled out of the eclass. -- /\ Georgi Georgiev /\ You have a truly strong individuality. /\ \/[EMAIL PROTECTED]\/\/ /\ http://www.gg3.net/ /\/\ pgpd6vB3yLpHY.pgp Description: PGP signature
[gentoo-dev] Modular X unported packages
With the help of Brian Harring, we've now got a check for unported packages. It indicates 207 unported packages, of which 93 can potentially be fixed by stabilizing newer versions and pulling unported ebuilds from the tree. I've uploaded the list [1]. Run `grep potentially unported-notinc-nonstable-arches.log | cut -d: -f1 | sed -e s:-[0-9].*:: | uniq | wc -l` to get the number of packages that can be stabilized, or `cut -d: -f1 unported-notinc-nonstable-arches.log | sed -e s:-[0-9].*:: | uniq | wc -l` to get the total unported packages. If you want a list, remove the `wc -l` from the end. Thanks, Donnie 1. http://dev.gentoo.org/~dberkholz/broken_modular/unported-notinc-nonstable-arches.log signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New virtuals: virtual/jre and virtual/jdk
Krzysiek Pawlik wrote:
Two new new-style virtuals have been added today to the tree:
- virtual/jdk
- virtual/jre
This allows migration to generation 2 of Java build system to advance.
All virtual/{jdk,jre} have been removed from profiles. The bug for this
was #138747.
Something worth mentioning... If you have problems where dependencies
fail to resolve, like dev-java/blackdown-1.5, or dev-java/kaffe-1.4, it
means you have some stale PROVIDE files kicking around. You will likely
want to run the following to find them:
find /var/db/pkg -name PROVIDE | xargs egrep -l 'virtual/jdk|virtual/jre'
This should give you a list of files to you'll want to delete.
- Josh
--
gentoo-dev@gentoo.org mailing list
