gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.03 release managers: fpletz and vcunat | https://logs.nix.samueldr.com/nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
mbrgm has quit [Ping timeout: 256 seconds]
mbrgm has joined #nixos-dev
<angerman> LnL: yea it actually was. I had packageOverrides, that added `haskell.x`; and apparently haskell.packageOverrides is required.
orivej has quit [Ping timeout: 240 seconds]
WilliButz has quit [Ping timeout: 240 seconds]
WilliButz has joined #nixos-dev
__Sander__ has joined #nixos-dev
<LnL> angerman: that makes sense since haskell uses it's own fixpoint separate from the toplevel layers
MichaelRaskin has quit [Quit: MichaelRaskin]
vcunat has joined #nixos-dev
Synthetica has joined #nixos-dev
<timokau[m]> glnaces
<timokau[m]> Sorry, mistook the chat window for a terminal and can't even type glances
ckauhaus has joined #nixos-dev
orivej has joined #nixos-dev
zybell has quit [Read error: Connection reset by peer]
zybell_ has joined #nixos-dev
pie__ has quit [Ping timeout: 260 seconds]
<srhb> When are Hydra's gc roots removed (if ever) when I disable a jobset?
pie__ has joined #nixos-dev
<vcunat> srhb: I assumed that "disabling" only means to stop checking for source updates
<vcunat> but I don't really know
srhb has quit [Quit: Quit]
<vcunat> (oops, left the room apparently)
pie__ has quit [Ping timeout: 276 seconds]
srhb has joined #nixos-dev
srhb has left #nixos-dev ["WeeChat 2.0"]
srhb has joined #nixos-dev
srhb has quit [Read error: Connection reset by peer]
srhb has joined #nixos-dev
srhb has quit [Client Quit]
srhb has joined #nixos-dev
NinjaTrappeur has quit [Quit: WeeChat 2.1]
NinjaTrappeur has joined #nixos-dev
jtojnar has quit [Ping timeout: 268 seconds]
NinjaTrappeur has quit [Quit: WeeChat 2.1]
NinjaTrappeur has joined #nixos-dev
jtojnar has joined #nixos-dev
ckauhaus has quit [Quit: Leaving.]
zybell_ has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 268 seconds]
zybell_ has joined #nixos-dev
<manveru> one more upgrade to ruby versions for security reasons: https://github.com/NixOS/nixpkgs/pull/39928 (pinging zimbatm)
NinjaTrappeur has quit [Quit: WeeChat 2.1]
NinjaTrappeur has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
<niksnut> aszlig: do you remember what the "NixOS aszlig" GCP API key is used for?
<aszlig> niksnut: GCP?
<niksnut> Google Cloud Platform
<aszlig> uh...
<niksnut> I got an email from google about pricing changes
<niksnut> that will cause the cost to exceed to free tier limit
<aszlig> no idea... maybe it's because of the chromium api key
__Sander__ has quit [Quit: Konversation terminated!]
<niksnut> I see ~700000 API requests in the last month
<aszlig> oh...
<aszlig> okay...
<aszlig> then they renamed it to GCP or integrated it into that
<aszlig> so it's basically for chromium in nixpkgs
<aszlig> and it seems that we have exceeded our limits
<niksnut> actually the email was about the "Google Maps Platform"
<aszlig> sec...
<niksnut> I see requests in the Safe Browsing API, Chrome Spelling API, Geolocation API and Speech API
<niksnut> probably Geolocation is part of the Google Maps Platform
orivej has joined #nixos-dev
<aszlig> seems so
<niksnut> aszlig: yeah the "NixOS aszlig" account corresponds to the API key in nixpkgs
<aszlig> yeah, "Google Maps Geolocation API"
<aszlig> hm, lemme write an email to them...
<niksnut> I can forward the email to you
<niksnut> uhm what's your address nowadays?
<aszlig> aszlig@nix.build
<copumpkin> niksnut: can you explain a bit more of what's going on with that "claims to be content-addressed but isn't" work? It's not clear to me whether your new commits that reference the issue are going to make the error go away
<niksnut> the last commit makes it go away by not making the path claim to be content-addressed
<copumpkin> oh, cool
<niksnut> so you lose the ability to fetch the path from a binary cache without a trusted signature
<copumpkin> even if I set require-sigs to false?
<niksnut> no
<copumpkin> cool, thanks :)
<aszlig> niksnut: mail sent and CCed you
<vcunat> huh, I suppose this can be explained without money
<vcunat> Surely they don't charge other distros.
<vcunat> Of course, with keys posted publicly, I can't see what they're for, but neither I can see a way around it.
<niksnut> aszlig: thanks
<niksnut> I don't understand the point of those API keys either
<vcunat> I understand it for cases where the keys don't need to be public.
<vcunat> One of the points is to make money from heavy users while still providing low-rate service for free.
<vcunat> (releatively common business model)
<copumpkin> hm, would you expect growpart to call fsck? noticing an fsck slowing down my EC2 image boots quite significantly
<copumpkin> looks like mountFS always calls checkFS
<copumpkin> why do we want to fsck automatically at startup?
<copumpkin> this is probably why NixOS has always taken far longer to boot than any of my other EC2 AMIs :P
<aszlig> niksnut: oh, the same key is also used for firefox...
<vcunat> copumpkin: it seems standard to fsck before resizing a partition
<vcunat> presumably because it's generally not a safe operation on a damaged FS
<copumpkin> I might make that optional
<copumpkin> this is a disk image booting for the first time
<copumpkin> doesn't seem necessary to do that on a fresh image
<copumpkin> vcunat: also, the checkFS call is outside of the resize call
<copumpkin> so we call checkFS, then if autoresize, we then call e2fsck and then resize2fs
<copumpkin> which seems like overkill
<copumpkin> trying to understand what the thinking was
<copumpkin> I'm not misunderstanding, right? all FS's get fsck'd, and if you autoresize you get fsck'd again
<vcunat> I don't know if resize2fs does that.
<copumpkin> how do you mean? I'm just talking about the e2fsck right before it
<vcunat> I see now.
<vcunat> (just before you wrote)
<vcunat> that one depends on checkJournalingFS, strictly speaking
Lisanna has joined #nixos-dev
<vcunat> and # Don't run `fsck' if the machine is on battery power. :-)
<copumpkin> oh, so checkFS might do nothing
<niksnut> I seem to remember that e2fsck was mandatory after a resize, but maybe that's no longer the case
<copumpkin> but in some cases, you might still get fsck'd twice
<copumpkin> niksnut: I think it is before a resize, but on a fresh image
<copumpkin> we pre-run fsck in the image builder (unless you changed that)
<copumpkin> so it's still pristine
<niksnut> yes it's supposed to be clean
<vcunat> maybe add a knob disabling this fsck and auto-turn it for clean images
<niksnut> well, maybe we need to set the check interval / period to 0
<copumpkin> so I might make that resize fsck optional and skip it on images
<copumpkin> yeah
<niksnut> tune2fs -i0 -c0
<copumpkin> also, we seem to have logic for growpart, and more logic for this: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1-init.sh#L301-L312
<niksnut> auto-fsck is a bad idea anyways nowadays
<copumpkin> two different resizers?
peti has quit [Ping timeout: 240 seconds]
lassulus has quit [Ping timeout: 240 seconds]
peti has joined #nixos-dev
lassulus has joined #nixos-dev
<Dezgeg> e2fsck with -a should be a no-op if the disk is clean
<Dezgeg> also there is a third ad-hoc part resizer in sd-image.nix :) never I have never heard of needing to run e2fsck with that...
<clever> Dezgeg: i think that one runs once, and the nix build pre-fsck's it
<Dezgeg> which one?
vcunat has quit [Ping timeout: 255 seconds]
<clever> the sd-image one
<Dezgeg> well I wrote that, so I'm really surprised if it does
<clever> i might be thinking of something else
ckauhaus has joined #nixos-dev
MichaelRaskin has joined #nixos-dev
<copumpkin> I think we need a fourth resizer
<copumpkin> to really be sure that the disk is the right size
drakonis has joined #nixos-dev
<copumpkin> niksnut: when are you planning 2.0.2? that content-addressable error has been hitting me quite a bit
<copumpkin> oddly enough it seems to go away, but then comes back
<copumpkin> not entirely clear what's going on
<copumpkin> probably has something to do with the state of the db
<niksnut> copumpkin: I can do it any time, only takes a few minutes
<copumpkin> ooh
<drakonis> is there any example nixos plugin code?
<copumpkin> well, if you feel like it, I wouldn't object to a 2.0.2 without the content-addressable failure :) but I'm also back on 2.0 so not a huge rush for me personally
<drakonis> nix plugins that is
<copumpkin> not sure if others have other needs out of a new release
<drakonis> or is it currently just "nix knows how to run plugins" but nothing was done yet
<copumpkin> shlevy has a bunch somewhere
<copumpkin> probably on his github
<drakonis> i'm looking to fiddle with it to produce a prototype of a command to import packages from repos
<drakonis> write the scaffolding for the import command
<drakonis> a relevant question, is there an up to date nix and nixos spec that's not based on eelco's thesis?
<MichaelRaskin> What's spec? I mean, Nix manual is quite good
<drakonis> a spec as in the specification for nix itself
<drakonis> so it can be implemented in other languages
<MichaelRaskin> I think there is nothing better than the manual
<MichaelRaskin> (which does work as a reference manual)
<MichaelRaskin> Then of course there are some omissions…
<drakonis> i mean, this is a thing https://nixos.org/~eelco/pubs/phd-thesis.pdf
<drakonis> the original spec
<drakonis> it counts as one at leat
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
<Sonarpulse> gchristensen: 77161de4546697f9bf2da6d081eeba4c399b3313 I purposely put 1 sentance per line
<Sonarpulse> so we get reasonable diffs in PRs
<Sonarpulse> for docs
<Sonarpulse> I feel like that is a more stable normal form than <=X charcter lines
<Dezgeg> I also like one sentence / line in e.g. tex files
<Dezgeg> copumpkin: why do you need a new resizer for "to really be sure that the disk is the right size"? can't you always assume resizing the last partition on the disk to fit rest of the disk is the right strategy
ckauhaus has quit [Quit: Leaving.]
<copumpkin> I just don't think three resizers is really enough
<copumpkin> 4, maybe 5
<Sonarpulse> Dezgeg: the rest of gchristensen's indentation changes were very good
<copumpkin> that's what it takes to be properly resized
<Sonarpulse> maybe let's just do 1 sentance/line after
<Dezgeg> heh
<Sonarpulse> to be clear that commit is merged
<Sonarpulse> so i mean do that not by reverting
<Dezgeg> I do agree having less disk resizers is good
<Sonarpulse> (only a few lines were by my anyways)
<copumpkin> :)
<Dezgeg> IIRC grow-parts (or some of those) wants to reboot the machine though instead of doing it live?
<copumpkin> does it? not sure
<copumpkin> I thought it was used in most "cloud" VM images to resize at startup
<copumpkin> so if it required a reboot that wouldn't be great
<Dezgeg> hmm
<Dezgeg> maybe it only works if the partition is not mounted, or something... I think I had some reason to do the custom thing
<clever> ive also noticed that the ec2 tools for resizing a part are horribly packed in nix
<clever> it symlinks some of its deps to $out/bin/
<clever> but makes no attempt to put them in PATH for the script
<clever> so it only works if you install the whole derivation, and fails if you nix-build && ./result/bin/growpart
<Dezgeg> maybe that was it, it was hard to run in initrd context or something, and refused to run on a mounted filesystem
<clever> from the initrd, the program and all of its $out/bin symlinks get packaged up, so it just works
jtojnar has quit [Remote host closed the connection]
drakonis has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
<srhb> Channel blocker early warning: https://github.com/NixOS/nixpkgs/issues/39946
<clever> obj-$(CONFIG_CRYPTO_CRC32C_INTEL) += crc32c-intel.o
<clever> srhb: the kernel module in question is made from that .o file
<clever> crc32c-intel-y := crc32c-intel_glue.o
<clever> crc32c-intel-$(CONFIG_64BIT) += crc32c-pcl-intel-asm_64.o
<clever> which is a composite of 2 other .o's
<clever> which come from .c's of the same name
<clever> glue contains the crc32c_intel_mod_init
<clever> and if `x86_match_cpu(crc32c_cpu_id)` fails, it returns ENODEV
<srhb> Yes, I think it shouldn't even be loading.
<clever> X86_FEATURE_MATCH(X86_FEATURE_XMM4_2),
<srhb> But something is causing it.
<clever> pkgs/build-support/vm/default.nix: echo "loading kernel modules..."
<srhb> And from thence it should get the generic crc32c module
<srhb> Which is fine.
<srhb> I think ext4 requires that at least, which should be what the change in question is about.
<clever> for i in $(cat ${modulesClosure}/insmod-list); do
<srhb> Hmm.
<srhb> Right you are.
<clever> i have patched it to print the contents and restarted the build
<srhb> Cool :)
<clever> /nix/store/x7g7dxk6m0di76sbkazwan39hq6vwai0-linux-4.14.39-shrunk/lib/modules/4.14.39/kernel/arch/x86/crypto/crc32c-intel.ko.xz
<gchristensen> Sonarpulse: I agree!
<clever> srhb: and i can confirm it somehow wound up inside insmod-list
<Sonarpulse> gchristensen: :)
<gchristensen> Sonarpulse: unfortunately the tools don't really grok that sort of thing... one _cool_ thing about that is it encourages thinking about your sentence length.
<Sonarpulse> hehe true
<gchristensen> ('one cool thing about that' where "that" is one sentence per line)
<srhb> clever: Yeah, it wasn't in the crypto dir in 4.14.38 presumably
<srhb> Why'd that happen...
<clever> "rootModules": "virtio_pci virtio_mmio virtio_blk virtio_balloon virtio_rng ext4 unix 9p 9pnet_virtio crc32c_generic rtc_cmos",
<clever> srhb: modules-closure was ran with this exact string
<clever> and it computed that crc32c-intel was somehow a dep of one of those
<clever> `nix log /nix/store/x7g7dxk6m0di76sbkazwan39hq6vwai0-linux-4.14.39-shrunk` confirms, but doesnt show the dep tree
<clever> checking modinfo on each...
<gchristensen> Sonarpulse: of course a danger of trying to get fancy is every time you change, there is a big ol' diff and a lot of churn that ideally doesn't have to happen, and is worth avoiding
<Sonarpulse> gchristensen: change fancy strategies you mean
<Sonarpulse> ?
<gchristensen> yeah
<Sonarpulse> well I just went through staging with yours :) so I'm happy to pay that cost again
<gchristensen> part of the reason I copied basically bit-for-bit SUSE's xml formatter is I can point to it and say "well they've been using it for like a decade just fine"
<Sonarpulse> is the tool in nixpkgs?
<gchristensen> (not that that is a great argument)
<gchristensen> yeah! xmlformat and the config is referred to from the makefile
<MichaelRaskin> Especially in a distro with the basic message «everyone is doing things wrong»…
<Sonarpulse> hehe yeah
<Sonarpulse> despite git "winning"
<Sonarpulse> I think there's been surprisingly little thought out there on "how can I avoid merge conflicts"
<clever> srhb: modinfo isnt showing much, possibly due to different kernel versions, ive patched modules-closure.sh
<gchristensen> Sonarpulse: oh did you get a nasty merge conflict?
<gchristensen> I can help if you did!
<Sonarpulse> yes :)
<Sonarpulse> I resolvd it
<clever> srhb: its somehow a dependency of ext4
<tilpner> /quit
<srhb> clever: Yep, that;s the new thing.
<tilpner> Oops, sorry
<gchristensen> how did you solve? probably easiest is run `make format`, commit, then merge
<MichaelRaskin> Git and thinking in advance about using VCS don't come together
<srhb> clever: Which is what I meant with: I think it should be generic.
<infinisil> Sonarpulse: Pijul (version control system, https://pijul.org/) handles merge conflicts a bit better than git
<Sonarpulse> MichaelRaskin: hahah well what about 5 years into using git?
<clever> srhb: yeah, there is no way to modprobe ext4 on amd now, if i'm reading this right
<infinisil> Thanks to MichaelRaskin for introducing me to pijul :P
<srhb> clever: We probably don't want to unblock then :D
<MichaelRaskin> Oh, Pijul actually works now/
<clever> srhb: attempting to confirm things...
<infinisil> MichaelRaskin: Yeah that's nice, I have yet to actually use it for a project though
<MichaelRaskin> I heard they recently required a not-yet-released version of Pijul to download latest development code from Nest, or something
<srhb> clever: I think the weirdness is probably cause by interchangable symbols here... Well, maybe.
<srhb> clever: So that ext4 depends on any one of those crc32c versions
<clever> srhb: in general, these things work by having a generic module, and then one of the backends has to also be loaded and register functions with the generic
<srhb> Ah
<srhb> Looks like they're doing it right then.
<Sonarpulse> infinisil: MichaelRaskin interesting
<infinisil> Sonarpulse: MichaelRaskin: (Maybe pijul discussion would be more for #nixos-chat)
<MichaelRaskin> If it is not over, yes
<clever> softdep: pre: crc32c
<clever> depends: mbcache,fscrypto,jbd2,crc16
<clever> srhb: ahh, yeah, modinfo is returning 2 sets of dependencies
<Sonarpulse> infinisil: I'll need to read more first :)
<clever> srhb: aha, found the problem
<clever> srhb: crc32c-intel and crc32c_generic both have `alias: crc32c` on them
<clever> so modprobe will "somehow" pick one of those 2
<clever> but our implementation runs modprobe without root, captures its verbose output, then tries to insmod without that "somehow" logic
<srhb> Could we capture the aliases and modprobe that instead of insmodding?
<clever> `modinfo crc32c` prints 2 modules out, the intel one is first
<clever> id want to skip insmod, and just call modprobe, on the smaller set of modules, and let modprobe do its thing
<clever> stage-1 already does so
<clever> but the vm tools dont
<srhb> Ah, okay.
<clever> cant test what `modprobe` does on a normal os, netfilter is using crc32
<clever> lets see what breaks if i just dont insmod anything!
<srhb> :-)
<srhb> I can't get rid of it either, too many dependencies everywhere.
<clever> mount: mounting store on /fs/nix/store failed: No such device
<clever> 9plan
<clever> 9p.ko
<srhb> Meep
<clever> ln -s ${modulesClosure}/lib/modules /lib/modules
<clever> ln: /lib/modules: No such file or directory
<srhb> That's fair, since we don't have lib ? :P
<clever> yeah
<Sonarpulse> dtz: I can't think of a good way for a setup hook itself to depend on anything :D
<clever> i also just noticed, stage2 in this file is doing almost exactly what i was just writing
<Sonarpulse> sadly there is no guarantee that dependency's setup hooks will be run first
<clever> but stage2 needs 9plan to run
<Sonarpulse> (I made a PR to do that, but things break due to nasty order dependencies)
<clever> `echo @extraUtils@/bin/modprobe > /proc/sys/kernel/modprobe`
<clever> srhb: i think something like this has to be ran, for the kernel to auto-load things on-demand
<clever> the kernel will automatically spawn that with an empty env and pid1 as the parent
<clever> oh right, the fstype for mount says 9p has to load, but it doesnt know which backend to load, 9pnet_virtio
<Sonarpulse> LnL: lmk if you have any ideas for reusing things in setup hooks too
<clever> srhb: i think the proper fix, would be to have 2 module lists, the same as nixos, available modules, and those it needs to auto-load
<clever> srhb: but thats a bigger change then the 1 line fix i just made
<srhb> Yeah.
<clever> pushing to my fork...
<clever> srhb: is the problem also present on master?
<srhb> Yes it is.
<srhb> I'm too tired to be helpful in any capacity now. :D G'night, thanks for figuring it out.
<Sonarpulse> is there an environment variable to do --store on every call?
<clever> srhb: opening a PR now
<clever> Sonarpulse: NIX_REMOTE=local?root=/mnt/
<Sonarpulse> clever: thanks!
rsa has quit [Ping timeout: 245 seconds]