Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
On Wed, 2007-10-10 at 20:03 -0700, Alec Warner wrote: > > B. don't use GNU extensions in pkg_functions and have some way to export > > them (extract pkg_* functions from environment.bz2). Those can then be > > used by pre/post script in binary package manager. > > This is your best bet, but again mandates are ineffective. As you've > no doubt noticed with quoting, people will do whatever works and the > people who aim for odd targets like no GNU crap or sh compatability > are going to have to do the code reviews and encourage that sort of > thing. Just saying 'pre/post functions must be POSIX compatable' will > get you nowhere. The point here is to sell your idea to other > developers; if you can't sell it you may need to take it elsewhere. This is what I'm preaching, but for the whole ebuild not just the pre/post functions. It's a tough crowd as everyone's a zealot with their own favourite "must have" tools + the territorial crap which rears it's ugly head from time to time. Thanks Roy -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Upcoming masking of dev-lang/php-4* and packages depending on it
Marius Mauch <[EMAIL PROTECTED]>: > On Sun, 7 Oct 2007 15:13:49 +0200 > Christian Hoffmann <[EMAIL PROTECTED]> wrote: > > I'm going to p.mask =dev-lang/php-4* and all packages explicitly > > depending on this version of php (i.e. the whole dev-php4/ category > > (36 packages) and one webapp, www-apps/knowledgetree, bug 194894 > > [1]) next weekend (around Oct 14th). This step is necessary as > > there is hardly any upstream activity anymore. > You should probably post that in a more user-oriented channel, like > gentoo-announce and/or the forums to reduce the number of "surprised" > users [1] Or even write a short summary for the GWN...they would be happy about it. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Upcoming masking of dev-lang/php-4* and packages depending on it
Christian Hoffmann wrote: > Heya, > > I'm going to p.mask =dev-lang/php-4* and all packages explicitly > depending on this version of php (i.e. the whole dev-php4/ category > (36 packages) and one webapp, www-apps/knowledgetree, bug 194894 [1]) > next weekend (around Oct 14th). This step is necessary as there is > hardly any upstream activity anymore. > > The last official version of php-4, 4.4.7, dates back to May 3rd and is > in the same state as php-5.2.2 security-wise (and we all know how many > issues php-5 had in the past, just have a look at the recently published > GLSA 200710-02 [2]). > > All those security problems, which were fixed in the 5.2 branch, > possibly apply to the 4.4 branch as well, yet there are no (backported) > fixes in upstream CVS and there is no sign of an upcoming release > either. > This means, if we were to continue php-4 support we would have to do > the upstream work and compile a list of issues + patches. Upstream > developers seem to see it the same way -- "if you really want to get it > done - do it" was one reply when I asked what's up with php-4. Noone > from our PHP team has the time and motiviation to do that work, and as > such we are going to mask it (unless someone volunteers to do the work > and/or upstream becomes active again). > > We will still keep php-4 (and all related packages) in the tree until at > least the end of the year (this is the date where official upstream > "support" ends) and bump it if (and not "when"...) there are any > releases. > > We advise all users of of php-4 to upgrade to php-5 as soon as possible. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=194894 > [2] http://www.gentoo.org/security/en/glsa/glsa-200710-02.xml Since you're doing the masking, can you please help out the GDP by reviewing a few of our documents for any potential changes that must be made? Grepping for "php4" shows that there are references in the following docs: 1. http://www.gentoo.org/doc/en/jffnms.xml 2. http://www.gentoo.org/doc/en/apache-troubleshooting.xml 3. http://www.gentoo.org/doc/en/qmail-howto.xml 4. http://www.gentoo.org/doc/en/handbook/hb-working-rcscripts.xml Thanks, Josh signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Upcoming masking of dev-lang/php-4* and packages depending on it
On Sun, 7 Oct 2007 15:13:49 +0200 Christian Hoffmann <[EMAIL PROTECTED]> wrote: > Heya, > > I'm going to p.mask =dev-lang/php-4* and all packages explicitly > depending on this version of php (i.e. the whole dev-php4/ category > (36 packages) and one webapp, www-apps/knowledgetree, bug 194894 [1]) > next weekend (around Oct 14th). This step is necessary as there is > hardly any upstream activity anymore. You should probably post that in a more user-oriented channel, like gentoo-announce and/or the forums to reduce the number of "surprised" users [1] Marius [1] http://forums.gentoo.org/viewtopic-t-597017.html -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
On 10/8/07, Natanael Copa <[EMAIL PROTECTED]> wrote: > On Mon, 2007-10-08 at 06:52 -0700, Alec Warner wrote: > > On 10/8/07, Natanael Copa <[EMAIL PROTECTED]> wrote: > > > On Sun, 2007-10-07 at 21:26 -0600, Joe Peterson wrote: > > > > Mike Frysinger wrote: > > > > > Fabian has summed it up nicely, thanks. i could care less what your > > > > > userland > > > > > is outside of the ebuild environment since it doesnt matter to ebuild > > > > > writers. you want a deficient runtime environment, more power to > > > > > you, but > > > > > forcing that environment onto ebuild developers is not acceptable. > > > > > off the > > > > > top of my head, i'd like to see GNU find/xargs added to the ebuild > > > > > environment. > > > > > -mike > > > > > > > > Mike, exactly as I said. That's option #2, and I think it could be a > > > > great solution. As for deficient, well, that's in the eye of the > > > > beholder. ;) > > > > > > > > -Joe > > > > > > Question, if you go for #2. Does that mean you will need all the > > > required GNU userland to do binary only installs? > > > > > > It would be highly desireable to be able to do binary installs (write > > > your own binary only package manager) without depending on all the GNU > > > stuff needed to compile the packages. > > > > Your own binary only package manager would still need to provide > > Option #2; ie you need to have GNU tools installed to process the > > binary packages. pkg_* functions could still have GNU stuff in them > > and those still get run during a binary package install. > > If we would like to be able to do binary installs without the GNU tools, > what alternatives do we have? > > Those pops up to my mind: > > A. move the pkg_* functions out of the ebuild to a separate file. Those > have a subset of the EAPI and needs to be posix compliant. This is just rife with complications, IMHO. Two files per ebuild revision? Shared pre/post functions? Extra manifests, stats, sourcing, bigger tree, inode requirements. Probably not an easy sell here. > > B. don't use GNU extensions in pkg_functions and have some way to export > them (extract pkg_* functions from environment.bz2). Those can then be > used by pre/post script in binary package manager. This is your best bet, but again mandates are ineffective. As you've no doubt noticed with quoting, people will do whatever works and the people who aim for odd targets like no GNU crap or sh compatability are going to have to do the code reviews and encourage that sort of thing. Just saying 'pre/post functions must be POSIX compatable' will get you nowhere. The point here is to sell your idea to other developers; if you can't sell it you may need to take it elsewhere. > > C. Binary package managers will need to write their own pre/post > scripts Good luck with this route; you may be able to write replacements for most utilities but I bet the conversion would still fail on weird constructs. D. Keep your own ebuilds. Particularly for embedded you probably aren't using a ton of them anyway and given a sufficient pool of developers interested in POSIX compatible ebuilds you could probably hammer out a posix-compliant embedded tree in short order. I know everyone hates option D; but I'm also kind of irritated by everyone trying to push weird requirements on everyone else. If you can't convince the majority of developers to do thing X, you may end up having to do it yourself; welcome to open source software ;) -Alec -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/pygtksourceview: metadata.xml pygtksourceview-2.0.0.ebuild Manifest ChangeLog
Donnie Berkholz wrote: > I think the python_mod_ functions take care of running python_version() > ... also have you noticed that you're optimizing in postrm instead of > cleaning up? I just copied the ebuild from our overlay to portage. I think this ebuild is quite similar to other gnome/python packages. Since I've never really made anything related to python, I'll have to take your word for it :) Thanks for your review, I'll open a bug so that we can really clean up our gnome/python ebuilds. Rémi -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/pygtksourceview: metadata.xml pygtksourceview-2.0.0.ebuild Manifest ChangeLog
On 21:22 Wed 10 Oct , Remi Cardona (remi) wrote:
> 1.1 dev-python/pygtksourceview/pygtksourceview-2.0.0.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/pygtksourceview/pygtksourceview-2.0.0.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/pygtksourceview/pygtksourceview-2.0.0.ebuild?rev=1.1&content-type=text/plain
> pkg_postinst() {
> python_version
> python_mod_optimize /usr/$(get_libdir)/python${PYVER}/site-packages/
> }
>
> pkg_postrm() {
> python_version
> python_mod_optimize /usr/$(get_libdir)/python${PYVER}/site-packages/
> }
I think the python_mod_ functions take care of running python_version()
... also have you noticed that you're optimizing in postrm instead of
cleaning up?
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: app-misc/gfontview
Hi, app-misc/gfontview depends on the phasing out gtk+-1.2 and has an open issue and is unmaintained upstream: Bug 189775 app-misc/gfontview-0.5.0-r6 segfaults on startup # Stefan Schweizer <[EMAIL PROTECTED]> (10 Oct 2007) # removal because of starting problems in Bug 189775, gtk+-1.2 usage # last release was in 2001, possible replacement: media-gfx/opcion app-misc/gfontview Best regards, Stefan Schweizer -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Denis Dupeyron wrote: > On 10/10/07, Zac Medico <[EMAIL PROTECTED]> wrote: >> Eventually I'd like to add an option that >> behaves similar to --resume but also recalculates dependencies. > > Why not make that the default ? That would be safer IMO. I agree. At a minimum, it should bail out if the previously calculated dependencies are no longer met. The only sanity check that it currently does it to verify that the packages are still available to be merged. > Plus, once we have this, it looks to me that nobody has to wait for > EAPI=1 in order to use whatever portage feature that's needed by an > ebuild. So we can all stop complaining about not having EAPI=1 in the > form we wanted or at all, and get back to writing ebuilds. For metadata syntax changes, such as IUSE defaults, a simple portage dependency won't work. In that case EAPI is needed in order to prevent older versions of portage from interpreting new ebuilds in ways that are not intended (leading to unpredictable results). Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHDSiW/ejvha5XGaMRArQeAKC9T90xrAq2SurgCM1qQ/DhbgjBMwCguXzH HLiySuH3xV7lh70dVjsF7Tk= =pmbn -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] lame use flag, local to global
On Wed, 2007-10-10 at 07:55 -0600, Steve Dibb wrote: > Mart Raudsepp wrote: > > On T, 2007-10-09 at 21:03 -0600, Steve Dibb wrote: > >> The little lame use flag has started showing up more in local use flags, > >> and all for the same purpose, MP3 support using LAME libraries. I vote > >> we move it into a global use flag. Any objections, let me know. > >> > >> $ quse -D lame > >> local:lame:media-libs/libquicktime: Support LAME mp3 encoding > >> local:lame:media-libs/mlt: Support LAME mp3 encoding > >> local:lame:media-sound/abcde: Support LAME mp3 encoding > >> local:lame:media-sound/gnusound: Enable lame support > >> local:lame:media-video/mpeg4ip: Support LAME mp3 encoding in the > >> server/mp4live > > > > Any reason to not use something like mp3enc flag instead at that point? > > mp3 USE flag is already global, and appears to mean mp3 decoding, so how > > about a general mp3 encoding USE flag? I guess merging decoding and > > encoding behind the same USE flag might be an option too. > > > > Ah, I knew this question was gonna come up, should have addresed it > first time around. > > The reason we have mp3 and lame use flag is because there is more than > one mp3 encoder. In almost every case of the use flag being applied > above, there is already support for another mp3 codec (ffmpeg). So, > lame adds support for lame, not for mp3, which is also provided. > > When there is just one mp3 codec used in an ebuild, then it makes sense > to use just the mp3 use flag. Actually, the encode USE flag makes more sense, if encoding support is optional. Basically, it should be like so: A is a mp3 program/library, which can do both encoding and decoding. It doesn't use USE=mp3, at all, since it is solely an mp3 program. Encoding support is enabled via USE=encode. B is a media program/library, which can do both encoding and decoding for multiple formats. It would use USE=mp3 to enable mp3 support. It would use USE=encode (with mp3 support enabled) to enable mp3 encoding support. C is an encoder for multiple formats. It uses USE=mp3 for enabling mp3 encoding. D is an encoder for mp3. It uses no USE flags, since it is always a mp3 encoder. I'm sure I missed other cases, but you get the point. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use
On 10/10/07, Zac Medico <[EMAIL PROTECTED]> wrote: > Eventually I'd like to add an option that > behaves similar to --resume but also recalculates dependencies. Why not make that the default ? That would be safer IMO. Plus, once we have this, it looks to me that nobody has to wait for EAPI=1 in order to use whatever portage feature that's needed by an ebuild. So we can all stop complaining about not having EAPI=1 in the form we wanted or at all, and get back to writing ebuilds. Denis. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gnatbuild.eclass
On 18:17 Wed 10 Oct , George Shapovalov (george) wrote: > george 07/10/10 18:17:58 > > Modified: gnatbuild.eclass > > Log: fixed src_install issue, no longer relies on portage leaking > env vars between functions It's really sad that you have to add this workaround. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: > On Wed, 10 Oct 2007 10:16:03 +0200 > "Denis Dupeyron" <[EMAIL PROTECTED]> wrote: > >> On 10/10/07, Zac Medico <[EMAIL PROTECTED]> wrote: >>> I think it's OK to start using package.use now considering that >>> package.use has been supported since portage-2.1.2 and that's been >>> stable since February. There are already a couple of packages using >>> it in the tree now. >> Is it a good idea for those ebuilds that require new features to have >> a >= dependency on a specific version of portage ? Or not ? > > No, as it wouldn't help anyway: the depgraph is calculated before > portage would be updated (so package.use/IUSE defaults wouldn't be > used). Results may vary if the user doesn't manually upgrade portage before doing other upgrades. After portage upgrades itself it will exec emerge --resume if there are remaining packages in the merge list. Like you said, the new version of portage will not recalculate dependencies when it resumes, but it will recalculate USE flags (bugs #183683). It's inconsistent, which is one reason why the recommended practice is to upgrade portage alone before attempting to do additional updates. Eventually I'd like to add an option that behaves similar to --resume but also recalculates dependencies. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHDQwB/ejvha5XGaMRAr2FAJ9E0OtHnzKO+fYRahsqR6W13AYzvwCggIIi BqHtFv3zbFKoYj5bR7heK9k= =SaBU -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: app-editors/pico
Hi, # Christian Faulhammer <[EMAIL PROTECTED]> (10 Oct 2007) # masked for removal, just useless because # it does not install anything, see bug 3464 app-editors/pico -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: lame use flag, local to global
Steve Dibb <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 10 Oct 2007 07:55:01 -0600: > The reason we have mp3 and lame use flag is because there is more than > one mp3 encoder. In almost every case of the use flag being applied > above, there is already support for another mp3 codec (ffmpeg). So, > lame adds support for lame, not for mp3, which is also provided. In that case, shouldn't the description mention that? Something like: MP3 encoding support using LAME (as opposed to ffmpeg) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] integrating solaris overlay into main portage
Hi Christian, On 10-10-2007 17:31:17 +0200, Christian Parpart wrote: ... > However, knowing that portage for Solaris (10) is only available via a prefix > is not the problem, but knowing that for solaris you have to use a completely > different portage tree which is just lagging behind is a real pain. Which/what tree are you using? > i'm not that familiar with this prefixed development as the maintainers > itself, but i don't think it's a big deal to tag those ebuilds with > solaris-x86 (for example) that are $EPREFIX aware, isn't it? Which system are you using? I know of three such systems, that's why I'm asking. -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
[gentoo-dev] integrating solaris overlay into main portage
Hi all, i always feared in asking this because of some typical flamewars, however. I am now in a company which is actively using Solaris 10 and Gentoo. We're deploying some house-written software onto both using the portage system (!). However, knowing that portage for Solaris (10) is only available via a prefix is not the problem, but knowing that for solaris you have to use a completely different portage tree which is just lagging behind is a real pain. i'm not that familiar with this prefixed development as the maintainers itself, but i don't think it's a big deal to tag those ebuilds with solaris-x86 (for example) that are $EPREFIX aware, isn't it? The benifit: we have so many ebuilds in the tree that just need keywording and/or a simple $EPREFIX addition. This shouldn't hurt any primary package maintainer in finding any of these in their ebuilds, in fact, i'd be happy to know there's yet another package that can be installed using gentoo's portage on yet another architecture. How do you feel with that idea? Regards, Christian Parpart. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: www-client/planet
Dawid Węgliński wrote: Dnia 09-10-2007, wto o godzinie 20:56 -0600, Steve Dibb napisał(a): # Steve Dibb <[EMAIL PROTECTED]> (11 Aug 2007) # Old, unmaintained, pending removal www-client/planet punted Anything to use instead? Well, anyone can ressurect the ebuild if they want. Besides, the old ebuild was a snapshot of Aug. of 2004. Not really too helpful considering it's still in development. Steve -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] lame use flag, local to global
Mart Raudsepp wrote: On T, 2007-10-09 at 21:03 -0600, Steve Dibb wrote: The little lame use flag has started showing up more in local use flags, and all for the same purpose, MP3 support using LAME libraries. I vote we move it into a global use flag. Any objections, let me know. $ quse -D lame local:lame:media-libs/libquicktime: Support LAME mp3 encoding local:lame:media-libs/mlt: Support LAME mp3 encoding local:lame:media-sound/abcde: Support LAME mp3 encoding local:lame:media-sound/gnusound: Enable lame support local:lame:media-video/mpeg4ip: Support LAME mp3 encoding in the server/mp4live Any reason to not use something like mp3enc flag instead at that point? mp3 USE flag is already global, and appears to mean mp3 decoding, so how about a general mp3 encoding USE flag? I guess merging decoding and encoding behind the same USE flag might be an option too. Ah, I knew this question was gonna come up, should have addresed it first time around. The reason we have mp3 and lame use flag is because there is more than one mp3 encoder. In almost every case of the use flag being applied above, there is already support for another mp3 codec (ffmpeg). So, lame adds support for lame, not for mp3, which is also provided. When there is just one mp3 codec used in an ebuild, then it makes sense to use just the mp3 use flag. Steve -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] lame use flag, local to global
George Shapovalov kirjoitti: > Wednesday, 10. October 2007, Steve Dibb Ви написали: >> The little lame use flag has started showing up more in local use flags, >> and all for the same purpose, MP3 support using LAME libraries. I vote >> we move it into a global use flag. Any objections, let me know. > Are these cases lame specific or would majority (all?) of them be satisfied > with the "mp3 encoding" notion? That is, would it make sense for these > packages to use a more general flag instead? Now, mp3 stands for "Add support > for reading mp3 files", but, perhaps, it would be usefull to extend it to > cover decoding and encoding? (or, alternatively, introduce some global mp3enc > flag?) > > George At least in my own desktop use I don't use mp3 encoding but do need decoding so it makes sense to keep them separate. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: new-style virtual/editor
Christian Faulhammer <[EMAIL PROTECTED]>: > about 26 ebuilds have a PROVIDE=virtual/editor. Those could be > transformed to a new-style virtual, which is really simple. According > to zmedico and genone the impact of just commiting the virtual would > be low. But I'd like to hear some comments on it. If noone objects I > will commit it next week (Monday probably) and remove all PROVIDE > lines. Eventually I will check profiles, too, and file bugs when > unsure what the intended behaviour? Or anyone objections about me > touching his profiles. New-style virtual in the tree with nearly 30 packages in RDEPEND...:)...we added some that were not providing it until now. Profiles fixed (except selinux/2005.1/mips) and ebuilds cleaned-up. Thanks to ulm for the help. So if you have a text-mode editor not in there, just add it to the virtual or file a bug. I put emacs, xemacs, vim teams and base-system into metadata.xml as maintainers. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Modular texlive eclasses up for review
On Tue, 09 Oct 2007 14:49:05 +0200
Francesco Riosa <[EMAIL PROTECTED]> wrote:
> Roy Marples ha scritto:
> > On Tue, 2007-10-09 at 13:17 +0200, Alexis Ballier wrote:
> >
> >>> if [ "${f/config/}" != "${f}" ]
> >>> Should be
> >>> if [ "${f#*config*}" != "${f}" ]
> >>>
> Should be
>
> if [ "${f#*config}" != "${f}" ]
>
> the 2nd asterisk is not needed, symmetry apart
>
just removed it
Alexis.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/vlc: ChangeLog vlc-0.9.0_alpha20071009.ebuild
On Tue, 9 Oct 2007 16:28:23 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > if use nsplugin; then > > if use seamonkey; then > > XPIDL=/usr/lib/seamonkey > > MOZILLA_CONFIG=/usr/lib/seamonkey/seamonkey-config > > else > > XPIDL=/usr/lib/mozilla-firefox > > MOZILLA_CONFIG=/usr/lib/mozilla-firefox/firefox-config > > fi > > fi > > Should this be get_libdir() ? should be more reliable indeed it's used only to teach the build system where to find mozilla's stuff, so as of now it shouldnt hurt, but I switched to get_libdir anyway. > > > > econf \ > > $(use_enable altivec) \ > > $(use_enable stream sout) \ > > $(use_enable httpd) \ > > $(use_enable gnutls) \ > > $(use_enable v4l) \ > > $(use_enable v4l2) \ > > $(use_enable cdda) $(use_enable cdda cddax)\ > > $(use_enable cddb libcddb) \ > > [crop another 30 or so] > > Another place where ordering would help. good idea, thanks; it's a bit difficult to read as of now :/ Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: www-client/planet
Dnia 09-10-2007, wto o godzinie 20:56 -0600, Steve Dibb napisał(a): > # Steve Dibb <[EMAIL PROTECTED]> (11 Aug 2007) > # Old, unmaintained, pending removal > www-client/planet > > punted Anything to use instead? Cheers -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use
On Wed, 10 Oct 2007 10:16:03 +0200 "Denis Dupeyron" <[EMAIL PROTECTED]> wrote: > On 10/10/07, Zac Medico <[EMAIL PROTECTED]> wrote: > > I think it's OK to start using package.use now considering that > > package.use has been supported since portage-2.1.2 and that's been > > stable since February. There are already a couple of packages using > > it in the tree now. > > Is it a good idea for those ebuilds that require new features to have > a >= dependency on a specific version of portage ? Or not ? No, as it wouldn't help anyway: the depgraph is calculated before portage would be updated (so package.use/IUSE defaults wouldn't be used). See http://dev.gentoo.org/~genone/docs/treedeps.txt for some information on this kind of issues (while the text wasn't written with this issue in mind it still applies to it). Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Denis Dupeyron wrote: > On 10/10/07, Zac Medico <[EMAIL PROTECTED]> wrote: >> I think it's OK to start using package.use now considering that >> package.use has been supported since portage-2.1.2 and that's been >> stable since February. There are already a couple of packages using >> it in the tree now. > > Is it a good idea for those ebuilds that require new features to have > a >= dependency on a specific version of portage ? Or not ? Can this > help when switching EAPIs ? Or plug the gap while the decision to > switch to EAPI=1 is being taken ? Does /me need more coffee or a good > clue-batting session ? > > Denis. Adding a dependency on >=sys-apps/portage-2.1.2 is a reasonable idea since that does ensure that the package.use is properly accounted for. Since EAPI only governs ebuilds and not profiles, you'd have to use IUSE defaults to get a similar effect while taking advantage of EAPI. The problem with EAPI-1 at the moment is that it's only supported by an unstable version of portage, which means that repoman users with stable portage will be unable to work with any ebuilds that have EAPI=1 defined. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHDJNZ/ejvha5XGaMRAv0BAJwIxec1FPMJQYjSJeolEyVC4njgfQCeMKb+ 8YgKitdWk8difKGR4nJkYuo= =51KN -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Gentoo Arch Testing Tool
Hi, all arch devs interested in above tool (app-portage/gatt-svn), I wrote a little introduction for it. See Planet. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use
On 10/10/07, Zac Medico <[EMAIL PROTECTED]> wrote: > I think it's OK to start using package.use now considering that > package.use has been supported since portage-2.1.2 and that's been > stable since February. There are already a couple of packages using > it in the tree now. Is it a good idea for those ebuilds that require new features to have a >= dependency on a specific version of portage ? Or not ? Can this help when switching EAPIs ? Or plug the gap while the decision to switch to EAPI=1 is being taken ? Does /me need more coffee or a good clue-batting session ? Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] lame use flag, local to global
Wednesday, 10. October 2007, Steve Dibb Ви написали: > The little lame use flag has started showing up more in local use flags, > and all for the same purpose, MP3 support using LAME libraries. I vote > we move it into a global use flag. Any objections, let me know. Are these cases lame specific or would majority (all?) of them be satisfied with the "mp3 encoding" notion? That is, would it make sense for these packages to use a more general flag instead? Now, mp3 stands for "Add support for reading mp3 files", but, perhaps, it would be usefull to extend it to cover decoding and encoding? (or, alternatively, introduce some global mp3enc flag?) George -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] lame use flag, local to global
On T, 2007-10-09 at 21:03 -0600, Steve Dibb wrote: > The little lame use flag has started showing up more in local use flags, > and all for the same purpose, MP3 support using LAME libraries. I vote > we move it into a global use flag. Any objections, let me know. > > $ quse -D lame > local:lame:media-libs/libquicktime: Support LAME mp3 encoding > local:lame:media-libs/mlt: Support LAME mp3 encoding > local:lame:media-sound/abcde: Support LAME mp3 encoding > local:lame:media-sound/gnusound: Enable lame support > local:lame:media-video/mpeg4ip: Support LAME mp3 encoding in the > server/mp4live Any reason to not use something like mp3enc flag instead at that point? mp3 USE flag is already global, and appears to mean mp3 decoding, so how about a general mp3 encoding USE flag? I guess merging decoding and encoding behind the same USE flag might be an option too. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] One-Day Gentoo Council Reminder for October
This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ -- [EMAIL PROTECTED] mailing list
