rsynnest has quit [Quit: Connection closed for inactivity]
cransom has joined #nixos-dev
<mjsir911>
I would like to create a new derivation based off of an old one while adding a new environment variable (trying to solve #110826). I'm not having much luck with overrideDerivation/overrideAttrs as it seems to rebuild the entire package. am I stuck with symlinkJoin? It doesn't seem to forward along the outputs, and I would like to preserve them
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
jess has joined #nixos-dev
plumm has joined #nixos-dev
<eyJhb>
supersandro2000: Is there any reason to put in the longer link ? I am unsure how well it will work, once/if they make a 5.4.73-100 <- example
<eyJhb>
So I don't think we can do that :/
<supersandro2000>
eyJhb: you mean the synaptic link?
<supersandro2000>
I thought it would be more easily to search for when the page goes missing
<eyJhb>
Yes
<supersandro2000>
also the old link redirects to the new one and not the node one.
<supersandro2000>
whatever tbh
<eyJhb>
Yeah, that is intended :p I somewhat just trust the "node" link more, as it functions the same way as the old :p
<eyJhb>
Are you OK with keeping it as-is?
<supersandro2000>
if they replace the page with a new one that is a different node it breaks
<supersandro2000>
I honestly don't care
<eyJhb>
Lets see if they do, and take it at that point :p But I don't think the node link will break. Seems like it just functions as the fileId links
<eyJhb>
Resolved with a link to this conversation. Seems like I am the only one that can test it...
orivej has joined #nixos-dev
<eyJhb>
Not sure how much longer we should wait, if any. I would just say merge. nshalman was the only one to test last time, and they currently have no setup available
<supersandro2000>
If you recreate a page and give it the same path the node link will break
<supersandro2000>
because nodes are unique and paths can be reassigned at will
<supersandro2000>
not necessarily something which will be a problem but it could be in the future
<eyJhb>
^ But now you are guessing at how it works internally in their system and how their implementation of links are?
<eyJhb>
Or am I misunderstanding something
<supersandro2000>
I am thinking about dead links in the future
<supersandro2000>
I am pretty sure they use some CMS which would work like this
<supersandro2000>
and you wouldn't linkback the node id because your public page is not using it
<mjsir911>
sterni: late response, but I want to add an env variable to the execution environment. It would make sense that the package gets rebuilt if I wanted to modify the built env
AlwaysLivid has quit [Remote host closed the connection]
MichaelRaskin has quit [Remote host closed the connection]
<gchristensen>
anyone have opinions about this additional restriction of python packages? https://github.com/NixOS/nixpkgs/pull/120220 still draft, haven't formally requested reviewers yet
<{^_^}>
#120220 (by grahamc, 1 hour ago, open): mkPythonDerivation: validate propogatedBuildInputs and buildInputs use a matching python
<sterni>
gchristensen: have you tested the eval time impact of this (before / after)?
<sterni>
at a first glance this looks like it could decrease eval performance potentially
<gchristensen>
it is a fairly trivial equality check in the success case
tomberek has joined #nixos-dev
<gchristensen>
if there are zero packages in nixpkgs which trip this warning I'm going to be inclined to think it is a good rule
<gchristensen>
but probably more likely the way the check is constructed isn't sufficient
<qyliss>
Ericson2314: I'm not sure how I feel about removing the splicing -- it makes package definitions in that one package set different to everywhere else in Nixpkgs
<qyliss>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 455
<gchristensen>
marked it as ready for review, no packages complain
<Ericson2314>
qyliss: let me do the splicing thing that python does
<Ericson2314>
now that it exists
<Ericson2314>
so that if one *were* to use `callPackage` splicing would work
<Ericson2314>
on the other hand, I think it's pretty benefitial to not use splicing here (distinct from not having it)
<Ericson2314>
because splicing makes a minefield of infinite recussions, and the gcc bootstrap is especially touchy
<qyliss>
Ericson2314: maybe we could callPackage all the stuff that isn't needed for the bootstrap?
tomberek has quit [Quit: Connection closed]
tomberek has joined #nixos-dev
<qyliss>
I'm fine with making the stuff needed for bootstrap an exception, but I think in general splicing is nice to have for consistency with the rest of Nixpkgs
<Ericson2314>
qyliss: sorry was busy for a second
<Ericson2314>
so I added proper splicing support not, and a note kind of along the lines of what you were saying
<Ericson2314>
but I think one thing that's good to keep in mind is that the status quo is already a special-case
<Ericson2314>
in that no where else do do `with splicedPackageSet;`
<Ericson2314>
Indeed someone wanted to do that for `all-packages.nix` but it broke bootstrapping
<cole-h>
gchristensen: I'd just add `at ${location}` at the very end (after the suggestions)
<gchristensen>
updated
tomberek has quit [Quit: Connection closed]
<cole-h>
gchristensen: also, maybe there should be a length limit for the leftpadding? e.g. recall the very long drv name that was once possible to DOS Nix (IIRC?)
dmj`_ has joined #nixos-dev
winterqt_ has joined #nixos-dev
charukiewicz_ has joined #nixos-dev
<gchristensen>
mehh
Willi_Butz has joined #nixos-dev
drakonis1 has joined #nixos-dev
<eyJhb>
cole-h: I .. I want to see that :D
charukiewicz has quit [*.net *.split]
drakonis has quit [*.net *.split]
bridge[evilred] has quit [*.net *.split]
winterqt has quit [*.net *.split]
dmj` has quit [*.net *.split]
WilliButz has quit [*.net *.split]
dmj`_ is now known as dmj`
drakonis1 is now known as drakonis
<cole-h>
ah, I was wrong. It wasn't a long drv name and it didn't DOS Nix -- it was a long path (longer than MAX_PATH): https://github.com/NixOS/nix/pull/3541
<cole-h>
I was conflating that with the aaaaaaaaaaaaaaaaaaaaaa......drv I've seen in my nix-collect-garbage output in the past :P
<eyJhb>
Ohh nice :)
<eyJhb>
cole-h++ thanks for providing it!
<{^_^}>
cole-h's karma got increased to 145
bridge[evilred] has joined #nixos-dev
tomberek has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-dev
<qyliss>
cole-h: it did DOS Nix
<qyliss>
it broke garbage collection unless you manually cleaned up your store
<cole-h>
yeah, brainfart
<gchristensen>
petition to have this work: let foo.bar.baz = "bar"; things = [ foo.bar.baz ]; in (getThingNames things) == [ { name = "foo.bar.baz"; value = "bar"; } ]
<qyliss>
Ericson2314: I'm not sure how interested I am in the NixOS part tbh
<qyliss>
I hope somebody else does it!
<Ericson2314>
it seems like a huge amount of work
<Ericson2314>
and the second kernel pays most off the cost
<Ericson2314>
(the 3rd kernel has it easy)
<qyliss>
yeah
<samueldr>
NixOS/kSCOUNIX when?
<MichaelRaskin>
Well, if I get around to rewriting NixOS/RFCs#78 with proper use of modules, I guess once you have kernel and some userland you can stop caring as much about NixOS proper?
<qyliss>
it would be nice to have all the services
<MichaelRaskin>
Yeah, but most of the work goes into config, which is a damned text file so should not care at all
<MichaelRaskin>
If you do have the config, a trivial launcher with that config is maybe a bit annoying to write but not too bad
<qyliss>
would anybody here actually _run_ NixOS NetBSD, if such a thing existed?
<qyliss>
or is it more a case of just wanting it to exist?
<MichaelRaskin>
Hmm. I am actually not sure how quickly I would hit an annoying driver problem
<Synthetica>
If it had the same level of polish as Linux NixOS?
<qyliss>
I think that's unlikely, because it's never going to have as many users
<MichaelRaskin>
Of all monocultures, Linux kernel upstream lead by Linus Torvalds is the one I am most inclined to trust
<qyliss>
MichaelRaskin: from what I've seen the driver situation doesn't seem to be that bad
<MichaelRaskin>
Yeah, but Lenovo means … interesting GPU attachment choices
<Ericson2314>
re drivers i hope someday for something to do to boring character drivers what llvm did for compiler backends
<Ericson2314>
*char devices
<MichaelRaskin>
For _boring_ ones, maybe CUSE all the things
<Ericson2314>
also i hope OS researchers could use this sort of thing to quickly spin up a userland and better evaluate their work
<Ericson2314>
basically it's less about "everyone stop using linux now" or "bsd 4 ever nostalgia', and knocking down some motes and generally de-ossifying thingns
<samueldr>
I would hope a lot of darwinistic issues also apply to NetBSD
<samueldr>
and in turn running qemu-kvm with NetBSD would be trivial enough
<MichaelRaskin>
It might be that Genode slowly chipping away at Linux _driver_ compatibility layers could reach a state where the usual suspects are actually easy to cover by ported Linux drivers
jess has quit []
<samueldr>
so that testing/fixing some of it by non-darwin users becomes simpler
jess has joined #nixos-dev
<MichaelRaskin>
qemu-kvm should be easy with NetBSD
<samueldr>
yeah, that's not the issue
<MichaelRaskin>
Scratch that, just run RUMP maybe?
<samueldr>
oh, sure, also
<samueldr>
the issue is making the environment to do a native eval/build trivial to get to
<samueldr>
and legal!
<qyliss>
MichaelRaskin: I think Lenovo is probably fine tbh
<samueldr>
compared to darwinwhere you need to get the hardware for it
<qyliss>
what do you expect NetBSD developers run? :P
<MichaelRaskin>
Yeah…
<MichaelRaskin>
But I guess once I mange to kill that ThinkPad, I switch back to Asus
<MichaelRaskin>
It's just… _what_ were they thinking when wiring the video outputs?
<ehmry>
I think rump is one of those things that is non-trivial to build with nix
<MichaelRaskin>
ehmry: a pity…
<qyliss>
NetBSD developer friend tells me that as long as you don't want to use brand new hardware desktop NetBSD tends to be fine
<qyliss>
ehmry: does rump use a different build system to normal NetBSD?
<samueldr>
and again: the method used to run a native environment is not relevant here, what would be is being _able_ to do so with a derivation coming from Nixpkgs
<ehmry>
qyliss: I think its similar, but you need to patch some specific version of netbsd?
<MichaelRaskin>
samueldr: well, these are two different questions
<qyliss>
ehmry: because we can build almost all of normal NetBSD now
<MichaelRaskin>
But from portability-quality point of view spinning up a VM is enough, sure
<qyliss>
I guess I'd totally run NixOS NetBSD on a server
<qyliss>
doubt drivers are a problem there
<samueldr>
MichaelRaskin: even if a vm wouldn't work, and you were forced to use real hardware, my point still stands, much easier (and legal) access to a non-linux platform :)
<ehmry>
i heard netbsd has a nice package manager…
<qyliss>
samueldr: darwin issues definitely sometimes apply to FreeBSD
<qyliss>
ehmry: it does!
<MichaelRaskin>
samueldr: given that Qemu defaults to simulating some very old and very well figured-out hardware, I do not believe in things that are easier to boot bare metal than Qemu
<qyliss>
I was talking to my friend about getting our package managers to be mutually hosting
<qyliss>
so you could install pkgin with Nix, and Nix with pkgin
<samueldr>
MichaelRaskin: why are you focusing on the unimportant part of the message?
vdemeester has quit [Ping timeout: 260 seconds]
<MichaelRaskin>
Because I already explicitly agreed with the important part, and then you said something completely unexpected about the unimportant part?
<{^_^}>
#120220 (by grahamc, 5 hours ago, open): mkPythonDerivation: validate propagatedBuildInputs and buildInputs use a matching python
vdemeester has joined #nixos-dev
<ehmry>
BTW, i've given up on the genode+nix stuff, I've been doing a post-mortem writeup this week
<qyliss>
aww, sorry to hear that
<ehmry>
but making the nixos modules work on a BSD would be something I'd been interested in
<qyliss>
well, sounds like we definitely have enough interest to seriously explore it
<cransom>
i don't have a production use case for it, but my nostalgia is in overdrive if there was a configuration.nix that either replaced or augmented an /etc/rc.conf
plumm has joined #nixos-dev
<qyliss>
well that's a good start :)
ajs124 has quit [Quit: Bridge terminating on SIGTERM]
das_j has quit [Quit: Bridge terminating on SIGTERM]
Scriptkiddi has quit [Quit: Bridge terminating on SIGTERM]
<{^_^}>
nix#4440 (by Ma27, 14 weeks ago, open): Miscellaneous improvements for positioning in eval-errors
<ris>
i'm getting awfully tempted to turn one of the hackintosh scripts into a nixos module
<ris>
as i'm no longer going to have access to a mac i can check PRs on
<qyliss>
Ericson2314: eval failure on your latest PR
<samueldr>
ris: you might want to dig around the nixos org stuff, just saying that hydra builders are vms running on official mac hardware running NixOS
<ris>
ORLY
<ris>
:)
<qyliss>
Ericson2314: also, a more sensible roadmap right now would be a roadmap to self-hosting. The big things are getting Nix to work (I have that one pretty much under control), getting a pure+native bootstrap, and figuring out why dynamic linking doesn't work.
<ris>
samueldr: thankyou for that - i think i wasn't reading between the lines enough when someone said they were running on official apple hardware
<qyliss>
Ericson2314: the pure+native stdenv is probably well outside of my abilities, and well within yours ;)
<Ericson2314>
Ah element desktop is being bad
<Ericson2314>
Curse electron
<samueldr>
ris: though the hackintosh vm itelf is a "draw the rest of th owl"
<Ericson2314>
I think I better fight zfs and Firefox for more ram
<samueldr>
ris: but maybe there's inspiration enough for the nixos plumbing
<Ericson2314>
And then view this not on my phone
<ris>
sure
<ris>
thanks
<Ericson2314>
Yay computing in 2021
<qyliss>
Ericson2314: there's always the log viewer :P
<Ericson2314>
@qyliss I'm actually thinking I might prefer NixOS without nix
<Ericson2314>
Baked immutable NixOS or whatever
<Ericson2314>
And just do everything in small as possible qemu, glove box style
<Ericson2314>
But I have no idea how much work that is
<MichaelRaskin>
So, how you update the host kernel?\
<gchristensen>
it isn't so tricky, though I've never tried to bring the changes back in to nixos
<qyliss>
(mostly) immutable base system with everything running in VMs
<qyliss>
and VMs as a well-defined concept, so gluing them together is easy
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
<Ericson2314>
I was hoping there might be overlap!
<piegames[m]>
I managed to package some leaf dependencies from the Python ML ecosystem. If I added these to nixpkgs, would anybody be willing to maintain them?
<Ericson2314>
piegames[m]: like what?
<Ericson2314>
cuda related by any chance?
<piegames[m]>
I think `pydeck` and `detectron2` are the big ones, the others being hooked in transitively. A few of them are music-related (optical music recognition)
<Ericson2314>
piegames[m]: i personally don't do these things, but sometimes I have client work that does
<Ericson2314>
no inserection bettween requested packages and those, sadly
<piegames[m]>
They are only drive-by contributions on a side quest for me, so I wouldn't want to have to maintain these a few years down from now. But it'd be sad for the work to be lost or to rot in my NUR.
<samueldr>
open the PRs with "searching for maintainers"?
<samueldr>
though it won't be merged without maintainers, at least it's close enough to Nixpkgs that maybe it'll be found by someone who needs them?
<qyliss>
if there's a reason I've missed for keeping it as netbsdCross that's fine :)
<Ericson2314>
qyliss: i have no real preference between those. Ideally there would be a stdenvNoCC-only one so we wouldn't even be passing the thing that blow up
<Ericson2314>
netbsdCross is farther upstream so I guess i ever so slightly prefer it
<qyliss>
valid :) my preference was for the less characters one but your reason is better
<Ericson2314>
(I really don't like these stdenvs with battteries, I wish we just passed the deps we needed every time, at least until well clear of bootstrapping)
<Ericson2314>
libc can have a propagatedBuildInputs on crt0 and libgcc/compiler-rt, that's enough batteries included for me :D
<qyliss>
hehe
supersandro2000 is now known as Guest71724
supersandro2000 has joined #nixos-dev
Guest71724 has quit [Ping timeout: 240 seconds]
jonringer has joined #nixos-dev
jonringer has quit [Remote host closed the connection]