inara has quit [Ping timeout: 256 seconds]
inara has joined #nixos-systemd
<flokli> andi-: filled out the when2meet
<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.
<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: 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.
<bk1603[m]> The relevant lines in `` for systemd:
<bk1603[m]> And the config that I am trying to build:
<andi-> bk1603[m]: do you need latest systemd or just some patches?
<andi-> There is active work ongoing on packaging the current version of systemd but that isn't as trivial as bumping the src ref
<bk1603[m]> I want to make changes to systemd, and test them out. I am trying to use `nixos-rebuild build-vm` for the purpose
<bk1603[m]> Oh I see
<{^_^}> #102355 (by Mic92, 2 weeks ago, open): systemd: 246.6 -> 247-rc2
<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 :)
<andi-> that might be the single change you really need
<andi-> but I could be wrong
<bk1603[m]> pie_: looks like it, you were right :). I got confused when I saw the `/etc` part was 4 years old.
<bk1603[m]> andi-: Oh I'll give that a shot. And if that doesn't work I'll just make patches like you suggested
<bk1603[m]> Thanks!
<andi-> bk1603[m]: no worries, what patch are you working on?
<bk1603[m]> andi-: I am trying to add syscall code parsing for seccomp in systemd.
<{^_^}> 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]
das_j has joined #nixos-systemd
ajs124 has joined #nixos-systemd
das_j has quit [Quit: killed]
ajs124 has quit [Quit: killed]
das_j has joined #nixos-systemd
ajs124 has joined #nixos-systemd
manveru[m] has quit [Ping timeout: 260 seconds]
manveru[m] has joined #nixos-systemd
danielrf[m] has quit [Ping timeout: 240 seconds]
danielrf[m] has joined #nixos-systemd