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

[Andrew Savchenko]

On Wed, 17 Feb 2016 22:26:32 -0500 Richard Yao wrote:
> On 02/17/2016 02:01 PM, Andrew Savchenko wrote:
> > On Tue, 16 Feb 2016 15:18:46 -0500 Rich Freeman wrote:
> >> 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.
> > 
> > This is not always possible. Two practical cases from my experience:
> > 
> > 1) NFS v4 shares can't be unmounted if server is unreachable (even
> > with -f). If filesystem (e.g. /home or /) contains such unmounted
> > mount points, it can't be unmounted as well, because it is still in
> > use. This happens quite often if both NFS server and client are
> > running from UPS on low power event (when AC power failed and
> > battery is almost empty).
> 
> Does `umount -l /path/to/mnt` work on those?

No, if mount point is already stalled, -l is of no use. 
 
> > 2) LUKS device is in frozen state. I use this as a security
> > precaution if LUKS fails to unmount (or it takes too long), e.g.
> > due to dead mount point.
> 
> This gives me another reason to justify being a fan of integrating
> encryption directly into a filesystem

Ext4 and f2fs do this, but with limited cypersuits available.

Actually problems with LUKS are not critical: I never lost data,
integrity there and had only a small security issue. The only
failure I can remember was libgcrypt whirlpool issue (invalid
implementation on old versions and incompatible fix on new ones).

> or using ecryptfs on top of the VFS.

No, never. Not on my setups. Ecryptfs is
1) unsecure (leaks several bytes of data)
2) unreliable, as it depends on boost and other high-level C++
stuff. I had lost an ability to decrypt data because of boost XML
versioning change.

> The others were possible integrity concerns (which definitely
> happen with a frozen state,

In theory — maybe. In real life — no. I use LUKS for over 8 years,
I often had frozen shutdowns and I never had data loss there. In
terms of data integrity LUKS + ext4 is ultimate. This joint
survived even on host with failing RAM for several years.

> although mine were about excessive layering
> adding opportunities for bugs) and performance concerns from doing
> unnecessary calculations on filesystems that span multiple disks (e.g.
> each mirror member gets encrypted independently).

Ehh... why independently? Just create mdadm with proper chunk
size, put LUKS on top of it, align both LUKS and internal fs to that
size and relevant stride and performance will be optimal. On SSDs
this is harder because it is very difficult to determine erase
block size properly, but that is another issue.

Best regards,
Andrew Savchenko


pgpY2gr1jxMe4.pgp
Description: PGP signature

Re: [gentoo-dev] games.eclass policy

[Michał Górny]

On Wed, 17 Feb 2016 18:06:29 -0700
Denis Dupeyron  wrote:

> On Wed, Feb 17, 2016 at 11:38 AM, Michał Górny  wrote:
> >
> > Well, maybe it's because you can talk to Python team, discuss and not
> > get ignored by them.  
> 
> We've already established the same is true for the games team. I'm a living
> example of it and I can't imagine I'm the only one.

Good for you. So... ignoring majority is fine as long as you can prove
that they don't ignore one of their old fellows. Good.

> > Unlike games team members who believe it's best to
> > ignore certain developers.  
> 
> I certainly hope we can still ignore abrasive developers since it's been
> proven many times that it's the best way to deal with them.
> 
> So, you don't answer my question. Or rather, you answer with a specious
> statement. Since you're being unusually shy I will say what you're trying
> hard not so say. There are actually first-class projects catered for by
> first-class developers, and those can set rules like the mandatory use of
> an eclass and actually enforce them. Then there are second-class projects
> and developers who can do the same as long as it doesn't bother the
> first-class people. Second-class developers, often working quietly and
> steadily, not wasting their time on mailing-lists like I just did, can see
> their projects trampled over at any time for the mere reason that they were
> trying to keep their business in order, just like first-class developers do.

Now you are trivializing the problem. I wasn't talking about mailing
lists. I was talking about explicit questions, requests, pings. Mail,
IRC, Bugzilla.

If you get bug from the Council asking you what to do... don't you
think it would be fair to reply? Of course, you could say 'mgorny
opened the bug, I'm going to ignore him'. But the fact is, this is
not some kind of 'quiet, steady work'.

This is an explicit attempt of ignoring everyone with differing opinion
by delaying things. Sure, you can disagree. But it's different to
discuss disagreements and reach a consensus. And it's different if you
silently ignore disagreeing opinions and make them wait months for
a single reply, hoping to stall them from having any effect whatsoever.

When was the last time games project got a new member? Where is that
'premiere Linux gaming platform'? What about all these users? Why were
we exposing security issues for almost 10 years?

So we're the bad ones in your opinion, troubling the little closed
team. We want to have some influence, bad us. We should just keep quiet
and let us be ordered. Stand out of the line -- and you're a problem,
you're abrasive developer, you should be ignored.

-- 
Best regards,
Michał Górny



pgprhTp8Tu3gt.pgp
Description: OpenPGP digital signature

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

[Robin H. Johnson]

On Tue, Feb 16, 2016 at 12:05:33PM -0600, William Hubbs wrote:
> 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'll look at why it's failing to change the mount to read-only, rather
than just ignore it.

I have a use case for mount-ro not previously discussed here:
kexec

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

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

[Richard Yao]

On 02/17/2016 02:01 PM, Andrew Savchenko wrote:
> On Tue, 16 Feb 2016 15:18:46 -0500 Rich Freeman wrote:
>> 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.
> 
> This is not always possible. Two practical cases from my experience:
> 
> 1) NFS v4 shares can't be unmounted if server is unreachable (even
> with -f). If filesystem (e.g. /home or /) contains such unmounted
> mount points, it can't be unmounted as well, because it is still in
> use. This happens quite often if both NFS server and client are
> running from UPS on low power event (when AC power failed and
> battery is almost empty).

Does `umount -l /path/to/mnt` work on those?

> 2) LUKS device is in frozen state. I use this as a security
> precaution if LUKS fails to unmount (or it takes too long), e.g.
> due to dead mount point.

This gives me another reason to justify being a fan of integrating
encryption directly into a filesystem or using ecryptfs on top of the
VFS. The others were possible integrity concerns (which definitely
happen with a frozen state, although mine were about excessive layering
adding opportunities for bugs) and performance concerns from doing
unnecessary calculations on filesystems that span multiple disks (e.g.
each mirror member gets encrypted independently).

> As far as I understand, mount-ro may be useful only if unmount
> failed, but from my practical experience, openrc just hangs forever
> in such case until UPS is shut down by battery drain.

It is useful even if mounting everything succeeds because of /. That
said, I do not think we can sanely handle every possible configuration
because someone will always come up with something new.

> Best regards,
> Andrew Savchenko
> 




signature.asc
Description: OpenPGP digital signature

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

[Richard Yao]

On 02/17/2016 01:32 PM, Rich Freeman wrote:
> On Wed, Feb 17, 2016 at 1:06 PM, Ian Stakenvicius  wrote:
>>
>> Genkernel's initramfs generation was what we endorsed for the most
>> part, until dracut came around.  it's hard to say what "most" are
>> doing but i expect dracut and genkernel based initramfs's make up
>> the vast majority in use by gentoo users, with a small minority
>> rolling their own through other means.
>>
> 
> While I personally endorse dracut over genkernel, the reality is that
> only genkernel is actually documented in the handbook.  This is due at
> least in part to laziness on my part as I've been meaning to add it
> since forever.
> 
> Likewise I intend to update the handbook to make selection of
> openrc/systemd less convoluted as well.  The current handbook does
> offer systemd as an option but then basically refers you out to
> another page that doesn't follow the same flow as the handbook.
> 
> In my notes I've found that it is a pretty trivial change to pick one
> or the other actually if you do it at the right time, so this could be
> added to the handbook with very little disruption to the flow for
> non-systemd users.  I imagine other service managers would be similar,
> or even simpler.  I found that switching between the two only requires
> two changes - one is to pick a systemd profile relatively early in the
> process before doing a world update, and then changing one line in
> your grub config at the end.  If you emerge world after you do most of
> your system configuration systemd will automatically pick up all the
> openrc configuration and use it, which as a bonus leaves you with a
> system that is easy to boot in either mode.
> 
> Getting back to dracut - it is really just a few lines added as an
> alternative to the initramfs section.  After you build your kernel it
> is really just a one-liner, and grub2-mkconfig picks up on it
> automatically (as I imagine it probably does with genkernel as well).
> Unless you want to play with the configuration there isn't much fuss.

dracut does not assist those who do not want generic kernel
configurations. Unfortunately, the handbook does not do a good job in
saying that the initramfs generation and generic kernel configurations
are optional.

> I think we really should give strong consideration to recommending
> dracut as a default, while of course preserving the option of
> genkernel.  I'm certainly open to feedback if there is some use case
> where genkernel is better, but dracut is cross-distro, gives you
> options to easily maximize or minimize your config, and is really easy
> to tailor with modules.

There is no default and system boot without an initramfs not only works,
but is advisable for faster boot unless something fancy is being done
that needs it.

Claiming to pick a default between genkernel and dracut when both are
optional makes no sense, especially since dracut's capabilities
(initramfs generation) are a subset of genkernel's (initramfs generation
and kernel builds). dracut could replace genkernel's initramfs
generation capabilities, but it simply cannot replace genkernel for
building a generic kernel. It was never intended to do that.

By the way, pver the course of time, there have been things genkernel
did better and things dracut did better. It is unlikely one will ever be
superior to the other. However, some feedback on what genkernel does
poorly versus dracut and could therefore improve would be helpful.



signature.asc
Description: OpenPGP digital signature

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

[Richard Yao]

