[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc/files/eblits: pkg_preinst.eblit
Il giorno mer, 13/10/2010 alle 20.12 -0400, Mike Frysinger ha scritto: > > yet another reason (strace also readily comes to mind) i keep asking > you to post fixes and/or notify maintainers (base-system/toolchain) For your information I _am_ part of base-system, so at least for strace you really can't say anything. I also told you before that if you want to be notified personally you should add _yourself_ to metadata beside the herd. > instead of just committing things. pushd/popd do not write to stderr. > so this change now echoes the dirs when people emerge it. plus, this > really should be outside of the loop. I admit the mistake, fwiw it was part of debugging: pushd &> /dev/null became pushd 2> /dev/null and then forgot about changing it back. So sorry to have added ... four lines of noise on a merge log? On the other hand if I left it to the same process I left my personal problem with binary merging of glibc (i.e. no news about it in months), the user who reported to me that glibc segfaulted during binary merges would probably still be hitting the same problem. Hmm I wonder what's worse. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc/files/eblits: pkg_preinst.eblit
On Fri, Oct 8, 2010 at 11:33 AM, Diego Petteno (flameeyes)
wrote:
> flameeyes 10/10/08 15:33:13
>
> Modified: pkg_preinst.eblit
> Log:
> QA: avoid using $D when testing the just-built loader, as it might cause
> trouble when it contains colon characters; the fix is trivial.
you'd think trivial fixes wouldnt contain bugs ...
> + pushd "${D}"/$(get_libdir) 2>/dev/null
> + ./ld-*.so --library-path . ${x} > /dev/null \
> || die "simple run test (${x}) failed"
> + popd 2>/dev/null
yet another reason (strace also readily comes to mind) i keep asking
you to post fixes and/or notify maintainers (base-system/toolchain)
instead of just committing things. pushd/popd do not write to stderr.
so this change now echoes the dirs when people emerge it. plus, this
really should be outside of the loop.
-mike
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
Excerpts from Mike Frysinger's message of Thu Oct 14 00:32:40 +0200 2010: > On Wednesday, October 13, 2010 18:13:18 Amadeusz Żołnowski wrote: > > Excerpts from Mike Frysinger's message of Wed Oct 13 23:46:43 +0200 2010: > > > On Wednesday, October 13, 2010 15:57:17 Amadeusz Żołnowski wrote: > > > > And why putting different tasks into one function? > > > > > > for the same reason we dont have separate test binaries: test_exist, > > > test_file, test_dir, etc... > > > > > > it makes more sense in my mind to combine the functionality. > > > > So the only argument for having more complicated, less intuitive and > > less readable function is the old 'test' program? Please, reconsider my > > solution with more reason. > > we prioritize differently. i prefer unified code with options. In which part it's unified? As I said it doesn't conform much to 'test' convention. > you preferred unrolled duplicated code. What I'm duplicating? Lines "local f", "for f; do" or "}"? And what's bad about it while still having less LOC? > > Moreover we're using 'test' as '[[ … ]]' which changes much in readability. > > what are you talking about ? no one is using `test` in their code and if > they > are, their code is broken. none of the stuff ive posted is running `test`. I've messed up with that paragraph. The point was that "path_exists -a" is even less readable than "test -e something". As you've said you wouldn't use "test -e" syntax instead of "[[ -e ]]", but let's skip that part… -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
On Wednesday, October 13, 2010 18:13:18 Amadeusz Żołnowski wrote: > Excerpts from Mike Frysinger's message of Wed Oct 13 23:46:43 +0200 2010: > > On Wednesday, October 13, 2010 15:57:17 Amadeusz Żołnowski wrote: > > > And why putting different tasks into one function? > > > > for the same reason we dont have separate test binaries: test_exist, > > test_file, test_dir, etc... > > > > it makes more sense in my mind to combine the functionality. > > So the only argument for having more complicated, less intuitive and > less readable function is the old 'test' program? Please, reconsider my > solution with more reason. we prioritize differently. i prefer unified code with options. you preferred unrolled duplicated code. > Moreover we're using 'test' as '[[ … ]]' which changes much in readability. what are you talking about ? no one is using `test` in their code and if they are, their code is broken. none of the stuff ive posted is running `test`. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
Excerpts from Mike Frysinger's message of Wed Oct 13 23:46:43 +0200 2010: > On Wednesday, October 13, 2010 15:57:17 Amadeusz Żołnowski wrote: > > And why putting different tasks into one function? > > for the same reason we dont have separate test binaries: test_exist, > test_file, test_dir, etc... > > it makes more sense in my mind to combine the functionality. > -mike So the only argument for having more complicated, less intuitive and less readable function is the old 'test' program? Please, reconsider my solution with more reason. Moreover we're using 'test' as '[[ … ]]' which changes much in readability. Next thing is that '-a' and '-o' don't strictly conform to 'test' convention. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
On Wednesday, October 13, 2010 15:57:17 Amadeusz Żołnowski wrote: > And why putting different tasks into one function? for the same reason we dont have separate test binaries: test_exist, test_file, test_dir, etc... it makes more sense in my mind to combine the functionality. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
On Wednesday, October 13, 2010 15:37:02 Ulrich Mueller wrote:
> > On Wed, 13 Oct 2010, Mike Frysinger wrote:
> > # If no paths are specified, then the return value is "false".
>
> For the "or" case that's fine. But for the "and" case, I would expect
> that the function returns true if called with no arguments.
i disagree as the comment says: it's sticking to the bash behavior.
f=
[[ -e ${f} ]] && [[ -e ${f} ]]
[[ -e ${f} ]] || [[ -e ${f} ]]
these both return false. as does this function:
f=
path_exists -a ${f}
path_exists -o ${f}
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
Excerpts from Amadeusz Żołnowski's message of Wed Oct 13 21:20:01 +0200 2010:
> Excerpts from Mike Frysinger's message of Wed Oct 13 20:51:35 +0200 2010:
> > path_exists() {
> > local opt=$1
> > [[ ${opt} == -[ao] ]] && shift || opt="-a"
> >
> > # no paths -> return false
> > # same behavior as: [[ -e "" ]]
> > [[ $# -eq 0 ]] && return 1
> >
> > local p r=0
> > for p in "$@" ; do
> > [[ -e ${p} ]]
> > : $(( r += $? ))
> > done
>
> 1) Why check every path in both "and" and "or" cases?
>
> 2) Even simpler:
> for p; do
> [[ -e $p ]]
> ((r+=$?))
> done
>
> >
> > case ${opt} in
> > -a) return $(( r != 0 )) ;;
> > -o) return $(( r == $# )) ;;
> > esac
> > }
And why putting different tasks into one function? My suggestion:
any_paths() {
local f
for f; do
[[ -e $f ]] && return 0
done
return 1
}
all_paths() {
local f
for f; do
[[ -e $f ]] || return 1
done
return 0
}
Isn't it simpler approach? And have benfits over 2in1:
1) More readable in use.
2) More efficient.
3) 1 + 1 < 2 in this case ;-)
--
Amadeusz Żołnowski
PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
> On Wed, 13 Oct 2010, Mike Frysinger wrote: > # If no paths are specified, then the return value is "false". For the "or" case that's fine. But for the "and" case, I would expect that the function returns true if called with no arguments. Ulrich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
Excerpts from Mike Frysinger's message of Wed Oct 13 20:51:35 +0200 2010:
> path_exists() {
> local opt=$1
> [[ ${opt} == -[ao] ]] && shift || opt="-a"
>
> # no paths -> return false
> # same behavior as: [[ -e "" ]]
> [[ $# -eq 0 ]] && return 1
>
> local p r=0
> for p in "$@" ; do
> [[ -e ${p} ]]
> : $(( r += $? ))
> done
1) Why check every path in both "and" and "or" cases?
2) Even simpler:
for p; do
[[ -e $p ]]
((r+=$?))
done
>
> case ${opt} in
> -a) return $(( r != 0 )) ;;
> -o) return $(( r == $# )) ;;
> esac
> }
--
Amadeusz Żołnowski
PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
here's what i'll commit to eutils.eclass:
# @FUNCTION: path_exists
# @USAGE: [-a|-o]
# @DESCRIPTION:
# Check if the specified paths exist. Works for all types of paths
# (files/dirs/etc...). The -a and -o flags control the requirements
# of the paths. They correspond to "and" and "or" logic. So the -a
# flag means all the paths must exist while the -o flag means at least
# one of the paths must exist. The default behavior is "and". If no
# paths are specified, then the return value is "false".
path_exists() {
local opt=$1
[[ ${opt} == -[ao] ]] && shift || opt="-a"
# no paths -> return false
# same behavior as: [[ -e "" ]]
[[ $# -eq 0 ]] && return 1
local p r=0
for p in "$@" ; do
[[ -e ${p} ]]
: $(( r += $? ))
done
case ${opt} in
-a) return $(( r != 0 )) ;;
-o) return $(( r == $# )) ;;
esac
}
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Truecrypt 3.0 License
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/13/2010 02:47 AM, Ulrich Mueller wrote: >> On Tue, 12 Oct 2010, Dane Smith wrote: > >> I would like to add the license for truecrypt-7.0 to Portage. Link >> is here http://www.truecrypt.org/legal/license > > It says "TrueCrypt License Version 3.0" not 7.0? > >> Does this license look ok to everyone? > > It looks very similar to the truecrypt-2.8 license that we already > have. > >> If yes, I'm assuming it's going to go in the same groups as the >> prior truecrypt licenses that are already in Portage? > > I don't see any truecrypt* license in profiles/license_groups so far. > > But to answer the question more generally: A new version of a license > should only be added to groups like FSF-APPROVED or OSI-APPROVED if it > has been approved by these organisations. On the other hand, for > groups like MISC-FREE, it is as you assume. There the presence of a > previous version is a good indication that the new version should also > be added (given that it's similar enough to the previous version). > > Ulrich > On a related note, given their download page, http://www.truecrypt.org/downloads, do you think it's necessary to fetch restrict it? They only "suggest" to point to them. - -- Dane Smith Gentoo Linux Developer -- Crypto and x86 Teams -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMtfsoAAoJEEsurZwMLhUxV90P/3me/3aPV+wqx8qztnXk5SOk NL+vTEzq+R8ZjGKIYDWtg/A942yT5ktN9Qa1jM2sbQNkYEJtlWaXuGnCkAcdvBIf usxbBPY/CV9QXgbJkmtdXJPzITXW7iAMjK4iKoyW/ghCJ6rn3v5vIvR5E6AfKHKA LocX2BCkJXgRH2JxpZ74XjA5feZtkyhO+95EUk/Wqe8Pn08kQTkukr1uJTzzZLQn NhQouWgi5m7FnskQtwOGIVicBITmjBsnOACbdOscX5wLA6sLvzLfd6g+7YFY9TdV IfBcBgo8i2WQx6r3NW5YnOFogZGA5iHsKyG5If0/q0frH6p84BiB4Cq2sVDrDg4o ztVxVuOFe+e3LIdMPs8PTVqBpYkGxbIoLWtPBcemG0K5Lmho7tF/fga6vivKXLlp 9OpItW/H7KJswPqsR0rnKFn2qh+ktCG/RCK9b+QV5gN8ujNFAoYI86uq258dnvuw 33t2UBiu0wHB/4Jnemat2T5UM6pOJuj8dU7MkssKofqLotLleHlJJCTfvGp0IexB KitMDpMIXHEqABbL/K6Wr9lakOEQjAH5ycQ2XA5HxtXAkNNAG+wGM99ikJCAPQJc iMCrYthagQitafcXZJf+606IT9Ve0e9hdGgvucS2SiaSEkglObIxdwFGpbizy1uG Cm8ejXxhf85aWULnWMVF =Axjx -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
On Wednesday, October 13, 2010 12:35:20 Vaeth wrote: > Mike Frysinger wrote: > > relying on an external program > > The point is that external programs can have all sorts of undesired > side effects. For instance, if an directory is not readable (or > readable but not executable or is on $FILESYSTEM with who-knows-what > permissions or accessability problems) it can cause unexpected > errors which otherwise are treated by "standard" shell behavior: > *This* is why the ls is hackish here, not the readability. and if you had read all my replies, you would see i already pointed out this problem with the original code > but your attack is inappropriate: might want to review the meanings of these words. i said your examples were worse, not better. i didnt say anything about you personally. the rest of your e-mail isnt worth responding to, so i wont bother. as most likely will any follow up to this. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
On Wednesday, October 13, 2010 13:26:24 Michał Górny wrote: > On Wed, 13 Oct 2010 18:51:31 +0200 Amadeusz Żołnowski wrote: > > > has_file()? > > > > What it would mean? „Has”? > > It's reference to has() function specified by PMS. 'The file system has > a file named one-of $...@}' :P. the has functions are typically used to look up an item in a list. i'd go with "path_exists" since this is doing -e and not -f. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
On Wed, 13 Oct 2010 18:51:31 +0200 Amadeusz Żołnowski wrote: > > has_file()? > > What it would mean? „Has”? It's reference to has() function specified by PMS. 'The file system has a file named one-of $...@}' :P. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
Excerpts from Michał Górny's message of Wed Oct 13 18:41:54 +0200 2010:
> On Wed, 13 Oct 2010 10:13:58 -0400
> Mike Frysinger wrote:
>
> > > any_exists() {
> > > local f
> > >
> > > for f; do
> > > [[ -e $f ]] && return 0
> > > done
> > >
> > > return 1
> > > }
> >
> > perhaps if it had a better name and were in a common location (eclass)
>
> has_file()?
What it would mean? „Has”?
--
Amadeusz Żołnowski
PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
On Wed, 13 Oct 2010 10:13:58 -0400
Mike Frysinger wrote:
> > any_exists() {
> > local f
> >
> > for f; do
> > [[ -e $f ]] && return 0
> > done
> >
> > return 1
> > }
>
> perhaps if it had a better name and were in a common location (eclass)
has_file()?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
Excerpts from Mike Frysinger's message of Wed Oct 13 16:13:58 +0200 2010:
> On Wednesday, October 13, 2010 04:23:16 Amadeusz Żołnowski wrote:
> > Excerpts from Mike Frysinger's message of Tue Oct 12 22:57:11 +0200 2010:
> > > On Tuesday, October 12, 2010 16:26:31 Jeroen Roovers wrote:
> > > > On Tue, 12 Oct 2010 22:09:06 +0200 Dirkjan Ochtman wrote:
> > > > > On Fri, Oct 1, 2010 at 15:07, Peter Volkov wrote:
> > > > > > [a very thorough review of the openvpn ebuild]
> > > > >
> > > > > Thanks for reviewing, I've fixed most of the issues.
> > > > >
> > > > > >> if [[ -n $(ls /etc/openvpn/*/local.conf 2>/dev/null) ]] ;
> > > > > >>
> > > > > >> then
> > > > > >
> > > > > > I'd suggested [ -e /etc/openvpn/*/local.conf ] here, but probably
> > > > > > there are better alternatives. Also ${ROOT} is missed here.
> > > > >
> > > > > I've put ${ROOT} in, are there no better alternatives? I don't think
> > > > > anyone mentioned any.
> > > >
> > > > for foo in ${ROOT}/etc/openvpn/*/local.conf; do
> > > >
> > > > [ -e ${foo} ] && bar ${foo}
> > > >
> > > > done
> > > >
> > > > If no ${ROOT}/etc/openvpn/*/local.conf is found, it returns the exact
> > > > string; which doesn't exist so Nothing Happens.
> > >
> > > i'd say doing a loop is worse than a `ls` hack. and this has quoting
> > > problems, but that's ancillary ...
>
> > What about defining following function?
> >
> > any_exists() {
> > local f
> >
> > for f; do
> > [[ -e $f ]] && return 0
> > done
> >
> > return 1
> > }
>
> perhaps if it had a better name and were in a common location (eclass)
> -mike
So give it a better name. :-) In this case 'ls' shouldn't hurt anybody,
but such function solves problem in much more elegant manner -
regardless it's definied in an ebuild or eclass.
--
Amadeusz Żołnowski
PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
Mike Frysinger wrote:
> relying on an external program
The point is that external programs can have all sorts of undesired
side effects. For instance, if an directory is not readable (or
readable but not executable or is on $FILESYSTEM with who-knows-what
permissions or accessability problems) it can cause unexpected
errors which otherwise are treated by "standard" shell behavior:
*This* is why the ls is hackish here, not the readability.
About the readability, one can always have different opinions,
but your attack is inappropriate:
> to get a single line of readable code is better than
> multiple lines of code that attempt to do the same thing.
First, my suggestions are not "multiple lines" but only
exactly *two* lines (i.e. only one additional line):
Please compare
set -- "${ROOT}"/etc/openvpn/*/local.conf
if test -e "${1}"
with the "single line of readable code" which contains not less code,
but is only squashed into one line:
if [[ -e $(ls -1 -- "${ROOT}"/etc/openvpn/*/local.conf) ]]
Is this really so much more readable?
(The "--" can be omitted in both code pieces iff portage has a test
that ROOT does not start with "-").
And if you really want only readability, you should like even much
more my second suggestion which could also be squashed as two lines:
Exists() { test -e "${1}"; }
if Exists "${ROOT}"/etc/openvpn/*/local.conf
I would say this is *way* more readable than the complex 1-liner.
Of course, opinions may differ, but I think an unfounded attack as
> your further examples here are even worse on many levels.
is not appropriate here.
Regards
Martin
Re: [gentoo-dev] perl-5.12 news item
> On Wed, 13 Oct 2010, Torsten Veller wrote: > Author: perl-team Maybe it's better to list the real author(s) here? Multiple Author: lines are allowed. Ulrich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
On Wednesday, October 13, 2010 03:08:24 Vaeth wrote:
> Mike Frysinger wrote:
> > > for foo in ${ROOT}/etc/openvpn/*/local.conf; do
> > >
> > > [ -e ${foo} ] && bar ${foo}
> > >
> > > done
> >
> > i'd say doing a loop is worse than a `ls` hack.
>
> Why do you think so? No external program on which you must rely,
> and if you put a "break" in there, the loop is just syntactical.
> Here is another possibility if you do not need positional
> parameters anymore:
>
> set -- "${ROOT}"/etc/openvpn/*/local.conf
> if test -e "${1}"
> then ...
> fi
>
> And if you do need, you can write a function:
>
> Test2() {
> test "${1}" "${2}"
> }
>
> if Test2 -e "${ROOT}"/etc/openvpn/*/local.conf
> then ...
> fi
relying on an external program to get a single line of readable code is better
than multiple lines of code that attempt to do the same thing. your further
examples here are even worse on many levels.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
On Wednesday, October 13, 2010 04:23:16 Amadeusz Żołnowski wrote:
> Excerpts from Mike Frysinger's message of Tue Oct 12 22:57:11 +0200 2010:
> > On Tuesday, October 12, 2010 16:26:31 Jeroen Roovers wrote:
> > > On Tue, 12 Oct 2010 22:09:06 +0200 Dirkjan Ochtman wrote:
> > > > On Fri, Oct 1, 2010 at 15:07, Peter Volkov wrote:
> > > > > [a very thorough review of the openvpn ebuild]
> > > >
> > > > Thanks for reviewing, I've fixed most of the issues.
> > > >
> > > > >> if [[ -n $(ls /etc/openvpn/*/local.conf 2>/dev/null) ]] ;
> > > > >>
> > > > >> then
> > > > >
> > > > > I'd suggested [ -e /etc/openvpn/*/local.conf ] here, but probably
> > > > > there are better alternatives. Also ${ROOT} is missed here.
> > > >
> > > > I've put ${ROOT} in, are there no better alternatives? I don't think
> > > > anyone mentioned any.
> > >
> > > for foo in ${ROOT}/etc/openvpn/*/local.conf; do
> > >
> > > [ -e ${foo} ] && bar ${foo}
> > >
> > > done
> > >
> > > If no ${ROOT}/etc/openvpn/*/local.conf is found, it returns the exact
> > > string; which doesn't exist so Nothing Happens.
> >
> > i'd say doing a loop is worse than a `ls` hack. and this has quoting
> > problems, but that's ancillary ...
> What about defining following function?
>
> any_exists() {
> local f
>
> for f; do
> [[ -e $f ]] && return 0
> done
>
> return 1
> }
perhaps if it had a better name and were in a common location (eclass)
-mike
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: perl-5.12 news item
Hi, Torsten Veller : > This will be committed before the arch teams stabilize > dev-lang/perl-5.12.2-r1. Maybe you should make an agreement with arches about a fixed date. They signal their ok after testing thoroughly in, say, two days and you immediately commit the news. > Display-If-Installed: > Run `perl-cleaner --all` after upgrading to a new Perl version! In my opinion you should move this sentence one or two paragraphs down, to emphasize more. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Truecrypt 3.0 License
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/13/10 02:47, Ulrich Mueller wrote: >> On Tue, 12 Oct 2010, Dane Smith wrote: > >> I would like to add the license for truecrypt-7.0 to Portage. Link >> is here http://www.truecrypt.org/legal/license > > It says "TrueCrypt License Version 3.0" not 7.0? > The license version is 3.0. It's for software version truecrypt-7.0a. >> Does this license look ok to everyone? > > It looks very similar to the truecrypt-2.8 license that we already > have. > >> If yes, I'm assuming it's going to go in the same groups as the >> prior truecrypt licenses that are already in Portage? > > I don't see any truecrypt* license in profiles/license_groups so far. > > But to answer the question more generally: A new version of a license > should only be added to groups like FSF-APPROVED or OSI-APPROVED if it > has been approved by these organisations. On the other hand, for > groups like MISC-FREE, it is as you assume. There the presence of a > previous version is a good indication that the new version should also > be added (given that it's similar enough to the previous version). > > Ulrich > Ok. Given this information, I will be committing this license along with the new truecrypt version later tonight unless someone raises a concern. Thanks! - -- Dane Smith Gentoo Linux Developer -- Crypto, x86 teams -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMtaMGAAoJEEsurZwMLhUxg6EP/jm/57QqW8McefIY+Du7AWeI szZqhxjZlblBpXyDnjG+ucNWmHektXsgIOuLwvETA5tU0ruqmzYmfkV/r2KMQSR7 M6cSpogCUV/6AvHXZgFogLNmIj8hbF28GqcGw8JsifrDWmMhCgDdryLaTvx/zyBQ j72VcP4JKHmL5Xzw3stTt+SpFI920nspyY0XA9rM3LnYSywvXi5PvrDXMDJkZQSl eGwufLuymVX1QEx+uUR1Yv9Vnk2jepJDlrC+PeUkZWPEy9Xf2QUIOYpmG+KpJQ9c lmX/5MCdjU436JnCrRe2Qdu4weO5M+LwdEU1/RbTkWrMOtiH95NAY00xIcC9/PKZ JGC/0HYqi2Y+XIUty0MZl/oRpGaM58rjzTeshkiNGUBeuy8mGNjQLo03byqQuGNL KaaBnZKGXjhTGTsf16oQe+fr/hHZbnZeJJ9B4PrZsHaYVyWdm71K6np8B4wF3UTc emT8RSYjCmek7wPmbIlNwVrlcfptPU0jmBLdF2WHdOq2zr2pHWjdf2OMYB1tBzri DuQ4s1gpctmUqUEngBiPlgl6bLnzRs2fK0R7bLRFdhse/f6nulONZAj4POqxF6Yy 92IhcN6+E6GvbjuzbpIrpC46pqVPpoVo2NnGh/1iCCUdpcKjCCJXB8zhbO+ClM+6 d37LVRlldgFpeAVxIG6t =LfBC -END PGP SIGNATURE-
[gentoo-dev] perl-5.12 news item
Remind users to run perl-cleaner after installing a new perl version. This will be committed before the arch teams stabilize dev-lang/perl-5.12.2-r1. , 2010-10-16-perl-5.12-upgrade-procedure.en.txt Title: Perl 5.12 upgrade procedure Author: perl-team Content-Type: text/plain Posted: 2010-10-16 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: http://search.cpan.org/dist/perl-5.12.2/INSTALL#Changes_and_Incompatibilities `
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
Excerpts from Mike Frysinger's message of Tue Oct 12 22:57:11 +0200 2010:
> On Tuesday, October 12, 2010 16:26:31 Jeroen Roovers wrote:
> > On Tue, 12 Oct 2010 22:09:06 +0200 Dirkjan Ochtman wrote:
> > > On Fri, Oct 1, 2010 at 15:07, Peter Volkov wrote:
> > > > [a very thorough review of the openvpn ebuild]
> > >
> > > Thanks for reviewing, I've fixed most of the issues.
> > >
> > > >> if [[ -n $(ls /etc/openvpn/*/local.conf 2>/dev/null) ]] ;
> > > >>
> > > >> then
> > > >
> > > > I'd suggested [ -e /etc/openvpn/*/local.conf ] here, but probably
> > > > there are better alternatives. Also ${ROOT} is missed here.
> > >
> > > I've put ${ROOT} in, are there no better alternatives? I don't think
> > > anyone mentioned any.
> >
> > for foo in ${ROOT}/etc/openvpn/*/local.conf; do
> > [ -e ${foo} ] && bar ${foo}
> > done
> >
> > If no ${ROOT}/etc/openvpn/*/local.conf is found, it returns the exact
> > string; which doesn't exist so Nothing Happens.
>
> i'd say doing a loop is worse than a `ls` hack. and this has quoting
> problems, but that's ancillary ...
> -mike
What about defining following function?
any_exists() {
local f
for f; do
[[ -e $f ]] && return 0
done
return 1
}
--
Amadeusz Żołnowski
PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
Mike Frysinger wrote:
> > for foo in ${ROOT}/etc/openvpn/*/local.conf; do
> > [ -e ${foo} ] && bar ${foo}
> > done
>
> i'd say doing a loop is worse than a `ls` hack.
Why do you think so? No external program on which you must rely,
and if you put a "break" in there, the loop is just syntactical.
Here is another possibility if you do not need positional
parameters anymore:
set -- "${ROOT}"/etc/openvpn/*/local.conf
if test -e "${1}"
then ...
fi
And if you do need, you can write a function:
Test2() {
test "${1}" "${2}"
}
if Test2 -e "${ROOT}"/etc/openvpn/*/local.conf
then ...
fi
