[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/imagemagick: ChangeLog imagemagick-6.3.5.10.ebuild

[Christian Faulhammer]

"Hans de Graaff (graaff)" <[EMAIL PROTECTED]>:

>   Modified: ChangeLog
>   Added:imagemagick-6.3.5.10.ebuild
>   Log:
>   Version bump: bug 193737

> src_install() {
>   make DESTDIR="${D}" install || die
 
 emake not possible?

[...]
>   dodoc NEWS ChangeLog AUTHORS README.txt QuickStart.txt
> Install-unix.txt

 Do you think that a installation manual is needed?

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 media-gfx/imagemagick: ChangeLog imagemagick-6.3.5.10.ebuild

[Donnie Berkholz]

On 06:56 Thu 27 Sep , Hans de Graaff (graaff) wrote:
> 1.1  media-gfx/imagemagick/imagemagick-6.3.5.10.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-gfx/imagemagick/imagemagick-6.3.5.10.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-gfx/imagemagick/imagemagick-6.3.5.10.ebuild?rev=1.1&content-type=text/plain

> MY_P=${MY_PN}-${PV%.*}
> MY_P2=${MY_PN}-${PV%.*}-${PV#*.*.*.}

This is starting to look like versionator.eclass might be nice.

>   make DESTDIR="${D}" install || die

No emake?

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

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

[George Shapovalov]

Thursday, 27. September 2007, Donnie Berkholz Ви написали:
> > +   if [[ [EMAIL PROTECTED] == "${MARKER}*" ]]; then
> > +   exit
>
> I'm surprised to see exit called in a function instead of returning
> nonzero.

This exit here indicates not a very usual but a valid situation, - no gnat 
profile has been activated yet. So, this is not an error, at least not 
always. But yes, returning a non zero also possible, though testing the 
result is not that different from testing for a non-zero string, and the 
latter is not intuitively percieved as an error :).

George 
--
[EMAIL PROTECTED] mailing list

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

[Mike Frysinger]

On Thursday 27 September 2007, George Shapovalov wrote:
> Thursday, 27. September 2007, Donnie Berkholz Ви написали:
> > > + if [[ [EMAIL PROTECTED] == "${MARKER}*" ]]; then
> > > + exit
> >
> > I'm surprised to see exit called in a function instead of returning
> > nonzero.
>
> This exit here indicates not a very usual but a valid situation, - no gnat
> profile has been activated yet. So, this is not an error, at least not
> always. But yes, returning a non zero also possible, though testing the
> result is not that different from testing for a non-zero string, and the
> latter is not intuitively percieved as an error :).

i think more to the point, ebuilds/eclasses should never be calling `exit`

if you want to "return an empty string", then you do `return`
-mike


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

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/rpy: ChangeLog rpy-0.99.2-r1.ebuild rpy-0.99.2.ebuild

[Donnie Berkholz]

On 07:34 Thu 27 Sep , Ali Polatel (hawking) wrote:
> 1.1  dev-python/rpy/rpy-0.99.2-r1.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/rpy/rpy-0.99.2-r1.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/rpy/rpy-0.99.2-r1.ebuild?rev=1.1&content-type=text/plain

> pkg_postinst() {
>   env-update
> }

Um. Is this really necessary?

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

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

[George Shapovalov]

Thursday, 27. September 2007, Mike Frysinger Ви написали:
> i think more to the point, ebuilds/eclasses should never be calling `exit`
>
> if you want to "return an empty string", then you do `return`
Ok, sorry, will fix.
Any pointers to some description of where each should be used? Is this 
about "the shell closing itself"? They both seem to have exactly the same 
effect in this code..

George
--
[EMAIL PROTECTED] mailing list

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 Wednesday 26 September 2007, Marijn Schouten (hkBst) wrote:
>> Who's gonna fix usr/lib/portage/bin/ebuild.sh?
> 
> what's broken in it ?
> -mike

Well, apparently it checking FEATURES is illegal, plus it seems that it
contains dead code. Why not replace it with:


src_test() {
if emake -j1 check -n &> /dev/null; then
vecho ">>> Test phase [check]: ${CATEGORY}/${PF}"
emake -j1 check || die "Make check failed. See above for 
details."
elif emake -j1 test -n &> /dev/null; then
vecho ">>> Test phase [test]: ${CATEGORY}/${PF}"
emake -j1 test || die "Make test failed. See above for details."
else
vecho ">>> Test phase [none]: ${CATEGORY}/${PF}"
fi
}

or in patch version:

- --- /usr/lib/portage/bin/ebuild.sh  2007-09-09 12:50:51.0 +0200
+++ /home/marijn/ebuild.sh  2007-09-27 11:58:18.0 +0200
@@ -666,16 +666,10 @@
 src_test() {
if emake -j1 check -n &> /dev/null; then
vecho ">>> Test phase [check]: ${CATEGORY}/${PF}"
- -   if ! emake -j1 check; then
- -   hasq test $FEATURES && die "Make check failed. See
above for details."
- -   hasq test $FEATURES || eerror "Make check failed. See
above for details."
- -   fi
+emake -j1 check || die "Make check failed. See above for details."
elif emake -j1 test -n &> /dev/null; then
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
+emake -j1 test || die "Make test failed. See above for details."
else
vecho ">>> Test phase [none]: ${CATEGORY}/${PF}"
fi


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+38Qp/VmCx0OL2wRApdnAJ9Yos8HKuhSX3UDS8rEe3qEeU7AbgCgxlOG
U8eATzDOZf7tFXXnJUD7vZk=
=4TEF
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

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

[Ulrich Mueller]

> On Thu, 27 Sep 2007, Mike Frysinger wrote:

> how about this:
> [...]
> + | (OFS=${IFS} IFS=$'\n'; while read -r n ; do (IFS=${OFS}; 
> eerror "  
> ${n}") ; done)

This is rather ugly. These IFS games are to allow for leading
whitespace, right?

Can't you do something like "xargs -d'\n' -n1 eerror"?

Ulrich
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Bugzilla improvements

[Thomas Anderson]

Did your work have anything to do with the e-mails from bugzilla-daemon only 
containing HTTPS links? I noticed that over the previous few days.

On Wednesday 26 September 2007 22:04:40 Robin H. Johnson 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#].



-- 
2.6.22-gentoo-r2
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Bugzilla improvements

[Olivier Crête]

On Wed, 2007-26-09 at 19:04 -0700, Robin H. Johnson wrote:
> I went and processed a bunch of pending Bugzilla bugs, and thought folk
> might be interested in the changes.
>
> - "Do not reply" note at the top of bugmail, and a related Reply-To
>   header. [Bug #181172]

Is this really required? It pushes the real content even farther down
the window. Or if you really want to keep it for new users, please allow
us to disable that.


-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


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

Re: [gentoo-dev] Bugzilla improvements

[Robin H. Johnson]

On Thu, Sep 27, 2007 at 07:13:05AM -0400, Thomas Anderson wrote:
> Did your work have anything to do with the e-mails from bugzilla-daemon only 
> containing HTTPS links? I noticed that over the previous few days.
That got fixed as well, but a while before I did this big pass.

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


pgpNKkjwvyxIu.pgp
Description: PGP signature

Re: [gentoo-dev] Bugzilla improvements

[Robin H. Johnson]

On Thu, Sep 27, 2007 at 03:05:28PM +0300, Olivier Cr?te wrote:
> Is this really required? It pushes the real content even farther down
> the window. Or if you really want to keep it for new users, please allow
> us to disable that.
Bugzilla does not generate the mail once per user, but rather once and
then send it multiple times, so no, I can't customize it per user.

If the links moving a whole 3 lines further down really bothers you,
edit the incoming mail with procmail.

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


pgp4wV74gXZQk.pgp
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 Thursday 27 September 2007, Ulrich Mueller wrote:
> > On Thu, 27 Sep 2007, Mike Frysinger wrote:
> >
> > how about this:
> > [...]
> > +   | (OFS=${IFS} IFS=$'\n'; while read -r n ; do (IFS=${OFS}; 
> > eerror "
> > ${n}") ; done)
>
> This is rather ugly. These IFS games are to allow for leading
> whitespace, right?

exactly

> Can't you do something like "xargs -d'\n' -n1 eerror"?

the BSD wankers would complain their xargs doesnt support -d
-mike


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

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

[Mike Frysinger]

On Thursday 27 September 2007, George Shapovalov wrote:
> Thursday, 27. September 2007, Mike Frysinger Ви написали:
> > i think more to the point, ebuilds/eclasses should never be calling
> > `exit`
> >
> > if you want to "return an empty string", then you do `return`
>
> Ok, sorry, will fix.
> Any pointers to some description of where each should be used?

how about:
exit should be used: never
;)

> Is this about "the shell closing itself"?

it's about people in the past incorrectly used `exit` instead of `die` so we'd 
prefer exit not leak back in so that new people dont inadvertently get the 
same idea

> They both seem to have exactly the same effect in this code..

i imagine the way you're using it, that is true (subshelling for output / 
piping), but considering the above, we'd really ask you go with return
-mike


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

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

[Mike Frysinger]

On Thursday 27 September 2007, Marijn Schouten (hkBst) wrote:
> Mike Frysinger wrote:
> > 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
>
> Well, apparently it checking FEATURES is illegal

you misinterpreted the statement ... *ebuilds* using FEATURES is illegal, 
portage itself is 100% free to do it

> plus it seems that it contains dead code. Why not replace it with:

i believe this stems back to src_test always being called irregardless of user 
input ... not sure if that's applicable anymore (so you'd be right, there'd 
be no point)
-mike


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

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 Thursday 27 September 2007, Marijn Schouten (hkBst) wrote:
>> Mike Frysinger wrote:
>>> 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
>> Well, apparently it checking FEATURES is illegal
> 
> you misinterpreted the statement ... *ebuilds* using FEATURES is illegal, 
> portage itself is 100% free to do it

I think default ebuild functions should also be legal when implemented in an
actual ebuild and thus I don't think default ebuild functions should be
considered to be part of portage.

There is no reason to allow defaults to do special magic stuff and it is
unclean to allow it. Any special stuff should either be made part of the API
so all ebuild functions can use it or removed from defaults and normal
functions alike.

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+7FPp/VmCx0OL2wRAj5wAJ4yYSKCwlY/Skj6/Xg+eKKpnEe2GQCfXBSb
70i45u3RdXr11fFDc1C+nDw=
=oMWg
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Bugzilla improvements

[Robert Buchholz]

On Thursday, 27. September 2007, Robin H. Johnson wrote:
> On Thu, Sep 27, 2007 at 03:05:28PM +0300, Olivier Cr?te wrote:
> > Is this really required? It pushes the real content even farther
> > down the window. Or if you really want to keep it for new users,
> > please allow us to disable that.
>
> Bugzilla does not generate the mail once per user, but rather once
> and then send it multiple times, so no, I can't customize it per
> user.

Is it possible to display the text only once when blocking bugs change?
Especially because of the "please visit" in the middle isn't followed by 
a link.
Here's how it looks:

8<8<8<8<
DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
whose email is mentioned below. To comment on this bug, please visit:

Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=186030
Secure: https://bugs.gentoo.org/show_bug.cgi?id=186030


DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
whose email is mentioned below. To comment on this bug, please visit:
Bug 186030 depends on bug 193737, which changed state.

Bug 193737 Summary: media-gfx/imagemagick-6.3.5.9 breaks external apps - 
libgomp.so.1: shared object cannot be dlopen()ed
Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=193737
Secure: https://bugs.gentoo.org/show_bug.cgi?id=193737
>8>8>8>8


Regards,
Robert


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

Re: [gentoo-dev] Bugzilla improvements

[Petteri Räty]

Robin H. Johnson kirjoitti:
> - Use site-specific link color instead of browser-provided, for
>   visibility when browser default is too light. [Bug #185760]

Is the value we are using different from what Firefox uses by default?
It looks a bit too bright to me.

Regards,
Petteri





signature.asc
Description: OpenPGP digital signature

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

[Ulrich Mueller]

> On Thu, 27 Sep 2007, Mike Frysinger wrote:

>> > +  | (OFS=${IFS} IFS=$'\n'; while read -r n ; do (IFS=${OFS}; 
>> > eerror "
>> > ${n}") ; done)

>> Can't you do something like "xargs -d'\n' -n1 eerror"?

> the BSD wankers would complain their xargs doesnt support -d

That's true. Then:
   sed 's/^/X/' | while read -r n; do eerror "${n#X}"; done
(The substitution can be included in the previous sed command.)

Ulrich
-- 
[EMAIL PROTECTED] mailing list

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

[Hanno Böck]

Am Donnerstag 27 September 2007 schrieb Donnie Berkholz:
> This thing is packed with quoting issues for S, D and FILESDIR, and the
> pkg_* functions don't respect ROOT.

Quotes done. About pkg_ and ROOT: Didn't find any issues here. python_mod_* 
seems to care about that itself. Found one issue in src_install, but none in 
pkg_*


-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


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

[Roy Marples]

On Thursday 27 September 2007 14:00:37 Mike Frysinger wrote:
> the BSD wankers

Better to wank over the Devil instead of being buggered by a pengiun :P
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Bugzilla improvements

[Raúl Porcel]

Good job, thanks!
-- 
[EMAIL PROTECTED] mailing list

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

[Jeroen Roovers]

On Wed, 26 Sep 2007 19:01:33 -0600
Ryan Hill <[EMAIL PROTECTED]> wrote:

> 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. ;)

Maybe it's a clue that [1] does /not/ mention FEATURES as a variable to
be used in ebuilds, but only as a variable that emerge might use.


Kind regards,
 JeR



[1] http://devmanual.gentoo.org/ebuild-writing/variables/index.html
-- 
[EMAIL PROTECTED] mailing list

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

[Hanno Böck]

Guys, it's nice that you have so interesting discussions, but let me just 
state that I haven't written this code. I just did a trivial copy-over-bump.

If anyone wants to improve the ebuild, feel free do go ahead and commit your 
changes.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


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

[gentoo-dev] SSL-Certificates and CAcert

[Hanno Böck]

Hi,

Everytime I'm sending out a mail with my gentoo.org-address, I get 
this "certificate may be unsecure" message. Gentoo mailserver (and forums, 
bugzilla and probably many more) use self-signed ssl-certificates.

Well, I hope I don't have to tell that self-signed certs are not really good 
security policy. Imho, having those "pay lots of $/€"-certs also isn't a very 
good option, because obviously "security for the ones who pay a lot" isn't a 
good idea either.

I think most of you know that there's CAcert, a "free" certificate authority. 
While it's sadly not free in a "free software" sense (their own software 
isn't released under a free license, though I hope that will change at some 
point in the future), it uses a web-of-trust-based concept for trust and 
issues certificates with no costs.

I think compared to self-signed, having cacert-certificates would be a big 
improvement. Many other free software projects (and more and more other 
pages) use cacert, so it becomes more and more likely that people will 
already have the cacert-root-cert installed.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


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

Re: [gentoo-dev] SSL-Certificates and CAcert

[Petteri Räty]

Hanno Böck kirjoitti:
> 
> I think compared to self-signed, having cacert-certificates would be a big 
> improvement. Many other free software projects (and more and more other 
> pages) use cacert, so it becomes more and more likely that people will 
> already have the cacert-root-cert installed.
> 

gentoo-project material

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

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

[Steve Long]

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.
> 
Yeah but if it's been declare'd -r (readonly) that isn't an issue. 

Personally I think access to all the variables is fine; an ebuild is a
shell-script, not a C++ project, and if a dev breaks something it's his
responsibility to fix it. (Quite apart from this review process picking
stuff up.) My 2c on that.

Wrt to the function, I'd define it so:

use_linguas() {
(($#)) || die 'use_linguas() called with no arguments'
ALL_LINGUAS=
local lingua
for lingua; do
use "linguas_$lingua" && ALL_LINGUAS+=" $lingua"
done
# [[ $ALL_LINGUAS ]] || die 'No Linguas available'
[[ $ALL_LINGUAS ]] && return 0
# ALL_LINGUAS=en # default to English
return 1
}
..to call with use_linguas de en es it zh # for example

It'd be easier to maintain if the ebuild author wrote:
MY_LINGUAS='de en es it zh'
..at the top of the file, with calls to:
use_linguas $MY_LINGUAS
..where needed.


-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] SSL-Certificates and CAcert

[Andrew Gaffney]

Hanno Böck wrote:
I think compared to self-signed, having cacert-certificates would be a big 
improvement. Many other free software projects (and more and more other 
pages) use cacert, so it becomes more and more likely that people will 
already have the cacert-root-cert installed.


How does a CAcert certificate help? Their own certificate for 
https://www.cacert.org/ can't be verified by Firefox 2.0.0.7, which tells me 
that their CA isn't trusted by default.


--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
[EMAIL PROTECTED] mailing list

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

[Steve Long]

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 ...
>> >   
>> 
>> 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?
>
This is from abort() in update (unreleased):
abort() {
f="Internal error in ${FUNCNAME[1]}(${BASH_LINENO[0]})"
[EMAIL PROTECTED]
if ((n>3)); then
for ((i=2;i

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

[Steve Long]

Donnie Berkholz wrote:

> On 13:15 Wed 26 Sep , Mart Raudsepp (leio) wrote:
>> 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:]]'.
> 
It seems a bit inefficient to keep calling the function in an implicit
subshell. What's wrong with ldir="/usr/$(get_libdir)/" [or "${ROOT}usr.."]
once and then reusing the value?
(The single use of $ROOT in pkg_postinst() seems odd too, to this newb.)


-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] MAKEOPTS settings

[Christian Faulhammer]

Hi, 

could there be side effects setting MAKEOPTS in the ebuild (in global
scope)?

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] Bugzilla improvements

[Mike Frysinger]

On Thursday 27 September 2007, Petteri Räty wrote:
> Robin H. Johnson kirjoitti:
> > - Use site-specific link color instead of browser-provided, for
> >   visibility when browser default is too light. [Bug #185760]
>
> Is the value we are using different from what Firefox uses by default?
> It looks a bit too bright to me.

what he means is the color matches the link color found on gentoo.org
-mike


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

Re: [gentoo-dev] MAKEOPTS settings

[Mike Frysinger]

On Thursday 27 September 2007, Christian Faulhammer wrote:
> could there be side effects setting MAKEOPTS in the ebuild (in global
> scope)?

you should only be incrementing, never setting ... anything that sets it is 
broken while anything that increments it is considered bad form, but 
currently overlooked due to a better solution lacking

iow, wrong:
MAKEOPTS="-j1"
currently overlooked:
MAKEOPTS="${MAKEOPTS} -j1"
-mike


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

Re: [gentoo-dev] SSL-Certificates and CAcert

[Hanno Böck]

Am Donnerstag 27 September 2007 schrieb Andrew Gaffney:
> How does a CAcert certificate help? Their own certificate for
> https://www.cacert.org/ can't be verified by Firefox 2.0.0.7, which tells
> me that their CA isn't trusted by default.

They're workin on that, goal is to include in ff. But anyway, I think it still 
helps.

On many IT events cacert is present and you can get their fingerprint. Beside, 
you only have to import their root-cert once and get verification for all 
cacert-pages out there, not only gentoo's. That's the whole idea and it's a 
lot more comfortable (and secure) than self-signed I think.


-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


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

[gentoo-dev] Re: MAKEOPTS settings

[Christian Faulhammer]

Mike Frysinger <[EMAIL PROTECTED]>:

> On Thursday 27 September 2007, Christian Faulhammer wrote:
> > could there be side effects setting MAKEOPTS in the ebuild (in
> > global scope)?
> you should only be incrementing, never setting ... anything that sets
> it is broken while anything that increments it is considered bad
> form, but currently overlooked due to a better solution lacking
> iow, wrong:
> MAKEOPTS="-j1"
> currently overlooked:
> MAKEOPTS="${MAKEOPTS} -j1"

 Ok, so the latter saves me from repeating all standard functions with
emake -j1.  Thanks.

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 Thursday 27 September 2007, Ulrich Mueller wrote:
> > On Thu, 27 Sep 2007, Mike Frysinger wrote:
> >> >
> >> > +| (OFS=${IFS} IFS=$'\n'; while read -r n ; do 
> >> > (IFS=${OFS}; eerror "
> >> > ${n}") ; done)
> >>
> >> Can't you do something like "xargs -d'\n' -n1 eerror"?
> >
> > the BSD wankers would complain their xargs doesnt support -d
>
> That's true. Then:
>sed 's/^/X/' | while read -r n; do eerror "${n#X}"; done
> (The substitution can be included in the previous sed command.)

yeah, that works nicely, thanks

time to commit !
-mike


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

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

[Mart Raudsepp]

On N, 2007-09-27 at 17:08 +0100, Steve Long wrote:
> Donnie Berkholz wrote:
> 
> > On 13:15 Wed 26 Sep , Mart Raudsepp (leio) wrote:
> >> 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:]]'.
> > 
> It seems a bit inefficient to keep calling the function in an implicit
> subshell. What's wrong with ldir="/usr/$(get_libdir)/" [or "${ROOT}usr.."]
> once and then reusing the value?

Readability in my eyes. This function call can't cost more than all the
disk activity that is going to go on from the calls..

> (The single use of $ROOT in pkg_postinst() seems odd too, to this newb.)

That's what python.eclass gives you. Other functions takes care of
${ROOT} for you, but that doesn't.


As a side note, the python_mod_optimize lib was changed to a
$(get_libdir) yesterday based on Donnies initial post here.

-- 
Mart Raudsepp
Gentoo Developer
Mail: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio


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

[gentoo-dev] Re: MAKEOPTS settings

[Christian Faulhammer]

Mike Frysinger <[EMAIL PROTECTED]>:

> >  Ok, so the latter saves me from repeating all standard functions
> > with emake -j1.  Thanks.
> sorry, i'll be a bit more specific ... the reason appending MAKEOPTS
> has been sliding is due to the large volume of gnome ebuilds and
> integrated eclasses ... it isnt trivial to pass that information
> along since the emake happens in nested eclasses, so MAKEOPTS gets
> incremented in the ebuild

 It is an ebuild based on gnome.eclass, so it hits your case. :)
 
> if you're doing it to avoid -j1 in like two calls to emake, that's
> poor taste :p

 I did not want to repeat whole gnome.eclass definitions.
 
> also, any package that fails -j1 building should have an open bug
> about it ... parallel building isnt something to be workedaround with
> -j1 and then ignored as it can severely screw people (consider
> systems that have a crap ton of slow procs -- common for mips people)

 That software is from 2005 and I can't help it as I was doing arch
maintenance, maintainers were not reacting => not my beer anymore.

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: MAKEOPTS settings

[Mike Frysinger]

On Thursday 27 September 2007, Christian Faulhammer wrote:
> Mike Frysinger <[EMAIL PROTECTED]>:
> > On Thursday 27 September 2007, Christian Faulhammer wrote:
> > > could there be side effects setting MAKEOPTS in the ebuild (in
> > > global scope)?
> >
> > you should only be incrementing, never setting ... anything that sets
> > it is broken while anything that increments it is considered bad
> > form, but currently overlooked due to a better solution lacking
> > iow, wrong:
> > MAKEOPTS="-j1"
> > currently overlooked:
> > MAKEOPTS="${MAKEOPTS} -j1"
>
>  Ok, so the latter saves me from repeating all standard functions with
> emake -j1.  Thanks.

sorry, i'll be a bit more specific ... the reason appending MAKEOPTS has been 
sliding is due to the large volume of gnome ebuilds and integrated 
eclasses ... it isnt trivial to pass that information along since the emake 
happens in nested eclasses, so MAKEOPTS gets incremented in the ebuild

if you're doing it to avoid -j1 in like two calls to emake, that's poor 
taste :p

also, any package that fails -j1 building should have an open bug about it ... 
parallel building isnt something to be workedaround with -j1 and then ignored 
as it can severely screw people (consider systems that have a crap ton of 
slow procs -- common for mips people)
-mike


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

Re: [gentoo-dev] Re: MAKEOPTS settings

[Mike Frysinger]

On Thursday 27 September 2007, Christian Faulhammer wrote:
> Mike Frysinger <[EMAIL PROTECTED]>:
> > also, any package that fails -j1 building should have an open bug
> > about it ... parallel building isnt something to be workedaround with
> > -j1 and then ignored as it can severely screw people (consider
> > systems that have a crap ton of slow procs -- common for mips people)
>
>  That software is from 2005 and I can't help it as I was doing arch
> maintenance, maintainers were not reacting => not my beer anymore.

i'm not telling you to fix it, i'm saying it needs to be tracked and not 
ignored
-mike


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

Re: [gentoo-dev] SSL-Certificates and CAcert

[Doug Goldstein]

Andrew Gaffney wrote:
> Hanno Böck wrote:
>> I think compared to self-signed, having cacert-certificates would be
>> a big improvement. Many other free software projects (and more and
>> more other pages) use cacert, so it becomes more and more likely that
>> people will already have the cacert-root-cert installed.
>
> How does a CAcert certificate help? Their own certificate for
> https://www.cacert.org/ can't be verified by Firefox 2.0.0.7, which
> tells me that their CA isn't trusted by default.
>
Yes, however a lot of people have their cert imported into their browser
and they provide a method for importing the their CA into your browser.
Where's the Gentoo CA for me to import into my browser?
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Bugzilla improvements

[Doug Goldstein]

Robin H. Johnson 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#].
>
>   
Three cheers for robbat2!

Only comment is that this really should have been sent to
gentoo-dev-announce and then kicked over to gentoo-dev to discuss.
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] SSL-Certificates and CAcert

[Robin H. Johnson]

On Thu, Sep 27, 2007 at 05:23:26PM +0200, Hanno B??ck wrote:
> Well, I hope I don't have to tell that self-signed certs are not really good 
> security policy.
Whether or not self-signed certs are secure or insecure depends entirely
on your definition of 'secure'. 
- Is the traffic encrypted between your machine and the server? 
  Always, regardless of it being a self-signed or self-CA, or external CA.
- Can you be sure that there is no MITM attack?
  Only if you trust the CA _OR_ you know in advance the SSL fingerprint.

Knowing the SSL fingerprint is trivial, if you login to machines with
SSH, you are be doing this every day.

> I think most of you know that there's CAcert, a "free" certificate authority. 
> While it's sadly not free in a "free software" sense (their own software 
> isn't released under a free license, though I hope that will change at some 
> point in the future), it uses a web-of-trust-based concept for trust and 
> issues certificates with no costs.
Go and read ALL of this bug:
http://bugs.gentoo.org/show_bug.cgi?id=108944
Pylon and myself, as folk in favour of CA-Cert tried to get the ball
rolling to get Organization-level certs from CACert. It seems to have
long blocked on trustees and paperwork - both on our side, and on the
side of CACert (Inclusion in Mozilla is blocking on the CACert internal
audit).

> I think compared to self-signed, having cacert-certificates would be a big 
> improvement. Many other free software projects (and more and more other 
> pages) use cacert, so it becomes more and more likely that people will 
> already have the cacert-root-cert installed.
I don't agree that it's a big improvement. If you read the bug above,
you'll note that we did at one stage have a 'Gentoo CA' that Infra ran
for generating certs.

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


pgpR1fxD9GfRh.pgp
Description: PGP signature

Re: [gentoo-dev] Bugzilla improvements

[Robin H. Johnson]

On Thu, Sep 27, 2007 at 03:31:00PM +0200, Robert Buchholz wrote:
> Is it possible to display the text only once when blocking bugs change?
> Especially because of the "please visit" in the middle isn't followed by 
> a link.
Should be fixed now.

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


pgp1gPBrxmL8p.pgp
Description: PGP signature

Re: [gentoo-dev] SSL-Certificates and CAcert

[Caleb Tennis]

> On Thu, Sep 27, 2007 at 05:23:26PM +0200, Hanno B??ck wrote:
>> Well, I hope I don't have to tell that self-signed certs are not really good
>> security policy.
> Whether or not self-signed certs are secure or insecure depends entirely
> on your definition of 'secure'.
> - Is the traffic encrypted between your machine and the server?
>   Always, regardless of it being a self-signed or self-CA, or external CA.
> - Can you be sure that there is no MITM attack?
>   Only if you trust the CA _OR_ you know in advance the SSL fingerprint.
>
> Knowing the SSL fingerprint is trivial, if you login to machines with
> SSH, you are be doing this every day.

Yes, you and I and most other technical people know and understand this.  But 
how
many end users know or care that their traffic to bugzilla is being safely
encrypted?  And how many are going to have worry and or doubt when they get a 
popup
telling them that some kind of security certificate may not be valid.  It's
definitely a red flag.

>> I think most of you know that there's CAcert, a "free" certificate authority.
>> While it's sadly not free in a "free software" sense (their own software
>> isn't released under a free license, though I hope that will change at some
>> point in the future), it uses a web-of-trust-based concept for trust and
>> issues certificates with no costs.
> Go and read ALL of this bug:
> http://bugs.gentoo.org/show_bug.cgi?id=108944
> Pylon and myself, as folk in favour of CA-Cert tried to get the ball
> rolling to get Organization-level certs from CACert. It seems to have
> long blocked on trustees and paperwork - both on our side, and on the
> side of CACert (Inclusion in Mozilla is blocking on the CACert internal
> audit).

Is there a reason that my Godaddy suggestion in the bug isn't being considered? 
Regardless of what you may think of them as a company, they offer the same free 
type
of certificate to open source projects just like cacert, and with what looks to 
be
considerable less overhead.  I understand that cacert is more "open sourcy" than
godaddy, but if they're as much of a roadblock as the Trustees are in this case,
maybe going that route would enable us to move forward?

>> I think compared to self-signed, having cacert-certificates would be a big
>> improvement. Many other free software projects (and more and more other
>> pages) use cacert, so it becomes more and more likely that people will
>> already have the cacert-root-cert installed.
> I don't agree that it's a big improvement. If you read the bug above,
> you'll note that we did at one stage have a 'Gentoo CA' that Infra ran
> for generating certs.

It is a big improvement.  Not in security, but in perception.

Caleb

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] SSL-Certificates and CAcert

[Robin H. Johnson]

On Thu, Sep 27, 2007 at 06:47:36PM -0400, Caleb Tennis wrote:
> Is there a reason that my Godaddy suggestion in the bug isn't being 
> considered? 
> Regardless of what you may think of them as a company, they offer the same 
> free type
> of certificate to open source projects just like cacert, and with what looks 
> to be
> considerable less overhead.  I understand that cacert is more "open sourcy" 
> than
> godaddy, but if they're as much of a roadblock as the Trustees are in this 
> case,
> maybe going that route would enable us to move forward?
See my comment #14, regarding regenerating the certs [1] each time the set
of SSL vhosts on a box changes. For mail services, this isn't really an
issue, but for web services it's a big one. Wildcards only work in
Mozilla, and nowhere else [2].

[1] 
http://wiki.cacert.org/wiki/VhostTaskForce#head-7236c4e2c9932ef42056b3ff6d367053081887de
[2] http://wiki.cacert.org/wiki/WildcardCertificates

> > I don't agree that it's a big improvement. If you read the bug above,
> > you'll note that we did at one stage have a 'Gentoo CA' that Infra ran
> > for generating certs.
> It is a big improvement.  Not in security, but in perception.
Ok, let's narrow this down for a moment.
Of the SSL-using services that Gentoo has, which do we care about for
users (NOT developers)? 
bugs.g.o and forums.g.o are the main two that I'm aware of.
Are there any others that get high traffic of security-clueless users?

If there aren't too many AND we can get a dedicated IP for each of those
services, I'd like to suggest the following, as an easily doable and
low-overhead (in terms of Trustees/paperwork) solution:

1. On the services identified, get extra IPs, and use the free GoDaddy certs.
2. On other services use the Gentoo-CA approach.

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


pgpPfdX9080Uy.pgp
Description: PGP signature