[gentoo-dev] It is GSoC season again

Google Summer of Code 2016 is starting. If you are a student please be patient. Your time will come soon, at which point we'll be able to answer all your questions. In this initial phase the audience is project mentors. Note that you do not need to be a Gentoo developer to be a mentor. While we a

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-fs/samba/, net-fs/samba/files/, net-fs/samba/files/4.4/

On Wed, Feb 10, 2016 at 01:22:22PM +0800, Jason Zaman wrote: > We do not need the whole manifest checking, we just need to have a list > of SRC_URI that is being added in any ebuilds and then grep Manifest if > those filenames exist. The receive hook checking the hashes of the files > is probably a

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-fs/samba/, net-fs/samba/files/, net-fs/samba/files/4.4/

On Wed, Feb 10, 2016 at 05:11:20AM +, Robin H. Johnson wrote: > On Wed, Feb 10, 2016 at 01:24:16AM +, Robin H. Johnson wrote: > > I will happily take a pre-receive hook, regardless of it using > > pkgcore/portage. Note that it should operate WITHOUT having a checkout, > > needs to be able t

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-fs/samba/, net-fs/samba/files/, net-fs/samba/files/4.4/

On Wed, Feb 10, 2016 at 01:24:16AM +, Robin H. Johnson wrote: > I will happily take a pre-receive hook, regardless of it using > pkgcore/portage. Note that it should operate WITHOUT having a checkout, > needs to be able to take new ebuilds & Manifest on stdin. > > Trying to checkout the tree f

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

On 09 Feb 2016 22:39, Duncan wrote: > Mike Frysinger posted on Tue, 09 Feb 2016 14:26:52 -0500 as excerpted: > > On 08 Feb 2016 13:46, Michał Górny wrote: > >> I'm strongly against this, because: > > > > agreed. i also don't see any reasons in Patrick's e-mail to suggest the > > current default i

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Tue, Feb 09, 2016 at 03:47:34PM -0800, Daniel Campbell wrote > I think the only people who can rightfully complain about lack of > attention or coverage are those who are using these lesser-known or > lesser-used systems. Maybe we can get some users to step up to the > plate and contribute to t

Re: [gentoo-dev] "Lazy" use flags?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 07:08 PM, Gordon Pettey wrote: > > On Tue, Feb 9, 2016 at 7:19 AM, Kent Fredric > mailto:kentfred...@gmail.com>> wrote: > > On 10 February 2016 at 02:14, Daniel Campbell > wrote: >> Another concern, though, is

Re: [gentoo-dev] "Lazy" use flags?

On Tue, Feb 9, 2016 at 7:19 AM, Kent Fredric wrote: > On 10 February 2016 at 02:14, Daniel Campbell wrote: > > Another concern, though, is it'd result in something similar. Instead > > of "cat/foo bar baz" and later removing 'baz', you'd have "cat/foo bar > > ~baz" (with '~baz' as 'enable this i

Re: [gentoo-dev] games.eclass policy

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 7 Feb 2016 04:13:38 -0800 Daniel Campbell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 02/07/2016 03:09 AM, Michał Górny wrote: > > On Sun, 7 Feb 2016 11:38:27 +0100 "M.B." wrote: > > > [...] > ies#Games_team_po

Re: [gentoo-dev] "Lazy" use flags?

On 10 February 2016 at 14:12, Rich Freeman wrote: >> I'd personally rather the list of "automatically turn this on if >> required" be something I had the power to restrict than have a blanket >> "autodostuff", because in the event some USE can't be satisfied, the >> first time that USE flag was de

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-fs/samba/, net-fs/samba/files/, net-fs/samba/files/4.4/

On Tue, Feb 09, 2016 at 08:08:33PM -0500, Tim Harder wrote: > I imagine in the end it would be better to put some of the faster checks > into the git hook pipeline itself. For example, reject commits at push > time that are missing DIST entries. > > Since I'm not familiar with the infra setup all

Re: [gentoo-dev] "Lazy" use flags?

On Tue, Feb 9, 2016 at 7:20 PM, Kent Fredric wrote: > I'd personally rather the list of "automatically turn this on if > required" be something I had the power to restrict than have a blanket > "autodostuff", because in the event some USE can't be satisfied, the > first time that USE flag was deem

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-fs/samba/, net-fs/samba/files/, net-fs/samba/files/4.4/

On 2016-02-09 19:59, Robin H. Johnson wrote: On Tue, Feb 09, 2016 at 07:03:28PM -0500, Tim Harder wrote: Just to note, devs that make these mistakes should already get emails from the CI test setup [1]. If those emails need to be more specific about the severity I'm sure that could be changed so

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-fs/samba/, net-fs/samba/files/, net-fs/samba/files/4.4/

On Tue, Feb 09, 2016 at 07:03:28PM -0500, Tim Harder wrote: > Just to note, devs that make these mistakes should already get emails from the > CI test setup [1]. If those emails need to be more specific about the severity > I'm sure that could be changed so you don't need to act like a CI bot if yo

[gentoo-dev] Re: Changing order of default virtual/udev provider

Rich Freeman posted on Tue, 09 Feb 2016 13:29:04 -0500 as excerpted: > This isn't holding back systemd, and doesn't really have anything to do > with systemd at all. /Now/ you and I (both systemd users) are on the same page, here. =:^) The outcome of this debate isn't going to affect systemd use

