Re: [gentoo-dev] games.eclass policy

[Michael Sterrett]

On Wed, Feb 17, 2016 at 2:39 AM, Michał Górny  wrote:

> The games team was pretty much formed of two kinds of developers back then. 
> One kind was retired developers, the other kind was developers who did what 
> they cared about and ignored everything and everyone else. Bugs, join 
> requests, complaints, all went ignored and games team kept silent claim to 
> games in gentoo.

False and slanderous.

> So the first Council case against games team was that they did not accept any 
> new members. Or rather, silently ignored join requests. They also ignored 
> inquiries wrt the case and the Council.

Also false.

> The result was that the Council set up someone external to take care of 
> inviting new members, and electing new team lead afterwards. As it could be 
> predicted, nobody wanted to join, or rather be forced into the team they 
> weren't welcome in.

Speculative and false.

> Then the case against policies started. The first abolished myth was games 
> team sole claim to games in gentoo. Where Council pretty much only confirmed 
> that they have no right for that and everyone can maintain game ebuilds 
> without having games team approval or co-maintenance.

Making things up.


> During the whole process, I don't recall a single reply from games team 
> member.

Well, here's at least one.

However, I'm not sure why anyone would reply to your drama, slander,
and lies so I'm not surprised that's been your experience.

Re: [gentoo-dev] games.eclass policy

[Michał Górny]

Dnia 17 lutego 2016 03:09:18 CET, Daniel Campbell  napisał(a):
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>On 02/08/2016 01:49 PM, Michał Górny wrote:
>> 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:
 
> Hello folks.
> 
> While hacking away on a new ebuild I came across the issue
> that games.eclass apparently got banned from future use. The
> only references I was able to dig up (apart from helpful
> people on IRC), were
> https://bugs.gentoo.org/show_bug.cgi?id=566498 (games.eclass:
> use of games group needs to be removed wrt 20151011 Council
> meeting) and 
>
>https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summ
>ar
> 
>>> ies#Games_team_policies_issue
> 
> 
>>> (A mere deprecation notice).
> 
> In contrast, a simple "grep deprec /usr/portage/eclass/"
> gives numerous deprecation warnings; just games.eclass is not
> among them.
> 
> Please provide some guidance how (community-)developers are 
> supposed to handle games (in particular wrt games.eclass) in
> the future. This also includes usage of
> /usr/games/{bin/lib/share} etc.
 
 For reference, this is the reference decision:
 

>https://projects.gentoo.org/council/meeting-logs/20151213-summary.tx
>t


 
>I'm going to open a bug asking games team how they're going to
 proceed.
 
>>> Please let us know when you do; there are a few Humble Bundle
>>> games I'd like to bring to the tree and I, too, don't have much
>>> to go on as far as guidelines beyond our usual.
>> 
>> I'm sorry for replying this late. The relevant bugs are:
>> 
>> https://bugs.gentoo.org/show_bug.cgi?id=566498 for games group 
>> https://bugs.gentoo.org/show_bug.cgi?id=574080 for paths 
>> https://bugs.gentoo.org/show_bug.cgi?id=574082 as tracker for both
>> 
>Thanks for the links. I understand games have been the subject of a
>lot of 'discussion' on the ML over the past few years. What do you
>believe to be some of the main blockers to getting more dev
>participation? From what I gather, a decent portion of us play games
>on our systems, so it seems reasonable to get more maintainership
>spread out. There's a lot of user interest too, as Ian pointed out.

To answer that, we have to go back a while.

The games team was pretty much formed of two kinds of developers back then. One 
kind was retired developers, the other kind was developers who did what they 
cared about and ignored everything and everyone else. Bugs, join requests, 
complaints, all went ignored and games team kept silent claim to games in 
gentoo.

So the first Council case against games team was that they did not accept any 
new members. Or rather, silently ignored join requests. They also ignored 
inquiries wrt the case and the Council.

The result was that the Council set up someone external to take care of 
inviting new members, and electing new team lead afterwards. As it could be 
predicted, nobody wanted to join, or rather be forced into the team they 
weren't welcome in.

Then the case against policies started. The first abolished myth was games team 
sole claim to games in gentoo. Where Council pretty much only confirmed that 
they have no right for that and everyone can maintain game ebuilds without 
having games team approval or co-maintenance.

The remaining cases you already know.

During the whole process, I don't recall a single reply from games team member. 
And in the meantime, they continue their silent routine of doing whatever they 
care about, and ignoring Council requests.

>- -- 
>Daniel Campbell - Gentoo Developer
>OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
>fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2
>
>iQIcBAEBCAAGBQJWw9ZJAAoJEAEkDpRQOeFwoDcP/2rHwIb1ztpkBOzt0UWh4IYr
>fbKHCi+NJ9p5j7alLQyjIarZgYMY5yLvRWaP+pR9PPyjIhAmEGEI1SoGLQC8MhJ2
>fqOUKr+EH2mt8I4U3EGzsLAMA4JXm1yaKmDcFV3RQett4uUD9MWECQUxrLBQ/cME
>F0kPaBziIAZM30+jBoplTISNW7n4L4a/S6smcUV0XR7vGL3P67UQiD1zQ2LvF2Ny
>Yj4NMk3Z79rYzog0mqNKaSPVR45rEpTPz+BSoxqwt2t117GQP01n3WlKdyOecKuH
>KRyJ90pOnmJVRmH3pLYubJwq0mjvv4YYD1HVVWzK5r30kmVbd5rWrwt/RVGnpkGk
>EI8CdKuiQwXeWjb+X1Jo0kEhs2e5dKRmPM4z2xHv7YCkkshO/aOC51iP75yLnnZS
>8pxp/D61Xdbfbjm8l+0oHJdIJ9qm6Oc5UGohcWU4pk/mTHNutWjKaOAT3D+Rtu7/
>ILCajj5QapXgJUqEZ8YleWD0e/7Ft2AvWaNNgalz4717daIHhk/JBE0WDDv1M3Pe
>+KT4pC9zToAZelwOnQGLZLyccbyLpgqrwsYArgsqBV3uTwgYRCTqEbBDZAx2m994
>0RyxIgF201hsGKp6yIS9X2nQEgZwFrM3XWDckydiQhpFi6ZMxbWsdKZJxVOUVOEf
>JAF0lamHDp2Em+rjKLU7
>=/tsU
>-END PGP SIGNATURE-


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] Re: RFC: intel-sdp-r1.eclass

[Michał Górny]

On Tue, 16 Feb 2016 22:48:08 -0600
Ryan Hill  wrote:

> On Mon, 15 Feb 2016 15:35:12 +0100
> Michał Górny  wrote:
> > On Mon, 15 Feb 2016 14:37:41 +0100
> > "Justin Lecher (jlec)"  wrote:  
> > > On 15/02/16 13:59, Michał Górny wrote:
> > > > On Mon, 15 Feb 2016 09:16:53 +0100
> > > > "Justin Lecher (jlec)"  wrote:  
> > > >> _isdp_big-warning() {
> > > >>debug-print-function ${FUNCNAME} "${@}"
> > > >>case ${1} in
> > > >>pre-check )
> > > >>echo ""  
> > > > Don't mix echo with ewarn.  
> > > Why?
> > Because they won't go through the same output channels.  
> 
> That's kinda the point.  You want a blank (unstarred) space
> to separate out the "important" messages from the generic
> spew put out by the package manager/eclasses/build system
> that you have no control over.

This is not just that. Different output channels mean that:

- some of them can be turned off. In this case, you end up with empty
  lines and no message.

- There is no guarantee of correct output order! The empty lines may
  move randomly over the text.

- When the function happens to be used in $(), part of the output will
  be collected (not that it's 100% valid concern right now because
  EAPI 6 doesn't guarantee e* using stderr yet).

> If you have several different messages you want a blank space
> in between them so you can use e* to create whitespace within
> the message to avoid the wall of text syndrome while still
> making it clear where it begins and ends.
> 
> Let's take openrc for example (not picking on anyone, it's just
> the last package with a bunch of different post-install messages
> I happened to emerge).
> 
> Currently:
> 
>  * The OpenRC dependency data has already been migrated.
>  * Caching service dependencies ... [ ok ]
>  * In this version of OpenRC, the loopback interface no longer
>  * satisfies the net virtual.
>  * If you have services now which do not start because of this,
>  * They can be fixed by adding rc_need="!net"
>  * to the /etc/conf.d/ file.
>  * You should also file a bug against the service asking that
>  * need net be dropped from the dependencies.
>  * The bug you file should block the following tracker:
>  * https://bugs.gentoo.org/show_bug.cgi?id=439092
>  * 
>  * Bug https://bugs.gentoo.org/show_bug.cgi?id=427996 was not
>  * fixed correctly in earlier versions of OpenRC.
>  * The correct fix is implemented in this version, but that
>  * means netmount needs to be added to the default runlevel if
>  * you are using nfs file systems.
>  * 
>  * You should now update all files in /etc, using etc-update
>  * or equivalent before restarting any services or this host.
> 
> This is pretty much unreadable to me.
> 
> Better:
> 
>  * The OpenRC dependency data has already been migrated.
>  * Caching service dependencies ... [ ok ]
>  *
>  * In this version of OpenRC, the loopback interface no longer
>  * satisfies the net virtual.
>  *
>  * If you have services now which do not start because of this,
>  * They can be fixed by adding rc_need="!net"
>  * to the /etc/conf.d/ file.
>  *
>  * You should also file a bug against the service asking that
>  * need net be dropped from the dependencies.
>  *
>  * The bug you file should block the following tracker:
>  * https://bugs.gentoo.org/show_bug.cgi?id=439092
>  * 
>  * Bug https://bugs.gentoo.org/show_bug.cgi?id=427996 was not
>  * fixed correctly in earlier versions of OpenRC.
>  *
>  * The correct fix is implemented in this version, but that
>  * means netmount needs to be added to the default runlevel if
>  * you are using nfs file systems.
>  * 
>  * You should now update all files in /etc, using etc-update
>  * or equivalent before restarting any services or this host.
> 
> This is better but you still have to read the whole thing to
> make sure you didn't miss anything important.
> 
> Even better:
> 
>  * The OpenRC dependency data has already been migrated.
>  * Caching service dependencies ... [ ok ]
> 
>  * In this version of OpenRC, the loopback interface no longer
>  * satisfies the net virtual.
>  *
>  * If you have services now which do not start because of this,
>  * They can be fixed by adding rc_need="!net"
>  * to the /etc/conf.d/ file.
>  *
>  * You should also file a bug against the service asking that
>  * need net be dropped from the dependencies.
>  * The bug you file should block the following tracker:
>  *
>  * https://bugs.gentoo.org/show_bug.cgi?id=439092
>  
>  * Bug https://bugs.gentoo.org/show_bug.cgi?id=427996 was not
>  * fixed correctly in earlier versions of OpenRC.
>  *
>  * The correct fix is implemented in this version, but that
>  * means netmount needs to be added to the default runlevel if
>  * you are using nfs file systems.
>  
>  * You should now update all files in /etc, using etc-update
>  * or equivalent before restarting any services or this host.
> 
> Here I 

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

