<supersandro2000>
How can I run make with rustplatform?
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
rajivr has joined #nixos-dev
ris has quit [Ping timeout: 264 seconds]
jonringer has quit [Ping timeout: 264 seconds]
AlwaysLivid has quit [Ping timeout: 268 seconds]
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]
das_j has joined #nixos-dev
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
teto has quit [Ping timeout: 265 seconds]
maljub01 has quit [Quit: maljub01]
AlwaysLivid has joined #nixos-dev
maljub01 has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
tomberek has joined #nixos-dev
justan0theruser has quit [Ping timeout: 272 seconds]
evils has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
cole-h has quit [Ping timeout: 256 seconds]
bgamari_ has joined #nixos-dev
bgamari has quit [Ping timeout: 276 seconds]
jonringer has joined #nixos-dev
FRidh has joined #nixos-dev
jonringer has quit [Ping timeout: 264 seconds]
alexarice[m] has quit [Quit: Idle for 30+ days]
simonpe^^ has joined #nixos-dev
<simonpe^^>
I'm currently working in a project where we use nix to build and deploy services on embedded devices, we use yocto to build the rootfs and kernel, and nix for the bootloader and secure boot chain of trust. I've been in this field for a long time and I've seen the possibilities since actively using and making custom things in the field with nix for a few years now. Now I've started a new project that
<simonpe^^>
would aim to be a better alternative than yocto and buildroot based on nix. It's not meant to be nixos on arm, it's more meant to provide a toolchain and library functions to assemble a traditional FHS system. With that background information, is there any known project working on this already and do you nixos devs have experience with embedded linux on i.e. NXP and Microchip SOC:s?
<simonpe^^>
The aim with these systems are often to have VERY granular control of what goes on the system and how it is compiled, so I don't really see the nixos module system being something usable on a tiny device with 32MB ram and 8MB NAND flash for storage.
<FRidh>
the NixOS module system is in the end just a front-end to configuration and building. There is no reason it could not be used for what you describe. The modules provided by Nixpkgs are probably not so much of use to you, because they don't cover systems you describe.
<simonpe^^>
FRidh: yes I realized that came out wrong, the module system is definitely usable but not the NixOS modules themselves
<simonpe^^>
Like systemd for example, NixOS is to my knowledge pretty tightly coupled to systemd which isn't usable on tiny devices due to it's size and large dependency tree
<simonpe^^>
rnhmjoj: thx, I'll have a look at that
<clever>
FRidh: but from looking at the diff, the old version is a fixed-output, plus a normal drv that just renames things, the new version is a single fixed-output, and does the rename before the hashing
<clever>
so now darwin and linux can share that renamed output
<FRidh>
right. Question is, was it just an optimization or more behind it.
<FRidh>
just optimization then right
<clever>
yeah, i'm also thinking just optimization
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #nixos-dev
<gchristensen>
archive.org might have it
teto has joined #nixos-dev
kraem1 has quit [Ping timeout: 245 seconds]
FRidh has quit [Ping timeout: 245 seconds]
simonpe^^ has quit [Ping timeout: 265 seconds]
FRidh has joined #nixos-dev
kraem1 has joined #nixos-dev
simonpe^^ has joined #nixos-dev
__monty__ has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 268 seconds]
supersandro2000 has quit [Quit: Ping timeout (120 seconds)]
<adisbladis>
Having the argument be `mysql` that is a polymorphic argument accepting any mysql argument makes sense
<adisbladis>
Your change completely breaks that
<supersandro2000>
no, it should be a no rebuild PR
<supersandro2000>
if not I did something wrong
<adisbladis>
It's not about rebuilds but about breaking interfaces
<adisbladis>
supersandro2000: Also you should CC package maintainers
<sterni>
breakage is not measured in builds only
<gchristensen>
+1 on the rename of mysql -> mariadb
<supersandro2000>
I don't think I should CC literally 100 or more people. thats just spam.
<supersandro2000>
pkgs-utils rename did the same thing with way more packages and we did not do any interface backwards comp
<adisbladis>
It's not spam
<adisbladis>
It gives maintainers ample opportunity to react to changes to their packages
<samueldr>
this cycle between 20.09 and 21.05 has seen, in my experience, a LOT of churn through breaking treewide changes
<samueldr>
many users don't follow the unstable channel at all, and will get the brunt of this in one shot when they change to 21.05 in june
<gchristensen>
since they're all aliased again in aliases.nix I think it should be okay
<gchristensen>
this seems like a strictly good cleanup afaict
justanotheruser has joined #nixos-dev
<samueldr>
there still is no "deprecation workflow"
<samueldr>
changing input names in the overloaded `callPackage` interface can be problematic here
<gchristensen>
I'm not sure these are deprecated aliases, this fixes "mysteriously not overridden" bugs of in the overrides system
<supersandro2000>
especially the mariadb -> mysql change should make it clear that mysql is mariadb since a longer time
<supersandro2000>
maybe some people will notice that they where using the wrong DB.
<gchristensen>
like it is definitely better to have minimal aliasing in aliases.nix
<gchristensen>
erm, all-packages.nix
<gchristensen>
and almost no users evaluate with aliases disabled, I don't anticipate many users being bitten by thins
<samueldr>
the issue is with `.override({})` AFAIUI
<adisbladis>
^ This
<supersandro2000>
I can create a post on discourse that more people are aware of the change but I don't think any single maintainer of any of this packages needs to take any action
<adisbladis>
Posting on discourse isn't good enough
<adisbladis>
There are plenty of maintainers who are not there
<adisbladis>
CCing on github is the reasonable thing here
<samueldr>
we are in dire needs, for years going on, on a proper policy on breaking changes
<samueldr>
even if the policy is "yolo whatever's on unstable", at least when it is codified, it is known
<gchristensen>
I don't think it is fair to point out this specific PR to put up blocks for missing policy, I understand where you're coming from on the issue with overrides (I realize now I meant to say overlays before) imho this is a pretty reasonable PR making nixpkgs have a more consistent interior
<adisbladis>
gchristensen: No one is really arguing for or against the PR itself but by how it's implemented
<samueldr>
I fear none of the specific PRs are "good" to put up blocks
<adisbladis>
With a lack of communication with maintainers
<samueldr>
which means they all end up going through, creating precedent that it's not important
<adisbladis>
"going to merge that sooner than later before the merge conflicts come" is reckless and irresponsible
<supersandro2000>
I like gchristensen suggestion to mention the maintainers of the packages which aliases where moved.
<gchristensen>
what are the maintainers going to do? I don't think it is fair to pretend we have a robust network of highly active maintainers either, even though I definitely wish we did. let's involve the maintainers that make sense, for sure, though
<adisbladis>
Just judging based on supersandro2000`s previous history of "communication" and eager merging I want to make sure that this won't get merged without giving maintainers ample time and opportunity to react
<gchristensen>
what does ample time mean to you?
<adisbladis>
Anything from a few days to a few weeks
<gchristensen>
I think a few days makes good sense and sounds good
<gchristensen>
supersandro2000: what do you think about waiting until Thursday to merge?
<adisbladis>
But also make sure to CC relevant parties
<adisbladis>
It's hard to keep up otherwise
<gchristensen>
in your mind, is the list of relevant parties the ~170 packages touched, or the 9 packages which are subject to their aliases changing?
<adisbladis>
For sure the latter are more relevant
<adisbladis>
I think it's a judgement call
<gchristensen>
yeah, I agree with that
<adisbladis>
Probably somewhere in between
<gchristensen>
like the 9 + maintainers of package sets with major impact
<gchristensen>
that one merged probably too fast too
<supersandro2000>
gchristensen: that would be fine for me.
<supersandro2000>
also while we have all people here: I am doing an aliases.nix for pythonPackages because right now removed packages are just gone without any throw or alias.
<supersandro2000>
which is an integral step when we ever (not going to do that anytime soon) want to normalize all pythonPackage names. I already asked jonringer and he liked the idea but open for feedback and changes as always.
FRidh has quit [Quit: Konversation terminated!]
asbachb has joined #nixos-dev
<tomberek>
anything of note needed more eyes?
tomberek has quit [Ping timeout: 240 seconds]
asbachb has quit [Ping timeout: 240 seconds]
greizgh has quit [Quit: greizgh]
greizgh has joined #nixos-dev
simonpe^^ has quit [Remote host closed the connection]
<supersandro2000>
staging does currently not pass any ofborg checks and I suspect that most things requiring python3-dev are not building. I think the commit that is causing it is https://github.com/NixOS/nixpkgs/commit/0c1aa67215a3b165a6036f2a6302e01dd6938752, the one before it does not eval. Can we give them a revert until FRiedh figures out why they don't work as
<supersandro2000>
he thought out?
orivej has quit [Ping timeout: 260 seconds]
__monty__ has quit [Quit: leaving]
<supersandro2000>
I am thinking about writing a RFC that forbids introducing new ``? null`` to inputs in nixpkgs without a strong reason behind it. The reasoning behind it is that it hides typos and non existent packages in inputs, it is easy to use wrong and overwriting something to null is most of the time not documented. When used in combination with boolean
<supersandro2000>
flags you even need to check if the packages are not null which is a bit pointless because by default packages can are never null. There are also some packages which enable/disable features based on packages being null which is in my opinion a really bad practice because it circumvents some of the safety checks nixpkgs has (package are never null
<supersandro2000>
but only not available on your platform, marked broken or insecure). The only potential downside could be that boolean flags add more inputs but overall the code size should be the same because the assert part can be removed for packages.
<supersandro2000>
TL;DR: I want to do a RFC to forbid new ``? null`` in inputs and replace it with boolean flags.
<supersandro2000>
What do you think about it? Would it be a good idea? Any other suggestions?
<samueldr>
don't ask to ask, you can just write the RFC
<samueldr>
it sounds like you've given it some thought already
<sterni>
I think that steers more in a direction of a packaging best practises which would not be a bad idea but probably a very bikeshedding heavy process to spell out
<samueldr>
now, is it going to be accepted? that's for the RFC process to decide
<supersandro2000>
after fishing out multiple packages which declared non existing packages in inputs I already remove them on every review and cleanup I do
<supersandro2000>
sterni: yeah and thats why I avoided it