[gentoo-dev] Re: Packages up for grabs: dev-erlang/*
I have removed myself from maintainers and dev-erlang has no more maintainers. I removed myself from ejabberd maintainers as well, but that is still maintained by Hanno. Hanno, given that you are the only maintainer of ejabberd now, you may need to look at dev-erlang/* packages. I'm happy to help get you started. :-) It would be ideal if someone with any interest in Erlang would take those over. Thanks, -- aidecoe aide...@gentoo.org writes: > Hi, > > I'm finding hard to get time and enough interest in maintaing > net-im/ejabberd and its deps at dev-erlang/*. > > Please feel free to take over. I'm happy to help to get anyone started. > > Thanks, > -- aidecoe signature.asc Description: PGP signature
[gentoo-dev] Re: Package up for grabs: sys-apps/firejail and sys-apps/firejail-lts
Hi, I have just removed myself from maintainers and assigned bugs to maintainer-needed. -- aidecoe signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Help maintaining dev-erlang and ejabberd
Hi R0b0t1, Thank you for you interest. Any help is welcome. You don't need to be experienced in writing ebuilds too much, but I'd expect some insight or some interest in Erlang to figure out why the hell sometimes a package just doesn't compile. Please look at bug reports related to dev-erlang and ejabberd. Toralf has reported lots of bugs. Cheers, -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] News item: changed default bedup configuration file in >=app-backup/burp-2.0.0
Gokturk Yuksek <gokt...@gentoo.org> writes: > Overall, my impression is that people handle conf file changes in > pkg_postinst() with REPLACING_VERSIONS rather than news items. +1. And it could be automated for the user, couldn't be? Cheers, -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Lastrites: app-editors/gobby
Pacho Ramos <pa...@gentoo.org> writes: > # Pacho Ramos <pa...@gentoo.org> (21 Aug 2016) > # Unmaintained, all versions broken in several ways, bug #465604 > # Removal in a month. > app-editors/gobby That's a pity, because it's still developed and looks like a really good, rich tool. No one uses it? -- Amadeusz Żołnowski signature.asc Description: PGP signature
[gentoo-dev] New category: dev-erlang
Hi, I'd like to add a new category for Erlang libraries: dev-erlang. Initially it's going to have 27 packages. Cheers, Amadeusz Żołnowski --- From 69b6a4f2449d420f02c6c9849885e37457cf9fbd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Amadeusz=20=C5=BBo=C5=82nowski?= <aide...@gentoo.org> Date: Sat, 6 Feb 2016 22:41:43 + Subject: [PATCH] dev-erlang: Add new category --- profiles/categories | 1 + 1 file changed, 1 insertion(+) diff --git a/profiles/categories b/profiles/categories index c9d7f03..44414d4 100644 --- a/profiles/categories +++ b/profiles/categories @@ -31,6 +31,7 @@ dev-cpp dev-db dev-dotnet dev-embedded +dev-erlang dev-games dev-go dev-haskell -- 2.8.3 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar
Michał Górny <mgo...@gentoo.org> writes:
>> +# @FUNCTION: erebar
>> +# @USAGE:
>> +# @DESCRIPTION:
>> +# Run rebar with verbose flag. Die on failure.
>> +erebar() {
>> +debug-print-function ${FUNCNAME} "${@}"
>> +
>> +(( $# > 0 )) || die "erebar: at least one target is required"
>> +
>> +local -x ERL_LIBS="${EPREFIX}$(get_erl_libs)"
>> +rebar -v skip_deps=true "$@" || die "rebar $@ failed"
>
> Maybe 'die -n', for consistency with emake?
Yes, just for consitency...
>> +# @FUNCTION: rebar_src_prepare
>> +# @DESCRIPTION:
>> +# Prevent rebar from fetching in compiling dependencies. Set version in
>> project
>
> I think this sentence is incorrect.
Yes, "in" -> "and". Thanks for catching this!
> I think I have no further comments, so the two things above
> considered, looks good to go.
Thank you for review!
I have pushed eclass along with tests. Feel free to comment on tests
later.
-- Amadeusz Żołnowski
signature.asc
Description: PGP signature
[gentoo-dev] Closed: [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Mike Frysinger <vap...@gentoo.org> writes:
> neither of those are terribly compelling and can be written in sed.
> you want to do a match & replace in that just as easily. roughly:
> sed -i \
> -e '/{[[:space:]]*deps[[:space:]]*,\/,\/}/{s:.*:{deps, []}:}' \
> foo
Oh, I know how to use sed on a single line. What if deps tuple
spans over multiple line which is usually the case? I have an idea how
to do it in sed but awk is much simpler to approach this.
> because no one else is using it or cares about it. we've gotten by
> for more than 10 years at this point w/out someone asking for this.
Or met the same argument and given up... ;-)
> if you really want it in rebar, then just DEPEND on gawk and use the
> inplace flag in your code. then there's no need for eawk anywhere.
Already did that. At the beggining I wanted to use sponge from moreutils
but I assumed it's not desired to depend on some tool not in @system or
specific gawk implementation and version (which is not even stabilized
yet) just for eclass/ebuild internals. But apparently it's fine, so I
did that, as I've said in some other response.
--
Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar
Michał Górny <mgo...@gentoo.org> writes:
>> +# Run rebar with verbose flag. Die on failure.
>> +erebar() {
>> +debug-print-function ${FUNCNAME} "${@}"
>> +
>> +(( $# > 0 )) || die 'erebar: at least one target is required'
>
> Why not [[ $# -gt 0 ]]? It's the first time I see someone using (( ))
> for conditionals.
'>' reads better than some '-gt'.
>> +evar_push ERL_LIBS
>> +export ERL_LIBS="${EPREFIX}$(get_erl_libs)"
>
> local -x ERL_LIBS=...
>
> We don't really have to employ terribly ugly eval hackery to have
> a local variable.
Fixed. I hoped there's better way! (-:
> I meant indent like this:
>
> + eawk rebar.config \
> + -v erl_libs="${erl_libs}" -v pn="${pn}" -v pv="${pv}" \
> + '/^{[[:space:]]*erl_opts[[:space:]]*,/, /}[[:space:]]*\.$/ {
> + pattern = "\"(./)?deps/" pn "/include\"";
> + if (match($0, "{i,[[:space:]]*" pattern
> "[[:space:]]*}")) {
> + sub(pattern, "\"" erl_libs "/" pn "-" pv
> "/include\"");
> + }
> + print $0;
> + next;
> + }
> + 1
> + ' || die "failed to fix include paths in rebar.config"
OK.
>> + insinto "${dest}"
>> +doins -r ebin
>> +[[ -d include ]] && doins -r include
>> +[[ -d bin ]] && for bin in bin/*; do dobin "$bin"; done
>> +[[ -d priv ]] && cp -pR priv "${ED}${dest}/"
>
> Missing ||die. Just don't do it as one-liner :-P.
You've got me! ;-)
Thanks,
--
Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Michał Górny <mgo...@gentoo.org> writes:>
>> +# Following commands should always succeed unless something weird is
>> going
>> +# on.
>> +cat "${tmpf}" >"${f}" || die 'failed to replace source file' || return
>> +rm "${tmpf}" || die "failed to remove temporary file"
>
> Any reason not to use mv here? Aside to making this simpler, it would
> also prevent this from rewriting contents of hardlinked files.
Permissions of ${f} wouldn't be preserved.
>> +return 1
>> +}
>> +
>> +tbegin "preserves permissions"
>> +
>> +cd "${tmpdir}" || tend $?
>
> This doesn't terminate tests. So you'll end up creating files
> in the wrong directory.
Of course! :-/ Probably it would be best to put each test case in a
function. I have the same issue in tests for rebar.eclass. Thanks!
PS. As of discussion with robbat2, I am probably going to depend on
gawk-4.1 (which has in-place edit feature) and use it explicitely in
rebar.eclass and some other ebuilds where I meant to use eawk. robbat2
has already requested stabilization of gawk-4.1.
Thanks,
-- Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Mike Frysinger <vap...@gentoo.org> writes: >> The same "sed -i" is used. I have some configs to edit in place in >> src_prepare(). It's easier with awk rather than sed. > > again, provide an example. one or two uncommon use cases doesn't justify > being added to eutils. See rebar.eclass review where it is used. Later ejabberd ebuild I'm going to add uses it as well. This function is too generic to be in rebar.eclass, so I have decided to move it to eutils. What is the problem with adding it to eutils? -- Amadeusz Żołnowski signature.asc Description: PGP signature
[gentoo-dev] Re: [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
aide...@gentoo.org writes:
> +tbegin "preserves permissions"
> +
> +cd "$(emktemp -d)"
tests-common.sh already creates tmp directory, so better would be:
cd "${tmpdir}" || tend $?
-- Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Amadeusz Żołnowski <aide...@gentoo.org> writes: > Indeed. So one of these: > > a) eawk > b) eawk -- > c) eawk -- Ups, actually (c) wouldn't be correct either, so only (a) and (b) and I'd just stick to (a) to not complicate things. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar
Michał Górny <mgo...@gentoo.org> writes: >> >> + [[ -d include ]] && doins -r include >> >> + [[ -d bin ]] && for bin in bin/*; do dobin "$bin"; done >> > >> > Please don't do inlines like this. >> >> Is there a particular problem with this? > > Readability and maintainability. At some point someone may want to > extend this, and it will no longer work as one-liner. That's rather subjective. Given the context I find concise. When uninlined it takes 4 lines more, gets out of context and looks more noisy to me. If someone would like to extend the inline version it could be uninlined at that point. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar
Peter Stuge <pe...@stuge.se> writes:
>> +pushd "${EPREFIX}$(get_erl_libs)" >/dev/null
>> +for p in ${pn} ${pn}-*; do
>> +if [[ -d ${p} ]]; then
>> +echo "${p#${pn}-}"
>> +return 0
>
> No popd on success?
Thanks for catching this up! Fixed.
>> +local tmpf="$(emktemp)"
>> +
>> +cat "${f}" >"${tmpf}" || return 1
>> +awk "$@" "${tmpf}" >"${f}"
>> +}
>
> Wouldn't it be nicer to cut cat, awk > $tmpf && mv $tmpf $f ?
No. Please see separate review of eawk where it is explained.
Thanks,
-- Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar
Michał Górny <mgo...@gentoo.org> writes:
>> +export ERL_LIBS="${EPREFIX}$(get_erl_libs)"
>
> I think calling get_libdir in global scope is forbidden. You should
> really export this somewhere in phase function.
Fixed.
>> +# @FUNCTION: _find_dep_version
>
> Namespace it, please. Just in case.
Fixed.
>> +_find_dep_version() {
>> [...]
>> +pushd "${EPREFIX}$(get_erl_libs)" >/dev/null
>
> || die
>
> [...]
>
>> +popd >/dev/null
>
> || die
Fixed.
>> +eawk() {
>> +local f="$1"; shift
>> +local tmpf="$(emktemp)"
>
> Missing eutils inherit for EAPI 6.
Fixed.
>> +# @FUNCTION: erebar
>> +# @USAGE:
>> +# @DESCRIPTION:
>> +# Run rebar with verbose flag. Die on failure.
>> +erebar() {
>> +debug-print-function ${FUNCNAME} "${@}"
>> +
>> +rebar -v skip_deps=true "$1" || die "rebar $1 failed"
>> +}
>
> Any reason it doesn't pass all the parameters? This inconsistency with
> emake etc. could be mildly confusing, esp. that you don't check for
> wrong argc.
Fixed.
>> +# @FUNCTION: rebar_fix_include_path
>> +# @USAGE: []
>> +# @DESCRIPTION:
>> +# Fix path in rebar.config to 'include' directory of dependant
>> project/package,
>> +# so it points to installation in system Erlang lib rather than relative
>> 'deps'
>> +# directory.
>> +#
>> +# is optional. Default is 'rebar.config'.
>
> Is it likely that you would be passing different values to it? Maybe it
> would be reasonable to make this an eclass variable.
Unlikely. But I'd better just remove these parameters rather than
defining as eclass variable.
>> +eawk "${rebar_config}" \
>> +-v erl_libs="${erl_libs}" -v pn="${pn}" -v pv="${pv}" \
>> +'/^{[[:space:]]*erl_opts[[:space:]]*,/, /}[[:space:]]*\.$/ {
>> +pattern = "\"(./)?deps/" pn "/include\"";
>> +if (match($0, "{i,[[:space:]]*" pattern "[[:space:]]*}")) {
>> +sub(pattern, "\"" erl_libs "/" pn "-" pv "/include\"");
>> +}
>> +print $0;
>> +next;
>> +}
>> +1
>> +' || die "failed to fix include paths in ${rebar_config}"
>
> I suggest you indent this a bit more since it feels like you start at
> two tabs and finish at zero.
How? Add space between "'" and "||" like follows?
+ eawk "${rebar_config}" \
...
+ print $0;
+ next;
+}
+1
+' || die "failed to fix include paths in ${rebar_config}"
It looks a bit weird as well...
>> +# @FUNCTION: rebar_src_prepare
>> +# @DESCRIPTION:
>> +# Prevent rebar from fetching in compiling dependencies. Set version in
>> project
>> +# description file if it's not set.
>> +#
>> +# Existence of rebar.config is optional, but file description file must
>> exist
>> +# at 'src/${PN}.app.src'.
>
> Wouldn't it be reasonable to make this configurable? Of course, it
> might be better to leave it for a possible future extension when
> it becomes necessary.
Which part you mean? 'src/${PN}.app.src'? Fixed: REBAR_APP_SRC eclass var.
>> +rebar_src_prepare() {
>> +debug-print-function ${FUNCNAME} "${@}"
>> +
>> +rebar_set_vsn
>> +[[ -f rebar.config ]] && rebar_remove_deps
>> +}
>
> You're missing obligatory default call for EAPI 6. You should really
> test stuff before submitting it.
Shame I have forgot to test it, sorry. I have completely forgotten about
EAPI 6. Fixed - I have made it working with EAPI 6 and dropped EAPI 5.
>> +# @FUNCTION: rebar_src_install
>> +# @DESCRIPTION:
>> +# Install BEAM files, include headers, executables and native libraries.
>> +# Install standard docs like README or defined in DOCS variable. Optionally
>
> Optionally what? It looks like an unfinished sentence.
Nothing. (-: Some leftover.
>> +rebar_src_install() {
>> +debug-print-function ${FUNCNAME} "${@}"
>> +
>> +local bin
>> +local dest="$(get_erl_libs)/${P}"
>> +
>> +insinto "${dest}"
>> +doins -r ebin
>> +[[ -d include ]] && doins -r include
>> +[[ -d bin ]] && for bin in bin/*; do dobin "$bin"; done
>
> Please don't do inlines like this.
Is there a particular problem with this?
>> +[[ -d priv ]] && cp -pR priv "${ED}${dest}/"
>
> This is about preserving executable bits, correct?
Yes.
Thanks for review.
--
Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Mike Frysinger <vap...@gentoo.org> writes: > On 18 May 2016 22:25, aide...@gentoo.org wrote: >> awk doesn't have the -i option like sed and if editing file in place is >> desired, additional steps are required. eawk uses tmp file to make it >> look to the caller editing happens in place. > > what's your real use case ? i've never once thought "man, i wish i could > run an awk script and modify a file in place". and i write awk most days. The same "sed -i" is used. I have some configs to edit in place in src_prepare(). It's easier with awk rather than sed. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
rindeal <dev.rind...@gmail.com> writes: > Have you guys read > https://stackoverflow.com/questions/16529716/awk-save-modifications-inplace > ? a) mawk doesn't support it. b) 4.1 is not stabilized, yet. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
"Robin H. Johnson" <robb...@gentoo.org> writes:
>> > cp -f "${tmpf}" "$f" || die "copy back failed"
>>
>> Why '-f' is required?
> Corner cases w/ copying and bad ebuild usage (specifically running
> ebuild as two different non-root users during development). Mostly
> habit.
Reading:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html
in 3.a.ii it is stated 'cp' should behave like redirection if file
already exists, but in case it must actually force (3.a.iii) it does
unlink first and in that case permissions of destination are not
preserved. So it should either be 'cp' alone or redirection as I already
have.
> Another thought I had, is that if you're using eawk on something in
> $ROOT, you're also going to clobber ownership, permissions and
> extended attributes.
Yes, that's why I have used stream redirection in the first place to
make it explicit/clear that permissions and attributes are preserved.
> If we declare the calling format in BSD style:
>
>
> Then this is negated, but means you need to be able to find the first
> file in the list, which requires parsing the options correctly.
Which is not even an option here. (Pun intended.)
> Another variation that you haven't considered above is passing
> multiple programs to awk via -e or -f options, in which case there is
> no non-option program argument.
Indeed. So one of these:
a) eawk
b) eawk --
c) eawk --
in (b) and (c) "--" is required. This makes it easy to separate options
From files without parsing args. With (c) we would have interface almost
similar to awk (only that we require "--"). (a) is simplest in
implementation and doesn't require "--". I am not sure which is most
intuitive. What do you think?
-- Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Mart Raudsepp <l...@gentoo.org> writes: > Similarly, I would like that all ebuild that call 'sed' actually DEPEND > on sed, not just half of them. > I would also like that no ebuild would assume packages in @system to be > present, beyond those dictated by PMS (unpackers and such). Please don't divert from the subject of the thread. Thanks, -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
"Robin H. Johnson" <robb...@gentoo.org> writes:
> 1.
> If your AWK command has an error, then this clobbers the file, a
> better variant, with die, would be:
> awk "$@" "$f" >"${tmpf}" || die "awk failed..."
> cp -f "${tmpf}" "$f" || die "copy back failed"
Thanks! On the one hand it's a simple function, and on the other hand
there are several things which can go wrong. I will submit corrected
version with unit test.
Why '-f' is required?
>> # @USAGE:
> This calling format is also a problem if they intended to pass multiple
> files to the command, or if they do so accidentally.
>
> Eg, an unprotected glob in the first argument, eg:
> eawk foo* '/foobar/{$1="x"; print $0}'
>
> If foo1 and foo2 existed, this would be considered as:
> awk foo2 /foobar/{$1="x"; print $0}' foo1
>
> which really will NOT have the desired effect.
I am aware of this. I considered before:
a) eawk files... -- awk_args...
b) eawk awk_args -- pattern files...
making '--' required, but that just complicates usage and function
itself. And anyway isn't it true for any other command with careless
glob use?
I have documented that function takes a file, not files. The effect of
misuse eawk would be awk error. Although maybe it would be useful to
support multiple files? Then I'd go for variant (b) probably.
Cheers,
--
Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Ulrich Mueller <u...@gentoo.org> writes:
> Yes, of course. "|| die -n || return" if you want the function to
> return at that point, if it was called under nonfatal.
>
>> https://blogs.gentoo.org/mgorny/2015/11/13/the-ultimate-guide-to-eapi-6
>
> Note that the ${?} in the code example there is redundant.
Why redundant? I imagine we can call it like:
if ! nonfatal efoo; then
do_something_on_error
fi
can't we?
-- Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Ulrich Mueller <u...@gentoo.org> writes: > The EAPI 6 method would be to use "|| die -n". Then the caller can > either call "eawk" if the function should die automatically, or > "nonfatal eawk" if it should return with an error status. Yes, that seems better. Hasn't it been introduced earlier than in EAPI 6? -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Göktürk Yüksek <gokt...@gentoo.org> writes:
>> +cat "${f}" >"${tmpf}" || return 1
> Why shell redirection with cat instead of cp? both are in coreutils.
I thought cp could overwrite file mode of already existing tmp file, but
actually it doesn't, so cp can be here as well. Is there actual benefit
of using cp here?
> Also, wouldn't the absence of 'die' cause silent breakages?
I want to caller decide whether die or not and what error messge to
give.
Cheers,
--
Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] On banning merge commits
I am working at the moment on debundling ejabberd. It will come with ~30 packages and I will do "git merge --no-ff ejabberd-debundled" because it will actually look less messy. Thanks, -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Herd likely up for grabs: net-im
Hanno Böck <ha...@gentoo.org> writes: >> > [...] >> > >> > net-im/ejabberd : >> >> I have not much knowledge about erlang stuff, but I will take >> ejabberd if noone else wants. Co-maintainers are welcome. > > I would love if ejabberd gets maintained again :-) Lovely! I have added myself and you to maintainers. (-: -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Packages Up For Grabs
Alex Brandt <alund...@gentoo.org> writes: > * app-backup/rdiff-backup Wasn't it meant for removal? -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Herd likely up for grabs: net-im
Michał Górny <mgo...@gentoo.org> writes: > Packages currently in herd along with their other maintainers: > [...] > > net-im/ejabberd : I have not much knowledge about erlang stuff, but I will take ejabberd if noone else wants. Co-maintainers are welcome. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Lastrites: app-admin/rigo, app-misc/magneto-loader, kde-misc/magneto-kde, x11-misc/magneto-gtk, x11-misc/magneto-gtk3, sys-apps/rigo-daemon, sys-apps/magneto-core, net-fs/tahoe-lafs,
Hi, Pacho Ramos <pa...@gentoo.org> writes: > # Pacho Ramos <pa...@gentoo.org> (06 Jan 2016) > # Unmaintained, upstream dead, doesn't work, bug #548920. Removal in a > # month. > app-admin/checkrestart I am taking the package. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] sys-kernel/dracut looking for more maintainers
Hi, prometheanfire, chutzpah and Alexander will take care of Dracut. I will just serve with advice and keep an eye on changes. Thanks, -- Amadeusz Żołnowski signature.asc Description: PGP signature
[gentoo-dev] sys-kernel/dracut looking for more maintainers
Hi, I'm resending e-mail from my gentoo.org address, instead of the private one... so just ignore the previuos thread with this subject. I have not much time [0] to maintain Dracut properly. Moreover I don't use its extra features anymore, so it's hard for me to keep up with changes. From some time Alexander Tsoy follows changes and solves issues, but I think that Dracut needs also a maintainer with rw access who could quickly solve critical issues and test it appropriately. It is especially important to have somebody who would care about Dracut health on OpenRC-based systems. Alexander, maybe you would like to become a Gentoo developer? (-: I could mentor you. I am still going to be involved, but more as a secondary maintainer or mentor, etc. [0] Yes, it actually has something to do with net-mail/notmuch. :-) I'd like to focus more on net-mail/notmuch related packages instead. Thanks, -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail
Robin H. Johnson robb...@gentoo.org writes: TL;DR: As of May 17, @gentoo.org will drop incoming spammy mail instead of delivering it. Speak now or hold your peace. Please no. Even Gmail has sometimes false positives. It is good enough that Spamassassin marks mails and every user can set up rule either to delete or to put to specific maildir. Moreover one sometimes gets mail that sounds like advertisement but is for example an amazing job offer. I wouldn't like to miss that one. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Mailing list for ebuild review
Michael Orlitzky m...@gentoo.org writes: Would anyone else find gentoo-review@lists.g.o useful? I think a lot of simple problems could be quickly caught with a second set of eyeballs. +1 Many opensource projects successfully run code review on mailing lists. Why not try that. But this should be loudly announced. There is already gentoo-dev-help@, but it's /very/ quiet. If we could all agree to subscribe and do reviews there, that would work as well. I didn't even know about gentoo-dev-help and maybe it's not just me. Cheers, -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Re: The state and future of the OpenRC project
Michael Palimaka kensing...@gentoo.org writes: Perhaps we could consider GitLab? +1 on that. I have deployed it recently at work and it seems to perform well. *Really* easy to use. Easy to deploy as well. It's written in Ruby, *not Java*. It's possible to have a basic integartion with external issue trackers. It also has an LDAP auth. +1 on docs. We should focus on forcing people who were involved into OpenRC to document what they know. I could do some contributions to OpenRC, but I don't have time for reverse engineering. I have developed some experimental Plytmouth plugin to OpenRC, but it was really time consuming to guess what does what... We cannot let OpenRC die. It cannot happen that systemd and upstart are the only init systems. -- Amadeusz Żołnowski pgpQ46M0fXYSk.pgp Description: PGP signature
Re: [gentoo-dev] Re: The state and future of the OpenRC project
Rich Freeman ri...@gentoo.org writes: Uh, you can't force anybody to do anything, and most of them are no longer around. You can always encourage or ask nicely. Yes, I meant that: forcing by asking nicely. :-) You can also set a policy of no further commits accepted without accompanying documentation, but that could just as easily result in fewer commits and not more documentation. Yup, that's right, unfortunately. -- Amadeusz Żołnowski pgpkHcxq9buzj.pgp Description: PGP signature
Re: [gentoo-dev] Last rites: sys-apps/usleep
Dion Moult mo...@gentoo.org writes: # Dion Moult mo...@gentoo.org (19 Jan 2014) # Mask for removal in 30 days. usleep is actually provided part of # app-admin/killproc (bug #467212) sys-apps/usleep Veto. app-admin/killproc isn't even keyworded, yet. (Bug #494254). -- Amadeusz Żołnowski pgpv1V6GgHkQg.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
Michał Górny mgo...@gentoo.org writes: I think I'm finally ready to put all the breaking awesomeness that was waiting for the git eclasses. However, I'm wondering what's the best way of proceeding with it. TL;DR any futher, but I have few packages which use git-2 eclass and I wouldn't like to have any breakage, so if you're going to break compatibility, do it in git-2-r1 or whatever new version, please. Regards, -- Amadeusz Żołnowski pgpSWifNxR8xL.pgp Description: PGP signature
Re: [gentoo-dev] Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c
Quoting Pacho Ramos (2013-01-17 20:21:30) # Pacho Ramos pa...@gentoo.org # Still uses depend.php (#449820), upstream dead for ages and # newer versions don't work. Removal in a month. www-apps/online-bookmarks Is there any goog alternative? -- Amadeusz Żołnowski signature.asc Description: signature
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
Hi,
Quoting Pacho Ramos (2013-01-07 10:34:52)
- Eclass was originally oriented to cover those kind of messages that
could be shown by elog first time the package is merged and, later,
rely on people reading that README.gentoo
This would be good - show README.gentoo for first time, and treat it
with config-protect (as Duncan said somewhere) to be sure user is not
going to miss changes (which could be compared with dispatch-conf).
- William asked for version checking support, in that case, what kind
of version checking should be covered?
- There are also a lot of exotic version checkings in the tree
(please grep looking for REPLACING_VERSIONS to see them) that I doubt
we should cover in eclass but, in that case, how to cover them also?
README.gentoo could have only common info wrt package. Things like
alerts that one should reemerge package because of update (which MUST be
checked with REPLACING_VERSIONS to avoid forcing users to check once
again if he/she is really updating from that version which is pretty
annoying).
- A suggestion about looking for ${FILESDIR}/README.gentoo has also
raised, in that case, should eclass look for either option (now
DOC_CONTENTS variable or ${FILESDIR}/README.gentoo)
${FILESDIR}/README.gentoo seems to be most reasonable place since this
file is going to be installed. Putting it next to metadata.xml and
ChangeLog kills the idea, because of no easy way to see diff.
Regards,
--
Amadeusz Żołnowski
signature.asc
Description: signature
Re: [gentoo-dev] app-text/dbacl is up for grabs
Quoting Pacho Ramos (2012-12-27 12:20:11) Steev contacted me few hours ago to tell me he won't maintain dbacl anymore and, then, it's now up for grabs. Thanks for taking care of it If nobody is interested I can take it. -- Amadeusz Żołnowski signature.asc Description: signature
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
Quoting Chris Reffett (2012-10-31 16:17:20)
Yep he should've assign them, but anyway the annoying elog messages
are an issue. And quite few packages suffer from it :-)
It would actually be hard to find useful message which place is in elog
showing up every install. Why not move such thing on Wiki for example?
I disagree on most of them (and have marked the KDE-related bugs as
WONTFIX appropriately). Messages that tell the user about config
options,
...are *really* annoying, especially when you read it 100th time and
especially the one from kdelibs: Your homedir is set to
\${HOME}/.kde4.
or for x functionality install y (at least until we get
SDEPEND or something similar added to portage) should show up every
time in my opinion.
elog message for optional dependencies could be unified if must be
shown every time.
Only initial config and you just enabled (flag) really merits this.
Basically, I would rather the user get too many elog messages than not
If you assume that users time have no value and we can flood them with
meaningless messages.
enough, since I feel that a lot of people skip over them anyway and so
the only display once method makes it far too easy for important
messages to get lost in the shuffle.
If user gets hundreds of such useless messages it is almost sure that
he/she will miss few hidden important messages. The example could be
udev long elog message which ONE time has had hidden very important
message which I have unfortunately missed and ended up with unbootable
system. In current form these messages have no use.
I have already highlighted this problem on mailing list:
Subject: [gentoo-dev] Useless messages (elog, ewarn, etc) in ebuilds
Id: 20120821132457.4319.78667@localhost
--
Amadeusz Żołnowski
signature.asc
Description: signature
[gentoo-dev] Useless messages (elog, ewarn, etc) in ebuilds
Hi, I'd like to call our attention to messages printed by ebuilds for users (elog, ewarn, and so on). We all know that users rarely read them, but this is understandable, since most of them are *completely* useless, most of the rest are confusing, and only couple of them are useful. Who has time to read tens of messages to find one useful sentence? I try to skim all messages and check if there's something new, but if some package has message which fill whole screen and requires from user to make several checks there is almost 100% chance that this new important message is going to be skipped. I'd like to encourage users to fill bugs wrt useless or confusing messages. There are several kind of messages: 1) If you are upgrading from X to Y, then do Z. I see this message in some packages even I have already version Y or later installed. We have has_version function to check if user has actually updated from relevant version. Please use this to not confuse users who installed the package first time or are upgrading from Y to another version. 2) We no longer do something and do something else. This is case similar to (1). We can check if user has upgraded between versions bringing the changes we want call their attention to. 3) You can install Y to have support for Z. This actually is optional dependencies problem, but we can unify printing the list at least. For example: * Optional dependencies: * * category1/pkg1 - description1 * category2/pkg2 - description2 4) If you are using baselayout-2, be sure to add Y to runlevel Z. 5) Y has been removed. Please remove it from your runlevels. We can easily check if user has added Y to runlevel Z. If this is critical that user has to add Y to runlevel Z, then an ebuild should add it itself and inform user about that. If it is not critical it should inform user that Y could be added to runlevel Z only if installed first time, not every upgrade. Same applies to removal - it can be done by an ebuild. 6) USE flag noY is deprecated, please use Y. Cannot we check if user has enabled noY? At least we can check if he/she enabled Y. 7) If you use Y, do something. We can check if Y flag is enabled or Y package is installed and skip the message if it is not. 8) Example configuration file has been installed to Y. We can check if user has already configured a package (check existence of a config file or its modification time). 9) Run revdep-rebuild. We can check if package has been upgraded at least and skip the message if it has been installed first time or the same version has been reinstalled. 10) Y config file has been moved to Z. If you have made changes to Y, migrate them to Z. We can check that in the ebuild and skip message if hasn't done anything to the config file. 11) If something happens, install Y. We can at least check if Y is already installed. *) Other kind of information which appears after EVERY installation. All howtos should go to Gentoo Docs! -- Amadeusz Żołnowski signature.asc Description: signature
Re: [gentoo-dev] Useless messages (elog, ewarn, etc) in ebuilds
Quoting Ciaran McCreesh (2012-08-21 15:35:38) On Tue, 21 Aug 2012 15:24:57 +0200 Amadeusz Żołnowski aide...@gentoo.org wrote: We have has_version function to check if user has actually updated from relevant version. Please use this to not confuse users who installed the package first time or are upgrading from Y to another version. Doing it using has_version isn't really recommended, since... [...] It's thus much better to use REPLACING_VERSIONS (which is plural, and this is important) rather than has_version, if you're asking about the current package rather than another package. Right. Thanks. REPLACING_VERSIONS and REPLACED_BY_VERSION is much better, but for older EAPIs couldn't one set it manually with help of has_version in pkg_setup and check that var later in postinst?. -- Amadeusz Żołnowski signature.asc Description: signature
Re: [gentoo-dev] net-misc/aiccu - maintainer needed
Quoting Maciej Grela (2012-07-31 22:31:53) If you'd be interested in cooperating on this please let me know. There's Proxy Maintaining Team [0] which is better for that, but I could do it, too. [0] http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml -- Amadeusz Żołnowski signature.asc Description: signature
[gentoo-dev] net-misc/aiccu - maintainer needed
I have taken it recently, but realised I'm not going to use aiccu on Gentoo any time soon. Sorry for mess-up. -- Amadeusz Żołnowski signature.asc Description: signature
Re: [gentoo-dev] Packages up for grabs due gmsoft concentrating in hppa work
Excerpts from Pacho Ramos's message of 2012-05-15 13:33:04 +0200: net-misc/aiccu I can take this one. -- Amadeusz Żołnowski signature.asc Description: PGP signature
[gentoo-dev] New license: yEd Software License Agreement
Hi, I'd like to add attached license to portage/licenses/. Any objections? -- Amadeusz Żołnowski yEd Description: Binary data signature.asc Description: PGP signature
[gentoo-dev] Re: New license: yEd Software License Agreement
This license would go to EULA group. Is this correct? -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
Excerpts from Duncan's message of 2012-04-27 15:38:20 +0200: No distribution allowed. You're going to be doing restrict=mirror, correct? Why RESTRICT=mirror? I'd put RESTRICT=fetch, actually. -- Amadeusz Żołnowski signature.asc Description: PGP signature
[gentoo-dev] Re: New license: yEd Software License Agreement
I'd like to add attached license to portage/licenses/. Any objections? Because there seem to be no objection wrt license itself, I've just committed it. I'll wait with adding ebuild until we get some consensus wrt RESTRICT=fetch/mirror. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
We have had a talk about yEd on #gentoo-dev which is worth attaching here: @ulm aidecoe: I suspect that yEd is in violation of the GPL :/ @ulm their package zip file includes JavaHelp classes but no source code for them @ulm and I also don't see it at their site @ulm neither do they include the GPL license text @aidecoe ulm: they provide links in their license @ulm that's not enough @ulm read the GPL ;) @aidecoe yes, i have read @aidecoe some time ago @ulm what's probably worse, they pack that GPLed software into their jar @ulm and in clause 1 of the yed license they forbid to unjar it @aidecoe yes, that's not fair @ulm and in clause 6 they forbid distribution @ulm I'm pretty sure that this contradicts the GPL @ulm aidecoe: that would be another reason for mirror restriction ;) @aidecoe ulm: i'll mail them about it I have just sent nice e-mail to yWorks about this. -- Amadeusz Żołnowski signature.asc Description: PGP signature
[gentoo-dev] plymouth maintainer-needed
Hi, I no longer use plymouth and have no more will to work on it, but because I believe many users use this package it would be good if somebody take maintainership of it. There's only one serious bug opened at this time and there's no much work with this package. I have also written some howto for users: http://dev.gentoo.org/~aidecoe/doc/en/plymouth.xml (Append .src to get the source.) You can move it anywhere you want. Plymouth has plugin I have written for OpenRC (see its openrc use flag) which is more proof-of-concept rather something to be used really seriously, therefore best would be to drop this plugin and support only systemd which is supported by upstream ootb. I'm happy to answer any question and help at the beginning with maintaining it. Cheers, -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] plymouth maintainer-needed
Excerpts from Alex Legler's message of 2012-04-18 16:49:57 +0200: On Wednesday 18 April 2012 16:03:09 Amadeusz Żołnowski wrote: I no longer use plymouth and have no more will to work on it, but because I believe many users use this package it would be good if somebody take maintainership of it. I'll take it for now. Co-maintainers welcome. Thank you! There's only one serious bug opened at this time and there's no much work with this package. I have also written some howto for users: http://dev.gentoo.org/~aidecoe/doc/en/plymouth.xml (Append .src to get the source.) You can move it anywhere you want. I guess this should go to the wiki. I was asked in the past to move howto from wiki to some more reliable place, because wiki used to be offline quite often. Has this been changed? If you move it, please just know me the address so I can redirect users from the old one. Plymouth has plugin I have written for OpenRC (see its openrc use flag) which is more proof-of-concept rather something to be used really seriously, therefore best would be to drop this plugin and support only systemd which is supported by upstream ootb. Works fine for me, so there's no point in dropping it in fear of systemd. Hm… nice. :-) -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Arbitrary breakage: sys-fs/cryptsetup
Excerpts from Samuli Suominen's message of 2012-03-29 19:59:17 +0200: I've been told dracut is able to handle this. Unverified. Dracut doesn't need anything built static. -- Amadeusz Żołnowski signature.asc Description: PGP signature
[gentoo-dev] Re: Usecase for slotted gnupg
Excerpts from Andreas Herz's message of 2012-03-12 23:33:40 +0100:
I use mcabber with gnupg2 and it has no problem with pinentry.
May i ask how you configured mcabber?
Do you use the curses pinentry?
Gtk usually, but curses works fine, too. I haven't configured anything
special in mcabber - just:
set pgp = 1
set pgp_private_key = MY HASH
I use 0.10.1.
Thanks for the hint with keychain, i will try this and also the ttl
stuff.
This is how I run keychain in my ~/.bashrc:
keys=id_dsa id_rsa ABCDEF12 CDF12345 # ssh and gpg priv keys
if [[ $- != *i* ]] ; then
eval `keychain --eval ${keys} --quiet --noask --quick`
# Shell is non-interactive. Be done now!
return
fi
eval `keychain --eval ${keys} --quiet`
[[ $(tty) == /dev/tty[0-9] ]] reset
So when I log into interactive shell first time (or after timeout), I'm
asked for pass phrases to unlock keys, and on non-interactive shell only
special environment vars are set.
I also got it done with masking gnupg2 but i will try your suggestions
so thanks so far. I just hope it will work with mcabber and also mutt
then :)
GnuPG2 should work everywhere today, and if it doesn't work for some
app, then bug should reported for this app. (Although some crypto herd
member could take a voice here or at least confirm, what I wrote.)
Cheers,
--
Amadeusz Żołnowski
signature.asc
Description: PGP signature
[gentoo-dev] Re: Usecase for slotted gnupg
Hm, I have just realised that we're not discussing it on ml, and unnecessarily I've CC'ed it to ml, sorry. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Doubts about need for ewarn when strip-linguas is used
Excerpts from Pacho Ramos's message of 2012-03-06 11:46:15 +0100:
I usually read messages in /var/log/portage/elog/summary.log to simply
warn me about es es_ES LINGUAS not being supported by that package.
That comes from eutils.eclass inside strip-linguas: ewarn Sorry, but
${PN} does not support the LINGUAS: ${nols}
Is this warning really required, personally I know a lot of packages
that don't support spanish translations and I get no warning from them
(as they don't use strip-linguas). When I set LINGUAS variable in my
make.conf I assume a lot of packages won't support spanish
translations, and I see no point on being informed about that for some
packages using strip-linguas.
What do you think?
+1, this warning is annoying.
--
Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: LANG=en_GB.UTF-8 by default
Excerpts from Ben's message of 2012-02-19 03:04:19 +0100: On 19 February 2012 09:00, James Cloos cl...@jhcloos.com wrote: Without LC_COLLATE=C things like [a-z]* gets a false=positive match on files like Makefile. [...] The real fix is to have root be C.UTF-8. Which differs from C only in that the charset is utf-8. In my opinion we should set a default environment with the following values: LANG=en_US.UTF-8 LC_ALL= LC_COLLATE=C This is only on my setups or this is xy_XY.utf8 instead of xy_XY.UTF-8? -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] have portage be quiet by default
Excerpts from Dale's message of 2011-11-14 13:17:28 +0100: Here is some feedback then. I liked it the way it was. When a build fails, I do a one of install of that package and I like to see the output. Why, because sometimes it gives me a hint as to why it failed or something I can google for. If it fails you get tail of build.log, so you see it anyway. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] have portage be quiet by default
Excerpts from Dale's message of 2011-11-14 13:43:36 +0100: Amadeusz Żołnowski wrote: Excerpts from Dale's message of 2011-11-14 13:17:28 +0100: Here is some feedback then. I liked it the way it was. When a build fails, I do a one of install of that package and I like to see the output. Why, because sometimes it gives me a hint as to why it failed or something I can google for. If it fails you get tail of build.log, so you see it anyway. That doesn't always go back far enough tho. I have on my new rig seen the failure be as far back as a couple hundred lines. Well, don't say that if problem is hundreds lines back you search it in that output. I'd use for that purpose less build.log anyway. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] have portage be quiet by default
Excerpts from Thomas Sachau's message of 2011-11-13 13:39:17 +0100: This can be argued from either side, if the default is verbose, you can make it quiet in the default emerge opts and the other way round. So this is no argument for or against default quiet build in my eyes. Not every user studies manpages of every program they use. Making --quiet-build=y default is a *benefit* for people who don't care much. If somebody cares about the output probably will care to read the manpage how to make it verbose. How many emerge users know that option? As already said, it is nice to see, where a build hangs, when some specific task does take longer and until now, it was easy to see, just watch the output. With the new default, you cannot say, what it does, where it may be or if there are many things or just one line taking much time. And you additionally have to go to the build.log manually to actually see something. Build output tells almost nothing about the progress (except of cmake). Many packages compile in few minutes on average machine. I hardly ever experience hangs and if - it's usually for boost. For those few packages it's no harm to check build.log. But --quiet-build=y actually gives more useful and handy info: what is a total progress. Which user cares about which module is actually being compiled? He/she cares more which package out of total is being compiled at the moment. In addition, it is also nice to just a quick look into the console to see, what and where it failed. When it fails, it prints tail of build.log. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] have portage be quiet by default
Excerpts from Thomas Sachau's message of 2011-11-13 14:59:57 +0100: How is that an argument for default quiet build? It is exactly the same argument against default quiet build. If someone does not care, he does not care about the output being verbose or not, so no need to change a default for him. As I have written below, information about overall process is more valuable than some gmake rubbish (to the user) output which slows down build time. And having that shinny human readable output gives actually an information to the reader. And what does a number of users knowing about an option have to do with a default setting? More user-friendly options should be default, not developer-friendly. The discussion started with problem, that build.log could be more verbose, which will clutter users' screen even more. You expect people to manually check the build.log just to see, where it hangs? I prefer checking the console, there i can see it directly and dont have to check for the path of the current build.log and then have to additionally open it manually. So your no harm is plain wrong, since it takes me more time for doing the same thing as before, while i still see no benefit for the change of the default. If you need to watch build output, change defaults. Defaults are for less experienced users, not for us developers or power users. But --quiet-build=y actually gives more useful and handy info: what is a total progress. Which user cares about which module is actually being compiled? He/she cares more which package out of total is being compiled at the moment. If someone does not care about the current state of a compile, he wont care about the total state either. Build output hardly ever says about current state of a compile. If you can tell from the output how much is left for example for firefox - respect. Beside the point, that you can see the total state in the terminal bar (i hope, i got the right name for that thing). This not always work. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Please don't use IUSE=static-libs unless really necessary
Excerpts from Mike Frysinger's message of 2011-09-19 18:05:39 +0200: On Monday, September 19, 2011 11:35:09 Michał Górny wrote: On Mon, 19 Sep 2011 11:11:31 -0400 Mike Frysinger wrote: by that token, i'll go ahead and remove glibc's static libraries since upstream doesn't even support static linking I'm probably ignorant so you'd have to elaborate more on that to make me see a problem there. think about it a little bit. your system is using static binaries right now, and considering you like to push systemd + initramfs so much, i would have thought you'd realize the implications more quickly. Hm, I seem to fail to notice other static binaries than busybox. And I don't think I use any specific configuration which makes me need static binaries; by default, tools that are needed to easily recover a system (busybox/cryptsetup/lvm/etc...) are IUSE=+static, and every binary that goes into initramfs is statically linked. I'd like to notice that's not the case for dracut. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
Hi,
Excerpts from Michal Hrusecky's message of 2011-09-13 13:11:28 +0200:
Comments and improvements are welcome.
Just some minor remarks:
[[ -z ${OPENSUSE_RELEASE} ]] || OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ -n ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ -n ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
You don't need -n/-z with [[.
[[ $var ]] == [[ -n $var ]]
[[ ! $var ]] == [[ -z $var ]]
So:
[[ ${OPENSUSE_RELEASE} ]] OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
obs-service_src_install() {
debug-print-function ${FUNCNAME} $@
debug-print Installing service \${OBS_SERVICE_NAME}\
exeinto /usr/lib/obs/service
doexe ${DISTDIR}/${OBS_SERVICE_NAME}
insinto /usr/lib/obs/service
doins ${DISTDIR}/${OBS_SERVICE_NAME}.service
if [[ -n ${ADDITIONAL_FILES} ]]; then
debug-print Installing following additional files:
debug-print ${ADDITIONAL_FILES}
exeinto /usr/lib/obs/service/${OBS_SERVICE_NAME}.files
for i in ${ADDITIONAL_FILES}; do
doexe ${DISTDIR}/$i
just in case.
done
fi
}
--
Amadeusz Żołnowski
PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
Excerpts from Joshua Kinard's message of 2011-09-13 14:26:02 +0200: You don't need -n/-z with [[. [[ $var ]] == [[ -n $var ]] [[ ! $var ]] == [[ -z $var ]] What about other comparisons, like -f, -e, or -d? Same as inside [, but no need of quotes inside [[. Also, is this a bash4-only thing, or bash3 and/or bash2 as well? I'm not sure. OT: When I was going through recruitment process, dberkholz pointed to me that I use things bash4-only. And again: why we need to stick to ancient 3 version? I would understand pseudo POSIX compatibility, but what is the benefit of bash3 compatibility while bash4 is stable already? -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
Excerpts from Ulrich Mueller's message of 2011-09-13 19:25:59 +0200: On Tue, 13 Sep 2011, Donnie Berkholz wrote: Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. If you read the quoted council log, you'll find that the retroactive change was done because usage of bash 3.2 features in the tree was already widespread at that time. This is very different from the current situation, therefore it is not at all a precedent. Ulrich So we need to do it “illegally” first to make it “legal”? -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] punt app-arch/cpio from system
Excerpts from Robin H. Johnson's message of 2011-09-09 22:25:59 +0200: On Fri, Sep 09, 2011 at 03:11:01PM -0400, Mike Gilbert wrote: On 9/9/2011 2:47 PM, Mike Frysinger wrote: anyone have a good reason for keeping cpio around in the system profile ? -mike The only uses I have seen for cpio are: 1. Working with initramfs archives Genkernel already has the correct dep. Does dracut need it? Yes, looks like dracut does need it added. Done. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: using /libexec
Excerpts from Rich Freeman's message of 2011-09-07 13:22:46 +0200: On Wed, Sep 7, 2011 at 5:27 AM, Michał Górny mgo...@gentoo.org wrote: Old systems should migrate to initramfs, like it was already pointed out before. Breakage is already there, you just don't notice it. Agreed, and once the official docs are updated and a working initramfs is available we can consider moving forward with things that break separate /usr. That seemed to be the general consensus on the other thread. Right now migrating to initramfs won't do any good, as Gentoo doesn't have an initramfs available which mounts /usr. No doubt once Fedora gets theirs working we'll be able to copy it (assuming it is FOSS), or we can write our own. Dracut supports mounting /usr since 013 if it's defined in /etc/fstab on destination rootfs. I'm still busy with my diploma to write Gentoo docs about it and push Dracut into stabilization process, but as soon as I finish I can move it forward. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: using /libexec
Excerpts from Robin H. Johnson's message of 2011-09-07 20:02:57 +0200: On Wed, Sep 07, 2011 at 07:22:46AM -0400, Rich Freeman wrote: Right now migrating to initramfs won't do any good, as Gentoo doesn't have an initramfs available which mounts /usr. No doubt once Fedora gets theirs working we'll be able to copy it (assuming it is FOSS), or we can write our own. The options for this are looking like: - static initramfs that I proposed (WilliamH has an early prototype) - genkernel - dracut WilliamH's prototype seems to mostly work, I just want to polish it some and then release it. I think we can offer it as an easy default to users, since it doesn't need to be rebuilt when the kernel is rebuilt at all. Dracut doesn't need either if we skip to include kernel modules. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
Excerpts from Rich Freeman's message of 2011-07-30 17:10:14 +0200: On Sat, Jul 30, 2011 at 10:59 AM, Samuli Suominen ssuomi...@gentoo.org wrote: 11:39 @aidecoe dracut has module fstab-sys. You might check this out to mount additional stuff before switching to root. If we want to make /usr required on boot we should build this capability into genkernel. Or, we should have genkernel invoke dracut, It's on my responsibilities list and a progress has been made. I'm currently overloaded since few months, but it is eventually going to be. (It's not so simple as just invoking dracut. Integration is a bit more complicated.) or just make dracut the official initramfs tool and document it accordingly. It will take some time to finally integrate dracut into genkernel, but making dracut more official tool until this time is possible to accomplish in the nearest future. Although first we need to introduce /run into stable baselayout. If you all decide on the matter and the way through dracut is chosen, just let me know and I'll try stabilize and write docs about dracut as soon as possible. Despite it's easily possible to workaround the problem with initramfs, it's really bad issue that the world is breaking FHS instead of designing something new. (Yes, I know it's so big deal that's impossible… but… doh…) -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
Excerpts from Michal Januszewski's message of Sun Jun 12 15:21:25 +0200 2011: I have a number of packages in which I have lost interest and which I no longer want to maintain: app-admin/hddtemp I'd take this one. I still have some hard disks, unfortunately. ;-) -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5
Re: [gentoo-dev] rfc: use of the /run directory
Excerpts from Olivier Crête's message of Tue May 17 22:00:41 +0200 2011: On Wed, 2011-05-18 at 01:18 +0530, Nirbheek Chauhan wrote: Maybe you should use /var/tmp for that? Or ~/tmp/ ? OTOH, we could use an rc.conf configuration variable to control whether /tmp is mounted as tmpfs. Having /tmp and /var/tmp as tmpfs sounds like a terrible idea.. I don't think we should facilitate it in any way. I think he just meant that /var/tmp should be used for bigger temporary stuff. This how I use it. /tmp for tiny temporary stuff and /var/tmp/ for bigger which would be good to have preserved between reboots. And this is somehow correct with FHS afaik. -- 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-p2p/transmission: transmission-2.12.ebuild
Excerpts from Samuli Suominen's message of Sat Apr 30 06:39:52 +0200 2011: sources.gentoo.org is for that. ChangeLog is for users, and old is not useful information to them If this is not useful information, then entry about added files is not useful either - user see that files are there. Following that we could eventually leave only entries which point to BugZilla. In fact ChangeLogs don't seem to be very useful to users at all. I think users are more interested in what has changed in the stuff in the package and not the package itself. Although ChangeLogs are useful to us. CVS sucks and it's more comfortable to read ChangeLog file than cvs log. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Using Jabber for developer communication
Excerpts from Dmitry Dzhus's message of Sun Apr 10 13:00:42 +0200 2011: When will Gentoo switch over to glorious and progressive Jabber from outdated and obsolete IRC? You made my day. Thanks! :-) -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Please enhance your USE descriptions!
Excerpts from Alec Warner's message of Thu Mar 31 08:23:45 +0200 2011: On Thu, Mar 31, 2011 at 5:59 AM, Dale rdalek1...@gmail.com wrote: Eray Aslan wrote: In all seriousness, this has been discussed before and it doesn't get any better. I'm not sure how to fix it either. The space for the description is limited. What is the limit? Anyway we can change it, cannot we? And you can always write shortly something better than “Enable support for foo”. On Thu, Mar 31, 2011 at 5:59 AM, Dale rdalek1...@gmail.com wrote: Read the ebuild? Read-the-ebuild? And maybe unpack the archive, check configure's help, read the README, INSTALL and so, and analyze source code to eventually find out what the flag does? This that what user is supposed to do for every package? -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Please enhance your USE descriptions!
Excerpts from James Cloos's message of Wed Mar 30 18:13:21 +0200 2011: j Enables foo intergration j or j Enables support for foo j if it isn't totally clear what foo is Even preferring $C/$PN where $PN is currently used would help, since it makes it clear that the foo is a package. The main problem is that user might not know what kind of “foo” support it is. For example I have “pango” USE flag in sys-boot/plymouth. What would explain to you something like: “Enables support for x11-libs/pango”? And how you would compare it with “Adds support for printing text on splash screen and text prompts, e.g. for password”? -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Please enhance your USE descriptions!
Excerpts from Olivier Crête's message of Wed Mar 30 22:14:30 +0200 2011: On Wed, 2011-03-30 at 21:56 +0200, Amadeusz Żołnowski wrote: The main problem is that user might not know what kind of “foo” support it is. For example I have “pango” USE flag in sys-boot/plymouth. What would explain to you something like: “Enables support for x11-libs/pango”? And how you would compare it with “Adds support for printing text on splash screen and text prompts, e.g. for password”? I'm sorry, but that's a terrible example.. In this case, it shouldn't be a use flag at all. We shoudl avoid having use flag where the description is Adds support for not being completely broken Please… We're not actually discussing about what should be flagged or not, but about descriptions, where I think I have made the point more or less. Justin has pointed problem which is worth our attention. It is not just me being pissed off when reading „Enable support for foo”, there are many users complaining about that. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Please enhance your USE descriptions!
Excerpts from justin's message of Tue Mar 29 16:24:57 +0200 2011: the descriptions of USE flags should explain what the USE is good for. In my opinion some thing like Enables foo intergration or Enables support for foo if it isn't totally clear what foo is, sucks!! There are many, many description which do not tell me as a user without googling what I could enable or not. That doesn't make gentoo very user friendly! So please enhance you descriptions!! I 100% agree with you! This is something what is always pissing me off when reading equery uses foo to find out how to set flags. I'm actually describing even global USE flags in my package's metadata.xml if their purpose might not be clear and I'd like to expect that from others. It is not a problem to write one sentence for each flag while you already know what flag does. Maybe it should even become our policy and not just recommendation? -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Please enhance your USE descriptions!
Excerpts from Angelo Arrifano's message of Tue Mar 29 17:14:48 +0200 2011: On Ter, 2011-03-29 at 17:08 +0200, Amadeusz Żołnowski wrote: I'm actually describing even global USE flags in my package's metadata.xml if their purpose might not be clear and I'd like to expect that from others. It is not a problem to write one sentence for each flag while you already know what flag does. Maybe it should even become our policy and not just recommendation? Why do we have to turn everything into policies? This case would be easily solved by making a list of use flags that we find poorly described, then improving the description of each. It would be hard to find good descriptions. The problem is that even if flag has similar meaning in few packages, it usually adds a bit different functionality and that difference matters. User would like to know what he/she benefits or looses with enabling/disabling the flag. It's not just a matter of one click, it at least minutes of compilation. I think it's a task to package maintainers to review if current descriptions explain what flags in their packages bring to user. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] FEATURES=test, sys-devel/gcc ignored test failures
Excerpts from Paweł Hajdan, Jr.'s message of Mon Mar 21 13:07:33 +0100 2011: My suggestion is to make the src_test empty (I think the default one still calls make). I can produce a patch if needed. What do you think? Maybe restrict? https://bugs.gentoo.org/298014 -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Making largefile a global use
Excerpts from justin's message of Thu Mar 10 09:08:24 +0100 2011: there are not many packages using it, but I will add this flag to another 10. And I think, it is of a general, global meaning. Do you agree in making it a global USE? I'm new here, but I think it would be good idea to list packages using that flag with meaning described by its maintainers and your proposal. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
Excerpts from Jeroen Roovers's message of Thu Mar 10 20:42:29 +0100 2011: For existing bugs, then, NEW bugs should be changed to UNCONFIRMED when they are assigned to bug-wranglers, and to CONFIRMED when they have already been assigned to their maintainers (irrespective of whether they are actually confirmed or not or whether they are deemed to be actual bugs). Status = NEW Assignee = bug-wranglers - Status = UNCONFIRMED Status = NEW Assignee = [maintainer] - Status = CONFIRMED Who confirms the bug? I would expect that CONFIRMED is set by the package maintainer and the one who assigns bugs leaves the status. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
[gentoo-dev] Add USE_EXPAND for dracut
Hello, All IUSE flags in dracut correspond to modules (which are put into /usr/share/dracut/modules.d). Much more intuitive would be to move the flags to DRACUT_MODULES. If nobody objects until Monday 22:00 UTC (is this sufficient or I should wait longer?), I'll add it to profiles/base/make.defaults and commit the ebuild. That ebuild is already posted in bug #353577[0]. [0] https://bugs.gentoo.org/353577 Cheers, -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Need help with updating LVM in genkernel
Excerpts from Sebastian Pipping's message of Fri Jan 14 18:16:22 +0100 2011: and check for another versions. Please do. Getting 2.02.74 to compile too would rock. A patch for --no-export-dynamic (should work, see [1]) is in place already, but more work is needed. If you can help once more, that would be very appreciated. OK, I'll fix it tomorrow. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Need help with updating LVM in genkernel
Excerpts from Sebastian Pipping's message of Thu Jan 13 17:20:00 +0100 2011: I get errors for all of 2.02.28, 2.02.36 and 2.02.74. I've create some draft-patch for lvm 2.02.28. Please let me know if it's OK, and I'll improve it and check for another versions. Patch is posted under bug #255196 [0]. [0] https://bugs.gentoo.org/show_bug.cgi?id=255196 Cheers, -- 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
Excerpts from Mike Frysinger's message of Sun Oct 17 23:33:57 +0200 2010:
On Wednesday, October 13, 2010 19:08:55 Amadeusz Żołnowski wrote:
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:
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?
the file checking status accumulation. extending my code to add more
options in the future is easier as well.
The name doesn't allow for any sensible extension. I'd advise to change
it to 'mtest' (which would stand for multiple test) or something like
that and give up default behaviour. OK, and then your /options way/
starts to make sense. (Although status accumulation has still no benefit
here.)
Having such an 'mtest' we might use it in following way:
mtest -[oa] -[fredcw...] path1 path2 ... pathn
And stil we can do it simpler:
mtest() {
local f log_op=$1 test_op=$2; shift 2
case $log_op in
-a) for f; do
eval [[ $test_op '$f' ]] || return 1
done
return 0
;;
-o) for f; do
eval [[ $test_op '$f' ]] return 0
done
return 1
;;
esac
return -1
}
– it's just a rough draft, proof of concept. You've already gone your
way…
this thread is going nowhere. i believe my proposal is the way to go, and we
arent arguing over anything of too much value (i.e. bike shedding). no one
else has an opinion, so ive gone my route.
Cheers,
--
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
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
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 vap...@gentoo.org 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
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
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
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
