<andi->
(reminder) aanderse, arianvp, Mic92, NinjaTrappeur, …: Here is a thing where we can try to find a rough weekday and time where most of us are available. The idea is to pick the best date from this poll and then use that for weekday & time for every other week to sync up on systemd. https://www.when2meet.com/?10369248-hdnZc
<Mic92>
andi-: twice a week?
<andi->
once
<andi->
err every 2nd week
<andi->
I just reposted that to get the attention of those that only IRC at work ;)
<Mic92>
so bi-monthly
<andi->
no, that would be every two months :)
<andi->
bi-weekly = every two weeks
<andi->
but we can talk about that.. it is just an idea
<andi->
I think the important thing would be to get everyone talking
<NinjaTrappeur>
I responded, but don't mind too much my answers. Some things are going on in my personal life, don't expect much activity from my side between January 2021 and November 2021
bk1603[m] has joined #nixos-systemd
<bk1603[m]>
I've been trying to build a nixos vm from my config, in which I changed the source directory for systemd to the path of my clone. I got this error: https://pastebin.com/iGJGqvTP Upon suggestion from Jan Tojnar, I looked into the meson build file. and sure enough systemd tries to copy stuff into the `/etc` directory. The variable `sysconfdir` is set to `sysconfdir`. and we `pkgsysconfdir` is `prefix` + `/etc/systemd`.
<bk1603[m]>
But when I tried git blame on the line that declared `sysconfdir`, the last change was made 4 years ago, which makes me think that this sholdn't be a recent change that did this.
<bk1603[m]>
From the default nixos derivation for systemd, the prefix is set to `/` in the preinstall hook.
<andi->
if you really need the latest systemd. Otherwise I usually just apply patches for my changes to test them in a VM.
<andi->
I usually have a test.nix file in my systemd tree that imports nixpkgs & sets up a VM test but also includes systemd.package = pkgs.systemd.overrideAttrs ({ patches ? [], ... }: { patches = patches ++ [ local.diff ]; };
<andi->
where local.diff is a file produced via git diff origin/master..HEAD
<pie_>
so it *is* a matter of build breaking changes since last supported version then?
<bk1603[m]>
andi-: Oh I see, that seems to be way easier than what I've been doing so far. I'll just resort to patches for now :)
<{^_^}>
systemd/systemd#17245 (by deliciouslytyped, 6 weeks ago, open): SysCallFilter/system-call-filter should support passing syscalls as numbers
pie_ has quit [Ping timeout: 256 seconds]
<andi->
Ah! I've seen that before
<andi->
Is there such a thing as a private range for syscalls?
<andi->
Otherwise I think that is fairly risky as was outline in there (but haven't read in a good few weeks)
<bk1603[m]>
I am sorry but I don't understand what you mean by private range of syscalls? There are reserved ones for sure. And you can't have syscalls in certain ranges afair.
pie_ has joined #nixos-systemd
<andi->
As far as I understand those numeric syscalls are usefull for applications like RR where you communicate across processes.
<bk1603[m]>
Ah yes yes
<bk1603[m]>
RR makes a few bogus syscalls from the traced process, to communicate with the tracee process
<andi->
And if there would be a kernel guaranteed set of syscalls that is *never* supported there those would be safe for usage in those applications.
<bk1603[m]>
Oh hmm, I see what you mean now.
<bk1603[m]>
I have a faint memory of reading something about this a while ago. But I don't remember exactly. I think the syscalls rr uses are not going to be used otherwise on `x86_64`
<bk1603[m]>
And since `86_64` is the only architecture supported so far
<bk1603[m]>
I don't think we have to worry about others
<bk1603[m]>
But that's what I think and not what I remember. I'll get back to you after I've reread somethings. (I've been too absorbed with trying to get systemd to build and run for the past two weeks.)
<bk1603[m]>
andi-: ^
<andi->
:)
<bk1603[m]>
andi- yep rr is only supported on the Linux kernel (system requirements page on their GitHub) and that too only for 64bit processors. And the Linux kernel has syscalls nearing 300 I guess. So they can fairly easily avoid any clashes by having a high enough number.
<andi->
bk1603[m]: now you just have to figure out how to add an x86_64 specific syscall filter to systemd and get a "contract" with the kernel :D
<bk1603[m]>
Hehe I kinda had half of that figured out already, and that's what I wanted to test.
<bk1603[m]>
Thanks a lot once again!
<bk1603[m]>
Got to go now :)
ajs124 has quit [Quit: killed]
das_j has quit [Quit: killed]
das_j has joined #nixos-systemd
ajs124 has joined #nixos-systemd
das_j has quit [Remote host closed the connection]
ajs124 has quit [Remote host closed the connection]