Re: [gentoo-portage-dev] [PATCH 00/10] EAPI 7, part one

2018-03-03 Thread Zac Medico
On 02/26/2018 07:59 AM, Michał Górny wrote:
> Hi, everyone.
> 
> Here's the first part of EAPI 7 support patches. All changes included
> here were tested and should not break anything. I'd like to merge them
> now to avoid having to rebase a very long batch of patches.
> 
> I have added tests for changed ^^/|| behavior. Other changes I've
> tested manually. Please let me know if you feel that any of them
> requires specific tests.
> 
> --
> Best regards,
> Michał Górny
> 
> 
> Michał Górny (10):
>   Enable testing EAPI 7_pre1
>   Use bash-4.2 for all future EAPIs, until declared otherwise
>   Empty ||/^^ REQUIRED_USE groups are no longer true in EAPI 7
>   Empty || *DEPEND group no longer satisfy deps in EAPI 7
>   isolated-functions.sh: Ensure informational command output to stderr
>   Ban dohtml for EAPI 7
>   Ban dolib/libopts for EAPI 7
>   dolib.{a,so}: inline the logic from dolib
>   domo: force /usr prefix in EAPI 7
>   Ban DESTTREE/INSDESTTREE in EAPI 7
> 
>  bin/eapi.sh | 22 --
>  bin/ebuild-helpers/dobin| 16 ++--
>  bin/ebuild-helpers/doconfd  |  4 +-
>  bin/ebuild-helpers/doenvd   |  4 +-
>  bin/ebuild-helpers/doheader |  4 +-
>  bin/ebuild-helpers/dohtml   |  7 +++-
>  bin/ebuild-helpers/doins| 18 ++---
>  bin/ebuild-helpers/dolib| 17 +++-
>  bin/ebuild-helpers/dolib.a  | 52 +++-
>  bin/ebuild-helpers/dolib.so | 54 
> -
>  bin/ebuild-helpers/domo | 21 --
>  bin/ebuild-helpers/dosbin   | 16 ++--
>  bin/isolated-functions.sh   | 30 +++---
>  bin/phase-functions.sh  | 11 +++--
>  bin/phase-helpers.sh| 39 +-
>  bin/save-ebuild-env.sh  |  4 +-
>  pym/portage/__init__.py |  2 +-
>  pym/portage/dep/__init__.py |  7 +++-
>  pym/portage/eapi.py | 10 -
>  pym/portage/tests/dep/testCheckRequiredUse.py   |  5 ++-
>  pym/portage/tests/resolver/test_eapi.py |  9 -
>  pym/portage/tests/resolver/test_required_use.py |  8 
>  22 files changed, 288 insertions(+), 72 deletions(-)

The only problem I found was in the
token_class("__const__/empty-any-of") usage here:

https://github.com/gentoo/portage/pull/261#pullrequestreview-100992073
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] last rites: app-pda/p3nfs

2018-03-03 Thread Andreas K. Huettel
# Andreas K. Hüttel  (03 Mar 2018)
# Fails to build without rpc support in glibc (bug 631044);
# no maintainer, requires obsolete hardware. Removal in
# 30 days.
app-pda/p3nfs

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

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


Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-03-03 Thread Benda Xu
Hi Andreas,

"Andreas K. Huettel"  writes:

> Well, in principle the idea is OK. We already/still keep some old
> glibc, gcc, and binutils versions for that reason.
>
> However, I have a few conditions.
>
> * Only masked. Only prefix keywords.

Not problem for masking.  For keywords, prefix-standalone uses usual
keywords, not prefix keywords.

  
https://wiki.gentoo.org/wiki/Project:Prefix/Technical_Documentation#Search_pathes

> If you really must unmask them in a specific prefix profile, you must
> provide big fat warnings about the resulting security risks.  (I dont
> know how things went in prehistoric times, but recently there have
> been a LOT of glibc-related CVEs. Many fixes can be backported, but
> definitely not all of them.)

Yes, I think that's the way to go to keep users reminded of security
risks involved.

> * No toolchain-glibc.eclass or eblits or similar abominations. Standard QA 
> rules apply.

Agreed!  Old glibc becomes a burden for toolchain-glibc.eclass
maintenance.  We'd better make them standalone.