Re: [gentoo-dev] "Lazy" use flags?

On 10 February 2016 at 09:35, Róbert Čerňanský wrote: > > The question is whether you really need to specify the lazy use flag > explicitly. I would say that any flag which user did not set > explicitly to -baz or baz could be considered as lazy use flag. > > So if I'd have 'baz' set in /etc/port

[gentoo-dev] Re: Changing order of default virtual/udev provider

Daniel Campbell posted on Tue, 09 Feb 2016 06:44:34 -0800 as excerpted: > If anything, a developer will have more control over how their daemon > is handled in the rc script. They would have to read systemd's C code > or its plethora of unit options to set it up 'just right' to achieve > the same.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-fs/samba/, net-fs/samba/files/, net-fs/samba/files/4.4/

On 2016-02-09 18:50, Robin H. Johnson wrote: Your commit is missing a DIST entry for: samba-disable-python-patches-4.4.0.tar.xz As such, is breaking git->rsync export. Please fix ASAP. Was this a partial repoman used, because the commit log shows a Portage line, yet the DIST is still missing.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-fs/samba/, net-fs/samba/files/, net-fs/samba/files/4.4/

Your commit is missing a DIST entry for: samba-disable-python-patches-4.4.0.tar.xz As such, is breaking git->rsync export. Please fix ASAP. Was this a partial repoman used, because the commit log shows a Portage line, yet the DIST is still missing. On Tue, Feb 09, 2016 at 10:06:42PM +, Ian St

Re: [gentoo-dev] Changing order of default virtual/udev provider

Rich Freeman wrote: > There is already a thread on gentoo-user asking how to safely switch > from udev->eudev. If that were just a part of the handbook that isn't > even a migration they'd have to make on a new install. Nor would > udev->systemd. To summarize my goals in this thread: 1. Suggest tha

Re: [gentoo-dev] Changing order of default virtual/udev provider

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 10:29 AM, Rich Freeman wrote: > On Tue, Feb 9, 2016 at 12:18 PM, Brian Dolbec > wrote: >> >> Why must it become yet another shouting match. And I'm sorry to >> have to tell you this, but you have been leading the charge in >> that di

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

On 09/02/16 23:38, Alex McWhirter wrote: > On 02/09/2016 05:39 PM, Duncan wrote: >> I'd agree, except that the way we're running udev is strongly discouraged >> and generally not supported by upstream, with a statement that it /will/ >> break in the future, it's simply a matter of time. >> >> Wh

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

On 02/09/2016 05:39 PM, Duncan wrote: > I'd agree, except that the way we're running udev is strongly discouraged > and generally not supported by upstream, with a statement that it /will/ > break in the future, it's simply a matter of time. > > Which makes a big difference when supporting that

Re: [gentoo-dev] "Lazy" use flags?

On 2016-02-09 15:35, Róbert Čerňanský wrote: BTW, what you are describing is essentially the same as in this bug: https://bugs.gentoo.org/show_bug.cgi?id=258371. It was also discussed on this list couple of times. I too would very much like to see it in portage. pkgcore's current resolver has

