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
[EPEL-devel] Intent to update nginx to 1.20.0
Hi there, I think this has been discussed at committee meetings before: nginx's procedure of immediately dropping a release series when a new one hits the stable branches is essentially forcing us to upgrade along with it, unless someone is willing to backport patches. I personally am not willing to do backports as I do not use EL7 at this point and only continue maintaining the package as a courtesy to the community. I therefor intend to make the following changes to the nginx package in EPEL7: - Update to 1.20.0 - build against OpenSSL 1.1 to enable TLS1.3 support Do I require additional permission do move forward with this in this manner? There should not be any breaking changes or incompatible changes to config syntax. But I'll admit that I do not have complex config scenarios as testcases. EPEL8 is not affected as nginx doesn't have an EPEL build for EL8. It is maintained upstream. There are, however, modules with certain streams (1.18 and mainline, for example) available from EPEL. Regards, Felix ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-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
Orphaning php-ZendFramework
Hi fellow Fedorians, I have been intending to orphan php-ZendFramework version 1 for over a year now. It is End-of-Life, unmaintained (no updates in over 2 years), has known security issues and probably doesn't fully work with PHP 7.2 and up anymore anyway. Plus, I no longer use it and one of it's dependencies (dojo) is also orphaned and to be retired by now. There are two packages in Fedora that depend on php-ZendFramework: ganglia-web webacula Both packages seem to even rely on the old ZF upstream. So if the maintainers wish they should either start bundling ZF in those packages or also think about retiring them. Thanks, Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning vdr-streamdev
Hi, I'm orphaning vdr-streamdev since I no longer use it. There shouldn't be any open issues with this one. Also, this was the package that initially got me sponsored :) Regards, Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Orphaning dansguardian
Hi there, I'm orphaning dansguardian. Upstream has been largely dormant and I haven't been using it for several years. The package has some co-maintainers who also haven't been very active. Feel free to pick-up the package, but bear in mind it needs some fixing. Regards, Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: AppData questions
Richard Hughes wrote: It's not mandatory, but highly reccomended. See http://people.freedesktop.org/~hughsient/appdata/#screenshots for details. A little off-topic but I was wondering: The spec states Screenshots should be taken with US English as the display language.. However the spec also defines the tag for the software license to be licence / (UK English). Is this a mistake or just a matter of habit/preference? - Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [F18][ATI Rage XL] Problems with install on ATI Rage XP video driver
Adam Williamson wrote: And please do realize your graphics adapter is well over a decade old. ATI stopped posting official Windows drivers for it in 2002: http://support.amd.com/us/gpudownload/Pages/legacy-xp.aspx . Quoting from Wikipedia: It was also seen on Intel motherboards, as recently as 2004, and was still used in 2006 for server motherboards. Well, yeah, old. But not ancient ;) Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning em8300 related stuff
Hi there, I'm orphaning em8300 in Fedora and em8300-kmod in RPMFusion because I no longer own the hardware to use it. Also, it has seen little love from upstream. Feel free to take it. Regards, Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: non-responsive icon theme maintainer
Am 13.10.2011 22:26, schrieb Kevin Fenzi: I have orphaned all their packages. Please feel free to take the ones you wish. faenza-icon-theme I've taken this. Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ethernet Installation of F15 using Apache and PXE environment on another machine
Am 11.10.2011 15:20, schrieb Aaron Gray: Thanks, still needs TFTP but this could simplify things a lot. If you want to circumvent using TFTP and you are using gPXE (or a PXE boot ROM that supports booting from HTTP) you could point it to the pxelinux of boot.fedoraproject.org at http://alt.fedoraproject.org/pub/alt/bfo/pxelinux.0 for doing a netinstall. If your PXE boot ROM however doesn't support HTTP you're pretty much stuck with TFTP. Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning rubyripper
Hi there! I'm orphaning rubyripper. I don't use it anymore and it has some bug that I'm not able to fix [1]. I've updated it to the 0.6.0 release just now, for the convenience of anyone who might want to take it ;) Felix [1]: https://bugzilla.redhat.com/show_bug.cgi?id=595812 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retiring nforenum
Hi there, as soon as grfcodec-1.0.1-0.1.r772 is in stable for all branches I will retire nforenum. nforenum has recently been included in the grfcodec codebase, so there's no need to keep nforenum as a seperate package. This will probably affect nobody directly (unless you develop graphics for OpenTTD) since it is only used in the build process of openttd-opengfx. Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Asterisk 1.8 in Rawhide (F-15)
Hi Jeff! I'll start testing Asterisk 1.8 on my home server soon. Thanks for the work updating the packages. Furthermore I'd be interested in comaintaining the Asterisk stack, especially also the DAHDI package, as I plan to submit the DAHDI kmods to RPMFusion and it would be easier for me to keep stuff in sync if I had commit access. Felix Am 02.08.2010 23:35, schrieb Jeffrey Ollie: I've just built Asterisk 1.8.0 Beta 2 for Rawhide (F-15). The packages are completely untested at this point so I make no guarantees at this point about it's usability. I'll be doing some testing on my own but I'd appreciate any testing that anyone else can do. Since we have already passed F-14's feature freeze date I am very unlikely to update F-14 to Asterisk 1.8 so F-13 and F-14 will stick with 1.6.2.X until they go EOL. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Many webapps in Fedora require httpd instead of webserver
Hi there, I had a short glimpse at the review request for dojo (#609817) today and saw that it explicitly requires httpd. Well, dojo is a collection of static JavaScript files so I feel that there is no reason why it should require httpd explicitly as I don't see what special features of Apache it needs. That led me to run a repoquery --whatrequires httpd and from that I found out that many webapps that we package in Fedora explicitly require httpd. In Fedora we have a meta-provides 'webserver' that should be used instead. Especially if there is no real reason to explicitly use httpd instead. But as many of those webapps bring their own Apache configuration files for an out of the box experience I wonder how we could remedy this. Lighttpd and nginx for example have a conf.d directory, too, and maybe we could move webserver specific configuration to subpackages. Cherokee, unfortunately, lacks such option at the moment. Any comments or ideas on this topic? Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
I get the feeling that no one on this thread has looked into https://fedorahosted.org/fesco/ticket/403 So this has already been handled by FESCo, mistakes have been made and most likely will be avoided in the future. Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rt2500usb bug and kernel 2.6.34 on fc13
Am 29.06.2010 18:50, schrieb Jean-Luc Fontaine: I have the following problem on fc13: https://bugzilla.kernel.org/show_bug.cgi?id=15699 which should be fixed on the latest kernel 2.6.34, but I cannot find an rpm (/x86_64/) anywhere (for fc13 or fc14). Any ideas? Thanks! Have a look at http://koji.fedoraproject.org/koji/packageinfo?packageID=8 The fc14 ones should work for F13 as well. Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A question about locale files
Hi Robin, I'm sure a peek into http://fedoraproject.org/wiki/Packaging/Guidelines#Handling_Locale_Files will definitely help you. HTH, Felix Am 26.04.2010 17:46, schrieb Robin 'cheese' Lee: Hello! I am now dealing with a package named 'gentoo'. It installs following locale files: /usr/share/locale/de/LC_MESSAGES/gentoo.mo /usr/share/locale/es_MX/LC_MESSAGES/gentoo.mo /usr/share/locale/fr/LC_MESSAGES/gentoo.mo /usr/share/locale/it/LC_MESSAGES/gentoo.mo /usr/share/locale/ja_JP.UTF-8/LC_MESSAGES/gentoo.mo /usr/share/locale/pl/LC_MESSAGES/gentoo.mo /usr/share/locale/ru_RU.CP1251/LC_MESSAGES/gentoo.mo /usr/share/locale/ru_RU.KOI8-R/LC_MESSAGES/gentoo.mo /usr/share/locale/ru_RU.UTF-8/LC_MESSAGES/gentoo.mo /usr/share/locale/ru_RU.cp1251/LC_MESSAGES/gentoo.mo /usr/share/locale/ru_RU.koi8r/LC_MESSAGES/gentoo.mo /usr/share/locale/ru_RU.utf8/LC_MESSAGES/gentoo.mo /usr/share/locale/sv/LC_MESSAGES/gentoo.mo There are some issues here: 1. Directories like /usr/share/locale/ru_RU.* are not provided by any package. This conflicts with guidelines. 2. /usr/share/locale/ru_RU.utf8 and /usr/share/locale/ru_RU.UTF-8/ are obvious duplicates. 3. /usr/share/locale/ru_RU.UTF-8/ should be identical with /usr/share/locale/ru/, /usr/share/locale/ja_JP.UTF-8/ should be identical with /usr/share/locale/ja/ . Which is the proper way to solve these issues? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Query about usb_modeswitch and how to handle its packaging
Am 20.04.2010 09:55, schrieb Huzaifa Sidhpurwala: 2. Have two srpms one for data and one for binary, with both depending on each other. This is the way to go. It also makes it easier for you to maintain it in the future. However, you must create a new review request for the data package then. Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: potentially unmaintained packages
Hi Michael, On 14.04.2010 09:19, Michael Schwendt wrote: Why would it need to be rebuilt manually? You don't need to. If a package is working perfectly fine and no update is available there's no need to rebuild. Hey, this pkg hasn't been built, even in rawhide, in a while, maybe you should 1. check that out and 2. if the pkg is dead or unmaintained consider retiring it. It's stable, works, and is still being used by dependencies. Would I rebuild just for fun (and possibly introduce bugs related to temporary issues with compilation, RPM, or other build deps)? Again, there really is no need to. And Seth didn't say that there is a need to do so. I think he really tried hard to make his point of the list not having any implications. For my part I found this list quite useful because I almost forgot that I took over rubyripper some time ago. I had some issues with it lately and I almost filed a bug for it. I can just imagine the hilarity if that bug would have been assigned to myself directly ;) So just see this list as a service that you _can_ use. But you aren't required to use this service. Thanks Seth. Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: non-responsive maintainer: thomasvs
I talked to him on IRC three days ago and he accepted one of my bugs I filed at morituri's (a cd ripping tool of his, best there is) bugtracker. Maybe ping him on IRC. His nick is thomasvs. Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
