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 >> 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 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 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 n
[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 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: 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 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=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
[gentoo-dev] mail-mta/courier needs a new maintainer
mail-mta/courier is without an active ebuild maintainer and has an open security bug [1]. Anyone willing to take care of this package in the future, please update metadata.xml and CC yourself on the bug. [1] https://bugs.gentoo.org/show_bug.cgi?id=135005 -- Sune Kloppenborg Jeppesen Gentoo Linux Security Team pgpz2aB6m6vjr.pgp Description: PGP signature
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 ab
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 . 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 . 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 . 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
Re: [gentoo-dev] Removing www-servers/resin-ee
Krzysiek Pawlik wrote: > 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. > it's not replaced by resin pro ? -- gentoo-dev@gentoo.org mailing list
