<arianvp>
What is the purpose of the ".real" files in /run/wrappers? they dont seem to be used by the wrapper creation script
<MichaelRaskin>
I think they are used by the wrapper itself, though
<arianvp>
aaah I see
<arianvp>
got it
<maralorn>
Hey there! The current haskell-updates job has 5200 pending darwin builds which are probably useless. If someone with the right permissions were to cancel them that would probably save us some build time.
lopsided98 has joined #nixos-dev
__monty__ has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
<maralorn>
gchristensen: Since I have seen you active in #nixos. I still think that it would be a good idea to cancel the darwin builds on this evaluation. https://hydra.nixos.org/eval/1668688#tabs-unfinished
<gchristensen>
sure
<gchristensen>
I can't cancel just darwin builds though
<gchristensen>
I can cancel everything or individual jobs
<gchristensen>
maralorn: what would you like?
<maralorn>
gchristensen: Can you cancel all jobs in that evaluation? There are only darwin jobs left.
<gchristensen>
yep
<gchristensen>
done, thanks
<gchristensen>
maralorn: are you taking point on maintaining the package set / will you be doing this often?
<maralorn>
<gchristensen "done, thanks"> Great.
<maralorn>
<gchristensen "maralorn: are you taking point o"> We decided on (I think and hope) great model. We will take turns for 2 weeks each.
<maralorn>
So we are in the middle of my two weeks, then it will by cdepillabout for two weeks and then sterni for 2 weeks, then me again.
<ajs124>
sure, I meant having a loop inside a package
supersandro2000 has joined #nixos-dev
<vcunat>
Yes, I assumed that.
<ajs124>
in this case, lib/galera links to lib, because the old build system put the files there
<ajs124>
or rather, the old installPhase. apparently scons doesn't do that itself? anyways, then I'll not do that again in the future.
<vcunat>
Oh, that's not what I'd classify as a loop. I thought you meant cases where the normal symlink resolution fails with ELOOP "Too many levels of symbolic links".
<qyliss>
I didn't think, because it was rebuild-0 on Linux
<qyliss>
but it isn't on Darwin
<qyliss>
does the staging freeze apply to bump that don't affect Linux?
<qyliss>
fwiw, none of the 4 NetBSD programs we use on Darwin have any changes listed in the 9.x release notes
<qyliss>
(column, getconf, getent, locale)
<vcunat>
The freeze is about changes being "breaking", not about mass rebuilds.
<qyliss>
hmm
<qyliss>
the RFC says "A change that is likely to break downstream.", I suppose this is not one of those
<qyliss>
the major version went up, but that's because it represents changes to the whole operating system, not the four commands we use on Darwin
<qyliss>
so I guess it's okay
contrapumpkin has joined #nixos-dev
<Ericson2314>
qyliss: yeah if it doesn't leak into important headers it's probably fine
copumpkin has quit [Ping timeout: 240 seconds]
<qyliss>
Ericson2314: I think it's only those four commands
<Ericson2314>
Yeah I doubt their behavior changed much or at all
<qyliss>
I assume they'd have had a release note if they did
orivej has quit [Ping timeout: 240 seconds]
<ajs124>
vcunat: sorry for not responding earlier, had to run. I'm not sure if this is a thing we should do or not, either. It's not needed for galera, we could actually just change the module(s)/test(s) and drop the symlink altogether, but I think having the symlink, one way or the other, is probably easier and also guarantees compatibility to downstream useres.
vikanezrimaya has joined #nixos-dev
<andi->
ryantm: I think you should stop closing so many discourse threads. I am seriously offended by that move. It is as if some discussions are not supposed to happen and they are being shut down.
<vcunat>
ajs124: no problem, sounds OK (from the little information I know).
<ryantm>
andi-: Are you offended by all my recent closings or just the flakes one?
<andi->
ryantm: mostly shutting down conversations in general. IMHO it should be a last resort if people do not start to discuss orderly.
<andi->
I can see why closing the blocking thread was good.
<ryantm>
I think what happened recently with Discourse threads getting way off topic has been pushing me toward trying to moderate more rather than wait for last resorts to be necessary.
<ryantm>
I'd like to hear more people's opinions about that flakes one though.
<qyliss>
I think it's a shame to shut it down when there was a perfectly okay discussion happening
<ryantm>
As far as I'm aware, 3 people liked me closing it and 3 people didn't.
<ryantm>
That seems split enough that I probably shouldn't have closed it.
<andi->
and 14 people liked my post. Where does that put us? I don't think going by likes is useful.
<qyliss>
domenkozar[m]'s point about threads for individual issues being more likely to be taken into account makes sense, but it seems pretty heavy handed to try to force that
<qyliss>
rather than letting people choose for themselves whether to continue the discussion they were already having, or to start new discussions about individual issues
<ryantm>
I reopened it.
<vcunat>
I think discourse allows to move off-topic sub-threads to other (new) topics.
<vcunat>
I've done that on another forum and I liked the approach.
<ryantm>
Yes, it recently started allowing making sub-threads into private messages.
<vcunat>
Oh, I didn't know about any public/private mixing.
aleph- has joined #nixos-dev
<ryantm>
I think you have to make the whole thread private, so maybe you have to first split it then make it private.
vcunat has quit [Quit: Leaving.]
<samueldr>
LTS 5.10 will be sticking around and maintained until December 2026
<MichaelRaskin>
drakonis: not sure if it has any relevance for Nix* given that auto-locking seems to be pretty far beyond the range of considered solutions
<Dandellion>
I dislike autio-closing because it makes it so that closed issues no longer means something is likely resolved one way or another
<hyperfekt>
"maintained" until 2026
<Dandellion>
it just means an issue was ignored long enough
<MichaelRaskin>
The different with WONTFIX is mostly theoretical, though
<Dandellion>
WONTFIXes usually come with some kind of reason why. And at least you rest assured that the maintainers are aware of the issue and has made an active choice
<MichaelRaskin>
Well, given that Nixpkgs is too large for Github search over issues to work and we keep using Github for issue tracking, I guess there is also an active choice implied
<MichaelRaskin>
(Of course, Nixpkgs stale bot does not close issues, either)
<Dandellion>
I do think that if you have to have a stalebot the nixpkgs way is the way to go definetly
<Dandellion>
and honestly with the size and speed some things are moving in nix its fairly reasonable to close very old inactive things. So I dont really mind
<Dandellion>
(it has even reminded me of old things I should finish up, so its quite nice)
<MichaelRaskin>
Given a) rate of revisit of old issues, b) the number of ways Github search is broken on Nixpkgs, it almost does not matter anymore
<andi->
Searching for closed issues is still broken? Didn't we file a bunch of issues years ago?
<MichaelRaskin>
I am under a strong impression that just keyword search does not always show everything
contrapumpkin is now known as copumpkin
__monty__ has quit [Quit: leaving]
fuzzypixelz has joined #nixos-dev
<hexa->
hyperfekt: hm?
<hexa->
hyperfekt: what does "maintained" mean?
<hyperfekt>
because older LTS releases don't get many security backports from what i've read
<hexa->
alot of stuff gets backported these days from what I hear
<hyperfekt>
and the issue should only be exacerbated with a full 6 years
<hexa->
is the process perfect? probably not
<hexa->
yeah, likely. but we're not going to stay on 5.10 for even a year.
<hexa->
and I'd be happy if more "products" used recent, or not so recent, lts versions
<hexa->
better at 4.4.268 instead of a random release that went EOL five years ago
<hexa->
granted, that means you still need an update process
<hyperfekt>
it's a very classical problem. between realism and fundamentalism
<hyperfekt>
you could say "people are using old kernels anyway, let's make them secure", or you can say "the place to fix this is to make people update their kernels instead of satisficing"
cole-h has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
supersandro2000 is now known as Guest74611
supersandro2000 has joined #nixos-dev
Guest74611 has quit [Ping timeout: 252 seconds]
<maralorn>
I would like to hear opinions on this: On hackage there about 500 packages with a custom license, which we can‘t automatially match on import. Hackage demands that the license is open source but doesn‘t say they enforce it.
<maralorn>
Currently hackage2nix uses a weird middle ground: It sets the license as unknown (which does not behave as unfree) but disables building of that job by hydra. Still we actually compile some of those packages when they are dependencies of a package with a known license.
<maralorn>
I feel like we should decide. Either we dare to build and distribute those packages then, so we can enable their hydra jobs or we don‘t then we should set them to unfree.
<qyliss>
when you say 500 packages, is that 500 unique licenses?
<maralorn>
qyliss: It's tough to say. It’s 500 opaque text files labeled on hackage as "LicenseRef-OtherLicense".
<maralorn>
I have looked into some of them. Some are the same, because they come from one maintainer/project. Some are just CC0 …
orivej has joined #nixos-dev
<samueldr>
is matching the content of thise "other" license texts hard?
<samueldr>
not necessarily the matching, but getting the data
<qyliss>
mark as unfree, have a list of overrides where we can add packages whose licenses have been checked?
<samueldr>
or maybe even add an "unfree" type of license as "unidentified please override"?
<maralorn>
samueldr: It might be possible via `curl https://hackage.haskell.org/<packagename>/src/LICENSE` but I am pretty sure that some packages call the file differently …
<qyliss>
that was going to be my other suggestion :)
<qyliss>
unfree with different messaging
<samueldr>
maralorn: so yes "kind of hard"
<samueldr>
qyliss's suggestion of forcing an override sounds good
<maralorn>
What do you mean with "forcing an override"?
<maralorn>
You mean you need to override the license if you want to use it without "allowUnfree"?
<samueldr>
that's what I understood of that suggestion
<samueldr>
through the thing that already is in use for overriding... things... on the haskell infra?
<samueldr>
(sorry, not too familiar with it!)
<qyliss>
maralorn: there should be an easy-to-add-to list in Nixpkgs of free, custom-licensed haskell packages
<qyliss>
so if we check a license, and discover that it's just CC0, we can add it to that list, and that'll mark it free