libera/#eudev/ Friday, 2021-11-05

dormitogentoo seems to have stopped directly needing eudev, and thus the package seems to be slated for removal. Anyone know if there's a decent way setup to continue using eudev on gentoo (an overlay maybe?)00:05
sam_we're probably going to keep it once a release for this one is made00:14
dormitooh, nice. According to my limited understand of the way virtual ebuilds are handled, they don't have a good way for a overlay to "provide" that virtual (without overriding the virtual as well).00:20
sam_yeah, you'd need to just give your own virtual00:22
sam_but I think this probably won't be a real issue given we'll keep it in gentoo00:22
dormitoalright sweet. I use buildroot a lot (for which eudev is still important), and devuan for some of my smaller systems (that I dont want to maintain a gentoo install on). So I figured if I could keep using eudev on gentoo I'd be better off.00:28
sam_sounds like you should use binpkgs and use gentoo everywhere ;)00:30
sam_but absolutely, that's a good point to keep in mind00:30
sam_thank you00:30
bb|hcbThat reminds me that it is maybe a good time to prepare a -pre1 release? What do you think about that (Arsen, Ariadne)?01:21
Ariadnewould be nice to have a final release before alpine 3.15 release01:22
bb|hcbAlso versioning in eudev is little bit confusing - eudev --version yields 243, while the release is 3.2.10; I haven't dived deep into this part, but I suppose there are things that rely on the 243 version (maybe blueness may sched some light here)?01:24
bb|hcbAriadne: I'd like to have a -pre first, so we can more broadly test the recently merged changes01:27
bb|hcbsam_: What is the effort to test a -pre on Gentoo?01:29
Ariadnebb|hcb: yes, there are things that rely on the 243 version01:58
Ariadnebb|hcb: go ahead and cut -pre1 release and i will update alpine to it in morning (as long as we can commit to a final within a reasonable time after)03:35
bb|hcbOK, just cut 3.2.11-pre1 :)04:15
bb|hcbgnu_srs: please package that for Devuan/experimental, afterwards I want to ask for wider testing on the channels04:16
sam_bb|hcb: not much effort, should be easily done :)04:38
bb|hcbgreat :)04:46
bb|hcbhttps://github.com/eudev-project/eudev/releases/tag/v3.2.11-pre104:47
Arsenbb|hcb: the machine readable version is indeed used by other programs08:08
ArsenI mean, a.b.c is machine readable too, depending on who you ask..08:09
ArsenAriadne: I suppose you'd be opposed to this, but what about replacing autotools with something more sane (namely, meson, or muons subset of it)12:58
Arsenbb|hcb: ^12:58
Ariadnewhy not make12:59
Ariadnejust make12:59
Arsenbecause writing a build system from scratch sounds annoying13:00
Arsen(and I've done it, it is annoying)13:00
Arsenmeson is not massively more complex, and muon could easily build with tools currently in alpine's bootstrap set13:00
Arsenanyway, issues with plain make: it's ad-hoc to get cross-compilation right, it's ad-hoc to get deps right13:01
Ariadnei mean13:06
Ariadnei’ve done it too13:06
ArsenI know13:06
Ariadnewe are only targeting linux13:06
ArsenI'm not13:06
Ariadneyes i know about mangarm or whatever it’s called but that’s linux enough13:07
Arsenbut it's always cross, and generally, pure make build systems have been a mess to cross13:07
Ariadne(though i still argue a devfs server makes more sense)13:07
Arsenthough, with GNU make, it can be made non-horrible13:07
ArsenBUILDDIR := build/ or such13:07
Ariadnei don’t think it’s a high priority to change the build system atm13:07
Arsenoh, me neither, I'm just looking for opinions13:08
Ariadneand if you want to add a meson one, that’s fine, as long as the autotools remains for now13:08
Arsenas a standalone libsystemd approaches reality (due to the great work of netbsduser, whose bouncer seems to have crashed again), so does reseparating udev out of systemd's tree13:08
Arsenwhich uses meson13:08
Arsenand that's why I mentioned muon explicitly, would that be problematic for alpine?13:09
Ariadnewell, we are planning to diverge some parts of eudev code from the systemd one13:09
Arsenyes, ofc13:09
ArsenI'm trying to say that that's the point I'd be implementing the change13:09
Ariadnenamely we want to rewrite the rules parser: we audited it last night and didn’t like what we saw13:09
Arsen+113:09
Ariadne(we audited it because there is a muppet who landed a patch in eudev and is now going around saying he is eudev maintainer on patreon as a result, so we wanted to double check that patch)13:10
Ariadnei do have to admit “hi i’m maintainer of thing i’m not maintainer of, please donate to my patreon” is a new one for me13:11
Ariadnenarrator: the systemd cherry pick was done wrong, but the code matched systemd in the end, but we didn’t like the systemd code13:12
Ariadneso we are going to rewrite it13:12
Ariadneit leaks memory13:13
Ariadneanyway regarding meson in future, it’s fine13:13
Ariadnefor like eudev “4.0” or something13:13
Arsenalright, got it13:14
Ariadnemeson has good support for byacc, yes?13:15
Ariadnei also would like to say that bb|hcb has done a great job leading the project so far :)13:17
Arsenhttps://github.com/mesonbuild/meson/blob/master/test%20cases/frameworks/8%20flex/meson.build#L24-L26 it's just a generator13:18
Arsenand indeed, I agree13:18
Ariadnebb|hcb: eudev 3.2.11-pre1 pushed to alpine edge (which is like debian sid)14:40
Nuc1eoNAriadne, Arsen just as a proposal there is also the xmake build system which I think is really neat https://github.com/xmake-io/xmake/ :)15:24
Nuc1eoNIt's kept nice and simple15:25
Arsenso is meson15:25
Arsenit's a package manager?15:27
Arsenanother reinvention of pkgconf(ig)?15:27
Ariadnefreedesktop pkgconfig is officially dead15:42
Ariadnethey tell people to use pkgconf when people complain about it in #freedesktop15:43
Ariadne:D15:43
Arsenyou won :)15:49
Arsenwhat was the "split" about anyway?15:50
Ariadnepc_sysrootdir, primarily16:20
Ariadnebut pkgconf was originally intended to be complimentary16:20
Ariadnei wanted to bring Apple's -framework to gcc16:20
Ariadneso that you could do16:20
Ariadnegcc -o foo foo.c -framework gtk+-2.016:20
Ariadneso, pkgconf began life as a library to do that16:21
Ariadneit didn't really work out16:21
Ariadnebut then pkg-config maintainer decided to depend on glib-2.0, which requires pkg-config16:21
Arsenjeez16:35
bb|hcbAbout build systems, my preference is plain gnu make. I can live with autotools but see no benefit in changing that part - if it ain't broken then why fix it?17:20
Arsenit's broken, that's why17:25
Arsenlook at the CI, the generation step takes an ungodly amount of time for some reason17:25
ArsenI outlied the reasons against plain make above17:26
Arsenmake is to build systems what assembly is to programming17:26
gnu_srsArsen: What's wrong with autotools for you? For me they always work nicely.17:27
ArsenI did say what's wrong with them17:27
Arsen... though, that's just the current instance, in other cases, they're ugly, barely holding themselves together, very error prone (just like make alone), unnecessarily complex and slow17:28
gnu_srsYou mean: " look at the CI, the generation step takes an ungodly amount of time for some reason"?17:28
Arsenyes17:28
gnu_srsI don't agree.17:29
gnu_srsmeson depends on python.17:30
Arsenyes?17:30
gnu_srscmake is completely non-understandable or traceable.17:30
Arsena programming language more ubiquitous than shell?17:30
Arsenyes?17:30
Arsendid I suggest cmake?17:30
Arsenregardless of "python bad" being a non-argument, I explicitly mentioned muon because I knew this'd be a problem for some17:31
gnu_srsNo just for completeness of info on build tools.17:31
Ariadnebb|hcb: feedback to the prerelease so far is positive20:17
Nuc1eoNAs a package maintainer I consider Autotools a pain. Also its painfully slow. Meson is better but yeah depends on python. Therefore I choose xmake because it doesnt suffer from any of these issues and is nicely self-contained. Also it offers option package manager functionality and gui.20:46
Nuc1eoNCmake is a lot better then autotools for what its worth.20:46
Nuc1eoNAlso its lua based so in comparison to the alternatives it actually offers a sane interface to work with20:48
Arsenthis doesn't make "python bad" a non-argument and still does ignore the existence of muon21:07
sam_it sounds odd that a package maintainer wants projects to use a random build system21:09
sam_even if autotools is annoying, it's established21:09
sam_=> we're familiar with workarounds, we have tooling, wrappers, ...21:10
sam_every time someone wants to use a "simple makefile" I die inside21:10
sam_it's a huge amount more work21:10
Arsen^21:11
Arsenthat's what I mean when I say "ad-hoc"21:11
Arsenit's always extra work to be sure about how to properly (cross)compile "simple makefiles"21:11
Nuc1eoNAutotools can be buggy and unpredicable, debugging it is a pain.21:11
sam_yeah sure, so use meson or cmake (if you must) or something else well-established21:12
sam_something something xkcd about standards21:12
Nuc1eoNIt spits out a random error message and you have to google it to figure out that you need some plugin21:12
Arseni usually grep21:12
sam_Arsen: something i'm experiencing particular hell with is people using libtool but not autotools21:12
Arsenpeople volunteer to use libtool?21:12
Arsenwow, that's news to me21:12
Nuc1eoNlibtool sucks yeah21:12
sam_yeah, to get darwin support easily and stuff21:12
Arsenah, I've never dealt with darwin for extended periods of time21:13
Ariadnei prefer to just stick with autotools until there is some really compelling reason not to22:57
Arsenyeah, I don't want a change now either, I just wanted to hear opinions for future reference22:59
plasma41Sticking with autotools sounds good from over here in the peanut gallery.23:08
bb|hcbI wouldn't like to sip more oil into a build system flame :) I have already shared my personal optinion but for the eudev project, I believe that sticking with autotools is the proper way ahead... If there is a specific problem, lets first try to solve that with the current autotools build system, and only in case that does not work (for whatever reason) we can discuss switching to another.23:21

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