<moredrea8>
<freenode_Mic "there is no other compiler in th"> Mic92: Strange... Ok I'll see if I can find where that comes from. Thanks for having a look!
drakonis has quit [Quit: drakonis]
drakonis1 is now known as drakonis
hedning has joined #nixos-dev
init_6 has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
<samueldr>
hmmmm, using wrapGAppsHook with qemu makes the qemu process .qemu-system-x86_64-wrapped, making pkill more annoying to use :(
pie__ has joined #nixos-dev
lassulus_ has joined #nixos-dev
pie_ has quit [Ping timeout: 246 seconds]
lassulus has quit [Ping timeout: 250 seconds]
lassulus_ is now known as lassulus
<samueldr>
reducing the amount of attribtues in possible need of wrapGAppsHook to 1717, removed all qt5 and qt4, as I mistakenly assumed it was new for qt 5.12
<samueldr>
(still leaves those in a situation where the issue could manifest itself)
<Mic92>
samueldr: I think we should modify makeWrapper to keep the executable name intact but move it to a subdirectory i.e. .wrapped
<Mic92>
that will solve a class of bugs we currently see.
jtojnar has joined #nixos-dev
orivej has joined #nixos-dev
<Mic92>
samueldr: I was thinking about this and this might introduce a new class of problems, when programs check there own directory they end up one level too deep.
init_6 has quit [Ping timeout: 240 seconds]
<timokau[m]>
Mic92: can't we just lie about argv[0]?
Melkor333 has joined #nixos-dev
<Melkor333>
I just updated a PR for a new package (mcfly) where I force pushed after a git rebase and git amend. ofborg now shows a very strange infinite recursion error which is from completely different packages
<Melkor333>
Does anybody know what is going on there and if I did something wrong?
<symphorien>
it says Target branch master doesn't evaluate!
<symphorien>
do it's not your fault
<symphorien>
*so
<tilpner>
I think I restarted the eval
<tilpner>
But it seems master is still broken in some way
<Melkor333>
Yeah the last few PR's all failed for the same reason as I just saw
<tilpner>
And across multiple builders too
<tilpner>
You may have to wait until gchristensen wakes up
<Melkor333>
Oh that's okay
<Melkor333>
How long does it roughly take for a package to enter nixos-stable after a PR has been accepted?
<tilpner>
That depends on what you mean by nixos-stable
<lassulus>
If it doesn't get bakported, you have to wait for the next releas3, so max 6 months, if it gets backported it's usually a couple of hours to days
<Melkor333>
aah okay thanks
<Melkor333>
how is determined which packages will be added to the next stable release? Is it just after a freeze period of unstable or something like that? And/Or is there any documentation on that?
<gchristensen>
whats up
<gchristensen>
someone broke master for a few hours? :)
<Melkor333>
gchristensen: yes apparently that's what happened
<tilpner>
I don't know how I feel about packaging prebuilt AppImages in nixpkgs
<tilpner>
But if it's done at all, it must not use appimage-run
Melkor333 has joined #nixos-dev
ixxie has quit [Ping timeout: 245 seconds]
ixxie has joined #nixos-dev
ixxie has quit [Ping timeout: 245 seconds]
ixxie has joined #nixos-dev
ixxie has quit [Ping timeout: 246 seconds]
ixxie has joined #nixos-dev
ixxie has quit [Ping timeout: 250 seconds]
<Mic92>
timokau[m]: we can and we already do
<Mic92>
but the OS steal leaks the abstraction
<Mic92>
mainly /proc/$pid/exe and /proc/$pid/comm are a problem
<timokau[m]>
Mic92:
<timokau[m]>
Mh thats a shame. I assumed those were influenced by argv0 too
<samueldr>
I wonder if there's a way to make some kind of prependable thing, probably needs to be binary, that would handle the wrapper duties in-place, and keep argv0 compatible in all cases
<samueldr>
but then it'd probably need multiple ones, as I wouldn't think a script one would work for binaries or vice-versa, but glad to be wrong
Melkor333 has quit [Quit: WeeChat 2.3]
drakonis has joined #nixos-dev
<infinisil>
Hmm, #54194 increases emacs' racer packages closure size by 250MB by linking to the rust source directly, what do you think of this? I guess it's very convenient, but there might be lots of people who don't use that source anyways (and set rust source to something more dynamic)
<samueldr>
I think a definitive action (merge / close) might need to happen with regards to the question, rather than moving it on the side
<samueldr>
and with the discussion happpening in the PR, and previous discussions on different nixos irc channels, I think that it should be closed; disk space being a cheaper resource to abuse than working memory (RAM) means it probably is better to keep the current default
<samueldr>
*especially* considering how not all FSes can receive a swap file
<gchristensen>
+1
<gchristensen>
but also kinda wish deleting temp on boot was default
<samueldr>
that's probably the more right alternative to the same intents
<samueldr>
though I was thinking it might need a "once you're installed" section to an installation appendix, with common configuration stories
<gchristensen>
a GREAT idea
<infinisil>
Alright I'll close it
<etu>
gchristensen: that would be nice indeed. Because it keeps piling up garbage in there.
<samueldr>
one PID's trash is another's treasure
<gchristensen>
especially malware.exe's treasure
<MichaelRaskin>
My experience tells me that the proper way of wiping /tmp on boot is mkfs
<MichaelRaskin>
(Also, it was complicated to express in terms of NixOS config, and I don't miss trying to shoehorn this into NixOS boot sequence…)
<MichaelRaskin>
If there are large nix-build leftovers, rm takes a long time and mkfs turns out to be much faster
<qyliss>
+1 to wiping /tmp on boot. I’ve meant to PR this before but didn’t get round to it.
<MichaelRaskin>
Round tuits seem to be a currency with stable demand
<gchristensen>
round tuits?
<simpson>
It's how you get things done in the future; you get a round tuit. (Say out loud.)
<gchristensen>
jeeze.
<etu>
MichaelRaskin: I had one of those many years back