On 02/17/2016 12:19 PM, Rich Freeman wrote:
> On Wed, Feb 17, 2016 at 9:24 AM, Richard Yao  wrote:
>> Systemd installs that go back into the initramfs at shutdown are rare 
>> because there is a
>> hook for the initramfs to tell systemd that it should re-exec it and very 
>> few configurations
>> do that. Even fewer that do it actually need it.
> 
> While I won't debate that it probably isn't strictly essential, dracut
> handles unmounting root for systemd just fine (well, at least on
> non-nfs - the version I'm using with an nfs root struggles in this
> regard, though unclean shutdown on nfs with no files open probably
> isn't really a problem).

Dracut handling it well is not up for dispute. When I checked last year,
dracut simply did not tell systemd to use this functionality because it
was unnecessary functionality that only served to slowed down the
shutdown process. It only enables it when a driver indicates an actual
need, which is the way that it should be.

> Is dracut still not widely used?  I know that it was all the fashion
> for a decade or two for every distro to build their own initramfs, but
> I don't get why anybody wouldn't just make the switch - it is far more
> capable and configurable.

Not many Gentoo users use dracut. It does not handle kernel compilation
or bootloader configuration. It is definite ahead of genkernel in
networking though, but there is not much demand for that among users.



signature.asc
Description: OpenPGP digital signature

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

[Richard Yao]

On 02/17/2016 01:47 PM, Rich Freeman wrote:
> On Wed, Feb 17, 2016 at 11:04 AM, Richard Yao  wrote:
>>
>> This is something that I think many of us who had systems broken by
>> sys-fs/udev multiple times before sys-fs/eudev was an option thought was
>> obvious.
> 
> About the only "system-breaking" change I'm aware of in udev over the
> years was the change in default network interface names.  That was
> preceded by news on how to avoid the change, or how to adapt to the
> change.
> 
> There certainly wasn't some change introduced without warning that
> just broke systems in random ways.
> 
>> If a complete list of the breakages that lead to the creation of
>> sys-fs/eudev were produced, I imagine that the list would have at least
>> 3 to 5 items from the ~18 months before sys-fs/eudev with half of them
>> were probably self inflicted by sys-fs/udev maintenance.
> 
> Anytime upstream changes something it is up to package maintainers to
> evaluate the change and adapt to it as needed, especially for critical
> packages like udev.  For the most part I think this is happening.
> Whether it is the udev maintainers doing the QA or the eudev
> maintainers doing the QA, somebody has to do the QA (and in Gentoo it
> sounds like we do it twice, which is fine).
> 
>> I recall one incident involving whether udev should be in /sbin or
>> /usr/sbin being resolved after 6 months of debate between then future
>> eudev founders and sys-fs/udev maintainers only because the systemd
>> developers told the sys-fs/udev maintainers it should be in /sbin like
>> others had told them.
> 
> So, this sounds like a disagreement between the future eudev founders
> and the udev maintainers in Gentoo.  It really has nothing to do with
> udev itself.

That is just one thing that I remembered off the top of my head and
quite frankly, that situation was the most absurd system breakage
incident that ever occurred involving udev. The arguments by the
sys-fs/udev maintainers at the time were that upstream wanted it that
way when even the systemd developers did not agree with them. The matter
was only resolved after one of the sys-fs/udev maintainers decided to
ask the systemd developers what they actually thought after 6 months of
claiming their way was the upstream way and were told that they thought
the packaging was wrong. Everyone else had believed the sys-fs/udev
maintainers' statements that upstream actually thought such things, and
consequently, were adamant that the systemd maintainers had no idea what
they were doing.

There were multiple breakages caused by sys-fs/udev maintainance
following systemd assimilating udev based on the principle that upstream
wanted it that way. The outsourcing of responsibility for thought on
such things were one of the things that contributed to eudev's creation.
Another were absolute refusal by Kay Sievers at the time to fix
regressions when given patches. It was not "rewrite the patch this way".
It was along the lines of "we are not fixing that because we don't care
about people affected by this and fixing that would add 40 lines to the
codebase".

> And that is OK - we're allowed to have the same package maintained
> under two different names by two sets of maintainers.  Obviously it
> isn't ideal, and it would be better if everybody could agree.
> 
>> Another broke support for older kernels for no apparent benefit (and
>> this sort of regression naturally enters sys-fs/udev):
> 
> That isn't really the same as "breaking Gentoo."  And as was pointed
> out they did accept patches to provide support back.

That is a new development.

> I think it is a bit unfair to characterize the udev maintainers as
> breaking things left and right.  They apparently differ with you in
> how they prefer to set their defaults, and what their dependencies
> are.  They apparently also accept patches when you provide them for
> older kernels, which is what upstreams are supposed to do.

There were multiple incidents where either the sys-fs/udev maintainers
or the systemd developers refused to listen to reason. Systems broke
because of it and there were no warnings.

> It really seems like the main reasons for eudev's existence right now
> are (based on this thread):
> 1.  The eudev maintainers don't trust the udev maintainer's QA and
> want to do their own layer of QA before introducing changes to the
> tree.
> 2.  The eudev maintainers prefer a different default network interface
> naming scheme (my understanding is that eudev can be configured to
> behave as udev does by default, and vice-versa - for example, on the
> box I'm typing this on my packets are going out over eth0 just fine on
> systemd).
> 3.  The eudev tarballs are smaller lacking the systemd components, and
> the udev build system doesn't have to build the systemd components (I
> don't think the same is true of udev but I could be wrong).
> 
> I'm not saying that eudev should go away, or that these concerns are
> completely 

Re: [gentoo-dev] games.eclass policy

[Denis Dupeyron]

On Wed, Feb 17, 2016 at 11:38 AM, Michał Górny  wrote:
>
> Well, maybe it's because you can talk to Python team, discuss and not
> get ignored by them.


We've already established the same is true for the games team. I'm a living
example of it and I can't imagine I'm the only one.


> Unlike games team members who believe it's best to
> ignore certain developers.


I certainly hope we can still ignore abrasive developers since it's been
proven many times that it's the best way to deal with them.

So, you don't answer my question. Or rather, you answer with a specious
statement. Since you're being unusually shy I will say what you're trying
hard not so say. There are actually first-class projects catered for by
first-class developers, and those can set rules like the mandatory use of
an eclass and actually enforce them. Then there are second-class projects
and developers who can do the same as long as it doesn't bother the
first-class people. Second-class developers, often working quietly and
steadily, not wasting their time on mailing-lists like I just did, can see
their projects trampled over at any time for the mere reason that they were
trying to keep their business in order, just like first-class developers do.

Thank you for the clarification.

Denis.

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

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/17/2016 04:43 AM, Michał Górny wrote:
> 
> [snip]
> 
> If Lennart's single statement from 2014 is a reason to use eudev 
> instead of systemd-udevd, my statement from today is a more
> important reason not to use eudev.
> 

That's kind of a false equivalence. Unlike Lennart, you are not the
primary developer or maintainer of what your (sarcastic) claim
indicates. Lennart's "single statement" has been backed up with every
large change made to systemd or udev. With each change, it becomes
more strongly coupled and that much harder to separate. Regardless of
my or others' feelings on Lennart, he *has* acted on things he's said
in that regard, and it's foolish to assume udev without systemd will
remain an option.

If Anthony had said that instead, I and many others would have reason
for concern and likely respond by migrating, again, to something else.
While you and I are part of Gentoo and thus somewhat 'upstream' to
eudev users, we aren't active on the project (to my knowledge; from
what I gather you're a systemd user and have no interest in eudev; I
have interest but no relevant experience/skill). I hope I was able to
explain the difference.

Rich made a good point that maybe we shouldn't act until udev simply
stops working. I'd prefer a more proactive approach, but I see the
merit in waiting.

- -- 
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

iQIcBAEBCAAGBQJWxQ4cAAoJEAEkDpRQOeFwGwIP/Rdw0Y6E+94bZNMCw+CfIveX
bb32aqkIDiXIsJjYAdYnglwhWff4DpUy8hW6VJchV6O1avU3m7FL3FZ1y3Z0GQOy
lkMprvahBqTwpcjCObtyWjAizJsdRyB4YcU1rUli4x30WG9exmQI2xTY2c2hz1fW
BKfjq7HGn/gPT8FPlHEhRVwB52HQDC0u5dHM7PKr1mrwBTMwc+1we16i0G+zNT4e
E/HcPjo7z6MbGHQNJ596GEm9PUXM/WDK85xYAeH1T3ILT1df+bBaq11v8c37Su5f
QkUqFsmCQuPNKbY99IwHEreiq0UeqwBoJmjIsVcn+sIs9ZhjXy71+3drUVC7iE5u
4lgPyaDLBWNP3+4stj4bsqwGGU7i2mei21Sk3kK19PcOyaCPsj2Oo/ohr6+yTN6C
yESh0vkQMZf5+5PSABDiczRIRtD8U0e5HrfBDs1gLxXblUTPk9PnOhlwDUipdN0y
pBcQ++BrOcQjDosnyQP4jRJjqodKuPZow+oqgW+SaQ5RVAlTz8K16Dm17KNfIc6k
Dm8dbmtaCNO6cZZUPuTHT8jSihlB2gclFR1ALZvfDjb3ghYmwy8uGxiec4x5abvj
0gVlXCP41jblNSXM+Q9EWCj+ICTVc0DbGPshPZ96p7XtetttKk6gdf+PcQ1UDzaa
UJFt2emel44zfnlQKY+f
=D8/l
-END PGP SIGNATURE-

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

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:

systemd and udev share the same codebase. You can no longer build udev
without systemd. udev is only a sub-project of systemd now, hence the
name "systemd-udevd".


Of course, sure. But since you seem not to be able to understand
basics: this *does not* mean Lennart is the only person having
influence on how udev progresses. Sharing the same repository
and utility libraries is not the same as being the same thing.


Ok, apparently I am too dense to understand that the someone who is the lead 
developer and visionary of a project naturally has the same say as someone 
who is only bickering from the sidelines. Maybe if you had pointed out a 
systemd developer who disagreed with Lennart's words I could have seen the 
light earlier.


Also I am obviously unable to understand that when the kernel folks 
complained about the "new maintainers" of udev breaking things, they would of 
course never suspect that these "new maintainers" have anything to do with 
systemd at all.


http://thread.gmane.org/gmane.linux.kernel/1368617

Seriously. You gave good reasons why udev should remain the default over 
eudev, I acknowledged as much already. But do not continue the path of 
labelling your opponents as stupid and their arguments as FUD, because this 
is clearly not the case. It really doesn't help your argument, it just makes 
you look bad.




