<dtz>
I thought there was something where it was discussed a bit more
<dtz>
bah sorry
<dtz>
simpson: what sort of builders have progress that'd be good to support? :)
<simpson>
dtz: Ones that come to mind: CMake, Python, Cabal, Perl.
lassulus_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 264 seconds]
lassulus has quit [Ping timeout: 268 seconds]
lassulus_ is now known as lassulus
matthewbauer has joined #nixos-dev
<matthewbauer>
hey all, does anyone know how to keep a remote builder running after my laptop has gone to sleep? the build seems to stop as soon as the connection is lot
matthewbauer has quit [Ping timeout: 256 seconds]
lezed1 has joined #nixos-dev
<lezed1>
I have a question about getting a dyn lib.so to be detected. `ldd` reports a binary needs `libX11.so.6` twice - the first one is not found but the second one is found properly. I've already wrapped the program to add `${libX11.out}/lib` to `LD_LIBRARY_PATH`, but it doesn't get picked up for both duplicates of the library. Any ideas how to fix that?
Synthetica has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 248 seconds]
__Sander__ has joined #nixos-dev
<aszlig>
niksnut: hm, regarding the "not-restartable-failed-with-output" thingy: what about using BuildMode of bmCheck if the current output contains a nix-support/failed once we do a restart of a job in hydra-queue-runner?
<niksnut>
that would require overwriting outputs in S3, which is a bad idea
<aszlig>
niksnut: but only if we upload a failed-with-output build to S3
<niksnut>
hydra uploads everything to s3
<aszlig>
niksnut: right now, it does, yes
jtojnar has joined #nixos-dev
<aszlig>
niksnut: so if i'd change that to prevent failed-with-output builds from uploading to S3 and use bmCheck for those builds on restart, would that work?
<aszlig>
niksnut: and also regarding large C files in nixpkgs: should i move them off to a separate repository? i thought i would put them into the same dir so that the implementation of the qemu patch doesn't divert from the actual video encoder
<aszlig>
if this would be on a separate repository this would not only mean that the implementation could divert but also make it harder for other people to make changes
<niksnut>
if you don't upload to S3, where would they be stored?
<aszlig>
ah, nope... it still resides on the build machine but it's not marked as valid
<niksnut>
aszlig: in the first case, /nix/store/i3ysd789998jyfqqmz99axjbs547s4z4-foo is not a valid path
<aszlig>
yep
<niksnut>
I'm thinking about adding an attribute like __keepFailedOutputs = [ "video" ] telling Nix which outputs to move to a content-addressed location and register as valid
<niksnut>
it could also be a global Nix config options (e.g. keep-failed-builds = true) but that might be too wasteful
<aszlig>
okay, so in this case the videos only need to be written to a separate output and they should be available for inspection
<aszlig>
that sounds good
<aszlig>
okay, so the only thing still to solve is what to do with the qemu patches and/or the video encoder itself
<aszlig>
the thing is: the video encoding is only part 1
<aszlig>
i'd like to later add some other things to the ui module that can be used to watch for changes in certain regions of the screen
<aszlig>
for example to make mouse/keyboard input more reliable
<aszlig>
so if we input some text to some ui widget in the vm, a key is pressed, the ui module checks whether there was a change in that widget and continues with more key input *only* after there was a visual change
<aszlig>
in a qemu ui module we only get changes, not full frame updates, so this is perfect for something like this
<aszlig>
moving the code to a separate repository would make the implementation less visible and also harder to change for contributors
<aszlig>
another addition i had in mind is watching for certain patterns in the ui, for example we could check whether there is the K icon on the bottom-left and also _where_ it is located
<aszlig>
(for the plasma test)
<aszlig>
like eg. $machine->findVisual('foo.png')->center->click; (or something like that)
<aszlig>
maybe not necessarily a png, but some mask that applies to greyscale approximation
<aszlig>
(approx, because it could be antialiased and/or have other filters applied)
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
<aszlig>
so in summary: the code will probably get bigger, but probably not for the video encoder
<niksnut>
aszlig: cleanest probably would be to just put a fork of qemu somewhere (e.g. github) and fetch that
<niksnut>
although that might require too much work updating the fork
<niksnut>
or use fetchpatch to get only the commit containing the changes
<aszlig>
niksnut: and for the video encoder an additional repository?
<aszlig>
because i didn't want to shovel ffmpeg into the closure of qemu_test
<aszlig>
so the encoder is separate from qemu but the intermediate format has to be kept in sync
<aszlig>
having them in separate repositories introduces the risk that they divert
<niksnut>
hm
<aszlig>
another way would be to add versioning to the format, so that newer encoders can still read the old format
<aszlig>
(of course only if the format would change)
<gchristensen>
"has a max RSS of .56 GiB rather than 4.7 GiB." :O
<niksnut>
what the commit message doesn't mention is the associated slowdown :p
<gchristensen>
:D
<gchristensen>
I _THINK_ Packet will be deploying updated NixOS images, for 18.03
<gchristensen>
and loads of bug fixes to the default installation
<niksnut>
cool
<gchristensen>
I didn't realize it until recently, but the display of GRUB was broken, so you couldn't do the famous rollback-via-bootloader :$
<LnL>
:o
jtojnar has joined #nixos-dev
<ikwildrpepper>
niksnut: a __keepFailedOutputs would be great, I think
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 245 seconds]
jtojnar_ is now known as jtojnar
peti has quit [Quit: restart irc client to get a proper timezone]
peti has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 264 seconds]
jtojnar_ is now known as jtojnar
jtojnar_ has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar_ has quit [Ping timeout: 264 seconds]
jtojnar has joined #nixos-dev
goibhniu1 is now known as goibhniu
<crystalgamma[m]>
hi everyone. I started porting NixOS to ppc64le a few weeks ago and was able to successfully install and boot it earlier today. Anyone interested in getting this upstreamed?
matthewbauer has joined #nixos-dev
Synthetica has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
matthewbauer has quit [Ping timeout: 248 seconds]
matthewbauer has joined #nixos-dev
ixxie has joined #nixos-dev
matthewbauer has quit [Remote host closed the connection]
matthewbauer has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
<Profpatsch>
Hrm, is there a reason the .so files are not in libressl.dev, but in libressl.out?
<Profpatsch>
The lib/pkgconfig stuff is in .dev
<matthewbauer>
that's how it should work. we want the "real" package to be in out and miscellaneous "helper" stuff to be put in other outputs.
<Profpatsch>
matthewbauer: ah, .dev is for headers only?
<niksnut>
no, for all build-time-only stuff
orivej has quit [Ping timeout: 264 seconds]
<niksnut>
I suppose the .so symlinks could be in dev, but it would probably cause lots of headaches
<Profpatsch>
Hm, okay
<Profpatsch>
I thought in a perfect world, "out" would just be the catch-all part.
<Profpatsch>
But the .so files could also be moved to .lib
goibhniu has quit [Ping timeout: 264 seconds]
lezed1 has joined #nixos-dev
orivej has joined #nixos-dev
<lezed1>
I have a question about getting a dyn lib.so to be detected. `ldd` reports a binary needs `libX11.so.6` twice - the first one is not found but the second one is found properly. I've already wrapped the program to add `${libX11.out}/lib` to `LD_LIBRARY_PATH`, but it doesn't get picked up for both duplicates of the library. Any ideas how to fix that?
<clever>
lezed1: have you tried instead adding it to the rpath with patchelf?
<lezed1>
yes, it worked when doing it manually, but I could never get it to work when part of the derivation. It also seems that the rpath is completely changed at some point (maybe in fixup?) to include gcc libs (like `libstdc++.so.6`), and that was lost when I patched in install phase
<lezed1>
I also tried patching in post fixup, and the rpath looked great when I checked it manually, but it still couldn't find the lib
<lezed1>
lastly, this used to work properly on an older NixOS install (a few months back on 17.09)
<orivej>
crystalgamma[m]: We may accept your changes to support ppc64le, and this should help you in keeping your fork in sync with the upstream.
jtojnar has quit [Ping timeout: 240 seconds]
goibhniu has joined #nixos-dev
ixxie has quit [Ping timeout: 256 seconds]
<crystalgamma[m]>
great! can I get the bootstrap files hosted with the others?
<gchristensen>
bootstrapping is tough because we have to trust it ultimately
<gchristensen>
can you document how to bootstrap, so a well trusted person can recreate it?
<Dezgeg>
ideally it will just be an invocation of make-bootstrap-tools-cross.nix
<gchristensen>
^
<gchristensen>
Dezgeg++
<{^_^}>
Dezgeg's karma got increased to 1
<crystalgamma[m]>
oh am I missing messages through the matrix relay? let me quickly fire up an irc client
CrystalGamma has joined #nixos-dev
<crystalgamma[m]>
problem is, I don't have a x86 NixOS lying around to try right now
<gchristensen>
if you have $5 I know how to get one :)
<crystalgamma[m]>
what I did is use the native stdenv from Ubuntu-ppc64le to invoke make-bootstrap-tools
<crystalgamma[m]>
well I'd need to get a new disc to install a new x86 NixOS
<gchristensen>
you could get a VM from aws/digitalocean/packet.net/etc. and hack there?
<crystalgamma[m]>
but I'll see what I can do
<crystalgamma[m]>
I might try that (never done that before, though)
<Dezgeg>
nix-on-debian or whatever distro should work just as well
<gchristensen>
true!
<crystalgamma[m]>
but are the bootstrap files not reproducibly built? I actually built another set of bootstrap files using the ones I originally made, and they did not match
<Dezgeg>
don't think they are bit-for-bit reproducible
<gchristensen>
one day ...
<dtz>
(and even if they would be you may need to go an iteration or two)
<crystalgamma[m]>
well I did do that over like three stages
srhb has quit [Ping timeout: 248 seconds]
srhb has joined #nixos-dev
<dtz>
(but I'm not suggesting you do so, I would be surprised if we actually got that)
<crystalgamma[m]>
I had hoped they would converge
<dtz>
oh, well
<dtz>
it's a fun experiment, curious how .much they differed--what ways, etc..
<dtz>
but there are lots of reasons we'd produce slightly different things, for sure
<crystalgamma[m]>
it's an interesting experiment for sure. If I knew that the cross-built binaries I'd produce on a cloud instance match the one I built on my system I'd rest much more easily
<dtz>
well the question is if they are different in ways you care about
<dtz>
bit-for-bit being the easiest way to compare but they might be for all purposes equivalent andsuch
<dtz>
anyway yeah it'd be fun to put together something like that and poke at the results :)
<crystalgamma[m]>
yes but if they are equivalent for all relevant purposes, the question becomes, why not make them actually identical :P
<crystalgamma[m]>
You know, I'll analyze these things while I separate the the hacks from the solutions in my changes
pie__ has quit [Ping timeout: 264 seconds]
pie__ has joined #nixos-dev
jtojnar has joined #nixos-dev
ixxie has joined #nixos-dev
pie__ has quit [Ping timeout: 264 seconds]
jtojnar_ has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
pie_ has joined #nixos-dev
jtojnar_ has quit [Ping timeout: 276 seconds]
goibhniu has quit [Ping timeout: 265 seconds]
pie_ has quit [Ping timeout: 264 seconds]
ixxie has quit [Ping timeout: 248 seconds]
Lisanna has joined #nixos-dev
pie_ has joined #nixos-dev
lezed1 has quit [Quit: Connection closed for inactivity]
matthewbauer has quit [Ping timeout: 265 seconds]
Sonarpulse has quit [Ping timeout: 248 seconds]
CrystalGamma has quit [Quit: Leaving]
matthewbauer has joined #nixos-dev
contrapumpkin is now known as filthySJW
filthySJW is now known as contrapumpkin
pie_ has quit [Ping timeout: 240 seconds]
goibhniu has joined #nixos-dev
matthewbauer has quit [Remote host closed the connection]