saschagrunert has quit [Remote host closed the connection]
jpn has quit [Ping timeout: 255 seconds]
darknao has joined #fedora-coreos
jpn has joined #fedora-coreos
ravanelli has joined #fedora-coreos
vgoyal has joined #fedora-coreos
jpn has quit [Ping timeout: 255 seconds]
saschagrunert has joined #fedora-coreos
saschagrunert has quit [Remote host closed the connection]
jpn has joined #fedora-coreos
baude has joined #fedora-coreos
mheon has joined #fedora-coreos
nalind has joined #fedora-coreos
mnguyen has joined #fedora-coreos
jpn has quit [Ping timeout: 268 seconds]
jpn has joined #fedora-coreos
<baude>
curious, if you had to make a simple image to test fcos boots, would you have recommendations on packages/package groups that couild be removed to reduce the size of the image?
<baude>
i was looking at the compression "problem" where for vhdx hyperv, cosa probably needs to support zip files
<baude>
and i see in src/cmd-compress where i think that can be implemented
<baude>
but i wondered if we should really only be using zip for the buildextend disk image and not others?
<baude>
or ... is that what the build id is for?
<baude>
jlebon, others ... with cosa, seems like the work flow when dev'ing might be like cosa fetch, build, buildextend, etc ... but once the image is built, you cannot just nuke the artifact in builds/latest/arch/' either
<baude>
seemingly bc json files keep track of things
<baude>
is there a cosa command to blow away the images but keep cache so you dont have start from scratch each time
vgoyal has quit [Read error: Connection reset by peer]
vgoyal has joined #fedora-coreos
<walters>
cosa clean
<baude>
does that not remove the cache ?
<walters>
Right, it doesn't
<walters>
that said many build commands take --force too
<baude>
yup, been using that liberally
<bgilbert>
baude: we should only use zip for the hyperv image, yes. '.xz' is part of our externally facing API, but there's precedent for using a different compression format for individual artifacts that require it for some reason
<bgilbert>
for example, some clouds support direct import of .gz images but not .xz
<baude>
can you name one?
<baude>
im having a helluva time finding precedence
<bgilbert>
digitalocean and gcp
<baude>
and where exactly is the relationship between the artifact/platform and its preferred compression?
<bgilbert>
walters: yeah, zstd decompress speed is pretty shocking
<bgilbert>
baude: we refactored this a while back, so I had to look it up
<baude>
im on the right track eh ?
<baude>
for giggles enabled gzip to true, and sure nuff
<bgilbert>
baude: it is "gzip": true, but note where the compression is done
<bgilbert>
baude: if a particular platform has special compression needs, then the image build handles it, not cmd-compress
<baude>
oh
<baude>
and help me understand, "image build" the way you mean is what ?
<bgilbert>
buildextend-hyperv
<bgilbert>
QemuVariantImage in qemuvariants.py
<baude>
so you thinking a if self.zip ?
<baude>
or prefer a alt_compression with [gzip, zip]
<bgilbert>
more like the latter, yeah
<baude>
oh you are going to let me really eff things up
<bgilbert>
note that there's also a `gzip: True` in ibmcloud.py
<baude>
yeah, a bunch have them
<baude>
bgilbert, one ishy idea, use gzip = true but also condition on platform=hyperv ?
<bgilbert>
nope :-)
<baude>
ok\
<baude>
i had to try
<baude>
you have name in mind alt_compress ?
vgoyal has quit [Quit: Leaving]
vgoyal has joined #fedora-coreos
<bgilbert>
I think 'compression' is fine. cmd-compress happens elsewhere so there's no conceptual conflict
<bgilbert>
actually the existing 'skip_compression' field could be folded in here too
<baude>
i was afraid you were going to say that
<bgilbert>
:-P
<baude>
compression=none ?
<baude>
er None
<bgilbert>
shouldn't be a large change
<bgilbert>
I don't think None works because that looks like not setting the kwarg
<bgilbert>
so probably 'none'
<bgilbert>
mtg, back later
<baude>
or skip ?
<bgilbert>
skip, sure
<adamw>
Colin Walters, dustymab1: etc: any idea why https://openqa.fedoraproject.org/tests/1761697#step/rpmostree_rebase/9 might be happening? (I know this is the coreos channel but it seems like possibly a generic rpm-ostree / content production / syncing issue, and the silverblue channel is very user-y)
<walters>
Not offhand; is it reproducible?
<walters>
Maybe a broken webserver/proxy returning e.g. HTML as a 500 error
<adamw>
yes, it's happening every time
<adamw>
it seems to be happening *part way through* the data transfer
<adamw>
the percentage it reaches is not consistent
<adamw>
but the same test is passing on other releases (which rebase to different versions); only rebasing to 38 seems to be the problem. or possibly rebasing *from* 39.
<adamw>
i can try a scratch build with that reverted and see what happens
<adamw>
agh, but that's not in the current compose, so the test probably isn't using it
<adamw>
oh, wait, it might be.
<adamw>
meh, no, first fail of this type was 2023-02-15 18:56, too early to be that.
<bgilbert>
baude: no, the meta_patch.update() part doesn't change. that part is a cross-component API (meta.json)
<bgilbert>
baude: so we just change the test that gates whether that meta_patch.update() occurs
Turnikov has quit [Ping timeout: 255 seconds]
<baude>
bgilbert, interestingly, cosa buildextend-ibmcloud --compress results in an xz compressed image ... seems like a bug to me
<bgilbert>
buildextend-powervs is the one that's supposed to gzip
<baude>
ah, duh
<baude>
i still gotta do the skip crapola; and i donit like how the code neccesarily came together, but bgilbert anything else that you are going to want re: zip?
<bgilbert>
baude: out of curiosity, are you using the zip cmdline tool, or Python zipfile?
<bgilbert>
not sure if one is better than the other
<baude>
im calling zip, it is in the cosa image
<bgilbert>
yeah it is
<baude>
generally the command line is always better
<bgilbert>
maybe
<bgilbert>
anyway, wfm
<bgilbert>
always appreciated if refactors go into a separate commit than new functionality
<bgilbert>
may not be 100% needed here, but still good if possible
<baude>
if you decide as such, im happy to refactor, fair nuff ?
<bgilbert>
sure
jpn has joined #fedora-coreos
<bgilbert>
baude: commit title please :-)
<baude>
yup already fixed and edit in gh now too
<baude>
also adding links
daMaestro has joined #fedora-coreos
<baude>
ive alwaysa wondered, is there a way with the git to update the title and desciption of what lands in github's web ui? or is it always manual
<bgilbert>
when creating the PR, or when updating it?