<gchristensen>
oh that reminds me nh2, I manage to get an incredible dedup ratio on the aarch64 community box in a directory with like 3,000 checkouts of the chromium source code, lol
<JJJollyjim>
D:
<gchristensen>
bup. another apenwarr tool. that guy is everywhere.
<hexa->
hm, my nix store is located on a btrfs volume that's a) zstd compressed b) out-of-band deduped using bees
<gchristensen>
nice
<gchristensen>
I am jealous of that out-of-band dedup'
<hexa->
bees can be given a target memory size to dedup
<hexa->
so it's not the all-in approach of zfs
<gchristensen>
nice
<hexa->
or actually a target load, my bad
<hexa->
nvm, both :D
<gchristensen>
nice
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
burkelibbey_ has quit [Quit: Connection closed for inactivity]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
drakonis has quit [Ping timeout: 260 seconds]
<aminechikhaoui>
manveru thank you for https://github.com/manveru/nix-whitelist :-) just tried it today in one of our projects at work and it solves one of the pain-points I had nicely
drakonis has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-dev
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Read error: Connection reset by peer]
justanotheruser has quit [Ping timeout: 260 seconds]
orivej_ has quit [Ping timeout: 256 seconds]
justanotheruser has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
<pie_>
i feel like that should be in lib
orivej has quit [Quit: No Ping reply in 180 seconds.]
<ashkitten>
i'd like to get the fix in nixpkgs now that i've figured out what my issue is. it looks like there are two commits since the last release, i'm not sure whether to add autoreconfHook and fetchFromGitLab or just add both changes to patches
<ashkitten>
is either method likely to be accepted into nixpkgs? what's preferable?
<cole-h>
I can't speak on likelihood or what's preferable, but I personally would add the two commits to `patches = [ ];` with a note that they can be dropped in the next release
<ashkitten>
much easier for me anyways
<ashkitten>
does fetchpatch need a name argument?
alp has joined #nixos-dev
<cole-h>
Not necessary, I don't think.
<cole-h>
At least I never do.
<cole-h>
Maybe it's nice for patches that are planned to be carried around longer to give a short name as a description (in addition to a comment, hopefully)
cole-h has quit [Quit: Goodbye]
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
orivej_ has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-dev
FRidh has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-dev
orivej_ has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
teto has joined #nixos-dev
__monty__ has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-dev
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
Shados has quit [Quit: Shados]
Shados has joined #nixos-dev
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #nixos-dev
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-dev
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
<FRidh>
we're also still on 0.9 in nixpkgs, right? 4e5b465052f4c41fba9d23827a7085dc3f9bc7ee
<domenkozar[m]>
yeah this PR should resolve the reason why
b42 has quit [Quit: WeeChat 2.7.1]
b42 has joined #nixos-dev
__monty__ has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
__monty__ has joined #nixos-dev
<manveru>
has anyone seen `Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads` in the new python nixos tests?
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
<nh2>
ashkitten I always give `fetchpatch` `name`s, because it makes it easy to spot in `nix-build` output what the things are that are being downloaded -- easier than if it's just some hash.patch
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
<FRidh>
manveru: yes there is a issue for it
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-dev
orivej_ has quit [Ping timeout: 264 seconds]
<ajs124>
andi-: Firefox 77.0 was released yesterday and their "ftp" already seems to have 77.0.1. I can try to upgrade it (and nss), if you're busy (and nobody else is working on it yet).
<andi->
ajs124: Yeah please do. The NSS update is straigt forward. I started it yesterday and lost motivation after it compiled..
<ajs124>
andi-: the nss-pem patch doesn't seem to be applying anymore. what is that patch even about?
<andi->
ajs124: what version have you tried to update to?
<andi->
3.52.1 was working fine yesterday
<ajs124>
3.53
<ajs124>
ah, ok
<andi->
It might be that they started refactoring more of the old craft in NSS and now you need to patch that patch a bit more ;)
<ajs124>
I'm wondering if the functionality that patch provides is actually used.
<andi->
I had that discussion a few times with aszlig already. Apparently it is being used. It is one of the things on my todo list to write a proper issue about.
<andi->
IIRC the example was users having PEM certificates in their browser (Firefox) to authenticate with websites.
<aszlig>
andi-: hm, i'm not sure we had discussed that patch already, but it was about a different patch
<andi->
Good question. I should have an answer to that in my chatlog
<aszlig>
anyway, i doubt the patch is needed nowadays
<andi->
aszlig: according to our conversation in November that patch in question was for Chromium to support PEM certificates.. but yeah we should probably drop it *after* having tested if something starts failing. So probably a follow-up PR.
<ajs124>
apparently this whitespace change makes the patch fail
<aszlig>
andi-: mhm, the question is whether chromium comes bundled with CA certificates nowadays or whether it just relies on NSS to either include them or being passed via cacert
<andi->
ajs124: yeah that is common, see the other sed lines in the NSS expression :/
<andi->
ajs124: just to make sure, you are on recent master? I feel like I've seen that whitespace issue already
<ajs124>
yup, master as of like an hour ago. but I agree, it's weird that it fails, because prePatch seems to be trying to fix exactly that.
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 246 seconds]
drakonis_ has joined #nixos-dev
<Ericson2314>
zimbatm: Ah i forgot you had commit bit for Nix
drakonis has quit [Ping timeout: 256 seconds]
<Valodim>
somehow zsh started clearing its history every now and then. causes a surprisingly big productivity hit for me :(
<Ericson2314>
zimbatm: I've been worried Matt and I have been cranking out PRs faster than eelco alone can review them, and also that the new feature ones vs pure cleanup ones are not easy to distinguish
<arianvp>
can we add some jitter to this stale-bot whilst it catches up with its backlog?
<arianvp>
my inbox literally exploded over the past few days; wonder if we can tweak things here
<arianvp>
it's a price we only have to pay once... but would be nice if we dont have to pay it at all
drakonis has joined #nixos-dev
<FRidh>
how much do Nix PR authors review eachothers' PR's?
<Ericson2314>
FRidh: I think it is unclear what authority eelco has invested the now-disbanded nix team to merge things
drakonis_ has quit [Ping timeout: 260 seconds]
<FRidh>
that I suppose is important to know. It seems like eelco is the one mostly reviewing other PR's. Maybe it helps if those that have the time to work on Nix could review more other PR's.
<Ericson2314>
FRidh you mean on approval leave to Eelco to merge?
<FRidh>
yes
<FRidh>
maybe also merge yourself if you can, but as a step
<gchristensen>
sounds nice
<FRidh>
its challenging I think when people have different amounts of time they can devote to a project, how to keep up if you want to keep up
{^_^} has quit [Ping timeout: 260 seconds]
<LnL>
I'm not sure if that really works in practice
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
FRidh has quit [Ping timeout: 260 seconds]
<Ericson2314>
FRidh: so the idea of the core time was to triage tickets and stuff
<Ericson2314>
but it didn't work great in pratice
cole-h has joined #nixos-dev
<Ericson2314>
FRidh: I will go review some PRs now as a demonstration of good faith
<Ericson2314>
but ultimately it's just as you say, Eelco has his own priorities, but I have me and 2 other devs working full time on this stuff as we must per our contract
justanotheruser has quit [Ping timeout: 246 seconds]
<zimbatm>
Ericson2314: domenkozar[m] also has commit access and is more confortable than me for taking bigger decisions I think
FRidh has joined #nixos-dev
<zimbatm>
at some points I think that we need somebody to step up and become the Linus of the NixOS project. Reviewing and merging code all day.
<zimbatm>
and cursing at people when they do things badly :p
<Ericson2314>
hehe. I don't know if it needs to be one person (e.g. GHC has multiple) but I agree we do need a formal policy.
<Ericson2314>
We simply need to authorize more people until enough time is allocated
<Ericson2314>
if existing people can't or don't want to spend more hours to meet the time budget
alp has quit [Ping timeout: 246 seconds]
<zimbatm>
I think one thing Linus did quite nicely is to spend time to discuss the boundaries of what is acceptable or not to merge into the kernel
<zimbatm>
then find people who he trusted to follow these rules
<zimbatm>
it doesn't need to be one person merging if we have a common understanding of the "taste" of the project
<zimbatm>
Ericson2314: how much time do you have to finish the project?
<Ericson2314>
zimbatm: you can see the projected dev hours here https://github.com/ipfs/devgrants/blob/master/open-grants/open-proposal-nix-ipfs.md . I think it's understood getting everything merged will take longer / be async. And we just merge our PR branches to a fork so we're never blocked. That said, it helps to pipeline things by getting the cleanup PRs merged earlier, as it makes reviewing the interesting/featureful ones
<Ericson2314>
later much easier
<zimbatm>
it might be worth discussing things in person with Eelco upfront to see if there is an agreement on the direction
<gchristensen>
yeah that'd be good
<Ericson2314>
Yes agree completely
justanotheruser has joined #nixos-dev
<zimbatm>
okay, let's setup a meeting then
<Ericson2314>
great!
<Ericson2314>
if you two want to be there too, that sounds great to me :)
<Ericson2314>
Also, eelco has merged a few things already, which I am quite grateful for, it's just we're writing them faster than they're getting reviewed
alp has joined #nixos-dev
<zimbatm>
pinged niksnut, I will let you know
<gchristensen>
for me I'd like to be there, but it isn't likely I can be there
<Ericson2314>
zimbatm: thanks!!
<Ericson2314>
gchristensen: no worries, I am sure it will be an evolving conversation
<domenkozar[m]>
hmm, why is no package from pkgsMusl built on hydra?
cole-h has quit [Quit: Goodbye]
<domenkozar[m]>
any objection building pkgsMusl.stdenv on hydra?
cole-h has joined #nixos-dev
<zimbatm>
I assume because it would add 10k+ failing packages to the build matrix
<zimbatm>
it might be good to cherry-pick a few packages like pkgs.nix to be built with musl
<domenkozar[m]>
it would be great to have some "getting started" docs for that
<Ericson2314>
matthewbauer wrote some good intros on his blog
<domenkozar[m]>
I think it's becoming a strong point of nixpkgs
<domenkozar[m]>
but the only way to get more people is to make it accessible
<domenkozar[m]>
we could attract a huge crowd with that
<Ericson2314>
Yeah I am not so sure on these things. I defined the attributes i made in the manual, but people always seem to want something more guided than the exhaustive reference
<Ericson2314>
do you know what they went to instead? buildroot? yoctolinux?
<Ericson2314>
unless they could get away with not cross compiling distro-wide, the choices are pretty limited
johnny101 has quit [Quit: Konversation terminated!]
<zimbatm>
does nixos support cross yet?
<Ericson2314>
yes
<zimbatm>
I think I saw an open issue fly by today. But there are so many due to the bot..
orivej has joined #nixos-dev
<Ericson2314>
hmm yeah something might need to be closed
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
<ajs124>
you're probably thinking of #4963
<Profpatsch>
Ericson2314: I think a good first step is to move the more formal description that the cross section starts with to an appendix
<Profpatsch>
And only mention the most basic things that people need, namely nativeBuildInputs and buildInputs
<Profpatsch>
Have a few examples for packages are known to be working
<Ericson2314>
I'll take another look
<FRidh>
domenkozar[m]: what do you think if we post the patchelf new maintainers thing on discuss.python.org? auditwheel, conda, and a couple others there use patchelf as well. Suppose it could be good if anaconda maintainers could help out.
<Ericson2314>
That sounds very good to me
<Ericson2314>
it's very interesting how disjoint our maintainership is with other stuff
MichaelRaskin has joined #nixos-dev
<Ericson2314>
if patchelf could be bridge of sorts, that would be nice
<gchristensen>
yeah even oracle
<domenkozar[m]>
FRidh: that would be great
<domenkozar[m]>
I worry how many know how to fix patchelf
<domenkozar[m]>
most of patches we got so far were from linuxfundation
<gchristensen>
let' riir
<FRidh>
yea, its quite specialistic
<domenkozar[m]>
I think I have musl+patchelf ready
<domenkozar[m]>
last thing missing is probably a simple Nix snippet how to create reproducible problems with binaries
<domenkozar[m]>
then the tooling is there if people want to contribute :)
<domenkozar[m]>
and we can merge things until they start working :D
<samueldr>
matthewbauer: yesterday I saw that systemd's build is broken for cross on unstable, do you know if it is fixed on staging or in an upcoming PR?
<samueldr>
matthewbauer: on the topic of that link, I see you have ubootRaspberrypi4 picked, is booting with u-boot on rpi4 working for you?
<matthewbauer>
no ubootraspberrypi4 doesn't actually boot, although it builds and everything
<matthewbauer>
i just had to use the traditional rpi bootloader
<samueldr>
u-boot itself can boot if you put the linux_rpi4 dtb
<samueldr>
but I had no luck booting nixos from there on, it hangs somewhere early in the kernel or late in u-boot when handing off
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
<matthewbauer>
hmmm, don't we already copy over bcm2711-rpi-4-b.dtb ?
<matthewbauer>
i guess not in firmware/ though
__monty__ has quit [Quit: leaving]
alp has joined #nixos-dev
<samueldr>
that's it
<samueldr>
note that linux_latest's FDT (.dtb) does not appear to work, at least it doesn't init the display
<samueldr>
(I wasn't setup to look at serial when I tried it)
hexa- has quit [Quit: WeeChat 2.7.1]
<matthewbauer>
yeah
<matthewbauer>
i gave up on anything but linux-rpi
<samueldr>
I was only using the .dtb from mainline in hope that, since u-boot syncs with mainline, that it would work better
lightbulbjim has joined #nixos-dev
justanotheruser has quit [Ping timeout: 260 seconds]
alp has quit [Ping timeout: 246 seconds]
justanotheruser has joined #nixos-dev
<samueldr>
:/ feels like there may have been a couple regressions piling up in master, then staging-next for cross-compilation... not sure I can properly take a look :(