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
<angerman> how do I idiomatically replace my `Cabal` with a custom source checkout for my haskellPackages, such that they all use the custom `Cabal` instead of the `Cabal_A_B_C_D` we have in haskellPackages?
<Sonarpulse_> angerman: for Setup.hs?
<Sonarpulse_> this is currently not too easy
<Sonarpulse_> because setup depends aren't yet handled properly
<angerman> yea...
<Sonarpulse_> especially for cross
<angerman> I don't mind having it globally
<Sonarpulse_> angerman: I was litterally helping a coworker with this for android haha
<Sonarpulse_> what's your timeframe?
<angerman> So I was thinking about adding some Cabal_HEAD package to hackage-packages.nix,
<angerman> Sonarpulse_: today?
<angerman> :D
<Sonarpulse_> yes
<angerman> today (just started)
<Sonarpulse_> and before
<Sonarpulse_> angerman: ok I
<angerman> Sonarpulse_: but, re android, all the necessary stuff should be in the 2.2 release branch I believe.
<Sonarpulse_> angerman: cool!
<Sonarpulse_> we were having trouble with old cabal
<Sonarpulse_> geting os(android) to work
<Sonarpulse_> hopefully that just goes away
<angerman> Sonarpulse_: if you have some rough stuff you can dump somewhere, I'll pick up the pieces.
<Sonarpulse_> angerman: yeah
<Sonarpulse_> I'm about to go
<Sonarpulse_> but I'll get you that
<angerman> Sonarpulse_: I'm curretly fixing up some more places, making mingw32 work
<Sonarpulse_> angerman: I've heard; nice!
<angerman> Sonarpulse_: so we got iOS, Android and Windows cross compilation.
<Sonarpulse_> :D
<Sonarpulse_> how's the nix mingw32 stuff working?
<angerman> got nix to almost do win32 hello-world, excepft for some rather idiotic assumptions in cabal, that fileextensions are dependend on the `buildOS` m(
<angerman> (hence I need a custom Cabal)
<angerman> Sonarpulse_: well, I needed to bump mingw32 to 5.0.3
<Sonarpulse_> angerman: wooo!
<angerman> as that contains _(un)lock_file, which 4.0.6 (which nix unstable has) is required by ghc.
<angerman> so yea, except for the `Setup install` phase, I'm pretty much done.
<Sonarpulse_> awesome!
<angerman> I wanted to iron out that today, and then start upstreaming stuff.
<Sonarpulse_> what makes me especially happy is
<Sonarpulse_> I worked a little bit unbreaking mingw stuff
<Sonarpulse_> and a lot on ghc stuff
<Sonarpulse_> in nixpkgs
<Sonarpulse_> but if it wasn't too shitty where you started
<Sonarpulse_> that combination of those is completely accidental :)
<angerman> Sonarpulse_: thus, if you can help me out with the custom Cabal, I'd be quite happy.
<Sonarpulse_> yeah
<Sonarpulse_> gettting link
<angerman> Yea there were still a few bumps, mostly incorrect `asserts`.
<angerman> and figureing out that mingw issue was ... well I ended up comparing symbols from the lirbaries I had to those that nix built ;-0
<Sonarpulse_> haha
<Sonarpulse_> angerman: ok so anyways
<Sonarpulse_> you want to override mkDerivation (not the stdenv one but the haskell one, ug shadowing)
<Sonarpulse_> to add a setup dependency for Cabal across the board
<Sonarpulse_> so it doesn't just use the one that comes with ghc
<Sonarpulse_> (implicit deps are the worst!)
<Sonarpulse_> Cabal itself should from from buildHaskellPackages
<Sonarpulse_> cause you want native Cabal, of course
<Sonarpulse_> finally generic-builder needs to be expanded a big (yuck) so it sets up a separate package db for setup haskell depends for Setup.hs compilation
<Sonarpulse_> that is what I am getting link for
<Sonarpulse_> need to cherry-pick that a bit
<Sonarpulse_> lmk when you clean that up for upstreaming, as shlevy and I want to more generally clean up how haskell deps work in generic-builder
<Sonarpulse_> ok g2g
<Sonarpulse_> hope that helps!
Sonarpulse_ has quit [Ping timeout: 240 seconds]
<angerman> Thanks! Will give it a try
<dtz> Sonarpulse_: err at https://ste.la/ I see talks "homotopy type theory" "parallel programming in haskell" and "haskell in your pocket" -- is one of those the cross talk?
* dtz guesses "in your pocket"
mbrgm has quit [Ping timeout: 240 seconds]
mbrgm has joined #nixos-dev
jtojnar has left #nixos-dev [#nixos-dev]
jtojnar has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
<shlevy> bgamari-: around?
jtojnar has joined #nixos-dev
<bgamari-> shlevy, yep
<shlevy> bgamari-: Did you see we have perl cross-compilation on master?
<shlevy> bgamari-: (also fixed the gcc-6 segfault issue)
<bgamari-> oh wow
<shlevy> I'm curious how to use it to build cross-modules though
<bgamari-> shlevy, based on my expression?
<bgamari-> shlevy, that's a good question :)
<shlevy> It uses arsv's thing but looks independent
<bgamari-> shlevy, perl is a bit of a nightmare
<shlevy> Well you must have figured it out because switch-to-configuration.pl needs them :D
<bgamari-> shlevy, which module does it depend upon?
<shlevy> Oh, wait, it is your work :D
<bgamari-> shlevy, frankly I suspect this is one place where I'm relying on binfmt
<shlevy> :(
<shlevy> OK
<shlevy> Well
<bgamari-> to be honest I'm not particularly hopeful that cross-compiling perl modules will be general in possible
<bgamari-> ahem, possible in general
<shlevy> I will try to see if I can make https://arsv.github.io/perl-cross/modules.html workable
<shlevy> Yeah, I have binfmt-misc set up but because I'm in the sandbox my interpreter isn't availbale
<bgamari-> shlevy, right
<bgamari-> shlevy, that's the best documentation on the matter I know of
jtojnar has left #nixos-dev [#nixos-dev]
<sorear> ( Is running native tools in qemu-system-whatever more or less frowned on than using binfmt_misc? )
<shlevy> sorear: Much less, both because it's much more likely to be faithful and, more importantly, it doesn't break reproducibility
<shlevy> Note we're talking about using binfmt to build a "cross-compiled" version of something that runs host binaries
<bgamari-> that being said, it doesn't work if the process needs to call a subprocess
<shlevy> *not* the same as using it to build a "native" version for the emulated host
<shlevy> bgamari-: Really? I've got that working outside of nix.
<shlevy> sorear: It would be different if we explicitly called qemu-user. That'd be fine from Nix's perspective, since it would get incorporated into the hash of the build
<bgamari-> shlevy, if I have a host program which wants to call another host process, then the only option I know of is to binfmt, no?
yegortim1 has quit [Ping timeout: 255 seconds]
yegortim1 has joined #nixos-dev
<sorear> hmm
<shlevy> bgamari-: Yes, but I thought you meant binfmt doesn't work for that
<shlevy> sorear: You can make a colorable argument that binfmt-misc is effectively like a kernel extension
<bgamari-> shlevy, sounds like we are in violent agreement :)
<shlevy> sorear: I think there'd be room for nix to have a notion of "this system has these interpreters installed" which would then become part of the derivation hash like the "system" strin gis
<sorear> would be much easier if binfmt_misc belonged to a namespace.
<shlevy> Yeah. Though I'd still want to make cross-builds not depend on it where possible :)
orivej has quit [Ping timeout: 256 seconds]
<shlevy> bgamari-: Should we be installing miniperl with our cross perl?
<angerman> why don't we have a cabal-builder.nix?
<shlevy> What would that be?
<angerman> why do we rely on `Setup.hs`? (Apart from the fact that building cabal would need to still be done via bootstrapping)
<shlevy> Isn't it a porcelain vs plumbing thing?
<bgamari-> relying on Setup.hs seems like the right thing for nix to be honest
<angerman> I guess this will become interesting when cabal drops old-build.
<angerman> Well, I'll try to work with Sonarpulse's initial setupDepends stuff for now, to pin Cabal versions for packages.
<angerman> Using `Setup.hs` with cross compilation might result in some tricky corner cases. Those packages that use custom `Setup.hs` to do system probing might end up with the wrong values, as the `Setup.hs` is run on the build instead of the host.
<bgamari-> angerman, but that is a problem regardless of whether you use Setup.hs
<bgamari-> angerman, since cabal might invoke a custom setup
<angerman> ha, guess why I'm trying to root out build-type: Custom :-)
<bgamari-> sure, in which case you won't see any cases with custom Setup.hs
<bgamari-> Setup.hs is otherwise just a wrapper around Cabal's defaultMain
<bgamari-> so it should be no less correct using Setup.hs than cabal-install
<angerman> right. I'll try to bump inject some Cabal, so we can use non-stock Cabal releases when building packages.
garbas has quit [Quit: WeeChat 1.9.1]
jtojnar has joined #nixos-dev
yegortim1 has quit [Remote host closed the connection]
yegortim1 has joined #nixos-dev
<clever> bgamari-: i just noticed, proof supports emulating binfmt_misc
<clever> bgamari-: in theory,that will allow you to run arm binaries on x86 in a pure manner, without relying on special host config
<clever> bgamari-: so cross-compiling can test things for the target more easily
<bgamari-> clever, proof?
<clever> bgamari-: proot
<clever> also, i made the exact same typo when trying to pull proot up in nixpkgs just now, lol
<bgamari-> ahh
<clever> i think its LD_PRELOAD based
bgamari- has left #nixos-dev ["Leaving"]
bgamari- has joined #nixos-dev
<bgamari-> lovely
<clever> i think its LD_PRELOAD based
<bgamari-> I suppose that makes sense
<clever> so the binfmt_misc would pre-open a binary in the parent, inspect the types, and then optionally prefix argv with an extra binary
<clever> proot*
<bgamari-> right
<bgamari-> that's good to know
<angerman> hmm... I guess all of `setupHaskellDepends` would need to be automatically lifted into buildPackages. I fear we can't do that trivially though.
pie_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
goibhniu1 has joined #nixos-dev
goibhniu has quit [Ping timeout: 256 seconds]
garbas has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
pie_ has joined #nixos-dev
pie_ has quit [Ping timeout: 248 seconds]
__Sander__ has joined #nixos-dev
pie_ has joined #nixos-dev
<shlevy> Hmm... A lot of places that use targetPlatform != buildPlatform probably want hostPlatform != buildPlatform
<manveru> now that we have fetchGit, would it make sense to add human-readable tags to nixpkgs-channels?
<manveru> something like a timestamp at least would make my nix shells way nicer :)
<shlevy> manveru: +1
<shlevy> niksnut: ^^
ma27 has joined #nixos-dev
<niksnut> human-readable tags?
<manveru> well, right now i can do `fetchGit {url = https://github.com/NixOS/nixpkgs-channels; ref = "098c7f3d945c36f6eb57f41aeed9638e2561ad18";}`
<manveru> but something like `fetchGit {url = https://github.com/NixOS/nixpkgs-channels; ref = "2018.02.28:12:05";}` would be nicer :)
<aminechikhaoui> you'll have to lookup the tag still, no ?
<manveru> sure
<aminechikhaoui> which is the same as looking up the revision :D
<aminechikhaoui> oh but maybe useful to know how old is the channel
<manveru> but you don't have to check how old your revision is later
<aminechikhaoui> right got you
<Mic92> Should we enforce maintainers to be set for new packages?
<Mic92> Maybe excluding those packages that are added automatically or to fix other packages (often the case in python)
<sphalerite_> I'm in favour!
<niksnut> well, using a hash is also better because it works in pure evaluation mode
<niksnut> very recognizable :-)
<niksnut> "default.nix" was probably not a good idea
<sphalerite_> I think it's a good idea overall, just not using it for packages that have no other files in nixpkgs
<Mic92> too late to change
<shlevy> niksnut: What would you rather?
<shlevy> pkgs/applications/misc/hello/hello.nix?
<niksnut> or pkgs/applications/misc/hello.nix
<niksnut> or pkgs/hello.nix
<niksnut> would be more editor-friendly
<Mic92> at the moment I use fd to find the right file
<Mic92> maybe I will use nix edit in future, but it also helps me to find nixos tests and modules.
ma27 has quit [Ping timeout: 245 seconds]
jtojnar has joined #nixos-dev
ma27 has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
infinisil has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
infinisil has joined #nixos-dev
infinisil has quit [Client Quit]
infinisil has joined #nixos-dev
infinisil has quit [Client Quit]
infinisil has joined #nixos-dev
<angerman> shlevy: re: host != build, yes!
<shlevy> angerman: I think the existing situation comes from people cargo-culting Sonarpulse, who does enough work on cross-compilers themselves that that's the right check
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
Sonarpulse_ has joined #nixos-dev
<Sonarpulse_> angerman: how did it go?
yegortim1 has quit [Remote host closed the connection]
yegortim1 has joined #nixos-dev
<shlevy> Sonarpulse_: <shlevy> [05:33:39] Hmm... A lot of places that use targetPlatform != buildPlatform probably want hostPlatform != buildPlatform
<shlevy> That would reduce a lot of the pointless rebuilds in nativeBuildInputs vs depsBuildBuild I think
<Sonarpulse_> shlevy: let me go take a look
<Sonarpulse_> early on i did that for some gcc things
<shlevy> Oh, not in the cross-compilers themselves :)
genesis has joined #nixos-dev
<shlevy> I mean for things like autogen
<Sonarpulse_> oh
<Sonarpulse_> before i figured out that "non-adjacent" comparisons are very very rarely needed
<sorear> ( is the system already smart enough to know that most non-gcc derivations don't depend on the target? )
<shlevy> That don't care about targets but do care about cross-compilation because they need to run themselves during their build
<Sonarpulse_> (adjacent given the "build < host < target" ordering)
<Sonarpulse_> sorear: yes
<shlevy> sorear: Yeah, and we're working on a better interface to make it even more so.
<shlevy> BTW I think I've got perl modules cross-building...
<shlevy> It's not the prettiest thing ever :D
<sorear> do CPAN and EUMM even have a concept of cross builds?
<Sonarpulse_> heheheh
<shlevy> Basically we take the miniperl built during the cross-build of perl itself and use it to run Makefile.pl
<Sonarpulse_> shlevy: can one just use full native perl?
<shlevy> Sonarpulse_: Possibly, but I assume we don't use full native perl for perl-cross for a reason
<shlevy> Actually, definitely not naively
<sorear> what are the advantages of perl-cross over qemu?
<shlevy> Because we need e.g. Config.pm from cross
<Sonarpulse_> shlevy: I know very little about perl
<Sonarpulse_> but I assume this is analogous to Setup.hs?
<shlevy> Sonarpulse_: Config.pm is basically "this is info about the perl install"
<shlevy> So we don't want the one from the native build
<shlevy> miniperl knows how to handle that. Not sure if native perl does.
<Sonarpulse_> oh ok
<Sonarpulse_> shlevy: Makefile.pl uses Config.pl ?
<shlevy> Yeah
<Sonarpulse_> ok
<shlevy> Probably we could do something with just a native perl and the right settings/INC
<Sonarpulse_> ew
<Sonarpulse_> well whatever
<shlevy> But miniperl is already there, so...
<Sonarpulse_> yeah
<Sonarpulse_> we can't be much wiser than upstream
<Sonarpulse_> hahah
<shlevy> sorear: It has the general benefits of cross-compilation vs emulated compilation, plus the additional benefits that if we get it working it's much easier to build an emulated compilation VM since we can just cross-build NixOS :)
<sorear> perl modules are like C libraries: there's a general agreement that perl Makefile.PL; make; make install will compile any necessary compiled parts and put a working module in your system Perl directory, but the implementation details have been reinvented fifty times
<shlevy> sorear: Basically I switched to this path when I realized I was reinventing core bits of NixOS in a terrible way to get my systemd+ssh system up
<shlevy> And we want cross-nixos anyway, for targets that are too slow to build native
<shlevy> (I don't know yet whether the HiFive will qualify :) )
<sorear> qemu has room to be made two or three times faster, if you want an even deeper rabbithole
<shlevy> :)
alunduil_ has joined #nixos-dev
niksnut_ has joined #nixos-dev
Willi_Butz has joined #nixos-dev
TonyTheLion_ has joined #nixos-dev
<sorear> (also, commercial alternatives that are WAY ahead)
<TonyTheLion_> trying to build nix for arm yields a 'configure: error: curl is required' error.
<TonyTheLion_> is anyone here qualified to advise?
<gchristensen> TonyTheLion_: #nixos and #nixos-aarch64 might be better places
<TonyTheLion_> I ran 'nix-build '<nixpkgs>' -A nix --arg crossSystem '(import <nixpkgs/lib>).systems.examples.armv7l-hf-multiplatform'
<TonyTheLion_> gchristensen: ok
<TonyTheLion_> I'll try there
<TonyTheLion_> thanks :)
<gchristensen> (even though it isn't aarch64, pretty much everyone inthe aarch64 room know things about things)
<gchristensen> yep!
mbrgm_ has joined #nixos-dev
mbrgm has quit [*.net *.split]
alunduil has quit [*.net *.split]
rsa has quit [*.net *.split]
WilliButz has quit [*.net *.split]
alp has quit [*.net *.split]
niksnut has quit [*.net *.split]
lassulus has quit [*.net *.split]
mbrgm_ is now known as mbrgm
<shlevy> \o/ cross-built all perl modules needed by NixOS
alp has joined #nixos-dev
<shlevy> TonyTheLion_: I think you need nixUnstable
<shlevy> I don't think anyone tried to get 1.11 built on cross
<TonyTheLion_> and how do I specify that?
<shlevy> -A nixUnstable instead of -A nix
<TonyTheLion_> cool
<sorear> once nixos is using nix 2.0, will it still need perl?
<shlevy> No, the perl it needs is for some scripts
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
lassulus has joined #nixos-dev
lassulus has joined #nixos-dev
lassulus has quit [Changing host]
rsa has joined #nixos-dev
<dtz> yeah, cross-build Nix 2 works, nevermind 1.11 :)
<dtz> re:cross-built perl modules yeah that's a problem I'd be happy to see solved... by someone else... :D
<shlevy> dtz: It's solved :P
<shlevy> I'm writing the docs now
<shlevy> Well, solved hackily, but no more hackily than cross-perl itself :)
<TonyTheLion_> Error running link command: No such file or directory
<TonyTheLion_> oh boy
<dtz> ** champagne **
<TonyTheLion_> does this build require me to install gcc or something in nix?
<dtz> for python things are much better with python3 to the point I just gave up on fixing python2 lol
<dtz> but since that's the default that can be a bit of a blocker for some things IIRC
<TonyTheLion_> [ 1%] Building C object CMakeFiles/brotlicommon-static.dir/c/common/dictionary.c.o [ 3%] Linking C static library libbrotlicommon-static.a Error running link command: No such file or directory
<TonyTheLion_> I don't see what link command its missing here...
<Sonarpulse_> shlevy: nice
<hedning[m]> Bash completion for Nix should work fairly well now.
<hedning[m]> Would it make sense for 18.03 to install it automatically when `programs.bash.enableCompletion` is enabled?
<Sonarpulse_> looking
<bgamari-> wow
<bgamari-> good work
<shlevy> the cross_perl thing is completely unique to us
<shlevy> But based on the cross-perl site no one else is doing cross-modules out of the perl build itself :)
<shlevy> I'm going to open an issue with perl-cross folks to upstream this
orivej has quit [Ping timeout: 240 seconds]
<shlevy> Hmm what's the possessive of nixpkgs? nixpkgs's?
<Sonarpulse_> shlevy: hehehe yeah i wonder that
<gchristensen> I typically do nixpkgs'
<Sonarpulse_> as it's sort of a fake plural
<copumpkin> genitive
<Sonarpulse_> i mean "nixpkgs" itself doesn't seem plural to me
<Sonarpulse_> there is no one nixpkg
<Sonarpulse_> which would point to nixpkgs's
<copumpkin> it's full of nixpkgs!
<Sonarpulse_> :D
<Sonarpulse_> "nixpkgs is a big pile of shit; vs nixpkgs are shit piles"
<shlevy> copumpkin: "also called the possessive case or second case" :P
<sphalerite_> I use nixpkgs's
<sphalerite_> or "of nixpkgs"
<Sonarpulse_> "of nixpkgs" nice dodge :D
<Sonarpulse_> but yeah nixpkgs's seems correct, and "of nixpkgs" a fine way to avoid the correct but awkward s's
<sphalerite_> I get it with my name. Linus's. Although I guess it's not as bad as with something that's derived from a plural
<sphalerite_> Or you could always use the full name, "the nix package collection". Right? :D
simpson has quit [Ping timeout: 256 seconds]
Mic92 has quit [Ping timeout: 256 seconds]
simpson has joined #nixos-dev
orivej has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
Mic92 has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
<Sonarpulse_> sphalerite_: two good points!
<dtz> btw how's that systemd fork fix going? :D
<Mic92> dtz: somebody needs to hit the merge button
<Mic92> I can't at the moment
<dtz> lol okay
<dtz> on it
<Mic92> I don't know all people who can merge this.
<Mic92> fpletz appearently
<gchristensen> fpletz domenkozar and eelco
<dtz> Mic92: oh I thought you meant the graalvm thing. Anyway, merged :)
<Mic92> dtz: :) sorry for putting preasure on you
<Mic92> but atleast it was tested in production before
<dtz> yeah and it's not like it changes anything someone uses today, so any unnoticed issues aren't regressions just missed opportunities :)
sphalerite is now known as sphalerit
sphalerite_ is now known as sphalerite
<shlevy> Damnit :D typo'd "LOCALE_ARCHIVE" as "LOCAL_ARCHIVE" :D
<dtz> LOL d'oh
vcunat has joined #nixos-dev
<shlevy> Such a dumb reason to rebuild glibc
<shlevy> dtz: Sonarpulse_: makeWrapper is broken, in a way I took advantage of in the perl cross work :)
<shlevy> It sets the shebang to $SHELL
<dtz> yeeeeep
pxc has joined #nixos-dev
ma27 has quit [Ping timeout: 245 seconds]
<Sonarpulse_> shlevy: saw hahah
<Sonarpulse_> patchShebangs has same problem
orivej has quit [Ping timeout: 240 seconds]
MichaelRaskin has joined #nixos-dev
disasm has quit [Quit: WeeChat 1.9.1]
FRidh2 has joined #nixos-dev
disasm has joined #nixos-dev
disasm has quit [Client Quit]
disasm has joined #nixos-dev
disasm has quit [Client Quit]
disasm has joined #nixos-dev
orivej has joined #nixos-dev
FRidh2 has quit [Quit: Konversation terminated!]
<dtz> new RFC? :D
<dtz> > :eyes:
<dtz> lol
* gchristensen is waiting on a final set of eyes on the doc prior to submission
<vcunat> Liked the 25 number so reserved it in advance? :-)
<MichaelRaskin> You could have at least revealed the title!
<LnL> yeah, what a teaser :)
<gchristensen> ;)
<gchristensen> it is public!
<dtz> \o
<dtz> \o/
<LnL> oh! I was expecting something else :D
<gchristensen> oh, what were you expecting? :)
<gchristensen> you could PM if you wanted hehe
<MichaelRaskin> So, the main author of the Nix Core Team RFC is not in the Nix Core Team as established by the RFC?
<gchristensen> correct
<genesis> what about derivation without maintainers, when we need update ?
<MichaelRaskin> puppeteer!
<shlevy> MichaelRaskin: Consensus-builder ;)
<shlevy> Hmm... Do the NixOS vm tests share a store?
<MichaelRaskin> I think so
yegortim1 has quit [Ping timeout: 255 seconds]
<shlevy> :D
<shlevy> No wonder my nix-ssh test wasn't working
orivej has quit [Ping timeout: 245 seconds]
<Mic92> they do share one, it is exposed through 9p
yegortim1 has joined #nixos-dev
<shlevy> OK
<MichaelRaskin> The RFC actually gives Nix* a chance to clean up processes without the fork/remerge. Nice.
<gchristensen> I'm so glad you think so, MichaelRaskin
<MichaelRaskin> You did hide the work well, though — I wouldn't say some (true and relevant in the context) things in the last two weeks if I had an idea something like that was being prepared.
<gchristensen> yes, it was tough, but important, to keep it quiet
<gchristensen> even in the face of your critique :)
<vcunat> Why was it important to keep it quiet?
<MichaelRaskin> Well, if you would privately say me «this is not as hopeless as you think, but I am not at liberty to say more» I would have believed you.
<vcunat> (Unless that's itself better kept quiet.)
<MichaelRaskin> Hard organisational changes are rarely made easier by too much wide participation
<MichaelRaskin> (I don't have any secret information, so _I_ can freely answer the question)
<MichaelRaskin> Basically, it is clear even from outside that a lot of work had to be done — apparently, mainly by gchristensen — to make sure the negotiations don't fall into a stage where some parties get defensive.
<vcunat> Hmm, right, there would be such risks, though it's hard for me to judge how significant.
<MichaelRaskin> Also, publically revealing details of negotiations that can later be completely rewritten is often a bad idea; but publically saying that negotiations exist without _any_ details leads to Wild Mass Guessing, which is not always healthy for the project in the period until neogtiations are complete.
<shlevy> It was helpful for me personally to be able to work through my concerns and questions privately
<shlevy> I'm hopeful that with a public ML and possibly IRC we can have fewer big reveals though :)
<shlevy> Moving forward, I mean
<MichaelRaskin> vcunat: and when nobody has made their minds completely, wide — and by necessity less qualified — participation in the discussion can create noise tha drowns the signal.
orivej has joined #nixos-dev
yegortim1 has quit [Remote host closed the connection]
yegortim1 has joined #nixos-dev
<MichaelRaskin> We-ell, that part I understand, it was more about the need of an external author for such an RFC (although in reality I do understand)
<gchristensen> :)
yegortim1 has quit [Remote host closed the connection]
yegortim1 has joined #nixos-dev
<Sonarpulse_> gchristensen definitely made the right call, everyone
<Sonarpulse_> re secrecy and things
Sonarpulse_ is now known as sonarpulse
<sonarpulse> I know nothing special either, just trust his judgement
<gchristensen> <3
orivej has quit [Ping timeout: 240 seconds]
<genesis> on gentoo , we have elog to let message to user what to do after install a piece of software, is it some plan about such feature ?
<shlevy> I don't know of a specific plan but I'd love to see a good design for that
<genesis> yep, need log backend.
<vcunat> I thought it served as a changelog, kind of.
<genesis> but sometime i donno how a derivation could be useful without telling people what to do next, so i'm a bit concerned. generate configuration on something like nixos is not as easy as other distrubution, and it's something i don't get yet.
<vcunat> (my Gentoo days are too far behind)
orivej has joined #nixos-dev
<genesis> it tells you what to do after a build, like setting this file, add user to such group ... it's not a gadget, and log system let you estimate build time etc
taktoa[c] has quit [Ping timeout: 256 seconds]
ocharles has quit [Ping timeout: 256 seconds]
jtojnar has quit [Quit: jtojnar]
vcunat has quit [Ping timeout: 248 seconds]
jtojnar has joined #nixos-dev
taktoa[c] has joined #nixos-dev
cbarrett has quit [Ping timeout: 256 seconds]
taktoa[c] has quit [Max SendQ exceeded]
ocharles has joined #nixos-dev
terrorjack has quit [Ping timeout: 256 seconds]
ghuntley has quit [Ping timeout: 256 seconds]
cbarrett has joined #nixos-dev
angerman has quit [Ping timeout: 240 seconds]
sorear has quit [Ping timeout: 256 seconds]
thoughtpolice has quit [Ping timeout: 276 seconds]
terrorjack has joined #nixos-dev
ghuntley has joined #nixos-dev
pauldub has quit [Ping timeout: 276 seconds]
sorear has joined #nixos-dev
ghuntley has quit [Max SendQ exceeded]
terrorjack has quit [Max SendQ exceeded]
taktoa[c] has joined #nixos-dev
thoughtpolice has joined #nixos-dev
gleber_ has quit [Ping timeout: 276 seconds]
angerman has joined #nixos-dev
thoughtpolice has quit [Max SendQ exceeded]
ocharles has quit [Ping timeout: 240 seconds]
angerman has quit [Max SendQ exceeded]
<samueldr> if there's configuration to do, AFAIUI there will usually be configuration options in the nixos module system, so I wouldn't e.g. install nginx, but configure nginx to run, with X,Y,Z options, and that then brings the necessary packages in
manveru has quit [Ping timeout: 256 seconds]
ghuntley has joined #nixos-dev
pauldub has joined #nixos-dev
angerman has joined #nixos-dev
angerman has quit [Max SendQ exceeded]
gleber_ has joined #nixos-dev
angerman has joined #nixos-dev
thoughtpolice has joined #nixos-dev
angerman has quit [Max SendQ exceeded]
terrorjack has joined #nixos-dev
genesis has quit [Ping timeout: 256 seconds]
angerman has joined #nixos-dev
angerman has quit [Max SendQ exceeded]
mbrock has quit [Ping timeout: 256 seconds]
terrorjack has quit [Max SendQ exceeded]
angerman has joined #nixos-dev
manveru has joined #nixos-dev
manveru has quit [Max SendQ exceeded]
mbrock has joined #nixos-dev
terrorjack has joined #nixos-dev
manveru has joined #nixos-dev
ocharles has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev