gchristensen 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 | 18.03 release managers: fpletz and vcunat | https://logs.nix.samueldr.com/nixos-dev
goibhniu has quit [Ping timeout: 240 seconds]
goibhniu has joined #nixos-dev
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 240 seconds]
lassulus_ is now known as lassulus
matthewbauer has quit [Read error: Connection reset by peer]
matthewbauer has joined #nixos-dev
ixxie has quit [Quit: Lost terminal]
matthewbauer has quit [Ping timeout: 265 seconds]
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
s33se has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
Jackneilll has joined #nixos-dev
Jackneillll has quit [Ping timeout: 245 seconds]
FRidh has joined #nixos-dev
<pie_> *is
s33se has quit [Quit: s33se]
rsa has quit [Read error: Connection reset by peer]
rsa has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
xeji has joined #nixos-dev
jtojnar has joined #nixos-dev
vcunat has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
Synthetica has joined #nixos-dev
<vcunat> Someone cancelled the staging builds?
<MichaelRaskin> After a merge of a security mass-rebuild into staging, if I remember correctly
<vcunat> Yes, I cancelled those before the merge.
<vcunat> But now most those *after* the merge got cancelled as well.
<vcunat> They appear as "Cancelled by user" but I can't see how one would easily do that with 32k jobs and leave a few thousand uncancelled...
<vcunat> Oh, I can see a probable way.
<MichaelRaskin> orivej: LnL:
<vcunat> Cancelling next-to-last eval would do something like that, due to job overlap.
<LnL> I canceled some stuff yesterday, maybe I forgot to restart everything in the last eval
<vcunat> This must've been within the last hour, perhaps even less.
<vcunat> Anyway, Hydra still has quite a lot of work to do.
<vcunat> (on staging)
<vcunat> So I'll restart aborted jobs on latest staging evaluation when it would be close to idling on some platform.
<LnL> hmm, what about trunk there are also a whole bunch of jobs aborted there
<vcunat> That was me.
<vcunat> So that it doesn't slow down the security updates.
<vcunat> Such mass rebuilds shouldn't be merged to master anyway, so I didn't feel like giving those an advantage.
<LnL> it's still part of the last staging merge + fixes of broken stuff
<vcunat> I hoped to clear both at once fast enough. (including the security fix)
<LnL> so we're going to merge 1460772 into master asap
<vcunat> Yes, that's my intention.
<vcunat> Sooner than all rebuilds finish, so that e.g. unstable-small doesn't have to wait for long.
<LnL> yeah, that's fine
<vcunat> Maybe half of the rebuilds is just because of a bison update - which doesn't seem to hurry - but I didn't take time to dissect such details.
<vcunat> I'll rather invest it into the new boxes I want to add to Hydra.
<LnL> what do you think about trying out part of the staging workflow with a stabilisation branch?
<LnL> that makes the intention more clear
<vcunat> this one? 52fdec3c1de
<vcunat> oops
<LnL> yeah
<vcunat> well, I tried to write in there what I think
<LnL> this was my attempt last week, because staging was in a pretty bad place https://github.com/NixOS/nixpkgs/pull/41138
<LnL> even without a hydra jobset it provides a place for fixes/discussion before a merge
xeji has quit [Quit: WeeChat 2.0]
<MichaelRaskin> Oh nice, samba build failure on master
<MichaelRaskin> Hm, complains about sybtax error at /nix/store/r14k2qhd660hczs14yq5pi5zimrmk5ym-glibc-2.27-dev/include/bits/types.h +30
<MichaelRaskin> Which is just typedef unsigned char __u_char;
FRidh has joined #nixos-dev
<vcunat> Right, having a discussion thread per staging iteration is a nice idea.
<FRidh> vcunat: I've opened a PR at your rfc PR. What do you think? It's going to need some more iterations but it is a start
<vcunat> FRidh: thanks for notification. I'm not sure why, but I wasn't getting notifications from that repo.
<MichaelRaskin> Of course, reading the IDL file doesn't make anything clearer…
<vcunat> hmm, I've never worked with IDL
<vcunat> You haven't tried bisecting it on nixpkgs yet?
<MichaelRaskin> Of the painful options, I preferred the one that uses only sane tools — strace-ing the build to see what it tries to feed to gcc when it fails
<vcunat> MichaelRaskin: BTW, to allow another language in libreoffice it's the right way to just extend the `langs` parameter of the derivation, right? (for everyone's builds)
<vcunat> I've seen it done for one or two languages over the past year
<MichaelRaskin> I think so, yes
<vcunat> OK, I'll test it locally (CZ) and then push directly.
<vcunat> Also into 18.03, perhaps.
<MichaelRaskin> Yeah, my maintenance of LO seems to be mostly about me being the person who is ready to throw build cycles at LO from time to time
<MichaelRaskin> I wonder what I should do about the weird outcome of staging merge for LO
<MichaelRaskin> Right now still = fresh
<vcunat> :-) that's some kind of merge conflict?
<MichaelRaskin> To bring the situation in line with upstream, we should side-grade still (switch back to older branch, and switch to the new release there)
<MichaelRaskin> I have no idea how the current layout has happenned, and I am not sure I want to know because then I will need to suppress the urge to wonder what the hell was <somebody specific> thinking
<vcunat> I can't say I know libreoffice. I use it very rarely. Now I just need to have it on a "family computer".
<MichaelRaskin> It's just a rare case when I want to do a more-downgrade-than-update for reasons other than «doesn't work»
vcunat has quit [Read error: Connection reset by peer]
vcunat has joined #nixos-dev
vcunat has quit [Read error: Connection reset by peer]
vcunat has joined #nixos-dev
<vcunat> bisected to 480434f7: libbsd: replace with nbcompat
<MichaelRaskin> OK, that might make some amount of sense
<MichaelRaskin> Not too much, though
<MichaelRaskin> A PID coincidence: 2584 seems to be a parent to 24584
gebner has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
<MichaelRaskin> I wonder what to use for navigating in a 6 GiB file
<gchristensen> I think vim does nicely?
<MichaelRaskin> Nope
<MichaelRaskin> Maybe I was missing some of the required cut-down options, though
<vcunat> Maybe syntax highlighting and such stuff get into the way :-)
<MichaelRaskin> That part is obvious
<vcunat> maybe vbindiff
<MichaelRaskin> The question is what I want to feed it to avoid
<vcunat> (from stuff I've used, but I haven't really tried huge files)
<MichaelRaskin> The file is actually text
<vcunat> 6 GiB text file :-)
<MichaelRaskin> And you know enough to guess what it is
<vcunat> what about `less`?
<vcunat> (worked fine for my huge logs)
<MichaelRaskin> Its search is _way_ slower than grep
<vcunat> really? That's weird.
<vcunat> I'd expect it to just use mmap or something.
<MichaelRaskin> I think at some point it starts filling the line number table
<MichaelRaskin> Which is not exactly what I want
<MichaelRaskin> Of course, cat -n does that in 12s and less takes longer…
orivej has joined #nixos-dev
<MichaelRaskin> I basically want «show 100KiBs around this point in less» and «grep from this point»
<MichaelRaskin> But I don't want to script it myself
<MichaelRaskin> Yet…
<vcunat> yeah, better improve performance of `less`
<LnL> do you know lnav? might be useful for what you're doing
<MichaelRaskin> (running @ @ lnav --help)
<MichaelRaskin> Well, it is quite a bit behind grep in search performance…
<MichaelRaskin> Hm, but if it caches all the searches, maybe it is not _that_ bad…
<LnL> yeah, it won't be better if all you want is grep of an entire file but you can select time ranges, etc.
<MichaelRaskin> Well, I don't want time ranges…
<MichaelRaskin> It is an strace of the failing samba build
<LnL> oh, not an actual logfile
<MichaelRaskin> Well, it is a logfile in a sense
<LnL> well might still be helpful
<MichaelRaskin> search caching does help, thanks
<MichaelRaskin> And it is slower than grep but still faster than less…
<orivej> MichaelRaskin: you could use https://github.com/orivej/fptrace
<orivej> (BTW I don't know who cancelled builds)
<MichaelRaskin> orivej: I think you asked LnL to do it
<MichaelRaskin> LnL: what I miss is backwards search… but I guess it is fast enough to just cache the interesting searches
<MichaelRaskin> A pity that lnav doesn't show progress in percents
orivej has quit [Ping timeout: 260 seconds]
<MichaelRaskin> Argh
<MichaelRaskin> So, it doesn't actually cache more than one search?
<MichaelRaskin> OK, lnav is not powerful enough for reading strace logs
<LnL> not sure that stuff is configurable, I've not used it myself
<MichaelRaskin> If it had backwards search, it could be enough
<MichaelRaskin> orivej: I guess I have to try fptrace next…
<MichaelRaskin> orivej: can I fptrace a nix-store realization?
<clever> MichaelRaskin: i have strace'd nix-build and even nix-daemon before
<MichaelRaskin> clever: strace yes
<clever> if fptrace is using the ptrace() api, then it shouldnt be any different
<MichaelRaskin> But it produces a 5.8 GiB log file which I cannot navigate because I know no tools that can do search with grep-equivalent performance
<MichaelRaskin> (and allow backwards search from a specific point)
<clever> MichaelRaskin: oh, thats where -ff comes in handy
<clever> MichaelRaskin: strace -o logfiles -ff
<clever> this will write to logfiles.<pid>
<MichaelRaskin> I thought of it
<clever> that 5gig should now be spread over many files
<MichaelRaskin> But theoretically I want to see the interleaving
<clever> use -e to filter what syscalls it logs?
<clever> turn on timestamps with -ff, and re-weave the section of interest?
<MichaelRaskin> I know of it, but I am not sure which syscalls to filter (and rerunning multiple times is not attractive)
<MichaelRaskin> I don't have a fixed defined section of interest
<clever> i tend to use a blacklist when i dont know what i want to look at
<MichaelRaskin> Actually, grepping the single unified log into parts might be better idea than trying to re-weave
<clever> -e 'trace=!'gettimeofday,futex
<clever> yeah, you could use egrep to heavily filter it, and easily re-filter it without re-running the slow strace
<clever> and its getting late here, i should get to bed
<MichaelRaskin> Good night
Jackneilll has quit [Read error: Connection reset by peer]
<MichaelRaskin> Is samba even supported on non-Linux in Nixpkgs?
Jackneilll has joined #nixos-dev
<MichaelRaskin> … the answer is no, because acl
<MichaelRaskin> I guess then I can just resurrect freedesktop version and drop patches and use it for Samba…
<MichaelRaskin> Seems to pass the IDL stage that way, actually
<gchristensen> [root@packet-t2-4:~]# nix-shell -p 'python3.withPackages (p: [p.requests])'
<gchristensen> error: cloning builder process: Cannot allocate memory
Synthetica has quit [Quit: Connection closed for inactivity]
<gchristensen> niksnut: around?
LnL has quit [Ping timeout: 240 seconds]
<vcunat> open a ticket, I guess, if you don't find out soon
<gchristensen> packet-t2-4 going down for a reboot
xeji has joined #nixos-dev
goibhniu has quit [Remote host closed the connection]
<samueldr> hi, there's a quite bad issue with the current docs + some man pages, both on unstable and 18.03
<samueldr> (being a code owner pierron has been request as a reviewer)
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
averell has joined #nixos-dev
orivej has joined #nixos-dev
<vcunat> FRidh: the changes you pushed to staging today - do they hurry with the security fixes that are being rebuilt now?
matthewbauer has joined #nixos-dev
goibhniu has joined #nixos-dev
LnL has joined #nixos-dev
<FRidh> vcunat: I don't follow you. I pushed some older changes, which did cause a large rebuild (python2). I'm not aware of any further security fixes.
<vcunat> FRidh: OK
<vcunat> I didn't mean to imply _you_ pushed security fixes.
<vcunat> There's a security fix in master..staging - I know of f96c5effd6b0f, possibly some other one as well
<vcunat> so my conclusion for Hydra rebuilds is to prioritize what's being built now and don't cancel it in favor of including your python fixes.
<FRidh> Ah, now I get you. Indeed, these Python changes can be build any time.
<FRidh> No hurry.
<vcunat> :-)
matthewbauer has quit [Ping timeout: 240 seconds]
matthewbauer has joined #nixos-dev
shlevy has quit [Ping timeout: 256 seconds]
shlevy has joined #nixos-dev
LnL has quit [Ping timeout: 248 seconds]
pie__ has joined #nixos-dev
pie_ has quit [Ping timeout: 240 seconds]
FRidh has quit [Quit: Konversation terminated!]
vcunat has quit [Quit: Leaving.]
LnL has joined #nixos-dev
matthewbauer has quit [Ping timeout: 265 seconds]
xeji has quit [Quit: WeeChat 2.0]
<gchristensen> I'm doing another reboot of packet-t2-4
contrapumpkin has quit [Remote host closed the connection]
<gchristensen> sometimes, this thing takes so long to reboot, I destroyed it mid reboot because I thought I broke it
contrapumpkin has joined #nixos-dev