<andi->
I would argue not having to write to EFI vars every rebuild but that happens alreayd anyway...
<gchristensen>
it does?
ben has joined #nixos-dev
<clever>
of note, grub has a state file to know if the bootloader has to be reinstalled or not
<clever>
[root@amd-nixos:~]$ cat /boot/grub/state
<clever>
this contains the version, efi/legacy/both, the device the legacy stub goes into, and the ESP path
<clever>
if any of those dont match the current configuration, it re-runs grub-install
<gchristensen>
andi-: where are efivars written on each run?
<andi->
gchristensen: Well I am not sure if the actual efi boot line is written every time probably only with --install-bootloader, confused that with the config of e.g. systemd-boot for a second
<gchristensen>
ah ok
<gchristensen>
but also, are there reasons to not write efivars each time?
<andi->
I had an EFI on my desktop that was being "filled up" with enough writes to it and would then stop accepting changes / deletions through efibootmgr..
<gchristensen>
ouch!
<andi->
since then I am a bit careful not to write toooo often
<andi->
It stores UEFI logs/dumps/… there in some implementations
<andi->
but in general I think it would be fine... Not sure what kind of flash there is.. I definitly think 1kish changes should be fine.. Not sure if that stuff is make for 10k+ writes
<gchristensen>
well clearly that isn't a good idea
<gchristensen>
but bootctl install --no-variables might could work
<andi->
how many rebuilds do you have on your everyday system? :-)
<gchristensen>
about 1600?
<andi->
I guess it is just regular flash and I am being paranoid
<gchristensen>
so it seems that we should be fine to call bootctl install --no-variables
init_6 has joined #nixos-dev
eadwu has quit [Quit: WeeChat 2.3]
eadwu has joined #nixos-dev
init_6 has quit [Ping timeout: 246 seconds]
init_6 has joined #nixos-dev
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 268 seconds]
lassulus_ is now known as lassulus
drakonis has quit [Read error: Connection reset by peer]
eadwu has quit [Ping timeout: 268 seconds]
init_6 has quit []
pie__ has joined #nixos-dev
pie_ has quit [Ping timeout: 258 seconds]
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
<samueldr>
on packet-epyc-1, on a small non-random sample, when tests pass connecting takes in the ballpark of 80~120 seconds
<samueldr>
so it probably wasn't an issue of being close to the alarm time
<samueldr>
it probably is something that once it happens, it's guaranteed not to connect... now what is that "something"?
<samueldr>
I'm a bit confused, on successful builds only some logs tell on which machine it was built
<samueldr>
so a non-cached build, going to the "build steps" tab will help knowing on which machine it was built
<samueldr>
oh, one diff between dmesg output I found is that on a successful build there is "console [hvc1] enabled"; which is probably the required console to work `console=hvc1`
<samueldr>
so first thing to check probably is what would cause some racing with hvc1
<samueldr>
up until that line, and even after that line, the dmesg logs are pretty much identical, except for some lines swapping places in (probably) innocuous places and timings
<samueldr>
not all failures are hvc1 failing to load, but those where the alarm triggered seem to be
<samueldr>
(multi machines test can have one machine seemingly fail to start hvc1, while the other loaded)
<Profpatsch>
Does `passthru.doc = …` have the same effect as copying everything into $doc from the other derivation?
<Profpatsch>
Especially concerning the meta.outputsToInstall mechanism.
<samueldr>
I thought passthru was to have an attribute set not present during the build, but present on the derivation?
<Profpatsch>
So it might “fall through” some tooling
<samueldr>
hard to grep since they are probably all passthru = {\n doc = ...; }; }... but is that pattern common? I haven't looked for it, but I don't think I've seen that before
<Profpatsch>
samueldr: I’m always making up stuff as I go. :)
<samueldr>
oh, I thought you were questioning an existing pattern
<Profpatsch>
Interesting side-note: passthru.doc shadows the existing doc output
<Profpatsch>
(if there is one)
<Profpatsch>
So I guess it’s an anti-pattern.
<samueldr>
I don't know if my knowledge is complete enough, but it smells like one
<Profpatsch>
Grrrr, I absolutely hate that you can’t run Qt apps from result/bin
<samueldr>
at the time I was mainly looking for people with more experience with nix
<samueldr>
and still am looking for a good sanity check of the C++ code
<samueldr>
with that PR, I wasn't able to get any failures with mixed Qts
<samueldr>
not saying it's impossible, but I haven't been able to break it yet
<Profpatsch>
samueldr: hah, great
<Profpatsch>
All plugin systems are shit. Don’t @ me
<samueldr>
Profp@tsch
<Profpatsch>
Though Anki is the only Qt app I use.
<Profpatsch>
So I’m not the right person to review that PR …
<samueldr>
do you write C++? do you know nix and nixpkgs?
<Profpatsch>
samueldr: Nope, no C++
<samueldr>
ah
<samueldr>
then yeah, maybe not :/
<Profpatsch>
samueldr: what’s the way to route around that problem without that patch? Install in system closure?
<samueldr>
jogging my memory, the crux of the issue is that if there are things from another Qt that somehow gets in PATH, it will cause it to be preferred even when using a Qt app built for another version
<samueldr>
so yeah, system close would work, or syncing the nixpkgs revisions
<samueldr>
the most common issue is running stable and using things from unstable
<thoughtpolice>
I'm not sure how complete this fix is, but it worked fine for me, allows me to run nextpnr out of ./result/bin, and it seems to be common-ish enough in Nixpkgs already
<thoughtpolice>
(I strace'd around a bit and found it was trying to load the plugins dir from ~/.nix-profile at first, and then doing 'nix-env -i qtbase' fixed it, and after grepping for a minute found QT_PLUGIN_PATH used elsewhere)
<{^_^}>
#38647 (by Profpatsch, 39 weeks ago, open): modules/profiles/minimal: sound is disabled by default
<Profpatsch>
infinisil: Also, do you know whether there is any progress on the “attribute deprecation” front? https://github.com/NixOS/nixpkgs/pull/19315 didn’t get merged.
<infinisil>
Profpatsch: Well my plan was to progress on the deprecation with rfcs#33, but oxij disagreeing with everything and Ericson saying they would co-author but not actually doing anything made this pretty discouraging to work on for me.
<Profpatsch>
infinisil: I wouldn’t listen to oxij’s bikeshedding.
<Profpatsch>
They are pretty uncooperative and prejudiced in many ways.
<Profpatsch>
infinisil: Would you like me to co-author?
<infinisil>
Profpatsch: If you feel like it, sure. The current version needs to do some revising to make it simpler though, as mentioned in my second-to-last comment
<infinisil>
And I'm currently very much out of time, a bunch of exams are coming up for me
<simpson>
infinisil: Happens. FWIW many of their points are quite valid, even if you're not comfortable with them, and they seem relatively professional about the whole thing.
<simpson>
Don't worry about Nix; it will be here after exams.
<infinisil>
Well it might be useful, but that has nothing to do with deprecation
<simpson>
It's a solid point: You can't really deprecate without versioning of some sort, and dates are pretty terrible for this.
<simpson>
FWIW I'm happy to offer an even weirder opinion than theirs: deprecation functionality is dangerous to add since it will invite people to start spuriously renaming things.
<infinisil>
simpson: So yeah, I'm fine with using release numbers to version stuff, but I'm not fine with supporting a configVersion setting that allows you to time travel
<infinisil>
simpson: Deprecation functionality is needed though, because there's so many things happening in nixpkgs that breaks configurations for users. It's frustrating me every time I need to update nixpkgs, wondering what broke this time (surprisingly the last update was the first one in a row of like 5 that didn't break anything))
<simpson>
infinisil: Sure, I can see that being tough. Also, though, if time is what matters, then a dated deprecation notice is disconnected from the commit which removes the functionality. (Since we use git, it would be hard to *not* be connected to the deprecating commit, which is lucky.)
<simpson>
infinisil: Ooh, careful that this isn't just a personal itch, then; such problems don't happen to me often enough to consider this personally worth working on.
<simpson>
Or maybe I'm just biased in the other direction! Who knows.
<infinisil>
I'm not the only one, as seen from other efforts and comments, Ericson, Profpatsch and other people have indicated wanting this
<Profpatsch>
simpson: It’s all personal itches.
<Profpatsch>
It’s mostly free-time work after all.
<simpson>
Profpatsch: Kind of? There's a sense in which Nix is clearly a transitional tool on the route to package-capability systems.
<Profpatsch>
I don’t understand.
* infinisil
doesn't either
<Profpatsch>
I don’t think nix is going to go away anytime soon, neither will nixpkgs
<Profpatsch>
And I don’t think anybody wants to do all the packaging work again for some new tool.
<simpson>
A capability is a token of authority; it denotes both the ability to do a thing as well as the permission to do that thing. A package capability would be a token, communicable but unforgeable, which grants the ability to use a package.
<Profpatsch>
I understand even less.
orivej has joined #nixos-dev
<simpson>
Don't worry; most current packages wouldn't make it anyway. They'd have to be rewritten from scratch in capability-aware languages.
<Profpatsch>
Oh, you mean which files to access and stuff. But that’s kind of wholly besides the point. :/
<simpson>
infinisil: The bigger point is that you should not fret so much just because people are inspecting and critiquing your ideas. I mean, the person you're complaining about left several long professional review comments as well as a PR with a PoC! That's a lot of work.
<Profpatsch>
oxij is not one for small incremental improvements, sure.
<infinisil>
Yes I already realized that, see my already linked comment
<simpson>
Profpatsch: I mean capabilities. There is a deeper path here that has been flowing for decades in a certain direction, and Nix is part of that, even if Nix didn't intend to.
JosW has joined #nixos-dev
<Profpatsch>
simpson: Probably. Everything is part of some other ideas in the future.
<infinisil>
Oh and one thing I didn't mention in my RFC: We should think better about the public interface nixpkgs should provide
<simpson>
Agreed.
<infinisil>
Because those are the things exposed to users, and those are the things we can break by updating stuff
<infinisil>
A great example from just yesterday: xdg-open stopped opening pdf files with evince, because it changed $out/share/applications/evince.desktop to $out/share/applications/org.gnome3.Evince.desktop
<infinisil>
All files in $out can be considered the public interface too, and can therefore break stuff
orivej has quit [Ping timeout: 258 seconds]
eadwu has joined #nixos-dev
<gchristensen>
I've had at least one production outage due to that
<infinisil>
The ultimate goal would be to have a bot that goes "Beeep, this and that is backwards incompatible" when people make PR's
<simpson>
Ah, sure. Don't be surprised if your detection heuristic doesn't catch much because it's coarse, and once you get your tracking to be fine enough, nearly everything is backwards-incompatible. It would be the typical way that this pattern goes.
<simpson>
OTOH I see your point that automatic generation of *which* incompatibilities have been introduced would be very nice.
<infinisil>
simpson: I think if we limit ourselves in what is public interface, then it doesn't have to be that way. E.g. we could say that only $out/share/applications and $out/bin are public interface (the filenames at least), everything else in $out isn't
<infinisil>
We could also ignore things people are very very unlikely to use
<simpson>
An interesting idea.
<infinisil>
Oh also something I just thought of: Allowing people to declare "I am using this" which would make the bot check for that thing as well. So when something like #53092 is done, it would say that those packages are still used by @paul and @betty
<simpson>
Ah, to have the days when popularity-contest was a good idea~
<FRidh>
if packages are used by only select individuals, then likely it doesn't belong in nixpkgs
<simpson>
I'd be okay with it for very specific individuals, namely ofborg~
JosW has quit [Ping timeout: 252 seconds]
<infinisil>
FRidh: isn't that how all packages start though :P? There's always a single person wanting to use it at first. But yeah, 100% unpopular packages probably don't belong
MichaelRaskin has joined #nixos-dev
<ivan>
andi-: that's probably just linux being annoying, I have to boot linux with efi_no_storage_paranoia
<ivan>
andi-: it was capped because some motherboards were bricking themselves
<andi->
ivan: ahh, I c
<samueldr>
thoughtpolice: you have diagnosed the issue right AFAIUI, but the fix is not good, imho, it's a workaround. I think it might even cause issues along the way, but I don't remember how
<samueldr>
and it's not the first variant of this fix getting into nixpkgs :/
<samueldr>
ah, I think I remember. If the software loads other qt libraries via QT_PLUGIN_PATH that aren't in qtbase, most common would be the image formats I think
<samueldr>
and also note that it may pollute the environment for other Qt software which could be started, and not using the same libraries, but this might not be a common issue
orivej has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
drakonis has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
drakonis has quit [Ping timeout: 272 seconds]
<samueldr>
gchristensen: I think you use prometheus, do you use alertmanager? if so can you judge whether #53877 is find for a backport to 18.09? (looks like it would)
<thoughtpolice>
Speaking of QT, Is there any policy on using different QT versions? Ugh.
<thoughtpolice>
We currently ship QT 5.11 for Darwin but 5.12 for Linux. But I have an app with a regression on Linux using QT 5.12 that isn't present with 5.11 (and it basically makes the app highly unusable)
<thoughtpolice>
But everything else otherwise uses 5.12, so having one expression out of a billion on Linux use 5.11 seems... unfortunate.
<thoughtpolice>
Suggestions? Thoughts? Rituals I can use to debug QT?
<samueldr>
sadly no, though I think it happened in the past that only a handful of Qt apps were using older Qt releases