[gentoo-dev] Re: Changing order of default virtual/udev provider

Mike Frysinger posted on Tue, 09 Feb 2016 14:26:52 -0500 as excerpted: > On 08 Feb 2016 13:46, Michał Górny wrote: >> I'm strongly against this, because: > > agreed. i also don't see any reasons in Patrick's e-mail to suggest the > current default is inadequate. "i don't like upstream" isn't re

Re: [gentoo-dev] python-exec2 C wrapper is looking for a new name!

On Tue, 9 Feb 2016 12:32:38 -0800 Brian Dolbec wrote: > On Tue, 9 Feb 2016 14:53:52 -0500 > Ian Stakenvicius wrote: > > > On 09/02/16 02:51 PM, Michał Górny wrote: > > > Hello, everyone. > > > > > > After all those boring, meaningless and violent mailing list > > > threads, here's something

Re: [gentoo-dev] "Lazy" use flags?

On Wed, 10 Feb 2016 02:19:54 +1300 Kent Fredric wrote: > On 10 February 2016 at 02:14, Daniel Campbell wrote: > > Another concern, though, is it'd result in something similar. > > Instead of "cat/foo bar baz" and later removing 'baz', you'd have > > "cat/foo bar ~baz" (with '~baz' as 'enable thi

Re: [gentoo-dev] python-exec2 C wrapper is looking for a new name!

On Tue, 9 Feb 2016 14:53:52 -0500 Ian Stakenvicius wrote: > On 09/02/16 02:51 PM, Michał Górny wrote: > > Hello, everyone. > > > > After all those boring, meaningless and violent mailing list > > threads, here's something nice and simple. I'd like to find a new > > nice name for the C wrapper pa

Re: [gentoo-dev] python-exec2 C wrapper is looking for a new name!

On 02/09/2016 02:53 PM, Ian Stakenvicius wrote: > > python-exec-cwrapper ? > Elmer Fudd goes to the bathroom? =) python-exec-candy

Re: [gentoo-dev] python-exec2 C wrapper is looking for a new name!

On 09/02/16 02:51 PM, Michał Górny wrote: > Hello, everyone. > > After all those boring, meaningless and violent mailing list threads, > here's something nice and simple. I'd like to find a new nice name for > the C wrapper part of python-exec2, and I would like to ask you for > ideas. > > For so

[gentoo-dev] python-exec2 C wrapper is looking for a new name!

Hello, everyone. After all those boring, meaningless and violent mailing list threads, here's something nice and simple. I'd like to find a new nice name for the C wrapper part of python-exec2, and I would like to ask you for ideas. For some explanation, python-exec2 consists of two wrappers. One

Re: [gentoo-dev] [Fwd: [gentoo-automated-testing] BROKEN: repository became broken!]

On 03 Feb 2016 22:35, Andreas K. Huettel wrote: > Am Dienstag, 2. Februar 2016, 02:33:30 schrieb Mike Frysinger: > > > I took the liberty of doing (2) and reverted the commit. Not sure why > > > this needs so much discussion; after all a broken tree is always > > > suboptimal. > > > > unless thing

Re: [gentoo-dev] abusive behaviour / communications from a user

On 02 Feb 2016 11:14, Ian Delaney wrote: > Members of comrel this is the gentoo-dev list. no idea why you're posting it here. if you want to rope in comrel, then do so on the bug, or file a new bug for them, or e-mail them directly. -mike signature.asc Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 08 Feb 2016 13:46, Michał Górny wrote: > I'm strongly against this, because: agreed. i also don't see any reasons in Patrick's e-mail to suggest the current default is inadequate. "i don't like upstream" isn't relevant. -mike signature.asc Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 2/9/16 7:43 AM, Rich Freeman wrote: > On Tue, Feb 9, 2016 at 7:36 AM, Daniel Campbell wrote: >> >> Given that the push for kdbus is more a political API move than >> anything, I can see eudev sticking to the current interface and >> working just fine. > > I doubt udev is going to make that swi

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Mon, 8 Feb 2016 10:08:22 +0100 Patrick Lauer wrote: > Ohey, > > I've opened a bug at: > https://bugs.gentoo.org/show_bug.cgi?id=573922 > > The idea here is to change the order of the providers of virtual/udev. > For existing installs this has zero impact. > For stage3 this would mean that eu

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Tue, Feb 9, 2016 at 1:25 PM, Alon Bar-Lev wrote: > > I also mask all systemd files that somehow find their way into my > system thanks to your past decisions as systemd supporter, instead of > installing these only when systemd USE flag is set and adding openrc > USE flag for the systemd users

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Tue, Feb 9, 2016 at 12:18 PM, Brian Dolbec wrote: > > Why must it become yet another shouting match. And I'm sorry to have to > tell you this, but you have been leading the charge in that direction. > Fair enough. I'll admit that this has been a lot of venting for me, and an unnecessary dist

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 9 February 2016 at 13:59, Rich Freeman wrote: > > On Tue, Feb 9, 2016 at 12:27 AM, Anthony G. Basile > wrote: > > On 2/8/16 10:09 PM, Rich Freeman wrote: > >> How many of those 14 distros have more than 14 users? > > > > gentoo is very unpopular as a distro. however, it excels as a meta > >

