Re: [gentoo-dev] [RFC] Proposed dates for Python 3.10 switch and Python 3.8 removal

2021-11-11 Thread Patrick McLean
On Thu, 11 Nov 2021 09:55:48 -0800
Patrick McLean  wrote:

> On Thu, 11 Nov 2021 17:05:45 +0100
> Michał Górny  wrote:
> > I'd like to add some dates regarding 3.8 removal and 3.10 switch to
> > the implementation timeline [1].
> > 
> > Unless I'm mistaken, CPython is following a yearly release cycle these
> > days.  I think it would make sense to also aim for a yearly cycle
> > in Gentoo, i.e. roughly switch to the next minor version every year.
> > 
> > Hence my proposal would be to:
> > 
> > a. ASAP: send "please port your packages to py3.9" mail
> > 
> > b. 2022-06-01: remove py3.8 target  
> 
> Could we please push this back, I would prefer some time in 2023 if
> possible.
To clarify, I am just asking for it to be pushed back to the start of
2023, not June 2023. 2023-01-01 would be fine.

> > c. ASAP: stabilize Python 3.9 interpreter + start working towards
> > unmasking python3_9 flag on stable
> > 
> > d. 2022-06-01: switch the default to py3.10
> > 
> > In other news, there's a good chance that PyPy3 will catch up to 3.9
> > before we remove 3.8.  
> 



Re: [gentoo-dev] [RFC] Proposed dates for Python 3.10 switch and Python 3.8 removal

2021-11-11 Thread Patrick McLean
On Thu, 11 Nov 2021 12:58:24 -0500
"Wolfgang E. Sanyer"  wrote:

> El jue, 11 de nov. de 2021 12:56 p. m., Patrick McLean 
> escribió:
> 
> > On Thu, 11 Nov 2021 17:05:45 +0100
> > Michał Górny  wrote:  
> > > I'd like to add some dates regarding 3.8 removal and 3.10 switch to
> > > the implementation timeline [1].
> > >
> > > Unless I'm mistaken, CPython is following a yearly release cycle these
> > > days.  I think it would make sense to also aim for a yearly cycle
> > > in Gentoo, i.e. roughly switch to the next minor version every year.
> > >
> > > Hence my proposal would be to:
> > >
> > > a. ASAP: send "please port your packages to py3.9" mail
> > >
> > > b. 2022-06-01: remove py3.8 target  
> >
> > Could we please push this back, I would prefer some time in 2023 if
> > possible.
> >  
> 
> Is there a particular reason you wish to push it back, or is it purely
> personal preference?
> 
Professional preference? My employer (which employs several Gentoo
developers, and funds a large amount of Gentoo work) needs a bit more
time to migrate all the internal stuff to 3.10.



Re: [gentoo-dev] [RFC] Proposed dates for Python 3.10 switch and Python 3.8 removal

2021-11-11 Thread Patrick McLean
On Thu, 11 Nov 2021 19:01:14 +0100
David Seifert  wrote:

> On Thu, 2021-11-11 at 09:55 -0800, Patrick McLean wrote:
> > On Thu, 11 Nov 2021 17:05:45 +0100
> > Michał Górny  wrote:
> > > I'd like to add some dates regarding 3.8 removal and 3.10 switch to
> > > the implementation timeline [1].
> > > 
> > > Unless I'm mistaken, CPython is following a yearly release cycle
> > > these
> > > days.  I think it would make sense to also aim for a yearly cycle
> > > in Gentoo, i.e. roughly switch to the next minor version every year.
> > > 
> > > Hence my proposal would be to:
> > > 
> > > a. ASAP: send "please port your packages to py3.9" mail
> > > 
> > > b. 2022-06-01: remove py3.8 target
> > 
> > Could we please push this back, I would prefer some time in 2023 if
> > possible.
> 
> Are you going to help maintain the python interpreter? And fix tests for
> old python targets?
> 
If that is what is required.
I am not asking to keep around 3.8 python targets for upstream that
drop support, only keep it around for a bit longer for the upstreams
that continue to support it. Upstream python isn't dropping support for
3.8 until 2024.



Re: [gentoo-dev] [RFC] Proposed dates for Python 3.10 switch and Python 3.8 removal

2021-11-11 Thread Patrick McLean
On Thu, 11 Nov 2021 17:05:45 +0100
Michał Górny  wrote:
> I'd like to add some dates regarding 3.8 removal and 3.10 switch to
> the implementation timeline [1].
> 
> Unless I'm mistaken, CPython is following a yearly release cycle these
> days.  I think it would make sense to also aim for a yearly cycle
> in Gentoo, i.e. roughly switch to the next minor version every year.
> 
> Hence my proposal would be to:
> 
> a. ASAP: send "please port your packages to py3.9" mail
> 
> b. 2022-06-01: remove py3.8 target

Could we please push this back, I would prefer some time in 2023 if
possible.

> c. ASAP: stabilize Python 3.9 interpreter + start working towards
> unmasking python3_9 flag on stable
> 
> d. 2022-06-01: switch the default to py3.10
> 
> In other news, there's a good chance that PyPy3 will catch up to 3.9
> before we remove 3.8.



Re: [gentoo-dev] News item: sys-libs/db old SLOT removal

2021-05-26 Thread Patrick McLean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 27 May 2021 00:41:23 +0200
David Seifert  wrote:

> The old Berkeley DB slots need to go at this point. The Base Project has
> decided to consider BDB a deprecated database backend, and we'll slowly
> be working towards a (possibly) BDB-free ::gentoo some time in the long-
> term future.

I think we should keep at least one non AGPLv3 berkdb in the tree as long
as we have any packages that unconditionally depend on it. June 1st is
too short a time frame for masking pre AGPLv3 berkdb versions. I think it
is reasonable to fix packages that either force berkdb USE flags on in their
deps, or have a hard dep (either by updating/fixing or last-rite).


