Re: [gentoo-dev] Adding USE=udev to linux profiles
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
Ü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
Ü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
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
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
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
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
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
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
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
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
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?
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
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
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
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)
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
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...
> 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...
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+
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...
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+
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+
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+
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...
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...
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,...
Ü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,...
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...
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
> 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