drakonis has quit [Remote host closed the connection]
drakonis has joined #nixos-dev
ris has quit [Ping timeout: 245 seconds]
kenjis1 has quit [Ping timeout: 245 seconds]
ivan has left #nixos-dev [#nixos-dev]
lovesegfault has quit [Ping timeout: 252 seconds]
lovesegfault has joined #nixos-dev
<infinisil>
Hm well this is unfortunate, I'm just noticing that static uid's would be kind of useful for zfs snapshots
<infinisil>
E.g. when you send a dataset from one machine to another, zfs can't and won't do any uid transformations
<infinisil>
So the uid's may just be completely off
<gchristensen>
static UIDs are a good idea for the principle of reproducibility
<infinisil>
Sure, but what I mention is a case where static uids seems like the only reasonable solution
<gchristensen>
sure
Taneb has quit [Quit: I seem to have stopped.]
<infinisil>
In a practical scenario at least
<gchristensen>
I mean, I 100% agree and it is the same essential case I mentioned when we first started moving away from them for less stateey services :)
<infinisil>
They do come with their problems, but I guess they do have their uses too
Taneb has joined #nixos-dev
<infinisil>
Why can't files just have a user*name* associated with them instead of ids :(
<gchristensen>
is that name stored in EBCDIC, ASCII, UTF-8, UTF-16, EUC-KR, or does it depend on the locale of the user?
<gchristensen>
and then there is LDAP of course :P
<samueldr>
hmm, what would be the cleanest way to refer to `buildPackages.whatever_the_real_attrname_of_the_python_argument_is` in a derivation would be?
<samueldr>
python is being parameterized as "python", buildPackages.python is not necessarily the one given to the args
<infinisil>
samueldr: Doesn't mkDerivation do some splicing action to implement nativeBuildInputs like that?
<samueldr>
yeah, but that's it, only in those special attributes
* samueldr
preps the commit
<infinisil>
Not on my pc right now, but i think there might be some attribute under python.* for that
<infinisil>
Maybe starting with _
<samueldr>
okay, here I had a specific example, so I used that, and it turns out that for *this* example there's an escape hatch :/
<samueldr>
.pythonForBuild
<samueldr>
(I think)
<samueldr>
looks like I don't have the need again, but that would be an unsolved issue, splicing when it used in something like makeFlags
<samueldr>
(unsolved to me)
<infinisil>
Alternative idea: Use the buildPackages versions for everything. When the package is build, replace all runtime dependencies with their non-buildPackages versions
<infinisil>
built*
<infinisil>
(As in, after it is built)
<infinisil>
Hm though not sure if that works with linking
<samueldr>
I think the same issues would exist, but on the other side of the coin
<samueldr>
so instead of requiring buildPackages something we'd need the hostPackages(?) one
<infinisil>
The idea is to push this decision to build time when we have the information on runtime deps
<infinisil>
Instead of at eval time
bhipple has quit [Remote host closed the connection]
tv has quit [Ping timeout: 265 seconds]
tv has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.6]
zarel has quit [Ping timeout: 260 seconds]
zarel has joined #nixos-dev
Jackneill has joined #nixos-dev
pepesza has quit [Ping timeout: 265 seconds]
FireFly has quit [Quit: Goodbye]
FireFly has joined #nixos-dev
pepesza has joined #nixos-dev
__monty__ has joined #nixos-dev
<domenkozar[m]>
do we just remove unar from blocking the release?
<domenkozar[m]>
it seems weird to have a random package in there
<LnL>
doesn't seem like something that should block to me
<Taneb>
I agree
<Taneb>
(although I do want to fix the thing that's breaking it)
<LnL>
sure, but it seems very specific to just that one package
<LnL>
and I have no idea how to fix that
<Taneb>
I've been trying to package something else which relies on GNUstep
<LnL>
gnustep-make has a similiar setup and that's actually used by a bunch of stuff IIRC
<domenkozar[m]>
most likely bumping clang for stdenv will fix it
<domenkozar[m]>
but I haven't tried it
<LnL>
it's not clang tho
<LnL>
problem is with binutils I think
<LnL>
or whatever else the clang stdenv from linux inherits from gcc
<domenkozar[m]>
that symbol comes from binutils?
<domenkozar[m]>
oh you mean the linker?
kenjis1 has joined #nixos-dev
kenjis1 has quit [Remote host closed the connection]
kenjis1 has joined #nixos-dev
kenjis1 has quit [Remote host closed the connection]
kenjis1 has joined #nixos-dev
ixxie has joined #nixos-dev
<LnL>
yeah, it's the linker that can't find a glibc symbol for some reason
kenjis1 has quit [Remote host closed the connection]
<yorick>
is anyone still interested in our acme.sh module?
<__monty__>
There's 12 noreply addresses already present in the maintainer-list fyi.
<qyliss>
I figure email should either be optional, or there should be an expectation it's set to a valid address.
<qyliss>
And since it's not currently optional...
<gchristensen>
there are other maintainers without an email unfortunately
<qyliss>
With the email attribute just omitted?
<__monty__>
Does github bounce messages to these addresses? Or are people using them as aliases in case their personal email changes?
<qyliss>
They don't forward mail
<qyliss>
IDK if they bounce or just swallow
FRidh has joined #nixos-dev
psyanticy has joined #nixos-dev
drakonis has joined #nixos-dev
<qyliss>
gchristensen: do you know what the email addresses are used for? Anything?
<gchristensen>
sometimes I email people
<gchristensen>
it is good to be able to contact people in case there are questions about contributions
<qyliss>
What do you think I should do with this PR?
<qyliss>
Should we still *require* email addresses?
<gchristensen>
not sure, are they abandoning that yandex address?
<qyliss>
It doesn't sound like it
<qyliss>
It sounds like they just don't want to be contacted by email
<gchristensen>
then it doens't seem like there is much point to their PR
<gchristensen>
I guess it is probably not the end of the world, it is just more work for if we do need to email them
<qyliss>
I'm inclined to say there needs to be some way of contacting maintainers in private
<gchristensen>
I agree
<gchristensen>
if we needed to we'd spelunk through commit history to find their address
<etu>
And github (surprisingly enough) doesn't have any way to contact people in private on their platform.
<gchristensen>
it sure does side-step the "abuse in the DMs" problem
<etu>
I can also see why since that would be another source for spam etc that they would have to deal with.
<qyliss>
gchristensen: What do you think of "It's important that there be some way to contact maintainers privately if necessary. If you don't want to use the email address currently in maintainer-list.nix for that, please replace it with a different one that could be used instead."?
<gchristensen>
sure
<gchristensen>
though qyliss
<gchristensen>
maybe include a note that this of course will stay in the history forever, so there is no actual deleting this email
<qyliss>
done
<qyliss>
gchristensen: fwiw, some people do use the GitHub noreply addresses in commit logs as well
bgamari_ has joined #nixos-dev
bgamari has quit [Ping timeout: 248 seconds]
<Taneb>
FRidh: I don't think #76927 should have been closed, although its importance has reduced a lot with unar's removal from the "blocks nixpkgs" list, the issue itself has not been solved
<Taneb>
Sorry for being accusational, I assumed it was intentially closed :(
ixxie has quit [Ping timeout: 258 seconds]
ixxie has joined #nixos-dev
* gchristensen
puts up the vcunat-signal
vcunat has joined #nixos-dev
drakonis has quit [Ping timeout: 245 seconds]
drakonis has joined #nixos-dev
<Profpatsch>
qyliss: We should respect users wishes to remove private data though.
<Profpatsch>
They can still be contacted through mentions.
<gchristensen>
we essentially can't remove their data
<Profpatsch>
*from the current version of the code
<Profpatsch>
It removes the data from any nixpkgs tarball from that point on.
<Profpatsch>
“You can’t remove any trace of it so we won’t remove it from the surface” is a bad precedent to set :)
<Profpatsch>
s/any trace/all traces/
<Profpatsch>
Stuff that uses the github search e.g. won’t find it after.
ixxie has quit [Ping timeout: 265 seconds]
<clever>
output '/nix/store/pzs3wbk19vx3rbvr0kyimwajky9rz7z7-ghc-8.6.5-with-packages' of '/nix/store/wwcnqxnha5il5jbn1y5s5885if30w3v0-ghc-8.6.5-with-packages.drv' differs from previous round
<clever>
gchristensen: call the reproducability police!
<gchristensen>
oh boy
<Taneb>
Hasn't Haskell had issues with reproducability for a long time?
FRidh2 has joined #nixos-dev
<clever>
Taneb: this is basically just a buildEnv with a cache update
FRidh has quit [Ping timeout: 265 seconds]
<Taneb>
Ah, right
<clever>
it may be putting timestamps into that cache
<clever>
but its a fairly simple step
ciil has quit [Ping timeout: 268 seconds]
ciil has joined #nixos-dev
<clever>
output '/nix/store/722j70s9f9ykwgphnvygya98lynsiybb-plex-media-player-2.40.0.1007' of '/nix/store/ib2fyzp2ddxqmwikq4piy13pc4fl6b6x-plex-media-player-2.40.0.1007.drv' differs from previous round
<clever>
gchristensen: and this one is c++ based, and the source is on github
<qyliss>
Profpatsch: certainly, but we have clearly at some point made the decision that maintainers be required to list an email address. If they don't want to list an email address, they probably shouldn't be a maintainer, or we should change that policy.
<gchristensen>
qyliss++
<{^_^}>
qyliss's karma got increased to 25
ixxie has joined #nixos-dev
<Profpatsch>
qyliss: Then let’s re-evaluate the policy :)
<gchristensen>
I think it is a good policy
<gchristensen>
it is important to be able to reach contributors in case there are questions about contributions, possibly legal questions
<qyliss>
I don't have strong feelings, but lean towards requiring email address.
<Profpatsch>
Do we have it written down somewhere?
<qyliss>
Actually gchristensen good point re legal and stuff. Now I'm more in favour of it.
<qyliss>
Profpatsch: maintainer-list.nix says email is a required field
<qyliss>
I interpreted that to mean there must be some reason to have emails, and that therefore a fake address wouldn't be okay.
phreedom has quit [Quit: No Ping reply in 180 seconds.]
phreedom has joined #nixos-dev
<Profpatsch>
qyliss: Well, we don’t have an official stance on that yet apparently. We can introduce it if we want.
<Profpatsch>
But we can’t enforce it technically.
<adisbladis>
Also emails are the best vendor-neutral identifier we have atm
<adisbladis>
Always good fora a project of our size to have backup contact options in case something happens to github
<Profpatsch>
Time to create an RFC then
<qyliss>
There's no need for an RFC
<qyliss>
This is the status quo
<infinisil>
Profpatsch: When a PR is merged that adds a maintainer mail, send an email to verify it, if verified within 24 hours a bot auto-commits a signed statement confirming it, otherwise the whole PR is rolled back :P
<Profpatsch>
infinisil: Let’s write an ACME-like protocol for that -.-
<Profpatsch>
With monthly re-queries and turing test that has to be answered to be sure it’s a human replying!
<clever>
lol
<Profpatsch>
qyliss: Then let’s add it to the maintainers-list and ping the people with obviously fake/noreply mail addresses.
<qyliss>
That sounds like a sensible thing to do.
<infinisil>
Profpatsch: A couple weeks ago I wanted to send eelco an email, but it turned out his email in the maintainers list was outdated and invalid by now, so I had to figure out a valid one and resend the mail
<infinisil>
Periodic requeries might not be such a bad idea
<infinisil>
Many entries in that list might be super outdated
<Taneb>
Even regular outdated is bad enough
<adisbladis>
Regular checkups is also not a bad metric for maintainer auto cleanup
kenjis1 has joined #nixos-dev
<infinisil>
Hm but maintainers != committers. We'd want to clean up committers but not necessarily maintainers
<qyliss>
It doesn't make sense to have inactive maintainers either
<qyliss>
Being a maintainer is a commitment
<infinisil>
Yeah I'm not sure what to do with maintainers that don't verify their email in the e.g. yearly checkup
ixxie has quit [Ping timeout: 258 seconds]
<infinisil>
Maybe just mark as "inactive"
<infinisil>
But not sure what that gets us either
<qyliss>
I'd just drop them.
<adisbladis>
infinisil: Remove them, they have another chance to notice they are being removed in the PR
<adisbladis>
Also reinstating someone should be easy
<adisbladis>
qyliss++
<infinisil>
maintainers are in meta.maintainers though
<{^_^}>
qyliss's karma got increased to 26
<infinisil>
Would have to go through all expressions and remove them there
<adisbladis>
infinisil: I'm sorry I overloaded the terms. I mean people with nixpkgs commit bit.
<qyliss>
But this is a completely different conversation from "should package maintainers to provide an email address"
<infinisil>
Yeah, but it's a bit related, since all committers should probably be listed in the maintainers file too
<gchristensen>
having it written in the maintainer-list.nix means there IS an official stance fwiw
<qyliss>
The official stance could be clarified
<qyliss>
"Email is a required field" isn't quite as clear as "you must provide an email address where you can be reached"
<qyliss>
Even if it follows if you think about it for a minute
<yorick>
there's a bunch of committers
<infinisil>
Does nixos.org have a mailserver that could be used to verify addresses?
<gchristensen>
no
<yorick>
including a bunch of people who I would not give push rights :P
eraserhd has left #nixos-dev ["WeeChat 2.7"]
mmlb has joined #nixos-dev
drakonis has quit [Ping timeout: 260 seconds]
phreedom has quit [Quit: No Ping reply in 180 seconds.]
phreedom has joined #nixos-dev
ryantm has quit [Ping timeout: 240 seconds]
Jackneill has quit [Remote host closed the connection]
mrCyborg has joined #nixos-dev
vcunat has quit [Quit: Leaving.]
<gchristensen>
`r13y check` creates a .json report and a directory of NARs. these'd need to be uploaded somewhere, and then fetched on the system which creates r13y.com. all good, none of this should be too tricky
<gchristensen>
next, the layout of the website is heavily designed towards a single jobset being checked. probably not so hard to fix :)
<LnL>
what about just 1 initial run?
<gchristensen>
sure, that could be made to happen
<gchristensen>
on nixos foundation equipment perhaps even
<LnL>
do you know how far I could get with just --option repeat?
<gchristensen>
if we're going to do it, I'd really like to do it on a regular basis -- and this also sort of feels ilke a moment where we could start implementing the more distributed execution plan of r13y
<LnL>
right, I also wanted to make something like that for sandboxing
<gchristensen>
yeah
<gchristensen>
r13y already uses the message formats for this stuff -- it just is all done locally, and serialized to json :)
<LnL>
would be great to know how far we get with the relaxed sandbox-paths, if the percentage is high enough we could enable it by default like on linux
<gchristensen>
yeah, that would be great
<gchristensen>
we could set up a mac in hydra with that enabled, and make a jobset with a feature which forced builds to that mac
<LnL>
oh hmm
<gchristensen>
copumpkin is gifting 3 macs soon, even, so we could do it without taking away from the regular jobsets
<LnL>
that sounds like a great option then :D
<gchristensen>
:)
ixxie has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
<LnL>
actually doesn't hydra also support build-repeat?
<gchristensen>
yeah it does
<gchristensen>
and there is a jobset for it too
<gchristensen>
so we could even do both in a single go if you wanted
<LnL>
maybe I can use that for an initial local run then
<gchristensen>
cool
<gchristensen>
it is helpful to start with a small core, so a build-repeat-enabled jobset of just stdenv would be a good start
<gchristensen>
that way if we achieve, say, 90% reproducible stdenv that is a milestone we can be proud of and work on to improve, before branching out and seeing a million packages unreproducible
justanotheruser has joined #nixos-dev
FRidh2 has quit [Quit: Konversation terminated!]
<LnL>
yeah definitely
mrCyborg has quit [Ping timeout: 260 seconds]
<LnL>
using --option check on darwin also requires hash rewriting so that probably makes it even harder to reproduce
<gchristensen>
joyous
ixxie has quit [Ping timeout: 240 seconds]
<LnL>
actually, it would be better if builds where tested across 2 hosts, comparing the two
<gchristensen>
yeah, that is why I setup r13y as a separate thing
<LnL>
things like LC_UUID are consistent when checked on the same machine
phreedom has quit [Ping timeout: 240 seconds]
phreedom has joined #nixos-dev
ixxie has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
ris has joined #nixos-dev
mrCyborg has joined #nixos-dev
psyanticy has quit [Quit: Connection closed for inactivity]
* aristid
is surprised that no opencollective expenses have been submitted since october
<clever>
Ericson2314: ive noticed that when vc4-elf-gcc is linking, it can find libgcc.a, but when vc4-elf-ld is linking directly, it cant, what would usually cause this?
<clever>
is it normal for the cross ld to ignore $NIX_LDFLAGS?
<Ericson2314>
no it should not ignore NIX_LDFLAGS
<clever>
[nix-shell:~/apps/rpi/lk]$ type vc4-elf-ld
<clever>
vc4-elf-ld is /nix/store/8cm6vq4xz8sfp8ngi519xp0zfyyj7a4r-vc4-elf-stage-final-gcc-debug-wrapper-6.5.0/bin/vc4-elf-ld