> Other distros such as Fedora have started a gradual phase-out of
> Berkeley DB too, given Oracle's strong-armed approach to community
> input and their arguably hostile switch to the AGPLv3
> (https://fedoraproject.org/wiki/Changes/Libdb_deprecated). Furthermore,
> Oracle is known to remove critical features from BDB in patch releases,
> such as the removal of the client-server architecture and the SQL API
> between 18.1.32 and 18.1.40.

Gradual phase-out is also the approach we should take. Dropping non
AGPLv3 version sort of immediately forces the issue for users that
can't or won't accept that license.

> To this end, we will also be removing USE="berkdb" from
> profiles/default/linux/make.defaults. If you implicitly depend on
> profiles enabling optional use of sys-libs/db, you will need to enable
> this USE flag yourself, beginning 1st June.
> 
> From here on, you should be working under the assumption that the
> sys-libs/db package will be gone from the Gentoo repository within
> **two years** from the time of this news item. If you depend on BDB in
> a production environment, we strongly suggest you move to one of the
> modern replacements, such as GDBM, SQLite or LMDB.

This makes sense for end users, but we should fix ::gentoo before we
force it on our users.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE4/aZebtLiSjaeOPRfL9E71w1CIMFAmCu1TgACgkQfL9E71w1
CIMU4A//RRAogOgwFcjLpDy3Xb5oJLVBfdO5XOhaYsVi8omafDS5lMdS2MlXE1t1
F6t3Q69yJ3vTxd7wVArnhEQCAqNpjUgRu8wFmmWQTy8hj5qOhLJEdirY1m6RqS//
BNjPYTPfPUsPyR112QZSxQ0X5YzoWJWHM2IBQ3ccDaVskHPpQTUPnfIJ72p4v69H
fNZQMDEPI9SsIL3iZtjFl9E00/FHZy24VXDyQqOAuIeE34V6Bt2Ph1Zw9ZxPlZCM
iybwOVMIfR3eAPIz6HZK1ImyFo6srBjyky1lOVQ5fgGi/vMDrID4YH6effD71DUM
mZkxLPYl78Pyzd20fK2ca0udc7HgEVqyoCcgpVzdpVzHpwwaVGWYl8HL1FCJlING
hgO4eMMbSaMVK8dMUvA/uUt1oLJVYXSFjPBGtg16lPjLCOY6UZsv6L5Lxs/tbqJa
GU0rRMuUJ2FqnJebcNfT80st1ZS+x14xy6Xg6e20+NKXMMzmBlnWZyDn5Z5ZBFAK
aHE4llH2a9lNSAis8z7sW0mm92Zy65LhZrtYbmhPtfoXlwHOzGdev/5ifTjnFhl4
w70XzeRtHHZTzCbBHTPO+e/14lVV8zG5LNCc1+FYeD73XCDxrnBP/8Eavns0/zf7
IHyCWJQ5T4y6gr4Gpjmo3urhzTBX9sR4arFYefSshGiNB/hRgfE=
=3x1D
-END PGP SIGNATURE-


Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

2021-03-02 Thread Patrick McLean
On Mon, 1 Mar 2021 22:54:45 -0500
Matt Turner  wrote:

> tl;dr: In app-portage/gentoolkit-0.5.1 there's a new tool I wrote,
> called merge-driver-ekeyword that can automatically resolve git merge
> conflicts involving the KEYWORDS=... line in ebuilds.
> 
> To use the merge driver, configure your gentoo.git as such:
> 
> gentoo.git/.git/config:
> 
>  [merge "keywords"]
>   name = KEYWORDS merge driver
>   driver = merge-driver-ekeyword %O %A %B %P
> 
> gentoo.git/.git/info/attributes:
> 
>  *.ebuild merge=keywords
> 
> With that configured, git merge conflicts on the KEYWORDS=... line will
> be resolved automatically (e.g. during git pull --rebase).
> 
Excellent, this will eliminate one source of annoyance with our
workflow. Perhaps we should document this in the wiki:
https://wiki.gentoo.org/wiki/Gentoo_git_workflow

That way new developers, or developers setting up a new machine will
have instructions on setting this up.



Re: [gentoo-dev] [PATCH 1/2] acct-user.eclass: Support ACCT_USER_ID override

2021-01-06 Thread Patrick McLean
On Wed, 6 Jan 2021 15:02:12 +0100
Thomas Deutschmann  wrote:

> Hi,
> 
> is there a specific reason why we want to support dynamic variables 
> (ACCT_USER_$foo) at all?
> 
> Isn't package.env support enough, i.e. use ACCT_USER_ID from environment 
> if set (which we should detect and log, maybe this will require a 
> different namespace for the variables at all to be able to differentiate 
> between values set by acct-* ebuild and user override)?
> 
> Of course this won't allow something like `ACCT_USER_ID=42 emerge 
> ` but I am not sure if 
> this is an implementation goal.

This is so ACCT_USER_$foo can be set in make.conf, and not have to
be specified as an environment variable whenever portage is run. This
helps when automated systems are building Gentoo images or systems.



Re: [gentoo-dev] [PATCH] acct-user.eclass: Support var overrides for user properties

2021-01-04 Thread Patrick McLean
On Tue, 05 Jan 2021 00:54:58 +0100
Michał Górny  wrote:

> On Mon, 2021-01-04 at 15:50 -0800, Patrick McLean wrote:
> > On Tue, 05 Jan 2021 00:16:49 +0100
> > Michał Górny  wrote:
> > > On Mon, 2021-01-04 at 14:58 -0800, Patrick McLean wrote:  
> > > > On Mon,  4 Jan 2021 18:08:02 +0100
> > > > Michał Górny  wrote:
> > > > > Introduce a few variables to allow easy overrides of common user 
> > > > > account
> > > > > proprerties, that is:
> > > > > 
> > > > > - ACCT_USER__SHELL
> > > > > - ACCT_USER__HOME
> > > > > - ACCT_USER__HOME_OWNER
> > > > > - ACCT_USER__HOME_PERMS
> > > > > - ACCT_USER__GROUPS
> > > > > - ACCT_USER__GROUPS_ADD
> > > > 
> > > > Please also add a way to override the UID/GID for the user/group.
> > > 
> > > Damn it, and I thought I'd avoid that ;-).  But do we really need it? 
> > > The eclass doesn't enforce UID/GID by default if the user exists
> > > already, so it's a bit tangential to the original problem.
> > >   
> > 
> > The user needs to already exist for that to be helpful. When one using
> > automation to build/deploy large numbers of Gentoo systems, it's quite
> > useful to have control over that sort of things. At the moment, the
> > only way is to fork the ebuilds, which of course means they need to be
> > kept in sync.  
> 
> Ok, I'll keep that mind.  However, I suppose you won't mind me
> addressing that separately?  Unlike the patch sent, ID-related logic
> needs to be done twice (due to pkg_pretend).  Ideally, could you report
> a feature request on Bugzilla?

Sure, I don't mind it being addressed separately. I created a feature
request on Bugzilla: https://bugs.gentoo.org/763615



Re: [gentoo-dev] [PATCH] acct-user.eclass: Support var overrides for user properties

2021-01-04 Thread Patrick McLean
On Tue, 05 Jan 2021 00:16:49 +0100
Michał Górny  wrote:

> On Mon, 2021-01-04 at 14:58 -0800, Patrick McLean wrote:
> > On Mon,  4 Jan 2021 18:08:02 +0100
> > Michał Górny  wrote:
> >   
> > > Introduce a few variables to allow easy overrides of common user account
> > > proprerties, that is:
> > > 
> > > - ACCT_USER__SHELL
> > > - ACCT_USER__HOME
> > > - ACCT_USER__HOME_OWNER
> > > - ACCT_USER__HOME_PERMS
> > > - ACCT_USER__GROUPS
> > > - ACCT_USER__GROUPS_ADD  
> > 
> > Please also add a way to override the UID/GID for the user/group.  
> 
> Damn it, and I thought I'd avoid that ;-).  But do we really need it? 
> The eclass doesn't enforce UID/GID by default if the user exists
> already, so it's a bit tangential to the original problem.
> 

The user needs to already exist for that to be helpful. When one using
automation to build/deploy large numbers of Gentoo systems, it's quite
useful to have control over that sort of things. At the moment, the
only way is to fork the ebuilds, which of course means they need to be
kept in sync.



Re: [gentoo-dev] [PATCH] acct-user.eclass: Support var overrides for user properties

2021-01-04 Thread Patrick McLean
On Mon,  4 Jan 2021 18:08:02 +0100
Michał Górny  wrote:

> Introduce a few variables to allow easy overrides of common user account
> proprerties, that is:
> 
> - ACCT_USER__SHELL
> - ACCT_USER__HOME
> - ACCT_USER__HOME_OWNER
> - ACCT_USER__HOME_PERMS
> - ACCT_USER__GROUPS
> - ACCT_USER__GROUPS_ADD

Please also add a way to override the UID/GID for the user/group.

> The first five variables override the respective ACCT_USER_* variables,
> with ACCT_USER_*_GROUPS being a space-separated list.  The *_GROUPS_ADD
> variable appends to groups present in the ebuild, as this seems a common
> necessity.



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-31 Thread Patrick McLean
On Tue, 29 Dec 2020 23:34:36 +
Peter Stuge  wrote:

> David Seifert wrote:
> > > Maybe because it is so well-known that monoculture is harmful per se,
> > > which is why the commitment to choice in Gentoo is very valuable.
> > > 
> > > Further, LibreSSL comes out of the OpenBSD project, which has a good
> > > reputation on code quality.  
> > 
> > Like strong-arming 99% of the users of OpenSSH because they were
> > unwilling to port to the OpenSSL 1.1 API, fully well knowing that most
> > of the OpenSSH consuming world doesn't actually use libressl? How is
> > explicitly tying OpenSSH to libressl not a form of monoculture?  
> 
> Now we're properly off-topic :) but considering that OpenSSH is developed
> for OpenBSD and that openssh-portable is merely provided as a service to
> other systems it's easy to understand why OpenSSH (remember, part of OpenBSD)
> uses the libressl API for crypto, and why the -portable team is not so keen
> on maintaining patches for other crypto providers. Another example is systemd
> binding tightly to Linux. In both cases it's understandable, but also quite
> unfortunate; better portability would be better.

I don't have any strong opinions on either side of this argument, I
have 1 machine on LibreSSL that I would need to switch, but that is
not really a major issue for me.

As the person who has been doing a large percentage of the OpenSSH
ebuild maintenance for a couple of years now I feel I should
mention that while it was the case that OpenSSH would not work with
OpenSSL 1.1+ without a (rather large) patch in the past, that has not
been the case for some time now. Modern OpenSSH versions work fine with
modern OpenSSL versions.



Re: [gentoo-dev] LiveCD Project disbanding: packages up for grabs

2020-11-06 Thread Patrick McLean
On Wed, 4 Nov 2020 16:09:37 -0500
Matt Turner  wrote:

> The LiveCD project is only me now, which isn't much of a project, so
> I'm putting these packages up for grabs. livecd@ is co-maintainer on a
> few others that aren't listed.
> 
> app-misc/livecd-tools
> 
>   - Releng@ will take this
> 
> sys-libs/libkudzu
> sys-apps/hwdata-gentoo
> sys-apps/hwsetup
> 
>   - These are used on the Live CDs, but I don't know if they actually
> do anything useful.
>   - Releng@ will take them with the understanding that I might remove
> them from the tree.
> 
> dev-python/pyparted
> dev-util/dialog
> sys-block/parted
> sys-fs/squashfs-tools
> x11-themes/gentoo-artwork-livecd

Please do not remove pyparted, parted or squashfs-tools these are most
certainly useful. I will maintain them if RelEng does not want them.

I should not that I believe that dev-util/dialog may be required for
"make menuconfig" in the kernel to work, so this is likely a rather
important package as well.



Re: [gentoo-dev] [virtualization project] Help needed with libvirt virtualization stack

2020-09-22 Thread Patrick McLean
On Mon, 21 Sep 2020 15:25:56 -0500
Matthias Maier  wrote:

> Dear all,
> 
> Due to some work related crunch time I had very limited time lately to
> properly maintain the following packages of the virtualization stack:
> 
>   app-emulation/qemu
I can help with qemu if needed.

>   sys-process/criu
I am already primary maintainer on this.
> 
> If you use these packages and are interested in helping out with version
> bumps and maintenance, please contact me over e-mail / IRC and add
> yourself to the virtualization project :-)
> 
> Best,
> Matthias



Re: [gentoo-dev] [RFC] Deadlines for next Python implementations

2020-06-01 Thread Patrick McLean
On Mon, 01 Jun 2020 23:04:38 +0200
Michał Górny  wrote:

> On Mon, 2020-06-01 at 13:34 -0700, Patrick McLean wrote:
> > On Mon, 01 Jun 2020 22:27:19 +0200
> > Michał Górny  wrote:
> >   
> > > Hi, everyone.
> > > 
> > > I'd like to be more proactive in avoiding the mess like Python 3.6->3.7
> > > switch were.  For this reason, I think it would be better to set
> > > and publish some early deadlines.  Even if we aren't going to strictly
> > > keep to them, it would help people realize how much time there is left
> > > to finish the preparations.
> > > 
> > > 
> > > Python 3.6→3.7 migration
> > > 
> > > We've already switched the profiles but there are still some unmigrated
> > > packages.  We will continue either migrating them or last riting if
> > > migration seems unlikely to happen.  Nevertheless, it is wortwhile to
> > > set some final deadlines.  My proposal is:
> > > 
> > > 
> > > 2020-08-01  Python 3.7 migration deadline
> > > 
> > >After this date, we lastrite all remaining packages that haven't been
> > >ported.  This gives people roughly two months, with a ping one month
> > >from now.
> > > 
> > > 2020-09-15  Python 3.6 target removal
> > > 
> > >As usual, the interpreter will be kept a bit longer, then moved to
> > >::python.  This accounts for some extra time if people decide to
> > >recover last rited packages last minute.  
> > 
> > Given that 2020-08-15 is still well over a year before the upstream EOL,
> > this might be a little premature. How about we the deprecation dates back
> > by 4 months? We can still have a similar schedule, just a little later. That
> > way we are deprecating 3.6 less than a year before the EOL upstream.
> > 
> > We can keep the 2.7 removal as-is.  
> 
> I don't mind shifting the removal.
> 
> >   
> > > Python 3.7→3.8 migration
> > > 
> > > The interpreter is stable but there's still lot of migration work to be
> > > done.  Good news is that because of the delay with 3.7, many packages
> > > are getting 3.7+3.8 or even 3.7+3.8+3.9 simultaneously, so there will be
> > > less work in the future.
> > > 
> > > 
> > > 2020-07-01  Python 3.8 target stable-unmasking goal
> > > 
> > >This is not really a deadline but I'd like to aim for resolving
> > >depgraph issues and stabilizing everything needed to unmask python3_7
> > >target on stable.  Initial set of stablereqs was filed already, 
> > >and we'll be unmasking the target as soon as the depgraph is clean.
> > > 
> > > 2020-09-01  Python 3.8 migration warning
> > > 
> > >At this point we tell people it's about time to start actively
> > >updating their packages.  
> > 
> > Under my suggested timeline, I would say we do this 2020-12-01.  
> 
> ...but I do mind this.  Python 3.8 is something we should very soon,
> and waiting another 6 months to tell people to start testing will just
> make it into another mess like Python 3.7 were.

That's fine with me, I don't mind having a warning about packages not
migrated to 3.8 earlier. I just would to keep 3.6 around for until next
year to give us a little more time to migrate.

> > > 2020-12-01  Python 3.8 migration deadline
> > > 
> > >We lastrite all the unmigrated packages.  
> > 
> > This could be pushed back to 2020-05-01 to not be too close to the 3.6
> > removal. I personally do not have any strong feelings either way about
> > 3.7, so I would be fine removing 3.6 and 3.7 at the same time if that
> > is easier.  
> 
> I would actually prefer pushing for 3.8 earlier and removing them
> at the same time.  If anything, this would let people who haven't moved
> off 3.6 yet go straight to 3.8 without having them do another update
> in a few months.

That's fine with me. We are actually taking this approach, skipping 3.7
entirely any moving directly to 3.8.

> > > 2021-01-15  Python 3.7 target removal
> > > 
> > >As above.
> > > 
> > > 
> > > Python 2.7 removal
> > > ==
> > > I would like to continue removing py2.7 from packages where possible,
> > > and slowly lastriting where clearly impossible.  However,
> > > for the remaining packages I'd like to set a hard deadline.
> > > 
> > > 
> > > 2021-01-01  Final Python 2.7 deadline
> > > 
>

Re: [gentoo-dev] [RFC] Deadlines for next Python implementations

2020-06-01 Thread Patrick McLean
On Mon, 01 Jun 2020 22:27:19 +0200
Michał Górny  wrote:

> Hi, everyone.
> 
> I'd like to be more proactive in avoiding the mess like Python 3.6->3.7
> switch were.  For this reason, I think it would be better to set
> and publish some early deadlines.  Even if we aren't going to strictly
> keep to them, it would help people realize how much time there is left
> to finish the preparations.
> 
> 
> Python 3.6→3.7 migration
> 
> We've already switched the profiles but there are still some unmigrated
> packages.  We will continue either migrating them or last riting if
> migration seems unlikely to happen.  Nevertheless, it is wortwhile to
> set some final deadlines.  My proposal is:
> 
> 
> 2020-08-01  Python 3.7 migration deadline
> 
>After this date, we lastrite all remaining packages that haven't been
>ported.  This gives people roughly two months, with a ping one month
>from now.
> 
> 2020-09-15  Python 3.6 target removal
> 
>As usual, the interpreter will be kept a bit longer, then moved to
>::python.  This accounts for some extra time if people decide to
>recover last rited packages last minute.

Given that 2020-08-15 is still well over a year before the upstream EOL,
this might be a little premature. How about we the deprecation dates back
by 4 months? We can still have a similar schedule, just a little later. That
way we are deprecating 3.6 less than a year before the EOL upstream.

We can keep the 2.7 removal as-is.

> 
> Python 3.7→3.8 migration
> 
> The interpreter is stable but there's still lot of migration work to be
> done.  Good news is that because of the delay with 3.7, many packages
> are getting 3.7+3.8 or even 3.7+3.8+3.9 simultaneously, so there will be
> less work in the future.
> 
> 
> 2020-07-01  Python 3.8 target stable-unmasking goal
> 
>This is not really a deadline but I'd like to aim for resolving
>depgraph issues and stabilizing everything needed to unmask python3_7
>target on stable.  Initial set of stablereqs was filed already, 
>and we'll be unmasking the target as soon as the depgraph is clean.
> 
> 2020-09-01  Python 3.8 migration warning
> 
>At this point we tell people it's about time to start actively
>updating their packages.

Under my suggested timeline, I would say we do this 2020-12-01.

> 2020-12-01  Python 3.8 migration deadline
> 
>We lastrite all the unmigrated packages.

This could be pushed back to 2020-05-01 to not be too close to the 3.6
removal. I personally do not have any strong feelings either way about
3.7, so I would be fine removing 3.6 and 3.7 at the same time if that
is easier.

> 2021-01-15  Python 3.7 target removal
> 
>As above.
> 
> 
> Python 2.7 removal
> ==
> I would like to continue removing py2.7 from packages where possible,
> and slowly lastriting where clearly impossible.  However,
> for the remaining packages I'd like to set a hard deadline.
> 
> 
> 2021-01-01  Final Python 2.7 deadline
> 
>That's one year after upstream's EOL.  At this point, we last rite
>all the remaining py2.7 packages.
> 
> 2021-02-15  Python 2.7 target removal
> 
>All packages relying on the target are removed.  The interpreter
>stays for as long as we need it.
> 
> 
> General goal
> 
> As a general goal, I'd like to set timelines like this once we decide
> that the next interpreter goes stable.  The exact lengths are highly
> dependent on properties of the next target.  For example, I suspect
> Python 3.9 will be easier for us; so far my testing has shown issues
> that are rather easy to solve.
> 

Here is an attempt at updating version of ASCII art, from what
I can tell, the 'w' at the 3.7->3.8 warning probably belonged
in the 3.7 column, I moved it. As I said above, I am personally
fine if we make 3.6 and 3.7 removals close together (even at
the same time).

Combined timeline
=
From the above dates:

2.7 3.6 3.7 3.8
2020-07-01   |   |   |   upy3.8 target unmasked
 |   |   |   |
 |   |   |   |
 |   |   |   |
 |   |   |   |
 |   |   |   |
 |   |   |   |
2020-12-01   |   |   w   |py3.7→3.8 migr. warning
 |   |   |   |
 |   |   |   |
2021-01-01   m   |   |   |py2.7 pkg last rites
 |   |   |   |
 |   |   |   |
2021-02-01   |   m   |   |py3.6 pkg last rites
 |   |   |   |
2021-02-15   x   |   |   |py2.7 pkg removal
2021-03-15   x   |   |py3.6 pkg removal
 |   |
 |   |
 |   |
2021-05-01   m   |py3.7 pkg last rites
 |   |
 |   |
2021-06-15   x   |py3.7 pkg removal
 |
 v




[gentoo-dev] Packages up for grabs

2020-05-28 Thread Patrick McLean
After looking over packages I maintain for packages that I no longer
need or use:

app-admin/qpage
app-text/tesseract
mail-filter/spamassassin-botnet
net-print/pkpgcounter
x11-plugins/pidgin-bot-sentry



Re: [gentoo-dev] Packages up for grabs

2020-05-28 Thread Patrick McLean
On Tue, 26 May 2020 16:31:36 -0700
Brian Dolbec  wrote:

> On Tue, 26 May 2020 23:12:06 +0100
> Andrey Utkin  wrote:
> 
> > I have transitioned to "away" state as I have to reclaim my time for
> > other uses. Here I am trying to reduce the scope of my Gentoo
> > responsibilities to make potential return to activity less dreadful
> > and overwhelming.
> > 
> > Call for successors
> > ===
> > 
> > The following are the packages I do not currently use myself so have
> > the least motivation about. Dropping me from maintainers list is
> > encouraged.
> > 
> > WIFI access point service:
> > 
> > * net-wireless/hostapd
> > (Co-maintained by zerochaos, still additional attention is
> > encouraged.)
> > 
> > Python API for AWS:
> > 
> > * dev-python/s3transfer  
> 
I will take this as it is somewhere in the dep tree for app-admin/salt
> > * dev-python/boto3
> > * dev-python/botocore  
> 
> I can take boto3, botocore since they are needed for buildbot
> 
I can co-maintain these since they are needed for app-admin/salt.



[gentoo-dev] [PATCH] python-utils-r1.eclass: Add PYTHON_RELAXED_VERSIONS variable

2020-04-29 Thread Patrick McLean
This adds PYTHON_RELAXED_VERSIONS that ebuilds can set before inheriting the
python eclasses that will make the implementation dependencies be simple slot
dependencies rather than >= dependencies. The purpose of this is for packages in
@system to use to avoid circular dependencies like in bug #720048

Bug: https://bugs.gentoo.org/720048
Signed-off-by: Patrick McLean 
---
 eclass/python-utils-r1.eclass | 56 ++-
 1 file changed, 42 insertions(+), 14 deletions(-)

diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index e85aefda792..e5781605c8e 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -57,6 +57,17 @@ readonly _PYTHON_ALL_IMPLS
 # which can involve revisions of this eclass that support a different
 # set of Python implementations.
 
+# @ECLASS-VARIABLE: PYTHON_RELAXED_VERSIONS
+# @INTERNAL
+# @DESCRIPTION:
+# Set to a non-empty value in order to make eclass dependencies on
+# Python versions be simple slot dependencies rather than setting
+# a minimum version.
+#
+# This is intended to be set in ebuilds that are part of @system, or
+# are dependencies of Python implementations themselves to avoid
+# circular dependencies with the Python interpreter.
+
 # @FUNCTION: _python_impl_supported
 # @USAGE: 
 # @INTERNAL
@@ -376,20 +387,37 @@ _python_export() {
;;
PYTHON_PKG_DEP)
local d
-   case ${impl} in
-   python2.7)
-   
PYTHON_PKG_DEP='>=dev-lang/python-2.7.17-r1:2.7';;
-   python3.6)
-   
PYTHON_PKG_DEP=">=dev-lang/python-3.6.10:3.6";;
-   python3.7)
-   
PYTHON_PKG_DEP=">=dev-lang/python-3.7.7-r1:3.7";;
-   python3.8)
-   
PYTHON_PKG_DEP=">=dev-lang/python-3.8.2:3.8";;
-   pypy3)
-   
PYTHON_PKG_DEP='>=dev-python/pypy3-7.3.0:0=';;
-   *)
-   die "Invalid implementation: 
${impl}"
-   esac
+   if [[ -z ${PYTHON_RELAXED_VERSIONS} ]]; then
+   case ${impl} in
+   python2.7)
+   
PYTHON_PKG_DEP='>=dev-lang/python-2.7.17-r1:2.7';;
+   python3.6)
+   
PYTHON_PKG_DEP=">=dev-lang/python-3.6.10:3.6";;
+   python3.7)
+   
PYTHON_PKG_DEP=">=dev-lang/python-3.7.7-r1:3.7";;
+   python3.8)
+   
PYTHON_PKG_DEP=">=dev-lang/python-3.8.2:3.8";;
+   pypy3)
+   
PYTHON_PKG_DEP='>=dev-python/pypy3-7.3.0:0=';;
+   *)
+   die "Invalid 
implementation: ${impl}"
+   esac
+   else
+   case ${impl} in
+   python2.7)
+   
PYTHON_PKG_DEP='dev-lang/python:2.7';;
+   python3.6)
+   
PYTHON_PKG_DEP="dev-lang/python:3.6";;
+   python3.7)
+   
PYTHON_PKG_DEP="dev-lang/python:3.7";;
+   python3.8)
+   
PYTHON_PKG_DEP="dev-lang/python:3.8";;
+   pypy3)
+   
PYTHON_PKG_DEP='dev-python/pypy3:0=';;
+   *)
+   die "Invalid 
implementation: ${impl}"
+   esac
+   fi
 
# use-dep
if [[ ${PYTHON_REQ_USE} ]]; then
-- 
2.26.2




Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Patrick McLean
On Mon, 20 Apr 2020 17:03:50 -0400
Michael Orlitzky  wrote:

> On 4/20/20 4:19 PM, Patrick McLean wrote:
> > 
> > My co-workers are not the only ones adding/maintaining go packages in the 
> > tree, please do not single out any groups, and let's all work to make 
> > Gentoo the best it can be.
> >   
> 
> Everyone else is just using the eclass that your coworkers defended and
> committed the last time we did this. We're not in this together and you
> sound like a COVID commercial from a billionaire that wants me to go
> back to work. You're in this for you, and everything you do for you
> makes things worse for me.
> 
We are under no obligation to contribute anything to ::gentoo, we could do all 
our go packaging work in a private overlay, and never push anything upstream. 
It is a considerable amount of extra work to push our packages upstream. We do 
this to contribute to the wider Gentoo community. I resent your statement that 
we are not doing this to contribute to the community.

Please explain how we are actively making things worse for you? We are 
contributing useful packages to the tree, we are doing the work and we are 
doing it in the way that makes the most effective use of our time. We simply do 
not have time to be trying to convince upstreams to make changes to their build 
systems to support a single, somewhat niche, distribution. We certainly don't 
have time to be patching build systems with every version bump.



Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Patrick McLean
On Mon, 20 Apr 2020 15:23:15 -0400
Michael Orlitzky  wrote:

> On 4/20/20 2:58 PM, Patrick McLean wrote:
> >>
> >> You keep saying that, but the fact that dev-go/* is filled with trash
> >> that has your name on it prevents anyone else from doing a better job.
> >>  
> > Ad-hominen attacks are unwarranted, please refrain from them. I challenge 
> > you to find *anything* in dev-go/* with my name on it.  
> 
> You quoted me one sentence prior saying that it's the Go ebuilds that
> are trash and not anyone personally. But OK, I should have said "Sony
> Interactive Entertainment" there instead of "you."

My co-workers are not the only ones adding/maintaining go packages in the tree, 
please do not single out any groups, and let's all work to make Gentoo the best 
it can be.

> 
> > Are you volunteering to do the work to package go packages? The people 
> > doing the work generally get to decide how that work gets done, and which 
> > approach they would like to take. The upstream situation makes it very 
> > labour-intensive to do the work in a the way you are proposing (many 
> > packages would end up with hundreds to thousands of packages in the tree). 
> > Separating everything out in to separate packages will just increase the 
> > maintenance load exponentially, with no gains as go upstreams version lock 
> > all their dependencies.
> >   
> 
> I'm volunteering to work on one or two small Go packages. Can I convert
> the eclass to use dynamic linking? Can I start replacing your packages
> with my own if I need them as dependencies? I suspect not, and that's
> one of many reasons why "having things in ::gentoo does not affect
> anyone who does not use them" is bullshit.
> 
Please do not make backward-incompatible changes to existing eclasses. If you 
would like to make a new go eclasss (say go-dynamic.eclass) then go ahead, I am 
certainly not going to stop you. As was said elsewhere in the thread, there is 
no policy against having a second version of a package in the tree. If the 
second version is truly better, then the other packages can be moved over to 
depending on it instead, and the original package can be moved or last-rited.

The current method of packaging go packages tries to strike a balance between 
maintainability, following upstream, and something that is compatible with 
ebuilds. If you have a better way to do things, we are not going to block you 
from trying, but we are also not going to necessarily adopt it if working with 
it would be orders of magnitude more work. We all have limited time to work on 
Gentoo stuff.



Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Patrick McLean
On Mon, 20 Apr 2020 14:07:01 -0400
Michael Orlitzky  wrote:

> On 4/20/20 1:31 PM, Patrick McLean wrote:
> >> Simply having things in ::gentoo does not affect anyone who does not  
> use them.
> >   
> 
> You keep saying that, but the fact that dev-go/* is filled with trash
> that has your name on it prevents anyone else from doing a better job.
> 
Ad-hominen attacks are unwarranted, please refrain from them. I challenge you 
to find *anything* in dev-go/* with my name on it.

Are you volunteering to do the work to package go packages? The people doing 
the work generally get to decide how that work gets done, and which approach 
they would like to take. The upstream situation makes it very labour-intensive 
to do the work in a the way you are proposing (many packages would end up with 
hundreds to thousands of packages in the tree). Separating everything out in to 
separate packages will just increase the maintenance load exponentially, with 
no gains as go upstreams version lock all their dependencies.



Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Patrick McLean
On Sun, 19 Apr 2020 11:37:15 -0400
Michael Orlitzky  wrote:

> On 4/19/20 10:55 AM, Samuel Bernardo wrote:
> > 
> > Taking into account the network sandbox requirement, sbt.eclass needs to
> > download all dependencies with some approach like EGO_SUM implementation
> > in go-module.eclass[1].
> >   
> 
> EGO_SUM is not a legitimate approach to packaging. You have to create
> packages for each package. I know, it sounds crazy when you say it.
> 
A lot of upstreams are doing things that are not very friendly to packagers. 
Sometimes we have to take different approaches to packaging to make it feasible 
to package these very popular programs.

Having 300+ packages in the tree with a single version that are only used as a 
dependency by a single package is not the way to a well-maintained tree. 
Sometimes things like EGO_SUM are the only feasible way to do things given we 
all have limited time to work on Gentoo, and we want these packages in the tree 
because many people find them useful.

If you object to the way these are handled, you are free to mask dev-lang/go on 
your system to endure that you do not get anything written in go installed. 
Simply having things in ::gentoo does not affect anyone who does not use them.

-- 



Re: [gentoo-dev] Stabilizations and src_test

2020-04-12 Thread Patrick McLean
On Sun, 12 Apr 2020 11:21:29 +0200
Michał Górny  wrote:

> On Sun, 2020-04-12 at 10:43 +0200, Agostino Sarubbo wrote:
> > Hello all,
> > 
> > If you work on the stabilization workflow you may have noticed that:
> > 
> > - There are people that rant if you don't run src_test against their 
> > packages;
> > - There are people that rant if you open a test failure bug against their 
> > packages and you block the stabilization.
> > 
> > So, unless there will be a clear policy about that, I'd suggest to 
> > introduce a 
> > way to establish if a package is expected to pass src_test or not.
> > 
> > A simple way to achieve this goal would be:
> > introduce a new bugzilla custom flag (like "Runtime testing required" we 
> > already have) maybe called "src_test pass" or similar, that, by default is 
> > yes 
> > and the maintainer should set it to no when needed.
> > 
> > In case of 'yes', the arch team member must compile with FEATURE="test" and 
> > he 
> > is allowed to block the stabilization in case of test-failure.
> > 
> > In case there will be a test-failure there are two choices:
> > 1) The maintainer fixes the test failure;
> > 2) The maintainer does not want to take care, so he can simply remove the 
> > blocker and set "src_test pass" to no.
> > 
> > Both of the above are fine for me.
> > 
> > Obviously, if there are already test-failure bugs open, the flag "src_test 
> > pass" should be set to 'no' when the stabilization bugs is filled.
> >   
> 
> This is not a problem that can be solved by a binary flag.
> 
> If package's test suite is entirely broken and unmaintained, the package
> should use RESTRICT=test and not silently ask arch teams to ignore it.
> 
> If package's test suite is only slightly broken, then I'd prefer saying
> 'please report but ignore *these* test failures' because I can't fix
> them right now but they don't seem major.  Skipping the test suite
> entirely is not a solution because it doesn't disambiguate between 'few
> tests fail' and 'every single test explodes'.
> 

I agree with this, the metric for marking an ebuild as "tests
don't work, please ignore them is RESTRICT=test". Usually for packages
that have a *few* tests that fail and don't seem major, I would suggest
trying to patch out the tests, or ask the test harness to skip the
known bad tests. This way the tinderbox will (hopefully) still succeed.



Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-27 Thread Patrick McLean
On Fri, 27 Mar 2020 15:51:35 -0700
Alec Warner  wrote:

> On Fri, Mar 27, 2020 at 3:11 PM Patrick McLean  wrote:
> 
> > On Fri, 27 Mar 2020 14:48:53 -0700
> > Matt Turner  wrote:
> >  
> > > On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean   
> > wrote:  
> > > >
> > > > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > > > _python_impl_supported to a separate eclass, this allows overlays
> > > > to easily support a different set of python implementations than
> > > > ::gentoo without having to fork the entire suite of eclasses.  
> > >
> > > (I think the issue is that you have some packages that still need
> > > Python 3.4. Correct me if I'm wrong)
> > >
> > > How many packages do you need to work with Python 3.4? Presumably just
> > > a couple and then a pile of dependencies in ::gentoo?
> > >  
> >
> > For our particular purpose, it's more complicated than that. We do not
> > expect or want ::gentoo to try support Python 3.4 in any way. We have an
> > overlay that is shared on a lot of machines, some of those machines are
> > older than others. As such we still have ebuilds that only support
> > python3_4 that still exist in the overlay. We would like it if the
> > existence of these packages in the overlay, do not cause metadata
> > generation or dependency calculation to explode on the more up-to-date
> > machines.
> >  
> 
> > We do not need Python 3.4 packages to be installable on the newer
> > machines, we just need them not to explode.
> >  
> 
> Couldn't you simply remove the ebuilds from the overlay entirely in this
> case? It's my understanding that on the machines with the packages
> installed, the merged package metadata is being used (which is why those
> machines work) and since the newer machines don't have this merged package
> metadata, they don't work properly.
> 

Sometimes we have to fix the older machines, so we have to keep
everything around until none of our machines are using it any more.

> 
> >
> > I am trying to come up with a solution that *any* overlay can use, I
> > am happy to do work towards that end. Basically, it would be very
> > nice if there was a minimal eclass that handles all the python
> > version compatibility. Almost everything in the eclasses does not care
> > about versions.
> >
> > This is not meant to be something just for our usage, we want this to
> > be usable for *any* overlay, and are more than happy to make things as
> > generic as possible. If some overlay wants to support Python 3.10 alpha,
> > resurrect jython support, or add Ironpython support, without forking
> > all the eclasses, I would like to think that could be doable as well.
> >
> >  




Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-27 Thread Patrick McLean
On Fri, 27 Mar 2020 14:48:53 -0700
Matt Turner  wrote:

> On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean  wrote:
> >
> > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > _python_impl_supported to a separate eclass, this allows overlays
> > to easily support a different set of python implementations than
> > ::gentoo without having to fork the entire suite of eclasses.  
> 
> (I think the issue is that you have some packages that still need
> Python 3.4. Correct me if I'm wrong)
> 
> How many packages do you need to work with Python 3.4? Presumably just
> a couple and then a pile of dependencies in ::gentoo?
> 

For our particular purpose, it's more complicated than that. We do not
expect or want ::gentoo to try support Python 3.4 in any way. We have an
overlay that is shared on a lot of machines, some of those machines are
older than others. As such we still have ebuilds that only support
python3_4 that still exist in the overlay. We would like it if the
existence of these packages in the overlay, do not cause metadata
generation or dependency calculation to explode on the more up-to-date
machines.

We do not need Python 3.4 packages to be installable on the newer
machines, we just need them not to explode.

I am trying to come up with a solution that *any* overlay can use, I
am happy to do work towards that end. Basically, it would be very
nice if there was a minimal eclass that handles all the python 
version compatibility. Almost everything in the eclasses does not care
about versions.

This is not meant to be something just for our usage, we want this to
be usable for *any* overlay, and are more than happy to make things as
generic as possible. If some overlay wants to support Python 3.10 alpha,
resurrect jython support, or add Ironpython support, without forking
all the eclasses, I would like to think that could be doable as well.



Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-27 Thread Patrick McLean
On Fri, 27 Mar 2020 06:53:13 +0100
Michał Górny  wrote:

> On Thu, 2020-03-26 at 14:03 -0700, Patrick McLean wrote:
> > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > _python_impl_supported to a separate eclass, this allows overlays
> > to easily support a different set of python implementations than
> > ::gentoo without having to fork the entire suite of eclasses.  
> 
> NAK.  This increases the maintenance effort (even if it means having to
> open yet another file) for *zero* gain to Gentoo users.  Your policy is
> entirely broken by design and I'm against supporting it officially.
> 
> The existing number of eclasses is already causing confusion and added
> maintenance effort, and it has strong justification in *a lot of shared
> code*.
> 
> To say it bluntly: if you want to do stupid things, do them yourselves
> and don't expect others to help.  You get paid for that.  We just waste
> our time.
> 
It can hard to keep the size of network we have in sync with upstream,
and we have quite a large number of internal repositories. The
approaches we are using are trying to strike a balance between
backwards compatibility and moving forward.

We get paid to do our job, which sometimes coincides with doing
upstream Gentoo work, and often doesn't. We have a policy to work
upstream wherever possible, this often makes certain types of tasks
take significantly more effort than if we just decided to fork
everything and work an internal overlay. These small changes are an
attempt to reduce the extra work that working upstream can create (we
generally work to support the general use case of all Gentoo users, not
just our limited use cases).

Would Gentoo as a whole be better served if we just forked everything
and stopped trying to contribute as much as possible upstream? Are some
small changes to some shared code to help us worth the amount of
contributions that we push back upstream.



[gentoo-dev] [PATCH v2]

2020-03-26 Thread Patrick McLean
This patch splits the definition of _PYTHON_ALL_IMPLS and
_python_impl_supported to a separate eclass, this allows overlays
to easily support a different set of python implementations than
::gentoo without having to fork the entire suite of eclasses.

Changes from previous version (based on feedback on IRC):
- add a guard variable to make sure it's being inherited
  python-utils-r1.eclass
diff --git a/eclass/python-impls-r1.eclass b/eclass/python-impls-r1.eclass
new file mode 100644
index 000..622cb1ccef3
--- /dev/null
+++ b/eclass/python-impls-r1.eclass
@@ -0,0 +1,93 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: python-impls-r1.eclass
+# @MAINTAINER:
+# Python team 
+# @AUTHOR:
+# Author: Michał Górny 
+# Split to separate eclass by: Patrick McLean 
+# Based on work of: Krzysztof Pawlik 
+# @SUPPORTED_EAPIS: 5 6 7
+# @BLURB: Definitions of supported eclasses for python-utils-r1
+# @DESCRIPTION:
+# A helper eclass defining the supported python implementations for
+# the python-r1 suite of eclasses.
+#
+# This eclass is meant to be inherited by python-utils-r1, inheriting
+# it separately is very unlikely to be useful.
+#
+# For more information, please see the Python Guide:
+# https://dev.gentoo.org/~mgorny/python-guide/
+
+case "${EAPI:-0}" in
+	[0-4]) die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" ;;
+	[5-7]) ;;
+	*) die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" ;;
+esac
+
+if [[ ${_PYTHON_ECLASS_INHERITED} ]]; then
+	die 'python-r1 suite eclasses can not be used with python.eclass.'
+
+elif [[ -z ${_PYTHON_ECLASS_CALLING} ]]; then
+	die 'python-impls-r1 can only be inherited from python-utils-r1'
+fi
+
+if [[ ! ${_PYTHON_IMPLS_R1} ]]; then
+
+# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
+# @INTERNAL
+# @DESCRIPTION:
+# All supported Python implementations, most preferred last.
+_PYTHON_ALL_IMPLS=(
+	pypy3
+	python2_7
+	python3_6 python3_7 python3_8
+)
+readonly _PYTHON_ALL_IMPLS
+
+# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
+# @INTERNAL
+# @DESCRIPTION:
+# Set to a non-empty value in order to make eclass tolerate (ignore)
+# unknown implementations in PYTHON_COMPAT.
+#
+# This is intended to be set by the user when using ebuilds that may
+# have unknown (newer) implementations in PYTHON_COMPAT. The assumption
+# is that the ebuilds are intended to be used within multiple contexts
+# which can involve revisions of this eclass that support a different
+# set of Python implementations.
+
+# @FUNCTION: _python_impl_supported
+# @USAGE: 
+# @INTERNAL
+# @DESCRIPTION:
+# Check whether the implementation  (PYTHON_COMPAT-form)
+# is still supported.
+#
+# Returns 0 if the implementation is valid and supported. If it is
+# unsupported, returns 1 -- and the caller should ignore the entry.
+# If it is invalid, dies with an appopriate error messages.
+_python_impl_supported() {
+	debug-print-function ${FUNCNAME} "${@}"
+
+	[[ ${#} -eq 1 ]] || die "${FUNCNAME}: takes exactly 1 argument (impl)."
+
+	local impl=${1}
+
+	# keep in sync with _PYTHON_ALL_IMPLS!
+	# (not using that list because inline patterns shall be faster)
+	case "${impl}" in
+		python2_7|python3_[678]|pypy3)
+			return 0
+			;;
+		jython2_7|pypy|pypy1_[89]|pypy2_0|python2_[56]|python3_[12345])
+			return 1
+			;;
+		*)
+			[[ ${PYTHON_COMPAT_NO_STRICT} ]] && return 1
+			die "Invalid implementation in PYTHON_COMPAT: ${impl}"
+	esac
+}
+_PYTHON_IMPLS_R1=1
+fi
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index aacee5ac35a..96e1bbbebe6 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -32,62 +32,9 @@ fi
 if [[ ! ${_PYTHON_UTILS_R1} ]]; then
 
 [[ ${EAPI} == 5 ]] && inherit eutils multilib
-inherit toolchain-funcs
-
-# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
-# @INTERNAL
-# @DESCRIPTION:
-# All supported Python implementations, most preferred last.
-_PYTHON_ALL_IMPLS=(
-	pypy3
-	python2_7
-	python3_6 python3_7 python3_8
-)
-readonly _PYTHON_ALL_IMPLS
-
-# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
-# @INTERNAL
-# @DESCRIPTION:
-# Set to a non-empty value in order to make eclass tolerate (ignore)
-# unknown implementations in PYTHON_COMPAT.
-#
-# This is intended to be set by the user when using ebuilds that may
-# have unknown (newer) implementations in PYTHON_COMPAT. The assumption
-# is that the ebuilds are intended to be used within multiple contexts
-# which can involve revisions of this eclass that support a different
-# set of Python implementations.
-
-# @FUNCTION: _python_impl_supported
-# @USAGE: 
-# @INTERNAL
-# @DESCRIPTION:
-# Check whether the implementation  (PYTHON_COMPAT-form)
-# is still supported.
-#
-# Returns 0 if the implementation is valid and supported. If it is
-# unsupported, returns 1 -- and the caller should ignore the entry.
-# If it is invalid, dies with an ap

[gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-26 Thread Patrick McLean
This patch splits the definition of _PYTHON_ALL_IMPLS and
_python_impl_supported to a separate eclass, this allows overlays
to easily support a different set of python implementations than
::gentoo without having to fork the entire suite of eclasses.
diff --git a/eclass/python-impls-r1.eclass b/eclass/python-impls-r1.eclass
new file mode 100644
index 000..0ae6e4e84a1
--- /dev/null
+++ b/eclass/python-impls-r1.eclass
@@ -0,0 +1,90 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: python-impls-r1.eclass
+# @MAINTAINER:
+# Python team 
+# @AUTHOR:
+# Author: Michał Górny 
+# Split to separate eclass by: Patrick McLean 
+# Based on work of: Krzysztof Pawlik 
+# @SUPPORTED_EAPIS: 5 6 7
+# @BLURB: Definitions of supported eclasses for python-utils-r1
+# @DESCRIPTION:
+# A helper eclass defining the supported python implementations for
+# the python-r1 suite of eclasses.
+#
+# This eclass is meant to be inherited by python-utils-r1, inheriting
+# it separately is very unlikely to be useful.
+#
+# For more information, please see the Python Guide:
+# https://dev.gentoo.org/~mgorny/python-guide/
+
+case "${EAPI:-0}" in
+	[0-4]) die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" ;;
+	[5-7]) ;;
+	*) die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" ;;
+esac
+
+if [[ ${_PYTHON_ECLASS_INHERITED} ]]; then
+	die 'python-r1 suite eclasses can not be used with python.eclass.'
+fi
+
+if [[ ! ${_PYTHON_IMPLS_R1} ]]; then
+
+# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
+# @INTERNAL
+# @DESCRIPTION:
+# All supported Python implementations, most preferred last.
+_PYTHON_ALL_IMPLS=(
+	pypy3
+	python2_7
+	python3_6 python3_7 python3_8
+)
+readonly _PYTHON_ALL_IMPLS
+
+# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
+# @INTERNAL
+# @DESCRIPTION:
+# Set to a non-empty value in order to make eclass tolerate (ignore)
+# unknown implementations in PYTHON_COMPAT.
+#
+# This is intended to be set by the user when using ebuilds that may
+# have unknown (newer) implementations in PYTHON_COMPAT. The assumption
+# is that the ebuilds are intended to be used within multiple contexts
+# which can involve revisions of this eclass that support a different
+# set of Python implementations.
+
+# @FUNCTION: _python_impl_supported
+# @USAGE: 
+# @INTERNAL
+# @DESCRIPTION:
+# Check whether the implementation  (PYTHON_COMPAT-form)
+# is still supported.
+#
+# Returns 0 if the implementation is valid and supported. If it is
+# unsupported, returns 1 -- and the caller should ignore the entry.
+# If it is invalid, dies with an appopriate error messages.
+_python_impl_supported() {
+	debug-print-function ${FUNCNAME} "${@}"
+
+	[[ ${#} -eq 1 ]] || die "${FUNCNAME}: takes exactly 1 argument (impl)."
+
+	local impl=${1}
+
+	# keep in sync with _PYTHON_ALL_IMPLS!
+	# (not using that list because inline patterns shall be faster)
+	case "${impl}" in
+		python2_7|python3_[678]|pypy3)
+			return 0
+			;;
+		jython2_7|pypy|pypy1_[89]|pypy2_0|python2_[56]|python3_[12345])
+			return 1
+			;;
+		*)
+			[[ ${PYTHON_COMPAT_NO_STRICT} ]] && return 1
+			die "Invalid implementation in PYTHON_COMPAT: ${impl}"
+	esac
+}
+_PYTHON_IMPLS_R1=1
+fi
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index aacee5ac35a..28df410d5a1 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -32,62 +32,7 @@ fi
 if [[ ! ${_PYTHON_UTILS_R1} ]]; then
 
 [[ ${EAPI} == 5 ]] && inherit eutils multilib
-inherit toolchain-funcs
-
-# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
-# @INTERNAL
-# @DESCRIPTION:
-# All supported Python implementations, most preferred last.
-_PYTHON_ALL_IMPLS=(
-	pypy3
-	python2_7
-	python3_6 python3_7 python3_8
-)
-readonly _PYTHON_ALL_IMPLS
-
-# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
-# @INTERNAL
-# @DESCRIPTION:
-# Set to a non-empty value in order to make eclass tolerate (ignore)
-# unknown implementations in PYTHON_COMPAT.
-#
-# This is intended to be set by the user when using ebuilds that may
-# have unknown (newer) implementations in PYTHON_COMPAT. The assumption
-# is that the ebuilds are intended to be used within multiple contexts
-# which can involve revisions of this eclass that support a different
-# set of Python implementations.
-
-# @FUNCTION: _python_impl_supported
-# @USAGE: 
-# @INTERNAL
-# @DESCRIPTION:
-# Check whether the implementation  (PYTHON_COMPAT-form)
-# is still supported.
-#
-# Returns 0 if the implementation is valid and supported. If it is
-# unsupported, returns 1 -- and the caller should ignore the entry.
-# If it is invalid, dies with an appopriate error messages.
-_python_impl_supported() {
-	debug-print-function ${FUNCNAME} "${@}"
-
-	[[ ${#} -eq 1 ]] || die "${FUNCNAME}: takes exactly 1 argument (impl)."
-
-	local impl=${1}
-
-	# keep in sync with _PYTHON_ALL_IMPLS!
-	# (not using that list

Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread Patrick McLean
On Thu, 26 Mar 2020 21:11:11 +0100
Michał Górny  wrote:

> On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> > There are situations in which downstream overlays need to have versions
> > of python which Gentoo no longer supports in the tree.
> > 
> > Currently, the only way to do this is for the overlay author to fork
> > python-utils-r1.eclass. This is highly undesirable since it creates a
> > very significant maintenance burden for the overlay author.  
> 
> Is it preferable to create the maintenance burden on Gentoo developers
> instead?  Is it fair that paid company developers shift the burden
> on people who work on Gentoo in their free time, and already have their
> plate full?

We have no intention of shifting maintenance burdens anywhere, we want
to make minor changes to make it easier for us to keep up. It's the
same as a Gentoo developer asking an upstream project to make minor
changes to their build system to support DESTDIR or a sandbox fix.

> 
> > The simplest way would be to apply the following patch.
> > In this situation, all the overlay author
> > would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable.  
> 
> ...which solves exactly zero problems because the eclass still doesn't
> support the implementation in question.  The best it could do is sweep
> part of the problem under the carpet.

We don't care if it *actually* supports it, the ebuilds in question
aren't going to be installed on modern machines. We just want it to not
blow up in the global scope.

> Even if it miraculously works right now at all, it will probably fail or
> misbehave randomly.  Any eclass change might break it.  Then one cheap
> hack will serve as an excuse to add one more, and another.\
> 
> > The other option would be to move _PYTHON_ALL_IMPLS and  the
> > implementation of _python_impl_supported to a separate eclass, e.g.
> > python-impls-r1.eclass. This eclass could be forked freely downstream
> > without worrying about the other python eclasses.  
> 
> Again, this doesn't solve the problem.  It just moves the problem
> elsewhere.  
> 

How does this not solve the problem? Overlays could trivially support
different implementations, without maintaining a lot of forks. We are
quite happy to do the work to split it out to a separate eclass.

> > Thoughts?  
> 
> I've already told you that if you want to fork, fork all eclasses.  Then
> you wouldn't have to worry about internal API going out of sync.
> 
> Or don't autoupdate ::gentoo when eclasses change.
> 




[gentoo-dev] [RFC v2] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Patrick McLean
Title: OpenSSH 8.2_p1 running sshd breakage
Author: Patrick McLean 
Posted: 2020-02-21
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: =net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
restarted.

Before restarting sshd, it is *strongly* recommended that you test your
configuraton with the following command (as root):
sshd -t

If your system is booted with openrc, use this command  (as root) 
to restart sshd:
rc-service sshd --nodeps restart

If your system is booted with systemd, use this command (as root)
to restart sshd:
systemctl restart sshd

If you are using systemd socket activation for sshd, then no action is
required.

WARNING: On systemd booted machines with PAM disabled, this command
 will terminate all currently open ssh connections. It is *strongly*
 recommended that you validate your configuration before restarting
 sshd.



[gentoo-dev] [RFC] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Patrick McLean
Title: OpenSSH 8.2_p1 running sshd breakage
Author: Patrick McLean 
Posted: 2020-02-21
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: =net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
restarted.

Before restarting sshd, it is *strongly* recommended that you test your
configuraton with the following command (as root):
sshd -t

If your system is booted with openrc, use this command  (as root) 
to restart sshd:
/etc/init.d/sshd restart

If your system is booted with systemd, use this command (as root)
to restart sshd:
systemctl restart sshd

WARNING: On systemd booted machines, this command will terminate all currently
 open ssh connections, it is *strongly* reccommended that you validate
 your configuration before restarting sshd.



Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation

2019-11-20 Thread Patrick McLean
On Thu, 7 Nov 2019 11:52:19 -0800
Patrick McLean  wrote:

I will push the attached version with zmedico's change on Friday unless
there are objections (I have addressed all the feedback so far AFAIK).

> Given glibc upstream's tentative plans to remove libcrypt [1], I think
> we should start working out the kinks well in advance. Toolchain has
> already added a package.use.force-ed "crypt" USE flag to
> sys-libs/glibc-2.30-r2 [2]. The main alternative out there is libxcrypt,
> which I have recently bumped and added a package.use.mask-ed "system"
> USE flag to make it provide the "system" version of libcrypt.so.
> 
> To give us time to work out dependencies in advance, I would like to
> propose a virtual to provide libcrypt.so, and we can gradually update
> all users of libcrypt to {R,}DEPEND on this virtual.
> 
> Maybe once this is in place and the obvious/common packages are
> updated, we could request a tinderbox run to flush out what was missed.
> 
> 
> [1] 
> https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=50479f17c9a3a5ef074dafa3f23aca954b82bd6a;hb=HEAD#l768
> [2] https://bugs.gentoo.org/699422



libcrypt-0.ebuild
Description: Binary data


Re: [gentoo-dev] [PATCH 1/4] distutils-r1.eclass: Add distutils_enable_sphinx helper function

2019-11-20 Thread Patrick McLean
Hi Michał,

Thanks for doing this work, it's always better to have standardized
ways of doing things.

On Wed, 20 Nov 2019 15:21:55 +0100
Michał Górny  wrote:



> +distutils_enable_sphinx() {
> + debug-print-function ${FUNCNAME} "${@}"
> + [[ ${#} -ge 1 ]] || die "${FUNCNAME} takes at least one arg: "
> +
> + _DISTUTILS_SPHINX_SUBDIR=${1}
> + shift
> + _DISTUTILS_SPHINX_PLUGINS=( "${@}" )
> +
> + local deps autodoc=1 d
> + for d; do
> + if [[ ${d} == --no-autodoc ]]; then
> + autodoc=
> + else
> + deps+="
> + ${d}[\${PYTHON_USEDEP}]"
> + fi
> + done
> +
> + if [[ ! ${autodoc} && -n ${deps} ]]; then
> + die "${FUNCNAME}: do not pass --no-autodoc if external plugins 
> are used"
> + fi
> + if [[ ${autodoc} ]]; then
> + deps="$(python_gen_any_dep "
> + dev-python/sphinx[\${PYTHON_USEDEP}]
> + ${deps}")"
> +
> + python_check_deps() {
> + use doc || return 0
> + local p
> + for p in "${_DISTUTILS_SPHINX_PLUGINS[@]}"; do
> + has_version "${p}[${PYTHON_USEDEP}]" || return 1
> + done
> + }

I think it would be better to put this code in sphinx_check_deps
(or some such) and define a python_check_deps that just calls
sphinx_check_deps. That would allow ebuilds that need to do more than
the sphinx stuff to not have to reimplement this.

> + else
> + deps="dev-python/sphinx"
> + fi
> +
> + python_compile_all() {
> + use doc || return
> +
> + cd "${_DISTUTILS_SPHINX_SUBDIR}" || die
> + [[ -f conf.py ]] ||
> + die "conf.py not found, distutils_enable_sphinx call 
> wrong"
> +
> + if [[ ${_DISTUTILS_SPHINX_PLUGINS[0]} == --no-autodoc ]]; then
> + if grep -q 'sphinx\.ext\.autodoc' "conf.py"; then

Since this is just searching for a fixed string maybe
"grep -F -q 'sphinx.ext.autodoc'" is a bit nicer.

> + die "distutils_enable_sphinx: --no-autodoc 
> passed but sphinx.ext.autodoc found in conf.py"
> + fi
> + else
> + if ! grep -q 'sphinx\.ext\.autodoc' "conf.py"; then
> + die "distutils_enable_sphinx: 
> sphinx.ext.autodoc not found in conf.py, pass --no-autodoc"
> + fi
> + fi
> +
> + # disable intersphinx (internet use)
> + sed -e 's:^intersphinx_mapping:disabled_&:' -i conf.py || die
> + # not all packages include the Makefile in pypi tarball
> + sphinx-build -b html -d _build/doctrees . _build/html || die
> +
> + HTML_DOCS+=( "${_DISTUTILS_SPHINX_SUBDIR}/_build/html/." )
> + }

Same as above, I think it would be better to define this as
sphinx_compile, and define a python_compile_all that just calls it.
That way if an ebuild defines it's own python_compile_all it can call
sphinx_compile to get this functionality.

> +
> + IUSE+=" doc"
> + if [[ ${EAPI} == [56] ]]; then
> + DEPEND+=" doc? ( ${deps} )"
> + else
> + BDEPEND+=" doc? ( ${deps} )"
> + fi
> +
> + # we need to ensure successful return in case we're called last,
> + # otherwise Portage may wrongly assume sourcing failed
> + return 0
> +}
> +
>  # @FUNCTION: distutils_enable_tests
>  # @USAGE: 
>  # @DESCRIPTION:




Re: [gentoo-dev] packages up for grabs

2019-11-18 Thread Patrick McLean
On Mon, 18 Nov 2019 17:47:22 -0700
Tim Harder  wrote:

> The following list of packages are up for grabs that I dropped myself
> as as a direct maintainer from. There are probably a significantly
> larger number that I've indirectly maintained hiding under the guise
> of older projects that mostly act likes herds (e.g. graphics, sound,
> and vim to name a few) so interested parties should feel free to
> directly add themselves as maintainers for such packages.
> 
> Note that some of the packages in this list already have maintainers,
> but I'm sure most of them wouldn't mind co-maintainers.

> app-misc/jq
> app-misc/ltunify
> dev-libs/libyaml
> dev-vcs/tig

I can take these ones.



[gentoo-dev] RFC acct-{user,group} for ceph

2019-11-13 Thread Patrick McLean
Fedora, CentOS, RHEL and alpine use 167, debian uses 64045

I propose using 267 what Fedora etc uses is already reserved in Gentoo,
and 64045 is reserved.



Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation

2019-11-07 Thread Patrick McLean
On Thu, 7 Nov 2019 20:40:40 +
Sergei Trofimovich  wrote:

> On Thu, 7 Nov 2019 11:52:19 -0800
> Patrick McLean  wrote:
> 
> > Given glibc upstream's tentative plans to remove libcrypt [1], I
> > think we should start working out the kinks well in advance.
> > Toolchain has already added a package.use.force-ed "crypt" USE flag
> > to sys-libs/glibc-2.30-r2 [2]. The main alternative out there is
> > libxcrypt, which I have recently bumped and added a
> > package.use.mask-ed "system" USE flag to make it provide the
> > "system" version of libcrypt.so.
> > 
> > To give us time to work out dependencies in advance, I would like to
> > propose a virtual to provide libcrypt.so, and we can gradually
> > update all users of libcrypt to {R,}DEPEND on this virtual.  
> 
> It's not clear how this virtual is supposed to work when
> sys-libs/libxcrypt actually changes ABI. Do we care about the missing
> rebuilds or we do not?

I clarified this in a reply to mgorny's message.

> 
> If we don't it's (not ideal but) fine. But it should be stated
> explicitly and consequences should be described: does
> sys-libs/libxcrypt override glibc's libcrypt.so.1 and break existing
> applications? Or we guarantee it not to happen?
> 
> > elibc_glibc? ( || (
> > sys-libs/glibc[crypt(+)]
> > sys-libs/libxcrypt[system(-)]
> > )
> > )  
> 
> Same for switching providers back and forth. For example, should we
> allow user to come back from sys-libs/libxcrypt to sys-libs/glibc?

With the current dual-library approach, switching back and fourth is
possible, but may involve a preserved-libs rebuild of recently built
packages. Portage does detect this and handle it cleanly.

> 
> > Maybe once this is in place and the obvious/common packages are
> > updated, we could request a tinderbox run to flush out what was
> > missed.  
> 
> I don't think tinderbox will find much as util-linux, shadow or any
> other low-level package will pull it in as a dependency and be
> silently available.

I suppose that is true, though we could detect via the NEEDED* files
that portage generates in the vdb (we just need _all_ packages to be
installed somewhere at some point to detect it).

> 
> I think you'll need to do extra to find those. Like, removing
> libcrypt.so to make sure linker won't find it even if libcrypt.so.1
> is available.

That is another approach, we could do some hackery in the tinderbox
once the basic system packages are there so we can detect those.

> 
> > [1]
> > https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=50479f17c9a3a5ef074dafa3f23aca954b82bd6a;hb=HEAD#l768
> > [2] https://bugs.gentoo.org/699422  
> 
> 




Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation

2019-11-07 Thread Patrick McLean
On Thu, 07 Nov 2019 21:28:34 +0100
Michał Górny  wrote:

> On Thu, 2019-11-07 at 11:52 -0800, Patrick McLean wrote:
> > Given glibc upstream's tentative plans to remove libcrypt [1], I
> > think we should start working out the kinks well in advance.
> > Toolchain has already added a package.use.force-ed "crypt" USE flag
> > to sys-libs/glibc-2.30-r2 [2]. The main alternative out there is
> > libxcrypt, which I have recently bumped and added a
> > package.use.mask-ed "system" USE flag to make it provide the
> > "system" version of libcrypt.so.
> > 
> > To give us time to work out dependencies in advance, I would like to
> > propose a virtual to provide libcrypt.so, and we can gradually
> > update all users of libcrypt to {R,}DEPEND on this virtual.
> > 
> > Maybe once this is in place and the obvious/common packages are
> > updated, we could request a tinderbox run to flush out what was
> > missed.  
> 
> Are you planning to use backwards-compatible .so.1 version of
> libxcrypt, or do you plan to switch to .so.2?

The current plan would be to initially we would be install both a .so.1
with full ABI compatibility with glibc (libxcrypt supports this) and a
.so.2 that libcrypt.so symlinks to without glibc compatibility (with
USE="compat" this is the current behaviour of the ebuild). Current
packages are using the .so.1 and any new builds end up linking to the
.so.2.

Eventually we can turn off the "compat" USE flag by default, some users
might end up doing preserved-libs rebuilds, but hopefully by that time
most stuff will be using .so.2.

> > 
> > 
> > [1]
> > https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=50479f17c9a3a5ef074dafa3f23aca954b82bd6a;hb=HEAD#l768
> > [2] https://bugs.gentoo.org/699422  
> 




[gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation

2019-11-07 Thread Patrick McLean
Given glibc upstream's tentative plans to remove libcrypt [1], I think
we should start working out the kinks well in advance. Toolchain has
already added a package.use.force-ed "crypt" USE flag to
sys-libs/glibc-2.30-r2 [2]. The main alternative out there is libxcrypt,
which I have recently bumped and added a package.use.mask-ed "system"
USE flag to make it provide the "system" version of libcrypt.so.

To give us time to work out dependencies in advance, I would like to
propose a virtual to provide libcrypt.so, and we can gradually update
all users of libcrypt to {R,}DEPEND on this virtual.

Maybe once this is in place and the obvious/common packages are
updated, we could request a tinderbox run to flush out what was missed.


[1] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=50479f17c9a3a5ef074dafa3f23aca954b82bd6a;hb=HEAD#l768
[2] https://bugs.gentoo.org/699422


libcrypt-0.ebuild
Description: Binary data


Re: [gentoo-dev] [RFC] News Item: Desktop profile switching USE default to elogind

2019-10-29 Thread Patrick McLean
On Tue, 29 Oct 2019 23:03:15 +
James Le Cuirot  wrote:

> On Tue, 29 Oct 2019 11:23:20 -0700
> Patrick McLean  wrote:
> 
> > On Tue, 29 Oct 2019 16:10:37 +0100
> > Andreas Sturmlechner  wrote:
> >   
> > > 
> > > Anyone else who thinks this should not be restricted to just
> > > desktop profiles?
> > 
> > I am not aware of any use cases for elogind/consolekit on servers,
> > it's really for machines where you have to distinguish between
> > someone connecting remotely and someone physically using a
> > keyboard/mouse connected to the machine.  
> 
> I switched from consolekit to elogind on my normally headless ARM box.
> It runs XMMS2 and outputs through PulseAudio. Under consolekit, my
> user's /var/run directory would disappear after a while, taking the
> pulse socket with it. Under elogind, I was able to set my user to
> "linger", which fixed the issue. It's not a typical use case but yeah,
> they do have uses outside of desktop.

Which sounds like perfect for a local setup, probably not something
that should be in a generic profile.




Re: [gentoo-dev] [RFC] News Item: Desktop profile switching USE default to elogind

2019-10-29 Thread Patrick McLean
On Tue, 29 Oct 2019 16:10:37 +0100
Andreas Sturmlechner  wrote:

> 
> Anyone else who thinks this should not be restricted to just desktop
> profiles?

I am not aware of any use cases for elogind/consolekit on servers, it's
really for machines where you have to distinguish between someone
connecting remotely and someone physically using a keyboard/mouse
connected to the machine.



Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass

2019-09-13 Thread Patrick McLean
On Fri, 13 Sep 2019 19:44:55 -0400
Michael Orlitzky  wrote:

> (Replying to both messages at once.)
> 
> 
> On 9/13/19 4:17 PM, Patrick McLean wrote:
> >>  
> > I don't think anyone here has suggested that any go packages are
> > installed in the stage3 tarballs, or included in profiles.
> > Something's presence in the tree does not mean that you are
> > required to install it. A package's presence in the tree really has
> > little to zero effect on any user that does not use the package. If
> > you do not install the package, it will have zero effect on your
> > banking.  
> 
> This is true only so far as they never become dependencies of anything
> else. Do all new developers know that dev-go is an insecure ghetto? Do
> our users? Or might someone accidentally install or depend upon
> something in dev-go before learning that crucial bit of information?

A suggestion was made on IRC to have a pkg_postinst in the eclass that
warn about golang package dependencies not having the same level of
Gentoo security coverage that other packages in the tree have due to
static linking. I think this is a reasonable approach, and users and
developers will know. There is precedent for this, see
sys-kernel/vanilla-sources

> > I also want to point out that the Gentoo packages for Firefox,
> > Chromium, and Webkit all have a _lot_ of bundled dependencies and
> > absolutely do static linking internally. If you are using a browser
> > to do your banking, you are almost certainly using static linking,
> > even without the presence of code written in golang.  
> 
> Is this is a "two wrongs make a right" argument? I'm telling mom =P

I am pointing out that we can't ban all static linking in the tree,
many upstream packages won't work without it (or significant effort
that no one has the time or motivation for).

> > Despite your (and my) objections to it's approach to linking,
> > golang is a very popular language these days with some very popular
> > packages written in it.  
> 
> No it's not. It's below Delphi and Object Pascal on TIOBE this month.
> It's a trend that a tiny percentage of people jumped on because they
> heard the name "Google" back when Google was cool.

Random stats from a website are not really an indication of how much a
language is being used. There are plenty of very popular packages that
are written in golang.

> The "people want this in Gentoo" argument I understand, but people
> don't really have it "in Gentoo." They have a thin wrapper around the
> "go" command. They don't get the Gentoo security guarantees, they
> don't get the Gentoo license handling, they don't get the ease of
> management that comes with a Gentoo @world update. They silently get
> something less than they're expecting. We would be better off telling
> people to run "go whatever" themselves, or by putting this stuff in
> an overlay where expectations are clearly defined.

Users and Gentoo developers want Docker and Kubernetes (to name a
couple) in the main tree. These are written in golang. I don't think we
should ban packages because of the language they are written in.
Especially if there are developers who want to maintain them.

They do get the ease of management of @world in that if the upstream
package releases a new version, it will be pulled in via an @world
update. That is quite a large advantage to users, and is worth doing if
there are developers willing to maintain the packages in the tree.

> 
> > While I personally have opinions about static linking (I basically
> > completely agree with you that it's a dumb idea). That said, this
> > has nothing to do with this particular discussion, I suggest you
> > take it up with the golang upstream. I don't think anyone here is
> > arguing that static linking is a great idea and everyone should do
> > it.  
> 
> We just have a philosophical difference here. I don't think we should
> commit admittedly-dumb ideas to ::gentoo. These packages would work
> fine in an overlay until such a time as someone is interested in
> doing things correctly. They also work "fine" if you install them
> with "go" yourself: Portage isn't doing much for you when everything
> is bundled, statically linked, and has LICENSE set incorrectly.

When "doing things correctly" means basically forking the entire
ecosystem and maintaining all the forks internally, that is not
something that is ever going to happen. There is demand from users and
developers for golang packages.

It's the same reason why we don't unbundle everything in Firefox and
Chromium, it's simply too much work. It basically means maintaining our
own fork of the package. That also means security updates will take
sign

Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass

2019-09-13 Thread Patrick McLean
On Fri, 13 Sep 2019 12:50:48 -0400
Michael Orlitzky  wrote:

> On 9/12/19 1:45 PM, Alec Warner wrote:
> > 
> > Er, I'm fairly sure computer *science* has not conclusively proven
> > that dynamic binaries are somehow superior to static binaries.
> >   
> 
> 
> If you statically link to a library, then none of its implementation
> details are hidden from you -- you need to "reassemble" your program
> whenever the library changes.
> 
> If we jump way forward to 1979, the SICP[1] is basically a
> thousand-page treatise on abstraction. But not only at one level of
> computation:
 
While I personally have opinions about static linking (I basically
completely agree with you that it's a dumb idea). That said, this has
nothing to do with this particular discussion, I suggest you take it up
with the golang upstream. I don't think anyone here is arguing that
static linking is a great idea and everyone should do it.

We are arguing that the golang community believes strongly in static
linking, and the entire ecosystem is designed around this idea, as such
trying to bodge dynamic linking on to the existing ecosystem is
probably more work than it is worth. In general, developers Gentoo
tries to stay close to upstream as much as possible, as this reduces
the maintenance burden.

The entire point of this thread is to try to find a sane way to support
the golang community's standards. I think the merits of static linking
are out of scope here.

>   Well-designed computational systems, like well-designed automobiles
> or nuclear reactors, are designed in a modular manner, so that the
> parts can be constructed, replaced, and debugged separately.
> 
> "Replaced" here is of course what I want to draw your attention to.
> But also on the fact that abstraction and modularity don't just apply
> at one level of software design and engineering -- it's a fractal. At
> the lowest levels, we abstract machine code to assembler, assembler to
> low-level languages, low-level languages to high-level languages,
> high-level languages to functions and procedures, functions and
> procedures to libraries, libraries to services, and services to
> distributed APIs. The same principles that apply to a collection of
> functions (a program) also apply to a collection of programs (an
> operating system). The rule "don't copy and paste code" applies to
> your linker just as much as it applies to the first program you wrote
> in CS101, and for the same reasons.
> 
> As you commented on IRC, the cost in terms of man-power is that
> someone's workload jumps from O(n) to O(m*n), because you have to
> duplicate everything you do for every statically-linked dependency.
> And you can find as much theory as you like on software modularity in
> papers from the 1970s and 1980s, but the benefits are not only
> theoretical. There's a mountain of empirical data that supports the
> theory. Some choice quotes [2][3]:
> 
>   Poorly placed dependencies, especially those that link otherwise
>   independent modules, may result in a cascade of unwanted and
> hard-to- detect indirect interactions. Our results suggest that
> purposeful actions to reduce such "rogue dependencies" can be
> effective (the redesign of Mozilla reduced propagation cost by over
> 80%).
> 
>   Our results confirm the existence of a relationship between
> component modularity and design evolution that is both statistically
> significant and large in magnitude... Tightly-coupled components
> are... less adaptable  via the processes of exclusion or
> substitution; they are more likely to  experience "surprise"
> dependency additions unrelated to new functionality, implying that
> they demand greater maintenance efforts;  and they are harder to
> augment, in that the mix of new components is  more modular than the
> legacy design.
> 
> The only difference between static linking and copy/pasting chunks of
> code around is in who pays the price. If the programmer copies &
> pastes code into his own program, he will eventually have to deal
> with the mess. On the other hand, it he forces his program to be
> statically linked, then it is the end user who is harmed by his
> decision.
> 
> In any case, the theory says that modularity is superior, and the
> empirical data confirm it. The fact that you won't find a paper saying
> "dynamic linking is better than static linking" is somewhat beside the
> point, and only muddies the water. Linking is just one specific
> instance of a problem that was solved 40 years ago.
> 
> 
> [0]
> https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf
> 
> [1] https://web.mit.edu/alexmv/6.037/sicp.pdf
> 
> [2] https://pubsonline.informs.org/doi/10.1287/mnsc.1060.0552
> 
> [3] http://www.hbs.edu/research/pdf/08-038.pdf
> 




Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass

2019-09-13 Thread Patrick McLean
On Fri, 13 Sep 2019 08:29:20 -0400
Michael Orlitzky  wrote:

> On 9/13/19 5:19 AM, Kent Fredric wrote:
> > On Thu, 12 Sep 2019 17:58:08 -0400
> > Michael Orlitzky  wrote:
> >   
> >> What kind of math would convince you that an idea with all "cons"
> >> and no "pros" is bad?  
> > 
> > Is "upstream tooling doesn't work without static compilation" or
> > "built packages tend to need exact version matching at runtime to
> > work" ( which necessitates massive-scale multi-slotting, where
> > every version of every packaged "thing" has a co-existing slot ) a
> > problem for you? 
> 
> I see it as a problem, but not one that has to be my problem. I don't
> see it as a foregone conclusion that we have to package every piece of
> software -- no matter how bad -- and distribute it with the OS that I
> use to do my banking.
> 
I don't think anyone here has suggested that any go packages are
installed in the stage3 tarballs, or included in profiles. Something's
presence in the tree does not mean that you are required to install it.
A package's presence in the tree really has little to zero effect on
any user that does not use the package. If you do not install the
package, it will have zero effect on your banking.

I also want to point out that the Gentoo packages for Firefox,
Chromium, and Webkit all have a _lot_ of bundled dependencies and
absolutely do static linking internally. If you are using a browser to
do your banking, you are almost certainly using static linking, even
without the presence of code written in golang.

> These languages are badly implemented, and very little of value is
> written in them. If their developers ever hit 2+ users, I'm sure
> they'll realize that everyone else was right back in the 1970s, and
> fix the design. But in the meantime, this stuff belongs in an
> overlay. Lowering our standards until they match upstream's is
> antithetical to how a distribution is supposed to improve my life.

Despite your (and my) objections to it's approach to linking, golang is
a very popular language these days with some very popular packages
written in it. Docker and Kubernetes immediately come to mind, but
there are many others. The argument "I don't use, and I dislike the
implementation language, so no one should use it" is not a very
compelling argument.

These are very popular packages, that users and developers absolutely
want to be available in Gentoo. Given this fact, and the fact that
there are Gentoo developers who want these packages enough that they
will maintain the packages, they absolutely do belong in the tree.



Re: [gentoo-dev] the state of dev-lang/lua

2019-03-26 Thread Patrick McLean
On Mon, 25 Mar 2019 04:23:08 +
"Robin H. Johnson"  wrote:

> On Sat, Mar 23, 2019 at 04:23:27PM -0500, William Hubbs wrote:
> > Hi all,
> > 
> > Soon I will be working on fixing up the state of dev-lang/lua, and
> > there are a couple of things I want to mention.
> > 
> > The first thing is liblua as a shared library. If you are using lua
> > internally in a program, upstream strongly recommends not linking it
> > this way; it is supposed to be statically linked into the
> > executable. Because of this, and because of the amount of custom
> > patching we do to maintain liblua as a shared library, I plan to
> > stop creating the shared library.  
> Please don't go back to static libraries. Look at the other major
> distros, all of them shipped shared Lua as the primary method.

+1

> 
> > I'm a bit undecided still about slotting lua. I'm sure we
> > need subslots so we can force rebuilds when new lua releases enter
> > the tree. However, I'm still unsure whether we need slots. I don't
> > know of many things in the tree that are locked to a specific
> > version of lua (there is only one package based on an irc
> > conversation I had this week).
> > Does anyone have any thoughts?   
> Lua needs first class slots, just like Python & Ruby, not just
> subslots. Changing between versions can be a major undertaking.
> 
> I think the slots to start with should be:
> - lua5.1
> - lua5.2
> - lua5.3
> - luajit5.1 (this is basically an alternative implementation of
> Lua5.1, much like pypy implements Python2).

I think we are going to have to have slots for the "openresty" lua
fork here as well. Several nginx modules require this version to work
properly (I can provide more details if needed).





Re: [gentoo-dev] Regarding the State of PaX in the tree

2018-04-16 Thread Patrick McLean
On 2018-04-16 05:12 AM, Anthony G. Basile wrote:
> On 4/16/18 4:05 AM, Marc Schiffbauer wrote:
>> * Anthony G. Basile schrieb am 16.04.18 um 02:04 Uhr:
>>> Hi everyone,
>>
>> Hi Anthony,
>>
>> I vote for keeping PaX Support as I am still using it and might be doing 
>> so in the future.
>>
>> Thanks ;)
>> -Marc
>>
> 
> How are you able to test?  Do you have your hands on the latest grsec
> patches or are you using an old kernel.  Old at this point means one
> year old.
> 

I am able to test, we have access to the latest grsecurity kernels at my
employer, and we would very much prefer to keep the PaX markings around.

We (I work with several Gentoo developers) are actively testing all the
packages we use internally with newer kernels, and fixing anything that
breaks.



Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

2018-03-23 Thread Patrick McLean
On 2018-03-23 06:27 AM, Rich Freeman wrote:
> On Fri, Mar 23, 2018 at 6:59 AM, Ulrich Mueller  wrote:
>>> On Fri, 23 Mar 2018, Roy Bamford wrote:
>>
>>> games-emulation/sdlmame is masked. I have a higher version in my
>>> overlay than the one in the tree and it gets masked too.
>>> Its not a problem to me as I know how to manage it.  Its just untidy.
>>
>> You still don't need a repository specific mask for this. Version
>> specific masking and unmasking is entirely sufficient to express that
>> the higher version is fine.
>>
> 
> It sounds to me that one of the intended behaviors is to tell portage
> that for a particular package we want to ignore a particular
> repository entirely.  Suppose for example an overlay contains
> misc/foo-3, and the main repo introduces misc/foo-4.  Perhaps we want
> portage to stick with foo-3 from the overlay.  However, if the overlay
> adds foo-4, or foo-4.1 we want this installed.  A version mask would
> not really cover this use case.
> 
> IMO this sounds like a useful feature.  Having it in profiles could
> probably also be useful in some testing scenarios, such as when making
> changes to a large number of packages that are already in the main
> tree (think something analogous to a feature branch in git, where the
> master branch continues to advance).>
> Perhaps I'm misunderstanding the intent here, but I would suggest that
> we describe the end goal in emails like these otherwise people focus
> on the implementation details first.
> 

Having the ability to specify a repository in atoms in profile is very
useful to people who have large overlays and make heavy use of profiles.

At my (and zmedico's) employer we use Gentoo heavily (all of our servers
run it), and have a few large internal overlays and hundreds of internal
profiles. There are packages in upstream Gentoo that we maintain an
internal fork of, and it would be extremely useful if we could mask the
::gentoo version of something so a version bump does not cause it to be
installed instead of our forked version.

To address ulm's comments, we want our internal fork to satisfy
dependencies in ::gentoo for the package without having to fork dozens
of ebuilds. Generally the forks are just for minor changes that do not
break dependency compatibility, but do something that we need for
whatever reason.

In case there are questions about why we have hundreds of profiles, we
use profile to define machine roles. Each internal machine type or role
has a profile in one of our internal repositories. This allows us to
manipulate USE flags, packages etc in each machine type with a fair bit
of fine-grained control. Adding repository support to profile atoms will
give us even more control, and having fine grained control over what we
have on our servers is the main reason we run Gentoo.



Re: [gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged

2017-11-21 Thread Patrick McLean


On 2017-11-21 03:19 AM, Benda Xu wrote:
> Francesco Riosa  writes:
> 
>> maybe ewarn() is more appropriate than einfo()?
>> Just in case it's executed outside the scope of prefix
> 
> I can't remember any use case when portage (or, paludis, etc.) is
> executed as a normal user but not a from Prefix.
> 
> This message will only affect Prefix users, who won't be surprised that
> they cannot create new groups or users.  Therefore I think einfo is more
> appropriate.
> 
> 
> Furthermore, we do have Prefix that runs as a root, mostly usable on NAS
> or smartphones, when we do ultimately like portage to manage groups and
> users.

I use portage as non-root all the time when developing and testing
ebuilds, via the "ebuild" command.



Re: [gentoo-dev] Reviving the Sandbox project

2017-09-22 Thread Patrick McLean


On 2017-09-22 10:03 AM, Brian Dolbec wrote:
> On Fri, 22 Sep 2017 15:06:49 +
> James McMechan  wrote:
> 
>> On Fri, Sep 22, 2017 at 5:27 AM, Rich Freeman 
>> wrote: 
>>> On Fri, Sep 22, 2017 at 7:38 AM, Sergei Trofimovich
>>>  wrote:  

 Some other distros try harder to isolate build environment either
 through chroot and/or private mount/user/network namespace that
 contains only explicitly specified files in build environment.

 That would require more cooperation from package manager to fetch
 list of all visible depends.
  
>>>
>>> I definitely think this is something that would be VERY useful to
>>> have, because it makes build-time dependency issues almost
>>> impossible.
>>>
>>> However, you don't need that complete solution just to have a
>>> sandbox. You could simply create a container with the entire
>>> contents of the main filesystem, but read-only, with the exception
>>> of the build area. That would replicate the functionality of the
>>> current sandbox and would be easier than building out just the files
>>> specified in the dependencies.
>>>
>>> The main issue I see with making it dependency aware is performance.
>>> You would need to walk all the dependencies and their run-time
>>> dependencies, and the system set, and then individually bind-mount
>>> the files that belong to them read-only into the container.  That
>>> isn't necessarily difficult, but I imagine that it would be slow.
>>> Walking the dependencies obviously already happens during resolution
>>> so that could probably be cached.  You could also cache the list of
>>> files for the system set, and you could even maintain a snapshot of
>>> these that is used as the base of the container (somebody would need
>>> to work out the savings of doing this vs the cost of updating it
>>> every time a system set package changes).
>>>
>>> However, the main thing I wanted to point out is that you don't need
>>> a dependency-aware solution to just replace the existing sandbox.
>>>  
 I like clear sandbox error reporting.  
>>>
>>> As far as error reporting goes, you would get kernel-level errors
>>> like attempting to write to a read-only bind mount, or trying to
>>> read a file that doesn't exist.  To a portage dev it should be
>>> pretty obvious what is going on.  You could add canned text to the
>>> portage error output at the end.  I'm not sure how visible the
>>> problems would be to portage except to the degree that the build
>>> system makes them visible
>>> - it would just see make terminate with a non-zero return.
>>>
>>> I would think that containers would be almost completely bug-free
>>> though.  The only thing I could see as an issue is some build system
>>> that relies on IPC with the host, network access, etc.  Namespaces
>>> themselves are very robust, and the kernel already looks at every
>>> process as belonging to a set of namespaces even in the default case
>>> where you only have one set of namespaces on the system, so they
>>> don't involve different code paths/etc.
>>>
>>> -- 
>>> Rich  
>>
>> Another possibility, could be to have the sandbox be an overlayfs
>> not of the build directory but of the entire system starting at "/"
>> and stick that into the container, only CLONE_NEWNS looks to be
>> needed.
>>
>> A container with all writes going to the upper layer of the overlay
>> could be safe against even #RM -RF / and other disasters, while still
>> tracking what is happening during the build.
>>
>> Should performance be too much of a problem having a bind mount of
>> the build directory on top of the overlay should give normal
>> performance to everything that is obeying good practice.
>>
>> After the build completes the directory that was mounted as upper
>> could be scanned to find any wayward writes that had occurred...
>>
>> This would not require LD_PRELOAD or ptrace eliminating most of the
>> "high magic" currently used.
>>
>> Just yesterday I had a lot of ptrace failures while trying something
>> odd with ROOT= and custom USE
>>
>> Jim McMechan
> 
> I kinda like this idea, It looks to me to have pretty much all the
> benefits of a sandbox and nearly none of the drawbacks.
> 
> Sounds like it should get more research into this idea, figure out it's
> limitations and if there are any caveats.
> 

I haven't had time as of yet to look in to it, but theoretically one
could use seccomp with bpf to make a more robust sandbox, though you
might not get as nice error reporting as we have now.

Also apparmor could theoretically be used to make a nice sandbox, but I
suspect that could come with other implications.



Re: [gentoo-dev] Reviving the Sandbox project

2017-09-21 Thread Patrick McLean


On 2017-09-21 02:07 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 21.09.2017 kell 22:54, kirjutas Michał Górny:
>> W dniu czw, 21.09.2017 o godzinie 23∶33 +0300, użytkownik Mart
>> Raudsepp
>> napisał:
>>> Ühel kenal päeval, N, 21.09.2017 kell 21:56, kirjutas Michał Górny:
 Hi, everyone.

 TL;DR: I'm looking for new people to resume work on sandbox, and
 I
 will
 most likely branch it at v2.10 and start keep-alive work on top
 of
 that.


 The state of our sandbox is not very well. Gentoo is currently
 using
 the old v2.10 with local patches. v2.11 is p.masked for a long
 time
 because of multiple unsolved bugs. The git repository also
 includes
 v2.12 tag that has not even been packaged for Gentoo. From what
 I've
 been able to establish, the bugs causing v2.11 mask are still
 present
 in git head.

 To add to this, the only person maintaining the code (vapier) has
 not
 touched it since March, and AFAIA he's not responding to any
 contact
 attempts from within Gentoo. Given this and the importance of
 sandbox
 to
 Gentoo at the moment, I think it's reasonable to presume he's MIA
 and start looking for volunteers to join the effort.

 I have already added myself to the project page [1] and I'm going
 to
 try
 to put some effort into improving the state of things. However,
 I'm
 not
 really an expert in the high magic used in sandbox. If anyone is
 interested in helping out, feel free to add yourself as well.


 The above considered, I don't think I'm really going to be able
 to
 solve
 the problems introduced by v2.11. If nobody has a better idea,
 I'm
 going
 to branch sandbox at v2.10 and look into backporting whatever's
 feasible
 and resuming development in hotfix mode on top of that.
>>>
>>> Do you have a handy list of problems with v2.11?
>>> Perhaps all is well for Gentoo usages after the more ptrace-happy
>>> fallbacking commit (apparently was needed by ChromeOS) is reverted
>>> if
>>> ptrace-path problems don't get fixes?
>>>
>>
>> There are two bugs listed in p.mask reason. There's a lot of bugs on
>> Bugzilla but I don't know which versions they affect.
> 
> 
> #580726 comes from the ptrace thing I mentioned. I identified the
> commit that makes it fallback to ptrace for firefox case, while it
> seemed to work fine before without fallback, and then there are issues
> in that ptrace codepath that might have always been there, but they
> just didn't get hit due to ptrace fallback being much rarer before
> this. I believe the commit hash is mentioned on the bug.
> 

I have been running sandbox-2.11 for quite awhile on my workstation, the
only problem I have actually encountered is the issue with Firefox. That
issue seems to have gone away in firefox-55 though, so I am not sure
that it is going to be relevant for much longer.

> #578582 seems to be just patrick being special and refusing to provide
> any information about the bug that no-one else hits.
> 
> Maybe if we revert that more easy ptrace fallback stuff for now, the
> rest in sandbox git master is fine (if my opendir fix gets applied
> that's only patched in via ebuild right now)?
> 
> Mart
> 



Re: [gentoo-dev] [PATCH 1/3] python-utils-r1.eclass: Allow -2/-3 as impl-patterns for py2/py3

2017-05-10 Thread Patrick McLean
On Wed, 10 May 2017 20:53:31 +0200
Michał Górny  wrote:

> Allow two special values in the implementation patterns for
> _python_impl_matches(): -2 to indicate all Python 2-compatible
> implementations, and -3 to indicate all Python 3-compatible
> implementations. Both of those values are implemented using
> the python_is_python3 function.

Seems mostly reasonable, though the syntax is somewhat confusing at
first glance. There are many places where we use "-value" to negate, so
this looks like it means "not python 2" rather than "all python 2".
Perhaps something like '+2' would make it easier to read.

> This is mostly meant to make it easier and more fool-proof to write
> dependencies on backports to Python 2 which in most cases apply to
> PyPy2 as well.



Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

2017-03-07 Thread Patrick McLean
On Tue, 7 Mar 2017 18:51:12 -0500
Michael Orlitzky  wrote:

> On 03/07/2017 05:40 PM, William Hubbs wrote:
> > Hi all,
> > 
> > I was attending SCALE, but now I'm back to answer this.
> > 
> > On Thu, Mar 02, 2017 at 04:46:22PM -0500, Michael Orlitzky wrote:  
> >> What kind of dependency do we need, anyway? William, are you
> >> saying that if I upgrade dev-lang/go, then things will break, but
> >> if I delete dev-lang/go, everything is fine?  
> > 
> > Go programs will not *break* if you upgrade or downgrade
> > dev-lang/go, but they will not get the new features or fixes in the
> > new version of dev-lang/go until they are rebuilt with the new
> > version.  
> 
> Ha, then I went off on a pointless tangent.
> 
> How is this situation different from, say, a C program? You need to
> recompile to get the new GCC optimizations, stack-mumbo-jumbo
> protections, etc.
> 
> 

You also need to recompile to get security bugs fixed. With go it's not
just compiler options, it's also the standard library updates that need
a recompile to get.



Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread Patrick McLean
On Fri, 3 Feb 2017 19:59:34 -0500
Ian Stakenvicius  wrote:

> On 03/02/17 02:37 PM, Michael Orlitzky wrote:
> > On 02/03/2017 10:30 AM, Ian Stakenvicius wrote:  
> >>
> >> ok you lost me.  Could you provide an explicit example of what you
> >> would want to see enabled in the profile (while everything else is
> >> disabled) that you don't get when USE="-*" is set?  
> > 
> > USE="hardened pax_kernel ..."
> >   
> 
> ok, so global flags that are never modified via IUSE defaults.  It
> still looks to me like all you need to do to get what you want is swap
> the order of 'conf' and 'defaults' in USE_ORDER? (man make.conf)
> 
> > 
> > I don't want to turn off all IUSE defaults. Since we have no policy
> > on what IUSE defaults should be used for, half of them are
> > important, and the other half are junk. I don't want to disable the
> > ones that are critical for the package to function, and I don't
> > want to disable the ones that satisfy an (otherwise unsatisfied)
> > REQUIRED_USE constraint. 
> 
> And herein lies the crux.  "Junk" is your definition, but it's not
> necessarily the maintainer's definition.  "Critical for the package to
> function" is entirely dependent on what you expect to use the package
> for.  If you want to disable everything optional then USE="-*" will do
> that, and really all you should be losing is the ability to have
> REQUIRED_USE auto-resolve based on the IUSE defaults that are set.
> However, even in that case, it seems likely that you may well want to
> use a different option to resolve a REQUIRED_USE conflict to ensure
> your minimalist install than is the default that the maintainer
> provided.
> 

I think the current policy of "maintainer's discretion" is probably the
only reasonable way to approach IUSE defaults. Attempting to dictate
some policy based on differing definitions of what is acceptable or not
is just a path to a lot of pain for very little gain. I don't think
that there are a very large proportion of people who want some sort of
"minimal" system, sacrificing basic, expected functionality (as say
"-readline" on app-shells/bash would do) in the default configuration
.
Leaving the IUSE defaults up to the maintainer allows said maintainer
to select what they consider reasonable defaults.



Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread Patrick McLean
On Fri, 3 Feb 2017 08:43:50 -0500
Michael Orlitzky  wrote:

> On 02/03/2017 08:21 AM, Ian Stakenvicius wrote:
> >>
> >> How about rather changing our defaults to satisfy the minimalists
> >> who don't mind drastically reduced functionality and usability in
> >> pursuit of "minimalism" we just strive to make USE="-*" mostly
> >> usable, so the minimalists can get what they want, while still
> >> having sane defaults. 
> > 
> > I'm in favour of this too -- I know we don't "officially" support
> > USE="-*" but I think we should still strive to make it work with
> > minimal effort to end-users -- that effort being mainly setting
> > whatever is necessary for REQUIRED_USE resolution.
> >   
> 
> It will never be easy, because USE="-*" overrides your profile. What
> people want is a way to have USE="-*" apply between the base profile
> and the one that they select.
> 
> This is all easily fixed by creating a new profile one-level above
> base where developers can put their favorite USE flags:
> 
>   1. We create a new empty profile called "penultimate" inheriting
>  from base.
> 
>   2. Update the profiles that inherit from base to inherit from
>  penultimate.
> 
>   3. Move every upstream and maintainer-pet IUSE default into the
>  penultimate profile.
> 
>   4. Make it policy that IUSE defaults should only be used for
>  critical flags and REQUIRED_USE persuasion.
> 
>   5. Now we can create embedded, hardened, etc. profiles that inherit
>  from base and get a minimal working set of USE flags.
> 

We might as well go back to before IUSE defaults then. Part of the
advantage of IUSE defaults is maintainers don't all have to fiddle with
the profiles, everything can be self-contained in the ebuild. This
drastically complicates maintenance, having two locations to track and
change rather than just one.

I don't know that I would agree that making an absolutely "minimal"
build as easy as possible is something that most people want
(especially if it makes maintainership more complicated for a
significant number of packages). I suspect that there is a small subset
of people interested in this, and perhaps those people could maintain a
"minimal" profile that unsets IUSE defaults.

Also, I would just point out that the particular IUSE default that
you objected to in your original email does not really affect this
"minimalist" ideal that you seem to hold. The "hpn" USE flag on
openssh does not actually pull in any extra dependencies, it just
adds some optimizations to the network code to make it faster.



Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-02 Thread Patrick McLean
On Thu, 2 Feb 2017 21:06:33 -0500
Michael Orlitzky  wrote:

> On 02/02/2017 09:00 PM, Sam Jorna wrote:
> >
> > Consider: a new user, coming from Ubuntu or Fedora or Windows,
> > starts building their system. They start installing packages they
> > want, only to find that half of the package isn't there because no
> > USE flags were enabled. They have to enable these flags for almost
> > every package they want because there's no defaults, you must
> > manually specify anything that's not a direct dependency or forced
> > by profile.  
> 
> Desktop profile!! We have a desktop profile!!! Why is the base
> profile a better location for new-user-with-a-desktop defaults than
> the **desktop** profile?
> 
> I'm going crazy. I give up.
> 

There are people who run servers on Gentoo, and don't particularly want
minimalism, then want a normal Linux system level of functionality (ie
upstream and/or sane defaults) without having to add dozens of USE
flags to random packages throughout the system.



Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-02 Thread Patrick McLean
On Thu, 2 Feb 2017 20:40:38 -0500
Michael Orlitzky  wrote:

> On 02/02/2017 01:01 PM, Rich Freeman wrote:
> > On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky 
> > wrote:  
> >>
> >> If (base == minimal), then all of the upstream defaults need to be
> >> added to package.use for the upstream-defaults profile. That's
> >> bad,  
> > 
> > I'll go further and say that it is unacceptably bad.
> >   
> 
> Only if anyone wants an upstream-defaults profile. But nobody's asked
> for one, in contrast with the large number of users who want minimal.
> 
> 
> > Is there a better way we can have our cake and eat it too?  I'll
> > admit that a huge package.use on the minimal profile isn't a whole
> > lot better than a huge package.use on all the other profiles.  
> 
> Every important upstream default is already enabled in some profile.
> If dropping a particular IUSE default breaks desktop systems, then
> that flag belongs enabled in the desktop profile. If it breaks every
> system, then let's keep it default.
> 

How about rather changing our defaults to satisfy the minimalists who
don't mind drastically reduced functionality and usability in pursuit
of "minimalism" we just strive to make USE="-*" mostly usable, so the
minimalists can get what they want, while still having sane defaults. 



Re: [gentoo-dev] Requirements for UID/GID management

2017-01-30 Thread Patrick McLean
On Mon, 30 Jan 2017 11:29:02 -0500
Michael Orlitzky  wrote:

> On 01/30/2017 09:25 AM, Alan McKinnon wrote:
> >>
> >> Any user can create a hard link in its home directory
> >> to /etc/shadow, so long as (a) they live on the same filesystem,
> >> and (b) there are no special kernel protections in place to
> >> prevent it. If you call chown on that hard link, it will change
> >> the ownership of /etc/shadow.  
> > 
> > That is absolutely not true, at least for the case of classic Unix
> > filesystems.
> > 
> > ...
> > 
> > I cannot chmod, chown or chgrp
> > /etc/shadow because I do not own it, and the kernel will not let me
> > ln it either:
> > 
> > alan@khamul /alan $ ln /etc/shadow
> > ln: failed to create hard link './shadow' => '/etc/shadow':
> > Operation not permitted
> >   
> 
> You have the fs.protected_hardlinks sysctl enabled. We patch that in
> gentoo-sources, but it's off by default in vanilla-sources. Try again
> with it disabled (and don't forget to turn it back on). Once the hard
> link has been created, a "chown -R foo /alan" or the equivalent "find
> ..." command will change the ownership of /etc/shadow.
> 
> 

No, that is also enabled by default on vanilla kernels, I just verified
on my machine running a vanilla kernel. It doesn't matter anyway, since
the permissions and ownership information is stored in the inode, not
the dentry so all hardlinks have exactly the same permissions.



Re: [gentoo-dev] Requirements for UID/GID management

2017-01-28 Thread Patrick McLean
On Sat, 28 Jan 2017 11:28:45 +
James Le Cuirot <ch...@gentoo.org> wrote:

> On Fri, 27 Jan 2017 18:37:52 -0800
> Patrick McLean <chutz...@gentoo.org> wrote:
> 
> > I don't think we need to have stable UIDs/GIDs in the "normal" case of
> > standalone users with a single Gentoo system at home. The people who
> > need predictable UIDs/GIDs are the "enterprise" users or the home users
> > who use things such as NFS. I work for a company that uses Gentoo, we
> > have a bunch of workarounds to make sure that UIDs and GIDs are
> > stable. To make something to solve our problem (and I suspect everyone
> > else who cares about this), it would be sufficient to have a mechanism
> > to override the default random assignment with a fixed UID/GID.
> > Possibly some file in /etc/portage or in the profile (or both) that
> > allows one to configure what UID/GID a user will get when the user is
> > being created. One advantage of this is that user.eclass could be
> > modified to support it, so we don't have to wait for a new EAPI before
> > taking advantage of it.  
> 
> Is this really a problem in enterprise? What are the workarounds you're
> using? NFS has long had idmapd, which takes care of this problem. I
> still find people shy away from NFSv4 but I've not had any trouble with
> it. There's also LDAP, usually coupled with sssd these days, in which
> case the users and groups are created just once on a central server.
> Samba with Active Directory effectively gives you the same thing and
> can also be coupled with sssd. I recently tried mixing Samba, sssd, and
> NFS, which was quite fascinating and surprisingly easy thanks to
> realmd. This allowed me to use NFS with Kerberos, which is something
> you really need in an enterprise environment.
> 

We are using both NFSv3 and NFSv4, the UID stability is also important
when you are using full-image deployments, and have local storage on
the system, you don't want the new OS to have different UIDs/GIDs than
the previous installation.

We are using file in /etc/portage/env that define a pre_pkg_setup that
creates the users before the standard pkg_setup does, with our stable
UID/GID for that system. We have to do this for each package that
creates a user that may be used to store stable data.



Re: [gentoo-dev] Requirements for UID/GID management

2017-01-27 Thread Patrick McLean
On Fri, 27 Jan 2017 14:53:18 -0500
Rich Freeman  wrote:

> On Fri, Jan 27, 2017 at 2:35 PM, Michael Orlitzky 
> wrote:
> > On 01/27/2017 01:52 PM, Rich Freeman wrote:  
> >>
> >> This doesn't really seem like a problem though.  Just have a table
> >> somewhere (wiki?) to track who is using what UID/GID and encode
> >> those defaults into the ebuild that creates those users.
> >>  
> >
> > It should be possible to have two different users with the same UID
> > in the tree, just like we can have two different packages that
> > install the same file. Eventually somebody will notice a file
> > collision, and then we add a blocker per usual.
> >  
> 
> I'm not saying we can't have random assignment for things where it
> doesn't matter, or fall back to random assignment, but it seems rather
> silly to go to all the trouble to have blockers when it would be just
> as easy to not have a conflict in the first place.  Now, if we have
> some longstanding issue from the past that might be another matter,
> but what's wrong with just picking an unused ID (again, for stuff that
> needs it)?
> 
> Telling users that they can't have postfix and apache on the same box
> because nobody can be bothered to pick IDs that don't collide seems
> like an arbitrary imposition.  Sometimes upstream creates conflicts
> that are just hard to work around (same SONAME, different ABI or even
> API, and so on).  And if we were talking about some binary-only
> upstream package that relies on hardcoded UIDs I guess blockers might
> be our only option, and users will just have to be happy that we're
> able to support it at all.  However, we shouldn't be the ones creating
> these kinds of conflicts.
> 

I don't think we need to have stable UIDs/GIDs in the "normal" case of
standalone users with a single Gentoo system at home. The people who
need predictable UIDs/GIDs are the "enterprise" users or the home users
who use things such as NFS. I work for a company that uses Gentoo, we
have a bunch of workarounds to make sure that UIDs and GIDs are
stable. To make something to solve our problem (and I suspect everyone
else who cares about this), it would be sufficient to have a mechanism
to override the default random assignment with a fixed UID/GID.
Possibly some file in /etc/portage or in the profile (or both) that
allows one to configure what UID/GID a user will get when the user is
being created. One advantage of this is that user.eclass could be
modified to support it, so we don't have to wait for a new EAPI before
taking advantage of it.



Re: [gentoo-dev] tmpfiles: call for testers

2016-11-08 Thread Patrick McLean
On Tue, 8 Nov 2016 17:41:02 -0600
William Hubbs  wrote:
> 
> The plan, once the first release is out, is to rewrite this utility
> in a better language. I'm considering C, but if I am comfortable by
> that time in Go or Rust, I may use one of them.
> 

For a low-level utility that is likely going to be in the default
@system set, please use C. Adding dependencies on the go or rust
compilers for this is not very nice.

> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=599044




Re: [gentoo-dev] grub-2 configuration

2016-10-28 Thread Patrick McLean
On Fri, 28 Oct 2016 10:56:08 +
Joakim Tjernlund  wrote:

> On Thu, 2016-10-20 at 11:03 -0400, Tom H wrote:
> > On Wed, Oct 19, 2016 at 4:43 PM, Joakim Tjernlund
> >  wrote:  
> > > 
> > > On Wed, 2016-10-19 at 15:21 -0400, Tom H wrote:  
> > > > 
> > > > 
> > > > but it looks like, unlike for grub-legacy, you need a grub
> > > > config file ("/boot/grub{,2}/grub.cfg") to exist.  
> > > 
> > > That is reasonable, to create a new entry one needs to copy the
> > > previous and replace the kernel.
> > > 
> > > Would be nice if someone could confirm this though.  
> > 
> > if [[ -z "${GRUB_CONF}" ]]; then
> > print_error 1 "Error! Grub2 configuration file does not exist,
> > please ensure grub2 is correctly setup first."
> > return 0
> > fi  
> 
> 
> Tried to make grub2 and EFI work on a HP Skylake laptop but failed.
> This laptop PXE boots linux during install in BIOS mode so no EFI
> vars etc. available when installing grub2. Is this an impossible
> combo? Do I need to EFI boot in order to install grub2 efi?
> 
>  Jocke

You need to be booted in EFI mode to be able to access the EFI vars and
install grub in EFI mode. If you are booted in legacy mode, you have to
use grub's i386-pc mode.



Re: [gentoo-dev] rfc: the demise of grub:0

2016-10-05 Thread Patrick McLean
On Thu, 6 Oct 2016 01:54:51 +1300
Kent Fredric  wrote:

> On Wed, 5 Oct 2016 06:04:38 -0500
> Rich Freeman  wrote:
> 
> > What you really want is another template file.  
> 
> I'd be happy with that. See the other thread with "grub-2" In the
> title.
> 
> > I'm happy with mkconfig, but I did hand-roll my config files before
> > that.  The docs are out there.  However, for whatever reason, it is
> > very hard to find examples of simple config files online.  The
> > official docs try to point you in the direction of mkconfig, and
> > since 99% of linux users don't configure their own grub there isn't
> > much alternative documentation (and when a distro's solution does
> > break the solution usually is based on mkconfig anyway).  
> 
> Yeah, the only reason I suggested "a tool" instead of "a template" is
> that perhaps there could be a handful of easily detectable things that
> generate a more optimal "initial" template.
> 
> Particularly with regards to getting the hard-drive numbers and stuff
> right, that's what always concerns me.

I have attached a somewhat cleaned up and commented version of the
hand-written grub config I use at home. Feel free to use as an example
for your machines, add it to the wiki and/or the handbook, or make the
ebuild install it to /usr/share etc.

One of the nice things about grub2 is that you no longer need to know
or care about the BIOS disk numbers, you can simply use the UUID of the
filesystem (and/or the PARTUUID for the kernel).

grub.cfg
Description: Binary data


Re: [gentoo-dev] base-system needs developers who care

2016-08-23 Thread Patrick McLean
On Tue, 23 Aug 2016 23:17:58 +
"Robin H. Johnson"  wrote:

> Some of these packages are very niche, and while they continue to
> work, they could use a bit more attention than they get presently
> (you might only hear about them when they break and never when they
> work). 
> 
> They are generally NOT broken and in need of tree-cleaning, but are
> just lacking forward momentum (not a few bugs are reasonable upstream
> bugs or feature improvements). Many were once shiny and had lots of
> people that cared, but that dwindled as they become mundane and just
> expected to work.
> 
> General increase in the number of developers in base-system would not
> be a bad outcome from this email either ;-).

I have some (both day job and personal) interest in keeping most of the
packages on that list working and moving forward, and would not be
opposed to joining base-system to help out (if you will have me). As it
is, I have been helping out with openssh X509 support for awhile now.

> 
> Some of this is from stuff I know needs eyeballs, and others are where
> the package seems to have more than a few old bugs open.
> 
> Packages in need of review & tweaks or just more eyeballs
> --
> app-admin/sudo (upstream?)
> app-admin/sysklogd- (upstream?)
> app-shells/bash (upstream?)
> dev-util/strace (upstream?)
> net-dialup/ppp
> net-firewall/iptables
> net-fs/nfs-utils (upstream?)
> net-misc/dhcpcd (upstream?)
> net-misc/dhcp (upstream?)
> net-misc/ntp (upstream?)
> net-misc/openssh 
> net-nds/rpcbind
> sys-apps/baselayout
> sys-apps/coreutils (upstream?)
> sys-apps/kbd (upstream?)
> sys-block/aoetools
> sys-block/iscsitarget
> sys-block/open-iscsi
> sys-block/thin-provisioning-tools
> sys-block/vblade
> sys-fs/lvm2 (mostly in regards to genkernel interaction)
> sys-fs/multipath-tools
> sys-fs/quota
> 




Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

2016-08-11 Thread Patrick McLean
On Thu, 11 Aug 2016 22:50:53 +0200
Michał Górny  wrote:

> On Thu, 11 Aug 2016 20:56:20 +0100
> James Le Cuirot  wrote:
> 
> > On Thu, 11 Aug 2016 11:05:00 -0400
> > Ian Stakenvicius  wrote:
> >   
> > > On 11/08/16 10:57 AM, Mart Raudsepp wrote:
> > > > Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich
> > > > Mueller:  
> > > >>> On Thu, 11 Aug 2016, James Le Cuirot wrote:  
> > > >>  
> > >  Have you asked Debian why they are doing that?  
> > > >>  
> > > >>> I did find out but had since forgotten. Here it is:
> > > >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10  
> > > >>
> > > >> So they are aware of the issue since 10 years, but chose not
> > > >> to fix it? Seriously, there's no good reason to dance to their
> > > >> tune then.  
> > > > 
> > > > It's not to dance to Debians tune, it's to dance to Valve tunes,
> > > > which happens to create its runtimes from Ubuntu packages.
> > > > I strongly believe that it's important to have such a use case
> > > > as Steam work problem-free in Gentoo. It's currently too messy,
> > > > with and without using steam runtime.
> > > > In the former case (using steam runtime), there are
> > > > incompatibilities between libraries found in the steam runtime,
> > > > and those that it doesn't include and assumes the system
> > > > provides (primarily mesa and deps); each steam runtime version
> > > > you get to hack around things by removing a small selection of
> > > > libraries from the steam runtime dir to get stuff working; a
> > > > 1-2 month old upgrade I haven't even managed to get to work yet
> > > > on a more up to date machine. In the latter case (forcing to
> > > > not use steam runtime), it's near impossible right now to get a
> > > > set of 32bit binaries to satisfy even steam client itself
> > > > without lots of trial and error, let alone some 32bit game.
> > > >   
> > > >>> I'm fine with putting it in libpcre-debian package as kentnl
> > > >>> suggested.  
> > > >>
> > > >> I still think that the libpcre.so.3 compatibility link
> > > >> shouldn't be installed in a generally visible location.
> > > >> Install it in a specific directory instead, and start your
> > > >> binary with a wrapper which will add that directory to
> > > >> LD_LIBRARY_PATH.  
> > > > 
> > > > Isn't this a use case for ldscripts, e.g like gen_usr_ldscript
> > > > toolchain.eclass function does, except for pointing
> > > > libpcre.so.3 to libpcre.so.1 (so can't use that eclass
> > > > function, but could just pre- create one to $FILESDIR if it
> > > > works)? The important points should be:
> > > > 1) No compilation/linking done on Gentoo should possibly end up
> > > > with putting libpcre.so.3 in its DT_NEEDED
> > > > 2) libpcre.so should link to libpcre.so.1
> > > > 
> > > > If we can satisfy these, I don't see a reason to mess around
> > > > with some extra package.
> > > > Debian reasoning of having stuck with libpcre.so.3 historically
> > > > is sound as well, especially if upstream will never use that,
> > > > given libpcre2.so.x or however they soname pcre2-10+. Also,
> > > > given PCRE2, and given debians todays situation with this, I
> > > > would also technically choose not to change this, as things
> > > > should migrate over to PCRE2.
> > > > 
> > > > Mart
> > > 
> > > Wouldn't the most simple solution here would be to make a symlink
> > > for libpcre.so.3 within the local bindir for each Valve or
> > > whatever package that needs it?  This is a
> > > binary-package-supporting hack, might as well do it in the binary
> > > packages that need it.  You might still need to wrap the binary
> > > to set some environment stuff, not sure; either way it doesn't
> > > seem to make sense to make this a system-wide thing.
> > 
> > We don't package Steam itself and doing so isn't viable. We package
> > upstream's script for bootstrapping it under the user's HOME. As
> > such, there is nowhere to create such a symlink. It's not actually
> > Steam itself that requires libpcre.so.3 but (at least) one of its
> > games. You similarly can't create a symlink for each game because
> > they also get installed under HOME or some other user-defined
> > location.  
> 
> Well, how about you package a script to easily install Ubuntu on top
> of Gentoo? That should make your system much more compliant with
> Valve's idiocy than random symlinks.
> 
> If you are going to commit such crap into Gentoo ignoring people more
> knowledgeable than you, please spare us the effort and open a QA bug
> against it requesting that you remove it immediately. Thank you. Feel
> free to also request revoking your commit rights for explicit ignoring
> of QA feedback.
>

Think of it as a package, install it if you want steam games to work on
your machine, if you don't care and don't want that crap on your
system, then don't install it. It's not like there is a shortage of

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

2016-08-11 Thread Patrick McLean
On Thu, 11 Aug 2016 17:53:31 +1200
Kent Fredric  wrote:

> On Thu, 11 Aug 2016 00:10:53 +0100
> James Le Cuirot  wrote:
> 
> > Hello all,
> > 
> > We, like almost everyone else and presumably upstream, install PCRE
> > 8 as libpcre.so.1. Debian, for reasons best known to themselves,
> > install it as libpcre.so.3. With Ubuntu still being the most widely
> > accepted "standard" Linux desktop, this presents a problem when
> > dealing with pre-compiled binaries.
> > 
> > I have been working on a script to replace the rather lacking
> > steam-games-meta ebuild (see steam-overlay). I'm very excited about
> > releasing it soon as I think it is a major step forwards in our
> > ability to easily run Steam without the official Ubuntu-based
> > runtime.
> > 
> > Before I put it out there, I'd like to get Alien Isolation working
> > properly. It links to libpcre.so.3. Hacking the binary might work
> > but this isn't ideal and not always an option as some games use
> > Valve's anti-cheat system, which is ruthless.
> > 
> > I have found that creating a symlink in /usr/lib that points
> > to /lib/libpcre.so.1 works, except that when you run ldconfig, it
> > automatically creates another symlink from /usr/lib/libpcre.so.1 to
> > libpcre.so.3. If you create the first symlink in /lib instead then
> > the existing /lib/libpcre.so.1 holds after running ldconfig. The
> > latter location is therefore probably preferable.
> > 
> > Would anyone have any issue with adding this to our libpcre
> > package? I don't foresee any problems. libpcre.so would obviously
> > still point to libpcre.so.1. I'm pretty sure there will never be
> > another libpcre.so.3 as upstream have released PCRE2 as libpcre2,
> > effectively an entirely separate library.
> > 
> > I could create a Steam-specific package for this but that would mean
> > adding some additional Steam-specific location to ld.so.conf, which
> > I'm trying to avoid. It would be nice to solve this generally
> > anyway.
> > 
> > Thoughts?
> >   
> 
> I'd say this is the sort of thing that has more application than just
> steam.
> 
> I'd just suggest a libpcre-debian package, which provides the .so via
> symlink and dependency mechanisms.
> 
> That way *if* anything happens in the future, we can just introduce
> blockers in the right place.
> 
> Then the applicable stuff depends on libpcre-debian for the forseeable
> future.
> 
> And this way, if debian do anything else magical, we can probably copy
> them and build a libpcre like they do for interop.
> 
> Essentially, the point here is to see debians libpcre is a competing
> implementation, even though we can locally pretend they're not at the
> technical level, it works as " conceptual model " for the problem we
> have.
> 

This sounds reasonable to me, that way we have pseudo-universal
handling of this for everything that needs it. The people who object to
adding stuff to support binary packages can just not install the
libpcre-debian package.



Re: [gentoo-dev] Signed push & clock drift rejection

2016-07-19 Thread Patrick McLean
On Tue, 19 Jul 2016 13:22:29 -0700
Patrick McLean <chutz...@gentoo.org> wrote:

> On Tue, 19 Jul 2016 21:23:16 +0300
> Andrew Savchenko <birc...@gentoo.org> wrote:
> > On Mon, 18 Jul 2016 22:21:22 -0400 waltd...@waltdnes.org wrote:  
> > > On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko
> > > wrote
> > > > 
> > > > As I wrote earlier in this thread, ntp server is not a guarantee
> > > > that such problems will not happen. If hardware clocked was
> > > > significantly offset during boot, it may take several _hours_
> > > > for ntp to fix this via clock skew. Apparantly commit may be
> > > > made during these several hours.
> > > 
> > >   I'm amazed that "robust linux servers" are deathly afraid of
> > > simply setting the time, and being done with it. And while we're
> > > at it, if a developer is doing development on a server machine,
> > > he may have other problems to worry about.  At home I occasionally
> > > manually run a script that includes the 2 lines...
> > 
> > I never said anything about "robust linux servers". If you think
> > than only servers need a gradual clock slew instead of stepping,
> > you are mistaken.
> >   
> > > /usr/bin/sudo /usr/bin/openrdate -n -s ca.pool.ntp.org
> > > /usr/bin/sudo /sbin/hwclock --systohc
> > 
> > And if time delta is significant, the system may become broken
> > this way. Congratulations.  
> 
> Really? I have many times skewed time by weeks using ntpdate with no
> issues.
> 
> > The gradual NTP time slew was not invented because people were lazy
> > to run two simple commands. Actually it is just the opposite:
> > setting system time via a single huge step is much easier to
> > implement than a proper adjustment via a series of small time slews.
> > For servers it is indeed important in many ways, including
> > time stamp based cryptography as kerberos or database integrity.  
> 
> Sure randomly skewing time can cause weird issues, which is why it is
> a manual operation (and/or boot time operation).
> 
> > 
> > But desktops also do need a proper time adjustment:
> > - Filesystems will not operate correctly with time stamps in
> > future, in the best keys they will be marked/reported as needed a
> > repair procedure.  
> 
> I have only ever seen ext4 complain about the superblock timestamp,
> and fsck generally just corrects without issue, and it generally is
> only an issue after a reboot.
> 
> > - Cron jobs may go broken too as chithanh mentioned already.  
> 
> Get a better crond? Decent cron daemons can detect time skews and act
> accordingly.
> 
> > - Video encoding is not happy with time shifts at all. While small
> > predictable slews can be tolerated, large jumps will just broke the
> > process.  
> 
> Anything that cares about having a monotonic clock, and doesn't
> actually care about the real time (like video encoding) should just
> use the monotonic clock, not the system time.
> 
> > - System may become *vulnerable* because of time stamp based attack.
> > Though it is not easy to use such behaviour, it is still possible.  
> 
> Once again, monotonic clock exists for a reason. If you want to
> talk about vulnerabilities, you do realize that doesn't work properly
> unless the client and server have reasonably similar system times.
> 
Err, SSL doesn't work properly.

> > - and many more...
> > 
> > Best regards,
> > Andrew Savchenko  
> 
> 




Re: [gentoo-dev] Signed push & clock drift rejection

2016-07-19 Thread Patrick McLean
On Tue, 19 Jul 2016 21:23:16 +0300
Andrew Savchenko  wrote:
> On Mon, 18 Jul 2016 22:21:22 -0400 waltd...@waltdnes.org wrote:
> > On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote  
> > > 
> > > As I wrote earlier in this thread, ntp server is not a guarantee
> > > that such problems will not happen. If hardware clocked was
> > > significantly offset during boot, it may take several _hours_ for
> > > ntp to fix this via clock skew. Apparantly commit may be made
> > > during these several hours.  
> > 
> >   I'm amazed that "robust linux servers" are deathly afraid of
> > simply setting the time, and being done with it. And while we're at
> > it, if a developer is doing development on a server machine, he may
> > have other problems to worry about.  At home I occasionally
> > manually run a script that includes the 2 lines...  
> 
> I never said anything about "robust linux servers". If you think
> than only servers need a gradual clock slew instead of stepping,
> you are mistaken.
> 
> > /usr/bin/sudo /usr/bin/openrdate -n -s ca.pool.ntp.org
> > /usr/bin/sudo /sbin/hwclock --systohc  
> 
> And if time delta is significant, the system may become broken
> this way. Congratulations.

Really? I have many times skewed time by weeks using ntpdate with no
issues.

> The gradual NTP time slew was not invented because people were lazy
> to run two simple commands. Actually it is just the opposite:
> setting system time via a single huge step is much easier to
> implement than a proper adjustment via a series of small time slews.
> For servers it is indeed important in many ways, including
> time stamp based cryptography as kerberos or database integrity.

Sure randomly skewing time can cause weird issues, which is why it is a
manual operation (and/or boot time operation).

> 
> But desktops also do need a proper time adjustment:
> - Filesystems will not operate correctly with time stamps in
> future, in the best keys they will be marked/reported as needed a
> repair procedure.

I have only ever seen ext4 complain about the superblock timestamp,
and fsck generally just corrects without issue, and it generally is
only an issue after a reboot.

> - Cron jobs may go broken too as chithanh mentioned already.

Get a better crond? Decent cron daemons can detect time skews and act
accordingly.

> - Video encoding is not happy with time shifts at all. While small
> predictable slews can be tolerated, large jumps will just broke the
> process.

Anything that cares about having a monotonic clock, and doesn't
actually care about the real time (like video encoding) should just use
the monotonic clock, not the system time.

> - System may become *vulnerable* because of time stamp based attack.
> Though it is not easy to use such behaviour, it is still possible.

Once again, monotonic clock exists for a reason. If you want to
talk about vulnerabilities, you do realize that doesn't work properly
unless the client and server have reasonably similar system times.

> - and many more...
> 
> Best regards,
> Andrew Savchenko




Re: [gentoo-dev] Need design help/input for eclean-kernel

2016-06-30 Thread Patrick McLean
On Thu, 30 Jun 2016 14:38:26 +0200
Michał Górny  wrote:
> So if you have some time, please reply to this thread with
> a specific /boot layout that you think needs to be handled, with
> as much helpful information as possible -- including possible
> distinctive features and pitfalls.
> 

All of our systems have this:
/boot/${KV}/{vmlinuz,initramfs,System.map,perf,config}-${KV}

With these symlinks
/boot/vmlinuz -> ${KV}/vmlinuz-${KV}
/boot/initramfs -> ${KV}/initramfs-${KV}
/boot/config -> ${KV}/config-${KV}
/boot/System.map -> ${KV}/System.map-${KV}

Some systems also have:
/boot/${KV}/vmlinux-${KV}

/boot/vmlinux -> ${KV}/vmlinux-${KV}

When updating to a new kernel, we generally unpack a tarball
containing the new kernel to /boot and update the symlinks to point to
the new versions. All files related to a kernel are in that kernel's
directory, which makes cleanup somewhat easier.

The values of KV look like one of these:
4.4.14-vanilla-base-1
4.4.14-gentoo-r1-base-1
4.7.0-rc5-vanilla-base-1
4.7.0-rc5-vanilla-base-1+
4.7.0-rc5-vanilla-base-1-00254-g1a0a02d

Mostly, it's a version, sources version, configuration type and
version. These are generated via setting CONFIG_LOCALVERSION, and
whatever else gets spit out by the build system.



Re: [gentoo-dev] Repoman rewrite stage3. Migrate check data to the tree

2016-03-10 Thread Patrick McLean
On Thu, 10 Mar 2016 18:30:07 -0800
Brian Dolbec  wrote:

>  So, where do we place this directory and what rules do we
> establish about it's modifications?
> 
>location? : in the metadata dir alongside the install-qa-check.d
>directory?

That sounds reasonable to me, it is certainly metadata.

> 
>name of the directory? : repoman, qa-rules, qa-data,
> repo-qa-data, ... ideas?

Something not project name specific, so nothing about repoman. Perhaps
something like "repo-checks", my personal vote would be make it a
directory with the contents being merged (so repo-checks.d maybe?)

> 
>data format? : json (my favorite) 
> compatible with many lanquages/interfaces
> is flexible to match various data types
>   ie: dictionaries, lists, strings...
> is human readable/editable
> can be validated
> 
>xml (PLEASE NO!)
> 
>native python file  (too language dependant)
> 
>ini style (python configparser compatible) meh :/
> 
>other ideas?

YAML - like JSON but made to be edited/read by humans (comment support
is a big feature). Also valid JSON is valid YAML. Also can be validated
just like JSON can.



Re: [gentoo-dev] Re: converting copyright/license information in OpenRC

2015-12-11 Thread Patrick McLean
On Fri, 11 Dec 2015 15:37:48 -0600
William Hubbs  wrote:

> On Fri, Dec 11, 2015 at 09:04:47PM +0100, Ulrich Mueller wrote:
> > > On Fri, 11 Dec 2015, William Hubbs wrote:  
> >   
> Well, the OpenRC project is currently inconsistent about this, so the
> intention is to make it consistent.
> 
>  The .c/.h files have file-scope licenses, but that isn't true for
>  everything in the project.
> 
> I am willing to make the effort to do this, I was just wondering if
> there are any legal pitfalls I need to worry about.
> 
> My theory is I can probably use git to find out who all of the authors
> are, and generate an Authors list from that information and from
> looking at copyright notices.
> 

One concern about this is the possibility of copied code. If OpenRC
ever copied code from other BSD licensed projects, then dropping the
notice from the top of the file would be a violation of the upstream
license.



Re: [gentoo-dev] rfc: removing mount-ro from OpenRC

2015-10-02 Thread Patrick McLean
On Fri, 2 Oct 2015 16:59:06 -0500
William Hubbs  wrote:
> 
> Does anyone know why we need this init script (it is Linux only), or
> why we can't remove it?
> 
This script is there to make sure as much effort as possible has been
done to prevent file system corruption before rebooting/powering off.
For the file systems that are in use (such as /) they cannot be
unmounted at shutdown time, so this script remounts them read only so
they will be in a clean when the machine reboots/powers off.



Re: [gentoo-dev] .gitignore

2015-08-13 Thread Patrick McLean
On Thu, 13 Aug 2015 07:43:24 -0700
Brian Dolbec dol...@gentoo.org wrote:
 
 No, there clearly should be some things that are commonly present
 that should never be committed.  Those common things should be in a
 global .gitignore.  I did not read the entire thread(s) but it seemed
 there was more bikeshedding that was necessary.  I had not seen
 mention of an alternate git ignore setting that could be used without
 the need to have a locally modified .gitignore that someone must
 constantly refrain from committing with git constantly reminding them
 it has been modified and lest they be chastised for committing it ;)  
 

We should have common editor artifacts and backup files in there, I
generally use this in just about every repository I touch:

*~
.*.sw[po]
.*.un~
*#
.#*

This should cover vim and emacs, if there other editors that like to
drop files around, we should consider adding those as well.0



Re: [gentoo-dev] sys-kernel/dracut looking for more maintainers

2015-08-08 Thread Patrick McLean
On Sat, 8 Aug 2015 14:18:53 -0400
Mike Gilbert flop...@gentoo.org wrote:

 On Sat, Aug 8, 2015 at 1:31 PM, Amadeusz Żołnowski aide...@gentoo.org wrote:
  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.

I can pitch in, we use dracut at my employer. I actually have a local
patchset fixing some issues/redhat-isms that I have been meaning to
release at some point.

 I'm willing to help debug things and commit fixes, although I
 primarily use systemd so it is harder for me to test most of the
 modules.
 
 I can certainly review patches and proxy commits. If you think it
 would be helpful, let me know.
 




Re: [gentoo-dev] rfc: openrc mount service prototype

2015-08-01 Thread Patrick McLean
On Sat, 1 Aug 2015 10:05:44 -0500
William Hubbs willi...@gentoo.org wrote:

 On Fri, Jul 31, 2015 at 05:29:37PM -0700, Patrick McLean wrote:
  On Fri, 31 Jul 2015 17:28:03 -0500
  William Hubbs willi...@gentoo.org wrote:
  
   On Fri, Jul 31, 2015 at 11:57:59PM +0200, Peter Stuge wrote:
   
   What I'm asking about is whether anyone knows of a smoothe way to
   transition users from local/netmount to mount.filesystem
   dependencies, without breaking systems. If that doesn't exist, 1.0
   will have to sit in p.mask until major packages catch up.
  
  You could make localmount and netmount scripts that
  read /etc/fstab and generate need dependencies on the network or
  local filesystems that exist in there. That should emulate current
  behaviour with the new system.
 
 This is exactly what I'm thinking about. Researching this as I go, there
 are reasons to keep localmount and netmount around, but I want to
 rewrite them to depend on mount.*.
 
 There will still be a change in behaviour, because localmount and netmount
 never fail in the current setup, but they potentially will in the new setup
 based on whether or not one of the file systems they depend on fails to mount.
 
 I'm a bit concerned about trying to auto generate dependencies in them,
 for the same reason I'm concerned about auto generating dependencies in
 netmount as it currently stands.
 
 All of this processing would be in the depend() function, and would be
 run every time the OpenRC dependency cache is regenerated. The best way
 to process fstab is with the fstabinfo helper, but every time you run
 it, that is a possible full scan of fstab, and I worry that that would
 slow down dependency cache regeneration for servers with many file
 systems. If I don't use fstabinfo, Im basically re-inventing the wheel
 and writing code in sh to parse fstab.

You could use fstabinfo or findmnt for processing it, but it does not
need to do all the processing, you could cache the results and only
regenerate when the mtime on the fstab is newer than the cache.

On the other hand, unless your fstab is extremely large, it's unlikely
this processing will take particularly long, fstab files tend to be
pretty short (less than 100 entries), and that is not exactly a large
dataset.

 
 Thoughts?
 
 William
 




Re: [gentoo-dev] rfc: openrc mount service prototype

2015-07-31 Thread Patrick McLean
On Fri, 31 Jul 2015 17:28:03 -0500
William Hubbs willi...@gentoo.org wrote:

 On Fri, Jul 31, 2015 at 11:57:59PM +0200, Peter Stuge wrote:
 
 What I'm asking about is whether anyone knows of a smoothe way to
 transition users from local/netmount to mount.filesystem
 dependencies, without breaking systems. If that doesn't exist, 1.0
 will have to sit in p.mask until major packages catch up.

You could make localmount and netmount scripts that
read /etc/fstab and generate need dependencies on the network or
local filesystems that exist in there. That should emulate current
behaviour with the new system.



Re: [gentoo-dev] rfc: openrc mount service prototype

2015-07-29 Thread Patrick McLean
On Thu, 30 Jul 2015 01:11:30 +0300
Alon Bar-Lev alo...@gentoo.org wrote:

 On 29 July 2015 at 23:20, William Hubbs willi...@gentoo.org wrote:
 
  All,
 
  so that there is a better idea out there of what I'm talking about,
  the OpenRC github repository now has a mount-service branch.
 
 Nice!
 
 But I still trying to figure out why do we need to keep fstab around.
 It is pure legacy.
 

On what planet is fstab pure legacy? Many utilities use it and expect it
to exist. For example the ability to do mount /foo requires a properly
configured fstab file (also mount -a).

AFAIK even systemd needs a fstab file if you want to do anything that
it can't autodetect by probing the system.

 There can be a migration script to generate /etc/conf.d/*
 configuration once, but there is no need to keep it around.
 The conf.d can contain everything that fstab contains.
 
 mount_mountpoint_\${NAME}=
 mount_type_\${NAME}=
 mount_fs_\${NAME}=
 mount_opts_\${NAME}=
 mount_dump_\${NAME}=
 mount_pass_\${NAME}=
 

That's a mighty verbose format, especially compared to fstab. I don't
think we should force people to move away from fstab because we have a
new and shiny service system.

Also if you are trying to get rid of legacy stuff, why on earth are
you keeping dump and pass around? Both of those are certainly not
needed if you are doing everything via services.



Re: [gentoo-dev] rfc: go packages vs repositories

2015-06-12 Thread Patrick McLean
On Fri, 12 Jun 2015 12:54:04 -0500
William Hubbs willi...@gentoo.org wrote:

 All,
 
 in looking at some of the Go ebuilds we have in the tree, I see that
 some of them, for example go-tools, have multiple Go packages in a
 single repository. This means that something like:
 
 go get -d -u -t golang.org/x/tools
 
 will fail. There is an issue opened upstream about this [1].
 
 My question for this list is, should we wait for this to be resolved
 before we do anything, or should we change the go packaging we are
 doing to package single go packages instead of repositories?

I would vote for packaging separate packages as we do for other
languages. We could make go ebuilds simply install their sources to
something like /usr/share/go/${PN}-${SLOT}. Then have an eclass build
GOPATH from the installation paths of all the dependencies of that
package. All go libraries should have subslots that match ${PV}, and go
packages should use slot operator deps to make sure they get rebuild
when a library gets updated.

AFAIK this is the only way to get sane and predictable dependency
behaviour with go packages, since upstream seems to be think dynamic
linking is evil.

 Thanks,
 
 William
 
 [1] https://github.com/golang/go/issues/11090




Re: [gentoo-dev] collab herd for cooperative pkg maintenance

2015-03-23 Thread Patrick McLean
On Mon, 23 Mar 2015 22:53:45 +0300
Andrew Savchenko birc...@gentoo.org wrote:

 On Mon, 23 Mar 2015 14:49:44 -0400 Tim Harder wrote:
  On 2015-03-23 13:48, Panagiotis Christopoulos wrote:
   You want to have a herd for that or something in metadata.xml
   that would raise a flag that the package can be freely
   touched/maintained by anyone?
  
  I'd rather have a herd so people can easily scan via euscan or
  similar to see the entire array of pkgs falling into the space.
  Abusing another metadata field doesn't give the same visibility or
  would require changes from tools.
  
  For example, bugs assigned to the herd or with it in CC could be
  fixed by anyone without having to ask for permission. How would
  that be handled easily when using an extra metadata field?

I agree that something along these lines would be really
useful. Possibly it might be a good idea to have some sort of extra
information in the metadata if you want to specify some restrictions on
this. Something like feel free to bump/fix bugs etc but please don't
bump to prerelease versions.



Re: [gentoo-dev] [rfc] enable USE=seccomp in default/linux/ profiles

2015-02-19 Thread Patrick McLean
On Thu, 19 Feb 2015 14:14:37 -0500
Mike Frysinger vap...@gentoo.org wrote:

 pro: improved security in daemons (often network)
 con: some packages might pull in libseccomp (~250KB)
 
 there shouldn't be measurable runtime overhead here as the filtering
 is done by a JIT in the kernel itself.  if the kernel lacks support
 for seccomp, daemons generally should fallback at runtime.  if they
 don't, people should file bugs to get them fixed.

+1

One thing to keep in mind: some upstreams don't really maintain their
seccomp functionality so when, they add usage of new syscalls the
daemon it just ends up crashing. This is definitely a bug that should
be fixed though.



Re: [gentoo-dev] Dropping GCC maintainership

2014-10-06 Thread Patrick McLean
On Mon, 06 Oct 2014 19:25:53 -0400
Anthony G. Basile bluen...@gentoo.org wrote:

 On 10/06/14 13:13, Markos Chandras wrote:
 Let's face it, this is not a job just anyone can do.  I asked a few 
 people I thought could handle it and they said they're too busy.  So
 I'm a bit worried.
 

If someone with the appropriate skills is interested, but currently has
no time. We have some open positions at my employer where Gentoo work is
part of the job.

Work locations are available in Orange County, CA/USA, San
Mateo, CA/USA and Berlin, Germany.

Contact me off-list if you are interested.




Re: [gentoo-dev] gentoo-functions is in the tree

2014-03-12 Thread Patrick McLean
On Thu, 13 Mar 2014 07:59:55 +0800
Patrick Lauer patr...@gentoo.org wrote:

 On 03/13/2014 12:52 AM, William Hubbs wrote:
 
 Why deprecate it?
 
 I'm getting really irritated with the current trend of randomly
 renaming and movearounding things. All it does is confuse people,
 break existing setups and make documentation splitbrained (now you
 need to document two things, and half the old docs won't be aware of
 it ...)
 
 So I guess it boils down to What does the /usr movearounding gain
 us, err, what does renaming bits of OpenRC improve?
 
 The best explanations so far I've seen are it's nicer, we've
 already done it and eh mate, why not? is groovy
 
  If Gentoo needs the symlink after it is removed from OpenRc, I think
  that is the time we can talk about putting it in gentoo-functions.
 
 Now that is funny, but why move it away just so that users panic and
 re-add the wrong flavour of it?
 
 Well, progress I guess: If you change enough things in trivial ways
 you can claim innovation and show a great rate of change (I'm not
 dead yet!)
 

I would say it's because library code such as that really does not
belong in /etc and placing it there in the first place was a mistake.
This is an attempt to correct the mistake without just breaking
everything without warning.



Re: [gentoo-dev] Portage QOS

2014-01-09 Thread Patrick McLean
On Fri, 10 Jan 2014 02:19:03 +0100
Tom Wijsman tom...@gentoo.org wrote:

 On Fri, 10 Jan 2014 08:31:21 +0800
 Patrick Lauer patr...@gentoo.org wrote:
 
  On 01/10/2014 08:16 AM, hero...@gentoo.org wrote:
   Igor lanthrus...@gmail.com writes:
   
   The ebuilds have approximately the same time to install, the
   failure rate is about the same, emerge is getting slower.
   
   I am curious about the slowness of emerge.
   
   How about profile the portage and rewrite the time-crucial part in
   C/C++, or ideally, borrowing the counterpart from paludis? How
   feasible is that?
  
  Last I checked paludis wasn't faster - on average portage was a few
  percents faster.
 

  For python things you really want  python or C instead of C++...
 
 Why is this a Python thing? What's the reason to exclude a language?
 
  So, what you wanted to ask was:
  Which parts of pkgcore can be migrated into portage?
 
 Or rather: What does it take to migrate parts of pkgcore into
 portage?

Why not just switch to using pkgcore as the default package manager.
radhermit has been doing a lot of work lately getting EAPI 5 support
added, and generally fixing bugs etc.

Since we no longer have anyone intimately familiar with the
portage code, we should just switch to a more modern and readable
system. Rather than having random people trying to learn the convoluted
portage code, let's concentrate on getting pkgcore to a point where
we can replace portage with it.

   I guess the dep-tree calculation is the slowest part.
  Yes, it's doing lots of silly dynamic things (backtracking),
 
 Exactly, without backtracking (which I can live without) it takes
 around half a minute as compared to a lot of minutes; when it started
 to take almost half an hour it was time to completely nuke
 backtracking.
 
 Now I happily live without ever needing to enable backtracking
 again. :)
 
  and portage codebase on average is not designed for speed.
 
 Yes, inspecting the profiler results has me worried; though I find
 half a minute acceptable for the amount of packages that are involved
 on my system, so, I'm less concerned but it is still interesting that
 there is the possibility to do things faster. It's just some work to
 actually get it to do that, which requires much more dedication, time
 and knowledge than doing an occasional commit.
 
  As a first step I would recommend profiling it and removing unneeded
  stuff (do less work!), rewriting parts in C is a lot of work and not
  needed for the first round of speedups.
 
 See my other mail 20140110020218.0f6244d5@TOMWIJ-GENTOO for recent
 profiling images; we should indeed start with dealing with the low
 hanging fruit (there are quite some 0-2% speed improvements possible),
 as that can get us to speed it up faster than trying to deal with some
 algorithmic complexity that needs far more insight to redesign, let
 alone to properly re-implement it.
 




Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

2013-10-14 Thread Patrick McLean
On Mon, 14 Oct 2013 15:50:36 -0400
Rich Freeman ri...@gentoo.org wrote:

 On Mon, Oct 14, 2013 at 2:58 PM, David Leverton
 levert...@googlemail.com wrote:
 
  If only someone would invent some sort of kernel feature that could
  make the name /etc/mtab refer to different files in different
  processes
 
 
 However, FWIW, linux namespaces cannot be used to have only a single
 file appear differently to different processes.  Mount namespaces can
 only operate at the directory level.

This is not true. Bind mounts can be performed on a single file, and
bind mounts are part of mount namespaces. Granted the target file _must_
exist (it could be a dead symlink, or a symlink to /dev/null) before
performing the bind mount.



Re: [gentoo-dev] renaming gentoo-oldnet

2013-08-05 Thread Patrick McLean
On Mon, 5 Aug 2013 22:09:54 +
Robin H. Johnson robb...@gentoo.org wrote:

 
 Naming goals:
 - Should describe what it does
 - Does NOT have a name conflict as verified by Google.
 - Does NOT imply OpenRC.
 - Implying Gentoo is fine, as it's where the package comes from.
 - Should drop 'old'
 
 I think we should focus on the first goal the most: 
 oldnet is a network configuring tool in pure POSIX shell
 So we probably want the substring 'net' somewhere in there. Beyond
 that, all suggestions are welcome.
 

Here are a couple of suggestions:
net-init (or netinit) - without the dash the only conflict appears to
be a matlab script of some sort



Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Patrick McLean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/01/13 02:02 PM, Chí-Thanh Christopher Nguyễn wrote:
 Andreas K. Huettel schrieb:
 * move setting USE=dri and USE=cups from default/linux/make.defaults to 
 targets/desktop/make.defaults
 
 I would prefer to keep USE=dri in the default profile. If you want to move 
 VIDEO_CARDS that would be fine with me though.

USE=dri is usually only relevant on desktops, why enable it on all profiles?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBCAAGBQJQ+dhBAAoJEHy/RO9cNQiDLt8P/3C8r+WtNM991Z5pAGIbabOz
ILTx2vvd2rDbo8RM+sCbr2elDF/WP0xntTwnTw3vxWMs8VC6/HZkM+LQLyaMMeMo
tWK9MtV8R7+QZ7XDoOmVDSKe9U62XGlMnnpWV3B7A4s51y71vMqY+TNDBneJWvTz
nh780899va7BVCyRtQ8ed6XjTPx2ft1bDNLr5Vcms3vp0yHXarvgqBXLJjh/Zec1
a+S1IwETNMaTr4Lg2ps5zKgoMvUb6bGTEpo4cksTAHUjISYRRJHyxhZOON2fPOw5
a1RNH0i0fWfipEU3XP5KMgH/mQYu4KNob3LjlKHuspUDjYbfeFkkYyC7jBAucioE
Z5YUfPKXPmE1tzQy59Ld0xQTXdrxES+uWwk1XC3UG+iGgKByk5rEyBX7RX3+brQQ
QdAcBuRBzZtrfAK9B9Un6jBE1bX81o/twiVvu3aTCHXXgGKuEUWfnLmjcJnuj0KE
pWyA3xYfPM11eTq5aWivizChSm7pJxcrR8+GDx4c24mlvJxb0vpuinZJlkaASVIZ
Ncvgmk8+d/L1f32Xeyz4GMDU2SzQA8lTdeUK9E7XyRRcZJOFPpdYMSIhYXAMD9SV
A8vU/zRTjAwrQ6OGVzHxowKQ6Av4pajv7hXeq7pW+dnxURdcOGMV+mbDZ1Qj4kOh
QKuxdgZxOAchIF2TSEq0
=ryu6
-END PGP SIGNATURE-



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/nspluginwrapper: ChangeLog nspluginwrapper-1.4.4-r1.ebuild nspluginwrapper-1.3.0.ebuild

2011-07-13 Thread Patrick McLean
Er, no I didn't, I'm not sure how that happened. I will fix it.

On 13/07/11 01:36 AM, Ryan Hill wrote:
 On Mon, 11 Jul 2011 15:00:41 + (UTC)
 Patrick McLean (chutzpah) chutz...@gentoo.org wrote:
 
 chutzpah11/07/11 15:00:41

   Modified: ChangeLog
   Added:nspluginwrapper-1.4.4-r1.ebuild
   Removed:  nspluginwrapper-1.3.0.ebuild
   Log:
   Revision bump, workaround to fix bug #374169. Drop version 1.3 as 1.4.4 is 
 stable and has a security fix.
 
 I'm guessing you didn't mean to overwrite the whole ChangeLog?
 
 




Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-23 Thread Patrick McLean
On 23/08/10 02:28 PM, Olivier Crête wrote:
 On Mon, 2010-08-23 at 19:09 +0100, Mike Auty wrote:
 On 23/08/10 18:26, Olivier Crête wrote:

 Other distributions are going one step further and are going for
 shell-free boot. We should follow that lead.

 Why?  Presumably they're doing it by writing programs that do their own
 parsing and executing, which means they'll need a maintainer just for
 that program and they'll have to go through a few iterations to get the
 initial bugs out, and then people will have to learn how to use the
 different-yet-again language that goes with it.  Why not rely on a
 prebuilt parser that devs already have to know to look after ebuilds?
 
 Systemd uses ini style files for configuration (and symlinks). So there
 really isn't much of a parser in there. And obviously, they're going
 through some bugfixing right now, so when F14/F15 are out there, we can
 just take their complete solution ;)
 

What are you actual complaints about openrc? What is wrong with using
shell for bootup, it works, it's fast (especially with openrc's ability
to be executed with dash) and _extremely_ flexible.



Re: [gentoo-dev] Optional Package Dependencies for netscape-flash - libflashsupport

2007-05-10 Thread Patrick McLean
Jim Ramsay wrote:
 
 1) Create a single local USE flag (flashsupport or something) that will
 just pull in this dependency.
 
 2) Use the same set of USE flags as libflashsupport has, with any of
 them adding libflashsupport to the dep list, since these are all global
 flags and will most likely be enabled for both netscape-flash and
 libflashsupport
 
 I'm personally thinking (1) is the better of the 2 options, but I'd
 like to know if anyone has any other wondrous solutions to this.

Does/will anything else dep on flashsupport? If not, why not just add
the USE flags to netscape-flash and install libflashsupport as part of
the netscape-flash install instead of a separate package.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] New network config for baselayout-ng

2007-02-07 Thread Patrick McLean

Roy Marples wrote:

Welcome to baselayout-ng which will be a virtual and will not require
bash.


So this means that you are planning to stop development of the current 
baselayout in favor of baselayout-ng?




We still need something that is array like for want of a better
phrase, so how about delimiting using ; like so
config_eth0=10.1.1.1 netmask 255.255.255.0; 10.1.1.2/24



Couldn't you use the current config on bash shells and parse it to 
something like that on non-bash. There is no reason why the shell needs 
to source the config file, it could be parsed just as easily, and 
writing the parser shouldn't be too hard with a bit of sed magic.

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New developer: Samuli Suominen (drac)

2007-02-05 Thread Patrick McLean

Petteri Räty wrote:

It's my pleasure to introduce to you Samuli drac Suominen. He is
joining us to look after the Xfce desktop environment and take care of
packages that have been proxy maintained before.


Welcome to the team drac :)
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Big change ideea

2006-12-15 Thread Patrick McLean
Marijn Schouten wrote:
 My conclusion is that they have the simpler solution and also technical
 superiority.

If you think that GoboLinux has a superior package management solution
to Gentoo or any other distro, than just use Gobo. Distribution choice
is not an absolute distro X is better than distro Y but it's a
personal choice. You happen to like how Gobo does things, probably close
to everybody else here likes how Gentoo does things. Some people prefer
Ubuntu and others Debian, Fedora, RHEL, etc, etc. There are also those
who do not like what any distribution is doing so they start their own
or do LFS. Whichever route you prefer, it's your personal choice. Others
have different opinions.

My point is that if you prefer how Gobo does package management (and
anything else for that matter), then please use Gobo and don't try to
convince other distros to be more like Gobo. This applies to anybody
that thinks that Gentoo should be more like Debian, Fedora or any other
distro. They have their way of doing things, we have our way.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon

2006-11-06 Thread Patrick McLean
Matthew Snelham wrote:
  
 If you want that level of flexability then simply symlink /lib/rcscripts 
 to /var/rcscripts or where-ever you like.
 
 But then baselayout is still 'behaving badly' by sttempting to store
 dynamic state information in /lib.  Something it has not done before, to
 the best of my knowledge (with the exception of /dev state tarballs, which
 are generally acceptable, since they don't change while the system is up).
 
 UNIX filesystem usage patterns are older than a good chunk of gentoo devs,
 so in the name of defaulting to expected behaviour, I think /lib should be
 avoided.

+1

This is a very good point, why are we breaking from accepted UNIX standards
uselessly? Generally, a live system should never need to write to /lib, but a
writable /var is pretty much standard. This new behavior breaks standards, if
/var is on a separate filesystem, maybe we can use a subdir in /tmp for the init
stuff until we get /var up, then move it over.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Scheme herd team needs some love

2006-10-30 Thread Patrick McLean

Matthew Kennedy wrote:

No one is working on the Scheme herd in Gentoo.  [EMAIL PROTECTED]
includes only me, but I'm not doing anything with Scheme and don't
really care to either.

Several of our Scheme implementations in Portage are out of date,
(chicken, gambit, drscheme, bigloo and, dare I mention, guile).



drscheme is not unmaintained or out of date, I am maintaining it. It has 
only one open bug, which is an enhancement request for a feature that 
doesn't compile in the current version.


A quick search found a bug in one of it's deps that was assigned to 
[EMAIL PROTECTED] for some reason (the metadata.xml has the package assigned to 
no-herd).

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] gtk1 vs. gtk2

2006-08-07 Thread Patrick McLean
Enrico Weigelt wrote:
 * Luca Barbato [EMAIL PROTECTED] schrieb:
 Enrico Weigelt wrote:

 It mixes up diffent things to one and just introduces new 
 problems instead of solving anything. I could live with that, 
 if it's for supporting different ABIs, but it obviously isn't.

 No?
 
 In this case not - it's used to mix up two different packages.
 
 
 gtk1 and gtk2 are completely different packages, they're not
 compatible. So why should they be one package ? Just because
 they share some ideas and the name ?!
 Because gtk-2.xx is originated from gtk+-1.2.xx and you still 
 have a common set of widget API ?
 
 The APIs are incompatible. 
 

They are still the both evolutions of the same development tree, they
are the same package, just different versions. If we changed the name of
a package every time there was an API break, we would literally have
thousands of packages in the tree that essentially do the same thing,
just with different API's. According to this philosophy, we should
change the name of the package every time net-misc/neon comes out with a
new version, since it breaks API on every version.

 For example, there are lots of packages requiring gtk1, other
 gtk2. As long as dependencies don't cope the slot cleanly, 
 slotting is utterly useless.
 gtk-1 is deprecated, it will disappear sooner or later.
 
 Maybe, maybe not. That will take some time until all packages are 
 rewritten from gtk1 to gtk2.
 
 BTW: an problem will go away by itself sooner or later isn't 
 actually an good argumentation for such kind of problems.

There is no problem, gtk1 and gtk2 can be installed on the same system
at the same time, and all packages in the tree have their dependencies
set up to depends on whichever version of gtk they need. SLOTS take care
of this quite well.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.

2006-07-10 Thread Patrick McLean
Denis Dupeyron wrote:
 This, for me, triggers 3 questions that are gentoo-dev@ material :
 
 1) Should all ebuilds that currently filter --fast-math die on its
 presence instead of filtering it ?

I don't think we should die on anything, if a user wants a particular
CFLAG, generally the default should be to let them use it. A warning
with a pause may also suffice.

Currently the amd64 profiles do some testing for broken USE flags. If
the user has flags that gcc will not accept (ie errors out with invalid
command line option), our profile.bashrc will filter them out
completely. If they have a flag that is on a list of pre-defined bad
flags it will warn the user about the flag and sleep for 5 seconds.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: GPL and Source code providing

2006-07-05 Thread Patrick McLean
Chris Gianelloni wrote:
 
 Anyway, I really am starting to like the DVD available via the store
 idea more and more, as it only means Release Engineering needs to do a
 little extra work, and it requires no extra work for our mirrors or
 Infrastructure team.
 

The source DVD sounds like a great idea to me, no need to keep anything
around on mirrors, and we fulfill all the requirements of the GPL.

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Nominations open for the Gentoo Council 2007

2006-07-05 Thread Patrick McLean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I would like to nominate:
vapier/SpanKY
flameeyes
Kugelfang
uberlord
wolf31o2
seemant
solar
Mr_Bones_
KingTaco

I would add dsd and spyderous if they hadn't both already turned down
nominations.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEq96HWt/XSf2CZdkRAixKAJ92u46sZDqkjTCf7j9nO4dCYaFvOACfazlb
tclqp4Pc8qtMq1GeHCvz7K4=
=9W0N
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: GPL and Source code providing

2006-07-04 Thread Patrick McLean
Chris Gianelloni wrote:
 On Sat, 2006-07-01 at 11:12 +, Duncan wrote:
 For example, if we hand out CDs at conventions etc, we would have to
 also hand out source CDs.
 
 As my reply there, however, Gentoo does still have it better than most, in
 that the LiveCDs contain relatively few binaries, and they tend to be
 relatively core packages to which sources should still be available even
 for historic releases, should we wish to continue distributing the
 historical LiveCDs. The packages CDs OTOH...
 
 Umm... The LiveCD has almost 700 packages on it.  Perhaps you mean the
 InstallCD?
 

I have absolutely zero experience with catalyst, but couldn't it be made
to create a source CD ISO when it is generating the binary one? Just
make a cd with all the distfiles used in the ISO, and keep the source
ISO with the binary one in /historical.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: GPL and Source code providing

2006-07-04 Thread Patrick McLean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:
 Patrick McLean schrieb:
 I have absolutely zero experience with catalyst, but couldn't it be made
 to create a source CD ISO when it is generating the binary one? Just
 make a cd with all the distfiles used in the ISO, and keep the source
 ISO with the binary one in /historical.
 
 Creating an ISO isn't a problem (assuming you have the sources, which
 for historical releases might be a problem), but it would require
 another several hundred megabytes per release on the mirrors which isn't
 exactly a trivial amount.
 
No it's not a trivial amount, but it's also important that we comply
with the licenses of the software that we distribute. I think that
storing a gig or two extra on the mirrors (or more on the mirrors that
archive /historical) is fairly trivial compared to violating the GPL.

If we violate the GPL in this case, we really won't be able to enforce
it in the future if someone were to violate it in the case of our stuff.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEqsTnWt/XSf2CZdkRAk6FAJ9Sph9N43xafN/ihxUOREjKgJX8KACcCbTy
52EK0y1dFpYu7PL17gu2K3U=
=NP2P
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] client+server packages - build which one?

2006-06-09 Thread Patrick McLean
Roy Marples wrote:
 USE client server
 client - just build the client - duh
 server - just build the server - duh
 client and server OR neither then build both.
 
 Other packages to possably beneift
 udhcp
 mldonkey
 samhain
 bacula
 boxbackup
 
finger, telnet and ssh are probably other candidates. (though not too
many people set up boxes without a ssh server these days).

++ to this, I have always found it a little absurd having dhcpd
installed on my laptop just for dhclient.

George Shapovalov wrote:
 Of course this multiplies the number of packages to support, if such 
 situation 
 is common. However the solution you describe can be considered clean only 
 after #2272 is finally resolved..
 https://bugs.gentoo.org/show_bug.cgi?id=2272
I doubt whether any devs would argue against USE based dependencies.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay

2006-06-08 Thread Patrick McLean
Chris Bainbridge wrote:
 On 08/06/06, Jon Portnoy [EMAIL PROTECTED] wrote:
 I do very much object to using any gentoo.org infrastructure or
 subdomains to do so. If someone is going to tackle that, it should be
 done outside of Gentoo proper. We don't need to be stuck maintaining and
 supporting a semiofficial overlay.
 
 There are already loads of semi-official overlays. Besides the stuff
 actually hosted by gentoo (random example
 http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official
 groups (again, not picking on anyone but exampes would be java, php,
 webapps...) with semi-official overlays. I don't know if the overlays
 are actually hosted on gentoo hardware, but when they're run by gentoo
 devs, publically available, and referred to in forums, bugzilla,
 mailing lists etc. then that at least makes them semi-official.

These overlays are completely controlled by Gentoo developers, which is
what the overlays.gentoo.org was going to be, simply a single location
for all these developer controlled overlays. This project is an overlay
(un)controlled by random users, with no quality checks or any standards
of any kind. This is fine for non-gentoo hosted stuff (like BMG), but
hosting stuff like this on *.gentoo.org, and not having the use go
through hoops to use it is probably not a good idea from either a
security or QA standpoint.

Currently 3rd party ebuilds can live in bugzilla, and the use must
create their own overlay, and generate their own digests to use them.
Making a user put this extra work into encourages users to be more
careful, and hopefully look stuff over before using it. It also
reinforces that the package is _unsupported_, hence discouraging them
from filing any new bugs.

Having a semi-official overlay where users can contribute ebuilds will
open possible security problems (malicious commits) as well as be a
QA/bug triaging nightmare as developers will have to figure out whether
the ebuild the user is using came from the official overlay or the
official tree.
-- 
gentoo-dev@gentoo.org mailing list



  1   2   >