<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_>
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
<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
<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 :)
<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?
<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
<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?
* 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.
<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]
<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]