Best regards,
Chí-Thanh Christopher Nguyễn

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

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/17/2016 09:30 AM, James Le Cuirot wrote:
> On Wed, 17 Feb 2016 12:19:52 -0500 Rich Freeman 
> wrote:
> 
>> Is dracut still not widely used?  I know that it was all the
>> fashion for a decade or two for every distro to build their own
>> initramfs, but I don't get why anybody wouldn't just make the
>> switch - it is far more capable and configurable.
> 
> Does anyone know what most Gentoo users are doing these days? I
> don't recall the handbook mentioning initramfs at all back in 2002
> because it wasn't really needed back then. I did without for years
> until I finally put / on LVM. I used lvm2create_initrd for a while
> but that was still quite a manual process and I couldn't imagine
> going back to it now. I've switched to Dracut and it's great but I
> don't get the impression that Gentoo really endorses that option
> over the more laborious ones. Maybe it should?
> 
> https://wiki.gentoo.org/wiki/Initramfs
> 
I went without an initrd until I encrypted my / and put LVM inside it.
I used genkernel's initrd functions for that with a
manually-configured kernel.

- -- 
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

iQIcBAEBCAAGBQJWxOssAAoJEAEkDpRQOeFwtDUQANLipE7ZGNjf8lrstbl6/6GJ
bEwrQX+xFST5c7U9OJgU1HrGmL7vrYLurg82Sqf2zqzlsXdSPAxQtvAPETvPW8Gy
lbWdV1UaaCda5W53lX2XrKVf9xQgT8wANlgWQmFlsOnbCUbaLYYdQQWN/yuW+NQL
xV2V57EUOLCmQ4LNNG/zuoo7JrrfVikNavlk70Emq0DNpt+dPhHK9hc6N6zAeUc2
6oEFDB6ILf63ZE0v1dLOc+HxnIeAZ06GwLnx+1ta6o2hfoqPDBqym2V6lplRk1KF
xQeWllMNcl5ez3d+T8BP6sm0gkv0WPpVAMBm58IdxhX0ITqIVDo/A8zR+tp7x5U+
Ih5+2vjhoFmpr+8NVo2HHDHCddokzcqgd6ZL4ZA5RYYLF4JC755QntTGTKuGdU1e
nVYySqTnmzxXIzEaplixesgKiG70KBDfStmLGjIbxl+E8fyZkx6fNg1dP7/QMZUY
GF/HiO5dpEynDvsO1VgJY6cbFbHW0Ee1AWhZmvpT5eOZTUtCiipaHwGrS6Tds3N2
R4odNpPBvnV9G6EvGrQ6rtAcdH+j2XsVcFsaJZT+YOcvIZBT6UEg3YcucTNJELRE
OSJzROeVau4p82o5YJTqwPAqvu9TI39kJ13ps8pTqJuNrj+A33ag3jiPh8Azpfbo
APYj1uIIrl6OcOinlHt8
=0SBA
-END PGP SIGNATURE-

[gentoo-dev] games.eclass deprecation - repoman warning in next portage release

[Andreas K. Hüttel]

Dear all, 

while we have taken a lot of time and called for feedback repeatedly, in the 
December 2015 meeting the council has decided (among other things, see [1])
* that /usr/games and /etc/games should not be used anymore
* that games.eclass should not be used anymore
* that games.eclass may not provide support for EAPI=6

This is to announce that starting with the next portage release, repoman will 
consider games.eclass deprecated and issue a QA warning if it is used in an 
ebuild.

For the council, 
Andreas

[1] https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

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

[Rich Freeman]

On Wed, Feb 17, 2016 at 2:01 PM, Andrew Savchenko  wrote:
> 1) NFS v4 shares can't be unmounted if server is unreachable (even
> with -f). If filesystem (e.g. /home or /) contains such unmounted
> mount points, it can't be unmounted as well, because it is still in
> use. This happens quite often if both NFS server and client are
> running from UPS on low power event (when AC power failed and
> battery is almost empty).

Perhaps at least the behavior in this case should be configurable
(timeouts, infinite or otherwise).

If you can't contact a remote nfs server then I believe it is possible
that unwritten changes are in buffers/etc.  Depending on circumstances
I could see either pausing until the server comes back or discarding
changes and powering off could either be the appropriate behavior.

Ultimately, anything not on the disk is always at risk, and any
filesystem needs to provide for unclean shutdown to be truly robust.
A kernel panic/etc could cause loss of all data in buffers without
warning.  However, barring that we should of course engineer openrc to
shut down in the most clean manner possible, and this should include
read-only mounts for anything which can't be unmounted.

And even systemd+dracut struggles to cleanly unmount NFS roots in the
versions I'm running at least, so that is an edge case that doesn't
get much testing.

-- 
Rich

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

[Andrew Savchenko]

On Tue, 16 Feb 2016 15:18:46 -0500 Rich Freeman wrote:
> 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.

This is not always possible. Two practical cases from my experience:

1) NFS v4 shares can't be unmounted if server is unreachable (even
with -f). If filesystem (e.g. /home or /) contains such unmounted
mount points, it can't be unmounted as well, because it is still in
use. This happens quite often if both NFS server and client are
running from UPS on low power event (when AC power failed and
battery is almost empty).

2) LUKS device is in frozen state. I use this as a security
precaution if LUKS fails to unmount (or it takes too long), e.g.
due to dead mount point.

As far as I understand, mount-ro may be useful only if unmount
failed, but from my practical experience, openrc just hangs forever
in such case until UPS is shut down by battery drain.

Best regards,
Andrew Savchenko


pgpdPGCaiu6gC.pgp
Description: PGP signature

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

[Rich Freeman]

On Wed, Feb 17, 2016 at 11:04 AM, Richard Yao  wrote:
>
> This is something that I think many of us who had systems broken by
> sys-fs/udev multiple times before sys-fs/eudev was an option thought was
> obvious.

About the only "system-breaking" change I'm aware of in udev over the
years was the change in default network interface names.  That was
preceded by news on how to avoid the change, or how to adapt to the
change.

There certainly wasn't some change introduced without warning that
just broke systems in random ways.

> If a complete list of the breakages that lead to the creation of
> sys-fs/eudev were produced, I imagine that the list would have at least
> 3 to 5 items from the ~18 months before sys-fs/eudev with half of them
> were probably self inflicted by sys-fs/udev maintenance.

Anytime upstream changes something it is up to package maintainers to
evaluate the change and adapt to it as needed, especially for critical
packages like udev.  For the most part I think this is happening.
Whether it is the udev maintainers doing the QA or the eudev
maintainers doing the QA, somebody has to do the QA (and in Gentoo it
sounds like we do it twice, which is fine).

> I recall one incident involving whether udev should be in /sbin or
> /usr/sbin being resolved after 6 months of debate between then future
> eudev founders and sys-fs/udev maintainers only because the systemd
> developers told the sys-fs/udev maintainers it should be in /sbin like
> others had told them.

So, this sounds like a disagreement between the future eudev founders
and the udev maintainers in Gentoo.  It really has nothing to do with
udev itself.

And that is OK - we're allowed to have the same package maintained
under two different names by two sets of maintainers.  Obviously it
isn't ideal, and it would be better if everybody could agree.

> Another broke support for older kernels for no apparent benefit (and
> this sort of regression naturally enters sys-fs/udev):

That isn't really the same as "breaking Gentoo."  And as was pointed
out they did accept patches to provide support back.

I think it is a bit unfair to characterize the udev maintainers as
breaking things left and right.  They apparently differ with you in
how they prefer to set their defaults, and what their dependencies
are.  They apparently also accept patches when you provide them for
older kernels, which is what upstreams are supposed to do.

It really seems like the main reasons for eudev's existence right now
are (based on this thread):
1.  The eudev maintainers don't trust the udev maintainer's QA and
want to do their own layer of QA before introducing changes to the
tree.
2.  The eudev maintainers prefer a different default network interface
naming scheme (my understanding is that eudev can be configured to
behave as udev does by default, and vice-versa - for example, on the
box I'm typing this on my packets are going out over eth0 just fine on
systemd).
3.  The eudev tarballs are smaller lacking the systemd components, and
the udev build system doesn't have to build the systemd components (I
don't think the same is true of udev but I could be wrong).

I'm not saying that eudev should go away, or that these concerns are
completely inappropriate.  If somebody wanted to fork their own kernel
stable series and carefully curate patches they could choose to do so
and package it in Gentoo, and give it different default configuration
options, and so on.

-- 
Rich

Re: [gentoo-dev] games.eclass policy

[Michał Górny]

On Wed, 17 Feb 2016 11:08:30 -0700
Denis Dupeyron  wrote:

> On Wed, Feb 17, 2016 at 10:33 AM, Michał Górny  wrote:
> 
> > I was stating the apparent state of facts. If people are told they're
> > supposed to go with games team, use their eclass, follow their
> > policies, that's how it looks to people.  
> 
> 
> That's an entirely different point from the one I was making. But I'll
> entertain you anyway. All teams have rules and enforce them. If I commit,
> say, a python package and I don't use the python eclass, I'm sure to get a
> bug filed telling me to do so, a python team-member forcing the change on
> me if I refuse, this escalating to comrel if I complain or reverse the
> change, etc... So why would it be OK for the python team to coerce and not
> OK for the games team? In other words, why would the games team have less
> right to good housekeeping than the python team? Here python is just an
> example, I could have picked any other team.

Well, maybe it's because you can talk to Python team, discuss and not
get ignored by them. Unlike games team members who believe it's best to
ignore certain developers. Then QA team. Then the Council.

-- 
Best regards,
Michał Górny



pgpqIl5RLydal.pgp
Description: OpenPGP digital signature

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

[Rich Freeman]

On Wed, Feb 17, 2016 at 1:06 PM, Ian Stakenvicius  wrote:
>
> Genkernel's initramfs generation was what we endorsed for the most
> part, until dracut came around.  it's hard to say what "most" are
> doing but i expect dracut and genkernel based initramfs's make up
> the vast majority in use by gentoo users, with a small minority
> rolling their own through other means.
>

