<genesis>
pkgs/build-support/appimage/default.nix provides some appimage-env with a lot of useless package
<genesis>
how override this to have only my requirement ? basicaly something like appimageTools.defaultFhsEnvArgs.multiPkgs = [ zlib ];
greizgh has quit [Quit: greizgh]
greizgh has joined #nixos-dev
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-dev
Taneb has quit [Quit: I seem to have stopped.]
Taneb has joined #nixos-dev
puck has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
juxiemaotu has joined #nixos-dev
cdepillabout has joined #nixos-dev
<worldofpeace>
Not sure how to care for this situation carefully https://github.com/NixOS/nixpkgs/pull/73251#issuecomment-563073432. But I know one thing, when I have to respond to oxij I feel like I have to prepare some sort of techinical debate argument. I don't currently have the mental bandwidth for that kind of mental creativity...
<worldofpeace>
It was removed because no one has stepped up to maintain it in any formal way (dev).
<worldofpeace>
So I don't feel fetching some patches from gentoo was the solution I was calling for.
orivej has quit [Ping timeout: 265 seconds]
justanotheruser has quit [Ping timeout: 268 seconds]
<worldofpeace>
My opinion is nixos isn't a package collection that shouldn't tre to hold onto or support slim. I think oxij would be more than welcome to distribute slim and continue using slim outside nixos.
<samueldr>
do you have the old(er) issue about removing slim handy?
<samueldr>
I may have overlooked it in the PR (and about to go to sleep state)
<worldofpeace>
samueldr: issue as in github issue, or like the original claim?
<samueldr>
github issue
<samueldr>
hm, can't find it
<worldofpeace>
I don't think there was one. It seems it was something that was suggested strongly when lightdm became the default. And recently became part of my personal roadmap for 20.03
justanotheruser has joined #nixos-dev
<yorick>
worldofpeace: some people see this as a package collection and others see it as a coherent distro and the two camps mostly don't collide
<{^_^}>
#12516 (by ericsagnes, 3 years ago, closed): Proposal: Change the default display manager
<worldofpeace>
yorick: I'm think NixOS/nixpkgs is for many things
<worldofpeace>
Though I'm not sure what's the differences between the two things you've mentioned. It's seems nixpkgs is used for both.
<yorick>
worldofpeace: we see the difference when upstream asks us to remove their package from our distro
<yorick>
or when people would like to keep their pet unsupported package in because it works for their usecase
<srhb>
I forget, is there a nice way to test this on a x86_64-linux? Seems cumbersome to make the cross infrastructure do the thing, but it's also annoying to try and fix blindly: https://hydra.nixos.org/build/107971259
<srhb>
iirc it's just bumping some fudge factors, but..
<samueldr>
aw, forgot to look at that
<samueldr>
it's not that the contents don't fit the image (fudge factor)
<samueldr>
but the image is too big for hydra
<samueldr>
(and cross-compilation isn't the answer here, especially since some packages need to be disabled for it to cross-compile currently, making the output size differ)
<samueldr>
Resizing from 628119 blocks to 526924 blocks. (~ 2058MiB)
<samueldr>
it's 58MiB too big
<samueldr>
hydra limits output sizes at 2GiB
<samueldr>
to get channels updated, moving the sd_image job from tested to uh... I don't know how, but "all other jobs", so the artifacts keep being built could be fine temporarily
<samueldr>
it's not going to be a straightforward fix, and any fix is temporary
<samueldr>
well, any quick fix
<samueldr>
I think the only solution for this is to "bundle" the building of the sd_image into one derivation, and not make the fs in one, and make the sd image in another
<worldofpeace>
yorick: Yeah, it seems in the past people used/misused nixpkgs for this purpose. I'd then say nixpkgs is the packages collection that ascribes NixOS, provides packages to be used with Nix on other platforms. It results in a weird socialization.
<samueldr>
the sd_image is compressed, so it's not an issue there
<samueldr>
but a part of the sd_image is a discrete derivation that must obey the same rules
<worldofpeace>
yorick: If the second case was really prevalent, I wouldn't take NixOS seriously :(
<samueldr>
though, a good non-trivial fix is to reduce the minimal install disk closure size ;)
<worldofpeace>
This makes me start to consider NixOS has some serious issues on how it's identified vs how its been used. I'd like to see it more defined, it's bit like an identity crisis in a linux distro. (I've heard this from other people too)
puck has joined #nixos-dev
orivej has joined #nixos-dev
cdepillabout has quit [Quit: Leaving]
puck has quit [Ping timeout: 240 seconds]
juxiemaotu has quit [Quit: WeeChat 1.9.1]
__Sander__ has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
__monty__ has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
domenkozar[m] has quit [Quit: killed]
Ox4A6F has quit [Quit: killed]
roberth has quit [Quit: killed]
abbradar[m] has quit [Quit: killed]
timokau[m] has quit [Quit: killed]
dtz has quit [Quit: killed]
worldofpeace has quit [Quit: killed]
jonge[m] has quit [Quit: killed]
jtojnar has quit [Quit: killed]
bennofs[m] has quit [Quit: killed]
yegortimoshenko has quit [Quit: killed]
ma27[m] has quit [Quit: killed]
layus[m] has quit [Quit: killed]
alienpirate5 has quit [Quit: killed]
nh2[m] has quit [Quit: killed]
thefloweringash has quit [Quit: killed]
rycee has quit [Quit: killed]
arcnmx has quit [Quit: killed]
vaibhavsagar has quit [Quit: killed]
aanderse has quit [Quit: killed]
Ericson2314 has quit [Quit: killed]
Nyanloutre[m] has quit [Quit: killed]
atopuzov[m] has quit [Write error: Connection reset by peer]
rnhmjoj has quit [Write error: Connection reset by peer]
psyanticy has joined #nixos-dev
<yorick>
what is the minimum supported debian version for nix?
bennofs[m] has joined #nixos-dev
dtz has joined #nixos-dev
yegortimoshenko has joined #nixos-dev
rnhmjoj has joined #nixos-dev
ma27[m] has joined #nixos-dev
domenkozar[m] has joined #nixos-dev
layus[m] has joined #nixos-dev
aanderse has joined #nixos-dev
Nyanloutre[m] has joined #nixos-dev
timokau[m] has joined #nixos-dev
vaibhavsagar has joined #nixos-dev
rycee has joined #nixos-dev
jtojnar has joined #nixos-dev
roberth has joined #nixos-dev
thefloweringash has joined #nixos-dev
worldofpeace has joined #nixos-dev
Ericson2314 has joined #nixos-dev
atopuzov[m] has joined #nixos-dev
nh2[m] has joined #nixos-dev
abbradar[m] has joined #nixos-dev
arcnmx has joined #nixos-dev
alienpirate5 has joined #nixos-dev
Ox4A6F has joined #nixos-dev
jonge[m] has joined #nixos-dev
puck has joined #nixos-dev
<Profpatsch>
worldofpeace: Wait, is there a reason to remove the slim package itself?
<Profpatsch>
I’m okay with the module, but why would you remove the package?
<jtojnar>
would not then people ask why is there not a module when we have a package?
<Profpatsch>
Why remove something that is not broken.
<Profpatsch>
We need to get away from “everything that’s older than 3 years should be deleted”. That’s unhealthy.
<Profpatsch>
Slim has been working for far longer than that and people are happily using it.
<Profpatsch>
If it were broken (aka it doesn’t build in nixpkgs) and nobody wants to fix it, then I’m all for removing it.
betawaffle has joined #nixos-dev
<betawaffle>
any idea why there doesn't seem to be a manpage for nft installed, even though the package seems to depend on documentation-building tools? cc Profpatsch
<gchristensen>
Profpatsch: I let betawaffle know you care and know about these details :)
<Profpatsch>
But I really, really like the fact that if I want to try something, and I have nixpkgs checked out, I can just nix-build it adn it works.
<betawaffle>
i only have documentation.nixos.enable = false; all the other doc things should be default
<Profpatsch>
Even if it’s some tool that hasn’t seen a patch in 10 years (I’d argue slow change is actually a good thing for unix one-thing-well tools)
<Profpatsch>
betawaffle: Sure, will take a look in a bit.
<betawaffle>
thanks!
<betawaffle>
all the versions of the manpage i can find on the web are not quite right
orivej has joined #nixos-dev
puck has quit [Quit: nya]
puck has joined #nixos-dev
eraserhd has quit [Quit: WeeChat 2.6]
eraserhd has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
<jtojnar>
Profpatsch: the integration is what is broken. It does not support modern desktop sessions like GNOME, Pantheon and Plasma
<jtojnar>
So if we want to ensure that all DMs work with all environments, the easiest solution is to drop the broken DMs
<Profpatsch>
jtojnar: I’m all for removing the module, but why remove the package
<Profpatsch>
jtojnar: Alternatively, make it incompatible with desktop managers by assertion
<Profpatsch>
Many people are not using a desktop manager, only a window manager.
<gchristensen>
I don't understand why people are so attached to slim
<simpson>
Profpatsch: I would mostly argue against the idea that broken <=> doesn't build. Your logic is good; we should have a deprecation plan and schedule for packages that seem abandoned and that we can't vouch for quality of as a result.
<simpson>
But all software rots, and so we'd better implement either a mold-management policy or a fridge-cleaning policy~
evanjs has quit [Remote host closed the connection]
evanjs has joined #nixos-dev
evanjs has quit [Remote host closed the connection]
evanjs has joined #nixos-dev
<worldofpeace>
Yeah, if you look at the thread and the things I mentioned in IRC, it's the integration with NixOS and systemd that's going to be an issue, and is an issue as time goes by.
<worldofpeace>
And it's not, some package hasn't seen a commit in 3 years let's delete it.
<thefloweringash>
betawaffle: does your nftables package have the change in #73324?
<thefloweringash>
hmm, I'm not sure that was backported
<betawaffle>
it's not really critical, just nice to have
<gchristensen>
probably worth backporting improvements like that
<adisbladis>
Profpatsch: We don't have a concept of what maintained/unmaintained means
<adisbladis>
Though in the case of slim there is an official website that even states that it's unmaintained
<Profpatsch>
adisbladis: which doesn’t mean we should not have it. just that it’s unmaintained ¯\_(tsu)_/¯
<adisbladis>
Make nixpkgs append-only :P
<gchristensen>
good news, it is already!
<gchristensen>
you can go back in the log and get it. we don't need to keep insecure and unmaintained software in HEAD
<adisbladis>
gchristensen: I was making a joke, though you're right.
<etu>
adisbladis: We should ban line removals in diffs.
<adisbladis>
Yes!
Cale has joined #nixos-dev
<adisbladis>
We can have some semantics around allowing commenting out old lines ?
<adisbladis>
Every line is sacred, every line is good
<gchristensen>
oh dear
<etu>
No, you just have to put everything in variables and redeclare them.
<qyliss>
We can't vouch for the quality of ~any software we package
ixxie has joined #nixos-dev
<Profpatsch>
^ hottest take
genesis has quit [Remote host closed the connection]
<qyliss>
that's on the user of the package
<michaelpj>
we have *some* tests
<gchristensen>
sure
<qyliss>
I've never used slim, so don't have a stake in its inclusion in particular, but I don't think we should be removing working software just because it doesn't work with NixOS or systemd
<qyliss>
we have a sysvinit package, even! last I checked
<adisbladis>
qyliss: It has a notice on it's webpage that it's unmaintained since 2013
<adisbladis>
I think that's reason enough.
<qyliss>
Why?
<gchristensen>
nixpkgs is a curated set
<gchristensen>
it isn't an archive of all software forever
<adisbladis>
Also what do you expect we do when software breaks and we don't have an upstream?
<qyliss>
Then we remove it
<gchristensen>
we know things are wrong with it, we know it is never going to get better
<qyliss>
What is wrong with it?
<adisbladis>
Reinstating the package is just a git revert away if you want it
<adisbladis>
If someone forks it or whatever
<gchristensen>
it has long-unpatched security vulnerabilities
<gchristensen>
because nobody has touched it since 2013, and at this point nobody is even looking at it for new problems because it isn't maintained softawer people should use
<qyliss>
If it has unpatched security issues I withdraw my objection in this case
<qyliss>
But I don't think "unmaintained" is reason enough
<etu>
gchristensen: Which makes it a bad package to "promote" by having it in the archive
<Profpatsch>
If there’s users like oxij who want to maintain it and apply patches, then I think it should belong in nixpkgs
<gchristensen>
it isn't like, a generic utility which is "finished" and doesn't need maintainence
<gchristensen>
NUR sounds like a good place for it
<adisbladis>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 179
<adisbladis>
Unmaintained user-patched sofware belongs in overlays
<gchristensen>
if it gets forked and becomes slim2020 as a new project with a new community and issue tracker etc, then yeah let's bring it back
<qyliss>
Do you think a window manager can never be finished in general? Or is there something specific about slim?
<worldofpeace>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 180
<worldofpeace>
note, I've mentioned NUR as well because there isn't a maintained fork and stuff
<worldofpeace>
it's just, NixOS shouldn't support it
<qyliss>
I'm all for NixOS not supporting it
<qyliss>
But Nixpkgs != NixOS
<Profpatsch>
^
<qyliss>
(And as noted, I'm also fine with dropping it for unpatched security vulns)
cjpbirkbeck has joined #nixos-dev
<srhb>
This seems like a discussion that could be alleviated with some policy decisions rather than opinions on what nixpkgs should or shouldn't support.. I got tired of it when someone decided that dmenu2 was ~*unmaintained*~ and killed it off with nebulous handwaving.
<gchristensen>
me too, srhb
<adisbladis>
Then where do we draw the line for nixpkgs inclusion?
<srhb>
(And it seems everyone agrees on security holes being an issue that's valid enough)
<gchristensen>
inclusion is a different question than removal I think
<worldofpeace>
Removal should be step in deprecation process
<qyliss>
> Today I realized that I really don’t want to include binary packages.
<{^_^}>
error: syntax error, unexpected $undefined, expecting ')', at (string):271:35
<qyliss>
Oh yes please
<qyliss>
worldofpeace++
<{^_^}>
worldofpeace's karma got increased to 46
<gchristensen>
I think about: the presence of security vulnerabilities + an unmaintained project + other distros have dropped it and aren't maintaining it + some measure of its criticalness to the rest of the package set
<worldofpeace>
This is always a pain topic for me, because I feel in a weird situaiton whenever I accept/rejectin/remove a package
<adisbladis>
gchristensen: It's really hard to decide
<gchristensen>
I agree
<worldofpeace>
I think this might make us the first (possible second) project to actually remove it
<srhb>
gchristensen: I thought you considered most other distros craycray :-)
<gchristensen>
srhb: they are but only because their package manager isn't very good :P
<srhb>
;-)
<gchristensen>
but if they're maintaining patches for something, I'm happy to fetchpatch
<{^_^}>
canonical/lightdm#102 (by simon-bueler, 6 days ago, closed): Wayland only setup for lightdm
pie_ has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
<__monty__>
qyliss: Afaiu yes, though for some reason people seem to purposefully ignore that fact. This was brought up in the discussion last time as well.