Re: [gentoo-dev] Changing order of default virtual/udev provider

+1, been using eudev since starting with gentoo, in fact, it was one of the prime motivators of trying out gentoo [1]. [1]: using gentoo for about a year now and primary reason for me and about 2 colleagues who switched with me was "a linux distro with enough flexibility to completely avoid system

Re: [gentoo-dev] Changing order of default virtual/udev provider

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/09/2016 02:39 PM, Ulrich Mueller wrote: > [Replying to a more or less random posting of this thread.] > > Maybe it helps to look at the actual dependency in > virtual/udev-217: > > RDEPEND=" !systemd? ( || ( >=sys-fs/udev-217 >=sys-fs/eudev-2

boot loader in @system, was Re: [gentoo-dev] Changing order of default virtual/udev provider

William Hubbs schrieb: A boot loader is also needed for a working system, but we do not > have one in @system. Instead, we direct the user to choose one. Actually it is not strictly necessary to install a separate boot loader. On EFI systems (arm and x86, not ia64 though), the kernel's EFI stu

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Tue, 9 Feb 2016 08:44:03 -0500 Rich Freeman wrote: > I'll admit this has been a bit of an emotional thread for me. I think > my frustration comes from the fact that it seems like the whole reason > that eudev exists is because people really strongly believe that > systemd isn't the right way

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Tue, Feb 09, 2016 at 03:23:15PM +0100, Ulrich Mueller wrote: > > On Tue, 9 Feb 2016, Rich Freeman wrote: > > > Well, if we're going to force it to be in the stage3, I guess this > > boils down to whether eudev or udev is the better nano. > > "Nicht alles was hinkt ist ein Vergleich", as we

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 09/02/16 04:09, Rich Freeman wrote: > On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile wrote: >> >> what does in-house tool mean? i'm a gentoo developer but i also work >> on an upstream project (eudev) that 14 distros use. >> >> some of the criticism given here are my concerns as well and i'

Re: [gentoo-dev] New packages up for grabs

On Sun, Jan 24, 2016 at 3:32 PM, Michał Górny wrote: > Hello, everyone. > > As a result of disbanding a few herds, we some new maintainer-needed > packages. > > Here's the complete list: > ... > app-cdr/burn-cd > ... I will take this one via proxy. This project has been inactive for several year

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Tue, Feb 9, 2016 at 9:44 AM, Daniel Campbell wrote: > > On 02/09/2016 05:44 AM, Rich Freeman wrote: > > If you go with systemd, you have to like or agree with > every change they make or every design decision on everything. There is a bit of irony in suggesting this in a discussion that starte

Re: [gentoo-dev] Hardware database

On Tue, 9 Feb 2016 17:53:09 +0300 agentsmith wrote: > Cool tool i create ebuild. > > On 02/09/2016 05:47 PM, Daniel Campbell wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > Could > > On 02/09/2016 05:55 AM, Urbain YANG wrote: > >> Thank you very much! > >> > >> And wish it

Re: [gentoo-dev] Hardware database

Cool tool i create ebuild. On 02/09/2016 05:47 PM, Daniel Campbell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 05:55 AM, Urbain YANG wrote: Thank you very much! And wish it will be merged into Portage soon. Urbain YANG urbain.y...@qq.com