While I personally endorse dracut over genkernel, the reality is that
only genkernel is actually documented in the handbook.  This is due at
least in part to laziness on my part as I've been meaning to add it
since forever.

Likewise I intend to update the handbook to make selection of
openrc/systemd less convoluted as well.  The current handbook does
offer systemd as an option but then basically refers you out to
another page that doesn't follow the same flow as the handbook.

In my notes I've found that it is a pretty trivial change to pick one
or the other actually if you do it at the right time, so this could be
added to the handbook with very little disruption to the flow for
non-systemd users.  I imagine other service managers would be similar,
or even simpler.  I found that switching between the two only requires
two changes - one is to pick a systemd profile relatively early in the
process before doing a world update, and then changing one line in
your grub config at the end.  If you emerge world after you do most of
your system configuration systemd will automatically pick up all the
openrc configuration and use it, which as a bonus leaves you with a
system that is easy to boot in either mode.

Getting back to dracut - it is really just a few lines added as an
alternative to the initramfs section.  After you build your kernel it
is really just a one-liner, and grub2-mkconfig picks up on it
automatically (as I imagine it probably does with genkernel as well).
Unless you want to play with the configuration there isn't much fuss.

I think we really should give strong consideration to recommending
dracut as a default, while of course preserving the option of
genkernel.  I'm certainly open to feedback if there is some use case
where genkernel is better, but dracut is cross-distro, gives you
options to easily maximize or minimize your config, and is really easy
to tailor with modules.

-- 
Rich

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

[Richard Yao]

On 02/17/2016 11:16 AM, Michał Górny wrote:
> On Wed, 17 Feb 2016 14:38:05 +0100
> Chí-Thanh Christopher Nguyễn  wrote:
> 
>> Michał Górny schrieb:
 With the exception that Lennart Poettering is the lead developer of
 systemd/udev, while such a thing cannot be said about you and eudev.  
>>> He's lead developer of *systemd*. udev is a split part of systemd
>>> codebase which has specific maintainers.  
>>
>> systemd and udev share the same codebase. You can no longer build udev 
>> without systemd. udev is only a sub-project of systemd now, hence the 
>> name "systemd-udevd".
> 
> Of course, sure. But since you seem not to be able to understand
> basics: this *does not* mean Lennart is the only person having
> influence on how udev progresses. Sharing the same repository
> and utility libraries is not the same as being the same thing.
> 
> Much like the Council does not strictly force the development of eudev.
> 

According to _AxS_, there are very few differences between systemd-udev
and eudev at the present time:

16:14 <@_AxS_> At this point there really aren't much in terms of
differences -- most of the code is the same as upstream, but the file
structure is different and obviously the build system is proper and
standalone.  There's the rule-generator patchset but otherwise
   things are pretty well the same iirc.
16:14 <@_AxS_> We *did* have a bunch of other things in eudev that
improved matters for older kernels or just general code/memory
improvements, but those have since been integrated upstream iirc
16:15 <@ryao> _AxS_: I recall hearing that eudev regressed with respect
to 2.6.32. If the older versions were not good enough and I had time, I
would try fixing that.
16:16 <@ryao> _AxS_: It is interesting to hear that patches to support
older kernels are now being merged by them. Kay told me that such
patches would not be merged.
16:18 <@_AxS_> ryao: eudev-3.x doesn't support the older kernels, true.
 However we determined that was ok because (1) the older kernels like
openvz have had the appropriate functionality backported into them, and
(2) we're keeping the older eudev versions around.

The main differences at this time seem to be the rule-generator patchset
for users who like that, a better build system (what IcedTea is to
OpenJDK) and a stricter process for getting newer code. Specifically,
instead of just doing a revision bump with the implicit assumption that
it was tested, every change is reviewed and committed to a repository
that is tagged independently of systemd-udev.

If there are regressions because of something upstream did, which has
occurred in the past, and they made it into eudev, there is someone who
accepted the commit that is responsible for it. They should not only
have caught it, but they also should have put a plan in place for
dealing with it like was done with the regressed kernel version support.
If they did not, then the eudev project can revise its QA strategies to
ensure that it does not happen again. That is something that can only be
rigorously done with a separate project that imports code from a vendor
like FreeBSD does, which is precisely what eudev is.

That is clearly better than what we have with sys-fs/udev. Given that
the two are almost identical with sys-fs/eudev being better suited for
systems where PID 1 is not systemd, there really is no point in having
sys-fs/udev be the first provider for virtual/udev. There is also no
point in having sys-fs/udev become a separate package from systemd,
unless we decide to break every component of systemd from the part meant
to be PID 1 too, but that is contrary to what systemd upstream recommends.

If making sys-fs/eudev the default virtual/udev provider turns out to be
a bad decision, we can always revisit it, but it seems better than the
status quo that we have now. Having less review of new code is bad and
having systemd-udev split from the systemd package on systems that use
systemd makes no sense. If we continue having the split, systemd would
depend on sys-fs/udev and consequently the systemd profiles with systemd
in @system would be unaffected by whatever the provider order happens to be.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] games.eclass policy

[Denis Dupeyron]

On Wed, Feb 17, 2016 at 10:33 AM, Michał Górny  wrote:

> I was stating the apparent state of facts. If people are told they're
> supposed to go with games team, use their eclass, follow their
> policies, that's how it looks to people.


That's an entirely different point from the one I was making. But I'll
entertain you anyway. All teams have rules and enforce them. If I commit,
say, a python package and I don't use the python eclass, I'm sure to get a
bug filed telling me to do so, a python team-member forcing the change on
me if I refuse, this escalating to comrel if I complain or reverse the
change, etc... So why would it be OK for the python team to coerce and not
OK for the games team? In other words, why would the games team have less
right to good housekeeping than the python team? Here python is just an
example, I could have picked any other team.

Denis.

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

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 17/02/16 12:30 PM, James Le Cuirot wrote:
> On Wed, 17 Feb 2016 12:19:52 -0500 Rich Freeman
>  wrote:
> 
>> Is dracut still not widely used?  I know that it was all the
>> fashion for a decade or two for every distro to build their own
>> initramfs, but I don't get why anybody wouldn't just make the
>> switch - it is far more capable and configurable.
> 
> Does anyone know what most Gentoo users are doing these days? I
> don't recall the handbook mentioning initramfs at all back in
> 2002 because it wasn't really needed back then. I did without for
> years until I finally put / on LVM. I used lvm2create_initrd for
> a while but that was still quite a manual process and I couldn't
> imagine going back to it now. I've switched to Dracut and it's
> great but I don't get the impression that Gentoo really endorses
> that option over the more laborious ones. Maybe it should?
> 
> https://wiki.gentoo.org/wiki/Initramfs
> 

Genkernel's initramfs generation was what we endorsed for the most
part, until dracut came around.  it's hard to say what "most" are
doing but i expect dracut and genkernel based initramfs's make up
the vast majority in use by gentoo users, with a small minority
rolling their own through other means.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlbEtr0ACgkQAJxUfCtlWe3/xwD+P4OlCY0RuTdGdPWOGRd8ePLi
EvZCZuyp2oxPdYt6xdAA/2CN/Nbgj4bVFa02KeVpuoNOHMErPU4meZfzUjNbGmTH
=iUu6
-END PGP SIGNATURE-

Re: [gentoo-dev] games.eclass policy

[Michał Górny]

On Wed, 17 Feb 2016 10:19:24 -0700
Denis Dupeyron  wrote:

> On Wed, Feb 17, 2016 at 9:22 AM, Michał Górny  wrote:
> 
> > On Wed, 17 Feb 2016 08:32:53 -0700
> > Denis Dupeyron  wrote:  
> > >  Not true. I've been maintaining games for a decade and have never been  
> > on  
> > > the team.  
> >
> > Quoting the previous documentation of games.eclass [...]
> >  
> 
> I'm not seeing the connection you make between the documentation of an
> eclass and the fact that I have been maintaining games for ten years
> without being part of the games team. From here it looks like you're typing
> faster than you can read.

I was stating the apparent state of facts. If people are told they're
supposed to go with games team, use their eclass, follow their
policies, that's how it looks to people.

Now, the fact that you had achieved otherwise doesn't mean others felt
forced to adhere to that.

-- 
Best regards,
Michał Górny



pgpZFYiaciyZq.pgp
Description: OpenPGP digital signature

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

[James Le Cuirot]

On Wed, 17 Feb 2016 12:19:52 -0500
Rich Freeman  wrote:

> Is dracut still not widely used?  I know that it was all the fashion
> for a decade or two for every distro to build their own initramfs, but
> I don't get why anybody wouldn't just make the switch - it is far more
> capable and configurable.

Does anyone know what most Gentoo users are doing these days? I don't
recall the handbook mentioning initramfs at all back in 2002 because it
wasn't really needed back then. I did without for years until I finally
put / on LVM. I used lvm2create_initrd for a while but that was still
quite a manual process and I couldn't imagine going back to it now.
I've switched to Dracut and it's great but I don't get the impression
that Gentoo really endorses that option over the more laborious ones.
Maybe it should?

https://wiki.gentoo.org/wiki/Initramfs

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] games.eclass policy

[Denis Dupeyron]

On Wed, Feb 17, 2016 at 9:22 AM, Michał Górny  wrote:

> On Wed, 17 Feb 2016 08:32:53 -0700
> Denis Dupeyron  wrote:
> >  Not true. I've been maintaining games for a decade and have never been
> on
> > the team.
>
> Quoting the previous documentation of games.eclass [...]
>

I'm not seeing the connection you make between the documentation of an
eclass and the fact that I have been maintaining games for ten years
without being part of the games team. From here it looks like you're typing
faster than you can read.

Denis.

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

[Rich Freeman]

On Wed, Feb 17, 2016 at 9:24 AM, Richard Yao  wrote:
> Systemd installs that go back into the initramfs at shutdown are rare because 
> there is a
> hook for the initramfs to tell systemd that it should re-exec it and very few 
> configurations
> do that. Even fewer that do it actually need it.

