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
<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…
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]
<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
<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