Re: [gentoo-dev] RFC: sh versionator.eclass
On 07-10-2007 16:37:21 -0600, Joe Peterson wrote:
1) Limit tool options to those that are common to all tool variants
2) Port a standard (i.e. GNU) set of tools to all platforms
3) Force all gentoo ports to use GNU userland
...
No, it is not. The problem IMHO is in the user userland and the
portage userland are being seen as one. I think it would be very easy
to install all GNU equivalents of tools on BSD in some separate dir, put
it in portage's DEFAULT_PATH before /bin and /usr/bin and all would work
perfectly well from the ebuild/eclass perspective.
Yep, that's option #2, and I think that could work - a subset of
commands in their GNU variants used by portage. It means formalizing
the official set of tools allowed for use in ebuilds (I'm not sure if
the dev guide really codifies this or not, even though it gives a list
of such tools).
Ok, then I misunderstood. Most important thing is that we agree that
this looks like it /is/ the way to go.
What I meant above is that #3, which would be changing all of userland
itself to GNU, would be major and undesirable. Having the option of a
complete GNU userland would be an interesting option/project, but it's a
good thing to have the flexibility to have any userland desired, as long
as portage has a way of being consistent (i.e. via something like #2).
If you want a GNU userland on FreeBSD, Solaris, Darwin, etc. I think you
should look at Prefix where [[ ${USERLAND} == GNU ]] always holds. ;)
--
Fabian Groffen
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: dev-php5/pecl-pdo*
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
[gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
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] Re: [gentoo-commits] gentoo-x86 commit in media-plugins/vdr-extrecmenu: ChangeLog vdr-extrecmenu-1.0.ebuild
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.1view=markup plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-plugins/vdr-extrecm
enu/vdr-extrecmenu-1.0.ebuild?rev=1.1content-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 vdr/timers.h
And this normally will find headers located under /usr/include.
Matthias
--
Matthias Schwarzott (zzam)
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: dev-php5/pecl-pdo*
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: use flags - use options
-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
http://www.gentoo.org/proj/en/lisp/, #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] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
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
[gentoo-dev] Re: use flags - use options
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] Re: use flags - use options
-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 http://www.gentoo.org/proj/en/lisp/, #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
Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
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
[gentoo-dev] Re: GNU userland and binary package (WAS: RFC: sh versionator.eclass)
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? snip stuff that all takes a lot of effort for zero end-user gain 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] Re: use flags - use options
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
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-kids/gcompris: ChangeLog gcompris-8.4.ebuild
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: [gentoo-commits] gentoo-x86 commit in games-kids/gcompris: ChangeLog gcompris-8.4.ebuild
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
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-util/devhelp: ChangeLog devhelp-0.16.1.ebuild
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 URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Modular texlive eclasses up for review
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
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-util/devhelp: ChangeLog devhelp-0.16.1.ebuild
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
Re: [gentoo-dev] Modular texlive eclasses up for review
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] Modular texlive eclasses up for review
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
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/win32codecs: ChangeLog win32codecs-20071007.ebuild
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.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-libs/win32codecs/win32codecs-20071007.ebuild?rev=1.1content-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] Re: [gentoo-commits] gentoo-x86 commit in games-kids/gcompris: ChangeLog gcompris-8.4.ebuild
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 app-emacs/lua-mode: ChangeLog lua-mode-20070708.ebuild
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.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emacs/lua-mode/lua-mode-20070708.ebuild?rev=1.1content-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
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/evms: ChangeLog evms-2.5.5-r8.ebuild
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.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/evms/evms-2.5.5-r8.ebuild?rev=1.1content-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
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-plugins/vdr-extrecmenu: ChangeLog vdr-extrecmenu-1.0.ebuild
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 vdr/timers.h
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
