supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
teto has quit [Ping timeout: 246 seconds]
__monty__ has quit [Quit: leaving]
rajivr has joined #nixos-dev
<abathur>
<3 jtojnar
<{^_^}>
jtojnar's karma got increased to 65
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
lukegb has quit [Quit: ~~lukegb out~~]
lukegb has joined #nixos-dev
<supersandro2000>
Am I the only one who sometimes needs to refresh github 3 times before I can merge a PR?
<aterius>
No, it happens to me a lot too on other repos
<supersandro2000>
if github wasn't that slow to load...
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 265 seconds]
tilpner_ is now known as tilpner
kalbasit_ has joined #nixos-dev
<abathur>
hah, crap
cole-h has quit [Ping timeout: 264 seconds]
<abathur>
start to update bats, looks like two steps in the existing patchPhase may be obsolete, remove them thinking nixpkgs-review should make it obvious if this causes trouble: 2 packages updated: bats (1.2.0 → 1.2.1) resholve
Raito_Bezarius has quit [Ping timeout: 260 seconds]
Raito_Bezarius has joined #nixos-dev
jonringer has quit [Remote host closed the connection]
jonringer has joined #nixos-dev
kalbasit_ has joined #nixos-dev
kalbasit__ has quit [Ping timeout: 240 seconds]
mkaito has quit [Quit: WeeChat 3.0]
kalbasit_ has quit [Ping timeout: 256 seconds]
copumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
orivej has joined #nixos-dev
kalbasit has quit [Ping timeout: 240 seconds]
cole-h has joined #nixos-dev
saschagrunert has joined #nixos-dev
saschagrunert has quit [Read error: Connection reset by peer]
saschagrunert has joined #nixos-dev
jonringer has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 246 seconds]
teto has joined #nixos-dev
orivej has joined #nixos-dev
saschagrunert has quit [Remote host closed the connection]
saschagrunert has joined #nixos-dev
saschagrunert has quit [Remote host closed the connection]
saschagrunert has joined #nixos-dev
<sphalerite>
https://github.com/zlib-ng/zlib-ng this looks like something that would be nice to have in nixpkgs and maybe evaluate for replacing zlib entirely
<sphalerite>
I've put it on my projects list to package it and see if the nixos tests still work, but if someone else beats me to it I have no problem with that :p
<supersandro2000>
but is it actually faster?
srk has quit [Ping timeout: 240 seconds]
<sphalerite>
well, that's part of evaluating it :)
thibm has joined #nixos-dev
hexa- has quit [Ping timeout: 258 seconds]
thibm has quit [Ping timeout: 240 seconds]
thibm has joined #nixos-dev
saschagrunert has quit [Remote host closed the connection]
saschagrunert has joined #nixos-dev
hexa- has joined #nixos-dev
cole-h has quit [Ping timeout: 246 seconds]
saschagrunert has quit [Remote host closed the connection]
saschagrunert has joined #nixos-dev
cstrahan has quit [Ping timeout: 244 seconds]
cstrahan has joined #nixos-dev
thibm has quit [Ping timeout: 240 seconds]
thibm has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
__monty__ has joined #nixos-dev
andi- has quit [Ping timeout: 260 seconds]
thibm has quit [Ping timeout: 256 seconds]
thibm has joined #nixos-dev
andi- has joined #nixos-dev
thibm has quit [Ping timeout: 264 seconds]
thibm has joined #nixos-dev
orivej has joined #nixos-dev
jonringer has joined #nixos-dev
supersandro2000 has quit [Quit: Ping timeout (120 seconds)]
supersandro2000 has joined #nixos-dev
WilliButz has quit [Ping timeout: 240 seconds]
WilliButz has joined #nixos-dev
<qyliss>
Profpatsch: is there a reason you didn't merge #109017 yet?
<qyliss>
Profpatsch: awesome -- I can see it on the graph now :)
<Profpatsch>
haha, yes, very small dip
<Profpatsch>
I’m waiting for haskellPackages to be regenerated ):
<Profpatsch>
:)
<qyliss>
oh did the cabal2nix PR get merged?
<qyliss>
oh, no
<infinisil>
We should really split up these huge files. Iirc git stores a full copy of the file for every change
<gchristensen>
nah, it stores deltas
<qyliss>
no, it stores full copies
<gchristensen>
orly?
<qyliss>
yeah
<supersandro2000>
git should store full files compressed
<qyliss>
it combines them into packfiles and compresses them
<qyliss>
so it shouldn't make too much of a difference
<supersandro2000>
the deltas are calculated at runtime
<qyliss>
but it puts complaints about committing lockfiles in Nixpkgs into perspective when every new package results in storing a new full copy of all-packages.nix
teto has quit [Quit: WeeChat 3.0]
tv has quit [Ping timeout: 260 seconds]
kalbasit has joined #nixos-dev
<gchristensen>
what if there was a pre-activation check that compared two trivial things: one of the new system and one of the host system to makes sure you're not doing something boneheaded, like activating your router's config on your fileserver by mistake
<clever>
gchristensen: been there, done that, had to reboot, lol
<gchristensen>
same
<clever>
but which key would you be testing?
asbachb has joined #nixos-dev
<michaelpj>
a `system.healthCheck` option that's a list of scripts that should return true?
<michaelpj>
like "has a boot generation" D:
<clever>
hostname is something you would want to be able to change
<gchristensen>
this got complicated quickly lol
<clever>
rootfs path could be changed (sda2 to uuid)
<asbachb>
Hi. I'm trying to analyze a segmentation fault.
<gchristensen>
I mean, like, a file named /run/current-system/flavor or something with a trivial `cat` to compare
<asbachb>
Do i get it right the program tries to open a file which is not present and that's causing the segmentation fault?
<kalbasit>
samueldr: trying out mobile NixOS for the first time on my Pine64. I can't seem to get past this panic at boot. Have you seen it before? https://imgshare.io/image/2021-01-12-08-47.N4CEF6
<{^_^}>
#108909 (by thiagokokada, 2 days ago, open): nixos/libinput: separate settings by mouse/touchpad
tv has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
<kalbasit>
asbachb: I built it locally following the instructions. Mobile NixOS at 25e9db5474621cfd22a96d3a26e3a76edda581f5 and nixpkgs at 56bb1b0f7a33e5d487dc2bf2e846794f4dcb4d01
<kalbasit>
asbachb: is there an image I can pull instead?
<kalbasit>
oh wow I did not know this, thanks gchristensen
<kalbasit>
asbachb: trying it now :cross_fingers:
<asbachb>
gchristensen: Is it possbile to get only the specified output (without the inputs)
<gchristensen>
-r will get all the dependencies
<asbachb>
(or maybe I'm mixing something)
<gchristensen>
if your .img has its inputs as dependencies, it is because you can `grep` the resulting file and find filenames -- a common problem for disk images
<asbachb>
so no way to prevent fetching the img only?
<gchristensen>
Nix won't let you realize a store path without also having its entire nix-determined run-time closure present
<asbachb>
gchristensen: I see
<asbachb>
kalbasit: Give some feedback if it works ;)
<kalbasit>
asbachb: same panic
<asbachb>
kalbasit: let me give it a try aswell
<asbachb>
kalbasit: You used 746sy5s8qhd6cq1wp3xzbm5dz6qhijsq ?
<kalbasit>
asbachb: Yes I did
<kalbasit>
I used this dd command: sudo dd if=/nix/store/746sy5s8qhd6cq1wp3xzbm5dz6qhijsq-pine64-pinephone_full-disk-image.img of=/dev/sdb bs=8M oflag=sync,direct status=progress
<kalbasit>
asbachb: did it work for you? Do you have one that works?
<asbachb>
kalbasit: Black screen. Red light. Mh..
<kalbasit>
asbachb: Yep that's what I see as well. Use your UART cable for serial console access
<asbachb>
kalbasit: Maybe you should open a bug on github.
saschagrunert has quit [Remote host closed the connection]
<asbachb>
kalbasit: So you have a sertal to usb converter and plugged it to an audiojack?
orivej has quit [Ping timeout: 240 seconds]
tv has joined #nixos-dev
<kalbasit>
asbachb: Yes. I bought it with the phone
cole-h has joined #nixos-dev
<samueldr>
kalbasit: 3GB variant?
<samueldr>
if so, there is a known issue, where I still need to work on updating the u-boot package... I need someone to bother/ping with a 3GB variant that is available and willing to validate :)
<samueldr>
I'll be doing that later today, opening a PR
<samueldr>
asbachb: what's your github handle?
<asbachb>
samueldr: I see. Is there some kind of bug report regarding that problem?
<asbachb>
asbachb as well
<samueldr>
good to know
<samueldr>
not a bug report at mobile nixos outright, but multiple spurious reports on IRC
<asbachb>
crossplatform name ^^
<samueldr>
there is that PR that serves as the de-facto "tracking" issue
<samueldr>
for mobile nixos
<asbachb>
I see
<samueldr>
other mobile ecosystems might have had reports, and most probably all already updated
<samueldr>
I'm just slow on the uptake
<asbachb>
feel free to ping me in case I should test anything.
<samueldr>
good, I'll ping both of you who had issues today... I can't exactly test for that variant
<samueldr>
it's really caused by the RAM topology, and not by any other factor
<infinisil>
Do we accept packages that add their own generated node-packages?
<cole-h>
I would. Tbh I hate the monolithic node-packages situation we have.
<infinisil>
The shared node-packages is a mess to update currently, so I don't blame anybody not wanting to deal with that
<cole-h>
Want to update a node package? Just generate a thousand+ line diff and hope there's nothing bad!
<infinisil>
Yeah
<infinisil>
I think we should have a bot that updates it daily, so users only need to add a single line to the json file
<infinisil>
But until then, I think people generating a separate node-packages is alright
<cole-h>
Or just do away with it altogether or something...
<infinisil>
Replacing it with what?
<infinisil>
Oh, just every package having their separate node-packages?
<cole-h>
Yes. The downside is that then node packages will increase the repo's disk space significantly (no more deduplication between packages)
<cole-h>
If only node was actually sane and allowed us to do what we do with Rust crates
<infinisil>
I think the current model can work just fine, if we have a better updating story
<infinisil>
I don't think there's any big downsides to it after that's done
mkaito has quit [Quit: WeeChat 3.0]
<kalbasit>
samueldr: hey sorry I was afk. Yes I do have the 3GB variant. Please pind me when you have something to test, I should be able to try it out as soon as it's ready.
dstzd has quit [Read error: Connection reset by peer]
dstzd_ has joined #nixos-dev
dstzd_ is now known as dstzd
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
<supersandro2000>
cole-h: It is rule now to not set platforms.all or unix when doing buildGoModule, buildPythonPackage or buildRustPackage and I didn't come up with this rule.
<supersandro2000>
if you think something different please don't start any discussion in PRs because I don't read them and it just draws out the PR.
<cole-h>
Who did? It seems odd to just allow a default of platforms.all when there's a low chance it actually runs on all platforms described by platforms.all. Especially for babelfish, which is only really useful in conjunction with the fish shell, whose meta.platforms is set to platforms.unix.
<cole-h>
Well, what's the point of PRs if discussion isn't desirable?
<supersandro2000>
if you have want to change the current behavior start some discussion where everyone can participate or some RFCs but please do not stale PRs and create disagreement between review.
<cole-h>
s/just allow a default/enforce a default/
<supersandro2000>
I am fine with changing things if there is a reason for it and we can agree on a default and do it everywhere like this and not one reviewer says yes and the other remove
<gchristensen>
where did this rule happen?
<supersandro2000>
gchristensen: what rule? I have a bad day today
<cole-h>
"It is rule now to not set platforms.all or unix when doing" I'd assume
<supersandro2000>
cole-h: then argue with that it requires fish which is set to platforms.unix. Fine by me but that someone could use it as a template is not a strong argument I buy.
<supersandro2000>
and discussing things in PRs which are way bigger than that PR are not great. Not everyone can get involved into it and it will just disappear under a pile of other PRs
<supersandro2000>
also I wouldn't mind if you wouldn't react with a thumbs down if you disagree.
<cole-h>
Is that not what the thumbs-down is for? Either way, I have retracted those.
<infinisil>
That's how these discussions usually start though
<gchristensen>
that is often how policy evolves in nixpkgs: continuous discussion on PRs, whether it is good or not is another thing
<ekleog>
… am I the only one having the feeling that you are both arguing in favor of not having platforms.all when we can reasonably expect it doesn't work on platforms.all? Reading your arguments it sounds like that to me
__monty__ has quit [Quit: leaving]
<infinisil>
Hmm, I feel like the whole meta.platforms concept is a bit off
<infinisil>
This should probably be stored on an external repository somewhere, automatically updated when hydra does builds
<supersandro2000>
cole-h: emojis don't have a universal meaning or font and on github you have one emoji in the middle between yay and nay and one nay which is the thumbs down. I always think thumbing something down is a pretty strong reaction.
<infinisil>
E.g., hydra builds it successfully on `x86_64-linux`, so it sets `foo.x86_64-linux = true`
<infinisil>
If it fails to build it sets `= false`
<infinisil>
And a `= true` can override a `= false`, but not the other way around
<supersandro2000>
I think that is really out of scope right now
<infinisil>
supersandro2000: This is IRC :)
<infinisil>
You don't need to participate in the discussion if you don't want to
<infinisil>
Although, doing this, it's kind of hard for third-party packages to specify the supported platforms
<infinisil>
It would be nixpkgs-centric
<gchristensen>
platforms also expresses intention
<supersandro2000>
anyhow I am continuing to comment on platforms on the three relevant wrappers around mkDerivation
<samueldr>
previous discussions ended-up, in my opinion, sorting out the thoughts that "platform" is overloaded
<samueldr>
there is: "intended to compile and work with" and "known to work with"
<samueldr>
we have a single attribute to mean both
<samueldr>
it is used so things don't get needlessly added to jobsets for the "wrong" platforms mainly, though
pmy has quit [Ping timeout: 264 seconds]
<infinisil>
Hmm good point
pmy has joined #nixos-dev
<infinisil>
So we have intents "builds" (it compiles), "works" (it's usable, depends on "builds") and maybe also "supported" (by upstream, depends on "works")
<samueldr>
the latter from upstream is one that'd be nice to document, but costly to implement and maintain for not that much worth
<gchristensen>
channeling michaelraskin, there is room for trinary support "known to work" "known to be broken" "unknown"
<samueldr>
also, yeah
<infinisil>
How about `meta.intent = { x86_64-linux = "works"; x86_64-darwin = "supported"; }`, everything undeclared is "unknown"
<infinisil>
And you could have helpers like `meta.intent = darwin "works" // linux "builds"`
<infinisil>
And negative ones as well, `meta.intent = unix "supported" // darwinNot "works"`
<infinisil>
Something like that. I'd probably also want to have a different name than "intent"
<{^_^}>
rfcs#46 (by 7c6f434c, 1 year ago, merged): [RFC 0046] Platform Support Tiers
<infinisil>
Hmm that feels orthogonal
<infinisil>
Maybe not
<ekleog>
Right, I guess what I mean is that this discussion might inform a follow-up to this RFC that would make the tier definitions more precise
<infinisil>
I guess we might want a `lib.platforms.usable` or so, which should be used as the default value of all packages
<infinisil>
And that would be derived from e.g. all platforms in tier 3 or higher
<ekleog>
Meh, people on tier4+ platforms already know that most of the things they're going to use are broken, IMO such a change would lead to little benefit for them, and worse it will make it harder for them to know what definitely won't work ahead of time
<infinisil>
Hm yeah
<infinisil>
Right, the above "unknown" concept fits much better
<supersandro2000>
If I would be on an unsupported platform I wouldn't support a PR to 100 packages to mark them work on my platform
<supersandro2000>
especially when they are just drawn in by other
<infinisil>
Yeah xD
<supersandro2000>
so linux, darwin and maybe arch64 would be widely set but everything else would be 🤷
<infinisil>
So I guess if the above `meta.intent.x86_64-linux = "supported"` idea would be implemented, the default value would just be `meta.intent = {}` (everything is unknown), since we don't know anything
<ekleog>
the issue is also that the “working level” (build-broken/builds/passes-tests/manually-tested) of a given package on a given architecture is a property not of the derivation itself, but of nixpkgs as a whole (including any overlay the user might provide, but that's probably a thing that can be ignored)
<ekleog>
(add “unknown” to the working-levels I guess, for cases where hydra doesn't build for $arch)
<supersandro2000>
did someone already think about renaming one of those fields to something like hydraPlatform or hydraBuilding?
<infinisil>
There is hydraPlatforms
<infinisil>
Only the platforms declared there are built by hydra
<worldofpeace>
Is there a page in the nixos website explaining why and when nixos is released?
<ekleog>
right, but I'm not sure we can rely on this because ideally people on exotic archs would be able to fill such a database with their feedback
<supersandro2000>
also manually tested would need to be cleared with every update probably
<supersandro2000>
yeah databases but not nixpkgs
<ekleog>
But IMO given that the “working level” data depends on nixpkgs as a whole… it makes more sense to just not store it inside nixpkgs
<samueldr>
worldofpeace: I don't think so, there's not many pages about "nixos" proper or about stable releases
<samueldr>
worldofpeace: unless the manuals do
<infinisil>
Yeah really feels like this should be a separate database
<ekleog>
What _might_ be in nixpkgs would be “is expected to work on”, which I'm not very sure is useful metadata
<supersandro2000>
so we just write in what hydra should do in nixpkgs to save resources
<infinisil>
I guess it's useful to get an early error, but that's not super useful
<ekleog>
well, looking at the latest non-unknown working level in the database probably gives just as good information
<samueldr>
but having hydra later build a package that doesn't build _now_ is useful too
<supersandro2000>
it is useful to know that something which takes forever to compile does not work on your platform
<samueldr>
since it might be that dependencies fixing their issues makes the package work
<infinisil>
samueldr: Exponential backoff
<ekleog>
(if not better, as I plead guilty to often have filled this field pretty liberally)
<samueldr>
or even upstream work
<worldofpeace>
samueldr: so currently in the nixos manual there is all this technical stuff about the nixos release, it doesn't belong there https://github.com/NixOS/nixpkgs/pull/107140, but I still think there should be either a section in the manual with this vital information, or should it be a part of the website since the manual isn't a pretty way to find this surface information
<ekleog>
I guess the problem is how to report to the user that a “manually-tested” package rolled back to “passes-tests” just because hydra built it again, so in this way it's special indeed
<ekleog>
IMO keeping all the database server-side is no problem, hydra basically already does it — fetching it client-side is more problematic
<ekleog>
(AFAICT hydra remembers all the history of all builds it did)
<infinisil>
Hmm..
<samueldr>
yes
dstzd has joined #nixos-dev
<samueldr>
only prohibitively expensive builds should be removed from hydraPlatforms
<samueldr>
and builds that are expected not to work
dstzd has quit [Client Quit]
<samueldr>
like x86-specific packages
<samueldr>
I started doing a chore thing (and never ended up following through due to starting mobile nixos) where I was going through all aarch64 failures removing many x86-obvious packages
<infinisil>
I think this would sort itself out automatically if hydra used exponential backoff with retrying failed builds
<samueldr>
like, packages using x86 assembly
<ekleog>
I'm not that even sure about builds that are expected not to work, a new update could port them without the updater noticing and then we end up with failed opportunities
<samueldr>
those are the kind of packages, using the current attributes, that should be figured out
<ekleog>
in the current state of things removing from platforms 100% makes sense, but I'm thinking that they should fail-fast on hydra anyway and so probably costs quite little
<samueldr>
ekleog: yeah, expected as in truly expected
<samueldr>
zsnes e.g. is an ASM-based x86 SNES emulator
<samueldr>
that makes no sense to try to build on ARM
<infinisil>
It would only cost a finite amount of built time with exp backoff though, which is not bad
<infinisil>
s/built/build
<ekleog>
oh right something that's 100% built in x86 asm most likely will never be ported
<samueldr>
I'm not even thinking about resources
<samueldr>
I assume they are infinite, and would fail early
<ekleog>
maybe the user could just fetch a database consisting of the “working level” for their nixpkgs revision, and if it's “unknown” the last not-unknown working level if there is one, and if it's “passes-tests” the last time “manually-tested” happened unless there was a non-“passes-tests” level in-between?
<samueldr>
that's mostly about uselessly failing packages
<ekleog>
samueldr: uselessly failing packages is a problem iff. the only way to communicate to the user that a package doesn't build is via platforms, though, right?
<samueldr>
it makes it hard to judge the aarch64 failures on hydra at a glance
<samueldr>
are they because things are not right in aarch64 or because we overuse platforms.all?
<samueldr>
I thought we were talking about hydra :)
<samueldr>
it's really an overloaded concept
<ekleog>
oh right there's that too… but then does it really matter whether the non-portability is due to us or to upstream?
<samueldr>
because there is the user-facing thing, there is the CI/CD-facing thing, then there is the "library of all information about all packages in the world" aspect that seems to permeate Nixpkgs
<ekleog>
maybe an additional “manual-cannot-be-made-to-work” working level could be added?
<samueldr>
well, it kind of matters, if it means NixOS is incorrect
<infinisil>
Not for hydra, but for users and contributors
<samueldr>
it's hard to go through failed attributes for aarch64-linux on hydra, since a good chunk are obviously-cannot-build issues
<ekleog>
(which then would naturally, by its nature of being tied to the nixpkgs revision, automatically turn back into a cannot-build working level on the next bump, so that people who want to give another try could)
<ekleog>
(but they would also know that the last attempt already failed and it's thus probably not the place to focus efforts on)
<infinisil>
Maybe hydra could assign a "chance of success" probability to each .drv
<infinisil>
Which is computed from previous build attempts for the given store path
<infinisil>
And the lower this is, the less likely hydra is to try again
<infinisil>
And the user-facing Nix could query that property of hydra for each .drv it tries to build, giving a warning to the user if the package is probably broken (with an override)
<infinisil>
Which can notably work even if hydra didn't attempt to build that exact store path
<infinisil>
"Which is computed from ... for the given *attribute path*" <- meant to say this
<ekleog>
does that work properly for eg. people trying to build old .drv's?
teto has quit [Quit: WeeChat 3.0]
<ekleog>
FWIW, I've taken a few notes of this discussion so it's not lost (forgot to take some of the recent dynamic/static option idea :/), here is what I have as an idea batch http://ekleog.xelpaste.net/SmAk4z
<ekleog>
(still up for any change obviously, just sharing in case it can help discussion)
<infinisil>
IRC logs are my notes :P (not really, but it at least won't be lost forever)
<ekleog>
right well, in practice I never remember when discussions happened, so if it's not written I'll lose said notes :p
<infinisil>
I think it should work just fine for old drvs, or why wouldn't it?
<ekleog>
well, we'd want the “chance of success” for the old nixpkgs revision, right?
<ekleog>
oh ok I just understood what you meant
<abathur>
I'm not entirely caught up with this, but since platform information being informed by hydra was mentioned; I have a suspicion that there are a lot of ~ small levers that could come out of some sort of system for collecting/aggregating metadata that isn't stored in the package
* infinisil
reads your notes
<ekleog>
abathur: such a system is exactly what we're talking about :D
<ekleog>
(though for now it's more the “what to collect/aggregate” than the “how”)
<infinisil>
Nice, I like the thought of the "pushing the state to one or the other side based on manual evaluation"
<abathur>
well
<abathur>
I occasionally saw on this here or there, I think mostly on the forums
<infinisil>
Oh, one thing is collecting how many reverse dependencies packages have
<abathur>
though mostly from the ~ux angle
<infinisil>
So that some packages can be given priority over others
<infinisil>
E.g. you could ingest that data into github, assigning labels to each PR based on how many reverse deps the package it touches has
<infinisil>
Another thing is build time
<ekleog>
well, that's more or less what ofborg does, I think?
<infinisil>
How long a package takes to build
<infinisil>
ekleog: Oh, I guess it is heh
<infinisil>
Stratch revers deps then
sgo has joined #nixos-dev
<infinisil>
But build time would be great, and can only be provided by hydra
<abathur>
so infinisil just hit one with build time; warning people when they're triggering something that will be a long build (especially if they might be triggering it through naive means, like overriding some dependency of the thing?)
<infinisil>
This would also allow Nix to have some indicators as to how long `nix-build`'s are going to take roughly
stigo has quit [Quit: stigo]
sgo is now known as stigo
<abathur>
another would be warning people before rebuild if their system/user profile depends on packages that would update to versions people are reporting broken behavior with
<ekleog>
well, even reverse deps could make sense to store there, if only because that's slow to re-compute and people working on archs might want to use it to know what to work on next
<ekleog>
build time would be great, though we'd probably want to have some coefficient applied to compensate for different machine speed
<infinisil>
Though the build time info is different in that it wouldn't be attached to .drv's (which I suggested for the probability of build success)
<infinisil>
Wait no it would
<ekleog>
(eg. that's what I was going for with meta.timeout on tests, but it turns out on hydra despite the fact that I took 10* what my laptop takes hydra still timed out…)
<infinisil>
For each evaluation, hydra would estimate the time it takes to build for each .drv and add that
<abathur>
another would be collecting meta on "known users" (nudge for consent), so that we have a non-maintainer list of people to ask to test out potentially disruptive package changes
<ekleog>
abathur: hmm… maybe that's advocating for an additional manual-tests-failed to show broken behavior not exposed by automated tests?
<abathur>
there are probably a few ways you could
<abathur>
if there was enough meta, client tooling could nudge users when it lacks info
<infinisil>
abathur: Oh, how about that thing being anonymous, where users can opt into it with e.g. `nixos-tester.enable = true`. Enabling this registers their machine at a central nix server for every .drv they use
<infinisil>
When changes need to be tested, nixpkgs contributors can only ask "we need this attr path to be tested, send a notification/notice to all the people who used these attr paths"
<abathur>
"I notice you're using the new version of jq. I don't have any reports on this yet. Can you try it out and run blahblahblah if it appears to be working fine?"
<infinisil>
Without being able to infer any actual machines
<infinisil>
Yess
<ekleog>
“for every .drv they use” -> that's not good, I don't want the .drv of my wifi passwords being public :p
<ekleog>
abathur's idea is great though
<infinisil>
Hmm, I don't think it would transfer the drv contents, only the paths
<infinisil>
Well, the filepath I mean
<ekleog>
even drv path is IMO too much, it's just a hash and if the password is weak enough it'd be bad
<infinisil>
Hmm true..
<abathur>
I would fall more on the side of explicit consent
<ekleog>
if it's reporting attrpaths it'd work though IMO
<abathur>
mostly because it's more clear what you're collecting
<abathur>
i.e., point-of-use consent
<ekleog>
well, “I don't have any reports on this yet” already requires consent to have been collected
<abathur>
and not, I said yes, but who knows what it does
* infinisil
nods to attr paths
<infinisil>
Well, but if it's .drv's we could have fancy things like distributed build/testing, where anybody can send a report to a central server saying that "I have tested this .drv, it works", or "this .drv doesn't build"
<ekleog>
the more I think about it, the more I feel most of meta should move to that database, with the exception of homepage and description maybe
<abathur>
but those reports could be anonymous, I would draw a line between collecting "known users who are invested in this package being stable and willing to test out changes to it" from anonymous "Did that thing you just tried work?" nudges
<ekleog>
eg. maintainers would probably be better maintained as mutable data, as people come and go
<abathur>
though the trick for anything is keeping the service from having its potential value trashed by abusive traffic
<ekleog>
(well, and change names, as the current Rust ecosystem's cargo changes are proving)
<infinisil>
ekleog: Oh also, the maintainer list on github is a bit of a problem because it stores personal data, and needs to be continuously updated, also because github ids change, etc.
<infinisil>
It would be better if this was out-of-git
<infinisil>
GDPR is theoretically a thing we'd have to conform to, though I think they look away for git repos because it's infeasible to enforce
<ekleog>
infinisil: it can still be done with attrpaths+nixpkgs revisions, just have to send attrpath+revision+drv hash and then the server just verifies the eval evals to the right drv hash? the only thing is such distributed testing no longer works with overlays, but I'd be like “well just maintain your own meta database”
<abathur>
other things I imagine are like, being able to flag specific packages as needing more tests, and once flagged the client nudges users for test cases
<ekleog>
yessss I agree
<ekleog>
(GDPR has provisions for “you actually can't do it”, but I'd much rather we didn't have to actually use them)
<abathur>
i.e., a package was building so we assumed it worked but someone just reported that literally only --help and --version work, mark it as needing test cases
<infinisil>
"The package graphviz doesn't have any command tests, what's a common command you run, and what do you get as a result? (open terminal)"
<abathur>
yes
<abathur>
but better
<abathur>
give them a wrapper for execing it
dstzd has joined #nixos-dev
<infinisil>
Oh, the wrapper could even trace syscalls to figure out which files it needs to run, after which it lists all files, asking the user if it's okay to transfer them
<infinisil>
A bit scary though
<ekleog>
^ that's definitely way into the “further improvements” section :p
<abathur>
"if you know of a good test command, run `blah <command>`", collect as little as we need, and show the user what's collected for final consent to send
<infinisil>
Maybe the user could interactively be asked "the package tries to read from path /..., allow?"
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
<infinisil>
ekleog: Ohh, how about we base it not on attr path, but derivation name
<abathur>
infinisil: I would say you can do the trace in CI in many cases if you know a valid invocation and can recognize files supplied to the command wrapper?
<abathur>
at least one asterisk would be things that break if you don't have ~/.gotchafile?
<infinisil>
derivation name is very anonymous, not specific to nixpkgs, and pretty much always the same for the same package
<gchristensen>
the name portion can be identifying, but the hash less so
<ekleog>
the idea is there are two sets and the two parties only learn the shared subset
<infinisil>
Ah neat
<infinisil>
Well
<gchristensen>
'course, there are places that have no matching derivation hashes but want to contribute to popcon stuff
dstzd has joined #nixos-dev
<infinisil>
One party could just add all kinds of naughty elements into their set to figure out if the other party has them
<infinisil>
ekleog: ^
<ekleog>
PSI, while not preventing attacks, does make them traceable as the server would have to publicly claim it already has the drv hash with a password in there
<ekleog>
oh well I should have typed faster :p
<infinisil>
Hmm.
dstzd has quit [Client Quit]
<ekleog>
overall I feel like for popcon & the like, attrpaths are probably just good enough with the least amount of issues
<infinisil>
popcon?
<ekleog>
popularity contest, sorry
<infinisil>
Ahh
<cole-h>
So much jargon :P
dstzd has joined #nixos-dev
<gchristensen>
pkgs.terraform.withPlugins (p: with p; [ p.aws ]) <- what about cases like this?
<infinisil>
gchristensen: We'd probably have a big standard deviation on such "env" derivations for build time and co.
<infinisil>
Which could be used as an indicator that it's not really predictable
<ekleog>
I think such cases are currently not built by hydra? ie. there'd be pkgs.terraform and pkgs.terraform.plugins.aws or similar… do you think it'd make sense to have metadata associated to the withPlugins derivation itself?
<gchristensen>
having the data about the aws plugin, yes
<gchristensen>
the combination: less interesting
<gchristensen>
but is there an attrpath you could find for p.aws?