Re: [gentoo-dev] Gentoo Council Reminder for April 23
Mart Raudsepp wrote: So my point is that the whole of the council should consider the objections of an individual council member, so that potentially bad things don't end up accepted based on some kind of an uninformed majority vote or concensus. Probably the best way to accomplish something like this is for a council member to publish their no vote BEFORE the actual council meeting so that there is actually time to discuss it. The actual council meeting isn't really a great forum to resolve issues - there just isn't that much time. I appreciate the fact that council members are avoiding huge amounts of back-and-forth on the mailing list, but waiting until the last minute for a surprise "no" vote isn't helpful either. I think one of the great things Donnie has done for the council is to push the discussion into the mailing list well in advance of the meeting, and to defer issues that haven't gotten properly hashed out on-list. If something really needs interactive discussion that is one thing, but going into a topic cold just results in a lot of "shooting from the hip" and not much constructive progress.
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-04-19 23h59 UTC
Dne čtvrtek 23 Duben 2009 21:46:44 James Cloos napsal(a): > Wierd. > > I must've fat-fingered while reading the list yesterday. > > I didn't even see the message buffer > > -JimC I was just thinking about "THE SECRET MAIL IS SECRET" :D Tomas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-04-19 23h59 UTC
Wierd. I must've fat-fingered while reading the list yesterday. I didn't even see the message buffer -JimC
Re: [gentoo-dev] Gentoo cluster liveCD
Tom Stellard wrote: > I am trying to build the Gentoo cluster live CD using the overlay from > here: git://git.overlays.gentoo.org/proj/clustering-livecd.git I have run > into some problems with some of the ebuilds in this overlay. Here is a > patch to fix the beowulf-head ebuild. > > -Tom Stellard > Please file these patches through bugs.gentoo.org to the overlay maintainers (or the via their other means if they have such). Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: > On 12:15 Thu 23 Apr , Tiziano Müller wrote: >> Am Mittwoch, den 22.04.2009, 23:21 -0700 schrieb Donnie Berkholz: >>> Here is an updated agenda. I've removed a few items that I consider >>> lower priority and unlikely for us to have time for during this >>> week's meeting. Also, I added the issue about USE=static-libs >>> because I think it's important. >> I'd really like to see the topic about "portage changing behaviour" >> being discussed since I see it as crucial for future eapi/portage/pm >> development and I therefore consider it urgent as well. Furthermore it >> has been deferred already once. > > Which other important topic should we drop for it? I'm thinking we > probably won't even get to the last one, that's almost a wish list. I > think there's a pretty reasonable chance we also wouldn't get to > whatever other items came after this one. > > Zac, have you commented on this topic previously? How do you think it > should work? See "Portage changing behavior in ebuild-visible ways" at > http://dev.gentoo.org/~dberkholz/20090514-agenda.txt for a description. > CC'ing you to make sure you see this... In the cases mentioned, I think that more communication would have helped, and I wasn't as careful as I should have been. In the future, I want to strive to use more communication to avoid problems like these. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknwp8EACgkQ/ejvha5XGaME8QCg3O1fMWlN87aH8xyfqy6mZK8+ KxkAoMP7SJKdhZSJ7H8nq47HnmKUXjOF =4e2L -END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Wed, 2009-04-22 at 23:21 -0700, Donnie Berkholz wrote: > > > Goals: Any unanswered queries? Figure out what to do with features > receiving a "no." I think the whole council should understand why something received a "no" from someone, as they might be important technical (or subjective) arguments against having that in EAPI-3, as to be able to make an informed decision that is best for the whole of Gentoo. I believe we have up to now just given individual stances on the features - voting based on that doesn't really work right. It is quite likely that almost all features will get a majority "yes" vote when taken individually because not all council members have seen the problems a few of the council members have. So my point is that the whole of the council should consider the objections of an individual council member, so that potentially bad things don't end up accepted based on some kind of an uninformed majority vote or concensus. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ECONF-OPTIONS (Was: PMS EAPI 3 more or less ready)
On Thu, 23 Apr 2009 20:25:14 +0300 Mart Raudsepp wrote: > > Yes, and in the real world, if you change / whilst something is > > compiling, things break. > > Except with dependency tracking they might not. Disabling dependency tracking will merely change "broken, in a way that may or may not end up being visible" to "broken, in a way that may or may not (under slightly different parameters) end up being visible. > I believe you forgot the topic of --enable-fast-install. Really, I'm in the 'whatever' camp on both of the econf things. I'm happy presenting arguments that have already been made, and debunking any untrue claims I happen to notice, but beyond that on this one I'm happy to just see it go to vote... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] ECONF-OPTIONS (Was: PMS EAPI 3 more or less ready)
On Thu, 2009-04-23 at 13:58 +0100, Ciaran McCreesh wrote: > On Thu, 23 Apr 2009 10:56:56 +0300 > Mart Raudsepp wrote: > > > If a parallel install is overwriting things on / whilst a package is > > > compiling, things are already horribly broken regardless of this > > > switch. PMS explicitly forbids that from happening. > > > > That's that. And then there's the real world. > > Yes, and in the real world, if you change / whilst something is > compiling, things break. Except with dependency tracking they might not. Anyways, I was "whatever" on the --disable-dependency-tracking already. > > > > Olivier Crête also has an outstanding comment about a maintainer > > > > possibly not wanting that disabled in case of patches applied. > > > > Could use some elaboration on that thought, or comments in > > > > replies. > > > > > It's always possible to override it if necessary. > > > > No. It is possible to not use econf and write all of the options it's > > supposed to be passing manually. Probably missing something or > > otherwise being horribly long. > > Uh, you just do econf --enable-dependency-tracking. I apparently did need that nap. Yeah, that should work. I believe you forgot the topic of --enable-fast-install. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] PMS EAPI 3 more or less ready
(Somewhat late, but here we go ) > * PKG-PRETEND critical > * SLOT-OPERATOR-DEPS yes > * USE-DEP-DEFAULTS critical > * DEFINED-PHASES critical > * PROPERTIES critical > * SRC-INSTALL critical > * CONTROLLABLE-COMPRESS critical > * DODOC yes > * DOINS yes > * ANY-USE whatever > * BANNED-COMMANDS yes > * DOEXAMPLE no > * DOINCLUDE whatever > * UNPACK-EXTENSIONS yes > * ECONF-OPTIONS yes > * PKG-INFO critical > * PROFILE-IUSE-INJECTION yes > * AA yes > * KV yes > * REPLACE-VERSION-VARS whatever > * S-WORKDIR-FALLBACK whatever > * UNPACK-IF-COMPRESSED whatever > * RDEPEND-DEPEND yes > * DIE-ON-FAILURE critical > * NONFATAL yes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Thu, 23 Apr 2009 08:53:24 -0700 Donnie Berkholz wrote: > Which other important topic should we drop for it? I'm thinking we > probably won't even get to the last one, that's almost a wish list. I > think there's a pretty reasonable chance we also wouldn't get to > whatever other items came after this one. Might as well hold off GLEPs 54 and 55. They're both effectively EAPI 4 territory anyway. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On 12:15 Thu 23 Apr , Tiziano Müller wrote: > Am Mittwoch, den 22.04.2009, 23:21 -0700 schrieb Donnie Berkholz: > > Here is an updated agenda. I've removed a few items that I consider > > lower priority and unlikely for us to have time for during this > > week's meeting. Also, I added the issue about USE=static-libs > > because I think it's important. > > I'd really like to see the topic about "portage changing behaviour" > being discussed since I see it as crucial for future eapi/portage/pm > development and I therefore consider it urgent as well. Furthermore it > has been deferred already once. Which other important topic should we drop for it? I'm thinking we probably won't even get to the last one, that's almost a wish list. I think there's a pretty reasonable chance we also wouldn't get to whatever other items came after this one. Zac, have you commented on this topic previously? How do you think it should work? See "Portage changing behavior in ebuild-visible ways" at http://dev.gentoo.org/~dberkholz/20090514-agenda.txt for a description. CC'ing you to make sure you see this... -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpS1YXoNjfGz.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Wed, 22 Apr 2009 23:21:26 -0700 Donnie Berkholz wrote: > Here is an updated agenda. I've removed a few items that I consider > lower priority and unlikely for us to have time for during this > week's meeting. Please bring forward dleverton's "Portage repeatedly changing behaviour" thing. Without a resolution to this all the EAPI work we're doing is a waste of time. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] SLOT-OPERATOR-DEPS (Was: PMS EAPI 3 more or less ready)
On Thu, 23 Apr 2009 11:48:08 +0300 Mart Raudsepp wrote: > > The best installed version that matches the spec is always picked > > for :=. We originally considered making this more complicated, or > > possibly making ways of saying "all installed slots", but neither > > appears to have a legitimate use case. The latter in particular > > would only encourage abuse (people might mistakenly think it's a > > solution to the Python / Ruby ABIs thing). > > I don't think that really works in all cases, e.g in combination with > PDEPEND or such. It works in all cases where you're guaranteed to know at build time what versions are there -- that is to say, it works for things that are listed both in DEPEND and in RDEPEND. > So to make this easy for everybody in the future, do you perhaps have > a concrete ebuild code example that shows how exactly to do it in an > ebuild pkg_setup or src_configure exactly? Most things that are affected by this will just work automatically. > My main open issue with SLOT-OPERATOR-DEPS is about the :* syntax, and > specifically how that potentially works un-intuituvely with some > future syntax regarding list of slots. The feature concept itself > seems sound and reasonable, but I think we might be able to do better > with the syntax for the long run when slot lists come into play. It fits in fine with the syntax we've been thinking of using for slot groups and version ranges. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] ECONF-OPTIONS (Was: PMS EAPI 3 more or less ready)
On Thu, 23 Apr 2009 10:56:56 +0300 Mart Raudsepp wrote: > > If a parallel install is overwriting things on / whilst a package is > > compiling, things are already horribly broken regardless of this > > switch. PMS explicitly forbids that from happening. > > That's that. And then there's the real world. Yes, and in the real world, if you change / whilst something is compiling, things break. > > > Olivier Crête also has an outstanding comment about a maintainer > > > possibly not wanting that disabled in case of patches applied. > > > Could use some elaboration on that thought, or comments in > > > replies. > > > It's always possible to override it if necessary. > > No. It is possible to not use econf and write all of the options it's > supposed to be passing manually. Probably missing something or > otherwise being horribly long. Uh, you just do econf --enable-dependency-tracking. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] PKG-INFO (Was: PMS EAPI 3 more or less ready)
On Thu, 23 Apr 2009 01:29:11 -0700 Brian Harring wrote: > On Wed, Apr 22, 2009 at 02:57:34PM +0100, Ciaran McCreesh wrote: > > On Wed, 22 Apr 2009 16:56:08 +0300 > > Petteri Räty wrote: > > > Ok. So people should then be using has_version in pkg_info if they > > > want to detect if it's installed or not? > > > > If they absolutely totally need to detect that, then yes. > > Presuming I read that correctly, invoking has_version w/in pkg x to > see if pkg x is installed seems like redundant code (and slightly > circuitious from a PM standpoint)- why not just export a bool into > the env for pkg_info indicating if it is installed or not? Because you might want to check that foo is installed from within foo, or you might want to check that foo-2 is installed from within foo-2, or you might want to check something subtly different -- and that's before we start thinking about slots. It's not really a bool thing, so has_version is the simplest way for people who need to detect a particular thing to detect it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] New eclass proposal: auto-export
Brian Harring wrote: > On Wed, Apr 22, 2009 at 04:35:37PM +0300, Petteri R??ty wrote: >> Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection >> of functions. This way all eclasses don't have to duplicate the EAPI >> detection code. If people find this useful, I will document it properly >> with eclass-manpages etc. > > Mind you I follow the "Keep It Simple Stupid", but is this really > needed? In other words, how often do people really hit this? > > If it's useful, whatever, but I can see the inverse of the problem > you're trying to solve occuring- folks being told to use autoexport, > then wondering how to block something from being exported... > > Neutral towards it, just seems a bit much imo. > ~harring betelge...@pena ~ $ grep -l src_prepare /usr/portage/eclass/*.eclass | wc -l 19 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
Am Mittwoch, den 22.04.2009, 23:21 -0700 schrieb Donnie Berkholz: > On 15:27 Fri 17 Apr , Donnie Berkholz wrote: > > On 15:17 Fri 17 Apr , Donnie Berkholz wrote: > > > If you have something you'd wish for us to chat about, maybe even vote > > > on, let us know! Simply reply to this e-mail for the whole Gentoo dev > > > list to see. > > > > I've got a few items pending that I would like to propose. It should be > > clear that there are way too many topics in this list for a single > > meeting, so we'll have to prioritize a bit and discuss on list in > > advance as much as possible. > > > > Feel free to reply to this email regarding any of the below items. > > Please change the subject so it's easier to parse through the > > subthreads. > > Here is an updated agenda. I've removed a few items that I consider > lower priority and unlikely for us to have time for during this week's > meeting. Also, I added the issue about USE=static-libs because I think > it's important. > I'd really like to see the topic about "portage changing behaviour" being discussed since I see it as crucial for future eapi/portage/pm development and I therefore consider it urgent as well. Furthermore it has been deferred already once. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] SLOT-OPERATOR-DEPS (Was: PMS EAPI 3 more or less ready)
On Tue, 2009-04-21 at 16:03 +0100, Ciaran McCreesh wrote: > On Tue, 21 Apr 2009 05:11:15 +0300 > Mart Raudsepp wrote: > > > * SLOT-OPERATOR-DEPS > > > > An outstanding problem to me as a package maintainer is the lack of > > means to know which slot the PM actually picked for the package, as > > some of my co-maintained packages have no use of := if it can't know > > which version was picked to act accordingly in src_configure. > > The best installed version that matches the spec is always picked > for :=. We originally considered making this more complicated, or > possibly making ways of saying "all installed slots", but neither > appears to have a legitimate use case. The latter in particular would > only encourage abuse (people might mistakenly think it's a solution to > the Python / Ruby ABIs thing). I don't think that really works in all cases, e.g in combination with PDEPEND or such. But if there is such a guarantee per spec, it's at least covering the common and most reasonable cases. So to make this easy for everybody in the future, do you perhaps have a concrete ebuild code example that shows how exactly to do it in an ebuild pkg_setup or src_configure exactly? My main open issue with SLOT-OPERATOR-DEPS is about the :* syntax, and specifically how that potentially works un-intuituvely with some future syntax regarding list of slots. The feature concept itself seems sound and reasonable, but I think we might be able to do better with the syntax for the long run when slot lists come into play. I need to lay down for a while now (caught a cold), but I'll work on a detailed description of what I have in mind - after thinking it more through to myself - in some 5-7 hours from now. It is also possible that this thinking will result in the conclusion that the proposed syntax is best afterall, but I'll see what I come up with. Still have REPLACED_BY_VERSIONS stuff to think through too, but I don't expect any big controversies from there from me, I hope. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] PKG-INFO (Was: PMS EAPI 3 more or less ready)
On Wed, Apr 22, 2009 at 02:57:34PM +0100, Ciaran McCreesh wrote: > On Wed, 22 Apr 2009 16:56:08 +0300 > Petteri Räty wrote: > > Ok. So people should then be using has_version in pkg_info if they > > want to detect if it's installed or not? > > If they absolutely totally need to detect that, then yes. Presuming I read that correctly, invoking has_version w/in pkg x to see if pkg x is installed seems like redundant code (and slightly circuitious from a PM standpoint)- why not just export a bool into the env for pkg_info indicating if it is installed or not? ~harring pgpu1i5oyg6OD.pgp Description: PGP signature
Re: [gentoo-dev] New eclass proposal: auto-export
On Wed, Apr 22, 2009 at 04:35:37PM +0300, Petteri R??ty wrote: > Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection > of functions. This way all eclasses don't have to duplicate the EAPI > detection code. If people find this useful, I will document it properly > with eclass-manpages etc. Mind you I follow the "Keep It Simple Stupid", but is this really needed? In other words, how often do people really hit this? If it's useful, whatever, but I can see the inverse of the problem you're trying to solve occuring- folks being told to use autoexport, then wondering how to block something from being exported... Neutral towards it, just seems a bit much imo. ~harring pgp0izROL8qjH.pgp Description: PGP signature
Re: [gentoo-dev] ECONF-OPTIONS (Was: PMS EAPI 3 more or less ready)
On Tue, 2009-04-21 at 16:17 +0100, Ciaran McCreesh wrote: > On Tue, 21 Apr 2009 05:11:15 +0300 > Mart Raudsepp wrote: > > > * ECONF-OPTIONS > > > > query > > --disable-dependency-tracking has other implications than it being > > allowed to be passed to ./configure or not - such as dependency > > tracking being, well, disabled and the affects of that in face of any > > outside influences to headers used by it from the system, when > > compared to the case when dependency tracking is enabled. Such as > > when a separate (possibly parallel) install step kicks in. > > If a parallel install is overwriting things on / whilst a package is > compiling, things are already horribly broken regardless of this > switch. PMS explicitly forbids that from happening. That's that. And then there's the real world. > > Olivier Crête also has an outstanding comment about a maintainer > > possibly not wanting that disabled in case of patches applied. Could > > use some elaboration on that thought, or comments in replies. > > It's always possible to override it if necessary. No. It is possible to not use econf and write all of the options it's supposed to be passing manually. Probably missing something or otherwise being horribly long. > > --enable-fast-install is completely new to me for consideration under > > EAPI-3. Maybe I just missed it when reading PMS draft before, and it > > wasn't listed in the other summaries. > > No, it's been there all along. Ok. That doesn't change it's complete pointlessness to be there. Anyway, "whatever" on --disable-dependency-tracking Definitely _no_ on --enable-fast-install. It is already the default and when it isn't (I know of no such cases), upstream maintainer has _explicitly_ made it so. It is not our business to be passing the libtool specific default argument. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
