genesis has quit [Remote host closed the connection]
Lisanna has quit [Remote host closed the connection]
sir_guy_carleton has joined #nixos-dev
<sir_guy_carleton>
what's the best way of proposing very small changes to nixpkgs (e.g. changing a line or two in the documentation for nixos options)?
<samueldr>
a PR!
<samueldr>
sir_guy_carleton: as it's documentation changes, you could even do it using the github editors
<samueldr>
the CI will build the documentation so if for any reason you broke the build, it would be noticed quickly
<samueldr>
ah, for options, too I think
Jackneill has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
<sir_guy_carleton>
hmm, it was about the the (gc-)keep-derivation example in nix.extraOptions that I asked about a week or so ago.
<sir_guy_carleton>
the man page for nix.conf lists it without the gc- prefix, so it felt inconsistent to me; but just trying it now, nixos-rebuild didn't have any trouble building it
<sir_guy_carleton>
so i'm not sure if it allowed or should be changed
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 256 seconds]
lassulus_ is now known as lassulus
Jackneill has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
sys9mm has quit [Ping timeout: 256 seconds]
fpletz has quit [Ping timeout: 256 seconds]
sys9mm has joined #nixos-dev
Florian[m] has quit [Ping timeout: 256 seconds]
mpickering has quit [Ping timeout: 256 seconds]
mpickering has joined #nixos-dev
Florian[m] has joined #nixos-dev
Lisanna has joined #nixos-dev
fpletz has joined #nixos-dev
orivej has joined #nixos-dev
pie__ has quit [Ping timeout: 244 seconds]
sir_guy_carleton has quit [Quit: WeeChat 2.0]
orivej has quit [Ping timeout: 256 seconds]
tv1 has joined #nixos-dev
tv has quit [Ping timeout: 264 seconds]
tv2 has joined #nixos-dev
tv1 has quit [Ping timeout: 260 seconds]
tv3 has joined #nixos-dev
tv2 has quit [Ping timeout: 248 seconds]
tv4 has joined #nixos-dev
tv3 has quit [Ping timeout: 256 seconds]
<peti>
domenkozar: 122 new build successes. :-)
<domenkozar>
can't say it's plenty :D
Sonarpulse has quit [Ping timeout: 256 seconds]
<peti>
domenkozar: Hackage is full of crap, basically. It would have been good to build sophisticated decentralized build sources into cabal-install instead of forcing people to (a) upload to Hackage or (b) set up their own server just so they can re-use packages.
<peti>
domenkozar: stack seems to be superior in that regard.
<domenkozar>
yes
<domenkozar>
iirc there is gsoc work on matrix building
<angerman>
hackage should be a blockchain!
* angerman
runs
<domenkozar>
it's a package chain of revisions
<angerman>
domenkozar: no. It's not a chain. It's a stack.
<angerman>
there is no chaining.
<domenkozar>
the consensus is more like ripple
<domenkozar>
a few validators, that's it
<angerman>
who validates?
<domenkozar>
trustees :P
<angerman>
not really. They can add additional revisions.
<angerman>
and well, they can prevent you from getting an account.
<domenkozar>
I wouldn't be hired to blockchain company due to my lack of knowledge :)
<domenkozar>
sadly I know too much about blockchains
<domenkozar>
more than I would like to
<peti>
Ah, sorry. :-)
<domenkozar>
np :)
<domenkozar>
for example I know that ripple is outstanding piece of tech
<domenkozar>
but don't tell cryptopunks or they'll hunt me down
<domenkozar>
so I'll wait 10 years for kids to grow up :)
<angerman>
domenkozar: liar!
<domenkozar>
:P
<angerman>
You know there is only one true blockchain. And that is EOS!
<domenkozar>
one to lose them all
genesis has joined #nixos-dev
orivej has joined #nixos-dev
tv has joined #nixos-dev
tv4 has quit [Ping timeout: 240 seconds]
vcunat has joined #nixos-dev
phreedom has quit [Ping timeout: 250 seconds]
phreedom has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
obadz has quit [Ping timeout: 276 seconds]
__Sander__ has joined #nixos-dev
obadz has joined #nixos-dev
page has quit [Quit: leaving]
page has joined #nixos-dev
pie__ has joined #nixos-dev
pie__ has quit [Ping timeout: 244 seconds]
pie_ has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
pie_ has quit [Ping timeout: 248 seconds]
pie_ has joined #nixos-dev
genesis has quit [Remote host closed the connection]
Sonarpulse has joined #nixos-dev
gchris`wednesday is now known as gchrist`recovery
<Sonarpulse>
peti: what's the protocol for hackage hashes updates on stable?
<thoughtpolice>
peti: (Very) New versions of cabal-install included support for e.g. git repositories. It took forever but it was there. There's nothing about Cabal that dictates using Hackage; having a "single source of truth" is just how people organize (and I'd argue it's how most communities organize already)
<thoughtpolice>
I mean, I guess it wasn't nearly as easy; many people ran their own small hackage servers, or sandboxing, AFAIK. I am happy for that. But I guess I've never found the "XYZ has a lot of crap" especially worrying/compelling, is the bigger thing.
<{^_^}>
nixos-weekly#58 (by samueldr, open): Logo proposal
<srhb>
Anyone have strong feelings about not increasing chromium timeout further? I think it'll timeout this time again (on a packet machine) despite having a 24 hour timeout. It's a close cut though: https://hydra.nixos.org/build/78308574/nixlog/1/tail
<srhb>
It seems mostly about which machine it lands on these days.
gchrist`recovery is now known as gchristensen
the has joined #nixos-dev
<gchristensen>
ok the is banning on some key words
<LnL>
Sonarpulse: your pong was a bit late last time, was wondering what your ideas are about changing stdenv bootstrapping
<Sonarpulse>
LnL: yes it was, haha
<Sonarpulse>
LnL: ok so I want to build libraries and tools never together
<Sonarpulse>
then in a single cross-like bootstrapping phase
<Sonarpulse>
should be able to build everything!
<Sonarpulse>
the idea is cross allows us to use bootstrap tools for nativeBuildInputs
<Sonarpulse>
but not buildInputs
<LnL>
oh!
<Sonarpulse>
it's as simple as that!
<Sonarpulse>
should be a way to auto do allowedRequisites to ensure nativeBuildInputs (and depsBuild* more broadly) don't make it to outputs
<Sonarpulse>
that will catch mistakes earlier
<Profpatsch>
Sonarpulse: I think I was too tired when you presented the new cross-system on the last Nixcon hackathon.
<Sonarpulse>
hehe we all were
<Sonarpulse>
the recent haskell -L debacle
<Profpatsch>
Do you have resources we can read that give an overview?
<Sonarpulse>
has showed me I still need to do far more explaining
<Sonarpulse>
:)
<Sonarpulse>
Profpatsch: I have link to slides, now
<LnL>
that's the thing I've been wondering about is if it would be possible to make dependencies in the stdenv more explicit
<Profpatsch>
Because I might have to implement some cross stuff (in a rules_haskell for bazel) soon, and I’d like to re-use your insights.
<Profpatsch>
Especially since we are using nixpkgs as backend for prebuilt haskell libraries.
Jackneill has quit [Remote host closed the connection]
<LnL>
right now it's {} -> bootstrap-tools, but then it's basically the wild west to get to the final stdenv
Jackneill has joined #nixos-dev
<Profpatsch>
I think bazel only has two systems, a host system and a target system, but your cross is a sliding window over three different systems.
<Sonarpulse>
Profpatsch: https://ste.la/ this is actually the talk i did at NY haskell meetuo
<LnL>
Sonarpulse: I still don't understand why the setup hooks run more than 2 times btw :p
<Profpatsch>
Nice, is there a recording of that talk as well?
<Sonarpulse>
Profpatsch: the two would be build and host, per the autoconf terminology
<Sonarpulse>
Profpatsch: recording was lost, unfortunately
<Sonarpulse>
LnL: it's on purpose because they are called with different parameters
<Profpatsch>
Sonarpulse: Huh, I can only see a few headings on https://ste.la/
<Profpatsch>
But none about cross
<Profpatsch>
Iceland, Homotopy Type Theory …
<Sonarpulse>
Profpatsch: oh single page app my link no good
<Sonarpulse>
haskell in pocket
<Sonarpulse>
is the one
<Profpatsch>
Ah, okay.
<LnL>
Sonarpulse: wait, as in for every build/host/target combination?
<Profpatsch>
Thanks!
<Sonarpulse>
LnL: not quite, thankfully
<Sonarpulse>
if you have a depsBuildBuild
<Sonarpulse>
that is running on the build platform, and makes things for the buildPlatform
<Sonarpulse>
so that
<Sonarpulse>
's a "0 -> 0 dep"
<Sonarpulse>
so the setup hook gets called with hostOffset=0 depOffset=0
<Sonarpulse>
(it's dynamic scope, sadly sourced scripts cannot take arguments even though AFAICT they act like bash functions with { .. })
Jackneill has quit [Remote host closed the connection]
<Sonarpulse>
*hostOffset targetOffset
<Sonarpulse>
the env hook also gets called with depHostOffset and depTargetOffset
Jackneill has joined #nixos-dev
<Sonarpulse>
LnL: the cc-wrapper env hook, using those hooks, will also populate different environment variables
<LnL>
yeah, I remember that
<Sonarpulse>
so without strictDeps, nothing in the stdenv/setup bash environment contains duplicate flags
<Sonarpulse>
with strictDeps, all the env hooks get run on all the packages
<Sonarpulse>
because we assume that the deps are miscategorized
<Sonarpulse>
also, the add-flags.sh of the wrappers will combine things
<LnL>
and I'm confused again, how does strictDeps end up with less flags then?
<Sonarpulse>
sorry I had it backwards
<LnL>
ah kk
<Sonarpulse>
so NIX_LDFLAGS and NIX_BUILD_LDFLAGS both get mixed into NIX_x86_64_unknown_linux_gnu_LDFLAGS
<Sonarpulse>
since we don't have, e.g. build-ld and host-ld to keep it separate
<Sonarpulse>
arguably that is a mistake
<Sonarpulse>
using actually triples in prefix, rather than abstract "build-" and "host-"
<Sonarpulse>
so between strictDeps and add-flags, we get a lot of -L duplication
<Sonarpulse>
*between strictDeps = false and add-flags.sh
<LnL>
right, but that's a separate problem no?
<LnL>
would it make sense to only run the setup hooks for a host/dep offset pair once? that would eliminate a bunch of duplicates for native
<LnL>
or are those always -1 0 1
<Sonarpulse>
LnL: yeah the offsets are abstract
<Sonarpulse>
don't care if things happen to be the same thing
<Sonarpulse>
LnL: I prefer to pull things in this abstract direction
<Sonarpulse>
fully abstract or fully transparent each avoids duplicate flags
<Sonarpulse>
it's only this middle ground where things get nasty
<Sonarpulse>
fully abstract also means cross will largely maintain itself
<Sonarpulse>
fully transparent means people will constantly break it
<LnL>
what about other env setup hooks, do they also run twice?
<LnL>
like addEnvHooks "$hostOffset" addPythonPath
<Sonarpulse>
LnL: only if python is a dependency twice
<Sonarpulse>
we typically only use depsBuildBuild for GHC and GCC
<Sonarpulse>
while also using them as nativeBuildInputs
<Sonarpulse>
so that's why we get things twice
<Sonarpulse>
with them
<LnL>
yeah, ok that makes sense
<LnL>
in that case I think you have to convince people separating nativeBuildInputs/buildInputs is a good thing
<Sonarpulse>
LnL: well, insofar that they've existed for a decade
<Sonarpulse>
I hope people don't mind the ditinction
<Sonarpulse>
but yes actually enforcing it is another matter
<gchristensen>
people just don't know what they mean or what they're for
<gchristensen>
(sometimes even after reading the manual)
<LnL>
I'd prefer it to be enforced tho, it makes the build environment cleaner and is more likely to result in working cross builds
<infinisil>
LnL: How is it possible to enforce that?
<LnL>
strictDeps = true;
<infinisil>
Oh, I didn't read the backlog
<LnL>
but not everybody agrees with that
<infinisil>
I'd also be in favor of enforcing it
<LnL>
and I don't think enabling it in a large set of packages like the haskell set is a good idea unless it's considered 'best practice' and done in more places
<gchristensen>
sounds onerous and we should be very careful about docs and usability and what-not before doing it widely
<LnL>
otherwise you end up with people confused why a binary doesn't show up in PATH only for a haskell package
<LnL>
exactly
<infinisil>
Would it be possible to start with enabling it for all packages that build successfully with it enabled?
<infinisil>
Then one by one fix the errors and make it default eventually
<gchristensen>
maybe even worse if you use overrides
<samueldr>
reading the backlog, is it that the strict deps makes it so native compiles work like cross compiles? so you get "free" cross compile compat?
<Dezgeg>
well, it's a necessary but not sufficient condition
<samueldr>
yeah, I didn't know how to add "for many/most situations"
<LnL>
in some ways
<Dezgeg>
there are like 250+ conditionals currently for cross that are needed regardless of this thing
<Dezgeg>
iow, a significant number of packages will need hacks, patches, additional configure options etc. to cross compile anyway, regardless of this strictDeps thing
<gchristensen>
+1
<gchristensen>
to both Dezgeg & LnL
<infinisil>
I see, I never really dabbled in cross, I only know nativeBuildInputs vs. buildInputs
<LnL>
sure, but I have no idea whether stuff belongs in nativeBuildInputs or not for most packages
<samueldr>
though, if I understand correctly, it helps enforce the minimal requirements needed for cross-compilation, so those that don't need hacks mostly get a free dinner, right?
<samueldr>
(at the expense of more headache for packagers, though, right?)
<samueldr>
(I'm really interested in *really* understanding more of the cross compilation stories here,)
<Profpatsch>
If it helps: I can never remember which one is nativeBuildInputs and which one buildInputs.
<Profpatsch>
So a simple rename of these attributes might work wonders.
<Profpatsch>
(It’s not nix that is the problem, it’s the complexity of stdenv as it stands).
<Sonarpulse>
Dezgeg: there's not that many hacks
<Sonarpulse>
that is really an unfair characterization
<Sonarpulse>
the vast majority of changes may be necessary for cross alone, but are fine with master too
<samueldr>
for what it's worth, even though I would hate the pain, and I know it hurts onboarding, anything that makes it easier along the way for cross to be supported is good imho
<Profpatsch>
Ugh, I just found this in my nixpkgs stashes:
<Profpatsch>
assert (assertMsg ("foo" == "bar") "foo is not bar, silly"); ""
<Profpatsch>
stderr> trace: foo is not bar, silly
<Profpatsch>
stderr> assert failed at …
<Profpatsch>
Somebody tell me why it’s a good/bad idea.
<Profpatsch>
The stuff you can find going through your temporary stashes …
<Dezgeg>
I mean stuff like pkgs/applications/networking/browsers/elinks/default.nix:, enableSpidermonkey ? (stdenv.hostPlatform == stdenv.buildPlatform),