libera/#devuan-eudev/ Monday, 2021-09-13

bb|hcbDoes someone know what happened with the announce pad? Last version looked fine, but now it is missing parts05:30
bb|hcbAlso we need to decide where it will be a good idea to post that; and who will post it05:32
golinuxShouldn't that be on #devuan-dev?05:37
bb|hcbYes, most probably, I will cross post there too.05:40
bb|hcbIn the meantime I have restored the history05:40
bluenesslet me know when/if you have adopted eudev.  i'll put a notice up on the README.  Give me a redirectin.16:46
bb|hcbblueness: sure, thanks! I believe it will not be a good idea to continue using the existing git, and we will most probably configure a fork. But we need to decide where16:57
ncopahi! someone is stepping up to maintain eudev?19:30
golinuxHopefully it will be a collective effort19:35
ncopai think alpine would be happy to contribute but i don't think we have anyone from us that wants to take the responsibility for it19:37
Ariadnewhat is the proposed governance for the project?19:40
Ariadnewho will be committer, how will decisions be made?  how closely will systemd-udevd be followed, with its "poetteringisms" and whatnot?19:49
Arsenfwiw it hasn't been very followed for quite a few years19:50
Ariadnenews to me19:53
ncopaim willing to contribute with eudev, and i think more alpine devs are, but i cannot take any leader role or set up a governance for a such project, or make releases of it19:54
Ariadnei am very skeptical19:54
ArsenAriadne: what of?20:02
Ariadnei am very skeptical that this proposed takeover will produce a udev implementation that remains compatible with programs dependent on libudev20:03
Arsenthat's a reasonable concern with such an unpredictable upstream20:03
Ariadneyou are already writing a new reality, one that is divorced from truth: the majority of eudev commits have been cherry-picks from systemd20:04
Arsenby "didn't follow" I didn't mean diverged, I meant fell out of date with20:04
Ariadneis there any plan to bring it back to date?20:05
Arsennot sure about a plan (I am not an authority on that) but there was an attempt previously ( and one of my own more recently ( which I haven't fully elaborated on (I'm moving currently, so it's a busy month)20:07
Arsenthe latter is in no way connected to the original eudev, other than by causality (and by blueness giving me the idea to just re-fork upstream udev and try cleaning the code up)20:08
Arsenjust to put into perspective how incomplete the latter is, I haven't gotten a chance to test it yet or replace glibc specifics20:09
gnu_srsIn my opinion the best way forward is to continue the upstream eudev path, nor trying to single out udev for every systemd release.20:10
Arsenthat's probably the easiest path20:10
ArsenIMO, it's unlikely systemd-udev will be changing enough for source-level compatability to become a hard goal to achieve in libudev20:11
gnu_srsFYI: I'm the current maintainer of eudev for Devuan. And I could help out with a new upstream of eudev, preferably group maintained :)20:12
Ariadneokay, so, will this eudev follow systemd changes or not20:13
golinuxIt will be what we choose it to be.20:19
Ariadneand that is?20:19
golinuxBy collaboration20:19
Ariadnei mean, you have to understand my skepticism, i've read enough of devuan mailing lists and irc logs to understand that you guys really hate lennart, and so i find it hard to believe a devuan eudev will actually follow what systemd does20:20
Arsenthat sounds like an insufficient reason to lose source-level compatibility over20:20
ArsenI was more concerned with the upstream doing something insane like rewriting the entire interface20:21
Ariadnei also find it difficult to be personally comfortable with participating in the maintenance of eudev without clear definitions of how "collaboration" will work, and an explicitly stated goal of source level compatibility with systemd-udevd releases20:22
bb|hcbI am happy to see more people around :)20:23
bb|hcbAll the projects using eudev have benefited from gentoo's efforts and kept it in a working shape. I think that we shall first focus on continuing this effort - cherrypicking patches from systemd udev and updating the hwdb20:25
bb|hcbDeviating from that path, without a specific clear goal list, would be an big effort without clear deliverables20:26
Ariadnewill this be a devuan project, or its own project?20:26
user____You speak the architectspeak and walk the ... plank?20:26
user____> bb|hcb20:26
Ariadnewhat does "architectspeak" mean?20:27
user____Meeting slang for "high level" project "managers" who make up a lot of stuff to sound interesting (sorry bb|hcb)20:27
* user____ be quiet now, since new here20:27
bb|hcbAbout hwdb, I think that we can script and half automate that unless some unpleasant changes happen in systemd udev...20:28
Ariadnein summary, here are the three must haves for alpine, in my opinion20:28
Ariadne- musl compatibility20:29
Arseneudev was sparked to fix the lack of portability in systemd-udevd20:29
Ariadne- integration of new changes from systemd (so that we don't have to patch things, because if we have to patch things, then why bother with eudev at all when we can build something better?)20:29
bb|hcbuser____: I am sorry if I don't express myself properly; I am not a native english speaker...20:29
Arsennew changes are few and far between, for the most part, and are probably best tackled as they happen20:30
Ariadne- commitment to community standards that are aligned with alpine's20:30
user____give me `cat /etc/ >/proc/sys/kernel/hotplug`20:30
Arsenthat's just not a great idea20:30
user____Back to the future. AND it still works on some systems like openwrt.20:30
user____"community standards aligned with alpine's"?20:31
user____And it should be echo not cat above.20:31
Arsenthe future is being fork bombed on boot? :P20:31
Ariadnein this context, that means, we are not interested in hearing about complaints concerning lennartp20:31
Ariadnee.g. we do not want a collaborative environment redolent of some of the more (in)famous devuan mailing list threads20:32
golinuxAriadne: Which mailing list are you following?20:34
Ariadnei will admit in the past year, it has been considerably more chill20:35
user____Since certain people were booted? That is not chill, that is the chill of death (of free speech).20:35
Arsenthis is going in the wrong direction20:36
Ariadnei don't know if anybody was booted or not20:36
Ariadnemy point is that a technically-focused collaborative environment is critical20:36
golinuxVery little devuan development happens on that channel. There is also a devuan-dev list20:36
Arsenultimately, the author of the code or the interface here does not matter, what matters is that libudev has a nonneglegable amount of reverse dependencies and it'd be in the best interest of all maintainers to retain source-level compatibility in that department20:37
Arsenas I said, udev is not a rapidly changing componentso extensions or compatibility issues should also be nonproblematic20:38
ncopaI guess "community standards aligned with alpine's" means that we need to be able to cooperate in a sane way20:38
Ariadnewe have limited time to commit to this effort, we would prefer to stay focused on technical details20:39
ncopai havent followed upstream systemd-udev development but i would expect it to not change to often too fast20:39
ncopawhat i read up here ^^^ looks promising imho20:40
Ariadnei mean, i'm open to it, but i am also working on an MR to replace eudev with systemd-udev with openembedded patches20:40
Ariadne. o O (i wonder if systemd-udev + openembedded patches is a viable starting point for new eudev?)20:41
sam_our intention is to just keep doing that unless/until there's a problem20:41
sam_and I don't know if there ever will be or not20:41
sam_yeah, that was my instinct20:41
user____keep an eye on others who already do this?
bb|hcbI would prefer to skip discussing systemd's authors; let's stay technical and discuss how to organize stuff and how to do the actual thing20:41
user____bb|hcb: agree, I'll do the cussing off screen.20:42
Arsenncopa: I've been bending the systemd repository in various ways last week, there's only a few thousand commits relevant in the udev code20:42
Arsenso, yes, there's not much going on in that department20:43
Arsen(in terms of rapid change)20:43
bb|hcbsam_: the most quircky thing will be if the libudev's interface start adding more stuff; but let's not cry for things that are yet to happen20:43
bb|hcbAriadne: I wouldn't mind conforming to Alpine's community standards (I am not aware what they are) but as long as your team contributes the major part of the effors, that sounds sane20:45
Ariadnebasically don't be a dick20:45
user____What about people who's name is Dick?20:46
* user____ requests he be ignored, due to late hour here20:46
bb|hcbIt would be in everyone's interest to produce eudev that is compatible and usabe in Devuan, Alpine, etc.20:47
Arsenand compatible with systemd's interface20:47
Ariadnefrom our perspective, eudev is preferable because we don't want to open pandora's box of introducing systemd components to alpine20:47
Ariadnesome will want additional systemd components20:48
Ariadneand before you know it, alpine will be on systemd20:48
bb|hcbuser____: please keep it OT20:48
Ariadneso, we are willing to commit some time to this20:48
Ariadnei would prefer that eudev be distro-neutral in terms of leadership20:48
Arsenfwiw, due to udevs unique position among systemd components in that it must run before systemd even can, it's decently separable20:49
Arsenthe "dependency" it has on systemd are utility functions and a few checks20:49
ncopaa few thousand commits... ugh.20:49
Arsenthat is over the span of a decade and a half20:50
Ariadnewhat alpine does not want20:50
sam_bb|hcb: cross that bridge when it comes to it, for sure20:50
Ariadneis to be stuck holding the bag unilaterally20:50
Ariadnee.g. we want eudev to be maintained by an independent team20:50
ncopaalso, me personally don't have the time or energy to take the leader role for a such project20:50
Ariadneme neither20:51
ncopabut i'd be happy to contribute20:51
Ariadnei have health issues, and bluntly, i don't want to deal with end users from distros outside of alpine20:51
Ariadnein long run, though, i think alpine prefers a non-udev solution20:52
ncopabut i think thats not realistic in any near future20:52
Ariadnebut that does not solve the immediate need20:53
Ariadnewe should also optimise the release cadence for distros, probably once per quarter20:54
ncopaand even a hypotheitcal future non-udev solution would probably be better not being an alpine specific thing either20:54
Ariadneyes, we don't want it to be alpine-specific, same as how we want s6-rc to remain independent20:54
Ariadnethere is already too much alpine-specific things20:55
skarnetso I'm going to mention it here as well: it is likely that in a decently near future, mdevd + libudev-zero becomes a fully viable alternative to the udev model20:55
skarnetso basically, whatever choice is made for eudev, it does not have to be forever20:56
Arsenoh hello20:56
Arsenskarnet: is mdevd using netlink and uevent? iirc, mdev (no d) was not20:57
skarnetmdev was used as a hotplug helper, mdevd listens to the netlink20:57
skarnetand also supports all event types (whereas mdev only supports add and remove)20:57
skarnet(technically in the future, the release that adds that support will happen some time this month, it's in git though)20:58
Ariadneyes, longer term, skarnet's work is what we want to use20:58
Ariadnesince skarnet is very familiar with alpine and has made lots of great stuff that is in alpine :P20:58
skarnetnone of which is being used at the moment but we don't talk about that20:59
Ariadnebut for now, we are happy, i think, to take the journey with you, as long as things are reasonably sane20:59
Ariadneskarnet: hmm, utmps is in use, jirutka is working on the final integration bits20:59
skarnetI'll believe it when I see it :P20:59
skarnet(I have high hopes for this time!)20:59
skarnetanyway I'm cool with that, it means I'm not (yet) the one lagging21:00
Ariadnewell, usually when i have time to work on integration, some new fire happens21:01
Ariadneor openssl 3.0 is released, and we focus on that because getting that vile openssl license out of alpine is desirable21:03
ArsenI'm happy to see a distro use skarnet goodies ;)21:03
Arsenfor diversity, at the very least21:03
skarnetif you're a devuan dev, there's an easy way for you to see a distro use skarnet goodies, you know. :P21:04
Ariadnewe did quite a bit of public relations effort to get skarnet a sponsor for s621:04
Ariadnei guess it worked in the end21:04
Ariadnehis website says s6 is sponsored now :D21:04
skarnetit is21:04
skarnetwell, the work on s6-rc is21:04
skarnetwhich is the most important part at the moment :)21:05
Ariadnei dunno21:07
Ariadnei'm more of an ideas person than an integration person21:07
Ariadneto be honest21:07
skarnetdon't worry about it21:08
skarnetif all goes well in November my contract is going to be something like 'write stuff that makes Alpine better'21:08
skarnetso everything will be covered and I'll be able to help directly21:09
Ariadnei'll recommend viagra to all my friends who have that problem21:11
Ariadneso that pfizer makes their money back21:11
skarnetI don't think they earn royalties on that anymore21:11
skarnetthere are generics all over the place anyway21:11
Ariadnei dont have that problem, so i dont know anything about it21:12
skarnetjust wait a decade or two :P21:12
Ariadneif i still exist in a decade or two i will be surprised21:13
gnu_srsmaybe you can move your offtopic stuff to some other channel?21:13
golinuxgnu_srs: Thank you21:14
Arsenright, eudev21:14
Arsenthe upstream is slow moving, it can be considered feature complete in my opinion, but the eudev downstream is quite out of date, really21:15
ArsenAriadne: do you have numbers about how many patches are needed to work around features missing in eudev?21:15
Arsensam_: I imagine you might know too?21:15
Ariadneright now?  there arent any packages in alpine that i know of which have to work around anything21:15
Ariadnemy question was, if there is new functions21:16
Ariadnewill we merge them from systemd or not21:16
ArsenI definitely would21:16
Arsenthere's no reason to diverge21:16
Ariadnegnu_srs: what do you think about new functionality from systemd, if any comes up?21:17
sam_none right now; the main worry for us has been "someone reports a bug and we have no idea if it ended up being fixed upstream in systemd, and nobody is keeping track of commits upstream in systemd"21:17
sam_I don't think anything is explicitly missing21:18
skarnetis there a place, a document, that sums up and/or explains the precise differences between systemd-udevd and eudev ?21:18
Ariadnesam_: how much time are you willing to contribute to maintenance?  will gentoo continue to ship eudev?21:18
Arsenskarnet: no, to my awareness21:19
Arsenany differences are probably unintentional, and results of a lack of maintenance21:19
Ariadnesorry for the questions, i am just trying to ascertain who is committing to what21:27
bb|hcbAriadne: New functionality should definitely be merged somehow; at least to the level that keeps all dependants running, preferably w/o patches21:30
bb|hcbskarnet: I am not aware about such a document; blueness may know, will ask him when he is back21:30
Ariadneis there a list of interested distros, etc21:33
Ariadnei mean, we're talking, its a good talk, but i like plans21:33
golinuxIt seems that devuan tracks upstream changes.  This just arrived to my inbox:21:36
golinuxThe version of eudev-dbgsym (previous version 3.2.9-9) in Devuan suite21:36
golinuxchimaera has changed, as instructed by britney.21:36
golinux chimaera remove: eudev-dbgsym 3.2.9-9 arm6421:36
golinuxDAK managing the Devuan archive21:36
Arseni'm here for a nonlinux distro that's interested, so that's one, though, it shouldn't be much impact21:37
Arsenthe notable thing is that we have a non-glibc non-musl libc21:37
Arsenthough that should be our problem, targetting musl works for us21:37
skarnetwhat libc are you folks using?21:37
ArsenI mean, I'm also here due to interest in linux distros I participate in or use, but people who can represent those are also here21:38
Ariadneim confused21:38
Ariadnewhy would a nonlinux distro21:39
Ariadnecare about eudev21:39
Ariadnethe entire value proposition of eudev21:39
bb|hcbWith my Devuan user hat on, I think that losing eudev will not be a good thing, that is why I have started this effort. In case mdev(d) could become a replacement/alternative - the better; OTOH with Devuan following Debian release cycle, there is time before current testing becomes stable21:39
Ariadneis consuming kevents/uevents21:39
Arsencompatability, our userspace is meant to be (source-level, at libc and pseudofs layers) compatible with linux21:39
Arsennot quite there yet but we're working towards it21:40
Ariadnedoes your kernel produce kevents/uevents though ?21:40
Arsenour posix-server does, yes21:40
Ariadnewhy not just have a real devfs21:40
Ariadneand use libudev-zero21:40
Ariadneudev is a giant hack because linus hates devfs21:41
ArsenI'm not a fan of that design, I believe (for flexibility) this is a job best fit for userspace (though netlink wouldn't be my first choice), and again, for compatibility21:41
Ariadnedevfs is the actually correct solution for a number of reasons21:41
Arsenlibudev-zero is also a few years younger21:43
Arsen(than our project)21:43
bb|hcbAriadne: Completely agree on the action plan; we have planned an announcement about this effort, not yet sent. I believe that this project should be as open as possible, next action is to agree on an acceptable git hosting place and then we can dive into the tech details, work on them and release. About how things are done, maybe a more conservative approach will be best21:43
Ariadnei think that the project should be independent of devuan, or alpine, etc21:43
Arsen^ I do agree21:43
Arsena small set of neutral maintainers should be picked to merge patches incoming from distributions, to centralize quality control and code review21:44
Arsen(neutral meaning disassociated from their respective project, not removed from distributions)21:45
Ariadnemeaning this channel should be renamed21:48
Ariadneat some point :)21:48
gnu_srsUpstream version of gentoo eudev is 3.2.10.  I've looked into that and compared to 3.2.9, and not much has changed.21:48
gnu_srsTherefore I have decided to release 3.2.10 yet.21:49
gnu_srsI think the person to answer how lose eudev is to systemd-udev is blueness.21:50
gnu_srsThere are alternatives like mdev, vdev etc. I know vdev was promising, but the upstream author abandoned it.21:51
gnu_srsAnd for mdev I know nothing.21:52
Arsenmdev, without the d, is probably not viable at all21:52
gnu_srsDo you have a link to mdev(d)?21:53
Arsenand, again, with upstream udev such a slow moving target, it's probably best to just keep source compatibility21:53
gnu_srsArsen: I agree systemd-udev is a slow moving target. Therefore continuing eudev is feasible.21:55
skarnetmdev is a part of busybox, originally written by landley and intended to be only used as a hotplug helper21:56
skarnetlater, someone (not vda, but a regular busybox contributor, idr who) added a -d option to mdev so it could run as a daemon, but it was still a hack21:56
skarnetmdevd is my from-scratch implementation of a daemon that uses the same config file format, it is meant to be a full replacement for mdev21:57
Arsenit's probably more useful to parse udev rules nowadays21:58
Arsenthough uglier21:58
skarnetyes, except I didn't want to write another udevd21:58
skarnetif you want udevd, you have two implementations to choose from21:59
Arsenhm, I'm not sure what there is to improve on or change in that area21:59
skarnetand I don't intend to _ever_ run behind systemd as far as features go21:59
skarnetwell, I am sure21:59
Ariadneen64sp1 or whatever22:00
Ariadnethe nic renaming thing it does22:00
Ariadneis one thing that could be improved22:00
skarnetudev is as poetterwarish as it gets: the way it is designed enforces the architecture and locks users in22:00
Ariadneby removing it22:00
skarnetif you want to implement something compatible to udev, no matter how you proceed, you will end up with a copy of systemd-udevd22:01
Ariadne(this is something alpine defanged already)22:01
Ariadneif you use eudev on alpine, eth0 remains eth022:02
skarnetI wanted an independent device manager that didn't have to implement libudev, and that's what I wrote22:02
skarnetin parallel to it, illility wrote libudev-zero, which is a libudev emulation22:02
gnu_srsskarnet: Is eudev also: designed to enforce the architecture and locks users in? just curious.22:03
skarnetgnu_srs: eudev follows the systemd-udevd model. It is a copy of it. It is a victim of that architecture22:03
skarnetit has to implement the systemd-udevd architecture whether it wants to or not22:03
skarnetlibudev, which maintains a stateful layer with a complex protocol, is the real problem here22:04
gnu_srsMaybe somebody could continue the work of vdev. That effort was really promising.22:05
skarnetlibudev-zero solves that problem by decoupling the stateful layer from the device manager22:05
skarnetlibudev-zero can now be used with any device manager daemon, and mdevd is a good candidate22:05
skarnetgnu_srs: maybe you should volunteer to do it, since you're motivated!22:05
gnu_srsJust a stupid question: Many architectures don't even use *dev*. Are they too ancient or just don't they need such features?22:08
Arsenhm, that should be an architecture independent linux thing22:10
golinuxAriadne: eth0 remains eth0 on Devuan also22:10
Arsenany example?22:11
gnu_srsWhen installing Devuan/eudev:  Warning: eudev will default to the older network;   interface names, such as eth0 or wlan0.22:13
gnu_srsIf you use  the new names, such as enp0s3, you will need to add the following to the boot command: net.ifnames=122:13
Ariadnegolinux: well yes, that seems reasonable22:14
Arsengolinux: what were devuans plans with eudev?22:17
bb|hcbeudev was under gentoo since its existence, but that does not mean it was unwelcoming and not helpful to other distros. I do not believe that renaming stuff right now is what is important. And I do not mind making that independent - there never was a plan for any kind of dependence, just shared interest.22:17
golinuxArsen: I am not the one to answer technical questions.  I serve more as facilitator and historian.22:20
Arsenah, is there anyone from devuan who is right now22:20
bb|hcbskarnet: getting mdevd into Devuan should most preferably happen by adding it to Debian; then it will automatically get included. Only if that can not happen for one or another reason, there is the other way22:21
bb|hcbArsen: The basic plan is to continue maintaining it. If we start thinking about that in two years when current testing is going to become stable and there are tons of changes to merge/implement it will not be possible22:22
golinuxArsen: Yes.  gnu_srs and bb|hcb22:23
skarnetbb|hcb: I can probably get mdevd into Debian as mechanism, but certainly not as the primary device manager22:24
skarnetI will ask Shengjing what he can do (the Debian maintainer of skaware packages, he does his best to navigate the braindead and skaware-hostile Debian policies)22:25
bb|hcbskarnet: Obviously. But only after getting it included, derivates may consider taking it as optional/default22:26
skarnetI'll get it included22:26
bb|hcbThere was some effort to include eudev in Debian, but I didn't track the progress, maybe gnu_srs can shed some light22:27
Arsenbb|hcb: what would continued maintance entail?22:28
Arsenbug fixed and synchronisation with libudev apis?22:28
bb|hcbalso hwdb22:28
bb|hcbwhat else, I don't see much more...22:28
Arsenthat can be done independent of distros by a few people22:29
Arsenthough, again, there's consideration to be made on how to update udev to match with systemd, if at all22:30
bb|hcbI agree on that, but all changes there should be tracked, because there may be un-reported bugfixes22:30
Arsenthat one is a difficult problem to solve22:31
bb|hcbJust tracking the bugs is not enough... :(22:31
Arsenforwarding patches to systemd, if any arise, and checking whether their respective bugs still exist upstream22:32
bb|hcbFrom what I have seen in the codebase, the deviation is high and posting patches upstream is an extra effort; if someone is willing to do, well, but I prefer to skip on that effort22:36
Arsenthe code itself can probably be reasonably ported over22:54
Arseni haven't ran diffs between the two, but I doubt it's major enough for it to be completely infeasible22:55
bb|hcbObviously but that is extra22:57
bb|hcbThe main point is to have eudev for our preferred distros :)22:59
Arsenit'd be in good faith to backport patches and forward issues23:03
Arsenand again due to the nature of the component, those are probably decently uncommon23:03
Arsenhow many bug reports has devuan had about eudev?23:03
bb|hcbI do not say I am against that, yes, that is a good idea but someone have to do it23:08
bb|hcbabout bugs maybe gnu_srs can say? not too many, as far as i remember23:08
Arsenwell, whoever is tasked with maintenance might as well :P23:10
Arsenwith help of others ofc23:10
bb|hcbDo you have an idea where I can see Alpine community standards?23:10
ArsenAriadne: ^ could you step in for this, please23:12
bb|hcbFrom what is written above, I get to know that Ariadne and ncopa are from Alpine, skarnet is developing mdevd, me, gnu_srs, golinux adn plasma41 are from Devuan23:20
bb|hcbI also package some stuff for Debian and Fedora... But that is irrelevant here, if someone wants links, lets do that privately23:22
* plasma41 is summoned23:22
Arsenpaper_: is there interest from your side?23:23
gnu_srsbb|hcb: I tried to get a sponsor for eudev in Debian, but nobody from debian-init-diversity responded :(23:28

Generated by 2.17.0 by Marius Gedminas - find it at!