AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
Synthetica has quit [Quit: Connection closed for inactivity]
<ekleog>
What would people think about adding test-pypi to the fetchurl/mirrors list? (I've been doing it locally for a while in order to nixos test stuff I'm releasing before actually releasing it anyway; don't see a usage for it in nixpkgs itself but it could be useful for other people who do the saem)
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
ris has quit [Ping timeout: 240 seconds]
<supersandro2000>
ekleog: test.pypi.org?
<ekleog>
yup
<ekleog>
(the diff I currently have in my local checkout being testpypi = [ "https://test.pypi.io/packages/source/" ]; in build-support/fetchurl/mirrors.nix)
<supersandro2000>
if the nix file accept config, then config.checkMeta is added, if not then not
<supersandro2000>
builtins.functionArgs (import ./.) gets you { } of all inputs
<supersandro2000>
hasAttr converts that into a bool
Magic_RB has joined #nixos-dev
<Magic_RB>
hi guys! I'm cross posting from #nixos, I'm hoping to tap into the old school Nix magicians' knowledge pool (you people that wrote Hydra), so I've got a Hydra question, is it possible to configure Hydra to somehow upload build products (OCI images) to an image registry, even if indirectly such as with a notification webhook so that some other piece
<Magic_RB>
of software could do the uploading part. Thanks for reading this and your answers
<sterni>
what happens if a derivation itself has recurseForDerivation = false set? does hydra ignore that derivation?
<sterni>
doesn't seem to make a difference for nix-env
orivej has quit [Ping timeout: 260 seconds]
bpye has quit [Ping timeout: 260 seconds]
bpye has joined #nixos-dev
s1341_ has quit [Quit: Connection closed for inactivity]
<aanderse>
supersandro2000: entirely valid as far as module requirements go... and wow, yeah, the most minimal module i've ever seen
<aanderse>
i'm not familiar with what the kde partition manager needs, so i can't speak to that though... but looks "right" to me
<supersandro2000>
thanks
<supersandro2000>
aanderse++
<{^_^}>
aanderse's karma got increased to 26
bpye has quit [Ping timeout: 265 seconds]
bpye has joined #nixos-dev
s1341_ has joined #nixos-dev
aminechikhaoui has quit [Quit: Ping timeout (120 seconds)]
aminechikhaoui has joined #nixos-dev
__monty_1 has joined #nixos-dev
__monty__ has quit [*.net *.split]
__monty_1 is now known as __monty__
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
<tazjin>
a note on https://github.com/NixOS/nixpkgs/pull/115197 - this PR introduced breaking API changes and was merged with unreviewed changes. sterni points out the details in a comment there. This isn't the first time something like this has happened recently, and I think this adoption of a culture which sacrifices quality for speed is harmful
<{^_^}>
#115197 (by SuperSandro2000, 1 week ago, merged): collection: format, fix cross-compile, cleanups, etc.
<tazjin>
cc supersandro2000
<andi->
There are empty commits in there o.O
<tazjin>
I understand the intention of a change like this, but nixpkgs is a huge project that many people depend on and breaking its API should require some amount of migration planning
<tazjin>
plus I think merging unreviewed changes is outright dangerous and our tooling should not allow it - this being possible means anyone with a commit bit can introduce malicious code unanimously
<tazjin>
which, especially in a large PR like that, is not guaranteed to be caught at all
<gchristensen>
I'd like to mandate PR checks passing and review, and I don't want to alienate important and valued contributors like qyliss
<tazjin>
then 1) mandate checks passing, 2) introduce a check that checks for either an in-UI review or a comment of a specified format (e.g. a contributor posting a comment that has "LGTM" as its first line)
<tazjin>
(I'm assuming your comment about qyliss is about relying on the Github UI)
<sterni>
gchristensen: would it be possible to add a removed attributes check to ofborg? it already does an outpath comparison anyways
<sterni>
nemoving attributes should at least be a warning in CI
<gchristensen>
sure, and actually the "has: clean-up" label is applied on removals
<gchristensen>
we could change the name of that label
<gchristensen>
a check tab entry could be created for changes in attribute names
<sterni>
has: clean-up is a bit of an euphemism :p
<gchristensen>
in retrospect it is ascribing value to a change which a bot cannot do :)
<supersandro2000>
that most likely happened during a rebase
<supersandro2000>
tazjin: there are still pushs straight to master which never passed ofborg or any review
<tazjin>
that should be banned
<supersandro2000>
don't tell me that
<supersandro2000>
also package inputs are not an API
<gchristensen>
yes, I'd really like to ban direct pushes
<tazjin>
does it have the ability to break external code? Then it's an API
<sterni>
supersandro2000: it is an API indeed
<tazjin>
fwiw, the existence of one bad practice doesn't give legitimacy to another
<supersandro2000>
every update that changes anything in the inputs is such a breaking change
<sterni>
even worse it's an user interface
<supersandro2000>
also unstable 🙃
<gchristensen>
I think overrides will fail if an input is defined and the expression doesn't accept it, isn't that right?
<supersandro2000>
also guess who did the python aliases PR like 9 days later
<supersandro2000>
gchristensen: yes
<sterni>
why not do it the other way around is my question
<supersandro2000>
if the next update no longer requires a package then it is broken, too
<siraben>
supersandro2000: yeah what happened with python alises
<siraben>
aliases*
<sterni>
also you did not add the necessary aliases in the second PR
<supersandro2000>
sterni: asking afterwards to use a new feature for an old problem is not a solution
<tazjin>
yes, we had breakage from this yesterday
<supersandro2000>
if a python package is removed right now it is just puff
<supersandro2000>
no aliases, no throw, nothing
<gchristensen>
I'm not sure this is too significant tbh, better than a silent failure
<supersandro2000>
also I am not going to collect all removed python package names in the last X and going to throw them into aliases
<sterni>
fwiw unstable means yes we can break things but also doesn't mean we have to
<supersandro2000>
we can start that now that we have the feature
<tazjin>
I guess this is a philosophical thing, some of us would like Nixpkgs to be a reliable thing on which maintainable stuff is built - in which case there is an expectation of considering which breakage you introduce
<tazjin>
others would like to be more like Arch Linux, move fast and break your downstream
<supersandro2000>
not like I broke your downstream. It was an easy to fix eval error
<tazjin>
you only broke it a bit, doesn't mean you didn't break it
<supersandro2000>
If you would upstream the package then I would have noticed it and fixed it
<tazjin>
not all uses of nix are for software that belongs in nixpkgs
<gchristensen>
a philosophical thing mixed with low bureaucracy and few policies. bureaucracy is a technology that is very useful in problems like this
<supersandro2000>
I live in Germany. I know what bureaucracy is.
<ajs124>
gchristensen: good bureaucracy is sadly very underrated
<gchristensen>
many people consider bureaucracy to be profane and all downside :)
<supersandro2000>
but I already built the feature that fixes this in the future
<tazjin>
I'd wager those people are in the move fast and break things camp
<supersandro2000>
it took my probably half a day. I don't know what you want from me now.
<tazjin>
i want you to consider these things before you break stuff
<tazjin>
not some arbitrary period of time later
<tazjin>
And I want you to get reviews of your changes from people, because there's occasionally cases where you might introduce a kind of breakage you're not aware of
<supersandro2000>
in the scope of nixpkgs this broke nothing and I considered that
<tazjin>
that attitude treats nixpkgs like an art project that exists only for itself, rather than a foundation upon which other things are built
<supersandro2000>
ofc it does not exists alone for itself but considering every possible breakage is hard and it is very human to miss something
<tazjin>
hence review requirements
<adisbladis>
supersandro2000: Did you ever stop to consider that the criticism towards you is warranted and that maybe you should address it and not double down on every single thing?
<niksnut>
thing is, nixpkgs doesn't *have* a well-defined public interface
<niksnut>
e.g. there is no guarantee that we won't remove packages on master
<ekleog>
that doesn't mean that we should break things at will either
<adisbladis>
There is a line and it's pretty clear that supersandro2000 keeps crossing it time and time again
<niksnut>
and it's unreasonable to expect nixpkgs contributors not to break an unspecified interface
<tazjin>
especially if there is a trivial fix (renaming something? make an alias that logs a deprecation warning)
<ajs124>
adisbladis++
<{^_^}>
adisbladis's karma got increased to 146
<tazjin>
adisbladis++
<{^_^}>
adisbladis's karma got increased to 147
<niksnut>
for instance, I once had an emacs fix reverted because it broke external users of emacs.overrideDerivation
<supersandro2000>
also I don't know if aliases would work for inputs
<niksnut>
so *any* change to nixpkgs is a potential breaking change
<symphorien[m]>
adisbladis++
<{^_^}>
adisbladis's karma got increased to 148
<supersandro2000>
every time there is some criticism about me I always see one of the exact two names
<supersandro2000>
if the breakage is very big of course we can and sometimes really should revert it but so far I either missed it or no one suggested that
<adisbladis>
supersandro2000: If this was a one off thing it wouldn't be so bad. This is a pattern of recklessness.
<gchristensen>
there are more people with concerns, and I think only a few people who are comfortable saying so, supersandro2000. I think the root of the issue here is around communication: seeking more reviews, working with reviewers, handling feedback -- something we've talked about privately, etc.
<gchristensen>
and ideally getting to a place where the other people with concerns feel more comfortable saying so! that'd be a good day
<das_j>
adisbladis++
<{^_^}>
adisbladis's karma got increased to 149
<domenkozar[m]>
eh, I don't think it's productive to attack someone due to lack of discipline
<domenkozar[m]>
we've been there in the past and it never works well
<domenkozar[m]>
(as niksnut noted it's hard to spot a breaking change)
<gchristensen>
+1
<domenkozar[m]>
I do agree we have a problem though
<domenkozar[m]>
I broke pipewire just weeks ago
<domenkozar[m]>
anyway, leaving all the blame on the side, is there a way to make an interface diff?
<domenkozar[m]>
that would be interesting
<gchristensen>
I think there is probably catch-up work to do: prohibiting direct pushes + requiring ofborg's +1
<domenkozar[m]>
yeah, although that wouldn't caught this one
<gchristensen>
right
<gchristensen>
I think if this were my PR I'd have tried to solicit some more reviews by asking on IRC and saying I'm planning on merging it in X days/hours
<supersandro2000>
for this usually has a 50% success chance
<supersandro2000>
and then the author asks a week later whats up with the PR
<gchristensen>
yeah, I don't always actually get more reviews :) but it does call it out a bit specially and gives a deadline hehe
<aminechikhaoui>
niksnut there is indeed no specified interface, but imo we should try to limit breakage for out-of-tree packages/expressions whenever possible (talking in general regardless of the current discussion)
<aminechikhaoui>
it really makes updating nixpkgs versions painful
<supersandro2000>
I vaguely remember that we wanted to prohibit direct pushes to master a couple of weeks back but people where concerned about something that I forgot
<piegames[m]>
Giving people a fair chance to review things before it gets merged does not necessarily increase the review rate, but it does make them fell less angry about that merge when things go wrong.
<domenkozar[m]>
supersandro2000: one thing you'll notice that in groups, there's a herd mindset so once you do something wrong, you'll get a huge stress response since the group will turn you into an enemy. Takes time to understand what's going on, I'd recommend reading https://web.archive.org/web/20140829215839/http://www.shirky.com/writings/group_enemy.html
<piegames[m]>
So even when making a pull request, self-merging it after 24h (or less) is a really short time span for a project maintained in most people's free time.
<aminechikhaoui>
niksnut a random example that I can remember now is the stdenv "set -u" change in 20.03, I had to change many expressions/scripts that worked for years. It's probably a bad example because it reduced complexity internally for stdenv so there was a valid reason for doing the change, but it was a bit annoying for perfectly working out-of-tree
<aminechikhaoui>
expressions/scripts.
<domenkozar[m]>
supersandro2000: all that being said, leaving a few days for a review is good practice, it's an important factor for keeping the quality high, it doesn't guarantee it though.
<domenkozar[m]>
it's also mostly our fault since these things are not documented well, but that's another thread/topic.
<ekleog>
FWIW, my personal way of doing things is that anything big gets a 7 (or 30-day for very big stuff) grace period for people to air concerns, poked about here, and if no one raises concerns then I consider people had their chance and I land
<abathur>
not to derail this, but gchristensen wished aloud for a (coherent?) popcon proposal recently, and I've been thinking a very ~nix way to handle something _like_ what popcon is trying to get at might be a mechanism for submitting links to published dependent expressions, with the carrot being: whether at the PR stage or later in master, rebuild the expression to test for breakage
<domenkozar[m]>
niksnut: one thing to consider for nickel is to separate public vs private interface
<domenkozar[m]>
abathur: popcon?
<abathur>
sorry, gc was responding to the common request for cache statistics as a way to guess at whether a package someone wants to move/rename/delete/etc. is in use
<abathur>
a reference to "popcon" or "popularity contest" projects in other PMs I guess
AlwaysLivid has quit [Ping timeout: 268 seconds]
<ekleog>
abathur: something like crater for rust? sounds like a good idea
<domenkozar[m]>
I think we should start at documentation of what is all required for getting changes into master.
<domenkozar[m]>
then the next step is automating that
<domenkozar[m]>
s/at/with/
<abathur>
I don't know how you'd handle the problem of effectively ending up maintaining compatibility with ~Thomassons people submitted but no longer use, though
<abathur>
ekleog: not previously familiar, but I suppose
<domenkozar[m]>
abathur: sorry I don't understand the context of "~Thomassons"
<ekleog>
abathur: crater is basically “run a change to rustc on all the crates published on crates.io, and see what breaks”
<ekleog>
it's usually reserved for known-breakage changes, to be able to fix unexpected behavior that is hard to categorize between “bug” and “behavior someone could be relying on”
<domenkozar[m]>
anyhow, we have yet to define a policy to deprecate packages, but that's another topic (I rarely see anyone making a PR to remove a package)
<piegames[m]>
domenkozar[m] (IRC): Because if nobody cares for a package, then there is nobody to care for its deprecation
cole-h has joined #nixos-dev
<supersandro2000>
domenkozar[m]: everytime we make a package python3 only it removes the python2 package and that happens not to rare
<domenkozar[m]>
yeah, I guess I'm saying that these are two separate topics: avoiding breakages in nixpkgs and deprecating of packages
<supersandro2000>
some of them where already broken or non functioning but nixops broke like this several times in the last months
<supersandro2000>
also side note: haskall-updates does not currently eval on ofborg. Would be nice if someone could look into that.
<cole-h>
Peti will when he streams later today
<gchristensen>
yes, I suspect peti would be quite annoyed by blocking pushes
<sterni>
I feel like it all comes down to the issue of nix-env in the end
marek has quit [Changing host]
marek has joined #nixos-dev
capisce has quit [Ping timeout: 272 seconds]
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
<gchristensen>
hmmm the initrd secrets feature is a bit interesting, having it mutate old profile's boot entries is spooxy
<supersandro2000>
Would it be a good idea to create a board for haskell-updates PR? or can they simple be filtered by target branch?
<cole-h>
peti filters them by target branch
<Taneb>
gchristensen: initrd secrets?
<gchristensen>
boot.initrd.secrets
<gchristensen>
it adds some more files to the initrd impurely
<cole-h>
I suppose it's so that if you have e.g. a file keylocation on a zfs encrypted dataset and it changes, you can still use it?
<sterni>
supersandro2000: I don't think it's necessary since we have the haskell label already
<sterni>
supersandro2000: oh you mean the one peti makes? they are pretty discoverable
<sterni>
i. e. filtering by author:peti :p
<gchristensen>
yeah cole-h but imho it shouldn't, it should leave the old ones alone. consider a case where you're iterating on some secrets and you get it wrong but now all your old boot entries are broken, when only your latest should be
<cole-h>
also fair
<gchristensen>
my feeling is that a given boot entry should be fixed, permanent, unchanging until it is deleted
<gchristensen>
anything else is unprincipled and surprising
<cole-h>
agreed
srk has quit [Remote host closed the connection]
srk has joined #nixos-dev
<gchristensen>
the perl in nixpkgs would be nicer if the little additions to it over time used functions instead of the soup that is there
<cole-h>
how do you mean?
<supersandro2000>
it is a giant nix file that is most of the time is not even using variables in version downloads
<supersandro2000>
not as bad as nodePackages but in that general direction
ris has joined #nixos-dev
<gchristensen>
here is an example, a file which gets little features and fixups added to it over time: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/loader/grub/install-grub.pl look carefully and you can see some pretty well defined functions that look pretty good but other places you see huge functions with tons of behavior, where there could be several easy to read functions, but
<gchristensen>
the path of least resistance is to be additive to existing structure, instead of adding more structure to match the new behavior
<supersandro2000>
lol. That function has probably a code complexity of 100
<supersandro2000>
not what I thought but yeah. looks like switch in python
<cole-h>
maybe we should rewrite it in python, like the systemd-boot-builder script
<gchristensen>
the pattern happens there too
<supersandro2000>
Wasn't the idea to improve it? 😃
<gchristensen>
it is just a common pattern for little fixups and features
<cole-h>
let's rewrite all of nixpkgs
<supersandro2000>
python sounds like not something you want in your boot chain
<supersandro2000>
except that this isn't in your bootchain. derp.
<gchristensen>
yeah :)
<supersandro2000>
it has grub in the name..
rajivr has quit [Quit: Connection closed for inactivity]
<gchristensen>
maybe it is something like no specific person considers themselves maintainer of these types of scripts, so no specific person is personally invested in them being a real pleasure to work on and improve, so the code review is "yeah that works" vs. "yeah that works, but let's factor it out a bit and clean this up"
justan0theruser has quit [Ping timeout: 264 seconds]
<supersandro2000>
or the fear to break something and the mob getting on you
<gchristensen>
yeah, quite probably some of that too -- spookiness of Perl and wanting to change as little as possible
<samueldr>
a few years back I was looking at the boot loader situation, and we direly need (still) a common framework to take in NixOS data (e.g. generations) and produce a bootloader-specific configuration
<cole-h>
that would be very nice
<cole-h>
do we have an issue for that?
<samueldr>
I don't know
<samueldr>
since every bootloader has a different supported feature set, part of it is because the bootloaders themselves don't support everything
<samueldr>
it gets a bit harder
<samueldr>
one of the paralyzing agents at the time was choosing how to implement it... it all boiled down to shell, perl, or C... none of which I judged really good to do it... well, perl would be, but it would have required me to learn even more perl
<gchristensen>
what is the status of rust as an option?
<samueldr>
though I guess these days with Rust-made tools being acceptable in the base closure, that would be good
<samueldr>
now now, stop ninjaing me
<gchristensen>
and may I vote to ixnay bash and C from that list? :P
<samueldr>
I think in ~2018 Rust wasn't in that position in Nixpkgs, but I don't actually remember
<samueldr>
gchristensen: exactly
<gchristensen>
I believe it
<samueldr>
they were the *plausible* languages that wouldn't cause a direct "NO" from the community
<samueldr>
because in 2018 I sure would have written good Ruby for it
<samueldr>
but eh
<samueldr>
good luck getting Ruby in the base system closure
<samueldr>
what do we look like? macOS?
<gchristensen>
:)
<samueldr>
(these days mruby could do, mruby is self-contained... but it still requires the community to find the language palatable)
<supersandro2000>
is the dependency on ruby over ascidoc for some doc?
<supersandro2000>
if so we could get rid of them for base
<supersandro2000>
I would actually benefit for the uutils-stdenv from that
<samueldr>
yeah, now imagine adding support for yet another EFI bootloader :)
<samueldr>
which of the partially incompatible setup scripts do you use as a basis?
<gchristensen>
both (⌐■_■)
<samueldr>
and "extlinux compatible" in all that? ;)
<gchristensen>
"yes" haha
<samueldr>
and the iso?
<samueldr>
the iso _should_ be using the same boot config generation than the system, but it doesn't! (and IIRC can't due to the design of either not really working out)
justanotheruser has joined #nixos-dev
<samueldr>
is it known that `tests/ca/substitute.sh` in Nix might be flappy?
<samueldr>
the same exact build was then nix-built a second time and it passed
<samueldr>
as you can see -j12, maybe an ordering thing with parallel tests running?
<samueldr>
(I really haven't looked at the details)
<regnat[m]>
Thanks 👍🏻
<samueldr>
to be entirely truthful: I haven't reproduced this on the master branch... but I assume the changes to the config test shouldn't affect this
<samueldr>
but maybe my assumption is flawed!
<regnat[m]>
I guess there must be some merge-induced fishery because I never saw that when developing it, but I just tried it on master and got the same error on the first try
<samueldr>
great!(?)
yegortimoshenko has quit [Quit: Connection closed for inactivity]
flokli is now known as FLOKLI
tazjin is now known as TAZJIN
sterni is now known as STERNI
adisbladis is now known as ADISBLADIS
lovesegfault is now known as LOVESEGFAULT
pie_ is now known as PIE_
ashkitten is now known as ASHKITTEN
cole-h has quit [Ping timeout: 246 seconds]
capisce has joined #nixos-dev
<edef>
< tazjin> others would like to be more like Arch Linux, move fast and break your downstream ← i think you overestimate how stable NixOS is, and underestimate how stable Arch is in practice
<yorick>
nixos is pretty stable in that you can just limit your upgrades
<ekleog>
uh my experience with arch and with nixos is that I spent about the same amount of time on arch and on nixos, and I had two major upgrades that broke my system and needed livecd usage with arch and zero with nixos
<yorick>
and have upgrades still succeed later
<ekleog>
(the systemd switch and the fhs change were the two issues I hit, iirc)
<yorick>
the stables are hard to use in production because bugfixes often don't get backported
<ekleog>
and that was on a laptop arch, that was kept up-to-date, so not even taking into account the “you can't upgrade an arch that's a few years without updates” issue
<TAZJIN>
edef: nixos is, at least in my experience, less stable than it used to be in recent years - where by "stable" I mean I have to do more work to maintain a steady state after upgrades
<TAZJIN>
edef: but the point is that if the culture shifts towards wanting the arch-like experience, then so will will nixpkgs
<edef>
no, i'm saying we're already easily doing worse than Arch
<ekleog>
unless arch has drastically changed in the past 5 years, this is definitely not true
<yorick>
agree, but I think this is because arch gets a lot more testing by users
<edef>
we have a vastly larger API surface, to be fair
<yorick>
(I have lost days on bugs fixed in arch but not nixpkgs)
<edef>
ekleog: it is hard to tell what is people actually experiencing instability, and what is people not reading the newspage before firing up pacman -Syu
<V>
arch has literally never broken for me over multiple years of use, except when I a) failed to look at thew news, and b) when I didn't upgrade for over a year (in which case there were instructions for getting past this)
<V>
NixOS breaks constantly
<ADISBLADIS>
Breaks how exactly?
<ekleog>
edef: I think we're having different definitions of breakage
<edef>
ekleog: elaborate?
<V>
ADISBLADIS: uh, how about the PR that wiped everyone's firefox extensions
<yorick>
nixos 20.09 got released with a default kernel incompatible with the default nvidia driver, I'm not sure if this is fixed yet
<ekleog>
for me, breakage is “my system can't be booted / doesn't work correctly”, and it reads to me like if to you “some option was renamed and so one hits an eval-time error with the hint for how to fix it” counts as breakage to you
<V>
or... managing to install tor browser in such a way that noscript/etc weren't functional
<ADISBLADIS>
V: Good point. I forgot about that one.
<edef>
my current experience is that nixpkgs upgrades should be fairly rare, because every time it breaks my workflows for a week, and often i find myself reverting those merges
<ADISBLADIS>
I'm not saying it doesn't break far too much btw, I'm genuinely interested
<yorick>
that one time dhcpcd didn't work for a month
<V>
oh yeah
<ekleog>
my point being: nixos is very strongly misuse-resistant, while arch is not at all
<V>
I spent god knows how long debugging that
<yorick>
same
<edef>
ekleog: the eval-time errors are plentiful but at least i have prior notice
<TAZJIN>
that one time the ACME module hasn't worked in ... who knows how long
<ADISBLADIS>
My setup is fairly minimal in part because I grew tired of stuff breaking all the time so I minimise the API surface I have to interact with
<V>
I would argue that "installing firefox" doesn't count as a large amount of API surface
<ekleog>
edef: have you hit non-eval-time errors? I've never hit those with nixpkgs, and have a number of times hit it with arch (arch timeframe being 10-5years from now, and nixos 5-0 years from now, roughly)
<TAZJIN>
Ericson2314: I'm already scared by the title
<Ericson2314>
my thing for "build time is now just as expressive as eval time"
<TAZJIN>
is this an alternative to recursive nix
<Ericson2314>
haha you weren't the first!
<Ericson2314>
yeah
<edef>
ekleog: same timeframes here
<ekleog>
correction: I hit non-eval-time errors for packages that were not packaged at all / packaged but not maintained, but IMO that doesn't count as breakage
<ekleog>
(as it didn't work before either)
<yorick>
Ericson2314: I'd like a bit more description on what that does
<V>
oh, I should add: c) don't do partial upgrades on Arch
<V>
but all of these are things that people are clearly told about
<ekleog>
V: except when the release notes tell you to*
<TAZJIN>
Ericson2314: I don't know what I'm looking at from the PR
<yorick>
that one time where fontconfig broke and all my emojis were 300px
<Ericson2314>
yorick: I will answer with a riddle :D `/nix/store-asdfasdf.drv.drv.drv.drv.drv`
<Ericson2314>
TAZJIN: the new tests would be the thing to look at
<V>
ekleog: that comes under a)/b)
<Ericson2314>
I'll add a link
<edef>
ekleog: not infrequently are things significantly busted in systems that *build* fine
<V>
yorick: isn't fontconfig still broken somehow with colour emojis
<edef>
yorick: oh god
<yorick>
V: works4me
<edef>
yorick: that was Wild
<V>
okay, *some* colour emojis
<Ericson2314>
yorick: today, such a thing wouldn't be useful, because you build that, and get someting with one less `.drv`, and then what? manually "pump" nix-build until all the `.drv` are gone?
<ekleog>
edef: interesting, that hasn't been my experience despite the fact I installed much more services with nixos than I had with arch
<yorick>
Ericson2314: sounds doable with recursive nix?
<Ericson2314>
yes but recursive nix is v ba
<ekleog>
(apart from the “expected to be busted” stuff like rustup or stuff like that, obviously)
<Ericson2314>
kills dry run
<edef>
yorick: i have a specific memory of very large cactus emoji
<Ericson2314>
incorrages imperative badness
<Ericson2314>
which kills build parallelism
<yorick>
Ericson2314: ah, you're solving *that*?
<Ericson2314>
yup!
<Ericson2314>
solved
<yorick>
ooh
<Ericson2314>
the things that make it WIP are not interesting :)
<Ericson2314>
(perl bindings, mainly)
<yorick>
hey, I like the perl bindings
<Ericson2314>
:)
<Ericson2314>
I will fix them at some point but it's a bikeshed
<Ericson2314>
inputDrvs field in derivations is more complicated
<Ericson2314>
so need to decide how to deal with that in perl
<Ericson2314>
anyways on a totally different note, arrow cpp wants libcuda.so at build time
<Ericson2314>
which is very rude of it
<Ericson2314>
and I don't know what I'm supposed to do
<yorick>
that time patchelf just crashes on libcuda.so
<yorick>
Ericson2314: what's arrow cpp?
<Ericson2314>
yorick: some apache monstrosity....
<yorick>
well, that sounds sensible
<yorick>
Ericson2314: it can build without cuda?
<Ericson2314>
yeah
<Ericson2314>
but i am trying to build a cudadf
<Ericson2314>
that depends on it
<Ericson2314>
and i am guessing it will need the cuda-enabled version?
<das_j>
umm what happened to our RSS feed?
<yorick>
Ericson2314: so buildInputs = [ cudatoolkit ]?
<Ericson2314>
yorick but i think libcuda is provided by the nvidia driver, not libcudatoolkit
<Ericson2314>
unless it's in both?
<yorick>
Ericson2314: I don't think so
<Ericson2314>
libcuda seems to be the impure thing you use at runtime, like we do with opengl and vulkan and the good open apis
<yorick>
no, libcuda just talks to the nvidia kernel driver I think? I could be wrong
<Ericson2314>
I will double check
<yorick>
/run/opengl-driver/lib/libcuda.so does exist
<Ericson2314>
ok came to say the same thing :)
<Ericson2314>
now checking cudatoolkit
<Ericson2314>
yeah `/nix/store/xdxr4dhf60ksahx544ys0z03430j4fcx-cudatoolkit-11.1.1/lib/libcuda.so` is *not* a thinng
<Ericson2314>
* yeah `/nix/store/xdxr4dhf60ksahx544ys0z03430j4fcx-cudatoolkit-11.1.1/lib/libcuda.so` is _not_ a thing
<yorick>
ah hm
<yorick>
why does it want libcuda at build time?
<Ericson2314>
I guess most things dlopen it
<Ericson2314>
but it is making it a DT_NEEDED
ericnoan has joined #nixos-dev
Magic_RB has quit [Quit: Connection closed]
bpye9 has joined #nixos-dev
dongcarl has quit [Write error: Connection reset by peer]
abathur has joined #nixos-dev
abathur has quit [Read error: Connection reset by peer]
bpye has quit [Read error: Connection reset by peer]