<Sonarpulse>
I threw out rust because only the C compiler, ghc doesn't reference it
<Sonarpulse>
so needs to be brought in seperate
<Sonarpulse>
s/only/unlike
<Sonarpulse>
oops
<shlevy>
Right, but if GHC had some native rust FFI support it would
<shlevy>
And if it doesn't (like it doesn't now) then you'd expect the packager of the package with weird rust ffi to care about it, yeah
<shlevy>
Though even then I'd epect the actual library would be built as a buildRustPackage or whatever
<Sonarpulse>
shlevy: right, thankfully ffi is ofen mainly a separate library / sepate derivation
<Sonarpulse>
shlevy: so I should get back to work in a second, but I'll definitely most something concurring that you've got a good point re the secondarily compiler
<Sonarpulse>
and the secondary compiler is the syntactically common case :)
<shlevy>
:D
<shlevy>
"you'll definitely most something concurring"
<Sonarpulse>
*post
<Sonarpulse>
not most
<shlevy>
Aaah OK
<shlevy>
Cool
<shlevy>
Then we can get to the fun part: bikeshedding
<Sonarpulse>
well before that
<Sonarpulse>
I am sort of apprehensive about changing nativeBuildInputs after ~200 cross package fixes
<Sonarpulse>
but
<Sonarpulse>
just do nothing
<Sonarpulse>
is lame argument
<Sonarpulse>
like bike in 2009 no xxx2nix
<shlevy>
Oh, we can talk about a transition path
<Sonarpulse>
so way less reason to keep silly buildInputs name around
<Sonarpulse>
also
<Sonarpulse>
the fact that we don't immediately agree on what the common depsBuild(* is
<Sonarpulse>
/ I am a bit buzzy on thinking about syntactic- for evaluation-weighted common case
<Sonarpulse>
makes me think that stdenv/setup should drop the legacy names
<Sonarpulse>
and just do somethhing completely consistent and explicit in both axes
<Sonarpulse>
and then stdenv.mkFullyGeneralDerivation
<Sonarpulse>
or whatever
<shlevy>
Yeah, that's fair. I think it's a consequence of you focusing on core infra while I focus on packages, but if we go with the consistent and coherent case we can add in nice shortcuts later
<Sonarpulse>
and then only the easy-peasy mkDerivation has the legacy names
<Sonarpulse>
shlevy: exactly, I like that division of labor with our focuses
<Sonarpulse>
so best don't let the legacy pollute the infra one way or the other
<Sonarpulse>
and then I can not care about the nativeBuildInputs bike shed :D
<shlevy>
:D
<Sonarpulse>
imma post something to that effect
<shlevy>
Yeah, the fact that gcc uses mkDerivation is kind of insane :D
<Sonarpulse>
feel free to....edit it even
<Sonarpulse>
yeah I want buildCPackage
<Sonarpulse>
screw this C-first bias
<shlevy>
+10000
<Sonarpulse>
damn C nativists hehehe
<shlevy>
By the way if Iever get around to writing a compiler I'm hiring you to keep me honest with respect to cross compilation
<Sonarpulse>
shlevy: :) will gladly do!
pxc has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
jtojnar_ is now known as jtojnar
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 260 seconds]
jtojnar_ is now known as jtojnar
orivej has joined #nixos-dev
mbrgm has quit [Ping timeout: 245 seconds]
mbrgm has joined #nixos-dev
pxc has quit [Ping timeout: 252 seconds]
Sonarpulse has quit [Ping timeout: 252 seconds]
taktoa has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
jtojnar_ has quit [Ping timeout: 276 seconds]
jtojnar_ has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
jtojnar_ has quit [Ping timeout: 276 seconds]
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
pxc has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
jtojnar2 has joined #nixos-dev
Lisanna has joined #nixos-dev
pie_ has quit [Ping timeout: 265 seconds]
FRidh2 has joined #nixos-dev
pie_ has joined #nixos-dev
adisbladis has joined #nixos-dev
adisbladis has quit [Changing host]
adisbladis has joined #nixos-dev
ckauhaus has joined #nixos-dev
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #nixos-dev
<Mic92>
yesterday we had 6xx something pull requests. Today there are 740 pull requests ...
<FRidh2>
yep, 5 pages of semi-automatically created PR's
<Mic92>
now I need automation to close them.
<Mic92>
but actually it would be better, if the guy open the pr would also test them
<makefu>
maybe also have a bot similar to the rust bot which merges and closes PRs :)
<FRidh2>
most of them have been checked by borg
<FRidh2>
yes, the merge bot that was proposed earlier would be good here.
<makefu>
yes, now up the game and have borg close them :D
<FRidh2>
if n_builds < 10 and all build, merge?
<makefu>
if 2 approvals and builds pass -> merge
pie_ has quit [Ping timeout: 248 seconds]
<makefu>
that way at least somebody sanity-checked the diff
<makefu>
or 1 approval
<Mic92>
I would be also ok, if I manually instruct borg to merge the pr after evaluation succeed
chaker has joined #nixos-dev
chaker` has joined #nixos-dev
chaker has quit [Ping timeout: 240 seconds]
pie_ has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
<Mic92>
maybe there could a system, where people adopt automatically generated updates.
<FRidh2>
I've only used the borg builds to determine whether to merge or not
<Profpatsch>
Libraries that need to be update in lockstep.
<Profpatsch>
And that 2.0.0->2.1.0
<Profpatsch>
*that’s
<Profpatsch>
So yeah, updating stuff is fine, but also work that can’t be trivially automated.
<gchristensen>
I can understand your reasoning for being so critical, I'm just not sure most of these updates are any different than standard updates we get. I can't pretend that when I did security patching it was carefully tested or intentionally artisinally selecting and validating versions most of the time... So I suspect most of these updates are good. When I saw them come in I was a bit upset too,but mostly I think
<gchristensen>
because I was scared about having to merge them. I think Ryan is trying to do the right thing and is open to (comstructive)feedback
<Profpatsch>
We direly need a set of well-maintained core-packages and give stronger guarantees for that subset.
<FRidh2>
most of it is part of the long tail, that is, it hardly causes any rebuilds and mostly is just relatively a lot of work for nixpkgs members. I think for those packages the best approach is typically try and see whether it fails.
<gchristensen>
So many of the updates were like "oh this maintainer hasn't even considered this package since 2014"
pie_ has joined #nixos-dev
<gchristensen>
I agree fridh2. I can probably do some work on that today to aurobuild if less than ten
<Profpatsch>
In that case, there’s two kinds of users. The ones that just use it and don’t really care, they just want it working (which it does on the current version).
<Profpatsch>
And the ones which would like to have guarantees about support, which currently we don’t give.
<FRidh2>
Right
<Profpatsch>
So (semi-)automatic updating basically breaks both contracts with the users.
<LnL>
I think getting a 10x increase in merge requests makes the pain points of the current process very clear, regardless it if the changes could have been tested better beforehand
<FRidh2>
which is why it is good I think if we don't do these kind of updates to often
<gchristensen>
That doesn't work when your library has remove code execution vulns
<gchristensen>
I agree lnl
<Profpatsch>
Especially since these updates will go into 18.03
<FRidh2>
with python packages on unstable I intend to do the major/minor updates only every month in the future
<Profpatsch>
Security fixes only work if the package is either 1) supported by the distribution or 2) there’s a user that is interested in following vulnerabilities in getting them upstream.
orivej has joined #nixos-dev
<Profpatsch>
And of course they are normally done with patch-releases, which I’m totally pro automatically merge.
<gchristensen>
Is this proposed policy?
<Profpatsch>
So 1.5.3->1.5.4 totally fine.
<FRidh2>
should write an rfc about these things
<gchristensen>
There is no normal for security patches heh
<Profpatsch>
1.5.3->1.6.0 nope, not really
<Profpatsch>
0.0.2->0.0.3 <- probably breaking, that one.
<Profpatsch>
What I do like is pinging the maintainers.
<adisbladis>
Which sadly in my experience does not work so well.
<Profpatsch>
Man, I really need to get my time investments straight, but I’d really like to get this thing here going:
<Profpatsch>
First step is to collect a list of core packages.
<Profpatsch>
And then somehow softly enforce they are well-maintained.
<FRidh2>
and then add these levels as a meta field?
<FRidh2>
have hydra jobs for them
<LnL>
packages are upgraded on master all the time and not just minor version bumps
<LnL>
the number of things handled otherwise is very small
<Profpatsch>
For core packages new versions should automatically open an issue and ping the maintainers, for example.
<Profpatsch>
And there should be a checklist, like on planes before liftoff.
<Profpatsch>
Maybe Debian watch scripts can be reused, or we push it upstream and ensure repology always works for these packages.
<Profpatsch>
The core-packagelist should also be under version control.
<Profpatsch>
And always checked against stuff like the minimal nixos closure.
<Profpatsch>
Stuff like that.
<Profpatsch>
Ideas are for free *sigh*
<Mic92>
Do we really behind updates for core packages?
<Profpatsch>
Do we have a list of core packages?
<Profpatsch>
Hard to answer that without a metric. :)
<FRidh2>
nixos-small
<Mic92>
A metric is how, many ancestors a package it has
<LnL>
depends on what you think of core packages, but with the rebuild labels it's pretty clear what to be careful with
romildo has joined #nixos-dev
romildo has quit [Client Quit]
<gchristensen>
And it doesn't matter because beyond a couple packages like gcc we do mahor bumps all the time without too much fuss
<Profpatsch>
gchristensen: Of course gcc can’t silently break.
<Profpatsch>
Because it’s used by so much if it goes, it goes out with a bang and is reverted in a manner of hours or even minutes.
<Profpatsch>
ofborg really does a lot to help with that.
<Profpatsch>
For strongly typed languages, even building is a pretty strong guarantee.
<gchristensen>
You missed my point: we routinely update packages of all sorts with little study fanfare or problem
<Profpatsch>
Maybe I’m too conservative.
<adisbladis>
I think what Profpatsch proposed in terms of version numbers would be sensible for an auto-merge bot.
<LnL>
for an active release I totally agree, but we handle that differently
<adisbladis>
Auto-merging should be a tad conservative
<gchristensen>
Agreed
<FRidh2>
Semver is a good assumption I think, and thus automating merging of patch releases is a good idea.
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
<gchristensen>
I take it back I'm not ok with unreviewed auto merging, but yes on "lgtm merge when build and eval passes"
<LnL>
yeah, auto merging is a different story
<gchristensen>
Yeah
<FRidh2>
auto-merging patch updates of packages that cause < 10 rebuilds and all build?
<gchristensen>
Maybe if you put a magic word in the body of the pr
<LnL>
my main concern there is the quality of the changes
<LnL>
unless it's only the hashes somebody should probably look at it
<gchristensen>
Magic word and a trusted user maybe
<FRidh2>
Patch updates should not need any modifications. If they do, upstream is not following semver, or its because of patches at our side.
<LnL>
yeah
<LnL>
good point :)
<FRidh2>
the former we could catch with a meta attribute (allowAutoMerge=false;)
__Sander__ has joined #nixos-dev
<gchristensen>
I just think it is bad if the bot does unwanted things
goibhniu has quit [Ping timeout: 240 seconds]
<gchristensen>
but this is far and away
<gchristensen>
the right-now problem is what is the simplest thing I can do to help today? maybe auto-schedule all jobs for <=10 is an option
<LnL>
that's probably the most logical first step
<gchristensen>
one reason I really liked the more clever one w.r.t. the package name, is it pushes good commit messages :)
<FRidh2>
Would it make more sense to build all packages of a relatively unimportant package, or build a statistically significant portion of relatively important packages?
pie_ has quit [Ping timeout: 240 seconds]
<gchristensen>
where importance is inferred from the rebuild #?
<FRidh2>
yes
<gchristensen>
I'm about to be stepping out for a meeting.
<gchristensen>
Profpatsch: patreon allows contributions starting at $1 ... :):
<Profpatsch>
gchristensen: But that’s only infrastructure. If I had the money, I’d love to pay you for your time, which is the thing that really matters.
<gchristensen>
oh! fair enough :)
<Profpatsch>
I can maybe pay for half an hour of your time per month tho. d)
<gchristensen>
I appreciate the sentiment, honestly I'm building this for the love of the community
<Profpatsch>
We really need to get that post-scarcity society thing going.
<Profpatsch>
gchristensen: Is Inodes Free actually Inodes Used? Or did you do a garbage collect?
<gchristensen>
it is inodes free
<Profpatsch>
Ah, so --optimize or --gc
<gchristensen>
yeah, I pushed out a more regular GC to handle the influx
<Profpatsch>
Right, it corresponds to the disk free increase m(
<gchristensen>
the red hatchmarks is an alert that there are no linux builders, which correlates to the "build workers by architecture" graph
<Profpatsch>
This gives me the Settlers II feeling. xD
<gchristensen>
what was because the autoscaling on linux would see >X jobs and spawn 10 ... then blow through them all and shut down :D
<shlevy>
niksnut: gchristensen: ofborg and/or hydra need an "insert your credit card here and spin up some builders allocated just for your jobset/PR" button
<Profpatsch>
holy grail of microtransactions.
<gchristensen>
ooh I like it
chaker` has quit [Remote host closed the connection]
<Profpatsch>
Why do I need to pay $2 VAT for $10 of monthly recurring payments. :'(
<gchristensen>
shlevy: excuse me while I figure out how to do that ;)
<Profpatsch>
Ah, VAT is Umsatzsteuer. I feel like if this were b2b it wouldn’t apply.
<shlevy>
@ofborg allocate 10 c5.18xlarge from @shlevy
<Profpatsch>
shlevy: Have you *seen* those AWS bills gone wild?
<gchristensen>
according to AWS' pricing page, they're $0.00/hr
<shlevy>
I mean, I'm going to keep with this RISC-V stuff but my primary interest in cross is in how it makes our *normal* packaging better
<shlevy>
E.g. stdenv bootstrapping is just a special case of cross, and we can (and IIRC already have to some extent) express our bootstrapping much better in the general language
<Sonarpulse>
yes!
<Sonarpulse>
no more manually separating things into stages
<Sonarpulse>
can bootstrapped tools can just be statically linked (with musl haha) executables
<shlevy>
And things like "don't put buildInputs into path, don't put nativeBuildInputs into linker path" will clean things up for native
<Sonarpulse>
yes
<Sonarpulse>
there is a specific back compat commit of mine
<Sonarpulse>
I need to write a RFC to revert
<gchristensen>
something I've said before, and will continue to say forever: I'm so glad to work with a team of people who are so damn smart
<Sonarpulse>
<3 likewise
<Sonarpulse>
also pkgs/stdenv/generic -> pkgs/build-support/stdenv
<Sonarpulse>
need RFC that is just "revert that commit"
<Sonarpulse>
shlevy: vision for 1 or 2? in thread
<shlevy>
for 1.
<shlevy>
Also thoughts on 2 of course
<shlevy>
But it helps to have a general API to design against :)
<Sonarpulse>
sure
<gchristensen>
with tests =)
<gchristensen>
dtz: "These changes usually can be safely applied on all platforms (although sometimes they are not for rebuild reasons)" I'd be inclined to just do it anyway, especially if "these changes are largely fixes improving compliance and correctness resulting in higher-quality programs" holds true
<shlevy>
+100000
<shlevy>
If need be, make a compat change, then revert it in staging.
<shlevy>
Same goes to you Sonarpulse ;)
<Sonarpulse>
hehe yeah i do that
<Sonarpulse>
not techdebt remains unstaged!
<Sonarpulse>
(unless I don't have time to wade through breakage, heh)
<dtz>
haha okay!
<dtz>
honestly partly that was because I never made myself a bootstrap so my builds were dependent on a hilarious number of stages through gcc6 (gcc5 default at the time) -> clang -> clang+libc++ -> ~~allvm~~
<dtz>
and so if I "broke" a glibc build I had a silly amount of rebuilding to do xD xD
<shlevy>
Yeah, we need a better way to do that
<shlevy>
"the stdenv I'm building" and "the stdenv I'm using to build" needing to pull from the same huge package set is obnoxious
<shlevy>
Hmm... Maybe we can make overlays conditional on which "stage" we're in?
<Sonarpulse>
yeah overlays and boostrapping is messed up
<Sonarpulse>
pierron wants one big fix point
<shlevy>
There's also a problem with nested package sets and overlays
<shlevy>
I have that on my backlog to redesign
<Sonarpulse>
nested?
<Sonarpulse>
you mean as it would be with one big fix point?
<shlevy>
E.g. I want to give my users a "pkgs" set where any "haskellPackages" variant has our internal packages
<Sonarpulse>
ahhhhh
<shlevy>
Right now I have a separate function to wrap a haskellPackages set
<Sonarpulse>
yes per-language package sets are within the stage
<Sonarpulse>
with the stage package set, that is
<shlevy>
So they import our special nixpkgs, which has top-level stuff, and add an overlay with our special haskellfunction :D
<FRidh2>
I'm hoping we could standardize the interfaces we have for the language package sets for 18.09, especially considering overriding with multiple overlays
<Sonarpulse>
(warning github might put them out of order)
<Sonarpulse>
FRidh2: yes that would be good
<Sonarpulse>
well...
<shlevy>
FRidh2: Please include me early in any discussions on that if possible :)
<Sonarpulse>
ok I think they all are doing it wrong :D
<Sonarpulse>
so might need to "standardize" on a goal that nothing realizes
<shlevy>
Yeah, good catch, I thought I'd seen him respond already :o
<FRidh2>
my plan was to open an RFC describing the purposes, and leaving the technical implementation for the discussion (as I also don't know how to, exactly)
<gchristensen>
shlevy: in the musl thread
<gchristensen>
Sonarpulse: ^
<Sonarpulse>
gchristensen: np
<Sonarpulse>
shlevy: some of those changes in the haskell PR are a bit silly
<Sonarpulse>
but they sort of elucidate some interesting stdenv and cc-wrapper things
<Sonarpulse>
that PR is sort of a strawman argument, I guess :)
<Sonarpulse>
but the first commit alone is probably a strict improvement
<dtz>
lol I just submitted a PR and thought to myself "this is really just a strawman" xD
davidlt has joined #nixos-dev
<Sonarpulse>
dtz: hehehe which one?
<dtz>
the man-page outputs one! haha
<dtz>
I'm still waking up so thought for sure that'd be an overly naive fix xD
<Sonarpulse>
dtz: hehe well hopefully vcunat will chime in
<Sonarpulse>
the issue thread was super confusing
<clever>
dtz: how exactly does appimage differ from nix-bundle?, bundle mainly uses a mount namespace, but what does appimage do?
<dtz>
not sure! I was just poking at what was in the repository xD. I haven't tracked appimage implementation details, sorry
<clever>
ah
<shlevy>
OMG hadn't really thought about musl-darwin
<dtz>
(but am interested in the answer...)
<shlevy>
dtz: By the way: Assuming we reached a point where most of the packages anyone cared about worked with musl, would there be strong arguments for having glibc the default still?
<shlevy>
Is it more performant, or something?
<simpson>
It's surely got better compat. Building with musl doesn't mean running with musl.
<gchristensen>
my impression is the musl team is much smaller than the already-small glibc team
<shlevy>
gchristensen: I'm talking about long down the road
<shlevy>
Oh, yo mean upstream
<gchristensen>
yeah
Lisanna has quit [Quit: Lisanna]
<pierron>
shlevy: There is no problem with nested packages, once we would have SOS
<pierron>
shlevy: and nested fix-point can also be handled with a post-process at the end of the unique fix-point
<domenkozar>
clever: it uses mount
<domenkozar>
afaik
<sorear>
shlevy: AIUI, on conventional distros, the big argument for glibc as default is that they aren't ABI compatible and proprietary software generally requires glibc
<gchristensen>
I also caution against spending innovation tokens on less innovative things
<gchristensen>
"you want me to switch to a weird distro with a weird language and a weird package manager, _AND_ it uses musl? gimme a break!"
<gchristensen>
* dramatization
<cransom>
but true.
<sorear>
there are also a couple missing features (the one that gets brought up most often in #musl is support for ISO-2022-JP locales). little first-hand experience
<sorear>
ah, weirdness points
<niksnut>
tbh, I don't see a single advantage to end users in switching to musl
<gchristensen>
niksnut: do you see the advantage in cases where people care a lot about closure size?
<niksnut>
potentially, but I don't think glibc is the main problem when it comes to closure size
<sorear>
my main use case for musl is static linking that works reliably, but that can be done as well with a "cross"-toolchain
__Sander__ has quit [Quit: Konversation terminated!]
<dtz>
i like that you can read musl's source lol
taktoa has quit [Remote host closed the connection]
<Sonarpulse>
niksnut: I hope we can get to a point where a) many people care about X b) those people are willing to put in the work to maintain X so it doesn't negatively affect others c) nobody needs worry *why* those people like X
<Sonarpulse>
like I think docker is silly
<Sonarpulse>
but I am glad we can produce docker packages
<domenkozar>
I don't think it's possible to create statically linked ghc executables without musl
<domenkozar>
at least I wasn't able to do so
<domenkozar>
and once we have cross-compilation one could produce for example dhall-json as static executable for macos/linux/win all from nix
<domenkozar>
that would be pure joy :)
<domenkozar>
Sonarpulse: btw, we hired angermann moritz to work on ghc linux->windows cross compilation :)
<thoughtpolice>
domenkozar: It's possible -in some limited cases- but due to glibc's design, even if it does compile, it can still explode later.
<Sonarpulse>
domenkozar: nice!
<thoughtpolice>
Personally I sort of agree with gchristensen - musl is great but probably not *that much better* to spend substantial effort moving the whole tree to, at least not anytime soon... I admit I've wanted proper static linking though, and it would be of use for cross builds in some cases. But I'd be more than willing to keep that stuff under lib/, that users can use to build their own closures.
<Dezgeg>
for static builds you still have the problem of static libraries depending on other static libraries, I'd think
<thoughtpolice>
Of course then there's the problem of actually building the damn thing and it taking a while, but that's a separate issue. (Related, but I really wish there was an instant turnkey way to spin-up Hydra instances on some cloud provider to build some closure for you, fetch it, and just tear it down...)
<thoughtpolice>
Really you don't even need Hydra I guess, in that case.
<domenkozar>
I haven't played with musl, but what would the common diff be for packages to support glibc and musl?
<gchristensen>
according to the RFC, nothing
<Sonarpulse>
yes
<Sonarpulse>
unless you need lots of gnu-specific stuff
<makefu>
gchristensen: fantastic, you can now remove the server from your closet! :D
<Profpatsch>
FRidh2: Phew, I didn’t know we had *quite* that many maintainers.
<Profpatsch>
I’ve written a little script that goes through the maintainer list and checks whether the github user exists.
<Profpatsch>
And I’m cross-checking every user with less than 5 characters, since we don’t want to ping too many bystanders. dP
<Profpatsch>
:P
<Profpatsch>
Just for reference, we have 788 maintainers at the moment.
<FRidh2>
next step is to check their activity
<Profpatsch>
Should be easy once we have the github mapping.
FRidh2 has quit [Quit: Konversation terminated!]
<gchristensen>
makefu: I can?
<gchristensen>
makefu: depends how rigorously I adhere to the purposes for which the funding was provided
<makefu>
if you love to sleep together with your servers, nobody will judge you :D
<gchristensen>
I really really don't :P
<gchristensen>
I prefer my home servers be used for things like backups and Plex, which only really work hard during hours I'm not trying to sleep
<Profpatsch>
m!
<Profpatsch>
m is a nice letter.
<Profpatsch>
Half way through
<Sonarpulse>
shlevy: if we're gonna do the big rename for build run emit
<Sonarpulse>
should we do it for 18.03?
<Sonarpulse>
gchristensen: orivej also knows at least cc-wrapper pretty well
<Sonarpulse>
probably stdenv too
<gchristensen>
nice
pxc has quit [Ping timeout: 245 seconds]
jtojnar has quit [Remote host closed the connection]
jtojnar2 has quit [Ping timeout: 240 seconds]
<shlevy>
Sonarpulse: Definitely not
<Sonarpulse>
shlevy: ok
ckauhaus has quit [Quit: Leaving.]
<Sonarpulse>
niksnut, dtz, bgamari, shlevy: https://ste.la/ finally got slides from cross talk up
<Sonarpulse>
I'm a bit fuzzy now, but I took the second half of that and added a slide for nixcon
orivej has joined #nixos-dev
<shlevy>
bgamari-: Sonarpulse: Were you guys able to cross-build NixOS?
<Sonarpulse>
bgamari- did somewhat
<Sonarpulse>
I wasn't really involved with that
<Sonarpulse>
other than occasional advice on IRC
<bgamari->
shlevy, yep
<shlevy>
bgamari-: What do I need to do it?
<bgamari->
shlevy, I have an ARM here running the image
<bgamari->
shlevy, one moment, let me try to update my simple-nix-cross repo
<shlevy>
Also, how did you cross-build systemd ? I only just got that working
<bgamari->
shlevy, I've had patches in my tree for that for quite some time
<shlevy>
Ah
<shlevy>
:(
<bgamari->
yeah
<bgamari->
I've been really bad about upstreaming this stuff
<bgamari->
it seems like I'm just jumping from one deadline to the other
<thoughtpolice>
Mmmm, I'm using Sonarpulse's branch to build on ARM with a cross systemd; not sure how that one works...
<thoughtpolice>
I imagine the three of us all probably have patches that are vaguely 80% similar to fix all the remaining stuff... Ugh. I've been bad about upstreaming some of it too
<bgamari->
shlevy, the trick (which is admittedly quite hacky) is to override nixpkgs.pkgs with a nixpkgs instantiated at the desired crossSystem
<bgamari->
really there probably ought to be a better way to do this
<shlevy>
I see
<bgamari->
Sonarpulse_ had a slightly nicer suggestion
<bgamari->
shlevy, the hard part is cutting down the default installation enough such that cross-compilation is feasible
<Sonarpulse_>
yeah now that there are those other options
<Sonarpulse_>
for nixpkgs
<Sonarpulse_>
we can make crossSystem one
<bgamari->
shlevy, strangely enough, that expression fails with
<bgamari->
anonymous function at /home/ben/block-eng/simple-cross/nixpkgs/pkgs/os-specific/linux/kernel/generic.nix:9:1 called without required argument 'stdenvNoCC', at /home/ben/block-eng/simple-cross/nixpkgs/lib/customisation.nix:74:12
* bgamari-
must be missing a piece
<shlevy>
bgamari-: Maybe some weekend soon we should set up in a coffeeshop or somemthing and get this all working upstream :)
<shlevy>
bgamari-: Hmm, how? I've been cross-building kernels...
<bgamari->
oh, no it's not
<bgamari->
it's my branch that breaks it
<bgamari->
shlevy, updated
<shlevy>
Thanks!
<shlevy>
I didn't realize it would be so straightforward on the nixos end... I should have. I'm testing adding a crossSystem argument to config.nixpkgs
<bgamari->
oh, right
<bgamari->
there is also a minor wrinkle
<shlevy>
:o
<bgamari->
pushed again
<bgamari->
environment.noXlibs breaks when you override nixpkgs.pkgs
<shlevy>
bgamari-: Any idea why "bind" is still trying to build with services.bind.enable = false?
<shlevy>
(I'm working against master for the moment)
<bgamari->
shlevy, hmm, afraid not
<shlevy>
:/ easier to just fix bind build than try to trace it down
<dtz>
"host" is from "bind" IIRC, as are nslookup and dig
<dtz>
shlevy: ^
<shlevy>
hmm, OK
<shlevy>
Got it working anyway :)
<dtz>
\o/
jtojnar has joined #nixos-dev
<shlevy>
Sonarpulse_: Oh, forgot to mention: When the target is "don't care", we want depsBuildBuild because that's guaranteed to be the same as the native build, whereas depsBuildHost might not be for incidental reasons
<shlevy>
bgamari-: Will check myself when I get home, but did you have a solution to stage-1.nix calling ldd?
<shlevy>
I assume readelf or patchelf could serve just as well..
<bgamari->
shlevy, I do
<bgamari->
I can't remember what though
<bgamari->
hmm
<bgamari->
or did I?
<shlevy>
Looks like you added glibc.bin but that doesn't have ldd on cross :)
<bgamari->
my tree actually still has a mention of ldd there
<shlevy>
OK, will try to find a fix
<bgamari->
yeah
<bgamari->
odd, I wonder how this is working
<bgamari->
shlevy, I'm doing my builds on Debian
<bgamari->
so it may be that it's picking up the debian ldd
<shlevy>
Unlikely. But maybe there's just no pipefail
<shlevy>
And you're getting lucky with your deps :D
<bgamari->
heh
<bgamari->
certainly can't rule it out
<bgamari->
admittedly, I think I'm also still relying on qemu's user-space emulation in a few spots
<bgamari->
so my nixos build isn't entirely clean
<Sonarpulse_>
shlevy: wellllllll
<Sonarpulse_>
that's true
<Sonarpulse_>
another way to look at it is use depsBuildHost because it ought to be the same and you want to notice if it isn't
<Sonarpulse_>
programming assuming bugs converges into a sort of sorry state