<worldofpeace>
it caused accountservice to cache nothing, or a wrong value (think it was default( which touches https://github.com/elementary/greeter/issues/368 because it won't select anything
<{^_^}>
elementary/greeter#368 (by worldofpeace, 9 weeks ago, open): tries to start nonexistant sessions if the user last used them
<jtojnar>
worldofpeace yeah, it happens if I remove `defaultSession = "pantheon"`
<jtojnar>
user-session defaults to default in lightdm.conf
<{^_^}>
error: syntax error, unexpected $undefined, expecting ')', at (string):271:80
<Profpatsch>
56M total
<manveru>
pretty cool :)
<Profpatsch>
Still has coreutils and gnugrep though :P
<Profpatsch>
But pretty good compared to 250MB
<manveru>
yeah, gnugrep is also referenced from the rbconfig
<manveru>
as is coreutils
<manveru>
so they should be safe to nuke as well
<Profpatsch>
manveru: Hm, not as safe, you’d have to nuke stuff that references mkdir and rmdir, that might well be something even the standard library needs
<Profpatsch>
So I guess those are fine.
<adisbladis>
Profpatsch: 3 more megs and you're in the same ballpark as python3Minimal
<manveru>
yeah, fileutils depends on that at least
<Profpatsch>
adisbladis: No need to make ruby as nice as python :P
<manveru>
but then you can just wrap into another env ^^;
<gchristensen>
is it unsafe to create symlinks manually in /dev/ ? like if I don't go through udev, will I get in trouble later?
<clever>
gchristensen: dont see that big of a problem from it, just be aware that they wont perist thru a reboot, and whatever your linking may not exist in the future
<clever>
gchristensen: udev also has rules to create symlinks for you
<gchristensen>
yeah, I can't really use udev because I need network acses which isn't available in early boot
<clever>
?
<gchristensen>
hm?
<clever>
what needs symlinks that early and also network?
<gchristensen>
deciding what symlinks to make involves network calls :P
<clever>
ah
<clever>
is this packet.net related?
<gchristensen>
aye
<clever>
i have seen people brick machines before, by doing network in an activation script
<clever>
it works when you switch, but it fails when you boot
<gchristensen>
yup
<clever>
and it fails in such an unexpected way, and doesnt put systemd into PATH
<gchristensen>
nice
<clever>
then it tries to continue the boot, and fails with the weirdest of errors
ixxie has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
<worldofpeace>
Jan Tojnar: Thanks, the validation makes sense there
<worldofpeace>
gchristensen: it's cool, also unexpected for me. (though most course of events here have been unexpected :D)
<jtojnar>
worldofpeace fetchpatch just drops renames
<worldofpeace>
Jan Tojnar: I guess this makes patches more reliable
<jtojnar>
worldofpeace more like renames are not part of the standard patch format
ixxie has quit [Ping timeout: 268 seconds]
<jtojnar>
but some kind of git extensions
<worldofpeace>
ugh, this means all the moved icons aren't going to be there
<worldofpeace>
rename from files/usr/share/icons/hicolor/scalable/actions/xapp-go-history-previous-symbolic.svg etc
<clever>
worldofpeace: you could also just fetchFromGitHub the new rev?
<clever>
instead of trying to patch from old->new
<worldofpeace>
clever: yeah, but it's actually a patch from a PR
<worldofpeace>
so then it'd have to be my fork that I control and rebased
<jtojnar>
there is some benefit to forking everything as salsa.debian.org does
<clever>
also, github treats every fork as a single massive repo
<clever>
so rev's from the forks, can be fetched from any fork, or the original
<clever>
so, you could slip a rev into your fetchFromGitHub, which isnt in the upstream repo, but still fetch it from "upstream" :P
drakonis has joined #nixos-dev
<jtojnar>
clever++ that's what I like to do with fetchpatch
<{^_^}>
clever's karma got increased to 279
<jtojnar>
though PRs are usually against master, so fetchFromGitHub would not work
<jtojnar>
unless we preserve .git and cherry-pick the commits in postFetch
<jtojnar>
at that point, I would be considering just adding the git-produced patch in-tree
<jtojnar>
and I really hate in-tree patches with passion
<clever>
jtojnar: what i mean, is that if you fork a repo, and push changes the the fork, i can use fetchFromGitHub against the original repo, but use a rev from the fork
<clever>
and it will just work, even without the .git
<jtojnar>
clever you are right, that will work too
<worldofpeace>
Reading the very last comment of https://gitlab.gnome.org/GNOME/glib/issues/543 "but still it's a nice property for a system to make the wrong thing - executing a non-existent binary - impossible to happen, instead of delegating the problem to error UIs.". TBH, why can't they check the path exists in the Exec case? Perhaps we should just patch it, since things in nixos can be ran uninstalled
<worldofpeace>
meh IO
<jtojnar>
worldofpeace I think because the gio-unix API is badly designed and does not support handling failures
<jtojnar>
it is common issue (e.g. AccountService does not tell you when you cannot change username/password), I would say it has something to do with how terrible language C is
<worldofpeace>
accountsservice is on some silly stuff something, though. Yep, 😁 C is easily a "wants to be untouched" lang for me.