[gentoo-dev] Re: [gentoo-dev-announce] Unused ebuild built_with_use cleanup
On Sun, 25 Oct 2009 11:48:39 +0200 Petteri Räty betelge...@gentoo.org wrote: James Cloos wrote: When you first psoted this list I noticed some (or several?) live ebuilds. Git- is the one I remember. Those should not get nuked during global cleanups, as they are likely to be in active use notwithstanding their keywording or masking. -JimC Their maintainers should be active and switch their ebuilds to EAPI 2. If they don't have an active maintainer, then do we want to keep live ebuilds for them around? Your stated goal was to remove unused ebuilds, which live ebuilds are not, regardless of the status of the maintainer. And I'm pretty sure git has an active maintainer. :P -- fonts, Character is what you are in the dark. gcc-porting, wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Unused ebuild built_with_use cleanup
On Tuesday 27 October 2009 02:07:02 Ryan Hill wrote: On Sun, 25 Oct 2009 11:48:39 +0200 Petteri Räty wrote: James Cloos wrote: When you first psoted this list I noticed some (or several?) live ebuilds. Git- is the one I remember. Those should not get nuked during global cleanups, as they are likely to be in active use notwithstanding their keywording or masking. Their maintainers should be active and switch their ebuilds to EAPI 2. If they don't have an active maintainer, then do we want to keep live ebuilds for them around? Your stated goal was to remove unused ebuilds, which live ebuilds are not, regardless of the status of the maintainer. And I'm pretty sure git has an active maintainer. :P indeed. you really should file bugs for these instead of deleting ebuilds on people who missed a thread on gentoo-dev. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: perl-5.10.1 status update
* Torsten Vellert...@gentoo.org: After that I'll minimize my perl work if no more people join to help. Plan revised: I stop doing perl work right now. Thanks
Re: [gentoo-dev] RFC: multilib and the compatibility to singlelib
Mike Frysinger wrote:
On Wednesday 21 October 2009 07:34:18 Michael Haubenwallner wrote:
Mike Frysinger wrote:
On Tuesday 20 October 2009 09:06:29 Michael Haubenwallner wrote:
As I'm building the toolchain myself too, I configure it with the
32bit host triplet on each platform, usually disabling multilib.
this doesnt make any sense to me
What exactly doesn't make sense to you:
it doesnt make sense to build your own toolchain when the default native one
Gentoo provides includes all multilib support already.
but i guess when you're commercially developing a binary-only package, people
tend to not have such freedoms as the binary-only mentality infects all
layers.
Even if it's commercially, it isn't binary-only here. But it is bound
to a specific set of (likely older) toolchain versions usually not
available on the target system.
I just don't want to make an exception for Gentoo Linux hosts when it
does work on both RedHat and SuSE Linux as well as *nix.
Isn't the intention of multilib to have a new (64bit) system
be compatible with the corresponding old (32bit) system?
your description of compatible is pretty vague. ignoring /lib -
/lib64 symlink (which shouldnt matter to any binaries), i'm not aware of
any differences off the top of my head.
Well, compatible here means to me that when I do
$ configure --{build,host}=i686-pc-linux-gnu
assuming you simply forgot the forcing of -m32 here, or you have a fully
named
i686-pc-linux-gnu-... toolchain
I do (like to) have a fully qualified i686-pc-linux-gnu-* toolchain.
Adding -m32 would require to create the i686-pc-linux-gnu-gcc wrapper,
resulting in some kind of a fully qualified i686 toolchain again.
It turns out that it is the /lib resolving to 64bit thing only that
causes me headaches here, which actually is distro-specific.
i'm not against changing things to fall in line with what other distros have
settled on (guess that's the risk you take when you're one of the first
distros to do multilib), i just want this kind of decision to be fully
informed / thought out before making it. it's not something i'd label
trivial.
Fully agreed. But as I don't have time to carry on this symlink change,
I'm going to live with the patches for now (in Prefix).
OTOH, Debian uses /lib-/lib64 symlink too IIRC...
Thank you!
/haubi/
Re: [gentoo-dev] Re: perl-5.10.1 status update
On Tue, Oct 27, 2009 at 11:10 PM, Torsten Veller t...@gentoo.org wrote: * Torsten Vellert...@gentoo.org: After that I'll minimize my perl work if no more people join to help. Plan revised: I stop doing perl work right now. Thanks Sorry to see you go. Thanks for all that you have done so far anyway, its greatly appreciated, we have a Works For Me 5.10.1 in tree, even as its still masked, that's an achievement to be proud of IMHO. -- Kent perl -e print substr( \edrgmaM SPA nocomil.i...@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Re: perl-5.10.1 status update
On Tuesday 27 October 2009 11:10:39 Torsten Veller wrote: * Torsten Vellert...@gentoo.org: After that I'll minimize my perl work if no more people join to help. Plan revised: I stop doing perl work right now. Thanks for all the time you spent on perl. I can understand that doing everything by yourself and getting no support and almost no feedback is exhausting, so I can't even be upset about your decision. You've done an awesome job while it lasted :) I'll try to be available as proxy-committer for perl things, but since I don't have that much experience with it I'll have to rely on the input of others. I hope a few other devs feel motivated to help out. Take care, Patrick
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/desklet-Mouse: - New directory
Joe Sapp (nixphoeni) wrote: nixphoeni09/10/27 11:21:25 Log: Directory /var/cvsroot/gentoo-x86/x11-plugins/desklet-Mouse added to the repository Since when did we start adding big letters to other than perl -categories? *Very* ugly.
Re: [gentoo-dev] Re: perl-5.10.1 status update
Torsten Veller wrote: * Torsten Vellert...@gentoo.org: After that I'll minimize my perl work if no more people join to help. Plan revised: I stop doing perl work right now. Thanks I am also sorry to see you stop. You have gotten a lot accomplished in a short period of time and it was a joy to see your work in action. Good luck and hope to see you around :) -david
Re: [gentoo-dev] Re: [gentoo-dev-announce] Unused ebuild built_with_use cleanup
Mike Frysinger wrote: On Tuesday 27 October 2009 02:07:02 Ryan Hill wrote: On Sun, 25 Oct 2009 11:48:39 +0200 Petteri Räty wrote: James Cloos wrote: When you first psoted this list I noticed some (or several?) live ebuilds. Git- is the one I remember. Those should not get nuked during global cleanups, as they are likely to be in active use notwithstanding their keywording or masking. Their maintainers should be active and switch their ebuilds to EAPI 2. If they don't have an active maintainer, then do we want to keep live ebuilds for them around? Your stated goal was to remove unused ebuilds, which live ebuilds are not, regardless of the status of the maintainer. And I'm pretty sure git has an active maintainer. :P indeed. you really should file bugs for these instead of deleting ebuilds on people who missed a thread on gentoo-dev. -mike All developers are required to follow gentoo-dev-announce. If they don't follow that, it can't be expected for them to follow bugzilla either. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Unused ebuild built_with_use cleanup
James Cloos wrote: Petteri == Petteri Räty betelge...@gentoo.org writes: Petteri Their maintainers should be active and switch their ebuilds to Petteri EAPI 2. If they don't have an active maintainer, then do we Petteri want to keep live ebuilds for them around? What possible benefit could be had from dropping ebuilds for no other reason than their EAPI? The goal is to eventually get rid of built_with_use. Your initial post indicated that you only wanted to drop ebuilds which were unlikely to be in use by users. Given the fact that most (all?) live ebuilds are masked, any automated tests for the likelyhood that an ebuild is in active use will, by definition, have false negatives when dealing with live ebuilds. (Where false negative means unlikely to be in use even though it, in fact, is in use.) If you read the code I attached you will see that the reason live ebuilds show up in there is because adjutrix -U puts them to the list because they don't have any keywords. It follows my original reasoning that for live ebuilds the solution is to migrate them to EAPI 2. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Unused ebuild built_with_use cleanup
On Tuesday 27 October 2009 09:09:48 Petteri Räty wrote: Mike Frysinger wrote: On Tuesday 27 October 2009 02:07:02 Ryan Hill wrote: On Sun, 25 Oct 2009 11:48:39 +0200 Petteri Räty wrote: James Cloos wrote: When you first psoted this list I noticed some (or several?) live ebuilds. Git- is the one I remember. Those should not get nuked during global cleanups, as they are likely to be in active use notwithstanding their keywording or masking. Their maintainers should be active and switch their ebuilds to EAPI 2. If they don't have an active maintainer, then do we want to keep live ebuilds for them around? Your stated goal was to remove unused ebuilds, which live ebuilds are not, regardless of the status of the maintainer. And I'm pretty sure git has an active maintainer. :P indeed. you really should file bugs for these instead of deleting ebuilds on people who missed a thread on gentoo-dev. All developers are required to follow gentoo-dev-announce. If they don't follow that, it can't be expected for them to follow bugzilla either. that's a poor excuse. file bugs instead of tromping on other people's packages since you clearly have a list of ebuilds you shouldnt be removing and you dont intend to fix. i doubt Ryan's example of git- is the only one. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME
On Tue, Oct 27, 2009 at 12:07:08PM -0400, Richard Freeman wrote: R??mi Cardona wrote: Le 26/10/2009 22:58, Richard Freeman a ??crit : Gentoo is about choice. No it isn't. Gentoo is about empowering users, giving them the ability and tools to _change_ the distro to _their_ needs. Gentoo does _not_ cater to all the possible needs. This is somewhat off-topic, but it irks me every time I see/hear it, so there. Well, I'm not sure I see any contradiction. When people say that gentoo is about choice, it means that we should give the end-user flexibility whenever it is feasible. Of course that doesn't mean that there should be a lunar-lander-in-a-box use flag. However, if KDE 4.2 includes a lunar lander module we should in fact add such a flag for the benefit of those of us who don't own space programs. Agreed. However, I think the discussion is around whether we should enable the lunar-lander-in-a-box use flag by default and where it should be enabled by us if we do enable it. Since profiles override IUSE defaults, if we enable the flag in the profiles, this means that it will be enabled for all packages that have the use flag, regardless of whether they are KDE related, unless the user disables the flag in make.conf or package.use. On the other hand, if we enable it with IUSE defaults at the package level, it lets the user decide whether or not they want it to be enabled for their entire system by editing make.conf. Imho the profiles should enable only use flags that are necessary for running that profile and allow users and package maintainers to control the rest. -- William Hubbs gentoo accessibility team lead willi...@gentoo.org pgpbTKeJIGaJC.pgp Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME
William Hubbs schrieb: On Tue, Oct 27, 2009 at 12:07:08PM -0400, Richard Freeman wrote: R??mi Cardona wrote: Le 26/10/2009 22:58, Richard Freeman a ??crit : Gentoo is about choice. No it isn't. Gentoo is about empowering users, giving them the ability and tools to _change_ the distro to _their_ needs. Gentoo does _not_ cater to all the possible needs. This is somewhat off-topic, but it irks me every time I see/hear it, so there. Well, I'm not sure I see any contradiction. When people say that gentoo is about choice, it means that we should give the end-user flexibility whenever it is feasible. Of course that doesn't mean that there should be a lunar-lander-in-a-box use flag. However, if KDE 4.2 includes a lunar lander module we should in fact add such a flag for the benefit of those of us who don't own space programs. Agreed. However, I think the discussion is around whether we should enable the lunar-lander-in-a-box use flag by default and where it should be enabled by us if we do enable it. Since profiles override IUSE defaults, if we enable the flag in the profiles, this means that it will be enabled for all packages that have the use flag, regardless of whether they are KDE related, unless the user disables the flag in make.conf or package.use. On the other hand, if we enable it with IUSE defaults at the package level, it lets the user decide whether or not they want it to be enabled for their entire system by editing make.conf. Are you sure about this part? Afaik IUSE defaults overrides make.conf, you will have to explicitly add an entry to package.use for every package, where it is enabled per IUSE default. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME
On Tue, Oct 27, 2009 at 06:43:52PM +0100, Thomas Sachau wrote: William Hubbs schrieb: On Tue, Oct 27, 2009 at 12:07:08PM -0400, Richard Freeman wrote: R??mi Cardona wrote: Le 26/10/2009 22:58, Richard Freeman a ??crit : Gentoo is about choice. No it isn't. Gentoo is about empowering users, giving them the ability and tools to _change_ the distro to _their_ needs. Gentoo does _not_ cater to all the possible needs. This is somewhat off-topic, but it irks me every time I see/hear it, so there. Well, I'm not sure I see any contradiction. When people say that gentoo is about choice, it means that we should give the end-user flexibility whenever it is feasible. Of course that doesn't mean that there should be a lunar-lander-in-a-box use flag. However, if KDE 4.2 includes a lunar lander module we should in fact add such a flag for the benefit of those of us who don't own space programs. Agreed. However, I think the discussion is around whether we should enable the lunar-lander-in-a-box use flag by default and where it should be enabled by us if we do enable it. Since profiles override IUSE defaults, if we enable the flag in the profiles, this means that it will be enabled for all packages that have the use flag, regardless of whether they are KDE related, unless the user disables the flag in make.conf or package.use. On the other hand, if we enable it with IUSE defaults at the package level, it lets the user decide whether or not they want it to be enabled for their entire system by editing make.conf. Are you sure about this part? Afaik IUSE defaults overrides make.conf, you will have to explicitly add an entry to package.use for every package, where it is enabled per IUSE default. I just tested this, and make.conf overrides iuse defaults. To verify this for yourself, pick a package with an iuse default turning on a flag, then turn off the flag in make.conf and check what would happen if you emerged the package. package.use overrides for a single package, but make.conf overrides for all of your system. -- William Hubbs gentoo accessibility team lead willi...@gentoo.org pgpKZ1xjYOJSj.pgp Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME
On Tue, Oct 27, 2009 at 11:29 PM, William Hubbs willi...@gentoo.org wrote: I just tested this, and make.conf overrides iuse defaults. To verify this for yourself, pick a package with an iuse default turning on a flag, then turn off the flag in make.conf and check what would happen if you emerged the package. package.use overrides for a single package, but make.conf overrides for all of your system. This behaviour is controlled by the variable USE_ORDER. make.globals sets this to: USE_ORDER=env:pkg:conf:defaults:pkginternal:env.d -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: adding a modification timestamp to the installed pkgs database (vdb)
Brian Harring wrote: The proposal is pretty simple; if code modifies the vdb in any fashion, it needs to update the mtime on a file named '.modification_time' in the root of the vdb. I'd to prefer using the mtime of the /var/db/pkg directory itself, since existence of a '.modification_time' file isn't going to prove that an programs that don't recognize that file haven't made any modifications. We can also use the mtimes of category subdirectories, in order to indicate whether a modification has occurred in any given category. -- Thanks, Zac
Re: [gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME
On Tue, Oct 27, 2009 at 11:37:38PM +0530, Nirbheek Chauhan wrote: On Tue, Oct 27, 2009 at 11:29 PM, William Hubbs willi...@gentoo.org wrote: I just tested this, and make.conf overrides iuse defaults. ??To verify this for yourself, pick a package with an iuse default turning on a flag, then turn off the flag in make.conf and check what would happen if you emerged the package. package.use overrides for a single package, but make.conf overrides for all of your system. This behaviour is controlled by the variable USE_ORDER. make.globals sets this to: USE_ORDER=env:pkg:conf:defaults:pkginternal:env.d That is correct, and the documentation (man make.conf) gives a very strong warning about changing this setting: Do not modify this value unless you are a developer and you know what you are doing. If you change this and something breaks, we will not help you fix it. I can't find the bug right now, but at one point I asked in a bug about the possibility of switching the order of defaults and pkginternal on the grounds that if a maintainer wants to disable a use flag for a package that is enabled in the profile they can't because the profile overrides the iuse defaults. It was closed as wontfix because it has been agreed that the profile's use flag settings should have a higher priority than the ebuild's. I'm cool with that, but that is also why I think the use flags the profiles enable should be the bare essentials for using that profile. -- William Hubbs gentoo accessibility team lead willi...@gentoo.org pgpJcdNpQuTLK.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Unused ebuild built_with_use cleanup
Mike Frysinger wrote: On Tuesday 27 October 2009 09:09:48 Petteri Räty wrote: Mike Frysinger wrote: On Tuesday 27 October 2009 02:07:02 Ryan Hill wrote: On Sun, 25 Oct 2009 11:48:39 +0200 Petteri Räty wrote: James Cloos wrote: When you first psoted this list I noticed some (or several?) live ebuilds. Git- is the one I remember. Those should not get nuked during global cleanups, as they are likely to be in active use notwithstanding their keywording or masking. Their maintainers should be active and switch their ebuilds to EAPI 2. If they don't have an active maintainer, then do we want to keep live ebuilds for them around? Your stated goal was to remove unused ebuilds, which live ebuilds are not, regardless of the status of the maintainer. And I'm pretty sure git has an active maintainer. :P indeed. you really should file bugs for these instead of deleting ebuilds on people who missed a thread on gentoo-dev. All developers are required to follow gentoo-dev-announce. If they don't follow that, it can't be expected for them to follow bugzilla either. that's a poor excuse. file bugs instead of tromping on other people's packages since you clearly have a list of ebuilds you shouldnt be removing and you dont intend to fix. i doubt Ryan's example of git- is the only one. -mike Normally old versions are not kept around as already said if you read the thread. Live ebuilds shouldn't really have been in the original list with my intended logic. For them I will usually just migrate them to EAPI 2 like with other packages we have been touching. Using a tracker bug makes sense if you expect some action from individual maintainers which is not the case here as they can just leave the job to people nuking built_with_use like me. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
On Tuesday 27 October 2009 14:46:31 Petteri Räty wrote: Normally old versions are not kept around as already said if you read the thread. normal is not the same thing as always. unless you're the maintainer, you have no idea whether old versions are kept there on purpose. ive had people delete older versions of packages on me simply because they made this invalid assumption without talking to the maintainer. the rest of the thread is irrelevant as this point was not made. a quick check of your list shows wine/uclibc shouldnt be blindly culled. Live ebuilds shouldn't really have been in the original list with my intended logic. For them I will usually just migrate them to EAPI 2 like with other packages we have been touching. OK Using a tracker bug makes sense if you expect some action from individual maintainers which is not the case here as they can just leave the job to people nuking built_with_use like me. i dont plan on fixing my ebuilds soonish since this isnt a terribly important issue, but they'll get fixed at some point -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: adding a modification timestamp to the installed pkgs database (vdb)
On Tue, Oct 27, 2009 at 11:32:30AM -0700, Zac Medico wrote: Brian Harring wrote: The proposal is pretty simple; if code modifies the vdb in any fashion, it needs to update the mtime on a file named '.modification_time' in the root of the vdb. I'd to prefer using the mtime of the /var/db/pkg directory itself, since existence of a '.modification_time' file isn't going to prove that an programs that don't recognize that file haven't made any modifications. Grumble. Works for me. We can also use the mtimes of category subdirectories, in order to indicate whether a modification has occurred in any given category. Pkgcore already relies on that for old style virtuals cache. The pisser there is that modifications w/in a node don't result in a category level mtime- it certainly would be nice to have it formalized in some fashion so that cache regeneration could just work on the areas it needs to. ~brian pgphkBO4EE29C.pgp Description: PGP signature
