[Bug 2150051] perl-Log-Dispatchouli-3.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2150051 Jitka Plesnikova changed: What|Removed |Added Fixed In Version||perl-Log-Dispatchouli-3.001 ||-1.fc38 Resolution|--- |RAWHIDE Status|ASSIGNED|CLOSED Last Closed||2022-12-05 07:44:56 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2150051 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Log-Dispatchouli] PR #2: 3.001 bump
jplesnik merged a pull-request against the project: `perl-Log-Dispatchouli` that you are following. Merged pull-request: `` 3.001 bump `` https://src.fedoraproject.org/rpms/perl-Log-Dispatchouli/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Log-Dispatchouli] PR #2: 3.001 bump
jplesnik opened a new pull-request against the project: `perl-Log-Dispatchouli` that you are following: `` 3.001 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Log-Dispatchouli/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
On Mon, Dec 5, 2022 at 12:02 AM Adam Williamson wrote: > > On Sun, 2022-12-04 at 19:27 +, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > The examples you provide are definitely interesting. They all > > > essentially boil down to, well, "I know exactly how this process works > > > and I'm gonna take advantage of that to achieve the right outcome > > > behind the scenes". > > > > Yeah, those four examples are very good. But they all can be summed up as > > "we need this update that is in updates-testing (or possibly will soon be > > there) > > to apply to all subsequent builds". Thus, maybe it would be enough to > > replace > > buildroot overrides with a single switch that says "make this update visible > > in the buildroot *now*". > > Isn't that...what a buildroot override *is*, though? Yes, but I guess the idea is that the workflow is simplified to allow you to submit an update and an override in one go. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
On Sun, 2022-12-04 at 19:27 +, Zbigniew Jędrzejewski-Szmek wrote: > > > > The examples you provide are definitely interesting. They all > > essentially boil down to, well, "I know exactly how this process works > > and I'm gonna take advantage of that to achieve the right outcome > > behind the scenes". > > Yeah, those four examples are very good. But they all can be summed up as > "we need this update that is in updates-testing (or possibly will soon be > there) > to apply to all subsequent builds". Thus, maybe it would be enough to replace > buildroot overrides with a single switch that says "make this update visible > in the buildroot *now*". Isn't that...what a buildroot override *is*, though? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ 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: Review Request: ImageMagick7
On Sun, Dec 4, 2022 at 10:06 PM Richard Shaw wrote: > > On Sun, Dec 4, 2022 at 6:32 PM Sérgio Basto wrote: >> >> Final statement, instead of wasting my time and energy on arguments, >> Imagemagick7 could already be built on rawhide if someone had done the >> package review for me > > > I understand the sentiment as another person who has donated 1000s of hours > to packaging on Fedora, but the "default" package SHOULD be the current > latest package. It' just part of "Fedora First". > > So my vote (as much as it matters) is that all packages should be built with > the latest version in COPR to verify compatibility, and the ones that don't, > build with an ImageMagik 6 compat package. > I've got this mostly worked out now: https://copr.fedorainfracloud.org/coprs/ngompa/ImageMagick7-dev/ There are five failures: * autotrace - plan to notify upstream * dvdauthor - point to GraphicsMagick or IM6, plan to notify upstream * q - dead upstream, planned to point to IM6 * vdr-skinnopacity - current upstream dead, plan to notify new upstream * vdr-tvguide - plan to notify upstream I've got an IM6 compat package made (forked from current IM): https://copr.fedorainfracloud.org/coprs/ngompa/ImageMagick7-dev/build/5081492/ -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Review Request: ImageMagick7
On Sun, Dec 4, 2022 at 7:32 PM Sérgio Basto wrote: > > On Sun, 2022-12-04 at 17:14 -0500, Neal Gompa wrote: > > On Sun, Dec 4, 2022 at 5:07 PM Sérgio Basto > > wrote: > > > > > > On Sun, 2022-12-04 at 14:33 -0500, Neal Gompa wrote: > > > > On Sun, Dec 4, 2022 at 9:39 AM Stephen Smoogen > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Sat, 3 Dec 2022 at 11:55, Neal Gompa > > > > > wrote: > > > > > > > > > > > > On Sat, Dec 3, 2022 at 11:25 AM Sérgio Basto > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel > > > > > > > wrote: > > > > > > > > On 03/12/2022 00:30, Sérgio Basto wrote: > > > > > > > > > The proposal now is to keep ImageMagick 6 and make a > > > > > > > > > new > > > > > > > > > package > > > > > > > > > with > > > > > > > > > ImageMagick 7 , when we have all applications use only > > > > > > > > > ImageMagick > > > > > > > > > 7, > > > > > > > > > we move the sources from ImageMagick7 to ImageMagick > > > > > > > > > > > > > > > > I think it would be better to update the ImageMagick > > > > > > > > package > > > > > > > > to > > > > > > > > version > > > > > > > > 7 and create a compatibility package ImageMagick6. > > > > > > > > > > > > > > Anyone is going to review the package or not ? > > > > > > > > > > > > > > I already explain the situation in the other emails on this > > > > > > > thread . > > > > > > > > > > > > > > I estimate that I will need about 200 hours to do what your > > > > > > > brilliants > > > > > > > minds ask . > > > > > > > > > > > > > > > > > > > Really? "200 hours"? Not a chance. Upgrading ImageMagick to > > > > > > v7 > > > > > > and > > > > > > > > > > > > > > > Patches please, Neal to help Sergio cut it down then. He is > > > > > saying > > > > > he needs that time to make it work for all the problems he is > > > > > seeing. Your commentary and others are coming across as > > > > > lambasting > > > > > him when he is wanting help. While your and other comments > > > > > seem > > > > > clear to you.. code would be clearer. > > > > > > > > > > > > > Sure. I've prepared a pull request for ImageMagick itself: > > > > https://src.fedoraproject.org/rpms/ImageMagick/pull-request/10 > > > > > > > > And I'm preparing a COPR to rebuild the reverse dependencies and > > > > work > > > > through the breakages (if any): > > > > https://copr.fedorainfracloud.org/coprs/ngompa/ImageMagick7-dev/ > > > > > > I already state why I against this approach , don't forget, before > > > merge this PR, you need do the compat-ImageMagick6912 or something, > > > like [1] > > > > > > > Sure, an ImageMagick6 package as a compatibility package is easy > > enough to do. > > > > > And this will delay a lot adding ImageMagick7 to epel9 and epel8 > > > > > > > No, it wouldn't. You could upgrade ImageMagick and add the > > ImageMagick6 compat package there too and be fully compliant without > > extra effort. > > With a lot more of time , energy , attention you can, but if you think > it won't break anything you are wrong and I don't want stresses, > eventually in a second phase I would do the same as you propose. > > I don't understand what advantages it brings do a compat ImageMagick to > do a new ImageMagick version. > There are four big advantages: 1. The newest version is default, which means as software comes in and/or gets upgraded, it gets validated against ImageMagick 7. 2. Things that can't work with the newer version will be easily explicitly marked as such, rather than implicitly so. 3. The ecosystem gets dragged forward as ImageMagick 7 is exposed as the default to people. 4. It matches upstream intent (ImageMagick = IM7, ImageMagick6 = IM6) > Final statement, instead of wasting my time and energy on arguments, > Imagemagick7 could already be built on rawhide if someone had done the > package review for me > For what it's worth, I am literally working through the dependency chain of things that link to ImageMagick in Fedora and fixing things. I've been doing it in between other tasks I'm working on today and have mostly qualified everything in Fedora. I've been comparing notes with PLD and openSUSE, who have both moved to ImageMagick 7 by default years ago. Smooge challenged me earlier in this conversation to provide patches and effort, and I'm doing just that. The two RPM Fusion reverse dependencies (OpenShot and xine-lib) can move to Fedora now since all their dependencies are available in Fedora proper (and EPEL 9), so I have popped both off the list to add to the other list of things to move from RPM Fusion. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
Re: Review Request: ImageMagick7
On Sun, Dec 4, 2022 at 6:32 PM Sérgio Basto wrote: > Final statement, instead of wasting my time and energy on arguments, > Imagemagick7 could already be built on rawhide if someone had done the > package review for me > I understand the sentiment as another person who has donated 1000s of hours to packaging on Fedora, but the "default" package SHOULD be the current latest package. It' just part of "Fedora First". So my vote (as much as it matters) is that all packages should be built with the latest version in COPR to verify compatibility, and the ones that don't, build with an ImageMagik 6 compat package. Thanks, Richard ___ 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
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-8f2df2e1e2 botan2-2.19.3-1.el9 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-48ffd03f66 snapd-2.57.6-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing bdii-5.2.26-10.el9 coturn-4.6.1-1.el9 ipv6calc-4.0.2-67.el9 libbsd-0.11.7-2.el9 livesys-scripts-0.3.1-1.el9 python-aiohttp-3.8.3-4.el9 python-mapbox-earcut-1.0.1-1.el9 python-w3lib-2.0.1-1.el9 rust-async-trait-0.1.59-1.el9 rust-easy-parallel-3.2.0-3.el9 rust-libc-0.2.138-1.el9 rust-polling-2.5.1-1.el9 rust-scoped-tls-1.0.1-1.el9 rust-simdutf8-0.1.4-2.el9 rust-syn-1.0.105-1.el9 rust-time-0.3.15-2.el9 rust-time-macros-0.2.4-3.el9 rust-tokio-macros-1.8.2-1.el9 rust-trybuild-1.0.72-1.el9 Details about builds: bdii-5.2.26-10.el9 (FEDORA-EPEL-2022-afaad8b85a) The Berkeley Database Information Index (BDII) Update Information: Migrate to slapd mdb backend to support openldap 2.5+ ChangeLog: * Sun Dec 4 2022 Mattias Ellert - 5.2.26-10 - Use mdb slapd backend (Fedors 36+, EPEL 9+) * Wed Jul 20 2022 Fedora Release Engineering - 5.2.26-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild References: [ 1 ] Bug #2150344 - bdii fails to start with openldap-servers >= 2.6 https://bugzilla.redhat.com/show_bug.cgi?id=2150344 coturn-4.6.1-1.el9 (FEDORA-EPEL-2022-4ff3d4b8f2) TURN/STUN & ICE Server Update Information: # Coturn 4.6.1* Fix memory corruption on socket close ChangeLog: * Sun Dec 4 2022 Robert Scheck - 4.6.1-1 - Upgrade to 4.6.1 (#2150608) References: [ 1 ] Bug #2150608 - coturn-4.6.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=2150608 ipv6calc-4.0.2-67.el9 (FEDORA-EPEL-2022-7040b25655) IPv6 address format change and calculation utility Update Information: Final release 4.0.2 ChangeLog: * Sun Dec 4 2022 Peter Bieringer - 4.0.2-67 - Final release 4.0.2 libbsd-0.11.7-2.el9 (FEDORA-EPEL-2022-13cfdabccc) Library providing BSD-compatible functions for portability Update Information: # libbsd 0.11.7 - Portability fixes for the Hurd - Fix ELF support for big endian SH - Sync the `arc4random(3)` implementation from OpenBSD - Adjust declaration shadowing to match new glibc additions - Manual pages and documentation cleanups - Manual page rewrite to get rid of a BSD-4-Clause license # libbsd 0.11.6 - Build system and test suite fixes for musl - Removal of unused OpenBSD support for `arc4random()` - LoongArch support for `nlist()` # libbsd 0.11.5 - Build system and test suite regression fixes - Documentation on how to build the project # libbsd 0.11.4 - Further rework of the libmd wrapping code, to simplify it again, and make it work even when we do not need SHA-2 functions - Fix builds with LTO - Various build system fixes - Various portability fixes - Various documentation fixes # libbsd 0.11.3 - Rework of the libmd wrapping code to not require users to explicitly link against libmd - Various build system fixes - Various portability fixes # libbsd 0.11.2 - Update `` from FreeBSD - Import some `closefrom()` changes from sudo - Make `closefrom()` use `close_range()` syscall on Linux when available - Update `libbsd(7)` man page with updates in 0.11.0 # libbsd 0.11.0/0.11.1 - Export `strnvisx()` function - New `recallocarray()` and `freezero()` from OpenBSD - New pwcache module from OpenBSD - New `timespec(3bsd)` man page alias to `timeval(3bsd)` - New progname implementation for Windows - New
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-d9f41aade7 snapd-2.57.6-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing coturn-4.6.1-1.el8 ipv6calc-4.0.2-67.el8 libbsd-0.11.7-2.el8 livesys-scripts-0.3.1-1.el8 Details about builds: coturn-4.6.1-1.el8 (FEDORA-EPEL-2022-2ff3256e38) TURN/STUN & ICE Server Update Information: # Coturn 4.6.1* Fix memory corruption on socket close ChangeLog: * Sun Dec 4 2022 Robert Scheck - 4.6.1-1 - Upgrade to 4.6.1 (#2150608) References: [ 1 ] Bug #2150608 - coturn-4.6.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=2150608 ipv6calc-4.0.2-67.el8 (FEDORA-EPEL-2022-6da3f24ff5) IPv6 address format change and calculation utility Update Information: Final release 4.0.2 ChangeLog: * Sun Dec 4 2022 Peter Bieringer - 4.0.2-67 - Final release 4.0.2 libbsd-0.11.7-2.el8 (FEDORA-EPEL-2022-08012668ea) Library providing BSD-compatible functions for portability Update Information: # libbsd 0.11.7- Portability fixes for the Hurd - Fix ELF support for big endian SH - Sync the `arc4random(3)` implementation from OpenBSD - Adjust declaration shadowing to match new glibc additions - Manual pages and documentation cleanups - Manual page rewrite to get rid of a BSD-4-Clause license # libbsd 0.11.6 - Build system and test suite fixes for musl - Removal of unused OpenBSD support for `arc4random()` - LoongArch support for `nlist()` # libbsd 0.11.5 - Build system and test suite regression fixes - Documentation on how to build the project # libbsd 0.11.4 - Further rework of the libmd wrapping code, to simplify it again, and make it work even when we do not need SHA-2 functions - Fix builds with LTO - Various build system fixes - Various portability fixes - Various documentation fixes # libbsd 0.11.3 - Rework of the libmd wrapping code to not require users to explicitly link against libmd - Various build system fixes - Various portability fixes # libbsd 0.11.2 - Update `` from FreeBSD - Import some `closefrom()` changes from sudo - Make `closefrom()` use `close_range()` syscall on Linux when available - Update `libbsd(7)` man page with updates in 0.11.0 # libbsd 0.11.0/0.11.1 - Export `strnvisx()` function - New `recallocarray()` and `freezero()` from OpenBSD - New pwcache module from OpenBSD - New `timespec(3bsd)` man page alias to `timeval(3bsd)` - New progname implementation for Windows - New `LIBBSD_VIS_OPENBSD` selection macro - Switch from embedded hashing function implementations to use libmd - Various man pages cleanups - Various portability fixes - Various memory leak fixes # libbsd 0.10.0 - Several security related fixes for `nlist()` - Preliminary and partial Windows porting - Fix for a leak in the vis family of functions - Fix for a configure check to not unnecessarily link against librt - General portability fixes for musl, uClibc, macOS and GNU/kFreeBSD - New architectures support for `nlist()` - Switch the `` `*c()` functions to be standalone and add `err()`, `warn()`, `errx()` and `warnx()` familiy of functions in case the system lacks them - Several man page fixes ChangeLog: * Sun Dec 4 2022 Mikel Olasagasti Uranga - 0.11.7-2 - Add runtime requirement on libmd-devel to libbsd-devel (#2148612) * Thu Nov 24 2022 Robert Scheck - 0.11.7-1 - Update to 0.11.7 (#1742611) * Thu Jul 21 2022 Fedora Release Engineering - 0.10.0-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Thu Jan 20 2022 Fedora Release Engineering - 0.10.0-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Thu Jul 22 2021 Fedora Release Engineering - 0.10.0-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Tue Jan 26 2021 Fedora Release Engineering - 0.10.0-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild *
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-63588ab702 woff-0.20091126-11.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-058d69433a snapd-2.57.6-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-735d1baeca brotli-1.0.9-10.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing coturn-4.6.1-1.el7 ipv6calc-4.0.2-67.el7 libbsd-0.11.7-2.el7 Details about builds: coturn-4.6.1-1.el7 (FEDORA-EPEL-2022-884f4fd70c) TURN/STUN & ICE Server Update Information: # Coturn 4.6.1* Fix memory corruption on socket close ChangeLog: * Sun Dec 4 2022 Robert Scheck - 4.6.1-1 - Upgrade to 4.6.1 (#2150608) References: [ 1 ] Bug #2150608 - coturn-4.6.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=2150608 ipv6calc-4.0.2-67.el7 (FEDORA-EPEL-2022-251556b8c1) IPv6 address format change and calculation utility Update Information: Final release 4.0.2 ChangeLog: * Sun Dec 4 2022 Peter Bieringer - 4.0.2-67 - Final release 4.0.2 libbsd-0.11.7-2.el7 (FEDORA-EPEL-2022-10049c7b14) Library providing BSD-compatible functions for portability Update Information: # libbsd 0.11.7 - Portability fixes for the Hurd - Fix ELF support for big endian SH - Sync the `arc4random(3)` implementation from OpenBSD - Adjust declaration shadowing to match new glibc additions - Manual pages and documentation cleanups - Manual page rewrite to get rid of a BSD-4-Clause license # libbsd 0.11.6 - Build system and test suite fixes for musl - Removal of unused OpenBSD support for `arc4random()` - LoongArch support for `nlist()` # libbsd 0.11.5 - Build system and test suite regression fixes - Documentation on how to build the project # libbsd 0.11.4 - Further rework of the libmd wrapping code, to simplify it again, and make it work even when we do not need SHA-2 functions - Fix builds with LTO - Various build system fixes - Various portability fixes - Various documentation fixes # libbsd 0.11.3 - Rework of the libmd wrapping code to not require users to explicitly link against libmd - Various build system fixes - Various portability fixes # libbsd 0.11.2 - Update `` from FreeBSD - Import some `closefrom()` changes from sudo - Make `closefrom()` use `close_range()` syscall on Linux when available - Update `libbsd(7)` man page with updates in 0.11.0 # libbsd 0.11.0/0.11.1 - Export `strnvisx()` function - New `recallocarray()` and `freezero()` from OpenBSD - New pwcache module from OpenBSD - New `timespec(3bsd)` man page alias to `timeval(3bsd)` - New progname implementation for Windows - New `LIBBSD_VIS_OPENBSD` selection macro - Switch from embedded hashing function implementations to use libmd - Various man pages cleanups - Various portability fixes - Various memory leak fixes # libbsd 0.10.0 - Several security related fixes for `nlist()` - Preliminary and partial Windows porting - Fix for a leak in the vis family of functions - Fix for a configure check to not unnecessarily link against librt - General portability fixes for musl, uClibc, macOS and GNU/kFreeBSD - New architectures support for `nlist()` - Switch the `` `*c()` functions to be standalone and add `err()`, `warn()`, `errx()` and `warnx()` familiy of functions in case the system lacks them - Several man page fixes # libbsd 0.9.0/0.9.1 - Add `__arraycount()` macro - Add `flopenat()` function - Add `strtoi()` and `strtou()` functions - Add several new vis and unvis functions - Add `pidfile_fileno()` function, and `struct pidfh` is now opaque - The `humanize_number()` now understands `HN_IEC_PREFIXES` - The `fmtcheck()` function supports all standard `printf(3)` conversions - The `getentropy()`, and thus `arc4random()` functions will not block anymore on Linux on boot when there's not enough entropy available - The `arc4random()` function handles direct `clone()` calls better # libbsd 0.8.7 Fixes the `nlist()` unit
Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
On 12/4/22 16:29, Kevin Kofler via devel wrote: > Neal Gompa wrote: >> I would prefer that *every* build would automatically generate a side >> tag, even if it's a side-tag of one package. Or at least provide an >> option to do that. That would provide opportunities for server-side >> automation for populating side-tags with updated builds against a >> package. > > But it is not practical given the performance concerns around side tags. Can those be fixed? -- Sincerely, Demi Marie Obenour (she/her/hers) ___ 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: Review Request: ImageMagick7
On Sun, 2022-12-04 at 17:14 -0500, Neal Gompa wrote: > On Sun, Dec 4, 2022 at 5:07 PM Sérgio Basto > wrote: > > > > On Sun, 2022-12-04 at 14:33 -0500, Neal Gompa wrote: > > > On Sun, Dec 4, 2022 at 9:39 AM Stephen Smoogen > > > > > > wrote: > > > > > > > > > > > > > > > > On Sat, 3 Dec 2022 at 11:55, Neal Gompa > > > > wrote: > > > > > > > > > > On Sat, Dec 3, 2022 at 11:25 AM Sérgio Basto > > > > > > > > > > wrote: > > > > > > > > > > > > On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel > > > > > > wrote: > > > > > > > On 03/12/2022 00:30, Sérgio Basto wrote: > > > > > > > > The proposal now is to keep ImageMagick 6 and make a > > > > > > > > new > > > > > > > > package > > > > > > > > with > > > > > > > > ImageMagick 7 , when we have all applications use only > > > > > > > > ImageMagick > > > > > > > > 7, > > > > > > > > we move the sources from ImageMagick7 to ImageMagick > > > > > > > > > > > > > > I think it would be better to update the ImageMagick > > > > > > > package > > > > > > > to > > > > > > > version > > > > > > > 7 and create a compatibility package ImageMagick6. > > > > > > > > > > > > Anyone is going to review the package or not ? > > > > > > > > > > > > I already explain the situation in the other emails on this > > > > > > thread . > > > > > > > > > > > > I estimate that I will need about 200 hours to do what your > > > > > > brilliants > > > > > > minds ask . > > > > > > > > > > > > > > > > Really? "200 hours"? Not a chance. Upgrading ImageMagick to > > > > > v7 > > > > > and > > > > > > > > > > > > Patches please, Neal to help Sergio cut it down then. He is > > > > saying > > > > he needs that time to make it work for all the problems he is > > > > seeing. Your commentary and others are coming across as > > > > lambasting > > > > him when he is wanting help. While your and other comments > > > > seem > > > > clear to you.. code would be clearer. > > > > > > > > > > Sure. I've prepared a pull request for ImageMagick itself: > > > https://src.fedoraproject.org/rpms/ImageMagick/pull-request/10 > > > > > > And I'm preparing a COPR to rebuild the reverse dependencies and > > > work > > > through the breakages (if any): > > > https://copr.fedorainfracloud.org/coprs/ngompa/ImageMagick7-dev/ > > > > I already state why I against this approach , don't forget, before > > merge this PR, you need do the compat-ImageMagick6912 or something, > > like [1] > > > > Sure, an ImageMagick6 package as a compatibility package is easy > enough to do. > > > And this will delay a lot adding ImageMagick7 to epel9 and epel8 > > > > No, it wouldn't. You could upgrade ImageMagick and add the > ImageMagick6 compat package there too and be fully compliant without > extra effort. With a lot more of time , energy , attention you can, but if you think it won't break anything you are wrong and I don't want stresses, eventually in a second phase I would do the same as you propose. I don't understand what advantages it brings do a compat ImageMagick to do a new ImageMagick version. Final statement, instead of wasting my time and energy on arguments, Imagemagick7 could already be built on rawhide if someone had done the package review for me Rest my case Best regards, -- Sérgio M. B. ___ 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: [HEADS UP] gpgme rebase to 1.17.1 and libqgpgme SONAME bump
Thanks for the excellent explanation, Adam. It makes me to understand the
problem now.
Jiri
On Fri, Dec 2, 2022 at 10:03 PM Adam Williamson
wrote:
> On Fri, 2022-12-02 at 21:25 +0100, Jiri Kucera wrote:
> > Yes, builds in [1] were built with the `f38-build-side-60497` side tag.
> In
> > [1] there are two errors that were not here in time I hit the submit
> button
> > (maybe I should wait a bit longer):
> > * `nothing provides libqgpgme.so.7 needed by
> > kdepim-addons-22.08.3-1.fc38.i686` - this one was
> > caused by not building `kdepim-addons` on `i686` since missing
> > `libphonenumber` on `i686`.
> > `libphonenumber` is not built for `i686` anymore due to `ExclusiveArch:
> > %{java_arches}`. This
> > can be fixed by skipping building the Java binding for `i686` only.
> > * ```
> > Undeclared file conflicts:
> > kleopatra-*.i686 provides ... which is also provided by
> kleopatra-*.x86_64
> > ...
> > kmail-*.i686 provides ... which is also provided by kmail-*.x86_64
> > ...
> > ```
> > These must have appeared also in the update before, but I cannot find
> > `rpmdeplint` tests
> > here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e8d23a026e
> >
> > I submitted [2] approx. 22h after [1] became stable. Have no idea why the
> > builds from pre-[1] rawhide were picked up. However, `rpmdeplint`
> > repoclosure failures are happening only on `i686` so maybe this is
> somehow
> > connected with `kdepim-addons` not built for `i686`.
> >
> > Regards and sorry for the chaos,
> > Jiri
> >
> > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2022-4c1b011b1b
> > [2] https://bodhi.fedoraproject.org/updates/FEDORA-2022-603eea89a3
>
> Ahhh, I see what happened!
>
> So, the problem is this. When a Rawhide update "goes stable" in Bodhi,
> all that really *means* is, it gets the release tag applied (so 'f38'
> at the moment). The next time the buildroot repo is composed after that
> (which happens frequently), the packages from the update will be added
> to it.
>
> However, the packages from the update will only show up in the main
> 'rawhide' repository after the next successful Rawhide compose, which
> is an uncertain interval. One compose is run per day automatically, so
> if those all succeed, you'd be sure of an update making it to 'rawhide'
> no more than 24 hours after it reached 'stable'. But sometimes they
> fail. When they fail, we might fix the problem and try again, or it
> might magically go away with the next day's compose, or we might not
> get a successful compose for a while.
>
> Right now, we haven't had a successful compose for several days due to
> various problems, so the current packages in the main 'rawhide' repo
> are the ones from the last successful compose, which I think was
> 20221130.n.0. Nothing that's gone "stable" since then is actually in
> the repo.
>
> openQA update tests for Rawhide updates use the latest packages from
> the main 'rawhide' repo, plus the packages from the update being
> tested. They do *not* include packages from the buildroot repo.
>
> So in the openQA tests, the first update - with all the builds in it -
> passed the tests just fine. But the second update, which only had gpgme
> in it, failed, because it didn't include the rebuilt dependent packages
> from the first update, even though they were now "stable".
>
> Overall I'd say this isn't your problem as the packager; everything you
> did was totally reasonable. In theory what you "should have done" to
> make the tests pass is wait till a Rawhide compose had completed before
> submitting the second update, but obviously that's not a reasonable
> thing to ask. It's more of a problem for me and releng to think about.
>
> I may think about having openQA Rawhide update tests enable the
> buildroot repo that includes packages from the release tag; this would
> make it include packages that have gone 'stable' since the previous
> Rawhide compose. I'd have to think if there are any potential drawbacks
> to doing that. Ironically, Fedora CI currently does that but is
> considering *not* doing it any more due to "unpleasant surprises":
> https://pagure.io/fedora-ci/general/issue/376 . I'm not sure exactly
> what the surprises were, I'll have to look into it.
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
>
___
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: [HEADS UP] gpgme rebase to 1.17.1 and libqgpgme SONAME bump
This will be not that easy as it looks like:
```
[ 63%] Generating
/builddir/build/BUILD/libphonenumber-8.12.57/cpp/src/phonenumbers/test_metadata.cc,
/builddir/build/BUILD/libphonenumber-8.12.57/cpp/src/phonenumbers/test_metadata.h
JAVA_BIN-NOTFOUND -jar
/builddir/build/BUILD/libphonenumber-8.12.57/cpp/../tools/java/cpp-build/target/cpp-build-1.0-SNAPSHOT-jar-with-dependencies.jar
BuildMetadataCppFromXml
/builddir/build/BUILD/libphonenumber-8.12.57/cpp/../resources/PhoneNumberMetadataForTesting.xml
/builddir/build/BUILD/libphonenumber-8.12.57/cpp/src/phonenumbers
test_metadata
gmake[2]: JAVA_BIN-NOTFOUND: No such file or directory
gmake[2]: *** [CMakeFiles/phonenumber_testing.dir/build.make:330:
/builddir/build/BUILD/libphonenumber-8.12.57/cpp/src/phonenumbers/test_metadata.cc]
Error 127
gmake[2]: *** Waiting for unfinished jobs
```
I will look more closely at how and why Java is used to generate C++
sources and how it can be replaced by something else in the build process.
Jiri
On Fri, Dec 2, 2022 at 9:37 PM Jiri Kucera wrote:
> Hmm, concerning `libphonenumber` there is no Java binding, only the C++
> port of the original Java library. Moreover, nothing Java-related is
> distributed in the RPMs. That means that `BuildRequires: java-devel` is
> redundant here. I will try to do a scratch build.
>
> Regards,
> Jiri
>
> On Fri, Dec 2, 2022 at 9:25 PM Jiri Kucera wrote:
>
>> Yes, builds in [1] were built with the `f38-build-side-60497` side tag.
>> In [1] there are two errors that were not here in time I hit the submit
>> button (maybe I should wait a bit longer):
>> * `nothing provides libqgpgme.so.7 needed by
>> kdepim-addons-22.08.3-1.fc38.i686` - this one was
>> caused by not building `kdepim-addons` on `i686` since missing
>> `libphonenumber` on `i686`.
>> `libphonenumber` is not built for `i686` anymore due to `ExclusiveArch:
>> %{java_arches}`. This
>> can be fixed by skipping building the Java binding for `i686` only.
>> * ```
>> Undeclared file conflicts:
>> kleopatra-*.i686 provides ... which is also provided by
>> kleopatra-*.x86_64
>> ...
>> kmail-*.i686 provides ... which is also provided by kmail-*.x86_64
>> ...
>> ```
>> These must have appeared also in the update before, but I cannot find
>> `rpmdeplint` tests
>> here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e8d23a026e
>>
>> I submitted [2] approx. 22h after [1] became stable. Have no idea why the
>> builds from pre-[1] rawhide were picked up. However, `rpmdeplint`
>> repoclosure failures are happening only on `i686` so maybe this is somehow
>> connected with `kdepim-addons` not built for `i686`.
>>
>> Regards and sorry for the chaos,
>> Jiri
>>
>> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2022-4c1b011b1b
>> [2] https://bodhi.fedoraproject.org/updates/FEDORA-2022-603eea89a3
>>
>> On Fri, Dec 2, 2022 at 11:54 AM Miro Hrončok wrote:
>>
>>> On 02. 12. 22 1:46, Adam Williamson wrote:
>>> > On Wed, 2022-11-30 at 13:59 +0100, Jiri Kucera wrote:
>>> >> Thanks for the reminder Petr. I will do the rebase in rawhide only
>>> then.
>>> >
>>> > Thanks for taking care of these dependencies and announcing the bump.
>>> >
>>> > For extra bonus points :D, if it's not too much trouble, it would be
>>> > great if you could do this on a side tag in future - yes, even for
>>> > Rawhide. Without a side tag and combined update, the openQA tests for
>>> > the gpgme update fail:
>>> >
>>> https://openqa.stg.fedoraproject.org/tests/overview?version=38=2=Update-FEDORA-2022-603eea89a3=fedora
>>> > if the gpgme bump and all dependent rebuilds were in the same update,
>>> > the tests would pass (assuming nothing's actually broken).
>>> >
>>> > Right now we're not gating Rawhide updates on test failures, but I do
>>> > check them all, so I had to make sure all the rebuilds had actually
>>> > been done, then add comments noting the tests need to be re-run after
>>> > the next Rawhide compose, then remember to re-run them so all that ugly
>>> > red ink goes away :D If/when we do start gating Rawhide on openQA
>>> > failures, this update would be blocked by gating.
>>>
>>> Interesting. I saw
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2022-4c1b011b1b where
>>> side tag
>>> was used.
>>>
>>> Later, there was
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2022-603eea89a3
>>> which only changed a small portion from the package.
>>>
>>> Why would the tests fails for the second update?
>>>
>>> --
>>> Miro Hrončok
>>> --
>>> Phone: +420777974800
>>> IRC: mhroncok
>>> ___
>>> 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
Re: FF 107.0 scratch builds - just for fun
FF 107.0 shipped in all current Fedora releases a while ago. You can find all that in bodhi. If you mean 107.0.1, that will depend on the FF maintainers. Maybe they see no reason to respin, because the bugs fixed in that release are not something that is important in Fedora - not sure. -- Bojan ___ 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: Review Request: ImageMagick7
On Sun, Dec 4, 2022 at 4:35 PM Kevin Kofler via devel wrote: > > Neal Gompa wrote: > > You can filter out things that use ImageMagick as a build dependency > > because that's just the command line utilities. That's why I checked > > only the ones that use the libraries, where the API changes and the > > required rebuilds are needed. > > How backwards-compatible is the CLI? Can there be things stopping to build > or to work at runtime because ImageMagick 7 convert does not understand some > option intended for ImageMagick 6 convert? > It's pretty compatible. Just by diffing "convert --help", it's mostly functional additions and some reorganization/rewording of descriptions. The only option missing is "convert -magnify", though curiously the code is still present in ImageMagick API. The command seems plumbed into the program in the source code too, so I'm confused why it's not documented. I've attached the diff of the program help too. -- 真実はいつも一つ！/ Always, there's only one truth! --- convert6.txt2022-12-04 16:51:43.547765023 -0500 +++ convert7.txt2022-12-04 17:07:45.018411091 -0500 @@ -1,8 +1,9 @@ -Version: ImageMagick 6.9.12-67 Q16 x86_64 17519 https://legacy.imagemagick.org +Version: ImageMagick 7.1.0-52 Q16-HDRI x86_64 20549 https://imagemagick.org Copyright: (C) 1999 ImageMagick Studio LLC License: https://imagemagick.org/script/license.php -Features: Cipher DPC Modules OpenMP(4.5) -Delegates (built-in): bzlib cairo djvu fontconfig freetype gslib gvc jbig jng jp2 jpeg lcms lqr ltdl lzma openexr pangocairo png ps raqm raw rsvg tiff webp wmf x xml zlib +Features: Cipher DPC HDRI Modules OpenMP(4.5) +Delegates (built-in): bzlib cairo djvu fftw fontconfig freetype gslib gvc jbig jng jp2 jpeg jxl lcms lqr ltdl lzma openexr pangocairo png ps raqm raw rsvg tiff webp wmf x xml zip zlib +Compiler: gcc (12.2) Usage: convert [options ...] file [ [options ...] file ...] [options ...] file Image Settings: @@ -20,9 +21,9 @@ Image Settings: -blue-primary point chromaticity blue primary point -bordercolor color border color -caption string assign a caption to an image - -channel typeapply option to select image channels + -clipclip along the first path from the 8BIM profile -clip-mask filename associate a clip mask with the image - -colors valuepreferred number of colors in the image + -clip-path idclip along a named path from the 8BIM profile -colorspace type alternate image colorspace -comment string annotate image with comment -compose operatorset image composite operator @@ -39,6 +40,7 @@ Image Settings: -encoding type text encoding type -endian type endianness (MSB or LSB) of the image -family name render text with this font family + -features distance analyze image features (e.g. contrast, correlation) -fill color color to use when filling a graphic primitive -filter type use this filter when resizing an image -font name render text with this font @@ -46,7 +48,8 @@ Image Settings: -fuzz distance colors within this distance are considered equal -gravity typehorizontal and vertical text placement -green-primary point chromaticity green primary point - -intensity methodmethod to generate intensity value from pixel + -illuminant type reference illuminant + -intensity methodmethod to generate an intensity value from a pixel -intent type type of rendering intent when managing the image color -interlace type type of image interlacing scheme -interline-spacing value @@ -58,7 +61,6 @@ Image Settings: -label stringassign a label to an image -limit type valuepixel cache resource limit -loop iterations add Netscape loop extension to your GIF animation - -mask filename associate a mask with the image -matte store matte channel if the image has one -mattecolor colorframe color -moments report image moments @@ -71,6 +73,7 @@ Image Settings: -preview typeimage preview type -quality value JPEG/MIFF/PNG compression level -quiet suppress all warning messages + -read-mask filename associate a read mask with the image -red-primary point chromaticity red primary point -regard-warnings pay attention to warning messages -remap filename transform image colors to match this set of colors @@ -102,6 +105,7 @@ Image Settings: virtual pixel access method -weight type render text with this font weight -white-point point chromaticity white point + -write-mask filename associate a write mask with the image -word-break type sets whether line breaks appear wherever the text would otherwise overflow Image Operators: -adaptive-blur geometry @@ -117,7 +121,11 @@ Image Operators: -auto-gamma automagically adjust
Re: Review Request: ImageMagick7
On Sun, Dec 4, 2022 at 5:07 PM Sérgio Basto wrote: > > On Sun, 2022-12-04 at 14:33 -0500, Neal Gompa wrote: > > On Sun, Dec 4, 2022 at 9:39 AM Stephen Smoogen > > wrote: > > > > > > > > > > > > On Sat, 3 Dec 2022 at 11:55, Neal Gompa wrote: > > > > > > > > On Sat, Dec 3, 2022 at 11:25 AM Sérgio Basto > > > > wrote: > > > > > > > > > > On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel > > > > > wrote: > > > > > > On 03/12/2022 00:30, Sérgio Basto wrote: > > > > > > > The proposal now is to keep ImageMagick 6 and make a new > > > > > > > package > > > > > > > with > > > > > > > ImageMagick 7 , when we have all applications use only > > > > > > > ImageMagick > > > > > > > 7, > > > > > > > we move the sources from ImageMagick7 to ImageMagick > > > > > > > > > > > > I think it would be better to update the ImageMagick package > > > > > > to > > > > > > version > > > > > > 7 and create a compatibility package ImageMagick6. > > > > > > > > > > Anyone is going to review the package or not ? > > > > > > > > > > I already explain the situation in the other emails on this > > > > > thread . > > > > > > > > > > I estimate that I will need about 200 hours to do what your > > > > > brilliants > > > > > minds ask . > > > > > > > > > > > > > Really? "200 hours"? Not a chance. Upgrading ImageMagick to v7 > > > > and > > > > > > > > > Patches please, Neal to help Sergio cut it down then. He is saying > > > he needs that time to make it work for all the problems he is > > > seeing. Your commentary and others are coming across as lambasting > > > him when he is wanting help. While your and other comments seem > > > clear to you.. code would be clearer. > > > > > > > Sure. I've prepared a pull request for ImageMagick itself: > > https://src.fedoraproject.org/rpms/ImageMagick/pull-request/10 > > > > And I'm preparing a COPR to rebuild the reverse dependencies and work > > through the breakages (if any): > > https://copr.fedorainfracloud.org/coprs/ngompa/ImageMagick7-dev/ > > I already state why I against this approach , don't forget, before > merge this PR, you need do the compat-ImageMagick6912 or something, > like [1] > Sure, an ImageMagick6 package as a compatibility package is easy enough to do. > And this will delay a lot adding ImageMagick7 to epel9 and epel8 > No, it wouldn't. You could upgrade ImageMagick and add the ImageMagick6 compat package there too and be fully compliant without extra effort. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Review Request: ImageMagick7
On Sun, 2022-12-04 at 14:33 -0500, Neal Gompa wrote: > On Sun, Dec 4, 2022 at 9:39 AM Stephen Smoogen > wrote: > > > > > > > > On Sat, 3 Dec 2022 at 11:55, Neal Gompa wrote: > > > > > > On Sat, Dec 3, 2022 at 11:25 AM Sérgio Basto > > > wrote: > > > > > > > > On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel > > > > wrote: > > > > > On 03/12/2022 00:30, Sérgio Basto wrote: > > > > > > The proposal now is to keep ImageMagick 6 and make a new > > > > > > package > > > > > > with > > > > > > ImageMagick 7 , when we have all applications use only > > > > > > ImageMagick > > > > > > 7, > > > > > > we move the sources from ImageMagick7 to ImageMagick > > > > > > > > > > I think it would be better to update the ImageMagick package > > > > > to > > > > > version > > > > > 7 and create a compatibility package ImageMagick6. > > > > > > > > Anyone is going to review the package or not ? > > > > > > > > I already explain the situation in the other emails on this > > > > thread . > > > > > > > > I estimate that I will need about 200 hours to do what your > > > > brilliants > > > > minds ask . > > > > > > > > > > Really? "200 hours"? Not a chance. Upgrading ImageMagick to v7 > > > and > > > > > > Patches please, Neal to help Sergio cut it down then. He is saying > > he needs that time to make it work for all the problems he is > > seeing. Your commentary and others are coming across as lambasting > > him when he is wanting help. While your and other comments seem > > clear to you.. code would be clearer. > > > > Sure. I've prepared a pull request for ImageMagick itself: > https://src.fedoraproject.org/rpms/ImageMagick/pull-request/10 > > And I'm preparing a COPR to rebuild the reverse dependencies and work > through the breakages (if any): > https://copr.fedorainfracloud.org/coprs/ngompa/ImageMagick7-dev/ I already state why I against this approach , don't forget, before merge this PR, you need do the compat-ImageMagick6912 or something, like [1] And this will delay a lot adding ImageMagick7 to epel9 and epel8 Best regards, [1] https://bodhi.fedoraproject.org/updates/FEDORA-2017-1362e7988d -- Sérgio M. B. ___ 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: Review Request: ImageMagick7
Neal Gompa wrote: > You can filter out things that use ImageMagick as a build dependency > because that's just the command line utilities. That's why I checked > only the ones that use the libraries, where the API changes and the > required rebuilds are needed. How backwards-compatible is the CLI? Can there be things stopping to build or to work at runtime because ImageMagick 7 convert does not understand some option intended for ImageMagick 6 convert? Kevin Kofler ___ 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: F38 proposal: Fedora Sway Spin (Self-Contained Change proposal)
On Fri, Dec 2, 2022, at 16:27, Major Hayden wrote: >> For those reasons, we propose to create a Sway spin and an ostree one, >> called `Sericea`. > > What made you choose the name? (Just curious.) It's actually named after Terminalia sericea [0] not Cornus sericea. The reasons were: * Terminalia Sericea is a tree. So is ostree. * Terminalia Sericea is also known as silverleaf. Silverleaf was one of the top contenders for the project name of what later became Fedora Silverblue [1]. * If you stare at a Terminalia Sericea for a while, you'll eventually start noticing similarities with the Sway logo Best, Fale [0] https://en.wikipedia.org/wiki/Terminalia_sericea [1] https://docs.fedoraproject.org/en-US/fedora-silverblue/faq/#_about_the_project -- Fabio Alessandro "Fale" Locati fale.io ___ 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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
Neal Gompa wrote: > I would prefer that *every* build would automatically generate a side > tag, even if it's a side-tag of one package. Or at least provide an > option to do that. That would provide opportunities for server-side > automation for populating side-tags with updated builds against a > package. But it is not practical given the performance concerns around side tags. Kevin Kofler ___ 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: Stupid question about QT6 and OpenGL support
Mattia Verga via devel wrote: > ... I wonder why... AFAIK, GLES should be better for low resource > systems like raspberry, isn't it? Probably yes. KDE upstream recommends it for Plasma Mobile, and Manjaro ARM builds a few qt5-es2-* packages (conflicting with the regular qt5-* ones) for the components where it makes a difference. Fedora could do the same on aarch64. And proprietary drivers for ARM often support ONLY OpenGL ES, so if we do not have Qt builds built for ES, Qt will not support OpenGL with those drivers at all. (Though it can be argued that that is a feature. ;-) ) As I understand it, Mesa now supports desktop OpenGL everywhere, but missing functionality is emulated in software, which is obviously slow. Kevin Kofler ___ 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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
On Sat, Dec 03, 2022 at 12:04:18PM +0100, Vitaly Zaitsev via devel wrote: > On 02/12/2022 22:30, Adam Williamson wrote: > > 1. Packages that have been pushed stable since the last time a compose > > succeeded (for Rawhide that's a Rawhide compose, for Branched it's a > > Branched compose, for stable releases it's an updates compose) > > 2. Packages that have active buildroot overrides > > I use buildroot overrides because generating side tags for stable releases > of Fedora is a very slow process. > > Two days ago I created F36, F37 and F38 side tags. F38 side tag was ready in > 10 minutes, and F36+F37 wasn't generated even after 6 hours. That's why I > created a new buildroot override and built everything directly. > > Before disabling buildroot overrides this issue must be fixed. Waiting for > 6+ hours is unacceptable. I don't think thats at all normal. We had mass updates/reboots and there was an issue with some ppc64le vm's not having the needed nfs mounts, causing them to fail newrepo tasks. This would have been the timeframe for that issue. Can you try again now and see if the stable release sidetags are not ready in ~10min? kevin signature.asc Description: PGP signature ___ 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: FF 107.0 scratch builds - just for fun
On 12/3/22 22:41, Bojan Smojver via devel wrote: > 107.0.1 build for > F37/x86_64: https://copr.fedorainfracloud.org/coprs/bojan/FF/ > > If you want/need or are obsessive about version numbers, like yours > truly. ;-) When will FF107 actually ship in Fedora? -- Sincerely, Demi Marie Obenour (she/her/hers) ___ 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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
On Sun, Dec 4, 2022 at 2:28 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Dec 02, 2022 at 03:35:31PM -0800, Adam Williamson wrote: > > On Sat, 2022-12-03 at 00:14 +0100, Kalev Lember wrote: > > > On Fri, Dec 2, 2022 at 10:30 PM Adam Williamson > > > > > > wrote: > > > > > > > So there's this CI ticket ATM[0] about whether the environment in which > > > > CI tests are run should or should not include and update from the > > > > 'buildroot' repo, which contains both: > > > > > > > > 1. Packages that have been pushed stable since the last time a compose > > > > succeeded (for Rawhide that's a Rawhide compose, for Branched it's a > > > > Branched compose, for stable releases it's an updates compose) > > > > 2. Packages that have active buildroot overrides > > > > > > > > Thinking about this reminded me again why buildroot overrides are such > > > > a bad idea: > > > > https://pagure.io/fedora-ci/general/issue/376#comment-830638 > > > > > > > > Buildroot overrides have unpredictable consequences for builds, updates > > > > *and* tests. I really feel like we should consider disallowing them and > > > > requiring all rebases to be done using side tags. Side tags are a > > > > *much* better design that avoids the problem of packages unexpectedly > > > > being built against a buildroot override somebody else submitted, and > > > > means test systems aren't stuck in a bind of not really knowing for > > > > sure what other packages should be installed when testing any given > > > > package. > > > > > > > > What does everyone else think? Has the time come? Or is there more we > > > > need to do to make side tags usable for all cases before getting rid of > > > > overrides? > > > > > > > > > > I would say that side tags are almost always the correct tool for ABI > > > rebuilds. I imagine people who submit global buildroot overrides to handle > > > a library soname bump are almost always doing it because they haven't > > > learned the "new" ways of doing it. > > > > > > I'd go as far as to say that anyone who does ABI rebuilds using global > > > buildroot overrides are doing it wrong. > > > > > > However, having said that, I also find buildroot overrides useful. Some > > > examples: > > > > > > 1) Fedora is in freeze. GNOME has gotten a Freeze Exception to pull a new > > > version through the freeze, but that includes a library soname bump. > > > > > > What I would do in that case is submit the GNOME megaupdate to Bodhi, and > > > also submit the library as a buildroot override to ensure that nothing can > > > build against the old soname -- I am fairly confident that the GNOME > > > megaupdate, together with the soname bump makes it to stable first. > > > > > > 2) I need to do a container build and include a new CVE fix (as it's > > > critical and we need to get fixes out ASAP), but that package build to > > > include in the container is only in updates-testing. > > > > > > What I'd do in this case is to submit a buildroot override because > > > everything that's overridden gets included in container builds. After my > > > container build is done I'd expire the buildroot override. > > > > > > 3) We've had some "fun" issues with sysprof symbols leaking out from the > > > GTK stack into other libraries consuming it. This has caused subtle ABI > > > issues and when working on a fix and to make sure no package can build > > > against the "wrong" GTK version, I've used buildroot overrides. > > > > > > 4) Compiler issues, with compilers producing broken code. > > > > > > To test the fixes and make sure packages start using the new fixed > > > versions > > > ASAP, a buildroot override is often useful. > > > > > > I could continue with the list but I think you get my point that there are > > > some cases where it's useful :) However I'd never use buildroot overrides > > > for soname bump rebuilds; that's what side tags are good for. > > > > Well, hmm. > > > > The examples you provide are definitely interesting. They all > > essentially boil down to, well, "I know exactly how this process works > > and I'm gonna take advantage of that to achieve the right outcome > > behind the scenes". > > Yeah, those four examples are very good. But they all can be summed up as > "we need this update that is in updates-testing (or possibly will soon be > there) > to apply to all subsequent builds". Thus, maybe it would be enough to replace > buildroot overrides with a single switch that says "make this update visible > in the buildroot *now*". > I would prefer that *every* build would automatically generate a side tag, even if it's a side-tag of one package. Or at least provide an option to do that. That would provide opportunities for server-side automation for populating side-tags with updated builds against a package. But one thing I like about the non-side-tag workflow is that I can submit one update for multiple releases and Bodhi will auto-split it for me. It speeds up my ability to ship updates a fair bit. I'd use side tags
Re: Review Request: ImageMagick7
On Sun, Dec 4, 2022 at 9:39 AM Stephen Smoogen wrote: > > > > On Sat, 3 Dec 2022 at 11:55, Neal Gompa wrote: >> >> On Sat, Dec 3, 2022 at 11:25 AM Sérgio Basto wrote: >> > >> > On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel wrote: >> > > On 03/12/2022 00:30, Sérgio Basto wrote: >> > > > The proposal now is to keep ImageMagick 6 and make a new package >> > > > with >> > > > ImageMagick 7 , when we have all applications use only ImageMagick >> > > > 7, >> > > > we move the sources from ImageMagick7 to ImageMagick >> > > >> > > I think it would be better to update the ImageMagick package to >> > > version >> > > 7 and create a compatibility package ImageMagick6. >> > >> > Anyone is going to review the package or not ? >> > >> > I already explain the situation in the other emails on this thread . >> > >> > I estimate that I will need about 200 hours to do what your brilliants >> > minds ask . >> > >> >> Really? "200 hours"? Not a chance. Upgrading ImageMagick to v7 and > > > Patches please, Neal to help Sergio cut it down then. He is saying he needs > that time to make it work for all the problems he is seeing. Your commentary > and others are coming across as lambasting him when he is wanting help. > While your and other comments seem clear to you.. code would be clearer. > Sure. I've prepared a pull request for ImageMagick itself: https://src.fedoraproject.org/rpms/ImageMagick/pull-request/10 And I'm preparing a COPR to rebuild the reverse dependencies and work through the breakages (if any): https://copr.fedorainfracloud.org/coprs/ngompa/ImageMagick7-dev/ -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Review Request: ImageMagick7
On Sun, Dec 4, 2022 at 2:21 PM Sérgio Basto wrote:
>
> On Sat, 2022-12-03 at 11:35 -0500, Neal Gompa wrote:
> > On Sat, Dec 3, 2022 at 11:25 AM Sérgio Basto
> > wrote:
> > >
> > > On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel wrote:
> > > > On 03/12/2022 00:30, Sérgio Basto wrote:
> > > > > The proposal now is to keep ImageMagick 6 and make a new
> > > > > package
> > > > > with
> > > > > ImageMagick 7 , when we have all applications use only
> > > > > ImageMagick
> > > > > 7,
> > > > > we move the sources from ImageMagick7 to ImageMagick
> > > >
> > > > I think it would be better to update the ImageMagick package to
> > > > version
> > > > 7 and create a compatibility package ImageMagick6.
> > >
> > > Anyone is going to review the package or not ?
> > >
> > > I already explain the situation in the other emails on this thread
> > > .
> > >
> > > I estimate that I will need about 200 hours to do what your
> > > brilliants
> > > minds ask .
> > >
> >
> > Really? "200 hours"? Not a chance. Upgrading ImageMagick to v7 and
> > splitting out a compat package is an hour at best. Then, any package
> > that fails to rebuild to IM7 needs to be checked if it can be easily
> > fixed or needs to be switched to the IM6 compat package. If it fails
> > to build with IM7, check openSUSE (who *already did this*) and see if
> > the package has a patch there to fix the build. If they don't, switch
> > it to the IM6 compat package and go onto the next one.
> >
> > > And btw, asking to the others to have the work that you maybe don't
> > > have in your packages , is very easy. if I do the compat package
> > > and
> > > wait for 200 packages dependency adapt to the change, will be a
> > > chaos ,
> > > and I don't like ignore all the tickets opened around it.
> > >
> > > ImageMagick-7.0.1-10 was release on 2016-06-07, today is 2022-12-03
> > > so
> > > after 6 Years and 5 Months and 26 Days, we still haven't any
> > > ImageMagick 7 in Fedora or EL, so or you help me on do it in my way
> > > ,
> > > or I won't do it .
> > >
> > > That is why package guidelines should be a guide and not all and
> > > not
> > > the all truth rule, when in practice you don't follow it just claim
> > > it.
> > >
> >
> > Have you considered that nobody has ever asked before for help? I
> > certainly haven't been asked.
> >
> > ngompa@fedora ~> sudo dnf --disablerepo="*updates*" repoquery
> > --whatrequires ImageMagick-c++ --qf "%{SOURCERPM}: %{REPOID}"
> > Last metadata expiration check: 0:54:24 ago on Sat 03 Dec 2022
> > 10:39:27 AM EST.
> > ImageMagick-6.9.12.64-1.fc37.src.rpm: fedora
> > R-magick-2.7.3-5.fc37.src.rpm: fedora
> > converseen-0.9.9.8-1.fc37.src.rpm: fedora
> > digikam-7.8.0-1.fc37.src.rpm: fedora
> > inkscape-1.2.1-3.fc37.src.rpm: fedora
> > kxstitch-2.1.1-8.fc37.src.rpm: fedora
> > libopenshot-0.2.7-8.fc37.src.rpm: rpmfusion-free
> > pdfmixtool-1.1-2.fc37.src.rpm: fedora
> > pfstools-2.2.0-5.fc37.src.rpm: fedora
> > pstoedit-3.78-5.fc37.src.rpm: fedora
> > synfig-1.5.1-3.fc37.src.rpm: fedora
> > synfigstudio-1.5.1-2.fc37.src.rpm: fedora
> > vdr-scraper2vdr-1.0.12-4.fc37.src.rpm: fedora
> > vdr-skinnopacity-1.1.12-2.fc37.src.rpm: fedora
> > vdr-tvguide-1.3.6-2.fc37.src.rpm: fedora
> >
> > ngompa@fedora ~> sudo dnf --disablerepo="*updates*" repoquery
> > --whatrequires ImageMagick-libs --qf "%{SOURCERPM}: %{REPOID}"
> > Last metadata expiration check: 0:54:32 ago on Sat 03 Dec 2022
> > 10:39:27 AM EST.
> > ImageMagick-6.9.12.64-1.fc37.src.rpm: fedora
> > R-magick-2.7.3-5.fc37.src.rpm: fedora
> > WindowMaker-0.95.9-9.fc37.src.rpm: fedora
> > autotrace-0.31.9-1.fc37.src.rpm: fedora
> > chafa-1.10.3-2.fc37.src.rpm: fedora
> > converseen-0.9.9.8-1.fc37.src.rpm: fedora
> > digikam-7.8.0-1.fc37.src.rpm: fedora
> > dmtx-utils-0.7.6-11.fc37.1.src.rpm: fedora
> > dvdauthor-0.7.2-18.fc37.src.rpm: fedora
> > eom-1.26.0-7.fc37.src.rpm: fedora
> > libopenshot-0.2.7-8.fc37.src.rpm: rpmfusion-free
> > php-pecl-imagick-3.7.0-4.fc37.src.rpm: fedora
> > psiconv-0.9.8-38.fc37.src.rpm: fedora
> > pstoedit-3.78-5.fc37.src.rpm: fedora
> > q-7.11-46.fc37.src.rpm: fedora
> > rss-glx-0.9.1.p-53.fc37.src.rpm: fedora
> > rubygem-rmagick-4.3.0-1.fc37.src.rpm: fedora
> > synfig-1.5.1-3.fc37.src.rpm: fedora
> > synfigstudio-1.5.1-2.fc37.src.rpm: fedora
> > vips-8.12.2-4.fc37.src.rpm: fedora
> > xine-lib-1.2.12-7.fc37.src.rpm: rpmfusion-free
> >
> > Hardly 200 packages
>
> 186 packages to check
> Depending on: ImageMagick (186), status change: 2022-02-21 (40 weeks
> ago)
> BlockOutII (maintained by: jwrdegoede)
> BlockOutII-2.5-21.fc37.src requires ImageMagick = 1:6.9.12.67-1.fc38
>
> CImg (maintained by: berrange, cheese, cicku)
> CImg-1:3.1.6-1.fc38.src requires ImageMagick-c++-devel = 1:6.9.12.67-
> 1.fc38
>
> COPASI (maintained by: neuro-sig, sagitter)
> COPASI-4.37.264-1.fc38.src requires ImageMagick = 1:6.9.12.67-1.fc38
>
> GoldenCheetah (maintained by: martinkg)
> GoldenCheetah-1:3.6-0.21.RC2.fc38.src requires ImageMagick =
>
Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
On Fri, Dec 02, 2022 at 03:35:31PM -0800, Adam Williamson wrote: > On Sat, 2022-12-03 at 00:14 +0100, Kalev Lember wrote: > > On Fri, Dec 2, 2022 at 10:30 PM Adam Williamson > > wrote: > > > > > So there's this CI ticket ATM[0] about whether the environment in which > > > CI tests are run should or should not include and update from the > > > 'buildroot' repo, which contains both: > > > > > > 1. Packages that have been pushed stable since the last time a compose > > > succeeded (for Rawhide that's a Rawhide compose, for Branched it's a > > > Branched compose, for stable releases it's an updates compose) > > > 2. Packages that have active buildroot overrides > > > > > > Thinking about this reminded me again why buildroot overrides are such > > > a bad idea: > > > https://pagure.io/fedora-ci/general/issue/376#comment-830638 > > > > > > Buildroot overrides have unpredictable consequences for builds, updates > > > *and* tests. I really feel like we should consider disallowing them and > > > requiring all rebases to be done using side tags. Side tags are a > > > *much* better design that avoids the problem of packages unexpectedly > > > being built against a buildroot override somebody else submitted, and > > > means test systems aren't stuck in a bind of not really knowing for > > > sure what other packages should be installed when testing any given > > > package. > > > > > > What does everyone else think? Has the time come? Or is there more we > > > need to do to make side tags usable for all cases before getting rid of > > > overrides? > > > > > > > I would say that side tags are almost always the correct tool for ABI > > rebuilds. I imagine people who submit global buildroot overrides to handle > > a library soname bump are almost always doing it because they haven't > > learned the "new" ways of doing it. > > > > I'd go as far as to say that anyone who does ABI rebuilds using global > > buildroot overrides are doing it wrong. > > > > However, having said that, I also find buildroot overrides useful. Some > > examples: > > > > 1) Fedora is in freeze. GNOME has gotten a Freeze Exception to pull a new > > version through the freeze, but that includes a library soname bump. > > > > What I would do in that case is submit the GNOME megaupdate to Bodhi, and > > also submit the library as a buildroot override to ensure that nothing can > > build against the old soname -- I am fairly confident that the GNOME > > megaupdate, together with the soname bump makes it to stable first. > > > > 2) I need to do a container build and include a new CVE fix (as it's > > critical and we need to get fixes out ASAP), but that package build to > > include in the container is only in updates-testing. > > > > What I'd do in this case is to submit a buildroot override because > > everything that's overridden gets included in container builds. After my > > container build is done I'd expire the buildroot override. > > > > 3) We've had some "fun" issues with sysprof symbols leaking out from the > > GTK stack into other libraries consuming it. This has caused subtle ABI > > issues and when working on a fix and to make sure no package can build > > against the "wrong" GTK version, I've used buildroot overrides. > > > > 4) Compiler issues, with compilers producing broken code. > > > > To test the fixes and make sure packages start using the new fixed versions > > ASAP, a buildroot override is often useful. > > > > I could continue with the list but I think you get my point that there are > > some cases where it's useful :) However I'd never use buildroot overrides > > for soname bump rebuilds; that's what side tags are good for. > > Well, hmm. > > The examples you provide are definitely interesting. They all > essentially boil down to, well, "I know exactly how this process works > and I'm gonna take advantage of that to achieve the right outcome > behind the scenes". Yeah, those four examples are very good. But they all can be summed up as "we need this update that is in updates-testing (or possibly will soon be there) to apply to all subsequent builds". Thus, maybe it would be enough to replace buildroot overrides with a single switch that says "make this update visible in the buildroot *now*". Zbyszek ___ 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: Review Request: ImageMagick7
On Sat, 2022-12-03 at 17:41 +0100, Kalev Lember wrote: > On Sat, Dec 3, 2022 at 5:38 PM Neal Gompa wrote: > > On Sat, Dec 3, 2022 at 11:34 AM Kalev Lember > > wrote: > > > > > > On Sat, Dec 3, 2022 at 5:26 PM Sérgio Basto > > wrote: > > >> > > >> On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel > > wrote: > > >> > On 03/12/2022 00:30, Sérgio Basto wrote: > > >> > > The proposal now is to keep ImageMagick 6 and make a new > > package > > >> > > with > > >> > > ImageMagick 7 , when we have all applications use only > > ImageMagick > > >> > > 7, > > >> > > we move the sources from ImageMagick7 to ImageMagick > > >> > > > >> > I think it would be better to update the ImageMagick package > > to > > >> > version > > >> > 7 and create a compatibility package ImageMagick6. > > >> > > >> Anyone is going to review the package or not ? > > >> > > >> I already explain the situation in the other emails on this > > thread . > > >> > > >> I estimate that I will need about 200 hours to do what your > > brilliants > > >> minds ask . > > >> > > >> And btw, asking to the others to have the work that you maybe > > don't > > >> have in your packages , is very easy. if I do the compat package > > and > > >> wait for 200 packages dependency adapt to the change, will be a > > chaos , > > >> and I don't like ignore all the tickets opened around it. > > >> > > >> ImageMagick-7.0.1-10 was release on 2016-06-07, today is 2022- > > 12-03 so > > >> after 6 Years and 5 Months and 26 Days, we still haven't any > > >> ImageMagick 7 in Fedora or EL, so or you help me on do it in my > > way , > > >> or I won't do it . > > >> > > >> That is why package guidelines should be a guide and not all > > and not > > >> the all truth rule, when in practice you don't follow it just > > claim it. > > > > > > > > > I think it makes sense to do it the way Sergio is planning as it > > makes it all much much easier. I don't think we should set a too > > high bar here wrt the package naming; anything is an improvement if > > we can start getting the distro migrating to ImageMagick 7. > > > > > > We can always rename ImageMagick -> ImageMagick6 and ImageMagick7 > > -> ImageMagick at a later date when someone has the energy to do > > it. > > > > > > Don't let perfect be the enemy of good :) > > > > > > > It matters in this case because both packages provide stuff in > > /usr/bin, and we only should have one provider of those. > > ImageMagick > > should retain them, and the ImageMagick6 compat package should only > > provide libraries for stuff that can't link to the IM7 libraries. > > > > > Ah, yes, that's a good point. I think we have a bunch of packages > that 'BuildRequires: ImageMagick' and then use /usr/bin/convert > during the build to convert icons from one format to another. Other > packages require /usr/bin/convert for runtime use. > > Sergio, what's your plan for handling /usr/bin/convert? Thank you Kalev , I don't indent change /usr/bin/convert from ImageMagick6 so probably it will /usr/bin/convert-7 Note that I checked Remi package and copied some ideas from there, so also should check how Remi handle this . > -- > Kalev > ___ > 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 -- Sérgio M. B. ___ 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: Review Request: ImageMagick7
On Sat, 2022-12-03 at 11:35 -0500, Neal Gompa wrote:
> On Sat, Dec 3, 2022 at 11:25 AM Sérgio Basto
> wrote:
> >
> > On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel wrote:
> > > On 03/12/2022 00:30, Sérgio Basto wrote:
> > > > The proposal now is to keep ImageMagick 6 and make a new
> > > > package
> > > > with
> > > > ImageMagick 7 , when we have all applications use only
> > > > ImageMagick
> > > > 7,
> > > > we move the sources from ImageMagick7 to ImageMagick
> > >
> > > I think it would be better to update the ImageMagick package to
> > > version
> > > 7 and create a compatibility package ImageMagick6.
> >
> > Anyone is going to review the package or not ?
> >
> > I already explain the situation in the other emails on this thread
> > .
> >
> > I estimate that I will need about 200 hours to do what your
> > brilliants
> > minds ask .
> >
>
> Really? "200 hours"? Not a chance. Upgrading ImageMagick to v7 and
> splitting out a compat package is an hour at best. Then, any package
> that fails to rebuild to IM7 needs to be checked if it can be easily
> fixed or needs to be switched to the IM6 compat package. If it fails
> to build with IM7, check openSUSE (who *already did this*) and see if
> the package has a patch there to fix the build. If they don't, switch
> it to the IM6 compat package and go onto the next one.
>
> > And btw, asking to the others to have the work that you maybe don't
> > have in your packages , is very easy. if I do the compat package
> > and
> > wait for 200 packages dependency adapt to the change, will be a
> > chaos ,
> > and I don't like ignore all the tickets opened around it.
> >
> > ImageMagick-7.0.1-10 was release on 2016-06-07, today is 2022-12-03
> > so
> > after 6 Years and 5 Months and 26 Days, we still haven't any
> > ImageMagick 7 in Fedora or EL, so or you help me on do it in my way
> > ,
> > or I won't do it .
> >
> > That is why package guidelines should be a guide and not all and
> > not
> > the all truth rule, when in practice you don't follow it just claim
> > it.
> >
>
> Have you considered that nobody has ever asked before for help? I
> certainly haven't been asked.
>
> ngompa@fedora ~> sudo dnf --disablerepo="*updates*" repoquery
> --whatrequires ImageMagick-c++ --qf "%{SOURCERPM}: %{REPOID}"
> Last metadata expiration check: 0:54:24 ago on Sat 03 Dec 2022
> 10:39:27 AM EST.
> ImageMagick-6.9.12.64-1.fc37.src.rpm: fedora
> R-magick-2.7.3-5.fc37.src.rpm: fedora
> converseen-0.9.9.8-1.fc37.src.rpm: fedora
> digikam-7.8.0-1.fc37.src.rpm: fedora
> inkscape-1.2.1-3.fc37.src.rpm: fedora
> kxstitch-2.1.1-8.fc37.src.rpm: fedora
> libopenshot-0.2.7-8.fc37.src.rpm: rpmfusion-free
> pdfmixtool-1.1-2.fc37.src.rpm: fedora
> pfstools-2.2.0-5.fc37.src.rpm: fedora
> pstoedit-3.78-5.fc37.src.rpm: fedora
> synfig-1.5.1-3.fc37.src.rpm: fedora
> synfigstudio-1.5.1-2.fc37.src.rpm: fedora
> vdr-scraper2vdr-1.0.12-4.fc37.src.rpm: fedora
> vdr-skinnopacity-1.1.12-2.fc37.src.rpm: fedora
> vdr-tvguide-1.3.6-2.fc37.src.rpm: fedora
>
> ngompa@fedora ~> sudo dnf --disablerepo="*updates*" repoquery
> --whatrequires ImageMagick-libs --qf "%{SOURCERPM}: %{REPOID}"
> Last metadata expiration check: 0:54:32 ago on Sat 03 Dec 2022
> 10:39:27 AM EST.
> ImageMagick-6.9.12.64-1.fc37.src.rpm: fedora
> R-magick-2.7.3-5.fc37.src.rpm: fedora
> WindowMaker-0.95.9-9.fc37.src.rpm: fedora
> autotrace-0.31.9-1.fc37.src.rpm: fedora
> chafa-1.10.3-2.fc37.src.rpm: fedora
> converseen-0.9.9.8-1.fc37.src.rpm: fedora
> digikam-7.8.0-1.fc37.src.rpm: fedora
> dmtx-utils-0.7.6-11.fc37.1.src.rpm: fedora
> dvdauthor-0.7.2-18.fc37.src.rpm: fedora
> eom-1.26.0-7.fc37.src.rpm: fedora
> libopenshot-0.2.7-8.fc37.src.rpm: rpmfusion-free
> php-pecl-imagick-3.7.0-4.fc37.src.rpm: fedora
> psiconv-0.9.8-38.fc37.src.rpm: fedora
> pstoedit-3.78-5.fc37.src.rpm: fedora
> q-7.11-46.fc37.src.rpm: fedora
> rss-glx-0.9.1.p-53.fc37.src.rpm: fedora
> rubygem-rmagick-4.3.0-1.fc37.src.rpm: fedora
> synfig-1.5.1-3.fc37.src.rpm: fedora
> synfigstudio-1.5.1-2.fc37.src.rpm: fedora
> vips-8.12.2-4.fc37.src.rpm: fedora
> xine-lib-1.2.12-7.fc37.src.rpm: rpmfusion-free
>
> Hardly 200 packages
186 packages to check
Depending on: ImageMagick (186), status change: 2022-02-21 (40 weeks
ago)
BlockOutII (maintained by: jwrdegoede)
BlockOutII-2.5-21.fc37.src requires ImageMagick = 1:6.9.12.67-1.fc38
CImg (maintained by: berrange, cheese, cicku)
CImg-1:3.1.6-1.fc38.src requires ImageMagick-c++-devel = 1:6.9.12.67-
1.fc38
COPASI (maintained by: neuro-sig, sagitter)
COPASI-4.37.264-1.fc38.src requires ImageMagick = 1:6.9.12.67-1.fc38
GoldenCheetah (maintained by: martinkg)
GoldenCheetah-1:3.6-0.21.RC2.fc38.src requires ImageMagick =
1:6.9.12.67-1.fc38
LaTeXML (maintained by: epel-packagers-sig, mikep)
LaTeXML-0.8.6-5.fc37.noarch requires perl(Image::Magick)
NsCDE (maintained by: dcavalca, salimma)
NsCDE-2.1-2.fc37.src requires ImageMagick = 1:6.9.12.67-1.fc38
NsCDE-2.1-2.fc37.x86_64 requires ImageMagick =
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
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 hashing algorithms rather than the bundled versions. Jonathan ___ 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
[rpms/perl-LWP-MediaTypes] PR #1: Package tests and update license to SPDX format
mspacek merged a pull-request against the project: `perl-LWP-MediaTypes` that you are following. Merged pull-request: `` Package tests and update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-LWP-MediaTypes/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-LWP-MediaTypes] PR #1: Package tests and update license to SPDX format
mspacek opened a new pull-request against the project: `perl-LWP-MediaTypes` that you are following: `` Package tests and update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-LWP-MediaTypes/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review Request: ImageMagick7
On Sat, 3 Dec 2022 at 11:55, Neal Gompa wrote: > On Sat, Dec 3, 2022 at 11:25 AM Sérgio Basto wrote: > > > > On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel wrote: > > > On 03/12/2022 00:30, Sérgio Basto wrote: > > > > The proposal now is to keep ImageMagick 6 and make a new package > > > > with > > > > ImageMagick 7 , when we have all applications use only ImageMagick > > > > 7, > > > > we move the sources from ImageMagick7 to ImageMagick > > > > > > I think it would be better to update the ImageMagick package to > > > version > > > 7 and create a compatibility package ImageMagick6. > > > > Anyone is going to review the package or not ? > > > > I already explain the situation in the other emails on this thread . > > > > I estimate that I will need about 200 hours to do what your brilliants > > minds ask . > > > > Really? "200 hours"? Not a chance. Upgrading ImageMagick to v7 and > Patches please, Neal to help Sergio cut it down then. He is saying he needs that time to make it work for all the problems he is seeing. Your commentary and others are coming across as lambasting him when he is wanting help. While your and other comments seem clear to you.. code would be clearer. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
[rpms/perl-Module-Runtime] PR #1: Package tests and update license to SPDX format
mspacek merged a pull-request against the project: `perl-Module-Runtime` that you are following. Merged pull-request: `` Package tests and update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-Module-Runtime/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Module-Runtime] PR #1: Package tests and update license to SPDX format
mspacek opened a new pull-request against the project: `perl-Module-Runtime` that you are following: `` Package tests and update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Module-Runtime/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics
Dne 01. 12. 22 v 16:43 Tomasz Torcz napsal(a): What does this warning mean? ladvd warning: valid as old and new and no changelong entry, please check Hmm, let me look. The ladvd license is ICS https://src.fedoraproject.org/rpms/ladvd/blob/rawhide/f/ladvd.spec#_10 and both license-validate'ISC' and license-validate--old 'ISC' validate it. I.e. this license is valid as both Callaway **and** SPDX identifier. It very often happens that the old Callaway id was identifier for the whole family of SPDX licenses (see MIT license case). I cannot guess if you investigated whether the old id is valid as the new one too **and** it reflect the same license. Or you still did not check it at all and the tag simply describe the old Callaway license id - and the validity using spdx rules are pure coincidence. If you checked that it actually match the SPDX license, then I recommend to put in a changelog (or even dist-git commit) a line - migrated to spdx license or - checked that license match spdx identifier In my script, I actually just check /spdx/i existence in the log. Miroslav ___ 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
Fedora rawhide compose report: 20221204.n.0 changes
OLD: Fedora-Rawhide-20221203.n.1 NEW: Fedora-Rawhide-20221204.n.0 = SUMMARY = Added images:3 Dropped images: 1 Added packages: 1 Dropped packages:0 Upgraded packages: 29 Downgraded packages: 0 Size of added packages: 2.00 MiB Size of dropped packages:0 B Size of upgraded packages: 392.29 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 7.37 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server dvd ppc64le Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20221204.n.0.iso Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20221204.n.0.iso Image: Server_KVM qcow2 aarch64 Path: Server/aarch64/images/Fedora-Server-KVM-Rawhide-20221204.n.0.aarch64.qcow2 = DROPPED IMAGES = Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20221203.n.1.aarch64.tar.xz = ADDED PACKAGES = Package: wlroots0.15-0.15.1-1.fc38 Summary: A modular Wayland compositor library RPMs:wlroots0.15 wlroots0.15-devel Size:2.00 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: COPASI-4.38.268-1.fc38 Old package: COPASI-4.37.264-1.fc38 Summary: Biochemical network simulator RPMs: COPASI COPASI-data COPASI-doc COPASI-gui python3-COPASI Size: 56.26 MiB Size change: -9.84 KiB Changelog: * Sat Dec 03 2022 Antonio Trande - 4.38.268-1 - Release 4.38 build-268 Package: ansible-lint-1:6.9.1-1.fc38 Old package: ansible-lint-1:6.8.6-1.fc38 Summary: Best practices checker for Ansible RPMs: python3-ansible-lint Size: 487.87 KiB Size change: 17.31 KiB Changelog: * Tue Nov 22 2022 Parag Nemade - 1:6.8.7-1 - Update to 6.8.7 version (#2144357) * Sun Dec 04 2022 Parag Nemade - 1:6.9.1-1 - Update to 6.9.1 version (#2147469) Package: cpuid-20221201-1.fc38 Old package: cpuid-20221003-1.fc38 Summary: Dumps information about the CPU(s) RPMs: cpuid Size: 147.00 KiB Size change: 1.89 KiB Changelog: * Sun Dec 04 2022 Fabian Affolter 20221201-1 - Update to latest upstream release 20221201 (closes rhbz#2149957) Package: freefem++-4.12-1.fc38 Old package: freefem++-4.11-5.fc38 Summary: PDE solving tool RPMs: freefem++ freefem++-mpich freefem++-openmpi Size: 208.89 MiB Size change: 6.38 MiB Changelog: * Sat Dec 03 2022 Ralf Cors??pius - 4.12-1 - Update to 4.12. Package: golang-bug-serial-1-1.4.1-1.fc38 Old package: golang-bug-serial-1-1.4.0-1.fc38 Summary: Cross-platform serial library for Golang RPMs: golang-bug-serial-1 golang-bug-serial-devel Size: 2.57 MiB Size change: 1.58 KiB Changelog: * Sun Dec 04 2022 Elliott Sales de Andrade 1.4.1-1 - Update to latest version (#2149721) Package: labwc-0.6.0-1.fc38 Old package: labwc-0.5.3-2.fc37 Summary: Openbox alternative for Wayland RPMs: labwc Size: 457.51 KiB Size change: 70.38 KiB Changelog: * Sun Dec 04 2022 Artem Polishchuk 0.6.0-1 - build: Update to 0.6.0 Package: libvirt-8.10.0-1.fc38 Old package: libvirt-8.9.0-1.fc38 Summary: Library providing a simple virtualization API RPMs: libvirt libvirt-client libvirt-client-qemu libvirt-daemon libvirt-daemon-config-network libvirt-daemon-config-nwfilter libvirt-daemon-driver-interface libvirt-daemon-driver-libxl libvirt-daemon-driver-lxc libvirt-daemon-driver-network libvirt-daemon-driver-nodedev libvirt-daemon-driver-nwfilter libvirt-daemon-driver-qemu libvirt-daemon-driver-secret libvirt-daemon-driver-storage libvirt-daemon-driver-storage-core libvirt-daemon-driver-storage-disk libvirt-daemon-driver-storage-gluster libvirt-daemon-driver-storage-iscsi libvirt-daemon-driver-storage-iscsi-direct libvirt-daemon-driver-storage-logical libvirt-daemon-driver-storage-mpath libvirt-daemon-driver-storage-rbd libvirt-daemon-driver-storage-scsi libvirt-daemon-driver-storage-zfs libvirt-daemon-driver-vbox libvirt-daemon-kvm libvirt-daemon-lxc libvirt-daemon-qemu libvirt-daemon-vbox libvirt-daemon-xen libvirt-devel libvirt-docs libvirt-libs libvirt-lock-sanlock libvirt-login-shell libvirt-nss libvirt-wireshark mingw32-libvirt mingw64-libvirt Size: 55.65 MiB Size change: 124.32 KiB Changelog: * Sat Dec 03 2022 Cole Robinson - 8.10.0-1 - Update to version 8.10.0 Package: libvirt-python-8.10.0-1.fc38 Old package: libvirt-python-8.9.0-1.fc38 Summary: The libvirt virtualization API python3 binding RPMs: python3-libvirt Size: 1.38 MiB Size change: 800 B Changelog: * Sat Dec 03 2022 Cole Robinson - 8.10.0-1 - Update to version 8.10.0 Package: nbdkit-1.33.4-1.fc38 Old package: nbdkit-1.33.3-1.fc38 Summary: NBD server RPMs: nbdkit nbdkit-S3-plugin nbdkit-bash-completion nbdkit-basic-filters nbdkit-basic-plugins
[rpms/perl-srpm-macros] PR #1: Update license to SPDX format
mspacek merged a pull-request against the project: `perl-srpm-macros` that you are following. Merged pull-request: `` Update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-srpm-macros/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-srpm-macros] PR #1: Update license to SPDX format
mspacek opened a new pull-request against the project: `perl-srpm-macros` that you are following: `` Update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-srpm-macros/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Inline] PR #1: Package tests and update license to SPDX license
mspacek merged a pull-request against the project: `perl-Inline` that you are following. Merged pull-request: `` Package tests and update license to SPDX license `` https://src.fedoraproject.org/rpms/perl-Inline/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Stupid question about QT6 and OpenGL support
Il 03/12/22 19:01, Neal Gompa ha scritto:
>
> Good question, I don't know. Seems glvnd provides the libraries, maybe
> that's enough?
I had a look at mesa specfile, first it is build with
-Dgles1=disabled \
-Dgles2=enabled \
but then:
# XXX can we just not build this
rm -vf %{buildroot}%{_libdir}/libGLES*
... I wonder why... AFAIK, GLES should be better for low resource
systems like raspberry, isn't it?
Mattia
___
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
Headers file in python package
I'm reviewing the un-retirement ticket of python-nss [1] and rpmlint is complaining about header files under the python module directory. The specfile is using the %pyproject_save_files macro to get the file list. I'm unsure if this is a false positive or I must ask the submitter to filter out those files in a -devel package... What do you think? Mattia [1] https://bugzilla.redhat.com/show_bug.cgi?id=2133080 ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
