supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
jonringer has quit [Remote host closed the connection]
jonringer_ has quit [Remote host closed the connection]
<siraben>
jonringer recommended me to use `nix-instantiate --readonly-mode --eval --strict --show-trace --json ./maintainers/scripts/find-tarballs.nix --arg expr 'import ./maintainers/scripts/all-tarballs.nix'` to find evaluation errors, which on my machine is a good substitute for evaluation using outpaths.nix
<siraben>
good in that it's faster
cole-h has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
rajivr has joined #nixos-dev
kalbasit_ has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
abathur has joined #nixos-dev
<abathur>
is there policy/guidance on closing issues? I've noticed for a bit that I have the button, and it is tempting to use...
<samueldr>
AFAIK not really
<samueldr>
but obviously if it's fixed, it can be closed
<samueldr>
but we probably need something
<samueldr>
since too often issues "become" hijacked by similar issues at the surface
<samueldr>
like that few years old grub issue which probably has half as many distinct problems than comments tacked into
<samueldr>
it makes it completely unactionable
<samueldr>
and closing it is impossible since "it's not resolved"
<samueldr>
(without more information)
<abathur>
in this case it's a 2018 issue that was reported, and then someone said they werent seeing in master, and there's no response after except stale bot
<samueldr>
probably fine
<samueldr>
especially if the reporter themselves said so
<abathur>
so my personal inclination is, "I'm a tyrant this is now closed. But I am benevolent and will reopen if you squeak."
<abathur>
no comment from the reporter
<samueldr>
ah, another user
<samueldr>
probably still fine
<samueldr>
and yeah, they themselves can also re-open AFAIK
<samueldr>
probably worth it to prepare some words saying what you said
<abathur>
ah, well, all the better
<samueldr>
for many contributors the issues tab is a lost cause I think, understandably
<samueldr>
I mean, they see it as a lost cause
<samueldr>
I know I do because of the inability to close likely-irrelevant issues
<samueldr>
since we don't have a policy
<abathur>
there's a batman movie about this
<abathur>
<3 samueldr
<{^_^}>
samueldr's karma got increased to 314, it's a crit!
<samueldr>
Batman Forever?
<abathur>
should have like, ofborg for issues, labels your issue if you submit a repro that it can confirm
<abathur>
and then occasionally re-runs your repro against master and politely closes it if it stops reproducing but is still open
<samueldr>
that would be quite funky
* abathur
submits a repro to mine crypto
<samueldr>
RSA or ROT13?
<abathur>
wonder if the CI services bother running some sort of anti-crypto-mining system, and if so if it causes trouble for related OSS
<samueldr>
I think it does and they do
kalbasit_ has quit [Ping timeout: 264 seconds]
<siraben>
Section 3.4 of Nix PhD thesis, "ultimately, how well the scanning approach works is an empirical question [...] scanning works very well in practice, as evidenced by the large set of components in the Nix Packages collection, which have not yielded a single example of a hidden pointer"
<siraben>
Is this still true? Has there been an example of a hidden pointer in Nixpkgs?
<siraben>
Basically the concern is if a store reference is encoded in a non-ASCII format (UTF-16, compressed, etc.) and is dereferenced at runtime, then the reference may no longer exist in the store leading to incomplete deployment
jonringer has joined #nixos-dev
<regnat[m]>
siraben: I think this occasionally happens with python wheels or java jars (as they are − potentially compressed − zip files)
<regnat[m]>
But I think in practice it's a much smaller issue than stuff expecting to magically find its dependencies in the environment without hardcoding their path
<clever>
Regnat[m]: i think android uses a trick where it adds dynamic libraries with a special flag to not compress them, so you can still mmap the library right out of the zip
<clever>
but you may need a fixupphase, that goes over every zip-like file, and undoes the compression if it has references
<regnat[m]>
<clever "Regnat: i think android uses a t"> Oh my…
<eyJhb>
Is there any convention on dirs/paths ending with a `/` in configs? E.g. if I have a datadir in a module, should that dir end with a `/`, or not? (not sure if there is any concensus on this)
bk1603[m] has quit [*.net *.split]
chvp has quit [*.net *.split]
danielrf[m] has quit [*.net *.split]
JJJollyjim has quit [*.net *.split]
piegames has quit [*.net *.split]
jdnixx-M has quit [*.net *.split]
joepie91 has quit [*.net *.split]
zhaofeng has quit [*.net *.split]
chvp has joined #nixos-dev
danielrf[m] has joined #nixos-dev
bk1603[m] has joined #nixos-dev
joepie91 has joined #nixos-dev
zhaofeng has joined #nixos-dev
piegames has joined #nixos-dev
jdnixx-M has joined #nixos-dev
JJJollyjim has joined #nixos-dev
alexarice[m] has quit [Ping timeout: 244 seconds]
michaelpj has quit [Ping timeout: 244 seconds]
jonge[m] has quit [Ping timeout: 244 seconds]
roberth has quit [Ping timeout: 244 seconds]
Ox4A6F has quit [Ping timeout: 244 seconds]
regnat has quit [Ping timeout: 240 seconds]
Irenes[m] has quit [Ping timeout: 240 seconds]
ma27[m] has quit [Ping timeout: 243 seconds]
nh2[m] has quit [Ping timeout: 243 seconds]
garbas[m] has quit [Ping timeout: 243 seconds]
ryantm has quit [Ping timeout: 243 seconds]
emily has quit [Ping timeout: 243 seconds]
maralorn has quit [Ping timeout: 243 seconds]
symphorien[m] has quit [Ping timeout: 243 seconds]
puzzlewolf has quit [Ping timeout: 243 seconds]
colemickens has quit [Ping timeout: 243 seconds]
aanderse has quit [Ping timeout: 246 seconds]
regnat[m] has quit [Ping timeout: 246 seconds]
timokau[m] has quit [Ping timeout: 246 seconds]
dtz has quit [Ping timeout: 246 seconds]
Valodim[m] has quit [Ping timeout: 246 seconds]
DamienCassou has quit [Ping timeout: 246 seconds]
philipp[m] has quit [Ping timeout: 246 seconds]
siraben has quit [Ping timeout: 246 seconds]
bbigras has quit [Ping timeout: 246 seconds]
rnhmjoj has quit [Ping timeout: 246 seconds]
thefloweringash has quit [Ping timeout: 246 seconds]
bk1603[m] has quit [Ping timeout: 258 seconds]
chvp has quit [Ping timeout: 258 seconds]
JJJollyjim has quit [Ping timeout: 258 seconds]
immae has quit [Ping timeout: 265 seconds]
domenkozar[m] has quit [Ping timeout: 265 seconds]
<{^_^}>
#110404 (by eyJhb, 1 day ago, open): WIP: module mautrix-* new service to handle all mautrix services
lopsided98 has joined #nixos-dev
<eyJhb>
(ping V infinisil and anyone else ! :))
nyanotech has quit [Quit: No Ping reply in 180 seconds.]
nyanotech has joined #nixos-dev
kraem has joined #nixos-dev
chvp has joined #nixos-dev
Ox4A6F has joined #nixos-dev
roberth has joined #nixos-dev
symphorien[m] has joined #nixos-dev
thefloweringash has joined #nixos-dev
siraben has joined #nixos-dev
bk1603[m] has joined #nixos-dev
ma27[m] has joined #nixos-dev
dtz has joined #nixos-dev
immae has joined #nixos-dev
maralorn has joined #nixos-dev
domenkozar[m] has joined #nixos-dev
jonge[m] has joined #nixos-dev
emily has joined #nixos-dev
Valodim[m] has joined #nixos-dev
ryantm has joined #nixos-dev
regnat[m] has joined #nixos-dev
timokau[m] has joined #nixos-dev
alexarice[m] has joined #nixos-dev
michaelpj has joined #nixos-dev
Irenes[m] has joined #nixos-dev
rnhmjoj has joined #nixos-dev
jtojnar has joined #nixos-dev
aanderse has joined #nixos-dev
DamienCassou has joined #nixos-dev
mjlbach has joined #nixos-dev
mjlbach has quit [Ping timeout: 246 seconds]
DamienCassou has quit [Ping timeout: 246 seconds]
emily has quit [Ping timeout: 240 seconds]
Valodim[m] has quit [Ping timeout: 240 seconds]
Irenes[m] has quit [Ping timeout: 258 seconds]
ma27[m] has quit [Ping timeout: 258 seconds]
Ox4A6F has quit [Ping timeout: 260 seconds]
michaelpj has quit [Ping timeout: 240 seconds]
roberth has quit [Ping timeout: 240 seconds]
chvp has quit [Ping timeout: 240 seconds]
maralorn has quit [Ping timeout: 240 seconds]
immae has quit [Ping timeout: 240 seconds]
rnhmjoj has quit [Ping timeout: 246 seconds]
kraem has quit [Ping timeout: 246 seconds]
alexarice[m] has quit [Ping timeout: 258 seconds]
dtz has quit [Ping timeout: 258 seconds]
bk1603[m] has quit [Ping timeout: 258 seconds]
aanderse has quit [Ping timeout: 265 seconds]
timokau[m] has quit [Ping timeout: 265 seconds]
ryantm has quit [Ping timeout: 260 seconds]
thefloweringash has quit [Ping timeout: 260 seconds]
siraben has quit [Ping timeout: 260 seconds]
symphorien[m] has quit [Ping timeout: 260 seconds]
jonge[m] has quit [Ping timeout: 244 seconds]
domenkozar[m] has quit [Ping timeout: 244 seconds]
jtojnar has quit [Ping timeout: 268 seconds]
regnat[m] has quit [Ping timeout: 268 seconds]
jonringer has quit [Ping timeout: 264 seconds]
zarel has joined #nixos-dev
jtojnar has joined #nixos-dev
bbigras has joined #nixos-dev
Ox4A6F has joined #nixos-dev
michaelpj has joined #nixos-dev
roberth has joined #nixos-dev
mjlbach has joined #nixos-dev
nh2[m] has joined #nixos-dev
maralorn has joined #nixos-dev
arcnmx has joined #nixos-dev
ryantm has joined #nixos-dev
danielrf[m] has joined #nixos-dev
colemickens has joined #nixos-dev
rycee has joined #nixos-dev
immae has joined #nixos-dev
thefloweringash has joined #nixos-dev
timokau[m] has joined #nixos-dev
siraben has joined #nixos-dev
chvp has joined #nixos-dev
kraem has joined #nixos-dev
aanderse has joined #nixos-dev
ma27[m] has joined #nixos-dev
Valodim[m] has joined #nixos-dev
DamienCassou has joined #nixos-dev
JJJollyjim has joined #nixos-dev
Dandellion has joined #nixos-dev
puzzlewolf has joined #nixos-dev
symphorien[m] has joined #nixos-dev
domenkozar[m] has joined #nixos-dev
dtz has joined #nixos-dev
Irenes[m] has joined #nixos-dev
garbas[m] has joined #nixos-dev
jonge[m] has joined #nixos-dev
philipp[m] has joined #nixos-dev
Ericson2314 has joined #nixos-dev
alexarice[m] has joined #nixos-dev
emily has joined #nixos-dev
worldofpeace has joined #nixos-dev
vaibhavsagar has joined #nixos-dev
bennofs[m] has joined #nixos-dev
regnat has joined #nixos-dev
rnhmjoj has joined #nixos-dev
codyopel has joined #nixos-dev
bk1603[m] has joined #nixos-dev
regnat[m] has joined #nixos-dev
treed[m] has joined #nixos-dev
zowoq[m] has joined #nixos-dev
mkg20001 has joined #nixos-dev
dywedir[m] has joined #nixos-dev
released has joined #nixos-dev
<siraben>
Regnat, clever I see
<siraben>
yay, only 1942 occurences of stdenv.lib remaining
<symphorien[m]>
> /foo/
<{^_^}>
error: path '/foo/' has a trailing slash
<symphorien[m]>
eyJhb: at least nix refuses trailing slashes
<eyJhb>
Hmm. I guess I will do it without the trailing slash then. Thanks symphorien[m] ! :)
lopsided98 has quit [Ping timeout: 260 seconds]
lopsided98 has joined #nixos-dev
__monty__ has joined #nixos-dev
<rnhmjoj>
philipp: i made some progress: the problem is gstreamer is not detecting the input devices (at least not audio sources) because nheko in fact can see my webcam
<rnhmjoj>
i tried with both pulseaudio or alsa
<philipp[m]>
ekleog: Alsa made some progress:
<philipp[m]>
>philipp: just found a solution for the gstreamer issue you had with nheko, if you hadn't found it yet: `wrapProgram "$prog" --suffix GST_PLUGIN_SYSTEM_PATH_1_0 : "${pluginPath}"` with `makePluginPath = plugins: builtins.concatStringsSep ":" (map (p: p + "/lib/gstreamer-1.0") plugins);` and `pluginPath = makePluginPath [ gstreamer gst-plugins-base gst-plugins-good gst-plugins-bad
<rnhmjoj>
running `nix-shell --pure -p gst_all_1.gst-plugins-base --run gst-device-monitor-1.0` i get "Failed to start device monitor!"
<philipp[m]>
>gst-plugins-ugly gst-libav ];` (taken from `pkgs/tools/networking/gmrender-resurrect/default.nix`) is an example way to make things work I think
<rnhmjoj>
philipp: gstreamer already populates that variable: i only had to do `qtWrapperArgs+=(--prefix GST_PLUGIN_SYSTEM_PATH_1_0 : "$GST_PLUGIN_SYSTEM_PATH_1_0")`
<philipp[m]>
Can you push your state somewhere? I've got some time on my hands and could fiddle around with it a little.
<Profpatsch>
This is just setup so far, it is able to parse arbitrary nix files
srk has joined #nixos-dev
<Profpatsch>
And then you have a syntax tree that you can query things on with a sexp-based language
<Profpatsch>
Or just manually traverse with “go left/right/up/down” style functions
<Profpatsch>
And then it depends on what you want to do
<Profpatsch>
e.g. we wanted to switch `lib, stdenv` in headers with `stdenv, lib`, taking into account stuff like default values.
<Profpatsch>
Mark the entries, extract source spans, transpose source spans
<Profpatsch>
tree-sitter only gives you the source spans, then you have to transpose yourself, but that should be doable.
<symphorien[m]>
Ah so the refactoring actually happens on s expressions... with lisp then ?
<Profpatsch>
No, the refactoring is purely textial
<Profpatsch>
*textual
<Profpatsch>
e.g. “if there is a function header at the toplevel of the file, and if the first argument is `lib` and the second is `stdenv`, then output the file name and the source spans of both”
<Profpatsch>
And then you feed them into a tool which knows how to transpose source spans
<symphorien[m]>
Ok
<Profpatsch>
And then you evaluate all of nixpkgs to see whether you introduced evaluation errors
<Profpatsch>
It really depends on what you are doing
<Profpatsch>
But I feel like more tooling will give us more incremental ways of doing transformations.
<Profpatsch>
And having a good parsing framework ready to use with examples is the best next incremental step that is not “manually go through files by hand and use editor macros” or “use complicated scripts of arbitrary sed pipelines”
<Profpatsch>
The next step after that would be to use some static semantic information of how the evaluator works to do stuff like e.g. “rename symbol x in this file”
<Profpatsch>
And then the next step would be to have a standardized way to know the semantic conventions in nixpkgs to e.g. rename as symbol in all-packages.nix and also find all `callPackage` invocations that has this symbol passed
<Profpatsch>
But I don’t see this happening any time soo.
<Profpatsch>
I mean this is nice and all, but strictly free-time work. I don’t see how anybody could be paid to do refactorings like this
<Profpatsch>
I mean this is not even technical debt in the strictest sense, just “convention debt”
<Profpatsch>
It lowers friction, freeing people to not having to think about whether this pkgs.stdenv.lib is semantically different from pkgs.lib and remember it in the future.
AlwaysLivid has quit [Ping timeout: 268 seconds]
<Profpatsch>
And since nixpkgs itself is usually just a tool to get tools installed, it’s a value proposition of the second or even third order.
AlwaysLivid has joined #nixos-dev
<edef>
on one hand, i wonder how many worthwhile refactors we have that we can do mechanically
<Profpatsch>
Nothing can be done mechanically
<edef>
especially given how little static information we have
<Profpatsch>
Most things are not possible by hand
<Profpatsch>
Some things are possible but very repetetive
<Profpatsch>
Some things can be done with clever macros or scripts
janneke has quit [Ping timeout: 265 seconds]
<Profpatsch>
Many things only become feasible with an AST-parser
<Profpatsch>
The most important property is that you can go from a clean checkout to a patched working dir in a small (<5min) amonut of time
<Profpatsch>
Because otherwise you can’t reproduce the run to improve the scripts incrementally
<Profpatsch>
Even better if the script is idempotent and any changes just add onto the existing changes, but very hard to do.
<Profpatsch>
So a quick “0 to patch” pipeline with formalized scripting (and no manual intervention) is paramount
<philipp[m]>
That looks like a huge step in the right direction for bridges. I'm not sure about namespacing though. Maybe we should add `services.matrixBrdiges.mautrix` or sth? Should make all the moduled bridges way more easily discoverable.
<philipp[m]>
Or `service.matrixAppservice`?
<eyJhb>
Currently running this setup, and it works flawless so far :p I am not sure about the namespacing however. But it could be nice. I would be more of the secound I would say, `service.matrixAppservices`, but could also be a seperation in-between? services.matrix.appbridges, ie. services.matrix.synapse, etc.?
<philipp[m]>
Yeah, that makes sense to me. Maybe we should ask over in #matrix-nix:transformierende-gesellschaft.org , what people there think about it.
janneke has joined #nixos-dev
<philipp[m]>
And I think that most of your stuff can be generalised away from mautrix and be a general tool for most matrix appservices. I think they all behave pretty similarly, mautrix or not.
<siraben>
I didn't know GNU parallel was so controversial
<symphorien[m]>
The parallel in moreutils is far for a drop in replacement
<symphorien[m]>
So we should keep the gnu one
<siraben>
What about licensing?
<philipp[m]>
I don't see how the GPL prohibits any of the described behaviours. parallel is still featured on the gnu.org website. Also it's still featured on gnu.org. I think they'd pull the plug pretty quick if they had concerns.
<symphorien[m]>
Ianal, but if it's a gnu project, it's probably gpl enough.
<philipp[m]>
I also didn't mean to type that out two times and on top of that type that out two times.
<eyJhb>
philipp[m]: Could do that, is that the most active Nix Matrix community?
<supersandro2000>
siraben: it has really strong opinions about citing its usage
<supersandro2000>
if it is features on gnu.org with a gnu license I am pretty sure the gnu org would do something if it violates the gnu license for a long time
<supersandro2000>
*featured
<siraben>
I see
<supersandro2000>
also debian has it in their main repository
<philipp[m]>
I would suggest acting polite and friendly to those kinds of requests, even if they seem outlandish. Acting in a way that can be seen as antagonising early from a position of power only makes the whole thing more messy than it needs to be.
<Profpatsch>
siraben: parallel is annoying, but we should leave it up to users and not dictate whether they want to use it
<supersandro2000>
I just don't think that downstream packaging repositories should need to decide if an upstream project violates their license in an non obvious way
<Profpatsch>
jtojnar: __structuredAttrs is a good example of something that is not automatable at all
<Profpatsch>
Because as far as I understand it, it requires semantic updates in the build scripts of packages
<Profpatsch>
that is they have to parse json instead of reading environment variables.
<supersandro2000>
There are obvious violations on which I think we should act in a timely manner but when all other repositories have it since years under gpl3 and not unfree then I am not sure if we set a statement here
<gchristensen>
debian has real lawyers to help decide, so if debian has it gpl3 then we're nobody to disagree
<supersandro2000>
we have no real lawyers and honestly I hope we don't need them for packaging anytime soon
<supersandro2000>
(at least I am aware of)
<gchristensen>
well, as a project who distributes binaries, it is our responsibility to follow the license of the software we package. so, we do sometimes need advice from copyright / license experts and lawyers -- and we do from time to time get that help
<Profpatsch>
That’s what the FSF is specialized to do for the free software community after all
<supersandro2000>
didn't know that
<Profpatsch>
I mean, I put the ball into rkoe’s half now, let’s see.
<supersandro2000>
but what if a project violates their license in an not very obvious way?
<gchristensen>
we do our best, and if someone notifies us we're doing the wrong thing we fix it
<Profpatsch>
Then they usually release statements upon request afaiu
<Profpatsch>
Especially when things relate to the GNU licenses
<Profpatsch>
Example, jslint/jshint, which was “MIT + one clause to use the software for good not evil”
<Profpatsch>
That’s a good (and cautionary) precedence
<Profpatsch>
Although not strictly GNU-related, but iirc the FSF released a statement
<Profpatsch>
btw it could indeed happen that GNU parallel is declared as non-GPL because of the nagbar, maybe just nobody has asked the FSF for a statement yet
<jtojnar>
Profpatsch: not sure if bash can use same name for structured variables and environment variables
<jtojnar>
e.g. if we start passing variables as structured `NIX_CFLAGS_COMPILE` bash variable might be a list
<philipp[m]>
rnhmjoj: I'll check it out when I'm back home.
<jtojnar>
but for child processes, it would be stringified somehow
<Profpatsch>
I … am slightly disturbed that the aim is to use advanced bash features in stdenv
<jtojnar>
but I think the export flag only marks bash variables to export
<Profpatsch>
As in: not just the internals but alse the package code
<jtojnar>
well, that is the whole point of structuredAttrs – to be able to pass lists to stdenv
<jtojnar>
if lists are advanced features in bash now, I would rather switch to LISP-based stdenv
<gchristensen>
we already do use lists, of course
<Profpatsch>
Arrays are medium well-known I’d say, assoc arrays pretty much never appear in the wild from what I’ve seen
<siraben>
supersandro2000: lumo seems to be fine in 110591
<jtojnar>
alternative would be fixing the array encoding but that would probably be a BC break too
<Profpatsch>
I have a major respect from anybody trying to do changes to stdenv
<Profpatsch>
s/from/for
<jtojnar>
but currently, people are trying to pass lists containing strings containing spaces and then they get confused why it does not work
<Profpatsch>
Because the semantics of internal and external API and what packages are intended to use and what they actually use is pretty much impossible to disentangle.
<Profpatsch>
And since there is no checks, no types, and no structured data that isn’t silently converted to strings, you can’t change anything without silently breaking lots and lots of stuff
<jtojnar>
right, we will basically have to break BC or fork stdenv
<jtojnar>
it might be possible to add some checks to mkDerivation
<jtojnar>
but probably not a full coverage
<gchristensen>
I hope we can avoid second system syndrome as we endeavor to improve stdenv
<jtojnar>
I would not call the current stdenv “small, elegant, and successful system” 😆
<jtojnar>
well two of those things anyway
<gchristensen>
right :)
<supersandro2000>
siraben: It would be cool if it would be zero rebuilds because then we could take a closer look at lumo. With 500 changing files that is not that easy.
<siraben>
supersandro2000: it's only 101 changed files for that PR, I don't understand how it is changing because only the meta is edited
<siraben>
how lumo is changing*
<supersandro2000>
the 500 changes was the other one? I'll take another look
<supersandro2000>
siraben: Not sure why either but I merged it.
<Profpatsch>
jtojnar: problem is that incremental changes are the only possible way forward
<Profpatsch>
the value is in the clients, not in stdenv
<jtojnar>
I agree
<Profpatsch>
So as long as it’s “good enough”, it’s more important to have more clients, and less to make stdenv perfect
<supersandro2000>
fixed it
<Profpatsch>
so “pkgs.stdenv2” would be a mistake imho
<supersandro2000>
there was some zero wide space before the *
<Profpatsch>
But, like, slowly adding more checks and balances to stdenv, fix the breakage, add more linters, fix the breakage, and so on
<Profpatsch>
until we can switch
<Profpatsch>
We have the advantage that we have more structured data coming from the package, so we can add lints on that side
<Profpatsch>
Unsure how we could add checks to the consuming side in bash though
<Profpatsch>
Maybe we can add them around hooks?
<jtojnar>
that's why I wanted to do the move to env attribute first
<Profpatsch>
jtojnar: hm, if you can create a list of properties that each use-site of the soon-to-be structured variables should have, maybe we can implement checks that tell us whether it would be used in the wrong way
<Profpatsch>
let me read the first PR
<jtojnar>
structuredAttrs stops setting attributes passed to `mkDerivation` as environment variables
<jtojnar>
only doing it for those in `env` attribute
<jtojnar>
I extracted the `env` attribute support into a separate PR so that we could deprecate the old use case gradually
<Profpatsch>
jtojnar: ah, but that’s only one failure case, rigth?
<Profpatsch>
Like, I can think of a few other probably
<Profpatsch>
e.g. what happens to compiler argument lists, depending on how they are interpolated
<jtojnar>
right, but it is one of the biggest ones, IIRC
<jtojnar>
right, that one is harder to detect
<jtojnar>
especially since it is undefined at the moment
<Profpatsch>
So all _structuredAttrs does is write a json with all the non-special arguments to the build directory
<Profpatsch>
And you want to translate that to stdenv by translating that to arrays and assocs?
<Profpatsch>
what is hindering us from using a bunch of helper functions instead? e.g. expose a different interface instead of re-using the same variables?
<jtojnar>
IIRC that is how it implemented in Nix – all or nothing
<jtojnar>
I guess we could but we would want to do that with most variables passed to mkDerivation
<jtojnar>
things like makeFlags & co.
<Profpatsch>
Hm, if it’s opt-in there could be multiple modes maybe.
<Profpatsch>
Simple packages can just set the structured stdenv to true with a few simple translation rules.
<Profpatsch>
And more complex ones can opt for the explicit interface via helper functions
<Profpatsch>
And then have a mechanical (but still by-hand probably) translation of the helper functions to bash-builtins.
<Profpatsch>
where the “canonical” but maybe slower interface is via the helper functions, and then the bash built-in via arrays is just an optimization
<Profpatsch>
So the semantic change happens on translation to helper functions, and then the next step is purely mechanical
<Profpatsch>
Or hm, what about a “hybrid” mode where stdenv already uses stucturedAttrs, and unsets the stuff that is a complex attr now.
<Profpatsch>
And all simple attrs are set as they were before.
<Profpatsch>
So simple packages still work as they did before, but stuff that would move to complex repr would error out
<Profpatsch>
And you opt-in by package
<jtojnar>
people already rely on the fact that Nix stringifies list attributes for environment variable
<jtojnar>
and missing NIX_CFLAGS_COMPILE might error out but the error will be very confusing
<jtojnar>
so the hybrid mode would have to have the structured attrs available in bash stdenv and stringify at exec boundary somehow
<jtojnar>
just unsetting them (not sure how) would break many packages
<jtojnar>
but yeah, if we add a check to mkDerivation that attributes unknown to stdenv have to be string, that might work
<jtojnar>
but then Eelco was not fan of adding more Nix-side checks
teto has quit [Ping timeout: 265 seconds]
teto has joined #nixos-dev
cole-h has quit [Ping timeout: 240 seconds]
<Profpatsch>
jtojnar: The trick is to make things that should still work (that is: scalars) work as before, while breaking the other things when flipping the opt-in switch
<Profpatsch>
Which unsetting list variables would achieve
<Profpatsch>
And then you have to switch to the new semantics
<Profpatsch>
Or opt-out again
<Profpatsch>
So you don’t block people while also not breaking them and updating nixpkgs incrementally
<Profpatsch>
Since you can’t really discover the wrong uses except manually or by introducing breakage, things cannot be automated
<Profpatsch>
but at least they can be done incrementally
vaibhavsagar has quit [Quit: Idle for 30+ days]
mkg20001 has quit [Quit: Idle for 30+ days]
dywedir[m] has quit [Quit: Idle for 30+ days]
bennofs[m] has quit [Quit: Idle for 30+ days]
treed[m] has quit [Quit: Idle for 30+ days]
<supersandro2000>
the danger with opt-out is that to many people opt-out and it is not bit by bit removed
<Profpatsch>
supersandro2000: that’s why there is a team of people doing these changes in one go (yay monorepo!), instead of every maintainer on their own
<Profpatsch>
So you can work on cross-cutting concerns like that othogonally to “business as usual”
<Profpatsch>
the stdenv.lib refactor was one simple example of how something like that can work
<Profpatsch>
Google for example has whole teams that do treewide infrastructural changes like that full time
<Profpatsch>
Which also only works because they have a monorepo with some form of cohesion
<jtojnar>
Profpatsch: well lists get passed as strings now so people use lists where they should use strings (e.g. CXXFLAGS) so that would have to be opt-in as well
<supersandro2000>
if you have multi repo merge trains that this can also work but is harder
<Profpatsch>
jtojnar: Ah, good point … But e.g. opting in in buildRustCrae would make it obvious because reverse deps would break that pass a list right?
<Profpatsch>
So if you patch non-leaves, you have to care about your clients of coruse
<jtojnar>
Profpatsch: yeah, the reverse deps would break but in non-obvious way, which is imho worst we can do from UI perspective
<Profpatsch>
jtojnar: but in these cases, if you change buildRustCrate, you need to handle that in a backwards-compatible manner
<Profpatsch>
e.g. by doing a nix-based check on list vs string
<Profpatsch>
So it propagates up the stack
<jtojnar>
yup, but then we could just do that in mkDerivation directly
<Profpatsch>
No, we want to have our own codebase as monotonic as possible
<Profpatsch>
Only the parts that are used from outside nixpkgs have to keep their interface
<Profpatsch>
Branching without good reasons makes everything more complicated than necessary and introduces overhead
<siraben>
Anyone willing to unbreak openmodelica? #110588
<siraben>
Project is still active as of 2020-12, but it's been broken on Nixpkgs for a few years now
<gchristensen>
probably up to somebody who wants to use it
<jtojnar>
Profpatsch: not sure what you mean, both buildRustCrate and mkDerivation are used outside of nixpkgs, aren't they?
aranea has quit [Quit: beep bop]
aranea has joined #nixos-dev
<Profpatsch>
jtojnar: yes, but that doesn’t mean we shouldn’t unify the internal usage of said switches
<Profpatsch>
*we should still unify
<Profpatsch>
to get rid of the double negation
<jtojnar>
right but does not buildRustCrate use mkDerivation internally so it would use the same switches?
<Profpatsch>
It would kinda forward the switch, but still with the aim of moving all of the nixpkgs crates to the new version
<Profpatsch>
So that the switch can be deprecated after some time and the complication removed
<Profpatsch>
But for example most packages in nixpkgs don’t forward any way to configure the switch, apart from ad-hocly overwriting build phases
<Profpatsch>
And even if somebody overwrites the a build phase, they would have to depend on the old behaviour for the switch to break that.
<Profpatsch>
So you don’t have to forward the switch for normal packages
<Profpatsch>
I mean https://www.hyrumslaw.com/ is still in full effect, but when you `overrideAttrs` you have to assume that upstream will break you after a while
janneke_ has joined #nixos-dev
janneke has quit [Ping timeout: 264 seconds]
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
jonringer has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
<elvishjerricco>
Awesome. Finally got my custom initrd to boot with luks root. I should probably finally commit this and push it somewhere
jonringer has quit [Remote host closed the connection]
<supersandro2000>
I think because owner requires you to set if it is a user or group because they use different paths
<supersandro2000>
they are not shared like on github
<supersandro2000>
groups have an ~ before their name
<sterni>
you mean don't?
<sterni>
the group arg is not used at all in the code somehow
<sterni>
the owner resolution needs reworking imo this if statement doesn't really sit right with me
<sterni>
but tbf most fetchers of that kind have incomprehensible argument handling because they always support like five different use cases at the same time
teto has joined #nixos-dev
<sterni>
with the user/group prefix potentially changing I think it is probably easiest to just have owner and the user having to provide it
<sterni>
so it is owner = "~user" and owner = "^group" or whatever
<{^_^}>
#110398 (by wirew0rm, 1 day ago, open): scenebuilder: init at 15.0.0 + scenic-view: init at 11.0.2
cole-h has joined #nixos-dev
<gchristensen>
it is a shame we don't really have a definition of what 'free' means in licenses.nix, since it'd make this a lot easier -- should sspl be considered free?
<ekleog>
^ this (though I guess I'm the one triggering this comment ^^')
<ekleog>
If I had to give my opinion, I'd say we should rename `free` into `hydraRedistributable`, and then SSPL would be hydraRedistributable, like unfreeRedistributableFirmware (which… currently is tagged free, which makes no sense) — we can't legitimately say that SSPL is free if both OSI and FSF reject it, but we can even less say that it's less free than unfree firmware
<gchristensen>
I *think* builds everything which is buildable when allowUnfree = false
<gchristensen>
hydra doesn't actually havemuch smarts about it afaik
<ekleog>
uhh so your comment makes me notice that allowUnfree = false allows unfree firmware…
<ekleog>
should be renamed allowUnfreeSoftware or something like that, but that's probably something too break-y to happen
<ekleog>
Hmmmm or maybe we could handle that by changing the semantics of allowUnfree actually? I'd default to nothing and instead allowUnfreePredicate would default to free + unfreeRedistributableFirmware; and hydra would set it to free + hydraRedistributable — and then we could make a decision whether or not to make sspl hydraRedistributable or not
<samueldr>
though we'd need to decide even who's Free definition we follow
<samueldr>
probably comb through all the licenses defined to match against that definition
<ekleog>
So the only breakage would be for people who explicitly set allowUnfree = false; and those probably expected the new behavior and not the current behavior of allowing unfree firmware
<gchristensen>
I think samueldr is pretty much right, here, that for allowUnfree to mean something it pretty much has to mean something specific
<samueldr>
SSPL *could* be free according to some criteriæ
<gchristensen>
it seems free enough to me :P
<samueldr>
I'm not a license nut, I don't even know who other than OSI and DSFG have definition
<samueldr>
definition with guidance per license*
<samueldr>
the FSF or one of the FSF offshoot maybe has too
<gchristensen>
and it seems to me that if I'm going tco start a business whose entire business is hosting SSPL-licensed software then I'd be smart enough to check the SSPL license
<ekleog>
Random thought: what about dumping the notion of free / unfree altogether; and instead having osiFree = true/false ; fsfFree = true/false ; and then an allowLicensePredicate that'd default to either osiFree or fsfFree + unfreeFirmware ?
<samueldr>
I was thinking about it actually
<samueldr>
but didn't share that thought because it'd mean more work :)
<samueldr>
but it'd actually make sense, if in addition there is a way to sync-up the lists
<ekleog>
Going through the OSI and FSF license lists adding osiFree / fsfFree = true to the licenses that are in there sounds like a reasonable enough amount of work to me
<JJJollyjim>
really hoping this doesnt turn into debian where we have to strip the docs out of all gnu software because DFSG :P
<ekleog>
(I'd be more scared about breaking the setup of all the people who were setting allowUnfree or allowUnfreePredicate)
<samueldr>
seems a bit lop-sided to only consider Free sources, we probably want to consult other distros as available sources of truth
<gchristensen>
JJJollyjim: interesting question, but the answer probably is dictated not by what we want but by what the rules of the licenses require
<ekleog>
@other distros as sources of truth… could that not come in a second time? if we can express our policy in terms of OSI or FSF assertions, IMO that's enough and then we can consider adding other sources of truth later on?
<samueldr>
that'd have to go with how it restricts the pool
<samueldr>
if any currently free license becomes unfree, we need to consider others until we lose the fewer amount
<samueldr>
(for our end-user's sakes)
<samueldr>
imagine if FSF and OSI both decided that WTFPL is unfree, (assuming we decided it's Free)
<samueldr>
that's breakage
<ekleog>
hmm… you mean… for setting the default allowLicensePredicate to something that wouldn't make too much currently-free stuff go default-disallowed?
<samueldr>
yes
<samueldr>
minimize the amount of packages to become unfree
<gchristensen>
let's become our own authority on what it means to be free
<ekleog>
Well, in a way if we want to set a policy for what free/unfree means that is not “what is encoded in nixpkgs” (as currently is), we probably can't do without some breakage one way or the other
<samueldr>
sure, but minimizing breakage imo is a goal here
<ekleog>
Not sure setting a policy that minimizes short-term breakage is the best long-term solution, but OTOH I won't have any strong arguments against that until someone actually goes through the trouble of designing a policy, so… ^^'
<Taneb>
(Minimizing breakage is necessarily a secondary goal, otherwise we wouldnt
<ekleog>
(all I can say is IMO minimizing breakage now to then change the policy later on is worse than having all the breakage now)
<Taneb>
... do anything)
<ekleog>
TBH I'd be willing to bet that following OSI would already basically make ~no change in what happens in practice (apart from the change from allowUnfree to allowLicensePredicate)
__monty__ has quit [Quit: leaving]
<sterni>
I think for the license question we should think about whose problem we want to solve with the switch
<sterni>
seems to me that the problem we want to solve currently is mostly “allowUnfree is an inaccurate description”
<sterni>
which is fine and should probably be solved, but the solution should also make sense from more than just this perspective probalby
<sterni>
I'm not sure how many people would want to turn on osi licenses but turn off fsf licenses, for example
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
<samueldr>
it's more about allowing multiple sources to be OR'd together
<samueldr>
or a user might prefer only allowing FSF, another only OSI, as a source of truth
jonringer has joined #nixos-dev
jonringer has quit [Remote host closed the connection]