Re: [gentoo-dev] Hardware database

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 05:55 AM, Urbain YANG wrote: > Thank you very much! > > And wish it will be merged into Portage soon. > > > Urbain YANG urbain.y...@qq.com > > > > >> 在 2016年2月9日，下午9:33，Ponomarenko Andrey >> >

Re: [gentoo-dev] Changing order of default virtual/udev provider

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 05:44 AM, Rich Freeman wrote: > On Tue, Feb 9, 2016 at 8:06 AM, Daniel Campbell > wrote: >> >> Perhaps that's because each of those things should not actually >> be considered the same object type. That sort of design may be >> conven

Re: [gentoo-dev] Changing order of default virtual/udev provider

> On Tue, 9 Feb 2016, Rich Freeman wrote: > Well, if we're going to force it to be in the stage3, I guess this > boils down to whether eudev or udev is the better nano. "Nicht alles was hinkt ist ein Vergleich", as we say in German. Emacs has a flexible extension language, whereas nano uses a

Re: [gentoo-dev] Hardware database

Thank you very much! And wish it will be merged into Portage soon. Urbain YANG urbain.y...@qq.com > 在 2016年2月9日，下午9:33，Ponomarenko Andrey 写道： > > Hello, > > I have released a new version of the hardware probe tool — HW Probe 1.0, that > supports Gentoo and some other popular Linux distri

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Tue, Feb 9, 2016 at 8:39 AM, Ulrich Mueller wrote: > > IMHO, switching the order within the first (i.e. !systemd) USE > conditional would make a lot of sense. Why should we default to the > systemd udev for users that request USE=-systemd in their flags? > Well, if we're going to force it to b

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Tue, Feb 9, 2016 at 8:06 AM, Daniel Campbell wrote: > > Perhaps that's because each of those things should not actually be > considered the same object type. That sort of design may be convenient > to users, but is more akin to treating everything like a nail when you > have a hammer. > > Also

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Replying to a more or less random posting of this thread.] Maybe it helps to look at the actual dependency in virtual/udev-217: RDEPEND=" !systemd? ( || ( >=sys-fs/udev-217 >=sys-fs/eudev-2.1.1 ) ) systemd? ( >=sys-apps/systemd-217:0 )" IMHO, switching the order within the first

[gentoo-dev] Hardware database

Hello, I have released a new version of the hardware probe tool — HW Probe 1.0, that supports Gentoo and some other popular Linux distributions. The "probe" is a snapshot of the hardware state including a list of devices on board and system logs. The primary purpose of the tool is to share the

Re: [gentoo-dev] "Lazy" use flags?

On 10 February 2016 at 02:22, Daniel Campbell wrote: > I can certainly see the benefit here, but wouldn't that still result > in (arguably) unnecessary (re)builds? If implemented well it'd also > result in depcleaning them when they're later unneeded, too, so I > guess it's a wash in that sense.

Re: [gentoo-dev] "Lazy" use flags?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 05:19 AM, Kent Fredric wrote: > On 10 February 2016 at 02:14, Daniel Campbell > wrote: >> Another concern, though, is it'd result in something similar. >> Instead of "cat/foo bar baz" and later removing 'baz', you'd have >> "cat/foo ba

Re: [gentoo-dev] "Lazy" use flags?

On 10 February 2016 at 02:14, Daniel Campbell wrote: > Another concern, though, is it'd result in something similar. Instead > of "cat/foo bar baz" and later removing 'baz', you'd have "cat/foo bar > ~baz" (with '~baz' as 'enable this if you need to'). You'd still have > cruft left in your p.use f

Re: [gentoo-dev] "Lazy" use flags?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 04:27 AM, Kent Fredric wrote: > There's a frequent irritation I experience with the revolving door > of REQUIRED_USE -> auto-unmask: > > There's no mechanism in place to automatically stop using a > "REQUIRED" use flag when it ceases t

Re: [gentoo-dev] Changing order of default virtual/udev provider

2016-02-09 13:17 GMT+01:00 Rich Freeman : > On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric > wrote: > > > > A pure udev system is in comparison, much simpler than a systemd system. > > I don't buy that at all. In systemd you have a unified object model > across device nodes, mountpoints, services,

