[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/baselayout: baselayout-2.0.0_rc4-r1.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Robin H. Johnson wrote:
> On Wed, Sep 26, 2007 at 06:41:50AM +, Mike Frysinger (vapier) wrote:
> > -   if [[ -f "${ROOT}/etc/conf.d/$1" ]]; then
> > +   if [[ -f ${ROOT}/etc/conf.d/$1 ]]; then
>
> You removed the quotes here - $ROOT with spaces?

same as your other comments, irrelevant ... [[ ]] handles things properly

> > -   for f in ${ROOT}etc/init.d/net.*; do
> > -   [[ -L ${f} || ${f} == "${ROOT}etc/init.d/${lo}" ]] && continue
> > +   for f in "${ROOT}"etc/init.d/net.*; do
> > +   [[ -L ${f} || ${f} == */${lo} ]] && continue
>
> Again the quotes, and that conditional looks iffy, it was checking
> against ${ROOT}/etc/init.d/net.lo before, and now it's checking against
> ${PWD}/*/net.lo?

where do you see $PWD ?  i see a simple string match
-mike


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

Re: [gentoo-dev] new old eclass - wxwidgets.eclass

[Donnie Berkholz]

On 21:14 Mon 24 Sep , Ryan Hill wrote:
> - is the stuff in global scope kosher?  i've seen other eclasses do
> similar, but i want to be sure.  the reason for the looping is because
> i figure calling built_with_use in global would get me hung.

>   for wxtoolkit in gtk2 base; do
>   debug-print "global outer loop - wxtoolkit is ${wxtoolkit}"
>   for wxdebug in release debug; do
>   debug-print "global inner loop - wxdebug is ${wxdebug}"
>   wxconf="${wxtoolkit}-${wxchar}-${wxdebug}-${WX_GTK_VER}"
>   debug-print "testing for config ${wxconf}"
>   [[ -f /usr/$(get_libdir)/wx/config/${wxconf} ]] || 
> continue

Checking for existence of files in global scope?

>   debug-print "found config ${wxconf} - setting WX_CONFIG"
>   WX_CONFIG="/usr/$(get_libdir)/wx/config/${wxconf}"
>   # TODO: needed for the wx-config wrapper
>   #WX_ECLASS_CONFIG="${WX_CONFIG}"
>   break
>   done
>   [[ -n ${WX_CONFIG} ]] && break
>   done
>   [[ -n ${WX_CONFIG} ]] && export WX_CONFIG #WX_ECLASS_CONFIG

OK, so let me try to follow the logic of preferences here:

1. gtk2-release
2. gtk2-debug
3. base-release
4. base-debug

Does that mean they can't get a debug setup if the release one is found? 
Does a debug build only produce debug and not release?

> else
>   :
> fi

What's up with the 'else' here?

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-servers/nginx: ChangeLog nginx-0.6.13.ebuild nginx-0.6.12.ebuild

[Donnie Berkholz]

On 07:16 Tue 25 Sep , Konstantin Arkhipov (voxus) wrote:
> voxus   07/09/25 07:16:42
> 
>   Modified: ChangeLog
>   Added:nginx-0.6.13.ebuild
>   Removed:  nginx-0.6.12.ebuild
>   Log:
>   * bump
>   (Portage version: 2.1.3.9)

> 1.1  www-servers/nginx/nginx-0.6.13.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/www-servers/nginx/nginx-0.6.13.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/www-servers/nginx/nginx-0.6.13.ebuild?rev=1.1&content-type=text/plain

>   use fastcgi || myconf="${myconf} --without-http_fastcgi_module"
>   use fastcgi && myconf="${myconf} --with-http_realip_module"
>   use flv && myconf="${myconf} --with-http_flv_module"
>   use zlib|| myconf="${myconf} --without-http_gzip_module"
>   use pcre|| {
>   myconf="${myconf} --without-pcre --without-http_rewrite_module"
>   }
>   use debug   && myconf="${myconf} --with-debug"
>   use ssl && myconf="${myconf} --with-http_ssl_module"
>   use imap&& myconf="${myconf} --with-imap" # pop3/imap4 proxy 
> support
>   use perl&& myconf="${myconf} --with-http_perl_module"
>   use status  && myconf="${myconf} --with-http_stub_status_module"
>   use webdav  && myconf="${myconf} --with-http_dav_module"

I take it that, for some obscure reason, use_with() doesn't work?

>   if [ ! -f /etc/ssl/${PN}/${PN}.key ]; then

Are you looking at the live root here, in a src_* function?

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in gnome-base/gconf: ChangeLog gconf-2.20.0.ebuild

[Donnie Berkholz]

On 18:29 Tue 25 Sep , Daniel Gryniewicz (dang) wrote:
> dang07/09/25 18:29:56
> 
>   Modified: ChangeLog
>   Added:gconf-2.20.0.ebuild
>   Log:
>   New series for Gnome 2.20
>   (Portage version: 2.1.3.9)

> 1.1  gnome-base/gconf/gconf-2.20.0.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/gnome-base/gconf/gconf-2.20.0.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/gnome-base/gconf/gconf-2.20.0.ebuild?rev=1.1&content-type=text/plain

> pkg_postinst() {
>   kill_gconf
> 
>   #change the permissions to avoid some gconf bugs
>   einfo "changing permissions for gconf dirs"
>   find  /etc/gconf/ -type d -exec chmod ugo+rx "{}" \;
> 
>   einfo "changing permissions for gconf files"
>   find  /etc/gconf/ -type f -exec chmod ugo+r "{}" \;
> }
> 
> kill_gconf() {
>   # this function will kill all running gconfd that could be causing 
> troubles
>   if [ -x /usr/bin/gconftool ]
>   then
>   /usr/bin/gconftool --shutdown
>   fi
>   if [ -x /usr/bin/gconftool-1 ]
>   then
>   /usr/bin/gconftool-1 --shutdown
>   fi
> 
>   # and for gconf 2
>   if [ -x /usr/bin/gconftool-2 ]
>   then
>   /usr/bin/gconftool-2 --shutdown
>   fi
>   return 0
> }

This stuff is broken with $ROOT.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sci-mathematics/freemat: ChangeLog freemat-3.5.ebuild

[Donnie Berkholz]

On 19:27 Tue 25 Sep , Sebastien Fabbro (bicatali) wrote:
> bicatali07/09/25 19:27:56
> 
>   Modified: ChangeLog
>   Added:freemat-3.5.ebuild
>   Log:
>   Version bump.
>   (Portage version: 2.1.3.9)

> pkg_postint() {
>   einfo "Initializing freemat data directory"
>   FreeMat -i /usr/share/${MY_P}
> }

This is broken with $ROOT != /.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/gimp-help: ChangeLog gimp-help-0.13.ebuild

[Donnie Berkholz]

On 03:01 Wed 26 Sep , Hanno Boeck (hanno) wrote:
> hanno   07/09/26 03:01:24
> 
>   Modified: ChangeLog
>   Added:gimp-help-0.13.ebuild
>   Log:
>   gimp-help version bump
>   (Portage version: 2.1.3.9)

> 1.1  app-doc/gimp-help/gimp-help-0.13.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-doc/gimp-help/gimp-help-0.13.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-doc/gimp-help/gimp-help-0.13.ebuild?rev=1.1&content-type=text/plain

>   local ALL_LINGUAS=""
> 
>   use linguas_cs && ALL_LINGUAS="${ALL_LINGUAS} cs"
>   use linguas_de && ALL_LINGUAS="${ALL_LINGUAS} de"
>   use linguas_en && ALL_LINGUAS="${ALL_LINGUAS} en"
>   use linguas_es && ALL_LINGUAS="${ALL_LINGUAS} es"
>   use linguas_fr && ALL_LINGUAS="${ALL_LINGUAS} fr"
>   use linguas_hr && ALL_LINGUAS="${ALL_LINGUAS} hr"
>   use linguas_it && ALL_LINGUAS="${ALL_LINGUAS} it"
>   use linguas_ko && ALL_LINGUAS="${ALL_LINGUAS} ko"
>   use linguas_nl && ALL_LINGUAS="${ALL_LINGUAS} nl"
>   use linguas_no && ALL_LINGUAS="${ALL_LINGUAS} no"
>   use linguas_ru && ALL_LINGUAS="${ALL_LINGUAS} ru"
>   use linguas_sv && ALL_LINGUAS="${ALL_LINGUAS} sv"
>   use linguas_zh_CN && ALL_LINGUAS="${ALL_LINGUAS} zh_CN"

I might define a custom function here to reduce duplication and increase 
readability.

use_linguas() {
local lingua=$1
use linguas_${lingua} && ALL_LINGUAS="${ALL_LINGUAS} ${lingua}"
}

And then..

use_linguas de
use_linguas en
...

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openswan: ChangeLog openswan-2.4.9-r1.ebuild openswan-2.4.9.ebuild

[Donnie Berkholz]

On 08:14 Wed 26 Sep , Alin Nastac (mrness) wrote:
> mrness  07/09/26 08:14:22
> 
>   Modified: ChangeLog
>   Added:openswan-2.4.9-r1.ebuild
>   Removed:  openswan-2.4.9.ebuild
>   Log:
>   Fix erroneous creation of rundir and subsysdir (#193824). Sanitize the 
> ebuild code.
>   (Portage version: 2.1.2.12)

> 1.1  net-misc/openswan/openswan-2.4.9-r1.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/openswan/openswan-2.4.9-r1.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/openswan/openswan-2.4.9-r1.ebuild?rev=1.1&content-type=text/plain

> pkg_setup() {
>   linux-info_pkg_setup
> 
>   if kernel_is 2 6; then
>   einfo "This ebuild will set ${P} to use 2.6 native IPsec 
> (KAME)."
>   einfo "KLIPS will not be compiled/installed."
>   MYMAKE="programs"
> 
>   elif kernel_is 2 4; then
>   if ! [ -d /usr/src/linux/net/ipsec ]; then

This isn't ROOT-safe.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in www-apps/dspam-web: dspam-web-3.8.0.ebuild ChangeLog

[Steve Long]

Mike Frysinger wrote:

> On Monday 24 September 2007, Donnie Berkholz wrote:
>>
>> You could use C-style syntax here:
>>
>> (( use_errors++ ))
>>
>> I find it a bit more readable.
> 
> i like to get anal and use ((++use_errors))
> 
> then again, it may also be more readable like so:
> use_errors=false
> if ... ; then
> ...
> use_errors=true
> fi
> if ... ; then
> ...
> use_errors=true
> fi
> ${use_errors} && die "..."
> -mike

Integer arithmetic is generally quicker:
((use_errors++)) [or: use_errors=1 ]
..
((use_errors)) && die 'meh'
 -- although true and false are builtins in this case.
For stuff like for ((i=0;i1)) && echo blah

It's handy as unset vars test to false, and also as the usual boolean values
apply, ie 0 is false, anything else is true. (Outside this context 0 is
true [success from cmd] and anything else is false [error code].) And ofc,
you don't need to put $ in front of your standard variables in this
context.

[1] http://wooledge.org/mywiki/ArithmeticExpression


-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openswan: ChangeLog openswan-2.4.9-r1.ebuild openswan-2.4.9.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Donnie Berkholz wrote:
> On 08:14 Wed 26 Sep , Alin Nastac (mrness) wrote:
> > mrness  07/09/26 08:14:22
> >
> >   Modified: ChangeLog
> >   Added:openswan-2.4.9-r1.ebuild
> >   Removed:  openswan-2.4.9.ebuild
> >   Log:
> >   Fix erroneous creation of rundir and subsysdir (#193824). Sanitize the
> > ebuild code. (Portage version: 2.1.2.12)
> >
> > 1.1  net-misc/openswan/openswan-2.4.9-r1.ebuild
> >
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/openswan/openswa
> >n-2.4.9-r1.ebuild?rev=1.1&view=markup plain:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/openswan/openswa
> >n-2.4.9-r1.ebuild?rev=1.1&content-type=text/plain
> >
> > pkg_setup() {
> > linux-info_pkg_setup
> >
> > if kernel_is 2 6; then
> > einfo "This ebuild will set ${P} to use 2.6 native IPsec 
> > (KAME)."
> > einfo "KLIPS will not be compiled/installed."
> > MYMAKE="programs"
> >
> > elif kernel_is 2 4; then
> > if ! [ -d /usr/src/linux/net/ipsec ]; then
>
> This isn't ROOT-safe.

it should be using the vars from the linux eclasses anyways ...
-mike


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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/gimp-help: ChangeLog gimp-help-0.13.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Donnie Berkholz wrote:
> On 03:01 Wed 26 Sep , Hanno Boeck (hanno) wrote:
> > hanno   07/09/26 03:01:24
> >
> >   Modified: ChangeLog
> >   Added:gimp-help-0.13.ebuild
> >   Log:
> >   gimp-help version bump
> >   (Portage version: 2.1.3.9)
> >
> > 1.1  app-doc/gimp-help/gimp-help-0.13.ebuild
> >
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-doc/gimp-help/gimp-he
> >lp-0.13.ebuild?rev=1.1&view=markup plain:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-doc/gimp-help/gimp-he
> >lp-0.13.ebuild?rev=1.1&content-type=text/plain
> >
> > local ALL_LINGUAS=""
> >
> > use linguas_cs && ALL_LINGUAS="${ALL_LINGUAS} cs"
> > use linguas_de && ALL_LINGUAS="${ALL_LINGUAS} de"
> > use linguas_en && ALL_LINGUAS="${ALL_LINGUAS} en"
> > use linguas_es && ALL_LINGUAS="${ALL_LINGUAS} es"
> > use linguas_fr && ALL_LINGUAS="${ALL_LINGUAS} fr"
> > use linguas_hr && ALL_LINGUAS="${ALL_LINGUAS} hr"
> > use linguas_it && ALL_LINGUAS="${ALL_LINGUAS} it"
> > use linguas_ko && ALL_LINGUAS="${ALL_LINGUAS} ko"
> > use linguas_nl && ALL_LINGUAS="${ALL_LINGUAS} nl"
> > use linguas_no && ALL_LINGUAS="${ALL_LINGUAS} no"
> > use linguas_ru && ALL_LINGUAS="${ALL_LINGUAS} ru"
> > use linguas_sv && ALL_LINGUAS="${ALL_LINGUAS} sv"
> > use linguas_zh_CN && ALL_LINGUAS="${ALL_LINGUAS} zh_CN"
>
> I might define a custom function here to reduce duplication and increase
> readability.
>
> use_linguas() {
>   local lingua=$1
>   use linguas_${lingua} && ALL_LINGUAS="${ALL_LINGUAS} ${lingua}"
> }
>
> And then..
>
> use_linguas de
> use_linguas en
> ...

nice ... and to take it a step further:
for l in de en ... ; do use_linguas ${l} ; done
-mike


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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/gimp-help: ChangeLog gimp-help-0.13.ebuild

[Donnie Berkholz]

On 04:36 Wed 26 Sep , Mike Frysinger wrote:
> On Wednesday 26 September 2007, Donnie Berkholz wrote:
> > I might define a custom function here to reduce duplication and increase
> > readability.
> >
> > use_linguas() {
> > local lingua=$1
> > use linguas_${lingua} && ALL_LINGUAS="${ALL_LINGUAS} ${lingua}"
> > }
> >
> > And then..
> >
> > use_linguas de
> > use_linguas en
> > ...
> 
> nice ... and to take it a step further:
> for l in de en ... ; do use_linguas ${l} ; done

And a step farther than that... =)

for USE in ${IUSE}; do
[[ ${USE} = linguas_* ]] && use_linguas ${USE}
done

with a slightly different definition of use_linguas(). The benefit of 
this is that you only need to define the available languages in one 
place, so you don't need to worry about them getting out of sync. It 
would be a little more elegant if you had IUSE_LINGUAS, which was then 
included in IUSE, so you didn't need to do that test.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-dotnet/libgdiplus: ChangeLog libgdiplus-1.2.5-r1.ebuild

[Steve Long]

Bo Ørsted Andresen wrote:

> On Monday 24 September 2007 21:56:49 Donnie Berkholz wrote:
>> > if [[ "$(gcc-major-version)" -gt "3" ]] || \
>> > ( [[ "$(gcc-major-version)" -eq "3" ]] && [[ "$(gcc-minor-version)" -gt
>> > "3" ]] )
>>
>> Code block { } might be good here instead of a subshell, or perhaps it
>> could use logic that's less convoluted such as if..then. Also don't need
>> the double quotes.
> 
> Or it could be as simple as:
> 
> if [[ $(gcc-major-version) -gt 3 || \
> ( $(gcc-major-version) -eq 3 && $(gcc-minor-version) -gt 3 ) ]]
> 
> [[ allows grouping of conditions without spawning subshells.
> 
http://wooledge.org/mywiki/BashFAQ#faq31 explains the differences between [[
and [, although in this case I'd use:
if ((gcc-major-version>3 || (gcc-major-version==3 && gcc-minor-version>3) ))

"As a rule of thumb, [[ is used for strings and files. If you want to
compare numbers, use an ArithmeticExpression."


-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/gimp-help: ChangeLog gimp-help-0.13.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Donnie Berkholz wrote:
> On 04:36 Wed 26 Sep , Mike Frysinger wrote:
> > On Wednesday 26 September 2007, Donnie Berkholz wrote:
> > > I might define a custom function here to reduce duplication and
> > > increase readability.
> > >
> > > use_linguas() {
> > >   local lingua=$1
> > >   use linguas_${lingua} && ALL_LINGUAS="${ALL_LINGUAS} ${lingua}"
> > > }
> > >
> > > And then..
> > >
> > > use_linguas de
> > > use_linguas en
> > > ...
> >
> > nice ... and to take it a step further:
> > for l in de en ... ; do use_linguas ${l} ; done
>
> And a step farther than that... =)

even nicer

> for USE in ${IUSE}; do
>   [[ ${USE} = linguas_* ]] && use_linguas ${USE}
> done

you dont want to use the variable 'USE' ... while it would work correctly if 
you declared it with 'local', it'd be confusing and repoman may just barf on 
it ($USE is supposed to be readonly for ebuilds)
-mike


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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/gimp-help: ChangeLog gimp-help-0.13.ebuild

[Donnie Berkholz]

On 04:51 Wed 26 Sep , Mike Frysinger wrote:
> On Wednesday 26 September 2007, Donnie Berkholz wrote:
> > for USE in ${IUSE}; do
> > [[ ${USE} = linguas_* ]] && use_linguas ${USE}
> > done
> 
> you dont want to use the variable 'USE' ... while it would work 
> correctly if you declared it with 'local', it'd be confusing and 
> repoman may just barf on it ($USE is supposed to be readonly for 
> ebuilds)

Ahh, reviewing is so fun and educational, it almost feels like I'm 
watching the Discovery channel. Although I'm not sure why $USE is 
directly accessible from ebuilds ... seems like it should only be 
accessible to use(). Implementation detail, or should it be part of the 
PMS?

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openswan: ChangeLog openswan-2.4.9-r1.ebuild openswan-2.4.9.ebuild

[Alin Năstac]

Mike Frysinger wrote:
> On Wednesday 26 September 2007, Donnie Berkholz wrote:
>   
>> On 08:14 Wed 26 Sep , Alin Nastac (mrness) wrote:
>> 
>>> mrness  07/09/26 08:14:22
>>>
>>>   Modified: ChangeLog
>>>   Added:openswan-2.4.9-r1.ebuild
>>>   Removed:  openswan-2.4.9.ebuild
>>>   Log:
>>>   Fix erroneous creation of rundir and subsysdir (#193824). Sanitize the
>>> ebuild code. (Portage version: 2.1.2.12)
>>>
>>> 1.1  net-misc/openswan/openswan-2.4.9-r1.ebuild
>>>
>>> file :
>>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/openswan/openswa
>>> n-2.4.9-r1.ebuild?rev=1.1&view=markup plain:
>>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/openswan/openswa
>>> n-2.4.9-r1.ebuild?rev=1.1&content-type=text/plain
>>>
>>> pkg_setup() {
>>> linux-info_pkg_setup
>>>
>>> if kernel_is 2 6; then
>>> einfo "This ebuild will set ${P} to use 2.6 native IPsec 
>>> (KAME)."
>>> einfo "KLIPS will not be compiled/installed."
>>> MYMAKE="programs"
>>>
>>> elif kernel_is 2 4; then
>>> if ! [ -d /usr/src/linux/net/ipsec ]; then
>>>   
>> This isn't ROOT-safe.
>> 
>
> it should be using the vars from the linux eclasses anyways ...
> -mike
>   
fixed in cvs. thanks!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-servers/nginx: ChangeLog nginx-0.6.13.ebuild nginx-0.6.12.ebuild

[Natanael Copa]

On Wed, 2007-09-26 at 00:43 -0700, Donnie Berkholz wrote:
> On 07:16 Tue 25 Sep , Konstantin Arkhipov (voxus) wrote:
> > voxus   07/09/25 07:16:42
> > 
> I take it that, for some obscure reason, use_with() doesn't work?
> 
> > if [ ! -f /etc/ssl/${PN}/${PN}.key ]; then
> 
> Are you looking at the live root here, in a src_* function?

Certs and keys shouldn't be generated in src_* at all since you would
ship the private key in binary packets.

Do it in pkg_postinst() if you have to.

-nc

-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/baselayout: ChangeLog baselayout-1.12.10-r5.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Christian Faulhammer wrote:
> "Mike Frysinger (vapier)" <[EMAIL PROTECTED]>:
> >   Added:baselayout-1.12.10-r5.ebuild

i've cleaned up the latest baselayout-2 ebuild since baselayout-1 is on the 
way out
-mike


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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/gimp-help: ChangeLog gimp-help-0.13.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Donnie Berkholz wrote:
> On 04:51 Wed 26 Sep , Mike Frysinger wrote:
> > On Wednesday 26 September 2007, Donnie Berkholz wrote:
> > > for USE in ${IUSE}; do
> > >   [[ ${USE} = linguas_* ]] && use_linguas ${USE}
> > > done
> >
> > you dont want to use the variable 'USE' ... while it would work
> > correctly if you declared it with 'local', it'd be confusing and
> > repoman may just barf on it ($USE is supposed to be readonly for
> > ebuilds)
>
> Ahh, reviewing is so fun and educational, it almost feels like I'm
> watching the Discovery channel. Although I'm not sure why $USE is
> directly accessible from ebuilds ... seems like it should only be
> accessible to use(). Implementation detail, or should it be part of the
> PMS?

if it's all common shell, it's pretty hard to hide ... you could try some 
tricks like rewriting USE to __USE__ so internal code (like the `use` 
function) still work, but in the end, does that really help ?
-mike


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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/gimp-help: ChangeLog gimp-help-0.13.ebuild

[Donnie Berkholz]

On 05:14 Wed 26 Sep , Mike Frysinger wrote:
> if it's all common shell, it's pretty hard to hide ... you could try some 
> tricks like rewriting USE to __USE__ so internal code (like the `use` 
> function) still work, but in the end, does that really help ?

I think so. It explicitly says that's private and not part of the API, 
and it makes accidental overwrites much more unlikely.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in media-tv/linuxtv-dvb-apps: ChangeLog linuxtv-dvb-apps-1.1.1.20070924.ebuild

[Steve Long]

Robert Buchholz wrote:

> On Tuesday, 25. September 2007, Donnie Berkholz wrote:
>> On 20:04 Mon 24 Sep , Doug Goldstein (cardoe) wrote:
>> > if ! use usb; then
>> > sed -i util/Makefile \
>> > -e '/ttusb_dec_reset/d' \
>> > -e '/dib3000-watch/d'
>> > fi
>> >
>> > # do not compile test-progs
>> > sed -i Makefile -e '/-C test/d'
>>
>> You might want to die if these seds fail.
> 
> I already wondered a while back:
> sed only fails if the file does not exist, but not if there was no
> replacement. Is there any way to force it to?
> 
ed will exit with an error if a regex doesn't match:
ed -s util/Makefile <<< 'H
/ttusb_dec_reset/d
/dib3000-watch/d
w
q' || die 'ohNoes!'

I prefer to mute errors in an ebuild (after testing):
ed -s Makefile 2>/dev/null <<< $'/-C test/d\nw\nq' \
|| die 'No match in Makefile'
..which I think is a lot easier to grok than the sed convolutions.
If it's supposed to be deleting every line with that regex (as the sed
currently does) I'd use: $'g/-C test/d\nw\nq'

I appreciate that ed seems hard (man ed is frightening!) but once you get
used to here-strings (and $' expansion) it's a doddle. (Use ,p instead of w
to see the output during testing.)
Tutorial: http://bash-hackers.org/wiki/doku.php?id=howto:edit-ed
Easier man page: http://plan9.bell-labs.com/magic/man2html/1/ed
Reference: http://www.opengroup.org/onlinepubs/009695399/utilities/ed.html

(I very much recommend that opengroup site as it outlines what a scripwriter
or programmer can expect on any POSIX/SuS compliant system.)


-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-dotnet/libgdiplus: ChangeLog libgdiplus-1.2.5-r1.ebuild

[Steve Long]

Steve Long wrote:

> Bo Ørsted Andresen wrote:
> 
>> On Monday 24 September 2007 21:56:49 Donnie Berkholz wrote:
>>> > if [[ "$(gcc-major-version)" -gt "3" ]] || \
>>> > ( [[ "$(gcc-major-version)" -eq "3" ]] && [[ "$(gcc-minor-version)"
>>> > -gt "3" ]] )
>>>
>>> Code block { } might be good here instead of a subshell, or perhaps it
>>> could use logic that's less convoluted such as if..then. Also don't need
>>> the double quotes.
>> 
>> Or it could be as simple as:
>> 
>> if [[ $(gcc-major-version) -gt 3 || \
>> ( $(gcc-major-version) -eq 3 && $(gcc-minor-version) -gt 3 ) ]]
>> 
>> [[ allows grouping of conditions without spawning subshells.
>> 
> http://wooledge.org/mywiki/BashFAQ#faq31 explains the differences between
> [[ and [, although in this case I'd use:
> if ((gcc-major-version>3 || (gcc-major-version==3 && gcc-minor-version>3)
> ))
> 
> "As a rule of thumb, [[ is used for strings and files. If you want to
> compare numbers, use an ArithmeticExpression."
> 
> 
Er missed that it's a function call (thanks zlin) but the general point
applies (and tbh I wouldn't call the function twice in any case, so
Donnie's point re logic might be more cogent.)


-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-scheme/hop: metadata.xml ChangeLog hop-1.7.0.ebuild Manifest

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christian Faulhammer wrote:
> "Marijn Schouten (hkbst)" <[EMAIL PROTECTED]>:
>>   Added:metadata.xml ChangeLog hop-1.7.0.ebuild
>> Manifest Log:
>>   Initial commit
>> ./configure --prefix=/usr --libdir=/usr/$(get_libdir) || die
>> "configure failed"
>
>  econf not possible here?

from the comments, please read them.

# Hop doesn't use autoconf and consequently a lot of options used by econf
give errors

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

iD8DBQFG+jwwp/VmCx0OL2wRApR+AJ4lTRyagWAUI7FB5/1xaF6Nx8XC6wCgyEur
TXoAweILJRBhZOuZoIz04gM=
=10X4
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/qbittorrent: ChangeLog qbittorrent-1.0.0_rc1.ebuild qbittorrent-1.0.0_beta7.ebuild

[Raúl Porcel]

Fixed :)

-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Last rites: app-emacs/speedbar

[Ulrich Mueller]

# Ulrich Mueller <[EMAIL PROTECTED]> (26 Sep 2007)
# Last upstream release as separate package was in 2002.
# Speedbar is included with Emacs 22; users of Emacs 21
# may use app-emacs/cedet as replacement.
# Masked for removal in 30 days. Bug #190768.
app-emacs/speedbar
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in gnustep-apps/gnumail: ChangeLog gnumail-1.2.0_pre3-r1.ebuild

[Christian Faulhammer]

"Bernard Cafarelli (voyageur)" <[EMAIL PROTECTED]>:

>   Added:gnumail-1.2.0_pre3-r1.ebuild
>   Log:
>   Fix bug 193806, add some quoting
>   egnustep_install || die
>   egnustep_install || die
>   egnustep_install || die
>   egnustep_install || die

 Die messages would make it perfect. :)

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

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/dibbler: ChangeLog dibbler-0.6.1.ebuild

[Christian Faulhammer]

"Guy Martin (gmsoft)" <[EMAIL PROTECTED]>:

>   Added:dibbler-0.6.1.ebuild
>   Log:
>   Version bump. Fix #166013.
> DIBBLER_DOCDIR=${S}/doc
[...]
>   use doc && dodoc ${DIBBLER_DOCDIR}/dibbler-user.pdf \
>   ${DIBBLER_DOCDIR}/dibbler-devel.pdf
>   doins ${FILESDIR}/dibbler-server ${FILESDIR}/dibbler-client \
>   ${FILESDIR}/dibbler-relay

 Please quote all variables that may contain spaces: $DIBBLER_DOCDIR and
$FILESDIR 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

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-auth/pam_mount: ChangeLog pam_mount-0.27.ebuild

[Christian Faulhammer]

"Hanno Boeck (hanno)" <[EMAIL PROTECTED]>:

>   Added:pam_mount-0.27.ebuild
>   Log:
>   pam_mount bump
>   dodoc doc/*.txt || die

 Die message, please.

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 dev-scheme/bigloo: ChangeLog bigloo-3.0b_p2.ebuild

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mike Frysinger wrote:
> On Tuesday 25 September 2007, Bo �rsted Andresen wrote:
>> On Tuesday 25 September 2007 12:47:35 Marijn Schouten (hkBst) wrote:
> # "make test" does something weird so default src_test() in
> /usr/lib/portage/bin/ebuild.sh fails the following test # elif emake
> -j1 test -n &> /dev/null; then
> # so copy straight from default src_test() all the stuff which
> depends on that test passing src_test() {
> vecho ">>> Test phase [test]: ${CATEGORY}/${PF}"
> if ! emake -j1 test; then
> hasq test $FEATURES && die "Make test failed. See above for
> details." hasq test $FEATURES || eerror "Make test failed. See above
> for details." fi
> }
 I'm a bit confused about what's going on here. Isn't src_test() only
 supposed to run when 'test' is in FEATURES?
>>> I'm not sure, but as the comment says, I copied this straight from
>>> /usr/lib/portage/bin/ebuild.sh and it goes:
>> [SNIP]
>>
>> Some of that code is unreachable since src_test is never called when test
>> is not in FEATURES. Also there is some dispute as to whether testing the
>> FEATURES variable at all is permitted in ebuilds (bug #174335). In either
>> case it's not needed here. if `emake -j1 test -n` really fails for some
>> reason even though `emake -j1 test` generally works your src_test should
>> just be:
>>
>> src_test() {
>> emake -j1 test || die "Make test failed"
>> }
> 
> why is src_test() defined at all ... the default src_test will execute `emake 
> check` if possible and then try `emake test`
> -mike

I cannot reproduce the failure that caused me to copy part of the code from
usr/lib/portage/bin/ebuild.sh so I've removed src_test from this bigloo ebuild
and rely now on the default.

Who's gonna fix usr/lib/portage/bin/ebuild.sh?

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

iD8DBQFG+nRpp/VmCx0OL2wRAgszAKCibdBHe5WoBZLprKTSxZ02wrKc0wCeNUwq
9snyDtGguXvZoCkF5p1F5tQ=
=yLpT
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in gnustep-apps/gnumail:ChangeLog gnumail-1.2.0_pre3 -r1.ebuild

[Bernard Cafarelli]

On Wed, 26 Sep 2007 16:35:54 +0200, Christian Faulhammer <[EMAIL PROTECTED]>

wrote:

> "Bernard Cafarelli (voyageur)" <[EMAIL PROTECTED]>:

> 

>>   Added:gnumail-1.2.0_pre3-r1.ebuild

>>   Log:

>>   Fix bug 193806, add some quoting

>>  egnustep_install || die

>>  egnustep_install || die

>>  egnustep_install || die

>>  egnustep_install || die

> 

>  Die messages would make it perfect. :)



Even better: egnustep_install already dies by itself, and with a message ;)



I'll remove these, thanks for spotting them!



-- 

Bernard

-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] guile-1.8 prestabilization

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello peeps,

In light of most discovered incompatibilities with guile-1.8* having been
fixed and the need for stable guile-1.8* to get rid of old borken versions of
lilypond I'd like to request that if you run stable and have guile installed
that you do a

echo "dev-scheme/guile" >> /etc/portage/package.keywords

and report any remaining issues blocking bug 163921
()

If nothing serious turns up I will request stabilization in a few weeks' time.

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

iD8DBQFG+ogAp/VmCx0OL2wRAjeoAKCkeN8ejFPT1WbD4V1JQng+f/7fVQCgykoP
QLW+1mlnyn6vqzFoTs7SDpQ=
=f+7R
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Joe Peterson]

Thanks for the tip.  I added "failed to install genlop (via dobin)" -
not sure if there is a standard way to do this, as it seems many ebuilds
just do "dobin failed", and some do "failed to install ...".

-Joe


Christian Faulhammer wrote:
> "Joe Peterson (lavajoe)" <[EMAIL PROTECTED]>:
>>   Modified: ChangeLog
>>   Added:genlop-0.30.8.ebuild
>>   Version bump for portability of -c option to non-GNU/Linux
>> platforms (bug #172839) and better -r option performance/fixes
> 
>>  dobin genlop || die
> 
>  Could use a die message.
> 
> V-Li
> 

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-scheme/bigloo: ChangeLog bigloo-3.0b_p2.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Marijn Schouten (hkBst) wrote:
> Who's gonna fix usr/lib/portage/bin/ebuild.sh?

what's broken in it ?
-mike


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

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Christian Faulhammer]

Joe Peterson <[EMAIL PROTECTED]>:

> Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> not sure if there is a standard way to do this, as it seems many
> ebuilds just do "dobin failed", and some do "failed to install ...".

 It is mainly to localise which die command caused the halt.  So I know
of no standard.

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

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/mldonkey: ChangeLog mldonkey-2.9.1.ebuild

[Christian Faulhammer]

"Raul Porcel (armin76)" <[EMAIL PROTECTED]>:

>   Added:mldonkey-2.9.1.ebuild
>   Log:
>   Version bump, bug #193777
>   (Portage version: 2.1.3.9)
>   cd ${S}
>   domenu ${FILESDIR}/${PN}-gui.desktop
>   doicon ${FILESDIR}/${PN}.png
>   cd ${S}/distrib
>   cd ${S}/docs
>   cd ${S}/docs/developers
>   cd ${S}/docs/images

 Quotes...you fail!

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

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/aide: ChangeLog metadata.xml aide-0.13.1.ebuild

[Christian Faulhammer]

"Matsuu Takuto (matsuu)" <[EMAIL PROTECTED]>:

> matsuu  07/09/26 17:14:18
>   Modified: ChangeLog metadata.xml
>   Added:aide-0.13.1.ebuild
>   Log:
>   Version bumped.

 Please let die follow a message.

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 app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Christian Faulhammer wrote:
> Joe Peterson <[EMAIL PROTECTED]>:
> > Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> > not sure if there is a standard way to do this, as it seems many
> > ebuilds just do "dobin failed", and some do "failed to install ...".
>
>  It is mainly to localise which die command caused the halt.  So I know
> of no standard.

if there is just one call to die in a function, then i usually dont bother ... 
but if there are multiple ones (possibly nested), then it can easily save 
time
-mike


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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Donnie Berkholz]

On 16:11 Wed 26 Sep , Mike Frysinger wrote:
> On Wednesday 26 September 2007, Christian Faulhammer wrote:
> > Joe Peterson <[EMAIL PROTECTED]>:
> > > Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> > > not sure if there is a standard way to do this, as it seems many
> > > ebuilds just do "dobin failed", and some do "failed to install ...".
> >
> >  It is mainly to localise which die command caused the halt.  So I know
> > of no standard.
> 
> if there is just one call to die in a function, then i usually dont bother 
> ... 
> but if there are multiple ones (possibly nested), then it can easily save 
> time

Cardoe was just telling me that die messages are not that useful or 
time-saving because portage posts the line number of the failure 
already. That prompts the question, should we get rid of die messages?

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Donnie Berkholz wrote:
> On 16:11 Wed 26 Sep , Mike Frysinger wrote:
> > On Wednesday 26 September 2007, Christian Faulhammer wrote:
> > > Joe Peterson <[EMAIL PROTECTED]>:
> > > > Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> > > > not sure if there is a standard way to do this, as it seems many
> > > > ebuilds just do "dobin failed", and some do "failed to install ...".
> > >
> > >  It is mainly to localise which die command caused the halt.  So I know
> > > of no standard.
> >
> > if there is just one call to die in a function, then i usually dont
> > bother ... but if there are multiple ones (possibly nested), then it can
> > easily save time
>
> Cardoe was just telling me that die messages are not that useful or
> time-saving because portage posts the line number of the failure
> already.

true, since portage has added this traceback feature (it hasnt always been 
there), the need for the message has decreased ... i want to say however that 
it still isnt 100% correct in some nested situations, but i may be 
remembering things wrong or outdated ...

also, ebuilds do change over time, so what line # may be correct one day may 
not be relevant the next ...

> That prompts the question, should we get rid of die messages? 

perhaps de-emphasize their general worth, but not get rid of them
-mike


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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Ferris McCormick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 26 Sep 2007 13:42:08 -0700
Donnie Berkholz <[EMAIL PROTECTED]> wrote:

> On 16:11 Wed 26 Sep , Mike Frysinger wrote:
> > On Wednesday 26 September 2007, Christian Faulhammer wrote:
> > > Joe Peterson <[EMAIL PROTECTED]>:
> > > > Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> > > > not sure if there is a standard way to do this, as it seems many
> > > > ebuilds just do "dobin failed", and some do "failed to install ...".
> > >
> > >  It is mainly to localise which die command caused the halt.  So I know
> > > of no standard.
> > 
> > if there is just one call to die in a function, then i usually dont bother 
> > ... 
> > but if there are multiple ones (possibly nested), then it can easily save 
> > time
> 
> Cardoe was just telling me that die messages are not that useful or 
> time-saving because portage posts the line number of the failure 
> already. That prompts the question, should we get rid of die messages?
> 
> Thanks,
> Donnie

No.  They might contain useful information.  Just the line
number of the failure is just frustrating:  You don't really
necessarily know what went wrong, and you have to go read the ebuild to
find out.  Users might not appreciate that.
> -- 
> [EMAIL PROTECTED] mailing list
> 
Regards,

- -- 
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Developer, Gentoo Linux (Sparc, Devrel)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG+sspQa6M3+I///cRAr1QAJ9e1rGHNFBavGgR7pIxr1Xzaw12GgCg4lAK
k5/iP9fH0kcmYlBdjTKcYrY=
=BEej
-END PGP SIGNATURE-
éí¢‡^¾§¶Š(®   šŠX§‚X¬

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Doug Goldstein]

Christian Faulhammer wrote:
> Joe Peterson <[EMAIL PROTECTED]>:
>
>   
>> Thanks for the tip.  I added "failed to install genlop (via dobin)" -
>> not sure if there is a standard way to do this, as it seems many
>> ebuilds just do "dobin failed", and some do "failed to install ...".
>> 
>
>  It is mainly to localise which die command caused the halt.  So I know
> of no standard.
>
> V-Li 
>
>   
Except that's completely pointless since Portage and the other package
managers print the EXACT line number where the call was made. So this
thinking that a die message is required to identify which die was called
is flawed.
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Doug Goldstein]

Ferris McCormick wrote:
> On Wed, 26 Sep 2007 13:42:08 -0700
> Donnie Berkholz <[EMAIL PROTECTED]> wrote:
>
> > On 16:11 Wed 26 Sep , Mike Frysinger wrote:
> >> On Wednesday 26 September 2007, Christian Faulhammer wrote:
> >>> Joe Peterson <[EMAIL PROTECTED]>:
>  Thanks for the tip.  I added "failed to install genlop (via dobin)" -
>  not sure if there is a standard way to do this, as it seems many
>  ebuilds just do "dobin failed", and some do "failed to install ...".
> >>>  It is mainly to localise which die command caused the halt.  So I
> know
> >>> of no standard.
> >> if there is just one call to die in a function, then i usually dont
> bother ...
> >> but if there are multiple ones (possibly nested), then it can
> easily save
> >> time
> > Cardoe was just telling me that die messages are not that useful or
> > time-saving because portage posts the line number of the failure
> > already. That prompts the question, should we get rid of die messages?
>
> > Thanks,
> > Donnie
>
> No.  They might contain useful information.  Just the line
> number of the failure is just frustrating:  You don't really
> necessarily know what went wrong, and you have to go read the ebuild to
> find out.  Users might not appreciate that.
> > --
> > [EMAIL PROTECTED] mailing list
>
> Regards,
die "dobin failed" or something equally vague and pointless is no less
or more frustrating or informative then a line number. And arguably if
there's multiple statements that contain die "dobin failed" in an ebuild
it can set you on the wrong path and is equally and if not more frustrating.


-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Doug Goldstein]

Mike Frysinger wrote:
> On Wednesday 26 September 2007, Donnie Berkholz wrote:
>   
>> On 16:11 Wed 26 Sep , Mike Frysinger wrote:
>> 
>>> On Wednesday 26 September 2007, Christian Faulhammer wrote:
>>>   
 Joe Peterson <[EMAIL PROTECTED]>:
 
> Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> not sure if there is a standard way to do this, as it seems many
> ebuilds just do "dobin failed", and some do "failed to install ...".
>   
  It is mainly to localise which die command caused the halt.  So I know
 of no standard.
 
>>> if there is just one call to die in a function, then i usually dont
>>> bother ... but if there are multiple ones (possibly nested), then it can
>>> easily save time
>>>   
>> Cardoe was just telling me that die messages are not that useful or
>> time-saving because portage posts the line number of the failure
>> already.
>> 
>
> true, since portage has added this traceback feature (it hasnt always been 
> there), the need for the message has decreased ... i want to say however that 
> it still isnt 100% correct in some nested situations, but i may be 
> remembering things wrong or outdated ...
>   
I thought these issues were worked out already?

> also, ebuilds do change over time, so what line # may be correct one day may 
> not be relevant the next ...
>   
True. I will concede this point. I could attempt to argue this is why
it's important to know the version and revision of the package you are
emerging. But the counter point is evident, times when the ebuild is
changed without a bump pose a problem.

Which could bring up a point of would it be useful to see if we can
print out the actual line that caused the die. Now, I don't know if this
feasible or something the Portage devs want to do. But again, in the
effort to streamline this might be something to consider.

>   
>> That prompts the question, should we get rid of die messages? 
>> 
>
> perhaps de-emphasize their general worth, but not get rid of them
> -mike
>   
Which is what I'm after. Let's not force people to put a pointless
message in there if it's going to be pointless. Essentially, the
argument here is let's be consistent and put a message always. But a
better plan of action is let's use common sense and add it as needed.
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Ferris McCormick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 26 Sep 2007 17:42:01 -0400
Doug Goldstein <[EMAIL PROTECTED]> wrote:

> Ferris McCormick wrote:
> > On Wed, 26 Sep 2007 13:42:08 -0700
> > Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> >
> > > On 16:11 Wed 26 Sep , Mike Frysinger wrote:
> > >> On Wednesday 26 September 2007, Christian Faulhammer wrote:
> > >>> Joe Peterson <[EMAIL PROTECTED]>:
> >  Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> >  not sure if there is a standard way to do this, as it seems many
> >  ebuilds just do "dobin failed", and some do "failed to install ...".
> > >>>  It is mainly to localise which die command caused the halt.  So I
> > know
> > >>> of no standard.
> > >> if there is just one call to die in a function, then i usually dont
> > bother ...
> > >> but if there are multiple ones (possibly nested), then it can
> > easily save
> > >> time
> > > Cardoe was just telling me that die messages are not that useful or
> > > time-saving because portage posts the line number of the failure
> > > already. That prompts the question, should we get rid of die messages?
> >
> > > Thanks,
> > > Donnie
> >
> > No.  They might contain useful information.  Just the line
> > number of the failure is just frustrating:  You don't really
> > necessarily know what went wrong, and you have to go read the ebuild to
> > find out.  Users might not appreciate that.
> > > --
> > > [EMAIL PROTECTED] mailing list
> >
> > Regards,
> die "dobin failed" or something equally vague and pointless is no less
> or more frustrating or informative then a line number. And arguably if
> there's multiple statements that contain die "dobin failed" in an ebuild
> it can set you on the wrong path and is equally and if not more frustrating.
> 
Well, I was talking about useful die messages of course.  'die "dobin
failed"' is the same as no die message at all.  Whoever wrote
'dobin ... || die "dobin failed"' certainly knows more than that.  'die
"dobin failed"' of course might as well be omitted, but better, it
seems to me, is to make it same something intelligent.
> 
> -- 
> [EMAIL PROTECTED] mailing list
> 


- -- 
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Developer, Gentoo Linux (Sparc, Devrel)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG+ttGQa6M3+I///cRAjFwAKDeMoVxlrBaZG2t98ZTzfCMuWtdEACfUZ1I
NivmnTpQL+eztQB3BOVs3CA=
=pVt8
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Donnie Berkholz]

On 17:53 Wed 26 Sep , Doug Goldstein wrote:
> Mike Frysinger wrote:
> > Donnie Berkholz wrote:
> > also, ebuilds do change over time, so what line # may be correct one day 
> > may 
> > not be relevant the next ...
> >   
> True. I will concede this point. I could attempt to argue this is why
> it's important to know the version and revision of the package you are
> emerging. But the counter point is evident, times when the ebuild is
> changed without a bump pose a problem.
> 
> Which could bring up a point of would it be useful to see if we can
> print out the actual line that caused the die. Now, I don't know if this
> feasible or something the Portage devs want to do. But again, in the
> effort to streamline this might be something to consider.

The backtrace code is in ebuild.sh:dump_trace(). If you can find a way 
in bash to print the source line, that would be great. I took another 
glance through the bash man page and didn't see much from that end. But 
since we do have the source file and line number, we could just grab it 
with some hack like:

sed -ne "${lineno}p" ${filename}

Anyone got something better?

> >> That prompts the question, should we get rid of die messages? 
> >> 
> >
> > perhaps de-emphasize their general worth, but not get rid of them
> > -mike
> >   
> Which is what I'm after. Let's not force people to put a pointless
> message in there if it's going to be pointless. Essentially, the
> argument here is let's be consistent and put a message always. But a
> better plan of action is let's use common sense and add it as needed.

That sounds reasonable. Anyone reviewing code, please ensure there's a 
reason if you're suggesting addition of a trivial die message, 
particularly if we can figure out how to start printing the actual bash 
code.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Joe Peterson]

Ferris McCormick wrote:
> On Wed, 26 Sep 2007 17:42:01 -0400
> Doug Goldstein <[EMAIL PROTECTED]> wrote:
> 
>> Ferris McCormick wrote:
>>> On Wed, 26 Sep 2007 13:42:08 -0700
>>> Donnie Berkholz <[EMAIL PROTECTED]> wrote:
>>>
 On 16:11 Wed 26 Sep , Mike Frysinger wrote:
> On Wednesday 26 September 2007, Christian Faulhammer wrote:
>> Joe Peterson <[EMAIL PROTECTED]>:
>>> Thanks for the tip.  I added "failed to install genlop (via dobin)" -
>>> not sure if there is a standard way to do this, as it seems many
>>> ebuilds just do "dobin failed", and some do "failed to install ...".
>>  It is mainly to localise which die command caused the halt.  So I
>>> know
>> of no standard.
> if there is just one call to die in a function, then i usually dont
>>> bother ...
> but if there are multiple ones (possibly nested), then it can
>>> easily save
> time
 Cardoe was just telling me that die messages are not that useful or
 time-saving because portage posts the line number of the failure
 already. That prompts the question, should we get rid of die messages?
 Thanks,
 Donnie
>>> No.  They might contain useful information.  Just the line
>>> number of the failure is just frustrating:  You don't really
>>> necessarily know what went wrong, and you have to go read the ebuild to
>>> find out.  Users might not appreciate that.
 --
 [EMAIL PROTECTED] mailing list
>>> Regards,
>> die "dobin failed" or something equally vague and pointless is no less
>> or more frustrating or informative then a line number. And arguably if
>> there's multiple statements that contain die "dobin failed" in an ebuild
>> it can set you on the wrong path and is equally and if not more frustrating.
> 
> Well, I was talking about useful die messages of course.  'die "dobin
> failed"' is the same as no die message at all.  Whoever wrote
> 'dobin ... || die "dobin failed"' certainly knows more than that.  'die
> "dobin failed"' of course might as well be omitted, but better, it
> seems to me, is to make it same something intelligent.

Looks like almost 1/2 of them are simply "dobin failed":

find /usr/portage -name "*.ebuild" | xargs grep dobin | grep die | grep
'"dobin failed"$' | wc
 2621885   24194

find /usr/portage -name "*.ebuild" | xargs grep dobin | grep die | grep
"\"$" | wc
 5484183   54643

-Joe
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Donnie Berkholz wrote:
> On 17:53 Wed 26 Sep , Doug Goldstein wrote:
> > Mike Frysinger wrote:
> > > Donnie Berkholz wrote:
> > > also, ebuilds do change over time, so what line # may be correct one
> > > day may not be relevant the next ...
> >
> > True. I will concede this point. I could attempt to argue this is why
> > it's important to know the version and revision of the package you are
> > emerging. But the counter point is evident, times when the ebuild is
> > changed without a bump pose a problem.
> >
> > Which could bring up a point of would it be useful to see if we can
> > print out the actual line that caused the die. Now, I don't know if this
> > feasible or something the Portage devs want to do. But again, in the
> > effort to streamline this might be something to consider.
>
> The backtrace code is in ebuild.sh:dump_trace(). If you can find a way
> in bash to print the source line, that would be great. I took another
> glance through the bash man page and didn't see much from that end. But
> since we do have the source file and line number, we could just grab it
> with some hack like:
>
> sed -ne "${lineno}p" ${filename}
>
> Anyone got something better?

that's probably about the best ... the trace was invoked because of the call 
to `die`, not the previous call and i dont think the stack stuff in bash 
tracks history, just the current execution tree

that sed will probably work about half the time since it'll only work on one 
liners ...
-mike


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

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gnat.eclass

[Donnie Berkholz]

On 20:41 Wed 26 Sep , George Shapovalov (george) wrote:
> george  07/09/26 20:41:34
> 
>   Modified: gnat.eclass
>   Log:
>   added get_active_profile helper function

> Revision  ChangesPath
> 1.28 eclass/gnat.eclass
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/gnat.eclass?rev=1.28&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/gnat.eclass?rev=1.28&content-type=text/plain
> diff : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/gnat.eclass?r1=1.27&r2=1.28

> +# Returns a name of active gnat profile. Peroroms some validity checks. No 
> input
> +# parameters, analyzes the system setup directly.
> +get_active_profile() {
> + # get common code and settings
> + . ${GnatCommon} || die "failed to source gnat-common lib"
> +
> + local profiles=( $(get_env_list) ) 
> +
> + if [[ [EMAIL PROTECTED] == "${MARKER}*" ]]; then 
> + exit 

I'm surprised to see exit called in a function instead of returning 
nonzero.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: new old eclass - wxwidgets.eclass

[Ryan Hill]

Donnie Berkholz wrote:
> On 21:14 Mon 24 Sep , Ryan Hill wrote:
>> - is the stuff in global scope kosher?  i've seen other eclasses do
>> similar, but i want to be sure.  the reason for the looping is because
>> i figure calling built_with_use in global would get me hung.
> 
>>  for wxtoolkit in gtk2 base; do
>>  debug-print "global outer loop - wxtoolkit is ${wxtoolkit}"
>>  for wxdebug in release debug; do
>>  debug-print "global inner loop - wxdebug is ${wxdebug}"
>>  wxconf="${wxtoolkit}-${wxchar}-${wxdebug}-${WX_GTK_VER}"
>>  debug-print "testing for config ${wxconf}"
>>  [[ -f /usr/$(get_libdir)/wx/config/${wxconf} ]] || 
>> continue
> 
> Checking for existence of files in global scope?

Yeah.  These config files work like pkg-config, in that calling, say, 
`gtk2-unicode-release-2.8 --libs` outputs the linker flags needed to link
to those libraries.  We need a way to know what config scripts are available.
This is the least expensive way i could think of, a minimum of one and max of
four stat calls.

I'm also going to drop the debug-prints here as there's too much overhead.
 
>>  debug-print "found config ${wxconf} - setting WX_CONFIG"
>>  WX_CONFIG="/usr/$(get_libdir)/wx/config/${wxconf}"
>>  # TODO: needed for the wx-config wrapper
>>  #WX_ECLASS_CONFIG="${WX_CONFIG}"
>>  break
>>  done
>>  [[ -n ${WX_CONFIG} ]] && break
>>  done
>>  [[ -n ${WX_CONFIG} ]] && export WX_CONFIG #WX_ECLASS_CONFIG
> 
> OK, so let me try to follow the logic of preferences here:
> 
> 1. gtk2-release
> 2. gtk2-debug
> 3. base-release
> 4. base-debug
> 
> Does that mean they can't get a debug setup if the release one is found? 
> Does a debug build only produce debug and not release?

True.  For example the 2.6 ebuild will install one of gtk2-ansi-release-2.6 or 
gtk2-ansi-debug-2.6 depending on the debug USE flag.  With USE="-X" it installs
base-ansi-release-2.6 or base-ansi-debug-2.6.  gtk2 builds provide both the gtk2
and base libraries so are preferred over plain base.

It technically possible to install debug and release builds side-by-side.  In 
fact, the previous version of this eclass was designed around it.  Some invasive
hackery was needed to pull it off though, and we decided not to support it.

>> else
>>  :
>> fi
> 
> What's up with the 'else' here?

oops, leftover from debugging.  i had an echo in there, then replaced it with 
a no-op and forgot to remove it completely.

> 
> Thanks,
> Donnie

Thanks for taking the time to look at it.

-- 
  fonts / wxWindows / gcc-porting / treecleaners
  9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)

-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-scheme/bigloo: ChangeLog bigloo-3.0b_p2.ebuild

[Ryan Hill]

Alec Warner wrote:
> You should not use $FEATURES in an ebuild as they are not meant to be
> part of the API.

Can someone put something in the dev guide about this?  I was
looking for exactly this answer a week or so ago and couldn't find
anything. ;)


-- 
  fonts / wxWindows / gcc-porting / treecleaners
  9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)

-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/pygobject: ChangeLog pygobject-2.14.0.ebuild

[Donnie Berkholz]

On 13:15 Wed 26 Sep , Mart Raudsepp (leio) wrote:
> 1.1  dev-python/pygobject/pygobject-2.14.0.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/pygobject/pygobject-2.14.0.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/pygobject/pygobject-2.14.0.ebuild?rev=1.1&content-type=text/plain

>   mv "${D}"/usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.py \
>   
> "${D}"/usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.py-2.0
>   mv "${D}"/usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.pth \
>   
> "${D}"/usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.pth-2.0
> }
> 
> pkg_postinst() {
>   python_version
>   python_mod_optimize /usr/lib/python${PYVER}/site-packages/gtk-2.0
>   alternatives_auto_makesym 
> /usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.py pygtk.py-[0-9].[0-9]
>   alternatives_auto_makesym 
> /usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.pth 
> pygtk.pth-[0-9].[0-9]
>   python_mod_compile 
> ${ROOT}usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.py

This is pretty weird, because it uses get_libdir() almost everywhere but 
skips it once. Wonder if we could add a repoman check that looks for 
whether an ebuild calls get_libdir(), then checks for any instances of 
'[^[:alnum:]]lib[^[:alnum:]]'.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/mldonkey: ChangeLog mldonkey-2.9.1.ebuild

[Donnie Berkholz]

On 16:29 Wed 26 Sep , Raul Porcel (armin76) wrote:
> 1.1  net-p2p/mldonkey/mldonkey-2.9.1.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-p2p/mldonkey/mldonkey-2.9.1.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-p2p/mldonkey/mldonkey-2.9.1.ebuild?rev=1.1&content-type=text/plain

>   if use gtk && !(built_with_use dev-ml/lablgtk svg); then
>   if use gd && !(built_with_use media-libs/gd truetype); then

Weird, pointless subshells. Avoid them; they're contagious.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/traceroute: ChangeLog traceroute-2.0.9.ebuild

[Donnie Berkholz]

On 19:39 Wed 26 Sep , Mike Frysinger (vapier) wrote:
> 1.1  net-analyzer/traceroute/traceroute-2.0.9.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-analyzer/traceroute/traceroute-2.0.9.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-analyzer/traceroute/traceroute-2.0.9.ebuild?rev=1.1&content-type=text/plain

> src_compile() {
>   tc-export CC AR RANLIB
>   emake env=yes || die
> }

This is neat. I wonder whether it could come in handy for other 
ebuilds that pass CC etc into econf/emake.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/traceroute: ChangeLog traceroute-2.0.9.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Donnie Berkholz wrote:
> On 19:39 Wed 26 Sep , Mike Frysinger (vapier) wrote:
> > 1.1  net-analyzer/traceroute/traceroute-2.0.9.ebuild
> >
> > src_compile() {
> > tc-export CC AR RANLIB
> > emake env=yes || die
> > }
>
> This is neat. I wonder whether it could come in handy for other
> ebuilds that pass CC etc into econf/emake.

tc-export should not be needed with autotool based packages as they should 
properly detect the correct programs ... its main use is for non-autotool 
based packages (like traceroute)

the env=yes thing is specific to traceroute
-mike


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

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/gentoolkit: ChangeLog gentoolkit-0.2.4_rc1.ebuild

[Donnie Berkholz]

On 00:18 Thu 27 Sep , Paul Varner (fuzzyray) wrote:
> 1.1  app-portage/gentoolkit/gentoolkit-0.2.4_rc1.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-portage/gentoolkit/gentoolkit-0.2.4_rc1.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-portage/gentoolkit/gentoolkit-0.2.4_rc1.ebuild?rev=1.1&content-type=text/plain

> src_install() {
>   emake DESTDIR="${D}" install-gentoolkit || die "install-gentoolkit 
> failed"
> }
> 
> pkg_postinst() {
>   python_mod_optimize "${ROOT}"usr/lib/gentoolkit
>   echo
>   elog "Another alternative to equery is app-portage/portage-utils"
>   elog
>   elog "For further information on gentoolkit, please read the gentoolkit"
>   elog "guide: http://www.gentoo.org/doc/en/gentoolkit.xml";
>   elog
> }
> 
> pkg_postrm() {
>   python_mod_cleanup "${ROOT}"usr/lib/gentoolkit

Shouldn't gentoolkit go into get_libdir() instead of lib? Portage 
appears to...

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Bugzilla improvements

[Robin H. Johnson]

I went and processed a bunch of pending Bugzilla bugs, and thought folk
might be interested in the changes.

- "Bug Reporting Guide" is now linked from the front page as well as the
  "Choose Product" page (during bug creation). [Bug #188687]
- The "Log In" link in the footer should take you back to the same page
  that you were on (please file a bug for bugzilla@ if it messes up).
  [Bug #188690]
- SH, m68k, BSD in the 'Add Arches' Box. [Bug #178698, #178855]
- Favicon fixups. [Bug #184565]
- After changing a bug, the default behavior is now showing the updated
  bug, not jumping to the next bug in your last list. If you don't like
  this, you should change your own prefs.  [Bug #171988].
- "Do not reply" note at the top of bugmail, and a related Reply-To
  header. [Bug #181172]
- 'emerge info' => 'emerge --info' [Bug #173059]
- During guided bug submit, users are asked to include the full package
  atom in the summary line. [Bug #165976]
- Fix javascript bug with content-type selection during attachment of a
  file and using the drop-down box. [Bug #172513].
- Do not display the banner for text-mode browsers. [Bug #78670]
- Dupe box height in strict browsers fixed. [Bug #173158]
- Use site-specific link color instead of browser-provided, for
  visibility when browser default is too light. [Bug #185760]
- All internal links should stay on the HTTPS if you go there, and not
  take you off the HTTPS site. [No Bug#].

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgprYFzB5nC80.pgp
Description: PGP signature

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/pygobject: ChangeLog pygobject-2.14.0.ebuild

[Ryan Hill]

Donnie Berkholz wrote:
> On 13:15 Wed 26 Sep , Mart Raudsepp (leio) wrote:
>> 1.1  dev-python/pygobject/pygobject-2.14.0.ebuild
>>
>> file : 
>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/pygobject/pygobject-2.14.0.ebuild?rev=1.1&view=markup
>> plain: 
>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/pygobject/pygobject-2.14.0.ebuild?rev=1.1&content-type=text/plain
> 
>>  mv "${D}"/usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.py \
>>  
>> "${D}"/usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.py-2.0
>>  mv "${D}"/usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.pth \
>>  
>> "${D}"/usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.pth-2.0
>> }
>>
>> pkg_postinst() {
>>  python_version
>>  python_mod_optimize /usr/lib/python${PYVER}/site-packages/gtk-2.0
>>  alternatives_auto_makesym 
>> /usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.py pygtk.py-[0-9].[0-9]
>>  alternatives_auto_makesym 
>> /usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.pth 
>> pygtk.pth-[0-9].[0-9]
>>  python_mod_compile 
>> ${ROOT}usr/$(get_libdir)/python${PYVER}/site-packages/pygtk.py
> 
> This is pretty weird, because it uses get_libdir() almost everywhere but 
> skips it once. Wonder if we could add a repoman check that looks for 
> whether an ebuild calls get_libdir(), then checks for any instances of 
> '[^[:alnum:]]lib[^[:alnum:]]'.

that would match foo-lib.txt foo-lib-defooifier /usr/share/lib-foo/ etc. and 
miss /usr/lib64/...
(though i don't see anyone doing that).

what about /\/lib[/|32|64]/ ?

-- 
  fonts / wxWindows / gcc-porting / treecleaners
  9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/gentoolkit: ChangeLog gentoolkit-0.2.4_rc1.ebuild

[Paul Varner]

On Wed, 2007-09-26 at 18:39 -0700, Donnie Berkholz wrote:
> On 00:18 Thu 27 Sep , Paul Varner (fuzzyray) wrote:
> > 
> > pkg_postrm() {
> > python_mod_cleanup "${ROOT}"usr/lib/gentoolkit
> 
> Shouldn't gentoolkit go into get_libdir() instead of lib? Portage 
> appears to...

It probably should, it is going to require changes to the python source
code and Makefile as well though.

Regards,
Paul
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Bugzilla improvements

[Alec Warner]

Awesome, thanks for all your hard work.

-Alec

On 9/26/07, Robin H. Johnson <[EMAIL PROTECTED]> wrote:
> I went and processed a bunch of pending Bugzilla bugs, and thought folk
> might be interested in the changes.
>
> - "Bug Reporting Guide" is now linked from the front page as well as the
>   "Choose Product" page (during bug creation). [Bug #188687]
> - The "Log In" link in the footer should take you back to the same page
>   that you were on (please file a bug for bugzilla@ if it messes up).
>   [Bug #188690]
> - SH, m68k, BSD in the 'Add Arches' Box. [Bug #178698, #178855]
> - Favicon fixups. [Bug #184565]
> - After changing a bug, the default behavior is now showing the updated
>   bug, not jumping to the next bug in your last list. If you don't like
>   this, you should change your own prefs.  [Bug #171988].
> - "Do not reply" note at the top of bugmail, and a related Reply-To
>   header. [Bug #181172]
> - 'emerge info' => 'emerge --info' [Bug #173059]
> - During guided bug submit, users are asked to include the full package
>   atom in the summary line. [Bug #165976]
> - Fix javascript bug with content-type selection during attachment of a
>   file and using the drop-down box. [Bug #172513].
> - Do not display the banner for text-mode browsers. [Bug #78670]
> - Dupe box height in strict browsers fixed. [Bug #173158]
> - Use site-specific link color instead of browser-provided, for
>   visibility when browser default is too light. [Bug #185760]
> - All internal links should stay on the HTTPS if you go there, and not
>   take you off the HTTPS site. [No Bug#].
>
> --
> Robin Hugh Johnson
> Gentoo Linux Developer & Infra Guy
> E-Mail : [EMAIL PROTECTED]
> GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
>
>
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-mail/mailman: ChangeLog mailman-2.1.9-r2.ebuild

[Donnie Berkholz]

On 00:55 Thu 27 Sep , Hanno Boeck (hanno) wrote:
> 1.1  net-mail/mailman/mailman-2.1.9-r2.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/mailman/mailman-2.1.9-r2.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/mailman/mailman-2.1.9-r2.ebuild?rev=1.1&content-type=text/plain

This thing is packed with quoting issues for S, D and FILESDIR, and the 
pkg_* functions don't respect ROOT.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Rémi Cardona]

Mike Frysinger wrote:
> On Wednesday 26 September 2007, Donnie Berkholz wrote:
>> sed -ne "${lineno}p" ${filename}
>>
>> Anyone got something better?
>
> that sed will probably work about half the time since it'll only work on one 
> liners ...

Print one or two lines before and after ${lineno} and highlight ${lineno} ?

Rémi
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/gimp-help: ChangeLog gimp-help-0.13.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Donnie Berkholz wrote:
> On 05:14 Wed 26 Sep , Mike Frysinger wrote:
> > if it's all common shell, it's pretty hard to hide ... you could try some
> > tricks like rewriting USE to __USE__ so internal code (like the `use`
> > function) still work, but in the end, does that really help ?
>
> I think so. It explicitly says that's private and not part of the API,
> and it makes accidental overwrites much more unlikely.

you cant accidentally do it now though ... there is a list of variables that 
repoman explicitly has marked so you cant set them (and i think portage 
declares them readonly now in the ebuild env ...)
-mike


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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Mike Frysinger]

On Wednesday 26 September 2007, Donnie Berkholz wrote:
> On 17:53 Wed 26 Sep , Doug Goldstein wrote:
> > Mike Frysinger wrote:
> > > Donnie Berkholz wrote:
> > > also, ebuilds do change over time, so what line # may be correct one
> > > day may not be relevant the next ...
> >
> > True. I will concede this point. I could attempt to argue this is why
> > it's important to know the version and revision of the package you are
> > emerging. But the counter point is evident, times when the ebuild is
> > changed without a bump pose a problem.
> >
> > Which could bring up a point of would it be useful to see if we can
> > print out the actual line that caused the die. Now, I don't know if this
> > feasible or something the Portage devs want to do. But again, in the
> > effort to streamline this might be something to consider.
>
> The backtrace code is in ebuild.sh:dump_trace(). If you can find a way
> in bash to print the source line, that would be great. I took another
> glance through the bash man page and didn't see much from that end. But
> since we do have the source file and line number, we could just grab it
> with some hack like:
>
> sed -ne "${lineno}p" ${filename}
>
> Anyone got something better?

how about this:
+   eerror "The specific snippet of code:"
+   # This scans the file that called die and prints out the logic that
+   # ended in the call to die.  This really only handles lines that end
+   # with '|| die' and any preceding lines with line continuations (\).
+   # This tends to be the most common usage though, so let's do it.
+   # Due to the usage of appending to the hold space (even when empty),
+   # we always end up with the first line being a blank (thus the 2nd sed).
+   sed -n \
+   -e "# When we get to the line that failed, append it to the
+   # hold space, move the hold space to the pattern space,
+   # then print out the pattern space and quit immediately
+   ${BASH_LINENO[0]}{H;g;p;q}" \
+   -e '# If this line ends with a line continuation, append it
+   # to the hold space
+   /\\$/H' \
+   -e '# If this line does not end with a line continuation,
+   # erase the line and set the hold buffer to it (thus
+   # erasing the hold buffer in the process)
+   /[^\]$/{s:^.*$::;h}' \
+   ${BASH_SOURCE[1]} \
+   | sed -e '1d' \
+   | (OFS=${IFS} IFS=$'\n'; while read -r n ; do (IFS=${OFS}; 
eerror "  
${n}") ; done)
-mike


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