<{^_^}>
#116475 (by davidak, 4 weeks ago, open): doc: add instructions to remove a package
abathur has quit [Quit: abathur]
supersandro2000 has quit [Remote host closed the connection]
supersandro2000 has joined #nixos-dev
<siraben>
supersandro2000: reviewing
<siraben>
Is it intentional that the number listing is 1.\n1.\n ...?
<samueldr>
in markdown it's fine
<samueldr>
by the spec it will maie <ol>
<samueldr>
make*
tomberek has joined #nixos-dev
<samueldr>
odd, the systemd-boot install script in NixOS fails silently, but with a success return code on aarch64...
<samueldr>
though I'm switching from grub, if it matters
<samueldr>
I had to `sudo bootctl --path /boot/ --no-variables install` to coax it into doing what it should
<samueldr>
otherwise it would end with `could not find any previously installed systemd-boot`
<siraben>
samueldr: ok
<samueldr>
odd, it doesn't boot, though grub can...
<samueldr>
systemd-boot starts, but the kernel panics
<tomberek>
playing around with declaring hydraJobs in flakes. Does this not support tracking input changes when flake.lock updates (or not using the flake.lock in order to pull master from input repos?) I'm referring to the "Changes" table here: https://hydra.nixos.org/build/4317089
<Ericson2314>
qyliss bsd label sounds good. OpenSSL I really have no clue, even after looking at the commit that TODO came from. Do whatever you want with it and feel free to just remove it then.
cole-h has quit [Ping timeout: 252 seconds]
tomberek has quit [Ping timeout: 240 seconds]
cjb has quit []
thonkpod has quit [Ping timeout: 260 seconds]
nyanotech has quit [Ping timeout: 250 seconds]
thonkpod has joined #nixos-dev
nyanotech has joined #nixos-dev
orivej has joined #nixos-dev
evanjs has quit [Read error: Connection reset by peer]
<ma27[m]>
niksnut: so would you approve https://github.com/NixOS/nix/pull/4688 if getting forcing eval errors always happen on `nix build` rather than only doing this if `-F` is set? :)
<{^_^}>
nix#4688 (by Ma27, 2 weeks ago, open): libcmd/installables: add `-F` to force revaluation of cached failures
<niksnut>
ma27[m]: in that case the -F flag would not be necessary anymore, right?
<ma27[m]>
yes.
Synthetica has joined #nixos-dev
bennofs__ has quit [Ping timeout: 240 seconds]
bennofs_ has joined #nixos-dev
bennofs_ has quit [Ping timeout: 246 seconds]
__monty__ has joined #nixos-dev
<ScottHDev>
Hello, I'm trying to make a derivation for some python modules and one of them needs to load a dynamic library at runtime. But this is not an executable but a python module. So I can't wrap anything to prefix it with a custom LD_LIBRARY_PATH.
<lukegb>
Can you replace the path to the dynamic library with a fully-qualified path using substituteInPlace?
<{^_^}>
#119859 (by domenkozar, 3 minutes ago, open): Add a warning comment on commits that violate https://github.com/NixO…
<qyliss>
Can we stop the label bot removing manually-added labels somehow?
<qyliss>
now that I've told it some paths that should automatically get the BSD label, it's removing the BSD label from any manually-tagged PRs that don't touch those paths
<supersandro2000>
there is an option to disable that and if remember I turn that off later if no one else did already did it
<qyliss>
supersandro2000: that's not really what we want though -- the bot should remove labels it's added if they're no longer relevant, it just shouldn't touch labels added by humans
<supersandro2000>
I did a quick search on GitHubs API and I don't think they really expose this information
<gchristensen>
I *think* the event stream does
jess has quit [Ping timeout: 622 seconds]
<ikwildrpepper>
domenkozar[m]: nice (warning)
jonringer has joined #nixos-dev
jonringer has quit [Remote host closed the connection]
jonringer has joined #nixos-dev
rj has joined #nixos-dev
jonringer has quit [Remote host closed the connection]
<domenkozar[m]>
Am I the only one that's really sad how we have automation for bugging people for extra whitespace (somehow that's a requirement on maintainer to remove it) but very little of automation of things like backporting, etc?
jonringer has joined #nixos-dev
<domenkozar[m]>
It's probably two separate things going on: requiring changes for nitpicking seems contraproductive vs. tooling to help maintainers would really make a huge difference in a positive way
<LinuxHackerman>
+1
<gchristensen>
we actually have quite a lot of very good automation helping maintainers, but I suppose the nature of the problem is in blends in :)
<gchristensen>
I think there is some automation now to help with backports
orivej has quit [Ping timeout: 240 seconds]
<domenkozar[m]>
gchristensen oh, do you know where?
<gchristensen>
maybe I'm thinking rebase
<gchristensen>
but I think there has been some looking at backports
rj has quit [Ping timeout: 240 seconds]
rj has joined #nixos-dev
<supersandro2000>
we do not have
<supersandro2000>
basically we need something that auto generates PR from merged PRs that have the backport label
<supersandro2000>
I would do it but I have no experience with writing GH Actions and if it isn't done properly it will be a bit problematic
<lukegb>
bear in mind that sometimes backports are bumping minor versions, and the same thing isn't applicable to stable as to master
<supersandro2000>
oh and GitHub Actions cannot create the PR directly or the CI will not run
rajivr has quit [Quit: Connection closed for inactivity]
<Ericson2314>
qyliss: btw the thing I was trying to say the other day about branches
<Ericson2314>
if the PR to staging is based on `git merge-base staging master`, then darwin and linux can be tested without extra rebuilding
<sterni>
ah that's why your build was faster than mine :p
<sterni>
it's still running
rj has quit [Ping timeout: 240 seconds]
<qyliss>
Ericson2314: lots of stuff I've been doing depends on other stuff that's only in staging
<qyliss>
(on NetBSD)
<Ericson2314>
that's true
<Ericson2314>
it's also a self-begetting process that as soon as the one thing is based on other staging commits, then other things will also need those commits
<Ericson2314>
(and I am not sure the extra work is always worth it) for the lua example one could do `git checkout merge-base; make lua changes: git merge staging`. annoying when making the PR, but makes it easy to regression test lua without rebasing, just checkout commit before the merge
<qyliss>
oh that's a good idea
<qyliss>
and that merge commit probably disappears if I rebase merge
rj has joined #nixos-dev
<Ericson2314>
ah good point, never thought of that
<Ericson2314>
yeah it should
* gchristensen
wonders if fridh is somehow paying attention without being in the channel
<Synthetica>
gchristensen: the real sneaky move is to only interact with the channel by reading the logs
<gchristensen>
no joke I have done this before and fridh would join the channel a second later knowing I wanted to talk to them
<sterni>
gchristensen: yeah, I've observed that as well
<qyliss>
Ericson2314: netbsd.headers uses an overridden netbsd.sys, so any change to netbsd.sys will force a rebuild
<Ericson2314>
qyliss: oh is it just headers? hmm this might explain some silliness in my PR
<qyliss>
I have a WIP patch that makes netbsd.headers make its own derivations of its sources to avoid that, but haven't got it polished yet
<qyliss>
Ericson2314: yeah
<qyliss>
with my patch my kernel change there caused no other rebuilds
<ma27[m]>
niksnut: removed the `-F` flag from https://github.com/NixOS/nix/pull/4688 as suggested. Now eval errors will be forced to be re-evaluated (even if cached) for `nix build` every time.
<{^_^}>
nix#4688 (by Ma27, 2 weeks ago, open): libcmd/installables: force re-evaluation of cached failures
<samueldr>
[13:47:22] [{^_^}] [nixpkgs] @Leeeooo19888 opened pull request #119887 → openarena: Update link from oa_ded to openarena-server → https://github.com/NixOS/nixpkgs/pull/119887
<supersandro2000>
even the github api is like: nope, I don't know what you are talking about
<hexa->
someone probably has an email copy :)
<cole-h>
that PR title is the exact same as #72824
<cole-h>
yeah, I noticed the same earlier this week, too :(
<qyliss>
it's very uncomfortable that github does this...
<cole-h>
saw an issue which involved volth, where they suggested something I would have liked to try. previously, could have just checked the events api, but no longer :(
<hexa->
so, firefox-esr 78.15.0, the last esr release of the 78 series, will be release around 2021-09-21
<supersandro2000>
looks like a spam account
<hexa->
and firefox-esr 91.0 will be released ~2021-07-27
<hexa->
is bumping esr this way fair game in a stable release? cc jonringer
<samueldr>
hexa-: what's upstream's suggestions?
<samueldr>
they probably have guidelins
<samueldr>
guidelines*
<samueldr>
is it expected that distros ugprade to the next ESR asap?
<gchristensen>
browser bumps are always okay
<hexa->
I expect that to be the case
<samueldr>
since it's a browser, I kind of assume it would be fine to upgrade it in still-supported stable NixOS
<hexa->
given that security advisories appear monthly for both esr and mainline
Jackneill has joined #nixos-dev
<samueldr>
the one neat thing is that we could wait for, let's say, a month for the esr bump in stable
<samueldr>
to see if people on unstable get bit by things
<hexa->
or package both at the same time, and let users switch between firefox-esr-78 and firefox-esr-91
<hexa->
and default firefox-esr to firefox-esr-78 for the time being
<lukegb>
mmm
<lukegb>
and then mark firefox-esr-78 as insecure whenever we need to do that :p
<niksnut>
ma27[m]: thanks, merged!
<hexa->
yeah, something like that, sgtm
<samueldr>
I don't think having both for just two months is really worth it
plumm has joined #nixos-dev
<samueldr>
if the overlap spanned a release cycle~ish, of let's say 6 months, maybe yes
<hexa->
ok
tomberek has quit [Ping timeout: 240 seconds]
rj has quit [Ping timeout: 240 seconds]
rj has joined #nixos-dev
tomberek has joined #nixos-dev
rj has quit [Ping timeout: 240 seconds]
<Synthetica>
Why is it fetchFromGitHub (with a From and with the official capitalization) yet fetchPypi (without From and with unofficial capitalization)
<LinuxHackerman>
Because nobody thought about consistency with existing stuff when implementing it.
<Synthetica>
Is this something that can still be changed?
* Synthetica
remembers that one time I was new to nix and wanted to change a pretty big thing and people actually went with it
<LinuxHackerman>
maybe with legacy aliases. Otherwise downstreams will hate us :D
<LinuxHackerman>
but yeah I wouldn't oppose that
<sterni>
Synthetica: we could probably makes this more consistent and add aliases for it
<sterni>
and phase them out slowly
rj has joined #nixos-dev
<LinuxHackerman>
of course, there are lots of bike sheds to paint along the way to getting something more uniform
<Synthetica>
So something like alias -> warning -> remove over a few releases?
<Synthetica>
LinuxHackerman: Well I don't care which color the bikeshed has, as long as it's one color ;)
<LinuxHackerman>
I don't see any reason not to go straight to a warning alias
<sterni>
Synthetica: yeah probably rename + add an alias, remove all old usage in nixpkgs (so allowAliases = false still evals) and add a warning
<sterni>
and then we could remove it in 21.11 theoretically
<Synthetica>
Might actually submit a PR for that
<sterni>
similar to how it has been done for stdenv.lib essentially
<supersandro2000>
^ yeah
<supersandro2000>
fetchFromPypi makes more sense but it is longer
<matthewcroughan>
It looks like they made their own fetcher to get around errors (with fixed output derivations?) in the grahamcofborg-eval bot.
<matthewcroughan>
The coq derivation now has anti-patterns in it, such as removal of `src =` entirely, in favor of some custom ecosystem-specific logic.
<matthewcroughan>
As well, it also refers to top-level packages in the intputs of the derivation, such as `ocamlPackages_4_05` instead of just `ocamlPackages`
<matthewcroughan>
Check the diff between 20.09 and nixos-unstable. This derivation looks like it is getting more bespoke, less overridable over time.
<matthewcroughan>
For example, do `grep -r '"V${v}"'` on nixpkgs, you'll see that coq is the only ecosystem that uses this format, meaning I would have to research coq and use coq specific patterns in my overrides, really annoying.
rj has joined #nixos-dev
<sterni>
that is unfair tbh
<sterni>
basically every ecosystem has specifics concerning overrides
<sterni>
almost every language specific ecosystem is incompatible with overrideAttrs
<MichaelRaskin>
And really, saying that overrides require knowing how does the expression work and how does upstream do the things makes me think «Yes, and?»
<sterni>
overrides are in a bit of a state in general: derivation specific, not discoverable (you have to read the source), unstable
<sterni>
this should maybe be improved, but would be a huge effort
<sterni>
and it would probably start with making these things more discoverable by documenting them
<sterni>
I had an idea towards that I need to play around with
<gchristensen>
I find it a bit concerning, and imvho significant deviation like this deserve a good bit of scrutiny
<sterni>
also they don't circumvent fixed output derivations, I'm pretty sure fetchTarball is only there for convenience
<sterni>
all derivations specify a sha256 in the PR and thus use fetchzip
<sterni>
gchristensen: the thread has 121 comments from people apparently actively using coqPackages and maintaining it
<sterni>
matthewcroughan: I'm not sure what your point about ocamlPackages is, they need different versions of the set to compile different versions of the coq compiler it looks to me (there is a lot of changes in OCaml between versions)
<matthewcroughan>
sterni: just bringing it to attention for further scrutiny, do not shoot me :P
<matthewcroughan>
Just look at the derivation in 2003.
<matthewcroughan>
It has gotten more conditional over time. Should it really be the job of Nix to constrain the mixing of versions and ocaml like this?
<matthewcroughan>
Mixing and matching coq and ocaml is quite hard with the derivation in its current state.
<matthewcroughan>
sterni: what do you think about the removal of `src =`? It makes it quite hard to override, from my perspective, since all the other packages in nixpkgs let you do this.
<matthewcroughan>
If you make it a `.override`, you've basically given every package the freedom to do their own strangeness.
<matthewcroughan>
coq.override { version = "V8.13.2" } seems to work, whereas coq.override { version = "v8.13.2" } does not for example. Maybe this is just caching.. one sec.
<matthewcroughan>
Yes, this is the case.
<matthewcroughan>
So instead of some standard overriding structure, overriding the attrs of `src` the package `coq` is now unable to be overriden in the same way you would expect of most other nixpkgs.
<matthewcroughan>
sterni: have you managed to figure out why they use their own "meta-fetcher" instead? I could not figure that out.
<matthewcroughan>
Actually discovering the correct format to pass to `version` in this override was pretty difficult, and still required reading the source.
<matthewcroughan>
Not to mention the fact that if you override this, it will still tell you it's getting the coq-dev derivation, it's confusing to me.
<matthewcroughan>
the version it is fetching is different from the derivation name, there is a disconnect, I think this has to be an anti-pattern.
<MichaelRaskin>
That's not that rare, actually
<matthewcroughan>
It just seems to me that this derivation is complex, for seemingly no reason.
<MichaelRaskin>
It is not derivation, singular
<matthewcroughan>
In the git history, the default.nix for coq was simple, I have tried to follow the reasoning behind its growing complexity and cannot understand it.
rj has quit [Ping timeout: 240 seconds]
<MichaelRaskin>
Did it have as many versions supported and add-on-packages provided?
<matthewcroughan>
As far as I can tell, it reinvents what existing fetchers do, I do not see what it does differently.
<MichaelRaskin>
Pretty sure the answer is »
<MichaelRaskin>
«does not require to manually specify different things for different upstreams»
<matthewcroughan>
Well, I see that it actually fetches many different kinds of things, in one fetcher, dependant on argument.
<matthewcroughan>
MichaelRaskin: What does that mean? "different things"?
<MichaelRaskin>
Which is pretty natural if you have some kind of an upstream list of things
<matthewcroughan>
what are these different things you're referring to though?
<matthewcroughan>
you mean the different formats? like tarball, git, svn, etc/
<MichaelRaskin>
There is a ton of add-on paclages
<matthewcroughan>
Yes, but can you state what is meant by "does not require to manually specify different things for different upstreams" and give me an example of 'different things'
<MichaelRaskin>
I do not know how exactly the upstream index of addon-packages looks like
rj has joined #nixos-dev
<matthewcroughan>
Yeah, so I'm still not sure why meta-fetch needs to exist, or what it does differently from existing fetchers. I am curious, because as far as I can tell it exists because of some misunderstanding.
<MichaelRaskin>
But meta-fetch looks like it is written to reduce effort when mass-translating from some kind of upstream index of add-on packages
<sterni>
well meta fetch is a unified interface for fetching coqPackages sources
<sterni>
seems to be designed to be as convenient as possible mostly
<sterni>
also it supports the multiple version and version constraint resolving that mkCoqDerivation can do
<sterni>
this would just be extremely verbose with normal fetchers
<matthewcroughan>
sterni: thanks for that
<matthewcroughan>
What do you think about the removal of `src =` then?
<matthewcroughan>
Necessary evil for the coq ecosystem?
<MichaelRaskin>
It looks like it inherits src just fine
Synthetica has quit [Quit: Connection closed for inactivity]
<MichaelRaskin>
If one has more than twenty versions supported, of course src will have to be generated
cjb has joined #nixos-dev
supersandro2000 is now known as Guest61649
Guest61649 has quit [Killed (hitchcock.freenode.net (Nickname regained by services))]