worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 20.03 BETA Announced https://discourse.nixos.org/t/nixos-20-03-beta/5935 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
abathur has joined #nixos-dev
ash_braker has joined #nixos-dev
bhipple has quit [Ping timeout: 256 seconds]
bhipple has joined #nixos-dev
<aanderse> ma27: ping
<ma27[m]> aaron: pong
<aanderse> available for a sec? question about matrix synapse pr
<ma27[m]> yes :)
<ma27[m]> (I'm currently working on it, I'm just procrastinating the release notes :) )
orivej has quit [Ping timeout: 255 seconds]
_ris has quit [Ping timeout: 272 seconds]
bhipple has quit [Ping timeout: 260 seconds]
<ash_braker> Can we make channels to be checked by end-users on demand? I mean like users on x86 would get the latest update regardless i386 test fails.
drakonis has quit [Quit: WeeChat 2.7.1]
ash_braker has quit [Quit: ash_braker]
<jtojnar> the easiest would probably be having per-arch channels
<jtojnar> and then a combined channel for people who have multi-arch fleets that they want to keep consistent
<jtojnar> it does not really make sense to have channels checked by users since channels are just symlinks to a nixpkgs snapshot (independent of the way they are produced)
ash_braker has joined #nixos-dev
<infinisil> ,random-pr
<{^_^}> https://github.com/NixOS/nixpkgs/pull/78783 (by simson, 6 weeks ago, open): i3ipc: 1.6.0 -> 2.1.1
ajs124 has quit [Quit: killed]
Scriptkiddi has quit [Quit: killed]
das_j has quit [Quit: killed]
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
<ash_braker> jtojnar: Would you like to take a look at smartdns? I have tuned it a little bit. Thx in advance:)
bhipple has joined #nixos-dev
ash_braker has quit [Quit: ash_braker]
<infinisil> Is there a way to see whether a github user has the nixpkgs commit bit?
<infinisil> Previously it was roughly "If it says 'Member', they can probably merge", but now with unprivileged maintainers, everybody is a Member..
<qyliss> You can look in the team list, but it's not very convenient...
<qyliss> Does anybody have a script to backport a PR? I find it incredibly tedious, especially having to post on the original PR.
<qyliss> I'll write one if not.
<infinisil> Hm I'm not sure about this, I usually have to manually make sure it works on the other branch
<samueldr> I have a script that handles the trivial things up to and including cherry-pick -x
<samueldr> but yeah, I nix-build and check, before then pushing
<qyliss> The script can nix-build and pause for checking
<qyliss> There's just so much other annoying stuff to do.
ash_braker has joined #nixos-dev
<infinisil> Maybe just a `cherry-pick-from-pr <number>`
<infinisil> I'd like that
<qyliss> that's easy
<qyliss> git fetch origin pull/$PR/head && git cherry-pick FETCH_HEAD
<Shados> Is there anyone with commit access I can ping to look at some Xen-related stuff? I've not had much luck getting a PR moving on that front, and I have a slowly growing backlog of further changes/updates to PR in the area.
ash_braker has quit [Client Quit]
<infinisil> qyliss: Will that pick all commits?
orivej has joined #nixos-dev
<qyliss> Oh, no.
<qyliss> That'd be something like
<qyliss> git fetch origin pull/$PR/head && git cherry-pick HEAD..FETCH_HEAD
<qyliss> That should do it.
<infinisil> Oh nice, I'll give this a try next time I need it
<infinisil> (If I can remember anyways)
orivej has quit [Ping timeout: 258 seconds]
bhipple has quit [Remote host closed the connection]
orivej has joined #nixos-dev
ash__ has joined #nixos-dev
abathur has quit [Ping timeout: 255 seconds]
ash__ has quit [Remote host closed the connection]
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
cole-h has quit [Ping timeout: 260 seconds]
lovesegfault has quit [Quit: WeeChat 2.7.1]
<danderson> policy question: what do we do about CVEs that are real, but that upstream has not patched?
<danderson> bonus question: marking the package insecure breaks a large closure, because it's a load-bearing core library (openjpeg).
<simpson> Are there any other patches available? IIUC we've yoinked patches from Debian and RH when it makes sense to do so.
<danderson> Not afaict. NVD's only resource is the upstream github issue, and the issue has other distros gently poking asking for fixes. I'll dig some more.
<danderson> one is relatively low severity imo: resource exhaustion, a malicious jpeg can omnomnom all the ram.
<danderson> the other is a buffer overflow, less good. The bug (https://github.com/uclouvain/openjpeg/issues/1127) has a proposed patch, but no activity.
<{^_^}> uclouvain/openjpeg#1127 (by Young-X, 1 year ago, open): Potential heap-based buffer overflow in function t2_encode_packet in src/lib/openmj2/t2.c
Jackneill has joined #nixos-dev
LnL has quit [Ping timeout: 260 seconds]
LnL has joined #nixos-dev
LnL has joined #nixos-dev
<Taneb> I've been getting a lot of "Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS" errors with my local Hydra server, is that suggestion sensible?
orivej has joined #nixos-dev
ash__ has joined #nixos-dev
<ash__> Has this commit solve the blockage? I didn't see success.
ash__ has quit [Quit: ash__]
<andi-> Taneb: not sure if related but hydra seems to no longer eval the trunk-combined job. `exit code 1` ofBorg still seems to be happy eval'ing new PRs
ash__ has joined #nixos-dev
<timokau[m]> infinisil: If you hover over someone's github name there'll be a popup that tells you exactly which teams they are member of. If they are a member of NixOS/nixpkgs-commiters, they have the commit bit. Only issue is that only works reliably if you are in the team yourself.
<andi-> unless that person is in one or more NixOS teams then you might not see the relevant bits and have to search in the teams if you find that person :/
<andi-> oh, I think they fixed that by now. I can click on "1 more" now
<timokau[m]> Yeah and I think in practice if somebody is in any more teams other than the "maintainers" one you can just assume they have the commit bit
<timokau[m]> Still it would be nice if we could set the committers team to public by default. I would find it really annoying as a non-commiter if I couldn't discern who can merge my PRs and who cannot. My team membership was on private for a while, simply because it was the default.
<andi-> I think that is up to each individually
<andi-> but I know the struggle.. You give someone a review and because they are a "Member" you assume they can take it from there (e.g. merge) but they can't and are not aware of the issue.
<timokau[m]> Yeah I don't mind the option to set it to private, but I think the opt-out nature is a problem because many are not even aware of the option (at least I wasn't at first)
__monty__ has joined #nixos-dev
abathur has joined #nixos-dev
<ash__> Seems like the evaluation for unstable channel has got error so that there is no job even created
myskran has joined #nixos-dev
evanjs- has quit [Quit: ZNC 1.7.5 - https://znc.in]
abathur has quit [Ping timeout: 268 seconds]
evanjs has joined #nixos-dev
ash__ is now known as ash_braker
drakonis has joined #nixos-dev
ash_braker has quit [Quit: ash_braker]
vcunat has joined #nixos-dev
<vcunat> I assume none of you have managed to reproduce that Hydra error?
<vcunat> (or even know what the problem is)
<vcunat> I forced it redo the evaluation a few times, but it looked always the same to me.
<andi-> Same, just exit code 1
<vcunat> I suppose the last line is important
<vcunat> > error: unexpected EOF reading a line
<{^_^}> <LAMBDA>
<vcunat> I would merge staging-next to master already. I just think it's better to unblock the channel first.
claudiii has joined #nixos-dev
bhipple has joined #nixos-dev
ixxie has joined #nixos-dev
myskran is now known as abathur
edwtjo has quit [Quit: WeeChat 2.6]
edwtjo has joined #nixos-dev
edwtjo has quit [Changing host]
edwtjo has joined #nixos-dev
<ryantm> Yay, thanks to bhipple, we have automated Go module updates now. https://github.com/NixOS/nixpkgs/pull/82492
<{^_^}> #82492 (by r-ryantm, 29 minutes ago, open): antibody: 4.2.0 -> 4.3.1
b42 has quit [Ping timeout: 256 seconds]
edwtjo has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-dev
cole-h has joined #nixos-dev
edwtjo has joined #nixos-dev
edwtjo has joined #nixos-dev
edwtjo has quit [Changing host]
<domenkozar[m]> Nix now has a proper CI: https://github.com/NixOS/nix/pull/3409
<{^_^}> nix#3409 (by domenkozar, 4 hours ago, merged): Add CI with github actions
<gchristensen> woo!
<domenkozar[m]> crap, forgot to do weekly
<domenkozar[m]> oh well, Monday :)
<emily> fun effect of nix's conservative gc model #38234: you can't copy something into the initrd including its nix store hash for filename uniqueness
<{^_^}> https://github.com/NixOS/nixpkgs/pull/38234 (by r-ryantm, 1 year ago, merged): icoutils: 0.32.2 -> 0.32.3
<emily> because nix is like "nooo, your directroy references the nix store, it's not allowed to!"
ixxie has quit [Ping timeout: 258 seconds]
<emily> considering just obfuscating the hash somehow to spite this restriction
bhipple has quit [Ping timeout: 256 seconds]
bhipple has joined #nixos-dev
lovesegfault has quit [Ping timeout: 240 seconds]
lovesegfault has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
<abathur> gchristensen: ping? (re: shell linker)
<yorick> emily: well, you can include parts of the hash
<lovesegfault> gchristensen: how do you feel about applying nixpkgs-fmt to nixops and adding the check to the CI?
<aminechikhaoui> maybe a niksnut question: if I have a derivation where I do a couple of `cat` of large log files >5G, any idea what can cause `cat: write error: Resource temporarily unavailable`, looking in the internet it seems it has to do with non-blocking pipes or something like that but I'm not able to figure out the problem by looking at Nix src
<aminechikhaoui> anyone has some ideas ?
<gchristensen> lovesegfault: +1
<lovesegfault> alright, it's happening after https://github.com/NixOS/nixops/pull/1255
<{^_^}> nixops#1255 (by lovesegfault, 19 minutes ago, open): ci: move back to hand-written yaml
<niksnut> aminechikhaoui: where are you cat'ing to?
<gchristensen> niksnut: any chance I could get your thinking on a video call?
<niksnut> gchristensen: about what?
<gchristensen> about https://github.com/NixOS/nixops/pull/1245 :) adisbladis and I are thinking through some changes to it, and I think we could use your insight
<{^_^}> nixops#1245 (by grahamc, 6 days ago, open): Deploy Targets: Policy/Behavior-free Deployment Hooks (auto-rollbacks, drain events, etc.)
<aminechikhaoui> niksnut stdout or stderr
<aminechikhaoui> just plain cat in a failureHook
<aminechikhaoui> failureHook in LB builds if you remember :D
<niksnut> aminechikhaoui: that's a pseudo-tty nowadays, maybe it gets full or something
<aminechikhaoui> niksnut "nowadays" as in which nix version
<niksnut> however I think it should block
<aminechikhaoui> I think the pseudo-tty is for those fancy colored logs ? we don't have that version anyway
<niksnut> 2.3
<niksnut> gchristensen: I'll have to take a closer look at that PR first
<gchristensen> niksnut: sure, it is pretty simple -- but sounds good -- are you available today, later, or not really?
<emily> (docbook tips: the error "Element book has extra content: info" means you included <emphasis> in <literal>, of course)
drakonis has quit [Quit: WeeChat 2.7.1]
<vcunat> aminechikhaoui: I don't think that can happen without *something* switching that output to non-blocking mode. For example, we used to have this issue with Firefox builds utilizing nodejs which (at some version) did that https://github.com/nodejs/node/issues/14752
<aminechikhaoui> vcunat that output being the file I'm running cat on ?
<vcunat> aminechikhaoui: it's outputting to stdout or stderr, if I read your description right
<aminechikhaoui> yeah just a `cat somefile.log` in the failureHook
<aminechikhaoui> vcunat ^ so I guess you meant something switching stdout to non blocking ?
MichaelRaskin has joined #nixos-dev
bhipple has quit [Ping timeout: 258 seconds]
<vcunat> that could be a way (I'm not aware of any shell comand to do that), but normally it just should be in blocking mode (i.e. not be in non-blocking mode)
<aminechikhaoui> vcunat and also non-blocking stdout is the only problem that can cause "write error: Resource temporarily unavailable" so I should focus on figuring that out ?
MichaelRaskin has quit [Ping timeout: 255 seconds]
<vcunat> I don't know of any other way.
<vcunat> In C you can switch it off by a one-liner.
<vcunat> fcntl(1, F_SETFL, fcntl(fd, F_GETFL) & ~O_NONBLOCK);
<aminechikhaoui> I wonder if there is a command or some proc fs file that gives the flags of an open fd
<vcunat> (oops, I forgot to substitute fd=1 above)
<vcunat> But the fcntl(fd, F_GETFL) part returns those flags.
<vcunat> Just today I got surprised by this - in normal case of running a program in a TTY all the three file-descriptors point to the same file-description, so they share properties like O_NONBLOCK. (And we were switching stdin to O_NONBLOCK.)
MichaelRaskin has joined #nixos-dev
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 258 seconds]
tilpner_ is now known as tilpner
<MichaelRaskin> pie_: (sigh) do you think it would make sense to have a minimeeting?
ixxie has joined #nixos-dev
abathur has quit [Ping timeout: 255 seconds]
<ma27[m]> niksnut: do you have any concerns about disk usage in https://github.com/NixOS/nixpkgs/pull/80751 (this PR adds a `debug`-output to a few packages and Jan Tojnar referenced a comment from you where you mentioned this issue a few years ago)
<{^_^}> #80751 (by Ma27, 2 weeks ago, open): treewide: add a debug-output to a few packages
abathur has joined #nixos-dev
<niksnut> ma27[m]: thanks, I've added a comment
<ma27[m]> thx :)
<niksnut> gchristensen: do you still want to do a call?
_ris has joined #nixos-dev
<gchristensen> niksnut: if you can, in like 1h?
<niksnut> ok
vcunat has quit [Quit: Leaving.]
drakonis has joined #nixos-dev
<tokudan> do we have an issue with the channels? no channel has been updated within the last 3 days and as far as I can tell from hydra, there were several successful builds e.g. for 20.03-small within the last 24h
<niksnut> tokudan: looks like I forgot to restart the systemd timer that updates the channels...
<tokudan> niksnut, that's probably going to be a quick fix then. thanks for your work :)
<jtojnar> could we please get this changed to gnome-3.36 branch? https://hydra.nixos.org/jobset/nixpkgs/gnome#tabs-configuration
<gchristensen> jtojnar: on it
<gchristensen> done
tokudan has quit [Quit: Dunno.]
tokudan has joined #nixos-dev
<jtojnar> thank you Graham
bhipple has joined #nixos-dev
<gchristensen> yep!
bhipple has quit [Ping timeout: 255 seconds]
vcunat has joined #nixos-dev
bhipple has joined #nixos-dev
bhipple has quit [Remote host closed the connection]
bhipple has joined #nixos-dev
bhipple has quit [Ping timeout: 240 seconds]
bhipple has joined #nixos-dev
<gchristensen> niksnut: I'm pretty tired. let's postpone, and talk maybe during our regular Monday call?
<niksnut> sure
bhipple has quit [Ping timeout: 255 seconds]
<gchristensen> cool :) I need to let my brain congeal back together
bhipple has joined #nixos-dev
bhipple has quit [Ping timeout: 255 seconds]
<lovesegfault> adisbladis: do you think the poetry2nix approach could work with Cargo?
bhipple has joined #nixos-dev
<adisbladis> lovesegfault: I don't know rust well enough to say anything remotely intelligent about that
<ashkitten> lovesegfault: what is the poetry2nix approach?
<adisbladis> ashkitten: Pure Nix parsing & interpreting lock files
<lovesegfault> ashkitten: no nix code generation, building drvs in-flights
<lovesegfault> *in-flight
<adisbladis> lovesegfault: Locking at a Cargo.lock I'd say: not right now
<adisbladis> They need to add hashes.
<adisbladis> Or...
* lovesegfault raises eyebrow
<adisbladis> Hm
<adisbladis> I just didn't scroll long enough lol
<lovesegfault> yeah
<lovesegfault> :P
<adisbladis> lovesegfault: Do you know what the hash is over?
<adisbladis> A tarball, a git checkout somehow?
<lovesegfault> I think it's the tarball, gimme one moment
<jtojnar> is not that what the thing mentioned on nixcon does?
<lovesegfault> adisbladis: yeah I think it's a tarball
<adisbladis> jtojnar: This guy https://github.com/nmattia/naersk/ ?
<jtojnar> yup adisbladis, could not recall the name
* lovesegfault uses crate2nix
<adisbladis> Is Naersk using IFD?
<lovesegfault> adisbladis: define IFD
<adisbladis> ,IFD
<{^_^}> import-from-derivation (IFD) is when you evaluate nix from a derivation result, for example `import (pkgs.writeText "n" "1 + 1")` will evaluate to 2. This is sometimes problematic because it requires evaluating some, building some, and then evaluating the build result. It has been described as "such a nice footgun."
<lovesegfault> Input Flurry Dogs
<adisbladis> lol
<cole-h> Integrated Florida Drivers
<adisbladis> Using the lockfile approach is trivial with IFD
<adisbladis> Not so much if you want purity
<adisbladis> Poetry2nix was ~15x more work than I imagined...
bhipple has quit [Ping timeout: 265 seconds]
<LnL> adisbladis: reminds me, any chance that poetry2nix#71 looks straightforward to fix?
lovesegfault has quit [Ping timeout: 260 seconds]
zarel has quit [Ping timeout: 255 seconds]
zarel has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
<Profpatsch> adisbladis: 15 times seems about right
orivej has joined #nixos-dev
<Profpatsch> even yarn2nix was probably 10 times more than I imagined
<Profpatsch> adisbladis: when you can do IFD, not doing ifd is just a matter of committing the generated nix code instead of generating it on the fly …
<Profpatsch> of course you might want to generate somewhat optimized nix code in that case, not commit the normalized version
justanotheruser has joined #nixos-dev
<multun> anybody using nix in very very old production environments?
<multun> 2.6 kernel old
bhipple has joined #nixos-dev
zarel has quit [Read error: Connection timed out]
zarel has joined #nixos-dev
<genesis> i'd like, many projects would be interestin' with such old boy.
<genesis> (playstation 2, tomtom devices and so much)
bhipple has quit [Ping timeout: 260 seconds]
<vcunat> multun: very old kernels may be problematic with our glibc version
<{^_^}> #80961 (by veprbl, 2 weeks ago, merged): glibc: provide fallback for kernels with missing prlimit64
bhipple has joined #nixos-dev
<gchristensen> multun: like 2.6.32-754?
<gchristensen> like new-old, or old-old
<multun> new old
<multun> the same as yours actually!
<multun> aw awesome
<gchristensen> ye olde frakenkernel
<multun> rhel6 is actually my target system
<adisbladis> They don't make em like they used to
<gchristensen> what, 750-patch-deep kernel forks?
<adisbladis> gchristensen: That's basically android
<gchristensen> "great"
<adisbladis> Though in their defense the android project is trying to move towards mainline
<drakonis> it has already moved towards mainline
<drakonis> surprisingly enough
<samueldr> it's about to happen the same year as the year of the linux desktop
<samueldr> android is still far from mainline
<adisbladis> samueldr: But I've been running linux on the desktop for the last 16 years
<samueldr> adisbladis: stop fooling yourself :)
<gchristensen> lol
<drakonis> oh? that's a surprise
<drakonis> they made a big hubhub about being able to track lts releases
<samueldr> the devices you get are not tracking the kernels, that's only the first layer of "dumping" that gets in android device kernels
<samueldr> the SoC vendors, then the misc. parts vendors all add up to that
<adisbladis> At least now the Pixel series is using DRM
__monty__ has quit [Quit: leaving]
<samueldr> those are not mainlined
<drakonis> oh that's a different situation
<drakonis> that's the unfortunate thing.
<samueldr> how come?
<samueldr> that's exactly what mainlining should be
<samueldr> all parts of the kernels in the end-user product be in the mainline tree
<samueldr> there's that scrappy little startup that does it
<samueldr> the chromeos team at google
<drakonis> ah yes, that sort of mainlining
<drakonis> fair enough.
<drakonis> i thought you meant tracking the latest kernel instead of mainlining drivers
<samueldr> adisbladis: yeah, that's nice, I have a DRM-using device here, though not ready for development
<samueldr> hopefully it'll help some
<adisbladis> samueldr: Your pinephone ?
<samueldr> nope, android device
<samueldr> razer phone
<adisbladis> Ah, nice
<adisbladis> I didn't know any others were on DRM yet
<vcunat> multun: rhel6 might work - if not, ping e.g. that pull request (with a link to a newly created issue, perhaps)
<samueldr> pretty sure newly developed platforms will be
<samueldr> though [citation needed] :)
<samueldr> maybe it's due to the fact it has eDP out
vcunat has quit [Quit: Leaving.]
lovesegfault has joined #nixos-dev
bhipple has quit [Read error: Connection reset by peer]
ixxie has quit [Ping timeout: 258 seconds]
justanotheruser has quit [Ping timeout: 240 seconds]