rajivr has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-dev
FRidh has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
ckauhaus has joined #nixos-dev
ris has quit [Ping timeout: 246 seconds]
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-dev
ixxie has joined #nixos-dev
<Mic92>
FRidh: how do we normalize pypi names, should it be tensorboardX or tensorboardx ?
<Mic92>
Ah. found it. lowercase
<FRidh>
latter
<ckauhaus>
does anyone know why python3Packages.zodb is marked as broken?
<ckauhaus>
I don't see build failures
<ckauhaus>
(20.03 - master is different)
b1000101 has joined #nixos-dev
colemickens has quit [Quit: killed]
jonge[m] has quit [Quit: killed]
zimbatm[m] has quit [Quit: killed]
Ericson2314 has quit [Quit: killed]
timokau[m] has quit [Quit: killed]
DamienCassou has quit [Quit: killed]
emily has quit [Quit: killed]
domenkozar[m] has quit [Quit: killed]
Irenes[m] has quit [Quit: killed]
freeman42x[m] has quit [Quit: killed]
jtojnar has quit [Quit: killed]
Ox4A6F has quit [Quit: killed]
regnat has quit [Quit: killed]
arcnmx has quit [Quit: killed]
michaelpj has quit [Quit: killed]
bennofs[m] has quit [Quit: killed]
aanderse has quit [Quit: killed]
danielrf[m] has quit [Quit: killed]
roberth has quit [Quit: killed]
mkg20001 has quit [Quit: killed]
Dandellion has quit [Quit: killed]
worldofpeace has quit [Quit: killed]
JJJollyjim has quit [Quit: killed]
tokudan[m] has quit [Quit: killed]
vaibhavsagar has quit [Quit: killed]
puzzlewolf has quit [Quit: killed]
zowoq[m] has quit [Quit: killed]
ma27[m] has quit [Quit: killed]
Valodim[m] has quit [Quit: killed]
bachp has quit [Quit: killed]
rnhmjoj has quit [Quit: killed]
PkmX[m] has quit [Quit: killed]
theotherjimmy[m] has quit [Quit: killed]
matthewbauer has quit [Quit: killed]
rycee has quit [Quit: killed]
alexarice[m] has quit [Quit: killed]
xfix has quit [Quit: killed]
thefloweringash has quit [Quit: killed]
__monty__ has joined #nixos-dev
<Mic92>
ckauhaus: might have been fixed due to dependency updates.
<ckauhaus>
yes, it is only in 20.03
<Mic92>
Just sent a pull request to mark it not as broken than.
<ckauhaus>
I'd like to backport the upcoming vulnix release to 20.03
<ckauhaus>
yes, I'll check that out
matthewbauer has joined #nixos-dev
jtojnar has joined #nixos-dev
DamienCassou has joined #nixos-dev
JJJollyjim has joined #nixos-dev
tokudan[m] has joined #nixos-dev
Ox4A6F has joined #nixos-dev
michaelpj has joined #nixos-dev
danielrf[m] has joined #nixos-dev
thefloweringash has joined #nixos-dev
Valodim[m] has joined #nixos-dev
domenkozar[m] has joined #nixos-dev
bennofs[m] has joined #nixos-dev
jonge[m] has joined #nixos-dev
vaibhavsagar has joined #nixos-dev
xfix has joined #nixos-dev
rycee has joined #nixos-dev
mkg20001 has joined #nixos-dev
timokau[m] has joined #nixos-dev
bachp has joined #nixos-dev
Ericson2314 has joined #nixos-dev
zimbatm[m] has joined #nixos-dev
puzzlewolf has joined #nixos-dev
colemickens has joined #nixos-dev
arcnmx has joined #nixos-dev
Dandellion has joined #nixos-dev
Irenes[m] has joined #nixos-dev
aanderse has joined #nixos-dev
freeman42x[m] has joined #nixos-dev
worldofpeace has joined #nixos-dev
alexarice[m] has joined #nixos-dev
emily has joined #nixos-dev
theotherjimmy[m] has joined #nixos-dev
regnat has joined #nixos-dev
PkmX[m] has joined #nixos-dev
zowoq[m] has joined #nixos-dev
roberth has joined #nixos-dev
rnhmjoj has joined #nixos-dev
ma27[m] has joined #nixos-dev
orivej has joined #nixos-dev
ixxie has quit [Ping timeout: 256 seconds]
ixxie has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
<manveru>
niksnut: what do you think about changing the `<spath>` behavior within flakes to reference `self.inputs.<spath>` so you don't have to pass it around everywhere?
<manveru>
right now that syntax seems pretty useless with flakes...
<manveru>
not sure if that's technically feasible or you want to phase out that syntax altogether anyway
<Valodim>
that sounds like a very confusing kind of syntax sugar
<manveru>
at least it's simpler than what it currently does :P
<Valodim>
"in *most* kinds of .nix files, that's syntax for resolving paths via channels, but in *those* kinds of .nix files, this syntax is only a shorthand for this slightly longer expression"
<manveru>
outside flakes it does a lot more than resolving channels...
<manveru>
so i find it suitable to provide equivalent functionality within flakes :)
<Valodim>
well, it's going to be around for a couple years still
<manveru>
well, then it should at least be a syntax error...
<manveru>
right now it's syntax you can write, but never use
<Valodim>
an error saying that that syntax can't be used in flakes (ideally pointing to a longer explanation why) is a good idea for sure
<ma27[m]>
manveru: is it stated that somewhere that this will be dropped? What about non-flake setups?
<manveru>
ma27[m]: i meant that NIX_PATH has no power over flakes, so it's kinda dead for me...
<Valodim>
I wouldn't technically call it a syntax error though, unless flakes officially don't use regular nix syntax but a special version (which I don't think is the case?)
<manveru>
no, it's not a syntax error, but uses the old code paths, which try finding an environment variable that can't exist
<manveru>
given that no environment variables get passed into flakes
<ma27[m]>
yes, but if you don't use flakes, the usage of NIX_PATH is still fine (even if `flakes` gets merged to master and will appear in a stable release)
<manveru>
yes, i'm arguing for a change for stuff within flakes, not outside :)
<domenkozar[m]>
yeah losing 5k subscribers is where most of the work is
<Valodim>
it's ridiculous that this is even an issue. reddit doesn't respect official requests from projects to recover officially-named subreddits?
<infinisil>
Well I hope they do
<infinisil>
And expect them to
<FRidh>
infinisil: once you suggested using makeScope. How well does overrideScope' work when having several overlays? Does it consider and extend each of the overrides?
<infinisil>
FRidh: Afaik .overrideScopes just appends another overlay, it doesn't clear anything
<infinisil>
Yeah
<infinisil>
(not sure what you mean by "extend each of the overrides" though)
<FRidh>
I meant that one can apply overrides sequentially, and not just applying the final set of overrides.
<infinisil>
FRidh: I think that's always the case
<infinisil>
(foo.override (...)).override (...)
<infinisil>
FRidh: Ah I think you might be asking about e.g. pythonPackages.override (old: { packageOverrides = ...; })
<infinisil>
Which unless you use `lib.combineExtensions old.packageOverrides (self: super: ...)` would only use the last packageOverrides
<infinisil>
But if you use makeScope, you don't need to use .override packageOverrides, but can instead do `.overrideScope (self: super: ...)`
<FRidh>
The question was confusing. Basically, what I'm concluding now is that overrideScope' works great if you want to extend the package set for a single version, but does not help if you want to modify all python sets. I'm inclined now to add a pythonPackagesOverrides = [ (self: super: {}) ]; to all-packages.nix. Still, I would prefer if we have an RFC on this topic in general.
<FRidh>
That would increase the scope significantly.
<infinisil>
I think we might have to include this, because otherwise we end up having to bolt whatever we need to make package sets works to the solution we end up with
<FRidh>
it's just annoying that every package set does this differnetly because there are no guidelines whatsoever
<infinisil>
But also many are hard to override
<infinisil>
Very convoluted
<FRidh>
which is probably because many (including myself) don't know well how to implement such feature.
<infinisil>
I have thought about this for a bit, I'd be interested to attempt this
<FRidh>
with package sets it is imporant to consider the different types of sets though, e.g. packages versus plugins, and whether the set should contain only the selected packages (e.g. python) or should be an overridden version of another set (e.g. qt)
<infinisil>
The qt thing of essentially using `pkgs // pkgs.qt` as the argument feels very bloated to me
<infinisil>
Wouldn't mind replacing this with something else
<infinisil>
The whole pkgs set is very bloated too anyways, I think a good solution would also not expose different versions of packages as top-level attributes
<FRidh>
Aside from the fact we try to avoid multiple versions, where would you keep those versions if you do not expose them in the top-level?
<infinisil>
One way is to expose them as passthru attributes of the main version. E.g. pkgs.linuxPackages.version."4.8"
<FRidh>
That's a way. I don't think this really is such a big problem, considering the huge amount of packages there are already, although some structure wouldn't hurt
<infinisil>
Another would be to have `pkgs.versioned.linuxPackages."4.8"`, and `pkgs.linuxPackages` just being an alias to that. Then you could have all specific versions in pkgs.versioned, but also default ones in pkgs.*
<adisbladis>
ajs124: I saw, that's why I commented.
<ajs124>
Yeah, it's pretty annoying. The seem to have turned of submissions a few weeks ago, but not been active in any other way and ignoring messages and requests -.-
<ajs124>
Why would you do that? Just hand it over, it's not high traffic, there are enough people that would mod it.
<FRidh>
abathur: no strong opinion, but discourse likely reaches the people you need to reach
<Profpatsch>
For backports, do I ping the release manager of that release?
<ma27[m]>
Profpatsch: usually not unless you're unsure if a backport is sensible. Also, we have @nixos/backports (or something like this to ping)
<Profpatsch>
It’s a nonbreaking release of lorri that people will want to have on 20.03
<Profpatsch>
Although I’m not entirely sure if that’s against policy
<Profpatsch>
The nixpkgs manual is not really specific about what the backporting policy is
<ma27[m]>
I'd say it's fine then, it's a leaf package in the end, right?
<adisbladis>
We don't even have a backporting policy?
<Profpatsch>
I guess
<Profpatsch>
yeah, leaf and dev tool at that
<adisbladis>
Profpatsch: You're the maintainer, so I think it's at your discretion
<Profpatsch>
cool
<ma27[m]>
I fully agree with adisbladis , a maintainer usually knows the package best (especially since Profpatsch is the author here :))
<worldofpeace>
hmm
<worldofpeace>
the discretion of the release manager seemed to be customary during beta and final release, I'd think the same during the rest of the lifetime of the release. but tbh that doesn't scale well at all
<worldofpeace>
since it's a leaf thingy, I think it would be fine
<Profpatsch>
worldofpeace: I like the idea of the @nixos/backports team
<qyliss>
Yeah I'd always defer to RM
<Profpatsch>
Should we put it in the manual?
<worldofpeace>
and as adisbladis said, if you're like the maintainer, and at times, if you're like a maintainer of a whole ecosystem, I don't think many people are going to be able to audit better than you. (especially since we don't really have a backports policy, but rather a backports word of mouth best practices)
<worldofpeace>
Profpatsch: I might have wrote something in the updated RM docs, can't remember (there could actually be something in there, though I haven't memorized it yet)
<worldofpeace>
and also in the case of @nixos/backports team, the scope of it really isn't so clear, and I also happen to be on that also 😸
<ma27[m]>
worldofpeace: does that scale though? I think that especially for low-risk packages it's fine if the maintainer themselves takes care of it.
<worldofpeace>
ma27: "the discretion of the release manager seemed to be customary during beta and final release, I'd think the same during the rest of the lifetime of the release. but tbh that doesn't scale well at all"
<worldofpeace>
I think that's what has been going on tbh
<worldofpeace>
I will say, for any PR labeled [20.03] I've been sorting through them
<worldofpeace>
so yeah, not enough rm to go around for that obviously, else we'd have patches for security not get merged timely
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #nixos-dev
orivej_ has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
justanotheruser has quit [Ping timeout: 272 seconds]
justanotheruser has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
Cale has quit [Read error: Connection reset by peer]
abathur has quit [Quit: abathur]
Cale has joined #nixos-dev
ris has joined #nixos-dev
drakonis has joined #nixos-dev
<aszlig>
oh geesh, this dns thingy is opening up a can of worms...
<gchristensen>
aszlig: I really appreciate how clear and direct your comment is
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
<aszlig>
gchristensen: well, i've had exactly those kind of reviews several times, where nobody actually said it clear enough and people tend to somewhat "silently" be against it
<gchristensen>
right
<aszlig>
but maybe it's just me who is unable to parse the meaning of people's sentences
Synthetica has quit [Quit: Connection closed for inactivity]
_ris has joined #nixos-dev
ris has quit [Ping timeout: 272 seconds]
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
ris has joined #nixos-dev
_ris has quit [Ping timeout: 244 seconds]
justanotheruser has quit [Ping timeout: 246 seconds]
justanotheruser has joined #nixos-dev
avn has quit [Read error: Connection reset by peer]
avn has joined #nixos-dev
ckauhaus has quit [Quit: WeeChat 2.7.1]
cole-h has joined #nixos-dev
b1000101 has quit [Quit: Lost terminal]
FRidh has quit [Ping timeout: 246 seconds]
FRidh has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
cole-h has quit [Client Quit]
cole-h has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
cole-h has quit [Client Quit]
cole-h has joined #nixos-dev
cole-h has quit [Client Quit]
averell has quit [Quit: .]
averell has joined #nixos-dev
cole-h has joined #nixos-dev
<c00w>
Anyone know what the current status with SRI hashes is?
<c00w>
It looks like we have support - should all the hashes in nixpkgs be rewritten?
<c00w>
Should new hashes only be allowed if they're in the new format?
<c00w>
Should nixpkgs-updater be taught to use SRI hashes?
<qyliss>
Older nix versions that people still use don't support them
<qyliss>
AIUI
<samueldr>
and that's important to eval unstable or upgrade
<samueldr>
though that's my understanding too
<niksnut>
they're safe to use on nixpkgs master
<niksnut>
because the minimum required version is 2.2
<samueldr>
nice, didn't know it had been done since the last time there was discussion about that :)
<c00w>
So it sounds like we can use SRI hashes everywhere. Was someone coordinating the effort? Is that the long term desired direction?
<kloenk>
I remember of something where the nix-daemon needs much ram while importing NARs from a client. Is this because the use of TeeSink? or did I mix something up?
<samueldr>
is there any reason we would like to make an automated change for that?
<samueldr>
a net negative is that all PRs touching hashes would be in conflict
<manveru>
what's the benefit of SRI hashes?
<manveru>
doesn't that stand for sub-resource-integrity?
abathur has joined #nixos-dev
<samueldr>
correct me if I'm wrong, but I think it's because it is borrowing the scheme for the hashes
orivej has quit [Ping timeout: 246 seconds]
<samueldr>
where you have the hash type as part of the hash string
orivej has joined #nixos-dev
<manveru>
yeah... so the attrname is always the same now?
<manveru>
i've just been converting my hashes to the old format, it's a bit annoying :)
<c00w>
samueldr: Well at a bare minimum if we're trying to go towards SRI hashes, then I can add support for it to go modules, then teach nixpkgs to use them when it updates stuff, which would eventually migrate that corner of nix
<c00w>
I can also bulk migrate them, but that's a cleanup step once nixpkgs-updater understands it.
<manveru>
i just don't see the need to migrate if nothing has changed about the content itself :)
<samueldr>
c00w: that's a perfectly fine approach if SRI hashes are now okay to use
<samueldr>
but bulk in non-automated parts of Nixpkgs is simply rude :)
<c00w>
samueldr: AFAIk they are ok to use - minimum nixver on master is 2.2 which supports them.
<samueldr>
yes, as niksnut stated
__monty__ has quit [Quit: leaving]
ixxie has quit [Quit: Lost terminal]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]