[Michał Górny]

On Tue, 16 Feb 2016 21:54:31 -0500
Richard Yao  wrote:

> On 02/08/2016 07:46 AM, Michał Górny wrote:
> > 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 eudev is pulled in instead of udev.
> >>
> >> The rationale behind this is:
> >>
> >> * eudev is an in-house fork, and there's more than a dozen distros
> >> already using it by default that are not us. Which is a little bit weird 
> >> ...  
> > 
> > That's not an argument. I can also fork random system components. Would
> > you consider that a reason to replace the defaults with our 'in-house'
> > forks?
> >   
> >> * Both udev and eudev have pretty much feature parity, so there won't be
> >> any user-visible changes
> >>
> >> * udev upstream strongly discourages standalone udev (without systemd)
> >> since at least 2012
> >>
> >> (see for example:
> >> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
> >> https://lkml.org/lkml/2012/10/3/618
> >> )
> >>
> >> So it'd be (1) following upstreams recommendations and (2) dogfooding
> >> our own tools. I don't see any downsides to this :)  
> > 
> > I'm strongly against this, because:
> > 
> > 1. It is a conflict-induced fork. As such, it will never be merged
> > upstream and it will never be supported upstream. In fact, it is
> > continually forces to follow upstream changes and adapt to them. eudev
> > is more likely to break because of the Gentoo developer(s) working hard
> > to merge upstream changes to their incompatible code.  
> 
> That was the entire point of the project. Upstream rejected any attempts
> to do things that we actually needed and broke things claiming the
> distributions were responsible for handling the breakage, so eudev was
> started on the basis that we needed a project that would ensure that
> changes in udev occur in a way that makes sense.

What things? Things like 'let's try to spawn this script third time in
case someone mounted something so that it happens to work this time'?
Yes, that old behavior really made sense.

> > 2. Many of Gentoo users are programmers who appreciate the 'vanilla'
> > API experience Gentoo often provides. Switching the defaults to a fork
> > that is known to intentionally diverge from upstream goes against that
> > principle. Programs written against eudev may not work correctly with
> > upstream udev.  
> 
> If upstream udev were stable, that would be one thing, but it
> intentionally diverges from itself continuously. The only experience
> that could be reliably provided with upstream udev is one of continual
> breakage.

This is FUD, without any proof.

> 
> > 3. eudev has fallen behind systemd/udev more than once in the past,
> > and caused visible breakage to users this way.  
> 
> When?

Whenever we installed new systemd and udev versions, and needed to bump
the dependency in virtual, and eudev maintainers were nowhere to be
found.

> Can we also consider all of the times udev broke the boot process
> because upstream just didn't care about doing changes in a sane way and
> the people interested in providing the upstream experience delivered on
> that goal?

Proof needed.

> > 4. eudev is underdocumented, and the maintainer admits that 'he sucks
> > at documenting'. In fact, did anyone even bother to note how far eudev
> > diverges from upstream udev to this point?  
> 
> The FreeBSD developers were complaining about how poorly documented udev
> was well before eudev existed. This is not a regression unless systemd's
> innovations in replacing documented things with undocumented things made
> them worse.

So... replacing thing that has some docs with a thing that has no docs
and links to docs of udev that aren't exact match for eudev is good?
Good to know.

-- 
Best regards,
Michał Górny



pgpcEYu26Ye6V.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: rfc: supervise-daemon -- a lightweight openrc daemon supervisor

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/16/2016 07:49 PM, Duncan wrote:
> James Le Cuirot posted on Tue, 16 Feb 2016 22:19:44 + as
> excerpted:
> 
>> Oh, that's cool! Now I come to think of it, I believe it was this
>> effort that made me aware of s6 in the first place but I'd
>> forgotten about it since. Now I feel dumb.
> 
> Umm... I think there was supposed to be a break, here...
> 
>> As you were then. You're doing great work and we're clearly
>> spoilt for choice. :)
> 
> ... because as it was written, it appeared to be...
> 
> "Now I feel dumb.  As you were [dumb] then."
> 
> Which is how I originally read it, but it'd didn't seem to make any
> sense at all given the context, so I had to go back and figure out
> where my parsing went wrong, and decided it was a missing break.
> 
> Just in case anyone else reads that wrong, as I did initially. 
> Unfortunately, I write things that end up reading totally not the
> way I intended too, from time to time.  I /hate/ it when that
> happens! =:^(
> 
> ... Unless of course a sneaky insult was actually intended! ;^)
> 
IMO you're over-thinking it. I read it as "As you were, then", which
is a common saying in the (American, at least) military advising one
to keep doing what they're doing, or return to a resting position. :)

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWxBOUAAoJEAEkDpRQOeFwNDAP/3GTnfW0NJBBICGu1Pvs+VjY
InWnxC+qvfkZQ7B1VXCdoUs/9WxdoCC7h+jFxkinVPkYDRntDq0DB2VxoEfiFLwl
EAOCiSEu7IH3QLW95sWuWRkOQkuIiiE5nHjHj/DYNlTxpG/BceKPrgGRNRoNczhV
tG+UGC/BfzILMdqv58H06eQzAC7ym1zyRvwoMOMfTucOa52zYvTXIhg8/P5fJn2Z
o5VqM60N2Ri+06q3ttc9cC3v6KdWzYUdXPU9tZLr/vQrKwZMeIARG2zRoM9CCy61
BtaL06cALkZy9ROifj7VvdkFSAcMkGb+SgqyLVsJ9ejOxUf4xzA75QjBF4j6x4TP
A0vIHxDHgJJLDzYJcbkJu/IJ4S1VPv1Rga9fw3Ji9FIKv5SPIxpNkM9WvOr6zsCu
VelKC5hDFPQ1tTKOLT7k+Q72pPoFEJv3xABsokWUdgQp81zk7b1Bhgv0YsZ6e1Py
Q0lNS6eOmt0Z4HccSRU3hm00qcJmwZ96kx+q+ix/lfBawpgqj2xGcn96nOdfsqUu
tQNo5i3GJt0InSGWXRr2gTjeY9j4A+PSDpfqtbtaaDos8WyqduHmh/YWKZ6tUFVW
1qvD5qDwC7NokQNBVHYE8cQnKAkB5VlE9un+6xYKE0B3p8Zo5RPjdEgGit5QKqqn
h8tP7v5KUpKICIPnZ95/
=O3dl
-END PGP SIGNATURE-

[gentoo-dev] Re: RFC: intel-sdp-r1.eclass

[Ryan Hill]

On Mon, 15 Feb 2016 15:35:12 +0100
Michał Górny  wrote:
> On Mon, 15 Feb 2016 14:37:41 +0100
> "Justin Lecher (jlec)"  wrote:
> > On 15/02/16 13:59, Michał Górny wrote:  
> > > On Mon, 15 Feb 2016 09:16:53 +0100
> > > "Justin Lecher (jlec)"  wrote:
> > >> _isdp_big-warning() {
> > >>  debug-print-function ${FUNCNAME} "${@}"
> > >>  case ${1} in
> > >>  pre-check )
> > >>  echo ""
> > > Don't mix echo with ewarn.
> > Why?  
> Because they won't go through the same output channels.

That's kinda the point.  You want a blank (unstarred) space
to separate out the "important" messages from the generic
spew put out by the package manager/eclasses/build system
that you have no control over.

If you have several different messages you want a blank space
in between them so you can use e* to create whitespace within
the message to avoid the wall of text syndrome while still
making it clear where it begins and ends.

Let's take openrc for example (not picking on anyone, it's just
the last package with a bunch of different post-install messages
I happened to emerge).

Currently:

 * The OpenRC dependency data has already been migrated.
 * Caching service dependencies ... [ ok ]
 * In this version of OpenRC, the loopback interface no longer
 * satisfies the net virtual.
 * If you have services now which do not start because of this,
 * They can be fixed by adding rc_need="!net"
 * to the /etc/conf.d/ file.
 * You should also file a bug against the service asking that
 * need net be dropped from the dependencies.
 * The bug you file should block the following tracker:
 * https://bugs.gentoo.org/show_bug.cgi?id=439092
 * 
 * Bug https://bugs.gentoo.org/show_bug.cgi?id=427996 was not
 * fixed correctly in earlier versions of OpenRC.
 * The correct fix is implemented in this version, but that
 * means netmount needs to be added to the default runlevel if
 * you are using nfs file systems.
 * 
 * You should now update all files in /etc, using etc-update
 * or equivalent before restarting any services or this host.

This is pretty much unreadable to me.

Better:

 * The OpenRC dependency data has already been migrated.
 * Caching service dependencies ... [ ok ]
 *
 * In this version of OpenRC, the loopback interface no longer
 * satisfies the net virtual.
 *
 * If you have services now which do not start because of this,
 * They can be fixed by adding rc_need="!net"
 * to the /etc/conf.d/ file.
 *
 * You should also file a bug against the service asking that
 * need net be dropped from the dependencies.
 *
 * The bug you file should block the following tracker:
 * https://bugs.gentoo.org/show_bug.cgi?id=439092
 * 
 * Bug https://bugs.gentoo.org/show_bug.cgi?id=427996 was not
 * fixed correctly in earlier versions of OpenRC.
 *
 * The correct fix is implemented in this version, but that
 * means netmount needs to be added to the default runlevel if
 * you are using nfs file systems.
 * 
 * You should now update all files in /etc, using etc-update
 * or equivalent before restarting any services or this host.

This is better but you still have to read the whole thing to
make sure you didn't miss anything important.

Even better:

 * The OpenRC dependency data has already been migrated.
 * Caching service dependencies ... [ ok ]

 * In this version of OpenRC, the loopback interface no longer
 * satisfies the net virtual.
 *
 * If you have services now which do not start because of this,
 * They can be fixed by adding rc_need="!net"
 * to the /etc/conf.d/ file.
 *
 * You should also file a bug against the service asking that
 * need net be dropped from the dependencies.
 * The bug you file should block the following tracker:
 *
 * https://bugs.gentoo.org/show_bug.cgi?id=439092
 
 * Bug https://bugs.gentoo.org/show_bug.cgi?id=427996 was not
 * fixed correctly in earlier versions of OpenRC.
 *
 * The correct fix is implemented in this version, but that
 * means netmount needs to be added to the default runlevel if
 * you are using nfs file systems.
 
 * You should now update all files in /etc, using etc-update
 * or equivalent before restarting any services or this host.