While I won't debate that it probably isn't strictly essential, dracut
handles unmounting root for systemd just fine (well, at least on
non-nfs - the version I'm using with an nfs root struggles in this
regard, though unclean shutdown on nfs with no files open probably
isn't really a problem).

Is dracut still not widely used?  I know that it was all the fashion
for a decade or two for every distro to build their own initramfs, but
I don't get why anybody wouldn't just make the switch - it is far more
capable and configurable.


-- 
Rich

Re: [gentoo-dev] games.eclass policy

[Michał Górny]

On Wed, 17 Feb 2016 08:32:53 -0700
Denis Dupeyron  wrote:

> On Wed, Feb 17, 2016 at 12:39 AM, Michał Górny  wrote:
> > games team sole claim to games in gentoo.
> >  
> 
>  Not true. I've been maintaining games for a decade and have never been on
> the team.

Quoting the previous documentation of games.eclass, before hasufell
changed it:

# This is the games eclass for standardizing the install of games ...
# you better have a *good* reason why you're *not* using games.eclass
# in a games-* ebuild

And this is just one piece of the puzzle. I don't have time to gather
all other past evidence. Nevertheless, it's just past.

-- 
Best regards,
Michał Górny



pgpkoL4mpBPR8.pgp
Description: OpenPGP digital signature

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

[Michał Górny]

On Wed, 17 Feb 2016 14:38:05 +0100
Chí-Thanh Christopher Nguyễn  wrote:

> Michał Górny schrieb:
> >> With the exception that Lennart Poettering is the lead developer of
> >> systemd/udev, while such a thing cannot be said about you and eudev.  
> > He's lead developer of *systemd*. udev is a split part of systemd
> > codebase which has specific maintainers.  
> 
> systemd and udev share the same codebase. You can no longer build udev 
> without systemd. udev is only a sub-project of systemd now, hence the 
> name "systemd-udevd".

Of course, sure. But since you seem not to be able to understand
basics: this *does not* mean Lennart is the only person having
influence on how udev progresses. Sharing the same repository
and utility libraries is not the same as being the same thing.

Much like the Council does not strictly force the development of eudev.

-- 
Best regards,
Michał Górny



pgp4CI5xpRJhX.pgp
Description: OpenPGP digital signature

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

[Richard Yao]

On 02/17/2016 09:54 AM, brettrse...@gmail.com wrote:
>  
> Sent from my Verizon Wireless BlackBerry
> 
> -Original Message-
> From: Ben Kohler 
> Date: Wed, 17 Feb 2016 08:01:32 
> To: 
> Reply-to: gentoo-dev@lists.gentoo.org
> Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider
> 
> On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao  wrote:
> 
>>
>>
>> eudev has every commit scrutinized by people who care about using it on
>> Gentoo. systemd-udev does not. Consequently, eudev has avoided the system
>> boot breaking regressions that prompted its creation. That is a good reason
>> to make it the new default. If it fails to fulfill its duties, then this
>> could be revisited, but that should be unlikely.
>>
>> I think if someone could enumerate those specific breakages and present it
> as evidence, that could get more people on board for this change.  Moreso
> than just "upstream doesn't care about us" or "eventually split udev will
> be impossible".
> 
> -Ben
> 

This is something that I think many of us who had systems broken by
sys-fs/udev multiple times before sys-fs/eudev was an option thought was
obvious.

If a complete list of the breakages that lead to the creation of
sys-fs/eudev were produced, I imagine that the list would have at least
3 to 5 items from the ~18 months before sys-fs/eudev with half of them
were probably self inflicted by sys-fs/udev maintenance.

I recall one incident involving whether udev should be in /sbin or
/usr/sbin being resolved after 6 months of debate between then future
eudev founders and sys-fs/udev maintainers only because the systemd
developers told the sys-fs/udev maintainers it should be in /sbin like
others had told them.

Another broke support for older kernels for no apparent benefit (and
this sort of regression naturally enters sys-fs/udev):

https://github.com/gentoo/eudev/commit/eeb8d70a6b38f736febaa4c3b03e39b4c1193a6c

There were other issues too, but I am unable to volunteer the time
required to go through history to figure out what was broken, when and
for how long.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] Wiki updates

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I wibbled the ongoing-todo-list[0] slightly. We should add any
long-standing bugs to the "specific bugs" list, and we should try to
come up with some low-hanging fruit to attract newcomers.

[0]  
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWxJZzAAoJENQqWdRUGk8BPvoP/3lxmOe8COz/01UmU6itWBqE
DCtHIRGpBldtrfpfwRA/cmtNwxBAK7e++FEWM1wzH5hVAyfo6SelCJeKuuDEo9RH
uZCNDNFvzCZYTURfXX/Olq5BhkW5G9BSnz3/bI2oGtCcdt4w+io7vlLAPJohl7my
FPX4Qo2TS7Yz/YsX3fSN04NfrnvRnzH1tmUVCJkxc2PTiI1Ba22hK9P5E/+q2l0T
nh3NkFzZ2GuDNXIuO7cUe3flhkl4zibUwHtbCRapuPqd6CwKizjlIe0At0fxNnDU
LwAuBI27y7INCG3rRxZTaV/dSyZxkrFyW4Z5MHiUTP8J2Jkndx8RCZ968i/rzAgd
yuis0BemPay4UYJUbBt2gdgHOI9vdOK2YGR8LDkT+IkUgx1brThhcm7CjcKe0p9Y
DI5GAnOeFqTxl/5ByLyLbPai++BFpwMp7a+zD8LoNZZjimI5igrHWVGbcTPXvo6d
AOhrCgLLX+tPX/oZCvpa8mbJFa8eylUtvX2jDZz/es6U0C+d91eCa4ojRUZHGi03
qT9fhu1DlC2C1403P5tg6g3rF1P4OViJeiIgLN0+kU7GuZ3vvVOioEWBW6xIOZil
AADO8bCEERe/abc1fxI+qr3ZgNatfm2UN8CsJEIp7KqxAnPQoDlHRblBDcI61TkD
WJlQ38KHarLUAuzhruWj
=rZ04
-END PGP SIGNATURE-

Re: [gentoo-dev] games.eclass policy

[Denis Dupeyron]

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

> developers who did what they cared about and ignored everything and
> everyone else.
>

I don't know if I'm an exception to the rule, but I've always had fruitful
interactions with the games team. I never felt they ignored me.


> games team sole claim to games in gentoo.
>

 Not true. I've been maintaining games for a decade and have never been on
the team.

Denis.

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

[brettrsears]

 
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Ben Kohler 
Date: Wed, 17 Feb 2016 08:01:32 
To: 
Reply-to: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider

On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao  wrote:

>
>
> eudev has every commit scrutinized by people who care about using it on
> Gentoo. systemd-udev does not. Consequently, eudev has avoided the system
> boot breaking regressions that prompted its creation. That is a good reason
> to make it the new default. If it fails to fulfill its duties, then this
> could be revisited, but that should be unlikely.
>
> I think if someone could enumerate those specific breakages and present it
as evidence, that could get more people on board for this change.  Moreso
than just "upstream doesn't care about us" or "eventually split udev will
be impossible".

-Ben

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

[Richard Yao]

> On Feb 17, 2016, at 9:41 AM, Richard Yao  wrote:
> 
> 
>> On Feb 17, 2016, at 9:01 AM, Ben Kohler  wrote:
>> 
>> 
>> 
>>> On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao  wrote:
>>> 
>>> 
>>> eudev has every commit scrutinized by people who care about using it on 
>>> Gentoo. systemd-udev does not. Consequently, eudev has avoided the system 
>>> boot breaking regressions that prompted its creation. That is a good reason 
>>> to make it the new default. If it fails to fulfill its duties, then this 
>>> could be revisited, but that should be unlikely.
>> I think if someone could enumerate those specific breakages and present it 
>> as evidence, that could get more people on board for this change.  Moreso 
>> than just "upstream doesn't care about us" or "eventually split udev will be 
>> impossible".
> 
> That would require more time than I have to give right now. Hopefully someone 
> else could go through the old bug reports and IRC logs to find those records.

I forgot to mention commit histories. The change log on CVS for sys-fs/udev 
should provide information on things that were broken for long spans of time if 
the causes of the fixes are scrutinized while commits to eudev fixing things 
that were broken (and likely still are) would also document things. At least 
some of the early ones under my name were rejected by systemd. They went into 
eudev when it was created.
> 
>> -Ben

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

[Richard Yao]

> On Feb 17, 2016, at 9:01 AM, Ben Kohler  wrote:
> 
> 
> 
>> On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao  wrote:
>> 
>> 
>> eudev has every commit scrutinized by people who care about using it on 
>> Gentoo. systemd-udev does not. Consequently, eudev has avoided the system 
>> boot breaking regressions that prompted its creation. That is a good reason 
>> to make it the new default. If it fails to fulfill its duties, then this 
>> could be revisited, but that should be unlikely.
> I think if someone could enumerate those specific breakages and present it as 
> evidence, that could get more people on board for this change.  Moreso than 
> just "upstream doesn't care about us" or "eventually split udev will be 
> impossible".

That would require more time than I have to give right now. Hopefully someone 
else could go through the old bug reports and IRC logs to find those records.

> -Ben

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

[Richard Yao]

> On Feb 16, 2016, at 9:20 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> 
> 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.

Systemd installs that go back into the initramfs at shutdown are rare because 
there is a hook for the initramfs to tell systemd that it should re-exec it and 
very few configurations do that. Even fewer that do it actually need it.

The biggest user of that mechanism of which I am aware is ZFS on EL/Fedora when 
booted with Dracut. It does not need it and it was only implemented was that 
someone who did not understand how ZFS was designed to integrate with the boot 
and startup processes thought it was a good idea.

As it turns out, that behavior actually breaks the mechanism intended to make 
multipath sane by marking the pool in such a way that it tells all systems with 
access to the disks that a pool that will be used on next boot is not going to 
be used by anyone. If they import it and the system boots, the pool can be 
damaged beyond repair.

Thankfully, no one seems to boot EL/Fedora systems off ZFS pools in multipath 
environments. The code to hook into this special behavior will be removed in 
the future, but that is a low priority as none of the developers' employers 
care about it and the almost negligible possibility that the mechanism would 
save someone from data loss  has made it too low of a priority for any of us to 
spend our free time on it.

