Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Michael Orlitzky
On 07/20/2018 01:06 AM, Mart Raudsepp wrote:
>>
>>   * They can't be undone. It's next to impossible for me to undo
>> USE=udev when set in a profile that is inherited by all others.
> 
> You set USE=-udev in your make.conf.

That doesn't work, for reasons already stated.

If I set USE="-udev" in my make.conf, I don't get the same behavior that
I would if you left the default alone. Specifically, setting USE="-udev"
in make.conf will disable udev support in all packages that have
IUSE="+udev", whereas now they are built WITH udev support. This causes
severe breakage in some cases, and there's no way for me (or anyone
else) to regain the existing behavior once you turn the flag on by default.


>  Or in a profile that really needs this disabled.

Yeah I'd love to except that you're proposing we add it to the "linux"
profile, and it can't be overridden in a sub-profile for the same reason
it can't be overridden in make.conf.



Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Mart Raudsepp
Ühel kenal päeval, R, 20.07.2018 kell 12:40, kirjutas Benda Xu:
> > Any objections to this idea?
> 
> To represent the Gentoo Prefix users, we would like to have USE=udev
> turned off or even hard masked on linux-prefix profiles.

Nothing stops you from doing that in prefix profiles, just like USE=acl
is handled right now.

That said, I would question such a choice. Does it technically not work
or what's the problem with it?
But it's up the prefix project.


Mart

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


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Mart Raudsepp
Ühel kenal päeval, R, 20.07.2018 kell 00:04, kirjutas Michael Orlitzky:
> On 07/19/2018 11:49 PM, Aaron Bauman wrote:
> > You are denying the majority default here. Granted, we don't have
> > statistics... Cuz Gentoo.
> 
> No I'm not. I'm saying add them per-package, because it's a better
> design. We have package.use in profiles now, not just IUSE defaults.
> 
> Global defaults have problems:
> 
>   * They can't be undone. It's next to impossible for me to undo
> USE=udev when set in a profile that is inherited by all others.

You set USE=-udev in your make.conf. Or in a profile that really needs
this disabled.
If as a package maintainer that's not appropriate for a package, then
that sounds like USE=udev is not appropriate for your package.
Got any concrete samples in that case?

>   * USE=udev means different things for different packages. You think
> it
> "makes udev work" or whatever, but nobody has any idea what it
> does
> for half of the packages that use it. The meaning is package-
> specific, so the default should be package-specific.

It makes hardware work without static configurations, including when
hotplugged. It should be enable by default for all Linux users.
People who make a conscious choice to deal with this by hand can easily
set USE=-udev in their make.conf and deal with this by hand afterwards.

The default shouldn't be "nothing works, until you make it work".

>   * They're easy to set, but hard do unset when you realize you were
> wrong a year from now.
> 
> If you really want to enable it globally after being told that it's
> bad
> engineering and downright annoying, go do it in a profile that I can
> avoid and not "linux".

Don't believe everything you're told.
If you still buy into all the trouble you are getting into by stopping
to rely on udev, you disable it in make.conf and use --changed-use for
emerge.


Mart

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


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Benda Xu
Hi Ben,

Ben Kohler  writes:

> I'd like to propose adding USE=udev to our linux profiles (in
> profiles/default/linux/make.defaults probably).  This flag is already
> enabled on desktop profiles but it also affects quite a few packages
> used on non-desktop linux systems.
>
> This flag provides useful functionality that most linux users will
> want. I'm a bit surprised that we still don't have it in all linux
> profiles, but I think we've worked around this in the past by adding
> IUSE=+udev to quite a few of those packages (33 packages, 116 ebuilds,
> by my count).
>
> This missing flag came to my attention again on bug 661584 where lvm2
> has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users
> have a bit of a mismatch between the 2 and get ugly errors on
> cryptsetup.

I expect this to be fixed on the package-by-package basis.

> Since this flag only affects linux, I think it makes more sense to set
> it in linux profiles than to use IUSE defaults.
>
> Any objections to this idea?

