| bb|hcb | Fixed, it was private with member only access; not what I wanted | 00:07 |
|---|---|---|
| golinux | Yes. OK now. Thanks | 00:10 |
| bb|hcb | I am somehow clumsy with stuff like that, when I mess up, tell me - it is most probably unintentional ;) | 00:19 |
| Lumaro | Hi | 13:08 |
| Lumaro | Will Gentoo accept eudev again? | 13:09 |
| Lumaro | Someone knows ? I didn't like that they accepted out the box, systemd-tmpfiles and systemd-udev, there are already two left over :( | 13:09 |
| Lumaro | https://archives.gentoo.org/gentoo-user/message/f7089525d3c330b20f11626c19a43b1c | 13:10 |
| Lumaro | s6 int, do it your self ... :( | 13:10 |
| Arsen | well, do it yourself ;) | 13:10 |
| Arsen | I've been running runit on Gentoo for years now | 13:11 |
| Arsen | for fun, moreso than to escape OpenRC | 13:11 |
| Lumaro | Ohhh, very interesting | 13:11 |
| Arsen | as for systemd-udevd, and systemd-tmpfiles, neither of these should present much of an issue | 13:11 |
| Lumaro | Runit + OpenRC or Runit only? | 13:11 |
| Arsen | I was too lazy to rewrite the boot runlevel so I just use openrc to invoke it | 13:11 |
| Arsen | but you could very well use runit only | 13:12 |
| Arsen | or s6 only, of course | 13:12 |
| Arsen | ... back on udevd, tmpfiles: at the very least, in their current state, they're able to run independently of systemd, for the time being, as for whether gentoo will be updating an eudev package in gentoo, I can't say | 13:12 |
| Arsen | there isn't any disadvantage to those yet, especially not on glibc systems | 13:13 |
| Lumaro | I like s6 with mdev/mdevd, but it´s replacement of udev really, many problems read in wiki, before begining O_o | 13:14 |
| Lumaro | s6 requieres write any service | 13:14 |
| Lumaro | it´s too hard for a simple user. | 13:14 |
| Lumaro | Your config with Runit, depends of systemd* ? I I guess so | 13:15 |
| Arsen | yes, I use both the aforeementioned systemd- packages | 13:16 |
| Arsen | there isn't much reason not to | 13:16 |
| Lumaro | systemd fuck!!! | 13:16 |
| Arsen | (yet) | 13:16 |
| Arsen | do you have any nonpolitical reason for not using them? | 13:16 |
| Lumaro | I use kiss linux, in a future chage s6 init, it´s works with mdev/mdevd. | 13:16 |
| Arsen | trust me, I want those political reasons to be enough, too, but with those components, they barely matter | 13:16 |
| Lumaro | No minimal, hard code, don´t like it. | 13:17 |
| Lumaro | You want to become standard by removing the available options. | 13:17 |
| Arsen | I do? | 13:17 |
| Lumaro | To shine it is not necessary to turn off the light of others. | 13:17 |
| Arsen | quite the contrary, I'm working on competing standards | 13:17 |
| Arsen | but I'm *working* on them, they aren't ready yet | 13:18 |
| Lumaro | Sorry you not !!! | 13:18 |
| Lumaro | sorry my bad english, traductor ... | 13:18 |
| Arsen | ah, sure, no worries | 13:18 |
| Lumaro | systemd ! | 13:18 |
| Lumaro | sorry. | 13:18 |
| Arsen | it isn't minimal, you're right, but those two components won't pull in the rest of systemd, which is why the gentoo maintainers saw fit to keep them | 13:18 |
| Arsen | so you don't have to worry about that really | 13:18 |
| Arsen | as for the code, I absolutely agree | 13:19 |
| Arsen | nothing to say about that | 13:19 |
| Arsen | but it's got many eyes on it, so stuff gets fixed quite quickly | 13:19 |
| Lumaro | I like minimal systems, less is more, i like musl, i like see top less than 100 MB on boot :))) | 13:19 |
| Arsen | that doesn't justify it, naturally, but it helps the case | 13:19 |
| Arsen | uh does systemd-tmpfiles even run any persistent processes | 13:19 |
| Arsen | it does not | 13:19 |
| Arsen | and eudev is the same codebase as udev | 13:20 |
| Lumaro | The love I have for Gentoo is infinite, although I use others like Void Linux and Kiss Linux, only the possibility of adopting components to finally make it the init default ... it terrifies me and at this point I would not be surprised ... | 13:21 |
| Arsen | I'm decently sure Gentoo has no interest in cutting out most of it's userbase just to please systemd ;) | 13:21 |
| Lumaro | I am very happy to read that, sorry that it takes a long time to answer, I have to translate. Thanks for those comments. | 13:23 |
| Lumaro | :))) | 13:23 |
| Arsen | no problem | 13:23 |
| Lumaro | Are you a Gentoo developer or related? | 13:24 |
| Arsen | contributor | 13:24 |
| Arsen | not maintainer, not full time | 13:24 |
| Lumaro | Perfect, You Know Gentoo god level, perfect. | 13:25 |
| skarnet | note that using mdev(d) or (e)udev is a totally independent choice from your init system | 13:25 |
| Arsen | I'm working with a few others on this channel of keeping eudev alive though | 13:25 |
| Arsen | ^ yeah | 13:25 |
| skarnet | you can use s6 with eudev, you can use mdevd with openrc, etc. | 13:25 |
| Lumaro | Oh !!! skarnet !! | 13:25 |
| Arsen | yeah he's interested in keeping eudev alive too | 13:25 |
| Arsen | for the time being | 13:25 |
| skarnet | anything that helps prevent systemd monoculture is a good thing | 13:26 |
| Arsen | +1 | 13:26 |
| Lumaro | +10000000 | 13:26 |
| Lumaro | Gentoo can use mdev really ? | 13:27 |
| Lumaro | i read a lot of problem | 13:27 |
| Arsen | I mean, really, anything can | 13:27 |
| Arsen | also mdev is not mdevd | 13:27 |
| Lumaro | yes, the idea is mdev por devices and mdevd for daemon | 13:27 |
| skarnet | don't use both at once :P | 13:28 |
| Lumaro | Kiss Linux run whit two mdev / mdevd | 13:28 |
| Arsen | what? | 13:28 |
| Arsen | mdevd replaces mdev entirely, with a daemon rather than a hotplug helper | 13:28 |
| Lumaro | dont understand, then | 13:28 |
| skarnet | what Arsen said | 13:28 |
| Lumaro | whit mdevd only? | 13:28 |
| skarnet | yes | 13:28 |
| Lumaro | ahhh | 13:28 |
| skarnet | if you're using mdevd then you don't need mdev at all | 13:28 |
| Lumaro | perfec, i understand | 13:28 |
| skarnet | (and if you're using mdev then you don't need mdevd at all, but there's no benefit to doing that. ;)) | 13:29 |
| Lumaro | no no :) | 13:29 |
| Lumaro | mdevd for ever | 13:29 |
| Lumaro | Let's see if I understand, mdevd works autonomously as device manager and daemon | 13:30 |
| Lumaro | You don't use Telegram? It would be nice :) I don't like it too much, but it ends up being useful. | 13:34 |
| Lumaro | Arsen | 13:36 |
| Lumaro | mdevd replaces mdev entirely, with a daemon rather than a hotplug helper | 13:36 |
| Lumaro | Thanks !!! | 13:36 |
| Lumaro | Now read it. | 13:36 |
| Arsen | yeah | 13:36 |
| Lumaro | No mdevd in Gentoo :( arg ! | 13:37 |
| Lumaro | skarnet too, excellent. | 13:47 |
| Lumaro | if you're using mdevd then you don't need mdev at all. | 13:47 |
| Lumaro | (and if you're using mdev then you don't need mdevd at all, but there's no benefit to doing that. ;)) | 13:47 |
| Lumaro | Saved ! Thx. | 13:47 |
| Lumaro | A pleasure to talk, I will return. | 13:48 |
| skarnet | that was a wild ride | 13:55 |
| bb|hcb | yep | 14:05 |
| Arsen | "I will return" sounds oddly ominous | 14:14 |
| skarnet | "for vengeance" | 14:15 |
| lu_zero | or tea and cookies ? | 14:36 |
| lu_zero | skarnet: btw, did you look on how tightly coupled is libudev with udevd ? | 14:51 |
| skarnet | gtg real soon, but very quickly: | 14:52 |
| skarnet | the problem, as often with systemd parts, is that the APIs and the way the code is structured imposes constraints on the architecture | 14:53 |
| skarnet | so no, it's not "tightly coupled" as in, you can reimplement a server for libudev, but given how libudev is, you will likely end up with a copy of udevd | 14:54 |
| skarnet | fortunately, it's possible to cheat and kinda sorta implement libudev without relying on a server maintaining the state that libudev needs | 14:54 |
| skarnet | and that's what libudev-zero does | 14:54 |
| skarnet | so libudev-zero can be associated with any device manager daemon (example: mdevd) because the daemon doesn't have to implement the server for libudev | 14:55 |
| skarnet | if I haven't answered your question, I'll do so later, gtg! | 14:56 |
| lu_zero | I'll look into libudev-zero, I wasn't aware it exists ^^ | 15:19 |
| rburton | so gentoo is dropping eudev but gentoo developers are going to keep it maintained. is there a splinter group who want to keep with eudev, or will it be likely that eudev remains in gentoo? | 15:49 |
| rburton | OE contributor here, who recoiled when seeing that gentoo was dropping eudev as they can just use the musl patches for systemd from OE. which when used, print a big "don't use these patches unless you're sure" warning at build time | 15:49 |
| Arsen | ah that's fun | 15:50 |
| rburton | they were very nearly deleted last month or so, but someone said that upstream systemd is a bit more open to musl so we're seeing how that goes for six months before maybe deleting them | 15:50 |
| Arsen | I think I'm alone in the endevour to keep eudev maintainer when it comes to people connected to gentoo | 15:50 |
| Arsen | maintained* | 15:51 |
| Arsen | and I'm just a contributor, not a gentoo dev | 15:51 |
| Arsen | why do you print that for the patches? | 15:52 |
| rburton | because at least one of them is actively bad, security wise | 16:36 |
| lu_zero | how so? | 16:37 |
| lu_zero | rburton: I guess somewhere should be written what part of the OE patchset is concerning | 16:38 |
| lu_zero | systemd upstream is quite happy to use any gnuism they find useful | 16:38 |
| rburton | yeah | 16:39 |
| rburton | gnu extensions were threadsafe or memory safe or something, and the portable form isn't | 16:39 |
| rburton | can't remember the details, sorry | 16:39 |
| lu_zero | no problem | 16:39 |
| bb|hcb | rburton: I'd be interested to have a look at these patches; at least to search for problematic parts relevant to eudev too | 17:32 |
| sam_ | rburton: I don't think that's is completely aligned with what we're doing in gentoo | 17:32 |
| bb|hcb | And in case you are aware of the details, a pointer or two would be helpful :) | 17:32 |
| sam_ | rburton: they're only applied for musl and while we now apply the whole lot, we did have a minimised set for a release or two, but ended up just using the whole lot for ease w/ systemd-tmpfiles too | 17:33 |
| sam_ | the actual set of patches needed isn't that big | 17:33 |
| sam_ | (for udev, anyway) | 17:33 |
| sam_ | rburton: but no, gentoo developers are not the people who are going to keep eudev maintained, I suspect, unless it ends up following a rebase-often approach | 17:33 |
| bb|hcb | I will give an example: https://github.com/eudev-project/eudev/pull/198 - this (the original code) clearly works well on recent glibc, but as per the definition that is not guaranteed elsewhere. We don't know how many skeletons like that will pop-up out of the systemd code... | 17:38 |
| bb|hcb | What I mean is that rebasing without thorough review is not guaranteed to work well out of Linux/glibc | 17:39 |
| Arsen | it is | 18:31 |
| Arsen | all it takes is a good test suite | 18:32 |
| sam_ | and runtime testing | 18:32 |
| Arsen | right | 18:32 |
| Arsen | I suspect I'll be able to use some existing testing tools to run a test suite across a matrix of environments on pushes or locally | 18:32 |
| Arsen | s/or/and/ | 18:32 |
| bb|hcb | I don't think that testing is OK in this case - in the example above (x)libc may implement the API with different code paths - one conforming to what is in glibc and one not; and the test may just not catch it | 18:37 |
| bb|hcb | The proper way to do that is with some static analyzer that knows what is guaranteed in the API | 18:37 |
| bb|hcb | Unfortuantely clang's one can't do that | 18:38 |
| Arsen | there's three cases: 1) the function is present in a standard, if there's a bug in (x)libc, it's a bug in (x)libc 2) the function exists solely in glibc, it can be reimplemented exactly and 3) the other libcs disagree with glibc behavior | 18:39 |
| Arsen | basename() is the third case, and it's a *very* well known case | 18:40 |
| Arsen | check the notes section of basename(3) in glibc | 18:40 |
| Ariadne | rburton: yes, i saw that about the OE patches, which is why alpine is trying to make this eudev continuation work | 18:42 |
| rburton | :) | 18:42 |
| bb|hcb | Arsen: The bad thing is that glibc implements that in a safe way, but that does not make it guaranteed with other libc | 18:44 |
| Arsen | POSIX has MT-Safety definitions, and in a large part, glibc complies with them | 18:46 |
| Arsen | what are you specifically referring to | 18:47 |
| bb|hcb | I mean that glibc behaves differently from what is guaranteed by POSIX. Also note that by define magic and including different set of headers one may get another basename, so this is a good candidate to always implement locally. Nothing bad with that, but the code relies on the non-guaranteed behaviour; and catching this by tests can not be accurate at best | 18:55 |
| Arsen | I have a way to catch it, one sec | 18:56 |
| Arsen | it's a technique I initially used to discover properties of udevd and it's relation to libsystemd | 18:56 |
| Arsen | https://paste.sr.ht/~arsen/bd2ccdf30540234d3926ea50e6df640ef7500b46 | 18:59 |
| Arsen | the posix one is __xpg_basename | 19:00 |
| Arsen | https://paste.sr.ht/~arsen/7c5f53ea5a8afba4b81793e76f74b10f86183709 there's a few of these | 19:01 |
| Arsen | but yeah, analyzing symbols and dynamiccs is quite useful | 19:02 |
| Arsen | s/cc/c/ | 19:03 |
| bb|hcb | Yep, that is a good approach, as long as we know the list of what is used improperly; see my comment on GH PR #198 | 19:14 |
| bb|hcb | That is an intentional violation of the standard, based on assumptions :( | 19:14 |
| Arsen | GNU is known to have those | 19:15 |
| Arsen | some more criminal than others | 19:15 |
| bb|hcb | No, its OK for GNU to have extensions with deviating behaviour, the problem is that the code replies on the unknown | 19:16 |
| * bb|hcb .oO( Who will possibly run my prog on a non-glibc?! ) | 19:16 | |
| Arsen | yeah, this one is more criminal than others | 19:18 |
| bb|hcb | I just did: grep basename `find . -name \*.[hc]` | 19:21 |
| bb|hcb | If we had a list ok known problematic calls, we could egrep '\<(bla1|bla2|...)\>' instead | 19:22 |
| bb|hcb | s/ok/of | 19:26 |
| Arsen | well, those __xpgs I posted above certainly are | 19:26 |
| Arsen | dunno about others | 19:27 |
| bb|hcb | BTW. Do we need external runners to setup CI? Or the GH provided ones will suffice? | 19:31 |
| bb|hcb | For Devuan it is OK to use a Debian build, no idea if Apline is in the built-in options | 19:32 |
| Arsen | any runner should be able to cross-compile it? | 19:32 |
| Arsen | Ariadne: what process do you guys undergo? | 19:32 |
| Arsen | (fwiw by the end of this, we should all be able to just plug in our cross files and get the desired result) | 19:33 |
| bb|hcb | X-compile is too hard; I think that native compile on different platforms should be OK as a start | 19:44 |
| bb|hcb | OTOH using a X-compile build reveals lots of problems, that a native on does not | 19:46 |
| bb|hcb | So focus on native builds initially and after we are at some point, we can also look into cross compiling; I didn;t try, but if it works out of the box, it can only help | 19:47 |
| Ariadne | alpine doesnt cross-compile udev | 19:49 |
| bb|hcb | In the meantime I got stuck at cdrom_id.c - current code uses static flags and sets them to known capabilities/properties, the SD one reimplemented it with dynamic memory :( | 19:56 |
| bb|hcb | Ariadne: does it have something like clean, isolated build in a sandboxes chroot? | 20:08 |
| bb|hcb | sandboxed | 20:08 |
| Ariadne | something like pbuilder? | 20:09 |
| Ariadne | yes, abuild rootbld | 20:09 |
| bb|hcb | Yes, pbuilder/sbuilder... | 20:09 |
| Ariadne | builds in bubble wrap | 20:09 |
| bb|hcb | Does it have net access? | 20:09 |
| Ariadne | some alpine devs still use sbuild! | 20:09 |
| Ariadne | no, not usually | 20:09 |
| bb|hcb | :) | 20:10 |
| Ariadne | the actual buildservers do due to … reasons | 20:10 |
| bb|hcb | OK, sbuild can be set to get the deps and disable net before the build, so whatever is there, stays there | 20:11 |
| Ariadne | yes i’m aware | 20:11 |
| bb|hcb | What do we need to make that run? | 20:12 |
| Ariadne | alpine was largely started by (at the time) young debian people who wanted to build something better, we know all about sbuild and stuff :p | 20:13 |
| Ariadne | hmm | 20:13 |
| Ariadne | what do you mean | 20:13 |
| Ariadne | generally we don’t create packages using CI | 20:13 |
| Arsen | neither does debian afaiu | 20:13 |
| Arsen | gentoo definitely doesn't :^) | 20:14 |
| Arsen | managarm does but rn all builds are nightlies anyway | 20:14 |
| bb|hcb | For eudev we need some CI to check the builds in different envs; Shall we run travis or is there something simpler? How many and what type of runners are needed? | 20:15 |
| Arsen | gh actions will do | 20:16 |
| bb|hcb | They do not have alpine | 20:16 |
| Arsen | they also don't have managarm, yet I'm not complaining | 20:16 |
| bb|hcb | I mean the internal runners | 20:16 |
| Arsen | I'm decently sure they can run a docker container | 20:16 |
| Arsen | I know | 20:16 |
| bb|hcb | I just briefly skimmed on what they have and how they do it, I am more inclined to setup a couple of VMs with whatever is needed and connect that via actions; but I never did that and I prefer not to reinvent the wheel | 20:18 |
| Arsen | why not just run a script in an alpine and debian container each | 20:18 |
| Arsen | that covers mlibc and glibc | 20:19 |
| Arsen | s/mlibc/musl/ sorry, reflex | 20:19 |
| bb|hcb | The internal runner will create whatever it is asked to, then perform xxx, then discard and only keep the artifacts. If the first step is to create a docker then that's going out of question ;) | 20:20 |
| Arsen | I'm pretty sure one can do that on gh-a (since we build docker containers on gh-a and that involves running containers), and lets us further control network access or such | 20:20 |
| sam_ | yep | 20:20 |
| Arsen | docker run -v artifact_dir:/out -v "$(pwd):/srcdir:ro" --net=none alpine sh -x /srcdir/.github/workflows/build_and_test.sh or something close to that | 20:21 |
| bb|hcb | Got it, but that is going to be slow, no? | 20:22 |
| Arsen | what makes it slower? | 20:22 |
| Arsen | a docker container is a ram fs overlayed over squashfs or whatever, in a namespace | 20:23 |
| Arsen | we can save time on container setup if we add an action that daily builds and pushes a build and test env on ghcr.io or whatever | 20:23 |
| bb|hcb | Yep, but the GH runner does not preserve state, so all that needs to be downloaded, unpacked, populated with the checkout to test, etc. | 20:24 |
| Arsen | and if we run it externally, it needs to run the same steps, plus installing extra packages before all that | 20:24 |
| Arsen | oh, wait, if we bring our own machines they can be preloaded | 20:25 |
| Arsen | I'm not sure how fast gh's intranet is | 20:25 |
| bb|hcb | That is what I mean... Preloaded :) | 20:25 |
| bb|hcb | And if we assume that the build deps would not change on a daily basis, running the build and tests in a clone of the docker/bubble/chroot/whatever should not be slower than the build | 20:27 |
| bb|hcb | AFAIK a amd64 host can run an i386 container, so two VMs for the runners - one Alpine and one Devuan... But there should be something on top to safely manage them - I do not want to do custom stuff and track security problems afterwards | 20:29 |
| Arsen | you could hack together any solution for the time being | 20:31 |
| Arsen | I'm not sure when I return, when I do I'll be measuring how fast or slow using gh runners is and will set up better infra if there is some | 20:32 |
| bb|hcb | I have only enjoyed the results of CI, never set one up, that is why I prefer to get advice from someone who already did... | 20:33 |
| bb|hcb | And amd64 VMs are avail, so the question is what to do on top | 20:34 |
| lu_zero | skarnet: libudev-zero is really cool | 22:11 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!