* Nico Kadel-Garcia:
> On Sun, Sep 1, 2019 at 3:52 AM Florian Weimer wrote:
>>
>> * Neal Gompa:
>>
>> > Well, technically, the correct thing to do would be for Mock to
>> > support downloading bootstrap images to speed up bootstrap. These
>> > images could be regularly produced by Fedora infrastr
On Sun, Sep 1, 2019 at 3:52 AM Florian Weimer wrote:
>
> * Neal Gompa:
>
> > Well, technically, the correct thing to do would be for Mock to
> > support downloading bootstrap images to speed up bootstrap. These
> > images could be regularly produced by Fedora infrastructure and made
> > available
On Sun, Sep 1, 2019 at 3:51 AM Florian Weimer wrote:
>
> * Neal Gompa:
>
> > Well, technically, the correct thing to do would be for Mock to
> > support downloading bootstrap images to speed up bootstrap. These
> > images could be regularly produced by Fedora infrastructure and made
> > available
* Neal Gompa:
> Well, technically, the correct thing to do would be for Mock to
> support downloading bootstrap images to speed up bootstrap. These
> images could be regularly produced by Fedora infrastructure and made
> available on the mirror network for all targets we support as a
> project. Th
On Sun, Sep 1, 2019 at 3:31 AM Florian Weimer wrote:
>
> * Kevin Fenzi:
>
> > On 8/29/19 11:44 PM, Miroslav Suchý wrote:
> >> Dne 29. 08. 19 v 18:58 Kamil Dudka napsal(a):
> >>> What is the recommended way to build Fedora 31+ RPMs on a RHEL-7 host?
> >>
> >> I think that no one contemplate support
* Kevin Fenzi:
> On 8/29/19 11:44 PM, Miroslav Suchý wrote:
>> Dne 29. 08. 19 v 18:58 Kamil Dudka napsal(a):
>>> What is the recommended way to build Fedora 31+ RPMs on a RHEL-7 host?
>>
>> I think that no one contemplate supporting RHEL 7 regarding zstd. The real
>> thing is "how to build Fedor
On 8/29/19 11:44 PM, Miroslav Suchý wrote:
> Dne 29. 08. 19 v 18:58 Kamil Dudka napsal(a):
>> What is the recommended way to build Fedora 31+ RPMs on a RHEL-7 host?
>
> I think that no one contemplate supporting RHEL 7 regarding zstd. The real
> thing is "how to build Fedora 31+ RPMs on a
> RHEL-
On Friday, August 30, 2019 8:44:39 AM CEST Miroslav Suchý wrote:
> I think that no one contemplate supporting RHEL 7 regarding zstd.
Panu said that the backport would be almost trivial:
https://lists.pagure.io/archives/list/devel@lists.fedoraproject.org/message/Z4EFFNJNVAP35KH74N3W5GC4E2AQXC7V/
On Thursday, August 29, 2019 11:17:18 PM CEST Nico Kadel-Garcia wrote:
> Sent from my iPhone
>
>
> > On Aug 29, 2019, at 12:58 PM, Kamil Dudka wrote:
> >
> >
> >> On Tuesday, June 4, 2019 9:43:53 AM CEST Panu Matilainen wrote:
> >>
> >>> On 6/4/19 9:56 AM, Daniel Mach wrote:
> >>>
> >>> Dne
Dne 29. 08. 19 v 18:58 Kamil Dudka napsal(a):
> What is the recommended way to build Fedora 31+ RPMs on a RHEL-7 host?
I think that no one contemplate supporting RHEL 7 regarding zstd. The real
thing is "how to build Fedora 31+ RPMs on a
RHEL-8 host"?
https://bugzilla.redhat.com/show_bug.cgi?id
Sent from my iPhone
> On Aug 29, 2019, at 12:58 PM, Kamil Dudka wrote:
>
>> On Tuesday, June 4, 2019 9:43:53 AM CEST Panu Matilainen wrote:
>>> On 6/4/19 9:56 AM, Daniel Mach wrote:
>>>
>>> Dne 31. 05. 19 v 2:15 Pavel Raiskup napsal(a):
>>>
> On Thursday, May 30, 2019 10:38:25 AM CEST Mi
On Tuesday, June 4, 2019 9:43:53 AM CEST Panu Matilainen wrote:
> On 6/4/19 9:56 AM, Daniel Mach wrote:
>
> > Dne 31. 05. 19 v 2:15 Pavel Raiskup napsal(a):
> >
> >> On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote:
> >>
> >>> Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
> >>>
>
On Tue, 2019-06-25 at 07:16 -0400, Nico Kadel-Garcia wrote:
> On Wed, Jun 19, 2019 at 9:31 AM Panu Matilainen
> wrote:
> > On 6/19/19 1:51 PM, Aleš Matěj wrote:
> > > > At this point, the drpm library is the only blocker for zstd
> > > > payloads,
> > > > since createrepo_c needs to be able to han
On Wed, Jun 19, 2019 at 9:31 AM Panu Matilainen wrote:
>
> On 6/19/19 1:51 PM, Aleš Matěj wrote:
> >
> >> At this point, the drpm library is the only blocker for zstd payloads,
> >> since createrepo_c needs to be able to handle zstd drpms.
> >
> > I looked into the drpm library and I should be abl
On 6/19/19 1:51 PM, Aleš Matěj wrote:
At this point, the drpm library is the only blocker for zstd payloads,
since createrepo_c needs to be able to handle zstd drpms.
I looked into the drpm library and I should be able to add the zstd support
(and make sure it works with createrepo_c)
Workin
On Wed, 2019-06-19 at 10:51 +, Aleš Matěj wrote:
> > At this point, the drpm library is the only blocker for zstd payloads,
> > since createrepo_c needs to be able to handle zstd drpms.
>
> I looked into the drpm library and I should be able to add the zstd support
> (and make sure it works w
> At this point, the drpm library is the only blocker for zstd payloads,
> since createrepo_c needs to be able to handle zstd drpms.
I looked into the drpm library and I should be able to add the zstd support
(and make sure it works with createrepo_c)
Working on it now.
___
On Thu, May 30, 2019 at 3:07 PM Kevin Fenzi wrote:
>
> So, most of my concerns have already been mentioned by other folks in
> this thread:
>
> * No rhel7/8 support will annoy people, and also increase burden on
> fedora infrastructure since we would have to move our koji hubs to
> Fedora instead
On Wed, Jun 5, 2019 at 1:38 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Jun 05, 2019 at 10:01:22AM -0600, Chris Murphy wrote:
> > I found this on HN today. While xz is not expressly being used within
> > Fedora/Red Hat packaging in an archive context, it does seem to have
> > quite a lot of
On Wed, Jun 05, 2019 at 10:01:22AM -0600, Chris Murphy wrote:
> On Wed, Jun 5, 2019 at 2:11 AM Panu Matilainen wrote:
> >
> > On 6/5/19 12:53 AM, Chris Murphy wrote:
> > > At least for small files, and there are many in any distribution,
> > > using a dictionary very well could improve compression
On Wed, Jun 5, 2019 at 2:11 AM Panu Matilainen wrote:
>
> On 6/5/19 12:53 AM, Chris Murphy wrote:
> > At least for small files, and there are many in any distribution,
> > using a dictionary very well could improve compression/decompression
> > time, compression ratio, more than threads. Adding di
On 6/5/19 12:53 AM, Chris Murphy wrote:
On Mon, Jun 3, 2019 at 7:01 PM Jason L Tibbitts III wrote:
"PM" == Panu Matilainen writes:
PM> Note that rpm doesn't support parallel zstd compression, and while
PM> it does for xz, that's not even utilized in Fedora.
Doing parallel xz compression h
On Mon, Jun 3, 2019 at 7:01 PM Jason L Tibbitts III wrote:
>
> > "PM" == Panu Matilainen writes:
>
> PM> Note that rpm doesn't support parallel zstd compression, and while
> PM> it does for xz, that's not even utilized in Fedora.
>
> Doing parallel xz compression has a surprising cost in comp
Jason L Tibbitts III wrote:
> One problem is that I don't think anyone wants to see any quantifiable
> regression in overall package size. Spins still struggle to fit within
> fixed media sizes as the package set grows ever larger.
The RPM compression method is pretty irrelevant to Spin sizes bec
On 6/4/19 9:56 AM, Daniel Mach wrote:
Dne 31. 05. 19 v 2:15 Pavel Raiskup napsal(a):
On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote:
Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
If we did this, wouldn't it make it very difficult to use tools like
mock on RHEL / CentOS 7 to bui
Dne 31. 05. 19 v 2:15 Pavel Raiskup napsal(a):
On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote:
Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
If we did this, wouldn't it make it very difficult to use tools like
mock on RHEL / CentOS 7 to build for Fedora 3x?
Speaking of Mock:
E
Dne 31. 05. 19 v 2:15 Pavel Raiskup napsal(a):
On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote:
Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
If we did this, wouldn't it make it very difficult to use tools like
mock on RHEL / CentOS 7 to build for Fedora 3x?
Speaking of Mock:
E
On 6/4/19 8:31 AM, Panu Matilainen wrote:
On 6/4/19 4:00 AM, Jason L Tibbitts III wrote:
"PM" == Panu Matilainen writes:
PM> Note that rpm doesn't support parallel zstd compression, and while
PM> it does for xz, that's not even utilized in Fedora.
Doing parallel xz compression has a surprisi
On 6/4/19 4:00 AM, Jason L Tibbitts III wrote:
"PM" == Panu Matilainen writes:
PM> Note that rpm doesn't support parallel zstd compression, and while
PM> it does for xz, that's not even utilized in Fedora.
Doing parallel xz compression has a surprising cost in compression ratio
which gets wor
> "PM" == Panu Matilainen writes:
PM> Note that rpm doesn't support parallel zstd compression, and while
PM> it does for xz, that's not even utilized in Fedora.
Doing parallel xz compression has a surprising cost in compression ratio
which gets worse as the thread count increases (because it
Dne 30. 05. 19 v 17:14 Peter Robinson napsal(a):
What about constrained systems where there's limited CPU, that could
be a container or a low end cloud instance without any guarantee of
resources or a Raspberry Pi.
Raspberry Pi is hard to measure. I'm getting quite random results due to
IO, I
Dne 30. 05. 19 v 17:14 Peter Robinson napsal(a):
What about constrained systems where there's limited CPU, that could
be a container or a low end cloud instance without any guarantee of
resources or a Raspberry Pi.
Raspberry Pi is hard to measure. I'm getting quite random results due to
IO, I
On 5/29/19 11:19 PM, Ben Cotton wrote:
* The macro for setting the compression is: %define _binary_payload w19.zstdio
* The recommended compression level is 19. The builds will take
longer, but the additional compression time is negligible in the total
build time and it pays off in better compre
On 5/30/19 1:18 PM, Neal Gompa wrote:
> I'm actually okay with the thought of Koji hub moving to Fedora. I'd
> rather see most of our infra running on Fedora so that we don't get
> kneecapped by RHEL moving too slowly. Our transition to Python 3 was
> made way more complicated by the fact our infr
On 5/31/19 12:53 PM, Chris Murphy wrote:
On Fri, May 31, 2019 at 12:40 PM Samuel Sieb wrote:
On 5/31/19 6:57 AM, Martin Kolman wrote:
I guess we can't just switch what the signature refers to as there are other
tools
that do this kind of verification on the compressed data, not just delta-RP
On Fri, May 31, 2019 at 12:40 PM Samuel Sieb wrote:
>
> On 5/31/19 6:57 AM, Martin Kolman wrote:
> > I guess we can't just switch what the signature refers to as there are
> > other tools
> > that do this kind of verification on the compressed data, not just
> > delta-RPM, right ?
> >
> > So may
On Thursday, May 30, 2019, Samuel Sieb wrote:
> On 5/30/19 1:56 PM, Chris Murphy wrote:
>
>> On Thu, May 30, 2019 at 8:40 AM Daniel Mach wrote:
>>
>>>
>>> Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a):
>>>
I'm pretty sure this would break DeltaRPMs, since none of the drpm
software ha
On 5/31/19 6:57 AM, Martin Kolman wrote:
I guess we can't just switch what the signature refers to as there are other
tools
that do this kind of verification on the compressed data, not just delta-RPM,
right ?
So maybe, could we attach a second signature computed on the uncompressed
payload ?
On Fri, May 31, 2019 at 7:58 AM Martin Kolman wrote:
> I guess we can't just switch what the signature refers to as there are other
> tools
> that do this kind of verification on the compressed data, not just delta-RPM,
> right ?
>
> So maybe, could we attach a second signature computed on the u
- Original Message -
> From: "Samuel Sieb"
> To: devel@lists.fedoraproject.org
> Sent: Thursday, May 30, 2019 11:52:55 PM
> Subject: Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd
> compression
>
> On 5/30/19 2:38 PM, Chris Murphy wrote
* Jonathan Dieter:
> On Wed, 2019-05-29 at 20:15 -0600, Chris Murphy wrote:
>> 'dnf info deltarpm' says
>> URL : http://gitorious.org/deltarpm/deltarpm
>> which has an expired certificate, but pushing passed that it says
>> current version 3.6 is 5 years old. Is this really maintained or
On Thu, 2019-05-30 at 16:18 -0400, Neal Gompa wrote:
>
> That said, I'm less happy about the thought that inspecting Fedora
> RPMs on RHEL 8 or openSUSE is going to be a royal pain.
> Ecosystem-wise, no one really prepared for a distribution to switch
> to
> zstd so quickly. Thankfully, it's easie
On Thu, May 30, 2019 at 11:44:23AM -0700, Samuel Sieb wrote:
> On 5/30/19 7:54 AM, Daniel Mach wrote:
> >>I think before approving such changes, owners need to do mass
> >>rebuilds on their own and provide a graph of changes in size
> >>between original compression format and new one(s).
> >Doing t
On Fri, May 31, 2019 at 9:36 AM Nicolas Mailhot via devel <
devel@lists.fedoraproject.org> wrote:
> Le vendredi 31 mai 2019 à 02:15 +0200, Pavel Raiskup a écrit :
> > On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote:
> > > Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
> > > > If we d
Le jeudi 30 mai 2019 à 14:29 -0700, Samuel Sieb a écrit :
> On 5/30/19 1:56 PM, Chris Murphy wrote:
> > On Thu, May 30, 2019 at 8:40 AM Daniel Mach
> > wrote:
> > > Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a):
> > > > I'm pretty sure this would break DeltaRPMs, since none of the
> > > > drpm
> > >
Le vendredi 31 mai 2019 à 02:15 +0200, Pavel Raiskup a écrit :
> On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote:
> > Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
> > > If we did this, wouldn't it make it very difficult to use tools
> > > like
> > > mock on RHEL / CentOS 7 to build
On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote:
> Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
> > If we did this, wouldn't it make it very difficult to use tools like
> > mock on RHEL / CentOS 7 to build for Fedora 3x?
>
> Speaking of Mock:
> Either the RPM on host need to unders
On 5/30/19 2:38 PM, Chris Murphy wrote:
On Thu, May 30, 2019 at 3:31 PM Samuel Sieb wrote:
On 5/30/19 1:56 PM, Chris Murphy wrote:
I have no idea how deltarpm works, but if working on bit level
difference on uncompressed data, I don't see why local rebuild needs
to use the same compression le
On Thu, May 30, 2019 at 3:31 PM Samuel Sieb wrote:
>
> On 5/30/19 1:56 PM, Chris Murphy wrote:
> > On Thu, May 30, 2019 at 8:40 AM Daniel Mach wrote:
> >>
> >> Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a):
> >>>
> >>> I'm pretty sure this would break DeltaRPMs, since none of the drpm
> >>> software
On 5/30/19 1:56 PM, Chris Murphy wrote:
On Thu, May 30, 2019 at 8:40 AM Daniel Mach wrote:
Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a):
I'm pretty sure this would break DeltaRPMs, since none of the drpm
software has been updated to handle zstd compression. Neither drpm nor
deltarpm handle it
On Thu, May 30, 2019 at 8:40 AM Daniel Mach wrote:
>
> Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a):
> >
> > I'm pretty sure this would break DeltaRPMs, since none of the drpm
> > software has been updated to handle zstd compression. Neither drpm nor
> > deltarpm handle it today.
> >
> Thanks for he
On Thu, May 30, 2019 at 3:07 PM Kevin Fenzi wrote:
>
> So, most of my concerns have already been mentioned by other folks in
> this thread:
>
> * No rhel7/8 support will annoy people, and also increase burden on
> fedora infrastructure since we would have to move our koji hubs to
> Fedora instead
So, most of my concerns have already been mentioned by other folks in
this thread:
* No rhel7/8 support will annoy people, and also increase burden on
fedora infrastructure since we would have to move our koji hubs to
Fedora instead of RHEL to be able to read the rpms made on builders.
(Or ship a
On 5/30/19 7:54 AM, Daniel Mach wrote:
I think before approving such changes, owners need to do mass rebuilds
on their own and provide a graph of changes in size between original
compression format and new one(s).
Doing that equals to the mass rebuild.
I'd rather do an analysis and if the numbe
On Thu, 2019-05-30 at 12:20 -0400, Adam Jackson wrote:
> - What's the mean and/or median size of an rpm in Fedora, and what
> difference in {de,}compression time would that likely experience?
Just to follow up on this since it was quick to math out. For Fedora
30's x86_64 repo, various "averages"
On Wed, 2019-05-29 at 16:19 -0400, Ben Cotton wrote:
> * Faster koji builds (installations in build roots)
The numbers here seem to indicate that you'll have faster koji build
_setup_. But getting comparable compression rates as xz means spending
(apparently) significantly more time at successful
On Thu, May 30, 2019 at 5:01 PM Daniel Mach wrote:
> Dne 30. 05. 19 v 8:39 Igor Gnatenko napsal(a):
> > Last time I was about to propose this in F29, I did mass-rebuild myself
> > and while decompressing was faster in most of the cases, the size was
> > definitely worse. So definitely "Lower band
On Thu, May 30, 2019 at 4:16 PM Ben Cotton wrote:
>
> Daniel added more contingency details to the proposal[1], but I want
> to call out the contingency date. Right now it is listed as a week
> before the final freeze, which is way too late. I would suggest that
> the end of the mass rebuild is th
Daniel added more contingency details to the proposal[1], but I want
to call out the contingency date. Right now it is listed as a week
before the final freeze, which is way too late. I would suggest that
the end of the mass rebuild is the appropriate contingency point. If a
second mass rebuild is
> Dne 30. 05. 19 v 14:57 Kevin Kofler napsal(a):
> > Jason L Tibbitts III wrote:
> >
> >>> "BC" == Ben Cotton writes:
> >> BC> * The recommended compression level is 19. The builds will take
> >> BC> longer, but the additional compression time is negligible in the
> >> BC> total build time and
> Dne 30. 05. 19 v 8:39 Igor Gnatenko napsal(a):
> > Last time I was about to propose this in F29, I did mass-rebuild myself
> > and while decompressing was faster in most of the cases, the size was
> > definitely worse. So definitely "Lower bandwidth on mirrors if we choose
> > the highest compres
Dne 30. 05. 19 v 14:57 Kevin Kofler napsal(a):
Jason L Tibbitts III wrote:
"BC" == Ben Cotton writes:
BC> * The recommended compression level is 19. The builds will take
BC> longer, but the additional compression time is negligible in the
BC> total build time and it pays off in better compres
Dne 30. 05. 19 v 8:39 Igor Gnatenko napsal(a):
Last time I was about to propose this in F29, I did mass-rebuild myself
and while decompressing was faster in most of the cases, the size was
definitely worse. So definitely "Lower bandwidth on mirrors if we choose
the highest compression level" is
Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a):
I'm pretty sure this would break DeltaRPMs, since none of the drpm
software has been updated to handle zstd compression. Neither drpm nor
deltarpm handle it today.
Thanks for heads-up. We'll look into it and provide a fix soon.
__
Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
On Wed, May 29, 2019 at 4:20 PM Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
= Switch RPMs to zstd compression =
== Summary ==
Binary RPMs are currently compressed with xz level 2.
Switching to zstd wo
Hello, Ben Cotton.
Wed, 29 May 2019 16:19:48 -0400 you wrote:
> Switching to zstd would increase decompression speed significantly.
Good change, but it will significantly increase Delta RPM rebuild
process especially on HDD, that's why drpm should be disabled by default
to achieve maximum speed.
On Wed, May 29, 2019 at 10:20 PM Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
>
> = Switch RPMs to zstd compression =
>
> == Summary ==
> Binary RPMs are currently compressed with xz level 2.
> Switching to zstd would increase decompression speed sign
Jason L Tibbitts III wrote:
>> "BC" == Ben Cotton writes:
> BC> * The recommended compression level is 19. The builds will take
> BC> longer, but the additional compression time is negligible in the
> BC> total build time and it pays off in better compression ratio than xz
> BC> lvl2 has.
>
On Wed, May 29, 2019 at 9:27 PM Josh Boyer wrote:
>
> On Wed, May 29, 2019 at 6:07 PM Neal Gompa wrote:
> >
> > On Wed, May 29, 2019 at 5:53 PM Josh Boyer
> > wrote:
> > >
> > > On Wed, May 29, 2019 at 4:20 PM Ben Cotton wrote:
> > > >
> > > > https://fedoraproject.org/wiki/Changes/Switch_RPMs
Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
> If we did this, wouldn't it make it very difficult to use tools like
> mock on RHEL / CentOS 7 to build for Fedora 3x?
Speaking of Mock:
Either the RPM on host need to understand the new format/compression **or** the
packages in @buildsys group (incl
On Wed, 2019-05-29 at 18:05 -0400, Neal Gompa wrote:
> On Wed, May 29, 2019 at 5:53 PM Josh Boyer wrote:
> >
> > If we did this, wouldn't it make it very difficult to use tools like
> > mock on RHEL / CentOS 7 to build for Fedora 3x? Or does RHEL 7 RPM
> > support zstd?
> >
>
> We're pretty mu
Last time I was about to propose this in F29, I did mass-rebuild myself and
while decompressing was faster in most of the cases, the size was
definitely worse. So definitely "Lower bandwidth on mirrors if we choose
the highest compression level" is under the question.
I think before approving such
On Wed, 2019-05-29 at 18:32 -0400, James Cassell wrote:
>
> Would this help with drpms similar to how it helps with faster yum
> repo metadata downloads? My biggest problem with drpms is the slow
> rebuild speed which is usually slower than my download bandwidth. It
> would be a big win if zstd h
On Wed, 2019-05-29 at 20:15 -0600, Chris Murphy wrote:
> 'dnf info deltarpm' says
> URL : http://gitorious.org/deltarpm/deltarpm
> which has an expired certificate, but pushing passed that it says
> current version 3.6 is 5 years old. Is this really maintained or
> updatabled?
Upstream ha
If we did this, wouldn't it make it very difficult to use tools like
mock on RHEL / CentOS 7 to build for Fedora 3x? Or does RHEL 7 RPM
support zstd?
We're pretty much screwed here. Also, since RHEL 8's rpm package does
not have zstd support compiled in, it too cannot handle the RPMs.
Hence
On Wed, May 29, 2019 at 4:07 PM Neal Gompa wrote:
>
> This is news to me, as I've never heard of any "side mass rebuilds".
> They're prohibitively expensive to do, which is why we do only one per
> release anyway.
Is it sane to test this in Rawhide now with just new builds? As things
get rebuilt
On Wed, May 29, 2019 at 2:20 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
>
> = Switch RPMs to zstd compression =
>
> == Summary ==
> Binary RPMs are currently compressed with xz level 2.
> Switching to zstd would increase decompression speed sign
On Wed, May 29, 2019 at 6:07 PM Neal Gompa wrote:
>
> On Wed, May 29, 2019 at 5:53 PM Josh Boyer wrote:
> >
> > On Wed, May 29, 2019 at 4:20 PM Ben Cotton wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
> > >
> > > = Switch RPMs to zstd compression =
> >
On Wed, May 29, 2019, at 4:20 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
>
> = Switch RPMs to zstd compression =
>
[...]
> == Benefit to Fedora ==
> * Faster installations/upgrades of user systems
> * Faster koji builds (installations in build
On Wed, May 29, 2019 at 5:53 PM Josh Boyer wrote:
>
> On Wed, May 29, 2019 at 4:20 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
> >
> > = Switch RPMs to zstd compression =
> >
> > == Summary ==
> > Binary RPMs are currently compressed with xz
On Wed, May 29, 2019 at 4:20 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
>
> = Switch RPMs to zstd compression =
>
> == Summary ==
> Binary RPMs are currently compressed with xz level 2.
> Switching to zstd would increase decompression speed sign
> "BC" == Ben Cotton writes:
BC> * The change requires setting a new compression algorithm in rpm
BC> macros. Then a mass rebuild of all packages is required.
Technically there is no harm if a mass rebuild is not done; there will
simply be no benefit for packages which aren't rebuilt. Certa
On Wed, 29 May 2019, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
= Switch RPMs to zstd compression =
== Summary ==
Binary RPMs are currently compressed with xz level 2.
Switching to zstd would increase decompression speed significantly.
...
mass
https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
= Switch RPMs to zstd compression =
== Summary ==
Binary RPMs are currently compressed with xz level 2.
Switching to zstd would increase decompression speed significantly.
== Owner ==
* Name: [[User:dmach| Daniel Mach]]
* Ema
84 matches
Mail list logo