To represent the Gentoo Prefix users, we would like to have USE=udev
turned off or even hard masked on linux-prefix profiles.

Yours,
Benda



Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Michael Orlitzky
On 07/19/2018 11:49 PM, Aaron Bauman wrote:
> You are denying the majority default here. Granted, we don't have
> statistics... Cuz Gentoo.

No I'm not. I'm saying add them per-package, because it's a better
design. We have package.use in profiles now, not just IUSE defaults.

Global defaults have problems:

  * They can't be undone. It's next to impossible for me to undo
USE=udev when set in a profile that is inherited by all others.

  * USE=udev means different things for different packages. You think it
"makes udev work" or whatever, but nobody has any idea what it does
for half of the packages that use it. The meaning is package-
specific, so the default should be package-specific.

  * They're easy to set, but hard do unset when you realize you were
wrong a year from now.

If you really want to enable it globally after being told that it's bad
engineering and downright annoying, go do it in a profile that I can
avoid and not "linux".



Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Aaron Bauman
Please provide substantial evidence for your claims.  Furthermore, a profile of 
your choice would be honorable.

On July 19, 2018 9:58:25 PM EDT, Rich Freeman  wrote:
>On Thu, Jul 19, 2018 at 9:42 PM Andrew Savchenko 
>wrote:
>>
>> On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote:
>> > Hello,
>> >
>> > I'd like to propose adding USE=udev to our linux profiles (in
>> > profiles/default/linux/make.defaults probably).  This flag is
>already
>> > enabled on desktop profiles but it also affects quite a few
>packages
>> > used on non-desktop linux systems.
>> >
>>
>> I have server setups with udev disabled for most packages. So udev
>> enabled by default will create maintenance problems. While I'm
>> perfectly fine with udev enabled by default on desktops, it should
>> not be forced on minimalistic setups like servers or containers.
>
>80% of the servers on the planet are running a linux distro, and 99%
>of those are probably running udev.  Gentoo is probably the only
>distro where making udev the (trivially disabled) default is even
>remotely controversial.
>
>Maybe we need some kind of ultra-minimal profile for people who really
>don't want anything installed if they didn't put it there.  It seems
>odd to make that sort of configuration our "base" as it really isn't a
>normal configuration by any standard.
>
>There is nothing wrong with people who want to start with a minimal
>profile.  I just don't think it makes a lot of sense to have that as a
>default starting point.  There is no reason that "base" needs to be a
>subset of all the other profiles.
>
>If for some reason we don't go with this, perhaps it would at least
>make sense to have a server profile that enables it by default and
>make base something that normal users are discouraged from using.
>
>-- 
>Rich

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Aaron Bauman
It's not about *you*.  Please provide a reasonable justification.

On July 19, 2018 9:54:40 PM EDT, Mikle Kolyada  wrote:
>
>
>On 20.07.2018 04:42, Andrew Savchenko wrote:
>> On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote:
>>> Hello,
>>>
>>> I'd like to propose adding USE=udev to our linux profiles (in 
>>> profiles/default/linux/make.defaults probably).  This flag is
>already 
>>> enabled on desktop profiles but it also affects quite a few packages
>
>>> used on non-desktop linux systems.
>>>
>>> This flag provides useful functionality that most linux users will
>want. 
>>>   I'm a bit surprised that we still don't have it in all linux
>profiles, 
>>> but I think we've worked around this in the past by adding
>IUSE=+udev to 
>>> quite a few of those packages (33 packages, 116 ebuilds, by my
>count).
>>>
>>> This missing flag came to my attention again on bug 661584 where
>lvm2 
>>> has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop
>users 
>>> have a bit of a mismatch between the 2 and get ugly errors on
>cryptsetup.
>>>
>>> Since this flag only affects linux, I think it makes more sense to
>set 
>>> it in linux profiles than to use IUSE defaults.
>>>
>>> Any objections to this idea?
>> I have server setups with udev disabled for most packages. So udev
>> enabled by default will create maintenance problems. While I'm
>> perfectly fine with udev enabled by default on desktops, it should
>> not be forced on minimalistic setups like servers or containers.
>>
>> Best regards,
>> Andrew Savchenko
>+1. widely used profiles should have as least flags enabled by default
>as possible, I would not be happy with +udev on my servers.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Aaron Bauman
You are the minimalist... Not the rest.  Provide a reasonable scenario please.

