<shlevy>
"No one will ever need more than 128 bytes of struct"
<lassulus>
thefloweringash has joined #nixos-dev
<vcunat>
:-D
<gchristensen>
IMO we should revert uses of Nix2 features for now
<gchristensen>
in nixpkgs
davidlt has quit [Ping timeout: 268 seconds]
ashgillman has quit [Ping timeout: 248 seconds]
<LnL>
placeholders? or is there more
<gchristensen>
well I'd like if we'd revert the closure thing in nixos too, but I think just placeholderes?
<LnL>
ah right the nixos tests, don't know the details of that
<rycee>
Hmm, in #nixos the user phry seems to have run into an interesting behavior with types.loaOf. Anybody around who knows about lib/types.nix and whether I'm misunderstanding the use of this type?
<rycee>
Basically the issue is that if you give a list of more than 10 elements to an option of type loaOf then the order is screwed up because the order becomes "unnamed-1.1", "unnamed-1.10", "unnamed-1.2", …
<LnL>
the order as in one assignment with a large list?
<rycee>
If you in your configuration have `programs.ssh.matchBlocks = [ conf1 conf2 … conf20 ]` then the entries will become reordered in the loaOf because it relies on alphabetic ordering.
<rycee>
Specifically maybe something like `elem.name or "unnamed-${toString defIdx}.${leftPadWithZero (toString elemIdx)}"`
<rycee>
LnL: I think the merge order is not relevant here. This affects a single assignment to the option with a list of >10 elements.
<LnL>
yeah in that case I wouldn't expect the order to change :)
davidlt has joined #nixos-dev
<angerman>
shlevy: take it twitter? :-)
<shlevy>
:)
<angerman>
shlevy: if you look at the buildInputs the generic-builder essentially creates... it's just... massive.
<shlevy>
angerman: I'm not sure who currently consumes cross-haskell... You, sonarpulse, bgamari ? If you're all on-board with no custom setups, that's easy
<angerman>
shlevy: another thing that's really annoying is the generic-builder -> hscolour -> ghc dependency.
<shlevy>
But even ifnot I'm willing to try a solution that reuses a base setup in most cases and compiles a custom setup separateonly only when needed
<shlevy>
(have to head off soon)
<angerman>
shlevy: right, but at that point what's the difference to just using cabal-install?
<angerman>
shlevy: also dropping the `nativeGhc` from the buildInputs helps quite a bit.
<angerman>
shlevy: If you have some stuff, I should look into, throw it at me... otherwise I'll just try to chip away at it for my cross compilation use case.
<angerman>
shlevy: also, cabal2nix should generate some system-parameterised derivation. E.g. grab the packageDescription in it's unfinalized version, and expose the pacakgeDescription finilization as a function in nix.
<angerman>
that arguably is a rather cross compilation specific issue though.
<shlevy>
angerman: I've wanted cabal2nix to be able to handle flags and systems better...
<angerman>
shlevy: yea, that would probably cover both.
<angerman>
shlevy: I'm not sure if cabal2nix still has this long hardcoded list of library mappings. A few(?) years ago, when I looked at it, that mapping was something that I though should have been in nixpkgs as well instead of in cabal2nix.
<angerman>
shlevy: I'm also on the fence if building of packageDatabases should be separate derivations.
davidlt has quit [Ping timeout: 260 seconds]
davidlt has joined #nixos-dev
andi- has quit [Ping timeout: 265 seconds]
andi- has joined #nixos-dev
<shlevy>
angerman: I kind of think they should... We do it anyway for nix-shell envsetc.
<angerman>
shlevy: about the `Setup.hs`. I believe we'll need some `doBootstrap`; where the builder still goes the `Setup.hs` + build path.
<angerman>
but that should be an escape hatch only... to break cycles, when you want to link against a different `Cabal` library.
<angerman>
(not the one that's shipped with ghc).
<shlevy>
angerman: Even then I think it should be a different drv...
<angerman>
shlevy: so for the Setup.hs, you can only properly do that with cabal2nix in nix, if I understand correctly, because you'd need to know apriori if it comes with a custom setup or not.
<shlevy>
angerman: Right, so we'd just tell cabal2nix to tell us that
<shlevy>
It's all open source ;)
<angerman>
shlevy: right! Don't take my complaining the wrong way...
<angerman>
shlevy: but maybe you can give me some additional reasoning why we would not want to use cabal-install. The way I'm looking at it, building the Setup, builds is something that's kind of similar to cabal-install anyway?
<angerman>
I do see that cabal-install comes with all the hackage pull down logic, and we'd probably want to pin the packages from nix anyway and don't really have use for the solver in cabal-install.
<shlevy>
angerman: It's basically a porcelain vs plumbing thing
<shlevy>
We don't want the fetching or dependency resolution
<shlevy>
and Cabal the lib is "the" way to just get the build bits, as I understand it
<shlevy>
It also reduces our bootstrapping load, which is definitely nice
<angerman>
shlevy: right, `cabal-install` would do the `Setup.hs` handling for us.
<shlevy>
Sure, but we'd still have non-trivial work providing it the right package sets etc.
<shlevy>
Especially if we support custom during cross
<angerman>
you mean custom setups for cross compilation?
<shlevy>
yeah
<angerman>
So the Custom setup's I've run into fall into two categories a) add doctest support, b) add some haddock logic.
<angerman>
As we don't really perform testing for cross compilation, the doctest part becomes somewhat irrellevant, and the haddock part is likely of low prio for cross compilation as well.
<angerman>
If a package tries to replicate any `configure` style logic in the `Setup.hs`, it's almost bound to get the wrong results when compiling (and running) the Setup on the build machine.
<shlevy>
I mean, I wouldn't a priorit say no to a switch to cabal-install. I just don't predict it'd be that big of a win
<angerman>
shlevy: ideally those kinds of needs should be exposed in a non-opaque way through the cabal file. Such that one can make proper decisions how to deal with them in a cross compilation setting.
<shlevy>
And I do think whenever possible aiming for same behavior in cross vs not is a really important goal
<shlevy>
So not building docs should be seen as a fault, even if not a super high priority one
<shlevy>
I'd eventually like to teach nix to be able to substitute a native drv for a cross-built one automatically, when the latter is available
<shlevy>
(opt-in, of course)
<angerman>
shlevy: I'd like to give your cabal2nix stuff a try (if you have any already).
<shlevy>
Hell, I'd be in favor of removing custom setups altogether :D but I'd rather do that through upstream
<shlevy>
angerman: Not yet, I'll let you know if/when I get something together
<angerman>
shlevy: I'll also see if I can chip off some more from the generic-builder.
<angerman>
As I said I have a custom Setup derivation that builds the default Setup, which I use for all cross compiling packages, (essentially disabling Custom).
<angerman>
shlevy: is there custom packageDb logic somewhere you could point me to? Otherwise I'd proably try to just rip that out of the generic-builder as well.
<shlevy>
angerman: I'd look at ghcWithPackages
<angerman>
shlevy: and yes, the `build-type: Custom` removal is something that needs to be addressed in cabal. The implementation of `cabal doctest` was only a minor step towards that goal.
<globin>
vcunat, fpletz: anything you need help on for the release right now, that I could/should take on except fixing builds?
<fpletz>
the systemd bump seems to break the containters-imperiative test :/
<fpletz>
will have time to debug that in a bit
<vcunat>
ATM I'm not aware of anything else
<vcunat>
and for x86 there's relatively few failures on Hydra
<vcunat>
(for Linux)
<globin>
vcunat: are we publishing 18.03 aarch64 channels?
<vcunat>
oh, that
<vcunat>
there seemed to be a preference for shared nixos channel for both
<vcunat>
but in current configuration Hydra isn't capable of evaluating the combined jobset
<vcunat>
(Even now I'd say that a noticeable fraction of evaluation fails transiently.)
<globin>
ack, that's why as long as that is the case we should do seperate channels IMHO?
<vcunat>
Yes, I suppose I'll just create a separate channel in the end.
<vcunat>
I hoped I could have a weekend to look at these performance optimizations, but there's always something that seems more important, as it still keeps going somehow as it is now.
<LnL>
for darwin I'm almost through the entire list, most of what's remaining I don't know how to fix
<vcunat>
Yeah, it's fine to just restrict the platforms.
davidlt has quit [Ping timeout: 276 seconds]
ma27 has quit [Ping timeout: 246 seconds]
ma27 has joined #nixos-dev
zybell_ has quit [Ping timeout: 264 seconds]
<LnL>
I have a branch with a bunch of platforms changes, just trying to get though the list frist
ma27 has quit [Ping timeout: 246 seconds]
ma27 has joined #nixos-dev
zybell_ has joined #nixos-dev
ma27 has quit [Ping timeout: 256 seconds]
ma27 has joined #nixos-dev
<domenkozar>
upgraded to 18.03, but my xfce got restarted
<aminechikhaoui>
is it stable enough to switch to 18.03 now ? or is it at my own risk :D
<domenkozar>
seems to work for me otherwise :)
<aminechikhaoui>
good
<gchristensen>
it is beta though
<clever>
domenkozar: check the journal for display-manager, right at the time of the restart, it may have failed internally due to something else restarting
fpletz has quit [Remote host closed the connection]
<domenkozar>
Mar 24 19:15:04 guava systemd[1]: Stopping X11 Server...
<domenkozar>
Mar 24 19:15:58 guava systemd[1]: Starting X11 Server...
<domenkozar>
Mar 24 19:15:58 guava systemd[1]: Started X11 Server.
<domenkozar>
this might explain it
<domenkozar>
also my mouse is really fast
<domenkozar>
but I can fix this :)
<vcunat>
that doesn't say why it's restarted, does it?
<domenkozar>
well I think systemd restarted it
<vcunat>
I assumed it was due to same dependencies among the unit files
<vcunat>
s/same/some/
<vcunat>
but that was just a guess
<vcunat>
in any case, I personally don't do "switch" for large upgrades, and use "boot" instead
<gchristensen>
same
<LnL>
yeah, with the previous release sudo would disappear if you don't open a new shell, etc. :D
<thoughtpolice>
When is the official 18.03 release scheduled?
pie_ has joined #nixos-dev
<vcunat>
In about a week.
<thoughtpolice>
I sort of messed myself up; I authored a package with a bad version in HEAD, and the new version released means I'd probably have to break the version scheme once, downgrading the package number
<thoughtpolice>
(e.g. 1.3.0 -> 1.2.1)
<vcunat>
though I don't think we've really announced a particular commitment about the date of schedule
<thoughtpolice>
OK, I'd like to fix that and cherry pick it, so I wanted to made sure I had time. I'm probably the only person using this package anyway...
<domenkozar>
thoughtpolice: I help you if you release ed25519 :P
<domenkozar>
(jk)
<thoughtpolice>
:x I have some work on my laptop I need to push, sorry domenkozar! This weekend does look like it's a hacking one tho, so...
<domenkozar>
at least I know my timing :)
<thoughtpolice>
(And a GHC patch to follow up on, and, and, and....)
<domenkozar>
thoughtpolice: it would make me really happy to see it out, we've been using it on all OSes
<domenkozar>
thoughtpolice: it doesn't need anything new, just a push :)
<domenkozar>
thoughtpolice: by nixos manual it says 18.03 should be released in 5 days
<domenkozar>
on 29th March
<thoughtpolice>
Aw shit. And I wanted to see if getting JDK10 in there would be possible too... Ugh.
<domenkozar>
my "oh shit" list is 20 items long >.<
<globin>
well adding it shouldn't be that a problem, defaulting to it is another story
<thoughtpolice>
globin: No, JDK10 is not LTS, so it would remain JDK8. But the real problem is JDK9 is now EOL'd, so ideally it would be nice not to ship 18.03 with an immediately EOL'd version...
<thoughtpolice>
(Actually adding jdk10 or changing jdk9 is relatively non-problematic right now since nothing uses them explicitly, essentially)
* aminechikhaoui
just switched to NixOS 18.03 \o/
<aminechikhaoui>
things seem ok
<globin>
hmm if jdk9 is EOL'd by that we should if still possible switch rather now
<globin>
vcunat ^
<thoughtpolice>
globin: I think it was EOL'd right when Java 10 was released, so it's already happened... Not sure if we want to just remove jdk9 though -- was it in 17.09?
<thoughtpolice>
jdk10 is a much smaller delta though, I haven't tried adding an expression yet but maybe the jdk9 one would be very close, I'd hope
<thoughtpolice>
openjdk9 is available in 17.09, currently.
<LnL>
well if it's not supported anymore we should remove it
<thoughtpolice>
That's true. Admittedly it's not released yet so breaking people depending on 'openjdk9' is less an issue than I imagine it might be...
<thoughtpolice>
Sort of an annoying 6 month cadence release synchronization going on, though...
<thoughtpolice>
We'll be playing this game every time now unless the schedules shift.
<LnL>
I mean for 18.03
<thoughtpolice>
Oh, just remove it outright. Yes that's probably worth doing sooner rather than later, and adding 10 if it manages to make the deadline...
<vcunat>
I expect we can just drop it from master and 18.03.
<vcunat>
(but I don't know the Java ecosystem at all)
<vcunat>
and for 17.09... well it won't be supported for long now, so we probably don't need to do anything unless some important security issue in there appears