justan0theruser has quit [Ping timeout: 268 seconds]
<samueldr>
hmm, I wonder why `wrapCC` would somehow not wrap `cc`
utsl has quit [Ping timeout: 260 seconds]
<samueldr>
hm, dropping pcc since I accidentally wasn't building with pkgsStatic and it doesn't
jonringer has quit [Ping timeout: 260 seconds]
alp_ has joined #nixos-dev
bqv has joined #nixos-dev
saschagrunert has joined #nixos-dev
nschoe has joined #nixos-dev
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
<teto>
timokau[m]: I am squashing hte neovim PR right now ^^
<raboof>
if a codeowner appears to be taking a break, would it make sense to add another one? I see some trivial PR's go unmerged, perhaps because other reviewers expect the codeowner to take care of it?
<raboof>
oops. basically the same PR (different title) was merged pretty much immediately https://github.com/NixOS/nixpkgs/pull/101730 - I guess I should format the title more like a regular update next time :D
<eyJhb>
Regarding our Firefox discussion some time ago, I would prefer to use chroot, as not everyone is doing symlinks of files in /nix/store, and just copying everything over to modify a single files seems like quite much. As far as I know, the chroot in NixOS, just adds all the normal paths and then you can override a single one?
<eyJhb>
Also, I have a question for anyone who is into Nix maybe niksnut. If I want to have a package, and it is in the cache, do I then also download the buildInputs for that package, even if I do not have to build it?
<teto>
eyJhb: depends if it's a propagatedBuildInput or nativeBuildInput I would say
<eyJhb>
I am guessing propagatedBuildInput should stay, but a standard buildInput, should not be needed, right?
<eyJhb>
I was just curious on how it handled it
<teto>
eyJhb: for instance you don't need cmake once the program is compiled
<eyJhb>
Yes, but it was more of, does Nix fetch cmake even if I do not need to compile and put it into my store?
<eyJhb>
Would be cool, if we had the ability to do a nix-store --remove-build-deps or something
<teto>
it doesn't fetch it
<teto>
you can play with nix-store queries and nix show-derivation to see what derivations look like. The wiki shows off some commands
<eyJhb>
teto: wiki or manual? Can't find much on the wiki
<manveru>
so i guess refs cannot have slashes in them by design? :|
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-dev
nschoe has quit [Ping timeout: 268 seconds]
<teto>
manveru: doc says nixUnstable accepts refs/tags/my_tag and it works in my experience
<manveru>
hmm, i tried `pull/number/head`
<etu>
ryantm: [PHP] Now we have I think 3 packages in repology that should be out of date that lives in separate files, phpstan, composer2 and something more :)
nschoe has joined #nixos-dev
nschoe has quit [Ping timeout: 240 seconds]
<gchristensen>
hmmm... it looks like if you run `nixos-rebuild dry-activate` as an unprivileged user, it erroneously says it'll restart systemd -- anyone else seeing this?
nschoe has joined #nixos-dev
alp_ has joined #nixos-dev
<gchristensen>
I wonder if dry-activate works otherwise as an unprivileged user o
<gchristensen>
it pre-builds the system automatically, but only when plugged in to power
<gchristensen>
and your copy of nixpkgs doesn't change mysteriously while it runs
<qyliss>
wowww
<qyliss>
super-lorri
<gchristensen>
it doesn't handle the case where you say "Not right now" option very well, it'll just re-prompt you every 5 minutes until you say yes or unplug from power. I guess you could say I took inspiration from Windows there
<luc65r>
supersandro2000: about #101868 the handling of ./fasmg and ./fasmg.x64 should work
<gchristensen>
there are other cases it handles poorly too, like if you nixos-rebuild switch on your own it will try to roll you back. probably some ctime comparisons are needed there
<luc65r>
on your build on darwin, it uses ./fasmg.x64, which is the right one
<luc65r>
but I guess the executable isn't compatible
teto has quit [Quit: WeeChat 2.9]
costrouc has quit [Quit: costrouc]
costrouc has joined #nixos-dev
<endocrimes>
gchristensen: Oh nice! - I've been starting to do some horribly cursed things now (I have my system build nightly on one of our hetzner boxes to populate my partner and I's nix cache). All I need to do is make it automatically bump the nixpkgs ref we're using next
<gchristensen>
endocrimes: anyway, yeah -- nice -- I don't fetch my nixpkgs clone often enough to depend on it, so I wanted to follow the channel but only have the channel update when I agreed to a system upgrade ... but you can't use `nix-channel` on an arbitrary profile ... so I "replaced" it with just some nix path bits.
<endocrimes>
That makes sense
<endocrimes>
I have a git checkout mostly for making it easier to test package changes or applying unmerged patches
<gchristensen>
the one major thing I wish I could do is tell the Nix daemon to do the builds in a way that prioritizes minimizing resources in exchange for taking longer
<endocrimes>
that would be nice
<endocrimes>
like some kind of `nix-build -j 1`
<gchristensen>
I guess I could do exactly that :P
<endocrimes>
oh yeah nix-build does give you options xD
<qyliss>
there's daemonNiceLevel also, which is sort of what you want if you squint at it :P
<gchristensen>
I was thinking more like the CPU* options in systemd
<endocrimes>
it would be nice if nix could use cgroups for limiting builds a bit
<michaelpj>
setting `daemonNiceLevel` and `daemonIONiceLevel` is extremely useful
<gchristensen>
if nix's daemon put the builds in to different, nested cgroups, I guess could spelunk the cgroup tree and do it manually :P
<michaelpj>
I wonder if we could set those to something de-prioritized by default?
cbarrett has quit [Read error: Connection reset by peer]
cbarrett has joined #nixos-dev
nschoe has quit [Ping timeout: 268 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
<ryantm>
etu: Okay! nixpkgs-update was dead for a few days due to disk being full, but it is running again. Hopefully we should see whether it works in the next couple days.
xwvvvvwx has quit [Ping timeout: 260 seconds]
xwvvvvwx has joined #nixos-dev
<supersandro2000>
nix store can be brutal. cleaned over 150GB today
<aanderse>
supersandro2000: thats only because i've been reviewing PRs like a boss
<aanderse>
supersandro2000++
<{^_^}>
supersandro2000's karma got increased to 5
<supersandro2000>
undefined context, give me more info please
<supersandro2000>
*you've been?
<supersandro2000>
but never building bigger PRs cause they take way way to long to build
<jonringer>
if you review PRs, be prepared for some store bloat
<jonringer>
having to pull in dev dependencies can sometimes be huge. For most haskell programs, the runtime closure is usually 10's of MB, but the dev closure is usually several GB
<jonringer>
supersandro2000++
<{^_^}>
supersandro2000's karma got increased to 6
<supersandro2000>
jonringer: I usually don't build haskell because they take way to long to build
<supersandro2000>
but glad you appreciate it. I was a bit unsure in the beginning.
<supersandro2000>
Just want to make master more stable and less broken
<supersandro2000>
especially for darwin
nschoe has joined #nixos-dev
<luc65r>
supersandro2000: I really appreciate that you are building PRs on darwin, it is really helpful because I can't test it myself
<luc65r>
supersandro2000++
<{^_^}>
supersandro2000's karma got increased to 7
<ehmry>
is there a trick to override stdenv to add an additional setup hook to mkDerivation?
<ehmry>
Ericson2314: ^?
<jonringer>
and it's appreciated a lot
<cole-h>
Especially while ofborg's darwin builder is down
<Ericson2314>
ehmry: well you can always put a set up hook in nativeBuildInputs
<Ericson2314>
or do you really want a new stdenv?
<supersandro2000>
luc65r: if you want something tested hit me up
<supersandro2000>
aanderse: you don't need to be. every little helps
<ehmry>
it looks like I'm going to have to apply libtoolize/autoreconf everywhere for the genode target unless I want to deal with static libraries everywhere
<aanderse>
well... thanks for being a super star :)
<supersandro2000>
aanderse: I heard a lot over the years but never this one 😃
<supersandro2000>
ehmry: if the storage in the space wouldn't be as slow I would hijack one server there...
<supersandro2000>
cleaning nix store there takes like 5x the time
<ehmry>
supersandro2000: thats easy to fix, don't build on ceph
<supersandro2000>
ehmry: do we have a non ceph that is good for building?
justan0theruser has quit [Ping timeout: 264 seconds]
ris has joined #nixos-dev
<samueldr>
AFAICT, from the manual, there is no way for a derivation to ask to have absolutely no extra sandbox paths added whatsoever?
alp_ has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
<regnat>
samueldr: There's the pre-build-hook that can be used for that
AlwaysLivid has quit [Remote host closed the connection]
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<samueldr>
hm, though nothing that allows *one* derivation to opt-out from /bin/sh existing as I can see
<samueldr>
does that mean that our compilers bootstrapping process "hopefully" don't end up accidentally using whatever /bin/sh has been made available?
justanotheruser has joined #nixos-dev
halfbit has joined #nixos-dev
<halfbit>
is this the room to ask about packaging woes?
<gchristensen>
usually #nixos is a good place to start, and if it gets deep in to the technicalities of how Nixpkgs works, then #nixos-dev becomes more appropriate
saschagrunert has quit [Remote host closed the connection]
red[evilred] has joined #nixos-dev
<red[evilred]>
gchristensen (IRC): I sent you some stuff in /msg, (in case your irc client doesn't notify you)
<gchristensen>
ah!
<gchristensen>
I accidentally cleared all buffer notifications in a moment of keyboard confusion
<hexa->
weechat alt+h? :D
<gchristensen>
yea
<red[evilred]>
do you still have all the text?
<gchristensen>
yea
<hexa->
i have buffer switching on alt+g and alt+j x(
<red[evilred]>
(it's about 30 lines)
<gchristensen>
I have all my IRc logs since 2012
<samueldr>
I'm also confused by the phrasing:
<samueldr>
>> Depending on how Nix was built, the default value for this option may be empty or provide /bin/sh as a bind-mount of bash.
<samueldr>
I'm looking at my NixOS Nix install and it's neither empty, nor **bash**
<samueldr>
I thought maybe I could cheat a bit by simply rm-ing it early, but that's not an option it looks like
<samueldr>
to at least run one build without `nix-build --option sandbox-paths ""`
<samueldr>
though it would be neat to opt-out from all sandbox paths at the derivation level
<samueldr>
since those sandbox paths are not inputs of the derivation, and building with and without can change results
nschoe has joined #nixos-dev
<aristid>
live CD using longterm kernels doesn't give best experience for people on the very latest hardware :P
<aristid>
had to modprobe i915 force_probe=9a49 to get my tiger lake intel graphics recognized
<cole-h>
Isn't that the point of LTS kernels? Little-to-no changes?
<aristid>
indeed, and i wonder if the nixos installer should use that
<aristid>
it does right now
<aristid>
maybe the best option would be to make an installer available that uses the latest kernel, with the warning "Use this if your hardware is not otherwise organized, but it may be less well tested and/or stable"
alp_ has quit [Ping timeout: 264 seconds]
<aristid>
but i guess things are going in the opposite direction, with the current homepage even making the unstable channel installer really hard to find
<samueldr>
aristid: I would consider that latter point a bug, can you open it on the nixos-homepage repo please?
<samueldr>
and for the latest kernel iso, I have an open issue about that somewhere
<samueldr>
the problem is that because of things like zfs we could hang the channel bumps until that catches up
<samueldr>
the details tab will have the nix expression (nixos/release-combined.nix)
<samueldr>
and the attribute name is the job name `nixos.iso_minimal_new_kernel.x86_64-linux`
<halfbit>
thanks gchristensen
<halfbit>
how does the cmake stuff work with nixpkgs to allow one build to find its deps? I don't think its working in this case
<halfbit>
find_library() cmake call seems to be failing, even though the library its looking for exists
<gchristensen>
do the things that takes place in stage-1 get proper timestamps, or are they all blatted out and loaded in one go?
* aristid
is hacking himself a plasma5 ISO image with new_kernel, let's see if it works :D
alp_ has joined #nixos-dev
<gchristensen>
okay, it can't possible have proper timestamps -- Startup finished in 11min 49.790s (kernel) + 10.323s (userspace) = 12min 113ms
<halfbit>
how does cmake even get run by mkDerivation
<samueldr>
gchristensen: what do you mean proper timestamps?
<samueldr>
systemd blame / analyze? I don't think so, there's pretty much nothing systemd-aware in our stage-1 (yet)
<gchristensen>
I launched a server at 20:09, and the very first log message in the journal says Oct 29 20:22:09 but I'm pretty sure I'm able to see console logs before 20:22:09
<samueldr>
ah, journald logs timestamps
<samueldr>
gchristensen: look at your own machine's logs, and you should also see something similar
<samueldr>
I know for sure it didn't take ~0 seconds for me to input my passphrase when booting my machine
<samueldr>
so it couldn't have the same log time as "stage-2-init: running activation script..." and the initial log line
<samueldr>
so, without actually verifying in journald, I would say you're right in thinking the latter
<aristid>
*mumbles something about mksquashfs using lzma and not a compression algorithm on the efficient frontier*
<gchristensen>
samueldr: I'm thinking I might add a set -x to the top of stage 1 and stage 2, and maybe use tricks to pipe all the output to something that prepends a timestamp ... does that sound reasonable?
<samueldr>
yes and no
<gchristensen>
not as a PR, just as a exploration
<worldofpeace>
aristid: I think hydra builds this as an artifact
<samueldr>
set -x in my mobile nixos exploration IIRC caused switch_root to not work
<gchristensen>
wow!
<worldofpeace>
aristid: we just don't have it linked on the website
<qyliss>
aristid: we've talked about linux_latest_zfs in the past I think?
<aristid>
_right now_ it seems in the unstable channel, linuxpkgs_latest is actually old enough (5.8)
<qyliss>
it would probably benefit enough people
costrouc has quit [Quit: costrouc]
<samueldr>
gchristensen: do try -x, might have been something else in my setup too
<aristid>
qyliss: maybe? but i wasn't there?
<halfbit>
thank you, I saw the cmake/default.nix I didn't realize that script was the magic sauce
<worldofpeace>
qyliss: I believe it's talked about in the issue I linked
<qyliss>
aristid: I don't remember what the outcome of the discussion was
<samueldr>
gchristensen: I'm not using shell anymore in stage-1 so I haven't tried it again
<gchristensen>
nice
<qyliss>
worldofpeace: oh, cool :)
<gchristensen>
okay
<qyliss>
sorry, wasn't following the discussion
<worldofpeace>
qyliss: Yeah, I think samueldr made some good suggestions, it just probably needs to be worked out and stuff
<gchristensen>
we need to get resholved and shellcheck in to stage1
<samueldr>
gchristensen: or entirely stop relying on sh :$
<halfbit>
so in theory then I can do something like nix-build --run-env -A paho-mqtt-cpp, run one of the steps in the derivation, and then hopefully see what some of the CMAKE env vars are?
<qyliss>
I should stop trying to IRC while watching TV
<gchristensen>
oh that too
<samueldr>
gchristensen: which I believe systemd in stage-1 would do?
<halfbit>
is there a guide on debugging this stuff for cmake I maybe missed when searching?
<halfbit>
worldofpeace: that script is very helpful, thank you for linking
<worldofpeace>
qyliss: lol, mood
<worldofpeace>
halfbit: so I believe you're trying to run the cmake phases?
<halfbit>
I want to see why paho-mqtt-cpp CMakeLists.txt find_library() call isn't finding the paho-mqtt-c lib, which is there. So I think that's right
<halfbit>
I want to see env vars after this script
<worldofpeace>
halfbit: like you want to know content of cmakeFlags?
<worldofpeace>
halfbit: so what you want is nix-shell -A
<worldofpeace>
that will drop you into a shell and you can introspect those environment variables values
<worldofpeace>
postHook isn't run as part of any phase, so it should be available right away
<worldofpeace>
an example, because I guess nix-shell cli can be confusing, is nix-shell -A paho-mqtt-c packages.nix
<aristid>
yass my plasma5+newkernel works. and i didn't even to have to write it, because the file actually exists. it's just not integrated for some reason
<halfbit>
in the middle of reinstall nix on archlinux... since I think it got screwed up royally somehow
costrouc has joined #nixos-dev
<gchristensen>
samueldr: I just peppered calls to date everywhere
<aristid>
ah of course, i guess it was removed from release.nix due to holding up the channel to often, as samueldr already kind of explained
<worldofpeace>
halfbit: this wiki page will also be helpful for further details https://nixos.wiki/wiki/Packaging/Tutorial. in the future it will be a lot o easier to do those things, because nix shell has a `--phase` flag
<samueldr>
gchristensen: understandably :)
<samueldr>
gchristensen: though aren't we already running stage-1 through shellcheck? I thought we were
<gchristensen>
I dunno, I didn't look. my immediate reaction to editing any shell script is to assume it inst'
<gchristensen>
:P
<samueldr>
haha
costrouc has quit [Client Quit]
<samueldr>
I moved quickly off of busybox sh and into *anything else* for Mobile NixOS as I realized it could become painful to track down slowness and such
<samueldr>
though my main concern was about ordering the script for dependencies, which was becoming way too hard
alp_ has quit [Ping timeout: 264 seconds]
<gchristensen>
nice. yup
<samueldr>
the "annoying consequence" is that it made the boot process lose a bit of its "wow" factor by going through too quickly rather than just wait uselessly for the framebuffer device before starting anything else lol
<gchristensen>
haha
<gchristensen>
so... the ubuntu linux AMI boots in 20s, and under identical configurations we boot in 15 minutes
* samueldr
places bet at udevadm
<gchristensen>
let's see what the date lines say
<gchristensen>
I feel like I'm at my job in 2015, debugging problems by making new AMI after new AMI, hoping this time it'll work
<andi->
great, in this industry nothing ever changes except the name of the tool ;-)
<gchristensen>
:P
<samueldr>
short of getting an AWS server at your desk, what else is there to do?
<aristid>
samueldr: what if there was a separate channel for things such as latest kernel? then it wouldn't hold up the main channel. not sure if i'm making sense right now
<samueldr>
aristid: "kind of" making sense, and at the same point that's missing the mark
<gchristensen>
samueldr: sword fight
<samueldr>
aristid: it's more about a byprocess (process byproduct???) of the way we get isos for the site
<samueldr>
we take *all* from that one channel
<samueldr>
from that one *revision* in fact
<samueldr>
so yes, there could be a channel for it, but not sure it'd be a good solution
<samueldr>
since it *also* needs to pass every testes under tested
<samueldr>
the `latest_with_zfs` option is better
<samueldr>
at that point we could also produce `latest_without_zfs`
<halfbit>
worldofpeace: ok so the CMAKE_LIBRARY_PATH is indeed correct, so now I'm even more confused why paho-mqtt-cpp isn't finding the library
<halfbit>
infuriating
<aristid>
samueldr: and the main problem of the latest_with_zfs kernel was the risk of an EOL kernel being the last one to support it?
<aristid>
samueldr: so for 5.9.0 at least, zfsonlinux was ready before 5.9.0 according to its website (presumably linux was a rcX when it became ready)
<aristid>
but yeah no guarantee that they're always so timely
<samueldr>
exactly
luc65r has quit [Quit: WeeChat 2.9]
<aristid>
and the problem with using EOL kernels is the risk of unaddressed security bugs?
<samueldr>
yeah, more to the point we don't want to _keep_ them around in the tree for longer than needed
<jonringer>
the biggest concern, but there may be some software which is sensitive to information provide by /proc for example
<samueldr>
so it cascades into not having them for producing the iso
<samueldr>
(jonringer: responding to what exactly?)
<jonringer>
EOL kernels
<samueldr>
then I don't follow that thought :)
<jonringer>
for example, the python3Packages.psutil will scrape output from /proc, so it's sensitive to the exact formatting of what is produced
<samueldr>
we're talking about EOL but still newer than latest LTS
<samueldr>
so that can't be an issue or else things would be broken between the default kernel (latest lts) and the new kernel releases
<worldofpeace>
halfbit: could u link the source code? the call in cmake
<jonringer>
oh, then yes, your main concern is that security patches won't be applied
<worldofpeace>
and other information about all the setup hooks in nixpkgs, and the section on stdenv will be very helpful too
<abathur>
timewarp
<samueldr>
how the F can the resize be made faster?
<halfbit>
ah perfect, I bet this will help me if I want to do pkgStatic and cross compiles too, some of this doc
<samueldr>
4TB I spy?
<halfbit>
I'm going to get where I want, its just a fun learning experience for sure :-)
<halfbit>
thank you again
<gchristensen>
samueldr: 2 things to consider here ... 1. is resize2fs actually that slow? 2. what is that message there from the kernel in the middle, and is it related
<halfbit>
now if only nix worked with windows and msvc, I could ditch conan
<samueldr>
gchristensen: crng init is the entropy pool AFAIUI
<samueldr>
which I haven't seen cause any problem really
<worldofpeace>
halfbit: I think there's nix for WSL?
<samueldr>
though could resize2fs need random?
<halfbit>
worldofpeace: there is, and I suppose it would work with gcc/clang in wsl
<halfbit>
which was sort of my game plan mostly, but native windows builds are probably still wanted for some people
<worldofpeace>
gchristensen: it seems you're busy, but if u could op me to change the topic it would be appreciated
<gchristensen>
samueldr: search the internet for "crng init done" and you'll find lots of complaitns about slowness directly after. I think I'll add strace to resize2fs to take a look.
<gchristensen>
worldofpeace: you're op'd!
<samueldr>
I would hazard a guess that it's a big red herring
<samueldr>
(from my booting experience)
<samueldr>
but please follow through the thought, I could be wrong!
<samueldr>
I've been searching `resize2fs slow` kind of searches and it seems... it may be
<samueldr>
I wonder if ubuntu is simply cheating by doing it live
<gchristensen>
samueldr: yes quite likely :)
<worldofpeace>
gchristensen: I need to make #nixos match now
<gchristensen>
that said, resize2fs on a live machine from 5TB to 10TB is nearly instance
<samueldr>
I'm thinking that ext4 might be creating different kind of structures at every order of magnitudes it grows
<samueldr>
so going through one order of magnitude wouldn't be as slow as through multiple
<samueldr>
but that's backed by nothing but assumptions
* samueldr
thinks
<gchristensen>
ah
<samueldr>
it almost feels like it would be faster to copy the data, make a new filesystem, and the copy it back in
<gchristensen>
I'm making a new AMI which runs strace on the resize, so we'll see!
alp_ has joined #nixos-dev
<worldofpeace>
gchristensen: u better make sure that my successors don't remove that sparkle from the topic 😸
<gchristensen>
:D
<gchristensen>
I couldn't imagine a sparkleless topic
<abathur>
it doesn't sound useful in context and support may differ by shell, but at least when preparing to seed a bash script with `date` invocations: I use `PS4='+ $(printf "\033[0m\033[0;33m[%(%a %b %d %Y %T)T]\033[0m") '` to print a colored timestamp before each command
orivej_ has quit [Ping timeout: 268 seconds]
<gchristensen>
nice...!
<abathur>
sorry, I didn't close the thought there I guess; with xtrace
<abathur>
PS4 == xtrace prompt
<worldofpeace>
gchristensen: the next frontier is getting many sparkles and emoji in nix output 😸
<gchristensen>
:D
<gchristensen>
a tricky bit with that is I'm not sure the kernel's tty supports emojis and sparkles :/
<worldofpeace>
gchristensen: *rubs hands together, my agenda has no limits 🙈
<samueldr>
then it's the perfect time to drop that archaic thing and use another console on the framebuffer!
<samueldr>
we could do proper ttf rendering!
<samueldr>
perfect for sillyDPI devices!
<worldofpeace>
samueldr: exactly!
<worldofpeace>
it would be glorious
<qyliss>
we could also just draw emoji to the framebuffer from the kernel console
<qyliss>
how hard can it be
<samueldr>
qyliss: something something windows font rendering in the kernel flaws
<samueldr>
(which is what I assume you were alluding to)
<qyliss>
i wasn't alluding to anything
<samueldr>
oh, because font rendering in the kernel has been a big issue with Windows at a point in the past :)
<gchristensen>
you can't not specify the key, it has to have a value there
<supersandro2000>
you are wrong
<gchristensen>
okay
* gchristensen
shrugs
<supersandro2000>
if I leave out the big-parallel it works without the key
<gchristensen>
lol
<gchristensen>
yes
<supersandro2000>
oh wait... wait a second. does it use 6 then?
<supersandro2000>
for the key
<gchristensen>
because 4 is the key, 8 is 4, and big-parallel is 8
<gchristensen>
you can't skip fields
<supersandro2000>
......
<supersandro2000>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 358
<supersandro2000>
ehmry++
<{^_^}>
ehmry's karma got increased to 1
<supersandro2000>
🤦
<supersandro2000>
my evening
<gchristensen>
instead of providing ++'s, please try to be more considerate and polite, and assume people's suggestions might have value instead of coming out blazing with "you're wrong"'s -- it isn't the culture of #nixos and its community
<supersandro2000>
I am sorry
<gchristensen>
thanks, I hope to see you being more friendly, polite, helpful, and considerate :)
<gchristensen>
samueldr: the strace output is probably going to make this boot take way longer than 15 minutes, just on the blocking output
<supersandro2000>
just a bit habit when telling stories
<samueldr>
gchristensen: I assumed so
<samueldr>
gchristensen: probably want to go cook something and come back to it done heh
<gchristensen>
haha, yeah, a good idea.
<gchristensen>
you know, I am actually a bit concerned the entire log won't be present for loading in to the journal ...
<samueldr>
there's nothing you can do about that right now, but you're right it's a possibility
<gchristensen>
:)
<samueldr>
you could redirect it to /run I think
<samueldr>
IIRC it gets its mount moved
<gchristensen>
I wonder if I could use perf that early, and just print a summary out of perf on what took a long time
<samueldr>
an option to help with hands on would be dropbear in initrd
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<gchristensen>
maybe this machine will never come back
red[evilred] has joined #nixos-dev
<red[evilred]>
uh oh, did you not light the appropriate number of black candles?
<worldofpeace>
I can perform the age old ritual if needed
<worldofpeace>
starting with the chant
<worldofpeace>
plz work plz work plz work
<red[evilred]>
<3
<red[evilred]>
I knew there was (another) reason I loved you
<red[evilred]>
btw - I really enjoyed and appreciated your deliberately inclusive introduction to nixcon worldofpeace (IRC)
<red[evilred]>
brought a smile to my face
<worldofpeace>
red[evilred]: I actually asked every speaker for their pronouns if they wanted to share. (if that's what you meant, or if how the introduction was also an invitation). glad I could make u smile, my job is to make things beautiful in unique and experimental ways.
<red[evilred]>
I appreciated it
<red[evilred]>
(even though I'm the very definition of the white, british, cis, hetro, male - I love looking out for all the peeps)
<red[evilred]>
the kernel wants a word methinks ;-)
<samueldr>
gchristensen: redirecting to /run/ will help I hope
<gchristensen>
I actually don't care about the whole strace output, so maybe another trace command would be better anyway
<worldofpeace>
red[evilred]: ❤️ I'd love it if nixcon 2021 could have me again, hopefully in person
<gchristensen>
samueldr: if it was resize2fs read on /dev/urandom / /dev/random causing this block, would a trivial amount of reading /dev/random also cause that?
<samueldr>
I'm not sure
<samueldr>
but that probably sounds as plausible to me as to you