libera/#eudev/ Thursday, 2021-09-16

joergcould you place the pad URL into /topic please?13:18
joergor just paste it again so somebody else may add13:19
bb|hcbsure: https://pad.dyne.org/pad/#/2/pad/edit/YTdxkNKr+GtEbedK6jGeWwG2/13:20
joergalso a link to some website, forum or mailinglist-archive related to the topic would be great :-)13:20
joergbb|hcb: I did a few minor edits to the pad, you might want to update github13:47
joergsorry, inline edits are hard to tag with ((name))13:48
joergmy edits were only in "ADOPTION NOTICE (2021-09-14)" (the italic text)13:49
joergplus a <strike> a few lines later13:49
joerggolinux: isn't there a "history" with timeline to scroll along, in dynre pad?13:50
joerg"getting started..." suggests "you can use 'history' to view edits..." - alas I don't find that symbol/button13:53
joergAAAH in *** menu13:54
bb|hcbYep, its a little hidden; I have applied the change: https://github.com/eudev-project/eudev14:01
joerg:-)14:02
bb|hcbI have tried couple of approaches to do automation to help with merging the changes from udev, including git log -p and parsing the output to produce list of udev related commits (I know this excludes the changes in the copied library functions).14:13
bb|hcbBut from what I see the codebases have diverged too much; also the commit count is crazy high. Maybe the good old two-way visual diff file by file can be used to produce a saner set of PRs... What do you think?14:14
Arsenbb|hcb: https://git.sr.ht/~arsen/eudev-new/tree/master/item/tools/systemd_upstream_filter.py15:03
Arsenthis will leave you with only files in REMAP_FILES and KEEP_EXACT_PATH15:03
Arsenit might take up to an hour to run though15:03
Arsenas you might imagine, filtering down that big of a history takes a bit15:04
joergforwarded from obsolete legacy channel:15:07
joerg[16 Sep 2021 13:43:41] <blueness> not so much tired as my life situation changed and i was the only guy doing this.  mostly since 2017 eudev didn't need much work15:08
joerg[16 Sep 2021 13:43:58] <blueness> proof of that gentoo15:08
joerg[16 Sep 2021 13:44:32] <blueness> very few bugs, people only said "its dead" because there were few commits, but i'm not going to commit just for the sake of committing15:08
joerg[16 Sep 2021 13:45:04] <blueness> the task now for the new eudev team is to just re-calibrate and do the same15:08
joerg[16 Sep 2021 13:45:30] <blueness> the only thing that i know of that eudev fell behind on was parsing the rules, and it was just this corner case15:08
joergo/ fsmithred :-)15:11
Arsenyeah, people tend to think "wow no commits" and presume dead on a feature-complete project with no known bugs16:06
Arsenit's a pet peeve16:06
fsmithredhi joerg. I'm here to watch it happen and also as a crash test dummy.16:19
skarnetArsen: cool, we share a pet peeve :)17:07
Arsen:D17:13
bb|hcbArsen: that is nice, but I do not think that blindly merging changes will yield any good :(17:20
Arsenwho said anything about merging them blindly17:20
Arsenplus, that's an effective strategy as long as it works, in terms of compatability17:21
bb|hcb:))) And that is the problem, because they are way too many. What do you think about diffing files?17:21
Arsengit diff systemd/main -- <pathspec>17:23
Arsenand no, there's relatively few of them17:23
ArsenI lost the exact count because I was testing this on a ramfs (I have more physical memory than disk space right now) but it was in the low thousands17:24
Arsen227617:25
Arsenthough, that count is from a msg before I included hwdb files17:25
bb|hcb2276 commits? Did you count how many -/+ per commit?17:30
bb|hcbIf they are small ones (like couple of hunks with couple of lines changed each) it's would not be that bad (actully I didn't see a huge one yet)17:31
bb|hcbs/it's/it17:34
ArsenI did not, but it's fair to assume that the last 365 days alone of backhistory suffice, as we know systemd-udevd works fine for Gentoo right now, without systemd17:37
Arsenso we *could* fork at the current point and further merge or reject patches as need be17:37
skarnetfor Alpine, getting rid of the glibcisms is important, so that's a set of patches that should be reapplied immediately17:42
Arsenabsolutely17:43
Arsensame for managarm17:43
bb|hcbAgreed, but we may miss some small detail. eudev also works in ALT, antiX, Crux, Devuan, Guix, Slackware, VOID and maybe others; I am using eudev on Devuan and it works well17:44
Arsenwhat kind of small detail are you expecting17:46
bb|hcbI have seen lots of whitespace/code beautify changes; maybe it will be better to merge them, so the code diverges less17:46
bb|hcbAlso there is the other proposed approach - redo the fork based on what we have in both repos, but I doubt that there will be issues in the result17:47
bb|hcbSo what you say above+review would be best, but there is one problem with that - correlated changes - it will be a nightmare to group the changes in semantically sane PRs17:49
bb|hcbOTOH if we split those in (e.g. 20 commits per PR) then the whole set should go all in or all out, we can't merge PR by PR17:50
Arsenhm?17:50
Arsenwhat would a PR do17:50
bb|hcbAllow others to review17:50
bb|hcbAnd the bigger the PR, the harder to say GO/NO GO17:51
Arsennot really17:51
Arsenthe only thing that should really matter is the latest revision of the source branch17:51
Arsenif it works for us after applying fixes for glibc-specific functions and similar issues, we should just merge that17:51
bb|hcbYou mean to squash all the history and merge the result?17:51
Arsenno, no squashing is needed17:52
Arsenif we squash we lose the ability to merge from the potential filtered middle repository17:53
bb|hcbi misunderstood. please explain17:54
bb|hcbi agree that its better not to squash; explain your proposed model (you alredy have been there) :)17:54
Arsenalright, filter down the upstream repo, grafted at a certain commit (I picked a point roughly a year ago that includes at least one release following that commit) to get a history of only recent udev-related changes, then continuously update that (yet to make updating that work though with the filter efficiently), and git merge (--allow-unrelated histories only the first time) that filtration result17:56
Arsenthat way we get a history directly linkable to upstream, to solve any attribution issues, and a relatively maintainable way to stay up to date17:56
bb|hcbHow do you manage files that moved around?17:57
Arsenhm17:58
ArsenI'm sure git thought of that already in the recursive merge strategy17:58
bb|hcbMost of them are not in the same place in both repos17:59
Arsenwait, wdym17:59
bb|hcbI am not sure, if there is a commit moving the file, then it will know, but if there isn't then I do not know what will happen18:00
Arsenwell, all changes to the src/{lib,}udev subtrees would've been kept18:01
Arsenso if a file is moved the commit that did it is there18:01
bb|hcbhm. that may work, lets try?18:06
Arsenwell I did :P18:06
Arsenthough I'm not home so I'm not keeping that up to date right now18:07
Arsenit requires more memory than my cheapo vps can handle18:07
bb|hcbI have some ram, but I have to go shortly18:21
bb|hcbLet us know when it happens, so we can discuss how to proceed with it18:27
Arsenwell it already did, it's just slightly out of date18:38
Arsenhttps://git.aarsen.me/systemd-udevonly.git/18:38

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