<samueldr>
fallocate: fallocate failed: Operation not supported
<gchristensen>
:x
<samueldr>
for this particular issue it looks like it fails the whole build, much better than making a differently-reproduced output
<infinisil>
Would using fuse to have a deterministic filesystem layer for builds be possible?
* samueldr
thinks about using FAT32 as the filesystem for builds
<gchristensen>
or better that reproducible dev FS
<clever>
or use disorderfs, and fix the programs to not care
<gchristensen>
that one
<infinisil>
Tbh fixing programs seems like a neverending struggle
<samueldr>
yeah, though disorderfs is for another kind of issue :)
<gchristensen>
that is the reproducibility promise!
<samueldr>
what I'm seeing is here is features being present *or* lacking
<infinisil>
gchristensen: I think making nix-build expose less impurities is much better longterm
<samueldr>
the software could be built differently because the feature exists, while still not failing
<samueldr>
imagine unicode normalization issues
<infinisil>
(though that probably brings other problems with it, such as it being much slower to build stuff..)
<clever>
i already had issues with net-snmp, trying to auto-detect what your distro calls /etc/mtab
<qyliss>
No way is it possible to maintain a completely reproducible environment forever across all times of machines while still being reasonably performant IMO
<clever>
due to the sandbox not including ANY variant, it deduced that the name is "unknown", so it hard-coded itself to just open the literal "unknown" file at runtime, to query it
<qyliss>
It's a losing battle
<infinisil>
qyliss: Yeah probably, but we should still try to get as close as possible
<samueldr>
the issue isn't necessarily to make our builds reproducible by using a filesystem layer, but that *tests* for reproducibility should include that as yet another ambient impurity
<qyliss>
infinisil: sure, the more reproducible the environment is, the fewer programs we have to fix
<gchristensen>
possibly with tiers, nixos-reproducible, nix-daemon-on-systemd reproducible, single-user-nix reproducible
<samueldr>
the first step should be to identify impurity types, list them, and provide guidance?
<{^_^}>
#93787 (by kalbasit, 3 days ago, open): Bazel is currently broken on Darwin
<kalbasit>
I believe it got broken by the recent changes to the C toolchain
<kalbasit>
would you be able to help us out here?
<kalbasit>
cc LnL as well
<Ericson2314>
kalbasit: i am afraid i am pretty busy ATM
<Ericson2314>
looking at the logs I...don't see the original errors?
<Ericson2314>
is it possible they are up above due to parallel building?
<kalbasit>
Ericson2314: I think the error is this: ld: library not found for -lstdc++
<Ericson2314>
kalbasit: there are some new flags files in nix-support/*
<Ericson2314>
make sure that bazel gets them too
<Ericson2314>
libcxx-cxxflags for example IIRC
<kalbasit>
Ericson2314: If I don't touch NIX_LDFLAGS, will they get automatically taken into account?
<kalbasit>
NIX_LDFLAGS env var that is
<Ericson2314>
with regular builds, yes, but who the hell knows what tricks Bazel is going to pull
<LnL>
I don't know much about bazel, but it does it's own messy wrapper stuff IIR
<Ericson2314>
I would look at the bazel packaging and build bazel package and see if it is munging flags already
<Ericson2314>
and just try to cargo cult that for the new files
<kalbasit>
I'll try a few things then. I'll try to remove our custom NIX_*FLAGS first, if that does not work, I'll try to make it source the nix-support files
<kalbasit>
If I understand it correctly, those nix-support flag files are the only flags that we need right? As in, I should not try to append to NIX_*FLAGS but instead make it equal that content?
drakonis has quit [Quit: WeeChat 2.8]
<kalbasit>
apologies for the noob questions, I'm not the best person when it comes to C toolchain in Nix
<LnL>
well it's kind of expected that extending NIX_*CFLAGS in your expressions will be honored
<kalbasit>
Right, but I'm wondering if I should be mergeing NIX_*FLAGS with the nix-support files, or just export it with a new value that is the content of the nix-support files
<LnL>
ah, don't think that really matters
<kalbasit>
got it. I'll get back to you with what I find on this
<LnL>
just as long as the compiler is called with everything internally
alp has quit [Ping timeout: 256 seconds]
kini has joined #nixos-dev
justanotheruser has quit [Ping timeout: 246 seconds]
justanotheruser has joined #nixos-dev
drakonis has joined #nixos-dev
jonringer has joined #nixos-dev
<kalbasit>
I'm pretty sure it has something to do with the nix-support/libcxx-ldflags which sets -stdlib to libc++. However, it breaks if I add that to NIX_LDFLAGS so I'm not sure where to add that.
<Profpatsch>
I like the new stale bot message
<Profpatsch>
kalbasit: Ah, if the nix flags changed, that probably clashes with some of the fixes we do on darwin
<Profpatsch>
kalbasit: there’s a few darwin-specific blocks in the bazel build expression, you might find something relevant in there?
alp has joined #nixos-dev
theotherjimmy[m] has quit [Ping timeout: 244 seconds]
Guest80879 has quit [Ping timeout: 260 seconds]
puzzlewolf has quit [Ping timeout: 244 seconds]
domenkozar[m] has quit [Ping timeout: 244 seconds]
Valodim[m] has quit [Ping timeout: 244 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 260 seconds]
theotherjimmy[m] has joined #nixos-dev
Guest80879 has joined #nixos-dev
Valodim[m] has joined #nixos-dev
Cale has quit [Ping timeout: 260 seconds]
drakonis has joined #nixos-dev
domenkozar[m] has joined #nixos-dev
puzzlewolf has joined #nixos-dev
jonringer_ has joined #nixos-dev
jonringer has quit [Ping timeout: 260 seconds]
Cale has joined #nixos-dev
TethysSvensson has joined #nixos-dev
<TethysSvensson>
Hi, I'm new to nixos, so I'm sorry if this is the wrong place to ask. I'm having some trouble finding a reviewer for my first PR (https://github.com/NixOS/nixpkgs/pull/92581). I was wondering if there is something else I should be doing to get feedback on this, or if I should just be patient?