[gentoo-dev] Re: Small change: Global USE flag nsplugin
Hi, Ben de Groot yng...@gentoo.org: Christian Faulhammer wrote: [- c ] nsplugin - Builds plugins for Netscape compatible browsers [- c ] nsplugin (media-video/totem): Build media plugin for Mozilla-based browsers such as www-client/mozilla-firefox Anyone against using the local description for the global one and eliminate the first? I am against. nsplugin is for any browser that implements the old netscape plugin protocol. This is not just for Mozilla-based ones, but also for others, such as KHTML and WebKit based ones. Ok. What about: Build media plugin for browsers supporting the Netscape plugin architecture such as www-client/mozilla-firefox V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
2009/3/30 Mounir Lamouri mounir.lamo...@gmail.com: portage don't install empty files (they are ignored) so it would be painless. Yeah I forgot about this, I thought it just does not install empty directories. So there will be no difference in using -e or -s if the other package managers have the same behaviour in that regard. -- Regards, Daniel
Re: [gentoo-dev] Preserving mtimes for EAPI3
On Tuesday 31 March 2009 00:59:57 Ulrich Mueller wrote: cut [1] For find -newermt we will need =findutils-4.3.3 which shouldn't be a problem because 4.3.4 went stable in May 2007. No, BSD find does not support it and we don't want to use findutils. Neither busybox find supports it. Make it POSIX[1] please. [1] http://www.opengroup.org/onlinepubs/009695399/utilities/find.html -- Timothy `Drizzt` Redaelli FreeSBIE Developer, Gentoo Developer, GUFI Staff There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Preserving mtimes for EAPI3
On Mon, 2009-03-30 at 19:14 +0200, Ulrich Mueller wrote:
I'll try to summarise the current state of discussion in
https://bugs.gentoo.org/264130. The goal is to satisfy two
(apparently contradictory) requirements:
a) Some packages need a preserved ordering of file modification
times, therwise things will break at run time (see above).
b) Files in the installed system should not have mtimes that are
older than the build time of the package.
Now, is it possible to satisfy both? I think that the following
procedure would accomplish it:
1. Record two timestamps:
before calling pkg_setup, timestamp1;
after src_install has completed, timestamp2.
2. After src_install and before merging (the exact time would be
implementation dependent), scan ${D} for files having
mtime timestamp1 or mtime timestamp2.
Update their mtimes to timestamp1 or timestamp2, respectively.
3. Otherwise (i.e. for files with timestamp1 = mtime = timestamp2),
preserve modification times when merging ${D} to ${ROOT}.
This way, any files generated during the build process (*.pyc, *.fasl,
*.elc) would end up with timestamps newer than their corresponding
source files (*.py, *.lisp, *.el).
Please keep this user-situation in mind, which complicates things:
When developing local applications outside of portage, they often have
autogenerated makefile-dependencies on host-os headerfiles.
Now when a host package gets remerged, and the headerfiles don't change,
all the local applications recompile everything for nothing...
OTOH, when the headerfile changes, it should have mtime updated to
'merge time', because local applications _should_ recompile then.
And using 'build time' is of less use with binary packages, it should be
'merge time' instead.
Maybe this could be done somehow like this, with 'merge time'
calculation for each file based on above steps 1.-3.:
* When a to-be-merged file does not exist before, set mtime to
'merge time'.
* When a to-be-merged file does exist already, and its content
does not change, take the mtime from the already existing file.
* When a to-be-merged file does exist already, and its content
does change, set mtime to 'merge time'.
Maybe this should be done for header files only, or with some black- or
whitelisting mechanisms, or for files which have mtime'build time'?
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
Re: [gentoo-dev] Re: Small change: Global USE flag nsplugin
Christian Faulhammer wrote: Ok. What about: Build media plugin for browsers supporting the Netscape plugin architecture such as www-client/mozilla-firefox Build media plugin for browsers supporting the Netscape plugin architecture (that is almost any modern browser) Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Xorg 1.5.3 is going stable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rémi Cardona wrote: The Upgrade Guide is located at http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml The upgrade guide indicates that one should use a .fdi file for the linuxwacom driver. IIRC, this .fdi file will only allow use of one end of the tablet's pen at a time. Unless the situation has changed since mid-February, the only way to get full use of a Wacom tablet is by specifying four InputDevice sections in xorg.conf. I extend my apologies if the situation really *has* changed since February. I don't currently have access to a tablet to double-check. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJJ0eW7AAoJEEtxx6PkYe4kH4YH/jiNjMcJpppUxylHuevB7xiK xtV8va/IEVwvuqJFX8qx7BAeVWOdlXbD4V/1yOo3UTMWXVuZ8EXayPECV5hEgZ9E lXZIn2A5H2bTyoA+/PZkisqZ+geBxEGVJYqu9o2qNBfeBZMtH3UAKZJbDcCRzXOc msycI8RRlegEVxlaWO31zfyArfSyssyaXvhevjV52W5PS8QSkapWi4aXPf/Q009w AC8AnY8xAn1h6NJH99Q/ePgdeByQ27FAxrxMZgIwMlRX9FNkC/x+iCknKMZq9mLV 4iqA3rNYxFCVvQ907vQPT9y9sbMYE/Ia2fR4/QYMhpkZBtj5afTbDddKLQmw1So= =4Ma1 -END PGP SIGNATURE-
Re: [gentoo-dev] Xorg 1.5.3 is going stable
Simon C. Ion a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rémi Cardona wrote: The Upgrade Guide is located at http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml The upgrade guide indicates that one should use a .fdi file for the linuxwacom driver. IIRC, this .fdi file will only allow use of one end of the tablet's pen at a time. Unless the situation has changed since mid-February, the only way to get full use of a Wacom tablet is by specifying four InputDevice sections in xorg.conf. I extend my apologies if the situation really *has* changed since February. I don't currently have access to a tablet to double-check. The FDI file can do _everything_ the xorg.conf can. I'm not saying it's easy, but it can be done. Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org
Re: [gentoo-dev] Request for Willikins
I'd like to have willikins on #gentoo-openmoko Contact: armin76
[gentoo-dev] Re: Preserving mtimes for EAPI3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Timothy Redaelli wrote:
On Tuesday 31 March 2009 00:59:57 Ulrich Mueller wrote:
cut
[1] For find -newermt we will need =findutils-4.3.3 which shouldn't
be a problem because 4.3.4 went stable in May 2007.
No, BSD find does not support it and we don't want to use findutils.
Neither busybox find supports it.
Make it POSIX[1] please.
[1] http://www.opengroup.org/onlinepubs/009695399/utilities/find.html
Here is a solution that should work with find(1p) and touch(1p):
Immediately preceding pkg_setup, `touch
${PORTAGE_BUILDDIR}/.pre_pkg_setup`; immediately following src_install,
`touch ${PORTAGE_BUILDDIR}/.post_src_install`.
Then, the following call to find(1p) should work:
find ${D} -type f \
\( \! -newer ${PORTAGE_BUILDDIR}/.pre_pkg_setup -exec \
touch -c -r ${PORTAGE_BUILDDIR}/.pre_pkg_setup {} + \
-o -newer ${PORTAGE_BUILDDIR}/.post_src_install -exec \
touch -c -r ${PORTAGE_BUILDDIR}/.post_src_install {} + \)
- --
ABCD
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknR9dwACgkQOypDUo0oQOrNqACgl6buNNyuQqaXLMSDfu2JzPU2
NuYAoNuaxtEmFcTq0jfIetjMTeT7X2Zn
=8+lB
-END PGP SIGNATURE-
[gentoo-dev] sandbox-1.7 and static binaries
partly because the QA notices about untraceable static binaries that sandbox-1.6 emits, but mostly because i wanted to bust solar's balls, i did a mini hack fest the other nite and added ptrace() support into sandbox for static binaries. seems to work for me, but if someone notices something new and freaky, you've been warned! side note, i think sandbox-1.6-r1 should be good for stable. only one minor compliant about 1.6, and that's fixed in 1.6-r1. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Preserving mtimes for EAPI3
On Tue, 31 Mar 2009, ABCD wrote:
Here is a solution that should work with find(1p) and touch(1p):
Immediately preceding pkg_setup,
`touch ${PORTAGE_BUILDDIR}/.pre_pkg_setup`;
immediately following src_install,
`touch ${PORTAGE_BUILDDIR}/.post_src_install`.
Then, the following call to find(1p) should work:
find ${D} -type f \
\( \! -newer ${PORTAGE_BUILDDIR}/.pre_pkg_setup -exec \
touch -c -r ${PORTAGE_BUILDDIR}/.pre_pkg_setup {} + \
-o -newer ${PORTAGE_BUILDDIR}/.post_src_install -exec \
touch -c -r ${PORTAGE_BUILDDIR}/.post_src_install {} + \)
Tested and works well. Seems we cannot do without auxiliary files,
since POSIX find doesn't support any reasonable time input format.
Ulrich
[gentoo-dev] RFC: EAPI cheat sheet for your desktop
Hi everyone, with EAPI 3 confusion about what is in which EAPI may increase, although appendix E of the PMS is quite helpful here. Anyway, something handy to put on your desk is my little EAPI leaflet which gives you all important (in my eyes) information in one leaf. Have a look at URL:http://v-li.de/temp/eapi_cheatsheet.pdf, print it, fold it and tell me if you like or not (and especially what exactly). V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] sandbox-1.7 and static binaries
On 07:52 Tue 31 Mar , Mike Frysinger wrote: partly because the QA notices about untraceable static binaries that sandbox-1.6 emits, but mostly because i wanted to bust solar's balls, i did a mini hack fest the other nite and added ptrace() support into sandbox for static binaries. seems to work for me, but if someone notices something new and freaky, you've been warned! Rock on. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpJ7LElEK7LY.pgp Description: PGP signature
[gentoo-dev] Small review on function return codes and simplicity
I noticed some eclass commits using java-pkg_func-exists() and it's a
lot more complicated than it needs to me. Perhaps not everybody knows
that bash generally gives a return status from functions of the last
command run in that function. So these two things are equivalent:
java-pkg_func-exists() {
if [[ -n $(declare -f ${1}) ]]; then
return 0
else
return 1
fi
}
java-pkg_func-exists() {
[[ -n $(declare -f ${1}) ]]
}
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgp4770BE4a4F.pgp
Description: PGP signature
Re: [gentoo-dev] Small review on function return codes and simplicity
On Tue, 31 Mar 2009 11:05:30 -0700
Donnie Berkholz dberkh...@gentoo.org wrote:
I noticed some eclass commits using java-pkg_func-exists() and it's a
lot more complicated than it needs to me. Perhaps not everybody knows
that bash generally gives a return status from functions of the last
command run in that function. So these two things are equivalent:
[...]
java-pkg_func-exists() {
[[ -n $(declare -f ${1}) ]]
}
What's with that -n thing? If you're going for less complicated, you
might as well go the whole hog:
java-pkg_func-exists() {
declare -f ${1} /dev/null
}
But then you're wasting time writing all those extra bytes
to /dev/null, so:
java-pkg_func-exists() {
declare -F ${1} /dev/null
}
But wait! $1 and ${1} are the same when they're surrounded by
whitespace. Those bytes are important!
java-pkg_func-exists() {
declare -F $1 /dev/null
}
And we don't need that extra space before the , either:
java-pkg_func-exists() {
declare -F $1/dev/null
}
I hope people can apply these lessons to write much more compact code.
I'm sure we all agree that shorter code is always better, since having
less to read makes things easier to understand.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Small review on function return codes and simplicity
On Tue, Mar 31, 2009 at 11:52 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
What's with that -n thing? If you're going for less complicated, you
might as well go the whole hog:
java-pkg_func-exists() {
declare -f ${1} /dev/null
}
I think this is where we should stop ;)
--
~Nirbheek Chauhan
Re: [gentoo-dev] Please review: prefix.eclass
On 12:59 Fri 27 Mar , Fabian Groffen wrote: This eclass facilitates in some of the needs of the Gentoo Prefix project. For now it provides the 'eprefixify' function, which is often used in Gentoo Prefix ebuilds to incorporate the used offset prefix into files. It's great to see you moving toward folding this back into the main tree! My only comment is that eprefixify could really use a better name because that one sounds really awkward. How about doprefix, or something else? -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpY5oPU5Fyfw.pgp Description: PGP signature
Re: [gentoo-portage-dev] Google SoC and cache sync
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emma Strubell wrote: Hi all. So, I'd love to do Google's Summer of Code with you guys. I was perusing the list of ideas on the Gentoo wiki, and the cache sync idea seems pretty interesting, especially since it concerns the overall speed of portage, including search, which of course I've already started some work on. However, there is no contact person associated with that project! I figured I'd come here before going to #gentoo-soc to see if anyone is interested in mentoring me on this project, since it seemed like a few of you might be interested. The way that I imagine the cache sync idea should be implemented is like paludis's unavailable repository which uses of tarball to distribute package metadata[1]. The tarball approach that they use seems pretty reasonable. However, it would probably also be nice to be able to use a protocol such as rsync to download the metadata/cache/ directory from the same URI which is used to fetch the ebuilds themselves (maybe paludis supports this already, I don't know). In order for the clients to be able to download the metadata/cache/ directory, first that directory has to be populated (as is done on gentoo's master rsync server). I'm currently working on a tool called 'egencache' that overlay maintainers will be able to use in order to populate the metadata/cache/ directory [2]. It will be included in the next portage release. Before we implement something like unavailable repository for portage, first we'll have to add multiple repository support, and that's a decent sized project of it's own. Somebody has mentioned interest in multiple repository support on the gentoo-soc list [3], but they haven't submitted a proposal to http://socghop.appspot.com yet. [1] http://paludis.pioto.org/configuration/repositories/unavailable.html [2] http://bugs.gentoo.org/show_bug.cgi?id=261377 [3] http://archives.gentoo.org/gentoo-soc/msg_e383863a6748e367e13fe53b092f3908.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknSnA4ACgkQ/ejvha5XGaO6tACgjzAsoXP0cJd0Vr1vJxU2CvLQ JtwAn2Sj+GxLyyRpOIdbejPirCljmF2c =k5u1 -END PGP SIGNATURE-