On July 19, 2018 9:42:11 PM EDT, Andrew Savchenko  wrote:
>On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote:
>> Hello,
>> 
>> I'd like to propose adding USE=udev to our linux profiles (in 
>> profiles/default/linux/make.defaults probably).  This flag is already
>
>> enabled on desktop profiles but it also affects quite a few packages 
>> used on non-desktop linux systems.
>> 
>> This flag provides useful functionality that most linux users will
>want. 
>>   I'm a bit surprised that we still don't have it in all linux
>profiles, 
>> but I think we've worked around this in the past by adding IUSE=+udev
>to 
>> quite a few of those packages (33 packages, 116 ebuilds, by my
>count).
>> 
>> This missing flag came to my attention again on bug 661584 where lvm2
>
>> has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop
>users 
>> have a bit of a mismatch between the 2 and get ugly errors on
>cryptsetup.
>> 
>> Since this flag only affects linux, I think it makes more sense to
>set 
>> it in linux profiles than to use IUSE defaults.
>> 
>> Any objections to this idea?
>
>I have server setups with udev disabled for most packages. So udev
>enabled by default will create maintenance problems. While I'm
>perfectly fine with udev enabled by default on desktops, it should
>not be forced on minimalistic setups like servers or containers.
>
>Best regards,
>Andrew Savchenko

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Aaron Bauman
You are denying the majority default here.  Granted, we don't have 
statistics... Cuz Gentoo.

On July 19, 2018 6:00:44 PM EDT, Michael Orlitzky  wrote:
>On 07/19/2018 05:51 PM, Ben Kohler wrote:
>> Hello,
>> 
>> I'd like to propose adding USE=udev to our linux profiles (in 
>> profiles/default/linux/make.defaults probably).  This flag is already
>
>> enabled on desktop profiles but it also affects quite a few packages 
>> used on non-desktop linux systems.
>> 
>> ...
>> 
>> Any objections to this idea?
>> 
>
>Please add defaults per-package, only where they make sense. Enabling
>flags globally creates a huge headache for people that want them off.
>
>If I want to undo your new flag, I have to set USE="-udev" globally,
>and
>that clobbers any important per-package defaults that maintainers have
>set.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Rich Freeman
On Thu, Jul 19, 2018 at 9:42 PM Andrew Savchenko  wrote:
>
> On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote:
> > Hello,
> >
> > I'd like to propose adding USE=udev to our linux profiles (in
> > profiles/default/linux/make.defaults probably).  This flag is already
> > enabled on desktop profiles but it also affects quite a few packages
> > used on non-desktop linux systems.
> >
>
> I have server setups with udev disabled for most packages. So udev
> enabled by default will create maintenance problems. While I'm
> perfectly fine with udev enabled by default on desktops, it should
> not be forced on minimalistic setups like servers or containers.

80% of the servers on the planet are running a linux distro, and 99%
of those are probably running udev.  Gentoo is probably the only
distro where making udev the (trivially disabled) default is even
remotely controversial.

Maybe we need some kind of ultra-minimal profile for people who really
don't want anything installed if they didn't put it there.  It seems
odd to make that sort of configuration our "base" as it really isn't a
normal configuration by any standard.

There is nothing wrong with people who want to start with a minimal
profile.  I just don't think it makes a lot of sense to have that as a
default starting point.  There is no reason that "base" needs to be a
subset of all the other profiles.

If for some reason we don't go with this, perhaps it would at least
make sense to have a server profile that enables it by default and
make base something that normal users are discouraged from using.

-- 
Rich



Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Mikle Kolyada