> * Try to stick to a minimum of required features (and a minimum of required 
> versions).
> We want to strongly avoid adding conditionals to other packages. [#]

Sure, the feature set will be kept bare minimal.  For example, handened
patches will be removed.

> * Please use our gentoo glibc repo to keep track of branches and patchsets.
> Happy to show you the details sometime soon.

Thanks Andreas.  Much appreciated.

> [#] If not for such "old version" considerations, we could soon move the 
> libtirpc headers to the place where the glibc headers used to live. That 
> could 
> save us a ...load of patching and bugfixing. By keeping flexibility and 
> compatibility, that is unfortunately not possible.

That's where I see providing glibc-2.16 and 2.19 in special profiles
might shed light on this delimma.  We keep versions of glibc to make
sure some old systems do not break.  But those systems are not clearly
defined.  We don't have a guideline for when and how to remove them.
(We used to keep them almost indefinitely before the reformation of
toolchain project.)

By explicitly spelling out the range of kernels a specific glibc
supports, and only keeping the minimal set of old versions, the
boundaries are defined.

Cheers,
Benda


signature.asc
Description: PGP signature


[gentoo-portage-dev] [PATCH] repoman: Warn on = dependencies without * or revision

2018-03-03 Thread Michał Górny
Warn if the '=' package dependency operator is used along with pure
version with no revision specified. This means to catch a common mistake
of developers copying '=' from upstream dependency specification while
'~' operator would be more appropriate. This causes unintended depgraph
breakage when the dependencies are revbumped e.g. due to dependency
changes, or prevents people from upgrading.

The developers are given two suggestions: either to use '~' if any
revision is acceptable, or to explicitly specify '-r0' when they really
do accept -r0 only.

Bug: https://bugs.gentoo.org/649482
---
 repoman/pym/repoman/modules/scan/depend/_depend_checks.py | 9 +
 repoman/pym/repoman/qa_data.py| 5 +
 2 files changed, 14 insertions(+)

diff --git a/repoman/pym/repoman/modules/scan/depend/_depend_checks.py 
b/repoman/pym/repoman/modules/scan/depend/_depend_checks.py
index 11435f99e..3e34be5b3 100644
--- a/repoman/pym/repoman/modules/scan/depend/_depend_checks.py
+++ b/repoman/pym/repoman/modules/scan/depend/_depend_checks.py
@@ -153,6 +153,15 @@ def _depend_checks(ebuild, pkg, portdb, qatracker, 
repo_metadata):
qacat, "%s: %s uses the ~ 
operator"
" with a non-zero revision: 
'%s'" %
(ebuild.relative_path, mytype, 
atom))
+   # plain =foo-1.2.3 without revision or *
+   if atom.operator == "=" and '-r' not in 
atom.version:
+   qacat = 'dependency.equalsversion'
+   qatracker.add_error(
+   qacat, "%s: %s uses the = 
operator with"
+   " no revision: '%s'; if any 
revision is"
+   " acceptable, use '~' instead; 
if only -r0"
+   " then please append '-r0' to 
the dep" %
+   (ebuild.relative_path, mytype, 
atom))
 
check_missingslot(atom, mytype, ebuild.eapi, 
portdb, qatracker,
ebuild.relative_path, ebuild.metadata)
diff --git a/repoman/pym/repoman/qa_data.py b/repoman/pym/repoman/qa_data.py
index c6abe1760..7d56ffedc 100644
--- a/repoman/pym/repoman/qa_data.py
+++ b/repoman/pym/repoman/qa_data.py
@@ -51,6 +51,10 @@ qahelp = {
"dependency.badtilde": (
"Uses the ~ dep operator with a non-zero revision part,"
" which is useless (the revision is ignored)"),
+   "dependency.equalsversion": (
+   "Suspicious =-dependency with a specific version and no rev. "
+   "Please either use ~ if any revision is acceptable, or append "
+   "-r0 to silence the warning."),
"dependency.missingslot": (
"RDEPEND matches more than one SLOT but does not specify a "
"slot and/or use the := or :* slot operator"),
@@ -258,6 +262,7 @@ qawarnings = set((
"dependency.badinexp",
"dependency.badmaskedinexp",
"dependency.badtilde",
+   "dependency.equalsversion",
"dependency.missingslot",
"dependency.perlcore",
"DESCRIPTION.toolong",
-- 
2.16.2




[gentoo-dev] last rites: app-text/noweb

2018-03-03 Thread Andreas K. Huettel
# Andreas K. Hüttel  (03 Mar 2018)
# Marked obsolete on CTAN. EAPI=3 ebuild. No consumers.
# Masked for removal in 30 days. Bug 644258
app-text/noweb

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

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


Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-03-03 Thread Benda Xu
Hi Michał,

Michał Górny  writes:

>> I am on the toolchain alias, and I am interested in joining the project.
>> I will be responsible to deal with all the bugs for glibc-2.16 and
>> glibc-2.19.  Bug wranglers' work load does not change.
>> 
>> Yes, I apologize this will generate some noise for toolchain@g.o.  But I
>> anticipate people on the team are interested in receiving those emails.
>
> That's not a solution. That's cheap a cheap excuse that works for one
> package, for today. It does not solve the generic case,

What I ask is a special treatment of glibc.  I do not intend to explore
a generic solution in this thread.  And don't get me wrong, I support
tree cleaning by all means.

Glibc is special, llvm is the only other (not so similar) example.  No
more package will be special like this.  This will not set a bad example
or bad excuses for keeping outdated ebuilds.  I don't see your argument
of generic case.

> it does not mean that other members of toolchain or any other team
> will not end up having to remember extra rules like 'do not remove
> this ebuild because X wants it'.

Is that a problem?  When at least 1 person is eager to maintain an
package, the package could be kept.  Consider that person as the de
facto upstream.

Consider glibc-2.16 as a sys-libs/glibc-revived package that is too
closely connected to sys-libs/glibc be treated as a 2nd package.  Then
the package argument carries to a special version of ebuild.

Cheers,
Benda


Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-03-03 Thread Michał Górny
W dniu sob, 03.03.2018 o godzinie 22∶51 +0900, użytkownik Benda Xu
napisał:
> Hi Michał,
> 
> Michał Górny  writes:
> 
> > > I am sure you are aware that Prefix has two variants: one is
> > > prefix-rpath targeting MacOS, Solaris, AIX, Cygwin, Interix and a subset
> > > of GNU/Linux; the other is prefix-standalone, targeting GNU/Linux and
> > > Android/Linux.[1]
> > > 
> > > For LLVM example, it is prefix-rpath, which hosts its own overlay at
> > > repo/proj/prefix.git.  Besides LLVM there are other hacks at present in
> > > the overlay.  But we still keep the ultimate goal of merging prefix.git
> > > into gentoo.git.
> > 
> > I am also keeping old versions of LLVM for Prefix team. That's why I'd
> > really prefer to get rid of them and have them in some common overlay
> > that all Prefix users can use.
> 
> Yes that's true. The case of LLVM for prefix-rpath is similar as glibc
> for prefix-standalone.
> 
> For the argument of overlay refer to the message below vvv
> 
> > > What we are discussing in this thread, however, is prefix-standalone, it
> > > uses the official gentoo repository without any overlay.  It works
> > > perfectly for kernel-2.6.26+ and linux-3.2+.  So, creating an overlay of
> > > 2 ebuilds for prefix-standalone is an overkill.
> > 
> > Maybe it is. But isn't making maintenance of Gentoo packages more
> > complexity for Prefix an overkill? We are effectively switching
> > from trivial model of 'assign bug with X to maintainer' to checking
> > which maintainer applies to which version of X.
> 
> I am on the toolchain alias, and I am interested in joining the project.
> I will be responsible to deal with all the bugs for glibc-2.16 and
> glibc-2.19.  Bug wranglers' work load does not change.
> 
> Yes, I apologize this will generate some noise for toolchain@g.o.  But I
> anticipate people on the team are interested in receiving those emails.
> 

That's not a solution. That's cheap a cheap excuse that works for one
package, for today. It does not solve the generic case, it does not mean
that other members of toolchain or any other team will not end up having
to remember extra rules like 'do not remove this ebuild because X wants
it'.

-- 
Best regards,
Michał Górny




Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-03-03 Thread Benda Xu
Hi Andreas,

I really appreciate your interest as I am try to convince our fellows.

"Andreas K. Huettel"  writes:

> another option would be to (try to) revive glibc-2.5, 2.12, and 2.17
> instead.

> Yes I know they are even older, but these are the versions that RHEL
> uses, and for which RH still provides support (until 2020 for 2.5,
> 2024 for 2.12)...
> https://sourceware.org/glibc/wiki/Release#Distribution_Branch_Mapping

> That however would require that the RHEL patchsets are public
> somehwere. Which I doubt... after all there's an "E" in RHEL...

> [...]

> ... except that my personal motivation has dropped somewhat when
> noticing that the CentOS package applies 552 (!) patches on top of
> 2.17.

Carrying Redhat patches are not only technical unfeasible, but also out
of our best interest.  The reasons are the following.

glibc-2.5 does not support fortify, thus breaking gentoo version of gcc
since verison 4.3 (Bug 289757).  The original purpose of
prefix-standalone was to introduce newer glibc from gentoo to solve this
issue.  So shipping glibc-2.5 requires maintaining seperate versions of
gcc.

glibc has some tolerance for kernel.  2012 glibc-2.16 supports 2004
linux-2.6.8.  It buys us 8 years!  That's the basis for the magic of
prefix-standalone.  gcc in turn has some tolerance for glibc.  So far
glibc-2.16 is still supported by the newest gcc but glibc-2.5 is
definitely out of the game.

I hear your instinct for RHEL versions for security consideration.  But
in this use case, the kernels are usually outdated for many years and
prone to multiple privilege escalation CVE's.  If the administrators of
these systems cared about security, these antiques wouldn't have existed
in the first place.

Therefore, using edge versions of glibc-2.16 (newest glibc to support
linux 2.6+) and 2.19 (newest glibc to support linux 2.6.16+) makes more
sense.

Yours,
Benda


signature.asc
Description: PGP signature


[gentoo-portage-dev] [PATCH v2 1/2] repoman: Fix default for -e to 'n' (rather than inconsistent False)

2018-03-03 Thread Michał Górny
---
 repoman/pym/repoman/argparser.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/repoman/pym/repoman/argparser.py b/repoman/pym/repoman/argparser.py
index f32972288..b7e6071ba 100644
--- a/repoman/pym/repoman/argparser.py
+++ b/repoman/pym/repoman/argparser.py
@@ -167,7 +167,7 @@ def parse_args(argv, qahelp, repoman_default_opts):
 
parser.add_argument(
'-e', '--include-exp-profiles', choices=('y', 'n'), 
metavar='',
-   default=False,
+   default='n',
help='include exp profiles in dependency checks')
 
parser.add_argument(
-- 
2.16.2




Re: [gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default

2018-03-03 Thread Michał Górny
W dniu sob, 03.03.2018 o godzinie 14∶50 +0100, użytkownik Ulrich Mueller
napisał:
> > > > > > On Sat, 03 Mar 2018, Michał Górny wrote:
> > I don't really want to go into this. As far as I'm concerned, I can
> > leave defunct '-d' and just check dev profiles unconditionally.
> 
> WFM. Or even better, leave defunct -d/--include-dev in place (in order
> not to break peoples' scripts) and add a long --no-include-dev option.
> 

...which would be inconsistent with -e/--include-exp-profiles.

-- 
Best regards,
Michał Górny




Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-03-03 Thread Benda Xu
Hi Michał,

Michał Górny  writes:

>> I am sure you are aware that Prefix has two variants: one is
>> prefix-rpath targeting MacOS, Solaris, AIX, Cygwin, Interix and a subset
>> of GNU/Linux; the other is prefix-standalone, targeting GNU/Linux and
>> Android/Linux.[1]
>> 
>> For LLVM example, it is prefix-rpath, which hosts its own overlay at
>> repo/proj/prefix.git.  Besides LLVM there are other hacks at present in
>> the overlay.  But we still keep the ultimate goal of merging prefix.git
>> into gentoo.git.
>
> I am also keeping old versions of LLVM for Prefix team. That's why I'd
> really prefer to get rid of them and have them in some common overlay
> that all Prefix users can use.

Yes that's true. The case of LLVM for prefix-rpath is similar as glibc
for prefix-standalone.

For the argument of overlay refer to the message below vvv

>> What we are discussing in this thread, however, is prefix-standalone, it
>> uses the official gentoo repository without any overlay.  It works
>> perfectly for kernel-2.6.26+ and linux-3.2+.  So, creating an overlay of
>> 2 ebuilds for prefix-standalone is an overkill.
>
> Maybe it is. But isn't making maintenance of Gentoo packages more
> complexity for Prefix an overkill? We are effectively switching
> from trivial model of 'assign bug with X to maintainer' to checking
> which maintainer applies to which version of X.

I am on the toolchain alias, and I am interested in joining the project.
I will be responsible to deal with all the bugs for glibc-2.16 and
glibc-2.19.  Bug wranglers' work load does not change.

Yes, I apologize this will generate some noise for toolchain@g.o.  But I
anticipate people on the team are interested in receiving those emails.

Cheers,
Benda


Re: [gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default

2018-03-03 Thread Ulrich Mueller
> On Sat, 03 Mar 2018, Michał Górny wrote:

> I don't really want to go into this. As far as I'm concerned, I can
> leave defunct '-d' and just check dev profiles unconditionally.

WFM. Or even better, leave defunct -d/--include-dev in place (in order
not to break peoples' scripts) and add a long --no-include-dev option.

Ulrich


pgppFpmvLee_2.pgp
Description: PGP signature


Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-03-03 Thread Benda Xu
Hi William and Alec,

Yes, I hear you.  

What I want to do is not randomly throwing upstream-unmaintained package
versions into Gentoo tree.  But the opposite, 1 specially maintained
glibc ebuild serving as a compatible layer will isolate the obsolete
linux kernel from the modern Gentoo tree.  Synonymically, 1 glibc ebuild
will allow the rest of the Gentoo tree compile and run on 10+ years old
platforms.

The users trapped with antique OS will be able to use tools from Gentoo,
and Gentoo will expand its horizon for new use cases.

Detailed replies inline, mostly repeating of the above point for special
cases.

William Hubbs  writes:

> I am with mgorny on this, this sort of specialized support does not
> belong in the main tree.
>
> The kernel versions you are talking about aren't even supported by the
> upstream kernel folks any more -- the oldest lts version is 3.2.99.

I am with you.  I don't care about outdated kernels.  Therefore I am
interested in a compatible layer that screens out the kernel.  So far, 1
glibc does the job.

Alec Warner  writes:

> So I actually originally thought this as well and settled on some
> logic that is:
>
> The problem we are trying to solve is supporting very old
> distros. This has two impacts on the tree:

> a) Very old versions of some packages stay in the tree because they
> are needed to support these old platforms.

s/some packages/1 glibc ebuild/

The concerned package is only 1 version of glibc per a group of kernels,
no more.  It is well-contained, not a can of worms.

> b) Very old versions of some packages will need to drop keywords for
> 'rolling' platforms. E.g. I'd expect glibc-really-old to be keyworded
> only for 'prefix' but not for 'x86' or 'amd64'.

To clarify, prefix-standalone uses implicit keyword scheme, the same
usual keywords as 'amd64'.  We could mask the old versions as the status
quo.

> This is because the latter two are not well tested[1]
>
> A and B are both mostly about control and maintenance of the tree
> itself (these do not necessarily reflect the quality or stability of
> prefix as a platform.)
>
> The separate problem is:

> Given some prefix users are running prefix on these old platforms, how
> do we detect when support for them breaks (as it did for py3, and will
> again in the future when something else critical breaks.) 

We can require each platform (or profile) to have at least 1 dev as an
active user, for example:

  https://wiki.gentoo.org/wiki/Project:Prefix#Platform_matrix

Recently, I have found an ultimate solution to the python3 puzzle.
Usually, glibc exposes all the symbols it supports.  Whether the kernel
supports the symbols are determined at runtime.  But, if the glibc is
patched to be faithful to the kernels it is running on, python3 happily
compiles and runs.  And yes, we know exactly what kernels are expected,
e.g. glibc-2.16 for linux-2.6 ~ 2.6.15.  Therefore we have a define goal
to patch the glibc.

By this strategy, even RHEL4 runs python-3.6 well.

> I'm curious to hear more about this process, but I think its
> orthogonal to in-tree or in-overlay support; other than the overlay
> gives you more control over when to release / withdraw various package
> versions (more control than just keywords do in the main tree.)  Note
> that Gentoo itself purports to offer only 1 year of support for the
> main tree; so just based on that axiom alone I think trying to support
> 10+ year old platforms goes against what the main-tree is targeting.

Again, a glibc ebuild isolates the antique kernel and all the dirty work
of supporting 10+ year old platform is absorbed in 1 ebuild.  Therefore
the 1-year-of-support model of Gentoo tree is not violated and
untouched.

Hope that address the concerns of potential degradation of our main tree
quality.

Cheers,
Benda


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default

2018-03-03 Thread Michał Górny
W dniu sob, 03.03.2018 o godzinie 13∶08 +0100, użytkownik Ulrich Mueller
napisał:
> > > > > > On Sat, 03 Mar 2018, Michał Górny wrote:
> > > It seems counter-intuitive for a simple binary option to require an
> > > argument. What is wrong with specifying -d to enable the option,
> > > and simply not specifying it to disable?
> > What is wrong is that a number of developers have historically not
> > specified the option and broke stuff. Plus, it's infinitely silly to
> > require people to explicitly specify the option to enable required
> > behavior.
> 
> My remark was about syntax, not about semantics. "-d y" and "-d n"
> instead of "-d" and "(nothing)" is a crappy user interface.
> 
> Maybe unify things into "--include-profiles=" (with a
> comma separated list of "stable", "dev", and "exp") or
> "--include-profile-level=" with n=0 for stable, n=1 for stable+dev,
> etc.?
> 

I don't really want to go into this. As far as I'm concerned, I can
leave defunct '-d' and just check dev profiles unconditionally.

-- 
Best regards,
Michał Górny




Re: [gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default

2018-03-03 Thread Ulrich Mueller
> On Sat, 03 Mar 2018, Michał Górny wrote:

>> It seems counter-intuitive for a simple binary option to require an
>> argument. What is wrong with specifying -d to enable the option,
>> and simply not specifying it to disable?

> What is wrong is that a number of developers have historically not
> specified the option and broke stuff. Plus, it's infinitely silly to
> require people to explicitly specify the option to enable required
> behavior.

My remark was about syntax, not about semantics. "-d y" and "-d n"
instead of "-d" and "(nothing)" is a crappy user interface.

Maybe unify things into "--include-profiles=" (with a
comma separated list of "stable", "dev", and "exp") or
"--include-profile-level=" with n=0 for stable, n=1 for stable+dev,
etc.?

Ulrich


pgpRefoLzQiiY.pgp
Description: PGP signature


Re: [gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default

2018-03-03 Thread Michał Górny
W dniu sob, 03.03.2018 o godzinie 12∶48 +0100, użytkownik Ulrich Mueller
napisał:
> > > > > > On Sat, 3 Mar 2018, Michał Górny wrote:
> 
>  
> > parser.add_argument(
> > '-d', '--include-dev-profiles', choices=('y', 'n'), 
> > metavar='',
> > -   default='n',
> > +   default='y',
> > help='include dev profiles in dependency checks')
> 
> It seems counter-intuitive for a simple binary option to require an
> argument. What is wrong with specifying -d to enable the option, and
> simply not specifying it to disable?
> 

What is wrong is that a number of developers have historically not
specified the option and broke stuff. Plus, it's infinitely silly to
require people to explicitly specify the option to enable required
behavior.

-- 
Best regards,
Michał Górny




Re: [gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default

2018-03-03 Thread Ulrich Mueller
> On Sat, 3 Mar 2018, Michał Górny wrote:
 
>   parser.add_argument(
>   '-d', '--include-dev-profiles', choices=('y', 'n'), 
> metavar='',
> - default='n',
> + default='y',
>   help='include dev profiles in dependency checks')

It seems counter-intuitive for a simple binary option to require an
argument. What is wrong with specifying -d to enable the option, and
simply not specifying it to disable?

Ulrich


pgpXXL5a128zO.pgp
Description: PGP signature


[gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default

2018-03-03 Thread Michał Górny
Enable testing 'dev' profiles by default. Those profiles are in the way
of becoming stable, and therefore it is crucial that developers test
that their changes do not break them. Instead of requiring developers
to explicitly type 'repoman full -d' all the time, just test them
by default.
---
 repoman/pym/repoman/argparser.py| 2 +-
 repoman/pym/repoman/tests/simple/test_simple.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/repoman/pym/repoman/argparser.py b/repoman/pym/repoman/argparser.py
index 2e8aee1b6..3359e2f65 100644
--- a/repoman/pym/repoman/argparser.py
+++ b/repoman/pym/repoman/argparser.py
@@ -162,7 +162,7 @@ def parse_args(argv, qahelp, repoman_default_opts):
 
parser.add_argument(
'-d', '--include-dev-profiles', choices=('y', 'n'), 
metavar='',
-   default='n',
+   default='y',
help='include dev profiles in dependency checks')
 
parser.add_argument(
diff --git a/repoman/pym/repoman/tests/simple/test_simple.py 
b/repoman/pym/repoman/tests/simple/test_simple.py
index 494152eca..f254336d9 100644
--- a/repoman/pym/repoman/tests/simple/test_simple.py
+++ b/repoman/pym/repoman/tests/simple/test_simple.py
@@ -191,7 +191,7 @@ class SimpleRepomanTestCase(TestCase):
("", git_cmd + ("init-db",)),
("", git_cmd + ("add", ".")),
("", git_cmd + ("commit", "-a", "-m", "add whole 
repo")),
-   ("", repoman_cmd + ("full", "-d", "y")),
+   ("", repoman_cmd + ("full",)),
("", cp_cmd + (test_ebuild, test_ebuild[:-8] + 
"2.ebuild")),
("", git_cmd + ("add", test_ebuild[:-8] + "2.ebuild")),
("", repoman_cmd + ("commit", "-m", "cat/pkg: bump to 
version 2")),
-- 
2.16.2




[gentoo-portage-dev] [PATCH 2/3] repoman: Unify -d option to match -e

2018-03-03 Thread Michał Górny
Unify the -d option to take y|n argument alike -e. This is necessary
to make it possible to control its value after changing the default.
Also rename the long option and its uses to match the full name for -e.
---
 repoman/pym/repoman/actions.py | 12 ++--
 repoman/pym/repoman/argparser.py   |  4 ++--
 repoman/pym/repoman/modules/scan/depend/profile.py |  2 +-
 repoman/pym/repoman/tests/simple/test_simple.py|  2 +-
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/repoman/pym/repoman/actions.py b/repoman/pym/repoman/actions.py
index 8e23322c8..3e9fe97d5 100644
--- a/repoman/pym/repoman/actions.py
+++ b/repoman/pym/repoman/actions.py
@@ -51,17 +51,17 @@ class Actions(object):
self.repoman_settings = repo_settings.repoman_settings
self.suggest = {
'ignore_masked': False,
-   'include_dev': False,
+   'include_dev_profiles': False,
}
if scanner.have['pmasked'] and not (options.without_mask or 
options.ignore_masked):
self.suggest['ignore_masked'] = True
-   if scanner.have['dev_keywords'] and not options.include_dev:
-   self.suggest['include_dev'] = True
+   if scanner.have['dev_keywords'] and not 
options.include_dev_profiles:
+   self.suggest['include_dev_profiles'] = True
 
 
def inform(self, can_force, result):
'''Inform the user of all the problems found'''
-   if ((self.suggest['ignore_masked'] or 
self.suggest['include_dev'])
+   if ((self.suggest['ignore_masked'] or 
self.suggest['include_dev_profiles'])
and not self.options.quiet):
self._suggest()
if self.options.mode != 'commit':
@@ -238,9 +238,9 @@ the whole commit message to abort.
"Note: use --without-mask to check "
"KEYWORDS on dependencies of masked packages"))
 
-   if self.suggest['include_dev']:
+   if self.suggest['include_dev_profiles']:
print(bold(
-   "Note: use --include-dev (-d) to check "
+   "Note: use --include-dev-profiles=y (-d y) to 
check "
"dependencies for 'dev' profiles"))
print()
 
diff --git a/repoman/pym/repoman/argparser.py b/repoman/pym/repoman/argparser.py
index b7e6071ba..2e8aee1b6 100644
--- a/repoman/pym/repoman/argparser.py
+++ b/repoman/pym/repoman/argparser.py
@@ -161,8 +161,8 @@ def parse_args(argv, qahelp, repoman_default_opts):
'filter the selection of profiles for dependency 
checks'))
 
parser.add_argument(
-   '-d', '--include-dev', dest='include_dev', action='store_true',
-   default=False,
+   '-d', '--include-dev-profiles', choices=('y', 'n'), 
metavar='',
+   default='n',
help='include dev profiles in dependency checks')
 
parser.add_argument(
diff --git a/repoman/pym/repoman/modules/scan/depend/profile.py 
b/repoman/pym/repoman/modules/scan/depend/profile.py
index 30d839af0..583a77e59 100644
--- a/repoman/pym/repoman/modules/scan/depend/profile.py
+++ b/repoman/pym/repoman/modules/scan/depend/profile.py
@@ -86,7 +86,7 @@ class ProfileDependsChecks(ScanBase):
 
is_stable_profile = prof.status == "stable"
is_dev_profile = prof.status == "dev" and \
-   self.options.include_dev
+   self.options.include_dev_profiles == 'y'
is_exp_profile = prof.status == "exp" and \
self.options.include_exp_profiles == 'y'
if not (is_stable_profile or is_dev_profile or 
is_exp_profile):
diff --git a/repoman/pym/repoman/tests/simple/test_simple.py 
b/repoman/pym/repoman/tests/simple/test_simple.py
index 3d7a70ad0..494152eca 100644
--- a/repoman/pym/repoman/tests/simple/test_simple.py
+++ b/repoman/pym/repoman/tests/simple/test_simple.py
@@ -191,7 +191,7 @@ class SimpleRepomanTestCase(TestCase):
("", git_cmd + ("init-db",)),
("", git_cmd + ("add", ".")),
("", git_cmd + ("commit", "-a", "-m", "add whole 
repo")),
-   ("", repoman_cmd + ("full", "-d")),
+   ("", repoman_cmd + ("full", "-d", "y")),
("", cp_cmd + (test_ebuild, test_ebuild[:-8] + 
"2.ebuild")),
("", git_cmd + ("add", test_ebuild[:-8] + "2.ebuild")),
("", repoman_cmd + ("commit", "-m", "cat/pkg: bump to 
version 2")),
-- 
2.16.2




[gentoo-portage-dev] [PATCH 1/3] repoman: Fix default for -e to 'n' (rather than inconsistent False)

2018-03-03 Thread Michał Górny
---
 repoman/pym/repoman/argparser.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/repoman/pym/repoman/argparser.py b/repoman/pym/repoman/argparser.py
index f32972288..b7e6071ba 100644
--- a/repoman/pym/repoman/argparser.py
+++ b/repoman/pym/repoman/argparser.py
@@ -167,7 +167,7 @@ def parse_args(argv, qahelp, repoman_default_opts):
 
parser.add_argument(
'-e', '--include-exp-profiles', choices=('y', 'n'), 
metavar='',
-   default=False,
+   default='n',
help='include exp profiles in dependency checks')
 
parser.add_argument(
-- 
2.16.2




Re: [gentoo-dev] Packages up for grabs due to retirement

2018-03-03 Thread Geaaru
Hi,

+1 for dev-python/ipcalc

I will update my issue as proxy maintainer for this if is ok.

Bye

On Mar 3, 2018 08:38, "Johann Schmitz (ercpe)"  wrote:

> Hi,
>
> due to my retirement, the following packages need a new maintainer:
>
> dev-java/boilerpipe
> dev-libs/grok
> dev-python/cfgio
> dev-python/disqus-python
> dev-python/django-openid-auth
> dev-python/django-opensearch
> dev-python/django-otp
> dev-python/django-otp-yubikey
> dev-python/django-phonenumber-field
> dev-python/django-two-factor-auth
> dev-python/ipcalc
> dev-python/pSQL
> dev-python/phonenumbers
> dev-python/py2neo
> dev-python/requests-oauthlib
> dev-python/shortuuid
> dev-python/twilio
> dev-python/twython
> dev-python/yubiotp
> net-analyzer/nagios-check_linux_bonding
> net-misc/openvpn-auth-ldap
> sci-biology/picard
>
> openvpn-auth-ldap, grok and django-two-factor-auth have open bugs:
> https://bugs.gentoo.org/buglist.cgi?email1=ercpe%
> 40gentoo.org_to1=1=equals_
> format=advanced=---
>
>
> Regards,
> Johann
>
>