libera/#devuan-eudev/ Tuesday, 2021-09-14

Ariadnedo you need help getting a sponsor in debian?02:06
Ariadnebb|hcb: yes, i think that is a summary of who is wearing what hat in this discussion, though skarnet also is an Alpine package maintainer.02:07
Ariadnehi,10:46
Ariadnethere is a group on gitlab.com, eudev, already.  is it anyone's here?10:47
user____Is the reason for eudev maintainance it's call interface level compatibility with systemd?11:47
Arsenthat seems like a desireable goal, yeah12:17
bb|hcbAriadne: As you and Arsen said before, wearing the hat is one thing, and making eudev dependent on a distro would not bring any benefit. Maybe it will be a good idea to add something like endorsement statement, bla bla, distro list :)12:19
bb|hcbIt would be nice for the rest of participants to introduce themselves one way or the other :)12:20
bb|hcbuser____: Mostly, the reason is the lib compatibility12:20
bb|hcbAbout gitlab - I have no idea, currently eudev is in Gentoo12:21
bb|hcb's git and mirrored on github. Keeping it in Getoo's git is maybe not preferrable, so I think to go for github. Does anyone have thoughts against github? Anyways as of now I see more benefits in github than drawbacks, also moving a git is easy nowadays12:23
Arsenit's a distributed scm, there's no need to worry about location really12:23
Ariadnei think fundamentally, alpine developers are willing to assist in bootstrapping the project and getting it on a reasonable cadence.  we have significant practical experience developing and maintaining C codebases.13:43
Ariadnewe want to see independent community-driven maintenance though13:43
skarnetputting software maintenance in the hands of one distro (no matter how good the distro) does not communicate clearly that it's a distro-independent project, indeed13:45
Ariadnewe will try to coordinate with blueness on a plan to transfer the gentoo/eudev repo outside of gentoo’s github org13:46
Ariadnethe first objective should be to look at systemd-udev and see what, if anything, is missing.  i can do that later this week13:47
ArsenI think that's not worth doing13:49
Arsenthe only difference that I've seen so far is https://manpages.debian.org/unstable/udev/systemd.link.5.en.html, and that's used nowhere13:50
ArsenI think it'd be better to add missing stuff as it's needed since, as I said before, this is a very nonvolatile area of development13:51
Arsenand, as we've talked about last night, there13:52
Arsen's nothing missing features in eudev so far in alpine or gentoo13:52
bb|hcbIn Devuan there are some patches applied on top of the upstream; but I believe the best way to deal with these is to discuss them 1 by 113:53
bb|hcbhttps://git.devuan.org/devuan/eudev/src/branch/suites/unstable/debian/patches13:54
Arsennot sure how many of these are desireable13:59
bb|hcbDoes Apline patch eudev?14:02
Ariadnenot really14:03
Ariadnewe just rm the eth0 renaming thing14:04
Ariadnethose patches at quick glance seem reasonable14:04
Ariadnei’ll look more later14:04
Ariadne6:51 AM <Arsen> I think it'd be better to add missing stuff as it's needed since, as I said before, this is a very nonvolatile area of development14:05
Ariadnemy concern is more missing security fixes and the like14:06
Ariadnedoing an audit is important for that reason14:06
Arsenah, fair enough14:08
bb|hcbI agree14:32
Ariadneblueness: hi, i think we have worked out a plan for taking over eudev.  how do you want to proceed?15:00
bluenessAriadne, email me your plan and i will respond: blueness@gentoo.org15:01
Ariadneokay15:01
Ariadnecan i get some emails from the devuan stakeholders and other interested stakeholders? :)15:02
bb|hcbblueness: I have already sent you an email yesterday15:07
bluenessi didn't check my email yet, but send it again, i might have lost it15:08
bluenessactually let me check now15:08
Ariadnethe tl;dr is that we will create an distro-neutral organization to manage eudev15:10
bluenessbb|hcb, got it15:10
Ariadneand will audit eudev against current systemd-udev to find if anything important is missing (security fixes and whatnot)15:10
Ariadnethen we will look at distro-specific patches to see what makes sense to include in the base eudev15:11
Ariadneblueness: i have a question though, on https://gitlab.com/eudev there is some organization already.  do you control it?15:13
bluenessAriadne, that page will go away, you should set up your own and i can redirect to i15:13
bluenessit15:13
Ariadneokay, we will set up an organization on gitlab, i guess15:14
Ariadnebb|hcb: what do you think about gitlab?15:15
bb|hcbI'd prefer github. Gitlab's web is, erhm, not convenient at best15:15
Ariadneokay15:16
bb|hcbAnd as I see it, one of the points is to attract more people to get involved, somehow github feels more welcoming15:17
Ariadnewell, the reason i suggest gitlab is because alpine has gitlab runners we can connect i think15:18
Ariadnei should ask our infrastructure team before confirming that though :)15:19
bb|hcbBTW, as an OT Devuan uses gitea, which is much saner than gitlab, but I am not sure if there is a public service with that or it is supposed to be self hosted only15:20
Ariadnegitea is also much more limited than gitlab (e.g. no good CI story), and does not come with the possibility of a maintenance contract15:20
Ariadnealpine needed CI and the ability to call a vendor at 3 AM if it was on fire :P15:21
Ariadnebut, we can use github15:22
bb|hcbI'd prefer to avoid being self hosted15:22
bb|hcbAlso I doubt that for eudev we need contract+SLA for the CI15:23
Ariadneno, we don't :P15:23
Ariadnei was just clarifying why alpine uses gitlab even though gitlab itself is not the greatest15:23
Ariadne:)15:23
bb|hcbWhat kind of runners are needed? For x86 I can run some15:25
Arsenfwiw MS gives out runners like candy15:25
Ariadnei think we probably will not hit any quota limits with the github CI15:25
Arsenso, gh actions will probably be good enough15:25
Ariadnei just prefer gitlab as they are more friendly to free software than microsoft :p15:26
bb|hcbAlso it may be feasible to do what Gentoo was doing - mirror the git to gitlab too15:26
Ariadnethats a mess15:26
Ariadneits not worth doing it imo15:26
Arsenthat's not hard15:26
Arsen(I could set that up in minutes)15:26
Arsenbut also not worth it15:26
Ariadneyou will get people contributing through those alternate channels and their contributions will likely not get looked at for months15:27
Ariadnebecause people tend to focus on the main channel15:27
Arsenmirrors are not alternate channels :P15:27
Arsenthey're just copies15:27
bb|hcbIn gh those can be disable or auto-closed by bots, in gitlab, IDK15:27
Ariadneyes, but theres no point in just mirroring :P15:27
bb|hcbdisabled15:27
Arseni agree, as I said15:27
Arsens/i/I/15:27
bb|hcbIf CI will better, I see no other point15:28
bb|hcbwill be15:28
Arsenactions are decent, I have no idea what gitlab does15:29
bb|hcbI am not good at the CI stuff, so I will rely on your experience15:31
AriadneGitlab CI is slightly better, in that docker support was not added as an afterthought15:32
Ariadnebut it is easy to implement a good CI story on both15:32
bb|hcbblueness: Got your answer; I have forwarded both mails to Ariadne and golinux, to have them informed15:39
bb|hcbI'd prefer to have github.org/eudev/eudev as the main place for the project; but it looks like eudev is registered as an organization in github; as per my understanding that is transferable, but I have no idea if that will collide with some Gentoo policy15:41
bb|hcbI am very glad to see that we do not have disagreement on any of the discussed topis :) Happy days!15:45
bb|hcbafk15:45
Ariadnebb|hcb: the github.com/eudev is some person16:36
Arseninconvenient16:46
Ariadnewe could do github.com/eudev-project/eudev16:52
Ariadneor such16:52
bb|hcbYep. I somehow missed that17:01
* skarnet is thinking of building a time machine just to go namesquat systemd on all platforms17:08
* golinux loves skarnet's sense of humor17:14
skarnet:)17:14
bb|hcbblueness: It looks that eudev in github is a person, so no need to take any action about transfering anything. We take the fork path17:27
bb|hcbblueness: I have already invited the interested people17:27
Ariadnewe should probably rename this to #eudev17:30
bb|hcbI don't mind, but I do not want to lose the logging and etc.17:35
bb|hcbWhat I see as a bigger prio is to transfer PR and issues from gentoo/eudev17:36
bb|hcbAbout renaming - is there a seamless way?17:37
bb|hcbI think not :(17:37
golinuxI don't think so because this is in Devuan's channel.17:38
golinuxYou would have to create another channel and go through whatever hoops are required to insure "ownership"17:39
golinuxwith Libera.17:39
Ariadnethat is not really much of a problem17:40
golinuxWell, whatever you decide just let me know and I'll inform parazyd17:41
golinuxWe should probably leave this channel up though  with a forward to the new one17:42
golinuxIt has served it purpose well.  :)17:43
Ariadnewell, i am already sitting on #eudev17:44
golinuxjoerg set up the logging.  I don't know whether that will follow to the new channel but I'm sure there are folks here who can set that up.17:45
Ariadneif this were on OFTC, alpine could just provide its logging infrastructure17:47
bb|hcbAriadne: can you register the project with libera? You were first :)17:48
bb|hcbgolinux: I think that we can ask joerg to shift the logging that is already there17:48
bb|hcbI'd propose to keep the important discussion here, until the new channel is setup17:52
bb|hcbHm. Currently I imported the gentoo/eudev repo - it is not listed as a fork, so not linked to the other forks (not good). Also issues/PRs are not transferred. For the test I did fork it, but then again issues/PRs are not there. Maybe it would be best to delete it now and wait for blueness to transfer the original repo. Afterwards he can create a new repo with the deprecation notice and18:03
bb|hcbredirect18:03
Ariadnehmm18:04
Ariadneyes, lets do that18:05
bb|hcbblueness: After checking the options, I think that the best is you to transfer the eudev repo from gentoo to eudev-project18:14
bluenessbb|hcb, i've opened a gentoo bug with infra: https://bugs.gentoo.org/81307620:51
bb|hcbblueness: I have also sent an email and tested the process :)20:51
bluenessplease comment if i missed anthtng20:51
bb|hcbOnly one thing - after transfer to create the same repo and add a README with your statement and a link20:53
Arsenwhy not just let the redirect happen?20:58
rktaTo introduce myself: I'm just a devuan user who needs udev to access devices in my day job as an embedded dev. That's why I cared enough to join this channel. Not sure if I'd be able to help, but willing.20:59
bluenessrkta, bug reports21:02
bb|hcbrkta: Welcome! This channel is going to be shifted to #eudev (will be announced here, there is no log yet); also git is not setup, but all these will hopefully get settled soon21:02
bb|hcbArsen: PRs, forks, bug reports - we do not want to lose those21:02
Arsenmoving a project on github places a 302 there...21:03
Arsenwhy not just let that happen as opposed to remaking a different repo21:03
Arsenor a 301, no idea21:04
bb|hcbhttps://github.com/bbonev/trte21:04
bb|hcbcheck this out - I have created a new repo, added some issues, asked a friend to fork and do a PR then transferred and again created a repo with the same name that only points to the transferred one21:05
Arsenyes, I'm saying the last step is needless21:07
rktablueness: sure, need to setup to use eudev build from source. But this is propably the easiest step to help.21:07
Arsensince a redirect happens if you browse to that URL anyway21:07
bb|hcbrkta: just an ./autogen.sh&&configure&&make -j21:14
bb|hcbArsen: I can't imageine how many links are already there, IMHO a redirect is a must - else many people who are not aware about what we are doing now will get lost21:16
Arsena redirect happens if you don't reuse the URL21:27
bluenessbb|hcb, i need to add mgorny to the repo, he's our infra guy to do the transfer21:42
sam_Ariadne: answering from yday21:43
sam_i don't anticipate being able to help right now21:43
sam_but we may continue to ship eudev if this ends up working out21:43
sam_i don't want to commit to something i can't realistically find energy/time for21:44
sam_that said, there's a lot more room for people from our end helping if eudev ends up staying up to date, because we already need to apply the patches for systemd-udev standalone21:44
sam_so i think it kind of depends?21:44
bb|hcbblueness: I see you have already added him21:46
bluenessand he's already added the repo and removed himself as a member21:47
Arsenstaying up to date sounds optimistic21:47
Arsenit's probably closer to say becoming up-to-date21:47
bluenessbb|hcb, feel free to edit the README21:47
bb|hcbArsen: as long as we are somewhere between realistic and daydreaming, we should be fine ;)21:49
bluenessthe original fork was Nov 15, 2012.  Insane.  I can't believe how long it has been.21:55
bluenessnostalgia -> https://github.com/eudev-project/eudev/commit/678b0b89572768b21d8b74360d55b75b233799c421:56
blueness104 forks in action21:57
bb|hcbblueness: Thank you for this effort! It made lots of things possible over almost a decade :)21:58
blueness2013 through 2015 were the crazy years, after that it settled down to just minor bugs21:59
bb|hcbIf it were an easy task our lord wouldn't bestow it on us ;)22:17
bb|hcbBefore editing the README, lets first make consensus on the following topics:22:20
bb|hcb1) Do we need a home page, besides https://github.com/eudev-project/eudev22:21
bb|hcb2) Do we need separate releases, as long as we can publish xz and xz.asc along with the gh tag based ones22:22
bb|hcb3) Let's delay IRC channels until the rename/redirect/log are done for the new one; also the plan is to ask blueness to do the redirect for the #gentoo-eudev one, so we gather everyone interested in a single place22:24
Arsen1) probably not22:27
Arsen2) not sure what you mean by that?22:27
Arsenlibera can forward users with the f mode, or some flag, I don't remember22:27
bb|hcbhttp://dev.gentoo.org/~blueness/eudev/22:27
bb|hcbYep, joerg already suggested that, its the best idea since sliced bread for the current situation22:28
Arsen/mode #gentoo-eudev +f #eudev22:28
Arsenah, no, let's just attach the releases to tags22:29
Arsenfrankly, there's no need to even do that, github will put them together, it's enough to PGP sign the annotated tags22:29
bb|hcbNot yet, I lost +o (because I closed it by mistake and ChanServ didn't give me +o) and Ariadne is AFK22:29
Arsenhttps://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work see "Signing Tags"22:29
Arsenregister a group with libera first22:30
Arsenit'll take a few emails but it should be pretty fast22:30
bb|hcbSigned tags are a good idea, but some tooling may not be able to properly eat that. It wouldn't hurt if we add a good old simple signed tarball to the release. We will most probably not release that often to justify scripting it (yes, that is possible). My point/proposal is to keep all that in https://github.com/eudev-project/eudev/releases22:35
bb|hcbAriadne already registered eudev with libera22:36
Arsencool22:36
Arsenalso signing tarballs automatically absolutely defeats the point22:37
Arsenthe implication of signing tarballs on github as opposed to using githubs own automatic packaging is that github is not a trustworthy entity22:37
Arsenautomating that would rely on trusting them22:38
Arsenhttps://github.com/managarm/xbstrap/releases/tag/v0.2 see assets here for example of the automatic packing I mention22:38
bb|hcbI see not tarball sig there22:39
bb|hcbs/not/no22:40
Arsenindeed22:40
bb|hcbhttps://github.com/Tomas-M/iotop/releases22:40
bb|hcbzip and tar.gz are gh generated. tar.xz and tar.xz.asc and manually added22:40
Arsenyes, and it's pointless to manually add them22:40
Arsentarball signatures aren't very useful, especially not if the use case permits for the signing to be automated22:41
bb|hcbI'd rather argue on that - the point to have a signed source is for packagers to be able to automate verification22:41
Arsenand there is a signed source - the annotated git tag22:42
Arsenand the only difference between pulling over TLS and pulling a .xz.asc is who signs it22:42
bb|hcbLet's assume that we appoint you to be the release manager, then all releases will be signed by your key. If you automate that process on your trusted machine, or you do that manually the chain of trust is not broken...22:42
Arsenthe former is still uninterceptable, but signed by github22:42
bb|hcbThe automation will only spare your time to manually upload...22:44
bb|hcbEverything else is compromise prone :(22:45
bb|hcbI'd rather consider github signed content as unsigned22:45
Arsenfair enough22:46
Arsenmy point was, automating that is close enough to as error prone as what gh does :P22:47
bb|hcbsee above - if releases are not too frequent, there is no point22:47
bb|hcbWhat is important, IMHO, is to have the signed tarball; there is quite a bunch of git aware packaging tools, but also many people still rely on the old ways, even in environments where the new way is supported. It does not hurt to have both22:49
bb|hcbYes, full automation is quite prone to errors :)22:51
bb|hcbLet me continue the list:22:51
bb|hcb4) We need to rework the Committers section - I would insist on keeping people formerly involved in some way, that does not attracts reports and questions on them22:52
bb|hcbI have just commited a top-post in the README23:00
bb|hcb5) We need to setup CI (as with IRC I am lacking in this and will rely on help)23:03
bb|hcbAnd after all these are done, we need to decide about reviewing upstream changes, issues, PRs and distro specific patches that may be quite applicable for the whole project23:04
bb|hcb6) Ask blueness to add link/redirect in Gentoo eudev's home page (https://wiki.gentoo.org/wiki/Project:Eudev) to this project; also add a note on http://dev.gentoo.org/~blueness/eudev/ that these are historic and point to the new ones23:07
bb|hcbsam_: Any kind of help is welcome; Keeping eudev in Gentoo is a good thing, esp. for openrc23:14
Arsenopenrc systems don't need eudev23:14
Arsensystemd-udevd works on them23:14
skarnetAlpine uses openrc, and doesn't want systemd-udevd.23:16
Arsenoh, naturally, I'm just saying that it's not something intrinsic to openrc23:17
sam_hence, "need"23:18
sam_need != want23:18
bb|hcbAFAIK openrc is not a systemd addon; it relies on some other init, right? And if you read carefully this: https://github.com/systemd/systemd/pull/20596#issuecomment-910360057 it says that systemd-udevd will sooner or later become inseparable from systemd. So far so good, but then openrc will need some kind of *udevd23:19
Arsenopenrc can be independent or ran via sysvinit23:19
sam_our position has just been to wait and see given it didn't happen for the last 10 years or w/e23:20
sam_we'd probably end up using eudev if such a thing happened, ofc23:21
sam_that's how we ended up here; blueness was very tired and we also figured there was no point half-maintaining something frozen in time until it was actually needed23:21
sam_given the obvious starting point would just be the last version which worked of systemd-udev with the patches we use23:21
skarnetopenrc is totally independent from a device manager23:22
bb|hcbExactly, and if/when systemd-udev stops working without systemd that will not be an option; I didn't bring my crystall ball today, so I can't say ;)23:22
skarnetit can uses *udevd, it can use mdev, it can use mdevd23:22
sam_that's why my suggestion for eudev would be to just continuously rebase until there's a problem23:22
Arsenan openrc user might not be, though, skarnet ;)23:22
sam_(essentially just be literally systemd-udev + musl patches)23:22
skarnetyes but that's not for openrc to solve, that's for the distribution23:22
Arsenmhm23:22
bb|hcbOK, lets do this the Devuan way ;)23:33
bb|hcbhttps://pad.dyne.org/pad/#/2/pad/edit/YTdxkNKr+GtEbedK6jGeWwG2/23:33
bb|hcbThis is better than collecting everything I typed above 1 by one and working on it23:34
Arsenseems fine23:41
bb|hcbBTW. In the pad you can edit your name and/or register so its preserved23:41
Arsento expand on IV)23:41
Arsenoh ok23:41
ArsenI'll just put the link there23:41

Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!