On 20.07.2018 04:42, Andrew Savchenko wrote:
> On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote:
>> Hello,
>>
>> I'd like to propose adding USE=udev to our linux profiles (in 
>> profiles/default/linux/make.defaults probably).  This flag is already 
>> enabled on desktop profiles but it also affects quite a few packages 
>> used on non-desktop linux systems.
>>
>> This flag provides useful functionality that most linux users will want. 
>>   I'm a bit surprised that we still don't have it in all linux profiles, 
>> but I think we've worked around this in the past by adding IUSE=+udev to 
>> quite a few of those packages (33 packages, 116 ebuilds, by my count).
>>
>> This missing flag came to my attention again on bug 661584 where lvm2 
>> has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users 
>> have a bit of a mismatch between the 2 and get ugly errors on cryptsetup.
>>
>> Since this flag only affects linux, I think it makes more sense to set 
>> it in linux profiles than to use IUSE defaults.
>>
>> Any objections to this idea?
> I have server setups with udev disabled for most packages. So udev
> enabled by default will create maintenance problems. While I'm
> perfectly fine with udev enabled by default on desktops, it should
> not be forced on minimalistic setups like servers or containers.
>
> Best regards,
> Andrew Savchenko
+1. widely used profiles should have as least flags enabled by default
as possible, I would not be happy with +udev on my servers.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Andrew Savchenko
On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote:
> Hello,
> 
> I'd like to propose adding USE=udev to our linux profiles (in 
> profiles/default/linux/make.defaults probably).  This flag is already 
> enabled on desktop profiles but it also affects quite a few packages 
> used on non-desktop linux systems.
> 
> This flag provides useful functionality that most linux users will want. 
>   I'm a bit surprised that we still don't have it in all linux profiles, 
> but I think we've worked around this in the past by adding IUSE=+udev to 
> quite a few of those packages (33 packages, 116 ebuilds, by my count).
> 
> This missing flag came to my attention again on bug 661584 where lvm2 
> has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users 
> have a bit of a mismatch between the 2 and get ugly errors on cryptsetup.
> 
> Since this flag only affects linux, I think it makes more sense to set 
> it in linux profiles than to use IUSE defaults.
> 
> Any objections to this idea?

I have server setups with udev disabled for most packages. So udev
enabled by default will create maintenance problems. While I'm
perfectly fine with udev enabled by default on desktops, it should
not be forced on minimalistic setups like servers or containers.

Best regards,
Andrew Savchenko


pgpKn16FFnEw6.pgp
Description: PGP signature


Re: [gentoo-dev] Re: What means bup?

2018-07-19 Thread Mikle Kolyada


On 18.07.2018 19:57, Matthew Thode wrote:
> On 18-07-18 11:28:16, Mike Gilbert wrote:
>> On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode
>>  wrote:
>>> On 18-07-18 09:16:07, Johannes Huber wrote:
 Hi all,

 english is not my mother language, so please clarify what bup means, just
 seen here:

 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397

 Just checked if it was a typo, but can't be:
 git log --oneline --grep bup | count -l
 Expected 0 lines, got 1248.

>>> It's similiar to a sound you make when you touch something's nose.
>>> *boop*
>>>
>>> I just prefer bup instead.  I generally only use it when doing simple
>>> bumps of packages (copy ebuilds with only keyword edits).
>> My preference is to mention the version being added when committing a
>> version bump. eg. "cat/pkg: bump to x.y.z".
>>
>> Yes, it does take a few more seconds, but I think it is worth the effort.
>>
> I think more recently I've been following this format.
>
> cat/pkg: x.y.z bup
>

But can you please *stop* doing this as well? It is neither clear
language *nor* useful reduction.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Ben Kohler

On 07/19/2018 05:00 PM, Michael Orlitzky wrote:


Please add defaults per-package, only where they make sense. Enabling
flags globally creates a huge headache for people that want them off.

If I want to undo your new flag, I have to set USE="-udev" globally, and
that clobbers any important per-package defaults that maintainers have set.



