Re: [gentoo-dev] Modular texlive eclasses up for review
On Tue, 2007-10-09 at 01:03 +0200, Alexis Ballier wrote:
> On Mon, 8 Oct 2007 23:47:31 +0200
> Alexis Ballier <[EMAIL PROTECTED]> wrote:
>
> > Hi list,
>
>
> Try 2, after dberkholz comments on irc:
> - replaced test by []
> - removed useless use of cat
>
>
> Alexis.
grep '^!' "${i}" | tr ' ' '=' |sort|uniq >> "${T}/jobs"
Could be done with a 1 sed and 1 sort call, but whatever floats your
boat.
case ${command} in
Should quote command here
if [ "${f/config/}" != "${f}" ]
Should be
if [ "${f#*config*}" != "${f}" ]
return $([ -f "${mark}" ])
Could be written as
[ -f "${mark}" ]
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: GNU userland and binary package (WAS: RFC: sh versionator.eclass)
On Mon, 2007-10-08 at 20:25 +0100, Steve Long wrote: > Natanael Copa wrote: > If you're that motivated why not just start hacking on binary support in > portage/pkgcore/paludis? There's always open bugs. I think I did contribute with some patches for qmerge in portage-utils. Unfortunally, its pretty difficult to make a lightweight C (language) only binary installer without having at least the eclasses and GNU tools. It kind of defeat the idea of having a lightweight binary only runtime environment. (lightweight means busybox - which give you most of the basic GNU tools, linux-utils, wget, shell, http server and much more for the size of bash only) > >> 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? > > > > > > Any other alternatives? > > > > Comments? > > > I'd just specify BASH (as I don't see the point in making the distinction as > it only applies to build machines) and coreutils/findutils etc. To properly install a prebuilt binary packages you need the pkg_* funcs in the ebuild. > Asking everyone to switch coding style for certain functions, just to > support the stuff that Gentoo was designed to do from the beginning, seems > counter-productive. We already do different for init.d scripts (which is great!) , but sure, I get the point. > For every market except embedded, which we've discussed > already, BASH is not a major issue: nor are the other tools mentioned. I happen to do embedded. > > > > Alternative C is what I do today. > > > Sounds rough :) Thats why I'm interested in alternatives. > (I really would recommend #pkgcore as well as there is several years of work > to do with binpkgs in that.) So far no packagemanager using the portage stuff (eclasses) are not even close to compete in size for binary only installs. Closest is portage-utils's qmerge but it would need atleast the eclasses and bash which would atleast double the size in comparison what I do today. Looks like i will need to continue do my own stuff. Thanks for you time! > Standardising on a certain subset of base GNU tools seems like a good idea > to me too. -nc -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-base/xorg-x11: xorg-x11-7.2.ebuild xorg-x11-7.3.ebuild ChangeLog
В Втр, 09/10/2007 в 07:43 +, Donnie Berkholz (dberkholz) пишет:
> dberkholz07/10/09 07:43:50
>
> Modified: xorg-x11-7.2.ebuild xorg-x11-7.3.ebuild ChangeLog
> Log:
> Fix quoting issues caught by latest repoman.
>
> Revision ChangesPath
> 1.14 x11-base/xorg-x11/xorg-x11-7.2.ebuild
> XORGCONF="/etc/X11/xorg.conf"
[...]
> - sed -i "/RgbPath/d" "${D}"${XORGCONF}
> + sed -i "/RgbPath/d" "${D}${XORGCONF}"
Sorry, but why? What is the difference? Seems $XORGCONF does not contain
any spaces inside and both forms are acceptable.
--
Peter.
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-base/xorg-x11: xorg-x11-7.2.ebuild xorg-x11-7.3.ebuild ChangeLog
On 13:50 Tue 09 Oct , Peter Volkov wrote:
> > XORGCONF="/etc/X11/xorg.conf"
> [...]
> > - sed -i "/RgbPath/d" "${D}"${XORGCONF}
> > + sed -i "/RgbPath/d" "${D}${XORGCONF}"
>
> Sorry, but why? What is the difference? Seems $XORGCONF does not contain
> any spaces inside and both forms are acceptable.
Oh, that's a leftover from when I was playing around with putting
${ROOT} in ${XORGCONF}, but it turned out to be the wrong way to go. I
do kinda like quoting the whole path, though. Haven't decided which way
I like better yet.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: use flags -> use options
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
> So what you want is a USE_EXPAND version that only allows one value
> per variable. That wouldn't be terribly difficult to do.
I extremely dislike that characterization. What I want is use flags with more
than two possible values. I see no reason to warp that to fit USE_EXPAND.
There may even be uses where this could be used in combination with USE_EXPAND.
> As for your idea (ignoring implementation issues), I'd expect that
> sooner or later people will request multivalue functionality as well,
> so we'd have the same situation there.
Right, current use flags are "2 options, pick 1", I am requesting "n options,
pick 1" and you're saying "n options, pick m, (m Also in the given example, how
> would the user/package manager actually know what values were
> valid/available for "impl"?
That is a good question. If all possible options need to be specified a syntax
should be developed for that. How about:
IUSE="+default_on_flag normalflag
multiwayflag={option1,option2,+default_option} -default_off_flag",
or
IUSE="+default_on_flag normalflag multiwayflag={option1 option2
+default_option} -default_off_flag",
or
IUSE="+default_on_flag normalflag multiwayflag=(option1 option2
+default_option) -default_off_flag".
In use.[local.]desc the multiwayflag description should explain what each
alternative means.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
Re: [gentoo-dev] Modular texlive eclasses up for review
On Tue, 09 Oct 2007 08:13:31 +0100
Roy Marples <[EMAIL PROTECTED]> wrote:
> grep '^!' "${i}" | tr ' ' '=' |sort|uniq >> "${T}/jobs"
> Could be done with a 1 sed and 1 sort call, but whatever floats your
> boat.
well as this is very inspired from texlive install-pkg.sh script, I'd
prefer not differing that much.
> if [ "${f/config/}" != "${f}" ]
> Should be
> if [ "${f#*config*}" != "${f}" ]
changed that one, the "semantics" looks better indeed; what is wanted
here is to exclude $f containing "config". Am I missing something when
I understand it as the exact same thing but more readable ?
> return $([ -f "${mark}" ])
> Could be written as
> [ -f "${mark}" ]
thanks, too much influence from other programming languages...
Attached try3, with some more comments on the functions of
texlive-module.eclass.
Alexis.
texlive-module.eclass
Description: Binary data
texlive-common.eclass
Description: Binary data
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/ace: ChangeLog ace-5.6.1.ebuild
On Monday 08 October 2007, Donnie Berkholz wrote:
> On 19:52 Sun 07 Oct , Daniel Black (dragonheart) wrote:
> > 1.1 dev-libs/ace/ace-5.6.1.ebuild
> >
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/ace/ace-5.6.1.eb
> >uild?rev=1.1&view=markup plain:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/ace/ace-5.6.1.eb
> >uild?rev=1.1&content-type=text/plain
> >
> > pkg_postinst() {
> > # This is required, as anything trying to compile against ACE will have
> > # problems with conflicting OS.h files if this is not done.
> >
> > local CC_MACHINE=$($(tc-getCC) -dumpmachine)
> > if [ -d "/usr/lib/gcc-lib/${CC_MACHINE}/$(gcc-fullversion)/include/ace"
> > ]; then mv
> > "/usr/lib/gcc-lib/${CC_MACHINE}/$(gcc-fullversion)/include/ace" \
> > "/usr/lib/gcc-lib/${CC_MACHINE}/$(gcc-fullversion)/include/ace.old"
>
> Does gcc not use get_libdir() ? I also find it a little unusual that
> you're not informing people when you're renaming directories on their
> live systems.
this cant be right at all ... i say the whole pkg_postinst() needs to get
punted
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Modular texlive eclasses up for review
On Tue, 2007-10-09 at 13:17 +0200, Alexis Ballier wrote:
> > if [ "${f/config/}" != "${f}" ]
> > Should be
> > if [ "${f#*config*}" != "${f}" ]
>
> changed that one, the "semantics" looks better indeed; what is wanted
> here is to exclude $f containing "config". Am I missing something when
> I understand it as the exact same thing but more readable ?
The former is bash specific, the later is POSIX. Both do different
things though.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Unmasking udev-115-r5
On Freitag, 21. September 2007, Matthias Schwarzott wrote: > Hi there! > > If nobody objects, I will unmask udev-115-r5 (or later if needed) today or > tomorrow. There are some rules that got removed between udev-115-r1 and > newer version. If you miss anything please contact us. Either these need to > be added back, or installed by other relevant packages. > > One package I know that needs this is aoetools (Bug #193315). > > Please, if you use or maintain any unusual hardware/driver, please test if > there are no regressions in udev-115-r5. > > One still open regression is this: As we no longer use a wrapper around > modprobe blacklisting will not work in all cases, until module-init-tools > is patched (Bug #192201). > Patched version of module-init-tools done, thanks to Mike Frysinger. So finally this version got unmasked. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Modular texlive eclasses up for review
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
>> changed that one, the "semantics" looks better indeed; what is wanted
>> here is to exclude $f containing "config". Am I missing something when
>> I understand it as the exact same thing but more readable ?
>>
>
> The former is bash specific, the later is POSIX. Both do different
> things though.
>
> Thanks
>
> Roy
>
>
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/evms: ChangeLog evms-2.5.5-r8.ebuild
Donnie Berkholz wrote:
On 22:01 Mon 08 Oct , Doug Goldstein (cardoe) wrote:
1.1 sys-fs/evms/evms-2.5.5-r8.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/evms/evms-2.5.5-r8.ebuild?rev=1.1&view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/evms/evms-2.5.5-r8.ebuild?rev=1.1&content-type=text/plain
epatch "${FILESDIR}/${PV}/md_super_fix.patch"
epatch "${FILESDIR}/${PV}/ntfs_unmkfs.patch"
epatch "${FILESDIR}/${PV}/raid5_degrade_fix_v2.patch"
epatch "${FILESDIR}/${PV}/raid5_remove_spare_fix.patch"
epatch "${FILESDIR}/${PV}/raid5_remove_spare_fix_2.patch"
epatch "${FILESDIR}/${PV}/raid5_algorithm.patch"
epatch "${FILESDIR}/${PV}/cli_reload_options.patch"
epatch "${FILESDIR}/${PV}/cli_query_segfault.patch"
epatch "${FILESDIR}/${PV}/get_geometry.patch"
epatch "${FILESDIR}/${PV}/BaseName.patch"
epatch "${FILESDIR}/${PV}/disk_cache.patch"
epatch "${FILESDIR}/${P}-as-needed.patch"
epatch "${FILESDIR}/${P}-glib_dep.patch"
epatch "${FILESDIR}/${P}-ocfs2.patch"
epatch "${FILESDIR}/${P}-use_disk_group.patch"
epatch "${FILESDIR}/${P}-pagesize.patch"
This would be another good candidate for using epatch's bulk patching,
particularly if you moved the last group of patches into the PV
directory.
dev-zero?
I merely fixed baselayout-2 issues and didn't change any functionality
of the ebuild since I don't have an evms setup to test.
mv -f ${D}/$(get_libdir)/*.a "${D}/usr/$(get_libdir)"
mv -f ${D}/sbin/evmsgui ${D}/usr/sbin
Quoting
Thanks,
Donnie
Your a bit late. I fixed the quoting issues in the ebuild around 8pm EDT
along with a few other issues. See the -r9 ebuild.
--
Doug Goldstein <[EMAIL PROTECTED]>
http://dev.gentoo.org/~cardoe/
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use
"Robin H. Johnson" <[EMAIL PROTECTED]> wrote: > how soon can we start to use it > to replace the old crufty no* flags So what's going on here? Do we need to wait for EAPI=1 and use the new IUSE defaults? Or can we use package.use right now? I also have some 'disablefoo' USE flags I want to clear out for the 1.0.0 release of fluxbox. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
[gentoo-dev] Re: Re: GNU userland and binary package (WAS: RFC: sh versionator.eclass)
Natanael Copa wrote: > On Mon, 2007-10-08 at 20:25 +0100, Steve Long wrote: >> Natanael Copa wrote: > >> If you're that motivated why not just start hacking on binary support in >> portage/pkgcore/paludis? There's always open bugs. > > I think I did contribute with some patches for qmerge in portage-utils. > Nice one! I really like portage-utils, they're good and fast. > Unfortunally, its pretty difficult to make a lightweight C (language) > only binary installer without having at least the eclasses and GNU > tools. > > It kind of defeat the idea of having a lightweight binary only runtime > environment. (lightweight means busybox - which give you most of the > basic GNU tools, linux-utils, wget, shell, http server and much more for > the size of bash only) > Yes but build time is not the same as runtime, especially for embedded systems. Installation doesn't have to be run by the target, which typically uses an image. >> I'd just specify BASH (as I don't see the point in making the distinction >> as it only applies to build machines) and coreutils/findutils etc. > > To properly install a prebuilt binary packages you need the pkg_* funcs > in the ebuild. > >> Asking everyone to switch coding style for certain functions, just to >> support the stuff that Gentoo was designed to do from the beginning, >> seems counter-productive. > > We already do different for init.d scripts (which is great!) , but sure, > I get the point. > That's entirely proper and reasonable to me, since it means the installed system can use whatever shell it likes. >> For every market except embedded, which we've discussed >> already, BASH is not a major issue: nor are the other tools mentioned. > > I happen to do embedded. > I don't understand then why you cannot build images using whatever tools you like and then simply run them using the targets. Apologies if I am missing something. >> > >> > Alternative C is what I do today. >> > >> Sounds rough :) > > Thats why I'm interested in alternatives. > >> (I really would recommend #pkgcore as well as there is several years of >> work to do with binpkgs in that.) > > So far no packagemanager using the portage stuff (eclasses) are not even > close to compete in size for binary only installs. Closest is > portage-utils's qmerge but it would need atleast the eclasses and bash > which would atleast double the size in comparison what I do today. > > Looks like i will need to continue do my own stuff. > > Thanks for you time! > Good luck with it! I recommend #gentoo-embedded on irc.freenode.org btw; ##electronics is good. Some of the bods in #gentoo-chat have experience with this kinda thing as well, and you'd be welcome in #friendly-coders. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-wm/fluxbox: ChangeLog fluxbox-1.0.0.ebuild
On 14:45 Tue 09 Oct , Jim Ramsay (lack) wrote:
> 1.1 x11-wm/fluxbox/fluxbox-1.0.0.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-wm/fluxbox/fluxbox-1.0.0.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-wm/fluxbox/fluxbox-1.0.0.ebuild?rev=1.1&content-type=text/plain
> pkg_setup() {
> if use imlib ; then
> if ! built_with_use media-libs/imlib2 X ; then
> eerror "To build fluxbox with imlib in USE, you need an
> X enabled"
> eerror "media-libs/imlib2 . Either recompile imlib2
> with the X"
> eerror "USE flag turned on or disable the imlib USE
> flag for fluxbox."
> die "USE=imlib requires imlib2 with USE=X"
> fi
> fi
> }
There's only one case you're interested in here, so you could just
combine the two things into a single statement:
if use imlib && ! built_with_use media-libs/imlib2 X; then
> src_compile() {
> export PKG_CONFIG_PATH=/usr/X11R6/lib/pkgconfig:/usr/lib/pkgconfig
This shouldn't be necessary anymore.
> src_install() {
> dodir /usr/share/fluxbox
> make DESTDIR="${D}" install || die "make install failed"
If emake doesn't work, please add a comment to that effect.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-plugins/vdr-radio: ChangeLog vdr-radio-0.2.4.ebuild
On 17:38 Tue 09 Oct , Matthias Schwarzott (zzam) wrote:
> 1.1 media-plugins/vdr-radio/vdr-radio-0.2.4.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-plugins/vdr-radio/vdr-radio-0.2.4.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-plugins/vdr-radio/vdr-radio-0.2.4.ebuild?rev=1.1&content-type=text/plain
> chown -R vdr:vdr "${D}"/var/cache/vdr-radio
You could use fowners here, since the rest of the ebuild uses the
portage functions.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-libs/libpcap: ChangeLog libpcap-0.9.8.ebuild libpcap-0.9.4.ebuild
On 17:57 Tue 09 Oct , Markus Ullmann (jokey) wrote: > 1.1 net-libs/libpcap/libpcap-0.9.8.ebuild > > file : > http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-libs/libpcap/libpcap-0.9.8.ebuild?rev=1.1&view=markup > plain: > http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-libs/libpcap/libpcap-0.9.8.ebuild?rev=1.1&content-type=text/plain > DEPEND="!virtual/libpcap" > PROVIDE="virtual/libpcap" Does this still work properly with some of the new portage versions that consider installed packages? Thanks, Donnie -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpdump: ChangeLog tcpdump-3.9.8.ebuild
On 18:04 Tue 09 Oct , Markus Ullmann (jokey) wrote:
> 1.1 net-analyzer/tcpdump/tcpdump-3.9.8.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-analyzer/tcpdump/tcpdump-3.9.8.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-analyzer/tcpdump/tcpdump-3.9.8.ebuild?rev=1.1&content-type=text/plain
> src_compile() {
> # tcpdump needs some optymalization. see bug #108391
> ( ! is-flag -O? || is-flag -O0 ) && append-flags -O
You don't need a subshell here. If you feel that it improves
readability, use a code block instead.
> # Fix wrt bug #48747
> if [[ $(gcc-major-version) -gt 3 ]] || \
> [[ $(gcc-major-version) -eq 3 && $(gcc-minor-version) -ge 4 ]]
> then
> filter-flags -funit-at-a-time
> append-flags -fno-unit-at-a-time
> fi
This kind of stuff might be worth verifying whether it's still needed on
every bump. The last comment on the bug refers to gcc 4.0.*.
> make CCOPT="$CFLAGS" || die "make failed"
If emake doesn't work, please add a comment to that effect.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: app-emacs/ses
# Ulrich Mueller <[EMAIL PROTECTED]> (09 Oct 2007) # Broken. Last upstream release as separate package in 2003; # newer version is included with Emacs 22. # Masked for removal in 30 days, bug #195232. app-emacs/ses -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for October
Just a quick reminder, the meeting will be on thursday. cheers, Wernfried -- Wernfried Haas (amne) - amne (at) gentoo.org Gentoo Forums - http://forums.gentoo.org forum-mods (at) gentoo.org #gentoo-forums (freenode) pgpYRQfO0VnSE.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/vlc: ChangeLog vlc-0.9.0_alpha20071009.ebuild
On 22:23 Tue 09 Oct , Alexis Ballier (aballier) wrote: > 1.1 media-video/vlc/vlc-0.9.0_alpha20071009.ebuild > > file : > http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/vlc/vlc-0.9.0_alpha20071009.ebuild?rev=1.1&view=markup > plain: > http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/vlc/vlc-0.9.0_alpha20071009.ebuild?rev=1.1&content-type=text/plain > IUSE="a52 3dfx debug altivec httpd vlm gnutls live v4l v4l2 cdda ogg matroska > dvb dvd vcd vcdx dts flac mpeg vorbis theora X opengl truetype svg fbcon svga > oss aalib ggi libcaca esd arts alsa wxwindows ncurses xosd lirc stream > mp3 xv bidi sdl sdl-image png xml samba daap mod speex shout rtsp > win32codecs skins hal avahi xinerama cddb directfb upnp nsplugin seamonkey > optimisememory libnotify jack musepack x264 dc1394 lua gnome pvr taglib > musicbrainz dbus libgcrypt id3tag cdio ffmpeg twolame" > > RDEPEND=" > ffmpeg? ( >=media-video/ffmpeg-0.4.9_p20050226-r1 ) > cdda? ( >=dev-libs/libcdio-0.72 > cddb? ( >=media-libs/libcddb-1.2.0 ) ) > live? ( >=media-plugins/live-2007.02.20 ) > dvd? ( media-libs/libdvdread > media-libs/libdvdcss > >=media-libs/libdvdnav-0.1.9 > media-libs/libdvdplay ) > esd? ( media-sound/esound ) > ogg? ( media-libs/libogg ) > matroska? ( > >=dev-libs/libebml-0.7.6 > >=media-libs/libmatroska-0.8.0 ) > mp3? ( media-libs/libmad ) > a52? ( >=media-libs/a52dec-0.7.4-r3 ) > dts? ( media-libs/libdca ) > flac? ( media-libs/libogg > >=media-libs/flac-1.1.2 ) > mpeg? ( >=media-libs/libmpeg2-0.3.2 ) > vorbis? ( media-libs/libvorbis ) > theora? ( media-libs/libtheora ) > truetype? ( media-libs/freetype > media-fonts/ttf-bitstream-vera ) [crop another 30 or so] Both the IUSE list and this dep list would be vastly easier to parse if they were ordered alphabetically. > 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() ? > > 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. 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 Jim Ramsay wrote: > "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: >> how soon can we start to use it >> to replace the old crufty no* flags > > So what's going on here? Do we need to wait for EAPI=1 and use the new > IUSE defaults? Or can we use package.use right now? 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. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHDC59/ejvha5XGaMRAgrmAJ4pDB143kdDUmONUP+K4zMUe+odOwCdGuxv AZ2l40GfjZCs9Urm04iNb1k= =11// -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: www-client/planet
# Steve Dibb <[EMAIL PROTECTED]> (11 Aug 2007) # Old, unmaintained, pending removal www-client/planet punted -- [EMAIL PROTECTED] mailing list
[gentoo-dev] lame use flag, local to global
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 Steve -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/mplayer: ChangeLog mplayer-1.0_rc2.ebuild
On 04:22 Wed 10 Oct , Steve Dibb (beandog) wrote:
> 1.1 media-video/mplayer/mplayer-1.0_rc2.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/mplayer/mplayer-1.0_rc2.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/mplayer/mplayer-1.0_rc2.ebuild?rev=1.1&content-type=text/plain
> if use encode; then
> use aac || myconf="${myconf} --disable-faac"
> use dv || myconf="${myconf} --disable-libdv"
> use x264 || myconf="${myconf} --disable-x264"
> else
> myconf="${myconf} --disable-mencoder --disable-libdv
> --disable-x264 \
> --disable-faac"
> fi
This could be:
if use encode; then
myconf="${myconf}
--enable-mencoder
$(use_enable aac faac)
$(use_enable dv libdv)
$(use_enable x264)"
fi
> use lirc || myconf="${myconf} --disable-lirc --disable-lircc"
> myconf="${myconf} $(use_enable joystick)"
> use ipv6 || myconf="${myconf} --disable-inet6"
> use rar || myconf="${myconf} --disable-unrarlib"
> use rtc || myconf="${myconf} --disable-rtc"
> use samba || myconf="${myconf} --disable-smb"
This could be more use_enable()'s. Does mplayer's build die if you pass
a redundant --enable-foo or something?
> # DVB / Video4Linux / Radio support
> if { use dvb || use v4l || use v4l2 || use radio; }; then
> use dvb || myconf="${myconf} --disable-dvb --disable-dvbhead"
> use v4l || myconf="${myconf} --disable-tv-v4l1"
> use v4l2 || myconf="${myconf} --disable-tv-v4l2"
> use teletext || myconf="${myconf} --disable-tv-teletext"
> use pvr || myconf="${myconf} --disable-pvr"
> if use radio && { use dvb || use v4l || use v4l2; }; then
> myconf="${myconf} --enable-radio $(use_enable encode
> radio-capture)"
> else
> myconf="${myconf} --disable-radio-v4l2
> --disable-radio-bsdbt848"
> fi
> else
> myconf="${myconf} --disable-tv --disable-tv-v4l1
> --disable-tv-v4l2 \
> --disable-radio --disable-radio-v4l2
> --disable-radio-bsdbt848 \
> --disable-dvb --disable-dvbhead --disable-tv-teletext \
> --disable-pvr"
> fi
Here's one other way to do this (leaving out myconf etc):
$(use_enable dvb)
$(use_enable dvb dvbhead)
$(use_enable v4l tv-v4l1)
$(use_enable v4l2 tv-v4l2)
$(use_enable teletext tv-teletext)
$(use_enable pvr)
if use dvb || use v4l || use v4l2; then
$(use_enable radio)
$(use_enable radio radio-bsdbt848)
$(use_enable radio radio-v4l2)
# etc...
fi
> use aac || myconf="${myconf} --disable-faad-internal"
> use amrnb || myconf="${myconf} --disable-libamr_nb"
> use amrwb || myconf="${myconf} --disable-libamr_wb"
> use dts || myconf="${myconf} --disable-libdca"
> ! use png && ! use gtk && myconf="${myconf} --disable-png"
> use lzo || myconf="${myconf} --disable-liblzo"
> use encode && use mp2 || myconf="${myconf} --disable-twolame \
> --disable-toolame"
> use mp3 || myconf="${myconf} --disable-mp3lib"
> use quicktime || myconf="${myconf} --disable-qtx"
> use vorbis || myconf="${myconf} --disable-libvorbis"
> use xanim && myconf="${myconf} --xanimcodecsdir=/usr/lib/xanim/mods"
Again, use_enable() would be cleaner in many cases.
> use aalib || myconf="${myconf} --disable-aa"
> use dga || myconf="${myconf} --disable-dga1 --disable-dga2"
> use fbcon || myconf="${myconf} --disable-fbdev"
> use fbcon && use video_cards_s3virge && myconf="${myconf} --enable-s3fb"
> use libcaca || myconf="${myconf} --disable-caca"
> use opengl || myconf="${myconf} --disable-gl"
> use video_cards_vesa || myconf="${myconf} --disable-vesa"
> use vidix || myconf="${myconf} --disable-vidix-internal \
> --disable-vidix-external"
> use zoran || myconf="${myconf} --disable-zr"
And again
> if use xv; then
> if use xvmc; then
> myconf="${myconf} --enable-xvmc --with-xvmclib=XvMCW"
> else
> myconf="${myconf} --disable-xvmc"
> fi
> else
> myconf="${myconf} --disable-xv --disable-xvmc"
> fi
Something along these lines might do:
$(use_enable xv)
$(use xv && $(use_enable xvmc))
$(use xv && $(use_with xvmc with-xvmclib XvMCW))
Would this kind of cleanup work?
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
