Ariadne | do you need help getting a sponsor in debian? | 02:06 |
---|---|---|
Ariadne | bb|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 |
Ariadne | hi, | 10:46 |
Ariadne | there 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 |
Arsen | that seems like a desireable goal, yeah | 12:17 |
bb|hcb | Ariadne: 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|hcb | It would be nice for the rest of participants to introduce themselves one way or the other :) | 12:20 |
bb|hcb | user____: Mostly, the reason is the lib compatibility | 12:20 |
bb|hcb | About gitlab - I have no idea, currently eudev is in Gentoo | 12: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 nowadays | 12:23 |
Arsen | it's a distributed scm, there's no need to worry about location really | 12:23 |
Ariadne | i 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 |
Ariadne | we want to see independent community-driven maintenance though | 13:43 |
skarnet | putting 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, indeed | 13:45 |
Ariadne | we will try to coordinate with blueness on a plan to transfer the gentoo/eudev repo outside of gentoo’s github org | 13:46 |
Ariadne | the first objective should be to look at systemd-udev and see what, if anything, is missing. i can do that later this week | 13:47 |
Arsen | I think that's not worth doing | 13:49 |
Arsen | the only difference that I've seen so far is https://manpages.debian.org/unstable/udev/systemd.link.5.en.html, and that's used nowhere | 13:50 |
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 development | 13:51 |
Arsen | and, as we've talked about last night, there | 13:52 |
Arsen | 's nothing missing features in eudev so far in alpine or gentoo | 13:52 |
bb|hcb | In 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 1 | 13:53 |
bb|hcb | https://git.devuan.org/devuan/eudev/src/branch/suites/unstable/debian/patches | 13:54 |
Arsen | not sure how many of these are desireable | 13:59 |
bb|hcb | Does Apline patch eudev? | 14:02 |
Ariadne | not really | 14:03 |
Ariadne | we just rm the eth0 renaming thing | 14:04 |
Ariadne | those patches at quick glance seem reasonable | 14:04 |
Ariadne | i’ll look more later | 14:04 |
Ariadne | 6: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 development | 14:05 |
Ariadne | my concern is more missing security fixes and the like | 14:06 |
Ariadne | doing an audit is important for that reason | 14:06 |
Arsen | ah, fair enough | 14:08 |
bb|hcb | I agree | 14:32 |
Ariadne | blueness: hi, i think we have worked out a plan for taking over eudev. how do you want to proceed? | 15:00 |
blueness | Ariadne, email me your plan and i will respond: blueness@gentoo.org | 15:01 |
Ariadne | okay | 15:01 |
Ariadne | can i get some emails from the devuan stakeholders and other interested stakeholders? :) | 15:02 |
bb|hcb | blueness: I have already sent you an email yesterday | 15:07 |
blueness | i didn't check my email yet, but send it again, i might have lost it | 15:08 |
blueness | actually let me check now | 15:08 |
Ariadne | the tl;dr is that we will create an distro-neutral organization to manage eudev | 15:10 |
blueness | bb|hcb, got it | 15:10 |
Ariadne | and will audit eudev against current systemd-udev to find if anything important is missing (security fixes and whatnot) | 15:10 |
Ariadne | then we will look at distro-specific patches to see what makes sense to include in the base eudev | 15:11 |
Ariadne | blueness: i have a question though, on https://gitlab.com/eudev there is some organization already. do you control it? | 15:13 |
blueness | Ariadne, that page will go away, you should set up your own and i can redirect to i | 15:13 |
blueness | it | 15:13 |
Ariadne | okay, we will set up an organization on gitlab, i guess | 15:14 |
Ariadne | bb|hcb: what do you think about gitlab? | 15:15 |
bb|hcb | I'd prefer github. Gitlab's web is, erhm, not convenient at best | 15:15 |
Ariadne | okay | 15:16 |
bb|hcb | And as I see it, one of the points is to attract more people to get involved, somehow github feels more welcoming | 15:17 |
Ariadne | well, the reason i suggest gitlab is because alpine has gitlab runners we can connect i think | 15:18 |
Ariadne | i should ask our infrastructure team before confirming that though :) | 15:19 |
bb|hcb | BTW, 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 only | 15:20 |
Ariadne | gitea is also much more limited than gitlab (e.g. no good CI story), and does not come with the possibility of a maintenance contract | 15:20 |
Ariadne | alpine needed CI and the ability to call a vendor at 3 AM if it was on fire :P | 15:21 |
Ariadne | but, we can use github | 15:22 |
bb|hcb | I'd prefer to avoid being self hosted | 15:22 |
bb|hcb | Also I doubt that for eudev we need contract+SLA for the CI | 15:23 |
Ariadne | no, we don't :P | 15:23 |
Ariadne | i was just clarifying why alpine uses gitlab even though gitlab itself is not the greatest | 15:23 |
Ariadne | :) | 15:23 |
bb|hcb | What kind of runners are needed? For x86 I can run some | 15:25 |
Arsen | fwiw MS gives out runners like candy | 15:25 |
Ariadne | i think we probably will not hit any quota limits with the github CI | 15:25 |
Arsen | so, gh actions will probably be good enough | 15:25 |
Ariadne | i just prefer gitlab as they are more friendly to free software than microsoft :p | 15:26 |
bb|hcb | Also it may be feasible to do what Gentoo was doing - mirror the git to gitlab too | 15:26 |
Ariadne | thats a mess | 15:26 |
Ariadne | its not worth doing it imo | 15:26 |
Arsen | that's not hard | 15:26 |
Arsen | (I could set that up in minutes) | 15:26 |
Arsen | but also not worth it | 15:26 |
Ariadne | you will get people contributing through those alternate channels and their contributions will likely not get looked at for months | 15:27 |
Ariadne | because people tend to focus on the main channel | 15:27 |
Arsen | mirrors are not alternate channels :P | 15:27 |
Arsen | they're just copies | 15:27 |
bb|hcb | In gh those can be disable or auto-closed by bots, in gitlab, IDK | 15:27 |
Ariadne | yes, but theres no point in just mirroring :P | 15:27 |
bb|hcb | disabled | 15:27 |
Arsen | i agree, as I said | 15:27 |
Arsen | s/i/I/ | 15:27 |
bb|hcb | If CI will better, I see no other point | 15:28 |
bb|hcb | will be | 15:28 |
Arsen | actions are decent, I have no idea what gitlab does | 15:29 |
bb|hcb | I am not good at the CI stuff, so I will rely on your experience | 15:31 |
Ariadne | Gitlab CI is slightly better, in that docker support was not added as an afterthought | 15:32 |
Ariadne | but it is easy to implement a good CI story on both | 15:32 |
bb|hcb | blueness: Got your answer; I have forwarded both mails to Ariadne and golinux, to have them informed | 15:39 |
bb|hcb | I'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 policy | 15:41 |
bb|hcb | I am very glad to see that we do not have disagreement on any of the discussed topis :) Happy days! | 15:45 |
bb|hcb | afk | 15:45 |
Ariadne | bb|hcb: the github.com/eudev is some person | 16:36 |
Arsen | inconvenient | 16:46 |
Ariadne | we could do github.com/eudev-project/eudev | 16:52 |
Ariadne | or such | 16:52 |
bb|hcb | Yep. I somehow missed that | 17:01 |
* skarnet is thinking of building a time machine just to go namesquat systemd on all platforms | 17:08 | |
* golinux loves skarnet's sense of humor | 17:14 | |
skarnet | :) | 17:14 |
bb|hcb | blueness: It looks that eudev in github is a person, so no need to take any action about transfering anything. We take the fork path | 17:27 |
bb|hcb | blueness: I have already invited the interested people | 17:27 |
Ariadne | we should probably rename this to #eudev | 17:30 |
bb|hcb | I don't mind, but I do not want to lose the logging and etc. | 17:35 |
bb|hcb | What I see as a bigger prio is to transfer PR and issues from gentoo/eudev | 17:36 |
bb|hcb | About renaming - is there a seamless way? | 17:37 |
bb|hcb | I think not :( | 17:37 |
golinux | I don't think so because this is in Devuan's channel. | 17:38 |
golinux | You would have to create another channel and go through whatever hoops are required to insure "ownership" | 17:39 |
golinux | with Libera. | 17:39 |
Ariadne | that is not really much of a problem | 17:40 |
golinux | Well, whatever you decide just let me know and I'll inform parazyd | 17:41 |
golinux | We should probably leave this channel up though with a forward to the new one | 17:42 |
golinux | It has served it purpose well. :) | 17:43 |
Ariadne | well, i am already sitting on #eudev | 17:44 |
golinux | joerg 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 |
Ariadne | if this were on OFTC, alpine could just provide its logging infrastructure | 17:47 |
bb|hcb | Ariadne: can you register the project with libera? You were first :) | 17:48 |
bb|hcb | golinux: I think that we can ask joerg to shift the logging that is already there | 17:48 |
bb|hcb | I'd propose to keep the important discussion here, until the new channel is setup | 17:52 |
bb|hcb | Hm. 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 and | 18:03 |
bb|hcb | redirect | 18:03 |
Ariadne | hmm | 18:04 |
Ariadne | yes, lets do that | 18:05 |
bb|hcb | blueness: After checking the options, I think that the best is you to transfer the eudev repo from gentoo to eudev-project | 18:14 |
blueness | bb|hcb, i've opened a gentoo bug with infra: https://bugs.gentoo.org/813076 | 20:51 |
bb|hcb | blueness: I have also sent an email and tested the process :) | 20:51 |
blueness | please comment if i missed anthtng | 20:51 |
bb|hcb | Only one thing - after transfer to create the same repo and add a README with your statement and a link | 20:53 |
Arsen | why not just let the redirect happen? | 20:58 |
rkta | To 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 |
blueness | rkta, bug reports | 21:02 |
bb|hcb | rkta: 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 soon | 21:02 |
bb|hcb | Arsen: PRs, forks, bug reports - we do not want to lose those | 21:02 |
Arsen | moving a project on github places a 302 there... | 21:03 |
Arsen | why not just let that happen as opposed to remaking a different repo | 21:03 |
Arsen | or a 301, no idea | 21:04 |
bb|hcb | https://github.com/bbonev/trte | 21:04 |
bb|hcb | check 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 one | 21:05 |
Arsen | yes, I'm saying the last step is needless | 21:07 |
rkta | blueness: sure, need to setup to use eudev build from source. But this is propably the easiest step to help. | 21:07 |
Arsen | since a redirect happens if you browse to that URL anyway | 21:07 |
bb|hcb | rkta: just an ./autogen.sh&&configure&&make -j | 21:14 |
bb|hcb | Arsen: 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 lost | 21:16 |
Arsen | a redirect happens if you don't reuse the URL | 21:27 |
blueness | bb|hcb, i need to add mgorny to the repo, he's our infra guy to do the transfer | 21:42 |
sam_ | Ariadne: answering from yday | 21:43 |
sam_ | i don't anticipate being able to help right now | 21:43 |
sam_ | but we may continue to ship eudev if this ends up working out | 21:43 |
sam_ | i don't want to commit to something i can't realistically find energy/time for | 21: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 standalone | 21:44 |
sam_ | so i think it kind of depends? | 21:44 |
bb|hcb | blueness: I see you have already added him | 21:46 |
blueness | and he's already added the repo and removed himself as a member | 21:47 |
Arsen | staying up to date sounds optimistic | 21:47 |
Arsen | it's probably closer to say becoming up-to-date | 21:47 |
blueness | bb|hcb, feel free to edit the README | 21:47 |
bb|hcb | Arsen: as long as we are somewhere between realistic and daydreaming, we should be fine ;) | 21:49 |
blueness | the original fork was Nov 15, 2012. Insane. I can't believe how long it has been. | 21:55 |
blueness | nostalgia -> https://github.com/eudev-project/eudev/commit/678b0b89572768b21d8b74360d55b75b233799c4 | 21:56 |
blueness | 104 forks in action | 21:57 |
bb|hcb | blueness: Thank you for this effort! It made lots of things possible over almost a decade :) | 21:58 |
blueness | 2013 through 2015 were the crazy years, after that it settled down to just minor bugs | 21:59 |
bb|hcb | If it were an easy task our lord wouldn't bestow it on us ;) | 22:17 |
bb|hcb | Before editing the README, lets first make consensus on the following topics: | 22:20 |
bb|hcb | 1) Do we need a home page, besides https://github.com/eudev-project/eudev | 22:21 |
bb|hcb | 2) Do we need separate releases, as long as we can publish xz and xz.asc along with the gh tag based ones | 22:22 |
bb|hcb | 3) 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 place | 22:24 |
Arsen | 1) probably not | 22:27 |
Arsen | 2) not sure what you mean by that? | 22:27 |
Arsen | libera can forward users with the f mode, or some flag, I don't remember | 22:27 |
bb|hcb | http://dev.gentoo.org/~blueness/eudev/ | 22:27 |
bb|hcb | Yep, joerg already suggested that, its the best idea since sliced bread for the current situation | 22:28 |
Arsen | /mode #gentoo-eudev +f #eudev | 22:28 |
Arsen | ah, no, let's just attach the releases to tags | 22:29 |
Arsen | frankly, there's no need to even do that, github will put them together, it's enough to PGP sign the annotated tags | 22:29 |
bb|hcb | Not yet, I lost +o (because I closed it by mistake and ChanServ didn't give me +o) and Ariadne is AFK | 22:29 |
Arsen | https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work see "Signing Tags" | 22:29 |
Arsen | register a group with libera first | 22:30 |
Arsen | it'll take a few emails but it should be pretty fast | 22:30 |
bb|hcb | Signed 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/releases | 22:35 |
bb|hcb | Ariadne already registered eudev with libera | 22:36 |
Arsen | cool | 22:36 |
Arsen | also signing tarballs automatically absolutely defeats the point | 22:37 |
Arsen | the implication of signing tarballs on github as opposed to using githubs own automatic packaging is that github is not a trustworthy entity | 22:37 |
Arsen | automating that would rely on trusting them | 22:38 |
Arsen | https://github.com/managarm/xbstrap/releases/tag/v0.2 see assets here for example of the automatic packing I mention | 22:38 |
bb|hcb | I see not tarball sig there | 22:39 |
bb|hcb | s/not/no | 22:40 |
Arsen | indeed | 22:40 |
bb|hcb | https://github.com/Tomas-M/iotop/releases | 22:40 |
bb|hcb | zip and tar.gz are gh generated. tar.xz and tar.xz.asc and manually added | 22:40 |
Arsen | yes, and it's pointless to manually add them | 22:40 |
Arsen | tarball signatures aren't very useful, especially not if the use case permits for the signing to be automated | 22:41 |
bb|hcb | I'd rather argue on that - the point to have a signed source is for packagers to be able to automate verification | 22:41 |
Arsen | and there is a signed source - the annotated git tag | 22:42 |
Arsen | and the only difference between pulling over TLS and pulling a .xz.asc is who signs it | 22:42 |
bb|hcb | Let'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 |
Arsen | the former is still uninterceptable, but signed by github | 22:42 |
bb|hcb | The automation will only spare your time to manually upload... | 22:44 |
bb|hcb | Everything else is compromise prone :( | 22:45 |
bb|hcb | I'd rather consider github signed content as unsigned | 22:45 |
Arsen | fair enough | 22:46 |
Arsen | my point was, automating that is close enough to as error prone as what gh does :P | 22:47 |
bb|hcb | see above - if releases are not too frequent, there is no point | 22:47 |
bb|hcb | What 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 both | 22:49 |
bb|hcb | Yes, full automation is quite prone to errors :) | 22:51 |
bb|hcb | Let me continue the list: | 22:51 |
bb|hcb | 4) 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 them | 22:52 |
bb|hcb | I have just commited a top-post in the README | 23:00 |
bb|hcb | 5) We need to setup CI (as with IRC I am lacking in this and will rely on help) | 23:03 |
bb|hcb | And 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 project | 23:04 |
bb|hcb | 6) 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 ones | 23:07 |
bb|hcb | sam_: Any kind of help is welcome; Keeping eudev in Gentoo is a good thing, esp. for openrc | 23:14 |
Arsen | openrc systems don't need eudev | 23:14 |
Arsen | systemd-udevd works on them | 23:14 |
skarnet | Alpine uses openrc, and doesn't want systemd-udevd. | 23:16 |
Arsen | oh, naturally, I'm just saying that it's not something intrinsic to openrc | 23:17 |
sam_ | hence, "need" | 23:18 |
sam_ | need != want | 23:18 |
bb|hcb | AFAIK 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 *udevd | 23:19 |
Arsen | openrc can be independent or ran via sysvinit | 23:19 |
sam_ | our position has just been to wait and see given it didn't happen for the last 10 years or w/e | 23:20 |
sam_ | we'd probably end up using eudev if such a thing happened, ofc | 23: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 needed | 23:21 |
sam_ | given the obvious starting point would just be the last version which worked of systemd-udev with the patches we use | 23:21 |
skarnet | openrc is totally independent from a device manager | 23:22 |
bb|hcb | Exactly, 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 |
skarnet | it can uses *udevd, it can use mdev, it can use mdevd | 23:22 |
sam_ | that's why my suggestion for eudev would be to just continuously rebase until there's a problem | 23:22 |
Arsen | an openrc user might not be, though, skarnet ;) | 23:22 |
sam_ | (essentially just be literally systemd-udev + musl patches) | 23:22 |
skarnet | yes but that's not for openrc to solve, that's for the distribution | 23:22 |
Arsen | mhm | 23:22 |
bb|hcb | OK, lets do this the Devuan way ;) | 23:33 |
bb|hcb | https://pad.dyne.org/pad/#/2/pad/edit/YTdxkNKr+GtEbedK6jGeWwG2/ | 23:33 |
bb|hcb | This is better than collecting everything I typed above 1 by one and working on it | 23:34 |
Arsen | seems fine | 23:41 |
bb|hcb | BTW. In the pad you can edit your name and/or register so its preserved | 23:41 |
Arsen | to expand on IV) | 23:41 |
Arsen | oh ok | 23:41 |
Arsen | I'll just put the link there | 23:41 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!