Here I can read the first line of the second block and know I can
skip the next 12 lines without missing anything.  The next block
isn't worded the greatest, but that's beside the point.  And now
I get an important message at the end that I previously never 
noticed because tl;dr.

You're right that using echo means the whitespace doesn't get
saved by the elog system.  A while back someone proposed we
add espace for exactly this reason but IIRC they were laughed
down, which is a shame.

-- 


pgpywRVygQn7V.pgp
Description: OpenPGP digital signature

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

[Duncan]

Michał Górny posted on Tue, 16 Feb 2016 23:16:41 +0100 as excerpted:

> On Tue, 16 Feb 2016 20:57:31 +0100 Patrick Lauer 
> wrote:
> 
>> On 02/16/2016 08:33 PM, Michał Górny wrote:
>> > This all is going into some bickering nonsense and noise made by
>> > systemd haters just to feed their troll, FUD and whatever else they
>> > made around here.
>> You call it hate, I call it having a choice.
> 
> You have a choice. This is trying to force your choice on everyone else
> just because you hate the other option and don't want anybody to be
> using it.

Who's forcing who's choice?  It's a virtual default, where virtuals are 
/designed/ to allow choice.

And as a systemd user myself, the only one I see trying to force a 
particular choice is systemd and its devs, which as they've made very 
clear, would prefer to be the only possibility on Linux, no choice 
available but to switch to some other non-Linux (or at least non-Gnu/
Linux) platform.

Meanwhile, systemd users already don't have a choice and thus aren't 
affected by the virtual default except at installation, and switching 
from udev or eudev to systemd, six of one, a half dozen of the other.

So what's the problem if non-systemd users decide to set a designed-to-be-
stand-alone package as the default device-manager, instead of an 
explicitly intended to be systemd-only package as a device-manager, using 
it apart from systemd in a way not intended and actively discouraged by 
its developers.  For non-systemd users, that would seem to be only 
logical, and systemd users have had that choice taken from them by 
systemd and thus don't have a choice to make, so what's the problem?

Again, that's as a systemd user myself.  You can't, at least not 
correctly, claim systemd hate here.  I'm simply a realist, using what 
seems to me to be the best tool for the job, which happens to be systemd 
currently, but I would sure like to keep the choice around as insurance 
against a dramatic turn for the worse, as unfortunately, I've seen happen 
too many times in my computer experience, Linux and otherwise.  (No need 
to enumerate details here.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Richard Yao]

On 02/08/2016 10:09 PM, 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've
>> spoken with the various distros --- slack, parted magic, puppy.  they
>> get what's going on and they still see eudev is the best way forward
>> for now.  it may not be in the future, but neither will a udev
>> extracted from a compiled full systemd codebase.
>
> How many of those 14 distros have more than 14 users?
>
> Look, I get it, some people don't like systemd.  That's fine.
> However, you have to realize at this point that a non-systemd
> configuration is anything but mainstream.  There will always be a
> "poppyseed linux" whose purpose in life seems to be to preserve linux
> without sysfs or some other obscure practice.  I just think that
> Gentoo should offer the choice to do those things, but have a more
> mainstream set of defaults.

The new mainstream is docker. Docker recently switched to Alpine Linux,
which uses OpenRC+eudev:

https://www.brianchristner.io/docker-is-moving-to-alpine-linux/

That dwarfs whatever marketshare systemd has in the same way that
Android+iOS dwarfed whatever marketshare Windows has.

If userbase is what matters to you, then OpenRC+eudev won. It is the
logical choice for those concerned about userbase because that is what
the Linux ecosystem will be using going forward.

I do not think userbase should be the sole means by which we make
decisions, but those that think otherwise should now join the
eudev+OpenRC camp. It has the bigger userbase share going forward.

To put it another way, the war is over. Welcome abroad. :)

>>
>> it needs to be in the new stage4s to make a bootable system.  imo a
>> stage4 should be bootable modulo a kernel.
>>
>
> Sure, a stage4 based on systemd makes a lot of sense.  I don't really
> see the point in leaving a kernel out though - I'd even stick a
> precompiled one in /boot on top of having the sources installed.  Why
> not make a stage4 install something that takes all of 5 minutes?
>
> I think that offering an eudev-based distro as a default just doesn't
> make sense in 2016.  I just think the better road to take is to start
> treating virtual/udev as something that gets installed post-stage3.
> We can't even get people to agree on vi vs emacs as a default.

We can leave virtual/udev out of stage3, but that doesn't diminish the
need to select sensible default for the virtual/udev provider.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: rfc: supervise-daemon -- a lightweight openrc daemon supervisor

[Duncan]

James Le Cuirot posted on Tue, 16 Feb 2016 22:19:44 + as excerpted:

> Oh, that's cool! Now I come to think of it, I believe it was this effort
> that made me aware of s6 in the first place but I'd forgotten about it
> since. Now I feel dumb.

Umm... I think there was supposed to be a break, here...

> As you were then. You're doing great work and
> we're clearly spoilt for choice. :)

... because as it was written, it appeared to be...

"Now I feel dumb.  As you were [dumb] then."

Which is how I originally read it, but it'd didn't seem to make any sense 
at all given the context, so I had to go back and figure out where my 
parsing went wrong, and decided it was a missing break.

Just in case anyone else reads that wrong, as I did initially.  
Unfortunately, I write things that end up reading totally not the way I 
intended too, from time to time.  I /hate/ it when that happens! =:^(

... Unless of course a sneaky insult was actually intended! ;^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Richard Yao]

On 02/08/2016 07:46 AM, Michał Górny wrote:
> 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 eudev is pulled in instead of udev.
>>
>> The rationale behind this is:
>>
>> * eudev is an in-house fork, and there's more than a dozen distros
>> already using it by default that are not us. Which is a little bit weird ...
> 
> That's not an argument. I can also fork random system components. Would
> you consider that a reason to replace the defaults with our 'in-house'
> forks?
> 
>> * Both udev and eudev have pretty much feature parity, so there won't be
>> any user-visible changes
>>
>> * udev upstream strongly discourages standalone udev (without systemd)
>> since at least 2012
>>
>> (see for example:
>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
>> https://lkml.org/lkml/2012/10/3/618
>> )
>>
>> So it'd be (1) following upstreams recommendations and (2) dogfooding
>> our own tools. I don't see any downsides to this :)
> 
> I'm strongly against this, because:
> 
> 1. It is a conflict-induced fork. As such, it will never be merged
> upstream and it will never be supported upstream. In fact, it is
> continually forces to follow upstream changes and adapt to them. eudev
> is more likely to break because of the Gentoo developer(s) working hard
> to merge upstream changes to their incompatible code.

That was the entire point of the project. Upstream rejected any attempts
to do things that we actually needed and broke things claiming the
distributions were responsible for handling the breakage, so eudev was
started on the basis that we needed a project that would ensure that
changes in udev occur in a way that makes sense.

> 2. Many of Gentoo users are programmers who appreciate the 'vanilla'
> API experience Gentoo often provides. Switching the defaults to a fork
> that is known to intentionally diverge from upstream goes against that
> principle. Programs written against eudev may not work correctly with
> upstream udev.

If upstream udev were stable, that would be one thing, but it
intentionally diverges from itself continuously. The only experience
that could be reliably provided with upstream udev is one of continual
breakage.

> 3. eudev has fallen behind systemd/udev more than once in the past,
> and caused visible breakage to users this way.

When?

Can we also consider all of the times udev broke the boot process
because upstream just didn't care about doing changes in a sane way and
the people interested in providing the upstream experience delivered on
that goal?

> 4. eudev is underdocumented, and the maintainer admits that 'he sucks
> at documenting'. In fact, did anyone even bother to note how far eudev
> diverges from upstream udev to this point?

The FreeBSD developers were complaining about how poorly documented udev
was well before eudev existed. This is not a regression unless systemd's
innovations in replacing documented things with undocumented things made
them worse.



signature.asc
Description: OpenPGP digital signature

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

[Richard Yao]

On 02/08/2016 04:08 AM, 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 eudev is pulled in instead of udev.
> 
> The rationale behind this is:
> 
> * eudev is an in-house fork, and there's more than a dozen distros
> already using it by default that are not us. Which is a little bit weird ...
> 
> * Both udev and eudev have pretty much feature parity, so there won't be
> any user-visible changes
> 
> * udev upstream strongly discourages standalone udev (without systemd)
> since at least 2012
> 
> (see for example:
> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
> https://lkml.org/lkml/2012/10/3/618
> )
> 
> So it'd be (1) following upstreams recommendations and (2) dogfooding
> our own tools. I don't see any downsides to this :)
> 

+1



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: rfc: Does OpenRC really need mount-ro

[Duncan]

William Hubbs posted on Tue, 16 Feb 2016 12:41:29 -0600 as excerpted:

> What I'm trying to figure out is, what to do about re-mounting file
> systems read-only.
> 
> How does systemd do this? I didn't find an equivalent of the mount-ro
> service there.

For quite some time now, systemd has actually had a mechanism whereby the 
main systemd process reexecs (with a pivot-root) the initr* systemd and 
returns control to it during the shutdown process, thereby allowing a 
more controlled shutdown than traditional init systems because the final 
stages are actually running from the virtual-filesystem of the initr*, 
such that after everything running on the main root is shutdown, the main 
root itself can actually be unmounted, not just mounted read-only, 
because there is literally nothing running on it any longer.

There's still a fallback to read-only mounting if an initr* isn't used or 
if reinvoking the initr* version fails for some reason, but with an 
initr*, when everything's working properly, while there are still some 
bits of userspace running, they're no longer actually running off of the 
main root, so main root can actually be unmounted much like any other 
filesystem.

The process is explained a bit better in the copious blogposted systemd 
documentation.  Let's see if I can find a link...

OK, this isn't where I originally read about it, which IIRC was aimed 
more at admins, while this is aimed at initr* devs, but that's probably a 
good thing as it includes more specific detail...

https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/

And here's some more, this time in the storage daemon controlled root and 
initr* context...

https://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/


But... all that doesn't answer the original question directly, does it?  
Where there's no return to initr*, how /does/ systemd handle read-only 
mounting?

First, the nice ascii-diagram flow charts in the bootup (7) manpage may 
be useful, in particular here, the shutdown diagram (tho IDK if you can 
find such things useful or not??).

https://www.freedesktop.org/software/systemd/man/bootup.html

Here's the shutdown diagram described in words:

Initial shutdown is via two targets (as opposed to specific services), 
shutdown.target, which conflicts with all (normal) system services 
thereby shutting them down, and umount.target, which conflicts with file 
mounts, swaps, cryptsetup device, etc.  Here, we're obviously interested 
in umount.target.  Then after those two targets are reached, various low 
level services are run or stopped, in ordered to reach final.target.  
After final.target, the appropriate systemd-(reboot|poweroff|halt|kexec) 
service is run, to hit the ultimate (reboot|poweroff|halt|kexec).target, 
which of course is never actually evaluated, since the service actually 
does the intended action.

The primary takeaway is that you might not be finding a specific systemd 
remount-ro service, because it might be a target, defined in terms of 
conflicts with mount units, etc, rather than a specific service.

Neither shutdown.target nor umount.target have any wants or requires by 
default, but the various normal services and mount units conflict with 
them, either via default or specifically, so are shut down before the 
target can be reached.

final.target has the After=shutdown.target umount.target setting, so 
won't be reached until they are reached.

The respective (reboot|poweroff|halt|kexec).target units Requires= and 
After= their respective systemd-*.service units, and reboot and poweroff 
(but not halt and kexec) have 30-minute timeouts after which they run 
reboot-force or poweroff-force, respectively.

The respective systemd-(reboot|poweroff|halt|kexec).service units 
Requires= and After= shutdown.target, umount.target and final.target, all 
three, so won't be run until those complete.  They simply 
ExecStart=/usr/bin/systemctl --force their respective actions.

And here's what the systemd.special (7) manpage says about umount.target:

  umount.target
A special target unit that umounts all mount and automount points
on system shutdown.

Mounts that shall be unmounted on system shutdown shall add
Conflicts dependencies to this unit for their mount unit,
which is implicitly done when DefaultDependencies=yes is set
(the default).

But that /still/ doesn't reveal what actually does the remount-ro, as 
opposed to umount.  I don't see that either, at the unit level, nor do I 
see anything related to it in for instance my auto-generated from fstab 
/run/systemd/generators/-.mount file or in the systemd-fstab-generator 
(8) manpage.

Thus I must conclude that it's actually resolved in the mount-unit 
conflicts handling in systemd's source code, itself.

And indeed... in systemd's tarball, we see in src/core/umount.c, in 
mount_points_list_umount...

That the function actually remounts /everything/ (well, everything not in 
a container) read-only, 

Re: [gentoo-dev] games.eclass policy

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/08/2016 01:49 PM, Michał Górny wrote:
> 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:
>>> 
 Hello folks.
 
 While hacking away on a new ebuild I came across the issue
 that games.eclass apparently got banned from future use. The
 only references I was able to dig up (apart from helpful
 people on IRC), were
 https://bugs.gentoo.org/show_bug.cgi?id=566498 (games.eclass:
 use of games group needs to be removed wrt 20151011 Council
 meeting) and 
 https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summ
ar
 
>> ies#Games_team_policies_issue
 
 
>> (A mere deprecation notice).
 
 In contrast, a simple "grep deprec /usr/portage/eclass/"
 gives numerous deprecation warnings; just games.eclass is not
 among them.
 
 Please provide some guidance how (community-)developers are 
 supposed to handle games (in particular wrt games.eclass) in
 the future. This also includes usage of
 /usr/games/{bin/lib/share} etc.
>>> 
>>> For reference, this is the reference decision:
>>> 
>>> https://projects.gentoo.org/council/meeting-logs/20151213-summary.tx
t
>>>
>>>
>>> 
I'm going to open a bug asking games team how they're going to
>>> proceed.
>>> 
>> Please let us know when you do; there are a few Humble Bundle
>> games I'd like to bring to the tree and I, too, don't have much
>> to go on as far as guidelines beyond our usual.
> 
> I'm sorry for replying this late. The relevant bugs are:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=566498 for games group 
> https://bugs.gentoo.org/show_bug.cgi?id=574080 for paths 
> https://bugs.gentoo.org/show_bug.cgi?id=574082 as tracker for both
> 
Thanks for the links. I understand games have been the subject of a
lot of 'discussion' on the ML over the past few years. What do you
believe to be some of the main blockers to getting more dev
participation? From what I gather, a decent portion of us play games
on our systems, so it seems reasonable to get more maintainership
spread out. There's a lot of user interest too, as Ian pointed out.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWw9ZJAAoJEAEkDpRQOeFwoDcP/2rHwIb1ztpkBOzt0UWh4IYr
fbKHCi+NJ9p5j7alLQyjIarZgYMY5yLvRWaP+pR9PPyjIhAmEGEI1SoGLQC8MhJ2
fqOUKr+EH2mt8I4U3EGzsLAMA4JXm1yaKmDcFV3RQett4uUD9MWECQUxrLBQ/cME
F0kPaBziIAZM30+jBoplTISNW7n4L4a/S6smcUV0XR7vGL3P67UQiD1zQ2LvF2Ny
Yj4NMk3Z79rYzog0mqNKaSPVR45rEpTPz+BSoxqwt2t117GQP01n3WlKdyOecKuH
KRyJ90pOnmJVRmH3pLYubJwq0mjvv4YYD1HVVWzK5r30kmVbd5rWrwt/RVGnpkGk
EI8CdKuiQwXeWjb+X1Jo0kEhs2e5dKRmPM4z2xHv7YCkkshO/aOC51iP75yLnnZS
8pxp/D61Xdbfbjm8l+0oHJdIJ9qm6Oc5UGohcWU4pk/mTHNutWjKaOAT3D+Rtu7/
ILCajj5QapXgJUqEZ8YleWD0e/7Ft2AvWaNNgalz4717daIHhk/JBE0WDDv1M3Pe
+KT4pC9zToAZelwOnQGLZLyccbyLpgqrwsYArgsqBV3uTwgYRCTqEbBDZAx2m994
0RyxIgF201hsGKp6yIS9X2nQEgZwFrM3XWDckydiQhpFi6ZMxbWsdKZJxVOUVOEf
JAF0lamHDp2Em+rjKLU7
=/tsU
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Uncoordinated changes

[Rich Freeman]

On Tue, Feb 16, 2016 at 5:55 PM, Ryan Hill  wrote:
> On Sun, 14 Feb 2016 10:58:10 -0500
> Rich Freeman  wrote:
>
>> Well, if debugging is your only concern, on the system you're going to
>> debug from:
>> touch herds.xml
>
> Don't do that.
>
> rhill@tundra /usr/portage/dev-util/creduce $ repoman
>
> RepoMan scours the neighborhood...
> [INFO] checking package dev-util/creduce
> Traceback (most recent call last):

See, you're uncovering bugs already.  :)

I wasn't really serious.  The suggestion was to stick an empty
herds.xml in the tree, and my point was that anybody can basically do
that already.

-- 
Rich

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

[Brian Dolbec]

On Tue, 16 Feb 2016 23:16:41 +0100
Michał Górny  wrote:

> On Tue, 16 Feb 2016 20:57:31 +0100
> Patrick Lauer  wrote:
> 
> > On 02/16/2016 08:33 PM, Michał Górny wrote:  
> > > This all is going into some bickering nonsense and noise made by
> > > systemd haters just to feed their troll, FUD and whatever else
> > > they made around here.
> > You call it hate, I call it having a choice.  
> 
> You have a choice. This is trying to force your choice on everyone
> else just because you hate the other option and don't want anybody to
> be using it.
>

NOT EVERYONE, just make it the non-systemd default, htere is still
choice to change to to whatever...

> > >  Because certainly
> > > project that is created plainly for political reasons is better.
> > > Because it will certainly be technically better if people have to
> > > focus on copying regular udev maintainers and reworking their
> > > changes to keep them working on forked codebase.
> > >
> > > And after all, as someone said, this will give eudev proper
> > > testing.
> > (1) It's already used by lots of people
> > (2) 'proper' testing? As opposed to be the default in more than a
> > dozen distros that have usecases you and I rarely think of?  
> 
> Are you really serious with those fringe distros? How many of them
> have a dozen users that do not happen to be developers of the distro?
> How many of them are actually used in production? How many of them
> have diverse enough userbase to prove that eudev works in different
> environments?


Now you are starting to spout incomplete truths from being riled up,
not thinking things through.

Since you consider them to be just a dozen or so...

In the 8 months where I am working now, they use eudev for all their
installs.  This includes more than 50 different server profiles and
resulting images.  Those are multiplied out into multiple instances in
each rack and server clusters distributed in many places around the
world.

So a real world example puts it over a 1000 units (guesstimate) in daily
production. Plus several hundred more on the development and
testing clusters. Plus several hundred (minimum) workstation and
developer vms.

In that 8 months in the release engineering team, I've not seen one
email or bug report that has been due to a problem with eudev.  If
there were I did not see it pass thru the group communications channels.


So, there are lots more eudev users out there than the few dozen you
seem to intimate to.


Can we please put an end to this thread!  ONE WAY OR THE OTHER!!!
-- 
Brian Dolbec 



pgpFDfuOoylwW.pgp
Description: OpenPGP digital signature

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

[Alexis Ballier]

On Tue, 16 Feb 2016 23:16:41 +0100
Michał Górny  wrote:
> > >  Because certainly
> > > project that is created plainly for political reasons is better.
> > > Because it will certainly be technically better if people have to
> > > focus on copying regular udev maintainers and reworking their
> > > changes to keep them working on forked codebase.
> > >
> > > And after all, as someone said, this will give eudev proper
> > > testing.
> > (1) It's already used by lots of people
> > (2) 'proper' testing? As opposed to be the default in more than a
> > dozen distros that have usecases you and I rarely think of?  
> 
> Are you really serious with those fringe distros? How many of them
> have a dozen users that do not happen to be developers of the distro?
> How many of them are actually used in production? How many of them
> have diverse enough userbase to prove that eudev works in different
> environments?


by that type of argument, we should really all be using android :)

[gentoo-dev] Re: Uncoordinated changes

[Ryan Hill]

On Sun, 14 Feb 2016 10:58:10 -0500
Rich Freeman  wrote:

> Well, if debugging is your only concern, on the system you're going to
> debug from:
> touch herds.xml

Don't do that.

rhill@tundra /usr/portage/dev-util/creduce $ repoman

RepoMan scours the neighborhood...
[INFO] checking package dev-util/creduce
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.4/repoman", line 37, in 
repoman_main(sys.argv[1:])
  File "/usr/lib64/python3.4/site-packages/repoman/main.py", line 104, in
repoman_main qatracker, can_force = scanner.scan_pkgs(can_force)
  File "/usr/lib64/python3.4/site-packages/repoman/scanner.py", line 281, in
