[Bug 2156168] perl-ExtUtils-Install-2.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2156168 Jitka Plesnikova changed: What|Removed |Added Doc Type|--- |If docs needed, set a value CC|jples...@redhat.com,| |mspa...@redhat.com, | |ppi...@redhat.com | 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=2156168 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
On Mon, Jan 02, 2023 at 01:59:46AM +0100, Kevin Kofler via devel wrote: > The application can pick the options with which each library is compiled? > What a stupid idea! Now I understand why the language is called "Rust". Okay. no. This is not how we do things here. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: wlroots 0.16 update announcement
On 11/27/22 14:51, Aleksei Bavshin wrote: Greetings, Sometime within the next week, I'll be updating wlroots in rawhide to 0.16.0[1] and sway to the latest release candidate. As usual, the update contains API/ABI breaking changes and soname will be bumped to libwlroots.so.11. wlroots0.15 compatibility package will be introduced in the same side-tag. No breakages are expected and no action is required from the maintainers of dependent packages. I'll send another notice with a side-tag id to unblock the updates that already require 0.16 (currently only labwc) when it's ready. *** I'm also planning to update wlroots in f37 once 0.16.1 is available. There are a plenty of bug fixes and some important security features (ext-session-lock-v1) that, I believe, should not require waiting another 6 months for f38. Sway will likely not be included in the initial f37 update, but may follow later when it gets sufficient testing. [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.16.0 Sorry for delay, the side-tag for f37 is ready. Use 'fedpkg build --target=f37-build-side-61499' to use it. Please, ping me when you build something into the tag so I could refresh the bodhi update. OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1dfe84c7fe GitPython-3.1.30-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing fluidsynth-2.3.1-1.el9 omniORB-4.3.0-6.el9 omniORBpy-4.3.0-4.el9 rust-clap_lex-0.3.0-2.el9 rust-clap_lex0.2-0.2.4-1.el9 Details about builds: fluidsynth-2.3.1-1.el9 (FEDORA-EPEL-2023-43a0db08ed) Real-time software synthesizer Update Information: Update to 2.3.1 ChangeLog: * Fri Dec 30 2022 Christoph Karl - 2.3.1-1 - Update to 2.3.1 omniORB-4.3.0-6.el9 (FEDORA-EPEL-2023-4b2e1f0ad5) A robust high performance CORBA ORB for C++ and Python Update Information: Initial packages ChangeLog: * Tue Dec 20 2022 Sandro Mani - 4.3.0-6 - Remove last usage of distutils * Mon Dec 19 2022 Sandro Mani - 4.3.0-5 - Add patch to fix build against python-3.12 * Fri Jul 22 2022 Fedora Release Engineering - 4.3.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Mon Jun 13 2022 Python Maint - 4.3.0-3 - Rebuilt for Python 3.11 * Thu Jan 20 2022 Fedora Release Engineering - 4.3.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Mon Jan 10 2022 Sandro Mani - 4.3.0-1 - Update to 4.3.0 * Tue Sep 14 2021 Sahana Prasad - 4.2.4-7 - Rebuilt with OpenSSL 3.0.0 * Thu Jul 22 2021 Fedora Release Engineering - 4.2.4-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Fri Jun 4 2021 Python Maint - 4.2.4-5 - Rebuilt for Python 3.10 * Tue Jan 26 2021 Fedora Release Engineering - 4.2.4-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild References: [ 1 ] Bug #2091150 - Request EPEL9 Package - omniORB https://bugzilla.redhat.com/show_bug.cgi?id=2091150 [ 2 ] Bug #2156893 - Please branch and build omniORB for EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2156893 [ 3 ] Bug #2156907 - Please branch and build omniORBpy for EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2156907 omniORBpy-4.3.0-4.el9 (FEDORA-EPEL-2023-4b2e1f0ad5) CORBA ORB for Python Update Information: Initial packages ChangeLog: * Fri Jul 22 2022 Fedora Release Engineering - 4.3.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Mon Jun 13 2022 Python Maint - 4.3.0-3 - Rebuilt for Python 3.11 * Thu Jan 20 2022 Fedora Release Engineering - 4.3.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Mon Jan 10 2022 Sandro Mani - 4.3.0-1 - Update to 4.3.0 * Thu Jul 22 2021 Fedora Release Engineering - 4.2.4-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Fri Jun 4 2021 Python Maint - 4.2.4-5 - Rebuilt for Python 3.10 * Tue Jan 26 2021 Fedora Release Engineering - 4.2.4-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Tue Jul 28 2020 Fedora Release Engineering - 4.2.4-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild References: [ 1 ] Bug #2091150 - Request EPEL9 Package - omniORB https://bugzilla.redhat.com/show_bug.cgi?id=2091150 [ 2 ] Bug #2156893 - Please branch and build omniORB for EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2156893 [ 3 ] Bug #2156907 - Please branch and build omniORBpy for EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2156907 rust-clap_lex-0.3.0-2.el9 (FEDORA-EPEL-2023-b401592285) Minimal, flexible command line parser Update Information: Update the clap_lex crate to version 0.3.0, and add a compat package for version 0.2 of the crate.
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
Fabio Valentini wrote: > Speaking for myself: Using rpmautospec has massively reduced the > maintenance burden for the Rust stack, and also for other packages > that I maintain. > > Due to the way optional dependencies / features are mapped to RPM > subpackages (this works like with "extra" dependencies in Python > packages, so this is not unique to Rust), you really should regenerate > the entire spec file with rust2rpm for every new version (and every > time when touching a patch that modifies features / optional > dependencies in Rust crate metadata). > > Previously, this meant arduously copying the old changelog contents > somewhere, regenerating the spec file with rust2rpm, copying the old > changelog back, set the Release count to "0", run "rpmdev-bumpspec" > for the latest change, and commit the changes (usually with a useless > duplicate of the changelog entry as commit message). > > With rpmautospec, all steps except "regenerate the spec file with > rust2rpm" and "git commit -c 'changelog contents'" are eliminated, > which makes updating packages *much* easier, faster, and less > error-prone. So it looks like in this case, it helps. That does not mean it needs to be the default for packages which are not autogenerated though. > Additionally, not having Release counter and changelog in the .spec > file means that you can usually freely cherry-pick or merge bug-fix > commits across different dist-git branches. This wasn't possible > without rpmautospec due to merge conflicts caused by different Release > counter or changelog contents. If I have a package that I upgrade in stable releases, I keep Release in sync, and the changelog only really reflects Rawhide. I just fast-forward Rawhide to the release branch, and the Release tag and the changelog go along with it. If that includes some "Rebuild for Fnn mass rebuild" entries that do not really apply to the release branch, so be it. At least it explains why the Release number is as high as it is. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
Fabio Valentini wrote: > - incompatible compile-time options (i.e. resulting in conditional > compilation): different packages depend on crates with different sets > of features enabled, sometimes with conflicting options. Even with a > stable ABI, you'd need to build crates for all necessary combinations > of configurations, and that matrix quickly explodes (i.e. usually > exponentially - 2^n builds for for n independent flags). This is a > deal-breaker for shared libraries in most cases, and also can't be > solved by using a different compiler. (Unless you want to figure out > *which* combinations to build, and *only* build these.) The application can pick the options with which each library is compiled? What a stupid idea! Now I understand why the language is called "Rust". Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 01.01.23 21:48, Jonathan Billings wrote:
On Wed, Aug 24, 2022 at 02:49:21PM +0100, Daniel P. Berrangé wrote:
I've done the same with all the mingw packages I maintained just
before Fedora 37 branched. So the following native packages now
just contain mingw sub-RPMs:
libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc
I don't know if this is a bug in the spec or in the %find_lang RPM
macro, but I've noticed that these packages have files out of the
mingw sys-root included in the non-mingw packages:
$ find /usr/*mingw32/ -type f | xargs rpm -qf | sort -u
gvnc-1.3.0-5.fc37.x86_64
gvncpulse-1.3.0-5.fc37.x86_64
libosinfo-1.10.0-4.fc37.x86_64
libvirt-glib-4.0.0-6.fc37.x86_64
osinfo-db-tools-1.10.0-4.fc37.x86_64
All the files in those packages look like:
/usr/{arch}-w64-mingw32/sys-root/mingw/share/locale/{lang}/LC_MESSAGES/{package}.mo
There's a thread on the users list about the existence of
/usr/i686-w64-mingw32/ and /usr/x86_64-w64-mingw32/ directories on
systems without any mingw* packages installed, and it looks like on my
system it's all due to the most recent commits to these packages to
include mingw subpackages.
I suspect the %find_lang macro's shell script
(/usr/lib/rpm/find_lang.sh) needs to know not to include the mingw
sysroot, or at least filter it out as part of the spec file %install.
That is how the files are getting included in the non-mingw subpackages.
They have: %files -n ... -f %{name}.lang in the %files section.
This should be fixed as of [1] (plus [2]). Simply rebuilding the
packages against a current mingw-filesystem should fix the issue.
[1]
https://src.fedoraproject.org/rpms/mingw-filesystem/c/846156c1bda9bcff98c850714fa5da688a55e66a?branch=rawhide
[2]
https://src.fedoraproject.org/rpms/mingw-filesystem/c/d897e0bb98731e5536c551be2cf401f1ced71138?branch=rawhide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On Wed, Aug 24, 2022 at 02:49:21PM +0100, Daniel P. Berrangé wrote:
> I've done the same with all the mingw packages I maintained just
> before Fedora 37 branched. So the following native packages now
> just contain mingw sub-RPMs:
>
> libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc
I don't know if this is a bug in the spec or in the %find_lang RPM
macro, but I've noticed that these packages have files out of the
mingw sys-root included in the non-mingw packages:
$ find /usr/*mingw32/ -type f | xargs rpm -qf | sort -u
gvnc-1.3.0-5.fc37.x86_64
gvncpulse-1.3.0-5.fc37.x86_64
libosinfo-1.10.0-4.fc37.x86_64
libvirt-glib-4.0.0-6.fc37.x86_64
osinfo-db-tools-1.10.0-4.fc37.x86_64
All the files in those packages look like:
/usr/{arch}-w64-mingw32/sys-root/mingw/share/locale/{lang}/LC_MESSAGES/{package}.mo
There's a thread on the users list about the existence of
/usr/i686-w64-mingw32/ and /usr/x86_64-w64-mingw32/ directories on
systems without any mingw* packages installed, and it looks like on my
system it's all due to the most recent commits to these packages to
include mingw subpackages.
I suspect the %find_lang macro's shell script
(/usr/lib/rpm/find_lang.sh) needs to know not to include the mingw
sysroot, or at least filter it out as part of the spec file %install.
That is how the files are getting included in the non-mingw subpackages.
They have: %files -n ... -f %{name}.lang in the %files section.
--
Jonathan Billings
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Sat, Dec 31, 2022 at 03:37:34PM -0500, Stephen Smoogen wrote: > On Sat, 31 Dec 2022 at 13:40, Kevin Kofler via devel < > > https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#changelog-entries-generated-from-commit-messages > > > > All in all a very complicated and error-prone process just to save some > > extremely lazy packagers a 5-second copy I really do not see why > > that > > should be the default and recommended process. > > > > The rules how to format the commit message are error-prone, and if you get > > them wrong, you usually only notice when it is too late to fix it (because > > force-pushes are not allowed). Yes, you can manually run "rpmautospec > > generate-changelog", but that is actually no less effort than just taking > > care of the changelog manually to begin with. > > > > My main questions are what is this supposed to fix long term? My understanding is that the main thing rpmautospec is supposed to address is to decouple changelog and release values from specific changes. This for example makes pull requests much easier. Without it, pull requests either have to specifically tie a change to a release/changelog entry or leave that to the maintainer. With it, PR's can be applied in any order or after some other unrelated changes without a bunch of back and forth to adjust the release/changelog to match unrelated changes. I think moving more things to it makes a lot of sense as long as we are moving to a more pull request flow. I can't speak for others, but I have indeed noticed a increase in PR's on packages I maintain over the last few years. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
On Sat, Dec 31, 2022 at 3:48 AM Neal Gompa wrote: > > On Fri, Dec 30, 2022 at 9:37 PM Kevin Kofler via devel > wrote: > > > > Neal Gompa wrote: > > > Can we please have gcc-rs also built (even though it's experimental)? > > > > Will gcc-rs be able to generate usable shared libraries for Rust crates? > > > > If someone were to spend the time to build the functionality into its > code generator, sure. I don't think that's high on anyone's list right > now, though. rustc can already produce shared libraries - they're just pretty useless due to two factors: - lack of stable ABI: for every compiler and dependency update, you'd need to recompile everything. And unless work on a stable ABI progresses in upstream Rust, I doubt that gcc-rs can do anything about this. - incompatible compile-time options (i.e. resulting in conditional compilation): different packages depend on crates with different sets of features enabled, sometimes with conflicting options. Even with a stable ABI, you'd need to build crates for all necessary combinations of configurations, and that matrix quickly explodes (i.e. usually exponentially - 2^n builds for for n independent flags). This is a deal-breaker for shared libraries in most cases, and also can't be solved by using a different compiler. (Unless you want to figure out *which* combinations to build, and *only* build these.) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Sat, Dec 31, 2022 at 9:38 PM Stephen Smoogen wrote: > > My main questions are what is this supposed to fix long term? > > I have guessed that it has to do with automation, the shrinking number of > active packagers in operating systems, and the exploding number of packages > in requested languages (Rust, Go, jq, etc). However, that is just a guess and > it doesn't really say "HOW" this gets to dealing with this long term. It also > isn't clear what the underlying remaining active packagers want to be part of. Speaking for myself: Using rpmautospec has massively reduced the maintenance burden for the Rust stack, and also for other packages that I maintain. Due to the way optional dependencies / features are mapped to RPM subpackages (this works like with "extra" dependencies in Python packages, so this is not unique to Rust), you really should regenerate the entire spec file with rust2rpm for every new version (and every time when touching a patch that modifies features / optional dependencies in Rust crate metadata). Previously, this meant arduously copying the old changelog contents somewhere, regenerating the spec file with rust2rpm, copying the old changelog back, set the Release count to "0", run "rpmdev-bumpspec" for the latest change, and commit the changes (usually with a useless duplicate of the changelog entry as commit message). With rpmautospec, all steps except "regenerate the spec file with rust2rpm" and "git commit -c 'changelog contents'" are eliminated, which makes updating packages *much* easier, faster, and less error-prone. Additionally, not having Release counter and changelog in the .spec file means that you can usually freely cherry-pick or merge bug-fix commits across different dist-git branches. This wasn't possible without rpmautospec due to merge conflicts caused by different Release counter or changelog contents. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2157195] perl-Pod-Coverage-TrustPod-0.100006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2157195 Paul Howarth changed: What|Removed |Added Fixed In Version||perl-Pod-Coverage-TrustPod- ||0.16-1.fc38 Status|NEW |CLOSED Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2023-01-01 19:21:40 --- Comment #2 from Paul Howarth --- Build for Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=95706253 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2157195 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2157212] perl-Perl-Critic-Lax-0.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2157212 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Perl-Critic-Lax-0.014- ||1.fc38 Status|MODIFIED|CLOSED Resolution|--- |ERRATA Last Closed||2023-01-01 17:39:46 --- Comment #2 from Fedora Update System --- FEDORA-2023-ce0be35223 has been pushed to the Fedora 38 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=2157212 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2157212] perl-Perl-Critic-Lax-0.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2157212 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2023-ce0be35223 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ce0be35223 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2157212 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Sat, Dec 31, 2022 at 11:44 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Dec 31, 2022 at 11:23:35AM -0500, Neal Gompa wrote: > > On Sat, Dec 31, 2022 at 11:17 AM Miro Hrončok wrote: > > > > > > On 31. 12. 22 15:07, Josh Boyer wrote: > > > > On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa wrote: > > > >> > > > >> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek > > > >> wrote: > > > >>> > > > >>> On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote: > > > On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton > > > wrote: > > > > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default > > > Have we made sure that when Red Hat forks Fedora packages for RHEL > > > that they don't truncate or eliminate the Git history anymore? > > > Because I would > > > personally be very displeased if my historical attribution went away > > > because of broken processes like the one used to fork all the Fedora > > > Linux 34 packages for CentOS Stream 9. > > > >>> > > > >>> I can't speak for the RH folks who do the forking… It'd be great if > > > >>> somebody who knows how that's done could answer. > > > >>> > > > >>> Fedora is already using rpmautospec widely enough that (if it was to > > > >>> be problem at all), it must already be a problem. > > > >>> > > > >>> At the level of specific solutions, obviously the obvious answer is to > > > >>> keep the git history. It's in general a great of source of information > > > >>> and discarding that is just an error. But if somebody were really to > > > >>> do that, > > > >>> it's fairly trivial to undo the conversion and get a static changelog > > > >>> again by inserting the output of 'rpmautospec changelog' in the > > > >>> %changelog > > > >>> section. > > > >>> > > > >> > > > >> As they are the most prominent downstream we have, I would like this > > > >> resolved before changing Fedora's defaults. > > > >> > > > >> At the time we branched from Fedora Linux 34, there were very few > > > >> packages using rpmautospec and I don't think any that were kept used > > > >> rpmautospec. Now it is very obvious it would be a problem, so I would > > > >> like that fixed first. CentOS and RHEL infrastructure needs to account > > > >> for it properly and not gut the Git history. > > > > > > > > We can look into it, but at the moment this is unlikely to change on > > > > the CentOS Stream/RHEL side. > > > > > > Are the packages imported on SRPM level with the changelogs rendered? > > > > > > > They are not. It's done using distrobaker[1], which syncs Git content > > and lookaside data. > > > > Example commit: > > https://gitlab.com/redhat/centos-stream/rpms/pipewire/-/commit/67142e715ecacbf1c94c4d6f8000ef113c1e7c92 > > > > [1]: https://github.com/fedora-eln/distrobaker > > I don't think that changes in Fedora should be held hostage by some downstream > utils. We know that the problem is solvable and in fact not hard at all. We > certainly can notify RHEL maintainers about this, which I did right now [1], > but actual implementation is something that we have no control of from the > Fedora side. > > [1] https://github.com/fedora-eln/distrobaker/issues/12 > I think it's absolutely reasonable to consider the effects of people forking the packages in a way where attribution is lost. Losing attribution and correct package history is just not acceptable to me. In many respects, this is *extremely* personal to me, because all I *have* is that attribution. I don't make any money on my work in Fedora. Nobody pays me to do it. The absolute *least* anyone can do is respect my copyright and preserve the attribution and history. I am insulted that you think that's an issue that can be hand-waved away. This is a hill I will die on. Fix it. And that means fundamentally changing how distrobaker works. Either preserve the whole Git history or always eliminate rpmautospec and expand the changelog when importing into RHEL. The current situation is simply not acceptable. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2157247] perl-Data-OptList-0.113 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2157247 Fedora Update System changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-Data-OptList-0.113-1.f ||c38 Resolution|--- |ERRATA Last Closed||2023-01-01 16:54:45 --- Comment #4 from Fedora Update System --- FEDORA-2023-ba7e82b4b8 has been pushed to the Fedora 38 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=2157247 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2157247] perl-Data-OptList-0.113 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2157247 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-2023-ba7e82b4b8 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ba7e82b4b8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2157247 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2157274] perl-File-Find-Object-0.3.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2157274 --- Comment #1 from Upstream Release Monitoring --- Scratch build failed. Details below: BuilderException: Build failed: Command '['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-1jsd06h2/perl-File-Find-Object.spec']' returned non-zero exit status 1. StdOut: error: Bad source: ./File-Find-Object-0.3.7.tar.gz: No such file or directory Traceback: File "/usr/local/lib/python3.10/site-packages/hotness/use_cases/package_scratch_build_use_case.py", line 56, in build result = self.builder.build(request.package, request.opts) File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line 188, in build raise BuilderException( If you think this issue is caused by some bug in the-new-hotness, please report it on the-new-hotness issue tracker: https://github.com/fedora-infra/the-new-hotness/issues -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2157274 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2157274] New: perl-File-Find-Object-0.3.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2157274 Bug ID: 2157274 Summary: perl-File-Find-Object-0.3.7 is available Product: Fedora Version: rawhide Status: NEW Component: perl-File-Find-Object Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: i...@cicku.me, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 0.3.7 Upstream release that is considered latest: 0.3.7 Current version/release in rawhide: 0.3.6-4.fc37 URL: http://search.cpan.org/dist/File-Find-Object/ 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://docs.fedoraproject.org/en-US/package-maintainers/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/2886/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-File-Find-Object -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2157274 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
* Vitaly Zaitsev via devel: > On 30/12/2022 20:01, Ben Cotton wrote: >> This document represents a proposed Change. As part of the Changes >> process, proposals are publicly announced in order to receive >> community feedback. This proposal will only be implemented if approved >> by the Fedora Engineering Steering Committee. > > -1 until these known issues[1] are fixed, especially with changelogs > and using rpmautospec in COPR or mock. > > [1]: > https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-constraints The page doesnt discuss COPR/mock? COPR seems to work in some cases, specifically with the dist-git build (but not just building from dist-git). A quick check suggests that rpmautospec does the right thing and produces a portable source RPM that doesn't depend on rpmautospec anymore. As a result, the compatibility impact won't be too severe, I hope. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2157237] perl-Getopt-Long-Descriptive-0.111 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2157237 Paul Howarth changed: What|Removed |Added Resolution|--- |RAWHIDE Status|NEW |CLOSED Fixed In Version||perl-Getopt-Long-Descriptiv ||e-0.111-1.fc38 Doc Type|--- |If docs needed, set a value Last Closed||2023-01-01 13:47:53 --- Comment #2 from Paul Howarth --- Build for Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=95703878 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2157237 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
License change: moolticute
While converting moolticute to SPDX licensing, I removed the "effective licensing" strategy that was used. This change is already pushed to rawhide, I forgot to notify the devel list. The license changes from GPLv3 to GPL-3.0-or-later AND (GPL-3.0-only WITH Qt-GPL-exception-1.0) AND BSD-2-Clause AND BSD-3-Clause AND MIT AND OFL-1.1 AND CC-BY-3.0 -- Arthur Bols fas/irc: principis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Retiring qwtplot3d-qt4
Hi all. Current and older 'qwtplot3d' sub-packages (0.2.7) will be obsoleted by newer Qt5/Qt6 rpms of 'qwtplot3d' (0.3.0) The rpm 'qwtplot3d-qt5' will be retired because replaced by 'qwtplot3d' sub-packages. Please, let me know if anyone still needs qwtplot3d (Qt4) 0.2.7 Regards. -- --- Antonio Trande Fedora Project mailto:sagit...@fedoraproject.org GPG key: 0x40FDA7B70789A9CD GPG keys server:https://keyserver.dcc.sib.swiss/ OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20230101.n.0 changes
OLD: Fedora-Rawhide-20221231.n.0 NEW: Fedora-Rawhide-20230101.n.0 = SUMMARY = Added images:0 Dropped images: 2 Added packages: 0 Dropped packages:0 Upgraded packages: 34 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 4.78 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -151.65 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Python_Classroom raw-xz aarch64 Path: Labs/aarch64/images/Fedora-Python-Classroom-Rawhide-20221231.n.0.aarch64.raw.xz Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20221231.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: boost-1.78.0-10.fc38 Old package: boost-1.78.0-9.fc37 Summary: The free peer-reviewed portable C++ source libraries RPMs: boost boost-atomic boost-b2 boost-build boost-chrono boost-container boost-context boost-contract boost-coroutine boost-date-time boost-devel boost-doc boost-doctools boost-examples boost-fiber boost-filesystem boost-graph boost-graph-mpich boost-graph-openmpi boost-iostreams boost-json boost-locale boost-log boost-math boost-mpich boost-mpich-devel boost-mpich-python3 boost-mpich-python3-devel boost-nowide boost-numpy3 boost-openmpi boost-openmpi-devel boost-openmpi-python3 boost-openmpi-python3-devel boost-program-options boost-python3 boost-random boost-regex boost-serialization boost-stacktrace boost-static boost-system boost-test boost-thread boost-timer boost-type_erasure boost-wave Size: 315.09 MiB Size change: -7.17 KiB Changelog: * Sat Dec 31 2022 Pete Walter - 1.78.0-10 - Rebuild for ICU 72 Package: ceph-2:17.2.5-3.fc38 Old package: ceph-2:17.2.5-2.fc38 Summary: User space components of the Ceph file system RPMs: ceph ceph-base ceph-common ceph-exporter ceph-fuse ceph-grafana-dashboards ceph-immutable-object-cache ceph-mds ceph-mgr ceph-mgr-cephadm ceph-mgr-dashboard ceph-mgr-diskprediction-local ceph-mgr-k8sevents ceph-mgr-modules-core ceph-mgr-rook ceph-mon ceph-osd ceph-prometheus-alerts ceph-radosgw ceph-resource-agents ceph-selinux ceph-test ceph-volume cephadm cephfs-java cephfs-mirror cephfs-shell cephfs-top libcephfs-devel libcephfs2 libcephfs_jni-devel libcephfs_jni1 libcephsqlite libcephsqlite-devel librados-devel librados2 libradospp-devel libradosstriper-devel libradosstriper1 librbd-devel librbd1 librgw-devel librgw2 python3-ceph-argparse python3-ceph-common python3-cephfs python3-rados python3-rbd python3-rgw rados-objclass-devel rbd-fuse rbd-mirror rbd-nbd Size: 340.95 MiB Size change: 26.88 KiB Changelog: * Sat Dec 31 2022 Pete Walter - 2:17.2.5-3 - Rebuild for ICU 72 Package: community-mysql-8.0.31-2.fc38 Old package: community-mysql-8.0.31-1.fc38 Summary: MySQL client programs and shared libraries RPMs: community-mysql community-mysql-common community-mysql-devel community-mysql-errmsg community-mysql-libs community-mysql-server community-mysql-test Size: 1.07 GiB Size change: -76.23 KiB Changelog: * Sat Dec 31 2022 Pete Walter - 8.0.31-2 - Rebuild for ICU 72 Package: cyrus-imapd-3.4.4-4.fc38 Old package: cyrus-imapd-3.4.4-3.fc38 Summary: A high-performance email, contacts and calendar server RPMs: cyrus-imapd cyrus-imapd-devel cyrus-imapd-doc-extra cyrus-imapd-libs cyrus-imapd-utils cyrus-imapd-virusscan perl-Cyrus Size: 15.91 MiB Size change: -2.98 KiB Changelog: * Sat Dec 31 2022 Pete Walter - 3.4.4-4 - Rebuild for ICU 72 Package: emacs-1:28.2-1.fc38 Old package: emacs-1:28.1-3.fc37 Summary: GNU Emacs text editor RPMs: emacs emacs-common emacs-devel emacs-filesystem emacs-lucid emacs-nox emacs-terminal Size: 524.86 MiB Size change: -3.21 MiB Changelog: * Tue Nov 01 2022 Dan ??erm??k - 1:28.2-1 - New upstream release 28.2, fixes rhbz#2126048 - Add patch to fix CVE-2022-45939, fixes rhbz#2149381 - spawn native-compilation processes with -Q rhbz#2155824 (petersen) Package: gi-docgen-2022.2-3.fc38 Old package: gi-docgen-2022.2-2.fc38 Summary: Documentation tool for GObject-based libraries RPMs: gi-docgen gi-docgen-doc gi-docgen-fonts Size: 562.91 KiB Size change: 626 B Changelog: * Fri Dec 30 2022 Miro Hron??ok 2022.2-3 - Use tomllib (tomli) instated of deprecated python3-toml Package: gnome-text-editor-43.1-3.fc38 Old package: gnome-text-editor-43.1-2.fc38 Summary: A simple text editor for the GNOME desktop RPMs: gnome-text-editor Size: 2.06 MiB Size change: 1.19 KiB Changelog: * Sat Dec 31 2022 Pete Walter - 43.1-3 - Rebuild for ICU 72 Package: golang-github-hashicorp-consul-1.14.3-1.fc38 Old package: golang-github-hashicorp-consul-1.11.10-1.fc38
