Re: [gentoo-dev] Please review: prefix.eclass

[Donnie Berkholz]

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-dev] RFC: EAPI cheat sheet for your desktop

[Ferris McCormick]

On Tue, 2009-03-31 at 19:21 +0200, Christian Faulhammer wrote:
> 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 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

I like it.  It's useful to me, at least, and I like having this
information available where I can find it in case I need it.

Regards,
Ferris

-- 
Ferris McCormick (P44646, MI) 
Developer, Gentoo Linux (Sparc, Userrel, Trustees)


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

Re: [gentoo-dev] Small review on function return codes and simplicity

[Alec Warner]

On Tue, Mar 31, 2009 at 11:05 AM, Donnie Berkholz  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:

Also worst feature ever, Ruby does it too and it sucks :)

>
> 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
>

Re: [gentoo-dev] Small review on function return codes and simplicity

[Donnie Berkholz]

On 19:22 Tue 31 Mar , Ciaran McCreesh wrote:
> On Tue, 31 Mar 2009 11:05:30 -0700
> Donnie Berkholz  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.

Thanks for your valuable contribution of sarcasm. It's guaranteed to 
give everyone a happy day.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgpUNeBfOopfI.pgp
Description: PGP signature

Re: [gentoo-dev] Small review on function return codes and simplicity

[Nirbheek Chauhan]

On Tue, Mar 31, 2009 at 11:52 PM, Ciaran McCreesh
 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] Small review on function return codes and simplicity

[Ciaran McCreesh]

On Tue, 31 Mar 2009 11:05:30 -0700
Donnie Berkholz  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

[gentoo-dev] Small review on function return codes and simplicity

[Donnie Berkholz]

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] sandbox-1.7 and static binaries

[Donnie Berkholz]

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] RFC: EAPI cheat sheet for your desktop

[Christian Faulhammer]

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 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
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

http://gentoo.faulhammer.org/>


signature.asc
Description: PGP signature

[gentoo-dev] Re: Preserving mtimes for EAPI3

[Ulrich Mueller]

> 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] sandbox-1.7 and static binaries

[Mike Frysinger]

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.

Re: [gentoo-dev] Request for Willikins

[Raúl Porcel]

I'd like to have willikins on #gentoo-openmoko

Contact: armin76

[gentoo-dev] Re: Preserving mtimes for EAPI3

[ABCD]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Timothy Redaelli wrote:
> On Tuesday 31 March 2009 00:59:57 Ulrich Mueller wrote:
> 
>> [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-

Re: [gentoo-dev] Xorg 1.5.3 is going stable

[Rémi Cardona]

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] Xorg 1.5.3 is going stable

[Simon C. Ion]

-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] Re: Small change: Global USE flag nsplugin

[Jan Kundrát]

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] Preserving mtimes for EAPI3

[Michael Haubenwallner]

On Mon, 2009-03-30 at 19:14 +0200, Ulrich Mueller wrote:

> I'll try to summarise the current state of discussion in
> . 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] Preserving mtimes for EAPI3

[Timothy Redaelli]

On Tuesday 31 March 2009 00:59:57 Ulrich Mueller wrote:

> [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] EAPI 3's default src_install needs bikeshedding

[Daniel Pielmeier]

2009/3/30 Mounir Lamouri :
>
> 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

[gentoo-dev] Re: Small change: Global USE flag nsplugin

[Christian Faulhammer]

Hi,

Ben de Groot :

> 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
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

http://www.faulhammer.org/>


signature.asc
Description: PGP signature