[gentoo-dev] Re: Packages up for grabs: dev-erlang/*

2019-07-13 Thread Amadeusz Żołnowski
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

2019-07-07 Thread Amadeusz Żołnowski
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

2017-08-24 Thread Amadeusz Żołnowski
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

2017-04-19 Thread Amadeusz Żołnowski
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

2016-08-23 Thread Amadeusz Żołnowski
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

2016-05-29 Thread Amadeusz Żołnowski
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

2016-05-22 Thread Amadeusz Żołnowski
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

2016-05-22 Thread Amadeusz Żołnowski
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

2016-05-21 Thread Amadeusz Żołnowski
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

2016-05-21 Thread Amadeusz Żołnowski
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

2016-05-21 Thread Amadeusz Żołnowski
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

2016-05-21 Thread Amadeusz Żołnowski
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

2016-05-21 Thread Amadeusz Żołnowski
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

2016-05-21 Thread Amadeusz Żołnowski
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

2016-05-20 Thread Amadeusz Żołnowski
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

2016-05-20 Thread Amadeusz Żołnowski
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

2016-05-20 Thread Amadeusz Żołnowski
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

2016-05-20 Thread Amadeusz Żołnowski
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

2016-05-20 Thread Amadeusz Żołnowski
"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

2016-05-20 Thread Amadeusz Żołnowski
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

2016-05-19 Thread Amadeusz Żołnowski
"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

2016-05-19 Thread Amadeusz Żołnowski
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

2016-05-19 Thread Amadeusz Żołnowski
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

2016-05-18 Thread Amadeusz Żołnowski
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

2016-05-08 Thread Amadeusz Żołnowski
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

2016-01-24 Thread Amadeusz Żołnowski
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

2016-01-24 Thread Amadeusz Żołnowski
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

2016-01-18 Thread Amadeusz Żołnowski
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,

2016-01-06 Thread Amadeusz Żołnowski
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

2015-08-09 Thread Amadeusz Żołnowski
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

2015-08-08 Thread Amadeusz Żołnowski
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

2015-05-12 Thread Amadeusz Żołnowski
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

2015-02-19 Thread Amadeusz Żołnowski
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

2014-06-09 Thread Amadeusz Żołnowski
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

2014-06-09 Thread Amadeusz Żołnowski
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

2014-01-19 Thread Amadeusz Żołnowski
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?

2013-08-28 Thread Amadeusz Żołnowski
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

2013-02-02 Thread Amadeusz Żołnowski
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

2013-01-07 Thread Amadeusz Żołnowski
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

2012-12-27 Thread Amadeusz Żołnowski
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

2012-10-31 Thread Amadeusz Żołnowski
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

2012-08-21 Thread Amadeusz Żołnowski
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

2012-08-21 Thread Amadeusz Żołnowski
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

2012-08-01 Thread Amadeusz Żołnowski
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

2012-07-31 Thread Amadeusz Żołnowski
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

2012-05-15 Thread Amadeusz Żołnowski
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

2012-04-27 Thread Amadeusz Żołnowski
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

2012-04-27 Thread Amadeusz Żołnowski

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

2012-04-27 Thread Amadeusz Żołnowski
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

2012-04-27 Thread Amadeusz Żołnowski
 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

2012-04-27 Thread Amadeusz Żołnowski
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

2012-04-18 Thread Amadeusz Żołnowski
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

2012-04-18 Thread Amadeusz Żołnowski
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

2012-03-30 Thread Amadeusz Żołnowski
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

2012-03-13 Thread Amadeusz Żołnowski
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

2012-03-13 Thread Amadeusz Żołnowski
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

2012-03-06 Thread Amadeusz Żołnowski
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

2012-02-19 Thread Amadeusz Żołnowski
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

2011-11-14 Thread Amadeusz Żołnowski
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

2011-11-14 Thread Amadeusz Żołnowski
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

2011-11-13 Thread Amadeusz Żołnowski
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

2011-11-13 Thread Amadeusz Żołnowski
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

2011-09-22 Thread Amadeusz Żołnowski
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

2011-09-13 Thread Amadeusz Żołnowski
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

2011-09-13 Thread Amadeusz Żołnowski
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

2011-09-13 Thread Amadeusz Żołnowski
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

2011-09-09 Thread Amadeusz Żołnowski
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

2011-09-07 Thread Amadeusz Żołnowski
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

2011-09-07 Thread Amadeusz Żołnowski
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?

2011-07-30 Thread Amadeusz Żołnowski
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

2011-06-20 Thread Amadeusz Żołnowski
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

2011-05-17 Thread Amadeusz Żołnowski
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

2011-04-30 Thread Amadeusz Żołnowski
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

2011-04-10 Thread Amadeusz Żołnowski
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!

2011-03-31 Thread Amadeusz Żołnowski
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!

2011-03-30 Thread Amadeusz Żołnowski
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!

2011-03-30 Thread Amadeusz Żołnowski
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!

2011-03-29 Thread Amadeusz Żołnowski
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!

2011-03-29 Thread Amadeusz Żołnowski
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

2011-03-21 Thread Amadeusz Żołnowski
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

2011-03-10 Thread Amadeusz Żołnowski
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

2011-03-10 Thread Amadeusz Żołnowski
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

2011-02-26 Thread Amadeusz Żołnowski
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

2011-01-14 Thread Amadeusz Żołnowski
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

2011-01-13 Thread Amadeusz Żołnowski
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

2010-10-17 Thread Amadeusz Żołnowski
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

2010-10-13 Thread Amadeusz Żołnowski
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

2010-10-13 Thread Amadeusz Żołnowski
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

2010-10-13 Thread Amadeusz Żołnowski
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

2010-10-13 Thread Amadeusz Żołnowski
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

2010-10-13 Thread Amadeusz Żołnowski
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