elvishjerricco has quit [Remote host closed the connection]
elvishjerricco has joined #nixos-dev
zowoq[m] has left #nixos-dev ["User left"]
justanotheruser has quit [Ping timeout: 260 seconds]
bennofs_ has quit [Ping timeout: 252 seconds]
bennofs_ has joined #nixos-dev
<rsynnest>
does anyone have experience using systemd tmpfiles.d in combination with DynamicUser and StateDirectory? Seems like these conflict but wondering if there's some way to make them play nice
<rsynnest>
maybe a question for #nixos ...
jonringer has quit [Ping timeout: 250 seconds]
<Ericson2314>
qyliss: would you want to make some sort of roaddmap some time?
<Ericson2314>
I like...don't even know where to begin for many things like how the entire system is assembled (bootloader, initramfs) even on linux
<Ericson2314>
I have no idea how important the remaining things like that `netbsd.tic` are either
<Ericson2314>
I am thinking less worrying about choosing the relative importance of things like "netbsd qemu image for nixos-style tests" vs "bootstrap binaries for pure native netbsd", than what the steps are
<Ericson2314>
(though I confess I know much more about how the latter works yet find the former much more exciting)
justanotheruser has joined #nixos-dev
<p01ar>
Ericson2314 hey :)
<Ericson2314>
p01ar: hi!
<p01ar>
!!!
<p01ar>
whats the news?
<Ericson2314>
I unfortunately wrote that just as I need to go get a late dinner
<Ericson2314>
news?
<Ericson2314>
I don't think much
<Ericson2314>
i mean one can build gnu hello for netbsd and I'm told it runs
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<p01ar>
nah related to the port
<Ericson2314>
of nix?
<Ericson2314>
you tell me :)
<p01ar>
meson for nix :^)
<p01ar>
anything intresting i dont know
abathur has joined #nixos-dev
<Ericson2314>
p01ar: nothing i know of
<Ericson2314>
but I will try to bring it up with eelco some more on monday
<p01ar>
okay fair :^)
<Ericson2314>
reminded me tomorrow to get a draft of my dynamic deps RFC up
<Ericson2314>
this would be for ninja->nix
<Ericson2314>
and then substitue a single derivation graph node for a subgraph
<Ericson2314>
cause i know eelco said something like "if we replaced make it would be with a nix-make"
MichaelRaskin has quit [Ping timeout: 240 seconds]
rajivr has joined #nixos-dev
<aaronjanse>
Dynamic dependencies?!?!
<aaronjanse>
I have no idea what that would involve. I look forward to seeing your RFC
<drakonis>
dynamic dependencies? that sounds fabulous
<Ericson2314>
well, more pressure for me to deliver. Good. :)
pmy has quit [Quit: WeeChat 3.1]
pmy has joined #nixos-dev
siraben has joined #nixos-dev
siraben has joined #nixos-dev
siraben has quit [Changing host]
arcnmx has joined #nixos-dev
arcnmx has quit [Changing host]
orivej has joined #nixos-dev
elvishjerricco has quit [Remote host closed the connection]
elvishjerricco has joined #nixos-dev
jonringer has joined #nixos-dev
bennofs_ has quit [Read error: Connection reset by peer]
<lukegb>
re: https://nixos.org/manual/nixpkgs/unstable/#sec-package-naming - the wording of this makes it sound like pname should have -unstable on the end and the version should be YYYY-MM-DD, but this is "obviously" written for name-style packages and not pname/version
<lukegb>
is the consensus that version = "unstable-YYYY-MM-DD"; is preferred? if so, I'll go update the manual :P
<lukegb>
(for stats: 460 files match `version\ =\ "unstable-`, 167 match `pname\ =\ "[^"]+unstable"`)
__monty__ has joined #nixos-dev
janneke has quit [Ping timeout: 245 seconds]
janneke has joined #nixos-dev
spacekookie has quit [Quit: No Ping reply in 60 seconds.]
spacekookie has joined #nixos-dev
Mic92 has quit [Ping timeout: 258 seconds]
Mic92 has joined #nixos-dev
joepie91 has quit [Ping timeout: 245 seconds]
<evils>
dunno about a concensus; i agree that -unstable in pname should only be used to disambiguate it from another package (don't change pname just because the commit used changed); and having something in a date version may be a fair way to prevent repology from assuming it's a release, though i don't think it's the only valid option (i like git- or git describe --tags, but that's ofc only applicable to git
<evils>
based repos)
bennofs_ has quit [Read error: Connection reset by peer]
bennofs_ has joined #nixos-dev
<ehmry>
I'd like to point out that just because software isn't versioned beyond a date doesn't make it unstable, thats kind of an odd judgement
<ehmry>
though that is often the case
joepie91 has joined #nixos-dev
joepie91 is now known as Guest22752
<evils>
yea the implication that it's not stable is one of the reasons i recoil from the use; though i think the intent is "not endorsed by the upstream developer" or "subject to change"
Guest22752 has joined #nixos-dev
Guest22752 has joined #nixos-dev
Guest22752 has quit [Changing host]
<lukegb>
yeah, I think "not a formal release, so probably hasn't undergone as formal a validation" is really the intent
Guest22752 is now known as joepie91
<evils>
i think a semantic version tag is entirely perscriptive (upstream perscribes the use of this); something like a git commit is entirely descriptive (it only describes what's being used); and a date can be either (descriptive if the packager just describes what date's code they're using, perscriptive if the upstream developer used that date as a tag)
<evils>
so using something extra in the ISO8601 date disambiguates the use of the date
<ehmry>
(I just made a PR for a lisp machine emulator with a date version, but thats because Lisp/Oberon/Smalltalk seems to exist in an alternate universe without versioned software packages)
<sterni>
lukegb: iirc there was at some point the idea to have unstable-YYYY-MM-DD as a version *unless* we have a stable and unstable version where the -unstable package would get -unstable in its pname and version would *just* be YYYY-MM-DD
<sterni>
lukegb: however I think this should probably be abandoned because it screws with repology for example (as pname doesn't match with the actual name anymore)
<lukegb>
ehmry: yeah, I just dropped a comment about that, heh
<sterni>
I think jtojnar can tell you more about it as well
<lukegb>
I think it already screws with repology
<MichaelRaskin>
I am pretty sure falsifying intermediate version numbers based on date (like 0.0.0.YYYY.MM.DD or 7.7.pre.0.YYYY.MM.DD) is the only way that can be made not to mess up version comparisons, but that would need a proper codification of how exactly we fake the numbers
<lukegb>
because repology's code appears to use the pname and version attributes, and then drop them and do re.match('(.+?)-([0-9].*)$', packagedata['name'])
<lukegb>
and then they mark packages as IGNORE if re.match('.*20[0-9]{2}-[0-9]{2}-[0-9]{2}', pkg.version)
<sterni>
yeah, it seems like it doesn't matter to repology if unstable is in pname or version now that I check again
sorear has quit []
sorear has joined #nixos-dev
<sterni>
okay, personally I'd say unstable- should always be in version regardless if we have an unstable and stable version or just an unstable one
<sterni>
someone should check if this messes with nix-env in any way, but I think it only relies on name anyways, right?
chvp has quit [Quit: authenticating]
chvp has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
ChanServ has quit [shutting down]
ChanServ has joined #nixos-dev
ChanServ has quit [shutting down]
ChanServ has joined #nixos-dev
jonringer has joined #nixos-dev
cole-h has joined #nixos-dev
tomberek has joined #nixos-dev
<abathur>
maybe "unstable-" just doesn't semantically fit with the version? can this be automatic in more/most cases? (I've also puzzled over this section... it may be a pointless time-waster at scale?) If the fetcher can reasonably distinguish between the ref/rev types, perhaps it could require <self_describing_semantic_date_attr> for commit refs and name the version
<abathur>
if so, maybe it's also meaningful to distinguish tag vs branch, too
abathur has quit [Quit: abathur]
<lukegb>
I'm impressed at the number of things we ship that include a bundled copy of clang
<lukegb>
and by impressed I mean dismayed :P
<jtojnar>
lukegb: repology uses pname and version returned by nix-env, which unfortunately are result of builtins.parseDrvName, not actual pname and version attributes
<jtojnar>
so unstable- at the beginning of version attribute will end up in nix-env's pname
<lukegb>
jtojnar: hmm, from my reading of their code they then throw that away anyway and then reparse the name attribute
<{^_^}>
nix#4463 (by jtojnar, 13 weeks ago, open): nix-env: Use pname and version attrs in -q
<jtojnar>
this one, sorry
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
devhell has joined #nixos-dev
devhell has quit [Client Quit]
devhell has joined #nixos-dev
devhell has quit [Remote host closed the connection]
devhell has joined #nixos-dev
devhell has quit [Quit: leaving]
rsynnest has quit [Quit: Connection closed for inactivity]
Guest80259 has quit [Ping timeout: 245 seconds]
thefloweringash has quit [Ping timeout: 245 seconds]
jonge[m] has quit [Ping timeout: 245 seconds]
regnat[m] has quit [Ping timeout: 245 seconds]
nh2[m] has quit [Ping timeout: 245 seconds]
roberth has quit [Ping timeout: 245 seconds]
garbas[m] has quit [Ping timeout: 245 seconds]
davidak[m] has quit [Ping timeout: 245 seconds]
jonge[m] has joined #nixos-dev
thefloweringash has joined #nixos-dev
Guest80259 has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
nh2[m] has joined #nixos-dev
roberth has joined #nixos-dev
regnat[m] has joined #nixos-dev
garbas[m] has joined #nixos-dev
davidak[m] has joined #nixos-dev
devhell has joined #nixos-dev
mjlbach is now known as aterius
aterius is now known as mjblach
mjblach is now known as mjlbach
<drakonis>
Ericson2314: dont be holding out on us
devhell has quit [Quit: nyaa~]
<samueldr>
anyone here sees any reason to keep grub legacy around for longer?
<samueldr>
talking about grub "1"
<samueldr>
I guess the real question would be: any users left? what migration paths do they have for their legacy boot machines?
<gchristensen>
is there reason to drop it?
<samueldr>
AFAIK it's not supported by the GRUB project for probably a decade
<samueldr>
huh, I'm looking at the history and the latest change to grub1 that isn't an inconsequential change and the most recent one was by myself in 2018
<samueldr>
and that's the other reason: AFAIK no one really maintains it
<Mic92>
attemp to drop it and see who complains?
<samueldr>
that's what I was going to do unless I had strong words against doing it
<samueldr>
it also would allow us to drop the grub1 specifics in the nixos modules
<MichaelRaskin>
Is it in need for any kind of maintenance, though?
<samueldr>
probably
<samueldr>
that's what I'm looking at right now
<MichaelRaskin>
Hmm, yeah, NixOS modules do get some edits
<MichaelRaskin>
(in the sense that you cannot just say that whatever touches GRUB1 stays as it is)
<samueldr>
and anyway having an important package (a bootloader) without maintainership is not good
<samueldr>
legacy boot is a dead-end anyway
<niksnut>
isn't grub1 needed for some old EC2 instance types?
<samueldr>
niksnut: glad to hear an actual concern
<samueldr>
I don't know!
<samueldr>
is it grub1 that's required, or legacy boot?
<gchristensen>
`the really old ec2 instances were a bit wacky
<samueldr>
yeah, that's why I'm asking
<samueldr>
it wouldn't surprise me that they need something specific
<niksnut>
IIRC it was for instance-store instances
<gchristensen>
# Generate a GRUB menu. Amazon's pv-grub uses this to boot our kernel/initrd.
<niksnut>
yeah, it just needs a generated config file
<niksnut>
pv-grub itself is provided by the VM
<niksnut>
*hypervisor
<samueldr>
AFAICT the previous changes to grub1 that were not reactionary fixes were in 2012 by niksnut :)
<samueldr>
in those failing tests /dev/sda and /dev/sdb are switched around
<samueldr>
totally not specific to that test, and I figure some other tests must fail because of that issue
maralorn has quit [Quit: issued !quit command]
<samueldr>
looks like only grub1 tests use "scsi" disk interface in the qemu tests
<samueldr>
so in the end it is an issue only for those tests
<samueldr>
alright
<samueldr>
so the even though we pass scsi index to the drives explicitly, sometimes it's sda, sometimes it's sdb
<samueldr>
fun!
<samueldr>
//nix/store/rl8m0k6n1k4g970wfg7g1789j8m1662h-run-nixos-vm failed and /nix/store/x8szfh0v2vdhcgp33bnj98lhcspfnah1-run-nixos-vm passed
<samueldr>
those, btw, are the scripts invoking the qemu vm
<samueldr>
interestingly, on the scsi bus the index is right, the 8GiB disk is always 2:0:0:0 and the other 3:0:0:0
<samueldr>
why is it that network interfaces get predictable device names, but not disks?
<samueldr>
(I know, /dev/disks/by-path and friends)
<samueldr>
let's see if we can use that!
<samueldr>
what's the test driver doing with stdout??
<lukegb>
swallowing it, mostly
<samueldr>
>:|
<samueldr>
why is it that it seems everything around me lately is trying hard to not give any useful information?
pmy has quit [Ping timeout: 240 seconds]
pmy has joined #nixos-dev
<samueldr>
alright, so it's hard to *conclusively test* that it works, but I think I got it
jonringer has joined #nixos-dev
pingiun has quit [Quit: Bye!]
janneke has quit [Quit: janneke quits Mes'sing]
janneke has joined #nixos-dev
<MichaelRaskin>
samueldr: well, predictability of network interface names is also often overstated… And maybe the problem is the same as with disks!
<gchristensen>
yes, it is definitely an issue
<samueldr>
great, definitely the pearl of wisdom that was neede
<samueldr>
needed*
<gchristensen>
probably the issue with NICs is disks get files in /dev for all its references, but not NICs, so udev can't come in and make a bunch of symlink options
__monty__ has quit [Quit: leaving]
<samueldr>
funny how I *knew* it was going to be said once I wrote the word "predictable"
<samueldr>
I guess it was predictable a predictable interface names naysayer would pipe up
<samueldr>
maybe that's the most predictable part of predictable interface names!
<samueldr>
I was able to get unreliable drive names often enough before testing my fix, but now that I have a fix, the damn thing predictably gives me /dev/sda for that drive!
<MichaelRaskin>
Should your fix work if you actually feed the images to the VM in a different order?
<samueldr>
on the VM side, ordering is already defined
<samueldr>
the SCSI bus has predictable and well-defined order
<MichaelRaskin>
And you use that order?
<samueldr>
the issue is that the kernel driver (apparently) sometimes gives the first device sda, more rarely the second device sda
<MichaelRaskin>
Yeah, something about first-to-initialise instead of first-on-bus
<samueldr>
something like that exactly
<MichaelRaskin>
Not sure how to create an initialisation delay by force… host load?
<samueldr>
probably not doable, only thing I can see is a FS that forces a delay only for one of the disk image files
<gchristensen>
I think it is a kernel race to some degree
<gchristensen>
it happens constantly on systems with lots of disks
<MichaelRaskin>
samueldr: strictly speaking, you do not need a selective FS if you make the images links to different FS'es
<samueldr>
in the nix sandbox? :)
<MichaelRaskin>
Nix knows how to hole-punch!
<samueldr>
though now I saw a weird issue with one of my runs
<samueldr>
which should have been successful
<MichaelRaskin>
Ouch
<samueldr>
and AFAIK should have also failed on the other setup
<samueldr>
woops, the commands runner apparently hangs if you have an unmatched quote in the command?
<samueldr>
I sent this
<samueldr>
print(machine.succeed("find /dev/disk/ '!' -type d -printf '%p → %l\n"))
<samueldr>
to try to debug that new issue
<samueldr>
wrote a check in the test, and fails the test when it's symlinked to the wrong (right) node
<samueldr>
now running in a bash until loop
<samueldr>
oh
<samueldr>
but if it fails that'll never resolve!
<samueldr>
meh, I'll give it a few minutes while I do other things
<samueldr>
huh, the test runner hung on... nothing obvious
supersandro2000 has quit [Killed (verne.freenode.net (Nickname regained by services))]
supersandro2000 has joined #nixos-dev
<samueldr>
finally got a sda↔sdb inversion!
<MichaelRaskin>
Congratulations!
<MichaelRaskin>
Did the fix work?
<samueldr>
yes
<lukegb>
\o/
<lukegb>
samueldr++
<{^_^}>
samueldr's karma got increased to 339
<MichaelRaskin>
Great!
<MichaelRaskin>
samueldr++
<{^_^}>
samueldr's karma got increased to 340
<samueldr>
but I wanted to check whether other things were using /dev/sda, but weren't obvious
<gchristensen>
samueldr++
<{^_^}>
samueldr's karma got increased to 341
<samueldr>
we don't have any /dev/sda or /dev/sdb references left in that test file
<samueldr>
(except for a comment)
<gchristensen>
it is a shame there isn't some way we could diff some stable output from two builds to see things like this faster
<samueldr>
it is a shame that we lost some of the more in-depth informations in tests
<samueldr>
e.g. failed tests outputs, and then the xml logs output
<gchristensen>
the failed test logs were a weird thing
<samueldr>
yes
<samueldr>
but especially for those with screenshots, had incredible value
<gchristensen>
yeah:(
bennofs_ has quit [Read error: Connection reset by peer]
<gchristensen>
how can we get them back? :)
<MichaelRaskin>
Would two-stage tests be worth the absurdity? (test itself always builds, and puts pass/fail report into nix-support)
bennofs_ has joined #nixos-dev
<MichaelRaskin>
Wrapper test then fails or passes
<gchristensen>
we couldn't ask hydra to re-run the failing build
<samueldr>
harder to restart failed tests
<gchristensen>
maybe hydra could upload the outputs on failure to the side cache
<samueldr>
sure, having them in the actual cache isn't good I assume
<gchristensen>
to a side cache*
<MichaelRaskin>
That conversation dangerously approaches fixed-output tests with details uploaded using network access in fixed-output builds…
<gchristensen>
lol
<gchristensen>
even worse, hydra would never rerun any tests
<MichaelRaskin>
Hm?
<gchristensen>
and I don't actually mean a cache, but some other public thing
<MichaelRaskin>
Each test has its own correct version
<MichaelRaskin>
So each test would be rerunnable until success