> 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 

[gentoo-dev] BOINC needs maintainer

[Justin Lecher (jlec)]

Hi,

currently BOINC supposed to be maintained by the science team, but we
are not really carrying about it. Is there anyone around whole likes to
take this over?

Thanks for your help,

Justin



signature.asc
Description: OpenPGP digital signature

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

[Richard Yao]

> On Feb 16, 2016, at 3:18 PM, Rich Freeman  wrote:
> 
>> 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.

Agreed.
> 
> -- 
> Rich
> 

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

[Richard Yao]

> On Feb 16, 2016, at 1:41 PM, William Hubbs  wrote:
> 
>> 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.

One idea proposed by systemd that is almost never used in production is to fall 
back to an initramfs environment to undo the boot process by umounting /. It 
would not surprise me if the normal case were hard coded to remount / as ro 
because you risk filesystem corruption otherwise. Journaling filesystems are 
fairly good at surviving that, but you are still taking a risk due to partial 
writes and anyone using ext2 would be taking a much bigger gamble.
> 
> William

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

[Richard Yao]

> On Feb 16, 2016, at 1: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].
> 
> 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.

If you shutdown the system while ext4 or XFS is mounted rw, then there is no 
guarantee that dirty data writeout finishes and you can get situations where 
partial writes to disks from power being cut at the end of the shutdown process 
kills the filesystem.

That said, ZFS does not need to be remounted rw because it is an atomic 
filesystem. There might be data loss, but it would only be the last 5 seconds 
of unsynced data (which is safe to use) and there would be no risk of killing 
it.

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

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

[Richard Yao]

> On Feb 17, 2016, at 8:47 AM, Ben Kohler  wrote:
> 
> 
> 
>> On Wed, Feb 17, 2016 at 7:39 AM, Richard Yao  wrote:
>> 
>> I have no idea why we are even discussing the choice of default for 
>> virtual/udev to have subdiscussions about kdbus. Practically everyone on the 
>> list thinks eudev is the best choice.
> 
> I think a lot of us appreciate that eudev exists as a lifeboat or backup 
> plan, but want to wait until there's a real, obvious, technical reason to 
> switch.  MOST of the reasons given have just been vague predictions of future 
> doom and gloom.  And if we dare ask for more technical reasons, we get 
> berated for being a "systemd lover".
> 
> "Let's wait until udev becomes unusable" doesn't seem that unreasonable to 
> me, and it has nothing to do with being pro or anti systemd.

eudev has every commit scrutinized by people who care about using it on Gentoo. 
systemd-udev does not. Consequently, eudev has avoided the system boot breaking 
regressions that prompted its creation. That is a good reason to make it the 
new default. If it fails to fulfill its duties, then this could be revisited, 
but that should be unlikely.

> 
> -Ben
> 

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

[Ben Kohler]

On Wed, Feb 17, 2016 at 7:39 AM, Richard Yao  wrote:
>
>
> I have no idea why we are even discussing the choice of default for
> virtual/udev to have subdiscussions about kdbus. Practically everyone on
> the list thinks eudev is the best choice.
>

I think a lot of us appreciate that eudev exists as a lifeboat or backup
plan, but want to wait until there's a real, obvious, technical reason to
switch.  MOST of the reasons given have just been vague predictions of
future doom and gloom.  And if we dare ask for more technical reasons, we
get berated for being a "systemd lover".

"Let's wait until udev becomes unusable" doesn't seem that unreasonable to
me, and it has nothing to do with being pro or anti systemd.

-Ben

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

[Rich Freeman]

On Tue, Feb 16, 2016 at 9:20 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Initial shutdown is via two targets (as opposed to specific services),

Since not everybody in this thread may be familiar with systemd, I'll
just add a quick definition.

When systemd says "target" - think "virtual service."  The equivalent
in openrc would be an init.d script that has dependencies but which
doesn't actually launch any processes.

Targets also take the place of runlevels in systemd.

Just as with runlevels in openrc they are used to synchronize
milestones during bootup, but the design is much more generic.
Presumably openrc hard-codes runlevels like sysinit, boot, and
default.  In systemd I believe it just looks at the config file and
directly launches the desired target, and then the dependency chain
for that pulls in all the targets that precede it.  Targets can depend
on other targets, and services can depend on previous targets.

The other dimension is that unit files describe what target they are
typically associated with if it isn't the default.  So, you don't run
into the sorts of situations you have with openrc that if you want to
enable mdraid support you need to remember to add it to the boot
runlevel.  That might be a relatively-easy thing to add support for in
openrc actually.

Hopefully that makes Dunan's summary easier to read for anybody who
doesn't speak systemdese.

Another bit of background that might be helpful is that systemd also
manages mounts directly.  It parses fstab and creates a network of
mount units with appropriate dependencies.  Whether you unmount
/var/tmp using "umount /var/tmp" or "systemctl stop var-tmp.mount"
systemd updates the status of the var-tmp.mount unit to a stopped
status.  I believe if you add a noauto line to fstab it will create a
mount unit automatically and not start it, and if you made it mount on
boot I think it would actually be mounted as soon as you save the file
in your editor (systemd can monitor config files for changes - all of
this is governed by scripts/software called generators).

So, systemd in general tries to stay aware of the state of mounts.  I
suspect that isn't just firing off a script to find/unmount anything
that is mounted.  From Dunan's email it sounds like you could create a
mount unit and explicitly not set a conflict with the unmount target
which would cause the filesystem to remain mounted at shutdown.  I
have no idea what that would do to unmounting the root.

-- 
Rich

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

[Richard Yao]

> On Feb 17, 2016, at 5:52 AM, Alexis Ballier  wrote:
> 
> On Tue, 16 Feb 2016 23:00:27 -0500
> Richard Yao  wrote:
> 
>>> 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. :)
> 
> I don't know docker well enough, but an lxc container definitely doesn't
> use udev inside the container.

There really is no point to running udev inside the container, but if you do 
run udev in an Alpine Linux docker container, you get eudev.

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

[M. J. Everitt]

On 17/02/16 13:38, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
>>> With the exception that Lennart Poettering is the lead developer of
>>> systemd/udev, while such a thing cannot be said about you and eudev.
>> He's lead developer of *systemd*. udev is a split part of systemd
>> codebase which has specific maintainers.
>
> systemd and udev share the same codebase. You can no longer build udev
> without systemd. udev is only a sub-project of systemd now, hence the
> name "systemd-udevd".
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>
How hard is it to understand that there really is no longer a standalone
udev .. it's part of another project .. therefore no longer separate.
One of the developers already works for systemd. The other is clearly
busy with kernel coding.

My two cents for today:

https://en.wikipedia.org/wiki/Udev
http://without-systemd.org/wiki/index.php/Main_Page

+5 for Chi-Thanh for keeping it factual and objective.

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

[Richard Yao]

> On Feb 17, 2016, at 7:58 AM, Michał Górny  wrote:
> 
> On Wed, 17 Feb 2016 07:53:22 -0500
> Richard Yao  wrote:
> 
>>> On Feb 17, 2016, at 7:43 AM, Michał Górny  wrote:
>>> 
>>> On Tue, 16 Feb 2016 23:41:33 +0100
>>> Chí-Thanh Christopher Nguyễn  wrote:
>>> 
 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.  
>>> 
>>> You're missing the third option which is a sane option, and jump
>>> straight to pitchforks.
>>> 
>>> As I see it, *if* this becomes a necessity, we're quite like are going
>>> to provide KDBUS parts of systemd the way we provide udev parts right
>>> now. After all, libsystemd-bus will be useful to more applications.
>>> 
>>> Of course, someone may want to fork that into libebus just for the sake
>>> of renaming.
>>> 
>>> And after all, as it has already been noted, there are people
>>> interested in maintaining non-systemd userspace for KDBUS. Which is
>>> kinda the obvious choice, unlike forking something.  
>> 
>> kdbus is dead. It is fatally flawed and Greg is no longer trying to get it 
>> merged as he is not updating his branch for newer kernel versions. If I 
>> recall correctly, kdbus was also removed from Fedora and has no distribution 
>> backing it anymore.
> 
> Then... why are we even discussing this?

I have no idea why we are even discussing the choice of default for 
virtual/udev to have subdiscussions about kdbus. Practically everyone on the 
list thinks eudev is the best choice. From the perspective of the Linux 
community going forward through docker, eudev is the only sensible choice for a 
udev-based system for those that want to use the same code everyone else uses.

All arguments about systemd are akin to arguments about how Windows 10 is the 
next thing in desktops in a world dominated by POSIX through iOS and Android. 
Coincidentally, neither use systemd.

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

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:

With the exception that Lennart Poettering is the lead developer of
systemd/udev, while such a thing cannot be said about you and eudev.

He's lead developer of *systemd*. udev is a split part of systemd
codebase which has specific maintainers.


systemd and udev share the same codebase. You can no longer build udev 
without systemd. udev is only a sub-project of systemd now, hence the 
name "systemd-udevd".



Best regards,
Chí-Thanh Christopher Nguyễn

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

[Michał Górny]

On Wed, 17 Feb 2016 14:09:57 +0100
Chí-Thanh Christopher Nguyễn  wrote:

> Michał Górny schrieb:
> >> 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.  
> > You're missing the third option which is a sane option, and jump
> > straight to pitchforks.  
> 
> Are you serious? The quoted line directly above your comment shows 
> clearly that I have read and understood the third option.
> 
> > If Lennart's single statement from 2014 is a reason to use eudev
> > instead of systemd-udevd, my statement from today is a more important
> > reason not to use eudev.  
> 
> With the exception that Lennart Poettering is the lead developer of 
> systemd/udev, while such a thing cannot be said about you and eudev.

He's lead developer of *systemd*. udev is a split part of systemd
codebase which has specific maintainers.

-- 
Best regards,
Michał Górny



pgpMpi_G7A2Pi.pgp
Description: OpenPGP digital signature

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

[Richard Yao]

> On Feb 17, 2016, at 1:37 AM, Michał Górny  wrote:
> 
> 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.

