<{^_^}>
#101444 (by jonringer, 1 day ago, open): nixos/doc: finish up 20.09 release notes
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 272 seconds]
tilpner_ is now known as tilpner
justanotheruser has quit [Ping timeout: 272 seconds]
Cale has quit [Ping timeout: 264 seconds]
Cale has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 272 seconds]
ris has quit [Ping timeout: 260 seconds]
cole-h has joined #nixos-dev
danderson has quit [Remote host closed the connection]
danderson has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
orivej has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nixos-dev
stoile has quit [Ping timeout: 260 seconds]
stoile has joined #nixos-dev
<colemickens>
Is there anyway to (easily) get nixos-rebuild to give me the same hash when building with/without flakes? I think the fundamental issue is that my flakes build passes richer git version info to nixos than the classic method using NIX_PATH pointed at a url.
<colemickens>
I think I've actually done this before my going into the flake and adding a module to override the system version, to make it match the classic method. But this doesn't feel great.
<colemickens>
I opened an issue for this as well: https://github.com/NixOS/nixpkgs/issues/101622. It's mostly to help demonstrate how flake.nix isn't necessarily magic, or hard to adopt into an existing nixos config.
<{^_^}>
#101622 (by colemickens, 10 minutes ago, open): Unify nixos version suffixes across flake and non-flake builds to demonstrate flakes
<cole-h>
colemickens: A workaround might be to place a file with the contents of the flake suffix in `.version-suffix`
cole-h has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 240 seconds]
<colemickens>
I guess, seems "cleaner" to forcibly just set it in a one-liner in the nixos config somewhere for the sake of the example
<colemickens>
Also, I think maybe I should try using builtins.getFlake instead of passing inputs to specialArgs? Is that what we're meant to do???
<colemickens>
I'm helping someone convert to flakes, and then have unpinned fetchTarball calls.
<colemickens>
Converting those to use flakes isn't so bad, but having to explain specialArgs, etc, is a lot of extra complexity.
alp has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
stoile has quit [Ping timeout: 246 seconds]
stoile has joined #nixos-dev
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
ivan has quit [Quit: lp0 on fire]
harrow has quit [Quit: Leaving]
bridge[evilred] has quit [Remote host closed the connection]
bridge[evilred] has joined #nixos-dev
bridge[evilred] has quit [Remote host closed the connection]
bridge[evilred] has joined #nixos-dev
harrow has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
ivan has joined #nixos-dev
kalbasit__ has quit [Ping timeout: 240 seconds]
alp has joined #nixos-dev
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
Mic92 has quit [Quit: WeeChat 2.9]
Mic92 has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-dev
alp has joined #nixos-dev
FRidh has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
alp has quit [Ping timeout: 272 seconds]
<arianvp>
hmm
<arianvp>
does the latest nixUnstable not include flakes anymore??
<MichaelRaskin>
The CI that typically happens to anything won't catch the actual kernel breakages anyway
<delroth>
ok, let me take a more immediate and specific example if "kernel updates should probably go through code review and any CI that's available" doesn't resonate
<delroth>
what's the argument for this not going through CI?
<delroth>
which would have caught the fact that it causes nixpkgs to not evaluate anymore
ris has joined #nixos-dev
<MichaelRaskin>
Yeah, messing with self. and other evaluation tricks should
<MichaelRaskin>
At least unless actually test-evaled locally, which never happens (almost)
<delroth>
if anything stuff that doesn't go through a PR should be held to an even higher standard of automated testing
<MichaelRaskin>
Or we need an auto-roll-back bot
<delroth>
but as it is clearly right now people who commit directly on master aren't running basic stuff like nix-review wip
<delroth>
even on refactorings, or package updates with few revdeps
<MichaelRaskin>
nix-review wip is a complete dream that is never an efficient solution
<eyJhb>
andi-: ping
__monty__ has joined #nixos-dev
<andi->
eyJhb: pong
<eyJhb>
Perfect! I have tried to explain better in the .patch file, what the pros/cons is for this patch. But I am not sure if it is OK. Mind reading it before I commit, and come with any suggestions andi- ? https://termbin.com/vhr7
<eyJhb>
This should also explain if it can be in the default Firefox build (which would be awesome), while it also states why it connot. From my POV, it can be in the default Firefox, as we are not common users which do not understand how such basic tasks work. But while that is said, there might be companies such as *insert nawe of that big US store I cannot remember the name of*, where it introduces a
<eyJhb>
risk they might not want to take
averell has quit [Quit: .]
<andi->
eyJhb: well I don't buy that security argument. Or well I don't follow it. My mom uses NixOS that auto-updates. Is she an advanced user now?
<MichaelRaskin>
I guess this would be a patch that blocks the use of the official branding?
<eyJhb>
andi-: That is what I thought about afterwards, so it should be rewritten as it still apples to us
<eyJhb>
Nope, it is OK MichaelRaskin , get the OK from Mozilla
<eyJhb>
But it makes sense to make it a seperate package then andi- ? As it does introduce a extra surface of attack, even if it is VERY VERY specialised
averell has joined #nixos-dev
<MichaelRaskin>
I have a feeling that this patch has never been in the set that Mozilla people looked at?
<tilpner>
eyJhb: Who will take advantage of this? Just you, or is this preparation for e.g. HM integration?
<andi->
Maybe. I am thinking about always setting the variable in the wrapper. If you then want to change it you have to do that through config.firefox.profilesfool in your NixOS config.
<andi->
eyJhb: he asked sylvestre about it. The conversation is in the PR.
<MichaelRaskin>
I see references to Mozilla's OK of our previous patchsets, which they agreed to classify as minor and portability
<andi->
Err MichaelRaskin ^
<tilpner>
eyJhb: Have you considered (and decided against) rolling profiles.json into the firefox derivation, instead of putting it in the profile?
<eyJhb>
andi-: Hmm, that could actually solve it! So that it will always set it to "DO NOT DO THIS!" even if specified is users.js, but then you can allow it by setting a value in your config? Seems like a nice solution
<eyJhb>
tilpner: Rebuilding Firefox is quite the task
<MichaelRaskin>
Hrm, pastebinned patch expired
<tilpner>
eyJhb: Yes, but you don't need to rebuild firefox, just wrap it
<tilpner>
(Yay, another wrapper for ultimate maintainability)
<MichaelRaskin>
Yeah, I compared link in conversation with the current discussion, found out they are different…
<andi->
Not another. There is already a giant one that will not go away any time soon
<eyJhb>
tilpner: How would you go about wrapping it? Because then you would not include the patch, and thereby have to make a chroot for each firefox profile, right?
<MichaelRaskin>
tilpner: in Nix model. wrappers are more maintainable than tuning the build
<tilpner>
I feel like I showed you this before
<eyJhb>
tilpner: That might be true! :p Sorry
<eyJhb>
MichaelRaskin: I have the original in my email, but it is the one that is in the PR that I linked :)
<eyJhb>
Yes, but then you get a Firefox instance pr. profile you might want. You would end up with firefox-p1, firefox-p2, etc. right?
<eyJhb>
If this was for a single Firefox instance, you wanted globally then you might as well use /etc/mozilla/firefox/policies.json as far as I remember
<tilpner>
Oh, you want multiple preconfigured profiles with a single wrapper?
<MichaelRaskin>
I wonder if a bit of symlinking magic and a bit of exec-ing in a way that fools Firefox about its location would actually be enough to get per-wrapper policies without even patching
<tilpner>
Good idea
<MichaelRaskin>
But needs careful checking whether it would actually work correctly
<eyJhb>
You can do that, but yet again you will end up with multiple wrappers, or something like that :/ (as far as I understand)
<MichaelRaskin>
If a wrapper costs like a MiB and is easy to generate from whatever management solution you use, why not?
<eyJhb>
Pros and cons each time I guess, but having a single wrapper (default firefox), just seems ideal. Esecially for the experience/integration with HM
<eyJhb>
Having each profile be a firefox-*, does not seem ideal + you would have to change default profile all the time and rebuild
<MichaelRaskin>
Of all things, HM could manage a handful of wrappers either with unique names or behind a single dispatcher pretty cheaply
<eyJhb>
Unless you can just alias firefox="firefox-work", but not sure how well that would wrok globally
<MichaelRaskin>
I would say less patching and ROFS stored policies.json are both good
<eyJhb>
The scenario is e.g. you have three profiles, home (default), uni and work. When you are doing each thing, then you would want all browsers to open the profile which corresponds to what you are doing. So you could easily set uni to be default when you get there (from within Firefox), then work afterwards and then home when you are free
<MichaelRaskin>
A zenity-based profile chooser sounds like a usrmountable amount of effort, and easy to iterate upon
<eyJhb>
I do not disagree with that. but having the multiple wrappers just seem less ideal
<MichaelRaskin>
Like, _how_ do you want to choose profiles in your case?
<MichaelRaskin>
Profile manager, and sometimes skipping it to launch the previous one?
<MichaelRaskin>
Sounds like zenity-based stuff would cope comparably?
<eyJhb>
firefox -P , set default, use that for some hours. There 100% is a oneliner.
<eyJhb>
But the main thing atm. is then (I guess), how one would go about making a wrapper the default wrapper without rebuilding
<MichaelRaskin>
One more dispatching wrapper, obviously
<MichaelRaskin>
Which stores the choice in ~ but can only choose among prebuilt options
<MichaelRaskin>
No hope for just exec without chroot? Pity
<MichaelRaskin>
I remember there are some silly tricks
<eyJhb>
How would you go about it? You either need to do as tilpner showed, or you have a single location where it will look for polices.json
<eyJhb>
So you have to make a pr. process policies.json, which should all be in the same place but different. There might be some clever hacks however!
<MichaelRaskin>
(exec -a id ls )
<eyJhb>
also andi-++ for getting your Mother onto NixOS
<{^_^}>
andi-'s karma got increased to 41
orivej has joined #nixos-dev
<andi->
eyJhb: it was more a made up exanple but they have a Pi that runs NixOS. I do not do family IT support anymore. They are stuck on windows ;)
<eyJhb>
andi-: aww, sad then :( But understandable... :p
<eyJhb>
MichaelRaskin: Not sure how you would use that
<andi->
eyJhb, MichaelRaskin: if you both figure out a nicer way to do the same or have some noteworthy result of your thoughts please add that to the PR. The more I think about the proposed approach the less I like having a bit of a footgun there. Gonna step away from the computer for a while.
<eyJhb>
Will do andi- :) Hoping MichaelRaskin have a sweet sweet exec trick
<eyJhb>
Added the current disucssion to the PR :)
<MichaelRaskin>
Well, I mean, at my stated cost of 1 MIB per wrapper you can just copy the binary
<MichaelRaskin>
And symlink everything around it
<MichaelRaskin>
I guess not the solution we need but solution we deserve…
<MichaelRaskin>
Bwahaha
<MichaelRaskin>
If we exec via ld-linux explicitly, we only need to copy <200KiB
<aminechikhaoui>
niksnut I think it might be useful to have hydra projects/jobsets declared through flakes ? that can phase out the declarative jobset api
<colemickens>
should I be using builtins.getFlake instead of passing inputs throgh specialArgs? Is there a discussion of this somewhere?