<{^_^}>
#120283 (by Ericson2314, 25 seconds ago, open): netbsd: Remove some env vars that are probably not needed.
<Ericson2314>
(which i kicked off a fresh build for)
<qyliss>
(just noticed it didn't build even though I fixed it earlier today)
<qyliss>
Ericson2314: did we just break staging?
<qyliss>
"The branch this PR will merge in to does not cleanly evaluate, and so this PR cannot be checked."
<Ericson2314>
Oops was that not happy with ofborg?
<qyliss>
while evaluating the attribute 'propagatedBuildInputs' of the derivation 'yarGen-0.23.4' at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-0/pkgs/stdenv/generic/make-derivation.nix:197:11:
<Ericson2314>
Peril of being trigger happy from my phone after eating
<qyliss>
maybe it wasn't us
<Ericson2314>
I'll go take a look
<Ericson2314>
acrue some karma for other times i did break things :D
orivej has quit [Ping timeout: 240 seconds]
<qyliss>
oh, it's from staging-next being merged into staging
<qyliss>
I think it's funny how several people seem to have independently noticed *immediately*
<qyliss>
even though it's late for most of the community (going by when there's normally IRC traffic), and even though it's only staging and staging-next that are broken
cole-h has quit [Ping timeout: 252 seconds]
<qyliss>
that's enough excitement. night everyone. :)
<Ericson2314>
goodnight!
asbachb has quit [Ping timeout: 240 seconds]
Jackneill has quit [Ping timeout: 260 seconds]
Jackneill has joined #nixos-dev
Jackneill has quit [Ping timeout: 252 seconds]
rajivr has joined #nixos-dev
Jackneill has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
tomberek has quit [Ping timeout: 240 seconds]
AlwaysLivid has quit [Remote host closed the connection]
<samueldr>
since the bigger ext4 is, the more reserved space there will be
<samueldr>
every unique snowflake fs/image builder we have should be replaced with a common tooling :|
orivej has quit [Ping timeout: 246 seconds]
<samueldr>
before someone writes a new one, again, I volunteer my approache, but I'm biased :) (it was partly written with the goal to replace the image/fs writers I know of in Nixpkgs)
<samueldr>
or at the very least a similar interface
<samueldr>
ah, no, not exactly, let me retract, and explain
<samueldr>
it needs to be done through the NixOS modules, for better composition :)
<samueldr>
but the interface is basically the same
<lukegb>
why is the auto size calculation wrong, though; fwict it picks 1382MB and there's no way there's 512M of ext4 overhead in a 1382MB disk
<lukegb>
(or is additionalSpace set to something else for ec2 images)
<samueldr>
lukegb: 1382MB is the size of the data?
<lukegb>
1382M is the size of the disk image it's putting the data into
<samueldr>
yeah
<samueldr>
we don't log useful data points like the size we want
<lukegb>
oh, that's also drastically smaller than the last successful build
<samueldr>
lukegb: can you copy the current failure log?
<samueldr>
I'll restart the job
<lukegb>
I already did that once
<lukegb>
but sure, sec
<samueldr>
ah, nah, if you did there's no need to
<samueldr>
didn't realize you had some hydra rights
<lukegb>
just restart-job
<samueldr>
some
<lukegb>
so the disk size we compute dropped from 2147MB to 1382MB for some reason
<lukegb>
hmm, doesn't apparent-size make the number go _down_ usually
<samueldr>
it's uh, cargo culted from the sd image, to be honest
<samueldr>
but it's more subtle
<lassulus>
ohoh
<samueldr>
print apparent sizes, rather than disk usage; although the apparent size is usually smaller, it may be larger due to holes in ('sparse') files, internal fragmentation, indirect blocks, and the like
<samueldr>
I trusted the previous implemented chose --apparent-size *and* --block-size for a reason
<samueldr>
reading the du manpage
* lukegb
nods
<samueldr>
lassulus: hopefully you understand I was saying that playfully :)
<symphorien[m]>
maybe take the max between the two :þ
<lassulus>
ah, I'm just in a meeting right now, will catch up later, hopefully I didn't break anything
<samueldr>
ah, something broke, now to be determined if it was really _you_ :)
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
cole-h has quit [Ping timeout: 260 seconds]
<lukegb>
20.09 is also stuck but for a different reason (the chromium test can't find the "Web Store" text, even though it does seem to be there when I run it locally)
<samueldr>
the amazon disk image built locally here
<lukegb>
hrm
<lukegb>
at d7abcef1e50?
<samueldr>
nope
<samueldr>
that's one variable
<samueldr>
it was on whatever master was at
<samueldr>
but nothing in between that looks like it would fix that
<samueldr>
Disk /build/nixos.raw: 2403MB
<lukegb>
yeah, built here too
<lukegb>
Thought: does this get impacted by the partitioning scheme of the hydra workers without apparent-size?
<samueldr>
good question
<samueldr>
that's kind of my assumption
<samueldr>
what _is_ apparent_size doing
<samueldr>
and how can it be impacted by things like optimized store
<samueldr>
use the apparent size (a la stat.st_size). */
<samueldr>
static bool apparent_size = false;
<samueldr>
blah
<samueldr>
/* If true, rather than using the disk usage of each file,
<samueldr>
that was the first line, but IRC ate it
<lukegb>
aha!
<lukegb>
yes, if I run the build on a ZFS machine it fails
<samueldr>
that was the other thing I had in mind, not optimized store, but FS shenanigans
<samueldr>
ambiant impurities!
<lukegb>
wait, hm, these are both zfs machines
<samueldr>
plausible
<samueldr>
wait, yours or hydra?
<lukegb>
mine
<samueldr>
oh, I wouldn't know
<lukegb>
one generated: Disk /build/nixos.raw: 1235MB
<lukegb>
the other generated: Disk /build/nixos.raw: 1866MB
<samueldr>
sounds to me like one might have either compression, or dedup, the other not?
<samueldr>
OR that one dedup'd while the other had no chance?
<samueldr>
but already this should allow us to test things out
<samueldr>
the first commit adds logging, and works with bytes, the following one adds --apparent-size
<samueldr>
so you could easily see how --apparent-size affects your build on ZFS
<samueldr>
on my end with --apparent-size it's 16 more bytes
<samueldr>
but I'm on boring ext4
<samueldr>
and maybe those 16 bytes are a rounding error coming from how the closure is put together
<samueldr>
anyway, I'll be off, it's uh... way past my bed time :)
<samueldr>
but I'm curious what this will look like on ZFS
<lassulus>
hmm, yeah, I didn't really thought about different filesystems having an impact on du and how image generation could be affected by it. maybe its better to pin the disk size for some images and have the auto size as an opt-in?
<lukegb>
I think in general the autosize thing is possibly better
<lukegb>
I get a final size of 1706558274 vs 1709206019 bytes
<lukegb>
ah, there's an outstanding PR for bumping ceph to... pacific? the new release
<devhell>
ah! no, still on octopus
<devhell>
I wondered if you might be able to walk me through your process of getting rgw up and running, everything else is working fine, all OSDs, all MONs and MGRs are fine
<qyliss>
I don't need to go through a PR to merge staging-next into staging, right?
<qyliss>
staging still has the eval error and I'd like to get rid of it
orivej has quit [Ping timeout: 246 seconds]
<sterni>
it should be merged automatically by the action we have
<sterni>
but you can probably also do it manually
<qyliss>
doesn't seem to have been
<qyliss>
action is supposed to be every six hours, and it's been almost 12
<LinuxHackerman>
samueldr: AFAICT the ext4 tools can't currently do this, but mkfs.btrfs can create a filesystem image from a directory, determining the image's size automatically
<qyliss>
sterni: ah, it looks like the action is getting stuck merging master into staging
<qyliss>
staging-next rather
<qyliss>
so it didn't even get to trying to staging-next -> staging
<lukegb>
it can read "Add shortcut" fine, but not "Web Store" (unless you fiddle with the tesseract parameters a bit)
<devhell>
lukegb: so, the Ceph manual for nautilus doesn't have a section describing how to manually deploy the RGW, however, I did find one from RedHat that seems to be up-to-date, I've created the directories, and added the keys, but when I start the service I get 'monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]
<lukegb>
-> #nixos :P
<devhell>
yeah
<devhell>
my allows are the same now as yours
<devhell>
mon just needed an extra x
<devhell>
but still, no dice
<devhell>
the RH documentation states that one is to add a [client.rgw.<obj_gw_hostname] in the global configuration, but services.ceph.rgw doesn't have an extraConfig
<devhell>
ah
<devhell>
I see, there is no need for this as the assumption is that rados stuff will end up in [global]
jonringer has joined #nixos-dev
cole-h has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
devhell has quit [Quit: leaving]
matthewcroughan has quit [Quit: No Ping reply in 180 seconds.]
matthewcroughan has joined #nixos-dev
rsynnest has joined #nixos-dev
<rsynnest>
i just submitted some new packages in my first PR, and there are some fixes needed. Should I rebase my fork to keep the package init commits clean? or should I make the necessary changes as separate commits?
<qyliss>
rsynnest: rebase
<qyliss>
but don't change the base, just amend your commits
<qyliss>
that way github can show us what changed between force pushes
<rsynnest>
thanks qyliss, not quite sure what "don't change the base" means. does that mean I should git rebase, edit an old commit and then use "git commit --amend"?
plumm has joined #nixos-dev
<qyliss>
rsynnest: yes, but don't rebase onto the latest master/staging, rebase onto the commit before yours
hexchen has joined #nixos-dev
evils has quit [Ping timeout: 240 seconds]
<samueldr>
LinuxHackerman: it's the other way around, not making a ZFS image, but using data about file size from a ZFS image
evils has joined #nixos-dev
<samueldr>
and for ext4, I don't remember for sure, but IIRC make_ext4fs in #67744 can