<Mic92>
All the replacement in `preConfigure` could be send upstream as meson options as well.
<Mic92>
ah. There is a TODO already
<Mic92>
Meanwhile I am cleanup node-packages.nix in nixpkgs.
<Mic92>
*cleanin up
<Mic92>
I think about adding a contribution guideline that will forbid adding new node-packages.json
hmpffff_ has joined #nixos-systemd
hmpffff has quit [Ping timeout: 260 seconds]
<flokli>
Mic92: I've been thinking about the different paths systemd reads stuff from. I think long-term it might make sense to distinguish between A) "systemd-generated units", B) "NixOS-config-generated stuff" and C) "imperatively created stuff" (in addition to the ephemeral paths in /run, ofcourse)
<Mic92>
Is this not already the case?
<flokli>
for C), we currently have /etc/systemd-mutable/system (Dysnomia), and /nix/var/nix/profiles/default/lib/systemd (nix-env -iA nixos.package)
<flokli>
but it's specific hacks
<flokli>
I'd rather see this in a somewhat more well-defined directory
<flokli>
maybe C) can be just /etc/systemd/…
<flokli>
but then we'd need another place for B).
<flokli>
and maybe the more granular meson options would help with that
<{^_^}>
#86581 (by akamaus, 2 days ago, open): loginctl attach fails with "Could not attach device: Read-only file system" message
<aanderse>
so /etc becomes more of a state directory...
<flokli>
Let's say, I'd like to have a discussion on where these things should be put.
<aanderse>
yeah, that makes sense
<flokli>
gathering some data on other mutable stuff in /etc. But not re-invent the wheel every time
<flokli>
ideally stuff like dysnomia would then also just be adapted to use these paths.
<Mic92>
Does anyone except the author uses dysomnia?
<Mic92>
It has 0 pull requests
<aanderse>
not sure if its disinix or dysnomia... but one of them is big time broken
<aanderse>
and should probably be removed
<globin>
probably not except maybe customers
<aanderse>
because after numerous pings he won't respond to the breakage
<aanderse>
it references services.mysql.rootPassword and other non existent options
<arianvp>
im trying to understand systemd's build system
<arianvp>
what exactly is the distinction between bindir and rootbindir and libdir vs rootlibdir ?
<arianvp>
systemctl is in bindir; but localectl is in rootbindir
<arianvp>
etc
<arianvp>
it's ... odd
<arianvp>
I know bindir and libdir from normal meson projects; but never heard of this split between root and root-less dirs. what does it mean?
<NinjaTrappeur>
m/buffer 1
<NinjaTrappeur>
...
<andi->
arianvp: re your message from yesterday: Why do we have to re-mount it at all? Is that due to root pivot?
<arianvp>
andi-: reason is as follows (at least in my current setup)
<arianvp>
I was booting without an initrd directly into my custom nixos install
<arianvp>
and I have the "remount nixos readonly" as a rule in /etc/fstab
<arianvp>
oh but hmm that should just work ..
<arianvp>
im rubber-ducking as we go
<arianvp>
nevermind! it works
<andi->
arianvp: does systemd in initrd also cover networking in initrd?
<andi->
aka early networkd?
<arianvp>
Yes
<flokli>
Mic92: on that note: feel free to file a PR removing 0005-Add-some-NixOS-specific-unit-directories.patch, once staging-next hit master.
<flokli>
I didn't want to stall the bump by bikeshedding on whether these paths should be kept or not.
<flokli>
just wanted to document where they might be used.
<Mic92>
aanderse: svanderburg sometimes disappears for some months and than is active for some time.
<aanderse>
Mic92: yup, i have noticed
<Mic92>
Can't we really blame him for that. Is probably just the job situtation / personal life. But the question is, given the maintainance status if things like disnix should stay in nixpkgs than.
<aanderse>
Mic92: yeah, sorry, didn't mean to come off as upset or whatever
<aanderse>
just pointing out that if he isn't maintaining it and no one else is maintaining it... and it is out of date
<aanderse>
nixpkgs master branch just doesn't seem like the right place for it
<Mic92>
Yeah. An overlay for stable might be better.
<aanderse>
ok maybe a systemd nixos related question
<aanderse>
i boot up my htpc and autologin a user called "htpc" into openbox
<aanderse>
from there .config/openbox/autostart file has "kodi -d 5 &" in it
<aanderse>
why when i just reinstalled nixos on that machine am i getting "error connecting to mysql database" now? :\
<aanderse>
running mysql from command line is working
<Mic92>
does kodi uses this mysql database stuff?
<aanderse>
yes
<aanderse>
am i not connected to the network by the time htpc user is logged in?
<Mic92>
*I mean the KDE mysql database.
<Mic92>
Forget it
<aanderse>
lol
<aanderse>
Mic92: you sound about as frazzled as i am right now, but for different reasons :D
<aanderse>
ha ha ha
<aanderse>
so server A hosts a mysql database which all htpcs in the house have access to, this stores all kodi metadata library stuff
<aanderse>
same server, A, serves media over nfs
<aanderse>
all htpcs have kodi configured to read from nfs and mysql
<aanderse>
so i can deploy a brand new htpc in my house and be up and running with a full kodi install in moments
<aanderse>
its pretty fantastic (but could be much more fantastic if i spent some time on it...)
<Mic92>
Is your network / DNS maybe not up at the point of of login?
<aanderse>
well... it was fantastic until i just reinstalled this box and it complained about mysql unable to connect :\
<Mic92>
sudo tcpdump -i any port mysql -n
<Mic92>
or nc -v <ip> mysql
<Mic92>
kodi also seems broken in master
<Mic92>
some xlib is not found in the build
<Mic92>
xrandr
<aanderse>
yes, i made a comment about kodi being broken in master and pinged some people
<aanderse>
no response
<aanderse>
confirmed... it is a networking on boot up thing :\
<aanderse>
so i run systemctl restart display-manager.service
<aanderse>
auto login steps in
<aanderse>
again
<aanderse>
logs the user back in
<aanderse>
and kodi is showing all the media fine
<aanderse>
i run stable, not master, btw
<aanderse>
i'll have to look at how i tell my login manager to hold up until iunno... network-online.target is reached?
<gchristensen>
any idea of what is different between running podman, and running podman program under systemd-run --user --scope, specifically in ways that running it under systemtd-run makes it work, and otherwise it fails with Failed to create /user.slice/user-1000.slice/session-1.scope/init.scope control group: Permission denied
<gchristensen>
running with sway, which should do the logind things. I tried starting sway with dbus-launch --sh-syntax --exit-with-session sway but no luck.