ekleog changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 18.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
<matthewbauer[m]> can an admin in hydra restart this build: https://hydra.nixos.org/build/90476567#tabs-constituents
<matthewbauer[m]> ?
<matthewbauer[m]> They were a temporary failure
<samueldr> matthewbauer[m]: done
<matthewbauer[m]> thanks
jtojnar has quit [Quit: jtojnar]
<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
<infinisil> Ohhh
<infinisil> Nice
<infinisil> samueldr++
<{^_^}> samueldr's karma got increased to 59
<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 :)
<{^_^}> https://github.com/NixOS/nixpkgs/pull/57559 (by Ekleog, 5 minutes ago, open): iso-image: make reproducible by not relying on mcopy's readdir
emily has quit [Ping timeout: 250 seconds]
emily has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.3]
<aszlig> samueldr: it's not 9p unfortunately, i tried it with sshfs and the same thing happens
<aszlig> and it's only related to the nix store, everything else works fine, so something[TM] we do on the host side might be the issue...
<teto> I finally managed to get a stack https://github.com/NixOS/nix/issues/2718 (would be nice to have a "crash" label)
<{^_^}> 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]
phreedom has joined #nixos-dev
pie__ has joined #nixos-dev
__Sander__ has joined #nixos-dev
<domenkozar> thanks :)
<aszlig> domenkozar: looks good, especially the rant X-D
<domenkozar> :D
<domenkozar> ok
<domenkozar> a nice mixture of things this week
<aszlig> domenkozar: i might have something for next week =)
<domenkozar> \o/
<{^_^}> #57519 (by aszlig, 21 hours ago, open): nixos: Add 'chroot' options to systemd.services
<aszlig> systemd.services.foo.chroot.enable = true;
<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
init_6 has joined #nixos-dev
<manveru> maybe better next week :)
<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?
<etu> andi-: oh, thanks
johanot has quit [Quit: WeeChat 2.4]
<sphalerite> Anyone looking at updating libvirt to 5.x? (particularly fpletz)
<sphalerite> Because virt-manager is currently broken on 19.03
<gchristensen> etu: want a cloak? I'm going to ask for one for someone else today
jtojnar has joined #nixos-dev
<jtojnar> Ericson2314: libgirepository is runtime dependency of pygobject but rarely a direct runtime dependency of programs
<jtojnar> we only want it for the setup-hook majority of the time
<jtojnar> hence adding it to nativeBuildInputs
<Ericson2314> @jtojnar I have a meeting now but can ping you back after.
<jtojnar> okay, thanks
<Ericson2314> jtojnar: ok
ixxie has joined #nixos-dev
init_6 has quit []
<gchristensen> sphalerite: hiya
<sphalerite> gchristensen: o/
<gchristensen> sphalerite: I believe FCP is closed and we can merge? :)
<sphalerite> gchristensen: ooooh yeah
<sphalerite> do it :D
<gchristensen> I couldn't possibly, this is your call
<sphalerite> I couldn't possibly, I don't have write access :')
<gchristensen> oh
<gchristensen> hrm
<gchristensen> I can't just merge, I have to move it to accepted/ and then merge?
<gchristensen> weird, the RFC docs need some cleanup. we don't have an accepted dir.
drakonis has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
yl has joined #nixos-dev
ixxie has quit [Ping timeout: 244 seconds]
drakonis has quit [Quit: WeeChat 2.3]
ixxie has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 246 seconds]
drakonis_ has joined #nixos-dev
<jtojnar> Ericson2314: is the natural deduction part of manual supposed to read like this? https://i.imgur.com/hApxdpZ.png
drakonis has quit [Ping timeout: 252 seconds]
<jtojnar> I converted it to MathML because the source code was unreadable
<infinisil> jtojnar: Nice!
<jtojnar> infinisil: MathML is just terrible compared to TeX https://github.com/jtojnar/nixpkgs/tree/mathml-deps
<infinisil> Oh boy, you wrote that manually??
<jtojnar> yup
<jtojnar> lot of seach and replace
<infinisil> Could probably also have used a tex -> mathml/mathjax converter :)
<jtojnar> I tried some but it did not work very well
<infinisil> I see
<jtojnar> too bad there does not seem to be a good semantic XML syntax for math
<gchristensen> omg you're a hero jtojnar
<jtojnar> I guess this will not help 90% of people at all
<jtojnar> but it is something like gofmt, it should allow people not to have to parse the unfamiliar formatting
<Ericson2314> jtojnar: that's awesome!!!!
<Ericson2314> btw https://wiki.linaro.org/PeterPearse/GobjectIntrospection I'm told is a good explanation of why gobject-introspection is so weird
<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"
<jtojnar> version="3.0"
<jtojnar> shared-library="/nix/store/dgxmi7sx70a42k6kw7rzijmgx5m3mfqw-gtk+3-3.24.5/lib/libgtk-3.so.0,/nix/store/dgxmi7sx70a42k6kw7rzijmgx5m3mfqw-gtk+3-3.24.5/lib/libgdk-3.so.0"
<jtojnar> (binary-encoded)
<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
<Ericson2314> Yeah there is no native: true kwarg in https://gitlab.gnome.org/GNOME/gobject-introspection/blob/master/tools/meson.build
<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> :)
<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> ekleog: Measurement always generates 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
<jtojnar> Ericson2314: according to https://wiki.linaro.org/PeterPearse/GobjectIntrospection, the typelib format is not even platform agnostic
<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?
<Ericson2314> could be wrong on that
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 252 seconds]
<jtojnar> Ericson2314: it seems to be run in buildInputs as well https://paste.gnome.org/ppoujid0o
<Ericson2314> jtojnar: you're right
<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)
<{^_^}> https://github.com/NixOS/nixpkgs/pull/54508 (by bachp, 7 weeks ago, open): nixos/overlayfs: add test
<aszlig> samueldr: yah, that test should be fine...
<samueldr> that test isn't about the 9p failure, but instead to ensure overlayfs doesn't break (at least in the way the revert broke)
<aszlig> yeah
<aszlig> that revert was kinda bogus, sorry for that :-/
<aszlig> but now after digging through the overlayfs code it's a bit more clear to me why :-D
<samueldr> no worries, we didn't have a test to vet it more thoroughly and it looked like it worked fine!
<aszlig> so, anyway, just need to figure out whether the fault lies in overlayfs or 9p
<aszlig> hm... turns out that's a bit more murky here...
<aszlig> so, 9p returns -EPERM if you're not the owner of the file
<clever> is this a problem where qemu doesnt boot due to permission denied on init?
<aszlig> clever: yep
<clever> ah, i was just debugging that with noonien in #nixos, and we ran out of things to check
<clever> he's having the issue with zfs on the host
<clever> but when i build the same qemu from the same nixpkgs rev, it doesnt fail
ajs124 has joined #nixos-dev
<aszlig> which from an admin-perspective is actually a good thing
<clever> so it must rely on the host kernel version?
<aszlig> because if you mount with atimes, you actually want to have those times for a reason
dmj has joined #nixos-dev
* dmj pokes in
<aszlig> so there shouldn't be a way to circumvent them, so it returns -EPERM
<aszlig> clever: well, which host kernel version did you use
<aszlig> ?
<clever> it works normally on Linux amd-nixos 4.14.104 #1-NixOS SMP Wed Feb 27 09:08:09 UTC 2019 x86_64 GNU/Linux
<aszlig> yeah, that version doesn't have the regression
<aszlig> clever: does zfs return -EPERM if you open a file you don't own with O_NOACCESS?
<aszlig> sorry, err...
<clever> aszlig: checking...
<aszlig> s/O_NOACCESS/O_NOATIME/g
<clever> [clever@amd-nixos:~/apps/nixpkgs]$./result/bin/run-nixos-vm <aszlig> clever: in uapi it's __O_NOATIME <aszlig> like eg: open("/foo/bar", __O_NOATIME) <clever> oh wait, i didnt even set a pw on this vm, lol <clever> but even the act of logging in should open things... <clever> [root@amd-nixos:~]$ strace -p 26273 -ff -e open,openat,chdir
<clever> [pid 5478] openat(198, "hk3vpjkqk63jy3bx51gm0rw6mr29ia51-login.defs", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW) = 206
<clever> hmm, its not using O_NOATIME...
<aszlig> clever: strace doesn't help here
<aszlig> O_NOATIME is kernel-internal
<aszlig> but you can also use it from uapi
<aszlig> that way you can test whether it's the same bug
<clever> 2019-03-13 19:08:47 < noonien> http://vpaste.net/llTOZ
<clever> 2019-03-13 19:09:41 < clever> noonien: so qemu on the host is failing to open the init file, and forwarding the error down to the guest
<clever> [pid 18949] openat(29, "init", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_NOATIME) = -1 EPERM (Operation not permitted)
<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
<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?
<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
<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
<aszlig> clever: because the lowerdir inode lookup previously was in fs/open.c, now it's in fs/overlayfs/file.c
<clever> [clever@amd-nixos:~/apps/nixpkgs]$nix-build nixos/ -A vm --arg configuration '{ users.users.root.initialPassword = "root"; }' <clever> [clever@amd-nixos:~/apps/nixpkgs]$ git rev-parse HEAD
<clever> 37694c8cc0e9ecab60d06f1d9a2fd0073bcc5fa3
<clever> 4.14 on both host and guest, no issues
<aszlig> clever: yeah, as said, 4.19
<aszlig> clever: since a6518f73e60e5044656d1ba587e7463479a9381a to be exact
<clever> i thought i was on the same rev as noonien, but maybe thats his host rev
<clever> aszlig: is it the host or guest kernel that has to be 4.19?
<noonien> i've also got boot.kernelPackages = pkgs.linuxPackages_latest;
<aszlig> clever: the one with overlayfs, so the guest kernel
<clever> aszlig: ahh
<noonien> 18.09.2327.37694c8cc0e is my nixpks version