>[1] https://github.com/facebook/zstd/issues/395#issuecomment-535875379
> .
>If that was part of zstd or even actively being looked at, then yes.
I mean, per your own comment on that thread, the API *is* available and it's in
zstd, but no frontend supports it yet.
And per the maintainer's
It's not possible to simply substitute one for another universally, there's no
"Fedora default", it's something that would need to be handled on a
package-by-package basis.
As long as there are existing xz-compressed files in the wild, Fedora will need
to support consuming them - as long as
It was unreasonable before zlib-ng too [0], but zlib-ng does make it a slightly
bigger issue.
[0] https://github.com/rpm-software-management/createrepo_c/pull/336
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email
It's not how free software works, but there are some interesting projects
working on (distributed, not centrally managed) code review systems that are
kind of similar in spirit to what OP describes.
https://github.com/crev-dev/crev
https://github.com/crev-dev/cargo-crev
It appears that libsystemd links to libraries for lzma/xz, bzip2, gzip and also
zstd, because some systemd utilities provide them as options in various
different contexts (but not consistently, zstd for instance is seemingly
supported by some utilities and not by others, and I see some code
This might be a good place to start
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1936
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
>ry xz -9, it should be better than zstd. It will take longer to compress, but
>should actually be FASTER (!) to decompress, which is what really matters.
Please provide data - any data - to support this claim, because it flies
completely in the face of every benchmark the internet has to
One more point: createrepo_c uses zstd compression level 10, but the range goes
all the way up to level 22. I would oppose making the default much
computationally heavier than it is currently, but if spending 20x longer to
compress the repo 10% more is desirable to the fedora project, then
Also, to use that squash benchmark you will probably want to run it yourself
with modern libraries and modern hardware, as the data on their website
(assuming it's the same as the data in their github repo) is 8+ years old.
zstd has improved a fair bit during that timeframe.
--
But we're not compressing text, we're compressing XML.
Anyway, I ran an experiment on a local copy of the Fedora 38 release repo and
the differences (while they do exist) aren't very significant. Less than 10%
createrepo_c --update --skip-stat --recycle-pkglist --general-compress-type gz .
> Except that it's not 100% compatible, since all those packages aren't
> building/working with zlib-ng-compat. At a minimum, you should be able
> to show that everything zlib-dependent successfully rebuilds with this,
> and since you've already identified some that don't, IMO they should be
>
>There are arguments
> about whether it's appstream-builder specific (given that Debian's
> archive is bigger, their package format is more complex to "pluck"
> from, etc and appstream-generator does fine there), but the point is
> that for Fedora with appstream-builder, it's too slow. Note that
Will this be posted soon?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
Yeah, the Zstd default of 3 is tuned to be roughly on par with alternatives but
much faster. To get better compression than gzip you generally need to go to
higher levels.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
> The background to this is I've spent far too long trying to optimize
> the conversion of qcow2 files to raw files. Most existing qcow2 files
> that you can find online are zlib compressed, including the qcow2
> images provided by Fedora. Each cluster in the file is separately
> compressed as a
As far as I can tell it's mostly legacy removal and adoption of (now)
standardized types, such as "z_size_t" being replaced by "size_t"
There is a document here that tries to describe the different considerations:
https://github.com/zlib-ng/zlib-ng/blob/develop/PORTING.md
"The zlib-ng native
The zlib-ng 2.1 beta, apparently, has some significant further enhancements
coming down the pipe. So the potential is there for users to see improvements
much greater than 40% eventually.
https://www.phoronix.com/news/Zlib-ng-2.1-Beta
"With zlib-ng 2.1 beta there is upwards of 56% faster
Also to that point, the compatibility issues aren't always compatibility
issues, but rather poorly written tests. For example, some tests might
hardcode an expected checksum [0] for the compressed output, which could be
broken by any number of changes even if the compressed output is entirely
>In my test zlib-ng is about 40% faster.
I did some testing with zlib-ng and createrepo-c a few months ago [0], and I
also found that the compression portion of the workload was about 40% faster.
So this matches my experience, too.
(BTW, if that github comment [0] sounds negative, it isn't
> If one uses OpenPGP and if people verify it
As you mention, that's a big "if"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
>and in 1-2 years, SHA256
I've not seen any speculation much less evidence about sha256 being insecure.
Is this a post-quantum-crypto thing?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
> - When adding groups.xml to repodata createrepo_c currently adds two
> variants to repomd.xml. The specified file as is, uncompressed, with
> the type "group" and also a compressed variant with type "group_XX",
> where XX is compression suffix. This is atypical and unexpected. We
> propose to
I am not sure whether by "all historical updates" you are only referring to all
updates being listed in updateinfo.xml, or all history generally (including old
packages). But in the latter case, note that keeping all updates massively
inflates the storage requirements for maintaining a copy of
Are you saying that DNF does an exact version match instead of making the
assumption that packages with version >= X contain a fix for a security bug
which the updateinfo declares to be fixed in X? Or that the updateinfo itself
gets purged of advisories that don't apply to the latest versions
Well, regarding the "based on something", you can hand off a list of packages
to createrepo_c with --pkglist, and avoid the need to download files with
--update + --skip-stat. Unfortunately that doesn't help you with the package
file management. In a vacuum --baseurl would help here because
A neat thing you can play around with is the color profiles, you can have
kernel stack frames in one color, C / C++ userspace stack frames in another
color, Java / Node / Python stack frames in another color, etc.
https://www.brendangregg.com/blog/2017-07-30/coloring-flamegraphs-code-type.html
Perhaps this would be amenable to a blog post demonstrating the benefits? e.g.
* What does the system performance analysis process look like, how to get
started
* What impacts does the lack of frame pointer information have on the outputs
(incoherent / invisible / inaccurate data), and how
> Daniel Alley wrote:
>
> But it can be in the function CALLING such a function, and said function
> will be completely missing from the backtrace.
>
> Quoting your link
> [https://developer.arm.com/documentation/dui0774/k/Compiler-Command-line-O...]:
The quotation says
> Hi,
>
> to those who are pushing the -fno-omit-frame-pointer change: Are you aware
> that neither that flag nor even -mno-omit-leaf-frame-pointer actually
> guarantee that every leaf function is going to carry a frame pointer, as
> required for your backtraces?
This feels slightly too
I will always applaud any attempt at standardizing & documenting the metadata
format, and I was never thrilled with glib, so this sounds great to me - I only
wish that it had been this way from the beginning :)
In practice I am not certain that Satellite (and similar tools) can prefer the
XML
I'm quite not sure how one would go about empirically measuring something like
that - at least in the general case. It might be an interesting research
topic. So no, unfortunately I don't really have hard evidence for this.
I just know that of all the C libraries I've looked at, in my personal
> I think almost all of these qualify as "Core system libraries that
> pretty much everything depends on.".
> Building their C dependencies from vendored copies (if that is even
> supported) and statically linking them seems like a pretty bad idea in
> almost all cases here, especially for things
> Do I really need to explain this point? I think linking against system
> OpenSSL is *way better* than statically linking to a random vendored
> copy of it.
There are maybe about 100-120 libraries for which this is obviously the case.
openssl, glibc, glib2, zlib, libxml2, libcurl, kde
> Is there any guide that explains fields of the updateinfo.xml files
> which are generated in repositories?
I very much wish there was, but alas, no. Pretty much everything to do with
rpm metadata is effectively implementation-defined, and the implementations are
all different, especially
> On 11/1/22 07:38, Dominique Martinet wrote:
>
> Has adding kernel support for DWARF unwinding been considered instead?
The references of the proposal has some discussion on this subject. Basically,
this was already considered and rejected by the kernel developers including
Torvalds directly
> The reason this bug isn't hitting RHEL right now is simply just because the
> default
RHEL repositories are much smaller - also crucially things like many -devel
packages are
in a separate repository.
RHEL actually is hitting this issue in different contexts for an entirely
different reason
> Unfortunately, no, there's no in-kernel DWARF unwinder due to the complexity
> involved.
> Instead, the kernel uses ORC and has an unwinder for that. Adding ORC support
> to all of
> Linux userspace so that we can unwind it in the kernel isn't likely to
> happen, since
> all tooling would
That's a fair point, I was actually not aware that
https://github.com/rpm-software-management/drpm contained a completely separate
implementation of applydeltarpm.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
> On Wed, Aug 11, 2021 at 10:03:50PM +0200, Marek Marczykowski-Górecki wrote:
> I do think we should drop drpms or make them more useful, but I don't
> think there's any security angle here. (see below)
>
> drpms work by downloading the delta, then using it + the version you
> have installed to
39 matches
Mail list logo