scan_pkgs self.pkgmeta.check(xpkg, checkdir, checkdirlist, self.repolevel)
  File
"/usr/lib64/python3.4/site-packages/repoman/checks/ebuilds/pkgmetadata.py",
line 165, in check self.repoman_settings)) File
"/usr/lib64/python3.4/site-packages/repoman/checks/herds/herdbase.py", line
111, in get_herd_base os.path.join(repoman_settings["PORTDIR"],
"metadata/herds.xml")) File
"/usr/lib64/python3.4/site-packages/repoman/checks/herds/herdbase.py", line 73,
in make_herd_base target=_HerdsTreeBuilder())) File
"/usr/lib64/python3.4/xml/etree/ElementTree.py", line 1187, in parse
tree.parse(source, parser) File
"/usr/lib64/python3.4/xml/etree/ElementTree.py", line 605, in parse self._root
= parser.close() xml.etree.ElementTree.ParseError: no element found: line 1,
column 0




-- 


pgpyF72G2zq4a.pgp
Description: OpenPGP digital signature

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

[Chí-Thanh Christopher Nguyễn]

Alexis Ballier schrieb:

If it's just that, it's not limited to udev, but anything using
kdbus/bus1, and would mean openrc/${favorite init system} will have
to do the same thing anyway. But again, almost 2 years is extremely
old considering all the flux that has been around kbus.


OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel
IPC system comes next.


Well, as Lennart wrote it, kbus would have needed some initialisation.
Just like we have a dbus init script, openrc would have a kdbus one.


But if upstream udev makes use of the systemd
userspace interface to the kernel IPC system, then OpenRC would have
to implement the same interface in order to have working udev.


As I understand it, a kernel IPC doesn't need systemd to work. udev
might use wrappers from libsystemd, or libbus1, just like we have
programs using libv4l or libbluetooth currently.


In a follow-up, upstream wrote about how you should only run udev together 
with systemd, and if you don't want to do that (spelling as in original):


"we will not support the udev-on-netlink case anymore. I see three options:
a) fork things, b) live with systemd, c) if hate systemd that much, but
love udev so much, then implement an alternative userspace for kdbus to
do initialiuzation/policy/activation."
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html

So it seems a bit more than only initialization is needed.


Also given the close relationship between systemd and udev, there is
no guarantee that supporting other users of kdbus/bus1 will make udev
automagically work. As these two are released together, there is no
reason to have a stable, public API between them.


Yes, which would mean systemd requires matching udev, not the other way
around. I'm a bit clueless here: Do you have any pointers on the recent
trends on this side ?


I have only upstream's statements from 2014. They talk about a kdbus 
userspace that systemd will provide to udev, which will be necessary for udev 
to function.
If and when upstream comes forward with statements about whether udev will 
only use public and stable API, these concerns could be either dispelled or 
confirmed.



Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] rfc: supervise-daemon -- a lightweight openrc daemon supervisor

[James Le Cuirot]

On Tue, 16 Feb 2016 16:04:42 -0600
William Hubbs  wrote:

> > I wonder if it might even make more sense to reuse one of these
> > instead of reinventing the wheel. They are both extremely
> > lightweight. If you feel you can do better though then go for it!  
> 
> We have s6 support in OpenRC, and I am looking at integrating runit
> support as well.
> 
> For s6 info, see the s6-guide.md file located in
> /usr/share/doc/openrc-*.

Oh, that's cool! Now I come to think of it, I believe it was this
effort that made me aware of s6 in the first place but I'd forgotten
about it since. Now I feel dumb. As you were then. You're doing
great work and we're clearly spoilt for choice. :)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpq_TKG59Wui.pgp
Description: OpenPGP digital signature

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

[Michał Górny]

On Tue, 16 Feb 2016 20:57:31 +0100
Patrick Lauer  wrote:

> On 02/16/2016 08:33 PM, Michał Górny wrote:
> > This all is going into some bickering nonsense and noise made by
> > systemd haters just to feed their troll, FUD and whatever else they
> > made around here.  
> You call it hate, I call it having a choice.

You have a choice. This is trying to force your choice on everyone else
just because you hate the other option and don't want anybody to be
using it.

> >  Because certainly
> > project that is created plainly for political reasons is better.
> > Because it will certainly be technically better if people have to focus
> > on copying regular udev maintainers and reworking their changes to keep
> > them working on forked codebase.
> >
> > And after all, as someone said, this will give eudev proper testing.  
> (1) It's already used by lots of people
> (2) 'proper' testing? As opposed to be the default in more than a dozen
> distros that have usecases you and I rarely think of?

Are you really serious with those fringe distros? How many of them have
a dozen users that do not happen to be developers of the distro? How
many of them are actually used in production? How many of them have
diverse enough userbase to prove that eudev works in different
environments?

> The whole discussion, which seems to turn everyone into a raging
> squirrel, is about changing the default provider of a virtual. All other
> providers will continue being listed and available. The change affects
> none of the current userbase (who seem to have a preference for eudev if
> forums polls have any meaning).
> 
> The change will only affect the default selected when no udev provider
> is already installed. This would finally allow releng to have eudev on
> stage3, which so far they were unable to do without manually overriding
> defaults.
> 
> ^^ That is pretty much all that changes. Seriously.
> 
> 
> I have no idea why this topic that doesn't even affect the most vocal
> neigh-sayers in this discussion seems to be so insanely difficult ...

The reason for that is simple: because it quickly turned away from
merits to politics, FUD and nonsense. And spammed the mailing list to
incredible level. So after next mail about the bad Templars silently
planning to take over the world by integrating udev in systemd codebase
and renaming it to systemd-udevd... I mean, people have their limits,
and there are amounts of nonsense that set us off.

Please don't forget to ban all *BSDs for keeping their sources
in a single repository. They took over the whole base-system already,
and you have to fork the whole system just to have the choice!

-- 
Best regards,
Michał Górny



pgprrnVox_mV3.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: supervise-daemon -- a lightweight openrc daemon supervisor

[William Hubbs]

On Tue, Feb 16, 2016 at 07:32:08PM +, James Le Cuirot wrote:
> On Tue, 16 Feb 2016 12:51:17 -0600
> William Hubbs  wrote:
> 
> > there is a branch in the OpenRC github repo called supervisor.
> 
> Interesting!
> 
> > It is still very rough, and not ready for production, but at this
> > point I would like to make everyone aware that it exists and  ask
> > folks to go over the code and provide comments.
> 
> I'm not really qualified to comment on the code but I'm aware that
> there are lot of ways to get this wrong so please do your homework if
> you haven't done so already. Your post seems like a good start. :)
 
That's exactly why I posted it; I know this is a complex issue, so I
want others to look over the code and provide suggestions for cleaning
it up before it goes mainline.

> runit seems highly regarded and we use it at work on CentOS to allow
> users of the same UNIX group to manage a collection of processes
> without requiring root or sudo. I wasn't aware of s6 at the time but
> I've heard that's also good and this makes an interesting read.
> 
> http://skarnet.org/software/s6/why.html
> 
> I wonder if it might even make more sense to reuse one of these instead
> of reinventing the wheel. They are both extremely lightweight. If you
> feel you can do better though then go for it!

We have s6 support in OpenRC, and I am looking at integrating runit
support as well.

For s6 info, see the s6-guide.md file located in
/usr/share/doc/openrc-*.

This is experimental work at this point, because I've been asked to
determine how much work would be involved in having a small light-weight
supervisor in OpenRC directly.

> Regards,
> -- 
> James Le Cuirot (chewi)
> Gentoo Linux Developer

William



signature.asc
Description: Digital signature

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

[Chí-Thanh Christopher Nguyễn]

Brian Dolbec schrieb:

Thank you for bringing this information to the forefront of this debate.

So, is it not better for us Gentoo-er's that wish to not install
systemd, to set the default non-systemd udev to eudev.


Note that I am not advocating for or against this move. I was just pointing 
out what I consider bad arguments.


This includes labeling valid concerns as "pure FUD", and calling a move 
"definitely premature" when it was only circumstances beyond udev upstream's 
control which prevented it from becoming a necessity.


I do feel that the eudev critics are correct in pointing out that both the 
real-world exposure of eudev so far and the size of its development team are 
too small. Whether it is a good idea to attempt to increase them by making 
eudev the Gentoo default I don't think I am qualified to answer.



Best regards,
Chí-Thanh Christopher Nguyễn

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

[Brian Dolbec]

On Tue, 16 Feb 2016 15:26:46 -0500
"Anthony G. Basile"  wrote:

> On 2/16/16 3:05 PM, Rich Freeman wrote:
> > On Tue, Feb 16, 2016 at 2:57 PM, Patrick Lauer 
> > wrote:  
> >> The whole discussion, which seems to turn everyone into a raging
> >> squirrel, is about changing the default provider of a virtual. All
> >> other providers will continue being listed and available. The
> >> change affects none of the current userbase (who seem to have a
> >> preference for eudev if forums polls have any meaning).  
> > 
> > Why is it that anytime there is a great debate over something
> > somebody says something like the following:  
> 
> https://www.youtube.com/watch?v=6rI8mDpnv7c
> 
> > 
> > This decision is completely trivial and won't really change
> > anything. That is why it is so critical that we make this decision
> > right now!
> > 
> > Either it matters or it doesn't...
> >   
> 
> 

And I had resisted several times now of pasting in youtube links... :)

time for some humor injection...

OK, in this first link, the eudev people think the systemd people are
the one migrating and the systemd people think the reverse...

https://www.youtube.com/watch?v=AOOs8MaR1YM

And from some people's comments in this thread...

https://www.youtube.com/watch?v=dndAXxqJbc0



-- 
Brian Dolbec 

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

[Alexis Ballier]

On Tue, 16 Feb 2016 15:09:23 -0500
Rich Freeman  wrote:

> On Tue, Feb 16, 2016 at 1:34 PM, Chí-Thanh Christopher Nguyễn
>  wrote:
> >
> > This claim was made by upstream, no less. And it refers to
> > *running* udev without systemd as opposed to building (which
> > upstream already made impossible).
> >
> > Here is the exact wording:
> > "Unless the systemd-haters prepare another
> > kdbus userspace until then this will effectively also mean that we
> > will not support non-systemd systems with udev anymore starting at
> > that point. Gentoo folks, this is your wakeup call."
> > https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
> >
> > Not sure what about this is FUD.
> >  
> 
> The fact that it came from Lennart doesn't make it any less FUD.

IMHO this makes a good argument for the wait (aka keep sys-fs/udev
default) position:
- May 2014: Lennart writes the world will fall apart and udev will
  somewhat require systemd with kdbus.
