<samueldr>
probably want to re-ask that at european working hours :)
harrow has joined #nixos-dev
ivan- has joined #nixos-dev
ivan- is now known as ivan
<samueldr>
tested passed for nixos:trunk-combined; meaning that once the queue is handled the nixos-unstable channel will update with the fixes for the latest CVE
<samueldr>
soon™
orivej has quit [Ping timeout: 258 seconds]
drakonis has joined #nixos-dev
justanotheruser has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
Jackneill has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
alp has joined #nixos-dev
<andi->
samueldr: it finished 5h before you posted and still there is no channel bump for unstable :/
<gchristensen>
maybe should go look-see
<gchristensen>
Jun 19 09:41:03 bastion z5wrdl1wkpzgqamrhvn3f37b13i2pc7m-unit-script-update-nixos-unstable-start[21285]: error: in hwdata (/nix/store/cdcgcd5lxvgfli4k5g1yl9nslhs474mg-hwdata-0.316): [json.exception.parse_error.101] parse error at line 1, column 1: syntax error while parsing value - invalid literal; last read: '<U+001B>'
<gchristensen>
not sure that is the problem. investigating.
<andi->
thanks! We should probably have a bit of tooling tell us when these things happen. I was alreayd thinking of adding it to my i3/sway bar..
<gchristensen>
+1
<gchristensen>
we could, not too much trouble I think
<gchristensen>
I think it wouldbe also interesting to make them jobs runnable via buildkite or something like that, for transparency
<gchristensen>
okay one of the partitions is full, with a very large ./nixos-files.sqlite
ciil has joined #nixos-dev
<gchristensen>
ehhh why is this file so large
<gchristensen>
ok so I pruned that file and it is on its way
<gchristensen>
andi-: I bet we could write a scraper for hydra's latest-finished URL json endpoint + the channel revision and error if they drift for too long
<{^_^}>
#63392 (by ivan, 1 day ago, open): nixos/cassandra: use cassandra's default cluster name "Test Cluster"
<gchristensen>
...lol...
<gchristensen>
oof is that in stable
<ivan>
I doubt it, checking
<ivan>
stable should be fine
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
johanot has quit [Quit: WeeChat 2.4]
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 252 seconds]
jtojnar_ is now known as jtojnar
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
drakonis has quit [Quit: WeeChat 2.5]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 258 seconds]
pie__ has quit [Ping timeout: 246 seconds]
<Guest4937>
do we have any ways to improve performance when working on the Nixpkgs git repo? right now it's so huge, I was wondering if there is some way to tell git to ignore all commits before a certain date in my checkout
<Guest4937>
it seems to be related specifically to the git history, not the size of the repo for what it's worth
drakonis_ has joined #nixos-dev
<Guest4937>
this is with magit on Nixpkgs master
<Guest4937>
i know there's git shallow, but I'd like to not have to rm -rf with my current stuff
<tilpner>
What storage do you have it cloned onto?
<tilpner>
Just navigating to the repo would take >30s when I had it on HDD
<Guest4937>
it's ssd
<Guest4937>
although I'm now wondering if magit-forge is messing things up, let me try disabling that
<Guest4937>
it makes a ref for each pr which is probably too much for Nixpkgs
<LnL>
I had pr refs enabled at some point, but disabled it because it's too much
<Guest4937>
yeah I wish it was just more lazy about it. i don't need refs for every pr, but just some meta on them
alp has joined #nixos-dev
Jackneill has quit [Quit: Leaving]
pie__ has joined #nixos-dev
NinjaTrappeur has quit [Quit: WeeChat 2.4]
psyanticy has quit [Quit: Connection closed for inactivity]
bgamari has joined #nixos-dev
orivej has joined #nixos-dev
Jackneill has joined #nixos-dev
NinjaTrappeur has joined #nixos-dev
genesis has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
cjpbirkbeck has joined #nixos-dev
Guanin has joined #nixos-dev
<drakonis_>
ah, lazy multi commands broke printing command names on the flakes branch
bgamari_ has joined #nixos-dev
bgamari has quit [Ping timeout: 245 seconds]
jtojnar has quit [Remote host closed the connection]
<niksnut>
Drakonis_: doh
<drakonis_>
and since you're here, i'm not sure if i understood how to create system configurations with flakes
<gchristensen>
niksnut: a lot of users are seeing a strange issue with Nix fetching form the cache, which can't be reproduced with curl.
<gchristensen>
Drakonis_: check out the flakes branch, doc/flakes
<drakonis_>
another question, allowUnfree only works on impure mode
<niksnut>
if command line curl doesn't see it, it might have something to do with http/2
<gchristensen>
niksnut: fastly doesn't seem to think we have errors. manveru can you force http/2 on curl?
<drakonis_>
that would need a replacement in nixpkgs going forward, wouldnt it?
<niksnut>
Drakonis_: it's still an open issue how we're going to deal with nixpkgs config / overlays
<niksnut>
you can however do something like: import inputs.nixpkgs { config.allowUnfree = true; }
<drakonis_>
huh, neat.
<niksnut>
well it's a bit ugly since it bypasses the regular flake outputs of nixpkgs
<drakonis_>
my other question is, if i understand the docs correctly, i would have to add the config flake to my user registry
<drakonis_>
right?
<gchristensen>
manveru: can you try with http 2?
<drakonis_>
and as you said, nixos-rebuild doesnt support flakes yet, shouldn't that be done by nix now?
<manveru>
gchristensen: trying :)
<manveru>
doesn't seem to have any problem yet
<manveru>
also wondering if maybe reducing http-connections would help... is there a maximum time a download may take?
<niksnut>
Drakonis_: that's all not clear yet (tbh haven't thought deeply about it yet), but there should be some way to pass in some flakes to other flakes
<niksnut>
or specifically, pass the "overlay" outputs of some flakes to the nixpkgs flake
<niksnut>
for the flakified nixos-rebuild, it would call nix to build the "system" output of your configuration flake, or something like that
<niksnut>
and the configuration flake has a dependency on the nixpkgs/nixos flake
<manveru>
gchristensen: will see if `--option http2 false` helps
<drakonis_>
ah, alright.
<drakonis_>
invoking the rebuilds through nix itself hasn't been thought out yet, right?
<drakonis_>
the commands
<drakonis_>
rather.
<drakonis_>
nix system <subcommands>?
<niksnut>
we probably don't want nix to do that, since there is some nixos-specific stuff (like running switch-to-configuration)
<niksnut>
though you could imagine some generalized concept of activating a new profile generation...
<ekleog>
we technically already have it with nix-shell's shellHook
<drakonis_>
yeah.
<drakonis_>
who does shell completion for nix?
<gchristensen>
Nix's lack of "install hooks" is a good thing
<samueldr>
one thing to keep in mind, most `nix subcmd [subject]` commands follow some convention about the subject, and it feels like `nix system` not defaulting to ./. (./default.nix) be wrong
<samueldr>
(`nix build` acts as `nix build ./default.nix`)
<manveru>
gchristensen: doesn't seem like either helped
<manveru>
wonder if i can maybe see it in wireshark, though it's https so i won't see any of the actual traffic :|
<drakonis_>
gchristensen, they should exist in nixpkgs tho
<drakonis_>
some software doesn't suddenly become aware of environment changes unless you tell them to
<samueldr>
and subjects not starting with ./ or / (i.e. not paths) are respecting NIX_PATH → NIX_PATH=foobar=$HOME/tmp/nixpkgs/nixpkgs nix build foobar.hello
<drakonis_>
though we shouldn't be fiddling with system packages all the time
<drakonis_>
the biggest offenders here are browsers and desktop environments
<samueldr>
so it feels like `nix some-system-rebuild-command` would feel out of place if it defaults to a similar nixos-rebuild behaviour of following <nixos-config> implcitly
<samueldr>
for such reasons, having `nixos subcmd [subject]` like `nixos rebuild` probably would be better to signify the default invocation is the system, and `nixos rebuild ./default.nix` to build a specific configuration I guess
<samueldr>
what would non-paths subjects signify, though?
<manveru>
is the `nix system` inspired by `guix system`?
<drakonis_>
yes, kind of
<drakonis_>
isn't 'guix system' inspired by nixos-rebuild and some other commands?
<drakonis_>
i'm not going to use the build subcommand because it already has a use
orivej has quit [Ping timeout: 258 seconds]
<drakonis_>
even if it could be extended to provide system building features
<manveru>
i dunno, wouldn't `nix os` make more sense?
<drakonis_>
it also would, yes.
<drakonis_>
i wasn't sure on which word to use for the command
<samueldr>
(note that my previous thoughts don't care about the name of the commands, only that subjects in subcommands should probably be consistent)
<ekleog>
having a nix subcommand not tie nix to nixos would mean having to explicitly mention nixos in the configuration.nix
<ekleog>
(iow, samueldr++)
<{^_^}>
samueldr's karma got increased to 94
<drakonis_>
you don't have to do that though
<drakonis_>
you manage generations with it, not unlike nix-env
<drakonis_>
'nix generation' then?
<drakonis_>
speaking of nix-env, is it going to get subsumed at some point?
<clever>
Drakonis_: ive seen somebody mention before, to just remove -i/-e support from nix-env, but keep all the generation logic
<clever>
so nix-env only supports --set and --rollback
<ekleog>
building a nixos config is not building the configuration.nix, it's building <nixpkgs/nixos>
<niksnut>
ekleog: in the flake world you *do* have to explicitly mention nixos (or nixpkgs) in your configuration
<drakonis_>
with flakes it would make it possible to change ditch -i/-e from nix-env and subsume it into nix
<ekleog>
niksnut: oh if we're in the world where flakes have replaced nixos then why not I guess
<ekleog>
that's farther away than what I'm willing to spend brain cycles on, though, as it'll mean having rewritten a good part of nixos as flakes, afaiu
<ekleog>
I'm eager to see an RFC to have a clear overview of the current state of flakes, though, things are changing every time I'm looking at them :p
<clever>
this allows you to pin nixpkgs with a json file, or override it with <cardano_pkgs> in NIX_PATH
<clever>
Drakonis_: without a NIX_PATH, that will be much more complicated, because you would have to thread the value thru potentially 3 or 4 different repos
<clever>
or just go back to env vars, and builtins.getEnv!!
<drakonis_>
spooky.
<qyliss>
I'm also keen on an RFC soon. Nervous to see heavy development without much opportunity for community feedback.
<ekleog>
getting rid of all implicit uses of NIX_PATH in the new API does sound like a good plan, though
<ekleog>
(unrelated to flakes AFAIU though)
<qyliss>
My NIX_PATH points to the Nixpkgs that was used to build my system, in the Nix store.
<qyliss>
It's nice
<clever>
qyliss: i do that on most things i deploy with nixops
<drakonis_>
to be fair, under the new system, modules would just be a flake
<qyliss>
Means that nix-shell etc doesn't update until I rebuild my syste
<drakonis_>
if you're not running nixos, you're probably not importing modules
<qyliss>
I use modules on Darwin!
<drakonis_>
unless someone gets them to work without nixos, which is another barrel of fun
justanotheruser has quit [Ping timeout: 272 seconds]
<clever>
qyliss: i notice you also set nixos-config in nixPath, so nixos-rebuild will always read a file from the store, and you cant eidt your config enless you override it with -I nixos-config=!
<qyliss>
Yeah.
<qyliss>
I rebuild by system with the `activate` script in the top level of that tree
<clever>
qyliss: in my case, nixos-rebuild generally breaks nixops machines, so i pointed it to a file that asserts on false
<clever>
so it will just fail
<qyliss>
nice :)
<ekleog>
clever: About systemd service files for use outside of nixos, how do you handle name conflicts? Do you have some way of renaming the systemd services, or do you just assert it doesn't happen?
<clever>
ekleog: pray :P
<qyliss>
clever: I'd be interested to see the systemd outside NixOS stuff
<ekleog>
clever: hm'k, I'd have been really interested in some auto-renaming :D
<edef>
i used to pull systemd services from NixOS into my Arch system
<edef>
that system was … interesting
<qyliss>
I'm working on trying to fix Nix on illumos right now, and want to generate smf services (esp for nix-daemon)
<clever>
[root@amd-nixos:~]# nix-build '<nixpkgs/nixos>' -A 'config.systemd.units."tor.service".unit'
<clever>
qyliss: this will generate a directory, that contains tor.service
<clever>
as long as you -I nixos-config=something, then nixos will happily generate the service file
<qyliss>
oh neat
<clever>
if you eval = import <nixpkgs/nixos> { configuration = something; }; then you can also buildEnv { paths = [ eval.config.systemd.units."tor.service".unit ]; }
<clever>
which lets you build several units at once into a single dir
<clever>
then you just symlink those somewhere systemd looks
<clever>
and pray the service doesnt do too much nixos-specific stuff
<clever>
things like user creation obviously wont work, so you have to set those up yourself
drakonis_ has quit [Read error: Connection reset by peer]
<clever>
Drakonis_: did you enable 32bit pulseaudio support?
<drakonis_>
i think i have 32 bit pulseaudio enabled already
<drakonis_>
let me look
puck has joined #nixos-dev
<drakonis_>
i do have it
<drakonis_>
oh, something i nearly forgot, pulseaudio under wine has choppy audio in certain applications, the choppy audio does not happen in other distributions
<drakonis_>
which is strange
<qyliss>
wonder if it could be a kernel config issue
<clever>
that reminds me
das_j has quit [Quit: "Bye!";]
<drakonis_>
a easy way to test that out is through deltarune
<drakonis_>
i think its something gamemaker does?
<clever>
when i first installed nixos, i had major problems with pulseaudio, teamspeak, and rtkit
<qyliss>
you could try diffing /proc/kernel.gz from NixOS and other distros
<qyliss>
I've found bugs like that before
<clever>
the issue, is that by default, pulseaudio sets itself as realtime, to get less stutter
<clever>
the system was randomly hanging (for other reasons i think)
<clever>
and the watchdog went "oh crap" and started killing all realtime processes to save itself :P
<clever>
and teamspeak cant reconnect when pulseaudio restarts
<clever>
so it would just randomly go silent, mid-conversation, and id have no sign that it crashed
<clever>
the other people just stopped responding
<drakonis_>
huh
<clever>
and i was forced to restart teamspeak, every 3 minutes