I was well aware of that when I prepared this proposal, and it's true of 
every USE flag in any profile's make.defaults.  I still believe it's the 
correct course of action.


Thanks,

Ben



Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Michael Orlitzky
On 07/19/2018 05:51 PM, Ben Kohler wrote:
> Hello,
> 
> I'd like to propose adding USE=udev to our linux profiles (in 
> profiles/default/linux/make.defaults probably).  This flag is already 
> enabled on desktop profiles but it also affects quite a few packages 
> used on non-desktop linux systems.
> 
> ...
> 
> Any objections to this idea?
> 

Please add defaults per-package, only where they make sense. Enabling
flags globally creates a huge headache for people that want them off.

If I want to undo your new flag, I have to set USE="-udev" globally, and
that clobbers any important per-package defaults that maintainers have set.



[gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Ben Kohler

Hello,

I'd like to propose adding USE=udev to our linux profiles (in 
profiles/default/linux/make.defaults probably).  This flag is already 
enabled on desktop profiles but it also affects quite a few packages 
used on non-desktop linux systems.


This flag provides useful functionality that most linux users will want. 
 I'm a bit surprised that we still don't have it in all linux profiles, 
but I think we've worked around this in the past by adding IUSE=+udev to 
quite a few of those packages (33 packages, 116 ebuilds, by my count).


This missing flag came to my attention again on bug 661584 where lvm2 
has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users 
have a bit of a mismatch between the 2 and get ugly errors on cryptsetup.


Since this flag only affects linux, I think it makes more sense to set 
it in linux profiles than to use IUSE defaults.


Any objections to this idea?

Thanks,

Ben



Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)

2018-07-19 Thread Chí-Thanh Christopher Nguyễn

Ulrich Mueller schrieb:

Users must never
need to modify files in /var/lib to configure a package's operation,
and _the_specific_file_hierarchy_ used to store the data _must_not_be_
_exposed_ to regular users."


One small note, while it is never needed to modify, skel.ebuild would then be 
a file that is meant to be accessed by users in /var/lib if your proposal is 
realized.



Best regards,
Chí-Thanh Christopher Nguyễn



[gentoo-dev] Packages up for grabs: net-im/qtox, net-libs/tox

2018-07-19 Thread Jonas Stein
Dear all,

The following packages are up for grabs:

net-im/qtox
net-libs/tox

after retirement of the proxied maintainer.

https://packages.gentoo.org/packages/net-im/qtox
https://packages.gentoo.org/packages/net-libs/tox

-- 
Best,
Jonas





































































signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs: app-backup/fsarchiver, app-cdr/daa2iso...

2018-07-19 Thread Ulrich Mueller
> On Thu, 19 Jul 2018, Johannes Huber wrote:

>> app-doc/devmanual

> I took those by myself.

I have added the devmanual project as well, as a backup maintainer.

Ulrich


pgpB8U3Eu2VqK.pgp
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs: app-backup/fsarchiver, app-cdr/daa2iso...

2018-07-19 Thread Mikle Kolyada


On 19.07.2018 11:10, Michał Górny wrote:
> Hello,
>
> Due to Markos Chandras' prolonged absence, the following packages are up
> for grabs now:
[snip]
> sys-auth/sssd
>
>

Will take this one, someone else is welcome to help :)



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH v2] distutils-r1.eclass: Enable parallel builds in py3.5+

2018-07-19 Thread Michał Górny
Python 3.5+ introduces parallel build support in distutils.  Take
advantage of that by passing appropriate -j option.  Since distutils
does not support an equivalent of --load-average, default to the number
of CPUs+1 when unspecified.

In order to avoid breaking stable systems, introduce the new behavior
only for EAPI 7 ebuilds, or older EAPI ebuilds with unstable
implementations (Python 3.7 and PyPy 3).
---
 eclass/distutils-r1.eclass | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 975383acc09b..85f8f4cb3be9 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -80,10 +80,10 @@ if [[ ! ${_DISTUTILS_R1} ]]; then
 
 [[ ${EAPI} == [45] ]] && inherit eutils
 [[ ${EAPI} == [56] ]] && inherit xdg-utils
