Re: [gentoo-dev] Re: Portage: missing pieces
On Mon, 10 Jul 2006 01:18:07 -0500 Andrew Gaffney [EMAIL PROTECTED] wrote: | 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. Yeah. It's more of a tradition thing than a strict technological enforcement. In the past we've always considered any GCC allowed by the profile (that is to say, not masked or out of the packages range) to be valid. Refusing to take bugs from people who're using a GCC permitted by the profile is rather unfair... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
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] 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] 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] 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
[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] 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
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
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
[gentoo-dev] Re: Portage: missing pieces
Molle Bestefich wrote: The current situation is very annoying for users that update often, and also makes Portage mostly unusable for automatic server upgrades After unmerging mono-tools so Portage could finally run a whole update, it stopped halfway through because of this bug: http://bugs.gentoo.org/show_bug.cgi?id=132122 I noticed that several users have commented with a relevant complaint: GCC-4.x is required by the ebuild, but no information is ever conveyed to the end user about this fact. The ebuild does not have a dependency on GCC-4.x. Try reading the bug - users are basically being shoved off with an arrogant silence and a stamp on their forehead saying INVALID. 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's the state of Portage and Gentoo in general? Is there not enough hands to do a proper job? Or is it just that none of the devs see what's wrong because bugs are wrongly being closed marked INVALID such as the above when they're in fact not? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
Molle Bestefich wrote: I noticed that several users have commented with a relevant complaint: GCC-4.x is required by the ebuild, but no information is ever conveyed to the end user about this fact. The ebuild does not have a dependency on GCC-4.x. No, it's not. gcc-3.4.x *is* required. That versions (or later) is *stable* everywhere where xine-lib is stable. Try reading the bug - users are basically being shoved off with an arrogant silence and a stamp on their forehead saying INVALID. 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. Dependency on a particular gcc version will solve exactly nothing. Having that version installed doesn't mean you are really *using* it. You won't be automagically switched to 3.4.x when upgrading from 3.3.x, you won't be automatically switched to gcc 4.x when upgrading from 3.4.x http://www.gentoo.org/doc/en/gcc-upgrading.xml What's the state of Portage and Gentoo in general? Is there not enough hands to do a proper job? Or is it just that none of the devs see what's wrong because bugs are wrongly being closed marked INVALID such as the above when they're in fact not? How about the you finally upgrade your outdated gcc, as asked over and over again? gcc-3.3.x is dead, unsupported upstream, we won't be fixing any bugs there. Hard to understand? Apparently, I guess... Thanks for your rant. -- 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
Re: [gentoo-dev] Re: Portage: missing pieces
On Sun, 09 Jul 2006 21:37:47 +0200 Jakub Moc [EMAIL PROTECTED] wrote: | Molle Bestefich wrote: | I noticed that several users have commented with a relevant | complaint: GCC-4.x is required by the ebuild, but no information is | ever conveyed to the end user about this fact. The ebuild does not | have a dependency on GCC-4.x. | | No, it's not. gcc-3.4.x *is* required. That versions (or later) is | *stable* everywhere where xine-lib is stable. 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. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
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. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Jakub Moc wrote: Try reading the bug - users are basically being shoved off with an arrogant silence and a stamp on their forehead saying INVALID. 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. Dependency on a particular gcc version will solve exactly nothing. Having that version installed doesn't mean you are really *using* it. You won't be automagically switched to 3.4.x when upgrading from 3.3.x, you won't be automatically switched to gcc 4.x when upgrading from 3.4.x Yes ok. So the user has to both merge the new version, and switch to it. Either way, the end user is not getting told what should be done, instead Portage just breaks, which is exactly what all the complaints are about. How about the you finally upgrade your outdated gcc, as asked over and over again? gcc-3.3.x is dead, unsupported upstream, we won't be fixing any bugs there. Hard to understand? Apparently, I guess... I've never been told so, I have no clue what you are talking about. Thanks for your rant. What kind of reply do you expect to get from such crap? Thanks for being an asshole? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/9/06, Molle Bestefich [EMAIL PROTECTED] wrote: Try reading the bug - users are basically being shoved off with an arrogant silence and a stamp on their forehead saying INVALID. *Sigh*. You really should post to -user first. 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. The devs can *not* be expected to verify that all software in portage builds with all versions of gcc in portage. For example, there is still an ebuild for gcc-2.95.3! But that is _not_ to be used for compiling new updates. 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. 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? I suppose portage could be enhanced to have a is_gcc_version_supported() check, but I'm not sure how useful that would be. What's the state of Portage and Gentoo in general? Is there not enough hands to do a proper job? Or is it just that none of the devs see what's wrong because bugs are wrongly being closed marked INVALID such as the above when they're in fact not? If you want to test compiling every version of every package in portage with all 21 versions (16 if you assume all -rX versions are compatible, or /only 9/ if you only consider stable x86 versions) of gcc that are currently in portage, and submit patches when things fail, go ahead. BTW, your patches cannot remove the ability to use improvements that are only available in newer stable versions of gcc, such as -fvisibility=hidden. -Richard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
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. 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. 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. 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. As far as I can tell, the complaints are about Portage being unable to handle GCC upgrades gracefully for end users. 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. 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. 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. What's the state of Portage and Gentoo in general? Is there not enough hands to do a proper job? Or is it just that none of the devs see what's wrong because bugs are wrongly being closed marked INVALID such as the above when they're in fact not? If you want to test compiling every version of every package in portage with all 21 versions (16 if you assume all -rX versions are compatible, or /only 9/ if you only consider stable x86 versions) of gcc that are currently in portage, and submit patches when things fail, go ahead. 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
-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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEsYLBrsJQqN81j74RAidcAKCGdhpAiObclSZuwR8Heod1wqK9yQCgmI16 ax6u8GA7z9GQEkdqErq8xD4= =0VzK -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Richard Fish writes: Unfortunately the Gentoo dev's have taken the rather unusual step of _breaking the tree_ due to a security problem. Thanks for the info. I would really wish that there was some mechanism in place to make sure that the tree was never broken. The current situation is very annoying for users that update often, and also makes Portage mostly unusable for automatic server upgrades :-(. 1. Unmerge both mono-tools and gecko-sharp. That did the trick. I'll have to remerge it later when/if the tree gets fixed... Thanks! (I see now that it was just me that didn't understand how to use --tree, which makes much of this conversation off-topic... Sorry about that!) [1] http://bugs.gentoo.org/show_bug.cgi?id=137665 I'm thinking that a Subversion pre-commit hook to secure integrity of the Portage tree would be cool. The changes listed in the bug above would have to be committed atomically, or it wouldn't get through the integrity check. Perhaps there could be a staging area in the form of a branch where the hypothetical integrity checker wouldn't run. Ho hum, wishful thinking. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Pierre Guinoiseau writes: pam-login is now included in shadow, you no longer need to emerge it. Thanks, that's what I needed to know. I had done an emerge -D world, and suddenly I couldn't turn on the PC. I later found out that /sbin/login had been removed. Richard Fish writes: USE=mono emerge -Devp evolution No mozilla comes in. So evolution does not depend on mozilla, at least not directly. Ok. Same picture here. (Above command pulls in 402 other packages though... caramba) In fact, in the current portage tree, mozilla is going away, and being replaced by seamonkey. Very few (and hard masked) packages like gecko-sdk still depend on mozilla. So what you should eventually end up with is no mozilla but seamonkey. Thanks for the info! Are you using an portage overlay? If so, what is in it? No. No idea what that is. Sounds interesting, though. When was the last time you did an emerge --sync? Yesterday. It changed things a bit since last time (month ago?), but it still wants to merge mozilla. Only now it's mono-tools (or rather gecko-sharp) that wants it, Evolution is out of the picture: [nomerge ] dev-util/mono-tools-1.1.11 [ebuild N] dev-dotnet/gecko-sharp-0.6 [nomerge ] www-client/mozilla-1.7.13 Also, the full output of emerge -Duvpt world Attached. Note that I got rid of the Xorg-6.9 blockers by merging virtual/xft-7.0. Doesn't make any sense to me at all, explanations sought for :-). These are the packages that would be merged, in reverse order: Calculating world dependencies . . !!! Packages for the following atoms are either all !!! masked or don't exist: media-tv/atitvout ... done! [blocks B ] www-client/seamonkey (is blocking www-client/mozilla-1.7.13) [blocks B ] www-client/mozilla (is blocking www-client/seamonkey-1.0.2) [ebuild U ] kde-base/kwalletmanager-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 2,910 kB [ebuild U ] sys-fs/device-mapper-1.02.07 [1.02.02] 902 kB [ebuild U ] kde-base/kdebase-meta-3.5.3 [3.5.2] 0 kB [ebuild U ] kde-base/konsole-3.5.3-r1 [3.5.2-r1] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 6 kB [ebuild U ] kde-base/ksysguard-3.5.3-r1 [3.5.2-r2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% -lm_sensors -zeroconf 0 kB [ebuild U ] kde-base/knetattach-3.5.3 [3.5.1] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kdeprint-3.5.3 [3.5.2] USE=cups kde xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kghostview-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 7,129 kB [ebuild U ] kde-base/ktip-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kate-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kscreensaver-3.5.3 [3.5.1] USE=opengl xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kmenuedit-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kpager-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/drkonqi-3.5.3-r1 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kappfinder-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kxkb-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 5 kB [ebuild U ] kde-base/klipper-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [nomerge ] app-cdr/k3b-0.12.14 USE=alsa encode ffmpeg flac kde mp3 sndfile* vorbis xinerama -arts* -css -debug -dvdr -hal -musepack -musicbrainz -vcd [ebuild U ] app-cdr/cdrdao-1.2.1-r1 [1.2.1] USE=encode gnome -debug -pccts 0 kB [nomerge ] dev-cpp/gtkmm-2.8.1 USE=-debug [ebuild U ]dev-cpp/glibmm-2.8.4 [2.8.1] USE=doc* -debug 1,977 kB [ebuild U ] kde-base/konq-plugins-3.5.3 [3.5.2-r1] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 1,607 kB [ebuild U ] kde-base/konqueror-3.5.3 [3.5.2] USE=java xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kfind-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] dev-libs/openobex-1.2-r1 [1.0.1] USE=bluetooth% -debug% -irda% -syslog% -usb% 333 kB [nomerge ] media-video/konverter-0.92_beta1 USE=xinerama -arts* -debug [ebuild U ] media-libs/xine-lib-1.1.2_pre20060328-r9 [1.1.2_pre20060328-r1] USE=X aac alsa asf directfb esd* fbcon ffmpeg flac gnome ipv6 mad opengl oss sdl theora vorbis win32codecs xinerama xv -a52 -aalib -arts* -debug -dts -dvd -dxr3
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/7/06, Molle Bestefich [EMAIL PROTECTED] wrote: Are you using an portage overlay? If so, what is in it? No. No idea what that is. Sounds interesting, though. It is a local portage tree with ebuilds that you have either written yourself or downloaded from others. Since the overlay will override what is in portage, you can easily get yourself into trouble this way. So it is not really recommended unless you *really* know what you are doing! [nomerge ] dev-util/mono-tools-1.1.11 [ebuild N] dev-dotnet/gecko-sharp-0.6 [nomerge ] www-client/mozilla-1.7.13 *Sigh*. What a mess. Unfortunately the Gentoo dev's have taken the rather unusual step of _breaking the tree_ due to a security problem. And from what I understand [1], mozilla is going to be package masked today (if it hasn't already), so the block messages should go away, but you'll get even worse no package to satisify messages. At this point your choices are fairly limited, and neither one is very good. 1. Unmerge both mono-tools and gecko-sharp. Mono-tools requires gecko-sharp, and that requires mozilla. You can use equery files mono-tools to see what you will lose by going this route. 2. Manually unmask mozilla (and probably mono-tools and gecko-sharp) to keep them around. This might work, but I think you're going to be jumping through a lot of hoops to try and avoid seamonkey. -Richard [1] http://bugs.gentoo.org/show_bug.cgi?id=137665 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Molle Bestefich wrote: I think a piece might be missing from Portage. I'll depict my workflow as an example. Same thing with a package called 'seamonkey': # emerge -Dpt world These are the packages that would be merged, in reverse order: Calculating world dependencies... done! [blocks B ] www-client/seamonkey (is blocking www-client/mozilla-1.7.13) [blocks B ] =sys-apps/shadow-4.0.14-r2 (is blocking sys-apps/pam-login-4.0.14) [blocks B ] sys-apps/pam-login (is blocking sys-apps/shadow-4.0.15-r2) ... etc ... # emerge --unmerge seamonkey --- Couldn't find 'seamonkey' to unmerge. No packages selected for removal by unmerge. # equery d seamonkey [ Searching for packages depending on seamonkey... ] # Nobody wants a seamonkey, and I haven't got one already, but Portage wants to smuggle one in anyway if I tell it to upgrade world. Where's the piece that can tell me why Portage wants to do so? (Alternatively, what's the manual process to find out?) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
Molle Bestefich wrote: Same thing with a package called 'seamonkey': Same answer as you got on the -user list: use --tree But don't only look at the top section of the output. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Dont snip. The relevant part comes *after* the blocks lines. Aah. I get it. Thanks. Sorry for the noise. www-client/seamonkey (is blocking www-client/mozilla-1.7.13) Also, you are mis-interpreting the blocks lines. The correct reading of X (is blocking Y) is that you have (or should have) X installed, and now portage wants to install Y instead. Usually this is because Y supercedes the functionality that used to be provided by X, and in almost all cases, the right thing to do is to unmerge X and merge Y. Evolution depends on Mozilla and Mono depends on SeaMonkey. Mono is the newer (actively developed... sort of) component, also, from what I've heard, SeaMonkey is based on a vastly newer version of Gecko. So I'm not sure how that fits with the above. Anyway, I tried unmerging SeaMonkey and merging Mozilla, which went fine. Doesn't help any with the blocker status, though. So I'm stuck here. Is it impossible to have Mono and Evolution installed at the same time? (Same story with OpenSSH and pam-login. OpenSSH wants shadow, and pam-login refuses to merge alongside shadow. I want both pam-login and OpenSSH, but seems like I'll have to choose, right?) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
(Same story with OpenSSH and pam-login. OpenSSH wants shadow, and pam-login refuses to merge alongside shadow. I want both pam-login and OpenSSH, but seems like I'll have to choose, right?) pam-login is now included in shadow, you no longer need to emerge it. -- Pierre Guinoiseau Email: [EMAIL PROTECTED] M$N: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/6/06, Molle Bestefich [EMAIL PROTECTED] wrote: Evolution depends on Mozilla and Mono depends on SeaMonkey. I don't think this is right, at least not for what is currently in portage. When I do a USE=mono emerge -Devp evolution No mozilla comes in. So evolution does not depend on mozilla, at least not directly. In fact, in the current portage tree, mozilla is going away, and being replaced by seamonkey. Very few (and hard masked) packages like gecko-sdk still depend on mozilla. So what you should eventually end up with is no mozilla but seamonkey. So I'm stuck here. Is it impossible to have Mono and Evolution installed at the same time? No, it is certainly possible, as I have both on my system. Are you using an portage overlay? If so, what is in it? When was the last time you did an emerge --sync? Also, the full output of emerge -Duvpt world would still be useful for us to see. -Richard -- gentoo-dev@gentoo.org mailing list
