Re: Status of AVIF support in Fedora
Hi there, On 2023-03-19 08:14, Sandro wrote: Dominik, since you picked up the RPMFusion package, which conflicts with the new Fedora package, could you bring me up to speed what needs (is planned to) happen with the RPMFusion package The Fedora packaged libheif came through as a stable update yesterday, replaced the RPMFusion one and broke my ability to work with any HEIC encoded images with no way of installing a version that works from RPMFusion. I understand that RPMFusion is not an officially supported or endorsed repository. Given that there seems to have been at least some effort in trying to coordinate this I was wondering if it was intentional to move forward without having fully coordinated an RPMFusion split-package scenario? Regards, Felix ___ 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: Fedora rawhide compose report: 20210909.n.0 changes
Hi there, On 2021-09-09 10:07 a.m., Zbigniew Jędrzejewski-Szmek wrote: On Thu, Sep 09, 2021 at 12:10:45PM +, Fedora Rawhide Report wrote: OLD: Fedora-Rawhide-20210908.n.0 NEW: Fedora-Rawhide-20210909.n.0 = DOWNGRADED PACKAGES = Package: nginx-1:1.20.1-6.module_f36+12925+96924a12 Old package: nginx-1:1.21.2-1.module_f36+12850+d1961063 [...] 1.21.2 to 1.20.1 ? Looks like a bug in the reporting scripts maybe? Not sure. I built new modules in the 1.20 and mainline (version 1.21.3 at this time) stream yesterday. So maybe the reporting script got confused. The rawhide branch in Git looks fine to me. It has the latest stable version of nginx, 1.20.1 at this time, and the latest version of the specfile including the dynamic module changes from Neal. If you simply compare NEVR then the latest version (1.21.3) lives only in the stream-mainline branch as the mainline branch is not considered a stable release train by upstream. This branch is only built as a module and shouldn't interfere with non-modular installs that only get the latest stable version. Also, when I look at https://src.fedoraproject.org/rpms/nginx, the description is: [... lots of unformatted text from README.dynamic ...] That is due to the fact that Pagure will try to Markdown render anything that starts with README. A recent commit adding capabilities to build dynamic modules out of tree added a file called README.dynamic that is not Markdown formatted. This is what Pagure picks up. Thanks for pointing this out, I otherwise would probably have missed this. Regards, Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Call for testing: nginx 1.20.0 with permission changes on logs
Dear Fedorans, Nginx 1.20.0 stable was just released and I took the opportunity to squash some long standing open bugs while updating the package. The new release is on it's way to updates-testing right now. I would like to encourage some extra testing for this release as there is one behaviour change, specific to Fedora/EPEL, that may affect some use cases: The ownership and mode of the log directory has changed to root:root and 700 respectively. Logrotate (if in use) no longer creates the logfiles when rotating and leaves this to nginx which will create them as root:root-owned. This matches the behaviour of httpd in Fedora. You may see the effects of this if you are using external tools to process these logs that do not run as root, but as the nginx user instead. The bugs relating to this are: - BZ#1390183 CVE-2016-1247 nginx: Local privilege escalation via log files [fedora-all] - BZ#1683388 Log file ownership created by logrotate inconsistent with the one created by systemd In my local testing I have not seen any changes to behaviour but I would like to make extra sure everything continues to work as expected for users as this version of the package will make it's way to EPEL 7 as well to replace the EOL version of nginx that is currently packaged there. Quite a number of other bugs that I deem to have no effect on simple upgrades have made it's way into this release of the package as well. Specifically: - BZ#1565377 Service reload should check configuration file - BZ#1708799 Drop nginx requirement on nginx-all-modules - BZ#1834452 Enable --with-compat configure option - BZ#1869026 nginx.service fails to parse /run/nginx.pid - BZ#1943779 nginx.service wants wrong network target - causes race condition on boot Here are the links to Bodhi for this update. Please test these releases and provide feedback/karma. Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3aa9ac7fd1 Fedora 33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-10c1cd4cba Fedora 32: https://bodhi.fedoraproject.org/updates/FEDORA-2021-1556d440ba Thanks a ton! Regards, Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
How to handle nginx 3rd party modules?
Fedorans, I am the maintainer of the nginx package in Fedora and EPEL. Currently I have two bug reports [1][2] open against nginx that ask for the inclusion of 3rd party extensions into the nginx main package. Unlike the Apache httpd, the nginx codebase does not allow modules to be built out-of-tree. This means that any and all modules you would want to use with nginx would have to be built against the same source tree using the same configure arguments used to build the main nginx package In fact, ideally together with the main nginx package. This means introducing external codebases into the nginx build tree. A few options as to how this could be addressed: 1. Bundle and ship the 3rd party modules in the main nginx package. Debian does this [3]. Debian also has a team of maintainers for nginx. In Fedora it is mainly me at this point. It increases the burden to package nginx because now I also need to track updates, CVEs and patches for these submodules and ensure they build against whichever update we are packaging at any given time. As I don't use any additional modules on my nginx installs I would not be willing to test each and every module additionally to the main package. 2. Offer a module of the main package that includes all the modules people may want. This is essentially duplicating the effort of packaging nginx but this way it wouldn't interfere with the main package too much. Also, this means someone else could take care of it. The question would then be: Do we do this for both the stable and mainline branch? 3. Use the packaging method used in this [4] COPR The method used here is simply to duplicate the building of nginx into each module separately and at the end of the build process only fish out the module file itself, plus any configuration and docs provided by the module. This option is elegant in that it generates separate packages and can be maintained in separate spec files but it requires all modules to be rebuilt or updated together with any new nginx package that is built as the modules would need to depend on the nginx package's NEVRA. This would make updating nginx quite the pain, I assume. 4. Not do it at all. As a compromise I could look to amend the current spec file to make it obvious how to build additional modules into your own version of the package. Anyone would then be free to maintain their own personal repository (possibly on COPR) to override the official packages. So I'd appreciate some input here as to what the best way forward would be from a distribution engineering perspective. Regards, Felix [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1654698 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1768317 [3]: https://salsa.debian.org/nginx-team/nginx/-/tree/master/debian/modules [4]: https://copr.fedorainfracloud.org/coprs/mtorromeo/nginx-modules-el7/ ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Unresponsive Maintainer: bpereto
Hi fellow Fedorans, I'm trying to contact Benjamin Pereto (FAS: bpereto), maintainer of borgbackup and borgmatic. https://src.fedoraproject.org/user/bpereto https://src.fedoraproject.org/rpms/borgmatic I have started the non-responsive maintainer process as borgmatic has not seen an update in over a year and is currently suffering from broken dependencies and some packaging problems (such as not building for noarch). I am maintaining an updated and fixed version here: https://copr.fedorainfracloud.org/coprs/heffer/borgmatic/ Borgbackup has an active co-maintainer but borgmatic does not. I filed the corresponding non-responsive maintainer bug here: https://bugzilla.redhat.com/show_bug.cgi?id=179 If anyone knows how to contact Benjamin, please let me know. I sent an email to his personal e-mail address about two months ago but received no response. Regards, Felix ___ 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
Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
On 2019-07-22 2:51 p.m., Ben Cotton wrote: After preliminary discussions with CPU vendors, we propose AVX2 as the new baseline. AVX2 support was introduced into CPUs from 2013 to 2015. See [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2 CPUs with AVX2]. Here's a JSON file of all Intel CPUs that do not have any AVX extension support that were released after January 1, 2013: https://odata.intel.com/API/v1_0/Products/Processors()?&$filter=not%20substringof(%27AVX%27,InstructionSetExtensions)%20and%20LaunchDate%20gt%20DateTime%272013-01-01T00:00:00.00Z%27&$format=json There are Pentium and Celeron CPUs being released today that don't even support AVX. Felix ___ 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
