On Tue, 2024-04-02 at 16:55 -0700, Kevin Fenzi wrote:
> On Tue, Apr 02, 2024 at 09:28:31PM +0100, Jonathan Dieter wrote:
> > * Alternatively, we could update whatever's calling createrepo_c
> > to add the `f` prefix to all non-rawhide builds.
>
> I like this option. ;)
&
On Sat, 2024-03-30 at 09:39 -0700, Kevin Fenzi wrote:
> On Fri, Mar 29, 2024 at 11:32:10PM +0000, Jonathan Dieter wrote:
> > On Wed, 2024-03-27 at 09:12 -0700, Kevin Fenzi wrote:
> > > Our next freeze is for Fedora 40 Final, currently scheduled for
> > > 2024-0
On Wed, 2024-03-27 at 09:12 -0700, Kevin Fenzi wrote:
> Our next freeze is for Fedora 40 Final, currently scheduled for
> 2024-04-02, which is NEXT TUESDAY!
Could you please update fedora-repo-zdicts to 2403.1 on the server(s)
used to generate the metadata? This will reduce the size of the
On Wed, 2023-09-06 at 22:33 +0100, Jonathan Dieter wrote:
> On Fri, 2023-08-25 at 12:42 +0100, Richard Hughes wrote:
> > The tl;dr: is I want to add a mDNS server that reshares the public
> > firmware update metadata from the LVFS on your LAN. The idea is that
> > rather than
On Fri, 2023-08-25 at 12:42 +0100, Richard Hughes wrote:
> The tl;dr: is I want to add a mDNS server that reshares the public
> firmware update metadata from the LVFS on your LAN. The idea is that
> rather than 25 users in an office downloading the same ~2MB file from
> the CDN every day, the
anning on a new release sometime this year, but there's still a
> few things they're trying to finish up first before releasing v3.13.
> Last I heard they wanted it to be out before summer.
> JT
>
> On January 28, 2023 10:14:14 AM Jonathan Dieter
> wrote:
>
> > I've
I've just orphaned lizardfs. Lizardfs is a clustered network
filesystem that has very efficient small file / metadata performance,
but hasn't seen any upstream point releases since the end of 2017 and
now FTBFS in the latest mass rebuild.
Jonathan
___
On Thu, 2022-12-01 at 00:41 +, Daniel Alley wrote:
>
> * zchunk and deltarpm both reimplement / "bundle" multiple different
> hashing algorithms
zchunk does have bundled versions of various hashing algorithms, but,
if it's compiled against OpenSSL (as it is in Fedora), it uses the
OpenSSL
On Tue, 2022-08-16 at 22:28 -0500, Maxwell G via devel wrote:
> On Tuesday, August 16, 2022 Jonathan Dieter wrote:
> > So, unless I hear from someone who wants it within the next week and
> > has a plan on how to fix the current FTBFS bug[2], on August 23, I will
> > re
In the deep mists of time, I managed to get a HP Touchpad in the Great
Fire Sale of 2011[1] and got to experiment with the Glorious System of
Operation that was webOS. Next, naturally, was packaging up novacom,
the webOS USB management tool (think the WebOS equivalent of adb), for
Fedora.
Hi everyone,
I'm orphaning deltarpm because, as it's currently used in Fedora, it's
not very effective, bugs keep getting opened against it because it's
not working as well as it should (mostly an infra issue as opposed to a
problem with the tool itself), and I no longer have the time or
On Sun, 2022-02-20 at 15:37 -0800, Adam Williamson wrote:
> On Sun, 2022-02-20 at 20:26 +0000, Jonathan Dieter wrote:
> > I've just pushed zchunk-1.2.0 to all active Fedora branches, and
> > it's
> > passed the (admittedly non-comprehensive) zchunk test suite, but
> &
I've just pushed zchunk-1.2.0 to all active Fedora branches, and it's
passed the (admittedly non-comprehensive) zchunk test suite, but I'm
seeing 2 OpenQA failed tests in Bodhi:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-e4bcaeea7a
Sorry for taking so long to reply. I'm afraid I don't check this
mailing list as often as I should. :)
On Tue, 2021-12-07 at 08:52 +0100, Aurelien Bompard wrote:
> Thanks for your input!
>
> > 1. We're using a clustered database (CockroachDB, for those who
> > care)
> > that uses optimistic
On Mon, 2021-12-06 at 18:36 +0100, Aurelien Bompard wrote:
> Anyway, this long email is about finding a common ground for
> SQLAlchemy integration in Flask, while taking into account our
> difficult experiences with webframewoks in the past, but not being
> locked in them. Is there something that
On Wed, 2021-09-08 at 09:14 -0700, Kevin Fenzi wrote:
>
> I've updated it.
>
> kevin
I can confirm that the latest F35 repodata has the dictionaries now.
Thanks so much!
Jonathan
signature.asc
Description: This is a digitally signed message part
Since branching, I've put out a new version of fedora-repo-zdicts with
dictionaries for F35 and updated dictionaries for Rawhide. This
version (2108.1) is now available in all active Fedora/EPEL branches, I
think.
Can we update fedora-repo-zdicts on the branched and rawhide composers
so they get
On Wed, 2021-06-02 at 09:35 -0700, Kevin Fenzi wrote:
> On Tue, Jun 01, 2021 at 09:13:30PM +0100, Jonathan Dieter wrote:
> > A major bug in zchunk-1.1.14 was flagged up to me today. If zchunk-
> > 1.1.14 (on a system with zstd 1.5.0+) is used to create a zck file with
> &
A major bug in zchunk-1.1.14 was flagged up to me today. If zchunk-
1.1.14 (on a system with zstd 1.5.0+) is used to create a zck file with
a zdict, the file will be impossible to decompress. Embarrassingly,
the tests weren't testing this combination.
The good news is that this doesn't affect
On Sat, 2021-04-03 at 21:46 +0100, Jonathan Dieter wrote:
> On Sat, 2021-04-03 at 11:09 -0700, Kevin Fenzi wrote:
> > ok. I've installed fedora-repo-zdicts on both branched and rawhide
> > composers.
> >
> > Lets see if that works in tomorrow's compose.
>
>
On Sat, 2021-04-03 at 11:09 -0700, Kevin Fenzi wrote:
> ok. I've installed fedora-repo-zdicts on both branched and rawhide
> composers.
>
> Lets see if that works in tomorrow's compose.
Thanks so much! Fingers crossed. :)
Jonathan
signature.asc
Description: This is a digitally signed
Right now, we're not using zdicts for the F34 zchunk metadata because
they were only added in fedora-repo-zdicts-2103.1-2 (which should now
be in the updates repo in all current Fedora releases).
If we could update fedora-repo-zdicts to 2103.1-2 on whichever servers
generate the metadata
Closed #48.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/48#event-4487171917___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
Sure. Closing now.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/48#issuecomment-803655541___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
On Sun, 2021-03-21 at 17:52 +, Jonathan Dieter wrote:
> I'm really hoping that I'm missing something obvious here, but I fear
> that a good chunk of our Fedora systems will be unbootable if they're
> rebooted without disabling raid-check.timer.
Just to follow up on this, i
On Sun, 2021-03-21 at 17:52 +, Jonathan Dieter wrote:
> There is a workaround: disabling raid-check.timer, but, if you can't
> boot due to this bug, you have to boot into single-user mode (which
> requires a root password to have been set).
As Tom Hughes just pointed out to me,
Hey everyone,
For reference, a bug report has been filed at
https://bugzilla.redhat.com/show_bug.cgi?id=1941335
I just wanted to give a heads up that I came across a bug today that
renders Fedora 33 systems unbootable, even after a clean install. If
systemd starts raid-check.timer, it gets
On Tue, 2021-01-05 at 08:49 -0500, Neal Gompa wrote:
> To be blunt, I would have never done Zchunk metadata if it was going
> to be used as a tool to kill DeltaRPMs. I firmly believe we need both
> to have a comprehensive offering that accommodates the needs of
> Fedora users across the world.
On Sat, 2021-01-02 at 18:12 +, Jonathan Dieter wrote:
> FWIW, I also think it's time for drpms to go. Aside from any potential
> issues with the proposed change, they haven't been useful in Fedora for
> three years, (see https://pagure.io/releng/issue/7215), and nobody's
> been
On Sat, 2021-01-02 at 13:42 +, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Dec 30, 2020 at 10:10:27AM -0800, Kevin Fenzi wrote:
>
> This is most likely because we are only making drpms against the most
> recent updates. So, we are making very few drpms and only against
> things
> that recently
Thanks Dusty for the pointers on the Freeze Exception process. I've
created https://bugzilla.redhat.com/show_bug.cgi?id=1886581 blocked
the Final Freeze Exception bug.
Jonathan
On Thu, Oct 8, 2020 at 8:32 PM Jonathan Dieter wrote:
>
> I'm afraid I'm late to the party on updating th
I'm afraid I'm late to the party on updating the zstd dictionaries
used by zchunk for F33. I've just built fedora-repo-zdicts-2010.1,
which now includes the F33 dictionaries, but we're obviously past
final freeze.
I would appreciate karma on the following update so it can go in as a
zero-day
On Sun, 2020-02-09 at 09:36 -0500, John Mellor wrote:
> Question for the repo managers,
>
> Why do I sometimes see invalid checksums for drpm downloads? E.g:
> This excerpt from the update this morning:
>
> > /var/cache/dnf/updates-7fc4c739b3909d9f/packages/selinux-policy-
> >
On Tue, 2019-06-04 at 18:54 -0700, Samuel Sieb wrote:
> On 6/1/19 5:27 AM, Garry T. Williams wrote:
> > On Friday, May 31, 2019 11:05:20 PM EDT Tim via users wrote:
> > > On Fri, 2019-05-31 at 17:18 -0400, Garry Williams wrote:
> > > > But, of course, the issue is why this happens in the first
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
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
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
On Thu, 2019-05-23 at 17:01 -0400, Randy Barlow wrote:
> On Thu, 2019-05-23 at 10:33 -0700, Kevin Fenzi wrote:
> > Applied. Thanks.
>
> One note: The patch to do zchunking is part of Bodhi 4.0.0, which is
> not yet in production; we plan to deploy it on Tuesday.
Unless I'm mistaken, that patch
On Sun, 2019-05-19 at 21:25 +0100, Jonathan Dieter wrote:
> The zchunk dictionaries used to reduce the size of zchunk metadata seems to
> not currently be installed on the bodhi server. This patch makes sure they
> are installed.
>
> Signed-off-by: Jonathan Dieter
> ---
>
The zchunk dictionaries used to reduce the size of zchunk metadata seems to
not currently be installed on the bodhi server. This patch makes sure they
are installed.
Signed-off-by: Jonathan Dieter
---
roles/bodhi2/backend/tasks/main.yml | 1 +
1 file changed, 1 insertion(+)
diff --git a/roles
On Sun, 2019-04-14 at 16:01 -0400, Stephen John Smoogen wrote:
> On Sat, 13 Apr 2019 at 21:06, Todd Zullinger wrote:
> > Neal Gompa wrote:
> > > If devtoolset is available for EPEL6 (which I think it is?)
> >
> > I don't believe devtoolset was enabled for el6 in koji.
> > When it was added to
On Sat, 2019-04-13 at 13:11 -0700, John Reiser wrote:
> > Unfortunately, the gcc in EL6 is too old to build zchunk
>
> In what specific way(s)? Can the complaints from gcc [which version?],
> or other tools in the toolchain, be listed here?
> Other developers may have faced the same or similar
So, the background is that I'd like to build zchunk for EPEL 6 (it's
already built for EPEL 7). Unfortunately, the gcc in EL6 is too old to
build zchunk, so I'd prefer to use a newer version from an SCL, rather
than rewrite zchunk to be compatible with an ancient version of gcc.
I noticed that
On Thu, 2019-04-11 at 18:08 -0700, Kevin Fenzi wrote:
> On 4/9/19 11:20 AM, Jonathan Dieter wrote:
> > On Tue, 2019-04-09 at 19:14 +0100, Jonathan Dieter wrote:
> > > This re-adds zchunk support for the updates and updates-testing
> > > repositories
> &g
FESCo has given us the go-ahead to turn zchunk metadata on again[1] for
the F30 fedora repository after the librepo segmentation fault bug[2]
was fixed. An updated librepo[3] was built a week ago and was pushed
to stable five days ago, so most beta users should have the new
version.
If you're
FESCo has given us the go-ahead to turn zchunk metadata on again[1] for
the F30 fedora repository after the librepo segmentation fault bug[2]
was fixed. An updated librepo[3] was built a week ago and was pushed
to stable five days ago, so most beta users should have the new
version.
If you're
On Tue, 2019-04-09 at 19:14 +0100, Jonathan Dieter wrote:
> This re-adds zchunk support for the updates and updates-testing repositories
> for both rpms and modularity.
>
> Zchunk metadata was turned off due to a broken version of librepo that made it
> out to stable, but a fixed v
on.
1: https://pagure.io/fesco/issue/2116
Signed-off-by: Jonathan Dieter
---
roles/bodhi2/backend/templates/pungi.module.conf.j2 | 3 +++
roles/bodhi2/backend/templates/pungi.rpm.conf.j2| 3 +++
2 files changed, 6 insertions(+)
diff --git a/roles/bodhi2/backend/templates/pungi.module.conf.j2
librepo-1.9.6 has a major bug that will cause a segfault when a
repository has zchunk metadata. To temporarily work around the
problem, set zchunk=False in /etc/dnf/dnf.conf or wait until the next
updates push comes out
About a week ago, we disabled zchunk metadata in the main F30
repository
librepo-1.9.6 has a major bug that will cause a segfault when a
repository has zchunk metadata. To temporarily work around the
problem, set zchunk=False in /etc/dnf/dnf.conf or wait until the next
updates push comes out
About a week ago, we disabled zchunk metadata in the main F30
repository
On Sun, 2019-03-31 at 10:37 -0700, Kevin Fenzi wrote:
> On 3/31/19 10:35 AM, Jonathan Dieter wrote:
> > On Sun, 2019-03-31 at 10:28 -0700, Kevin Fenzi wrote:
> > > On 3/31/19 1:56 AM, Jonathan Dieter wrote:
> > > > On Sun, 2019-03-31 at 09:09 +0100, Jonath
On Sun, 2019-03-31 at 10:28 -0700, Kevin Fenzi wrote:
> On 3/31/19 1:56 AM, Jonathan Dieter wrote:
> > On Sun, 2019-03-31 at 09:09 +0100, Jonathan Dieter wrote:
> > > Due to an unrelated *major* bug in the latest librepo update (
> > > https://bugzilla.redhat.com/show_bu
On Sun, 2019-03-31 at 09:09 +0100, Jonathan Dieter wrote:
> Due to an unrelated *major* bug in the latest librepo update (
> https://bugzilla.redhat.com/show_bug.cgi?id=1694411), I'd like to
> request that we disable zchunk metadata generation in updates and
> updates-testing unti
On Sun, 2019-03-31 at 05:13 +, Peter Robinson wrote:
> On Sun, Mar 31, 2019 at 6:01 AM Kevin Fenzi wrote:
> > On 3/30/19 9:50 PM, Peter Robinson wrote:
> > > > Great, thanks! I'll be keeping an eye on the composes to see if there
> > > > are any issues.
> > >
> > > Wasn't this disabled in
On Sat, 2019-03-30 at 16:00 -0700, Kevin Fenzi wrote:
> On 3/30/19 3:32 PM, Jonathan Dieter wrote:
> > On Sat, 2019-03-30 at 15:13 -0700, Kevin Fenzi wrote:
> > > On 3/30/19 11:35 AM, Jonathan Dieter wrote:
> > >
> > > > Stephen and Kevin, thanks so much!
On Sat, 2019-03-30 at 15:13 -0700, Kevin Fenzi wrote:
> On 3/30/19 11:35 AM, Jonathan Dieter wrote:
>
> > Stephen and Kevin, thanks so much!
>
> Can you rebase and attach the patch?
>
> It's not applying cleanly for me... if not I can try and manually poke
> it l
Rebased patch against master
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List
This adds zchunk support for the updates and updates-testing repositories
for both rpms and modularity
Signed-off-by: Jonathan Dieter
---
roles/bodhi2/backend/templates/pungi.module.conf.j2 | 3 +++
roles/bodhi2/backend/templates/pungi.rpm.conf.j2| 3 +++
2 files changed, 6 insertions
On Sat, 2019-03-30 at 14:05 -0400, Stephen John Smoogen wrote:
> +1
>
> On Sat, 30 Mar 2019 at 13:53, Kevin Fenzi wrote:
> > On 3/29/19 1:33 PM, Jonathan Dieter wrote:
> > > On Mon, 2019-03-11 at 20:23 +, Jonathan Dieter wrote:
> > > > On Mon, 2019-03-
On Mon, 2019-03-11 at 20:23 +, Jonathan Dieter wrote:
> On Mon, 2019-03-11 at 11:24 -0700, Kevin Fenzi wrote:
> > On 3/11/19 12:26 AM, Jonathan Dieter wrote:
> > > This adds zchunk support for the updates and updates-testing
> > > repositories for both rpms and m
On Sat, 2019-03-16 at 12:20 -0500, Michael Cronenworth wrote:
> On 3/16/19 7:10 AM, Akarshan Biswas wrote:
> > With the above stated reasons, I am willing to know your
> > suggestions/opinions on this.
> > Building with GCC has become quite a headache for me. If it goes against
> > the
On Mon, 2019-03-11 at 11:24 -0700, Kevin Fenzi wrote:
> On 3/11/19 12:26 AM, Jonathan Dieter wrote:
> > This adds zchunk support for the updates and updates-testing
> > repositories for both rpms and modularity. We already have zchunk
> > metadata being generated for the fe
-by: Jonathan Dieter
---
roles/bodhi2/backend/templates/pungi.module.conf.j2 | 3 +++
roles/bodhi2/backend/templates/pungi.rpm.conf.j2| 3 +++
2 files changed, 6 insertions(+)
diff --git a/roles/bodhi2/backend/templates/pungi.module.conf.j2
b/roles/bodhi2/backend/templates/pungi.module.conf.j2
index
On Sun, 2019-03-10 at 15:47 +, Peter Robinson wrote:
> git send-email so it's inline on the list for easy review.
Thanks for the tip! Just sent it using git send-email.
Jonathan
___
infrastructure mailing list --
This adds zchunk support for the updates and updates-testing repositories
for both rpms and modularity
Signed-off-by: Jonathan Dieter
---
roles/bodhi2/backend/templates/pungi.module.conf.j2 | 3 +++
roles/bodhi2/backend/templates/pungi.rpm.conf.j2| 3 +++
2 files changed, 6 insertions
On Sat, 2019-03-09 at 21:29 +0100, Mikolaj Izdebski wrote:
> On Sat, Mar 9, 2019 at 2:29 PM Jonathan Dieter
> wrote:
> > Hey, I just noticed that, while we have zchunked metadata for the
> > F30
> > base repository, it's not enabled to for updates-testing.
> >
>
On Sat, 2019-03-09 at 09:43 -0500, Neal Gompa wrote:
> On Sat, Mar 9, 2019 at 8:28 AM Jonathan Dieter
> wrote:
> > Hey, I just noticed that, while we have zchunked metadata for the
> > F30
> > base repository, it's not enabled to for updates-testing.
> >
>
Hey, I just noticed that, while we have zchunked metadata for the F30
base repository, it's not enabled to for updates-testing.
I've looked in the ansible repo and in pungi, but I can't see where
createrepo_c is actually called for updates-testing. Can someone
please point me in the right
On Fri, 2019-01-25 at 20:24 -0800, Gordon Messmer wrote:
> On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
> > Is there a quicker way to protect my data when I give the drives away,
> > other than smashing the drives to bits?
>
> The quickest would be to encrypt the drives from the beginning. When
On Thu, 2019-01-17 at 00:48 +0100, Björn 'besser82' Esser wrote:
> Am Mittwoch, den 16.01.2019, 22:08 + schrieb Jonathan Dieter:
> > Just a heads up Rawhide has had zchunked metadata for almost three
> > weeks, and I'd greatly appreciate some more testing on the client sid
Just a heads up Rawhide has had zchunked metadata for almost three
weeks, and I'd greatly appreciate some more testing on the client side
before we finish pushing the client changes to Rawhide.
If you're running Rawhide, are willing to test, and have backups of
libdnf and librepo, please enable
On Fri, 2018-12-14 at 15:15 -0500, Randy Barlow wrote:
> On Fri, 2018-12-14 at 19:02 +0000, Jonathan Dieter wrote:
> > Hey Randy, at the moment the --zck option *only* applies to
> > primary.xml, filelists.xml and other.xml. It should be pretty
> > straightforward to add it
On Fri, 2018-12-14 at 19:24 +, Jonathan Dieter wrote:
> On Fri, 2018-12-14 at 11:13 -0800, Kevin Fenzi wrote:
> > On 12/14/18 10:52 AM, Jonathan Dieter wrote:
> > > I suspect that the maintainers would like to see this feature tested
> > > more before pushing it
On Fri, 2018-12-14 at 11:13 -0800, Kevin Fenzi wrote:
> On 12/14/18 10:52 AM, Jonathan Dieter wrote:
> > On Thu, 2018-12-13 at 16:42 -0800, Kevin Fenzi wrote:
> > > Cool.
> > >
> > > I see the new createrepo_c only has a rawhide build... any chance for a
On Fri, 2018-12-14 at 11:20 -0500, Randy Barlow wrote:
> On Thu, 2018-12-13 at 22:56 +0000, Jonathan Dieter wrote:
> > The call to createrepo_c or mergerepo_c
> > (whichever is run last to generate the final metadata) would need to
> > be
> > run with the new zchunk argu
On Thu, 2018-12-13 at 16:42 -0800, Kevin Fenzi wrote:
> On 12/13/18 3:34 PM, Jonathan Dieter wrote:
> > On Thu, 2018-12-13 at 15:12 -0800, Kevin Fenzi wrote:
> > > pungi calls createrepo_c for us (in both rawhide/branched and updates)
> > > so we need a pungi patch (pr
On Wed, 2018-12-12 at 06:10 +, Raphael Groner wrote:
> > I've just orphaned pykka (
> > https://admin.fedoraproject.org/pkgdb/package
> > /rpms/pykka/) as I'm no longer using it.
>
> Hi Jonathan,
> what do you use instead?
> Regards, Raphael
MPD with local music.
Jonathan
On Thu, 2018-12-13 at 15:12 -0800, Kevin Fenzi wrote:
> pungi calls createrepo_c for us (in both rawhide/branched and updates)
> so we need a pungi patch (probibly with a config option?) to enable
> this. If it's added as a optional thing we would need to add that
> setting to our pungi-fedora
Createrepo_c in F30 has finally grown zchunk support and I've packaged
up some zdicts that we can use for F30/rawhide, so I'd love to see us
start building zchunk metadata for F30.
To enable zchunk metadata generation, whichever systems are running
createrepo_c/mergerepo_c for Rawhide would need
I'm currently in the process of packaging up fedora-repo-zdicts[1], a
package which will contain the zchunk dictionaries for all active
Fedora releases.
When running createrepo_c or mergerepo_c with zchunk support, the
directory containing the zdicts is passed in and createrepo_c will
choose the
On Mon, 2018-12-03 at 22:16 +0100, Jan Pokorný wrote:
> On 16/11/18 22:07 +0000, Jonathan Dieter wrote:
> > The core idea behind zchunk is that a file is split into independently
> > compressed chunks and the checksum of each compressed chunk is stored
> > in the zchunk head
On Thu, 2018-11-22 at 11:31 -0500, Josh Boyer wrote:
> I'm concerned that this will effectively render EL RPM unable to
> handle any Fedora RPMs at all. That's both a practical concern, as
> many people develop Fedora using EL and vice versa, and also a broader
> ecosystem concern. I would very
On Wed, 2018-11-21 at 14:36 +0100, Kamil Paral wrote:
> On Fri, Nov 16, 2018 at 11:13 PM Jonathan Dieter wrote:
> > For reference, this is in reply to Paul's email about lifecycle
> > objectives, specifically focusing on problem statement #1[1].
> >
> >
>
On Wed, 2018-11-21 at 11:31 -0500, Colin Walters wrote:
> After having introduced a new format (OSTree) into the ecosystem here,
> as well as working a lot on the Docker/OCI ecosystem, one thing I want
> to emphasize is:
>
> A lot of Red Hat's customers don't connect their systems to the
On Tue, 2018-11-20 at 12:45 +, Michael Schroeder wrote:
> On Mon, Nov 19, 2018 at 08:30:14PM +0000, Jonathan Dieter wrote:
> > Just to be clear on this, unlike deltarpm, zchunked rpms shouldn't
> > require extra CPU usage on the client side as they don't go through the
Hey, thanks for the detailed analysis. Comments inline.
On Tue, 2018-11-20 at 00:47 +0100, s...@gmx.com wrote:
> Based on work I've done in this area, I'm somewhat sceptical that this
> will work out well. I spent a decent amount of time comparing various
> approaches to data saving for both
On Mon, 2018-11-19 at 16:29 -0500, Simo Sorce wrote:
> On Mon, 2018-11-19 at 21:02 +0000, Jonathan Dieter wrote:
> > On Mon, 2018-11-19 at 15:18 -0500, Simo Sorce wrote:
> > > I do not think you can just trust random metadata somewhere, one of the
> > > points of a rpm
On Mon, 2018-11-19 at 22:18 +0100, Nicolas Mailhot wrote:
> Le lundi 19 novembre 2018 à 20:30 +0000, Jonathan Dieter a écrit :
> > The zchunk advantage over deltarpms is much less CPU usage, while its
> > disadvantages are slightly larger network usage and increased
On Mon, 2018-11-19 at 21:14 +, Tom Hughes wrote:
> On 19/11/2018 20:30, Jonathan Dieter wrote:
>
> > On the client:
> > The zchunk advantage over regular rpm is decreased network usage, while
> > its disadvantage is increased disk usage (since the local chunks
On Mon, 2018-11-19 at 15:18 -0500, Simo Sorce wrote:
> On Mon, 2018-11-19 at 19:58 +0000, Jonathan Dieter wrote:
> > That's an interesting thought. I was picturing using the zchunk
> > library in the dnf download stage to build a local rpm from the
> > verified lo
On Sun, 2018-11-18 at 13:19 -0500, Stephen John Smoogen wrote:
> On Sun, 18 Nov 2018 at 12:49, Neal Gompa wrote:
> > On Sun, Nov 18, 2018 at 11:54 AM Jonathan Dieter > > wrote:
> > > On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote:
> > > > Jonathan Diete
On Mon, 2018-11-19 at 20:16 +0100, Jan Pokorný wrote:
> On 19/11/18 13:13 +0100, Nicolas Mailhot wrote:
> > Le 2018-11-19 12:28, Martin Kolman a écrit :
> >
> > > Many people might think RAM would not be an issue in 2018, but in
> > > practice there are
> > > and likely always will be memory
On Sun, 2018-11-18 at 07:02 +, Leigh Scott wrote:
> +1 to anything to rid me of deltarpms, I currently have to disable
> this lame default.
The irony is that getting deltarpms into Fedora was largely my
fault. ;) Sorry, Leigh.
Jonathan
___
devel
On Mon, 2018-11-19 at 14:57 +0100, Miroslav Suchý wrote:
> Dne 16. 11. 18 v 23:07 Jonathan Dieter napsal(a):
> >1. Downloading a new release of a zchunked rpm would be larger than
> > downloading the equivalent deltarpm. This is offset by the fact
> > th
On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote:
> Jonathan Dieter wrote:
> > My proposal would be to make zchunk the rpm compression format for
> > Fedora.
>
> Given that:
> 1. zchunk is based on zstd, which is typically less efficient in terms of
>compressi
On Sat, 2018-11-17 at 14:43 -0600, Chris Adams wrote:
> Once upon a time, Jonathan Dieter said:
> > The benefit of zchunked rpms is that, when downloading an updated rpm,
> > you would only need to download the chunks that have changed from
> > what's on your system.
>
&
On Sat, 2018-11-17 at 14:36 -0500, Neal Gompa wrote:
> On Sat, Nov 17, 2018 at 1:15 PM Jonathan Dieter wrote:
> > Neal, thanks so much for your thoughts on this. Responses inline:
> >
> > On Sat, 2018-11-17 at 09:53 -0500, Neal Gompa wrote:
> >
> > >
Neal, thanks so much for your thoughts on this. Responses inline:
On Sat, 2018-11-17 at 09:53 -0500, Neal Gompa wrote:
> If we're really considering changing the RPM file format, then we need
> a proper discussion on rpm-maint@ and rpm-ecosystem@ mailing lists on
> rpm.org. Can you please start
For reference, this is in reply to Paul's email about lifecycle
objectives, specifically focusing on problem statement #1[1].
Have rpm use zchunk as its compression format, removing the need for
deltarpms, and thus reducing compose time. This will require changes
to both the rpm format and new
On Thu, 2018-11-08 at 20:35 +0100, Nicolas Chauvet wrote:
> Le jeu. 8 nov. 2018 à 19:43, Jonathan Dieter a
> écrit :
> > On Thu, 2018-11-08 at 16:57 +, Andrew Bauer wrote:
> > > I'll create a new package request for the raspberry-vc libs. I'm
> > > not
> >
1 - 100 of 556 matches
Mail list logo
