<infinisil>
It would be really cool if *anybody* could submit this metadata, to like a central nix metadata server
<ekleog>
hmm… is it not pkgs.terraform.plugins.aws or similar? (I don't know anything about terraform, just assuming it's similar to python, maybe it's not?)
<gchristensen>
how would you get from a used expression to that?
supersandro2000 has quit [Disconnected by services]
<infinisil>
But yeah, I want to not use an attr path because that's going to be tricky to pass to explicit derivations
supersandro2000 has joined #nixos-dev
<infinisil>
And it's inherently tied to nixpkgs
<ekleog>
hmmmmmmmm right I hadn't thought of popcon itself
<ekleog>
working-levels and most other use cases we've been discussing work without having to automatically map the withPlugins drv to the attrpath, but popcon does have to automatically do that mapping
<gchristensen>
especially for places that have no matching derivation hashes due to nixpkgs patches, but do want to contribute to popcon stuff
<infinisil>
I still think derivation names would be great
<ekleog>
I'm somehow leaning towards “popcon should live in another database than working-levels” right now, as it has very different properties (in particular it's tied to a “package” and not actually to a derivation)
<infinisil>
Yeah makes sense
dstzd has joined #nixos-dev
<infinisil>
What if every new package in nixpkgs gets a unique id, set with `meta.id`, which it should maintain over its lifetime
<abathur>
another useful one, though hydra would probably submit itself, would just be some metrics on requests (count, most-recent, some decaying measure of volume-over-time?) I'm a little leery on this one--I don't want nixpkgs to end up with something like the (hashicorp?) support policy gchristensen has bemoaned. But also could be helpful for triage, recognizing unused packages, etc.
<infinisil>
So meta.id could also be set by non-nixpkgs packages
<gchristensen>
the thing about hashicorp's policy is it is 100% user-centric and actually quite good, just a bit demoralizing :P
<infinisil>
And we'd use it to track these per-package things
<abathur>
right
<abathur>
I'm on the fence about it, I don't really disagree, but proportion also matters I guess
<abathur>
a showstopper for 10 people is more important than a mild annoyance of simple FR from 1000
<abathur>
*or
<infinisil>
gchristensen: I think one problem with it is that they're pretty much just sorting issues by popularity. Instead I think they should allocate resources to each issue proportional to popularity
<samueldr>
abathur: hydra doesn't see downloads
<infinisil>
So even if an issue only has 1 vote, it still gets 1 person-hour a month
<abathur>
sorry, cache
<infinisil>
abathur: 10 * 100 == 1000 * 1 though
<infinisil>
A big annoyance for a small amount of users can bring the same frustration as a mild annoyance for many users
<infinisil>
In total
<abathur>
and, of course, they should also be proportional to the best-guess on fix effort
<infinisil>
Hmm, so a score based on <amount of users affected>, <how bad the problem is> and <how hard it is to fix>
<abathur>
if we can fix darwin builds for dozens of simple platform.unix packages in the time it'd take to get the chromium package building...
dstzd has joined #nixos-dev
<ekleog>
OK I've just updated my notes on this discussion by splitting out things that would be better in a popcon-like db, hopefully I forgot no one as I added the list only after the fact http://ekleog.xelpaste.net/Cv3t6D
<infinisil>
Could also link to the IRC logs :)
<abathur>
(problems that affect NixOS are also a bit different than problems on other platforms, where we can elect to use any other package manager if we hit trouble)
<abathur>
I wouldn't focus too hard on trying to metrify it; I think *trying* to metrify these is part of how hashicorp ends up counting votes for simplicity
<ekleog>
well this way it's already half-way through the RFC-ization, though I'm not sure I'm ready to go through an RFC process :p
<infinisil>
ekleog: Why is this a "popcon db" if it stores not only popcon things? Shouldn't it be a "package db" instead?
<ekleog>
right, edited this way :)
<infinisil>
:)
<abathur>
my own razor would be that popularity information's ~best use is identifying rarely-used packages that are causing lots of issue/update volume, or large amounts of build-resources
<gchristensen>
ideally the popcorn database would be local, also so it can be conveniently queried during movies
<infinisil>
Oh, isn't this kind of an ideal use case for federating servers?
<gchristensen>
not really, the goal is to make a central database
<infinisil>
Is the central aspect needed for anything though?
<gchristensen>
querying? :P
<abathur>
user: nix-I'm-having-a-problem-with-X; nix: sorry to hear that--would you like me to check the feedback server to see if other users are reporting trouble with this? user: oh, yes please! nix: gosh! I see a lot of reports here on your platform...
<infinisil>
gchristensen: Can also do that in a federation
<infinisil>
Most people would probably just use the nixos.org server, but they could also host their own servers, which can also provide data
<abathur>
the reaaaaaaaaaaly sick trick, eventually
<ekleog>
we can do that with federated servers, it just sounds way harder to do for maybe little use case?
dstzd has quit [Client Quit]
<infinisil>
Yeah maybe
<ekleog>
abathur: hmm… I guess that's more package-level than drv-level? but then we do need some way of eliminating feedback that is no longer relevant (well, and of moderating spam but that's another issue)
<abathur>
user: nix-do-a-bad-thing; nix: oh, gosh! that didn't work. Judging by your error message, it looks like there's already an issue report open at <link>. You don't need to report this, but you might want to subscribe to that issue so you know when it's fixed.
<infinisil>
abathur: Ohh only just seeing that now, but hell yeah
dstzd has joined #nixos-dev
<infinisil>
Alright I need to go watch some series now, I'm exhausted from talking so long :P
<infinisil>
Thanks for the discussion, cheers!
<gchristensen>
make sure you've got your local popcon database handy, infinisil
<abathur>
ekleog: yeah, figuring out the right combination of smoothing over package v. drv is some degree of trick
<abathur>
obviously any can differ, but many drvs could have the same issue
* infinisil
wishes there was popcon at home
dstzd has quit [Client Quit]
<abathur>
my razor there would probably be to try to use the client/db behavior to fill in the gaps
<gchristensen>
name it "popcom" as a real troll
<infinisil>
mono-spaced irc font, you can't trick me :)
<ekleog>
see you! :)
<ekleog>
abathur: not sure what you mean by “the client/db behavior”?
<abathur>
I won't swear I know, either
<abathur>
but, for example, if the db knows it has an issue report correlated with a package x with source hash y and drv z
<abathur>
it might nudge someone installing package x with source hash y and drv a to confirm if they see the same problem?
<ekleog>
oh ok, so storing all the information in the db and then letting the client decide their own behavior?
<ekleog>
Which would hint at this being a drv-level database and then the client filtering over all drv hashes
* infinisil
. o O ( bloom filter )
<abathur>
not sure at the architectural/implementation level what the primary orientation should be
<ekleog>
huhhhh I'd have went with an index, ORDER BY version DESC LIMIT 50 :p
<abathur>
different granularity probably makes sense for different kinds of issue
<abathur>
some of that might be discoverable via context
<abathur>
if you know package x source y had no issue reports at drv b and started getting them at drv c, and you know what dependency changed...
<abathur>
maybe you can just ask people to re-check if the source changes, or if the dependencies that rolled over in c change again
<infinisil>
Community-based bisection!
<abathur>
low-fruit first, I guess
<abathur>
nix-ofborg-bisect
<ekleog>
that kind of bugtracker would probably be awesome to reduce our backlog on github issues by having them automatically be tagged to the right person… but it is basically doing our own bugtracker
<ekleog>
tagged to the right drv * (not sure why I meant person sorry)
<abathur>
~popularity data could inform whether it's likely signal-bearing that something wasn't reported
<ekleog>
my point being that I don't think we actually have the manpower to do that :p
<abathur>
right
<ekleog>
(but yeah it'd be awesomely awesome)
<abathur>
and shouldn't, if the expected leverage wasn't greater than the expected investment
<ekleog>
well… different people have different notions of “leverage”/“investment”
<abathur>
nod
<ekleog>
like, if I had to pick between working on such a bugtracker for 1 year or working on triaging nixpkgs PRs for 1 month, I'd most likely pick the first even if it'd definitely be less objectively efficient
<abathur>
I mostly just mean I'm barfing out things that might work without much regard for whether they'd be timesinks or levers
<abathur>
and that ultimately I agree that levers should be the priority
<ekleog>
yeah it's actually great and I shouldn't have interrupted with practicalities, I guess, brainstorming being the objective today :)
<ekleog>
triaging nixpkgs issues *
<abathur>
well, I didn't necessarily mean it as distinct from the gh tracker
<abathur>
mostly imagining the correlation layer, that might even be human tagged
<ekleog>
ugh now I want to derail the conversation towards “we shouldn't build too much more gh-centric tooling”, but please ignore me
<abathur>
saying package x is known to have a problem, reported at this URI, with this error message
<abathur>
and the processor looks at the error message, and knocks out the things that smell like nix/store paths, versions, etc.
<abathur>
and then matches breaks against the template to see if they are familiar
<abathur>
I am the swiss on that one
<infinisil>
Building a bugtracker might be more efficient in the long term
<abathur>
<3 infinisil
<{^_^}>
infinisil's karma got increased to 401
<infinisil>
xD
<abathur>
GH obviously is a lever, in that it is a community, and has helped build communities
<abathur>
but, it's also not bad to own your infra, or at least own your contingency plan
<abathur>
i.e., it's good to not be a hostage
<abathur>
but it's not *inherently* good to not be on GH, I don't think
<ekleog>
on that topic, I remember at some point I had tried repeatedly (and probably too much) poking people to make sure we have backups of the “export all the database” button github provides (provided?) — does anyone know whether that actually ever happened? I remember I eventually gave up but that's all
<ekleog>
(unfortunately one has to be an org owner to have that button IIRC)
<abathur>
I'm not in that loop, but I agree that having a record of the last backup(s) and who took them or where they put them might be good to have
<abathur>
ideally it's just automated, as long as there's a way to notice if it isn't happening
<ekleog>
which in turn means that automating is probably a bad idea, as we don't want owner tokens in automated systems
<ekleog>
but IMO something like backing up every release would make sense, it'd still be better than no backup at all (if only to keep the next volth's contributions) and hopefully we won't lose _too much_ stuff from one day to the next without warning
<cole-h>
Interestingly enough, the titles of volth's issues are still around if they're tagged in a milestone
<samueldr>
their measures are leaking data like a sieve
<samueldr>
I wonder if you can use the API calls to add them to a milestone
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
dstzd has joined #nixos-dev
<abathur>
ekleog: this may not satisfy your concern, but the GH tokens do have reasonably granular perms, so it's at least not immediately evident to me that it isn't possible to make a key that can back up but not, say, delete everything
<abathur>
not sure how that specific function is gated, if it's even automatable without scripting a browser, etc.
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
<infinisil>
ekleog: abathur: GitHub Apps can be configured to have separate read/write perms
<ekleog>
abathur: interesting :) I guess it's something that should be investigated and then brought up either before org owners or as an RFC, though I must say I'm not going to spend more cycles in this domain, having already given up once
<infinisil>
Hmm, above is only the repo, not issues and co.
<samueldr>
sorear: interesting
<infinisil>
Wait no "BackHub creates daily backups with snapshots of all your GitHub repositories including metadata, such as issues, pull requests etc"
<cole-h>
sorear++ Nice find
<{^_^}>
sorear's karma got increased to 1
rajivr has joined #nixos-dev
<infinisil>
BackHup is paid, $12/month for up to 10 repos, but I think that's reasonable
<ekleog>
I wonder whether that'd actually work on the nixpkgs scale though, due to timeouts
<ekleog>
(looks like it doesn't use the migration API I was linking above)
<ekleog>
though hopefully it'd work anyway: > Anyway, github-backup does do an incremental backup, picking up where it left off, so will complete the backup eventually even if it's rate limited.
<ekleog>
so actually maybe I should just start running it myself
<ekleog>
gonna do that overnight to not get rate-limited out of github though, I guess
<ekleog>
… overnight… /me looks at the clock
<samueldr>
ekleog: even with rate limits for an account token accounted for
<samueldr>
you're in for more than 10 hours *only* for pull requests bodies, not comments
<ekleog>
oooh right rate limits without an account token are counted separately, so I can run it without and leave it running while still using github
<infinisil>
Yeah, and also there's going to be a management overhead to this whole thing as well. A fully-managed solution like BackHup sounds kind of nice to really not have to worry about it
<ekleog>
that said with these numbers I'm started for a month to complete running it :(
<samueldr>
but rate limits without an account are much more limited
<samueldr>
I think about 10×
<infinisil>
(Note that BackHup is even GitHub's recommended backup solution)
<ekleog>
right, I'm just looking for whatever gets me have a backup with as little authorization required
<ekleog>
actually I could probably create a burner account and run the thing from my server, wonder how long github-backup would take then
<red[evilred]>
so, in theory? could I add the arch, open a PR, and ask ofBorg to build it?
<samueldr>
oh, your sentence just clicked with me
<samueldr>
ofborg won't
<samueldr>
ofborg hasn't been given an M1 machine
<red[evilred]>
how would I go about getting it tested?
<samueldr>
for the time being, good question, ask on the PR about the better way to approach this maybe? or maybe someone else has an opinion on the matter
<red[evilred]>
which PR? the one I would raise? or is there a PR that's tracking this stuff already?
<{^_^}>
#105026 (by thefloweringash, 6 weeks ago, open): Native support for Apple Silicon
<red[evilred]>
there's got to be a thread somewhere for the addition of a whole new target
<red[evilred]>
sorry - didn't see that - thank you :-)
<red[evilred]>
since they're only at about 50% successful building, I'll wait a little later until I ask
<red[evilred]>
afaik, we only have one user :-)
<red[evilred]>
(and it's not me)
<siraben>
Why is it important to do runHook preInstall and runHook postInstall when overriding installPhase?
<samueldr>
to be considerate of users who might add pre/post hooks to the phase
<samueldr>
if I was to .overrideAttrs(_: { postInstall = "echo important stuff"; }) I'd expect it to work
<siraben>
I see. Is this done throughout all of Nixpkgs?
* siraben
ponders another treewide issue
<samueldr>
it should, it might not be consistently applied due to human involvement :)
<ekleog>
I always wondered why `runHook preInstall` was not actually outside of `installPhase`
<ekleog>
(and then disable-able by using a `disableHooks` or similar)
<samueldr>
I guess it's like many things in Nixpkgs "it's always been this way" :)
<ekleog>
heh ^^'
<ekleog>
“and changing it would introduce lots of churn because all non-nixpkgs derivations would end up running the hooks twice” I guess
<samueldr>
I hadn't taken the thought that far
* ekleog
is slowly accumulating stuff that should be changed in mkDerivation so as to suggest it all in a single step, so that it cleanly breaks compat for everyone but only once
<ekleog>
(actually maybe I should just call the fixed thing not-mkDerivation so that the break is _really_ clean and we can carefully migrate from mkDerivation to the all-thorns-removed version of it)
<samueldr>
maybe it's time we plan an stdenv2 ;)
<ekleog>
like, the other ideas I currently have are to set strictDeps and remove the default autotools logic to introduce a mkAutotools instead
<samueldr>
(I say that jokingly, mostly)
<ekleog>
well, I'm hoping there's enough space in that “mostly” for considering an RFC the day I feel like I have accumulated all the thorns and submit an RFC :p
<samueldr>
I'm thinking about the size of the bikeshed :)
<ekleog>
BIGGER
kalbasit has quit [Quit: kalbasit]
kalbasit has joined #nixos-dev
krkini has quit [Remote host closed the connection]
kini has joined #nixos-dev
kalbasit has quit [Quit: WeeChat 2.9]
orivej has quit [Ping timeout: 256 seconds]
srk has quit [Remote host closed the connection]
srk has joined #nixos-dev
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
dstzd has quit [Remote host closed the connection]
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
dstzd has quit [Remote host closed the connection]
sorki has joined #nixos-dev
srk has quit [Ping timeout: 240 seconds]
sorki is now known as srk
dstzd has joined #nixos-dev
eyJhb has joined #nixos-dev
puck has quit [Quit: nya]
puck has joined #nixos-dev
<eyJhb>
The module mautrix-telegram, is basically in a series of mautrix-* stuff, which all follow the same parameters and how they work basically, as they are backed by a "mautrix" library. Wouldn't it make sense to have a services.mautrix = [], where one could define multiple mautrix modulse, using e.g. a package attribute ? Eg. atm. there is a lot of code dub if new modules were to be supported
<infinisil>
But no to lists, I think it should be an attribute set :)
<eyJhb>
The only issue is, that the mautrix-telegram should be keept. But for how long? Could it be replaced in a next release of NixOS? Where the "new" way is forced?
dstzd has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
<roberth>
is anyone else building little content-addressable stores in their derivations?
<roberth>
I just wrote one for sbtix to be able to replace copied jars by store references. Perhaps I could reuse some pre-existing format so we can have interop and/or reuse
orivej has quit [Ping timeout: 272 seconds]
FRidh has joined #nixos-dev
<sphalerite>
oh, excellent timing :p I've been trying to debug an issue with zope.interface, python2 won't import it since [f7e28bf5d8181926e600a222cb70180519d09726] Split buildPythonPackage into setup hooks (by FRidh ) and it's not entirely clear to me why
<sphalerite>
Before that commit, it checked the existence of …python2.7-zope.interface-4.6.0/lib/python2.7/site-packages/zope and then went straight on to zope/interface while afterwards it checks for zope/__init__.py (which doesn't exist) and then fails
<FRidh>
sphalerite: yes its an issue with old-style namespace packages
dstzd has quit [Remote host closed the connection]
jonringer has joined #nixos-dev
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
WilliButz has quit [Ping timeout: 256 seconds]
halfbit has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
WilliButz has joined #nixos-dev
<FRidh>
adisbladis: by the way, what is your intention with the emacs pr? Suppose its fine to merge?
<adisbladis>
FRidh: I've been busy with other things. If you think it's in line with RFC 0083 I think it's fine to merge.
<FRidh>
adisbladis: okay. rfc 83 is in such an early phase, so no need to follow what's in the draft to the details (that aren't in it yet either). The only change I expect is that we're going back from emacs.pkgs to emacsPackages.
<adisbladis>
I quickly glanced over the RFC again and I think it's all fine and dandy
<adisbladis>
Why would we go back to the latter?
<adisbladis>
I've always found that approach strangely assymetrical
<adisbladis>
For example we don't have package sets for pythonFull, but we do have python310Packages
<adisbladis>
With `pythonX.pkgs` the interface is the same regardless
<halfbit>
so to fix gcc inadvertantly containing symbols when creating a cross compiler, its clear to me I think that I need to run the cross-compiler toolchain's strip on the libraries, and the host toolchains strip on the binaries
<halfbit>
but strip.sh isn't really setup to do that as far as I can tell, I can't for example provide a list of "host" strip dirs and "target" strip dirs
<FRidh>
adisbladis: originally my argument was overriding, but with overrideScope' that is no longer valid, except when you also make a change to the interpreter ``` mypython3 = let mpython = python3.override { self = mypython; ... }; in mypython
<adisbladis>
Yeah, I just remembered we've had this discussion before
dstzd has joined #nixos-dev
<FRidh>
then there was the argument if you want to make package sets for different variants and have the set decoupled from the interpreter
<adisbladis>
In emacs this is already semi-decoupled
saschagrunert has quit [Remote host closed the connection]
<aszlig>
ah, this was about the nixos module system part of nixcloud
<aszlig>
at least i guess it was
<nbp>
aszlig: is there something special that we could uplift?
<aszlig>
ah, what do you mean?
<nbp>
something that we can move to the module system which might be interesting for another project?
<aszlig>
that project is more or less stale since two years and it also relies on a few module system internals, so i'm nut sure whether it still works
<aszlig>
hm, good question...
<nbp>
I see there is some versioning where you check that NixOS modules are stable, by checking the hashes of them.
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
<aszlig>
nbp: yeah, that's for example to make sure that you get an assertion error once the module which is overridden changes upstream
<samueldr>
kalbasit: at the very least it's not an issue coming from u-boot
<samueldr>
kalbasit: I'm pretty sure I know the cause of the issue, not sure about the actual problem and solution, but it's something I can check and work on on my own
<kalbasit>
samueldr: let me check this patch. Which nixpkgs commit you're working/testing with?
<samueldr>
kalbasit: whatever last built the `tested` jobset successfully on hydra
<samueldr>
generally
<samueldr>
though my current checkout is 56bb1b0f7a33e5d487dc2bf2e846794f4dcb4d01
<kalbasit>
samueldr: got it, thanks
<samueldr>
something is going unexpectedly (but maybe expectedly) wrong during the teardown of the usb gadget when kexecing
dstzd has joined #nixos-dev
ris has quit []
dstzd has quit [Read error: Connection reset by peer]
* kalbasit
building the image...
ris has joined #nixos-dev
<samueldr>
kalbasit: just saying, if you build fromt the default.nix at the root, it will uh... "hang" at a login shell
<samueldr>
in reality it's booted to an unconfigured system, with actually no way to configure it from the device, no default password, not even a default user
<samueldr>
I haven't thought of the user story for their "first boot" yet
<samueldr>
though, if you use examples/demo as a starting point, it's pre-configured with defaults (dangerously open!)
<kalbasit>
samueldr: I left a comment of the error it surfaced on your Gist
<kalbasit>
samueldr: that was my next question cause I got a login shell :)
<kalbasit>
samueldr: I'll build the demo then
<samueldr>
kalbasit: you could also customize the build using `local.nix`
<kalbasit>
samueldr: since it's my first time trying this out, I'll try out your demo first
<samueldr>
yeah, I'm probably tearing it down wrong... most sources online don't explain how to tear down a usb gadget, and what the official doc from the kernel does... cannot be totally right
dstzd has joined #nixos-dev
<samueldr>
kalbasit: note that the demo is not really a "real" mobile system, it was mostly made so I could show off quickly at nixcon 2019 :)
<samueldr>
and, in turn, it ended up being useful to explore devices without external comms
<kalbasit>
samueldr: do you have a local.nix then I can use to get started?
<samueldr>
examples/demo/configuration.nix ;)
dstzd has quit [Client Quit]
<samueldr>
(local.nix is simply a nixos configuration import)
<samueldr>
but whew it's not a great experience to use desktop X11 apps on mobile, but it sure can be made just bearable enough
<samueldr>
as long as you have the stage-1 for your device, it'll boot it on all aarch64 devices
<samueldr>
(though it's using framebuffer with X11 for maximum compatibility by default, it's something you might want to re-configure later on)
<kalbasit>
so the rootfs is the 128M partition or the 776M partition? I see 4 partitions in total
dstzd has joined #nixos-dev
<samueldr>
the biggest partition
<samueldr>
the later one, the fourth
<gchristensen>
how would we feel about backporting alacritty 0.6.0 to stable (currently at 0.5.0)? 0.6 fixes a bug where alacritty crashes often when running tmux
orivej has joined #nixos-dev
<samueldr>
does it have backwards incompatibilities?
<gchristensen>
I think some changes to config, yeah
<samueldr>
e.g. dropping features, breaking config
<samueldr>
do we know the patch that fixes your breakage?
<gchristensen>
I haven't looked for it
<samueldr>
right, so not a specific fix you were following
<cole-h>
I don't see anything incompatible in the changelog