- May/June 2015: kdbus is first sent for review/merge for the linux 4.1
  merge window (I think).
- Feb. 2016: kdbus has been included then removed from fedora kernels,
  it is being reworked and is not even proposed for the linux 4.5 merge
  window.

I'd say we still have some time to see how things will evolve :)

Alexis.

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

[Anthony G. Basile]

On 2/16/16 3:05 PM, Rich Freeman wrote:
> On Tue, Feb 16, 2016 at 2:57 PM, Patrick Lauer  wrote:
>> The whole discussion, which seems to turn everyone into a raging
>> squirrel, is about changing the default provider of a virtual. All other
>> providers will continue being listed and available. The change affects
>> none of the current userbase (who seem to have a preference for eudev if
>> forums polls have any meaning).
> 
> Why is it that anytime there is a great debate over something somebody
> says something like the following:

https://www.youtube.com/watch?v=6rI8mDpnv7c

> 
> This decision is completely trivial and won't really change anything.
> That is why it is so critical that we make this decision right now!
> 
> Either it matters or it doesn't...
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] rfc: Does OpenRC really need mount-ro

[Rich Freeman]

On Tue, Feb 16, 2016 at 2:31 PM, Patrick Lauer  wrote:
>
> The failure message comes from rc-mount.sh when the list of PIDs using a
> mountpoint includes "$$" which is shell shorthand for self. How can the
> current shell claim to be using /usr when it is a shell that only has
> dependencies in $LIBDIR ?
> As far as I can tell the code at this point calls fuser -k ${list of
> pids}, and fuser outputs all PIDs that still use it. I don't see how $$
> can end up in there ...

What does openrc do when the script fails?  Just shut down the system anyway?

If you're going to shut down the system anyway then I'd just force the
read-only mount even if it is in use.  That will cause less risk of
data loss than leaving it read-write.

Of course, it would be better still to kill anything that could
potentially be writing to it.

-- 
Rich

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

[Rich Freeman]

On Tue, Feb 16, 2016 at 1:34 PM, Chí-Thanh Christopher Nguyễn
 wrote:
>
> This claim was made by upstream, no less. And it refers to *running* udev
> without systemd as opposed to building (which upstream already made
> impossible).
>
> Here is the exact wording:
> "Unless the systemd-haters prepare another
> kdbus userspace until then this will effectively also mean that we will
> not support non-systemd systems with udev anymore starting at that
> point. Gentoo folks, this is your wakeup call."
> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
>
> Not sure what about this is FUD.
>

The fact that it came from Lennart doesn't make it any less FUD.

I don't think that the eudev folks plan to completely go off in a
separate direction, so most likely whatever changes occur to systemd
to keep udev running will probably end up getting made to openrc to
keep (e)udev running.

If the argument was that we should be running eudev by default because
it is better I could buy that.  However, this seems to be an argument
based on a fear of what some other project might do in the future.

Even the great Lennart doesn't know with certainty what the future
holds for udev/systemd/etc.

-- 
Rich

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

[Alexis Ballier]

On Tue, 16 Feb 2016 20:33:55 +0100
Michał Górny  wrote:
[...]
> This all is going into some bickering nonsense and noise made by
> systemd haters just to feed their troll, FUD and whatever else they
> made around here.
> 
> So, yes, we should definitely switch to semi-maintained,
> semi-documented fork made plainly of systemd hate. Because certainly
> project that is created plainly for political reasons is better.
> Because it will certainly be technically better if people have to
> focus on copying regular udev maintainers and reworking their changes
> to keep them working on forked codebase.
> 
> And after all, as someone said, this will give eudev proper testing.
> Because why default to something tested and working when you can throw
> your random fork on our users. After all, if we force them to use it,
> they will eventually start co-maintaining it, and it will no longer be
> semi-maintained!

keep cool; eudev has its merits, I'm just trying to figure out what is
a real one and what is a pure guess on the future. For me, the main
advantage for eudev is the loose coupling with the kernel, which we
have no way to control/force in gentoo, and in some worlds (embedded)
it is often, unfortunately, not even an option to use a recent kernel.

Alexis.

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

[Rich Freeman]

On Tue, Feb 16, 2016 at 2:57 PM, Patrick Lauer  wrote:
> The whole discussion, which seems to turn everyone into a raging
> squirrel, is about changing the default provider of a virtual. All other
> providers will continue being listed and available. The change affects
> none of the current userbase (who seem to have a preference for eudev if
> forums polls have any meaning).

Why is it that anytime there is a great debate over something somebody
says something like the following:

This decision is completely trivial and won't really change anything.
That is why it is so critical that we make this decision right now!

Either it matters or it doesn't...

-- 
Rich

Re: [gentoo-dev] rfc: Does OpenRC really need mount-ro

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/16/2016 10:05 AM, William Hubbs wrote:
> All,
> 
> I have a bug that points out a significant issue with 
> /etc/init.d/mount-ro in OpenRC.
> 
> Apparently, there are issues that cause it to not work properly for
> file systems which happen to be pre-mounted from an initramfs [1].
> 
> This service only exists in the Linux world; there is no equivalent
> in OpenRC for any other operating systems we support.
> 
> The reason it exists is very vague to me; I think it has something
> to do with claims of data loss in the past.
> 
> I'm asking for more specific information, and if there is none, due
> to the bug I lincluded in this message, I am considering removing
> this service in 0.21 since I can't find an equivalent anywhere
> else.
> 
> Thanks,
> 
> William
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=573760
> 

I have a LUKS-encrypted / with LVM volumes within it, and they
(apparently?) need to be remounted read-only upon shutdown. I've not
found an easy way to take a picture of the process so I can indicate
*why*, but I've seen it scroll by.

I use an initramfs to decrypt the LUKS partition and discover the LVM
volumes. I can only assume it goes read-only before shutdown/reboot
because it needs to.

Just my two cents.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWw4CkAAoJEAEkDpRQOeFwrUoP+wR1Poxssa29MNQOGo0INPKW
7lKTDIDYuLFHqsKbgwBClaDQSNMEDyeZxmcpw7WXYxykftJ7IXlOYP55WDK/65kQ
QvcF+p7WhsG41kmcmKWrZpaL6Qo8wI58Bo/y3i62/lsecQiuuX8bPlTwTCLBvBxW
iDlMPPMRkHoTheTZK6BPJ4F7jkHKD6LjWKSH1cTigKOtX1Sl+ZYWw6RPgAvS3TPW
9rP6v6QBxYaeM9qiEr4OPyKwiDtm0QOfLswWSxwCmRvZriED8to1n2/CQsSee29L
C04j9nfj5Ez+O8q0hDaiuTZxVZ5AJm3obGQtKpcTDdtHxAQvKvG71AY6wuOfSDh1
kWHfUSSCGv8dB+bglb1beFGyUdZYNt3baVYhmiRqtAUGCXCSOm1Vpj8XCPOGcyPc
FOZaj6iqBfSwZGn5Ah3PwTMiwH+qgPOsYzuhb1okts99DVtNQZ28IGHvOzhYpqvZ
D/loe++/Y05HTmY9S+BhaePe0yU1BKjfO4BtMSsBHcm9cOPjni6KZRa6mGRN4fZS
X7XThXuv9WoD14FLvTMf2DbLJuNivvoyHBZ5qVuSfSachDII6LxaM4Mdvm3bbT67
Bt3jPua39eRBYm0EBNKrM7wOpE2NfLtjZ7bwoaX67EvvG1TuiYYLkXHrB9arFm09
rKNCGZvRDqwDx/PgJkFd
=wWjL
-END PGP SIGNATURE-

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

[Alexis Ballier]

On Tue, 16 Feb 2016 20:14:03 +0100
Chí-Thanh Christopher Nguyễn  wrote:

> Alexis Ballier schrieb:
> > I also fail to see how udev using a new linux ipc would make it
> > require systemd. Quoting Lennart:
> > "You need the userspace code to set up the bus and its policy and
> > handle activation. That's not a trivial task. For us, that's what
> > sytemd does in PID 1. You'd need to come up with an alternative for
> > that."
> >
> > If it's just that, it's not limited to udev, but anything using
> > kdbus/bus1, and would mean openrc/${favorite init system} will have
> > to do the same thing anyway. But again, almost 2 years is extremely
> > old considering all the flux that has been around kbus.  
> 
> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel 
> IPC system comes next.

Well, as Lennart wrote it, kbus would have needed some initialisation.
Just like we have a dbus init script, openrc would have a kdbus one.

> But if upstream udev makes use of the systemd 
> userspace interface to the kernel IPC system, then OpenRC would have
> to implement the same interface in order to have working udev.

As I understand it, a kernel IPC doesn't need systemd to work. udev
might use wrappers from libsystemd, or libbus1, just like we have
programs using libv4l or libbluetooth currently.

> Also given the close relationship between systemd and udev, there is
> no guarantee that supporting other users of kdbus/bus1 will make udev 
> automagically work. As these two are released together, there is no 
> reason to have a stable, public API between them.

Yes, which would mean systemd requires matching udev, not the other way
around. I'm a bit clueless here: Do you have any pointers on the recent
trends on this side ?

Alexis.

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

[Patrick Lauer]

On 02/16/2016 08:33 PM, Michał Górny wrote:
> On Tue, 16 Feb 2016 20:14:03 +0100
> Chí-Thanh Christopher Nguyễn  wrote:
>
>> Alexis Ballier schrieb:
>>> I also fail to see how udev using a new linux ipc would make it require
>>> systemd. Quoting Lennart:
>>> "You need the userspace code to set up the bus and its policy and handle
>>> activation. That's not a trivial task. For us, that's what sytemd does
>>> in PID 1. You'd need to come up with an alternative for that."
>>>
>>> If it's just that, it's not limited to udev, but anything using
>>> kdbus/bus1, and would mean openrc/${favorite init system} will have to
>>> do the same thing anyway. But again, almost 2 years is extremely
>>> old considering all the flux that has been around kbus.  
>> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel 
>> IPC system comes next. But if upstream udev makes use of the systemd 
>> userspace interface to the kernel IPC system, then OpenRC would have to 
>> implement the same interface in order to have working udev.
>>
>> Also given the close relationship between systemd and udev, there is no 
>> guarantee that supporting other users of kdbus/bus1 will make udev 
>> automagically work. As these two are released together, there is no 
>> reason to have a stable, public API between them.
> This all is going into some bickering nonsense and noise made by
> systemd haters just to feed their troll, FUD and whatever else they
> made around here.
You call it hate, I call it having a choice.
If I didn't want a choice I'd be using MacOS anyway, so please don't
claim to understand my motivations (and why they are obviously wrong,
since you know The Truth)