Re: [gentoo-dev] Changing order of default virtual/udev provider

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 04:17 AM, Rich Freeman wrote: > On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric > wrote: >> >> A pure udev system is in comparison, much simpler than a systemd >> system. > > I don't buy that at all. In systemd you have a unified objec

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Tue, Feb 9, 2016 at 7:36 AM, Daniel Campbell wrote: > > Given that the push for kdbus is more a political API move than > anything, I can see eudev sticking to the current interface and > working just fine. I doubt udev is going to make that switch until kdbus is merged into the kernel. I dou

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Tue, Feb 9, 2016 at 7:14 AM, Anthony G. Basile wrote: > On 2/9/16 6:59 AM, Rich Freeman wrote: >> On Tue, Feb 9, 2016 at 12:27 AM, Anthony G. Basile >> wrote: >>> On 2/8/16 10:09 PM, Rich Freeman wrote: How many of those 14 distros have more than 14 users? >>> >>> gentoo is very unpopula

Re: [gentoo-dev] Changing order of default virtual/udev provider

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 01:03 AM, Kent Fredric wrote: > On 9 February 2016 at 18:27, Anthony G. Basile > wrote: >> all the vitriolic attacks i get about eudev come from the gentoo >> community. outside of this community i get praise. > > > In case my ear

[gentoo-dev] "Lazy" use flags?

There's a frequent irritation I experience with the revolving door of REQUIRED_USE -> auto-unmask: There's no mechanism in place to automatically stop using a "REQUIRED" use flag when it ceases to be necessary. So you find yourself doing things like: - I want X - X only supports python 2.7 - X t

Re: [gentoo-dev] Changing order of default virtual/udev provider

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/08/2016 11:43 PM, waltd...@waltdnes.org wrote: > How difficult would it be to make it an install-time choice, like > the bootloader? Not very. It would need proper documentation, however, and at least indications on limitations or consequences

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric wrote: > > A pure udev system is in comparison, much simpler than a systemd system. I don't buy that at all. In systemd you have a unified object model across device nodes, mountpoints, services, and cron jobs. In the alternate model you have complet

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 2/9/16 6:59 AM, Rich Freeman wrote: > On Tue, Feb 9, 2016 at 12:27 AM, Anthony G. Basile > wrote: >> On 2/8/16 10:09 PM, Rich Freeman wrote: >>> How many of those 14 distros have more than 14 users? >> >> gentoo is very unpopular as a distro. however, it excels as a meta >> distro. if you ma

Re: [gentoo-dev] Changing order of default virtual/udev provider

On Tue, Feb 9, 2016 at 12:27 AM, Anthony G. Basile wrote: > On 2/8/16 10:09 PM, Rich Freeman wrote: >> How many of those 14 distros have more than 14 users? > > gentoo is very unpopular as a distro. however, it excels as a meta > distro. if you marginalize its special features, you take away all

[gentoo-dev] Last rites: java-virtuals/jaxp && dev-java/jax{p,b,-ws,-ws-api,r} && dev-java/jsr93

# Patrice Clement (09 Feb 2016) # Old, ancient, deprecated, obsolete.. so many adjectives could describe these # ebuilds. Let's just say it's about time to kiss them goodbye. # Masked for removal in 30 days. See bug 566232. java-virtuals/jaxp-virtual dev-java/jaxp dev-java/jaxb dev-java/jax-ws dev

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 9 February 2016 at 18:27, Anthony G. Basile wrote: > all the vitriolic attacks i get about eudev come from the gentoo > community. outside of this community i get praise. In case my earlier messages stating a desire to exercise much caution gave the wrong impression, I just want to state fo

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 9 February 2016 at 16:09, Rich Freeman wrote: > There will always be a > "poppyseed linux" whose purpose in life seems to be to preserve linux > without sysfs or some other obscure practice. This seems to be an attempt at painting the "stick with eudev" model as an "old fogies who are afraid

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

On Tue, 9 Feb 2016 07:37:10 +0100 Patrick Lauer wrote: > And now I can't figure out what I need to enable to have "rewrite" > work. Good job! > > The names match the internal module names, which is what I care about. > Figuring out if I need USE="zlib" or USE="compress" or even a combo > is a lo