<gchristensen>
yes, right now logs are deleted after seven days
<gchristensen>
700M and 5,000,000 lines %)
<dtz>
wwhhhyyyy is libgcc_s.so.1 in our glibc package copied from bootstrap tools? >.<
<gchristensen>
:o
<dtz>
I swear we've discussed this before but can't find the thread on github O:)
<ekleog>
ok, thanks! :)
<gchristensen>
I should publish that somewhere, huh? :)
<gchristensen>
omg lol I forgot to put up a page on https://nix.ci
<ekleog>
The 7-day limit? I guess if the link to “full log” showed “The logs have expired in order to save space to new logs. Sorry!”, it would avoid questions :) Opening an issue to ofborg-viewer right now :)
<gchristensen>
well it is challenging because the viewer has no way of knowing if it was deleted or not
<gchristensen>
it just ... isn't there, know what I mean?
<samueldr>
gchristensen: when you delete, you could leave an IOU :)
<gchristensen>
but samueldr and I can sort something out
<gchristensen>
hah
<samueldr>
it's halfway the right location though, ekleog :)
<gchristensen>
so there are a few options ...
<gchristensen>
1) gzip logs so I can store more, longer
<ekleog>
well, I'll leave it to you two then, looks like there's maybe not even a need to actually open an issue :)
<gchristensen>
2) push logs out to S3 or whatever, but this is a bit costly
<gchristensen>
nah, an issue is definitely right ... I can't solve this tonight :)
<MichaelRaskin>
gchristensen: by the way, you are very welcome to comment if you think some details of nixpkgs/tests would make them more convenient to eventually use by ofBorg
<gchristensen>
oh right
<gchristensen>
ekleog: also samueldr is well experienced at converting my IRC-brainstorms in to issue comments ... something I definitely appreciate...
<gchristensen>
samueldr: what if I didn't delete the metadata but either there wouldn't be a log URL, or if there were it 404'd
<samueldr>
as long as it can be determined that not having a log is from a garbage collection vs. something wrong vs. actually no logs (I think)
<gchristensen>
that would be hard to tell :)
<ekleog>
would just replacing the logs by "***DELETED LOGS***" during GC somehow be easily possible?
<ekleog>
(that's a bit of a hack, though)
<gchristensen>
strictly speaking, ideally, they'd just get relocated somewhere else for long term storage
<MichaelRaskin>
And to save inodes, it is a hardlink to a single file with that line
<ekleog>
I'd say having something that works now sometime trumps having the ideal result, so maybe this hack and then when a long-term storage solution is found move the logs to the long-term storage?
<ekleog>
(that said there's no real emergency for this kind of issue, so maybe it's better to just leave it waiting for the long-term storage solution)
<gchristensen>
sometimes the hacks take longer than the long term solution
<gchristensen>
anyway, supper. back later.
<ekleog>
hmm, was thinking the deletion process could be `echo "***DELETED LOGS***" > logfile` instead of the likely-current `rm logfile`, but I just can't find where this rotation code is implemented, so not sure at all :/
<jtojnar>
I merged new version of wayland-protocols
<shlevy>
jtojnar: Looking
<shlevy>
jtojnar: All evals or all but latest?
<jtojnar>
all evals
<jtojnar>
thanks shlevy
<shlevy>
Done
thefloweringash has joined #nixos-dev
<ekleog>
Hmm, anyone familiar with how gcc7 is built? In the deriver of gcc7.cc I can't find what compiler is used to build it :/ (basically, looking into https://hydra.nixos.org/build/71018796 , and the spidermonkey-38 build failure looks similar to http://readlist.com/lists/gcc.gnu.org/gcc-help/7/37522.html to me, ie. gcc7 and the associated glibc must be built by gcc7 in order to link correctly)
<ekleog>
(can be reproduced only for spidermonkey-38.i686-linux, for my x86_64 system)
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
<niksnut>
gchristensen: Mar 14 16:15:31 chef hydra-queue-runner[26245]: possibly transient failure building ‘/nix/store/39hqp80qy6viz3g1w5xs29d9a08kgbbl-python2.7-BlinkStick-1.1.8.drv’ on ‘root@packet-t2a-1’: cannot connect to ‘root@packet-t2a-1’: Permission denied (publickey,keyboard-interactive).
<niksnut>
did the host key change?
<gchristensen>
should not have
<gchristensen>
one sec, very interesting logs
<gchristensen>
"Mar 14 15:15:30 builder-2A-1 sshd[2714]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]"
<shlevy>
:o
<shlevy>
Good ;)
<niksnut>
bad
<shlevy>
Yeah
<niksnut>
it seems that with every major NixOS upgrade, ssh insists on locking users out of machines
<shlevy>
Is that an 18.03 default?
<gchristensen>
should be warning more, sooner
<gchristensen>
but also should probably upgrade that key
<clever>
gchristensen: have you seen a nix-build command doing fun things like this before?
<gchristensen>
haha nope
<clever>
the NIX_REMOTE part emulates a chroot during the build, NIX_(CONF|LOG|STORE) change where (within the chroot) the build products go, and the .override teaches the nix it builds about those paths
<gchristensen>
incredible
<clever>
so you can then move the whole nix directory into $HOME on another machine, assuming $HOME is identical, and it should work
<clever>
i also suspect that this can be ran inside a nix sandbox
<clever>
ive seen signs that nix itself does this when testing itself
<LnL>
clever: :D
<fpletz>
yeah, finally, the 18.03 tested job finished and all packages from that evaluation has been built
<fpletz>
hopefully we get the nixos-18.03 channels soon :)
<LnL>
I don't think so, but might be misremembering
<gchristensen>
why wouldn't it?
<LnL>
thought it was only for armv*
<Sonarpulse>
peti: no
<Sonarpulse>
Dezgeg: changed that :D
<Sonarpulse>
there is a notion of the whole arm family
<gchristensen>
but aarch64 sort of implies armv8?
<Sonarpulse>
but isArm is arm 32 bit
<gchristensen>
only because it is currently defined that way, not because it is true
<Sonarpulse>
sure
<Sonarpulse>
talk to Dezgeg I'm not deciding policy just implementing shit :P
<gchristensen>
hah
<gchristensen>
:)
<MichaelRaskin>
I guess a proper fix would be to rename isArm → isArm32 treewide, and maybe add isArm and isArm64
<Sonarpulse>
MichaelRaskin: that's what I had originally! :D
<Sonarpulse>
or at least isArm and isArm64
<MichaelRaskin>
Well, if isArm doesn't include isArm64, it should better be renamed…
orivej has joined #nixos-dev
<gchristensen>
anyone around who likes formal methods
<MichaelRaskin>
Depends on which ones.
<manveru>
Profpatsch: yeah, we run `yarn` during the build phase, which needs the yarn.lock
<manveru>
usually the yarn.nix doesn't need to be committed, since we get the deps from the yarn.lock anyway, but due to the restrictions in hydra and ofborg that won't eval due to the additional eval step
<Sonarpulse>
gchristensen: sure i like formal methods
<Profpatsch>
manveru: Ah, I see.
<Profpatsch>
Since I don’t run yarn in the build, I don’t need that file … hrm.
<manveru>
so for normal development, i use our yarn2nix all the time, since it makes working with others seamless, they don't need to generate some .nix file for the builds to work
<Profpatsch>
One possibility is reconstructing the yarn.lock instead.
<Profpatsch>
Shouldn’t be too hard.
<manveru>
yeah... the yarn.nix could also be compressed like yours
<manveru>
i really like that style
<manveru>
i finished my first version of a kind of depnix for go today, where i read the Gopkg.toml and fetch all the go dependencies via nix :)
<Profpatsch>
Problem with go is that there’s about five different package “managers”
<manveru>
yeah, but that's the one we use at work
<manveru>
fetchGit makes it super easy to implement, but also super slow to initially run :|
<manveru>
takes like half an hour for something you could clone in 10 seconds
<manveru>
takes me back to the old dockertools performance...
<manveru>
i should benchmark it for fun :)
<manveru>
anyway, i think this approach should work also with vgo
<manveru>
which will be the official go package manager
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
jarth has quit [Ping timeout: 260 seconds]
<Dezgeg>
well, 'aarch64' is the official / gnu naming in the triplets, with no sight of 'arm' - and there is even less commonality between aarch64 and arm than i686 and x86_64
viric has quit [Quit: mirar]
<dtz>
can someone restart the 17.09 busybox job ( https://hydra.nixos.org/build/71020865/nixlog/1 )--it needs to run on a non-broken builder, and includes the fix to make broken builders on 17.09 un-broken lol :(
<dtz>
nvm I'll see if I can fix...
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
* shlevy
whistles innocently
infinisil has joined #nixos-dev
<shlevy>
Sonarpulse: Do you think {build,run,emit}Platform, considered as inputs, belong in the same namespace as options like "enableGold" and "x11Support"?
<dtz>
fixed, patchShebangs FTW lol
<shlevy>
\o/
<dtz>
if someone wants to kick off an eval that'd be swell since it's on an 8-hour timer lol. But not a priority I don't think :).
<shlevy>
dtz: If you make an account I think I can give you that power
<gchristensen>
Everyone with an account can trigger evals. No special prics
<gchristensen>
Privs required
pie_ has quit [Ping timeout: 264 seconds]
<shlevy>
Ah cool
<shlevy>
So I can definitely give you that pwoer :P
<gchristensen>
:D couldn't hurt to have restart privs
ma27 has quit [Ping timeout: 276 seconds]
<Sonarpulse>
shlevy: i do that already, and put them on stdenvn
<Sonarpulse>
*in stdenv, I suppose
<Sonarpulse>
dtz: PR?
<dtz>
oh, no PR lol. :(
<Sonarpulse>
haha ok
<Sonarpulse>
just pushed to master?
<Sonarpulse>
or wip?
<Sonarpulse>
*would be pushed to staging I suppose
<dtz>
wait, which PR are you looking for? If you mean the busybox patchShebangs, yeah I pushed the change directly since it seemed pretty straightforward and can't really make things work than the current state which is failed build (on 17.09 anyway). Was that too bold? Apologies if so!
<dtz>
yay nixos-17.09-small is going, already made it past that point \o/