<ekleog>
wasn't there some faketime hook? it looks like adding it to `nativeBuildInputs` isn't enough to get the derivation faketime'd
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
<samueldr>
infinisil: adding "bcachefs" to boot.supportedFilesystems apparently automatically brings in pkgs.linuxPackages_testing_bcachefs which is now based on 4.19+ kernel, which is why the bcachefs test is failing
<samueldr>
so, yeah, it's definitely related to the 4.19+ failure, since it is the 4.19+ failure
phreedom_ has joined #nixos-dev
phreedom has quit [Ping timeout: 256 seconds]
joepie91 has joined #nixos-dev
pie__ has quit [Ping timeout: 252 seconds]
<ekleog>
if someone has some spare time to have a look at #57559, it's way too late and I'm quite likely going to break the world if this lands in its current state -- that said, 'night, and please hl me if you find something interesting about it :)
<{^_^}>
nix#2718 (by teto, 2 days ago, open): crash when evaluating module
<aszlig>
samueldr: okay, my memory seems to be wrong, just tried it with sshfs and it does work
<aszlig>
hmm.....
<aszlig>
-rwxrwxrwx 1 aszlig users 29368 Jan 1 1970 hello
<aszlig>
... works
<aszlig>
-rwxrwxrwx 1 root users 29368 Jan 1 1970 hello
<aszlig>
... doesn't
johanot has joined #nixos-dev
<aszlig>
tried with a different set of permissions and only the owner seems to be the culprit
<aszlig>
at least this pins down the issue to a smaller subset
<aszlig>
we could as a workaround patch qemu again X-D
<aszlig>
i mean, we already have that patch that forces the uid to 0 for the store
<aszlig>
and no, that patch is not the issue, the output from above is without that patch
<aszlig>
that patch actually was my first suspicion, so it was the first thing i verified
<aszlig>
but before we patch qemu again to work around what is a kernel regression, i'm going to dig into the kernel side again... because that at least should make it easier to find the real culprit
phreedom_ has quit [Remote host closed the connection]
<aszlig>
and the service has just the runtime store paths available
<aszlig>
i might need to change the PR description, it's really awful
<aszlig>
but first, back to overlayfs
<aszlig>
i think i found the location of the bug
<domenkozar>
nice :D
<aszlig>
also, fpletz: https://github.com/aszlig/avonc <- that doesn't have the config file limitation of the one we have in nixpkgs, but it's also a "bit" more to maintain
<gchristensen>
ekleog, samueldr, can I get a summary of what was discussed w.r.t. hydra?
<ekleog>
gchristensen: basically: the failures look transient, and appear to arise mostly on packet-epyc-1 (though it's also receiving a big share of the jobs so that in itself is not conclusive), so it looks like hardware failures ; and you already checked RAM wasn't an issue with memtest ; so my assumption is it may be an issue in the CPU (overclocking or just imprecision during the manufacturing process), hence
<ekleog>
attempting to stress-test the CPU in a way similar to the RAM at the last attempt
<gchristensen>
can do
<gchristensen>
whats the process?
<ekleog>
I think it's something like “run prime95”, which appears to be FOSS and have a linux version, though I just noticed it doesn't appear to be packaged for nixos yet ( https://www.mersenne.org/download/#newusers )
<gchristensen>
okay
<gchristensen>
if you can package it, I can run it
<ekleog>
SGTM, will try to do so ASAP if no one beats me to it :)
<gchristensen>
thank you a lot
<domenkozar>
manveru: do post it for next week
orivej has joined #nixos-dev
<manveru>
domenkozar: one more thing, "Updated merchant report for the release" should have its own bullet point :)
<domenkozar>
ah, thought that's artwork related :)
<manveru>
i guess, kinda, but no :P
<domenkozar>
agreed :)
* etu
spotted someone (lejonet) with a very cool freenode cloak (nixos project one). Who do I ask to get one?
<Ericson2314>
I'll comment again explaining myself better, this is also a place where the "build-time" "run-time" desciptions of the dependencies breaks down a bit, and one must think of cross directly.
<jtojnar>
I would expect the main problem stem from gir-introspect trying to parse CFLAGS
<jtojnar>
the typelibs itselfs should be platform independent (barring the path to library)
<Ericson2314>
it's sort of like gettext in that there's a library and executable part, right?
<Ericson2314>
(gettext vs libintl or whatever)
<jtojnar>
s/gir-introspect/scanner/
<Ericson2314>
except we're building a thing that would be naturally cross compiled, *and then we need to run it*
<jtojnar>
Ericson2314: yeah, except most app do not use either of those
<Ericson2314>
if you think of it as *more* an exectuable than a library, we can change the hostOffset to targetOffset
<Ericson2314>
but I think we will still need to have the dependency twice so the library part can be linked to the other library parts?
<jtojnar>
the executable is used by libraries to build bindings file
<jtojnar>
and then python programs use pygobject (linked against libgirepository) to load the bindings at runtime
<Ericson2314>
and the executable links the library code you built?
<Ericson2314>
something is definitely linking library code, but there could be two exes, one which wrapps tools, and one which is freshly built
<jtojnar>
the libgirepository library (used by pygobject) dlopens the path listed in bindings file (typelib)
<jtojnar>
so the programs do not need either the library or the executable
<jtojnar>
just the setup hook so that pygobject could find the generated typelivs
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 252 seconds]
<jtojnar>
there are some things that work differently (e.g. gtkdoc generation and rust/haskell bindngs) but that should not be issue in this simple case
<Ericson2314>
jtojnar: who generates them though?
<Ericson2314>
just the downstream pkg on demand, or the upstream dependency at build time?
<jtojnar>
each library, eg. gtk builds them at build time
<Ericson2314>
but the setup hook is only downstream?
<Ericson2314>
or also in gtk and friends?
<jtojnar>
yeah, only needed for downstram
<jtojnar>
for finding the typelivs
<jtojnar>
Ericson2314: actually, it migth be needed for building as well
<jtojnar>
when trying to build typelibs depending on other typelibs
<Ericson2314>
Ah ok
<Ericson2314>
Still this helps
<Ericson2314>
Sounds like targetOffset would be better
<Ericson2314>
Maybe
<jtojnar>
how does the offset factor into the envhook?
<jtojnar>
does targetOffset mean the hook will be run on dependencies whose host equals to the current package's target?
<Ericson2314>
exactly!
<Ericson2314>
jtojnar: how does it find the library to dlopen?
<jtojnar>
the library looks into the typellib, which contains something like <namespace name="Gtk"
<Ericson2314>
jtojnar: and I see the env hook assists with that
<Ericson2314>
ok so why is the nixpkgs in the library subdir
<Ericson2314>
should we have `out` and `bin` outputs by any chance?
<Ericson2314>
is the exe in dev?
<jtojnar>
> ok so why is the nixpkgs in the library subdir
<{^_^}>
error: syntax error, unexpected IN, expecting ')', at (string):222:26
<jtojnar>
what do you mean?
<Ericson2314>
sorry "why is the package in a library subdirectory in nixpkgs"
<Ericson2314>
and in which output does the exe go?
<jtojnar>
yeah, that's why I would like Triton-like layout more
<Ericson2314>
(and also which output does the lib go)
<Ericson2314>
hehe wouldn't we all
pie__ has quit [Remote host closed the connection]
<jtojnar>
the lib is in $out, the utilities in $dev
<Ericson2314>
ah ok
<Ericson2314>
jtojnar: so this is a lot like the the `foo-config` exe problem
pie__ has joined #nixos-dev
<Ericson2314>
so assume we naively cross compiler gobject-introspection
<Ericson2314>
now we have tools in `dep`. If the are compiled for the build platform, the `dlopen` will fail, if they are compiled for the host platform the `dlopen` will fail
<Ericson2314>
sorry if we compile for the host platform the dlopen would succeed, but we cannot run the program without an emulator!
<jtojnar>
I would expect gir-scanner to build GIR file for whatever host we build the library
<jtojnar>
assuming meson passes it the same flags it passed the compiler
<jtojnar>
it is basically a compiler with target determined by current host
<Ericson2314>
jtojnar: ok so yeah lets make it `targetOffset`
<jtojnar>
(in my limited understanding)
<Ericson2314>
but we may need to add it as a `nativeBuildInput` to places where it is only a `buildInput` today, if those exist and use `strictDeps`
<Ericson2314>
your understanding makes sense
<Ericson2314>
:)
<Ericson2314>
so in conclusion we still need it as both a `buildInput` and `nativeBuildInput` if we need to run the tool and link the library
<Ericson2314>
but in the python case we just need the tool, not the library, right?
<jtojnar>
in python case we need jut he setup hook
<jtojnar>
the tool is only needed by the libraries
<jtojnar>
for generating /nix/store/dgxmi7sx70a42k6kw7rzijmgx5m3mfqw-gtk+3-3.24.5/lib/girepository-1.0/Gtk-3.0.typelib
<jtojnar>
the library is only needed by runtime binding consumers (e.g. pygobject)
<jtojnar>
and python programs will use pygobject and the setup hook to load the typelib and dlopen the library
<Ericson2314>
jtojnar: oh!!!
<Ericson2314>
pygobject is a library
<Ericson2314>
jtojnar: I'm going to stew on that for a second
<jtojnar>
yeah, I shoul have bean more precise, I meant introspectable/bindable libraries
<Ericson2314>
so the setup hook doesn't run any tools, but the library and/or pygobjec do sniff the env vars that the env hook sets up?
<Ericson2314>
sorry "pygobject is a library" makes sense, but I had who uses the tools totally backwards
<Ericson2314>
the fact that gtk and friends don't use `strictDeps` atm also make us hit only half the problem, so we have to imagine the other half
<jtojnar>
Ericson2314: correct, the setup hook doesn't run any tools
<jtojnar>
yeah, the tools are only used to generate the binding files (and docs and for debugging)
<jtojnar>
hmm, apparently some of the g-i executables depend on libgirepository, I thought they were all python scripts
<jtojnar>
but that should not change anything in my understanding
<Ericson2314>
and they might also, in wrapping the compiler, cause the library to be linked?
<Ericson2314>
jtojnar: ok conclusion, take 2 :): the setup hook should have nothing to do the with dev output
<Ericson2314>
tool has nothing to do with setup hook
<Ericson2314>
and while pygobject links the library, the user of pyobject only transitively links the library
<Ericson2314>
i.e. doesn't need headers or the tools
<Ericson2314>
Can we make the setup hook a standalone derivation, and use `targetOffset`?
<jtojnar>
✔ tool has nothing to do with setup hook
<jtojnar>
✔ and while pygobject links the library, the user of pyobject only transitively links the library i.e. doesn't need headers or the tools
<jtojnar>
as for "the setup hook should have nothing to do the with dev output"
<jtojnar>
the setup hook actually does multiple things
ixxie has quit [Ping timeout: 246 seconds]
<Ericson2314>
hehehe
<jtojnar>
first, you should know that the typelib is generated in two steps: first XML representation is generated from the compile flags by g-ir-scanner
<jtojnar>
(GIR file)
<Ericson2314>
ok
<jtojnar>
then the typelib is converted to binary format for performance reasons (by g-ir-compiler, I think)
<Ericson2314>
it does a compile too I assume, "stealing" the CFLAGS for this?
<jtojnar>
Ericson2314: yeah, I think it is something like that
drakonis_ has joined #nixos-dev
<jtojnar>
not sure why when it already tries to parse the cflags
<jtojnar>
the typelib generation is just trivial conversion, IIRC
<jtojnar>
and typelib is what will be picked up at runtime (by pygobject through libgirepository)
<Ericson2314>
trivial conversion from the headers?
<jtojnar>
from the generated GIR file
<Ericson2314>
so what is the other purpose of the setup hook?
drakonis has quit [Ping timeout: 240 seconds]
<jtojnar>
we want to store the GIR too for some reason so one thing the setup hook does is it moves the GIR to dev output
<jtojnar>
in _multioutMoveGlibGir
<jtojnar>
that's the thing it has with dev output
<jtojnar>
yeah, I think I recall why it was invoking compiler in addition to parsing CFLAGS
<jtojnar>
glib's type system is semi-dynamic and so it needs to run the library to see what types are registered
<jtojnar>
this will kill cross-compilation
<jtojnar>
it runs the *_class_new functions ((static) class constructors)
<Profpatsch>
infinisil: Another (general) approach to debugging evaluation times would be to add a flamegraph output to nix itself.
<Profpatsch>
Because apart from very simple counters we have no way to debug the evaluation as far as I’m aware of.
<Profpatsch>
the bazel build system has an option to debug their evaluator by outputting the flamegraph format that can be read by the Chromium devtools (and so probably also firebug)
<Profpatsch>
We should do something similar.
<Profpatsch>
Screw that, adding it to the issue on GH
<Ericson2314>
jtojnar: is the dlopen at build time?
<Ericson2314>
that also kills cross compilation
<Ericson2314>
I think the whole thing is dead wrt cross compilation, except for emulation tricks
<jtojnar>
I think that is only at runtime
<Ericson2314>
oh ok that's less bad
<Ericson2314>
OK so we can split the setup hook in two, and then one part stays with gobject-introspetion.dev, and the other is standalone
<Ericson2314>
sound good?
<jtojnar>
sounds good
<jtojnar>
any specific emulation tricks on your mind
<jtojnar>
?
<ekleog>
Profpatsch: you could `-vvvvv`, add timestamping information to each line and count, I think
<ekleog>
though the time of debug printing would generate imprecision
<Profpatsch>
But in that case I think it’s important that the evaluator is capable of measurement. Maybe even a conditional compilation option in the nix build, so we can build an instrumented evaluator for debugging.
<ekleog>
yeah, having a semi-proper measurement would be great, the -vvvvv solution is really hackish and debug printing is going to add way more imprecision than could be done I think
<Ericson2314>
jtojnar: yeah it's a mess. I wasn't planning on doing any emulation tricks yet
<Ericson2314>
just thinking ahead so we get the design right today
<jtojnar>
Ericson2314: regarding "does targetOffset mean the hook will be run on dependencies whose host equals to the current package's target?", does it make a difference if whether the setup hook is in package's nativeBuildInputs or buildInputs?
<infinisil>
Profpatsch: That sure would be neat
<Ericson2314>
jtojnar: yes is does make a difference
<Ericson2314>
buildInputs would be called depsHostTarget
<Ericson2314>
nativeBuildInputs would be called depsBuildHost
<Ericson2314>
but as you noticed, I think only nativeBuildInputs have their setup hook run?
<jtojnar>
Ericson2314: so all the offsets are calculated against the current build platform?
<Ericson2314>
jtojnar: no they are still calcuated against the dep
<Ericson2314>
I thought there was a special rule that looked at the depedency's host offset to decide whether to run the setu hook
<Ericson2314>
but that doesn't exist
<Ericson2314>
so a setup hook for a build input for the library is fine
<Ericson2314>
*setup hook for the library is fine even though the library is usually used as build input
<Ericson2314>
standalone setup hook using targetOffset is also fine, setup should be used as a nativeBuildInput
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 244 seconds]
drakonis_ has quit [Ping timeout: 252 seconds]
<etu>
gchristensen: Sure, I'd like to request one by the name "etu" :-)
<gchristensen>
NixOS/users/etu ?
<gchristensen>
(or /user/, I forget :P)
<etu>
gchristensen: Sure, seems to be "NixOS/user/etu" that is the correct form :-)
<gchristensen>
ok, I've got a request from you (etu), aszlig, and ekleog -- anyone else want a cloak?
<worldofpeace>
jtojnar: can dfeet export dbus-send command snippets?
<jtojnar>
worldofpeace: am not aware of that
<jtojnar>
I guess not, as it is primarily meant to execute methods/signals itself
<jtojnar>
it would be nice to have more integration between the dbus tools (bustle & dfeet)
drakonis has joined #nixos-dev
<worldofpeace>
I guess, though it would be nice feature. dbus-send commands are annoying to type even with a wrapper script
drakonis has quit [Quit: WeeChat 2.3]
drakonis has joined #nixos-dev
<aszlig>
samueldr: i got it!
<aszlig>
finally!
<samueldr>
!!
<samueldr>
praise aszlig (hopefully)
<aszlig>
the culprit is that overlayfs internally uses O_NOATIME and this causes 9p to return -EPERM
<aszlig>
now i just need to figure out whether this needs to be fixed in 9p or overlayfs
<gchristensen>
!!!!!!!!!
<samueldr>
explain like I don't know what those return values mean, since I don't know what those return values mean
<samueldr>
:)
<aszlig>
EPERM -> operation not permitted
<samueldr>
well -EPERM was good :)
<aszlig>
O_NOATIME -> no access times
<samueldr>
O_ stands for?
<aszlig>
open flag
<aszlig>
or maybe "option"? don't know
<samueldr>
you know you're doomed to be "the one that checks kernel issues"? ;)
<aszlig>
well, i hope it's not always the case that i'm staring *at* the actual problem for so long
<aszlig>
because initially i didn't even thing that O_NOATIME would ever return -EPERM
<aszlig>
s/ing/ink/
<aszlig>
so at first i thought the underlying inode of the lowerdir was the wrong one
<aszlig>
then went to "maybe it's the wrong f_ops callback?"
<samueldr>
maybe drop a note in the ML thread about the finding in case it gives 'em an eureka moment too?
<aszlig>
samueldr: haha, i will, along with a patch
<aszlig>
they were on the wrong path as well
<aszlig>
totally wrong actually
<samueldr>
ah! I thought you tracked the issue, but still didn't have a plan for fixing
<aszlig>
"OK, what I don't understand and requires debugging is that the print of (realfile, IS_ERR(realfile) ? 0 : realfile->f_flags) suggests that realfile is not an error value and realfile->f_flags are 0."
<aszlig>
realfile _IS_ an error value
<aszlig>
the person probably was confused as i was during debugging sometimes, because there is realfile and realinode
<Profpatsch>
ah yeah, good ol kernel api, can’t even tell an error value from a normal value ;)
<aszlig>
both are *different* things
<aszlig>
or not entirely different, but realfile is the *result* of looking up realinode
<samueldr>
#54508 has a test to ensure overlayfs itself still works (fails with the initial revert patch)
<clever>
strace against qemu caught it passing O_NOATIME and failing
<aszlig>
clever: yeah, from that side you'll see the O_NOATIME
<aszlig>
okay, so it is the same bug
<aszlig>
clever: should i cc you when sending the patch?
<clever>
sure
<worldofpeace>
jtojnar: That is a good idea. Are you thinking of using gitlab for gnome too?
<jtojnar>
worldofpeace: no, I would create fetchFromGnome
<jtojnar>
since the mirror should be faster
<jtojnar>
just like fetchFromGitHub downloads the tarballs when possible
<gchristensen>
that sounds cool
<worldofpeace>
Right, some people are not really for `fetchFrom*somethingnew` but it would look cleaner
<samueldr>
there is a fetchFromGitLab already (if useful here)
noonien has joined #nixos-dev
obadz has quit [Quit: WeeChat 2.4]
<worldofpeace>
jtojnar: Unrelated, but should we distribute a gnome3 installer iso?
obadz has joined #nixos-dev
<clever>
aszlig: i think the issue is that overlayfs is trying to O_NOATIME the lowerdir, to keep it as read-only as possible, and then when 9plan forwards O_NOATIME to the host, you lack permission to hide your reads
<jtojnar>
worldofpeace: there was some discussion about it, people are worried about size
<noonien>
clever: have you managed to reproduce the issue?
<worldofpeace>
jtojnar: It would be bigger. But does that really matter for gnome? It wouldn't be the super blessed install iso
<clever>
noonien: not on my machine, i believe it has to do with the host kernel
<noonien>
if not, i can provide some more info if required
<clever>
aszlig: which host kernels have you reproduced it on?
<aszlig>
clever: >= 4.19
<aszlig>
clever: this was actually introduced with the refactor of overlayfs