libera/#eudev/ Sunday, 2021-09-19

joerganyway, fixed (was 404)01:25
joergI closed #devuan-eudev for good14:49
Arsengot it16:05
golinuxjoerg: Thanks for getting everything set up.  :)17:34
joergyw20:22
gnu_srs1joerg: The link (on the #eudev topic list) of recent work is password protected?22:19
bb|hcbgnu_srs1: sent it private22:20
gnu_srs1tks :)22:21
joergplease keep topic up to date. I'm not sufficiently involved to accomplish that task22:25
* joerg idly wonders if logging should somehow get a copy of topic (changes)22:30
joergfor the record (literally): currently it's "Let's keep eudev maintained https://github.com/eudev-project/eudev | chanlogs: http://reisenweber.net/irclogs/libera/_eudev/ || recent work: https://pad.dyne.org/pad/#/2/pad/edit/OxndgL71YfgX8ypl5BC2kuT9/p/"22:31
bluenessbb|hcb, there is no way you're going to be able to automatically important commits from systemd that touch udev into eudev22:43
bluenessthat was never true22:43
bluenessyou're going to have to figure out what each commit upstream does and decide if you want it or not in eudev22:43
bluenessi know that's work22:43
bb|hcbblueness: Thanks! I already become aware of that. What Arsen proposed is to refork it (like eudev-4 branch), he has already done lots on this way.22:46
bluenessyes, i was just about to suggest that22:46
bluenesseudev-4 was an experiment, and it worked22:47
bluenessbut i had no reason to switch from the working master branch22:47
bb|hcbAnd I was wondering how a good idea is to review the file changes one by one - there are about 70 .c files, and reviewing the changes one by one is not impossible22:48
rworkmanSeems like less work to create/maintain a "build script" to build udev from systemd sources22:48
bluenessrworkman, except ... heheh22:48
bluenessit doesn't build on embedded systems22:48
bluenessso22:48
rworkmanah yes, meh22:48
bluenessyou have a choice, either the eudev route, or the openembedded route22:48
bluenessi did originally consider a huge patchset against systemd to have it build on musl22:49
bluenessbut i went the eudev route22:49
rworkmanWe'll be shipping eudev-3.2.10 in Slackware 15.0 when it releases (soonish)22:50
rworkmanbut moving forward, it's up in the air. I've got a (still a bit ugly) build of udev from systemd that seems to work fine, but not sure if we want to do that. Not sure *what* we want to do right now :/22:51
bb|hcbBoth approaches have pros/cons - stripping udev from systemd may keep part of the commits but afterwards it will need some patches for portability, etc. Syncing file by file will most probably lose history and attribution22:53
bb|hcbAnd in both ways most of the effort have to be repeated for each next release22:53
bb|hcbThere is a third way - to completely diverge and think how to add new features to be compatible and fix bugs22:56
bluenessi used to reference the original commit for comparison and attribution22:57
bb|hcbSomehow from the all listed approaches, I have the feeling that #2 is most 'stable' - it can produce a sanely low amount of PRs to be reviewed (unlike the other two)22:57
Arsenblueness: it's more viable than one might think to do that22:58
bb|hcbYes, this is what I was thinking about, but there are too many commits and most of them deal with whitespace and coding style22:58
Arsenit just needs about 200 lines of python to support the effort ;)22:58
bluenessArsen, if you can make it happen, great, but there's a lot of cross references between functions that i'm not sure how a simple python program can deal with it22:59
bluenessbut maybe if it works most of the time, it can greatly reduce the work22:59
ArsenI do believe reforking from the point upstream is at and ensuring that it works for our usecase is an effective approach that brings eudev closer to udev22:59
Arsenah, yeah, those would be maintained separately, I had originally narrowed down the effort of maintaining eudev in my attempts to maintaining those functions and fixing merge conflicts23:00
Arsenwhich is very doable when done in reasonable increments23:00
bluenessand expect upstream to unexpectedly create new calls to functions you may not have imported ;)23:01
Arsenabsolutely! that's where the effort part comes in23:01
bluenessyeah but if you have it mostly automated that will definitely help because a lot of commits maybe "cosmetic"23:01
Arsenhell, the organization of libsystemd code is a mess of arbitrary and nonsensical boundaries23:01
bluenessi know23:01
Arsenit took me about a week to extract all the code that was needeed to make eudev compile23:02
bb|hcbArsen: else, we wouldn't be here23:02
Arsenended up being 3x bigger than the actual udev code, and I bet significantly dead code23:02
Arsennetbsduser: would libfi be able to handle lib{fundamental,basic,shared}? those aren't meant to be part of systemds public api, how are they exported in the actual libsystemd?23:03
Arsenthough, that makes me worry about the "false dependencies" those three pull into sys-fs/udev (which is sysd-udev) on gentoo23:04
Arsenfalse dependencies being libraries that are never actually called, but are still required at link time due to libsystemd23:04
netbsduserArsen: some libsystemd stuff depends on them, e.g. sd-event (not anymore with my rewrite), sd-bus does heavily, possibly so does libudev by now23:06
Arsenso they're publically exported?23:08
Arsenor, is just libshared not considered private23:08
netbsduserthe sd-* public APIs themselves don't need them, but the implementations of them do, so libshared is dragged in but you are forbidden to use those functions unless you're in the systemd source tree23:09
Arsenamazing23:10
bb|hcbI have already started reviewing some of the files and see things that are not right... e.g.23:15
bb|hcbeudev/src/scsi_id/scsi_id.c:340 vs systemd/src/udev/scsi_id/scsi_id.c:243 - options b and s are missing from eudev, but code is there in the implementation23:17
joergooops23:17
Arsenthis is eudev vs upstream systemd?23:17
bb|hcbyes23:17
Arsenright23:18
bb|hcbboth master branches23:18
bb|hcbAlso there are less devices recognized by ata_id.c in eudev and different semantics in capabilities parsing in v4l_id.c23:20
bb|hcbI can't say what are the exact consequences from those (obviously there are many more) but I think that it is a good idea to make PRs, review them and release, e.g. 3.2.1123:28
bb|hcbIn the meantime, I also like the approach Arsen is describing and it would be nice to explore that too23:29
Arsenbb|hcb: https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/25279  this looks neat23:49
Arsendoes github have such a feature?23:50
Arsen(in reference to our tarball signing debocle from the other day)23:50
Arsens/debocle/discussion/  I misremembered the meaning (and spelling) of the word23:50
bb|hcbI do not know; to me it looks like git metadata and should be supported, but even then - generating that and adding it to the repo does not guarantee that the generated tarball (by whatever forge is there) will not change and thus invalidate the sig23:56
Arsenwell, yes, that's up to the forge to enforce23:58
bb|hcbI have seen some work on reproducible tarballs from git tag, but this is too early to rely on23:58
Arsen(and that concern is brought up in the first patch of the patchset)23:58
Arsenwell, realistically, it should be trivial23:58
Arsentree objects have a specified and reproducible order23:58
Arsenif you export a tar in that order, it will be the same each time23:58
Arsen(this is why git doesn't randomly decide changes happened when they really did not)23:59
Arsenexport-tree AFAIK also is stable-ordered23:59
bb|hcbBut tar may not generate the exactly same content; then the compressor may not compress in the same way, etc.23:59
Arsenhm, it's not called export-tree23:59

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