-inherit toolchain-funcs
+inherit multiprocessing toolchain-funcs
 
 if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
-   inherit multiprocessing python-r1
+   inherit python-r1
 else
inherit python-single-r1
 fi
@@ -454,7 +454,23 @@ distutils-r1_python_compile() {
 
_distutils-r1_copy_egg_info
 
-   esetup.py build "${@}"
+   local build_args=()
+   # distutils is parallel-capable since py3.5
+   # to avoid breaking stable ebuilds, enable it only if either:
+   # a. we're dealing with EAPI 7
+   # b. we're dealing with Python 3.7 or PyPy3
+   if python_is_python3 && [[ ${EPYTHON} != python3.4 ]]; then
+   if [[ ${EAPI} != [56] || ${EPYTHON} != python3.[56] ]]; then
+   local jobs=$(makeopts_jobs "${MAKEOPTS}" INF)
+   if [[ ${jobs} == INF ]]; then
+   local nproc=$(get_nproc)
+   jobs=$(( nproc + 1 ))
+   fi
+   build_args+=( -j "${jobs}" )
+   fi
+   fi
+
+   esetup.py build "${build_args[@]}" "${@}"
 }
 
 # @FUNCTION: _distutils-r1_wrap_scripts
-- 
2.18.0




Re: [gentoo-dev] Packages up for grabs: app-backup/fsarchiver, app-cdr/daa2iso...

2018-07-19 Thread Brian Dolbec
On Thu, 19 Jul 2018 10:10:11 +0200
Michał Górny  wrote:

> Hello,
> 
> Due to Markos Chandras' prolonged absence, the following packages are
> up for grabs now:
> 
> dev-util/buildbot-slave

I've taken over all buildbot maintenance.  This one will be tree-cleaned
soon.  The old buildbot-0.8 releases are long since dead upstream.  I
will begin that process once I stabilize one of the newer
releases.


pgpETlmIeVsOT.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Enable parallel builds in py3.5+

2018-07-19 Thread Mike Gilbert
On Thu, Jul 19, 2018 at 10:14 AM, Michał Górny  wrote:
> W dniu czw, 19.07.2018 o godzinie 10∶06 -0400, użytkownik Mike Gilbert
> napisał:
>> On Tue, Jul 17, 2018 at 10:48 AM, Michał Górny  wrote:
>> > W dniu wto, 17.07.2018 o godzinie 10∶40 -0400, użytkownik Mike Gilbert
>> > napisał:
>> > > On Tue, Jul 17, 2018 at 4:41 AM, Michał Górny  wrote:
>> > > > Python 3.5+ introduces parallel build support in distutils.  Take
>> > > > advantage of that by passing appropriate -j option.  Since distutils
>> > > > does not support an equivalent of --load-average, default to the number
>> > > > of CPUs+1 when unspecified.
>> > >
>> > > How do we disable this in individual ebuilds when we inevitably run
>> > > into problematic packages?
>> >
>> > My guess would be, same as emake:
>> >
>> >   distutils-r1_python_compile -j1
>> >
>> > (I haven't tested it though)
>>
>> This will affect stable ebuilds that have python3_5 or python3_6
>> enabled. It would be a good idea to test it on a reasonable sample of
>> ebuilds first.
>>
>> Alternatively, we could enable it for python3_7 first and see what
>> kind of fallout that produces.
>>
>
> Given that we still have a reasonably small set of EAPI 7 ebuilds, how
> about EAPI 7 for all Pythons + python3_7 for all EAPIs?  ;-)

That sounds good to me.



Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Enable parallel builds in py3.5+

