Re: [gentoo-dev] Gsoc Idea: EeePC Script/Build
Le mercredi 25 mars 2009 à 11:42 -0600, Aaron Lebahn a écrit : Hello, I would like to apply as a student in the Google Summer of Code program. I would like to work on creating a simple method to install Gentoo on an EeePC. This will involve creating scripts and code that will preconfigure the Gentoo instalation to be optimized for the EeePC, and to contain all of the appropriate modules and configurations to enable all hardware on the EeePC. I own an EeePC 900 with which I wil be abe to test. I am uncertain if this or something similar has been done before, or if this is an appropriate Google SOC project. Please give feedback or questions, thankyou. I'm a bit late on this but, by experience (I did it for work a few months ago), creating an eeepc specific gentoo chroot/squashfs is no more than 3 days worth of work with a dual p4 @3ghz (1 week if you're not so familiar with gentoo maybe) so I don't see anything challenging here. Working on enhancing stage builder or stage4 generation (or whatever you name it) would be more interesting for the project as a whole and require much more time which would probably satisfy GSoC objectives. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
Re: [gentoo-dev] bugs.gentoo.org status report, 2009/03/19 10h00 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: The primary Bugzilla webserver is now back in operation. Additionally, for the moment, I've re-enabled the load-balancing, but note that it comes with a warning... Load balanced bugzilla webservers: http://bugs-web-lb.gentoo.org/ (HTTPS supported as well, but the SSL certificate won't match). Visiting either specific side of the webserver nodes: http://bugs-web1.gentoo.org/ http://bugs-web2.gentoo.org/ (The web node you're on is listed on the frontpage only). Caveat: - Why can't we just always use the load-balancer? Unfortunately bugzilla writes a number of files to the local disk and then gives you a URL to them. If the file was written to disk on web1, but your request was delivered to web2, then you would get a 404 error. Robbat, would persistency on loadbalancer level solve this problem ? In that case a tcp-connect that has been build stays with that real-server instance in the loadbalancer, provided that data from the same ip is coming in below a specified timeout. We've used this in the past when we still used disk-based sessions in our webapp. It works well, but can create hotspots in your webfarm if a large percentage of your userbase is behind a single NATed gateway. It would also limit your attacker to a single host. Ramon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknQnNoACgkQwiVM6CtDHQ1zwgCfZfEXwjZ9a0y7mHjq7A5MAxTo HPIAn17SCBu0M71j6UBH8uW+7bVpMUnD =gzHX -END PGP SIGNATURE-
[gentoo-dev] Preserving mtimes for EAPI3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On behalf of the Lisp project (which includes the Emacs subproject) I'd like to
propose that preservation of mtimes be included as a requirement of EAPI3.
An EAPI bump may not be really necessary for this - after all we're just
specifying previously unspecified behavior - but it will help Paludis.
Portage already supports this, and according to my information pkgcore too, but
unfortunately not paludis. More details on the bug mentioned below.
Background:
Dynamic languages such as Common Lisp and Elisp, but also python (and ruby?)
compile source files to some form which loads and executes faster; in Lisp-speak
these are called fasl's (for FASt Load), for python these are the pyc files.
Need for recompilation is determined by comparing the mtimes of the original
source and the fasl. Both source and fasl are usually installed. If the mtimes
are modified such that the fasl is not newer than the original source anymore
then implementations will attempt to recompile these sources and will try to
write the output alongside the sources. This will cause a sandbox violation if
it happens in an ebuild or fail due to permissions when done as a user.
See also:
https://bugs.gentoo.org/264130 PMS should require that file mtimes are
preserved on merge; Gentoo Hosted Projects, PMS/EAPI; NEW;
u...@g.o:pms-b...@g.o
Marijn
- --
Gods do not want you to think, lest they lose existence.
Religions do not want you to think, lest they lose power.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknQ1+wACgkQp/VmCx0OL2yE0QCeJZZJOCFuWY7+6FfnQUCnfFRK
YX0Anj+pGrV+kbkrW6UK2w6FNGF0vBzp
=sjQR
-END PGP SIGNATURE-
[gentoo-dev] Xorg 1.5.3 is going stable
Hi all, This is just a quick announcement to let everyone know that Xorg 1.5.3 and pretty much all X libraries and apps which have been sitting in ~arch for months/years are finally going to go stable, replacing our old, rusty and busted 1.3 X server. Arch Teams have received the final package list just this afternoon. The Upgrade Guide is located at http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml Now, I'm pretty sure there will be a ton of new bugs opened in Bugzilla, so let me thank in advance bug wranglers who will probably deal with dozens of dupes. Thanks to everyone who helped test this release, it saved me a lot of headaches. Cheers Rémi -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org
Re: [gentoo-dev] Preserving mtimes for EAPI3
On Mon, 30 Mar 2009 15:40:14 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: No, an EAPI bump is necessary. Older (post-EAPI) Portage versions do something different, so any ebuild relying upon particular behaviour is already broken. For an example of this, see http://bugs.gentoo.org/264308
[gentoo-dev] EAPI 3's default src_install needs bikeshedding
So far, we've got this, by agreement of the Council:
* There will be a default src_install in EAPI 3
* It will have a DOCS variable, or something along those lines.
I'd like to suggest the following too:
* If DOCS is explicitly specified, it is an error if anything in it
doesn't exist.
* If DOCS isn't explicitly specified, it isn't an error if anything in
its default, if it has one, doesn't exist.
We don't have an implementation yet. So I'll start off with this:
default_src_install() {
emake -j1 DESTDIR=${D} install
local d
if ! declare -p DOCS /dev/null 21 ; then
for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
THANKS BUGS FAQ CREDITS CHANGELOG ; do
[[ -s ${d} ]] dodoc ${d}
done
elif declare -p DOCS | grep -q '^declare -a ' ; then
for d in ${do...@]} ; do
dodoc ${d}
done
else
dodoc ${DOCS}
fi
}
I got the default list by some horrid shell voodoo. Alternatively,
there's the following, which is a lot more comprehensive:
default_src_install() {
emake -j1 DESTDIR=${D} install
emagicdocs
}
emagicdocs() {
done_docs=
old_set=$(shopt | grep 'nocaseglob[[:space:]]*on')
shopt -s nocaseglob
for d in '' ${default_src_install_extra_subdi...@]} ; do
if [[ -n ${d} ]]; then
[[ -d ${d} ]] || die ${d} is not a dir
pushd ${d} /dev/null || die Failed to enter ${d}
local docdesttree=${DOCDESTTREE}
docinto ${d}
fi
for f in README Change{,s,Log} AUTHORS NEWS TODO ABOUT THANKS
{KNOWN_,}BUGS SUBMITTING \
HACKING FAQ CREDITS PKG-INFO HISTORY PACKAGING MAINTAINER{,S}
CONTRIBUT{E,OR,ORS} RELEASE \
ANNOUNCE PORTING NOTES PROBLEMS NOTICE
${default_src_install_extra_do...@]}; do
for p in ${default_src_install_extra_prefix...@]} '' ; do
for doc in ${p}*([[:digit:]])${f}{,+([._-])*} ; do
if [[ -s ${doc} ]] ; then
for e in ${default_src_install_exclu...@]} ; do
[[ ${doc} == ${e} ]] continue 2
done
done_docs=${done_docs} ${d%/}${d:+/}${doc}
dodoc ${doc}
fi
done
done
done
if [[ -n ${d} ]]; then
docinto ${docdesttree}
popd /dev/null || die Failed to leave ${d}
fi
done
if [[ -n ${done_docs} ]] ; then
echo Installed docs ${done_docs# }
else
echo Didn't find any docs to install
fi
[[ -n ${old_set} ]] || shopt -u nocaseglob
}
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
On Mon, 30 Mar 2009 18:33:48 +0200
Thomas Sachau to...@gentoo.org wrote:
Why do you want to force -j1 here?
Because any package using an old automake has a non-parallel-safe
install.
And i had this proposal some months ago, which noone argued against
any more
It, along with the half dozen other variants floating around, are good
starting points, but we need a final solution.
if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ];
Uh, yeah. I forgot about that bit. We need that.
if [ -n ${DOCS} ]; then
dodoc ${DOCS} || die dodoc failed
Spaces... Also, the || die bit for EAPI 3 will be wrong.
else
for x in AUTHORS ChangeLog NEWS README; do
if [ -e ${x} ]; then
Is -e really better than -s?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Preserving mtimes for EAPI3
On Mon, 30 Mar 2009, Peter Alfredsen wrote: No, an EAPI bump is necessary. Older (post-EAPI) Portage versions do something different, so any ebuild relying upon particular behaviour is already broken. For an example of this, see http://bugs.gentoo.org/264308 I would say that is a secondary problem, caused by the package manager not preserving mtimes, and the eclass trying to work around it. Ulrich
Re: [gentoo-dev] Preserving mtimes for EAPI3
On Mon, 30 Mar 2009, Marijn Schouten (hkBst) wrote:
On behalf of the Lisp project (which includes the Emacs subproject)
I'd like to propose that preservation of mtimes be included as a
requirement of EAPI3.
[...]
Background: Dynamic languages such as Common Lisp and Elisp, but
also python (and ruby?) compile source files to some form which
loads and executes faster; in Lisp-speak these are called fasl's
(for FASt Load), for python these are the pyc files. Need for
recompilation is determined by comparing the mtimes of the original
source and the fasl. Both source and fasl are usually installed.
If the mtimes are modified such that the fasl is not newer than
the original source anymore then implementations will attempt to
recompile these sources and will try to write the output alongside
the sources. This will cause a sandbox violation if it happens in
an ebuild or fail due to permissions when done as a user.
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.
Currently, Portage and Pkgcore preserve file modification times when
merging, which doesn't always fulfil b). Paludis updates mtimes, which
breaks a).
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).
Problems remain for packages with pre-compiled files, or for packages
requiring exact mtimes (like ghdl). But I think this affects only very
few packages, and it could be fixed on the ebuild level. For example,
a Lisp package with both *.lisp and precompiled *.fasl could touch its
fasl files at the end of src_install.
I am aware of the fact that we are late for EAPI 3 (partly because I
didn't expect that the change would require an EAPI bump). Question to
the council: is it still possible to include this? Considering that
there is a lot of breakage, as well as strange workarounds related to
the current inconsistent behaviour of package managers.
Ulrich
[gentoo-dev] Small change: Global USE flag nsplugin
Hi, one local USE flag nsplugin only differs slightly from the global one: [- 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? 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] Preserving mtimes for EAPI3
Am Montag, den 30.03.2009, 18:05 +0200 schrieb Peter Alfredsen: On Mon, 30 Mar 2009 15:40:14 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: No, an EAPI bump is necessary. Older (post-EAPI) Portage versions do something different, so any ebuild relying upon particular behaviour is already broken. For an example of this, see http://bugs.gentoo.org/264308 I currently fail to see how mtime preservation is related to this since .py[co] files are generated in pkg_postinst() and therefore not installed by the PM. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
Ciaran McCreesh schrieb am 30.03.2009 18:43:
On Mon, 30 Mar 2009 18:33:48 +0200
Thomas Sachau to...@gentoo.org wrote:
else
for x in AUTHORS ChangeLog NEWS README; do
if [ -e ${x} ]; then
Is -e really better than -s?
I think -s should be used here. I have seen projects out there which
don't use the mandatory autotools files (INSTALL, NEWS, README, AUTHORS,
ChangeLog, COPYING) at all or use other files than these. So they just
place an empty file there to make automake happy instead of using the
--foreign option. Besides that it makes no sense to install empty
documentation files at all.
--
Daniel Pielmeier
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
Daniel Pielmeier wrote:
Ciaran McCreesh schrieb am 30.03.2009 18:43:
On Mon, 30 Mar 2009 18:33:48 +0200
Thomas Sachau to...@gentoo.org wrote:
else
for x in AUTHORS ChangeLog NEWS README; do
if [ -e ${x} ]; then
Is -e really better than -s?
I think -s should be used here. I have seen projects out there which
don't use the mandatory autotools files (INSTALL, NEWS, README, AUTHORS,
ChangeLog, COPYING) at all or use other files than these. So they just
place an empty file there to make automake happy instead of using the
--foreign option. Besides that it makes no sense to install empty
documentation files at all.
portage don't install empty files (they are ignored) so it would be
painless.
Mounir
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
Ciaran McCreesh wrote:
So far, we've got this, by agreement of the Council:
* There will be a default src_install in EAPI 3
* It will have a DOCS variable, or something along those lines.
I'd like to suggest the following too:
* If DOCS is explicitly specified, it is an error if anything in it
doesn't exist.
* If DOCS isn't explicitly specified, it isn't an error if anything in
its default, if it has one, doesn't exist.
We don't have an implementation yet. So I'll start off with this:
default_src_install() {
emake -j1 DESTDIR=${D} install
should have || die where appropriate
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
Ciaran McCreesh wrote: On Mon, 30 Mar 2009 18:33:48 +0200 Thomas Sachau to...@gentoo.org wrote: Why do you want to force -j1 here? Because any package using an old automake has a non-parallel-safe install. I would rather have detection in place for old automake in the build system and not force -j1 there. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Preserving mtimes for EAPI3
Ulrich Mueller wrote: I am aware of the fact that we are late for EAPI 3 (partly because I didn't expect that the change would require an EAPI bump). Question to the council: is it still possible to include this? Considering that there is a lot of breakage, as well as strange workarounds related to the current inconsistent behaviour of package managers. For most features the block is the need for Portage to implement the feature. If I read the thread correctly, Portage already implements what is wanted here so it's just a matter of agreeing on the specification. I don't see any reason not to have something in EAPI 3 if it's specified and implemented in the same time frame as the main driving features of EAPI 3. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
On Mon, 30 Mar 2009 21:07:42 +0300 Petteri Räty betelge...@gentoo.org wrote: should have || die where appropriate It's EAPI 3, so it doesn't need it. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Xorg 1.5.3 is going stable
Hi all, This is just a quick announcement to let everyone know that Xorg 1.5.3 and pretty much all X libraries and apps which have been sitting in ~arch for months/years are finally going to go stable, replacing our old, rusty and busted 1.3 X server. Arch Teams have received the final package list just this afternoon. The Upgrade Guide is located at http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml Now, I'm pretty sure there will be a ton of new bugs opened in Bugzilla, so let me thank in advance bug wranglers who will probably deal with dozens of dupes. Thanks to everyone who helped test this release, it saved me a lot of headaches. Cheers Rémi -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
On Monday March 30 Ciaran McCreesh wrote: It, along with the half dozen other variants floating around, are good starting points, but we need a final solution. Yet another one: how about building/installing the documentation into two separate functions doc_compile and doc_install? It's a bit of overtuning, but it could allow features such re-installing package with switching the doc flag without the need of re-compiling everything, and trivialize the src_install. Going further, we could even define a USE-like variable such as DOC, with a limited spectrum of values e.g. api examples html pdf. -- Sébastien signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
On Mon, 30 Mar 2009 19:19:48 +0100 Sébastien Fabbro bicat...@gentoo.org wrote: It's a bit of overtuning, but it could allow features such re-installing package with switching the doc flag without the need of re-compiling everything, and trivialize the src_install. Anything involving partial recompiles is way beyond what we can get done for EAPI 3. They're a lot harder than one might initially think. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
On Monday 30 March 2009, Thomas Sachau wrote:
Ciaran McCreesh schrieb:
So far, we've got this, by agreement of the Council:
* There will be a default src_install in EAPI 3
* It will have a DOCS variable, or something along those lines.
I'd like to suggest the following too:
* If DOCS is explicitly specified, it is an error if anything in it
doesn't exist.
* If DOCS isn't explicitly specified, it isn't an error if anything
in its default, if it has one, doesn't exist.
We don't have an implementation yet. So I'll start off with this:
default_src_install() {
emake -j1 DESTDIR=${D} install
Why do you want to force -j1 here?
And i had this proposal some months ago, which noone argued against
any more (the default list may of course be extended):
...
What Ciaran added was a way to disable installation of default DOCS. The
implmenetation we discussed on the thread a while ago does not check
whether DOCS is declared but empty.
I believe the way the DOCS variable is handled in the first example of
the thread starter is good for a default_src_install although I don't
know if we really need arrays. But why not? :-)
So what about this funcion for the next EAPI and also implementation
in base.eclass?
Why would you want to implement it in base.eclass when it's in EAPI=3? I
can't think of a case where inherit base would make things easier
than bumping to EAPI=3. In both cases, you might need to change logic
within your ebuild and test it.
Robert
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Xorg 1.5.3 is going stable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rémi Cardona wrote: Hi all, This is just a quick announcement to let everyone know that Xorg 1.5.3 and pretty much all X libraries and apps which have been sitting in ~arch for months/years are finally going to go stable, replacing our old, rusty and busted 1.3 X server. Arch Teams have received the final package list just this afternoon. The Upgrade Guide is located at http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml perhaps you made a typo did you meant INPUT_DEVICES=evdev instead of INPUT_DRIVER=evdev, isn't it? bye - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknRLIIACgkQV/B5axfzrPvrgwCeJkfiypY9cO/i/LTTDh0Bjxjj cqcAn0DWEUIK9ftCstJFDZMr3NlA/NKH =6qxR -END PGP SIGNATURE-
[gentoo-dev] Request for Willikins
Hi, we'd like to have Willikins join #gentoo.de, so here's my official request :) Thanks in advance. (This is a -nomail subscription, you'll have to CC me.) Stefan (stkn @ #gentoo.de)
Re: [gentoo-dev] Request for Willikins
Stefan Knoblich schrieb: Hi, we'd like to have Willikins join #gentoo.de, so here's my official request :) Thanks in advance. (This is a -nomail subscription, you'll have to CC me.) Stefan (stkn @ #gentoo.de) ok from me for this request. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: bzr.eclass: The next level (this time with patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Faulhammer schrieb: Hi, René 'Necoro' Neumann li...@necoro.eu: So I'd vote for switching back to using normal checkouts (or branches - they don't really differ in bzr for that matter). My tests with Bazaar 1.13.1 show roughly the same time with and without --lightweight. Although I am not sure what you mean by export vs. fetch. fetch: bzr branch / bzr co export: bzr export And depending on the type of the repository, the export will take different times. And I see the export as quite important, as the number of exports is at least as high as the number of fetches. Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknRP2AACgkQ4UOg/zhYFuBunwCfQG03AEruswY0UX39LTL6jmmt ZWsAn06PRrCHaGMzoIneRVPLwzzYxrb2 =C9GU -END PGP SIGNATURE-
Re: [gentoo-dev] Preserving mtimes for EAPI3
On Mon, 30 Mar 2009, Petteri Räty wrote:
For most features the block is the need for Portage to implement the
feature. If I read the thread correctly, Portage already implements
what is wanted here so it's just a matter of agreeing on the
specification.
Not completely. Portage preserves modification times already when
merging, but if we make updating of old timestamps mandatory (as
Ciaran has suggested), then this part is still missing in Portage.
But as far as I can see, something along the lines of the following
two commands [1] should be all that is needed:
find ${D} -type f \( -newermt @${stamp1} -o -print0 \) \
| ${XARGS} -0 touch -c -d @${stamp1}
find ${D} -type f -newermt @${stamp2} -print0 \
| ${XARGS} -0 touch -c -d @${stamp2}
Variables stamp1 and stamp2 would be assigned from $(date -u +%s)
before pkg_setup and after src_install, respectively.
The second find command is sort of redundant, since it shouldn't
happen that ${D} contains files with timestamps from the future.
Maybe it's better to emit a warning in this case.
Ulrich
[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.
[gentoo-dev] Re: Preserving mtimes for EAPI3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ulrich Mueller wrote:
But as far as I can see, something along the lines of the following
two commands [1] should be all that is needed:
find ${D} -type f \( -newermt @${stamp1} -o -print0 \) \
| ${XARGS} -0 touch -c -d @${stamp1}
find ${D} -type f -newermt @${stamp2} -print0 \
| ${XARGS} -0 touch -c -d @${stamp2}
Variables stamp1 and stamp2 would be assigned from $(date -u +%s)
before pkg_setup and after src_install, respectively.
The second find command is sort of redundant, since it shouldn't
happen that ${D} contains files with timestamps from the future.
Maybe it's better to emit a warning in this case.
Ulrich
[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.
Personally, I would use
find ${D} -type f \! -newermt @${stamp1} -exec \
touch -c -d @${stamp1} {} +
and
find ${D} -type f -newermt @${stamp2} -exec \
touch -c -d @${stamp2} {} +
to avoid an unneeded call to xargs.
Just my USD0.02,
- --
ABCD
(and the bikeshed shall be BLUE)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknRXQIACgkQOypDUo0oQOo9DwCeJ3O/cnVo2HIc2J88jSj/C1Tc
50kAoI+slGgo2M+ghs2j+awOrrCXyuEl
=c5R7
-END PGP SIGNATURE-
[gentoo-dev] Re: Preserving mtimes for EAPI3
On Mon, 30 Mar 2009, ABCD wrote:
Personally, I would use
find ${D} -type f \! -newermt @${stamp1} -exec \
touch -c -d @${stamp1} {} +
and
find ${D} -type f -newermt @${stamp2} -exec \
touch -c -d @${stamp2} {} +
to avoid an unneeded call to xargs.
Right. And it can be done in one command:
find ${D} -type f \
\( \! -newermt @${stamp1} -exec touch -c -d @${stamp1} {} + \
-o -newermt @${stamp2} -exec touch -c -d @${stamp2} {} + \)
Ulrich
[gentoo-portage-dev] Recommendation about faster (not smaller) filesystem and blocksize combination for portage tree
Hello I am trying to know what filesystem+blocksize combination could be better for the kind of files stored in portage tree. In the past, I have been using reiserfs for my / partition and I had /usr/portage under it. Later, I moved /usr/portage to a different partition (distfiles go to a different directory) and switched it to ext2 (as, in theory, ext2 should be faster as has no journaling) and 2048 as blocksize (that, of course, shrinks portage tree sizes but I am unsure about its effects from a performance point of view) Of course, I am not asking you for benchmarks or something else, I am simply asking for your opinions about what would be better combination from a performance point of view of filesystem+blocksize (or, at least, what blocksize would be better for speed, I can test filesystems later based on it) Thanks a lot for your recommendations :-)
[gentoo-portage-dev] Re: Recommendation about faster (not smaller) filesystem and blocksize combination for portage tree
Pacho Ramos pa...@condmat1.ciencias.uniovi.es posted 1238412618.18113.15.ca...@localhost, excerpted below, on Mon, 30 Mar 2009 13:30:18 +0200: I am trying to know what filesystem+blocksize combination could be better for the kind of files stored in portage tree. In the past, I have been using reiserfs for my / partition and I had /usr/portage under it. Later, I moved /usr/portage to a different partition (distfiles go to a different directory) and switched it to ext2 (as, in theory, ext2 should be faster as has no journaling) and 2048 as blocksize (that, of course, shrinks portage tree sizes but I am unsure about its effects from a performance point of view) You are aware of the various reiserfs mount options, including notail and nolog, right? See the mount manpage. reiserfs was tuned for small files, but these may speed it up even further. Other than that, much as I could suggest all sorts of stuff (like PORTAGE_TMPDIR as tmpfs, will probably make more of a difference if you have a decent amount of memory), I'll point you to the user forums and list as more appropriate. This list is really for discussion of portage and portage related development, not so much user portage speed tips, but ask in the user list and forums and you'll surely get all sorts of info! =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