>
> So, yes, we should definitely switch to semi-maintained,
> semi-documented fork made plainly of systemd hate.
You mean sys-fs/udev ? I'd say unsupported instead of semi-maintained ;)

>  Because certainly
> project that is created plainly for political reasons is better.
> Because it will certainly be technically better if people have to focus
> on copying regular udev maintainers and reworking their changes to keep
> them working on forked codebase.
>
> And after all, as someone said, this will give eudev proper testing.
(1) It's already used by lots of people
(2) 'proper' testing? As opposed to be the default in more than a dozen
distros that have usecases you and I rarely think of?
> Because why default to something tested and working when you can throw
> your random fork on our users. After all, if we force them to use it,
> they will eventually start co-maintaining it, and it will no longer be
> semi-maintained!
>
I have no idea why you think eudev is so horrible, but you're entitled
to having opinions.

And we don't throw it on our users more than we do now: If you don't
like it just remove it. emerge -C is easy!
You make it sound like we're removing choice, which is just ... how the
... what are you?!?

The whole discussion, which seems to turn everyone into a raging
squirrel, is about changing the default provider of a virtual. All other
providers will continue being listed and available. The change affects
none of the current userbase (who seem to have a preference for eudev if
forums polls have any meaning).

The change will only affect the default selected when no udev provider
is already installed. This would finally allow releng to have eudev on
stage3, which so far they were unable to do without manually overriding
defaults.

^^ That is pretty much all that changes. Seriously.


I have no idea why this topic that doesn't even affect the most vocal
neigh-sayers in this discussion seems to be so insanely difficult ...

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

[Michał Górny]

On Tue, 16 Feb 2016 20:14:03 +0100
Chí-Thanh Christopher Nguyễn  wrote:

> Alexis Ballier schrieb:
> > I also fail to see how udev using a new linux ipc would make it require
> > systemd. Quoting Lennart:
> > "You need the userspace code to set up the bus and its policy and handle
> > activation. That's not a trivial task. For us, that's what sytemd does
> > in PID 1. You'd need to come up with an alternative for that."
> >
> > If it's just that, it's not limited to udev, but anything using
> > kdbus/bus1, and would mean openrc/${favorite init system} will have to
> > do the same thing anyway. But again, almost 2 years is extremely
> > old considering all the flux that has been around kbus.  
> 
> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel 
> IPC system comes next. But if upstream udev makes use of the systemd 
> userspace interface to the kernel IPC system, then OpenRC would have to 
> implement the same interface in order to have working udev.
> 
> Also given the close relationship between systemd and udev, there is no 
> guarantee that supporting other users of kdbus/bus1 will make udev 
> automagically work. As these two are released together, there is no 
> reason to have a stable, public API between them.

This all is going into some bickering nonsense and noise made by
systemd haters just to feed their troll, FUD and whatever else they
made around here.

So, yes, we should definitely switch to semi-maintained,
semi-documented fork made plainly of systemd hate. Because certainly
project that is created plainly for political reasons is better.
Because it will certainly be technically better if people have to focus
on copying regular udev maintainers and reworking their changes to keep
them working on forked codebase.

And after all, as someone said, this will give eudev proper testing.
Because why default to something tested and working when you can throw
your random fork on our users. After all, if we force them to use it,
they will eventually start co-maintaining it, and it will no longer be
semi-maintained!

-- 
Best regards,
Michał Górny



pgp9m0EQxaIJ1.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: Does OpenRC really need mount-ro

[Patrick Lauer]

On 02/16/2016 07:05 PM, William Hubbs wrote:
> All,
>
> I have a bug that points out a significant issue with
> /etc/init.d/mount-ro in OpenRC.
>
> Apparently, there are issues that cause it to not work properly for file
> systems which happen to be pre-mounted from an initramfs [1].
I don't understand how this fails, how does mounting from the initramfs
cause issues?

The failure message comes from rc-mount.sh when the list of PIDs using a
mountpoint includes "$$" which is shell shorthand for self. How can the
current shell claim to be using /usr when it is a shell that only has
dependencies in $LIBDIR ?
As far as I can tell the code at this point calls fuser -k ${list of
pids}, and fuser outputs all PIDs that still use it. I don't see how $$
can end up in there ...

>
> This service only exists in the Linux world; there is no equivalent in
> OpenRC for any other operating systems we support.
>
> The reason it exists is very vague to me; I think it has something to do
> with claims of data loss in the past.
Yes, if you just shut down without unmounting file systems -
(1) you may throw away data in the FS cache that hasn't ended up on disk yet
(2) the filesystem has no chance to mark itself cleanly unmounted, so
you will trigger journal replay or fsck or equivalent on boot

That's why sysvinit had a random "sleep(1)" in the halt and "sleep(2)"
in the reboot function, to give computers more of a chance to shutdown
and reboot sanely.

The changes in sysvinit-2.88-r8 and later add the "-n" option:
   -n Don't sync before reboot or halt. Note that the kernel and
storage drivers may still sync.

This was added *because* we can guarantee that filesystems are
consistent enough with mount-ro. If you wish to remove it you need to
reconsider all these little details ...
>
> I'm asking for more specific information, and if there is none, due to
> the bug I lincluded in this message, I am considering removing this
> service in 0.21 since I can't find an equivalent anywhere else.
Please don't just remove things you don't understand.
>
> Thanks,
>
> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=573760

Looking at the init script as of openrc-0.20.5:

~line32:
# Bug 381783
local rc_svcdir=$(echo $RC_SVCDIR | sed
's:/lib\(32\|64\)\?/:/lib(32|64)?/:g')
This looks relatively useless with everything migrated to /run and can
most likely be removed

~line35:
  local
