<Profpatsch>
gchristensen: Haha, you just evaled an open PR I had completely forgotten about.
<Profpatsch>
It’s so bad I don’t even know what I used the package for.
<Profpatsch>
And what prompted me to update it in the first place. oO
<gchristensen>
:) I'm considering having OfBorg periodically eval every open PR.
<gchristensen>
Anyway, goodnight!
<Profpatsch>
gchristensen: This one had merge conflicts though.
<Profpatsch>
So maybe check on those first?
<Profpatsch>
Oh, this was a time when mention-bot was still at it.
<gchristensen>
Well yeah so the idea there is to auto find PRs that don't matter
<Profpatsch>
We really need ofborg to replace mention bot.
<gchristensen>
Don't merge×
<gchristensen>
There is an issue for that
<gchristensen>
Anyway. Good night for real this time:)
<Profpatsch>
I commented on it a few hours ago yes. :)
<Profpatsch>
gn8!
<Profpatsch>
gchristensen: Haha, I’m waiting for @grahamcofborg breaking Gist because it has too many gists
<Profpatsch>
The pro-point of pushing stuff at this hour is that I’ve got ofborg’s evaluator nearly all to myself. :)
<thoughtpolice>
I have a package with multiple outputs, including a bin, but setting outputs to include "bin" gives me an error: `builder for '/nix/store/xzhw0zl1mp7xr6vn46vkxyd4rwvj7k4h-comdb2-7.0.0pre-1d9c87a50.drv' failed to produce output path '/nix/store/my5iyqbb226glybgwf93s8l7badi8gv2-comdb2-7.0.0pre-1d9c87a50-bin'`
<thoughtpolice>
Shouldn't the default multi-output fixup just move $out/bin to the $outputBin dir for me? It does this for lib/ and include/ at least
<thoughtpolice>
Oh, no, apparently it doesn't, I think.
<Profpatsch>
thoughtpolice: Afaik only for "doc" and "man"
<Profpatsch>
Maybe also for "dev"
<Profpatsch>
Don’t forget that you always need "out" to exist.
<Profpatsch>
Which is an awkward restriction in nixpkgs
<thoughtpolice>
I already have that one covered, but yes, in the case where you don't call moveToOutput, it assumes the default configureFlags it adds etc (--bindir) will work it out
<thoughtpolice>
From reading multiple-outputs.sh, anyway
<thoughtpolice>
Ugggggggggh
<thoughtpolice>
`Removing empty /nix/store/nsm4vx58gs7igjcwr6qcvjyx2byy5jpw-comdb2-7.0.0pre-1d9c87a50/ and (possibly) its parents`
<thoughtpolice>
My outputs exactly captures all derivations and there are no leftovers in $out. Ugh
<thoughtpolice>
Profpatsch: That is an annoying restriction...
<thoughtpolice>
a postFixup = ''mkdir $out''; seems to have done the trick :/
<Profpatsch>
yeah
obadz has quit [Ping timeout: 260 seconds]
obadz has joined #nixos-dev
ma27 has joined #nixos-dev
ma27 has quit [Ping timeout: 240 seconds]
pie_ has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 264 seconds]
MichaelRaskin has quit [Quit: MichaelRaskin]
pie_ has joined #nixos-dev
pie_ has quit [Ping timeout: 240 seconds]
<Mic92>
how do I abort evaluations in hydra?
<Mic92>
ikwildrpepper: can you stop the evaluation started three days before? https://hydra.nixos.org/jobset/nixpkgs/cpan-update It this kind of meaning-less because it was build on top of a broken staging branch. there was some misunderstanding with vcuncat.
__Sander__ has joined #nixos-dev
<Mic92>
I am also not so sure, if I was properly be able to restart evaluation
<Mic92>
I think it did, but I wonder why it rebuilds so many things, if it is based on master.
aminechi1haoui is now known as help
help is now known as Guest58784
Guest58784 is now known as aminechikhaoui
Synthetica has joined #nixos-dev
ashgillman has joined #nixos-dev
thefloweringash has quit [Remote host closed the connection]
thefloweringash has quit [Remote host closed the connection]
thefloweringash has joined #nixos-dev
thefloweringash has quit [Ping timeout: 276 seconds]
ashgillman has quit [Ping timeout: 256 seconds]
<shlevy>
What is the cpan-update branch and why is it building full release.nix?
<gchristensen>
it is updating all of the cpan packages and I think requires very careful testing AFAIK
<gchristensen>
cc jtojnar I think
<shlevy>
Ah
<shlevy>
I didn't realize cpan was so fundamental to our package set
<gchristensen>
not sure, I think it is just a bit scary because of how perly perl is
<shlevy>
:D
<shlevy>
Fair
<jtojnar>
gchristensen: not me
<clever>
gchristensen: did you ever get a chance to see the PR i linked?
<gchristensen>
I haven't :( been quite swamped
<shlevy>
I'm wondering if we need to move to a general model of "nothing goes into staging until release-small has passed, then you get in line for merge to staging, one thing is merged into staging at a time then fixed until mergable into master"
<gchristensen>
shlevy: sounsd like a borsian model
<shlevy>
Ah, nice, prior art :D
<shlevy>
That means it must be a good idea
<clever>
oh, github has some magic refs, like pull/${PR_NUMBER}/head that refer to the branch of a PR
<clever>
is there another, that refers to its merged state?
<gchristensen>
yeah /merge I think
<shlevy>
clever: AFAIK most tools that operate over a merged PR do themerge themselves
Lisanna has joined #nixos-dev
<shlevy>
oh nice
<shlevy>
Should fix Jenkins github integration then :D
<clever>
shlevy: but also, appveyor and travis, only build that merged result once, when the pr is updated
<clever>
so if the target branch is updated, it wont re-test the PR
<shlevy>
Yeah. That's understandable but not technically correct
<clever>
but declarative jobs in hydra can check the /merge every minute, and re-build them when master changes
<shlevy>
This was probably not a response to my comment but really that workflow is begging for a borsian model too :)
<shlevy>
"I'm ready to merge" puts you in the queue
<shlevy>
Then you only re-merge when you're the next bit in line anyway
<gchristensen>
a benefit of moving merges in to a ofborg command is it can also perform a final merge-and-eval check
<gchristensen>
to prevent stale PRs which do merge from introducing eval issues
<shlevy>
Yeah
<shlevy>
Though without ofborg getting a global lock on merges there's still a potential race ;)
<shlevy>
(I wouldn't be opposed to ofborg having a global lock on merges eventually)
<clever>
gchristensen: replied to all 3 comments
thefloweringash has joined #nixos-dev
<clever>
gchristensen: once my load avg is no longer at 15, i can begin applying that change
<gchristensen>
:P
<clever>
the latest gpu drivers in nixos-unstable have been ... unstable!
<clever>
the whole machine locked up solid
<gchristensen>
:o
<clever>
and chrome is now busy restoring all the state
<clever>
its been chewing up 100% cpu for nearly an hour now
<clever>
loadavg is down to 10, on an 8 core machine
<clever>
8!
<clever>
and its almost usable!
Sonarpulse has joined #nixos-dev
Sonarpulse has quit [Remote host closed the connection]
Sonarpulse has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 276 seconds]
<peti>
hydra.nixos.org is boldly building nothing. :-)
<Synthetica>
Off with its head!
__Sander__ has quit [Quit: Konversation terminated!]
<dtz>
it's got like 7 to spare or something right
<gchristensen>
ah it is building now
orivej has quit [Ping timeout: 260 seconds]
<makefu>
dtz: and with every one you cut off the builds will stall for another N*2 minutes
<dtz>
lol!
<shlevy>
dtz: Not sure if you saw my question yesterday about binutils 2.30 and llvm, but I was pointed to a binutils bug about it: https://sourceware.org/bugzilla/show_bug.cgi?id=22868. Trying reverting that commit and seeing what happens.
<Dezgeg>
I don't know why bug new versions of binutils always seem buggy
<gchristensen>
I've noticed that
<shlevy>
Probably because distros notice they're always buggy so no one tests them :D
<shlevy>
Nah, no idea why
<dtz>
yeah :/
<dtz>
we skipped .29 entirely lol
<shlevy>
:D
<shlevy>
I wouldn't be working on this if 2.30 weren't the first supporting RISC-V
<shlevy>
glibc 2.27 causes a segfault in the ATLAS tests that no one else seems to have hit yet... But who rebuilds ATLAS, anyway
<gchristensen>
lol ...
<dtz>
I do :(. Takes foreeeverrr
<shlevy>
Tracing that down is going to be such a pain... such a long build
pie_ has quit [Ping timeout: 245 seconds]
ma27 has quit [Ping timeout: 240 seconds]
ma27 has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
jtojnar has joined #nixos-dev
LangeOortjes is now known as qqlq
<Sonarpulse>
dtz: we should deduplicate the gcc derivations
<Sonarpulse>
now that odd one out 4.5 is gone
<dtz>
oh? yes please
<dtz>
also they're a giant mess, lol, so updating them all is .. .painful :3
<dtz>
maybe I'm just used to LLVM expressions' special brand of crazy ;)
<dtz>
although refactoring those would be nice too :)
jtojnar_ has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
jtojnar_ has quit [Ping timeout: 264 seconds]
<Sonarpulse>
dtz: the gcc ones should be easy to deduplicate as is
<Sonarpulse>
then worry about making saner after
<Sonarpulse>
yeah the llvm ones need help too
<Sonarpulse>
especially if cross is to work
<Sonarpulse>
also I borked release-cross.nix last night oops
MichaelRaskin has joined #nixos-dev
jtojnar_ has joined #nixos-dev
<dtz>
sokay :)
<dtz>
did we give up on cross targeting i686? lol O:)
jtojnar has quit [Ping timeout: 240 seconds]
jtojnar_ is now known as jtojnar
<Sonarpulse>
dtz: hehe we gave up on cross targeting just about everything with this change
<Sonarpulse>
not sure what happened
<dtz>
D:
<dtz>
haha
<dtz>
apparently cross-i686 and native i686 "stdenv.cc.cc" aren't in cache? haven't cached down hydra builds....
<dtz>
i mean I know only limited for32bit but QQ
<dtz>
while we're refactoring gcc can we let GCC override with "-fno-stack-protector" as appropriate? :(
<dtz>
nm I think I'll workaround the stack protector thing, although it is probably worth considering.... gcc tries to intentionally not build libgcc with stack-protector, so...
<dtz>
IIRC there's an issue somewhere that makes hardening flags come before so they can be disabled?
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
jtojnar_ is now known as jtojnar
<Sonarpulse>
dtz: there is a way to disable drv-wide
<thoughtpolice>
Here's a weird question I've had on my mind: would it ever be possible to do Nix builds with something like a container image as input? That is, I want to package some extremely hostile proprietary software inside say, an Ubuntu 16.04 container and just expose enough to run the tools, and use that in a Nix build.
<dtz>
yeah, and we do it in glibc and musl (and other libc's) for same reasons--these sort of things need to disable it sometimes
<thoughtpolice>
(The reason I ask this is because this would allow using NixOS, provided something like this could happen.)
<gchristensen>
thoughtpolice: some nix builds run entire VMs, can't see why you couldn't run a container
<gchristensen>
if not directly, a container in the VM :)
<thoughtpolice>
Actually a VM would work fine too. :)
<MichaelRaskin>
I would actually bet on having the Ubuntu image unpacked, and using unshare inside the build to pretend to be root.
<thoughtpolice>
Right now we have Ubuntu 16.04 on Nix, but due to the way this software works (EDA tooling) it really hates if you try anything other than whatever they support. This makes things like sandboxing difficult as hell.
<thoughtpolice>
Not every Nix expression (especially kernel related ones) are actually pure, they rely on the sandbox to purify them, so you have a tradeoff of all sorts of things working or not working, etc
<thoughtpolice>
It sucks.
<MichaelRaskin>
VM is reasonably easy, proper container with default init might be hard, unprivileged containers (runC?) should be feasible
<thoughtpolice>
MichaelRaskin: Right, various restrictions around container privileges was the thing I figured might hold it up.
<thoughtpolice>
But a VM would be just as good, provided it could boot fast enough.
<thoughtpolice>
I mean, maybe that doesn't matter. The tools are slow as hell, anyway.
<MichaelRaskin>
thoughtpolice: there is also relaxed sandboxing, when _specific_ builds get more access to outside world.
<MichaelRaskin>
There is some VM overhead…
<thoughtpolice>
MichaelRaskin: Yeah... I've thought about that too, but because we often propagate the tools through other expressions, then like half of our target expressions (or more) would need to have noChroot passed through
<thoughtpolice>
Which would work too. Ideally just piling all that crap somewhere that it's happy would be better.
orivej has joined #nixos-dev
<MichaelRaskin>
Just tested: unshare does work inside a build
<MichaelRaskin>
So having an unpacked image of Ubuntu and using unshare or something similar to chroot into it should work
ma27 has quit [Ping timeout: 256 seconds]
<thoughtpolice>
MichaelRaskin: Thanks! That's good to know.
gchristensen has quit [Quit: WeeChat 1.9.1]
gchristensen has joined #nixos-dev
<Sonarpulse>
thoughtpolice: see clever's stuff
<Sonarpulse>
on using qemu
<thoughtpolice>
I should just have my IRC client prefix every message in this channel with 'clever: '
<Dezgeg>
I don't see what's unconsistent with 'arm' and 'aarch64'
<gchristensen>
I think the confusing thing is that aarch64 is an ARM arch
<Sonarpulse>
ARM = everything. Armv8 -> latest version; Aarch{32,64} => modes of armv8; A64, A32, T32 -> instruction sets
<Dezgeg>
fedora has 'aarch64' and 'armv7l'
<Sonarpulse>
yeah that's fineish
<Sonarpulse>
the basic issue is, just as Intel did 10 years before, adding more modes and more indirection is going to invalidate old naming scheme
<Sonarpulse>
so to make things consistent need to contort ones head
<Sonarpulse>
armv7 as a one-mode ISA with thumb and non-thumb instruction sets
<Dezgeg>
the consistent thing is to call all 32-bit ones 'ARM' and 64-bit ones 'AArch64', no
<Dezgeg>
?
<Sonarpulse>
the ISA vs mode distrinction doesn't add any useful degrees of freedom
<Sonarpulse>
but does make consistent with armv8
<Dezgeg>
but instruction set _is_ what matters to most software
<Sonarpulse>
right
<Dezgeg>
most software don't care whether it's armv6/armv7/armv8 or not, but rather 'is it 32-bit or not'
<Sonarpulse>
armv7 and aarch64 is fine
<Sonarpulse>
it's `isArm` being false for aarch64 that's confusing
<Sonarpulse>
it makes sense in that "armv7" starts with "arm"
<Sonarpulse>
but doesn't otherwise
<shlevy>
I bumped on that, FWIW
<Dezgeg>
how often do you ever need the combination 'armv* || aarch64' except by coincidence?
<shlevy>
that isArm was false for aarch64
<Sonarpulse>
their retronym "Aarch32" at least has "32" in the name
<Sonarpulse>
Dezgeg: the coicidence of "my stuff happens to be ported to a lot of phone arches" is not uncommon
<shlevy>
I think if you ask most people who know what aarch64 is "is it Arm" they'd say yes
<shlevy>
Or they would if they didn't think you were asking a trick question :P
<Dezgeg>
so if mips happened to be a phone architecture as well, would that include mips then? :P
<Sonarpulse>
eventually ARM will probably add some more aarch64 instructions, if they haven't already
<Sonarpulse>
armv9 or whatever
<MichaelRaskin>
Has Aarch64 roughly inherited the set of gotchas of ARM memory model?
<Dezgeg>
IIRC it is stricter, but I don't see that as relevant
<Sonarpulse>
unless they fuck up their naming scheme again (heh probably will), there will be armv8-aarch64 and armv9-aarch64
<Dezgeg>
they are almost certainly having internal competitions on who makes up the most confusing marketing name
<Dezgeg>
given that you have ARM11 cpus and ARMv7 cpus for instance
<Sonarpulse>
yeah it's real fucked up
<Sonarpulse>
just like that linus rant goes
<Sonarpulse>
but I like when there's a way to be creative and make it a little less bad
<shlevy>
Awww I was just about ot make a dumb joke but I realized the RISC-V extension naming scheme doesn't actually allow a possible future RV64LGBT ISA, since L and B are included in G :(
<Sonarpulse>
(like maybe we should say x86_32 instead of i686 because there is newer 32-bit x86 instructinos)
<Dezgeg>
I don't like anything that has combined arm & aarch64 instruction sets because it is almost never a correct answer except by coincidence
<Dezgeg>
if you grep e.g. current usages in nixpkgs
<Sonarpulse>
Dezgeg: we could just get rid of isArm then
<Sonarpulse>
have isAarch32 or isAarch64
<shlevy>
+1
<Dezgeg>
next to nobody else calls it 'aarch32'
<shlevy>
or isArm32
<Sonarpulse>
they can both be "families" with the "aarch64" family containing just aarch64 as you made
<gchristensen>
IMO we should stick with what we have
<ekleog>
(and then we start the debate x86_64 vs amd64)
<gchristensen>
ARM's scheme is confusing but we shouldn't add to it by deviating
<Dezgeg>
:)
<Sonarpulse>
gchristensen: Aarch32 is official
pie_ has joined #nixos-dev
<MichaelRaskin>
Just rename i686 to x86_32
<gchristensen>
now we're cooking
<Sonarpulse>
Dezgeg: official + unambiguous > unpopular, IMO
<shlevy>
gchristensen: But should isArm be true for aarch64 or false?
<gchristensen>
can I phone a friend?
<Sonarpulse>
gchristensen: easy way to avoid conflict is no "isArm" hahaha
<shlevy>
Currently it's false, which makes sense because you rarely want something that matches both 32 bit and 64 bit, but is confusing because pretty much everyone would say "yeah, of course it's ARM"
<Sonarpulse>
if there's no good reason to conflate them, let's be up front that we won't offer that short-hand, not stealthy about it
<shlevy>
+1
<shlevy>
Especially if aarch32 is upstream nomenclature
<Dezgeg>
it is for marketing persons but not for essentially nobody else
<Sonarpulse>
I'd really like to revert that (again haha)
<Sonarpulse>
find some incantation that works correctly
<shlevy>
Oh man I just learned that "el" stands for "EABI Little", not a cutesy way of saying "little endian"
<Dezgeg>
yeah, I suppose it requires some deep digging of gcc/binutils configure.ac or something
<Sonarpulse>
shlevy: :D
<Sonarpulse>
thank you for that
<Sonarpulse>
(but then we also do eabi at the end ughhhhhh)
<Dezgeg>
where does it say it stands for "EABI little" btw?
<Sonarpulse>
wait
<shlevy>
wikipedia
<Sonarpulse>
shlevy: what about mipsel?
<Sonarpulse>
isn't eabi just an arm thing?
<shlevy>
Hmm
<Dezgeg>
where does it refer? :P
<shlevy>
Maybe wikipedia is lying
<Dezgeg>
yes EABI is an ARM thing
<shlevy>
i was looking it up to validate a grouse about being cutesy over being transparent
<shlevy>
So I guess I'll do that instead :P
<sorear>
shlevy: somebody is lying, mipsel is a thing
<shlevy>
Yeah
<Sonarpulse>
now that we force the GNU ld "emulation", that might help
<Dezgeg>
maybe recompiling the bootstrap tools would help as well, who knows
<Sonarpulse>
oh right hmmmm
<Sonarpulse>
well, I think I'm going to make a Aarch32 PR for further discussion in a public way :)
<shlevy>
Sonarpulse: I was musing the other day about what to call the "build" system of the boostrap tools in the world where bootstrapping is cross-compilation. I ended up with build = "primordial ooze"; run = "bootstrap"; emit = "bootstrap";