joerg | anyway, fixed (was 404) | 01:25 |
---|---|---|
joerg | I closed #devuan-eudev for good | 14:49 |
Arsen | got it | 16:05 |
golinux | joerg: Thanks for getting everything set up. :) | 17:34 |
joerg | yw | 20:22 |
gnu_srs1 | joerg: The link (on the #eudev topic list) of recent work is password protected? | 22:19 |
bb|hcb | gnu_srs1: sent it private | 22:20 |
gnu_srs1 | tks :) | 22:21 |
joerg | please keep topic up to date. I'm not sufficiently involved to accomplish that task | 22:25 |
* joerg idly wonders if logging should somehow get a copy of topic (changes) | 22:30 | |
joerg | for 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 |
blueness | bb|hcb, there is no way you're going to be able to automatically important commits from systemd that touch udev into eudev | 22:43 |
blueness | that was never true | 22:43 |
blueness | you're going to have to figure out what each commit upstream does and decide if you want it or not in eudev | 22:43 |
blueness | i know that's work | 22:43 |
bb|hcb | blueness: 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 |
blueness | yes, i was just about to suggest that | 22:46 |
blueness | eudev-4 was an experiment, and it worked | 22:47 |
blueness | but i had no reason to switch from the working master branch | 22:47 |
bb|hcb | And 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 impossible | 22:48 |
rworkman | Seems like less work to create/maintain a "build script" to build udev from systemd sources | 22:48 |
blueness | rworkman, except ... heheh | 22:48 |
blueness | it doesn't build on embedded systems | 22:48 |
blueness | so | 22:48 |
rworkman | ah yes, meh | 22:48 |
blueness | you have a choice, either the eudev route, or the openembedded route | 22:48 |
blueness | i did originally consider a huge patchset against systemd to have it build on musl | 22:49 |
blueness | but i went the eudev route | 22:49 |
rworkman | We'll be shipping eudev-3.2.10 in Slackware 15.0 when it releases (soonish) | 22:50 |
rworkman | but 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|hcb | Both 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 attribution | 22:53 |
bb|hcb | And in both ways most of the effort have to be repeated for each next release | 22:53 |
bb|hcb | There is a third way - to completely diverge and think how to add new features to be compatible and fix bugs | 22:56 |
blueness | i used to reference the original commit for comparison and attribution | 22:57 |
bb|hcb | Somehow 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 |
Arsen | blueness: it's more viable than one might think to do that | 22:58 |
bb|hcb | Yes, this is what I was thinking about, but there are too many commits and most of them deal with whitespace and coding style | 22:58 |
Arsen | it just needs about 200 lines of python to support the effort ;) | 22:58 |
blueness | Arsen, 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 it | 22:59 |
blueness | but maybe if it works most of the time, it can greatly reduce the work | 22:59 |
Arsen | I 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 udev | 22:59 |
Arsen | ah, 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 conflicts | 23:00 |
Arsen | which is very doable when done in reasonable increments | 23:00 |
blueness | and expect upstream to unexpectedly create new calls to functions you may not have imported ;) | 23:01 |
Arsen | absolutely! that's where the effort part comes in | 23:01 |
blueness | yeah but if you have it mostly automated that will definitely help because a lot of commits maybe "cosmetic" | 23:01 |
Arsen | hell, the organization of libsystemd code is a mess of arbitrary and nonsensical boundaries | 23:01 |
blueness | i know | 23:01 |
Arsen | it took me about a week to extract all the code that was needeed to make eudev compile | 23:02 |
bb|hcb | Arsen: else, we wouldn't be here | 23:02 |
Arsen | ended up being 3x bigger than the actual udev code, and I bet significantly dead code | 23:02 |
Arsen | netbsduser: 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 |
Arsen | though, that makes me worry about the "false dependencies" those three pull into sys-fs/udev (which is sysd-udev) on gentoo | 23:04 |
Arsen | false dependencies being libraries that are never actually called, but are still required at link time due to libsystemd | 23:04 |
netbsduser | Arsen: some libsystemd stuff depends on them, e.g. sd-event (not anymore with my rewrite), sd-bus does heavily, possibly so does libudev by now | 23:06 |
Arsen | so they're publically exported? | 23:08 |
Arsen | or, is just libshared not considered private | 23:08 |
netbsduser | the 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 tree | 23:09 |
Arsen | amazing | 23:10 |
bb|hcb | I have already started reviewing some of the files and see things that are not right... e.g. | 23:15 |
bb|hcb | eudev/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 implementation | 23:17 |
joerg | ooops | 23:17 |
Arsen | this is eudev vs upstream systemd? | 23:17 |
bb|hcb | yes | 23:17 |
Arsen | right | 23:18 |
bb|hcb | both master branches | 23:18 |
bb|hcb | Also there are less devices recognized by ata_id.c in eudev and different semantics in capabilities parsing in v4l_id.c | 23:20 |
bb|hcb | I 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.11 | 23:28 |
bb|hcb | In the meantime, I also like the approach Arsen is describing and it would be nice to explore that too | 23:29 |
Arsen | bb|hcb: https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/25279 this looks neat | 23:49 |
Arsen | does github have such a feature? | 23:50 |
Arsen | (in reference to our tarball signing debocle from the other day) | 23:50 |
Arsen | s/debocle/discussion/ I misremembered the meaning (and spelling) of the word | 23:50 |
bb|hcb | I 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 sig | 23:56 |
Arsen | well, yes, that's up to the forge to enforce | 23:58 |
bb|hcb | I have seen some work on reproducible tarballs from git tag, but this is too early to rely on | 23:58 |
Arsen | (and that concern is brought up in the first patch of the patchset) | 23:58 |
Arsen | well, realistically, it should be trivial | 23:58 |
Arsen | tree objects have a specified and reproducible order | 23:58 |
Arsen | if you export a tar in that order, it will be the same each time | 23:58 |
Arsen | (this is why git doesn't randomly decide changes happened when they really did not) | 23:59 |
Arsen | export-tree AFAIK also is stable-ordered | 23:59 |
bb|hcb | But tar may not generate the exactly same content; then the compressor may not compress in the same way, etc. | 23:59 |
Arsen | hm, it's not called export-tree | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!