On 30/11/19 23:23, Kevin Fenzi wrote:
On Sat, Nov 30, 2019 at 02:20:42PM -0700, Chris Murphy wrote:
On Sat, Nov 30, 2019 at 12:46 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
On Wed, Nov 27, 2019 at 02:43:48PM -0700, Chris Murphy wrote:
On Wed, Nov 27, 2019 at 12:18 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
...snip...
I'd love to explore using Btrfs for doing it. I have no idea how to
get started with that...
Before Btrfs specific, I'd ask how much compression configurability is
needed in the compose system and where? That relates to plain squashfs
images as well as hypothetical Btrfs images. Is there any advantage to
having Rawhide use zstd:3 since these nightlies are throw away? These
would be much faster to create and use than xz or zstd:16, but the ISO
size would be a lot bigger, maybe 25% bigger. And then for branched
nightlies, RCs, and releases, use zstd:16 or even zstd:19? Could the
granularity be compress=low,medium,high? And that is then translated
by lmc or even the installer, into the specific level numbers? This is
in effect the question I'm posing here:
https://pagure.io/releng/issue/8581#comment-613760
I think we should just use the same everywhere, or we risk testing
something that is not actually what we ship.
I'm definitely advocating testing what will be shipped:
Test and ship zstd:3 for Rawhide
Test and ship zstd:16 for branched (nightlies, RC, release)
I'd casually estimate zstd:3 is 2x faster to create the image than
zstd:16 - but since the compose system is typically throwing something
like 32 cores at these tasks, it may not substantially reduce the
overall compose time.
Yeah, but then we aren't using Rawhide to test the thing that will go
into the next branched. So, say there's some zstd bug or a size issue or
something we don't catch in rawhide and then have to figure out months
later in branched. I'd really prefer we just use the same for both.
kevin
What I'm looking for mainly, as a first step, is to get reproducibility
at binary level, not at rpm level (maybe after that).
Apart from that, the most important part is the bootstrap, because that
would require regenerating Fedora, or at least a subset of key packages,
like gcc, glibc, without using any of the current binaries.
I'll be conducting a few tests over the next weeks and reporting back,
but if this is an interesting thing to tackle for Fedora as a whole, it
would be good to know which would be the first steps.
Pablo.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
