[Bug 2106752] perl-Chart-2.403.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106752 Petr Pisar changed: What|Removed |Added Resolution|--- |RAWHIDE Status|ON_QA |CLOSED Last Closed||2022-07-14 05:45:21 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106752 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-463787a597 seamonkey-2.53.13-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing R-Rcpp-1.0.9-1.el7 R-qtl-1.52-1.el7 inih-56-1.el7 libidn2-2.3.3-1.el7 libuv-1.44.2-1.el7 lynis-3.0.8-1.el7 nagelfar-1.3.2-1.el7 rpminspect-data-fedora-1.9-1.el7 trafficserver-9.1.2-9.el7 Details about builds: R-Rcpp-1.0.9-1.el7 (FEDORA-EPEL-2022-4b529cc1f8) Seamless R and C++ Integration Update Information: Rcpp 1.0.9 ChangeLog: * Wed Jul 13 2022 Mattias Ellert - 1.0.9-1 - Update to 1.0.9 R-qtl-1.52-1.el7 (FEDORA-EPEL-2022-eb7d1db3ea) Tools for analyzing QTL experiments Update Information: R qtl 1.52 ChangeLog: * Wed Jul 13 2022 Mattias Ellert - 1.52-1 - Update to 1.52 * Wed Jan 19 2022 Fedora Release Engineering - 1.50-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild inih-56-1.el7 (FEDORA-EPEL-2022-6c74d13f0a) Simple INI file parser library Update Information: # inih v56* Fix redundant cast-to-int when `INI_USE_STACK!=0` * Make inline comments work on subsequent lines of multiline values ChangeLog: * Wed Jul 13 2022 Robert Scheck - 56-1 - New upstream release 56 (#2106574) References: [ 1 ] Bug #2106574 - inih-56 is available https://bugzilla.redhat.com/show_bug.cgi?id=2106574 libidn2-2.3.3-1.el7 (FEDORA-EPEL-2022-007c4c328d) Library to support IDNA2008 internationalized domain names Update Information: # libidn2 2.3.3 (2022-07-11)* Upgrade IDNA Tables from Unicode 11 to 12* Upgrade TR46 Tables from Unicode 13 to 14* Updated gnulib files and various build fixes Gnulib's Unicode code claims conformance to Unicode 14.0.0 rather than Unicode 9.0.0. A bug in Libidn2's build system was fixed that caused the system libunistring to be used even though the system version was too old.* Self-check improvements Self-checks for the idn2 command line tool were added. The C self-checks in `tests/` should now be usable outside of the libidn2 build environment, for system integration checks of a system- installed libidn2. ChangeLog: * Wed Jul 13 2022 Robert Scheck 2.3.3-1 - Upgrade to 2.3.3 (#2106161) * Thu Jan 20 2022 Fedora Release Engineering - 2.3.2-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Tue Aug 31 2021 Robert Scheck 2.3.2-3 - Disable undesired Makefile rebuilding by automake (#1999520) * Thu Jul 22 2021 Fedora Release Engineering - 2.3.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild References: [ 1 ] Bug #2106161 - libidn2-2.3.3 is available https://bugzilla.redhat.com/show_bug.cgi?id=2106161 libuv-1.44.2-1.el7 (FEDORA-EPEL-2022-44b304fa3d) Platform layer for node.js Update Information: ## Important bugs fixed * loop: better align order-of-events behavior between platforms #3598 * zos: fix fs event not fired if the watched file is moved/removed/recreated #3540 * win: Fix pipe resource leak if closed during connect (and other bugs) #3611 * zos: don't error when killing a zombie process #3625 ## Regressions fixed * macos: avoid posix_spawnp() cwd bug #3597 * kqueue: skip EVFILT_PROC events when invalidating events for an fd. #3629
[Bug 2102698] Add perl-UNIVERSAL-moniker to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2102698 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- FEDORA-EPEL-2022-e717a06552 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e717a06552 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102698 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2102614] Add perl-Data-Dumper-Concise to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2102614 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-7fe882d39c has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-7fe882d39c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102614 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2103378] perl-Socket-2.035 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2103378 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Socket-2.035-1.fc37|perl-Socket-2.035-1.fc37 ||perl-Socket-2.035-1.fc36 Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2022-07-14 01:46:11 --- Comment #3 from Fedora Update System --- FEDORA-2022-1a662f3bdc has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2103378 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2102614] Add perl-Data-Dumper-Concise to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2102614 Bug 2102614 depends on bug 2102624, which changed state. Bug 2102624 Summary: Add perl-Devel-ArgNames to EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2102624 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102614 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2102624] Add perl-Devel-ArgNames to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2102624 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2022-07-14 01:41:30 --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-deef165038 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102624 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2106528] perl-File-MimeInfo-0.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106528 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2022-8bcc85b42a has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-8bcc85b42a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8bcc85b42a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106528 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
It's not even a question worth asking because it's both impractical and unlikely to actually fix the situation we have. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2105729] pangzero and frozen-bubble won't launch and segfault on F36
https://bugzilla.redhat.com/show_bug.cgi?id=2105729 --- Comment #9 from Hans de Goede --- Thanks, that is a bit of a weird backtrace. What GPU are you using and which driver are you using with this GPU ? Is this perhaps inside a virtual-machine ? -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2105729 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2105729] pangzero and frozen-bubble won't launch and segfault on F36
https://bugzilla.redhat.com/show_bug.cgi?id=2105729 --- Comment #8 from Sergio Basto --- bt #0 0x in ?? () #1 0x7fffdf70e330 in __glXGetDrawableAttribute () from /lib64/libGLX_mesa.so.0 #2 0x7fffe9f4d2c4 in X11_GL_GetSwapInterval (_this=0x56bb3db0) at /usr/src/debug/SDL2-2.0.22-2.fc36.x86_64/src/video/x11/SDL_x11opengl.c:933 #3 X11_GL_GetSwapInterval (_this=_this@entry=0x56bb3db0) at /usr/src/debug/SDL2-2.0.22-2.fc36.x86_64/src/video/x11/SDL_x11opengl.c:917 #4 0x7fffe9f4d38e in X11_GL_SetSwapInterval (_this=0x56bb3db0, interval=0) at /usr/src/debug/SDL2-2.0.22-2.fc36.x86_64/src/video/x11/SDL_x11opengl.c:890 #5 0x7fffe9eb775e in GL_CreateRenderer (window=0x56c2a8c0, flags=) at /usr/src/debug/SDL2-2.0.22-2.fc36.x86_64/src/render/opengl/SDL_render_gl.c:1849 #6 0x7fffe9ea8b98 in SDL_CreateRenderer_REAL (window=0x56c2a8c0, index=0, flags=2) at /usr/src/debug/SDL2-2.0.22-2.fc36.x86_64/src/render/SDL_render.c:977 #7 0x779b16a7 in SDL_SetVideoMode (width=width@entry=640, height=height@entry=480, bpp=, bpp@entry=24, flags12=) at /usr/src/debug/sdl12-compat-0.0.1~git.20211125.4e4527a-4.fc36.x86_64/src/SDL12_compat.c:5172 #8 0x77dce67c in XS_SDL__Video_set_video_mode (my_perl=, cv=) at lib/SDL/Video.xs:137 #9 0x77b0a790 in Perl_pp_entersub () from /lib64/libperl.so.5.34 #10 0x77b02260 in Perl_runops_standard () from /lib64/libperl.so.5.34 #11 0x77a7eace in perl_run () from /lib64/libperl.so.5.34 #12 0x534a in main (argc=, argv=, env=) at /usr/src/debug/perl-5.34.1-486.fc36.x86_64/perlmain.c:110 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2105729 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Shall we add a limit to number of packages in a Bodhi update?
Jul 13, 2022 1:13:38 PM Adam Williamson : > If they need to be rebuilt for an API/ABI change, then by policy they > should be grouped together. We do not want a situation where the > API/ABI change gets pushed stable but some of the rebuilds do not, or > vice versa. We're not talking about ABI/API changes. This about the recent rebuilds we've done to fix CVEs in golang/the surrounding libraries. golang/the libraries are only needed at buildtime and the binaries are statically linked, so it doesn't matter if everything is pushed at exactly the same time. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Shall we add a limit to number of packages in a Bodhi update?
On Wed, Jul 13, 2022 at 03:38:29PM +, Mattia Verga via devel wrote: > Bodhi is a nice interface to create multi-builds update from side-tags, > but it is not really optimized for massive updates. In the past we had > some troubles pushing updates with a lot of builds. There are too many > things done in the background that can break while processing a massive > update and making Bodhi more reliable is not so simple. > > I wonder if it would be safe to set a cap to the number of builds a > single Bodhi update can carry. I think **really** massive updates (say > more than 99 builds?) should be handled manually asking Releng to merge > the side-tag manually. I'd prefer you didn't limit them to such a low number. OCaml updates have ~ 180 packages (https://bodhi.fedoraproject.org/updates/FEDORA-2022-d3e15b41f5) and it's a lot easier to do the push myself rather than have to ask someone. And I will have to remember each time _how_ to ask someone, since I do this infrequently enough that I'll forget each time. What is the actual problem and could it be fixed instead? > I'd like to hear someone else opinion, especially from FESCo and Releng > members. Meanwhile I'll keep an eye on the recent massive Golang update > (which carries 315 builds...) to see if it shows any hiccups. (I'm quite > surprised it didn't screw up already) 315 builds doesn't strike me as being that massive TBH. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [External] Re: F36 official respin iso for lenovo Z13 and Z16
On Wed, Jul 13, 2022 at 03:19:12PM -0400, Mark Pearson wrote: > On 7/13/22 15:13, Kevin Fenzi wrote: > > On Wed, Jul 13, 2022 at 02:34:12PM -0400, Mark Pearson wrote: > >> Hi Fedora Devs, > >> > >> Would someone be able to help getting an official-respin done from F36 > >> latest please? Similar to what was done for the Carbons etc. > >> > >> We need one for the Z13 & Z16 preload. We're waiting on one FW fix but > >> Fedora itself is in good shape (at least from my testing) so I want to > >> get an image into the QA team so they can get started > > > > Can you file a releng ticket on this? > > > > https://pagure.io/releng>> > > Either releng can make one, or perhaps the Respins SIG has or is doing > > one that will meet your needs. We can discuss that in the ticket. :) > > > No problem: https://pagure.io/releng/issue/10886 > > I did ping Mohan yesterday but thought he might be on PTO or swamped. He's actually moved on to another group. :) 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [External] Re: F36 official respin iso for lenovo Z13 and Z16
On 7/13/22 15:13, Kevin Fenzi wrote: > On Wed, Jul 13, 2022 at 02:34:12PM -0400, Mark Pearson wrote: >> Hi Fedora Devs, >> >> Would someone be able to help getting an official-respin done from F36 >> latest please? Similar to what was done for the Carbons etc. >> >> We need one for the Z13 & Z16 preload. We're waiting on one FW fix but >> Fedora itself is in good shape (at least from my testing) so I want to >> get an image into the QA team so they can get started > > Can you file a releng ticket on this? > > https://pagure.io/releng>> > Either releng can make one, or perhaps the Respins SIG has or is doing > one that will meet your needs. We can discuss that in the ticket. :) > No problem: https://pagure.io/releng/issue/10886 I did ping Mohan yesterday but thought he might be on PTO or swamped. Thanks! Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 official respin iso for lenovo Z13 and Z16
On Wed, Jul 13, 2022 at 02:34:12PM -0400, Mark Pearson wrote: > Hi Fedora Devs, > > Would someone be able to help getting an official-respin done from F36 > latest please? Similar to what was done for the Carbons etc. > > We need one for the Z13 & Z16 preload. We're waiting on one FW fix but > Fedora itself is in good shape (at least from my testing) so I want to > get an image into the QA team so they can get started Can you file a releng ticket on this? https://pagure.io/releng Either releng can make one, or perhaps the Respins SIG has or is doing one that will meet your needs. We can discuss that in the ticket. :) 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Shall we add a limit to number of packages in a Bodhi update?
My 2 cents... we should try and get bodhi (and the rest of the pipeline) to work with these large updates if at all possible. Having releng merge tags works of course, but as Adam pointed out, it skips our CI and feedback testing area. Additionally, it's more work to releng folks and more waiting around time for requesters. We also have some KDE updates that were over 300 builds. (like https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-a6c0f04770 ) I'm sure there have been others. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Announcing fmt library soversion bump
On Sunday, 10 July 2022 at 19:43, Vitaly Zaitsev via devel wrote: > Hello. > > fmt 9.0.x update will include a soversion bump from .8 to .9. It has both > API and ABI changes. [...] > mkvtoolnix mkvtoolnix updated and built in the side tag: https://koji.fedoraproject.org/koji/taskinfo?taskID=89457215 Coincidentally, upstream added support for fmt 9.0 in this latest release. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F36 official respin iso for lenovo Z13 and Z16
Hi Fedora Devs, Would someone be able to help getting an official-respin done from F36 latest please? Similar to what was done for the Carbons etc. We need one for the Z13 & Z16 preload. We're waiting on one FW fix but Fedora itself is in good shape (at least from my testing) so I want to get an image into the QA team so they can get started Thanks! Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Shall we add a limit to number of packages in a Bodhi update?
On Wed, 2022-07-13 at 19:49 +0200, Fabio Valentini wrote: > On Wed, Jul 13, 2022 at 7:32 PM Maxwell G via devel > wrote: > > > > On 22/07/13 08:58AM, Adam Williamson wrote: > > > It's also where we usually route *manual* testing feedback. If people > > > can't comment and karma a Bodhi update, where can they test this big > > > and very-potentially-destabilizing change? > > > > The go rebuilds in question are not very destabilizing, and they don't > > have breaking changes. The packages are simply getting rebuilt against > > the new go minor version with fixes for the CVE(s). I've already had to > > waive the tests, as they timed out when trying to download the 300+ > > packages in the update. > > I wonder if it would have made sense to have submitted those 300+ > builds in separate bodhi updates (at least in several smaller batches, > if not individually)? > At least in this case, that would've been a little bit more work, but > would have caused less of a chance to break bodhi. > As far as I can tell, there's no reason the builds need to be handled > together, as the only thing that ties these builds together is the > *reason* why they were rebuilt, but they don't necessary need to be > pushed to testing or stable as a single unit. If they need to be rebuilt for an API/ABI change, then by policy they should be grouped together. We do not want a situation where the API/ABI change gets pushed stable but some of the rebuilds do not, or vice versa. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Shall we add a limit to number of packages in a Bodhi update?
On 22/07/13 07:49PM, Fabio Valentini wrote: > I wonder if it would have made sense to have submitted those 300+ > builds in separate bodhi updates (at least in several smaller batches, > if not individually)? > At least in this case, that would've been a little bit more work, but > would have caused less of a chance to break bodhi. > As far as I can tell, there's no reason the builds need to be handled > together, as the only thing that ties these builds together is the > *reason* why they were rebuilt, but they don't necessary need to be > pushed to testing or stable as a single unit. You're right. They don't have to be rebuilt together as long as the patched version of golang/the libraries with CVEs are in the buildroot. I decided to handle them as a single update to make it easier to manage/organize. I don't want to have to manage 300+ different updates and have my Fedora mailbox flooded with notifications from them. The RH prodsec team already does a good enough job at flooding my inbox :(. It probably wouldn't be too much effort to split them into multiple batches, though. --- Also, there was a new golang version released today that has fixes for 9 CVEs, so I will probably have to do another rebuild in F36 and Rawhide. It would be helpful if we could come to a conclusion about how to handle this properly sooner rather than later. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Script to get all deps of a package (for soname bumps etc.)
On 22/07/13 05:35PM, Ankur Sinha wrote:
> > This is what we (I) aren't sure of, and that's why I first obtain the
> capabilities manually and then query for them. If someone can confirm
> that this is indeed the case, that would certainly simplify things.
Here is confirmation:
```
sudo dnf repoquery --repo=rawhide{,-source} -q --whatrequires
python3-setuptools | grep '\.src' | grep yt-dlp
yt-dlp-0:2022.06.29-2.fc37.src
$ sudo dnf repoquery --repo=rawhide-source -q --requires yt-dlp | grep
setuptools
python3dist(setuptools) >= 40.8
```
yt-dlp depends on one of `python3-setuptool`'s virtual provides, and it is still
found when using the command I gave to find which packages BuildRequire
a certain other package. This also works when querying runtime
dependencies:
```
$ sudo dnf repoquery -q --repo=rawhide --requires reuse | grep setuptools
python3.11dist(setuptools)
$ sudo dnf repoquery -q --repo=rawhide --whatrequires python3-setuptools | grep
reuse
reuse-0:1.0.0-2.fc37.noarch
```
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Shall we add a limit to number of packages in a Bodhi update?
On Wed, Jul 13, 2022 at 7:32 PM Maxwell G via devel wrote: > > On 22/07/13 08:58AM, Adam Williamson wrote: > > It's also where we usually route *manual* testing feedback. If people > > can't comment and karma a Bodhi update, where can they test this big > > and very-potentially-destabilizing change? > > The go rebuilds in question are not very destabilizing, and they don't > have breaking changes. The packages are simply getting rebuilt against > the new go minor version with fixes for the CVE(s). I've already had to > waive the tests, as they timed out when trying to download the 300+ > packages in the update. I wonder if it would have made sense to have submitted those 300+ builds in separate bodhi updates (at least in several smaller batches, if not individually)? At least in this case, that would've been a little bit more work, but would have caused less of a chance to break bodhi. As far as I can tell, there's no reason the builds need to be handled together, as the only thing that ties these builds together is the *reason* why they were rebuilt, but they don't necessary need to be pushed to testing or stable as a single unit. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Shall we add a limit to number of packages in a Bodhi update?
On 22/07/13 08:58AM, Adam Williamson wrote: > It's also where we usually route *manual* testing feedback. If people > can't comment and karma a Bodhi update, where can they test this big > and very-potentially-destabilizing change? The go rebuilds in question are not very destabilizing, and they don't have breaking changes. The packages are simply getting rebuilt against the new go minor version with fixes for the CVE(s). I've already had to waive the tests, as they timed out when trying to download the 300+ packages in the update. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On 6/30/22 10:23, Michael Catanzaro wrote: I take a pretty dim view towards arguments about "Flathub is untrusted" and "Flathub packaging is poor" since proponents of these arguments conveniently ignore the fact that traditional RPMs are totally unsandboxed. [...] Opponents of Flatpak have had seven years since Flatpak launched to figure out an alternative model to make apps safe using firejail or bwrap or whatever, but nobody ever seriously did, and at this point the endgame has arrived with a *commanding* lead in favor of Flatpak. So it's time to move on. There are two separate issues: sandboxing and library duplication/lifecycle management. I agree that sandboxing is desirable, but I don't think we should give up on the shared libraries, because of their savings of memory and storage, and because of their better security profile. I see how RPM-driven flatpaks can actually mitigate the security issue--presumably any vulnerability fixes/updates to system libraries also end up in the rebuilt flatpaks, so they would not rot in place. Still, the library/runtime duplication bothers me and I hope that there will be some technical solution to it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Script to get all deps of a package (for soname bumps etc.)
On Wed, 13 Jul 2022 at 18:43, Stephen Smoogen wrote: > > > > On Wed, 13 Jul 2022 at 12:25, Iñaki Ucar wrote: >> >> On Wed, 13 Jul 2022 at 18:13, Robbie Harwood wrote: >> > >> > Maxwell G via devel writes: >> > >> > > I believe Miro uses this for the FTI bugs. It tends to be more accurate, >> > > especially when there hasn't been a compose for a couple days. If this >> > > is something people are interested in, I think it's worthwhile to >> > > include this repo definition in fedora-packager. >> > >> > An authoritative, preferably single, simple command to run to answer the >> > question "across all architectures, what needs my package and in what >> > form?" would be really helpful. Even if there's a "correct" way to do >> > it today, it's not discoverable (as evidenced by these threads) nor is >> > it easy to remember. Something like `dnf whatuses src:mypackage` (or of >> > similar simplicity) would be appreciated. >> >> If this functionality requires defining and enabling additional repos, >> maybe dnf is not the proper place? But then maybe fedpkg is. Anyway, I >> agree that a simple command would be very much appreciated. >> > > fedpkg would only call dnf to try and get the same information. It doesn't > have any better window on things It could e.g. package the necessary "development" repos and activate them when calling dnf. -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Script to get all deps of a package (for soname bumps etc.)
Hello, Thanks for that---some really useful bits in there that I wasn't aware of. On Wed, Jul 13, 2022 10:09:10 -0500, Maxwell G wrote: > I don't think you need to do all of this. With > > ``` > sudo dnf repoquery --repo=rawhide -q --whatrequires dcmtk | xargs sudo dnf > repoquery --repo=rawhide -q --latest-limit 1 --source > ``` > > AFAIK, dnf repoquery is smart enough to figure out the virtual provides > by itself. This is what we (I) aren't sure of, and that's why I first obtain the capabilities manually and then query for them. If someone can confirm that this is indeed the case, that would certainly simplify things. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Script to get all deps of a package (for soname bumps etc.)
On Wed, 13 Jul 2022 at 12:25, Iñaki Ucar wrote: > On Wed, 13 Jul 2022 at 18:13, Robbie Harwood wrote: > > > > Maxwell G via devel writes: > > > > > I believe Miro uses this for the FTI bugs. It tends to be more > accurate, > > > especially when there hasn't been a compose for a couple days. If this > > > is something people are interested in, I think it's worthwhile to > > > include this repo definition in fedora-packager. > > > > An authoritative, preferably single, simple command to run to answer the > > question "across all architectures, what needs my package and in what > > form?" would be really helpful. Even if there's a "correct" way to do > > it today, it's not discoverable (as evidenced by these threads) nor is > > it easy to remember. Something like `dnf whatuses src:mypackage` (or of > > similar simplicity) would be appreciated. > > If this functionality requires defining and enabling additional repos, > maybe dnf is not the proper place? But then maybe fedpkg is. Anyway, I > agree that a simple command would be very much appreciated. > > fedpkg would only call dnf to try and get the same information. It doesn't have any better window on things -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Shall we add a limit to number of packages in a Bodhi update?
Jul 13, 2022 10:45:02 AM Mattia Verga via devel : > Meanwhile I'll keep an eye on the recent massive Golang update (which > carries 315 builds...) to see if it shows any hiccups. (I'm quite > surprised it didn't screw up already) The recent 315 build F35 Bodhi update is not the first one that I've done. I've done the same thing for F36 and F37 with minimal hiccups, including the gating tests timing out due to the amount of packages and needing to be waived. The other rebuilds that I did not perform had issues for reasons unrelated to the amount of packages in them. I've also written a script to check for new builds that involve the packages in the rebuild so I can warn the packagers not to push those until the sidetag is merged to avoid the problem we had with snapd last time. > I wonder if it would be safe to set a cap to the number of builds a > single Bodhi update can carry. I think **really** massive updates (say > more than 99 builds?) should be handled manually asking Releng to merge > the side-tag manually. That's fine with me. I'm happy to work with releng to make this process smoother in the future. The Python rebuilds are already handled like this. However, they have thousands of packages instead of hundreds. Would those still have to wait 7 days, though? The nice thing about submitting through Bodhi is that the updates can get karma and proceed to stable sooner, which is desirable for security updates. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Script to get all deps of a package (for soname bumps etc.)
On Wed, 13 Jul 2022 at 18:13, Robbie Harwood wrote: > > Maxwell G via devel writes: > > > I believe Miro uses this for the FTI bugs. It tends to be more accurate, > > especially when there hasn't been a compose for a couple days. If this > > is something people are interested in, I think it's worthwhile to > > include this repo definition in fedora-packager. > > An authoritative, preferably single, simple command to run to answer the > question "across all architectures, what needs my package and in what > form?" would be really helpful. Even if there's a "correct" way to do > it today, it's not discoverable (as evidenced by these threads) nor is > it easy to remember. Something like `dnf whatuses src:mypackage` (or of > similar simplicity) would be appreciated. If this functionality requires defining and enabling additional repos, maybe dnf is not the proper place? But then maybe fedpkg is. Anyway, I agree that a simple command would be very much appreciated. -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2106752] perl-Chart-2.403.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106752 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Chart-2.403.2-1.fc37 --- Comment #1 from Petr Pisar --- An enhancement release suitable for Fedora ≥ 37. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106752 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2106752] perl-Chart-2.403.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106752 Petr Pisar changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED CC|ppi...@redhat.com | -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106752 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Announcing qatlib soversion bump in next release
Hi All, QATlib 22.07 (https://github.com/intel/qatlib) is going to be released in about 2 weeks. This will include a soversion bump (from 2 to 3). I can rebuild the dependent packages (qatlib and qatengine) once qatlib is be updated. Regards, -- Giovanni ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Script to get all deps of a package (for soname bumps etc.)
Maxwell G via devel writes: > I believe Miro uses this for the FTI bugs. It tends to be more accurate, > especially when there hasn't been a compose for a couple days. If this > is something people are interested in, I think it's worthwhile to > include this repo definition in fedora-packager. An authoritative, preferably single, simple command to run to answer the question "across all architectures, what needs my package and in what form?" would be really helpful. Even if there's a "correct" way to do it today, it's not discoverable (as evidenced by these threads) nor is it easy to remember. Something like `dnf whatuses src:mypackage` (or of similar simplicity) would be appreciated. Be well, --Robbie 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Shall we add a limit to number of packages in a Bodhi update?
On Wed, 2022-07-13 at 15:38 +, Mattia Verga via devel wrote: > Bodhi is a nice interface to create multi-builds update from side-tags, > but it is not really optimized for massive updates. In the past we had > some troubles pushing updates with a lot of builds. There are too many > things done in the background that can break while processing a massive > update and making Bodhi more reliable is not so simple. > > I wonder if it would be safe to set a cap to the number of builds a > single Bodhi update can carry. I think **really** massive updates (say > more than 99 builds?) should be handled manually asking Releng to merge > the side-tag manually. > > I'd like to hear someone else opinion, especially from FESCo and Releng > members. Meanwhile I'll keep an eye on the recent massive Golang update > (which carries 315 builds...) to see if it shows any hiccups. (I'm quite > surprised it didn't screw up already) Well, one awkward thing about this is that Bodhi is where we've implemented quite a lot of CI/test automation integration. Fedora CI runs tests at the package build level, but the results are primarily shown - and gating is potentially done - at the Bodhi update level. openQA runs tests at the Bodhi update level; if there isn't an update, it will not automatically run tests. It's also where we usually route *manual* testing feedback. If people can't comment and karma a Bodhi update, where can they test this big and very-potentially-destabilizing change? 99+-package updates are exactly the kind of case where we'd *want* to consider automated test results before deciding to merge, usually. If Bodhi can't be improved to handle this, I'd really want the alternative path to have proper consideration for integrating test feedback, both manual and automated. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2102698] Add perl-UNIVERSAL-moniker to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2102698 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-e717a06552 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e717a06552 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102698 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Shall we add a limit to number of packages in a Bodhi update?
Bodhi is a nice interface to create multi-builds update from side-tags, but it is not really optimized for massive updates. In the past we had some troubles pushing updates with a lot of builds. There are too many things done in the background that can break while processing a massive update and making Bodhi more reliable is not so simple. I wonder if it would be safe to set a cap to the number of builds a single Bodhi update can carry. I think **really** massive updates (say more than 99 builds?) should be handled manually asking Releng to merge the side-tag manually. I'd like to hear someone else opinion, especially from FESCo and Releng members. Meanwhile I'll keep an eye on the recent massive Golang update (which carries 315 builds...) to see if it shows any hiccups. (I'm quite surprised it didn't screw up already) 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Script to get all deps of a package (for soname bumps etc.)
On 22/07/13 02:19PM, Ankur Sinha wrote:
> Hi folks,
>
> I'm sure this exists somewhere but I couldn't find one, so with the help
> of folks on #fedora-devel, I hacked up this simple shell script to get
> the all the deps of a package. It's useful when your package update
> includes a soname bump, and you need to figure out what packages need to
> be rebuilt etc.
>
> https://pagure.io/fedora-get-package-dependencies/blob/main/f/get_deps.sh
>
> It lists all the capabilities of the package, and then asks dnf to list
> what packages require any of them. It should cover most cases.
>
> If someone has a better script, please do share it, and please feel free
> to improve this one too. I'm more than happy to give everyone access to
> the repo and/or hand it over to a particular package maintainers related
> pagure group.
I don't think you need to do all of this. With
```
sudo dnf repoquery --repo=rawhide -q --whatrequires dcmtk | xargs sudo dnf
repoquery --repo=rawhide -q --latest-limit 1 --source
```
AFAIK, dnf repoquery is smart enough to figure out the virtual provides
by itself. You can install fedora-repos-rawhide on a stable Fedora
release to get the rawhide repo definitions. (They're disabled by
default, so don't worry about your packages getting updated to rawhide
versions!) `--release rawhide` is not what you want. On my system, it
adds a few seconds to the script's execution, as it tries to load the
rawhide version for all of the enabled repositories. You only want to
query the rawhide repo itself.
A better version of the above would be
```
sudo dnf repoquery --repo=rawhide -q --whatrequires dcmtk | xargs sudo dnf
repoquery --repo=rawhide -q --source | pkgname | sort | uniq
```
which just includes the *names* of the affected source packages. This is
most likely what you want for doing rebuilds.
If you're trying to find which source packages *Build*Require something,
you can use
```
sudo dnf repoquery --repo=rawhide{,-source} -q --whatrequires dcmtk-devel |
grep '\.src' | pkgname | sort | uniq
```
You can add --recursive to either command if appropriate.
You can also add a .repo file for the koji buildroot repository and
query that
```
$ cat /etc/distro.repos.d/koji.repo
[koji]
name=koji
baseurl=http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/
enabled=0
[koji-source]
name=koji-source
baseurl=http://kojipkgs.fedoraproject.org/repos/rawhide/latest/src/
enabled=0
```
I believe Miro uses this for the FTI bugs. It tends to be more accurate,
especially when there hasn't been a compose for a couple days. If this
is something people are interested in, I think it's worthwhile to
include this repo definition in fedora-packager.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20220713.n.0 compose check report
Missing expected images: Minimal raw-xz armhfp Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 16/239 (x86_64), 31/167 (aarch64) New failures (same test not failed in Fedora-Rawhide-20220712.n.0): ID: 1323573 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home URL: https://openqa.fedoraproject.org/tests/1323573 ID: 1323631 Test: x86_64 Workstation-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1323631 ID: 1323644 Test: x86_64 Workstation-live-iso eog URL: https://openqa.fedoraproject.org/tests/1323644 ID: 1323651 Test: x86_64 Workstation-live-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1323651 ID: 1323664 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1323664 ID: 1323703 Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1323703 ID: 1323725 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi URL: https://openqa.fedoraproject.org/tests/1323725 ID: 1323732 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/1323732 ID: 1323734 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/1323734 ID: 1323741 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/1323741 ID: 1323747 Test: aarch64 Server-dvd-iso install_repository_nfs_variation@uefi URL: https://openqa.fedoraproject.org/tests/1323747 ID: 1323771 Test: aarch64 Server-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1323771 ID: 1323774 Test: aarch64 Server-raw_xz-raw.xz base_package_install_remove@uefi URL: https://openqa.fedoraproject.org/tests/1323774 ID: 1323824 Test: x86_64 Workstation-upgrade desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/1323824 ID: 1323831 Test: aarch64 Workstation-upgrade nautilus@uefi URL: https://openqa.fedoraproject.org/tests/1323831 ID: 1323835 Test: aarch64 Workstation-upgrade help_viewer@uefi URL: https://openqa.fedoraproject.org/tests/1323835 ID: 1323836 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi URL: https://openqa.fedoraproject.org/tests/1323836 ID: 1323837 Test: aarch64 Workstation-upgrade desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1323837 ID: 1323839 Test: aarch64 Workstation-upgrade desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1323839 ID: 1323842 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1323842 ID: 1323846 Test: aarch64 Workstation-upgrade clocks@uefi URL: https://openqa.fedoraproject.org/tests/1323846 ID: 1323847 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1323847 ID: 1323850 Test: aarch64 Workstation-upgrade desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/1323850 ID: 1323937 Test: aarch64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/1323937 ID: 1323953 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/1323953 ID: 1323966 Test: aarch64 universal install_repository_http_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1323966 ID: 1323970 Test: aarch64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/1323970 ID: 1323980 Test: aarch64 Minimal-raw_xz-raw.xz base_package_install_remove@uefi URL: https://openqa.fedoraproject.org/tests/1323980 ID: 1323983 Test: aarch64 Minimal-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1323983 ID: 1323984 Test: aarch64 Minimal-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/1323984 ID: 1323994 Test: aarch64 Server-dvd-iso server_cockpit_default@uefi URL: https://openqa.fedoraproject.org/tests/1323994 ID: 1324010 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1324010 ID: 1324032 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1324032 ID: 1324033 Test: aarch64 universal install_serial_console@uefi URL: https://openqa.fedoraproject.org/tests/1324033 ID: 1324321 Test: aarch64 universal install_addrepo_metalink_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1324321 ID: 1324322 Test: aarch64 universal install_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/1324322 Old failures (same test failed in Fedora-Rawhide-20220712.n.0): ID: 1323641 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1323641 ID: 1323671 Test: x86_64
Re: rpmbuild is very slow with large files
On 7/11/22 Marius Schwarz wrote:
I have just create(d/ not finished yet, started 15 minutes ago) a ~2.5 GB rpm
and found, that rpmbuild is an extrem bottleneck.
IMHO, this is caused by a fileread function which reads files in 32k blocks,
which is very slow and extrem IO intensive. The result is a task running at 1
core at 100% perma. With changes to larger chunks, we can speed up so many
build tasks on the farm.
Multicore use would also be helpful i.e. while packing the files.
Any counter-arguments ?
If you give the complete package name and URL of the repo,
then more persons may be likely to help investigate.
Specifying a reproducible example is always good.
If you know "strace -p $PID" then please learn "perf record -p $PID".
If the size of the package is in gigabytes, then upstream bears some
responsibility for investigating and documenting the use of
data compression with the package. What does upstream say?
In the few samples of "read(" from the output of strace,
there I see text similar to JSON or XML tags. A large dataset
that contains zillions of repetitions of only a few dozen
tags, creates O(n**2) work for deflation. Finding many matches
of any particular tag is quick, but which match can be extended
the most, considering the exact context of prefixes and suffixes?
A "looser" compression such as "gzip -3" or lzo might be
much faster with only slightly larger output.
A software implementation of a hardware technique such as WK,
or even "ancient" modem compression MNP5 or MNP10,
might also be a good choice.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Request for fence-agents-pve package
ive been trying to rebuild their rpm using only the missing agents and
am having trouble getting the sources at a minimum. would someone be
able and interested in helping get these other agents into epel?
i am happy to test and will be a constant user, but not sure i am the
best for long term maintainer of the package.
thanks.
On 2022-06-29 15:02, Carl George wrote:
Correct, a fence-agents-epel package is probably the best choice here.
Are you interested in creating and maintaining that? It's described
in further detail in the EPEL docs [0], although it's lacking
examples.
[0] https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/
On Tue, Jun 21, 2022 at 9:15 AM Alex Talaran wrote:
Carl,
it looks like this will not be included in centos stream per RH. so
looks like option 2 or 3 would be next right? to help the greater
community 3 might be better since other agents are missing too.
https://bugzilla.redhat.com/show_bug.cgi?id=2098360
On 2022-06-17 16:28, Carl George wrote:
On Fri, Jun 17, 2022 at 8:31 AM Alex Talaran wrote:
would anyone be willing to package this in epel or help get it in the
existing package please?
i asked on bugzilla [1] but the current maintainer isnt able to help at
the moment. from what i can tell it might just need uncommented in the
spec file [2]. someone else asked about it [1][3] and the ownership is
being thrown back and forth between epel and rhel.
[1]
https://bugzilla.redhat.com/show_bug.cgi?id=2029251
[2]
https://github.com/ClusterLabs/fence-agents/blob/main/fence-agents.spec.in#L33
[3]
https://github.com/ClusterLabs/fence-agents/issues/456
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
In Fedora fence-agents-pve is a subpackage of fence-agents.
fence-agents is in RHEL, so the Fedora package cannot be branched
as-is for EPEL. Some possible alternatives:
- Open a CentOS Stream bugzilla and request that fence-agents-pve be
added to the fence-agents spec file. If the maintainer agrees, it
will show up in the next RHEL minor release ("next" being contingent
on timing). This is the ideal solution from a packaging perspective
but has a fair chance of being declined if RHEL doesn't want to
ship/support that subpackage.
- Create a stand-alone fence-agents-pve package, and get it reviewed
as an EPEL-only package. That would be allowed in EPEL because
neither the srpm or rpm name would conflict with RHEL.
- Create a fence-agents-epel package that contains all the subpackages
that are disabled in the RHEL spec file. Similar to the previous
option, this would be EPEL-only and would be allowed because the srpm
and rpm names don't conflict with RHEL.
- Rebuild the Fedora spec file with all subpackages somewhere where
replacing base packages is allowed, such as a copr or a CentOS SIG.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Blueman and polkit - safe to remove "wheel" group requirement?
On Fri, 01 Jul 2022 11:56:38 - "Artur Frenszek-Iwicki" wrote: > Blueman, the bluetooth manager [0], requires the user to be in the > "wheel" group in order to perform certain functions (like > enabling/disabling bluetooth). This leads to a sub-optimal user > experience, where the user is prompted to authenticate as root in > order to perform certain actions. [1] I am using blueberry instead of blueman because blueberry does not require the root password. It looks like blueberry does not use any special privileges but just calls /usr/bin/rfkill. (Bluman manipulates /dev/rfkill). As a normal user I can use /usr/sbin/rfkill to list, block, and unblock the bluetooth adapter. I can also run bluetoothctl as a normal user. I think blueman should run with the same privileges as these other tools. Jim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2102685] Add perl-Graph to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2102685 Jitka Plesnikova changed: What|Removed |Added Flags||needinfo?(walt@gouldfamily. ||org) ||needinfo?(igor.raits@gmail. ||com) --- Comment #1 from Jitka Plesnikova --- Hi, I can take care of the build if you grant me access. My FAS username is jplesnik. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102685 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Script to get all deps of a package (for soname bumps etc.)
On Wed, 2022-07-13 at 14:19 +0100, Ankur Sinha wrote: > Hi folks, > > I'm sure this exists somewhere but I couldn't find one, (IMHO) The script that give really all deps is find_unblocked_orphans.py from https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py , you can use it with option --skip-orphans for example : find_unblocked_orphans.py --max_deps 30 --skip-orphans glib It is used by Miro to generate the weekly reports for orphans packages . I'm still working in some improvements of the script , which aren't finished yet (neither published) > so with the help > of folks on #fedora-devel, I hacked up this simple shell script to > get > the all the deps of a package. It's useful when your package update > includes a soname bump, and you need to figure out what packages need > to > be rebuilt etc. > > https://pagure.io/fedora-get-package-dependencies/blob/main/f/get_deps.sh > > It lists all the capabilities of the package, and then asks dnf to > list > what packages require any of them. It should cover most cases. > > If someone has a better script, please do share it, and please feel > free > to improve this one too. I'm more than happy to give everyone access > to > the repo and/or hand it over to a particular package maintainers > related > pagure group. > > Ideally, a script of this form should be noted in the package- > maintainer > docs so we can all use it. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2102687] Add perl-Text-RecordParser to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2102687 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|emman...@seyman.fr |jples...@redhat.com --- Comment #1 from Jitka Plesnikova --- https://pagure.io/releng/fedora-scm-requests/issue/45731 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102687 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2102581] Add perl-SQL-Abstract to EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2102581 Jitka Plesnikova changed: What|Removed |Added Assignee|spo...@gmail.com|jples...@redhat.com Status|NEW |ASSIGNED --- Comment #3 from Jitka Plesnikova --- (In reply to Tom "spot" Callaway from comment #2) > You have access now. Thank you. https://pagure.io/releng/fedora-scm-requests/issue/45730 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102581 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2106394] perl-Chart-2.403.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106394 Petr Pisar changed: What|Removed |Added Resolution|--- |RAWHIDE Status|MODIFIED|CLOSED Last Closed||2022-07-13 13:42:24 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106394 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2102698] Add perl-UNIVERSAL-moniker to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2102698 Paul Howarth changed: What|Removed |Added Assignee|spo...@gmail.com|p...@city-fan.org Status|NEW |ASSIGNED --- Comment #3 from Paul Howarth --- https://pagure.io/releng/fedora-scm-requests/issue/45729 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102698 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2102698] Add perl-UNIVERSAL-moniker to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2102698 --- Comment #2 from Tom "spot" Callaway --- Paul, you have access now. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102698 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2102581] Add perl-SQL-Abstract to EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2102581 --- Comment #2 from Tom "spot" Callaway --- You have access now. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102581 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Script to get all deps of a package (for soname bumps etc.)
Hi folks, I'm sure this exists somewhere but I couldn't find one, so with the help of folks on #fedora-devel, I hacked up this simple shell script to get the all the deps of a package. It's useful when your package update includes a soname bump, and you need to figure out what packages need to be rebuilt etc. https://pagure.io/fedora-get-package-dependencies/blob/main/f/get_deps.sh It lists all the capabilities of the package, and then asks dnf to list what packages require any of them. It should cover most cases. If someone has a better script, please do share it, and please feel free to improve this one too. I'm more than happy to give everyone access to the repo and/or hand it over to a particular package maintainers related pagure group. Ideally, a script of this form should be noted in the package-maintainer docs so we can all use it. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2106752] New: perl-Chart-2.403.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106752 Bug ID: 2106752 Summary: perl-Chart-2.403.2 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Chart Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com, st...@silug.org Target Milestone: --- Classification: Fedora Releases retrieved: 2.403.2 Upstream release that is considered latest: 2.403.2 Current version/release in rawhide: 2.403.0-1.fc37 URL: http://search.cpan.org/dist/Chart/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/5871/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Chart -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106752 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: proposal idea: EOL notifications
On Wed, Jul 13, 2022 at 6:29 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Sun, Jul 10, 2022 at 06:34:16PM +0200, Miroslav Suchý wrote: > > Dne 08. 07. 22 v 4:59 Stewart Smith via devel napsal(a): > > > > Another - what do we do about, e.g., Fedora IoT and Fedora CoreOS, > > > > which have their own somewhat different release/life cycles? What about > > > > module lifecycles? What is it about*lifecycles* that's important, > > > > anyway? Don't we maybe want to just have a sort of generic system for > > > > "important events"? > > > I view it as a mechanism to communicate well in advance of when someone > > > is going to have to do work. > > > > > > Fedora is the simple case: every 6-12 months you're going to have to > > > upgrade the version of the OS. > > > > And when implementing this for Fedora, can you bear RHEL in mind too? > > Because it has several levels of EOL > > > > https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel > > RHEL is indeed more complicated. But RHEL already has its own subscription > manager that knows when and to what extent a given installation has support. > The two main ways to support SUPPORT_END= on such systems: > > 1. let the subscription management system fill out a date in os-release, >based on the information it has. If appropriate, the date can be adjusted >over time. I'm not aware of any plans to do that. > 2. leave SUPPORT_END= unset, so that the existing mechanisms are used. > > Option 1. has the advantage that over time generic tools might learn > to look at SUPPORT_END=. But if SUPPORT_END= is not a good fit for some > reason, existing mechanisms can continue to be used, i.e. option 2. Right. > Which way is better will depend on the installation type and other details. > > I don't think we should try encode multiple levels of support in os-release. > That file by design is simple: simple to write and simple to read and simple > to interpret. More complicated state can stay external and be a source > for the simplified information in os-release. I agree. And RHEL's lifecycle(s) are fairly complex, depending on exactly what you want to know and what your usage scenarios are. I don't think SUPPORT_END fits there very well. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: proposal idea: EOL notifications
On Tue, Jul 12, 2022 at 2:46 PM Adam Williamson wrote: > > On Mon, 2022-07-11 at 07:02 -0400, Josh Boyer wrote: > > On Sun, Jul 10, 2022 at 12:34 PM Miroslav Suchý wrote: > > > > > > Dne 08. 07. 22 v 4:59 Stewart Smith via devel napsal(a): > > > > > > Another - what do we do about, e.g., Fedora IoT and Fedora CoreOS, > > > which have their own somewhat different release/life cycles? What about > > > module lifecycles? What is it about *lifecycles* that's important, > > > anyway? Don't we maybe want to just have a sort of generic system for > > > "important events"? > > > > > > I view it as a mechanism to communicate well in advance of when someone > > > is going to have to do work. > > > > > > Fedora is the simple case: every 6-12 months you're going to have to > > > upgrade the version of the OS. > > > > > > And when implementing this for Fedora, can you bear RHEL in mind too? > > > Because it has several levels of EOL > > > > > > https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel > > > > RHEL is already implementing it's own scheme for lifecycle metadata. > > How does it work, and is it F/OSS? Is it integrated with the actual > release processes or just updated manually? It's a work in progress and will likely be tied to the Insights service that comes with a RHEL subscription. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Self Introduction: Ítalo Garcia
Hello folks, I am a software engineer who has worked mainly in startups. I have made very few contributions to some free/open source software, but that will be changing :) I just created a package review( https://bugzilla.redhat.com/show_bug.cgi?id=2106699) it is about a new package with aiokafka. If you are near the Ruhr area in Germany maybe we can have a drink or just hang out ;) Best, Italo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20220713.n.0 changes
OLD: Fedora-Rawhide-20220712.n.0 NEW: Fedora-Rawhide-20220713.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 4 Dropped packages:0 Upgraded packages: 119 Downgraded packages: 0 Size of added packages: 3.69 MiB Size of dropped packages:0 B Size of upgraded packages: 5.82 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -116.19 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: authbind-2.1.2-1.fc37 Summary: Allow non-root users to open restricted ports RPMs:authbind Size:109.68 KiB Package: nagelfar-1.3.2-1.fc37 Summary: Syntax checker for Tcl RPMs:nagelfar Size:104.09 KiB Package: rust-memcached-rs-0.4.2-1.fc37 Summary: MemCached Library in Rust RPMs:rust-memcached-rs+default-devel rust-memcached-rs+nightly-devel rust-memcached-rs-devel Size:39.02 KiB Package: tytools-0.9.7-1.fc37 Summary: Collection of tools to manage Teensy boards RPMs:tycmd tycommander tyuploader Size:3.44 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: amprd-3.0.1-1.fc37 Old package: amprd-3.0-9.fc36 Summary: An user-space IPIP encapsulation daemon for the ampr network RPMs: amprd Size: 151.46 KiB Size change: -16 B Changelog: * Tue Jul 12 2022 Jaroslav ??karvada - 3.0.1-1 - New version Resolves: rhbz#2103065 Package: bluedevil-5.25.3-1.fc37 Old package: bluedevil-5.25.2-1.fc37 Summary: Bluetooth stack for KDE RPMs: bluedevil Size: 1.77 MiB Size change: 13.40 KiB Changelog: * Tue Jul 12 2022 Marc Deop - 5.25.3-1 - 5.25.3 Package: breeze-gtk-5.25.3-1.fc37 Old package: breeze-gtk-5.25.2-1.fc37 Summary: Breeze widget theme for GTK RPMs: breeze-gtk breeze-gtk-common breeze-gtk-gtk2 breeze-gtk-gtk3 breeze-gtk-gtk4 Size: 322.45 KiB Size change: 76 B Changelog: * Tue Jul 12 2022 Marc Deop - 5.25.3-1 - 5.25.3 Package: catch22-0.4.0-1.fc37 Old package: catch22-0.3.1-1.fc37 Summary: CAnonical Time-series CHaracteristics RPMs: catch22 python3-catch22 Size: 388.17 KiB Size change: 4.02 KiB Changelog: * Tue Jul 12 2022 Benjamin A. Beasley 0.4.0-1 - Update to 0.4.0 (close RHBZ#2095508) - Add a Python helper script ???compare_output??? to validate test output while allowing for small differences in floating-point values across architectures Package: cfn-lint-0.61.2-1.fc37 Old package: cfn-lint-0.61.1-3.fc37 Summary: CloudFormation Linter RPMs: cfn-lint Size: 2.38 MiB Size change: 75.47 KiB Changelog: * Tue Jul 12 2022 Benjamin A. Beasley 0.61.2-1 - Update to 0.61.2 (close RHBZ#2105446) Package: cinnamon-desktop-5.4.0-2.fc37 Old package: cinnamon-desktop-5.4.0-1.fc37 Summary: Shared code among cinnamon-session, nemo, etc RPMs: cinnamon-desktop cinnamon-desktop-devel Size: 1.22 MiB Size change: -666 B Changelog: * Tue Jul 12 2022 Leigh Scott - 5.4.0-2 - Fix testsound positions in cinnamon-settings Package: conserver-8.2.7-1.fc37 Old package: conserver-8.2.6-6.fc37 Summary: Serial console server daemon/client RPMs: conserver conserver-client Size: 878.64 KiB Size change: 4.32 KiB Changelog: * Tue Jul 12 2022 Luk Zaoral - 8.2.7-1 - Update to 8.2.7 (rhbz#2105250) - Drop unused patches - Fix incorrect license * BSD with advertising and zlib -> BSD and zlib - Fix install-file-in-docs rpmlint warning - Install license into correct destination - Modernize and reformat the specfile - Run upstream test suite - Update URL to homepage and sources - Verify sources signatures Package: dbus-1:1.14.0-2.fc37 Old package: dbus-1:1.14.0-1.fc37 Summary: D-BUS message bus RPMs: dbus dbus-common dbus-daemon dbus-devel dbus-doc dbus-libs dbus-tests dbus-tools dbus-x11 Size: 5.30 MiB Size change: 4.90 KiB Changelog: * Tue Jul 12 2022 David King - 1:1.14.0-2 - Use sysusers.d snippet for user configuration (#2105177) Package: dovecot-1:2.3.19.1-2.fc37 Old package: dovecot-1:2.3.19.1-1.fc37 Summary: Secure imap and pop3 server RPMs: dovecot dovecot-devel dovecot-mysql dovecot-pgsql dovecot-pigeonhole Size: 28.47 MiB Size change: 3.62 KiB Changelog: * Tue Jul 12 2022 Michal Hlavinka - 1:2.3.19.1-2 - fix possible privilege escalation when similar master and non-master passdbs are used Package: erlang-eradius-2.2.4-1.fc37 Old package: erlang-eradius-0.9.2-6.fc35 Summary: Erlang RADIUS server framework RPMs: erlang-eradius Size: 256.69 KiB Size change: -6.27 KiB Changelog: * Thu Jan 20 2022 Fedora Release Engineering - 0.9.2-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Tue Jul 12 2022 Peter Lemenkov - 2.2.4-1 - Ver. 2.2.4 Pack
Re: proposal idea: EOL notifications
On Sun, Jul 10, 2022 at 06:34:16PM +0200, Miroslav Suchý wrote: > Dne 08. 07. 22 v 4:59 Stewart Smith via devel napsal(a): > > > Another - what do we do about, e.g., Fedora IoT and Fedora CoreOS, > > > which have their own somewhat different release/life cycles? What about > > > module lifecycles? What is it about*lifecycles* that's important, > > > anyway? Don't we maybe want to just have a sort of generic system for > > > "important events"? > > I view it as a mechanism to communicate well in advance of when someone > > is going to have to do work. > > > > Fedora is the simple case: every 6-12 months you're going to have to > > upgrade the version of the OS. > > And when implementing this for Fedora, can you bear RHEL in mind too? Because > it has several levels of EOL > > https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel RHEL is indeed more complicated. But RHEL already has its own subscription manager that knows when and to what extent a given installation has support. The two main ways to support SUPPORT_END= on such systems: 1. let the subscription management system fill out a date in os-release, based on the information it has. If appropriate, the date can be adjusted over time. 2. leave SUPPORT_END= unset, so that the existing mechanisms are used. Option 1. has the advantage that over time generic tools might learn to look at SUPPORT_END=. But if SUPPORT_END= is not a good fit for some reason, existing mechanisms can continue to be used, i.e. option 2. Which way is better will depend on the installation type and other details. I don't think we should try encode multiple levels of support in os-release. That file by design is simple: simple to write and simple to read and simple to interpret. More complicated state can stay external and be a source for the simplified information in os-release. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: proposal idea: EOL notifications
On Mon, Jul 11, 2022 at 08:52:28AM -0500, Kate Stewart wrote: > On Mon, Jul 11, 2022 at 6:02 AM Josh Boyer > wrote: > > > On Sun, Jul 10, 2022 at 12:34 PM Miroslav Suchý wrote: > > > > > > Dne 08. 07. 22 v 4:59 Stewart Smith via devel napsal(a): > > > > > > Another - what do we do about, e.g., Fedora IoT and Fedora CoreOS, > > > which have their own somewhat different release/life cycles? What about > > > module lifecycles? What is it about *lifecycles* that's important, > > > anyway? Don't we maybe want to just have a sort of generic system for > > > "important events"? > > > > > > I view it as a mechanism to communicate well in advance of when someone > > > is going to have to do work. > > > > > > Fedora is the simple case: every 6-12 months you're going to have to > > > upgrade the version of the OS. > > > > > > And when implementing this for Fedora, can you bear RHEL in mind too? > > Because it has several levels of EOL > > > > > > > > https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel > > > > RHEL is already implementing it's own scheme for lifecycle metadata. > > > > A "ValidUntilDate" was added to SPDX 2.3 about a month ago, to enable > capture of End of Support / End of Life information as metadata captured > about a package or group of packages, so different policies can be > articulated this way. (see: https://github.com/spdx/spdx-spec/pull/709). > In 2.3, it's an optional field, so if the information is available, > there's a place to put it. Similarly a ReleaseDate and BuiltDate were > added, which are useful in some policy and automated checkers. Those two approaches should not conflict. Maybe at some point we'll have the information in two places, but that's not a problem. (Right now we don't have include generate the spdx BOM for packages that we build, nor is there any mechanism for making it available in Fedora installations. So the spdx fields are not directly relevant for us, at least for 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2102581] Add perl-SQL-Abstract to EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2102581 --- Comment #1 from Jitka Plesnikova --- I can take care of the build if you grant me access. My FAS username is jplesnik. It needs to be built twice due to bootstrap. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102581 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: You can't be serious! you want to remove mesa-libGL.i686 support?
Hi All!
On 7/6/22 01:24, Miro Hrončok wrote:
On 06. 07. 22 1:17, Miro Hrončok wrote:
On 06. 07. 22 0:14, Kevin Kofler via devel wrote:
Stephen Smoogen wrote:
Hyperbole aside, it isn't a joke. Looking at the chain we see a common
If mesa's i686 support should be removed, then this proposal would need to be
reverted.
I had filled bugs against all native direct dependencies of java (eg subversion) and against all packages, which transitively depends on java, and are themsleves important (being dependence of 78+ other pkgs[that is where the non linear
curve really started to grow]). All direct no-arch deps got injected ExclusiveArch: %{java_arches}. See https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs#Workflow; there are also exact listings of what was filled bug agasint.
problem where subversion relies on java-11-openjdk and without it is going
to cause a lot of packages to be removed. Either subversion needs to lose
that requirement or a lot of packages are going to get removed as failure
to build in i686.
libglvnd-glx<-mesa-libGL<-libxcb<-doxygen<-git<-subversion<-java-11-
openjdk-devel
This email isn't a comment about it being a good or bad thing.. it is just
what is being presented.
I do not see why bogus "bug" reports are filed against a bazillion packages
when subversion is the only package that needs to be fixed.
I cant agree. Of course subversion is main to act, but afaik all its dependence
should be warned. Otherwise they would suddenly got very weird FTBFS on i686.
My investigations shown, probably nothing will be affected by removal of jdk on i686 and the fix in subversion and automake/autotools is fluid and, again, will damage nothing. However I'm not sure. I can not possibly see into all details of
all affected packages.
Where casual pkg which is being depndent by nothing, may simply get weird
FTBFS, but not a package, on which half of the system depend.
File a bug against subversion, put it on the release blocker tracker, and do
not waste everyone else's time.
Thus saying, is it really waste of time? I really doubt. It is making people aware of quite major happening, and thus about fact, that they may be affected, even if they did not know. Maybe "the script that generated this data and filed
bugs for
packages affected by the removal of Java packages on i686 was a bit
over-zealous." ( to quote :) ) but I still somehow finds it correct.
Jiri, could you please close all the bugzillas that were only opened due to the
subversion<-java dependency now when
https://bugzilla.redhat.com/show_bug.cgi?id=2103909 was fixed?
I've closed some bugs for very important components manualy, but there are
simply too many.
Argh:( You should have not. I'm really reluctant to do so. How can you proof
the package is really not affected by the change?
I have actually second set of dependent packages (with 50-77 dependencies)
prepared to fill bug aganst, if the mass rebuild next week goes bad.
If this thread asks me to close the transitive depndencies of subversion to be closed, I will do so. But I relly think it is bad idea. Owner should check the impact, and close on his own. And actually it is no tso much. It is less then 50
which depends *only* on subversion.
Sorry for delayed reply, Miro, thanx for ping.
J.
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[Bug 2102614] Add perl-Data-Dumper-Concise to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2102614 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2022-7fe882d39c has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-7fe882d39c -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102614 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2102698] Add perl-UNIVERSAL-moniker to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2102698 Paul Howarth changed: What|Removed |Added CC||p...@city-fan.org --- Comment #1 from Paul Howarth --- Hi Spot, I can handle this one if you give me (FAS: pghmcfc) commit access. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102698 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards (System-Wide Change)
On 7/13/22 09:10, Miro Hrončok wrote: On 13. 07. 22 8:58, Jens-Ulrik Petersen wrote: Has a bug been filed against subversion (and other low-lying deps) yet? The bugs were filled agaisnt all native direct depndencies of java(-devel) and against all transitive depndencies of java, which are dependece f more then 50 other packages (that was the point,where the non linear curve really start to grow). (I could not see any bug and wondering why not?) Yes and it has been fixed: https://bugzilla.redhat.com/show_bug.cgi?id=2103909 Thank you for posting this! hth! J. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2105085] perl-HTTP-Daemon: HTTP::Daemon allows request smuggling
https://bugzilla.redhat.com/show_bug.cgi?id=2105085 Petr Pisar changed: What|Removed |Added Link ID||Github ||libwww-perl/HTTP-Daemon/iss ||ues/56 --- Comment #7 from Petr Pisar --- Upstream commits supposedly fixing this vulnerability: e84475de51d6fd7b29354a997413472a99db70b2 Fix Content-Length ', '-separated string issues 8dc5269d59e2d5d9eb1647d82c449ccd880f7fd0 Include reason in response body content faebad54455c2c2919e234202362570925fb99d1 Add new test for Content-Length issues ef8c1265c9558e92bac3178a0ed42eb937d943c6 Remove 'trailing spaces' to satisfy some authors c10445d014584546f99f85d24b4a140ec37a (HEAD -> master, origin/master, origin/HEAD) Add CVE-2022-31081 fix to the Revision History -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2105085 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-35-20220713.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20220712.0): ID: 1323555 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1323555 ID: 1323562 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1323562 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2106528] perl-File-MimeInfo-0.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106528 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-File-MimeInfo-0.33-1.f ||c37 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106528 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2106528] perl-File-MimeInfo-0.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106528 --- Comment #1 from Fedora Update System --- FEDORA-2022-8bcc85b42a has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-8bcc85b42a -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106528 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2106640] perl-Crypt-PasswdMD5-1.42 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106640 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Crypt-PasswdMD5-1.4.2- ||1.fc37 Doc Type|--- |If docs needed, set a value Resolution|--- |RAWHIDE Last Closed||2022-07-13 08:12:11 --- Comment #1 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=89449192 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106640 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2106394] perl-Chart-2.403.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106394 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Chart-2.403.1-1.fc37 --- Comment #1 from Petr Pisar --- An enhancement release. It updates list of colors, documentation, removes Chart::Setting. Suitable for Rawhide only. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106394 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2106528] perl-File-MimeInfo-0.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106528 Jitka Plesnikova changed: What|Removed |Added CC|jples...@redhat.com,| |ktdre...@ktdreyer.com, | |mspa...@redhat.com, | |p...@city-fan.org | Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106528 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2106640] New: perl-Crypt-PasswdMD5-1.42 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106640 Bug ID: 2106640 Summary: perl-Crypt-PasswdMD5-1.42 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Crypt-PasswdMD5 Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: imlinux+fed...@gmail.com, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.42 Upstream release that is considered latest: 1.42 Current version/release in rawhide: 1.4.1-5.fc37 URL: http://search.cpan.org/dist/Crypt-PasswdMD5/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/2750/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Crypt-PasswdMD5 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106640 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2106394] perl-Chart-2.403.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2106394 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value CC|ppi...@redhat.com | -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2106394 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-36-20220713.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-36-20220712.0): ID: 1323539 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1323539 ID: 1323546 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1323546 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards (System-Wide Change)
On 13. 07. 22 8:58, Jens-Ulrik Petersen wrote: Has a bug been filed against subversion (and other low-lying deps) yet? (I could not see any bug and wondering why not?) Yes and it has been fixed: https://bugzilla.redhat.com/show_bug.cgi?id=2103909 -- 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 reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards (System-Wide Change)
Has a bug been filed against subversion (and other low-lying deps) yet? (I could not see any bug and wondering why not?) Naively it looks like the filed bugs are more targeting higher dependent packages which is less useful. I think it is the immediate dependencies like subversion (and possibly some of their direct dependents) which need the most immediate attention. Filing bugs against many higher dependent packages first seems a bit premature yet and creates confusion for many packagers. I think the thread "You can't be serious! you want to remove mesa-libGL.i686 support?" summarizes the problem better, but I wanted to make sure the problem is mentioned clearly here in this Change thread too. Jens ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
