<gchristensen>
it needs to build GHC for some reason
<gchristensen>
oh nvm
mbrgm has quit [Ping timeout: 256 seconds]
mbrgm has joined #nixos-dev
Lisanna has quit [Remote host closed the connection]
Lisanna_ has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
Lisanna_ has quit [Remote host closed the connection]
Lisanna has joined #nixos-dev
Lisanna has quit [Quit: Lisanna]
<dtz>
hugs for all and ty all for everything great that is Nix and for being your wonderful selves <3
<dtz>
'night o/
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 248 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 276 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 260 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
jtojnar has joined #nixos-dev
pie_ has quit [Ping timeout: 240 seconds]
jtojnar has quit [Ping timeout: 264 seconds]
pie_ has joined #nixos-dev
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 276 seconds]
jtojnar has joined #nixos-dev
pie_ has quit [Ping timeout: 248 seconds]
jtojnar has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 255 seconds]
pie_ has joined #nixos-dev
ma27 has joined #nixos-dev
FRidh has joined #nixos-dev
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
pie_ has quit [Ping timeout: 255 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 255 seconds]
pie_ has joined #nixos-dev
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 256 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 256 seconds]
jtojnar has joined #nixos-dev
pie_ has quit [Ping timeout: 255 seconds]
jtojnar has quit [Ping timeout: 276 seconds]
orivej has quit [Ping timeout: 264 seconds]
__Sander__ has joined #nixos-dev
jtojnar has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
<Mic92>
I merged this innocent looking derivation https://github.com/NixOS/nixpkgs/pull/35074/files and now we have the following evaluation error: ‘flock-0.2.3’ has invalid meta attribute ‘overrideDerivation’
<Mic92>
where is this comming form?
<Mic92>
*from
<Mic92>
fixed
jtojnar has quit [Ping timeout: 240 seconds]
Lisanna has joined #nixos-dev
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 255 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 268 seconds]
pie_ has joined #nixos-dev
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 248 seconds]
<FRidh>
Mic92: callPackages instead of callPackage
<FRidh>
ah, you found it, good.
jtojnar has joined #nixos-dev
orivej has joined #nixos-dev
jtojnar has quit [Ping timeout: 264 seconds]
MichaelRaskin has quit [Quit: MichaelRaskin]
orivej has quit [Ping timeout: 256 seconds]
pie_ has quit [Ping timeout: 264 seconds]
pie_ has joined #nixos-dev
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 248 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 260 seconds]
FRidh has quit [Ping timeout: 276 seconds]
FRidh has joined #nixos-dev
jtojnar has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 256 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 256 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 256 seconds]
FRidh has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-dev
<gchristensen>
Miv
<gchristensen>
C
<gchristensen>
... mic92 did it pass evaluation before merging and fail after merging?
<dtz>
(looking at the PR, it appears that way? (!))
jtojnar has joined #nixos-dev
s33se has quit [Ping timeout: 248 seconds]
jtojnar has quit [Ping timeout: 240 seconds]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
<Mic92>
gchristensen: I can't tell anymore. Too many pull requests.
<Mic92>
I noticed it after.
<gchristensen>
ouch... and scary ... might have to send another PR trying it :)
pie_ has quit [Ping timeout: 248 seconds]
pie_ has joined #nixos-dev
<gchristensen>
man, this RFC has gone sour and I think I did it. I'm sorry
jtojnar has joined #nixos-dev
<dtz>
no no, we just need to be careful and kind. We got this ^_^
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
<gchristensen>
<3 I updated my last comment, you should probably refresh
<dtz>
welp unless I see "EDIT: dtzWill is dumb and should feel bad" I think I stand by saying any potential sourness is not your fault
<gchristensen>
oh, haha, I mean I added a second question :P
<FRidh>
It seems what we need is an rfc on architectures and variations in general, defining the scope of Nixpkgs. Although such rfc is likely too abstract.
<shlevy>
FRidh: One of the big problems is nixpkgs is not quite modular enough to limit scope on these kind of fundamental changes without effectively requiring a fork
<shlevy>
One possibility is, once builtins.fetchGit has spread widely enough, breaking nixpkgs up into chunks with clearly defined scopes, policies, and interfaces
<shlevy>
I think among other things that would force us to do overriding better
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
<FRidh>
shlevy: I know and I agree. The way it is now, the only solution is in-tree. I'm fine with that...but only after having an idea of how much additional maintenance/patches it is going to need. That seems to be unclear at this point. I think supporting this and other things is interesting, yet fracturing a community which is small already is not a smart move either. Show what is *actually* needed so people can make an informed decision.
<shlevy>
I think in practice that's really hard to know in advance.
<shlevy>
But yeah, it's definitely good tot ry to estimate
<FRidh>
Right. #34645 shows already roughly what it encompasses, like additional patches. But what is the scope? nixos-small, nixos? Who is going to maintain these patches? See e.g. Darwin, it's quite amazing how that works, yet at the same time, the scope is way too big judging from the amount of broken packages.
<FRidh>
(Same actually with the Python packages in general)
<shlevy>
I'm hopeful the ofborg work will allow us to enforce some basic CI sanity
<shlevy>
Then at least there will be a baseline of crystal clear expectations :)
<gchristensen>
I hope it has already done that! how can we take it to the next level? what is the next level?
<shlevy>
gchristensen: Protected branches
<gchristensen>
ooh no pushing to master at all?
<gchristensen>
ALL PRs?
<gchristensen>
we had that for a sweet, sweet, 1 hour
<shlevy>
Yep. We can say no reviews because we're not there yet, but if you're confident in ofborg's stability we can require certain baseline checks
<gchristensen>
well there is a small hit-list of stability things we should do first, but I'm proud to say there hasn't been a real outage in it for quite some time now
<shlevy>
:)
<shlevy>
Would be nice to have a "things seem broken, greenlight this PR if it's not fixed within 12 hours" button
<shlevy>
(and an on-call rota ;) )
<gchristensen>
I already have paging setup
<gchristensen>
I have an on-call rotation already
<gchristensen>
I got on call at 00:01 and go off call at 00:00 every day
<shlevy>
:D
jtojnar has quit [Ping timeout: 256 seconds]
<gchristensen>
(though I confess to muting the alerts between 11pm and 6am)
<domenkozar>
hmmm nixpkgs pinning doesn't work with latest hydra
<gchristensen>
how do you get that otherwise-random-path?
<gchristensen>
ah, nix/config.nix?
<domenkozar>
yes
<gchristensen>
I wonder if restricted mode could permit access to the nix/config.nix paths, but I think allowing arbitrary/direct path access otherwise should be blocked
<domenkozar>
let me use more real-world example
jtojnar has joined #nixos-dev
<domenkozar>
done :)
<gchristensen>
maybe update the title to reflect storePath with nix/config.nix?
<gchristensen>
man, I feel RFC could be going well and making progress towards a successful RFC, but is being bogged down by meta-concerns :(
<gchristensen>
I know there are a lot of valid, pent-up concerns around decision making and technical process in the community
jtojnar has quit [Quit: jtojnar]
<gchristensen>
I think it is promising that people are expressing their concerns and questions on the RFC -- better than other RFCs which don't even get that.
jtojnar has joined #nixos-dev
Sonarpulse has joined #nixos-dev
<gchristensen>
^ is that unreasonable, am I misreading the situation?
Sonarpulse has quit [Quit: Leaving]
Sonarpulse has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
<Mic92>
domenkozar: the change was motivated by nixpkgs evaluation in borg.
<domenkozar>
well now pinning doesn't work anymore :)
<LnL>
I use a nixpkgs input with the same revision
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 256 seconds]
jtojnar_ is now known as jtojnar
Sonarpulse has quit [Changing host]
Sonarpulse has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar_ has quit [Ping timeout: 260 seconds]
__Sander__ has quit [Quit: Konversation terminated!]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 260 seconds]
jtojnar has joined #nixos-dev
<Sonarpulse>
niksnut: I just found 5be0a9acd7b9abe4bff3202a7ac7defc17a37877
<Sonarpulse>
but now native and cross are the odd ones out :)
<Sonarpulse>
:D
<dtz>
... am I the only one that can edit the RFC? I understand I'm the author so I should take the lead but not sure if others can edit or not. So I suppose everyone enacts changes to it via me? Never done an RFC before
<gchristensen>
IMO, yes, it all goes through you (and now shlevy)
<dtz>
anyway, goes to respond and triage feedback
<dtz>
okay. Do I need to do something to "let" shlevy make edits? Dunno if he wants to but it seems like a useful thing ^_^
<dtz>
ruhroh, RUHROH! Just saw this in a build log (?!): hash mismatch importing path '/nix/store/hzaa05jxc85h0pzaswk6sf85b67l0q3n-libidn2-2.0.4'; expected hash 'sha256:0000000000000000000000000000000000000000000000000000', got 'sha256:0in9sgvbv8nk4sx4x7xzk2dpg99qmfp1kbhpfl74f326cbx51d5p'
<dtz>
did I bork all my things
<dtz>
lol
<shlevy>
dtz: IIRC niksnut suggested the nix-2.0 branch of nixpkgs for that issue
<dtz>
at least it's all 0's-- if it was a different hash somehow I'd be super sad
<dtz>
okay well at some point recently "real" hydra seems to have done the same: https://hydra.nixos.org/build/68788544/nixlog/38 and it doesn't appear to be on fire so maybe there's hope yet :)
<dtz>
shlevy: I'm running 2.0, but this is also the first time adding "nixos-test" to my builders. lots of variables :3
<shlevy>
dtz: nixpkgs branch, not nix branch
<dtz>
oh! oh interesting. okay, TYVM!
<Sonarpulse>
dtz: yeah I don't think as many people have super access to nixpkgs
<Sonarpulse>
*nix rfcs as nixpkgs
ma271 has joined #nixos-dev
ma27 has quit [Remote host closed the connection]
<Profpatsch>
Sonarpulse: If we get musl as cross-target we need a way to say x86_64+glibc, or armv7+musl, right?
<Profpatsch>
Is that already supported by the current framework?
<Sonarpulse>
Profpatsch: on hydra?
<Sonarpulse>
you mean?
<dtz>
if command-line (or via expression) you can use "config" in localSystem (native) or crossSystem (cross), for example:
<dtz>
nix-build -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/master.tar.gz '<nixpkgs>' --arg crossSystem '{config="x86_64-unknown-linux-musl";}' -A bash
<dtz>
for arm I usually grab the system definitions from lib.systems.examples :3
<Profpatsch>
Sonarpulse: In nixpkgs.
<Profpatsch>
Because architecture and libc are on two different axis, right?
<Profpatsch>
libcs are more of a backend, while architectures are a result.
<Profpatsch>
Hm, of course one could use different libcs to “cross-compile” to a different libc. So maybe it’s not that clear of a distinction?
<Sonarpulse>
Profpatsch: mmm
<Sonarpulse>
Profpatsch: so internallly
<Sonarpulse>
there is {build,host,target}Platform
<Profpatsch>
The RFC doesn’t really say how this should be implemented technically.
<Sonarpulse>
each of which has a `libc` string
<Sonarpulse>
which says which one is used
<Profpatsch>
Ah!
<Sonarpulse>
Profpatsch: we could add it, but none of the mechanism is new
<Sonarpulse>
it is already used for Darwin
<Profpatsch>
So it’s in the architecture tuple.
<Profpatsch>
I see.
<Sonarpulse>
and in fact the libc string dates back to old cross
<Sonarpulse>
Profpatsch: musl is also directly in the string
<Sonarpulse>
libSystem isn't
<Sonarpulse>
but we infer it from various darwin things
<Sonarpulse>
see lib/systems/*
<Sonarpulse>
there's a lot of parsing magic :D
<Profpatsch>
Oh crap, we have a “parser” of these strings in nixpkgs?
<Sonarpulse>
Profpatsch: :D
<Profpatsch>
I wasn’t aware.
ma271 has quit [Ping timeout: 255 seconds]
<Sonarpulse>
Profpatsch: I need to write a new nix pill
<Sonarpulse>
for how all the lib stuff works
<Profpatsch>
Why not just generate it from attribute sets?
<Sonarpulse>
starting with (import ./. { .. })
<Sonarpulse>
Profpatsch: It is bidirectional! :D
<Profpatsch>
You are basically constructing strings from attrsets and then parsing them in again?
<Profpatsch>
But why do we need that? On the nix level I mean?
<Sonarpulse>
Profpatsch: it will fill in whatever is not explicit
<Sonarpulse>
if you just do string
<Sonarpulse>
it fills in attributes
ma271 has joined #nixos-dev
<Sonarpulse>
if you just do the attributes it fills in the llvm-style tripple
<Profpatsch>
Yeah, but why go through strings?
<Sonarpulse>
Profpatsch: easy ui
<Sonarpulse>
everybody wanted to just do
<Profpatsch>
If you could to let defaultSystem = … in defaultSystem // { system = "linux" };
<Profpatsch>
Instead of defining what is experimental (which means everything is supported by default), let’s define a core set that is supported and some base guarantees.
jtojnar has joined #nixos-dev
<vcunat>
I do like this inverted approach.
<Profpatsch>
We could also couple more guarantees to e.g. full, like automatic testing for each package.
<Profpatsch>
Or start loose and slowly move to stronger guarantees.
<Profpatsch>
Better tooling enables stronger guarantees of course.
<vcunat>
We could extend the meaning meta.platforms to also be able to express which libcs are expected to work/
<vcunat>
and which cross-compilation configs.
<vcunat>
(maybe it would be in some other meta field, I don't know)
<Profpatsch>
This also ties in to better industrial support and the talk peti gave at NixCon
<vcunat>
That way a maintainer could declare that (s)he wants to also support this.
* dtz
reads
<Sonarpulse>
Profpatsch: looking
<Sonarpulse>
Profpatsch: you need more dimensions :D
<Sonarpulse>
but I think I agree with cells themselves
<Profpatsch>
Sonarpulse: I knooow. :)
<Sonarpulse>
Profpatsch: this nicely illustrates other things I want to accomplish with the release.nix cleanup :)
<Sonarpulse>
annoying our current "core" is nixos unstable small
<Sonarpulse>
but that doesn't make sense for non-nixos
<copumpkin>
looks like chromium is dead on release-17.09
<copumpkin>
anyone know what's up
<copumpkin>
?
<Profpatsch>
Probably all derivations that construct a minimal nixos system should be part of the core set.
<Profpatsch>
Because it should be ensured nixos always runs on all supported platforms. d)
<Profpatsch>
That’s why Core musl is only listed as “support”, in case we don’t want to make it a core platform.
<Profpatsch>
There’s support on bug reports, but no guarantee everything always builds.
<Sonarpulse>
Profpatsch: hmm it would be nice to get the closure, minus the nixos stuff itself
<Profpatsch>
One could even think about less support, like putting Core armv7 down to support and Core musl down to ask
<Profpatsch>
Of course the semantics of the different support levels and field values are up for debate also, those are just from the top of my head.
<Profpatsch>
Like, Supported and Maintained could be collapsed into one tier and shoud probably be renamed.
<copumpkin>
it'd be nice if triggering a rebuild allocated a new build id
<copumpkin>
niksnut: are old build logs available somewhere if I trigger a rebuild on hydra?
<gchristensen>
don't think so
orivej has quit [Ping timeout: 260 seconds]
<vcunat>
No, they get overwritten.
<vcunat>
It's in-place on AWS, I think.
<copumpkin>
that's a pity
<copumpkin>
usual workflow: spurious failure on hydra -> rebuild -> go check logs to figure out what went wrong
<copumpkin>
-> cry because there aren't any logs anymore
<Sonarpulse>
copumpkin: sad sad sad
<copumpkin>
"I have tremendous reliable builds. Tremendous! But dishonest Lyin' Hydra wants to claim it always succeeds when it fails most of the time. Only guilty people deletes logs. Sad"
<copumpkin>
(covfefe)
<gchristensen>
firey
taktoa has joined #nixos-dev
<copumpkin>
tellin it like it is
<gchristensen>
ofborg will show you all the logs, just not where they ran or what it is building ;)
<vcunat>
yes, I've thought of that feature as well
<vcunat>
and nix does the same
<vcunat>
(locally)
<vcunat>
and it's hard to read in-progress logs due to compressinon lagging the writes too much
<vcunat>
(well maybe the reason is different, but I think it's because of that bz2 compression)
<copumpkin>
yeah, it'd be nice to have a nix-tee
<copumpkin>
:P
<copumpkin>
that acts as a middleman for the daemon logging machinery
vcunat has quit [Ping timeout: 264 seconds]
vcunat has joined #nixos-dev
goibhniu has quit [Ping timeout: 240 seconds]
<dtz>
is it likely for hydra to (more directly) start leveraging the new Nix 2 store / remote builder goodness anytime soon?
<dtz>
Perhaps after this release push, when things settle a bit and folks are more widely using it.....(?)
<dtz>
:)
<LnL>
all of the hydra builders use nixUnstable afaik
orivej has joined #nixos-dev
<vcunat>
Yes, I think so.
<gchristensen>
yeah
<vcunat>
gcc-7 is on master!
<LnL>
compiler updates for everybody \o/
pie_ has quit [Ping timeout: 248 seconds]
<vcunat>
And linux 4.14 as well!
<vcunat>
Can't upgrade the Darwin kernel for you, unfortunately.
<vcunat>
Hmm, this didn't upgrade the default compiler for Darwin even.