Fedora eln compose report: 20250314.n.0 changes
OLD: Fedora-eln-20250313.n.0 NEW: Fedora-eln-20250314.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 30 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 680.20 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -3.84 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: apache-commons-parent-73-5.eln146 Old package: apache-commons-parent-73-4.eln145 Summary: Apache Commons Parent Pom RPMs: apache-commons-parent Size: 34.60 KiB Size change: -42 B Changelog: * Thu Mar 13 2025 Mikolaj Izdebski - 73-5 - Disable XMvn javadoc MOJO Package: apache-parent-33-7.eln146 Old package: apache-parent-33-6.eln145 Summary: Parent POM file for Apache projects RPMs: apache-parent Size: 17.76 KiB Size change: 10 B Changelog: * Thu Mar 13 2025 Mikolaj Izdebski - 33-7 - Disable XMvn javadoc MOJO Package: apache-resource-bundles-1:1.5-21.eln146 Old package: apache-resource-bundles-1:1.5-20.eln146 Summary: Apache Resource Bundles RPMs: apache-resource-bundles Size: 47.54 KiB Size change: 102 B Changelog: * Thu Mar 13 2025 Mikolaj Izdebski - 1:1.5-21 - Disable XMvn javadoc MOJO Package: aqute-bnd-6.3.1-23.eln146 Old package: aqute-bnd-6.3.1-22.eln145 Summary: BND Tool RPMs: aqute-bnd aqute-bndlib Dropped RPMs: aqute-bnd-javadoc Size: 2.47 MiB Size change: -2.44 MiB Changelog: * Thu Mar 13 2025 Mikolaj Izdebski - 6.3.1-23 - Drop javadoc package Package: chkconfig-1.32-1.eln146 Old package: chkconfig-1.31-3.eln145 Summary: A system tool for maintaining the /etc/rc*.d hierarchy RPMs: alternatives chkconfig ntsysv Size: 1000.49 KiB Size change: 5.64 KiB Changelog: * Thu Mar 13 2025 Jan Macku - 1.32-1 - Allow paths with /usr/sbin and /usr/bin as equivalent - mkosi: update conf to match latest mkosi version - Translated using Weblate (Italian) Package: cldr-emoji-annotation-47-1.eln146 Old package: cldr-emoji-annotation-47~beta2-1.eln146 Summary: Emoji annotation files in CLDR RPMs: cldr-emoji-annotation cldr-emoji-annotation-dtd Size: 8.41 MiB Size change: -82.88 KiB Changelog: * Thu Mar 13 2025 Takao Fujiwara - 47-1 - Bump to release-47 Package: curl-8.13.0~rc1-2.eln146 Old package: curl-8.13.0~rc1-1.eln146 Summary: A utility for getting files from remote servers (FTP, HTTP, and others) RPMs: curl libcurl libcurl-devel libcurl-minimal Size: 7.28 MiB Size change: -300 B Changelog: * Thu Mar 13 2025 Jan Macku - 8.13.0~rc1-2 - fix --cert parameter (#2351531) Package: emacs-1:30.1-10.eln146 Old package: emacs-1:30.1-5.eln146 Summary: GNU Emacs text editor RPMs: emacs emacs-common emacs-lucid emacs-nw emacsclient Size: 570.50 MiB Size change: -986.12 KiB Changelog: * Fri Mar 07 2025 Peter Oliver - 1:30.1-6 - Drop recommendation of gcc-c++ for newer Tree-sitter versions * Fri Mar 07 2025 Peter Oliver - 1:30.1-7 - Automatically generate Recommends for Tree-sitter parsers. * Thu Mar 13 2025 Peter Oliver - 1:30.1-8 - Correct provided emacs-transient version. * Thu Mar 13 2025 Peter Oliver - 1:30.1-9 - Restore emacs-terminal subpackage * Thu Mar 13 2025 Peter Oliver - 1:30.1-10 - Tidy up Recommends of emacs-common. Package: felix-parent-9-10.eln146 Old package: felix-parent-9-9.eln145 Summary: Parent POM file for Apache Felix Specs RPMs: felix-parent Size: 15.14 KiB Size change: -52 B Changelog: * Thu Mar 13 2025 Mikolaj Izdebski - 9-10 - Disable XMvn javadoc MOJO Package: fontconfig-2.16.1-1.eln146 Old package: fontconfig-2.16.0-2.eln145 Summary: Font configuration and customization library RPMs: fontconfig fontconfig-devel fontconfig-devel-doc Size: 1.80 MiB Size change: -6.01 KiB Changelog: * Thu Mar 13 2025 Akira TAGOH - 2.16.1-1 - New upstream release. Package: fusesource-pom-1.12-31.eln146 Old package: fusesource-pom-1.12-30.eln145 Summary: Parent POM for FuseSource Maven projects RPMs: fusesource-pom Size: 15.05 KiB Size change: -34 B Changelog: * Thu Mar 13 2025 Mikolaj Izdebski - 1.12-31 - Disable XMvn javadoc MOJO Package: google-api-python-client-2:2.164.0-1.eln146 Old package: google-api-python-client-2:2.163.0-1.eln146 Summary: Google APIs Client Library for Python RPMs: python3-google-api-client Size: 4.62 MiB Size change: 7.25 KiB Changelog: * Thu Mar 13 2025 Packit - 2:2.164.0-1 - Update to 2.164.0 upstream release - Resolves: rhbz#2351788 Package
Fedora 42 compose report: 20250314.n.0 changes
OLD: Fedora-42-20250313.n.0 NEW: Fedora-42-20250314.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = -- ___ 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
Problem with cloning via SSH
Hello, I'm having trouble cloning a forked repository from https://src.fedoraproject.org/ via SSH. I have uploaded my SSH key to pagure, but I still see the error: *You need to upload SSH key to be able to clone over SSH* Could someone help me troubleshoot this? (I am in the packager group) Thanks in advance for any assistance. Best regards, Nikola Davidova -- ___ 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: F43 Change Proposal RPM 6.0 (system-wide)
On 3/13/25 10:56 AM, Dan Čermák wrote: Aoife Moloney via devel-announce writes: * This is the first version of rpm built as C++, so rpm gains a runtime dependency on libstdc++. I am not too happy about yet another dependency. As someone involved in building containers, I constantly have to battle the growth of everything and now with rpm gaining an unavoidable dependency on libsdc++ means that every rpm based container will now grow another 2.5MB in size. That's assuming libstdc++ isn't there already. Software written in c++ isn't exactly rare. I know that there are good reasons for doing this, but please consider the trade-offs too. There's only so much that we as release engineers can do to fight the entropic growth of software. I can tell you it was considered. That ship sailed a year ago already. - Panu - -- ___ 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: Problem with cloning via SSH
Hi Nikola, I don't know how you've tried cloning but this works for me: "fedpkg clone forks//rpms/". Regards Konrad On Thu, Mar 13, 2025 at 1:15 PM Nikola Davidova wrote: > Hello, > I'm having trouble cloning a forked repository from > https://src.fedoraproject.org/ via SSH. I have uploaded my SSH key to > pagure, but I still see the error: > *You need to upload SSH key to be able to clone over SSH* > Could someone help me troubleshoot this? (I am in the packager group) > Thanks in advance for any assistance. > > Best regards, > Nikola Davidova > -- > ___ > 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 > -- ___ 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: Problem with cloning via SSH
Try log out and then log in again into src.fedoraproject.org. User data is only refreshed upon logging in. Inviato da Proton Mail Android Messaggio originale 13/03/25 13:12, Nikola Davidova ha scritto: > Hello, > I'm having trouble cloning a forked repository from > https://src.fedoraproject.org/ via SSH. I have uploaded my SSH key to pagure, > but I still see the error: > You need to upload SSH key to be able to clone over SSH > Could someone help me troubleshoot this? (I am in the packager group) > Thanks in advance for any assistance. > > Best regards, > Nikola Davidova-- ___ 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: Problem with cloning via SSH
Hi Nikola, you mean the issue is when you clone on the command line but with the URL from the website, right? In that case, check that your ~/.ssh/config has no special entry for the git server and that you are cloning as the user that owns the keys. Also you might want to enable verbose SSH like so: GIT_SSH_COMMAND='ssh -v' git clone I hope this helps Konrad On Thu, Mar 13, 2025 at 1:50 PM Nikola Davidova wrote: > It works in command line, the problem is only on the web. > > On Thu, Mar 13, 2025 at 1:45 PM Nikola Davidova > wrote: > >> This is what I meant: >> >> [image: image.png] >> >> On Thu, Mar 13, 2025 at 1:37 PM Konrad Kleine wrote: >> >>> Hi Nikola, >>> >>> I don't know how you've tried cloning but this works for me: "fedpkg >>> clone forks//rpms/". >>> >>> Regards >>> Konrad >>> >>> On Thu, Mar 13, 2025 at 1:15 PM Nikola Davidova >>> wrote: >>> Hello, I'm having trouble cloning a forked repository from https://src.fedoraproject.org/ via SSH. I have uploaded my SSH key to pagure, but I still see the error: *You need to upload SSH key to be able to clone over SSH* Could someone help me troubleshoot this? (I am in the packager group) Thanks in advance for any assistance. Best regards, Nikola Davidova -- ___ 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 >>> -- >>> ___ >>> 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 >>> >> -- > ___ > 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 > -- ___ 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: SONAME BUMP openh264
It's been more than one week. Are we ready to land this side tag? -- ___ 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: GCC defined(__cplusplus) one rawhide
On Tue, 11 Feb 2025 at 22:44, Sérgio Basto wrote: > > On Tue, 2025-02-11 at 21:45 +, Jonathan Wakely wrote: > > On Tue, 28 Jan 2025 at 09:07, Jakub Jelinek wrote: > > > > > > On Mon, Jan 27, 2025 at 07:31:35PM +, Sérgio Basto via devel > > > wrote: > > > > I just want check, if I'm thinking correctly before submitting a > > > > fix in > > > > gtest package > > > > > > > > The problem is on Rawhide I have this warning that make other > > > > packages > > > > fail to build [1] > > > > > > > > gtest source [2] source get __cplusplus value and include > > > > or > > > > #include depending on __cplusplus value . > > > > > > > > On rawhide I got the warning on Fedora 41 don't but __cplusplus > > > > of GCC > > > > compiler is the same (201703) > > > > > > > > My proposal is to change the comparison from 202002L to 201703L > > > > -#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \ > > > > +#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 201703L && \ > > > > > > That is not correct. is actually not guaranteed to be > > > there for > > > C++17, it was only added in https://wg21.link/p0754r2 in 2018 (so > > > e.g. for > > > GCC since GCC 9.1). __has_include is supported by GCC since 2014 > > > (so GCC > > > 5.1). So your change would break building with GCC 5.1 to 8.5. > > > I think if it did e.g. > > > #if (GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \ > > > !defined(__has_include)) || \ > > > (GTEST_INTERNAL_CPLUSPLUS_LANG >= 201703L && \ > > > GTEST_INTERNAL_HAS_INCLUDE()) > > > #include > > > #endif > > > it would be better, C++20 should guarantee there is (but > > > also > > > that __has_include is there, but this stuff attempts to cover also > > > the cases > > > of the incremental development of the standard features). > > > I don't really see the point of including , it is a > > > useless header > > > which doesn't contain anything since its introduction and has been > > > removed > > > without deprecation in C++20. > > > I think the rationale some people give is that it is the smallest > > > C++ header > > > (contains nothing) which still includes some basic header with some > > > macros > > > (in the libstdc++ case it is , in libcxx case it > > > is > > > <__config>). But e.g. in the libstdc++ case, that header doesn't > > > really > > > define any feature test macros, the __cpp_* macros are predefined > > > by the > > > compiler and __cpp_lib_* are defined by the individual headers > > > which provide > > > that functionality or (when it exists) in . > > > > "Traditionally" was included to find out which C++ standard > > library implementation you were using, by including it and then > > checking for _LIBCPP_VERSION or _GLIBCXX_VERSION. > > > > So it's not supposed to be used for checking the standard > > __cpp_lib_xxx macros, but the implementation-specific ones. > > > > N.B. GCC's did not actually define _GLIBCXX_VERSION (or any > > other libstdc++ macros) until GCC 6.1, because it really did > > _nothing_ > > before that. It didn't even include . > > > > I second Jakub's suggestion to just include if it's > > available. It's not required by the C++ standard until C++20, but > > given a sufficiently new compiler the header is still > > present and can be included for older versions of C++. > > > > Hi, but if we are build in an "old" GCC , can we replace by > ? I also like the Jakub's suggestion [1] . Should/Can we > apply this suggestion also to abseil-cpp-20240722.1 ? > > [1] > #if GTEST_INTERNAL_HAS_INCLUDE() || \ > (GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && > !defined(__has_include)) > #include // C++20 and later > #else > #include // Pre-C++20 > #endif I missed this follow-up question, sorry. Including would have equivalent effects to , except for also declaring all the contents of (which isn't very much, so mostly harmless). Before GCC 6.1 did not define the _GLIBCXX_xxx macros, but neither did so there's no difference between then in that respect. -- ___ 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: Rawhide: openh264: Public key is not installed.
On Wed, Mar 12, 2025 at 11:30:07AM +0100, Mikolaj Izdebski wrote: > On Wed, Mar 12, 2025 at 9:49 AM Marián Konček wrote: > > > > When running a container with current Fedora Rawhide and installing > > `maven`, which transitiely causes the installation of `openh264`, I am > > getting an error: > > > > Running transaction > > Transaction failed: Signature verification failed. > > Public key "file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide-x86_64" > > is already present, not importing. > > OpenPGP check for package "openh264-2.4.1-2.fc42.x86_64" > > (/var/cache/libdnf5/fedora-cisco-openh264-4896e02bbb10d47b/packages/openh264-2.4.1-2.fc42.x86_64.rpm) > > from repo "fedora-cisco-openh264" has failed: Public key is not installed. > > See related releng and infra issues: > > https://pagure.io/releng/issue/12617 > https://pagure.io/fedora-infrastructure/issue/12112 Just FYI, this should be fixed (for rawhide at least) now. kevin -- ___ 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: GCC defined(__cplusplus) one rawhide
On Thu, 2025-03-13 at 14:53 +, Jonathan Wakely wrote: > On Tue, 11 Feb 2025 at 22:44, Sérgio Basto wrote: > > > > On Tue, 2025-02-11 at 21:45 +, Jonathan Wakely wrote: > > > On Tue, 28 Jan 2025 at 09:07, Jakub Jelinek > > > wrote: > > > > > > > > On Mon, Jan 27, 2025 at 07:31:35PM +, Sérgio Basto via > > > > devel > > > > wrote: > > > > > I just want check, if I'm thinking correctly before > > > > > submitting a > > > > > fix in > > > > > gtest package > > > > > > > > > > The problem is on Rawhide I have this warning that make other > > > > > packages > > > > > fail to build [1] > > > > > > > > > > gtest source [2] source get __cplusplus value and include > > > > > or > > > > > #include depending on __cplusplus value . > > > > > > > > > > On rawhide I got the warning on Fedora 41 don't but > > > > > __cplusplus > > > > > of GCC > > > > > compiler is the same (201703) > > > > > > > > > > My proposal is to change the comparison from 202002L to > > > > > 201703L > > > > > -#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \ > > > > > +#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 201703L && \ > > > > > > > > That is not correct. is actually not guaranteed to > > > > be > > > > there for > > > > C++17, it was only added in https://wg21.link/p0754r2 in 2018 > > > > (so > > > > e.g. for > > > > GCC since GCC 9.1). __has_include is supported by GCC since > > > > 2014 > > > > (so GCC > > > > 5.1). So your change would break building with GCC 5.1 to 8.5. > > > > I think if it did e.g. > > > > #if (GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \ > > > > !defined(__has_include)) || \ > > > > (GTEST_INTERNAL_CPLUSPLUS_LANG >= 201703L && \ > > > > GTEST_INTERNAL_HAS_INCLUDE()) > > > > #include > > > > #endif > > > > it would be better, C++20 should guarantee there is > > > > (but > > > > also > > > > that __has_include is there, but this stuff attempts to cover > > > > also > > > > the cases > > > > of the incremental development of the standard features). > > > > I don't really see the point of including , it is a > > > > useless header > > > > which doesn't contain anything since its introduction and has > > > > been > > > > removed > > > > without deprecation in C++20. > > > > I think the rationale some people give is that it is the > > > > smallest > > > > C++ header > > > > (contains nothing) which still includes some basic header with > > > > some > > > > macros > > > > (in the libstdc++ case it is , in libcxx case > > > > it > > > > is > > > > <__config>). But e.g. in the libstdc++ case, that header > > > > doesn't > > > > really > > > > define any feature test macros, the __cpp_* macros are > > > > predefined > > > > by the > > > > compiler and __cpp_lib_* are defined by the individual headers > > > > which provide > > > > that functionality or (when it exists) in . > > > > > > "Traditionally" was included to find out which C++ > > > standard > > > library implementation you were using, by including it and then > > > checking for _LIBCPP_VERSION or _GLIBCXX_VERSION. > > > > > > So it's not supposed to be used for checking the standard > > > __cpp_lib_xxx macros, but the implementation-specific ones. > > > > > > N.B. GCC's did not actually define _GLIBCXX_VERSION (or > > > any > > > other libstdc++ macros) until GCC 6.1, because it really did > > > _nothing_ > > > before that. It didn't even include . > > > > > > I second Jakub's suggestion to just include if it's > > > available. It's not required by the C++ standard until C++20, but > > > given a sufficiently new compiler the header is still > > > present and can be included for older versions of C++. > > > > > > > Hi, but if we are build in an "old" GCC , can we replace > > by > > ? I also like the Jakub's suggestion [1] . Should/Can we > > apply this suggestion also to abseil-cpp-20240722.1 ? > > > > [1] > > #if GTEST_INTERNAL_HAS_INCLUDE() || \ > > (GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && > > !defined(__has_include)) > > #include // C++20 and later > > #else > > #include // Pre-C++20 > > #endif > > > I missed this follow-up question, sorry. Including would > have > equivalent effects to , except for also declaring all the > contents of (which isn't very much, so mostly harmless). > > Before GCC 6.1 did not define the _GLIBCXX_xxx macros, but > neither did so there's no difference between then in that > respect. > OK, I will check if maintainer of the package in question want apply this solution IIRC, I disabled warnings being treated as errors ... Thank you , -- 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.fedoraproj
Re: %pyproject_buildrequires -t/-e and %tox without a suitable tox configuration will error
On 13. 03. 25 19:39, Tomasz Torcz wrote: On Thu, Mar 13, 2025 at 06:55:57PM +0100, Miro Hrončok wrote: On 13. 03. 25 18:50, Milan Crha wrote: On Wed, 2025-03-12 at 00:11 +0100, Miro Hrončok via devel-announce wrote: This change will land to rawhide first and later to all stable releases as well. However, if people fight me on this, I am willing to reconsider. All affected packagers maintainers were bcced both a month ago and now. FTR, I am one of the maintainers bcced, and I have no idea what any of the stuff in the original message mean. I'd need to find some time to reasearch what the tox is, and how it relates to my package. Having said that, I am not opposing the change. I just do not understand it at all. It is OK to do it in Rawhide, but let's leave F40-42 alone. tl;dr if you don't know what tox is and your package is affected: don't use %pyproject_buildrequires -t/-e or %tox. If you remove the -t/-e flag from %pyproject_buildrequires (and remove the %tox call if it exists), it will do the same thing as before (nothing) except it will not give a false sense of tests. Here you go: https://src.fedoraproject.org/rpms/python-simple-pid/pull-request/1 I can certainly make it so that f40-f42 is unaffected by the change, but I strongly believe that it is not necessary. (But I hear you and will yield if yours opinion is the majority.) The most "unsafe" thing is running %tox withotu a tox config -- as a compromise, I can only make that part hard error on f40-f42. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Unresponsive packager: nilskoenig
On Thu, Mar 13, 2025 at 09:48:04AM +0100, Pierre-Yves Chibon wrote: > On Fri, Mar 07, 2025 at 04:46:32PM +, Richard W.M. Jones wrote: > > On Fri, Mar 07, 2025 at 09:57:32AM +0100, Pierre-Yves Chibon wrote: > > > Good Morning Everyone, > > > > > > We have been emailing daily the following user to notify that the email > > > they > > > have set in FAS does not correspond to a valid bugzilla account. > > > This is a requirement for Fedora packagers. > > > > > > Does someone know how to contact them? > > > > > > nilskoenig - emailed since February 14th > > > nilskoenig is maintainer of rpms/vhostmd > > > > CC-ing him... > > > > I was talking to Nils about vhostmd packaging only a few weeks ago. > > Hey Richard, > > Did you receive any feedback? > Things don't seem to have changed on our side. No, I'm afraid I didn't receive any reply. Nils, if you're here, please see the above & reply to this email. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- ___ 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 42 compose report: 20250313.n.0 changes
OLD: Fedora-42-20250312.n.0 NEW: Fedora-42-20250313.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = -- ___ 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: Problem with cloning via SSH
It works in command line, the problem is only on the web. On Thu, Mar 13, 2025 at 1:45 PM Nikola Davidova wrote: > This is what I meant: > > [image: image.png] > > On Thu, Mar 13, 2025 at 1:37 PM Konrad Kleine wrote: > >> Hi Nikola, >> >> I don't know how you've tried cloning but this works for me: "fedpkg >> clone forks//rpms/". >> >> Regards >> Konrad >> >> On Thu, Mar 13, 2025 at 1:15 PM Nikola Davidova >> wrote: >> >>> Hello, >>> I'm having trouble cloning a forked repository from >>> https://src.fedoraproject.org/ via SSH. I have uploaded my SSH key to >>> pagure, but I still see the error: >>> *You need to upload SSH key to be able to clone over SSH* >>> Could someone help me troubleshoot this? (I am in the packager group) >>> Thanks in advance for any assistance. >>> >>> Best regards, >>> Nikola Davidova >>> -- >>> ___ >>> 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 >>> >> -- >> ___ >> 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 >> > -- ___ 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: Problem with cloning via SSH
Please open a ticket at https://pagure.io/fedora-infrastructure/new_issue so it can be debugged if there is a problem with the backend of src (a pagure instance) or with the IDM system. On Thu, 13 Mar 2025 at 08:15, Nikola Davidova wrote: > Hello, > I'm having trouble cloning a forked repository from > https://src.fedoraproject.org/ via SSH. I have uploaded my SSH key to > pagure, but I still see the error: > *You need to upload SSH key to be able to clone over SSH* > Could someone help me troubleshoot this? (I am in the packager group) > Thanks in advance for any assistance. > > Best regards, > Nikola Davidova > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Problem with cloning via SSH
This is what I meant: [image: image.png] On Thu, Mar 13, 2025 at 1:37 PM Konrad Kleine wrote: > Hi Nikola, > > I don't know how you've tried cloning but this works for me: "fedpkg clone > forks//rpms/". > > Regards > Konrad > > On Thu, Mar 13, 2025 at 1:15 PM Nikola Davidova > wrote: > >> Hello, >> I'm having trouble cloning a forked repository from >> https://src.fedoraproject.org/ via SSH. I have uploaded my SSH key to >> pagure, but I still see the error: >> *You need to upload SSH key to be able to clone over SSH* >> Could someone help me troubleshoot this? (I am in the packager group) >> Thanks in advance for any assistance. >> >> Best regards, >> Nikola Davidova >> -- >> ___ >> 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 >> > -- > ___ > 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 > -- ___ 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 Linux 42 Beta is a GO
The Fedora Linux 42 Beta RC1.4 compose is GO and will be shipped live on Tuesday, March 18 2025. Final Freeze will start on Tuesday, April 1 (no joke!) for Fedora Linux 42 Final. For more information on today's release go/no-go meeting please check the meeting minutes[2] or log[3]. [1] https://fedorapeople.org/groups/schedule/f-42/f-42-key-tasks.html [2] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-03-13/f42-beta-go-no-go-meeting.2025-03-13-17.02.txt [3] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-03-13/f42-beta-go-no-go-meeting.2025-03-13-17.02.log.html -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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: 20250313.n.0 changes
OLD: Fedora-Rawhide-20250312.n.0 NEW: Fedora-Rawhide-20250313.n.0 = SUMMARY = Added images:11 Dropped images: 1 Added packages: 6 Dropped packages:1 Upgraded packages: 170 Downgraded packages: 0 Size of added packages: 10.57 GiB Size of dropped packages:352.95 KiB Size of upgraded packages: 4.44 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -31.16 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Silverblue bootable-container x86_64 Path: Silverblue/x86_64/images/Fedora-Silverblue-x86_64-Rawhide.20250313.n.0.ociarchive Image: Kinoite bootable-container aarch64 Path: Kinoite/aarch64/images/Fedora-Kinoite-aarch64-Rawhide.20250313.n.0.ociarchive Image: Sericea bootable-container aarch64 Path: Sericea/aarch64/images/Fedora-Sericea-aarch64-Rawhide.20250313.n.0.ociarchive Image: COSMIC-Atomic bootable-container x86_64 Path: COSMIC-Atomic/x86_64/images/Fedora-COSMIC-Atomic-x86_64-Rawhide.20250313.n.0.ociarchive Image: Kinoite bootable-container x86_64 Path: Kinoite/x86_64/images/Fedora-Kinoite-x86_64-Rawhide.20250313.n.0.ociarchive Image: Onyx bootable-container x86_64 Path: Onyx/x86_64/images/Fedora-Onyx-x86_64-Rawhide.20250313.n.0.ociarchive Image: Silverblue bootable-container aarch64 Path: Silverblue/aarch64/images/Fedora-Silverblue-aarch64-Rawhide.20250313.n.0.ociarchive Image: COSMIC-Atomic dvd-ostree x86_64 Path: COSMIC-Atomic/x86_64/iso/Fedora-COSMIC-Atomic-ostree-x86_64-Rawhide-20250313.n.0.iso Image: COSMIC-Atomic bootable-container aarch64 Path: COSMIC-Atomic/aarch64/images/Fedora-COSMIC-Atomic-aarch64-Rawhide.20250313.n.0.ociarchive Image: Sericea bootable-container x86_64 Path: Sericea/x86_64/images/Fedora-Sericea-x86_64-Rawhide.20250313.n.0.ociarchive Image: COSMIC-Atomic dvd-ostree aarch64 Path: COSMIC-Atomic/aarch64/iso/Fedora-COSMIC-Atomic-ostree-aarch64-Rawhide-20250313.n.0.iso = DROPPED IMAGES = Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20250312.n.0.iso = ADDED PACKAGES = Package: java-25-openjdk-portable-1:25.0.0.0.13-0.1.ea.fc43 Summary: OpenJDK 25 Runtime Environment portable edition RPMs:java-25-openjdk-portable java-25-openjdk-portable-devel java-25-openjdk-portable-devel-fastdebug java-25-openjdk-portable-devel-slowdebug java-25-openjdk-portable-docs java-25-openjdk-portable-fastdebug java-25-openjdk-portable-misc java-25-openjdk-portable-slowdebug java-25-openjdk-portable-sources java-25-openjdk-portable-static-libs java-25-openjdk-portable-static-libs-fastdebug java-25-openjdk-portable-static-libs-slowdebug java-25-openjdk-portable-unstripped Size:10.57 GiB Package: python-pyinfra-3.2-2.fc43 Summary: Provision, manage and deploy infrastructure RPMs:python3-pyinfra Size:578.46 KiB Package: rust-cargo-platform0.1-0.1.9-1.fc43 Summary: Cargo's representation of a target platform RPMs:rust-cargo-platform0.1+default-devel rust-cargo-platform0.1-devel Size:26.79 KiB Package: rust-derp-0.0.15-1.fc43 Summary: DER Parser (and Writer) RPMs:rust-derp+default-devel rust-derp-devel Size:22.83 KiB Package: rust-pipeline-0.5.0-1.fc43 Summary: Macro collection to pipe |> your functions calls, like in F# or Elixir RPMs:rust-pipeline+default-devel rust-pipeline-devel Size:18.10 KiB Package: rust-tryfn-0.2.3-1.fc43 Summary: File-driven snapshot testing for a function RPMs:rust-tryfn+color-auto-devel rust-tryfn+color-devel rust-tryfn+default-devel rust-tryfn+diff-devel rust-tryfn-devel Size:45.03 KiB = DROPPED PACKAGES = Package: python-nose-1.3.7-62.fc42 Summary: Deprecated test runner for Python RPMs:python3-nose Size:352.95 KiB = UPGRADED PACKAGES = Package: anaconda-43.6-1.fc43 Old package: anaconda-43.5-1.fc43 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 17.40 MiB Size change: -3.94 KiB Changelog: * Tue Mar 11 2025 Packit - 43.6-1 - network: add dnsconfd to installer environment (rvykydal) - network: add dnsconfd to selected packages if used in installer (rvykydal) - Disable systemd-resolved when enabling dnsconfd (rvykydal) - Revert "pyanaconda: storage: workaround for Virtio Block Device being displayed as 0x1af4" (k.koukiou) - network: start dnsconfd in initramfs (rvykydal) - Disable support of kernel 'nokill' option in anaconda (ppolawsk) - Create autogenerated dbus docs (adamkankovsky) Package: argbash-2.10.0-18.fc43 Old package: argbash-2.10.0-17.fc42 Summary: Bash argument parsing code generator RPMs: argbash Size: 61.75 KiB Size change: -159 B Changelog: * Wed Mar 12 2025 Stephen Gallagher - 2.10.0-18 - Update documentation Package: bluedevil-6.3.3-1.
Re: SONAME BUMP openh264
Fabio is going to handle builds. Thank you, 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: SONAME BUMP openh264
It seems nothing except GStreamer has been rebuilt. -- ___ 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: %pyproject_buildrequires -t/-e and %tox without a suitable tox configuration will error
On Wed, 2025-03-12 at 00:11 +0100, Miro Hrončok via devel-announce wrote: > This change will land to rawhide first and later to all stable > releases as well. Hi, are you really going to intentionally break all the stable releases? I thought there is a strict policy, and a big no-no, to _not_ do any such thing. If you want to implement a breaking change, then do it strictly in the rawhide only. Possibly with a fedora change paperwork, maybe. Not that I mind of those packages, I do not use any of them, at least not directly, but seeing broken f40 or f41 this late does not sound right. The f42 might be out of question as well, from my point of view. Bye, Milan -- ___ 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: %pyproject_buildrequires -t/-e and %tox without a suitable tox configuration will error
On 13. 03. 25 18:50, Milan Crha wrote: On Wed, 2025-03-12 at 00:11 +0100, Miro Hrončok via devel-announce wrote: This change will land to rawhide first and later to all stable releases as well. Hi, are you really going to intentionally break all the stable releases? I thought there is a strict policy, and a big no-no, to _not_ do any such thing. If you want to implement a breaking change, then do it strictly in the rawhide only. Possibly with a fedora change paperwork, maybe. Not that I mind of those packages, I do not use any of them, at least not directly, but seeing broken f40 or f41 this late does not sound right. The f42 might be out of question as well, from my point of view. Yes, that was my plan. The affected packages are already broken, but they build successfully (and shouldn't). This was a long-standing bug, never an intended behavior. However, if people fight me on this, I am willing to reconsider. All affected packagers maintainers were bcced both a month ago and now. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: %pyproject_buildrequires -t/-e and %tox without a suitable tox configuration will error
On Thu, Mar 13, 2025 at 06:55:57PM +0100, Miro Hrončok wrote: > On 13. 03. 25 18:50, Milan Crha wrote: > > On Wed, 2025-03-12 at 00:11 +0100, Miro Hrončok via devel-announce > > wrote: > > > This change will land to rawhide first and later to all stable > > > releases as well. > > However, if people fight me on this, I am willing to reconsider. All > affected packagers maintainers were bcced both a month ago and now. FTR, I am one of the maintainers bcced, and I have no idea what any of the stuff in the original message mean. I'd need to find some time to reasearch what the tox is, and how it relates to my package. Having said that, I am not opposing the change. I just do not understand it at all. It is OK to do it in Rawhide, but let's leave F40-42 alone. -- Tomasz Torcz “God, root, what’s the difference?” to...@pipebreaker.pl “God is more forgiving.” -- ___ 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: F42 Change Proposal: RPM Support For Systemd Sysusers.d (system-wide)
On 3/12/25 6:37 PM, Miroslav Suchý wrote: Dne 12. 03. 25 v 4:57 odp. Fabio Valentini napsal(a): error: invalid sysuser type: u! 4< (%error) error: lua script failed: [string "add_sysuser"]:22: error expanding macro 3<(%lua) 2< (%add_sysuser) error: lua script failed: [string "__sysusers_provides"]:12: error expanding macro 1<(%lua) group(copr-dist-git) = ZyBjb3ByLWRpc3QtZ2l0IC0A 0< (%__sysusers_provides) Is this a bug, feature or something else? This looks like a missing feature in the RPM-internal sysusers implementation. As far as I know, it doesn't support all the features that systemd-sysusers supports. Zbyzsek already answered me this elsewhere. It is included in rpm-4.20.1. When I upgraded my F42 to recent rpm, the error disappeared. This feature cannot be used on F41 and olders. Yet. 4.20.1 is on it's way to F41 too: https://bodhi.fedoraproject.org/updates/FEDORA-2025-9e82367954 - Panu - -- ___ 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: F43 Change Proposal RPM 6.0 (system-wide)
Aoife Moloney via devel-announce writes: > * This is the first version of rpm built as C++, so rpm gains a > runtime dependency on libstdc++. I am not too happy about yet another dependency. As someone involved in building containers, I constantly have to battle the growth of everything and now with rpm gaining an unavoidable dependency on libsdc++ means that every rpm based container will now grow another 2.5MB in size. I know that there are good reasons for doing this, but please consider the trade-offs too. There's only so much that we as release engineers can do to fight the entropic growth of software. Cheers, Dan -- ___ 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: F43 Change Proposal RPM 6.0 (system-wide)
Panu Matilainen writes: > On 3/13/25 10:56 AM, Dan Čermák wrote: >> Aoife Moloney via devel-announce >> writes: >> >>> * This is the first version of rpm built as C++, so rpm gains a >>> runtime dependency on libstdc++. >> >> I am not too happy about yet another dependency. As someone involved in >> building containers, I constantly have to battle the growth of >> everything and now with rpm gaining an unavoidable dependency on >> libsdc++ means that every rpm based container will now grow another >> 2.5MB in size. > > That's assuming libstdc++ isn't there already. Software written in c++ > isn't exactly rare. You're right, libstdc++ is there anyway thanks to bash. Sorry for the noise. Cheers, Dan -- ___ 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: Unresponsive packager: nilskoenig
On Fri, Mar 07, 2025 at 04:46:32PM +, Richard W.M. Jones wrote: > On Fri, Mar 07, 2025 at 09:57:32AM +0100, Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > > > We have been emailing daily the following user to notify that the email they > > have set in FAS does not correspond to a valid bugzilla account. > > This is a requirement for Fedora packagers. > > > > Does someone know how to contact them? > > > > nilskoenig - emailed since February 14th > > nilskoenig is maintainer of rpms/vhostmd > > CC-ing him... > > I was talking to Nils about vhostmd packaging only a few weeks ago. Hey Richard, Did you receive any feedback? Things don't seem to have changed on our side. Thanks, Pierre -- ___ 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: F43 Change Proposal RPM 6.0 (system-wide)
On 3/12/25 12:45 PM, Miroslav Suchý wrote: Dne 11. 03. 25 v 10:36 dop. Panu Matilainen napsal(a): It's exactly for reasons like this that rpm will not even try to automatically setup the signing - it has no way of knowing what the right thing is. Mock has it's own signing plugin, rpm wont interfere with it: https://rpm-software-management.github.io/mock/Plugin-Sign Hmm, but this plugin is not enabled by default. And it is not even enabled in Copr where packages are signed after Mock finishes and passed to obs-sign. Can you provide a Copr project with RPM 6.0 build that I can try (I did not find it in the Change document)? We don't provide any "official" builds for any version, but https://copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/ is ~daily-weekly builds of rpm git master branch, currently in pre-6.0. I run this on my laptop at all times, so it's not expected to eat anybodys kittens for breakfast but of course, approach with caution. mock and copr seem to be working fine, but it's possible I'm not testing some specific thing that does actually break with this. Just realized there are a couple of clarifications to be made as to what exactly is enforced: the enforced signature checking only concerns installations (including update/reinstall) through transactions. 'rpm -i foo.src.rpm' is not affected, nor is querying packages. - Panu - -- ___ 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: F43 Change Proposal RPM 6.0 (system-wide)
Dne 13. 03. 25 v 8:31 dop. Panu Matilainen napsal(a): On 3/12/25 12:45 PM, Miroslav Suchý wrote: Dne 11. 03. 25 v 10:36 dop. Panu Matilainen napsal(a): It's exactly for reasons like this that rpm will not even try to automatically setup the signing - it has no way of knowing what the right thing is. Mock has it's own signing plugin, rpm wont interfere with it: https://rpm-software-management.github.io/mock/Plugin-Sign Hmm, but this plugin is not enabled by default. And it is not even enabled in Copr where packages are signed after Mock finishes and passed to obs-sign. Can you provide a Copr project with RPM 6.0 build that I can try (I did not find it in the Change document)? We don't provide any "official" builds for any version, but https://copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/ is ~daily-weekly builds of rpm git master branch, currently in pre-6.0. I run this on my laptop at all times, so it's not expected to eat anybodys kittens for breakfast but of course, approach with caution. Great. Thank you. I think others can appreciate this too and you can add it to Change to How To Test section. mock and copr seem to be working fine, but it's possible I'm not testing some specific thing that does actually break with this. I created https://github.com/rpm-software-management/mock/issues/1560 to gather any feedback with mock and rpm 6.0 testing. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ 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: F43 Change Proposal RPM 6.0 (system-wide)
On Thu, Mar 13, 2025 at 10:42 AM Dan Čermák wrote: > > Panu Matilainen writes: > > > On 3/13/25 10:56 AM, Dan Čermák wrote: > >> Aoife Moloney via devel-announce > >> writes: > >> > >>> * This is the first version of rpm built as C++, so rpm gains a > >>> runtime dependency on libstdc++. > >> > >> I am not too happy about yet another dependency. As someone involved in > >> building containers, I constantly have to battle the growth of > >> everything and now with rpm gaining an unavoidable dependency on > >> libsdc++ means that every rpm based container will now grow another > >> 2.5MB in size. > > > > That's assuming libstdc++ isn't there already. Software written in c++ > > isn't exactly rare. > > You're right, libstdc++ is there anyway thanks to bash. Sorry for the > noise. I'm sorry, bash depends on what now? I hope you meant something else. -- ___ 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: F43 Change Proposal RPM 6.0 (system-wide)
Alexander Sosedkin writes: > On Thu, Mar 13, 2025 at 10:42 AM Dan Čermák > wrote: >> >> Panu Matilainen writes: >> >> > On 3/13/25 10:56 AM, Dan Čermák wrote: >> >> Aoife Moloney via devel-announce >> >> writes: >> >> >> >>> * This is the first version of rpm built as C++, so rpm gains a >> >>> runtime dependency on libstdc++. >> >> >> >> I am not too happy about yet another dependency. As someone involved in >> >> building containers, I constantly have to battle the growth of >> >> everything and now with rpm gaining an unavoidable dependency on >> >> libsdc++ means that every rpm based container will now grow another >> >> 2.5MB in size. >> > >> > That's assuming libstdc++ isn't there already. Software written in c++ >> > isn't exactly rare. >> >> You're right, libstdc++ is there anyway thanks to bash. Sorry for the >> noise. > > I'm sorry, bash depends on what now? I hope you meant something else. I have looked at this on SLES (my primary $dayjob platform), where bash depends on libreadline, libreadline depends on libtinfo and libtinfo on ncurses, which in turn depends on libstdc++. This appears to be a SUSE only "issue" though. At least this specific dependency chain is not present on Fedora (ncurses does not drag in libstdc++). -- ___ 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
Removal of Javadoc Packages in Fedora
According to Fedora packaging guidelines, building Java documentation (-javadoc) packages is now optional. It was previously mandatory, then recommended, and is now left entirely to the maintainer's discretion. As the primary maintainer of many Java packages, I have decided to obsolete and remove Javadoc packages from all the packages I maintain. These changes will take effect in Fedora Rawhide (43) and later. I encourage others to consider doing the same. Why Remove Javadoc Packages? 1. Reduced maintenance burden Maintaining Javadoc packages isn't as simple as packaging documentation once and forgetting about it. Several issues make it time-consuming for maintainers. Javadoc generation often breaks with new JDK versions. Each major JDK update can introduce changes to the Javadoc tool (javadoc), leading to build failures. Maintainers must frequently patch Javadoc builds to maintain compatibility. By removing Javadoc packages, maintainers can focus on keeping core Java packages functional instead of spending time fixing documentation builds. 2. Reduced maintenance for javadoc-related tooling Many Javadoc builds depend on external tools (e.g., Maven plugins) that also require maintenance and updates. Updating a single Java library may also require updating its Javadoc dependencies. Removing Javadoc packages allows maintainers to retire unnecessary packages that exist only for building Javadocs. 3. Lower storage and bandwidth usage Javadoc packages take up considerable space because they contain thousands of interlinked HTML files, CSS, JavaScript, and image assets for styling, search indexes for fast lookups, and sometimes even embedded copies of external dependencies. For Fedora storing and distributing these extra files across mirrors is unnecessary when the same documentation is readily available online. Moreover, removal of more than a hundred of javadoc packages, each containing hundreds or thousands files, will result in non-negligible size reduction of repository metadata, particularly the file lists metadata. 4. Improved build reproducibility Fedora aims for reproducible builds, where compiling the same package on different systems should yield identical binaries. However, Javadoc generation makes this difficult due to various issues such timestamps embedded in generated files, non-deterministic ordering of elements, dependency on system fonts/external assets etc. Removing Javadoc packages enhances consistency and reproducibility across builds. 5. Availability of online alternatives Most Java libraries already publish documentation online. There exists javadoc.io service, which hosts Javadocs for most open-source projects. Developers typically already retrieve dependencies and documentation from repositories like Maven Central. Maintaining a separate Fedora-hosted copy is redundant when developers can access the latest online versions. 6. Eliminates privacy concerns Some Javadoc pages automatically load third-party resources, such as Google Fonts, Bootstrap CSS, JavaScript frameworks (e.g., jQuery). This raises privacy concerns because it can expose user behavior to external servers. In order to protect Fedora users from tracking them, Fedora maintainers take effort to patch out these resources. Removing Javadoc packages avoids these issues altogether. Conclusion While javadoc packages were useful in the past, the shift to online documentation and modern development tools has made them obsolete. Removing them from Fedora offers numerous benefits. For those who still need offline documentation, local javadoc generation remains an option. Given the high maintenance cost and diminishing benefits, I think it's time to retire Fedora's Javadoc packages. -- Mikolaj Izdebski -- ___ 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: F43 Change Proposal RPM 6.0 (system-wide)
V Thu, Mar 13, 2025 at 11:26:31AM +0200, Panu Matilainen napsal(a): > On 3/13/25 10:56 AM, Dan Čermák wrote: > > Aoife Moloney via devel-announce > > writes: > > > > > * This is the first version of rpm built as C++, so rpm gains a > > > runtime dependency on libstdc++. > > > > I am not too happy about yet another dependency. As someone involved in > > building containers, I constantly have to battle the growth of > > everything and now with rpm gaining an unavoidable dependency on > > libsdc++ means that every rpm based container will now grow another > > 2.5MB in size. > > That's assuming libstdc++ isn't there already. Software written in c++ isn't > exactly rare. > E.g. dnf5. -- Petr 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: F43 Change Proposal RPM 6.0 (system-wide)
On Thu, Mar 13, 2025 at 6:19 AM Dan Čermák wrote: > > Alexander Sosedkin writes: > > > On Thu, Mar 13, 2025 at 10:42 AM Dan Čermák > > wrote: > >> > >> Panu Matilainen writes: > >> > >> > On 3/13/25 10:56 AM, Dan Čermák wrote: > >> >> Aoife Moloney via devel-announce > >> >> writes: > >> >> > >> >>> * This is the first version of rpm built as C++, so rpm gains a > >> >>> runtime dependency on libstdc++. > >> >> > >> >> I am not too happy about yet another dependency. As someone involved in > >> >> building containers, I constantly have to battle the growth of > >> >> everything and now with rpm gaining an unavoidable dependency on > >> >> libsdc++ means that every rpm based container will now grow another > >> >> 2.5MB in size. > >> > > >> > That's assuming libstdc++ isn't there already. Software written in c++ > >> > isn't exactly rare. > >> > >> You're right, libstdc++ is there anyway thanks to bash. Sorry for the > >> noise. > > > > I'm sorry, bash depends on what now? I hope you meant something else. > > I have looked at this on SLES (my primary $dayjob platform), where bash > depends on libreadline, libreadline depends on libtinfo and libtinfo on > ncurses, which in turn depends on libstdc++. > > This appears to be a SUSE only "issue" though. At least this specific > dependency chain is not present on Fedora (ncurses does not drag in > libstdc++). Since Fedora 41, libstdc++ has already been in the base buildroot and containers with the switch to DNF v5. We don't pull in Boost like Zypper does (thankfully). -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 Change Proposal RPM 6.0 (system-wide)
On 3/13/25 10:05 AM, Miroslav Suchý wrote: Dne 13. 03. 25 v 8:31 dop. Panu Matilainen napsal(a): On 3/12/25 12:45 PM, Miroslav Suchý wrote: Dne 11. 03. 25 v 10:36 dop. Panu Matilainen napsal(a): It's exactly for reasons like this that rpm will not even try to automatically setup the signing - it has no way of knowing what the right thing is. Mock has it's own signing plugin, rpm wont interfere with it: https://rpm-software-management.github.io/mock/Plugin-Sign Hmm, but this plugin is not enabled by default. And it is not even enabled in Copr where packages are signed after Mock finishes and passed to obs-sign. Can you provide a Copr project with RPM 6.0 build that I can try (I did not find it in the Change document)? We don't provide any "official" builds for any version, but https:// copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/ is ~daily- weekly builds of rpm git master branch, currently in pre-6.0. I run this on my laptop at all times, so it's not expected to eat anybodys kittens for breakfast but of course, approach with caution. Great. Thank you. I think others can appreciate this too and you can add it to Change to How To Test section. I'd rather not advertise it too much yet because this is NOT rpm 6.0, it's not even 6.0 alpha. So while it's useful for getting a rough idea, it's not ready yet. Eg an easy process to setup the auto-signing just isn't there yet. mock and copr seem to be working fine, but it's possible I'm not testing some specific thing that does actually break with this. I created https://github.com/rpm-software-management/mock/issues/1560 to gather any feedback with mock and rpm 6.0 testing. Ack, subscribed myself there as well. - Panu - -- ___ 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