2018-07-19 Thread Michał Górny
W dniu czw, 19.07.2018 o godzinie 10∶06 -0400, użytkownik Mike Gilbert
napisał:
> On Tue, Jul 17, 2018 at 10:48 AM, Michał Górny  wrote:
> > W dniu wto, 17.07.2018 o godzinie 10∶40 -0400, użytkownik Mike Gilbert
> > napisał:
> > > On Tue, Jul 17, 2018 at 4:41 AM, Michał Górny  wrote:
> > > > Python 3.5+ introduces parallel build support in distutils.  Take
> > > > advantage of that by passing appropriate -j option.  Since distutils
> > > > does not support an equivalent of --load-average, default to the number
> > > > of CPUs+1 when unspecified.
> > > 
> > > How do we disable this in individual ebuilds when we inevitably run
> > > into problematic packages?
> > 
> > My guess would be, same as emake:
> > 
> >   distutils-r1_python_compile -j1
> > 
> > (I haven't tested it though)
> 
> This will affect stable ebuilds that have python3_5 or python3_6
> enabled. It would be a good idea to test it on a reasonable sample of
> ebuilds first.
> 
> Alternatively, we could enable it for python3_7 first and see what
> kind of fallout that produces.
> 

Given that we still have a reasonably small set of EAPI 7 ebuilds, how
about EAPI 7 for all Pythons + python3_7 for all EAPIs?  ;-)

-- 
Best regards,
Michał Górny


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


Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Enable parallel builds in py3.5+

