Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Is there a reason why we should ram through a new EAPI for something that *looks* like another Paludis supports this so let's make it a Portage standard proposal? Is there some kind of time deadline here that you all want? Also, why the bannination of || ( foo? (.).) -- how is it error prone, exactly. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Ideas for a (fast) EAPI=3
Hi, Josh Saddler nightmo...@gentoo.org: Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Is there a reason why we should ram through a new EAPI for something that *looks* like another Paludis supports this so let's make it a Portage standard proposal? Is there some kind of time deadline here that you all want? built_with_use supports exactly that with the --missing switch and yesterday I noticed some ebuilds that could not be transferred to EAPI 2 because of that. Also, why the bannination of || ( foo? (.).) -- how is it error prone, exactly. I would like to hear about that, too. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 08 Mar 2009 00:08:37 -0800 Josh Saddler nightmo...@gentoo.org wrote: Is there a reason why we should ram through a new EAPI for something that *looks* like another Paludis supports this so let's make it a Portage standard proposal? Is there some kind of time deadline here that you all want? If we were sticking through things Paludis has that're useful, the list would be an awful lot longer... And not everything on that list is even in Paludis... But hey, some things never go out of fashion. A few things on the list are required pretty soon. Bug 249166 and various existing screwups in the tree suggest that [use(+)] (or whatever syntax is decided upon) is going to crop up fairly frequently. And certain people are reluctant to nuke their prepalldocs calls despite Council decisions... I think the rest are just there because they're useful and easy. Also, why the bannination of || ( foo? (.).) -- how is it error prone, exactly. Last time I checked, every single use of foo? as a direct child of || in the tree was wrong, as were the Portage docs. Let's say you have the following: DEPEND=|| ( foo? ( cat/foo ) bar? ( cat/bar ) cat/baz ) Then this is wrong: if use foo ; then myconf=--enable-foo elif use bar ; then myconf=--enable-bar else myconf=--enable-baz fi Here's why: Say the user already has baz installed, and has USE=foo. The package manager will see that baz is already installed, and as per the rules for || will not look at the foo or bar deps. So if the user doesn't have foo installed, the --enable-foo will be wrong. So the 'correct' code would have to be something like this: if use foo has_version cat/foo ; then myconf=--enable-foo elif use bar has_version cat/bar ; then myconf=--enable-bar else myconf=--enable-baz fi Except this is *still* a mess, because a user who has USE=foo bar is going to end up with a differently configured package depending upon what he happens to have installed up-front, which is something that's not supposed to happen. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 8 Mar 2009, Ciaran McCreesh wrote: Last time I checked, every single use of foo? as a direct child of || in the tree was wrong, as were the Portage docs. Let's say you have the following: DEPEND=|| ( foo? ( cat/foo ) bar? ( cat/bar ) cat/baz ) Then this is wrong: if use foo ; then myconf=--enable-foo elif use bar ; then myconf=--enable-bar else myconf=--enable-baz fi I would suspect that in most of such cases the code expresses what is intended, but the dependency should be changed: foo? ( cat/foo ) !foo? ( bar? ( cat/bar ) !bar? ( cat/baz ) ) Ulrich
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 00:08 -0800 schrieb Josh Saddler: Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Is there a reason why we should ram through a new EAPI for something that *looks* like another Paludis supports this so let's make it a Portage standard proposal? Ok, first it's not about paludis,portage,pkgcore,whatever but about the ebuild-format. Paludis also fails if you have DEPEND=cat/foo[moo] in bar-0.1.ebuild but cat/foo doesn't have a moo USE flag. So, please let's focus on the problems we have and try to find a solution. Please fill in the blanks in the table if you know how portage has it implemented. And I used the word fast because people start to use use-dependencies on a larger scale leading to more problems like the one I described in the example. In fact, you could already say that for git the dep-tree is broken because newer subversion doesn't carry the dso USE flag anymore. Is there some kind of time deadline here that you all want? Well, 2 weeks discussion and 1 month implementation would be cool. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 08 Mar 2009, Tiziano Müller wrote: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ I get Not Found - Error 404 for this URL. Ulrich
Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
On Sunday 08 March 2009 05:22:03 Donnie Berkholz wrote: FYI, using EXPORT_FUNCTIONS before inherit, as this patch caused x-modular.eclass to do, is broken in current portage releases. Zac said he would change this to be consistent with the lack of any ordering restriction in the PMS. Thanks to Tomáš Chvátal for tracking down this tricky bug! Better to ask for PMS to be clarified. All existing package managers do EXPORT_FUNCTIONS in more or less the same way, so changing it shouldn't happen without an EAPI bump.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
2009-03-08 10:43:44 Tiziano Müller napisał(a): Am Sonntag, den 08.03.2009, 00:08 -0800 schrieb Josh Saddler: Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Is there a reason why we should ram through a new EAPI for something that *looks* like another Paludis supports this so let's make it a Portage standard proposal? Ok, first it's not about paludis,portage,pkgcore,whatever but about the ebuild-format. Paludis also fails if you have DEPEND=cat/foo[moo] in bar-0.1.ebuild but cat/foo doesn't have a moo USE flag. So, please let's focus on the problems we have and try to find a solution. Please fill in the blanks in the table if you know how portage has it implemented. And I used the word fast because people start to use use-dependencies on a larger scale leading to more problems like the one I described in the example. In fact, you could already say that for git the dep-tree is broken because newer subversion doesn't carry the dso USE flag anymore. http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-util/subversion/subversion-1.5.5.ebuild?view=markup contains: IUSE=apache2 berkdb debug doc +dso emacs extras java nls perl python ruby sasl vim-syntax +webdav-neon webdav-serf ^^^ (Subversion 1.6.* also has dso USE flag.) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 12:05 +0100 schrieb Arfrever Frehtes Taifersar Arahesis: 2009-03-08 10:43:44 Tiziano Müller napisał(a): Am Sonntag, den 08.03.2009, 00:08 -0800 schrieb Josh Saddler: Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Is there a reason why we should ram through a new EAPI for something that *looks* like another Paludis supports this so let's make it a Portage standard proposal? Ok, first it's not about paludis,portage,pkgcore,whatever but about the ebuild-format. Paludis also fails if you have DEPEND=cat/foo[moo] in bar-0.1.ebuild but cat/foo doesn't have a moo USE flag. So, please let's focus on the problems we have and try to find a solution. Please fill in the blanks in the table if you know how portage has it implemented. And I used the word fast because people start to use use-dependencies on a larger scale leading to more problems like the one I described in the example. In fact, you could already say that for git the dep-tree is broken because newer subversion doesn't carry the dso USE flag anymore. http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-util/subversion/subversion-1.5.5.ebuild?view=markup contains: IUSE=apache2 berkdb debug doc +dso emacs extras java nls perl python ruby sasl vim-syntax +webdav-neon webdav-serf ^^^ True, but subversion-1.4* doesn't. Anyway, it was meant as an example... signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] Re: How to speed up maintenance and other Gentoo work?
Hi, (Mail sent to gentoo-dev gentoo-scm, please Fu2 gentoo-scm only) On Sat, Mar 07, 2009 at 06:29:08PM -0800, Robin H. Johnson wrote: On Sat, Mar 07, 2009 at 07:57:02PM -0500, Caleb Cushing wrote: On Sat, Mar 7, 2009 at 2:27 PM, Alec Warner anta...@gentoo.org wrote: People are working on the whole 'replace cvs with git' thing on the gentoo-scm list. I'm supposedly on that list and I haven't gotten a message all week? is it low traffic? or do I have a subscription/other problem. It's fairly low traffic. The last discussion was just under 2 weeks ago, was about how Manifests would need to be changed to cut down on merge conflicts. The last proposal on that was to consider a form of slim Manifest for developers only (it would still be a full form going to rsync), where objects in git were not explicitly tracked in the Manifest, but rather but signed commits (not tags), as their checksums were tracked by the DVCS anyway. Additionally, there is this pending item on a Git resource usage bug that hurts badly during the initial clone: http://archives.gentoo.org/gentoo-scm/msg_df7c98ec7d2e313856bec31769df407f.xml Following this discussion on the dev list, it appears that some of us missed the 'replace cvs with git' project going on here (on gentoo-scm). As it's very time consuming to find the relevant previous threads. So, could someone give us more information of the state of the project ? (general expected workflow, technical issues, etc) A brief abstract would be very much appreciated. I've read the above link. Now, I know about the Manifest issue. Also, did you had information on how git hosted overlays work ? Thanks, -- Nicolas Sebrecht
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sunday 08 March 2009, Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ I'm not sure if you would like to discuss items to be added to the spreadsheet on this list first, but I accidently added default_src_install (bug 33544) to the list. I did not know it would store and share changes immediately. However, the proposed implementation on the bug does not follow the ideas of adding arguments to the default_src_* implementations (230725). Still, I think adding the default src_install function to EAPI=3 would be both trivial and an improvement for many simple ebuilds. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 08:49 Sun 08 Mar , Tiziano Müller wrote: So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ It's still being edited, so I have no idea whether I'm commenting on the same version as was originally posted. Regardless, here's a few points on the version I'm reading: - pkg_pretend() and a default src_install() would be excellent to have. - docompress is good - doheader/doinclude would be nice, same for dodoc -r, doins symlinks - fixing problems in some existing features would be useful - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I strongly oppose this implementation because it makes ebuilds less like bash scripts that are easy to understand. Instead I suggest extending use_with() and use_enable() to accept multiple sets of arguments (alternately, making custom, similar functions that will take multiple args). Combined with the addition of src_configure() in EAPI=2, the amount of code could be a large reduction from existing versions without raising the barrier to entry. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpm0J8uQhoXG.pgp Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 8 Mar 2009 09:42:29 -0700 Donnie Berkholz dberkh...@gentoo.org wrote: - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I strongly oppose this implementation because it makes ebuilds less like bash scripts that are easy to understand. Instead I suggest extending use_with() and use_enable() to accept multiple sets of arguments (alternately, making custom, similar functions that will take multiple args). How would that work? I can't see an obvious way of doing it that isn't more or less as verbose as just using multiple calls. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 16:48 Sun 08 Mar , Ciaran McCreesh wrote: On Sun, 8 Mar 2009 09:42:29 -0700 Donnie Berkholz dberkh...@gentoo.org wrote: - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I strongly oppose this implementation because it makes ebuilds less like bash scripts that are easy to understand. Instead I suggest extending use_with() and use_enable() to accept multiple sets of arguments (alternately, making custom, similar functions that will take multiple args). How would that work? I can't see an obvious way of doing it that isn't more or less as verbose as just using multiple calls. It would just eliminate all but one call to use_with(). Depending on how many you've got, this can shorten things up a fair bit. Here's an example: econf \ $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') econf \ $(use_with x X) \ $(use_with foo libfoo) \ $(use_with bar) \ $(use_with python pygtk) -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpnd1Ie6CDqQ.pgp Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tiziano Müller wrote: | Hi everyone | | With eapis 1 and 2 we introduced nice features but also a couple of new | problems. One of them are the use dependencies when the package you | depend on doesn't have the use flag anymore (see [1] for an example). Hello all, ~Now that this topic was brought to light, I would like to add another point... ~I'm not sure if this has been worked out, or I just don't know how it is done, but a lot of python packages ~need to check use flags for dev-lang/python, like tk or threads for example. Now this is tricky considering the slotting of ~the interpreter. Let me give you an example: ~Suppose I have both python-2.5 and python-2.6 installed. python-2.5 was installed with tk use flag enabled but python-2.6 has it disabled. ~When some package tries to check for foo? ( dev-lang/python[tk] ) it will merge nicely because the use dep restriction is achieved with python-2.5, even ~if python-2.6 is the selected interpreter and it misses the tk use flag. Is there a way to workaround this? am I missing something? or is just something else ~to take into account for next eapi? ~Thanks a lot, ~Best regards, ~Jesus Rivero (Neurogeek) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmz/lMACgkQdIssYB9vBoPEbwCfYg/BaEhRtNCv1LChbqdAt8RW T8oAmwaA6Jz2HX5NbSHhD3XeN7JnqAHL =oJr/ -END PGP SIGNATURE-
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Mar 08, 2009 at 10:01:05AM -0700, Donnie Berkholz wrote: How would that work? I can't see an obvious way of doing it that isn't more or less as verbose as just using multiple calls. It would just eliminate all but one call to use_with(). Depending on how many you've got, this can shorten things up a fair bit. Here's an example: econf \ $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') econf \ $(use_with x X) \ $(use_with foo libfoo) \ $(use_with bar) \ $(use_with python pygtk) I like this idea also, but I would prefer using something other than spaces in each argument, like so: econf \ $(use_with x:X foo:libfoo bar python:pygtk) - -- William Hubbs gentoo accessibility team lead willi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmz/zUACgkQblQW9DDEZTgnugCgkTMUOCQUbcAs9qcvxxmt2Wna BY4AoKAjdpzXkiiizFsQ8MKUmAwHxZMC =lFam -END PGP SIGNATURE-
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 08 Mar 2009 12:50:19 -0430 Jesus Rivero neurog...@gentoo.org wrote: ~if python-2.6 is the selected interpreter and it misses the tk use flag. Is there a way to workaround this? am I missing something? or is just something else ~to take into account for next eapi? Fixing this mess properly really requires package manager support for multiple ABIs (for some value of B that includes things like Python versions). I doubt this is fixable in the timeframe that seems to be being considered here. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). you can solve this right now, even if in a not very elegant way. For instance, if you need glibc with NPTL support, you can use elibc_glibc? ( =sys-libs/glibc-2.3 || ( sys-libs/glibc-2.6[nptl] =sys-libs/glibc-2.6 ) ) -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 10:01 Sun 08 Mar , Donnie Berkholz wrote: On 16:48 Sun 08 Mar , Ciaran McCreesh wrote: On Sun, 8 Mar 2009 09:42:29 -0700 Donnie Berkholz dberkh...@gentoo.org wrote: - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I strongly oppose this implementation because it makes ebuilds less like bash scripts that are easy to understand. Instead I suggest extending use_with() and use_enable() to accept multiple sets of arguments (alternately, making custom, similar functions that will take multiple args). How would that work? I can't see an obvious way of doing it that isn't more or less as verbose as just using multiple calls. It would just eliminate all but one call to use_with(). Depending on how many you've got, this can shorten things up a fair bit. Here's an example: econf \ $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') econf \ $(use_with x X) \ $(use_with foo libfoo) \ $(use_with bar) \ $(use_with python pygtk) And the straightforward evolution of this would be additional with() and enable() functions for mandatory support. I still find this more intuitive than the set of variables. econf \ $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') \ $(with foo bar blah baz) \ $(enable bam paw tick) -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpx0EF3mG45G.pgp Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 10:01 -0700 schrieb Donnie Berkholz:
On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
On Sun, 8 Mar 2009 09:42:29 -0700
Donnie Berkholz dberkh...@gentoo.org wrote:
- I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I
strongly oppose this implementation because it makes ebuilds less
like bash scripts that are easy to understand. Instead I suggest
extending use_with() and use_enable() to accept multiple sets of
arguments (alternately, making custom, similar functions that will
take multiple args).
How would that work? I can't see an obvious way of doing it that isn't
more or less as verbose as just using multiple calls.
It would just eliminate all but one call to use_with(). Depending on how
many you've got, this can shorten things up a fair bit. Here's an
example:
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
econf \
$(use_with x X) \
$(use_with foo libfoo) \
$(use_with bar) \
$(use_with python pygtk)
The above could be rewritten to:
ECONF_USE_WITH='x X' 'foo libfoo' 'bar' 'python pygtk'
econf $(use_with ${ECONF_USE_WITH})
or an eclass could even export this:
src_configure() {
[ -n ${ECONF_USE_WITH} ] USE_WITH=$(use_with
\${ECONF_USE_WITH}\)
econf ${USE_WITH}
}
Guessing from what I see in the gnome/kde eclasses I think people will
implement the above then in eclasses and I therefore don't see why we
can't do it like that from the beginning...
(Besides, there are already shortcuts in eclasses like G2CONF=...)
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 19:06 +0100 schrieb Stelian Ionescu: On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). you can solve this right now, even if in a not very elegant way. For instance, if you need glibc with NPTL support, you can use elibc_glibc? ( =sys-libs/glibc-2.3 || ( sys-libs/glibc-2.6[nptl] =sys-libs/glibc-2.6 ) ) Well, that's exactly what could be avoided and eventually be written as: elibc_glibc? ( =sys-libs/glibc-2.3[nptl(+)] ) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 17:22 +0100 schrieb Robert Buchholz: On Sunday 08 March 2009, Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ I'm not sure if you would like to discuss items to be added to the spreadsheet on this list first, but I accidently added default_src_install (bug 33544) to the list. I did not know it would store and share changes immediately. This accident was intended ;-) However, the proposed implementation on the bug does not follow the ideas of adding arguments to the default_src_* implementations (230725). Still, I think adding the default src_install function to EAPI=3 would be both trivial and an improvement for many simple ebuilds. Fine by me. I didn't add this bug because I thought that the discussion about it could get too controversal and thus not suited for a fast release of a new eapi (mainly thought to be fixing bugs). signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 11:24 -0700 schrieb Donnie Berkholz:
On 10:01 Sun 08 Mar , Donnie Berkholz wrote:
On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
On Sun, 8 Mar 2009 09:42:29 -0700
Donnie Berkholz dberkh...@gentoo.org wrote:
- I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I
strongly oppose this implementation because it makes ebuilds less
like bash scripts that are easy to understand. Instead I suggest
extending use_with() and use_enable() to accept multiple sets of
arguments (alternately, making custom, similar functions that will
take multiple args).
How would that work? I can't see an obvious way of doing it that isn't
more or less as verbose as just using multiple calls.
It would just eliminate all but one call to use_with(). Depending on how
many you've got, this can shorten things up a fair bit. Here's an
example:
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
econf \
$(use_with x X) \
$(use_with foo libfoo) \
$(use_with bar) \
$(use_with python pygtk)
And the straightforward evolution of this would be additional with() and
enable() functions for mandatory support. I still find this more
intuitive than the set of variables.
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') \
$(with foo bar blah baz) \
$(enable bam paw tick)
Which could already be written as ...
econf --with-{foo,bar}
using bash :-)
(or did I miss the point?)
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 19:35 Sun 08 Mar , Tiziano Müller wrote:
Am Sonntag, den 08.03.2009, 11:24 -0700 schrieb Donnie Berkholz:
On 10:01 Sun 08 Mar , Donnie Berkholz wrote:
On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
On Sun, 8 Mar 2009 09:42:29 -0700
Donnie Berkholz dberkh...@gentoo.org wrote:
- I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I
strongly oppose this implementation because it makes ebuilds less
like bash scripts that are easy to understand. Instead I suggest
extending use_with() and use_enable() to accept multiple sets of
arguments (alternately, making custom, similar functions that will
take multiple args).
How would that work? I can't see an obvious way of doing it that isn't
more or less as verbose as just using multiple calls.
It would just eliminate all but one call to use_with(). Depending on how
many you've got, this can shorten things up a fair bit. Here's an
example:
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
econf \
$(use_with x X) \
$(use_with foo libfoo) \
$(use_with bar) \
$(use_with python pygtk)
And the straightforward evolution of this would be additional with() and
enable() functions for mandatory support. I still find this more
intuitive than the set of variables.
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') \
$(with foo bar blah baz) \
$(enable bam paw tick)
Which could already be written as ...
econf --with-{foo,bar}
using bash :-)
(or did I miss the point?)
Consistency, and that gets pretty ugly after a few when you also want to
pass arguments to them.
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpijeydm3D5W.pgp
Description: PGP signature
[gentoo-dev] LC_ALL=C Set by default for portage
Hi, lately i see that in our bugzilla most of the build reports are reported with localized build logs which we dont understand. This leads to us asking the user to run the emerge once more with LC_ALL=C. Wont it be nice to have this variable set by default in portage so users reporting bugs report in English? Since if everything goes fine they dont even bother about the warnings/errors and if something goes wrong it ends up on us to solve the mess :] The LC_ALL should be set for all relevant configure/compile/install phases at least. Regards Tomas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
Nirbheek Chauhan wrote:
On Sat, Mar 7, 2009 at 3:20 PM, Ulrich Mueller u...@gentoo.org wrote:
On Fri, 06 Mar 2009, Donnie Berkholz wrote:
Any thoughts?
+ *)
+ die Unknown EAPI ${EAPI}
+ ;;
Is is safe to assume that an unknown EAPI will provide a die
function?
If we get all Ciaran-ey about that, then we can't even assume the
existence of a case statement in some future version of bash (which is
required by some EAPI)
I think in these cases we just have to use common sense. If a function
is deprecated or known to be 'on the way out' then using them would
obviously be a bad idea. On the other hand even if they are used,
surely someone would test an ebuild and discover this case pretty quickly.
Re: [gentoo-dev] LC_ALL=C Set by default for portage
Hi, lately i see that in our bugzilla most of the build reports are reported with localized build logs which we dont understand. This leads to us asking the user to run the emerge once more with LC_ALL=C. Wont it be nice to have this variable set by default in portage so users reporting bugs report in English? Since if everything goes fine they dont even bother about the warnings/errors and if something goes wrong it ends up on us to solve the mess :] Moreover this would automagically solve the [a-z] friends regexp failures; though that's still good QA to fix them but we wouldn't encounter them anymore. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] LC_ALL=C Set by default for portage
On Sun, Mar 08, 2009 at 09:20:14PM +0100, Tomáš Chvátal wrote: Hi, lately i see that in our bugzilla most of the build reports are reported with localized build logs which we dont understand. This leads to us asking the user to run the emerge once more with LC_ALL=C. Wont it be nice to have this variable set by default in portage so users reporting bugs report in English? I can't speak for others, but I'd like to find and fix bugs with strange locales, at least for the packages I maintain. If portage were to force LC_ALL=C on me, I'd have a very hard time doing so.
Re: [gentoo-dev] LC_ALL=C Set by default for portage
On Sun, Mar 08, 2009 at 09:27:20PM +0100, Alexis Ballier wrote: Moreover this would automagically solve the [a-z] friends regexp failures; though that's still good QA to fix them but we wouldn't encounter them anymore. We would encounter them when using the programs outside of portage, but not when running the testsuite (if available) from within portage. It would succeed in working around compile-time only bugs, but it would be a major pain for locale bugs that can also cause problems at run time.
[gentoo-dev] Packages needing manitainer
We (kde team) have some packages that we are not interested much/are so popular that we cant handle their bugload/releases/etc. So here they are: media-sound/amarok for both kde3 and kde4 version net-misc/mDNSResponder Is there around some brave soul that would became maintainer for this two (or at least one :P)? Regard Tomas Chvatal Gentoo KDE Herd Testers Lead signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages needing manitainer
Le 08/03/2009 21:38, Tomáš Chvátal a écrit : net-misc/mDNSResponder How about dropping this one in favor of avahi? Or am I missing something obvious? Cheers :) Rémi
Re: [gentoo-dev] Packages needing manitainer
Dne neděle 08 Březen 2009 22:54:23 Rémi Cardona napsal(a): How about dropping this one in favor of avahi? Or am I missing something obvious? Well we can do it, but first i would love to see if somebody is interested. Dont you think? Tomas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages needing manitainer
On Sunday 08 March 2009 22:38:47 Tomáš Chvátal wrote: We (kde team) have some packages that we are not interested much/are so popular that we cant handle their bugload/releases/etc. So here they are: media-sound/amarok for both kde3 and kde4 version net-misc/mDNSResponder Is there around some brave soul that would became maintainer for this two (or at least one :P)? Regard Tomas Chvatal Gentoo KDE Herd Testers Lead What will happen to amarok if nobody maintains it ? In my opinion, amarok is a quite complicated package so It should not be assigned just to one developer. We ( as kde team ) can take care of amaroks' several bugs. For example, I can take care of [1] and somebody else can take care of another bug as well. Nobody else from kde team is interested on amarok? [1]: http://bugs.gentoo.org/show_bug.cgi?id=258861 -- Markos Chandras (hwoarang) Gentoo Linux Developer Qt/KDE/Sound/Sunrise signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 19:27 Sun 08 Mar , Tiziano Müller wrote:
Am Sonntag, den 08.03.2009, 10:01 -0700 schrieb Donnie Berkholz:
It would just eliminate all but one call to use_with(). Depending on how
many you've got, this can shorten things up a fair bit. Here's an
example:
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
The above could be rewritten to:
ECONF_USE_WITH='x X' 'foo libfoo' 'bar' 'python pygtk'
econf $(use_with ${ECONF_USE_WITH})
Why would I want to obfuscate my code like that by purposely making
people look in multiple places to figure out what it's doing? I don't
see how this is any improvement.
or an eclass could even export this:
src_configure() {
[ -n ${ECONF_USE_WITH} ] USE_WITH=$(use_with
\${ECONF_USE_WITH}\)
econf ${USE_WITH}
}
Guessing from what I see in the gnome/kde eclasses I think people will
implement the above then in eclasses and I therefore don't see why we
can't do it like that from the beginning...
If it can be implemented in an eclass, why would we want to do it as an
EAPI in a package manager? Eclasses can be easily changed, you only need
to write them once, and you don't have to deal with updating approving
a spec and new implementation for a bug in the previous implementation
(which you have to retain indefinitely).
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpEIwaNLiQmh.pgp
Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 15:16 -0700 schrieb Donnie Berkholz:
On 19:27 Sun 08 Mar , Tiziano Müller wrote:
Am Sonntag, den 08.03.2009, 10:01 -0700 schrieb Donnie Berkholz:
It would just eliminate all but one call to use_with(). Depending on how
many you've got, this can shorten things up a fair bit. Here's an
example:
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
The above could be rewritten to:
ECONF_USE_WITH='x X' 'foo libfoo' 'bar' 'python pygtk'
econf $(use_with ${ECONF_USE_WITH})
Why would I want to obfuscate my code like that by purposely making
people look in multiple places to figure out what it's doing? I don't
see how this is any improvement.
or an eclass could even export this:
src_configure() {
[ -n ${ECONF_USE_WITH} ] USE_WITH=$(use_with
\${ECONF_USE_WITH}\)
econf ${USE_WITH}
}
Guessing from what I see in the gnome/kde eclasses I think people will
implement the above then in eclasses and I therefore don't see why we
can't do it like that from the beginning...
If it can be implemented in an eclass, why would we want to do it as an
EAPI in a package manager? Eclasses can be easily changed, you only need
to write them once, and you don't have to deal with updating approving
a spec and new implementation for a bug in the previous implementation
(which you have to retain indefinitely).
Well, the point I'm trying to make here is a different one:
The syntax you proposed is more to write but still equivalent to the one
using vars.
And looking at the ebuilds - taking G2CONF as an example - it seems that
people don't have a problem with putting their config options into vars.
And furthermore with your syntax you still have to write out econf
$(use_with ...) explicitly while adding it the conf-vars to a var (as
proposed) makes the complete src_configure function obsolete, allows the
usage of the default src_configure/src_compile/src_install (see
http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml
for example) and is therefore even shorter to write.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Leverton wrote: On Sunday 08 March 2009 05:22:03 Donnie Berkholz wrote: FYI, using EXPORT_FUNCTIONS before inherit, as this patch caused x-modular.eclass to do, is broken in current portage releases. Zac said he would change this to be consistent with the lack of any ordering restriction in the PMS. Thanks to Tomáš Chvátal for tracking down this tricky bug! Better to ask for PMS to be clarified. All existing package managers do EXPORT_FUNCTIONS in more or less the same way, so changing it shouldn't happen without an EAPI bump. As discussed on irc, if we make it conditional on EAPI then you'll practically never be able to call EXPORT_FUNCTIONS before inherit since eclasses generally support multiple EAPIs. So, I've added a warning message that is triggered when EXPORT_FUNCTIONS is called before inherit. In a year or two we can consider having the warning removed. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkm0SPsACgkQ/ejvha5XGaN/+ACgsS44TWTR2fODGzwSI0XH5xN7 xpkAoOJhSWeXQDnhO8OuoXuViB2MNe7F =RJI6 -END PGP SIGNATURE-
[gentoo-dev] Re: LC_ALL=C Set by default for portage
On Sun, 8 Mar 2009 21:20:14 +0100 Tomáš Chvátal scarab...@gentoo.org wrote: Hi, lately i see that in our bugzilla most of the build reports are reported with localized build logs which we dont understand. This leads to us asking the user to run the emerge once more with LC_ALL=C. Wont it be nice to have this variable set by default in portage so users reporting bugs report in English? Since if everything goes fine they dont even bother about the warnings/errors and if something goes wrong it ends up on us to solve the mess :] The LC_ALL should be set for all relevant configure/compile/install phases at least. You do realize that many people don't speak any English, and therefore wouldn't be filing bugs anyways? They just want to use their computer. I'm not sure they will appreciate you forcing a language they don't speak on them any more than I would like to suddenly see all my build errors in Myanmar. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: LC_ALL=C Set by default for portage
On Sunday 08 of March 2009 23:50:08 Ryan Hill wrote: You do realize that many people don't speak any English, and therefore wouldn't be filing bugs anyways? They just want to use their computer. I'm not sure they will appreciate you forcing a language they don't speak on them any more than I would like to suddenly see all my build errors in Myanmar. Plz fix the bug [1] [1] - http://bugs.gentoo.org/show_bug.cgi?id=166730
[gentoo-dev] when the music's over
Hey everyone, It's my turn to say goodbye. It's been really nice for two years. I've had great fun and have no bad feelings as I leave. This mail is meant as an apology to people who are awaiting my return. I'm sorry to let you down. So when the fun^Wmusic's over, turn off gentoo^Wthe lights. Ah.. the reasons? there are no reasons, who needs reasons when you got exherbo? Goodbye all you people There's nothing you can say To make me change my mind Goodbye -- Regards, Ali Polatel
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-03-08 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-03-08 23h59 UTC. Removals: games-fps/anaglyph-stereo-quake 2009-03-02 01:37:10 mr_bones_ games-arcade/ppracer2009-03-06 22:44:11 mr_bones_ dev-perl/Text-Tabs+Wrap 2009-03-07 11:31:27 tove gnome-base/gnome-vfs-monikers 2009-03-08 20:50:20 eva Additions: app-misc/yagtd 2009-03-02 14:00:37 bangert dev-util/mock 2009-03-02 19:42:51 deathwing00 net-libs/gsoap 2009-03-03 06:35:29 patrick net-dialup/freeradius-client2009-03-03 21:01:56 mrness media-libs/freeverb32009-03-04 20:33:43 yngwin gpe-base/libsoundgen2009-03-06 17:50:52 solar gpe-base/libdisplaymigration2009-03-06 17:53:43 solar dev-util/cppcheck 2009-03-06 20:13:04 vapier sci-biology/plink 2009-03-07 04:37:27 weaver perl-core/Text-Tabs+Wrap2009-03-07 10:02:26 tove virtual/perl-Text-Tabs+Wrap 2009-03-07 10:14:52 tove app-text/tofrodos 2009-03-07 15:46:14 patrick dev-python/twisted-web2 2009-03-08 00:44:48 patrick net-misc/tigervnc 2009-03-08 15:34:44 armin76 dev-util/monodevelop-vala 2009-03-08 16:11:32 loki_val dev-util/monodevelop-debugger-gdb 2009-03-08 16:15:05 loki_val dev-util/monodevelop-debugger-mdb 2009-03-08 16:17:07 loki_val dev-util/gitg 2009-03-08 22:42:56 ikelos dev-python/python-gtkmvc2009-03-08 22:54:20 blackace -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: games-fps/anaglyph-stereo-quake,removed,mr_bones_,2009-03-02 01:37:10 games-arcade/ppracer,removed,mr_bones_,2009-03-06 22:44:11 dev-perl/Text-Tabs+Wrap,removed,tove,2009-03-07 11:31:27 gnome-base/gnome-vfs-monikers,removed,eva,2009-03-08 20:50:20 Added Packages: app-misc/yagtd,added,bangert,2009-03-02 14:00:37 dev-util/mock,added,deathwing00,2009-03-02 19:42:51 net-libs/gsoap,added,patrick,2009-03-03 06:35:29 net-dialup/freeradius-client,added,mrness,2009-03-03 21:01:56 media-libs/freeverb3,added,yngwin,2009-03-04 20:33:43 gpe-base/libsoundgen,added,solar,2009-03-06 17:50:52 gpe-base/libdisplaymigration,added,solar,2009-03-06 17:53:43 dev-util/cppcheck,added,vapier,2009-03-06 20:13:04 sci-biology/plink,added,weaver,2009-03-07 04:37:27 perl-core/Text-Tabs+Wrap,added,tove,2009-03-07 10:02:26 virtual/perl-Text-Tabs+Wrap,added,tove,2009-03-07 10:14:52 app-text/tofrodos,added,patrick,2009-03-07 15:46:14 dev-python/twisted-web2,added,patrick,2009-03-08 00:44:48 net-misc/tigervnc,added,armin76,2009-03-08 15:34:44 dev-util/monodevelop-vala,added,loki_val,2009-03-08 16:11:32 dev-util/monodevelop-debugger-gdb,added,loki_val,2009-03-08 16:15:05 dev-util/monodevelop-debugger-mdb,added,loki_val,2009-03-08 16:17:07 dev-util/gitg,added,ikelos,2009-03-08 22:42:56 dev-python/python-gtkmvc,added,blackace,2009-03-08 22:54:20 Done.
Re: [gentoo-dev] Re: LC_ALL=C Set by default for portage
Dawid Węgliński wrote: On Sunday 08 of March 2009 23:50:08 Ryan Hill wrote: You do realize that many people don't speak any English, and therefore wouldn't be filing bugs anyways? They just want to use their computer. I'm not sure they will appreciate you forcing a language they don't speak on them any more than I would like to suddenly see all my build errors in Myanmar. Plz fix the bug [1] [1] - http://bugs.gentoo.org/show_bug.cgi?id=166730 Possible solution: Don't set LC_ALL in general unless you're merging to get specific error messages. It's a known issue. Try searching for LC_ALL among CLOSED documentation bugs. Pops up a lot: [1] http://tinyurl.com/d3df5y (bug search list) [2] http://bugs.gentoo.org/show_bug.cgi?id=260477 [3] http://www.gentoo.org/doc/en/bugzilla-howto.xml [4] http://www.gentoo.org/doc/en/guide-localization.xml#doc_chap3 * * Note the big ol' WARNING before code listing 3.1. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] LC_ALL=C Set by default for portage
On Sunday 08 March 2009 16:20:14 Tomáš Chvátal wrote: lately i see that in our bugzilla most of the build reports are reported with localized build logs which we dont understand. This leads to us asking the user to run the emerge once more with LC_ALL=C. LC_ALL does a lot more than localization of messages. this topic has come up before on the list, so i'd search the archives for all the reasons why this is not the thing to do. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: LC_ALL=C Set by default for portage
On Sunday 08 March 2009 18:52:58 Dawid Węgliński wrote: On Sunday 08 of March 2009 23:50:08 Ryan Hill wrote: You do realize that many people don't speak any English, and therefore wouldn't be filing bugs anyways? They just want to use their computer. I'm not sure they will appreciate you forcing a language they don't speak on them any more than I would like to suddenly see all my build errors in Myanmar. Plz fix the bug [1] [1] - http://bugs.gentoo.org/show_bug.cgi?id=166730 it's not entirely clear this is a locale specific bug considering other people say they hit it with en_US.UTF8. that's the locale i use and ive never hit that problem. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] LC_ALL=C Set by default for portage
Dne pondělí 09 Březen 2009 01:35:07 Mike Frysinger napsal(a): On Sunday 08 March 2009 16:20:14 Tomáš Chvátal wrote: lately i see that in our bugzilla most of the build reports are reported with localized build logs which we dont understand. This leads to us asking the user to run the emerge once more with LC_ALL=C. LC_ALL does a lot more than localization of messages. this topic has come up before on the list, so i'd search the archives for all the reasons why this is not the thing to do. -mike Well if complete LC_ALL is not option so how about reseting at least LC_MESSAGES... signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] LC_ALL=C Set by default for portage
On Sunday 08 March 2009 20:38:01 Tomáš Chvátal wrote: Dne pondělí 09 Březen 2009 01:35:07 Mike Frysinger napsal(a): On Sunday 08 March 2009 16:20:14 Tomáš Chvátal wrote: lately i see that in our bugzilla most of the build reports are reported with localized build logs which we dont understand. This leads to us asking the user to run the emerge once more with LC_ALL=C. LC_ALL does a lot more than localization of messages. this topic has come up before on the list, so i'd search the archives for all the reasons why this is not the thing to do. Well if complete LC_ALL is not option so how about reseting at least LC_MESSAGES... that would be a lot safer, but i still dont agree it should be done. document the process in the bugzilla howto and call it a day. see #198077 and #260477. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: LC_ALL=C Set by default for portage
On Monday 09 of March 2009 01:36:52 Mike Frysinger wrote: Plz fix the bug [1] [1] - http://bugs.gentoo.org/show_bug.cgi?id=166730 In my opinion it's nowhere near locale specific bug, unless user sets PORTAGE_TMPDIR to some path containing UTF-8 character beyond ASCII and having broken locales in system. The problem is mainly that such build logs are barely helpful when localized in some funny way. it's not entirely clear this is a locale specific bug considering other people say they hit it with en_US.UTF8. that's the locale i use and ive never hit that problem. Agreed. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, Mar 08, 2009 at 09:42:29AM -0700, Donnie Berkholz wrote: On 08:49 Sun 08 Mar , Tiziano M?ller wrote: So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I strongly oppose this implementation because it makes ebuilds less like bash scripts that are easy to understand. Instead I suggest extending use_with() and use_enable() to accept multiple sets of arguments (alternately, making custom, similar functions that will take multiple args). Combined with the addition of src_configure() in EAPI=2, the amount of code could be a large reduction from existing versions without raising the barrier to entry. While I understand your concerns about the SRC_CONFIGURE stuff, there are two points I'd like to make; 1) The barrier to entry is negligible. How much more difficult is it for someone to learn what CONFIGURE_ENABLES=( 'foo foobar' ) ? I didn't find it difficult at all(and I've used them). 2) src_configure is just one part; src_compile has uses as does src_install. In fact, if you want to do patches, src_prepare would be in there too. What I'm saying is that focusing on the one part(configure) is ignoring the good part of the rest of the proposal. Regards, Thomas -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council - pgp4mn7bM5lm2.pgp Description: PGP signature
Re: [gentoo-dev] Re: perl-module.eclass -- review - 2
On 14:09 Tue 03 Mar , Bo Ørsted Andresen wrote: On Tuesday 03 March 2009 12:13:34 Peter Volkov wrote: Could you just use dosed here? dosed needs to die. Why? Because it's utterly pointless and exists only for legacy reasons. Few packages use it anyway. I did a quick check to look at the data supporting your point and found 120 packages using it. I guess that qualifies as few when compared to the whole tree. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgp17EdQMQtWH.pgp Description: PGP signature
Re: [gentoo-dev] LC_ALL=C Set by default for portage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harald van Dijk yazmış: On Sun, Mar 08, 2009 at 09:27:20PM +0100, Alexis Ballier wrote: Moreover this would automagically solve the [a-z] friends regexp failures; though that's still good QA to fix them but we wouldn't encounter them anymore. We would encounter them when using the programs outside of portage, but not when running the testsuite (if available) from within portage. It would succeed in working around compile-time only bugs, but it would be a major pain for locale bugs that can also cause problems at run time. I agree. There are quite a number of bugs, either compile time or runtime, that can be spotted and reported to upstream (and hope that they get fixed) in Turkish locale and I posted on my dev blog why[1] this happens. I choose to translate the messages after the build.log if I reproduce the bug only in Turkish locale. If our bug reporting guide is not guiding people (yeah people don't read docs and especially ones that are longer than a paragraph and in a language that they can't read) portage could say a few words on sending the bug report in English if it spots another locale with the exception of the bug being a locale specific issue. 1: http://blogs.gentoo.org/serkan/2008/11/16/applications_failing_with_turkish_locale - -- Sincerely, Serkan KABA Gentoo Developer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm0kPgACgkQRh6X64ivZaKsKgCfYPtokmwM6G1jyBM1tbBZOrc5 RVwAnAwkHu+nIN4Khtj0lZYgSRnjKiMC =9n5G -END PGP SIGNATURE-
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 23:35 Sun 08 Mar , Tiziano Müller wrote: Well, the point I'm trying to make here is a different one: The syntax you proposed is more to write but still equivalent to the one using vars. And looking at the ebuilds - taking G2CONF as an example - it seems that people don't have a problem with putting their config options into vars. And furthermore with your syntax you still have to write out econf $(use_with ...) explicitly while adding it the conf-vars to a var (as proposed) makes the complete src_configure function obsolete, allows the usage of the default src_configure/src_compile/src_install (see http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml for example) and is therefore even shorter to write. I think the idea of ebuilds as scripts showing directly how to build software is a core part of the Gentoo build-system philosophy. This proposal pushes ebuilds toward a formatted file that is not a script. Instead, it is more like an Ant XML file that more abstractly describes a build. I think this is the wrong direction for ebuilds because they should directly resemble how software is built by hand. One of the key reasons people use Gentoo is that ebuilds are so easy to get for anyone who has ever built software by hand. I will continue to vehemently defend anything that I think retains this key advantage of Gentoo over other distributions. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpN1K1VVp0pJ.pgp Description: PGP signature
Re: [gentoo-dev] when the music's over
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ali Polatel yazmış: Hey everyone, It's my turn to say goodbye. It's been really nice for two years. I've had great fun and have no bad feelings as I leave. This mail is meant as an apology to people who are awaiting my return. I'm sorry to let you down. So when the fun^Wmusic's over, turn off gentoo^Wthe lights. Ah.. the reasons? there are no reasons, who needs reasons when you got exherbo? Goodbye all you people There's nothing you can say To make me change my mind Goodbye It's sad to hear you going. It was a privilege to work with you fellow. I wish you good luck and success with rest of the life and Exherbo. - -- Sincerely, Serkan KABA Gentoo Developer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm0mX0ACgkQRh6X64ivZaIwpwCeNtgguX2WbtpBqornpCfMXK5C 1lwAnjWom/lobhgT/Eg/Z5QC5358O5nZ =BLeo -END PGP SIGNATURE-
Re: [gentoo-portage-dev] What is a meta package?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Amit Dor-Shifer wrote:
Hi.
i read in
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=3
QUOTE
Never depend on a meta-package.
So don't depend on gnome-base/gnome, always depend on the specific
libraries like libgnome.
UNQUOTE
Where can I find a definition of this term?
Is there some equery/qsearch invocation that returns a list of such
packages (installed or available)?
Is there some ebuild setting that marks a package as being a meta
package? Does gnome-base/gnome carry this setting?
Thanks,
Amit
Hi Amit,
a meta-package is a package that depends on a group of other packages but
doesn't contain any source of itself. Basically it's a shorthand for the entire
group for installing from command line.
Portage is getting explicit support for groups so I think we then no longer need
metapackages.
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmzy5IACgkQp/VmCx0OL2y1cwCeKLo/u6u6cNhimb6zFXPgW4FO
zJwAn0UvF6OzakSuJmYH4P+Cxb75FOF4
=R05+
-END PGP SIGNATURE-