That kind of breakage is the reason eudev exists. If it did not occur, I would 
have not organized people to start eudev a few years ago. Part of the 
motivation was inflicted by the sys-fs/udev maintainers at the time, but 
systemd upstream did it's fair share by rejecting compatibility patches on the 
basis that only downstream should handle those. eudev was founded to be that 
downstream and also be upstream as sys-fs/udev refused to take patches that 
systemd would not take.
> 
>> 
>>> 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.

Go back and look at logs of me talking to WilliamH and talking in #systemd in 
the year before eudev was founded. There were problems with separate user among 
others. By the time, eudev was started, it was a wonder why it was not started 
earlier.
> 
>>> 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.

What documentation do you mean? As far as I know, udev documentation had always 

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

[Richard Yao]

> On Feb 17, 2016, at 5:34 AM, Michał Górny  wrote:
> 
> Dnia 17 lutego 2016 05:00:27 CET, Richard Yao  napisał(a):
>>> 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. :)
> 
> Oh, the new thing every cool kid users these days. I have only one question 
> in return: for how long?
> 
> Today Alpine uses eudev. But people change, distributions change. One year 
> from now, it may be using systemd.
> 
> Today docker uses Alpine. Tomorrow it may use something else. Or even require 
> systemd by design.

The Alpine Linux developers use eudev where mdev is a pain to use and prefer 
mdev to it. They also prefer busybox init to just about everything else. The 
only way Alpine Linux would use systemd is if it were merged into busybox, but 
the busybox developers dropped systemd support last year because the systemd 
developers were not great at collaborating. The "busybox is a joke" remarks 
that I got from them before that happen means that they have been actively 
sabotaging that relationship for a long time.

I think it is safe to assume that Redhat will drop Linux for Windows before 
Alpine Linux uses systemd.

> Today docker is the cool thing. One year from now, nobody may remember about 
> it. Didn't things like this happen before?

The iPhone did the same thing to Windows. Then Android came along. Neither 
contribute to Windows hemomgeny, which is dead. The same is true for systemd. 
Coincidentally, neither Android nor iOS use systemd.

> Now, let's extend this to a perspective of few years. What is more likely to 
> be extinct: userbase of eudev or systemd?

systemd will always have its niche. The same is true for eudev. The latter will 
always exist as long the the former exists though as there are too many people 
who have been alienated by systemd development for them to accept a system 
running it.

That is unlikely that will change unless developers who the systemd developers 
alienate were to all die at once.

 
 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.
> 
> 
> -- 
> Best regards,
> Michał Górny (by phone)
> 

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

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:

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.

You're missing the third option which is a sane option, and jump
straight to pitchforks.


Are you serious? The quoted line directly above your comment shows 
clearly that I have read and understood the third option.



If Lennart's single statement from 2014 is a reason to use eudev
instead of systemd-udevd, my statement from today is a more important
reason not to use eudev.


With the exception that Lennart Poettering is the lead developer of 
systemd/udev, while such a thing cannot be said about you and eudev.



Best regards,
Chí-Thanh Christopher Nguyễn

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

[Alexis Ballier]

On Wed, 17 Feb 2016 13:58:51 +0100
Michał Górny  wrote:

> On Wed, 17 Feb 2016 07:53:22 -0500
> Richard Yao  wrote:
> 
> > > On Feb 17, 2016, at 7:43 AM, Michał Górny 
> > > wrote:
> > > 
> > > On Tue, 16 Feb 2016 23:41:33 +0100
> > > Chí-Thanh Christopher Nguyễn  wrote:
> > > 
> > >> 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.
> > > 
> > > You're missing the third option which is a sane option, and jump
> > > straight to pitchforks.
> > > 
> > > As I see it, *if* this becomes a necessity, we're quite like are
> > > going to provide KDBUS parts of systemd the way we provide udev
> > > parts right now. After all, libsystemd-bus will be useful to more
> > > applications.
> > > 
> > > Of course, someone may want to fork that into libebus just for
> > > the sake of renaming.
> > > 
> > > And after all, as it has already been noted, there are people
> > > interested in maintaining non-systemd userspace for KDBUS. Which
> > > is kinda the obvious choice, unlike forking something.
> > 
> > kdbus is dead. It is fatally flawed and Greg is no longer trying to
> > get it merged as he is not updating his branch for newer kernel
> > versions. If I recall correctly, kdbus was also removed from Fedora
> > and has no distribution backing it anymore.  
> 
> Then... why are we even discussing this?
> 

because s/kdbus/bus1/

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

[Richard Yao]

> On Feb 17, 2016, at 7:25 AM, Rich Freeman  wrote:
> 
>> On Tue, Feb 16, 2016 at 11:00 PM, Richard Yao  wrote:
>> 
>> 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.
> 
> Uh, if we cared solely about userbase we'd be using upstart.  I'm
> pretty sure that there are more chromebooks out there than Docker
> containers running Alpine linux.
> 
> Do people actually use docker images created by docker?

They do. Docker is popular because it enables developers to start microservices 
from prebuilt images. Those images by default are Alpine Linux, which means 
anything using udev in them is using eudev.

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

[Michał Górny]

On Wed, 17 Feb 2016 07:53:22 -0500
Richard Yao  wrote:

> > On Feb 17, 2016, at 7:43 AM, Michał Górny  wrote:
> > 
> > On Tue, 16 Feb 2016 23:41:33 +0100
> > Chí-Thanh Christopher Nguyễn  wrote:
> >   
> >> 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.  
> > 
> > You're missing the third option which is a sane option, and jump
> > straight to pitchforks.
> > 
> > As I see it, *if* this becomes a necessity, we're quite like are going
> > to provide KDBUS parts of systemd the way we provide udev parts right
> > now. After all, libsystemd-bus will be useful to more applications.
> > 
> > Of course, someone may want to fork that into libebus just for the sake
> > of renaming.
> > 
> > And after all, as it has already been noted, there are people
> > interested in maintaining non-systemd userspace for KDBUS. Which is
> > kinda the obvious choice, unlike forking something.  
> 
> kdbus is dead. It is fatally flawed and Greg is no longer trying to get it 
> merged as he is not updating his branch for newer kernel versions. If I 
> recall correctly, kdbus was also removed from Fedora and has no distribution 
> backing it anymore.

Then... why are we even discussing this?

-- 
Best regards,
Michał Górny



pgp_8h5x6FqVM.pgp
Description: OpenPGP digital signature

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

[Richard Yao]

> On Feb 17, 2016, at 7:43 AM, Michał Górny  wrote:
> 
> On Tue, 16 Feb 2016 23:41:33 +0100
> Chí-Thanh Christopher Nguyễn  wrote:
> 
>> 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.
> 
> You're missing the third option which is a sane option, and jump
> straight to pitchforks.
> 
> As I see it, *if* this becomes a necessity, we're quite like are going
> to provide KDBUS parts of systemd the way we provide udev parts right
> now. After all, libsystemd-bus will be useful to more applications.
> 
> Of course, someone may want to fork that into libebus just for the sake
> of renaming.
> 
> And after all, as it has already been noted, there are people
> interested in maintaining non-systemd userspace for KDBUS. Which is
> kinda the obvious choice, unlike forking something.

kdbus is dead. It is fatally flawed and Greg is no longer trying to get it 
merged as he is not updating his branch for newer kernel versions. If I recall 
correctly, kdbus was also removed from Fedora and has no distribution backing 
it anymore.

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

[Michał Górny]

On Tue, 16 Feb 2016 23:41:33 +0100
Chí-Thanh Christopher Nguyễn  wrote:

> 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.

You're missing the third option which is a sane option, and jump
straight to pitchforks.

As I see it, *if* this becomes a necessity, we're quite like are going
to provide KDBUS parts of systemd the way we provide udev parts right
now. After all, libsystemd-bus will be useful to more applications.

Of course, someone may want to fork that into libebus just for the sake
of renaming.

And after all, as it has already been noted, there are people
interested in maintaining non-systemd userspace for KDBUS. Which is
kinda the obvious choice, unlike forking something.

> >> 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.

And here you have my statement, from today:

  I declare that eudev will be discontinued. You should either move to
  systemd, to alternative device manager or fork it. This is your last
  call, Gentoo users!

Now please copy it to slashdot, reddit or whatever cool kids use these
days, and make sure to request at least half of existing eudev users
switch to something else because of the above statement.

Does it matter that I haven't contributed a single line to eudev code?
eudev upstream is Gentoo, and I'm a Gentoo developer. So I'm part of
upstream. Even if I don't touch eudev, I'm part of the upstream.
In fact, I think I even have commit access there!

If Lennart's single statement from 2014 is a reason to use eudev
instead of systemd-udevd, my statement from today is a more important
reason not to use eudev.

-- 
Best regards,
Michał Górny



pgpQTNn24wD65.pgp
Description: OpenPGP digital signature

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

[Rich Freeman]

On Tue, Feb 16, 2016 at 11:00 PM, Richard Yao  wrote:
>
> 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.
>

Uh, if we cared solely about userbase we'd be using upstart.  I'm
pretty sure that there are more chromebooks out there than Docker
containers running Alpine linux.

Do people actually use docker images created by docker?  That seems a
bit like asking the Apache Foundation to build you a website.

-- 
Rich

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

[Michał Górny]

Dnia 17 lutego 2016 11:53:32 CET, Duncan <1i5t5.dun...@cox.net> napisał(a):
>Michał Górny posted on Wed, 17 Feb 2016 07:47:06 +0100 as excerpted:
>
>> 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:
>
>>> > > > 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:
>
>> - There is no guarantee of correct output order! The empty lines may
>>   move randomly over the text.
>
>Good point!  (Of course the others are too, but this one could be 
>particularly damaging to the intended communication.)
>
>>> 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.
>
>>> 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.
>> 
>> So... to summarize your point. You shouldn't use the correct function
>> that is saved in elog which is primary way of getting info because
>you
>> find it more convenient to have empty non-'starred' lines that don't
>> actually get to elog and make elog a mess?
>> 
>> If you really don't like empty 'starred' lines (and I actually like
>them
>> since they make separation between packages cleaner), why not submit
>a
>> patch for Portage and make 'elog' with no arguments output log line
>> without a star? That's a trivial solution that doesn't require extra
>> functions for the sake of inventing elogspace, ewarnspace, ...
>
>It is at least possible to use say blank ewarn between elog lines, or
>the 
>reverse, so while there's no totally blank separator, there's at least
>a 
>different color to the star on the starred-blank-line separator.
>
>Similarly, if there's more than one "topic" to the messages, and
>they're 
>of different severity, the severities can be interspersed to get color 
>separation.
>
>I believe I've seen both techniques used to good effect in a few
>packages 
>in the past, but I can't name any off the top of my head.

