<thoughtpolice>
Finally got my GPG setup working again and now I have that sweet 'verified' badge.
<thoughtpolice>
Need to recover and issue revocations for my old keys, now...
<teto>
wait nix is not participating to Gsoc :'that's too
<teto>
bad I could have helped with the administrative stuff
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-dev
<domenkozar>
any nix news for weekly? :)
<domenkozar>
gchristensen: did you manage to rerun r13y?
<domenkozar>
I guess from staging :)
<domenkozar>
oh I hope he's sleeping
<domenkozar>
:grin:
ivan has quit [Quit: lp0 on fire]
harrow has quit [Quit: Leaving]
ivan has joined #nixos-dev
harrow has joined #nixos-dev
ivan has quit [Quit: lp0 on fire]
harrow has quit [Client Quit]
ivan has joined #nixos-dev
harrow has joined #nixos-dev
v0|d has joined #nixos-dev
<ckauhaus_>
sphalerite: I have to go to another meeting this afternoon, so my time slot is only 1330 UTC till 1400 UTC
<ckauhaus_>
but I think we should be able to cover the most importants topics during the first half hour
<sphalerite>
alright. Ideally we'll be finished by then, failing that you can just jump out :)
e-user has joined #nixos-dev
ckauhaus_ is now known as ckauhaus
v0|d has quit [Remote host closed the connection]
primeos_ has quit [Quit: WeeChat 2.3]
primeos has joined #nixos-dev
init_6 has joined #nixos-dev
init_6 has quit []
init_6 has joined #nixos-dev
<teto>
I would like to reduce impurities in the kernel (make the config depend on package requirements). Not sure where and how to store package requirements : meta.requiredKernelConfig ? Looking for some feedback in https://github.com/NixOS/nixpkgs/issues/41103#issuecomment-463119193
init_6 has quit [Ping timeout: 246 seconds]
init_6 has joined #nixos-dev
FRidh has joined #nixos-dev
<gchristensen>
domenkozar: nothing spectacular has changed, many of the changes went in to staging-next
<tilpner>
While it's feasible for the user to adjust the rules for applications with few responsibilities, it would require a lot more structure and coordination to properly wrap any desktop application
<tilpner>
And I wrote pbServe myself, so I know exactly what it does (very little), and what to allow
<tilpner>
So I wouldn't try this on e.g. Firefox
<tilpner>
(And the rlimit arg was probably a bad choice, that should happen in the systemd service, not via apparmor)
<gchristensen>
right
<gchristensen>
ok the new r13y.com report is up https://r13y.com/ dropping to 97.99% (wavering is to be expected as things which happened to reproduce before don't this time)
<andi->
:+1:
<tilpner>
"unfairly closed source software" :o
<qyliss>
So how does this meeting thing work?
ciil has quit [Remote host closed the connection]
<gchristensen>
sphalerite: ^
<sphalerite>
qyliss: see the link on "location" in the calendar thingy
ciil has joined #nixos-dev
<gchristensen>
qyliss: you can click the no-video thing if you'd like
orivej has quit [Remote host closed the connection]
<domenkozar>
gchristensen: how come the new diffoscope is not in the report? :)
<domenkozar>
Generated by diffoscope 99
<domenkozar>
:(
<gchristensen>
hmmmm
<domenkozar>
pinned nixpkgs?
<gchristensen>
oops, I used my local nixpkgs instead of nixos-unstable-small :)
<domenkozar>
so unpinned :D
<gchristensen>
yep
<gchristensen>
I'm doing a re-check now, so don't really have any cpu or ram to spare for running diffoscope again
<domenkozar>
no worries
<gchristensen>
but once it is done (5-6hrs or so) I'll make sure to regenerate with the new one
<sphalerite>
gchristensen regenerates? Like the Doctor?
<gchristensen>
these RFC meetings leave me feeling invigorated!
<domenkozar>
> give strength or energy to.
<{^_^}>
error: syntax error, unexpected ')', expecting ID or OR_KW or DOLLAR_CURLY or '"', at (string):219:1
<qyliss^work>
Great, thank you! We don't get many patches this way, so people might not see it, but it's important to me that people don't have to use GitHub so I'll try to make sure this gets through.
<{^_^}>
#53672 (by eadwu, 5 weeks ago, open): switch-to-configuration not interpreted using perl
<dtz>
oh I thought you found the commit, sorry! Don't mean to put words in your mouth. Happened on my laptop and nixops-controlled machine and sure seemed to start happening with 4.20.8 (and not 4.20.7)
<dtz>
brb git
<samueldr>
dtz: aszlig tracked it down (see the upstream issue)
<samueldr>
(wasn't doubting, just assessing the situation, because it could become a large thorn on our side)
<gchristensen>
tilpner: macOS doesn't support scripts as shebangs
<tilpner>
gchristensen: So then we compile them? This doesn't get any prettier :(
<samueldr>
this is a situation where the kernel is breaking userland, and I'm like 99% sure we shouldn't have to deal with gnarly hacks :/
<gchristensen>
1) revert the upgrade in nixpkgs
<gchristensen>
2) aszlig halp
<dtz>
xD <3
<samueldr>
oh no! 4.14.y too?
<samueldr>
I need to go back to $workthing-which-is-not-nixpkgs-nor-linux-related
<ekleog>
we could automatically compile a program that just does `execve` with the right arguments, but… that'd mean requiring `gcc` for writing any shebang :(
<gchristensen>
and would cause a significant performance drop
<tilpner>
I wonder if it could be done by patching a precompiled binary
<tilpner>
But even if that was possible, it's still really ugly and severely hinders debugability
<ekleog>
it's one more `execve`, do you think it'd be actually significant?
<tilpner>
Which isn't that great to start with
<gchristensen>
it isn't 1 more, it is 1 more per exec
<gchristensen>
so, 2x :)
<ekleog>
indeed
<qyliss^work>
Is this a different bug to spaces in shebangs?
<ekleog>
tilpner++, was thinking about patching a prebuilt binary
<{^_^}>
tilpner's karma got increased to 15
<ekleog>
it's potentially non-trivial, though
<ekleog>
gchristensen: even 2x for the execve, there'd be for sure a performance drop, but do programs actually `execve` scripts often?
<tilpner>
ekleog: It could also be "#!/nix/store/*-exec-wrapper /nix/store/*-exec-wrapper-args-foo", and it would read args-foo and execute them. No patching, and constant shebang length
<ekleog>
(and it's still better than the script-in-shebang option, that'd have spin-up and tear-down of a script)
<gchristensen>
if this were a voting thing
<ekleog>
tilpner: that's too long, though, isn't it?
<gchristensen>
I'd vote we not discuss workarounds, and instead brainstorm ways to get appropriate attention on the issue, and work first to get it fixed
<ekleog>
hasn't that already failed? I mean, if the patch has even been backported then the breaking change is already done, whatever we can say about it, isn't it?
<samueldr>
the kernel never breaks userland
<ekleog>
except when it's “fixing a kernel bug”
<samueldr>
they probably haven't noticed the bug in the tracker
<samueldr>
pretty sure that here it's not a case where they're fine breaking userland
<tilpner>
ekleog: Well, it's closer than comfortable
<tilpner>
Which is < 128, which is what my BINPRM_BUF_SIZE is set to
<tilpner>
Longer names, and (more importantly) longer storeDir prefixes... and it breaks
<ekleog>
tilpner: then it's possible indeed (thought it was set to 64 by default)
<ekleog>
maybe we should ask the person who r+'d the backport about our issue
<samueldr>
(and note that the workaround assumes /nix/store; if I were to /var/lib/some-businessy-longish-string/nix/store it would fail)
<gchristensen>
"If you suspect a maintainer is notresponding to these types of bugs in a timely manner (especially during amerge window), escalate the bug to LKML and Linus Torvalds."
* ekleog
wonders how bad it would be to drop NARs and use tar. We'd have to write a custom executable that would build the tar in a reproducible way, but would that be worse than having a custom executable that builds the NARs?
<ekleog>
worst thing would likely be the churn :/
<ekleog>
like, how to introduce tar fetching support in nix, and only in years stop building nars and build tars instead
<gchristensen>
NARs are pretty cool
<ekleog>
the good point would that then we'd be extensible like tar is, ie. we could include support for sparse files without having to patch the fetching side
<ekleog>
are they?
<gchristensen>
thy support way less than tar
<ekleog>
they do, which is exactly the issue in this case (of handling sparsity)
<gchristensen>
like I don't think it is really possible for a tar to express a file should exist outside of its destination dir
<gchristensen>
using tar, which supports way more, makes it way more risky
<ekleog>
it definitely is, but we're already having `builtins.fetchTarball`, I don't see in what way it'd be worse
<gchristensen>
fetchTarball doesn't write in to /nix/store
<gchristensen>
anyway, yeah
<ekleog>
well, fetching a nar could write to someplace else in the sandbox and nix move it afterwards :)
<ekleog>
(basically using the same level of sandboxing than fetchTarball & co)
<gchristensen>
couldn't hurt
<ekleog>
erhm, s/nar/tar/ actually as I was thinking of the “let's switch to tar” 15-year plan, but it could do for nar's too
<tilpner>
Could hurt, on small devices with small /tmp
<gchristensen>
oh NARs also can't express things like setuid etc.
<ekleog>
if the nar download is done in a sandbox, nix's steps in moving it out of the sandbox will erase the setuid bit etc. anyway :)
<ekleog>
tilpner: I wonder how nix currently handles nar download… just-in-time decompression?
<zimbatm>
is anyone looking at generating switch-to-configuration without the huuuge shebang?
<tilpner>
zimbatm: Could try a buildEnv, instead of passing each dependency individually
* tilpner
knows nothing about perl packaging
<samueldr>
it's most likely something rooted in the perl infra of nixpkgs, rather than switch-to-configuration specific
<gchristensen>
https://r13y.com/ new report is up -- 98.15% after 2 previous unchecked paths were checked (and the diffoscopelinks are improved -- generated with diffoscope 110, domenkozar)
<tilpner>
gchristensen: What's the one remaining unchecked path?
copumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<tilpner>
I looked at the groff manpages, their manpages use @MDATE@
<tilpner>
How should this be fixed?
<tilpner>
Patch it out in nixpkgs? faketime?
<gchristensen>
protip: googling "MDATE" turns up a millionaire dating website.
<gchristensen>
what is @MDATE@?
<tilpner>
(Tell upstream of the benefits of... not doing this?)
<tilpner>
Probably modification date
<tilpner>
Which is what causes the current date to appear in the built manpages
<gchristensen>
I'd look in the /tmp/nix-build-... dir for its build and see if @MDATE@ is defined in the configure script. if so, fix the configure script. if not, check debian's groff package to see if they have a patch, failing that, use a substitution thing to dejlete it :P
<tilpner>
Fix this, and groff.man --checks
<tilpner>
-e "s|@MDATE@|$(mdate)|g" \
<tilpner>
Ahh, their Makefile does this
<tilpner>
But what do we want it to say?
<tilpner>
No date? Jan 1 1970?
<gchristensen>
perfect, replace with 01 January 1970
<gchristensen>
yeah
<gchristensen>
tilpner++
<{^_^}>
tilpner's karma got increased to 16
<tilpner>
.TH roff2dvi 1 "13 February 1969" "Groff Version 1.22.3"
<gchristensen>
samueldr: is this right? --- the important part of the shebang, ie: the executable path, was less than the maximum length, so the remainder would be truncated or not -- whatever -- it makes no difference... but then perl would come along and reread it and find the good stuff. but, now that the kernel doesn't truncate, and fails instead ... well, perl doesn't have the opportunity
drakonis has joined #nixos-dev
catern has joined #nixos-dev
<catern>
I'm going to start actually working on https://github.com/NixOS/nix/issues/1734 does anyone have any opinions about how to approach it? I'd like to do option 4, but that requires some non-trivial enhancements to the daemon protocol, so I might just do it totally locally, but then that requires the Nix client to walk the whole build tree itself... which is easy, but inelegant, and maybe unacceptably inefficient?
<{^_^}>
nix#1734 (by catern, 1 year ago, open): Add a mechanism for untrusted users to offload builds of fixed-output derivations
<samueldr>
gchristensen: I don't know if it's *right*, but I remember hearing this or something along the line
<samueldr>
I don't know where
<gchristensen>
it feels right
<gchristensen>
does volth do IRC?
<srhb>
gchristensen: I've never seen them with that name on freenode at least.
<gchristensen>
despite their gives-me-creeping-skin avatar, they're our perl person! :)
<tilpner>
With all those rebuilds, nobody will merge it just to fix some indeterminism
<gchristensen>
tilpner: do you know how to re-point it to staging?
<gchristensen>
beyond need ing to go to staging, the diff lgtm
<tilpner>
No, but I'll try anyway
<gchristensen>
tilpner: here is how I do it: while on the branch, `git fetch origin; git reset --hard origin/staging; git cherry-pick a23a4b5af7608f615ef6212e106c5cc395665934; git push myfork mybranch --force`
<tilpner>
Oh no
<gchristensen>
uh oh
<tilpner>
I trusted you :/
<gchristensen>
what happened
<tilpner>
I requested reviews from everyone
<gchristensen>
what'd I delete
<gchristensen>
oh no worries, we'll fix that shortly
<LnL>
that's unavoidable
<LnL>
gchristensen: oh?
<tilpner>
Oh, you can do that?
<gchristensen>
we'll as in, I'll, as in, I just deleted all the requseted reviews and pointed it to staging :P