2018-07-19 Thread Mike Gilbert
On Tue, Jul 17, 2018 at 10:48 AM, Michał Górny  wrote:
> W dniu wto, 17.07.2018 o godzinie 10∶40 -0400, użytkownik Mike Gilbert
> napisał:
>> On Tue, Jul 17, 2018 at 4:41 AM, Michał Górny  wrote:
>> > Python 3.5+ introduces parallel build support in distutils.  Take
>> > advantage of that by passing appropriate -j option.  Since distutils
>> > does not support an equivalent of --load-average, default to the number
>> > of CPUs+1 when unspecified.
>>
>> How do we disable this in individual ebuilds when we inevitably run
>> into problematic packages?
>
> My guess would be, same as emake:
>
>   distutils-r1_python_compile -j1
>
> (I haven't tested it though)

This will affect stable ebuilds that have python3_5 or python3_6
enabled. It would be a good idea to test it on a reasonable sample of
ebuilds first.

Alternatively, we could enable it for python3_7 first and see what
kind of fallout that produces.



Re: [gentoo-dev] Packages up for grabs: app-backup/fsarchiver, app-cdr/daa2iso...

2018-07-19 Thread Juippisi .
On Thu, Jul 19, 2018 at 8:10 AM, Michał Górny  wrote:

> Hello,
>
> Due to Markos Chandras' prolonged absence, the following packages are up
> for grabs now:
>
> sys-kernel/pf-sources
>

I would be interested in maintaining this. Been using it for a long time
and bumped the ebuild locally. I've also rewritten the whole ebuild to
include "base" and "extras" patch sets from genpatches, and to be EAPI6.
All in all its very close to how ck-sources look and behave. There's also a
bug open to bump it.

I'd need someone to commit pushes for me, and if some dev wants to
co-maintain this, I'd be more than happy to do the PRs.



> x11-misc/lightdm
> x11-misc/lightdm-gtk-greeter
>

If there's no interest from anyone, I can take these when updating / fixing
bugs.


Re: [gentoo-dev] Packages up for grabs: app-backup/fsarchiver, app-cdr/daa2iso...

2018-07-19 Thread Johannes Huber


Am 19.07.2018 um 10:10 schrieb Michał Górny:
> Hello,
> 
> Due to Markos Chandras' prolonged absence, the following packages are up
> for grabs now.
> app-doc/devmanual
> net-misc/sshpass
> sys-apps/cpuid
> sys-apps/daemonize
> sys-fs/fuse-zip
> x11-misc/fpm2
> x11-misc/obconf

I took those by myself.

> x11-themes/tactile
> x11-themes/tactile3

The themes will be maintained by desktop-misc.

Best regards,
Johannes




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs: net-news/rssguard,...

2018-07-19 Thread Mart Raudsepp
Ühel kenal päeval, K, 18.07.2018 kell 23:38, kirjutas Jonas Stein:
> net-misc/streamlink

I can take this, as I use it. Co-maintainers very welcome.


Mart

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


[gentoo-dev] Re: Packages up for grabs: net-news/rssguard,...

2018-07-19 Thread Johannes Huber


Am 18.07.2018 um 23:38 schrieb Jonas Stein:
> ...
> app-crypt/zulucrypt
> app-admin/profile-cleaner
> ...

Took those two.

Best regards,
Johannes



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs: app-backup/fsarchiver, app-cdr/daa2iso...

2018-07-19 Thread Michał Górny
Hello,

Due to Markos Chandras' prolonged absence, the following packages are up
for grabs now:

app-backup/fsarchiver
app-cdr/daa2iso
app-cdr/gaffitter
app-doc/devmanual
app-emulation/phpvirtualbox
app-i18n/transifex-client
app-misc/conmux
app-misc/pysmssend
app-misc/socnetv
app-mobilephone/qtadb
app-text/chm2pdf
app-text/u2ps
dev-lang/jimtcl
dev-libs/json-c
dev-util/buildbot-slave
games-misc/xcowsay
media-gfx/mypaint
media-libs/liblqr
media-libs/libmetalink
media-libs/opusfile
media-sound/fluid-soundfont
media-sound/wildmidi
media-video/get_flash_videos
media-video/imagination
media-video/rtmpdump
media-video/ushare
net-analyzer/arpon
net-ftp/vsftpd
net-libs/libtorrent-rasterbar
net-misc/mulk
net-misc/netctl
net-misc/pmsvn
net-misc/sshpass
net-misc/ttytter
net-misc/wol
sci-electronics/gresistor
sys-apps/cpuid
sys-apps/daemonize
sys-apps/stroke
sys-apps/syslog-notify
sys-auth/sssd
sys-fs/fuse-zip
sys-fs/lessfs
sys-fs/treesize
sys-kernel/pf-sources
x11-misc/fpm2
x11-misc/googsystray
x11-misc/lightdm
x11-misc/lightdm-gtk-greeter
x11-misc/obconf
x11-themes/tactile
x11-themes/tactile3

-- 
Best regards,
Michał Górny


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


[gentoo-dev] Re: rfc: moving default location of portage tree

2018-07-19 Thread Ulrich Mueller
> On Wed, 18 Jul 2018, Christopher Head wrote:

> On July 18, 2018 2:55:55 AM PDT, Ulrich Mueller  wrote:
>> It was mentioned that all three directories (ebuild repository,
>> binary packages, distfiles) have some characteristics of a cache.
>> However, I think this is much more true for distfiles than for the
>> other two, which cannot be easily restored to a previous state.

> Neither can a Web browser’s cache, if the remote page has changed,
> yet those are still called caches. Surely a cache is something that
> can safely be discarded without negative impact

In my understanding, a cache is typically an open collection of items.
Some subset of them can be deleted without much negative consequence,
and there may also be surplus items that are no longer necessary and
will be expired at some later time in order to reclaim disk space.

Nothing of this is true for an ebuild repository, which is a closed
collection of files: A single file cannot be discarded without
invalidating the whole repository. Also there cannot be any stray
files which would be expired later. Same as above, a single stray file
will invalidate all.

(A collection of binary packages may qualify as a cache though, by
this definition.)

> (which, for most users, the ebuild tree can be, since for most
> users, getting back today’s tree rather than last week’s is not a
> negative impact), not something that can be restored to exactly its
> prior state automatically.

Consider a production system that is only updated at certain well
defined times. Its system administrator may still want to install one
additional package, or flip a use flag for another. In this scenario,
the gentoo repository is a precious resource, and restoring it to a
different state would not be acceptable.

Ulrich


pgp28LKwWKBQZ.pgp
Description: PGP signature