[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-emacs/lua-mode: ChangeLog lua-mode-20070708.ebuild

[Christian Faulhammer]

Donnie Berkholz <[EMAIL PROTECTED]>:

> On 15:22 Mon 08 Oct , Christian Faulhammer (opfer) wrote:
> > 1.1  app-emacs/lua-mode/lua-mode-20070708.ebuild
> > 
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emacs/lua-mode/lua-mode-20070708.ebuild?rev=1.1&view=markup
> > plain:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emacs/lua-mode/lua-mode-20070708.ebuild?rev=1.1&content-type=text/plain
> 
> > src_compile() {
> > /usr/bin/emacs -batch --no-site-file --no-init-file \
> > --load "${S}/lua-mode.el" -f batch-byte-compile
> > lua-mode.el }
> 
> Shouldn't this be using the new eclass functions?

 XEmacs has the new eclass, Emacs has had this for a long time.  But
you are right.

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] Re: [gentoo-commits] gentoo-x86 commit in media-plugins/vdr-extrecmenu: ChangeLog vdr-extrecmenu-1.0.ebuild

[Piotr Jaroszyński]

On Monday 08 of October 2007 11:22:42 Matthias Schwarzott wrote:
> On Montag, 8. Oktober 2007, Donnie Berkholz wrote:
> > On 20:23 Sun 07 Oct , Joerg Bornkessel (hd_brummy) wrote:
> > This doesn't respect ROOT != / and it's also dependent on the build
> > system.
>
> I guess ROOT-safeness here is irrelevant, as for vdr / vdr-plugin.eclass
> there is yet no good solution to use the headers from
> ${ROOT}/usr/include/vdr for compiling.
>
>
> How can this be converted to respect ROOT ?

$ROOT shouldn't be used in src_*

> Most times the sources just do
> #include 
>
> And this normally will find headers located under /usr/include.

And that's the way to go. When you build with ROOT=/foo DEPEND is installed 
into / and only {R,P}DEPEND into /foo.

-- 
Best Regards,
Piotr Jaroszyński
--
[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]

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.