m="/dev|/dev/.*|/proc|/proc.*|/sys|/sys/.*|/run|${rc_svcdir}" x= fs=
Since this is a regexp it can be cut down to something more simple - why
/dev and /dev/* when the second one is already excluded by the first
one. Also rc_svcdir is most likely a subdir of /run ...

Re: [gentoo-dev] rfc: supervise-daemon -- a lightweight openrc daemon supervisor

[James Le Cuirot]

On Tue, 16 Feb 2016 12:51:17 -0600
William Hubbs  wrote:

> there is a branch in the OpenRC github repo called supervisor.

Interesting!

> It is still very rough, and not ready for production, but at this
> point I would like to make everyone aware that it exists and  ask
> folks to go over the code and provide comments.

I'm not really qualified to comment on the code but I'm aware that
there are lot of ways to get this wrong so please do your homework if
you haven't done so already. Your post seems like a good start. :)

runit seems highly regarded and we use it at work on CentOS to allow
users of the same UNIX group to manage a collection of processes
without requiring root or sudo. I wasn't aware of s6 at the time but
I've heard that's also good and this makes an interesting read.

http://skarnet.org/software/s6/why.html

I wonder if it might even make more sense to reuse one of these instead
of reinventing the wheel. They are both extremely lightweight. If you
feel you can do better though then go for it!

Regards,
-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp9qOD_XNjkz.pgp
Description: OpenPGP digital signature

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

[Brian Dolbec]

On Tue, 16 Feb 2016 19:53:48 +0100
Chí-Thanh Christopher Nguyễn  wrote:

> William Hubbs schrieb:
> > Maybe FUD is the incorrect way to put it, but I think us doing
> > something about it at this point is definitely premature since   
> > KDBUS is no where near ready to go -- they were forced to retract
> > it a while back because they had to re-think the design.
> 
> kdbus got sent for inclusion in the kernel, and they were sure ready
> to pull off their plan back then if kdbus had been accepted.
> 
> Whether switching to eudev now is premature is actually the central 
> issue of this whole discussion. Given that dropping support for udev
> on non-systemd systems was narrowly avoided once, and upstream leaves
> no doubt that they are ready to do so once their redesigned kernel
> message bus goes upstream, I say describing such a move as
> "definitely premature" is not warranted.
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn

Thank you for bringing this information to the forefront of this debate.

So, is it not better for us Gentoo-er's that wish to not install
systemd, to set the default non-systemd udev to eudev.  In that way,
maybe eudev will get more contributed support and Anthony more eyes on
things.  It seems that unless kdbus is perpetually rejected by the
kernel team... it is only a matter of time.


So, I say, we've all had enough bickering about the subject.

 Time for a final vote!

If we had all spent our time working on real problems as
we've spent reading this never ending debate mail...

but alas, this will be yet another item that must be decided by the
council.
-- 
Brian Dolbec 

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

[Chí-Thanh Christopher Nguyễn]

Alexis Ballier schrieb:

I also fail to see how udev using a new linux ipc would make it require
systemd. Quoting Lennart:
"You need the userspace code to set up the bus and its policy and handle
activation. That's not a trivial task. For us, that's what sytemd does
in PID 1. You'd need to come up with an alternative for that."

If it's just that, it's not limited to udev, but anything using
kdbus/bus1, and would mean openrc/${favorite init system} will have to
do the same thing anyway. But again, almost 2 years is extremely
old considering all the flux that has been around kbus.


OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel 
IPC system comes next. But if upstream udev makes use of the systemd 
userspace interface to the kernel IPC system, then OpenRC would have to 
implement the same interface in order to have working udev.


Also given the close relationship between systemd and udev, there is no 
guarantee that supporting other users of kdbus/bus1 will make udev 
automagically work. As these two are released together, there is no 
reason to have a stable, public API between them.



Best regards,
Chí-Thanh Christopher Nguyễn

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

[Alexis Ballier]

On Tue, 16 Feb 2016 19:34:20 +0100
Chí-Thanh Christopher Nguyễn  wrote:

> Alexis Ballier schrieb:
> > It would probably generate controversy indeed, but my comment was
> > more to understand what is the root of the f34R of udev being
> > absorbed by systemd: "it is supposedly unsupported upstream and
> > might not work at some point".
> > Well, as far as I can see, you are maintaining sys-fs/udev
> > standalone and don't intend to drop it. Even if you did, we could
> > still pkgmove it to systemd. My conclusion is that this claim of
> > udev being a dead end is pure FUD.  
> 
> This claim was made by upstream, no less. And it refers to *running* 
> udev without systemd as opposed to building (which upstream already
> made impossible).
> 
> Here is the exact wording:
> "Unless the systemd-haters prepare another
> kdbus userspace until then this will effectively also mean that we
> will not support non-systemd systems with udev anymore starting at
> that point. Gentoo folks, this is your wakeup call."
> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
> 
> Not sure what about this is FUD.

If it is kdbus, this has changed quite a bit in the past months: it's
now dropped and replaced by bus1, and afaik, there is no plan to make a
systemd only lib for easying usage:
https://github.com/bus1/libbus1

I also fail to see how udev using a new linux ipc would make it require
systemd. Quoting Lennart:
"You need the userspace code to set up the bus and its policy and handle
activation. That's not a trivial task. For us, that's what sytemd does
in PID 1. You'd need to come up with an alternative for that."

If it's just that, it's not limited to udev, but anything using
kdbus/bus1, and would mean openrc/${favorite init system} will have to
do the same thing anyway. But again, almost 2 years is extremely
old considering all the flux that has been around kbus.

Alexis.

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

[Chí-Thanh Christopher Nguyễn]

Sorry about the messed up quoting, somehow enigmail and format=flowed do 
not work well together.

[gentoo-dev] rfc: supervise-daemon -- a lightweight openrc daemon supervisor

[William Hubbs]

All,

there is a branch in the OpenRC github repo called supervisor.

On that branch, I am working on a lightweight daemon supervisor that
will be native to OpenRC.

It is based on start-stop-daemon, but it will stay around and make sure
that the daemon gets restarted if it dies.

It is still very rough, and not ready for production, but at this point
I would like to make everyone aware that it exists and  ask folks to go
over the code and provide comments.

It can currently launch a daemon, and I still am working on making it
restart a daemon if it dies.

This will only work for non-forking daemons; the daemon should not fork
and should not write a pid file.

One of the big questions I have is about PAM usage. Do I still need to
do that in this supervisor? If I open a PAM session, does it carry
across forks?

Thanks,

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] rfc: Does OpenRC really need mount-ro

[William Hubbs]

On Tue, Feb 16, 2016 at 01:22:13PM -0500, Rich Freeman wrote:
> On Tue, Feb 16, 2016 at 1:05 PM, William Hubbs  wrote:
> >
> > The reason it exists is very vague to me; I think it has something to do
> > with claims of data loss in the past.
> >
> 
> Is there some other event that will cause all filesystems to be
> remounted read-only or unmounted before shutdown?

When localmount/netmount stop they try to unmount file systems they know
about, but they do not try to remount anything.


> You definitely will want to either unmount or remount readonly all
> filesystems prior to rebooting.  I don't think the kernel guarantees
> that this will happen (I'd have to look at it).  Just doing a sync
> before poweroff doesn't seem ideal - if nothing else it will leave
> filesystems marked as dirty and likely force fscks on the next boot
> (or at least it should - if it doesn't that is another opportunity for
> data loss).
> 
> There are different ways of accomplishing this of course, but you
> really want to have everything read-only in the end.

unmounting is easy enough; we already do that.

What I'm trying to figure out is, what to do about re-mounting file
systems read-only.

How does systemd do this? I didn't find an equivalent of the mount-ro
service there.

William


signature.asc
Description: Digital signature

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

[William Hubbs]

On Tue, Feb 16, 2016 at 07:34:20PM +0100, Chí-Thanh Christopher Nguyễn wrote:
> Alexis Ballier schrieb:
> > It would probably generate controversy indeed, but my comment was more
> > to understand what is the root of the f34R of udev being absorbed by
> > systemd: "it is supposedly unsupported upstream and might not work at
> > some point".
> > Well, as far as I can see, you are maintaining sys-fs/udev standalone
> > and don't intend to drop it. Even if you did, we could still pkgmove it
> > to systemd. My conclusion is that this claim of udev being a dead end
> > is pure FUD.
> 
> This claim was made by upstream, no less. And it refers to *running* 
> udev without systemd as opposed to building (which upstream already made 
> impossible).
> 
> Here is the exact wording:
> "Unless the systemd-haters prepare another
> kdbus userspace until then this will effectively also mean that we will
> not support non-systemd systems with udev anymore starting at that
> point. Gentoo folks, this is your wakeup call."
> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
> 
> Not sure what about this is FUD.

Maybe FUD is the incorrect way to put it, but I think us doing something
about it at this point is definitely premature since KDBUS is no where
near ready to go -- they were forced to retract it a while back because
they had to re-think the design.

William



signature.asc
Description: Digital signature

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

[Chí-Thanh Christopher Nguyễn]

Alexis Ballier schrieb:

It would probably generate controversy indeed, but my comment was more
to understand what is the root of the f34R of udev being absorbed by
systemd: "it is supposedly unsupported upstream and might not work at
some point".
Well, as far as I can see, you are maintaining sys-fs/udev standalone
and don't intend to drop it. Even if you did, we could still pkgmove it
to systemd. My conclusion is that this claim of udev being a dead end
is pure FUD.


This claim was made by upstream, no less. And it refers to *running* 
udev without systemd as opposed to building (which upstream already made 
impossible).


Here is the exact wording:
"Unless the systemd-haters prepare another
kdbus userspace until then this will effectively also mean that we will
not support non-systemd systems with udev anymore starting at that
point. Gentoo folks, this is your wakeup call."
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html

Not sure what about this is FUD.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] rfc: Does OpenRC really need mount-ro

[Rich Freeman]

On Tue, Feb 16, 2016 at 1:05 PM, William Hubbs  wrote:
>
> The reason it exists is very vague to me; I think it has something to do
> with claims of data loss in the past.
>

Is there some other event that will cause all filesystems to be
remounted read-only or unmounted before shutdown?

You definitely will want to either unmount or remount readonly all
filesystems prior to rebooting.  I don't think the kernel guarantees
that this will happen (I'd have to look at it).  Just doing a sync
before poweroff doesn't seem ideal - if nothing else it will leave
filesystems marked as dirty and likely force fscks on the next boot
(or at least it should - if it doesn't that is another opportunity for
data loss).

There are different ways of accomplishing this of course, but you
really want to have everything read-only in the end.

-- 
Rich

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

[Alexis Ballier]

On Tue, 16 Feb 2016 11:45:41 -0600
William Hubbs  wrote:

> On Mon, Feb 15, 2016 at 07:11:26AM -0500, Rich Freeman wrote:
> > On Mon, Feb 15, 2016 at 4:29 AM, Alexis Ballier
> >  wrote:  
> > > On Sun, 14 Feb 2016 19:34:52 -0600
> > > William Hubbs  wrote:
> > >  
> > >> And, as for right now, udev-229 is in the tree, so udev can
> > >> still be extracted and run standalone from systemd.  
> > >
> > > and even with that, I don't think there is anything preventing
> > > using systemd-udev from an openrc boot, is it ? (ie, have systemd
> > > installed but booting with openrc)
> > >  
> > 
> > Correct, you can uninstall sys-fs/(e)udev and install
> > sys-apps/systemd, then boot with openrc, and udev will work just
> > fine.  
> 
> This is correct. udev does not require systemd in order to run; the
> only thing it needs is the systemd build environment since there is
> common source code.
> 
> The primary reason we have sys-fs/udev in the tree these days is so
> people can have upstream udev without installing systemd.
> 
> In theory, we could lastrites sys-fs/udev and make sys-apps/systemd
> the default udev provider, but I'm sure that change would be even
> more controversial than what we are discussing. ;-)

It would probably generate controversy indeed, but my comment was more
to understand what is the root of the f34R of udev being absorbed by
systemd: "it is supposedly unsupported upstream and might not work at
some point".

Well, as far as I can see, you are maintaining sys-fs/udev standalone
and don't intend to drop it. Even if you did, we could still pkgmove it
to systemd. My conclusion is that this claim of udev being a dead end
is pure FUD.

Alexis.

[gentoo-dev] rfc: Does OpenRC really need mount-ro

[William Hubbs]

All,

I have a bug that points out a significant issue with
/etc/init.d/mount-ro in OpenRC.

Apparently, there are issues that cause it to not work properly for file
systems which happen to be pre-mounted from an initramfs [1].

This service only exists in the Linux world; there is no equivalent in
OpenRC for any other operating systems we support.

The reason it exists is very vague to me; I think it has something to do
with claims of data loss in the past.

I'm asking for more specific information, and if there is none, due to
the bug I lincluded in this message, I am considering removing this
service in 0.21 since I can't find an equivalent anywhere else.

Thanks,

William

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


signature.asc
Description: Digital signature

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

[William Hubbs]

On Mon, Feb 15, 2016 at 07:11:26AM -0500, Rich Freeman wrote:
> On Mon, Feb 15, 2016 at 4:29 AM, Alexis Ballier  wrote:
> > On Sun, 14 Feb 2016 19:34:52 -0600
> > William Hubbs  wrote:
> >
> >> And, as for right now, udev-229 is in the tree, so udev can still be
> >> extracted and run standalone from systemd.
> >
> > and even with that, I don't think there is anything preventing using
> > systemd-udev from an openrc boot, is it ? (ie, have systemd installed
> > but booting with openrc)
> >
> 
> Correct, you can uninstall sys-fs/(e)udev and install
> sys-apps/systemd, then boot with openrc, and udev will work just fine.

This is correct. udev does not require systemd in order to run; the only
thing it needs is the systemd build environment since there is common
source code.

The primary reason we have sys-fs/udev in the tree these days is so
people can have upstream udev without installing systemd.

In theory, we could lastrites sys-fs/udev and make sys-apps/systemd the default
udev provider, but I'm sure that change would be even more controversial
than what we are discussing. ;-)

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] libressl: proposing a new project and calling for help

[Toralf Förster]

Anthony G. Basile:
> Before I put up a project page, can I ask who is interested in this?
> 
If I can help with my tinderbox [1] - I'd appreciate it.


[1] http://www.zwiebeltoralf.de/tinderbox/index.html

-- 
Toralf
PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7

Re: [gentoo-dev] libressl: proposing a new project and calling for help

[Anthony G. Basile]

On 2/15/16 8:43 AM, Kristian Fiskerstrand wrote:
> On 02/15/2016 01:20 PM, Dirkjan Ochtman wrote:
>> On Sun, Feb 14, 2016 at 10:38 PM, Anthony G. Basile 
>>  wrote:
>>> We discussed the state of libressl today in the council. 
>>> Proceeding forward with that work, I'm going to propose a new 
>>> project and getting together a team.  Much of the work has 
>>> already done by hasufell and what remain is just following 
>>> through on his plan.
>>
>> Is "his plan" detailed anywhere? In other words, what does it mean 
>> to sign up for this project? :)
>>
> 
> https://github.com/gentoo/libressl/wiki/Transition-plan#fixing-unstable-arch-ebuilds
> 
> 
> 

That is the plan, and I do need help with it, but even if you don't have
a lot of time, I would appreciate if you get familiar with the issues
and advise me so that I don't act alone (aka act stupidly).  So I run
other "alt" projects like the uclibc/musl stuff and hardened, and these
mostly stay out of the way of other projects.  I'd like libressl to do
the same.

I'll put up a page over the weekend.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197