Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

On 21 May 2016 17:08, Amadeusz Żołnowski wrote: > Mike Frysinger 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

[gentoo-dev] last rites: dev-perl/Gtk2-WebKit

# Andreas K. Hüttel (21 May 2016) # Unmaintained since 2011, needs old webkit-gtk:2 slot that has # security issues, no consumers in tree, bug 573092 # Removal in 30 days dev-perl/Gtk2-WebKit -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org

[gentoo-dev] [PATCH 2/2] Add tests for rebar.eclass

From: Amadeusz Żołnowski --- eclass/tests/rebar_fix_include_path.sh | 159 + eclass/tests/rebar_remove_deps.sh | 99 eclass/tests/rebar_set_vsn.sh | 115 3 files changed, 373

Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Do not modify the HOME variable

On 05/06/2016 08:25 AM, Mike Gilbert wrote: > This was only necessary when we ran phases in parallel. > Also, PMS says this variable should not be modified. > --- > eclass/distutils-r1.eclass | 6 -- > 1 file changed, 6 deletions(-) > > diff --git a/eclass/distutils-r1.eclass

[gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

From: Amadeusz Żołnowski It is an eclass providing functions to build Erlang/OTP projects using dev-util/rebar. All packages in upcoming category dev-erlang are going to use this eclass. --- eclass/rebar.eclass | 223 1

Re: [gentoo-portage-dev] [PATCH v2 2/2] portage.package.ebuild.config: Always export filtered USE_EXPAND vars

On 05/21/2016 12:15 AM, Michał Górny wrote: > Ensure that all USE_EXPAND variables are always exported with filtered > USE flags inside, even if none of those flags are declared in IUSE. > This is the behavior required for EAPI 5+ by the PMS. > > Since the behavior for earlier EAPIs is left

Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

Michał Górny 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

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

Michał Górny 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

Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

On Sat, 21 May 2016 14:26:00 +0100 aide...@gentoo.org wrote: > From: Amadeusz Żołnowski > > It is an eclass providing functions to build Erlang/OTP projects using > dev-util/rebar. All packages in upcoming category dev-erlang are going > to use this eclass. > --- >

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

On Sat, 21 May 2016 14:49:41 +0100 aide...@gentoo.org wrote: > From: Amadeusz Żołnowski > > 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

Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Do not modify the HOME variable

On Fri, 6 May 2016 09:25:50 -0400 Mike Gilbert wrote: > This was only necessary when we ran phases in parallel. > Also, PMS says this variable should not be modified. > --- > eclass/distutils-r1.eclass | 6 -- > 1 file changed, 6 deletions(-) > > diff --git

Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Do not apply patches if DISTUTILS_OPTIONAL is used

On Sun, 15 May 2016 11:30:00 +0200 Michał Górny wrote: > Do not apply PATCHES and user patches (either via the EAPI 6 default or > pre-EAPI 5 code) when DISTUTILS_OPTIONAL is being used. In this case, > distutils functions are usually called conditionally, in a subdirectory, >

Re: [gentoo-dev] Re: [RFC] How to deal with LINGUAS mess?

On Sat, 21 May 2016 11:00:08 +0200 Ulrich Mueller wrote: > > On Sat, 21 May 2016, Michał Górny wrote: > > > I see the following possibilities: > > > 1. We start explicitly listing linguas_* in all ebuilds, no matter > > how tiny they are. Maintainers are required to

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

On Sat, May 21, 2016 at 09:41:28AM +0200, Micha?? Górny wrote > I see the following possibilities: > > 1. We start explicitly listing linguas_* in all ebuilds, no matter how > tiny they are. Maintainers are required to keep IUSE up-to-date > and users are forced to rebuild a lot. This is also a

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

On 05/21/2016 06:08 PM, Amadeusz Żołnowski wrote: > Mike Frysinger 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

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

Mike Frysinger 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

[gentoo-dev] Package up for grabs

Because of the current maintainer not having time to take care of them, the following packages are now up for grabs: app-misc/astrolog

[gentoo-dev] Package up for grabs

Because of the current maintainer not having time to take care of them, the following packages are now up for grabs: dev-db/freetds dev-db/libiodbc dev-libs/libxdiff net-libs/rabbitmq-c

[gentoo-dev] Package up for grabs

Because of the current maintainer not having time to take care of them, the following packages are now up for grabs: dev-python/edpwd net-mail/mhonarc-gentoo

[gentoo-dev] Package up for grabs

Because of the current maintainer not having time to take care of them, the following packages are now up for grabs: games-simulation/corsix-th media-sound/gnaural

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

On 20 May 2016 21:09, Amadeusz Żołnowski wrote: > Mike Frysinger 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 >

[gentoo-dev] Package up for grabs

Because of the current maintainer not having time to take care of them, the following packages are now up for grabs: net-misc/tightvnc sys-fs/davl

[gentoo-dev] Package up for grabs

Because of the current maintainer not having time to take care of them, the following packages are now up for grabs: app-cdr/cdck dev-util/heaptrack sys-process/wait_on_pid

Re: [gentoo-dev] Package up for grabs

> On Sat, 21 May 2016, Pacho Ramos wrote: > Because of the current maintainer not having time to take care of > them, the following packages are now up for grabs: > app-editors/joe > dev-lang/ucblogo > www-apache/mod_limitipconn The Emacs team will take app-editors/joe unless someone else

[gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

From: Amadeusz Żołnowski 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. New version of gawk (not stabilized yet) does support editing

[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

[gentoo-dev] Package up for grabs

Because of the current maintainer not having time to take care of them, the following packages are now up for grabs: media-sound/aacgain net-dialup/dtrace

[gentoo-dev] Package up for grabs

Because of the current maintainer not having time to take care of them, the following packages are now up for grabs: dev-lang/io dev-lang/srf

[gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

From: Amadeusz Żołnowski It is an eclass providing functions to build Erlang/OTP projects using dev-util/rebar. All packages in upcoming category dev-erlang are going to use this eclass. --- eclass/rebar.eclass | 217 1

[gentoo-dev] Package up for grabs

Because of the current maintainer not having time to take care of them, the following packages are now up for grabs: app-editors/joe dev-lang/ucblogo www-apache/mod_limitipconn

[gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

From: Amadeusz Żołnowski 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. New version of gawk (not stabilized yet) does support editing

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

On 05/21/2016 03:41 AM, Michał Górny wrote: > > I see the following possibilities: > #2 is ugly and requires a special case due to a bad choice of variable name; #4 will never work. > 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds have > a good reason to use flags for

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

Amadeusz Żołnowski 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:

Re: [gentoo-dev] Re: [RFC] How to deal with LINGUAS mess?

> On Sat, 21 May 2016, Kent Fredric wrote: > On 21 May 2016 at 21:00, Ulrich Mueller wrote: >> Why would users have to rebuild more often? Language support in a >> package will change with a version bump, when they must rebuild in >> any case. > But changing IUSE would

Re: [gentoo-dev] Re: [RFC] How to deal with LINGUAS mess?

On 21 May 2016 at 21:00, Ulrich Mueller wrote: > Why would users have to rebuild more often? Language support in a > package will change with a version bump, when they must rebuild in any > case. But changing IUSE would cause users to cause rebuilds under --new-use, even though

Re: [gentoo-dev] new developers' keyword requests

On Fri, 20 May 2016 21:47:56 -0700 Matt Turner wrote: > On Thu, May 19, 2016 at 6:36 PM, Daniel Campbell > wrote: > > To make sure I understand what you're getting at, are you saying > > some devs get on board and then request to add keywords to packages >

[gentoo-dev] Re: [RFC] How to deal with LINGUAS mess?

> On Sat, 21 May 2016, Michał Górny wrote: > I see the following possibilities: > 1. We start explicitly listing linguas_* in all ebuilds, no matter > how tiny they are. Maintainers are required to keep IUSE up-to-date > and users are forced to rebuild a lot. Why would users have to rebuild

Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

Michał Górny 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

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

On 21 May 2016 at 19:41, Michał Górny wrote: > Hello, > > > Those of you who read my blog post on LINGUAS [1] may already know > what's going on. For those who didn't, short summary: > > In EAPI 5 and newer, all variables listed in USE_EXPAND are supposed to > be

[gentoo-dev] [RFC] How to deal with LINGUAS mess?

Hello, Those of you who read my blog post on LINGUAS [1] may already know what's going on. For those who didn't, short summary: In EAPI 5 and newer, all variables listed in USE_EXPAND are supposed to be unconditionally exported with their values reduced to enabled USE flags listed in IUSE. In

[gentoo-portage-dev] [PATCH v2 2/2] portage.package.ebuild.config: Always export filtered USE_EXPAND vars

Ensure that all USE_EXPAND variables are always exported with filtered USE flags inside, even if none of those flags are declared in IUSE. This is the behavior required for EAPI 5+ by the PMS. Since the behavior for earlier EAPIs is left undefined and having different behavior would be confusing

[gentoo-portage-dev] [PATCH v2 1/2] portage.package.ebuild.config: Rename iuse_implicit -> iuse_effective

Rename the iuse_implicit variable used in USE_EXPAND handling to iuse_effective, since that is what is actually passed there. Correct naming makes figuring out what the function does much easier. --- pym/portage/package/ebuild/config.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

[gentoo-dev] Re: new developers' keyword requests

Matt Turner posted on Fri, 20 May 2016 21:47:56 -0700 as excerpted: > He's saying people add new packages and then speculatively add keywords > for a bunch of architectures that they haven't tested. This causes > unnecessary packages to be keyworded on archs that don't want them and > can hardly

Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

On Sat, 21 May 2016 00:06:01 +0100 Amadeusz Żołnowski wrote: > >> +rebar_src_install() { > >> + debug-print-function ${FUNCNAME} "${@}" > >> + > >> + local bin > >> + local dest="$(get_erl_libs)/${P}" > >> + > >> + insinto "${dest}" > >> + doins -r ebin > >> + [[ -d

Re: [gentoo-portage-dev] [PATCH 2/2] ebuild.config: Fix filtering all USE_EXPAND variables in EAPI 5+

On Sat, 21 May 2016 00:26:40 +0200 Michał Górny wrote: > Ensure that all USE_EXPAND variables are properly filtered and exported > in EAPI 5 and newer, as required by the PMS. This includes exporting > an empty value if no matching flag is provided in IUSE. > > Bug:

Re: [gentoo-dev] new developers' keyword requests

On 05/20/2016 09:47 PM, Matt Turner wrote: > On Thu, May 19, 2016 at 6:36 PM, Daniel Campbell wrote: >> To make sure I understand what you're getting at, are you saying some >> devs get on board and then request to add keywords to packages that they >> already maintain? > > No,