[gentoo-dev] bison/flex extra runtime packages
Hi there! I'm working on a cross compilation to native windows from an Interix Gentoo Prefix, using the normal Prefix portage tree. My setup is nearly the same as when really cross compiling, except that I can execute what I compile. I use command line utilities (DEPEND atoms) from Interix, and all others (RDEPEND, PDEPEND) from winnt. Now some package of mine in a local overlay requires bison and flex. It's quite hard to get those to build _and_ work on winnt, so I though about splitting the bison ebuilds in dev-util/bison and dev-libs/bison-runtime (and the same for flex). What do you think about this? Before we started using portage at our company I built the runtimes only for winnt, so I know this works (for me)... Is there any better Idea around? Cheers, Markus
Re: [gentoo-dev] bison/flex extra runtime packages
On 16-10-2008 09:27:29 +0200, Duft Markus wrote: Now some package of mine in a local overlay requires bison and flex. It's quite hard to get those to build _and_ work on winnt, so I though about splitting the bison ebuilds in dev-util/bison and dev-libs/bison-runtime (and the same for flex). What do you think about this? Before we started using portage at our company I built the runtimes only for winnt, so I know this works (for me)... Not sure if I understand correctly, but if you're aiming for dev-libs/bison-bin, then I prefer to keep on using an overlay for winnt. It's too evasive, IMO. We can just create a new overlay either in gentoo-alt or a new top-level one on overlays.g.o. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] bison/flex extra runtime packages
On Thu, Oct 16, 2008 at 09:27:29AM +0200, Duft Markus wrote: Now some package of mine in a local overlay requires bison and flex. It's quite hard to get those to build _and_ work on winnt, so I though about splitting the bison ebuilds in dev-util/bison and dev-libs/bison-runtime (and the same for flex). What do you think about this? Before we started using portage at our company I built the runtimes only for winnt, so I know this works (for me)... Does yacc build+work maybe? -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpNTaNCHXZwh.pgp Description: PGP signature
RE: [gentoo-dev] bison/flex extra runtime packages
On Thu, Oct 16, 2008 at 09:27:29AM +0200, Duft Markus wrote: Now some package of mine in a local overlay requires bison and flex. It's quite hard to get those to build _and_ work on winnt, so I though about splitting the bison ebuilds in dev-util/bison and dev-libs/bison-runtime (and the same for flex). What do you think about this? Before we started using portage at our company I built the runtimes only for winnt, so I know this works (for me)... Does yacc build+work maybe? Hmm, haven't tried, I must admit, since our software has an explicit depend on binson, since it uses it's runtime library. That's why I would require distinct packages for bin and runtime. Bin should be built as interix executable, which dependes on m4, which I just can't get to work on winnt, and runtime should be built as winnt, since I need to link against it. After playing _many_ hours, this seems to be the only solution. If there are objections against this, I can do it in a local overlay. I just wanted to discuss it, to not do it in the overlay when others might want this too, and just don't have time to do it :) Cheers, Markus -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[gentoo-dev] virtualx eclass
While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. -- Doug Goldstein
[gentoo-dev] Re: virtualx eclass
Doug Goldstein [EMAIL PROTECTED] writes: It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Kinda like good ol' kde.eclass: VIRTUALX_ONLY_TEST=yes inherit virtualx and instead of using IUSE=X for that, IUSE=test. -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgp02mjr9xxds.pgp Description: PGP signature
Re: [gentoo-dev] virtualx eclass
Doug Goldstein wrote: While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Dave Leverton brings up a better suggestion. Providing VIRTUALX_DEPS and having the ebuild just toss that into it's depends as needed.
Re: [gentoo-dev] Re: virtualx eclass
Diego 'Flameeyes' Pettenò wrote: Doug Goldstein [EMAIL PROTECTED] writes: It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Kinda like good ol' kde.eclass: VIRTUALX_ONLY_TEST=yes inherit virtualx and instead of using IUSE=X for that, IUSE=test. That leaves a conditional that must be evaluated in the global scope every time the depends are looked at. And if that isn't set then making xorg-server always required in DEPEND? What about packages that rely on virtualx to depend on xorg-server for them (i.e. a RDEPEND)?
Re: [gentoo-dev] Re: virtualx eclass
Doug Goldstein wrote: Diego 'Flameeyes' Pettenò wrote: Doug Goldstein [EMAIL PROTECTED] writes: It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Kinda like good ol' kde.eclass: VIRTUALX_ONLY_TEST=yes inherit virtualx and instead of using IUSE=X for that, IUSE=test. That leaves a conditional that must be evaluated in the global scope every time the depends are looked at. And if that isn't set then making xorg-server always required in DEPEND? What about packages that rely on virtualx to depend on xorg-server for them (i.e. a RDEPEND)? For the third line item, those packages are broken in general and need to be fixed so that's out of the scope of this.
Re: [gentoo-dev] virtualx eclass
Doug Goldstein wrote: While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Alright... after talking to Diego, Dave, and Remi the final result that I've come up with is the following: VIRTUALX_CONDITIONAL_USE=test inherit virtualx That'll result in virtualx adding the following: DEPEND=test? ( x11-base/xorg-server x11-apps/xhost ) if VIRTUALX_CONDITIONAL_USE is unset (as it will be for all ebuilds initially) the default will be X. Which means the default is the same as what we've got today. If it's set to an empty string, it'll always be required. Otherwise, it will use the supplied USE flag. -- Doug Goldstein
[gentoo-dev] Re: Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Arun Raghavan wrote: I've not really got an opinion on the topic, per se, but fwiw, this is really not a meaningful statistic. *If* parsing strings in the ebuild is not a trivial part of the overall ebuild parsing process, then yes, this is a significant gain and should be treated as such. I find it unlikely that this would be the case. Sure, it's nothing that major, it's just one example of a free performance increase. (Although I would point out that parsing strings is basically what shells do.) Sure, that's nothing in the context of the actual install, but there were a few comments in the huge GLEP-55 thread about performance during cache generation. I'm not sure how one can go about measuring the impact of this on ebuild parsing as a whole. Maybe make take a few typical ebuilds, change quoting style, and run it through ebuild.sh in a loop. All the inherited eclasses would need to change too, though, I guess. Yeah, though I won't be doing it, I've kinda lost my enthusiasm; if anyone's learnt something they didn't know before, that's good enough.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Peter Volkov wrote: Steve, your example only tests how much time bash takes to parse string. It's obvious that in quoted strings some expansions could be avoided and thus bash works faster. Yeah that's all I wanted to get across. But although ebuilds use bash syntax they are interpreted not only by bash - the time to parse stings is negligible to other activities. I have not calculated but made a rough estimation taking into account the number of ebuilds in the tree. So I think we have of order of 10^6 string. This means that during merge of all packages we'll win 10 seconds. I don't think it's worth to consider this gain. Agreed; in the context of a build it's not at all significant. It might be in the context of metadata generation. So in portage tree this is the matter of style. That's said, since personally I don't have any preference on this style and until there will be arguments not to use this style I'll start to use full quotation of the strings. Thanks for taking it on board :-) And yes, in pure bash programs possibly this'll make sense. Yeah; that's effectively what ebuild.sh, combined with all the files it sources, is. (There's quite a bit of code there.) Regards, Steve.
[gentoo-dev] Re: Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Ciaran McCreesh wrote: On Wed, 15 Oct 2008 20:28:43 +0100 Steve Long [EMAIL PROTECTED] wrote: Fernando J. Pereda wrote: A big gain in the context of ebuilds and source packages. Well done. Yes, almost as important as not sourcing any ebuilds, so let's all stick an EAPI extension on the end of the filename. If you really think that EAPI as an extension has anything to do with performance You mentioned performance a few times in that lovely thread when it got shot down, I believe in the context of metadata generation: Performance hit (when discussing an alternative) [1] The GLEP is not about performance, but any solution that forces the introduction of a slowdown of more than, say, 20%, isn't viable. [2] It's several more directory reads. This is a measurable performance hit [3] Are you now saying performance doesn't matter? , you are even more sadly mistaken than usual My how the insults fly.. must be a new academic year. , and I suggest you lay off the GLEP 55 bashing until you've bothered to read it. Yeah cos obviously I never read it when it was last discussed. Way to go with unfounded, clearly absurd, assertions. [1] http://article.gmane.org/gmane.linux.gentoo.devel/53512 [2] http://article.gmane.org/gmane.linux.gentoo.devel/53751 [3] http://article.gmane.org/gmane.linux.gentoo.devel/53668
[gentoo-dev] Re: Re: [RFC] some global useflags
Ciaran McCreesh wrote: Steve Long wrote: Ciaran McCreesh wrote: Markus Meier wrote: server16 Already been discussed, can't be done. What does it break? Have a look at, for example, [1], where Mike already gave you an answer one of the previous times we discussed it. I'm aware of the prior discussion. Re-read it, and tell me what it breaks, if you can.
Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
On Thu, 16 Oct 2008 22:01:40 +0100 Ranjit Singh wrote: If you really think that EAPI as an extension has anything to do with performance You mentioned performance a few times in that lovely thread when it got shot down, I believe in the context of metadata generation: Performance hit (when discussing an alternative) [1] The GLEP is not about performance, but any solution that forces the introduction of a slowdown of more than, say, 20%, isn't viable. [2] It's several more directory reads. This is a measurable performance hit [3] Are you now saying performance doesn't matter? Please re-read what I said. EAPI as an extension has nothing to do with performance. This does not mean that an alternative that has significant performance implications is not a problem. I'll explain it for you in much simpler terms: equipping a car with a new kind of engine and fuel system that is much safer in the case of an accident is a good thing, but not if it also reduces the car's top speed to 30mph. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [RFC] some global useflags
On Thu, 16 Oct 2008 22:06:40 +0100 Steve Long [EMAIL PROTECTED] wrote: Have a look at, for example, [1], where Mike already gave you an answer one of the previous times we discussed it. I'm aware of the prior discussion. Re-read it, and tell me what it breaks, if you can. Well, which part of the previous times it's been explained to you didn't you understand? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
On Thu, Oct 16, 2008 at 10:01:40PM +0100, Steve Long wrote: Ciaran McCreesh wrote: On Wed, 15 Oct 2008 20:28:43 +0100 Steve Long [EMAIL PROTECTED] wrote: Fernando J. Pereda wrote: A big gain in the context of ebuilds and source packages. Well done. Yes, almost as important as not sourcing any ebuilds, so let's all stick an EAPI extension on the end of the filename. If you really think that EAPI as an extension has anything to do with performance You mentioned performance a few times in that lovely thread when it got shot down, I believe in the context of metadata generation: Performance hit (when discussing an alternative) [1] The GLEP is not about performance, but any solution that forces the introduction of a slowdown of more than, say, 20%, isn't viable. [2] It's several more directory reads. This is a measurable performance hit [3] Are you now saying performance doesn't matter? No, performance is just a side effect it has never been part of the motivation of the GLEP. You are the only fighting over stupid pico optimizations. - ferdy pgpa4DJ4UDaap.pgp Description: PGP signature
Re: [gentoo-dev] virtualx eclass
On 11:35 Thu 16 Oct , Doug Goldstein wrote: Doug Goldstein wrote: While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Alright... after talking to Diego, Dave, and Remi the final result that I've come up with is the following: VIRTUALX_CONDITIONAL_USE=test inherit virtualx That'll result in virtualx adding the following: DEPEND=test? ( x11-base/xorg-server x11-apps/xhost ) if VIRTUALX_CONDITIONAL_USE is unset (as it will be for all ebuilds initially) the default will be X. Which means the default is the same as what we've got today. If it's set to an empty string, it'll always be required. Otherwise, it will use the supplied USE flag. I'm not sure whether this would work, but one idea would be to handle dependencies depending on what's in IUSE of the ebuild inheriting. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgphn3ksNxYpD.pgp Description: PGP signature
[gentoo-dev] Gentoo Council Reminder for October 23
This is your friendly reminder ! Same bat time (typically the 2nd 4th Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! 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. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpT0evRxp1Ge.pgp Description: PGP signature
Re: [gentoo-dev] virtualx eclass
On Thursday 16 October 2008 23:54:32 Donnie Berkholz wrote: I'm not sure whether this would work, but one idea would be to handle dependencies depending on what's in IUSE of the ebuild inheriting. That would require ebuilds to set IUSE before inheriting the eclass. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI change: Call ebuild functions from trusted working directory
On Monday 13 October 2008, Ciaran McCreesh wrote: On Mon, 13 Oct 2008 10:42:21 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: It seems to me that this is an EAPI=0 change. Since EAPI=1 and EAPI=2 are just differences to EAPI=0, they wouldn't be voted on. Since EAPI=0 isn't actually approved yet, council wouldn't vote either. As it's a draft standard, this would be resolved amongst package-manager developers and PMS editors. It's a retroactive change to EAPI 0 that requires changes from package managers and has security implications... Robert isn't requesting that we specify and mandate existing behaviour here, so it's not really something that should be left up to PMS to decide and enforce. All package manager developers have implemented this change, and PMS editors have not objected to adding it to the spec. If Ciaran is uncomfortable with adding this change, I would like council to sign off on it. If council will not add this to the agenda, please state so and I hope the PMS folks can add it to the spec without a vote. Furthermore, what are the blockers to vote on PMS as a draft standard for EAPI=0 ? Is there a timeframe for its ratification? Robert signature.asc Description: This is a digitally signed message part.
