dormito | gentoo 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 made | 00:14 |
dormito | oh, 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 virtual | 00:22 |
sam_ | but I think this probably won't be a real issue given we'll keep it in gentoo | 00:22 |
dormito | alright 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 mind | 00:30 |
sam_ | thank you | 00:30 |
bb|hcb | That reminds me that it is maybe a good time to prepare a -pre1 release? What do you think about that (Arsen, Ariadne)? | 01:21 |
Ariadne | would be nice to have a final release before alpine 3.15 release | 01:22 |
bb|hcb | Also 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|hcb | Ariadne: I'd like to have a -pre first, so we can more broadly test the recently merged changes | 01:27 |
bb|hcb | sam_: What is the effort to test a -pre on Gentoo? | 01:29 |
Ariadne | bb|hcb: yes, there are things that rely on the 243 version | 01:58 |
Ariadne | bb|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|hcb | OK, just cut 3.2.11-pre1 :) | 04:15 |
bb|hcb | gnu_srs: please package that for Devuan/experimental, afterwards I want to ask for wider testing on the channels | 04:16 |
sam_ | bb|hcb: not much effort, should be easily done :) | 04:38 |
bb|hcb | great :) | 04:46 |
bb|hcb | https://github.com/eudev-project/eudev/releases/tag/v3.2.11-pre1 | 04:47 |
Arsen | bb|hcb: the machine readable version is indeed used by other programs | 08:08 |
Arsen | I mean, a.b.c is machine readable too, depending on who you ask.. | 08:09 |
Arsen | Ariadne: 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 |
Arsen | bb|hcb: ^ | 12:58 |
Ariadne | why not make | 12:59 |
Ariadne | just make | 12:59 |
Arsen | because writing a build system from scratch sounds annoying | 13:00 |
Arsen | (and I've done it, it is annoying) | 13:00 |
Arsen | meson is not massively more complex, and muon could easily build with tools currently in alpine's bootstrap set | 13:00 |
Arsen | anyway, issues with plain make: it's ad-hoc to get cross-compilation right, it's ad-hoc to get deps right | 13:01 |
Ariadne | i mean | 13:06 |
Ariadne | i’ve done it too | 13:06 |
Arsen | I know | 13:06 |
Ariadne | we are only targeting linux | 13:06 |
Arsen | I'm not | 13:06 |
Ariadne | yes i know about mangarm or whatever it’s called but that’s linux enough | 13:07 |
Arsen | but it's always cross, and generally, pure make build systems have been a mess to cross | 13:07 |
Ariadne | (though i still argue a devfs server makes more sense) | 13:07 |
Arsen | though, with GNU make, it can be made non-horrible | 13:07 |
Arsen | BUILDDIR := build/ or such | 13:07 |
Ariadne | i don’t think it’s a high priority to change the build system atm | 13:07 |
Arsen | oh, me neither, I'm just looking for opinions | 13:08 |
Ariadne | and if you want to add a meson one, that’s fine, as long as the autotools remains for now | 13:08 |
Arsen | as 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 tree | 13:08 |
Arsen | which uses meson | 13:08 |
Arsen | and that's why I mentioned muon explicitly, would that be problematic for alpine? | 13:09 |
Ariadne | well, we are planning to diverge some parts of eudev code from the systemd one | 13:09 |
Arsen | yes, ofc | 13:09 |
Arsen | I'm trying to say that that's the point I'd be implementing the change | 13:09 |
Ariadne | namely we want to rewrite the rules parser: we audited it last night and didn’t like what we saw | 13:09 |
Arsen | +1 | 13: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 |
Ariadne | i 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 me | 13:11 |
Ariadne | narrator: the systemd cherry pick was done wrong, but the code matched systemd in the end, but we didn’t like the systemd code | 13:12 |
Ariadne | so we are going to rewrite it | 13:12 |
Ariadne | it leaks memory | 13:13 |
Ariadne | anyway regarding meson in future, it’s fine | 13:13 |
Ariadne | for like eudev “4.0” or something | 13:13 |
Arsen | alright, got it | 13:14 |
Ariadne | meson has good support for byacc, yes? | 13:15 |
Ariadne | i also would like to say that bb|hcb has done a great job leading the project so far :) | 13:17 |
Arsen | https://github.com/mesonbuild/meson/blob/master/test%20cases/frameworks/8%20flex/meson.build#L24-L26 it's just a generator | 13:18 |
Arsen | and indeed, I agree | 13:18 |
Ariadne | bb|hcb: eudev 3.2.11-pre1 pushed to alpine edge (which is like debian sid) | 14:40 |
Nuc1eoN | Ariadne, 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 |
Nuc1eoN | It's kept nice and simple | 15:25 |
Arsen | so is meson | 15:25 |
Arsen | it's a package manager? | 15:27 |
Arsen | another reinvention of pkgconf(ig)? | 15:27 |
Ariadne | freedesktop pkgconfig is officially dead | 15:42 |
Ariadne | they tell people to use pkgconf when people complain about it in #freedesktop | 15:43 |
Ariadne | :D | 15:43 |
Arsen | you won :) | 15:49 |
Arsen | what was the "split" about anyway? | 15:50 |
Ariadne | pc_sysrootdir, primarily | 16:20 |
Ariadne | but pkgconf was originally intended to be complimentary | 16:20 |
Ariadne | i wanted to bring Apple's -framework to gcc | 16:20 |
Ariadne | so that you could do | 16:20 |
Ariadne | gcc -o foo foo.c -framework gtk+-2.0 | 16:20 |
Ariadne | so, pkgconf began life as a library to do that | 16:21 |
Ariadne | it didn't really work out | 16:21 |
Ariadne | but then pkg-config maintainer decided to depend on glib-2.0, which requires pkg-config | 16:21 |
Arsen | jeez | 16:35 |
bb|hcb | About 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 |
Arsen | it's broken, that's why | 17:25 |
Arsen | look at the CI, the generation step takes an ungodly amount of time for some reason | 17:25 |
Arsen | I outlied the reasons against plain make above | 17:26 |
Arsen | make is to build systems what assembly is to programming | 17:26 |
gnu_srs | Arsen: What's wrong with autotools for you? For me they always work nicely. | 17:27 |
Arsen | I did say what's wrong with them | 17: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 slow | 17:28 |
gnu_srs | You mean: " look at the CI, the generation step takes an ungodly amount of time for some reason"? | 17:28 |
Arsen | yes | 17:28 |
gnu_srs | I don't agree. | 17:29 |
gnu_srs | meson depends on python. | 17:30 |
Arsen | yes? | 17:30 |
gnu_srs | cmake is completely non-understandable or traceable. | 17:30 |
Arsen | a programming language more ubiquitous than shell? | 17:30 |
Arsen | yes? | 17:30 |
Arsen | did I suggest cmake? | 17:30 |
Arsen | regardless of "python bad" being a non-argument, I explicitly mentioned muon because I knew this'd be a problem for some | 17:31 |
gnu_srs | No just for completeness of info on build tools. | 17:31 |
Ariadne | bb|hcb: feedback to the prerelease so far is positive | 20:17 |
Nuc1eoN | As 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 |
Nuc1eoN | Cmake is a lot better then autotools for what its worth. | 20:46 |
Nuc1eoN | Also its lua based so in comparison to the alternatives it actually offers a sane interface to work with | 20:48 |
Arsen | this doesn't make "python bad" a non-argument and still does ignore the existence of muon | 21:07 |
sam_ | it sounds odd that a package maintainer wants projects to use a random build system | 21:09 |
sam_ | even if autotools is annoying, it's established | 21: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 inside | 21:10 |
sam_ | it's a huge amount more work | 21:10 |
Arsen | ^ | 21:11 |
Arsen | that's what I mean when I say "ad-hoc" | 21:11 |
Arsen | it's always extra work to be sure about how to properly (cross)compile "simple makefiles" | 21:11 |
Nuc1eoN | Autotools 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-established | 21:12 |
sam_ | something something xkcd about standards | 21:12 |
Nuc1eoN | It spits out a random error message and you have to google it to figure out that you need some plugin | 21:12 |
Arsen | i usually grep | 21:12 |
sam_ | Arsen: something i'm experiencing particular hell with is people using libtool but not autotools | 21:12 |
Arsen | people volunteer to use libtool? | 21:12 |
Arsen | wow, that's news to me | 21:12 |
Nuc1eoN | libtool sucks yeah | 21:12 |
sam_ | yeah, to get darwin support easily and stuff | 21:12 |
Arsen | ah, I've never dealt with darwin for extended periods of time | 21:13 |
Ariadne | i prefer to just stick with autotools until there is some really compelling reason not to | 22:57 |
Arsen | yeah, I don't want a change now either, I just wanted to hear opinions for future reference | 22:59 |
plasma41 | Sticking with autotools sounds good from over here in the peanut gallery. | 23:08 |
bb|hcb | I 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/!