<Profpatsch>
siraben: that one is a bit harder, since it depends on which function you are calling
<Profpatsch>
I’d restrict to stdenv.mkDerivation first
<siraben>
Right.
Profpatsch has joined #nixos-dev
<supersandro2000>
and it causes rebuilds
<supersandro2000>
lots of
__monty__ has joined #nixos-dev
sorki has joined #nixos-dev
srk has quit [Remote host closed the connection]
sorki is now known as srk
<eyJhb>
Anybody have some time to talk about DockerTools in nixpkgs? It seems like it is build on some wrong assumptions. ie. In our manifest file, the first entry in that `[0]` is not always the entry we want, as we actually want the last one (as that is the latest one), etc. But I am not sure if I am overlooking something?
<eyJhb>
It is just annoynig that the fromImage really does not "work" as such
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 268 seconds]
<siraben>
supersandro2000: it does? I thought changing name+version to pname shouldn't cause a rebuild
<supersandro2000>
siraben: I merged something yesterday that caused a rebuild
<supersandro2000>
can't find it right now
<supersandro2000>
maybe it changed some variable from name to pname
<siraben>
does anyone have a way to query packages maintained by a certain user?
<immae>
supersandro2000: did you try nix-diff to figure out the diff ?
<immae>
(and as far as I know name + version to pname do cause a rebuild)
saschagrunert has quit [Remote host closed the connection]
<gchristensen>
the first 6h was wasted and re-tried, so onlyf ~12h
julm has quit [Ping timeout: 258 seconds]
__monty__ has quit [Quit: Biab, building on a memory-poor system >.<]
<etu>
gchristensen: firefox :(
<gchristensen>
hm?
<gchristensen>
oh
<gchristensen>
yeah that one is gonna be a doozy
<Taneb>
What's this that's building?
<gchristensen>
all of iso_gnome
<gchristensen>
it fetches it, then runs nix-build --check
<Taneb>
To waht end/
<Taneb>
?
<gchristensen>
r13y.com
<Taneb>
Ah!
<Taneb>
I was wondering if you'd move on to a graphical ISO when the minimal one is reproducible
<siraben>
Are there plans to move that under nixos.org/reproducibility or something?
<siraben>
r13y.com seems kind of random for outsiders
<gchristensen>
I have no such plans
<siraben>
Oh so is this the first time you're building the graphical iso?
<gchristensen>
I've built a plasma iso before
<siraben>
will r13y.com be showing the percentage for the graphical and minimal iso then?
<gchristensen>
no, I don't know how it'll do it
<gchristensen>
it'll be a totally separate page, it is a one-off build
<gchristensen>
if you'd like to help, I'd love your help =) github.com/grahamc/r13y.com
julm has joined #nixos-dev
<adisbladis>
etu: Iirc it's not possible to build firefox in a reproducible fashion?
<adisbladis>
At least not with some optimisations like PGO/LTO
<adisbladis>
Which you absolutely want
<etu>
adisbladis: Yeah, I would think that it's not really doable yes. Those optimizations are very nice...
<siraben>
gchristensen: hehe, might look into it.
<gchristensen>
sure
<gchristensen>
the report logging could be way better, like ... how many, progress, ... :P
jonringer has joined #nixos-dev
<gchristensen>
supersandro2000: I'm not sure this one should have merged: https://github.com/NixOS/nixpkgs/pull/109626 it is a fairly strange thing introducing something brand new that probably needed more discussion
<immae>
Couldn’t we have a quick-win with all the python modules by touch’ing the extracted files just after downlaoding the tarball? (and before running any python command)
<symphorien[m]>
how can I build a nixos vm with nixos-rebuild build-vm with more memory ?
<adisbladis>
gchristensen: I'm always amazed just how good diffoscope is
<gchristensen>
immae: what would the touch do?
<supersandro2000>
most of the diff pyc or dates
<gchristensen>
I'd expect them all to have a consistent timestamp already
<immae>
gchristensen: the diff for the python modules lies in the first bytes of the .pyc files, which corresponds to the timestamp of the related .py file
<gchristensen>
ah interesting
<gchristensen>
note also the minimal iso also has python packages in its build closure, but doesn't have this issue
<gchristensen>
I wonder why
<supersandro2000>
do the python packages have native code?
<immae>
gchristensen: I might mis-analyse the situation too, I only looked at the pyc spec and compared with the diffoscope
<gchristensen>
you probably have it righT!
<immae>
oh cool
<gchristensen>
I certainly haven't read the pyc spec :)
<immae>
I didn’t read the whole spec, only the first bytes :D
<gchristensen>
we should figure out how to make this report linked to from the homepage and generate it regularly :)
cole-h has joined #nixos-dev
tgamblin-llnl has joined #nixos-dev
<supersandro2000>
propagatedBuildInputs or makeWrapper with PATH env? I am not sure which is preferred and why
Guest4239 has joined #nixos-dev
Guest4239 has joined #nixos-dev
Guest4239 has quit [Changing host]
Guest4239 is now known as joepie91
rajivr has quit [Quit: Connection closed for inactivity]
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
__monty__ has joined #nixos-dev
<symphorien[m]>
<supersandro2000 "propagatedBuildInputs or makeWra"> propagated build inputs only work inside a nix build (or nix-shell)
<symphorien[m]>
so only wrapping PATH or patching the source is correct
NinjaTrappeur has joined #nixos-dev
teto has quit [Quit: WeeChat 3.0.1]
rj has joined #nixos-dev
<clever>
cycle detected in build of '/nix/store/hilbc39k1bipqdflji7vlmcwazmvln9h-armv6l-unknown-linux-gnueabihf-stage-final-gcc-debug-7.4.0.drv' in the references of output 'lib' from output 'out'
<clever>
and --keep-failed didnt keep it
<clever>
now what? lol
<gchristensen>
something must be in the water, I'venever seen so many errors about cycles lately
<clever>
gchristensen: i'm shuffling outputs in the cross gcc
<clever>
gchristensen: if i build with sandbox=false, then it does keep the outputs
<clever>
now i get to rebuild another 3 or 4 gcc's in a row...
rj has quit [Quit: rj]
justanotheruser has quit [Ping timeout: 246 seconds]
<clever>
[6/17/268 built, 43 copied (156.2 MiB), 0.0 MiB DL] building gzip-1.10 on ssh://builder@192.168.2.32
<infinisil>
I think this plugin just loops through all jobset inputs, triggering github status notifications for if they're github repos. But with flakes this needs to be changed to signal it to the flake reference
<infinisil>
Currently trying to figure out how
<gchristensen>
yeah that looks hard
<infinisil>
I think it might just be like an `if ($eval->flake != undef) { <match flake url to owner/repo/rev> } else { <the foreach input loop> }`
<clever>
cycle detected in build of '/nix/store/xf9lcfi41pk271r2ykscqg67jmskv369-armv6l-unknown-linux-gnueabihf-stage-final-gcc-debug-7.4.0.drv' in the references of output 'lib' from output 'out'
<gchristensen>
one thing though is I don't thnik it can build locally really without being trusted? or does it set the store path so it is user writable?
<gchristensen>
oh, no, the problem is remote building. ignore me.
<energizer>
Sometimes unfree packages have problems but the problems aren't noticed because hydra doesn't build them because they can't be redistributed. Could hydra build them for testing purposes without redistributing?
<gchristensen>
Hydra has no mechanism to build but not upload
<gchristensen>
hydra has no concept of free / unfree, either
<energizer>
suppose they're built and uploaded, could the cache disallow reads for unfree?
<gchristensen>
nixpkgs introduces the idea of freeness and by default refuses to build them from within nixpkgs
<energizer>
s/reads/downloads/
<gchristensen>
on another level, the freeness may be very unfree -- like "not allowed to run this on systems with more than 2 cores" or "can't run this in a datacenter"
<gchristensen>
so it becomes a very difficult question of if it is legal for hydra to "build" it
<energizer>
sure, maybe some more level of detail is needed
<energizer>
could `pkg.meta.redistributable = false` work?
<gchristensen>
I'd be interested in having hydra build and upload unfree, redistributable software like the SSPL and ISPL
<gchristensen>
but unfree unredistributable ... that is a different line I think
<energizer>
i am thinking in particular of https://discourse.nixos.org/t/comparing-nix-and-conda/11366/8 "The are many paper cuts, but our current biggest problem [1] is that we do not have packages built against MKL and CUDA in our binary cache. This makes the user experience miserable. With conda or plain old pip, you are up and running in a few seconds. With nixpkgs, you are first off to one or two hours of builds. That is if the packages build at
<energizer>
all, since we don’t build them in Hydra regressions are not always noticed."
<gchristensen>
yeah, I think those are redistributable
<gchristensen>
I think MKL requires ISPL
<gchristensen>
yeah, MKL is ISPL
<gchristensen>
cc zimbatm
<gchristensen>
I'd like to have hydra build them, but the important thing is that builds for, like, nixos tests and stuff still fail if you use unfree software, otherwise we inadvertantly make nixos an unfree OS!
pmy_ has quit [Ping timeout: 258 seconds]
pmy_ has joined #nixos-dev
<infinisil>
Well damn: not a content address because it is not in the form '<prefix>:<rest>': /nix/store/pl8hg4ghv0srdn6p7hddvbwpd4l2lr7x-test
<clever>
cycle detected in build of '/nix/store/wa547lcy3hl4mxss60b4m4z75bw5zjhr-armv6l-unknown-linux-gnueabihf-stage-final-gcc-debug-7.4.0.drv' in the references of output 'lib' from output 'out'
<clever>
and still fails...
<clever>
the .py is still there
pmy_ has quit [Ping timeout: 272 seconds]
pmy_ has joined #nixos-dev
__monty__ has quit [Quit: leaving]
<infinisil>
Yeah never mind, the restricted mode error can still happen
<infinisil>
If somebody has a quick solution for that, that would be great
<infinisil>
(context hydra)
<infinisil>
I guess something about IFD
<infinisil>
Oh, what if I just set allow_import_from_derivation
<infinisil>
Nope
<infinisil>
(Putting `allow_import_from_derivation = 1` in hydra.conf doesn't work)
<infinisil>
Ah, I just need to add the urls I want to allow to nix.conf's allowed-uris
<infinisil>
Fair enough
<das_j>
infinisil: in prePatch just do sed -i 's/evalSettings.restrictEval = true/evalSettings.restrictEval = false/' "$(find -name hydra-eval-jobs.cc)"
<{^_^}>
hydra#866 (by Infinisil, 24 seconds ago, open): Fix Github status plugin for flakes
<infinisil>
gchristensen: ^
<dhess>
infinisil: how does a flake jobset work? I tried but couldn't figure it out and just ended up writing a release.nix that returns .hydraJobs.
<infinisil>
dhess: It looks at the hydraJobs output
<infinisil>
Otherwise it's pretty easy
<infinisil>
s/easy/straightforward
<dhess>
infinisil: just set nixexprpath to flake.nix?
<infinisil>
You can change the jobset to a flake one, then it asks you for a flake to use
<infinisil>
No nixexprspath necessary
<gchristensen>
(or valid)
<dhess>
so declaratively, set "type" to "flake" ?
<infinisil>
Ah
<infinisil>
Wait I'll give an example
<infinisil>
dhess: { type = 1; flake = "github:owner/repo/rev"; <all the other properties except nixexprinput, nixexprpath and inputs> }
<dhess>
cool thanks, I'll try that out this weekend
<infinisil>
The development with foreman worked great btw, thanks for the tip cransom++ and others
<{^_^}>
cransom's karma got increased to 8
<clever>
cycle detected in build of '/nix/store/hkw3izdchp62yqiv7kyvx3via1xj7z32-armv6l-unknown-linux-gnueabihf-stage-final-gcc-debug-7.4.0.drv' in the references of output 'lib' from output 'out'