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
<shlevy> Eh, why are only two builds running on hydra? :o
<shlevy> niksnut: ^?
<shlevy> gchristensen: 5 day old darwin build... https://hydra.nixos.org/build/70033184
<gchristensen> I swear I wrote a tool to help me fix these
<gchristensen> I would like to put a $100 bounty on "nixops, but for nix-darwin"
<shlevy> gchristensen: Just support the musl work and we can just cross-compile for darwin :P
<gchristensen> it isn't the compiling, its the activation and service management
<gchristensen> which makes the macs really annoying to admin
<shlevy> gchristensen: Right, but if you cross-compile to macs you never have to *run* them
<gchristensen> haha
<gchristensen> you wish
<shlevy> OK, strange... I wonder if the long-running build is plugging up the queue somehow? Or if staging shares have some kind of starvation? nixpkgs:trunk has completely built but other stuff's been hanging around unbuilt for up to a week...
<shlevy> niksnut: How hard would it be to make a "really super seriously abort build" button that would kill the remote connection? :P
<gchristensen> it'd be pretty annoying I think
<shlevy> What's our backwards compat policy for nixpkgs by the way? e.g. am I allowed to have stdenv depending on structuredAttrs by 18.07?
<gchristensen> the mac builds should be fixed now
<shlevy> Thanks!
<shlevy> Very odd to me that only one build is running right now
<shlevy> Only 24k backlog...
<gchristensen> hmm
<gchristensen> erm, the strangest thing to me is that it is building on hydra itself
<shlevy> :D
<shlevy> What
<shlevy> Also not a hydra issue but that's a "tarball" job and appears to be building guile itself
<gchristensen> well we are the build farm for guile
<shlevy> Right, it's just the job name seems weird
<gchristensen> ah
<shlevy> Why do I need to build guile to make a tarball? And it's not guile from nixpkgs, it's part of the tarball build itself.
<gchristensen> presumably the guile build involves tarballing itself
<shlevy> Yay, queue is filling
<shlevy> erm, s/filling/emptying I guess
<gchristensen> maybe a network problem caused hydra to give up on all the remotes for a while
<shlevy> It seems suspiciously timed relative to the job you killed
<shlevy> I mean, the job was hanging on networking
<gchristensen> yep
<shlevy> But it shouldn't have hogged the whole pipe :o
<gchristensen> nopew
<gchristensen> well maybe
<gchristensen> but AWS did have (they claim minor, so probably the entire DC fell off the net) network issues today according to their dashboard,
<shlevy> Outage wouldn't have affected routes to e.g. Wendy, right?
<gchristensen> I don't know :/
pie__ has joined #nixos-dev
pie___ has quit [Ping timeout: 260 seconds]
<samueldr> let's say I wanted to help triage (mainly older) issues for nixos-homepage, would replying with a comment explaining why it can be closed correct?
yorick has quit [Ping timeout: 256 seconds]
<shlevy> Think I have a solution for ssh-ng as a build-remote... But it's not pretty :(
<gchristensen> samueldr: can't hurt :)
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
pie__ has quit [Ping timeout: 276 seconds]
jtojnar has joined #nixos-dev
<gchristensen> nice, samueldr
<samueldr> and, since I have a feeling any activity in that repo is often muted by all the activty elsewhere, a couple PRs https://github.com/NixOS/nixos-homepage/pulls/samueldr
mbrgm has quit [Ping timeout: 248 seconds]
mbrgm has joined #nixos-dev
<shlevy> niksnut: Am I reading right that the worker protocol basically forbids parallel builds? :(
<shlevy> Oh, right, nix.machines has its own notion of number of parallel builds
<shlevy> OK
pxc has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
pxc has quit [Ping timeout: 260 seconds]
pxc has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
pxc has quit [Ping timeout: 252 seconds]
pie__ has joined #nixos-dev
ma27 has quit [Ping timeout: 256 seconds]
vcunat has joined #nixos-dev
orivej has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
FRidh has quit [Remote host closed the connection]
<Mic92> just for the record, on which day will we have branch-off?
<fpletz> Mic92: we need a stable system and upgrade path first, I'm with vcunat that currently https://github.com/NixOS/nixpkgs/issues/36268 is the only blocker
<fpletz> Mic92: branchoff also means a call for testing and if we know of severe issues it doesn't make sense to waste other people's time :)
<ekleog> (about branch-off, it's not a blocker but I don't think there is anything blocking this PR from being merged? https://github.com/NixOS/nixpkgs/pull/30416 )
<Mic92> ok. so it is done when its done.
<fpletz> so my suggestion would be some time this week probably… vcunat? :)
<fpletz> ekleog: I was hoping for more reviews on that PR
<vcunat> I was thinking we might branch now, and cherry-pick smaller regressions later
<vcunat> (like the upgrade-path problem)
<vcunat> fpletz: do we know any other "18.03 blocker" that's missing from master?
<fpletz> vcunat: is the remainig problem only iso generation? with you part-revert at least regular nixos system should be fine, right?
<fpletz> vcunat: I was going through the PRs on the weekend and didn't find anything else that might delay the branchoff at least :)
<vcunat> fpletz: well, I know little around that issue, unfortunately.
<vcunat> I still want to look into a libGL mass-rename before branch-point https://github.com/NixOS/nixpkgs/pull/34461 as it seems best to do it close before branching to minimize conflicts during the whole release cycle.
<vcunat> I do hope I can decide that one today
<fpletz> +1
<vcunat> BTW, I just started a discussion about staging workflow on a new RFC: https://github.com/NixOS/rfcs/pull/26
<ekleog> fpletz: hmm ok, I guess it won't make it in time for 18.03 then :/
<fpletz> ekleog: nah, was just going through that again, let's merge :)
<ekleog> oh great, thanks! :)
<vcunat> I also scanned especially "blocker" label and 18.03 milestone this weekend, so we're hopefully good, except for what we just mentioned.
<fpletz> vcunat: good idea with staging-next… I'm never really sure when to merge stuff to staging when I haven't actively montiored hydra for a while
<vcunat> There are lots of changes in master..staging (~10 days), but maybe they didn't hope to get to 18.03.
__Sander__ has joined #nixos-dev
<vcunat> March 31 is Saturday, so even with this nix-2.0 delay we might still have three weeks for stabilization+ZHF.
* fpletz will take 2+ weeks of holidays for release hacking starting next week :)
<vcunat> :-D taking holidays to do what most would call work.
<__Sander__> hehe :D
<vcunat> Wait, I thought NixOS is important for your work. (Contrary to mine.)
<vcunat> That's even stranger.
<__Sander__> well, we do use Nix-related solutions
<__Sander__> but
<__Sander__> I can only focus myself on the specific areas that my employer considers to be important for them
<vcunat> Right, I understand the focus. I meant Frank this time, as I thought the company runs some production stuff on NixOS releases, but maybe I was mistaken.
<vcunat> But even there, they would surely use only a tiny subset of packages, so it actually makes the same sense.
goibhniu1 is now known as goibhniu
<niksnut> the closure size of my system has increased by over a gigabyte going from 17.09 to 18.03 :-|
<vcunat> Hehe, should we add closure-size decreases for ZHF?
<niksnut> maybe we should make the NixOS tests require that there are no -dev paths in the VM closures
<vcunat> I'd rather hardcode some closure-size limits into them.
<vcunat> Perhaps as a separate set of closure-size tests.
<vcunat> Or both approaches. -dev will get reasonably recognized only by pattern matching on the name, right?
<vcunat> Setting the size values might be even more fragile, but I think it's bearable for _this_ kind of tests to be hacky.
* vcunat is trying to get a nixos-unstable bump today to avoid the nix-2.0 upgrade problems.
<niksnut> vcunat: yeah, a closure size limit would also be nice, but more fragile
ma27 has joined #nixos-dev
ma27 has quit [Ping timeout: 260 seconds]
Lisanna has quit [Quit: Lisanna]
Lisanna_ has joined #nixos-dev
<pierron> niksnut: I really dislike the debuggability aspect of https://github.com/edolstra/nixpkgs/commit/42350901667af92bf21c3d0cfa229b9a61d75d8a
<pierron> niksnut: callPackage is lightly better as you can lookup the environment in which these names are solved from.
<niksnut> I'm not really seeing the difference
<shlevy> I kind of worry that "include" without extensible attrsets will be strictly worse than the status quo... and with it it can be implemented in library code
<niksnut> here you can also lookup the environment (namely, it's "pkgs" in this case)
<vcunat> well, over the long term, I would like to get rid of most significant code in all-packages.nix
<vcunat> and e.g. do the callPackage stuff inside the per-package expressions
<copumpkin> is that include like an importScoped?
<copumpkin> erm, scopedImport :)
<niksnut> I would argue that any use of library code indicates a failure/insufficiency of Nix as a DSL
<copumpkin> eh, I much prefer a fairly minimal set of building blocks that allow us to compose them nicely
<copumpkin> than a DSL that predicts every possible use case and include a special construct for it
<copumpkin> (it's about smoothness of experience when you do something the DSL author didn't predict)
<vcunat> yes, I agree we don't need everything inside the language proper
<copumpkin> so in that sense, I think you did a pretty good job with Nix the DSL so far :P
<niksnut> then you should use a general-purpose language (e.g. scheme ;-)
<copumpkin> eh, I don't want that much power :)
<copumpkin> the lack of arbitrary effects is a big draw for me to Nix
<vcunat> :-D
<copumpkin> Haskell would sort of fit my needs, but I still don't know how to type nixpkgs properly, so Nix is perfect
<niksnut> or dhall
<vcunat> It seems common that a standard library is "part of language" but written in the language and almost-normally imported.
<vcunat> (e.g Haskell's prelude)
<copumpkin> but it's sort of the framework vs. library distinction
<copumpkin> frameworks seem to (in common parlance) be precomposed lumps of "we make one use case extremely easy, but woe be anyone who attempts to deviate from the endorsed path"
pie__ has quit [Ping timeout: 265 seconds]
<copumpkin> and I generally don't like that approach, because I generally try to do weird things
<shlevy> I think using library code in core places is fine. If it's littered throughout normal code then it's maybe a smell your L isn't DS enough, but I think it's case-by-case.
<shlevy> Putting it another way: A "language" is made up of both core language features and standard library idioms. If you can push things into a library instead of core features without sacrificing expressiveness or ease of use in the common case, great!
<shlevy> memcpy is a fundamental operation in the domain of "mucking about directly with heap memory", but doesn't need to be provided as a C builtin.
ocharles has quit [Ping timeout: 276 seconds]
globin_ has quit [Ping timeout: 276 seconds]
pbogdan has quit [Ping timeout: 276 seconds]
globin_ has joined #nixos-dev
ocharles has joined #nixos-dev
pbogdan has joined #nixos-dev
ma27 has joined #nixos-dev
<niksnut> actually sacrificing expressiveness might be a good thing
<niksnut> the problem with expressiveness (i.e. functions) is that everybody invents their own abstractions
<niksnut> so potentially every Nix expression looks different
<niksnut> and is therefore harder to understand for someone unfamiliar with some particular abstraction
<niksnut> whereas, say, every RPM spec file has the same structure
<gchristensen> RPM specs have their own invented abstractions based on m4 where if you're unfamiliar with the territory you're hopelessly lost
<gchristensen> and having to deal with m4 :P
<sorear> rpm does not use m4
<gchristensen> hmm you sure? I could have sworn I was dealing with m4.
<vcunat> I don't find RPM specs readable, for more complicated packages.
<contrapumpkin> sorear: whoa, are you the mystical old haskeller sorear?
<vcunat> Those I've seen were way too long, lots of lines in a single file.
<sorear> rpm has a baroque macro language of its own, I have no idea if it's m4-derived (although it's visually closer to cpp) but it doesn't use m4 today
<niksnut> I thought it only has variables
<sorear> contrapumpkin: I was a #haskell person ca 2007, do I have a reputation
<contrapumpkin> yes :)
<niksnut> but in any case m4 is a great example of the danger of adding programmability :-)
<contrapumpkin> JSON for all!
<gchristensen> the challenge is perhaps not strictly how to limit expressiveness, but how to guide the various pieces of nixpkgs in to developing a common method of getting the job done
<shlevy> niksnut: I mean sacrificing expressiveness relative to an in-language version of the feature
<vcunat> Macro languages :-(
<Dezgeg> how about GNU make?
<Dezgeg> as a dangerous example :)
<vcunat> Rings a bell - my work project has everything in gnu-makefiles + pkg-config (instead of autotools or such), and it's a nice mess.
<contrapumpkin> I like to run M4 over CPP over C++ for maximum fun
<shlevy> Anyway, as far as I can tell we haven't had a fundamental change in the mkDerivation/callPackage paradigm in a *very* long time. At least as long as I've been around I think. Before implementing new language features I think we can and should try out the new interfaces in the existing language so we can make sure it actually gives us what we want
<gchristensen> let's all just go back to a time when computers were programmed via needle and wire. no package management problems then.
<shlevy> (yes, even if the new interface requires hacks like mkIf for the time being)
<gchristensen> (without looking at the article) I didn't know the nixos module system was based on IBM's
<shlevy> :D
<niksnut> shlevy: well, self/super is a new-ish paradigm
<vcunat> +1
<shlevy> Yes, but it doesn't change the way we express dependencies of packages or the use of callPackage
<vcunat> But we've been using self/super for years already, I think.
<shlevy> And, FWIW, it actually works pretty damn well
<shlevy> When I hit pain it's rarely due to the fixpoint. It's due to the interfaces exposed
<shlevy> I have an idea for what a new interface might look like brewing... I'll try to write it up soon
<niksnut> interface for what?
<copumpkin> (and just to reiterate, I love that the language gives us the flexibility to experiment with that sort of thing)
<copumpkin> (and also, that it doesn't have a built-in notion of self/super, unlike e.g., jsonnet)
<copumpkin> (which would have simplified a tiny bit of the self/super design at the cost of not being able to do other things as nicely)
<shlevy> niksnut: For what e.g. gcc-7.nix will look like
<shlevy> And how to compose those things
sonarpulse has joined #nixos-dev
<vcunat> fpletz: I think we're ready to branch 18.03. (Will be online a little later this evening.)
<Profpatsch> Fuck, we missed nix-env.
<Profpatsch> Uh, let’s see …
<gchristensen> I don't think that was an accident?
<Profpatsch> Well, I never use nix-env, so I didn’t notice.
<gchristensen> what do you mean we missedi t?
<Profpatsch> $ nix-env -qaP --meta --xml >/dev/null
<Profpatsch> derivation 'docker-17.12.1-ce' has invalid meta attribute 'maintainers'
<Profpatsch> derivation 'docker-18.02.0-ce' has invalid meta attribute 'maintainers'
<gchristensen> ack
<Profpatsch> I hope there is shortName support.
<Profpatsch> Otherwise this won’t be easy.
<vcunat> I've seen those errors, but I don't yet see how they originate.
<vcunat> (or how to get rid of them)
<Profpatsch> vcunat: We changed maintainers.nix
<vcunat> I know that.
<vcunat> But changing the schema didn't help for me.
<vcunat> (I did something wrong, I guess.)
<gchristensen> Profpatsch: I'm not sure how nix-env is puking for you when Ofborg always checks that
<Profpatsch> Not me
<Profpatsch> But we broke peti’s Workflow
<gchristensen> well I agree with him
<Profpatsch> Let me check the nix-env source once I’ve updated my system here.
yegortim1 has quit [Write error: Connection reset by peer]
<gchristensen> it is only a handful though
yegortim1 has joined #nixos-dev
globin_ is now known as globin
<gchristensen> got a fix, Profpatsch
<Profpatsch> gchristensen: Awesome.
<sonarpulse> vcunat: you're minutes away from making the branch?
<sonarpulse> or just sometime today?
<Profpatsch> gchristensen: What!
<Profpatsch> I thought I had removed every null?
<Profpatsch> That’s strange.
<vcunat> Sonarpulse: just waiting for ACK from fpletz.
<Profpatsch> I’m sure I manually went through the list.
<gchristensen> I'd believe it
<gchristensen> with the shuffle of the rebase/ revert / revert-revert... things happen
<fpletz> vcunat: ah, sorry, ack from me :)
<vcunat> But the main point to hurry is to start a channel, jobset, ZHF
<Profpatsch> But great that it’s just that.
<gchristensen> indeed, I'm glad we don't have to revert all the way :P
<Profpatsch> Some people had `null` in their mail field.
<Profpatsch> …
<Profpatsch> I just removed them from the maintainer list.
<Profpatsch> I think it was one person. But they had no packages.
<vcunat> fpletz: never mind, I didn't hurry that much. I'll actually start working on it in an hour or two, unless you want to do it earlier :-)
<vcunat> (yourself)
<gchristensen> while I have people's attention, any opinions on this little fella? https://github.com/NixOS/nixpkgs/pull/36344
<fpletz> vcunat: that's your privilege - you have to pick the new release codename anyway :>
<Profpatsch> gchristensen: Does ofborg check the structural integrity of the maintainers file?
<Profpatsch> Because that would hinder people from sneaking nulls.
<gchristensen> it definitely should, note my comment on the PR:)
<vcunat> fpletz: my privilege? I thought we're both release managers for 18.03.
<Profpatsch> Check your privilege!
<fpletz> vcunat: you're the new one :)
<fpletz> but yeah, that isn
<fpletz> *isn't written anywhere :)
<vcunat> hehe
vcunat has quit [Quit: Leaving.]
<Profpatsch> I take it that nixpkgs upgrade to 2.0 should be working now?
<gchristensen> if people notice ofborg taking a long time to eval a PR, please ping me. periodically I've seen it take >10min and get "stuck"
<sonarpulse> Profpatsch: the nixos one is still broken on latest channel
<sonarpulse> but it is fixed on master
<gchristensen> guh something is wrong, ofborg can't seem to finish this PR...
<Profpatsch> Sonarpulse: Fixed on master works for me, thanks.
<sonarpulse> Profpatsch: np
mbrgm has quit [Quit: ZNC 1.6.5 - http://znc.in]
<Profpatsch> wish me luck, people
<Profpatsch> Or wait, let’s back up the database firs.
<gchristensen> good luck
vcunat has joined #nixos-dev
mbrgm has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
pie__ has joined #nixos-dev
pxc has joined #nixos-dev
<dtz> anyone observing Nix 2.0 being more or less incapable of functioning within a docker container? Trying with lnl7/nix or nixos/nix as the base, grabbing nixUnstable from nixos-unstable, but then many builds just.... hang? :(
<dtz> no worries if not, still some env problems to sort out but thought I'd ask since it's strange
<LnL> I'm using a horrible fork of that container with nixUnstable at work
<dtz> maybe docker is being silly, for example :).
<dtz> okay, good to know ty sir
jtojnar has quit [Quit: jtojnar]
<LnL> release-18.03 \o/
<LnL> it 2.0 in nixpkgs-unstable yet?
<fpletz> LnL: yeah!
<fpletz> oh, nixpkgs… not sure, but probably
<fpletz> it is in nixos-unstable :)
<LnL> let me check again if I can create a new image
<Profpatsch> I’m on 2.0!
<Profpatsch> *party*
<Profpatsch> > man nix
<Profpatsch> No manual entry for nix
<sonarpulse> Profpatsch: I was thinking the same
<Profpatsch> man nix build links to the nix-build manpage.
<Profpatsch> Sonarpulse: But what should be in the manpage?
<Profpatsch> just typing nix returns an alphabetically sorted list of all commends.
<Profpatsch> *ands
<Profpatsch> So maybe the manpage can group them a bit more?
<Profpatsch> For full documentation, run 'man nix' or 'man nix-<COMMAND>'.
<Profpatsch> hehe
<sonarpulse> Profpatsch: oh I didn't know it worked with spaces
<sonarpulse> c.f. git manpages
<sonarpulse> also c.f. `man git`
<Profpatsch> Sonarpulse: That seems to be a man feature.
<Profpatsch> With docker it works as well, but only one level deep.
<Profpatsch> man docker container works, but man docker container inspect fails
<sonarpulse> lol
<sonarpulse> lazy docker
<samueldr> isn't that like `man 5 something`?
<Profpatsch> IP works for
<Profpatsch> ip a, ip ad, ip addr, ip address …
<Profpatsch> Interesting.
<Profpatsch> So it must be program-directed
<samueldr> hmmm, for `ip addr` I see "No manual entry for addr"
<samueldr> though, it loads the manpage for `ip`
<Profpatsch> Ah, I didn’t look close enough.
<Profpatsch> So it seems to be a man feature after all.
<samueldr> though, it seems to work with git and docker
* samueldr is interested
<samueldr> I've been working off and on (mostly off) on a manpage thing for nix
<samueldr> By default, man will try to interpret pairs of manual page names given on the command line as equivalent to a single manual page name containing a hyphen or an underscore. This supports the common pattern of programs that implement a number of subcommands, allowing them to provide manual pages for each that can be accessed using similar syntax as would be used to invoke the subcommands themselves. For example:
<Profpatsch> samueldr: ^
<dtz> LnL: if you do revisit that docker container, consider installing things like 'gzip' and such so it can unpack channels and such :)
<LnL> euh, nix-channel works doesn't it?
<fpletz> vcunat: regarding backporting stuff to the release-18.03 branch: globin and me maintained a release-review branch where we pushed the state of master we reviewed and backported if needed
<fpletz> do you want to do the same to share the workload or go through all the commits? :)
<vcunat> Share it :-)
<vcunat> Probably the same workflow, if it seemed good to you.
<vcunat> At least from the start, and we'll see.
<fpletz> worked well for me, open for suggestions though… the branch is basically a marker
<vcunat> Yes, it sounded OK.
<dtz> oh pointing at a URL doesn't, like nix-env -f https://github.com/NixOS/nixpkgs/archive/master.tar.gz -iA nixUnstable ... that needs gzip/gnutar I think.
<LnL> ah, the nixos channels use xz
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
goibhniu has quit [Ping timeout: 240 seconds]
goibhniu has joined #nixos-dev
ma27 has quit [Ping timeout: 265 seconds]
<Profpatsch> So, how do we get the http:// -> https:// issue merged? https://github.com/NixOS/nixpkgs/pull/30906
<gchristensen> how about doing 10 at a time
<Profpatsch> We really need a linter that does stuff like test the rewrite to https and propose that.
<Profpatsch> nix build --lint hello
<Profpatsch> > you are missing a license
<gchristensen> like nixpkgs-lint
<Profpatsch> > The homepage can also be reached by https
<Profpatsch> > it looks like you produce docs. please add a "man" output and a "doc" output
<Profpatsch> > Your "doc" output references "out" in this file:
<Profpatsch> That’s only from the top of my head. :)
<Profpatsch> nixpkgs-lint is very arcane. It uses the package name for example, and tries to work on all of nixpkgs by default.
<gchristensen> `like `
<Profpatsch> Which probably was a good idea when nixpkgs still had a few hundred derivations. :)
<symphorien> This could go into nox-review
<Profpatsch> symphorien: Hm, I’d suggest a separate tool that can be integrated into nox.
<Profpatsch> But yeah, something like that.
<Profpatsch> So much to do, so little time.
<vcunat> yeah :-)
MichaelRaskin has joined #nixos-dev
<sonarpulse> shlevy: said this in nixos-aarch64 but you are not there
<sonarpulse> I started looking at https://github.com/NixOS/nixpkgs/pull/34444, and tl;dr there is misc rebuilds that I think are best fixed by starting to do the lib.optionalDep thing
<sonarpulse> shlevy: also pkgs/development/interpreters/guile/1.8.nix is unchanged?
<sonarpulse> it is the last selfNativeBuildInput
<shlevy> Sonarpulse: Should I join that channel?
<shlevy> I don't have any aarch64 :D
<sonarpulse> shlevy: well, I separately wonder if we are leaning towards too many channels
<shlevy> :D
<sonarpulse> when cross-cutting stuff like that comes up a lot
<shlevy> Yeah. I think #nixos-dev is fine
<sonarpulse> (I was responding in there, would definitely start the discussion here)
<shlevy> Anyway, I want to write up my ideas for the interface of the new clean cross-compilation interface, which includes the optionalDep thing
<shlevy> But it's kind of orthogonal to what we do on the existing infra,if you want to get something in soon
<shlevy> (AFK for a bit, will see when I get back)
MichaelRaskin has quit [Ping timeout: 248 seconds]
<sonarpulse> shlevy: also, sorry, but I'd like to get rid of stdenv.isCross for now
<sonarpulse> I think it too vague
<sonarpulse> I noticed in guile you use it for native guile
<sonarpulse> but if native guile is depsBuildBuild, would we not also need it when build == host != target?
vcunat has quit [Quit: Leaving.]
pxc has quit [Ping timeout: 268 seconds]
Guest77574 has joined #nixos-dev
Guest77574 has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
symphorien has left #nixos-dev ["WeeChat 1.9.1"]
<sonarpulse> shlevy: why is libtool a buildInput for guile?
<sonarpulse> oh nevermind the dynamic linking library
pxc has joined #nixos-dev
lopsided98 has quit [Remote host closed the connection]
pxc has quit [Ping timeout: 248 seconds]
lopsided98 has joined #nixos-dev
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-dev
pxc has joined #nixos-dev
sonarpulse has quit [Ping timeout: 260 seconds]
<shlevy> Mic92: Do you know if the systemd fix will make it into 18.03?
<Mic92> shlevy: it is already in master
<Mic92> 88530e02b6fa9b5429dc09972b599e7b0a3af569
<shlevy> Ah nice