This is mixing channels again. Someone may decide to output warnings separately 
from elogs. Or not output elogs at all.


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

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

[David Seifert]

On Mi, 2016-02-17 at 10:53 +, Duncan wrote:
> Michał Górny posted on Wed, 17 Feb 2016 07:47:06 +0100 as excerpted:
> 
> > On Tue, 16 Feb 2016 22:48:08 -0600 Ryan Hill 
> > wrote:
> > 
> > > On Mon, 15 Feb 2016 15:35:12 +0100 Michał Górny  > > g>
> > > wrote:
> > > > On Mon, 15 Feb 2016 14:37:41 +0100 "Justin Lecher (jlec)"
> > > >  wrote:
> > > > > On 15/02/16 13:59, Michał Górny wrote:
> 
> > > > > > 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:
> 
> > - There is no guarantee of correct output order! The empty lines
> > may
> >   move randomly over the text.
> 
> Good point!  (Of course the others are too, but this one could be 
> particularly damaging to the intended communication.)
> 
> > > 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.
> 
> > > 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.
> > 
> > So... to summarize your point. You shouldn't use the correct
> > function
> > that is saved in elog which is primary way of getting info because
> > you
> > find it more convenient to have empty non-'starred' lines that
> > don't
> > actually get to elog and make elog a mess?
> > 
> > If you really don't like empty 'starred' lines (and I actually like
> > them
> > since they make separation between packages cleaner), why not
> > submit a
> > patch for Portage and make 'elog' with no arguments output log line
> > without a star? That's a trivial solution that doesn't require
> > extra
> > functions for the sake of inventing elogspace, ewarnspace, ...
> 
> It is at least possible to use say blank ewarn between elog lines, or
> the 
> reverse, so while there's no totally blank separator, there's at
> least a 
> different color to the star on the starred-blank-line separator.
> 
> Similarly, if there's more than one "topic" to the messages, and
> they're 
> of different severity, the severities can be interspersed to get
> color 
> separation.
> 
> I believe I've seen both techniques used to good effect in a few
> packages 
> in the past, but I can't name any off the top of my head.
> 

For all those who care, I've updated the eclass under:

https://github.com/gentoo-science/sci/pull/588

Re: [gentoo-dev] games.eclass policy

[Michał Górny]

Dnia 17 lutego 2016 08:52:31 CET, Michael Sterrett  
napisał(a):
>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.

Nice to hear from you. Please don't expect me to write things I didn't know 
about.

So maybe games team did reply. To the people that were worthy replying to. Did 
this group include the Council or QA team?

As I see it, this only adds to your case. Ignoring messages is inappropriate at 
least. Ignoring them in order to stall others from doing their Gentoo work is 
more serious.



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

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

[Duncan]

Daniel Campbell posted on Tue, 16 Feb 2016 22:30:45 -0800 as excerpted:

> 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. :)

Yes.  That's how I read it too... with the direct military reference in 
my head... but only _after_ realizing my first read simply didn't make 
sense in context.

But I agree, that's almost certainly what was intended, which was why I 
decided there was a missing break, so that "As you were, then", could 
take on the military meaning, which in my (no-military-experience) mind 
at least, generally comes after a pause, represented by a break, in 
print.  Without that, I saw it as continuation of the previous thought, 
with its connections with "dumb".

And knowing from hard experience how easy it is to type something that 
ends up being misread across continents and cultures, I thought it best 
to mention the missing break, tho in hindsight I also should have been 
explicit about the military reference of the positive interpretation, as 
well, as while I considered it obvious once the break was there, now that 
I think about it, it's equally likely (if not more so) to be missed, by 
anyone not particularly familiar with the cultural reference.

So thanks for making the military reference explicit.  I saw it on second 
read, but failed to make it explicit, thus inviting misinterpretation, 
myself.

-- 
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

[Michał Górny]

Dnia 17 lutego 2016 05:00:27 CET, Richard Yao  napisał(a):
>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. :)

Oh, the new thing every cool kid users these days. I have only one question in 
return: for how long?

Today Alpine uses eudev. But people change, distributions change. One year from 
now, it may be using systemd.

Today docker uses Alpine. Tomorrow it may use something else. Or even require 
systemd by design.

Today docker is the cool thing. One year from now, nobody may remember about 
it. Didn't things like this happen before?

Now, let's extend this to a perspective of few years. What is more likely to be 
extinct: userbase of eudev or systemd?

>
>>>
>>> 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.


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

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

[Michał Górny]

Dnia 17 lutego 2016 09:17:37 CET, Patrick Lauer  napisał(a):
>On 02/17/2016 07:37 AM, Michał Górny wrote:
>>
> * 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.
>It did. Not having it made booting a lot more exciting, and exciting is
>bad.

So, to summarize. Random non-repeatable behavior is good. Having repeatable 
boots is bad and exciting. Because then you can't claim your bugs are not bugs, 
right?

>
>Now you need to boot before you boot (mount all relevant filesystems
>before starting PID1?), which is fragile and suddenly makes the
>initramfs complex enough to require, err, a dhcp client, different fsck
>implementations, and pretty much all that would have been in /bin or
>/sbin before the /usr movearounding started. And firmware and kernel
>modules, like this it's easy to go >150MB for a compressed initramfs if
>you need firmware and a dhcp client to bring up the NFS share with
>/boot
>(hey, with ceph it's even more exciting ...)
>
>"initramfs is the new rootfs" - yeah, that sounds like a good idea,
>until you figure out that the initramfs doesn't fit in /boot anymore
>(kernels are ~3-4MB each, so 25MB is plenty, eh?) and you need to
>either
>repartition or boot from USB.
>
>And since there was no visible failure mode for us before, of course
>some of us are very confused why a reasonable and effective feature got
>pruned without replacement. Just because somewhere else it didn't work
>100% - that's no reason to remove features for everyone!
>>
 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.
>See your reply to (3) - you disagree with yourself!
 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.
>Which was only needed due to API changes and/or feature removal. Which
>is exactly what you claimed didn't happen, so go FUD yourself :)
>>
>>> 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.
>"Persistent network naming" caused me at least three independent boot
>failures -
>
>(1) network device got renamed away from eth0 by default. That's
>horrible, why would you change the default like this?!
>(If it were an option that I had to consciously turn on it'd be great)
>
>(2) persistent naming only triggers when net link status is up. Thus if
>the switch takes more time than the server (which it did) the renaming
>did *not* happen, init script looks for en3p7 or whatever but now it's
>eth0 again. This means I can't automatically power on systems after
>power failure ...
>
>(3) race condition in persistent naming renames on average 2 out of 4
>of
>the interfaces on bnx2 / bnx2x quad ethernet cards. So you may have
>en3p0, eth1, 

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

[Luca Barbato]

On 16/02/16 19:05, 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].

Who is using that file system? Ideally if "we" are the last user of the
file system it should be safe to mount ro it as well.

In general this happens when there is a "too smart to fit /" filesystem
in use.

In general that means that the same stuff used in /usr to mount it
should live in the initrd...

In general deprecating split-/usr moves the problem in in supporting fat
initrds to begin with. (I guess needing a boot filesystem that is fuse
based and needs rabbitmq or postgresql might be extra fun btw).

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

Given it is a safety feature I do not know how the other kernels achieve
the same out of box.

> 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 think any fuse-supporting system should have it for more or less
obvious reasons (see the evil example above).

lu

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

[Patrick Lauer]

On 02/17/2016 07:37 AM, Michał Górny wrote:
>
 * 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.
It did. Not having it made booting a lot more exciting, and exciting is bad.

Now you need to boot before you boot (mount all relevant filesystems
before starting PID1?), which is fragile and suddenly makes the
initramfs complex enough to require, err, a dhcp client, different fsck
implementations, and pretty much all that would have been in /bin or
/sbin before the /usr movearounding started. And firmware and kernel
modules, like this it's easy to go >150MB for a compressed initramfs if
you need firmware and a dhcp client to bring up the NFS share with /boot
(hey, with ceph it's even more exciting ...)

"initramfs is the new rootfs" - yeah, that sounds like a good idea,
until you figure out that the initramfs doesn't fit in /boot anymore
(kernels are ~3-4MB each, so 25MB is plenty, eh?) and you need to either
repartition or boot from USB.

And since there was no visible failure mode for us before, of course
some of us are very confused why a reasonable and effective feature got
pruned without replacement. Just because somewhere else it didn't work
100% - that's no reason to remove features for everyone!
>
>>> 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.
See your reply to (3) - you disagree with yourself!
>>> 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.
Which was only needed due to API changes and/or feature removal. Which
is exactly what you claimed didn't happen, so go FUD yourself :)
>
>> 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.
"Persistent network naming" caused me at least three independent boot
failures -

(1) network device got renamed away from eth0 by default. That's
horrible, why would you change the default like this?!
(If it were an option that I had to consciously turn on it'd be great)

(2) persistent naming only triggers when net link status is up. Thus if
the switch takes more time than the server (which it did) the renaming
did *not* happen, init script looks for en3p7 or whatever but now it's
eth0 again. This means I can't automatically power on systems after
power failure ...

(3) race condition in persistent naming renames on average 2 out of 4 of
the interfaces on bnx2 / bnx2x quad ethernet cards. So you may have
en3p0, eth1, eth2, en3p4 ... or eth0, en3p1, eth3, eth2.

The only available fixes for this are *not* using the persistently buggy
renamer thingy and instead use either MAC-based naming or pass
'net.ifnames=0' on the kernel command line to keep the stable kernel names.

At my current workplace we're stapling it to the MAC address - that way
whenever a NIC fails we need