>   mv -f ${D}/$(get_libdir)/*.a "${D}/usr/$(get_libdir)"
>   mv -f ${D}/sbin/evmsgui ${D}/usr/sbin

Quoting

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-emacs/lua-mode: ChangeLog lua-mode-20070708.ebuild

[Donnie Berkholz]

On 15:22 Mon 08 Oct , Christian Faulhammer (opfer) wrote:
> 1.1  app-emacs/lua-mode/lua-mode-20070708.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emacs/lua-mode/lua-mode-20070708.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emacs/lua-mode/lua-mode-20070708.ebuild?rev=1.1&content-type=text/plain

> src_compile() {
>   /usr/bin/emacs -batch --no-site-file --no-init-file \
>   --load "${S}/lua-mode.el" -f batch-byte-compile lua-mode.el
> }

Shouldn't this be using the new eclass functions?

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-kids/gcompris: ChangeLog gcompris-8.4.ebuild

[Bo Ørsted Andresen]

On Monday 08 October 2007 06:47:05 Donnie Berkholz wrote:
> > src_unpack() {
[SNIP]
> Shouldn't this respect ROOT != / ? I can see how that would be a bit of
> an unusual use case for games, though.

Use of $ROOT in src_* would be illegal (which is why there a bunch of bug 
reports with "abusing ROOT" in the summary field...).

-- 
Bo Andresen


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/win32codecs: ChangeLog win32codecs-20071007.ebuild

[Donnie Berkholz]

On 11:13 Mon 08 Oct , Steve Dibb (beandog) wrote:
> 1.1  media-libs/win32codecs/win32codecs-20071007.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-libs/win32codecs/win32codecs-20071007.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-libs/win32codecs/win32codecs-20071007.ebuild?rev=1.1&content-type=text/plain

>   cd ${S}

A polite reminder that the quoting patch is in released portage.

> QA_TEXTRELS="usr/$(get_libdir)/real/drvc.so
>   usr/$(get_libdir)/real/drv[34].so.6.0
>   usr/$(get_libdir)/win32/vid_*.xa"
>   dodir /usr/$(get_libdir)/win32
>   dodir /usr/$(get_libdir)/real
>   insinto /usr/$(get_libdir)/real
>   ln -s "${D}/usr/$(get_libdir)/real/*" 
> "${D}/usr/$(get_libdir)/win32/"
>   insinto /usr/$(get_libdir)/win32
> SEARCH_DIRS_MASK="/usr/$(get_libdir)/real /usr/$(get_libdir)/win32"

With this many calls to get_libdir(), it might make sense to just call 
it once and save it in a global variable.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Modular texlive eclasses up for review

[Jeroen Roovers]

On Tue, 9 Oct 2007 01:03:17 +0200
Alexis Ballier <[EMAIL PROTECTED]> wrote:

> > Hi list, 

A bit of documentation for the (exported) functions would be nice. And
maybe some "red tape" to show where the exported bits end/start. And
short bits of text explaining why some of the variables are needed and
what they do.


Kind regards,
 JeR
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Modular texlive eclasses up for review

[Alexis Ballier]

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.


texlive-common.eclass
Description: Binary data


texlive-module.eclass
Description: Binary data


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-util/devhelp: ChangeLog devhelp-0.16.1.ebuild

[Gilles Dartiguelongue]

Le lundi 08 octobre 2007 à 23:36 +0200, Christian Faulhammer a écrit :
> "Gilles Dartiguelongue (eva)" <[EMAIL PROTECTED]>:
> 
> >   Modified: ChangeLog
> >   Added:devhelp-0.16.1.ebuild
> >   Log:
> >   bump to 0.16.1
> > sparc? ( >=www-client/mozilla-firefox-1.0.2-r1 )
> > ||  (
> > xulrunner? ( net-libs/xulrunner )
> > >=www-client/mozilla-firefox-1.0.2-r1
> > )
> 
>  Is there a specific reason?  xulrunner is stable/keyworded on sparc,
> so why exclude it here?

that was a leftover, thanks for pointing it out.
-- 
Gilles Dartiguelongue <[EMAIL PROTECTED]>
Gentoo


signature.asc
Description: Ceci est une partie de message	numériquement signée

[gentoo-dev] Modular texlive eclasses up for review

[Alexis Ballier]

Hi list, 

attached are two new eclasses I'm planning to commit soon.
I'm sending 'em as some reviewing never hurts, but I hope they're
perfectly fine ;)

texlive-common.eclass : helper eclass for handling the texmf
tree; it contains variable definitions used by texlive ebuilds and
two functions : 
- one to move config files that might be modified by the
user to /etc and symlink them from the original location to not break
texmf stucture; 
- the second function search for a file in the texmf tree in the
current directory (the usual tex distribution's way is to have ls-R
files and use kpsewhich but we must not assume the presence of such
programs/files as we'll be using it for installing texlive...)


texlive-module.eclass : generic installation eclass for all the
different parts of texlive's texmf tree, this is to avoid code
duplication in 80+ ebuilds.


If no objection, I'll commit them in a few days.


Regards, 

Alexis.


texlive-module.eclass
Description: Binary data


texlive-common.eclass
Description: Binary data


signature.asc
Description: PGP signature

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-util/devhelp: ChangeLog devhelp-0.16.1.ebuild

[Christian Faulhammer]

"Gilles Dartiguelongue (eva)" <[EMAIL PROTECTED]>:

>   Modified: ChangeLog
>   Added:devhelp-0.16.1.ebuild
>   Log:
>   bump to 0.16.1
>   sparc? ( >=www-client/mozilla-firefox-1.0.2-r1 )
>   ||  (
>   xulrunner? ( net-libs/xulrunner )
>   >=www-client/mozilla-firefox-1.0.2-r1
>   )

 Is there a specific reason?  xulrunner is stable/keyworded on sparc,
so why exclude it here?

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] Re: [gentoo-commits] gentoo-x86 commit in games-kids/gcompris: ChangeLog gcompris-8.4.ebuild

[Denis Dupeyron]

On 10/8/07, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> >   cp /usr/share/gettext/config.rpath .
>
> Shouldn't this respect ROOT != / ? I can see how that would be a bit of
> an unusual use case for games, though.

While we're on that topic :

[EMAIL PROTECTED] /tmp/gcompris-8.4 $ ./configure --help
[...]
--disable-rpath do not hardcode runtime library paths

I don't recall seeing this in previous versions. This whole thing is
certainly beyond my understanding, but could this option enable us to
avoid that ugly copy of config.rpath in src_unpack() ?

Denis.
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-kids/gcompris: ChangeLog gcompris-8.4.ebuild

[Jan Kundrát]

Tristan Heaven wrote:
> It's my understanding that anything in DEPEND will be installed into /,
> so no.

If you mean that running `ROOT=/target emerge --usepkgonly foo-package`
will install foo-package's dependencies into real /, then no, it won't.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: use flags -> use options

[Marius Mauch]

On Mon, 08 Oct 2007 13:45:04 +0200
"Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Marius Mauch wrote:
> >>> "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]>:
>  I imagine there are a lot more cases where the simple on/off
>  system we have now is suboptimal. I could be wrong of course.
>  Please comment.
> >>>  This key=value systems sounds interesting.  Another use could be
> >>> the choice between xulrunner, seamonkey, firefox. 
> > 
> > We already have this with USE_EXPAND. Not exactly the same syntax,
> > but I don't see a terrible problem in that, and we don't have to
> > fix all three trillion related tools to handle it. Unless you can
> > come up with a case that can't be handled with USE_EXPAND.
> 
> No, USE_EXPAND is only a way to abbreviate use flags with a common
> substring in their name, such as "impl_guile impl_sbcl impl_clisp"
> which could be encoded interchangeably as either
> 
> # without USE_EXPAND
> IUSE="impl_guile impl_sbcl impl_clisp"
> 
> or
> 
> # with USE_EXPAND
> for impl in IMPL; do IUSE+="impl_${impl}"; done
> 
> but the effect is that there are 3 use flags with a total of 2^3=8
> combinations, while really something with exactly 3 combinations is
> needed:
> 
> IUSE="impl"
> 
> case ${impl} in
>   guile)  #use guile as backend
>sbcl)  #use sbcl  as backend
>   clisp)  #use clisp as backend

So what you want is a USE_EXPAND version that only allows one value
per variable. That wouldn't be terribly difficult to do.
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. Also in the given example, how
would the user/package manager actually know what values were
valid/available for "impl"?

Marius
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: GNU userland and binary package (WAS: RFC: sh versionator.eclass)

[Steve Long]

Natanael Copa 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, 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.  ;)
>> > >
++ on the general idea: GNU sed, grep, awk, ed and find get my vote (as well
as BASH ofc.) (I don't /think/ you need xargs anymore with find .. -exec.)

>> >
>> > 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.
>>
Well all you're talking about is BASH and a few others on the machine that
builds the binaries afaict. I don't see that as a major imposition. You can
then package for downstream using whatever you like.

If you're that motivated why not just start hacking on binary support in
portage/pkgcore/paludis? There's always open bugs.

>> 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.
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. For every market except embedded, which we've discussed
already, BASH is not a major issue: nor are the other tools mentioned.
> 
> Alternative C is what I do today.
> 
Sounds rough :)
(I really would recommend #pkgcore as well as there is several years of work
to do with binpkgs in that.)

Standardising on a certain subset of base GNU tools seems like a good idea
to me too.


-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)

[Natanael Copa]

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.

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.

C. Binary package managers will need to write their own pre/post
scripts.


Any other alternatives?

Comments?


Alternative C is what I do today.

-nc

> 
> -Alec

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: use flags -> use options

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ryan Hill wrote:
> Marijn Schouten (hkBst) wrote:
>> Marius Mauch wrote:
> 
>>> We already have this with USE_EXPAND. Not exactly the same syntax, but
>>> I don't see a terrible problem in that, and we don't have to fix all
>>> three trillion related tools to handle it. Unless you can come up
>>> with a case that can't be handled with USE_EXPAND.
>  
>> No, USE_EXPAND is only a way to abbreviate use flags with a common substring
>> in their name, such as "impl_guile impl_sbcl impl_clisp" which could be
>> encoded interchangeably as either
> 
> You're kidding, right?

No, if what I'm saying makes no sense it is ignorance. Please enlighten me.

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project
, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHCkNVp/VmCx0OL2wRAv1/AJ9GBpu8wL6NL4Xw8sawwPEeHAmkdQCeJFqF
fq8NiFnqnV9NBErojijBW+A=
=LO9y
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: use flags -> use options

[Ryan Hill]

Marijn Schouten (hkBst) wrote:
> Marius Mauch wrote:

>> We already have this with USE_EXPAND. Not exactly the same syntax, but
>> I don't see a terrible problem in that, and we don't have to fix all
>> three trillion related tools to handle it. Unless you can come up
>> with a case that can't be handled with USE_EXPAND.
 
> No, USE_EXPAND is only a way to abbreviate use flags with a common substring
> in their name, such as "impl_guile impl_sbcl impl_clisp" which could be
> encoded interchangeably as either

You're kidding, right?

> USE EXPAND Defines a list of variables which are to be treated incrementally 
> and who
>   contents are to be expanded into the USE variable as passed to ebuilds. 
> Expansion 
>   done as per Algorithm 2. So, for example, if USE EXPAND contains ‘ALSA 
> CARDS’, an
>   the ALSA CARDS variable contains ‘foo’, ‘alsa_cards_foo’ will be 
> appended to USE.

> Algorithm 2: USE EXPAND logic
>   for each variable V listed in USE EXPAND do
> for each token T in V do
> append v_T to USE, where v is the lowercase of V
> end for
>   end for


-- 
  fonts / wxWindows / gcc-porting / treecleaners
  EFFD 380E 047A 4B51 D2BD  C64F 8AA8 8346 F9A4 0662 (0xF9A40662)

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)

[Alec Warner]

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.

-Alec
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: use flags -> use options

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:
>>> "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]>:
 I imagine there are a lot more cases where the simple on/off
 system we have now is suboptimal. I could be wrong of course.
 Please comment.
>>>  This key=value systems sounds interesting.  Another use could be
>>> the choice between xulrunner, seamonkey, firefox. 
> 
> We already have this with USE_EXPAND. Not exactly the same syntax, but
> I don't see a terrible problem in that, and we don't have to fix all
> three trillion related tools to handle it. Unless you can come up
> with a case that can't be handled with USE_EXPAND.

No, USE_EXPAND is only a way to abbreviate use flags with a common substring
in their name, such as "impl_guile impl_sbcl impl_clisp" which could be
encoded interchangeably as either

# without USE_EXPAND
IUSE="impl_guile impl_sbcl impl_clisp"

or

# with USE_EXPAND
for impl in IMPL; do IUSE+="impl_${impl}"; done

but the effect is that there are 3 use flags with a total of 2^3=8
combinations, while really something with exactly 3 combinations is needed:

IUSE="impl"

case ${impl} in
guile)  #use guile as backend
 sbcl)  #use sbcl  as backend
clisp)  #use clisp as backend

or something like that.

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project
, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHChhAp/VmCx0OL2wRArxWAKCWfciDl5XihPOoiI/01J3DjGGpqgCdFJxV
9n89OMcqxqD4JqFTPDGt12o=
=njyU
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Last rites: dev-php5/pecl-pdo*

[Robert Buchholz]

Am 08.10.2007 um 10:05 schrieb Christian Hoffmann:


On 2007-10-08 at 05:37 +0200, Robert Buchholz wrote:


On Thursday, 4. October 2007, Christian Hoffmann wrote:

# Christian Hoffmann <[EMAIL PROTECTED]> (04 Oct 2007)
# Outdated (no releases since May 2006), buggy and possibly
vulnerable
# to security problems


Anything security-related you know of or just a wild guess?

Not exactly a wild guess, I just didn't want to make a statement
on whether these are security problems or not:
  * INFILE LOCAL option handling vs. open_basedir or safe_mode
  * A crash inside pdo_pgsql on some non-well-formed SQL queries
(both from php-5.2.4 ChangeLog)


Since the second is only locally invoked* DoS and the first an
ever-beloved workaround for the basedir restriction, we don't
need to say goodbye with a maskglsa.

Thanks,
Robert

* unless someone allows remote users to submit SQL queries... :-)
--
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-plugins/vdr-extrecmenu: ChangeLog vdr-extrecmenu-1.0.ebuild

[Matthias Schwarzott]

On Montag, 8. Oktober 2007, Donnie Berkholz wrote:
> On 20:23 Sun 07 Oct , Joerg Bornkessel (hd_brummy) wrote:
> > 1.1 
> > media-plugins/vdr-extrecmenu/vdr-extrecmenu-1.0.ebuild
> >
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-plugins/vdr-extrecm
> >enu/vdr-extrecmenu-1.0.ebuild?rev=1.1&view=markup plain:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-plugins/vdr-extrecm
> >enu/vdr-extrecmenu-1.0.ebuild?rev=1.1&content-type=text/plain
> >
> > src_unpack() {
> > vdr-plugin_src_unpack
> >
> > if grep -q fskProtection /usr/include/vdr/timers.h; then
> > sed -i "s:#WITHPINPLUGIN:WITHPINPLUGIN:" Makefile
>
> This doesn't respect ROOT != / and it's also dependent on the build
> system.
>
I guess ROOT-safeness here is irrelevant, as for vdr / vdr-plugin.eclass there 
is yet no good solution to use the headers from ${ROOT}/usr/include/vdr for 
compiling.


How can this be converted to respect ROOT ?

Most times the sources just do
#include 

And this normally will find headers located under /usr/include.

Matthias

-- 
Matthias Schwarzott (zzam)
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)

[Natanael Copa]

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.

-nc

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Last rites: dev-php5/pecl-pdo*

[Christian Hoffmann]

On 2007-10-08 at 05:37 +0200, Robert Buchholz wrote:

> On Thursday, 4. October 2007, Christian Hoffmann wrote:
> > # Christian Hoffmann <[EMAIL PROTECTED]> (04 Oct 2007)
> > # Outdated (no releases since May 2006), buggy and possibly
> > vulnerable
> > # to security problems 
> 
> Anything security-related you know of or just a wild guess?
Not exactly a wild guess, I just didn't want to make a statement
on whether these are security problems or not:
  * INFILE LOCAL option handling vs. open_basedir or safe_mode
  * A crash inside pdo_pgsql on some non-well-formed SQL queries
(both from php-5.2.4 ChangeLog)

That's why I said "possibly". :)

-- 
Christian Hoffmann
Gentoo PHP herd


signature.asc
Description: PGP signature