Re: percona-xtrabackup bundling the kitchen sink in static libs
Sven Lankes kirjoitti 26.8.2022 klo 0.03: Non-responsive maintainer policy [2]. This package has CVE bugs open [3], There was _one_ CVE bug and that was for the old version of xtrabackup that is not shipped for fedora. I have just closed that bug. The other CVEs are for EPEL builds - while I am in theory interested in fixing epel as well I won't touch it until the fedora branch is in a better state. Thank you for correcting me, and for updating bug statuses. I apologize for not checking on those bugs more closely before writing here. I had to go back and check how I ended up pasting a link that contains EPEL bugs as well. The reason: If you click on package's "Bugs" link at Fedora Packages site, you get bugs for Fedora only. If you click "Bug Reports" at Fedora Package Sources, you get bug for Fedora *and* EPEL. I must have used the latter this time. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: percona-xtrabackup bundling the kitchen sink in static libs
On Tue, Aug 23, 2022 at 11:27:55AM -0400, Paul Wouters wrote: > >[1]: https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/ > Thanks for the link. Sadly, the justification would be "because upstream > hardcoded this an errors on any other version", which in itself is > pretty weak. And since it includes boost, which can't easilly be > upgraded between fedora releases, all the older stuff lingers forever. There is a little more to it: percona-xtrabackup also comes with mysql (because it is basically running a copy of it's own mysql/innodb to do it's job - just like the other comparable versions around). And this mysql is what is "bound" to that boost version. xtrabackup just inherits this bundling. If you look at the percona-xtrabackup versioning you'll see that the current upstream release is: * percona-xtrabackup-8.0.29-22 and that refers to it's bundling of mysql 8.0.29 > >Non-responsive maintainer policy [2]. This package has CVE bugs > >open [3], There was _one_ CVE bug and that was for the old version of xtrabackup that is not shipped for fedora. I have just closed that bug. The other CVEs are for EPEL builds - while I am in theory interested in fixing epel as well I won't touch it until the fedora branch is in a better state. > Miro started the non-responsive maintainer process and woke up the > maintainer, but they themselves are also thinking it might be better > to kick it out of fedora. > https://bugzilla.redhat.com/show_bug.cgi?id=1989019 Yes - the build process is cumbersome and it is a bad fit for fedora on that alone. Yet for me it still scratches an itch and being able to do a 'dnf install percona-xtrabackup' is still useful. -- sven ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: percona-xtrabackup bundling the kitchen sink in static libs
On Tue, 23 Aug 2022, Otto Liljalaakso wrote: The relevant policy is Bundled software policy [1]. Unlike in the past, a package does not need a FESCo exception to bundle dependencies. However, the requirements of that policy are not being met here: The reason for bundling should be recorded in the specfile, and Provides: bundled(x) = 1.2.3 should be included. [1]: https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/ Thanks for the link. Sadly, the justification would be "because upstream hardcoded this an errors on any other version", which in itself is pretty weak. And since it includes boost, which can't easilly be upgraded between fedora releases, all the older stuff lingers forever. If the maintainer is not responding, you should invoke the Non-responsive maintainer policy [2]. This package has CVE bugs open [3], so most probably it should eith be retired, or somebody should start caring for it. Miro started the non-responsive maintainer process and woke up the maintainer, but they themselves are also thinking it might be better to kick it out of fedora. https://bugzilla.redhat.com/show_bug.cgi?id=1989019 Paul ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: percona-xtrabackup bundling the kitchen sink in static libs
Paul Wouters kirjoitti 23.8.2022 klo 3.07: Hi, I looked at fixing percona-xtrabackup and noticed it is staticly linking to a bunch of libraries. These .a files are then removed in %install so they are not shipped. It bundles a bunch of this stuff from its extra/ dir: duktape googletest icu libcbor libedit libevent libfido2 libkmip lz4 protobuf rapidjson robin-hood-hashing zlib zstd On top of that, it pins boost to a specific (older!) version and bundles boost seperate via dist-git / sources :( The relevant policy is Bundled software policy [1]. Unlike in the past, a package does not need a FESCo exception to bundle dependencies. However, the requirements of that policy are not being met here: The reason for bundling should be recorded in the specfile, and Provides: bundled(x) = 1.2.3 should be included. [1]: https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/ I've just fixed it up in the same bad way, making it link to the old openssl just to get it past F35FailsToInstall for rhbz#1989019. It is going through rawhide and the branches now. But I think perhaps this package should be removed from rawhide. This package clearly breaks a lot of packaging rules, so I was wondering if there was ever any exception of some kind given to this package? I will definitely look at $dayjob migrating away from this, eg see if myhoard or mariabackup can be used instead. Any feedback would be appreciated, as it seems the maintainer is MIA. If the maintainer is not responding, you should invoke the Non-responsive maintainer policy [2]. This package has CVE bugs open [3], so most probably it should eith be retired, or somebody should start caring for it. [2]: https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ [3]: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=percona-xtrabackup=Fedora=Fedora%20EPEL ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
percona-xtrabackup bundling the kitchen sink in static libs
Hi, I looked at fixing percona-xtrabackup and noticed it is staticly linking to a bunch of libraries. These .a files are then removed in %install so they are not shipped. It bundles a bunch of this stuff from its extra/ dir: duktape googletest icu libcbor libedit libevent libfido2 libkmip lz4 protobuf rapidjson robin-hood-hashing zlib zstd On top of that, it pins boost to a specific (older!) version and bundles boost seperate via dist-git / sources :( I've just fixed it up in the same bad way, making it link to the old openssl just to get it past F35FailsToInstall for rhbz#1989019. It is going through rawhide and the branches now. But I think perhaps this package should be removed from rawhide. This package clearly breaks a lot of packaging rules, so I was wondering if there was ever any exception of some kind given to this package? I will definitely look at $dayjob migrating away from this, eg see if myhoard or mariabackup can be used instead. Any feedback would be appreciated, as it seems the maintainer is MIA. Paul ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
