worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ | | | 20.09 RMs: worldofpeace, jonringer |
<ehmry> samueldr: I mean do a few talks and breakouts again
<gchristensen> samueldr: systemd runs it, after / is mounted
<samueldr> maybe we need an overview of what rC3 is meant to be first :)
<samueldr> gchristensen: between mount and switch_root or after switch_root?
<gchristensen> after
<samueldr> great, extremely cheaty
<samueldr> I guess we could, as long as the partition is resized
<ehmry> remote chaos communication congress. I'm not sure how its going to work
<samueldr> yeah, that much I gathered, but since you proposed nixcon2020.12, I assumed they were doing like multiple minicons??
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
<ehmry> I just mean mini december nixcon, but I'm not volunteering to organize
<samueldr> yeah, that's most likely the issue, I don't think any of the people that organized are interested in doing another one so soon :)
<gchristensen> samueldr: resizing 3G to 5T online took about 20s... I'm increasingly suspicious the problem involves randomness
<samueldr> that's possible
<samueldr> can you enable rngd in stage-1?
<gchristensen> dunno :x
<gchristensen> butwhat would resize2fs need with randomness
<samueldr> I'll take a peek at the extfs tools after replying to this e-mail
<samueldr> uuids for structures?
<gchristensen> I'll do another expand and strace
<gchristensen> no /dev/[u]random usage
<gchristensen> wow... I attached a device with a partition labeled the same a the / partition, and mount and resize2fs thought the new dis kwas my /
supersandro2000 has quit [Quit: The Lounge -]
supersandro2000 has joined #nixos-dev
halfbit has quit [Quit: WeeChat 2.9]
alp_ has quit [Ping timeout: 264 seconds]
ris has quit [Ping timeout: 240 seconds]
chrisaw has quit [Ping timeout: 240 seconds]
<gchristensen> ah ha!
<gchristensen> Ubuntu sets CONFIG_RANDOM_TRUST_CPU=y for their AWS kernel
davidtwco has quit [Read error: Connection reset by peer]
raboof has quit [Read error: Connection reset by peer]
thoughtpolice has quit [Ping timeout: 260 seconds]
dmj` has quit [Read error: Connection reset by peer]
chrisaw has joined #nixos-dev
davidtwco has joined #nixos-dev
raboof has joined #nixos-dev
thoughtpolice has joined #nixos-dev
<samueldr> >> This can also be configured at boot with "random.trust_cpu=on/off".
<samueldr> gchristensen: ^ probably preferable
<gchristensen> yeah, giving that a go
<gchristensen> thanks!
<gchristensen> looking at dmesg for related words and comparing messages + grep solves so many things
<samueldr> whenever I encounter a kernel config I don't know, cateee is the place I go first
<gchristensen> oh cool
<samueldr> the data is indexed with versioning
dmj` has joined #nixos-dev
<samueldr> and if it's defined multiple times (e.g. once per arch) they're shown that way
<gchristensen> might be worth comparing the ubuntu aws kernel config to their default config and see if we should crib some defaults
<samueldr> do we want to maintain diverging kernel configurations?
<samueldr> but yes if it's universal enough
<gchristensen> probably not, but some of those options might happily become kernel config options like random.trust_cpu
<samueldr> and that's a real question
<samueldr> yeah
<gchristensen> but also, maybe we do
<samueldr> I think we do, but we can't at the maintainer scale we are at
<gchristensen> yeah
<gchristensen> agreed
<samueldr> we'd have to have maintainers on a pay roll [any pay roll] doing that
<samueldr> where their day job is maintaining cloud images, and only that
<gchristensen> tell me about it
* gchristensen looks at the 6mo old request from packet to update support
<samueldr> what's a missed version release?
<gchristensen> or 2
<samueldr> :x
<gchristensen> part of that was their fault
<gchristensen> but yeah
<gchristensen> it is hard to test images on a dozen types of hardware, when each image is unique to the hardware and each test takes ~1h and a given hardware name might have subtle differences across actual sleds of hardware
<samueldr> *and* you can't touch it at all
<gchristensen> yup
<samueldr> not that it really helps most of the time
<gchristensen> and it was slow to roll out updated installers, so the pressure was extremely high to deliver as-good-as-possible images from the start
<gchristensen> booted at :11, ...aaand whoops my new AMI didn't have the kernel option set.
<samueldr> oh
<gchristensen> turns out you can't just put kernel parameters into the list of kernel modules.
<samueldr> ugh, and it's not an error because it's lenient for compatibility across different kernel versions
<samueldr> successfully square peg in a round hole there
<gchristensen> :)
<gchristensen> well, I'll start the AMI upload and test it tomorrow. I don't want to be up another 30min.
<samueldr> 30 minutes test cycle? ew
<gchristensen> 2 minutse to build the AMI, uploading the 1.4GiB AMI at 2.5MiB/s upload rate + about 10-15 minutes for AWS to "import" it + 30s to 15 minutes boot time
<samueldr> that's what I figured, minus the import
<gchristensen> :) good night! let's see what this gets us in the morning
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
zarel has quit [Ping timeout: 256 seconds]
maljub01 has quit [Ping timeout: 256 seconds]
maljub01 has joined #nixos-dev
zarel has joined #nixos-dev
maljub01 has quit [Client Quit]
maljub01 has joined #nixos-dev
ashkitten has quit [Quit: WeeChat 2.9]
ashkitten has joined #nixos-dev
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-dev
stoile has quit [Ping timeout: 260 seconds]
maljub017 has joined #nixos-dev
maljub01 has quit [Ping timeout: 260 seconds]
maljub017 is now known as maljub01
supersandro2000 has quit [Quit: The Lounge -]
supersandro2000 has joined #nixos-dev
red[evilred] has joined #nixos-dev
<red[evilred]> Good luck gchristensen (IRC)
cole-h has quit [Ping timeout: 265 seconds]
stoile has joined #nixos-dev
jonringer has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
nschoe has quit [Quit: - Chat comfortably. Anywhere.]
alp_ has joined #nixos-dev
<siraben> Does wrapCCWith accept `enableParallelBuilding = true;`?
<siraben> looks like no, sadly
* siraben waits for gcc to cross-compile
supersandro2000 has quit [Quit: The Lounge -]
supersandro2000 has joined #nixos-dev
saschagrunert has joined #nixos-dev
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
alp_ has quit [Remote host closed the connection]
alp_ has joined #nixos-dev
justanotheruser has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 268 seconds]
kalbasit has quit [Ping timeout: 268 seconds]
luc65r has joined #nixos-dev
<{^_^}> firing: RootPartitionLowDiskSpace:
<{^_^}> resolved: RootPartitionLowDiskSpace:
<gchristensen> [Fri Oct 30 10:10:59 UTC 2020] resize2fs 1.45.5 (07-Jan-2020)
<gchristensen> [Fri Oct 30 10:22:32 UTC 2020] Resizing the filesystem on /dev/disk/by-label/nixos to 1310719483 (4k) blocks.
<gchristensen> whatever happens between the version and the what it is gonna do ... takes 12 minutes.
<gchristensen> unless that is buffered
orivej has joined #nixos-dev
risson has quit [Excess Flood]
risson has joined #nixos-dev
vdemeester has quit [Ping timeout: 272 seconds]
sdier has quit [Ping timeout: 272 seconds]
vdemeester has joined #nixos-dev
sdier has joined #nixos-dev
teto has joined #nixos-dev
teto1 has joined #nixos-dev
<Mic92> gchristensen: ah. That explains it.
<Mic92> So it needs to copy more data between userspace and kernel.
<gchristensen> 30s -> 15m worth of extra data seems like an extreme increase for that
<gchristensen> I think maybe we should delay resize2fs on ext4 volumes to when they're mounted, just for this
<Mic92> gchristensen: yeah. maybe the userspace implementation has some other problems as well.
<Mic92> Copying should not take that long
<Mic92> Especially when doing block i/o stuff it usually is quite fast
<gchristensen> yea
<Mic92> Maybe userspace chooses its buffer too small?
<Mic92> For networking zero-copy is more important
<supersandro2000> Mic92: you wanted me to remind you of
<{^_^}> Mic92/nixpkgs-review#142 (by SuperSandro2000, 1 day ago, open): Add platform run on to report
<Mic92> supersandro2000: Thanks. I will take this to the weekend. This evening I am on Nix Friday, which I prepared this morning
<gchristensen> I'm running resize2fs with -d62 to get timing information from the offline resize to see if there is something obvious
<supersandro2000> Mic92: I will remind you again in a few days.
<Mic92> gchristensen: are you aware of off-cpu- flamegraphs?
<gchristensen> yeah, but I haven't tried too hard to implement it since it is so early in boot. samueld\r mentioned it'd probably be easy to save the data but I wasn't feeling up to figuring that out yesterday. I can try that today
<Mic92> bcc has this very nice tool called offcputime, which can be fed into brendan greggs flamegraphs.
<Mic92> ok
<gchristensen> strace on resize2fs in stage1 going to the console was a bad idea though :)
<Mic92> yeah, maybe log to tmpfs
__monty__ has joined #nixos-dev
<gchristensen> the test cycle is a punishing 30min, so not keen on doing things which have tricky bits
<Mic92> gchristensen: it is not reproducible locally?
<gchristensen> I didn't think to try. It only happens during early boot, and up until now I was still thinking maybe some kernel + hypervisor things were getting in the way.
<gchristensen> next :)
<gchristensen> (good thing I have a system nearby with 5T free ... )
<Mic92> So doing non-online resize in a later boot stage is faster?
<gchristensen> yup
<gchristensen> iirc. let me double check.
<Mic92> Really weird. From a kernel perspective, once you start calling init, it's already quite late from a kernel perspective.
<gchristensen> yeah, that and a nearby "crng init done" message is what took me down the rng road
<gchristensen> but that doesn't appear to be related
<Mic92> I still see the non-online vs online resizement as the biggest difference. Once the kernel initialized virtio-blk it should work the same the whole time.
<gchristensen> [Fri Oct 30 11:21:09 UTC 2020] adjust_superblock: Memory used: 396k/4556k (295k/102k), time: 654.21/ 0.59/ 5.13
alp_ has quit [Ping timeout: 264 seconds]
zimbatm has quit [Quit: - Chat comfortably. Anywhere.]
zimbatm has joined #nixos-dev
alp_ has joined #nixos-dev
<Mic92> gchristensen: things I miss in nixos-rebuild: nixos-rebuild kexec and nixos-rebuild boot-once
<Mic92> using systemctl kexec and bootctl set-oneshot
<gchristensen> oh gosh me too
<gchristensen> confirmed: time resize2fs -d 62 /dev/xvdf2 (xvdf2 is a 5T disk from the exact same snapshot which took 12 minutes to expand) took 37s when the system is fulling running, but xvdf2 is unmounted
orivej has quit [Ping timeout: 240 seconds]
<gchristensen> logs from the journal, and the offline resize run after the system was booted
bgamari has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-dev
FRidh has quit [Remote host closed the connection]
bgamari has joined #nixos-dev
<gchristensen> I *think* I figured it out ...
alp_ has quit [Ping timeout: 268 seconds]
<gchristensen> ^ when I said that I started resizing an ext4 filesystem from 3G to 3T, and it is still running, so I think I figured it out
alp_ has joined #nixos-dev
<delroth> could someone cherry-pick to 20.09?
<{^_^}> #102127 (by delroth, 10 hours ago, merged): fix Qt version pinning
<delroth> it's harmless and we had bug reports from the release
<gchristensen> delroth: can you do the cherrypick / PR? (git cherry-pick -x ...)
<delroth> gchristensen: not immediately, sorry (on my work laptop right now). do you strongly prefer a PR for cherry-picks in general? (I'm assuming so it goes through CI)
<gchristensen> yeah
<delroth> opening two PRs is kind of annoying and time consuming
<delroth> I really wish ofborg had an option for simple stuff like this to run tests against master + 20.09
<delroth> (and maybe automate the cherry-pick! :P)
<gchristensen> me too
<delroth> maybe one day I'll figure out how to do a local ofborg setup and see how hard that would be to implement.
<Mic92> gchristensen: so the issue is that it tries to zero everything manually?
<gchristensen> Mic92: as far as I can see, it initializes the entire inode table if the ext4 kernel module isn't loaded
costrouc has joined #nixos-dev
<Mic92> gchristensen: but the inode table should not increase if you are not adding inodes, no? Is it not rather that it uses efficient block discard if ext4 is loaded rather than writing zeros to disk?
<gchristensen> not sure
* gchristensen splunks
<Mic92> this allocates zero bytes
<Mic92> *writes zero bytes
<Mic92> anyway modprobing ext4 should be an easy fix.
<gchristensen> yeah, testing that now
<gchristensen> (I mean, I did test it locally and it fixed it. checking it in an AMI now)
justanotheruser has joined #nixos-dev
alp_ has quit [Ping timeout: 264 seconds]
alp_ has joined #nixos-dev
<gchristensen> resize started: DATEMARK: Fri Oct 30 14:59:58 UTC 2020, resize finished: DATEMARK: Fri Oct 30 15:00:55 UTC 2020
saschagrunert has quit [Quit: Leaving]
cole-h has joined #nixos-dev
justanotheruser has quit [Ping timeout: 268 seconds]
justanotheruser has joined #nixos-dev
jonringer has joined #nixos-dev
<cole-h> gchristensen: "zfs create -V 3G rpool/scratch/ext4" and "mkfs.ext4 /dev/zvol/rpool/scratch/ext4"...
<cole-h> Wait that's illegal
<gchristensen> lol
<gchristensen> I also have zvols for windows and macos ...
<cole-h> I can't swear at you for that -- I do have a Windows zvol for my VM :P
<gchristensen> hehe
<gchristensen> samueldr, clever: can both of you review ?
<{^_^}> #102174 (by grahamc, 33 minutes ago, open): AMI root partition table: use GPT to support >2T partitions
<gchristensen> launched: 13:09, ready: 13:11... not as fast as Amazon Linux, but a good start
<gchristensen> probably moving to a systemd init would get us closer
alp_ has quit [Ping timeout: 264 seconds]
alp_ has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-dev
<ajs124> is there any documentation/policy on how to properly remove a package from nixpkgs? e.g. if and when a throw should be added to aliases.nix
<supersandro2000> generally when it was in for a bit of time and people might actually use it
<supersandro2000> if you added it last week to master and now rename or remove it, it should be fine
<samueldr> ajs124: do you hate your users?
<samueldr> ajs124: if so just remove the attribute and don't speak about it :)
<samueldr> ajs124: otherwise add a throw stating quickly why it was removed and maybe a path forward
<samueldr> e.g. another tool _actually_ replaces it
<ajs124> samueldr: the software basically cannot have worked since 2017
<samueldr> if you know that our packaging of it is broken for long, then doing it without a throw is good, IF you state the why clearly enough in the commit message
<ajs124> it's not that out package is broken, it still builds fine. it's just that the software can't work, because… ok, so the specific case here is skype call recorder. it talked to the old native skype linux client. that client cannot connect to the skype network anymore and hasn't been able to for a long time. so you can still install the software, it just doesn't do anything.
<samueldr> haha, then acceptable too I figure
<ajs124> so the policy is "use your best judgement"? ^^
<samueldr> it is, but really, think about the children^W users first
<samueldr> breaking a config without a message is terrible, for things that are expected to be in use some
<ajs124> yeah. I guess I'll add one, just in case
<samueldr> though in your specific case, yes, you're back to using judgement :)
<cole-h> If you add a throw, please, please, please put the attr in the message
<ajs124> the other reason I'm asking is, because aliases seems to not have any kind of deprecation policy
<samueldr> it really can go either way
<samueldr> that is true, and not great either
<samueldr> but not terrible still
orivej has joined #nixos-dev
alp_ has quit [Ping timeout: 240 seconds]
alp_ has joined #nixos-dev
teto1 has quit [Quit: WeeChat 2.9]
alp_ has quit [Ping timeout: 264 seconds]
<gchristensen> samueldr: I was also surprised that parted was outputting 1049kb and considered the partitions aligned
<samueldr> :/
ris has joined #nixos-dev
<gchristensen> samueldr: I don't want to merge that until you're happy about it
<gchristensen> b/c I'm not going to pretend I'm competent there
<samueldr> I mean, if parted says it's 1049KB, maybe add [sic] after it :)
<samueldr> even using `1049kB` exactly as parted says
<cole-h> Or even "(yes, 1049K)"
<samueldr> sic: used in brackets after a copied or quoted word that appears odd or erroneous to show that the word is quoted exactly as it stands in the original
<gchristensen> it sounds like you're comfortable with the value, and not feeling like we should look in to that weirdness further?
<samueldr> I really assumed you typo'd 1048
<samueldr> 9 and 8 are so close together
<gchristensen> yeah I know, but since I didn't -- should we look closer at what is happening?
<samueldr> let me try
<gchristensen> to be honest I'm surprised we're not looking at 4k blocks or something here
<gchristensen> "To an operating system installed on an EC2 instance, an attached EBS volume appears to be a physical hard disk drive containing 512-byte disk sectors."
<samueldr> this is all a really leaky abstraction AFAIUI
<gchristensen> yeah
<samueldr> I usually use sfdisk
<samueldr> I think parted is just weird in how it prints its things
<gchristensen> O.o huh
<samueldr> I don't know how to make sense of what parted does, seeing what sfdisk says
<gchristensen> indeed. ... is this an OBO?
<samueldr> so I would use 1MiB, 2048 long partition as its description, and disregard the weirdness that parted uses for its units in the output
<samueldr> 2048 sectors*
<samueldr> parted does the right thing, but prints something that is surprising here
<gchristensen> - # For "legacy+gpt", the GPT partition table is used, a 1049K no-fs partition for
<gchristensen> + # For "legacy+gpt", the GPT partition table is used, a 1MiB no-fs partition for
<gchristensen> lgty?
<samueldr> sure
<samueldr> we know it is 2048 sectors; parted is just being weird imo
<gchristensen> yeah
<gchristensen> I pushed an updated set of commits
<supersandro2000> I wrote a quick and dirty function around nix-build which hightlights if a package build has no python tests, but pytest was run anyway
<supersandro2000> theoretically you can highlight anything with that
<supersandro2000> hopefully someone finds this useful
<gchristensen> neat!
<supersandro2000> and if Mic thinks this is a great idea I would like to integrate that into nixpkgs-review
<gchristensen> samueldr: mind issuing a second review?
alp_ has joined #nixos-dev
<gchristensen> these will be some nice PRs to merge and backport. I like being able to boot machines in a nice amount of time
<samueldr> I'm surprised no one noticed before
<gchristensen> the MBR issue: someone else did mention it :) and the resize issue: probably not a lot of people spinning up machines with 5T root disks
<samueldr> still, I would assume it took some host minutes on smaller drives too?
<samueldr> some hot minutes*
<gchristensen> yeah
<gchristensen> but 12min for 5000GB... 100g worth of slowness is maybe just "thats weird... where's the coffee?" time
<gchristensen> the thing that actually made me look in to it was resize2fs took 9 hours
<eyJhb> I.. I really want to place the damn -unstable in a way that makes sense. And there is no standard on this...
<eyJhb> I am a sad panda atm.
<samueldr> gchristensen: hours?
<samueldr> eyJhb: I *really* think that it should be neither in version or pname, though, which is a conundrum!
<gchristensen> samueldr: yes
<samueldr> hmmmm
<samueldr> some kind of variant suffix?
<samueldr> meta.variant = "unstable"; or even for e.g. chrome meta.variant = "beta" and meta.variant = "dev"
<eyJhb> For now, I will put it into version, as -unstable :| Who wants to create a RFC for this?! :p
<samueldr> eyJhb: version as unstable-xx-yy-zz you mean?
<gchristensen> does the version number need to be last in the string for nix-env to consider it an upgarde?
<samueldr> yes
<eyJhb> samueldr: as "yyyy-mm-dd-unstable"
<eyJhb> Fuck
<eyJhb> THen I guess the other way around!
* samueldr opens the manual to double-check
<eyJhb> I just wanted to give you guys among-sus :(
<samueldr> >> If a package is not a release but a commit from a repository, then the version part of the name must be the date of that (fetched) commit. The date must be in "YYYY-MM-DD" format. Also append "unstable" to the name - e.g., "pkgname-unstable-2014-09-23".
<samueldr> the main gist of it is: unstable has to be between the "useful pname" and the "useful version"
<eyJhb> samueldr: so it goes into the name? among-sus-unstable ?
<worldofpeace> lol, this is the most debated section of the manual ever
<supersandro2000> can't we fail a build if the unstable is at the wrong end?
<samueldr> according the what is written currently in the manual
<eyJhb> I was about to ping you worldofpeace , help
<worldofpeace> I can find the thread about it
<samueldr> but yes, as I said previously, I believe already it should be in neither
<gchristensen> clever: I don't suppose you're 'round?
<eyJhb> worldofpeace: I have found them all
<{^_^}> #68531 (by jtojnar, 1 year ago, closed): Incorrect packages names or versions according to repology
<{^_^}> #68518 (by jtojnar, 1 year ago, open): unstable part of version instead of pname
<worldofpeace> eyJhb: yeah, that last one is where it's at
<eyJhb> Yes, but then it should be prepended to version?
<gchristensen> worldofpeace: for #102176 do you mind one backport PR for the whole group?
<{^_^}> (by grahamc, 2 hours ago, open): NixOS AMI Boot Time and Disk Improvements
<worldofpeace> eyJhb: no, unstable belongs in `name`
<worldofpeace> lol
<worldofpeace> `pname`
<eyJhb> I. Want. To. Die.
<worldofpeace> the rational is parseDrvName is going to put it into name anyways
<worldofpeace> eyJhb: the issue is about fixing it to be as I just described
<worldofpeace> the issue title is misleading
<eyJhb> worldofpeace: Tell me what to do, should I just do `among-sus-unstable` in pname?
<worldofpeace> eyJhb: yes
<eyJhb> worldofpeace++ :(
<{^_^}> worldofpeace's karma got increased to 253
<worldofpeace> gchristensen: One backport PR would be best. that way it can all be tested together?
<aranea> just three more increments and your karma will wrap around to 0!
<worldofpeace> I usually never bother with multiple backport PRs if they're all related
<gchristensen> cool, yep, I just made a branch picking everything and am building a test AMI now!
<worldofpeace> aranea: I need to change the bot to do 1's too 😸
<worldofpeace> sparkle support was a moment too
<worldofpeace> ✨ gchristensen
<{^_^}> gchristensen's karma got increased to 360
<gchristensen> I like it when I can ctrl-z nix-build's and come back to it and they made significant progress
<worldofpeace> infinisil: would u hate if I added code to to somehow match my nickname to always give me 1's at the end 😸
<infinisil> worldofpeace: Hehe, like `worldofpeace111's karma got increased to N`?
<worldofpeace> infinisil: so like worldofpeace's karma got increased to N.(some random string of repeating one's)
<eyJhb> If anyone wants to end my suffering, then here -
<{^_^}> #101384 (by eyJhb, 1 week ago, open): among-sus: init at 2020-10-22
<infinisil> worldofpeace: Hmmm, I kind of don't want to special-case on nicks. I wouldn't mind this as a random karma flavor for everybody though :)
<worldofpeace> eyJhb: lol, it makes me want to make a bug to have a configuration for port instead of hardcoding it
<worldofpeace> infinisil: sounds okay to me then for everyone to have a random flavor with 1's
<__monty__> Can't you do pname = "blah"; version = "YYYY-MM-DD"; name = "${pname}-unstable-${version}";?
<eyJhb> worldofpeace: Don't. You. Dare. Also, how would you go about doing it?
<worldofpeace> __monty__: that doesn't really make much sense? like we expect name to equal pname-version in the case that those attributes exist
<etu> Well, the port is hardcoded in the code
<worldofpeace> there actually used to be some sort of code in mkDerivation to disallow that
<worldofpeace> eyJhb: like have some sort of .ini configuration
<etu> They don't seem to have any flag or so for the port number... 🤷
<worldofpeace> yeah, and also a flag on command line would be nice
<worldofpeace> I can open these reports. I typically make it to open source games because this comes up very frequently
<etu> ✨ worldofpeace
<{^_^}> worldofpeace's karma got increased to 255, it's a crit!
<eyJhb> 255 :o Gz
<eyJhb> worldofpeace: Ahh, thought you were going to delay my PR!
<etu> Not overflowing just yet!
<worldofpeace> soon, soon 😸
<worldofpeace> eyJhb: I would never do that to anyone
<eyJhb> You are a nice person, I believe that.
<eyJhb> Now I somehow want to make a fetchFromSourceHut thingy
<worldofpeace> I'd recommend that we should try to make x and x better by requesting to upstream, but if it's really minor it can be handled outside of adding the package. only if it's a really big problem for adding a new package to nixpkgs, meaning it's not a great port, I'd hold up the thread
<gchristensen> eyJhb: lol.
<etu> eyJhb: One could... have a fetchFromSrHt that is just a wrapper for fetchgit until it's fixed
<eyJhb> True
<eyJhb> *sigh* when will I have time, just to play with Nix all the time
<eyJhb> Hell, a lot of our fetch do not support submodules
<drakonis> is there a nickel irc channel yet?
<gchristensen> nickel is just an experimental tweag thing, isn't it?
<drakonis> currently i suppose
<worldofpeace> eyJhb: merged
<worldofpeace> opening issues, but I have to make an account
<eyJhb> Did you change your display name or something worldofpeace ? And thanks! :D
<drakonis> maybe a bit too soon to want it?
<worldofpeace> eyJhb: did I?
<eyJhb> Thought it was all caps/lowercase
<worldofpeace> oh, since a while ago I now do it stylized
<worldofpeace> because I keep cute and stylish
<eyJhb> Also.. Is it just me, or does it seem weird that 3 out of 4 services matches the same sha256, but the fourth does not?
<eyJhb> Moving to nixos-chat
<eyJhb> Or maybe not... the newest comment -
<eyJhb> It would be ideal for something to match the sha256 over all distributions
<worldofpeace> eyJhb: hmm, I'm not seeing an issue tracker for this software?
<eyJhb> I have no clue how to get there from But just knew it was .todo
<eyJhb> ALso, I should have said, you do not need to create a user. You can do email stuff!
<eyJhb> Also, not to brag. But our package is newer than AURs
<eyJhb> Yay!
<eyJhb> Also sad that srht broke your style worldofpeace </3
aristid has quit [Ping timeout: 260 seconds]
<worldofpeace> eyJhb: I guess sourcehut isn't fab enough for it. I kinda struggled navigating
aristid has joined #nixos-dev
<eyJhb> worldofpeace: I do that as well...
teozkr_ has quit [Ping timeout: 240 seconds]
<eyJhb> Still annoyed about not producing the same hash
teozkr_ has joined #nixos-dev
alp_ has quit [Ping timeout: 268 seconds]
<clever> gchristensen: i am now
<samueldr> clever: if you want to take a peek post-merge
<{^_^}> #102174 (by grahamc, 5 hours ago, merged): AMI root partition table: use GPT to support >2T partitions
* clever looks
<clever> samueldr: looks good
<samueldr> gchristensen: ^
<gchristensen> yay :)
<gchristensen> thank you, both
<gchristensen> clever: provisioning with a 5T root disk takes less than 1 minute on a t3.large now
<clever> gchristensen: ive also been thinking, the resize doesnt need to block the boot
<samueldr> I'm thinking the off-by-one is basically that maths thing with sets and [0-10[ and [0-10]
<clever> i have done online resize of ext4 without a reboot
<gchristensen> yeah I know but that seemed like a much scarier change to make to 20.09.
<samueldr> clever: one step at a time
<clever> so you could potentially do the resize after boot, via a systemd service
<gchristensen> cloud-init for example doesn't, they do it after startup
<clever> yeah, thats a change for another pr
<clever> of note, the partition resize can potentially need a reboot, so doing it in the initrd is a good idea
<clever> but expanding the fs itself, doesnt need a reboot, and can be done online
<samueldr> maybe sfdisk uses [0-2048[ and parted uses [1-1049] or something like that
<clever> so that half, could be done via systemd, in parallel to other tasks
MichaelRaskin has joined #nixos-dev
ehmry has quit [Read error: Connection reset by peer]
ehmry has joined #nixos-dev
alp_ has joined #nixos-dev
<gchristensen> so ... if you make an AMI or disk image from a dirty copy of nixpkgs, the dirty copy makes it in to the disk image
<gchristensen> a concrete example of this is if you edit, say, the "make an ami" script to include some tweaks and your creds ... that file with your creds ends up in the AMI:
<gchristensen> this very well might be a "duh" but it surprised me a bit. I wonder if there is a way to safen this up, or something
<gchristensen> it also included files not committed or staged in any way
<clever> i think all of the installer iso's also do that
<roberth> gchristensen: I don't think we can prevent people from putting creds in scripts, but we can write our scripts to load secrets from dotfiles for example
<roberth> flakes approach of only adding staged-ish files prevent this either
<gchristensen> yeao
<roberth> don't prevent I mean XD
<supersandro2000> If I am reviewing PRs quickly after they are being created I often get strange build errors which I can never reproduce
<supersandro2000> Do I need to turn down some TTLs?
<gchristensen> aminechikhaoui: can we regenerate AMIs after hits a channel?
<{^_^}> #102182 (by grahamc, 2 hours ago, merged): [20.09] Backport AMI Boot Time and Disk Improvements
__monty__ has quit [Quit: leaving]
luc65r has quit [Quit: WeeChat 2.9]
bgamari_ has joined #nixos-dev
bgamari has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 258 seconds]