[Bug 1956364] perl-DBIx-RunSQL-0.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1956364 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-DBIx-RunSQL-0.22-1.fc3 ||4 Resolution|--- |ERRATA Last Closed||2021-07-01 01:14:09 --- Comment #5 from Fedora Update System --- FEDORA-2021-6b628d737e has been pushed to the Fedora 34 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. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1974093] perl-Module-CoreList-5.20210620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1974093 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021 |0620-1.fc35 |0620-1.fc35 ||perl-Module-CoreList-5.2021 ||0620-1.fc34 Resolution|--- |ERRATA Last Closed||2021-07-01 01:13:52 --- Comment #4 from Fedora Update System --- FEDORA-2021-5419793232 has been pushed to the Fedora 34 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. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1974101] perl-CPAN-Perl-Releases-5.20210620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1974101 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0210620-1.fc35 |0210620-1.fc35 ||perl-CPAN-Perl-Releases-5.2 ||0210620-1.fc34 Resolution|--- |ERRATA Last Closed||2021-07-01 01:13:54 --- Comment #4 from Fedora Update System --- FEDORA-2021-0b372c6a1a has been pushed to the Fedora 34 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. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1973900] perl-Log-Dispatchouli-2.023 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1973900 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Log-Dispatchouli-2.023 |perl-Log-Dispatchouli-2.023 |-1.fc35 |-1.fc35 ||perl-Log-Dispatchouli-2.023 ||-1.fc34 Resolution|--- |ERRATA Last Closed||2021-07-01 01:13:25 --- Comment #3 from Fedora Update System --- FEDORA-2021-f5135e5a2b has been pushed to the Fedora 34 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. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Schedule for Thursday's FPC Meeting (2021-07-01 16:00 UTC)
NOTE: This is the third meeting we'll have on IRC.LIBERA.CHAT NOTE2: The version draft is back on the agenda. Following is the list of topics that will be discussed in the FPC meeting Thursday at 2021-07-01 16:00 UTC in #fedora-meeting-1 on irc.libera.chat. Local time information (via. uitime): = Day: Thursday == 2021-07-01 09:00 PDT US/Pacific 2021-07-01 12:00 EDT --> US/Eastern <-- 2021-07-01 16:00 UTC UTC 2021-07-01 17:00 BST Europe/London 2021-07-01 18:00 CEST Europe/Berlin 2021-07-01 18:00 CEST Europe/Paris 2021-07-01 21:30 IST Asia/Calcutta New Day: Friday - 2021-07-02 00:00 HKT Asia/Hong_Kong 2021-07-02 00:00 +08 Asia/Singapore 2021-07-02 01:00 JST Asia/Tokyo 2021-07-02 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting = Followup Actions = #topic #pr-814 * mhroncok talk to authors again, having a working example might help a lot = Followup Issues = #topic #886 Enable BRP for detecting RPATH .fpc 886 https://pagure.io/packaging-committee/issue/886 #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #1058 How to handle %lang files in package owned directories? .fpc 1058 https://pagure.io/packaging-committee/issue/1058 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 #topic #pr-1045 WIP: Add discussion of macro names beginning with underscores. https://pagure.io/packaging-committee/pull-request/1045 #topic #pr-1073 Use tilde and caret in version field https://pagure.io/packaging-committee/pull-request/1073 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Tue, Jun 29, 2021 at 04:21:03PM -0500, Michael Catanzaro wrote: > On Tue, Jun 29 2021 at 11:05:26 PM +0200, Dan Čermák > wrote: > > Thanks a lot for this Michel! > > Yes, this will reduce packager pain and suffering. Nice! > You're welcome :) If affected package owners want to help, I'm happy to add them as Change owners too. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 9:26 AM Vitaly Zaitsev via devel wrote: > > On 30/06/2021 14:44, Owen Taylor wrote: > > Setting up an independent non-profit, and maintaining it's non-profit > > status is a quite involved activity. (details depend on the country, > > of course!) > > If Flathub want to be a trustworthy repository, it should be done. > > > Hopefully this > > provides some assurance that Flathub won't suddenly start doing > > something entirely different. > > No, it doesn't. FreeNode situation is an example. While the GNOME Foundation could license or transfer the Flathub name to a commercial entity if it determined it was in the public's best interest, so could a hypothetical Flathub Foundation. In the end, Fedora doesn't have a lot of leverage to demand that the Flathub community organize itself as an independent non-profit! That being said, if we get some Flathub maintainers to come to the FESCO meeting, I'm sure they would be happy to answer questions about how Flathub is run and decisions are made. > > If we lost trust in Flathub, Fedora would also have the ability to > > update the filter to have *no* applications in it. > > Every application with --filesystem=host or --filesystem=home can drop > all filters, enable new repositories, etc. There's a distinction to be made between dubious behavior (inserting ads in applications, say) and out-and-out malware. My comment was aimed at the former - different things would need to be done in the latter case. I don't see any reason to expect Flathub to be knowingly engaging in either. We currently offer various third-party RPM repositories where the packages run without any sandboxing at all. > > Flathub is a packaging community, like Fedora. Being a professional is > > definitely not a criteria for contributing to Fedora. > > All Fedora packagers must be sponsored first and they know at least > Fedora packaging guidelines. On Flathub anyone can add anything. > > > This is something that definitely can be and will be examined when > > reviewing applications for inclusion in the Fedora filter. > > This is not a panacea. Some Flathub maintainers added --filesystem=host > or --filesystem=home after the initial review. I would imagine that when it happens, it's typically not because the maintainer is trying to sneak something over on their users (and users will get prompted on upgrade), but because it turned out there were issues with the more restrictive permissions. The main point of sandboxing is not to protect the users against the Flathub maintainers, or the app authors. It's to protect the users from malicious actors exploiting vulnerabilities in the application. By checking that the application has reasonable permissions at review time, we can get some idea of whether the Flathub maintainer knows how to use permissions, but yes, we are delegating some trust to Flathub here in the case where this changes. The Flatpak and Flathub communities would definitely appreciate help in figuring out how to nudge Flatpak packagers and application authors towards more restrictive permissions. - Owen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: List of long term FTBFS packages to be retired in August
On Wed, Jun 30, 2021 at 12:57:18PM -0400, Steve Grubb wrote: > On Wednesday, June 30, 2021 5:43:10 AM EDT Zbigniew Jędrzejewski-Szmek wrote: > > > >radamsa huzaifas, mrniranjan > > > >Fedora 32> > > > Has no bugzillas, the mass rebuilds builds never finished (they hang for > > > days) > > > > It'd be sad to lose radamsa from the distro. I pushed a snapshot build. > > Agreed and thanks. It has found many bugs in Fedora packages. However, I see > that the package's version has a '^' in it. I wonder if that is a typo? That's just me hoping that https://pagure.io/packaging-committee/pull-request/1073 gets approved ;-] Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Third-party Software Mechanism (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 7:53 AM Zbigniew Jędrzejewski-Szmek wrote: > > * There is a fedora-third-party package with a > > fedora-third-party script with > > enable/disable/refresh/query subcommands. The status is > > stored in /etc/fedora-third-party.conf > > * Packages like fedora-workstation-repositories that > > include third-party repositories will drop config files into > > /etc/fedora-third-party.d/*.conf. There will be a > > post-transaction file trigger to run fedora-third-party > > refresh, which applies the users opt-in status to newly > > installed repository files. > > For packaged stuff, please do: > > s|/etc/fedora-third-party.conf|/usr/lib/fedora-third-party.conf| > > We shouldn't add yet more stuff in /etc/. Yes, agreed. Thanks for the suggestion! Owen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Bumping lapack to 3.10.0 in rawhide
LAPACK & BLAS are going to 3.10.0 in rawhide. The sover on the shared libs is still at .3, so it _should_ not break anything, but there is a history of this not always being true. Please file bugs if things stop building against LAPACK/BLAS. Thanks, ~spot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Tue, Jun 29, 2021 at 04:25:13PM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros > > == Summary == > Introduce macros, similar to openSUSE's > [https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints > memory-constraints]), for optionally limiting build parallelism for > build-time memory-bound packages Seems fine to me. Note that of course packages like ceph also have disk space constraints. ;( But at least unifying this would be good... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: List of long term FTBFS packages to be retired in August
On Wednesday, June 30, 2021 5:43:10 AM EDT Zbigniew Jędrzejewski-Szmek wrote: > > >radamsa huzaifas, mrniranjan > > >Fedora 32> > > Has no bugzillas, the mass rebuilds builds never finished (they hang for > > days) > > It'd be sad to lose radamsa from the distro. I pushed a snapshot build. Agreed and thanks. It has found many bugs in Fedora packages. However, I see that the package's version has a '^' in it. I wonder if that is a typo? -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bringing glibc 2.34 snapshots to Fedora 35 and CentOS Stream 9
On 16/06/2021 11:17, Florian Weimer wrote: glibc-2.33.9000-18.fc35 with the first set of changes has been tagged into Fedora rawhide. Please take a look at this: https://bugzilla.redhat.com/show_bug.cgi?id=1977878 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Packager for hire - Was: Re: Additon to the repos - Kubectx + Kubens
On 30/06/2021 16:25, Miroslav Suchý wrote: But ... do we have here someone willing to do packaging and maintenance of package in Fedora/EPEL for money? Will anyone be interested in such list of people available for hire? Looks interesting. But who will pay for this job? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Rebuild ordering and side-tag support
On 6/30/21 2:38 PM, Stephen Gallagher wrote: In the scenario I'm discussing, we would take those final PackageA and PackageB from Fedora and have them in the buildroot for the ELN builds. That would mean that the bootstrap step wouldn't be needed. If there's a case you know of that this won't work for, I'd really like to hear it (preferably with real package names). Ah ok, I didn't know that ELN had already the Fedora packages as a base. I thought everything was rebuilt from scratch. Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F35 Change: Gconv package split in glibc (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Gconv_package_split_in_glibc == Summary == Most Gconv modules with the exception of unicode and similar essential ones have been split into a separate package called glibc-gconv-extra. Currently, the core package glibc has a strong (Requires) dependency on glibc-gconv-extra making this change transparent to users. This proposal is to weaken this dependency to Recommends so that it is possible to remove glibc-gconv-extra from installations that do not need it. == Owner == * Name: [[User:siddhesh| Siddhesh Poyarekar]] * Email: sipoy...@redhat.com == Detailed Description == The glibc-gconv-extra package contains all iconv converter plugins except UTF-*, unicode, ISO-8859-1, ISO8859-15, CP1252 and ANSI_X3.110. A number of minimal installations would typically not need all those plugins and they can be removed without any ill effects to those environments. To achieve this, the glibc dependency on glibc-gconv-extra needs to be weakened from Requires to Recommends. Weakening the dependency of glibc on glibc-gconv-extra implies that glibc-gconv-extra may not be pulled into certain installations by default, e.g. in buildroots for package builds. glibc-gconv-extra is however necessary because a number of packages either run tests that verify conversions between arbitrary character sets or need similar functionality to convert character sets of files in the upstream sources. A method would have to be devised to ensure that glibc-gconv-extra is available in buildroots. One option is to have redhat-rpm-config Require glibc-gconv-extra as a way to ensure that glibc-gconv-extra is in every buildroot, but better ideas are desirable. == Feedback == The change was made assuming that the weak dependency would be sufficient to address compatibility but it was subsequently rolled back when it was discovered that buildroots do not pull in weak dependencies. Since the [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/JQTTSNHMSFV63KIDDPW4M7WV7CI6KZYW/ announcement on fedora-devel] the reception to the change idea itself has been positive. There are compatibility concerns with respect to buildroots and backward compatibility, which will be addressed. == Benefit to Fedora == The ability to remove glibc-gconv-extra brings in two main benefits: * Removal can save about 8MB in the installed size, which is an advantage for minimal container images * A number of the infrequently used modules have historically had bugs that have been considered security issues. Removing the glibc-gconv-extra package is thus a hardening opportunity for UTF-8 clean environments. == Scope == * Proposal owners: The change required in glibc is minimal, requiring only spec file changes to change dependencies. * Other developers: To allow glibc-gconv-extra to be installed in minimal koji buildroots, redhat-rpm-config needs to be modified to depend on glibc-gconv-extra. Alternatively, the buildroot definition needs to be altered somehow to include glibc-gconv-extra. If none of the above are feasible, package owners will need to add a BuildRequires on glibc-gconv-extra if they need the extra converter modules. However this is the last option and should ideally be avoided. * Release engineering: [https://pagure.io/releng/issue/10176] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == 1. Update glibc on an older system and verify that glibc-gconv-extra gets updated by default 2. Update glibc on a system that has glibc-gconv-extra removed and verify that glibc-gconv-extra is not pulled in 3. glibc downgrades should also have analogous behaviour 4. Build any package in mock or koji and verify that glibc-gconv-extra is present in the buildroot == User Experience == Minimal, UTF-8-only containers can be reduced by 8MB. == Dependencies == If buildroot issues cannot be resolved through releng or a dependency on redhat-rpm-config, a number of packages will need to be updated to ensure that they build. At this moment that list is unknown. == Contingency Plan == * Contingency mechanism: glibc dependency on glibc-gconv-extra is reverted to Requires * Contingency deadline: 2021/08/24 (Beta freeze) * Blocks release? No == Documentation == Package split and its potential announced and discussed here: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/JQTTSNHMSFV63KIDDPW4M7WV7CI6KZYW/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@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
F35 Change: Gconv package split in glibc (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Gconv_package_split_in_glibc == Summary == Most Gconv modules with the exception of unicode and similar essential ones have been split into a separate package called glibc-gconv-extra. Currently, the core package glibc has a strong (Requires) dependency on glibc-gconv-extra making this change transparent to users. This proposal is to weaken this dependency to Recommends so that it is possible to remove glibc-gconv-extra from installations that do not need it. == Owner == * Name: [[User:siddhesh| Siddhesh Poyarekar]] * Email: sipoy...@redhat.com == Detailed Description == The glibc-gconv-extra package contains all iconv converter plugins except UTF-*, unicode, ISO-8859-1, ISO8859-15, CP1252 and ANSI_X3.110. A number of minimal installations would typically not need all those plugins and they can be removed without any ill effects to those environments. To achieve this, the glibc dependency on glibc-gconv-extra needs to be weakened from Requires to Recommends. Weakening the dependency of glibc on glibc-gconv-extra implies that glibc-gconv-extra may not be pulled into certain installations by default, e.g. in buildroots for package builds. glibc-gconv-extra is however necessary because a number of packages either run tests that verify conversions between arbitrary character sets or need similar functionality to convert character sets of files in the upstream sources. A method would have to be devised to ensure that glibc-gconv-extra is available in buildroots. One option is to have redhat-rpm-config Require glibc-gconv-extra as a way to ensure that glibc-gconv-extra is in every buildroot, but better ideas are desirable. == Feedback == The change was made assuming that the weak dependency would be sufficient to address compatibility but it was subsequently rolled back when it was discovered that buildroots do not pull in weak dependencies. Since the [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JQTTSNHMSFV63KIDDPW4M7WV7CI6KZYW/ announcement on fedora-devel] the reception to the change idea itself has been positive. There are compatibility concerns with respect to buildroots and backward compatibility, which will be addressed. == Benefit to Fedora == The ability to remove glibc-gconv-extra brings in two main benefits: * Removal can save about 8MB in the installed size, which is an advantage for minimal container images * A number of the infrequently used modules have historically had bugs that have been considered security issues. Removing the glibc-gconv-extra package is thus a hardening opportunity for UTF-8 clean environments. == Scope == * Proposal owners: The change required in glibc is minimal, requiring only spec file changes to change dependencies. * Other developers: To allow glibc-gconv-extra to be installed in minimal koji buildroots, redhat-rpm-config needs to be modified to depend on glibc-gconv-extra. Alternatively, the buildroot definition needs to be altered somehow to include glibc-gconv-extra. If none of the above are feasible, package owners will need to add a BuildRequires on glibc-gconv-extra if they need the extra converter modules. However this is the last option and should ideally be avoided. * Release engineering: [https://pagure.io/releng/issue/10176] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == 1. Update glibc on an older system and verify that glibc-gconv-extra gets updated by default 2. Update glibc on a system that has glibc-gconv-extra removed and verify that glibc-gconv-extra is not pulled in 3. glibc downgrades should also have analogous behaviour 4. Build any package in mock or koji and verify that glibc-gconv-extra is present in the buildroot == User Experience == Minimal, UTF-8-only containers can be reduced by 8MB. == Dependencies == If buildroot issues cannot be resolved through releng or a dependency on redhat-rpm-config, a number of packages will need to be updated to ensure that they build. At this moment that list is unknown. == Contingency Plan == * Contingency mechanism: glibc dependency on glibc-gconv-extra is reverted to Requires * Contingency deadline: 2021/08/24 (Beta freeze) * Blocks release? No == Documentation == Package split and its potential announced and discussed here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JQTTSNHMSFV63KIDDPW4M7WV7CI6KZYW/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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:
Packager for hire - Was: Re: Additon to the repos - Kubectx + Kubens
Dne 30. 06. 21 v 15:54 Justin Lamp napsal(a): want to request a new package to be added to the fedora repos. Actually... I wonder... Do we have packager(s) available for hire here? I know that we have Package maintainers wishlist: https://fedoraproject.org/wiki/Package_maintainers_wishlist But what about reverse list? People available for hire? Most of us do the package maintenance because it is our hobby or because our employer pays for that (and we are limited to the packagers of our employer choice). But ... do we have here someone willing to do packaging and maintenance of package in Fedora/EPEL for money? Will anyone be interested in such list of people available for hire? Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1853802] font selection is broken on perl-Tk-804.035-1.fc32.x86_64
https://bugzilla.redhat.com/show_bug.cgi?id=1853802 --- Comment #7 from Fedora Update System --- FEDORA-2021-639b8bfb6e has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-639b8bfb6e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-639b8bfb6e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails
https://bugzilla.redhat.com/show_bug.cgi?id=1803711 --- Comment #19 from Fedora Update System --- FEDORA-2021-639b8bfb6e has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-639b8bfb6e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-639b8bfb6e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1853802] font selection is broken on perl-Tk-804.035-1.fc32.x86_64
https://bugzilla.redhat.com/show_bug.cgi?id=1853802 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #6 from Fedora Update System --- FEDORA-2021-49127bd223 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-49127bd223` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-49127bd223 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails
https://bugzilla.redhat.com/show_bug.cgi?id=1803711 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #18 from Fedora Update System --- FEDORA-2021-49127bd223 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-49127bd223` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-49127bd223 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Additon to the repos - Kubectx + Kubens
Dne 30. 06. 21 v 15:54 Justin Lamp napsal(a): Hey there, I hope I am at the right place: I want to request a new package to be added to the fedora repos. I'd like kubectx kubens to be added. They are really nice Kubernetes tools to change the cluster or the namespace respectively. The source can be found under kubectx.dev. It is waiting for you :) https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On Wed, Jun 30, 2021 at 08:11:38AM -0500, Justin Forbes wrote: > On Wed, Jun 30, 2021 at 3:40 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Tue, Jun 29, 2021 at 03:13:10PM +0200, Tomas Tomecek wrote: > > > On Thu, Jun 24, 2021 at 8:09 PM Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > > > > > On Thu, Jun 24, 2021 at 03:48:54PM +0200, Tomas Tomecek wrote: > > > > > On Thu, Jun 24, 2021 at 12:41 PM Miro Hrončok > > > > > wrote: > > > > > > > > > > > > On 24. 06. 21 11:16, Tomas Tomecek wrote: > > > > > > > ## Choosing git forge to host source-git repositories > > > > > > > We need to find a home for all the source-git repositories. This > > > > > > > is > > > > > > > actually a really hard task because we have many options > > > > > > > (github.com, > > > > > > > gitlab.com, pagure.io, src.fedoraproject.org, something custom or > > > > > > > on-premise) and different expectations: some projects already have > > > > > > > repos set up on different platforms while Pagure is the primary > > > > > > > forge > > > > > > > now. Since the CPE team is investigating GitLab as a forge, it's > > > > > > > even > > > > > > > harder for us to figure out the primary forge. We may end up > > > > > > > supporting both actually: pagure.io and gitlab.com. What are your > > > > > > > thoughts on this topic? Would you prefer pagure.io or gitlab.com > > > > > > > More info: > > > > > > > * https://pagure.io/fedora-source-git/sig/issue/1 > > > > > > > * https://pagure.io/fedora-source-git/sig/issue/7 > > > > > > > > > > > > I would expect that since the soruce git is just an intermediate > > > > > > thing, > > > > > > supporting "any forge" is nice to have, but hard. I'd start with > > > > > > some common > > > > > > options (Pagure + 1 other) and see where you'll get. > > > > > > > > > > Yep, that's exactly what I'd like us to do. As soon as we have the > > > > > service which accepts processes events up and running, it shouldn't be > > > > > that hard to teach it new fedora-messaging messages or webhook > > > > > payloads. > > > > > > > > > > > > ## High-level workflow proposal up for review > > > > > > > Hunor proposed a high-level workflow linked below and I strongly > > > > > > > recommend reading it. We have also started discussing many > > > > > > > details in > > > > > > > the process, such as getting archives: should we generate one > > > > > > > from the > > > > > > > source-git repo or use the official release archive from upstream? > > > > > > > > > > > > One thing to consider is that the upstream tarballs might be > > > > > > cryptographically > > > > > > signed and packages should verify the signature in %prep. > > > > > > > > > > This is a very good point - in such a case, we should always pull the > > > > > official upstream tarball instead of generating a new one downstream. > > > > > > > > Hmm, but how would that work? I thought that the whole point of > > > > source-git is to build from a commit that contains some upstream > > > > version + downstream patches + downstream distro config like the spec > > > > file, > > > > and that the build step of applying downstream patches just doesn't > > > > exist. > > > > If you reuse the upstream tarball, then by necessity those downstream > > > > patches need to be serialized and applied on top like in dist-git. So > > > > you lose the property that the checkout from version control is *the* > > > > source you build, but you also lose the property that the source you > > > > build is what was signed (since patches are applied). > > > > > > What you just described I understand as an (upstream) maintenance > > > branch and is not what we call source-git. > > > > It's an "upstream maintenance branch" PLUS the .spec bits that specify > > how to build a package. > > > > > Our definition of source-git is: > > > * upstream release tarball > > > * downstream code changes applied as patches during %prep > > > * additional configs for sake of building and testing > > > > But that describes dist-git *exactly*. Where is the difference? > > > > In the spirit of openness that Fedora is based upon, it must be very > easy to determine what patches we carry as opposed to upstream, and > exactly how we build things. I very much agree with this. > This does not go away even if we get to > the point where dist-git no longer exists, and we can build directly > from source-git. In the meantime, dist-git is the "canonical source > of truth" for fedora packages, so there is a middle step to convert > from source-git to dist-git. With both, the difference in using > source-git means there is an exploded tree there, with patches > applied. This makes debug and development much easier. There is also > git history, which hopefully contains a lot more background than > currently exists in dist-git. Finally, it makes bisecting a much more > simple process, whether the offending patch is in upstream or > downstream changes. [See my long reply to the parent message...] The
Re: Weird glibc recursive stack crash in Rawhide
Dne 30. 06. 21 v 15:04 Richard W.M. Jones napsal(a): In unrelated news, what happened to the -ow...@fedoraproject.org email addresses? They seem to be bouncing for me. Please see the "package maintainer email aliases, now with more epel" email from Kevin. The -owner alias was deprecated already for quite some time AFAIK, probably since we moved away from pkdgb to Pagure. BTW there is some documentation at: https://fedoraproject.org/wiki/EmailAliases#Package_maintainers_email_aliases but it would deserve small refresh. Vít Rich. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Additon to the repos - Kubectx + Kubens
Hey there, I hope I am at the right place: I want to request a new package to be added to the fedora repos. I'd like kubectx kubens to be added. They are really nice Kubernetes tools to change the cluster or the namespace respectively. The source can be found under kubectx.dev. Thank you! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On Wed, Jun 30, 2021 at 02:03:22PM +0200, Tomas Tomecek wrote: > On Wed, Jun 30, 2021 at 10:40 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > > Our definition of source-git is: > > > * upstream release tarball > > > * downstream code changes applied as patches during %prep > > > * additional configs for sake of building and testing > > > > But that describes dist-git *exactly*. Where is the difference? > > Upstream git history and downstream patches tracked as git commits > instead of files. Hmm, so debian does something like this, with quilt for patches… Debian-style packaging needs to do this, because they still need to support non-git upstreams, even upstreams without version control, and generally cater to the lowest possible denominator. Since source-git would be the the biggest change in Fedora packaging in a decade, I hope we could do something better. The "source-git" proposal as is right now tracks the patches as git commits, but serialized. This means that the patches must be a serial sequence of commits, so any history with merges needs to be turned into a fake linear history. The current proposal also keeps the "upstream tarball" as the central object. In the past a tarball could be a custom-crafted thing with some pre-generated or pre-compiled stuff and files added and removed, and the pristine checkout of a repo wouldn't build. Those times are thankfully behind us. Tarballs are fine, but nowadays pretty much everything is just a snapshot generated from a git repo. So we shouldn't treat this one blob as special. A tarball generated from a release commit is just like a tarball generated from non-tagged commit, except that upstream designated it as special. But if the maintainer wants/needs to build from a non-release commit, then we should just do it. If we are using git, we shouldn't need to deal with applying and removing textified patches. In particular, requiring a linear history quickly breaks down for real-life repos. For example, let's say that upstream has released version 248, does a few immediate bugfix commits, and then applies a few spelling patches on top, and another CVE bugfix _merged_ as commit 248+15. We want to build this as quickly as possible. We have two choices now: use upstream tarball and pick patches by hand and create a linearized history. This is complex work, fraught with potential breakage. If the merge commit had some conflicts, the original patch from the bugfix branch will not apply. Even if there is _no confict_, the maintainer might have applied some fixes in the merge. So the packager needs to do a rebase of the patch and possibly find subsequent tweaks that are not part of the patch. I maintain the stable branches from systemd [1], and I know firsthand that trying to rebase non-trivial patches is complex and you just screw it up every once in a while. And this is for a project which I know extremely well. For a project where I'm just a packager, non-trivial rebases become guesswork. The other choice is to take the appropriate upstream commit and just build the tarball from that. Just do it, without guesswork or manual steps. It feels very much like the current "source-git" proposal is trying to recreate the existing workflows with some minimal changes. Those existing workflows evolved to handle idiosyncrasies which are not needed anymore. Those old projects will not switch to source-git anyway. I think it's much better to handle those modern git upstreams idiomatically. In the proposed workflow [2], 'git reset --hard' is an integral part of the maintainer steps. I proposed how not to do that in a comment there [3]. The important part is that how we reach the commit from which we will build, i.e. the details of history, should be an implementation detail. (Similarly to how normal git repos work: some upstreams use github's "squash", others use "merge" always, and so on. We only care about the end result, i.e. the tree content of the commit, not its parents.) In very short detail, the workflow IMO should be: - take an upstream repo - create a branch that contains selected upstream commit + possibly some patches + downstream packaging stuff (.spec, etc). The tree object attached to that commit is what will be built. (In the common case, this branch will be a child of the upstream release and the previous packaging branch. After all, most of the time packaging changes when updating to a new release are very small. This is important to be able to see (using appropriate 'git diff' and 'git log' invocations), what changed wrt. to the upstream, previous packaging build, latest upstream release, etc.) - to build: 'git archive', unpack in the build system, go to %build. [1] https://github.com/systemd/systemd-stable [2] https://pagure.io/fedora-source-git/docs/pull-request/2#request_diff [3] https://pagure.io/fedora-source-git/docs/pull-request/2#comment-152304 Zbyszek ___ devel mailing
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On 30/06/2021 14:44, Owen Taylor wrote: Setting up an independent non-profit, and maintaining it's non-profit status is a quite involved activity. (details depend on the country, of course!) If Flathub want to be a trustworthy repository, it should be done. Hopefully this provides some assurance that Flathub won't suddenly start doing something entirely different. No, it doesn't. FreeNode situation is an example. If we lost trust in Flathub, Fedora would also have the ability to update the filter to have *no* applications in it. Every application with --filesystem=host or --filesystem=home can drop all filters, enable new repositories, etc. Flathub is a packaging community, like Fedora. Being a professional is definitely not a criteria for contributing to Fedora. All Fedora packagers must be sponsored first and they know at least Fedora packaging guidelines. On Flathub anyone can add anything. This is something that definitely can be and will be examined when reviewing applications for inclusion in the Fedora filter. This is not a panacea. Some Flathub maintainers added --filesystem=host or --filesystem=home after the initial review. Unfortunately, a lot of interesting software can't be completely sandboxed - because it, say, uses X11 rather than Wayland. X11 is not a problem. Btw, a lot of Qt applications from Flathub explicitly uses X11 over Wayland due to buggy downstream patch: https://github.com/flathub/com.kristianduske.TrenchBroom/blob/98a3b8a6e55ccbf1a44771d8a099d30622c07d3e/com.kristianduske.TrenchBroom.json#L12 https://github.com/flathub/org.kde.kolourpaint/blob/0527e34fabb41cba37c6707ee107e97556ee762a/org.kde.kolourpaint.json#L14 https://github.com/flathub/com.chatterino.chatterino/blob/18e03ca830f28ea876dae6507c26e5f1cbfb9cec/com.chatterino.chatterino.yml#L14 https://github.com/flathub/org.openhantek.OpenHantek6022/blob/6fa7f8c357fc0573f64aed6e6e5de5e28d04427b/org.openhantek.OpenHantek6022.yml#L15 https://github.com/flathub/com.rosegardenmusic.rosegarden/blob/8ac254753f6e7b29413ae30f03a6ef621461c289/com.rosegardenmusic.rosegarden.json#L13 https://github.com/flathub/org.electrum.electrum/blob/7a3867719cb20ee22e7c3ef8847dc57b2360f7ff/org.electrum.electrum.json#L10 https://github.com/flathub/com.github.fontmatrix.Fontmatrix/blob/49fdebbf009bc336f5c19417b818783ed5a53421/com.github.fontmatrix.Fontmatrix.json#L16 https://github.com/flathub/uk.org.zint.zint-qt/blob/f6c30cfe2858bada7785ae73284644858a583cf0/uk.org.zint.zint-qt.yaml#L15 https://github.com/flathub/org.avidemux.Avidemux/blob/75ffac52c85cc1ceb105992f4581fe0469194139/org.avidemux.Avidemux.yaml#L11 https://github.com/flathub/org.dash.electrum.electrum_dash/blob/fdad9ec436cf6ed92a2cd13b331566c1131d0a78/org.dash.electrum.electrum_dash.json#L10 https://github.com/flathub/org.hydrogenmusic.Hydrogen/blob/425efc134dfa9f3fae189792e21e5ae060815e74/org.hydrogenmusic.Hydrogen.json#L14 https://github.com/flathub/org.musescore.MuseScore/blob/c2a2f112f34538c2e59b20cba74a53a0c329bd16/org.musescore.MuseScore.yaml#L21 https://github.com/flathub/io.lmms.LMMS/blob/1a7c3f8780794c2fd3d088a24ac12f9398d08b7c/io.lmms.LMMS.json#L19 https://github.com/flathub/org.kde.okular/blob/7e4f34ccf6e86eaf3f4ad57ec3747aa9e1f9/org.kde.okular.json#L15 https://github.com/flathub/net.scribus.Scribus/blob/9f6bebb19e525242437583d376f436aa0ba253ce/net.scribus.Scribus.yaml#L23 https://github.com/flathub/org.mixxx.Mixxx/blob/da784e9b76cb1c304401164899d8fe6ad350d8d3/org.mixxx.Mixxx.yaml#L16 https://github.com/flathub/org.freecadweb.FreeCAD/blob/abbc05c0ff45d3e59f7581edf03339a767444a0f/org.freecadweb.FreeCAD.yaml#L10 https://github.com/flathub/org.kde.kontact/blob/2d277bd9054141b831e02ebe72ffc1c601d65cc7/org.kde.kontact.json#L49 The text you qouoted said "or software in Fedora that could easily be made into a Flatpak" - I left some wiggle room there, but certainly if we were including anything that overlapped Fedora RPMs, one of two things would need to be true: Fixed version: d) doesn't exists in Fedora RPM repositories (except ostree-based Fedora editions). Installation from Flathub would need to be prioritized after installation from Fedora RPMs Gnome Sofware already prioritizes Flatpaks over RPM packages even on Workstation Edition. I don't like that. Flatpaks prioritization should only be done on ostree versions. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On Wed, Jun 30, 2021 at 3:40 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Jun 29, 2021 at 03:13:10PM +0200, Tomas Tomecek wrote: > > On Thu, Jun 24, 2021 at 8:09 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Thu, Jun 24, 2021 at 03:48:54PM +0200, Tomas Tomecek wrote: > > > > On Thu, Jun 24, 2021 at 12:41 PM Miro Hrončok > > > > wrote: > > > > > > > > > > On 24. 06. 21 11:16, Tomas Tomecek wrote: > > > > > > ## Choosing git forge to host source-git repositories > > > > > > We need to find a home for all the source-git repositories. This is > > > > > > actually a really hard task because we have many options > > > > > > (github.com, > > > > > > gitlab.com, pagure.io, src.fedoraproject.org, something custom or > > > > > > on-premise) and different expectations: some projects already have > > > > > > repos set up on different platforms while Pagure is the primary > > > > > > forge > > > > > > now. Since the CPE team is investigating GitLab as a forge, it's > > > > > > even > > > > > > harder for us to figure out the primary forge. We may end up > > > > > > supporting both actually: pagure.io and gitlab.com. What are your > > > > > > thoughts on this topic? Would you prefer pagure.io or gitlab.com > > > > > > More info: > > > > > > * https://pagure.io/fedora-source-git/sig/issue/1 > > > > > > * https://pagure.io/fedora-source-git/sig/issue/7 > > > > > > > > > > I would expect that since the soruce git is just an intermediate > > > > > thing, > > > > > supporting "any forge" is nice to have, but hard. I'd start with some > > > > > common > > > > > options (Pagure + 1 other) and see where you'll get. > > > > > > > > Yep, that's exactly what I'd like us to do. As soon as we have the > > > > service which accepts processes events up and running, it shouldn't be > > > > that hard to teach it new fedora-messaging messages or webhook > > > > payloads. > > > > > > > > > > ## High-level workflow proposal up for review > > > > > > Hunor proposed a high-level workflow linked below and I strongly > > > > > > recommend reading it. We have also started discussing many details > > > > > > in > > > > > > the process, such as getting archives: should we generate one from > > > > > > the > > > > > > source-git repo or use the official release archive from upstream? > > > > > > > > > > One thing to consider is that the upstream tarballs might be > > > > > cryptographically > > > > > signed and packages should verify the signature in %prep. > > > > > > > > This is a very good point - in such a case, we should always pull the > > > > official upstream tarball instead of generating a new one downstream. > > > > > > Hmm, but how would that work? I thought that the whole point of > > > source-git is to build from a commit that contains some upstream > > > version + downstream patches + downstream distro config like the spec > > > file, > > > and that the build step of applying downstream patches just doesn't exist. > > > If you reuse the upstream tarball, then by necessity those downstream > > > patches need to be serialized and applied on top like in dist-git. So > > > you lose the property that the checkout from version control is *the* > > > source you build, but you also lose the property that the source you > > > build is what was signed (since patches are applied). > > > > What you just described I understand as an (upstream) maintenance > > branch and is not what we call source-git. > > It's an "upstream maintenance branch" PLUS the .spec bits that specify > how to build a package. > > > Our definition of source-git is: > > * upstream release tarball > > * downstream code changes applied as patches during %prep > > * additional configs for sake of building and testing > > But that describes dist-git *exactly*. Where is the difference? > In the spirit of openness that Fedora is based upon, it must be very easy to determine what patches we carry as opposed to upstream, and exactly how we build things. This does not go away even if we get to the point where dist-git no longer exists, and we can build directly from source-git. In the meantime, dist-git is the "canonical source of truth" for fedora packages, so there is a middle step to convert from source-git to dist-git. With both, the difference in using source-git means there is an exploded tree there, with patches applied. This makes debug and development much easier. There is also git history, which hopefully contains a lot more background than currently exists in dist-git. Finally, it makes bisecting a much more simple process, whether the offending patch is in upstream or downstream changes. Justin ___ 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:
List of long term FTBFS packages to be retired in August
Dear maintainers. Based on the current fail to build from source policy, the following packages will be retired from Fedora 35 approximately one week before branching (August 2021). Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 32. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers Latest build cardpeek kalevFedora 32 percona-xtrabackupslaanesh, slankesFedora 32 php-opencloud-openstack lcts Fedora 32 proxyfuzz psklenar Fedora 32 radamsa huzaifas, mrniranjan Fedora 32 sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora 31 tuxbrewr zram pbrobinson Fedora 32 The following packages require above mentioned packages: Depending on: percona-xtrabackup (1), status change: 2020-11-22 (31 weeks ago) holland (maintained by: immanetize, jeffreyness, survient) holland-xtrabackup-1.2.4-2.fc35.noarch requires /usr/bin/xtrabackup Affected (co)maintainers callkalpa: sugar-view-slides chimosky: sugar-view-slides huzaifas: radamsa immanetize: percona-xtrabackup jeffreyness: percona-xtrabackup kalev: cardpeek lcts: php-opencloud-openstack mrniranjan: radamsa pbrobinson: zram, sugar-view-slides psklenar: proxyfuzz slaanesh: percona-xtrabackup slankes: percona-xtrabackup survient: percona-xtrabackup tuxbrewr: sugar-view-slides ___ devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On 30/06/2021 14:30, Michael Catanzaro wrote: Well that's required for anything not present in the runtime. That's why I prefer classic RPM packages over Flatpaks. I use Flatpaks only for proprietary software like Steam (with a lot of permission hardening overrides). I believe hardening flags are added in by flatpak-builder. I think they somehow come from the runtime, though I'm not sure exactly how. (Anybody know?) Yes, but some developers think they are smarter than runtime maintainers and explicitly explicitly ignore them. I've previously reported such incidents. However, for most Fedora editions, it's also irrelevant, because RPMs are entirely unsandboxed and banning poorly-sandboxed flatpak applications doesn't make sense when you can just install completely unsandboxed RPM applications. Flatpak is being advertised as a safe and secure environment for running desktop applications. Flatpak with access to user's home directory can do everything: change Flatpak policies, add/remove Flatpak repositories, override security permissions, etc. I think Flatpaks with --filesystem=host or --filesystem=home should be banned too. Flathub admins don't consider this a security breach. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Weird glibc recursive stack crash in Rawhide
On Wed, Jun 30, 2021 at 01:30:52PM +0100, Richard W.M. Jones wrote: > It seems to affect only qemu for some reason. > > https://bugzilla.redhat.com/show_bug.cgi?id=1975693#c13 So it's a genuine bug: if you are using glibc from Rawhide and seccomp, and your seccomp rules are blocking the sched_getaffinity syscall, then glibc will go into an infinite loop and crash :-( In unrelated news, what happened to the -ow...@fedoraproject.org email addresses? They seem to be bouncing for me. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 7:44 AM Ian McInerney wrote: >> Roughly speaking, the criteria for including software is a) will not >> cause legal or other problems for Fedora to point to b) does not >> overlap Fedora Flatpaks or software in Fedora that could easily be >> made into a Flatpak c) works reasonably well. For Fedora 35, We expect >> to include all software from the top 50 most popular applications on >> Flathub that meet these criteria plus selected other software of >> interest to the Fedora target audience - Fedora community members are >> welcome to propose additions. > > Does this mean that FESCO is now forcing Fedora packagers to maintain Fedora > Flatpaks and respond to their related issues when many of them seem to be > created without the packagers' knowledge/consent, and there is no > documentation in the packaging guidelines/wiki about how to actually do > anything for them, or information about where the manifests for them actually > live? This proposal doesn't really change anything with respect to Fedora Flatpaks. (Docs for Fedora Flatpaks: https://docs.fedoraproject.org/en-US/flatpak/) Are you concerned that there's some implicit threat that if you don't create a Fedora Flatpak for your Fedora RPM, users will be directed to the Flathub version? We're really not anticipating overlap between the set of applications packaged in Fedora and the set included in the filtered-view of Flathub. Any exceptions to that would definitely have to be coordinated closely with the relevant package maintainer. Owen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 6:42 AM Vitaly Zaitsev via devel wrote: > > On 29/06/2021 22:25, Ben Cotton wrote: > > Enabling third-party repositories will now create a Flathub remote > > that is a filtered view of Flathub. > > I don't trust Flathub at all, because they don't want to register a > non-profit organization. They can easily sell their business like > FreeNode did recently. Setting up an independent non-profit, and maintaining it's non-profit status is a quite involved activity. (details depend on the country, of course!) Flathub's non-donated hardware resources are owned by the GNOME Foundation (a registered non-profit) and the GNOME Foundation also owns the Flathub trademark (See: https://foundation.gnome.org/logo-and-trademarks/). Hopefully this provides some assurance that Flathub won't suddenly start doing something entirely different. If we lost trust in Flathub, Fedora would also have the ability to update the filter to have *no* applications in it. > Flathub relies on upstreams, not professional maintainers. Most of > upstream developers don't know how to package software properly. They > bundle lots of libraries, don't use C/C++ build hardening flags, etc. Flathub is a packaging community, like Fedora. Being a professional is definitely not a criteria for contributing to Fedora. :-) > A lot of applications from Flathub uses --filesystem=host or > --filesystem=home, which means they don't use Flatpak isolation at all. This is something that definitely can be and will be examined when reviewing applications for inclusion in the Fedora filter. Unfortunately, a lot of interesting software can't be completely sandboxed - because it, say, uses X11 rather than Wayland. But where thing *can* be sandboxed they should be sandboxed. > Due to the bundling of a large number of libraries, some applications > have critical vulnerabilities with assigned CVE numbers: CVE-2020-12284, > CVE-2019-17498, CVE-2018-11235, CVE-2018-17456, CVE-2017-9780. There are definitely improvements that could be made to CVE response policies in Flathub, and I know automated scanning was being worked on. If we were activitely looking to delegate software that is packaged in Fedora to Flathub, I think we'd need to have a very high bar here. But as a source of *additional* software, I think the standard should be comparison to wherever the Fedora user would get the software from otherwise. When this is scheduled for FESCO discussion, I'll try to see if we can get some Flathub maintainers to attend in case people have questions in this area (or other areas). > > Roughly speaking, the criteria for including software is a) will not > > cause legal or other problems for Fedora to point to b) does not > > overlap Fedora Flatpaks or software in Fedora that could easily be > > made into a Flatpak c) works reasonably well. > > Should be added also: > > d) doesn't exists in Fedora RPM repositories. The text you qouoted said "or software in Fedora that could easily be made into a Flatpak" - I left some wiggle room there, but certainly if we were including anything that overlapped Fedora RPMs, one of two things would need to be true: * Installation from Flathub would need to be prioritized after installation from Fedora RPMs * Fedora Silverblue would need it's own filter list with additional applications In the immediate future, our plan is to avoid any such overlap. > > Fedora users who opt-in to third-party software repositories will have > > immediate access to more software out-of-the-box. > > Fedora Silverblue must have its own Flatpaks and do not rely on third-party > repositories. This is not about replacing software that is included in Fedora. It's about providing access to software *not* included in Fedora. Thanks for the feedback! Owen - Owen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 2:31 PM Michael Catanzaro wrote: > I believe hardening flags are added in by flatpak-builder. I think they > somehow come from the runtime, though I'm not sure exactly how. > (Anybody know?) > Yes: there's a flatpak-builder config file in /etc/flatpak-builder/defaults.json that's part of the runtime that adds the hardening flags. -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Third-party Software Mechanism (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 02:09:19PM +0200, Miroslav Suchý wrote: > Dne 30. 06. 21 v 13:52 Zbigniew Jędrzejewski-Szmek napsal(a): > >For packaged stuff, please do: > > > > s|/etc/fedora-third-party.conf|/usr/lib/fedora-third-party.conf| > > > >We shouldn't add yet more stuff in/etc/. > > I guess that /usr/lib is typo and you meant /var/lib/ No, /usr/lib. This was in response to: > Packages like fedora-workstation-repositories that include > third-party repositories will drop config files into > /etc/fedora-third-party.d/*.conf Those config files should be in /usr/lib/fedora-third-party.d/. > There is a fedora-third-party package with a fedora-third-party > script with enable/disable/refresh/query subcommands. The status is > stored in /etc/fedora-third-party.conf That part is fine. When the user does a manual configuration step, this should be stored in /etc/. (Essentially, the usual systemd-style config file split.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Rebuild ordering and side-tag support
On Tue, Jun 29, 2021 at 2:34 PM Robert-André Mauchin wrote: > > On 6/28/21 5:55 PM, Stephen Gallagher wrote: > > Summary: I think we can fix the ELN side-tag rebuild problems and make > > the composes more reliable if we change the mechanism for kicking off > > rebuilds. I'm soliciting feedback to help identify potential issues > > with this proposed approach. > > > > How do you handle packages that need bootstrapping? Several Go packages > must be built in a certain order with bootstrapping on, on a virgin > branch. It takes auite a lot of time. > Would they not be able to build atop the Fedora versions that have already been bootstrapped? I'm not sure I understand the situation. Most bootstrapping scenarios that I'm aware of are essentially: PackageB needs an updated PackageA to build, but PackageA also needs an updated PackageB to build. PackageA can be bootstrapped (by building it in some special manner, such as from a prebuilt upstream binary), allowing PackageB to be built and then rebuilding PackageA with the updated PackageB. In the scenario I'm discussing, we would take those final PackageA and PackageB from Fedora and have them in the buildroot for the ELN builds. That would mean that the bootstrap step wouldn't be needed. If there's a case you know of that this won't work for, I'd really like to hear it (preferably with real package names). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: PSA: /usr/lib/rpm/redhat/brp-python-hardlink: No such file or directory [and how to solve it]
On 30. 06. 21 14:21, Miro Hrončok wrote: If you see the following error in a Rawhide mock build: ... + /usr/lib/rpm/redhat/brp-python-hardlink /var/tmp/rpm-tmp.WFxggi: line 65: /usr/lib/rpm/redhat/brp-python-hardlink: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WFxggi (%install) Update your mock chroot from the "local" repository: $ mock -r fedora-rawhide-x86_64 --enablerepo=local --update And don't clean it before running the build. If you see the error in Koji, please let me know ASAP. I've mixed my WIP fix with the roginal error. The error you are likely to see is actually: /usr/lib/rpm/brp-python-hardlink: No such file or directory -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: PSA: /usr/lib/rpm/redhat/brp-python-hardlink: No such file or directory [and how to solve it]
On 30. 06. 21 14:21, Miro Hrončok wrote: If you see the following error in a Rawhide mock build: ... + /usr/lib/rpm/redhat/brp-python-hardlink /var/tmp/rpm-tmp.WFxggi: line 65: /usr/lib/rpm/redhat/brp-python-hardlink: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WFxggi (%install) Update your mock chroot from the "local" repository: $ mock -r fedora-rawhide-x86_64 --enablerepo=local --update And don't clean it before running the build. If you see the error in Koji, please let me know ASAP. I've mixed my WIP fix with the roginal error. The error you are likely to see is actually: /usr/lib/rpm/brp-python-hardlink: No such file or directory -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Rebuild ordering and side-tag support
On Tue, Jun 29, 2021 at 12:59 PM Kevin Fenzi wrote: > Would these rawhide builds go out in ELN composes? > Or would you block composes until you had only eln rpms in it? They would go out in the composes until they are successfully rebuilt. This is to ensure that Content Resolver continues to have a fresh compose to check dependencies. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
Randy, thank you for providing such detailed information! A few comments inline. On Wed, Jun 30, 2021 at 3:01 AM Randy Barlow via devel < devel@lists.fedoraproject.org> wrote: > On Tue, 2021-06-29 at 15:36 +0200, Tomas Tomecek wrote: > > > On the "uni-repo" counter proposal: there's a bunch of real-world > > > examples here of distributions using this successfully: > > > > > https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow > > Hey Tomas! > > As Colin noted above, Gentoo uses a single repo (well, technically, > they also have overlays, but the main distro is just one git repo is > what I mean…) I'll add some comments to your thoughts below: > After reading your explanation of how gentoo does packaging, it indeed makes a lot of sense and feels like that most of the concerns I pointed out have solutions or could be mitigated. The biggest problem I personally see is the effort which would be needed to pull this off: it would take years to accomplish, a ton of teams would be involved and all the maintainers would need to cooperate - and then we'd need to do the same thing for CentOS Stream and RHEL. Such a change to the development workflow would be massive and the level of coordination would be immense. That's all I can say. * On a system with an ssd I hadn't pulled for two days, and a git > pull took 0m3.357s. > * On a system with a spinny disk I hadn't pulled since January 17, > and a git pull took 1m27.878s. I'd say that this is probably close > to a "worst case" scenario, except that I do have a 200 Mbps > internet connection. Most of the time was spent doing stuff with > the disk and not on network. I could imagine a slow network making > this even longer. > Since we all would work in a single git repo, I'm assuming the pulls would be cheap most of the time. CI and builders would probably need a caching mechanism so the repo wouldn't need to be fetched from scratch all the time. > * How would CI function? > > Due to the atomic commit, I'd say CI could function better because you > know what changes need to be tested together. > > Gentoo doesn't have per-package CI that I'm aware of, but they do have > general checks that they do on all packages. They've got a QA bot that > check PRs on GitHub and marks them as pass/fail. > > > * Where and how would tests be stored? > > As said, I don't think Gentoo does this, but I could imagine having a > tests/ subfolder in the package's folder, not too different from what > we do now. > Well, tests could be stored alongside packaging files as they are right now. > * How would contributions be handled? It would be hard to detect > > stalled PRs, maintainers would be swarmed with changes not related to > > their packages. > > Here's an example of a Gentoo PR I worked on recently: > > https://github.com/gentoo/gentoo/pull/20975 > > Note that there are two bots that have commented on it. The interesting > one for this question is gentoo-bot - it came and marked the PR with > some metadata, helpful links into the bug tracker, CoC, and other > stuff, and most usefully, labeled the PR with some special labels. > > If Fedora had such a bot you could imagine it doing things like > assigning it to the right person (or otherwise notifying them), pinging > long-open PRs, or other things like that. > > The other bot on that PR is the Gentoo QA bot, and it does some basic > checks on your commit to make sure you followed some basic > rules/guidelines. It's not the same thing as what we have in Fedora. > > We do have PRs in Fedora that stay open for a long time too, so I don't > think that's a monorepo vs. lots-of-repos problem ☺ > Looks like the gentoo-bot is a critical piece of the development process so that people are able to progress with their contributions efficiently. Oh, and one other thought, Gentoo is not doing what we call source-git > either. Like us, the packages operate on a tarball, typically from > upstream, and then they apply patches to them as needed. I think it > would be probably too extreme to do a source-git thing with a monorepo > (like, if the kernel source code and the Firefox source code and the > GNOME source code were all in the same repo, that would probably be a > bit much ☺) > Monorepo source-git wouldn't work, our SSDs are not that big, yet :D Thanks Randy for such a great write-up. Now that I think about it, the monorepo proposal is orthogonal to the source-git proposal as the two workflows serve different purposes: one is meant for development (source-git: write a patch), the other one for integration into the operating system (tinker with a spec file or the build system). Tomas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:
Weird glibc recursive stack crash in Rawhide
It seems to affect only qemu for some reason. https://bugzilla.redhat.com/show_bug.cgi?id=1975693#c13 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On Wed, Jun 30 2021 at 12:41:17 PM +0200, Vitaly Zaitsev via devel wrote: They bundle lots of libraries, Well that's required for anything not present in the runtime. don't use C/C++ build hardening flags, etc. I believe hardening flags are added in by flatpak-builder. I think they somehow come from the runtime, though I'm not sure exactly how. (Anybody know?) For freedesktop-sdk and the GNOME SDK, the hardening flags are actually copied straight from Fedora with only minor adjustments. E.g. GCC is built with --enable-default-pie --enable-default-ssp so the runtime doesn't need to use GCC specs in the default flags like Fedora does. Again, since applications do get these flags (somehow), they have to go out of their way to screw this up. (Seriously, how do the applications inherit the hardening flags? It can't be via magic. We should confirm that this actually works.) A lot of applications from Flathub uses --filesystem=host or --filesystem=home, which means they don't use Flatpak isolation at all. This is true. However, for most Fedora editions, it's also irrelevant, because RPMs are entirely unsandboxed and banning poorly-sandboxed flatpak applications doesn't make sense when you can just install completely unsandboxed RPM applications. For Silverblue, it would make sense IMO to be stricter and filter poorly-sandboxed applications out of GNOME Software. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 7:59 AM Colin Walters wrote: > > > > On Tue, Jun 29, 2021, at 4:25 PM, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros > > > > == Summary == > > Introduce macros, similar to openSUSE's > > [https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints > > memory-constraints]), for optionally limiting build parallelism for > > build-time memory-bound packages > > If our RPM builds were Kubernetes pods (or executed via podman, which > understands the same things), it'd make sense to use > https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ > > Plus there's a whole ecosystem around that, like the vertical pod autoscaler: > https://docs.openshift.com/container-platform/4.7/nodes/pods/nodes-pods-vertical-autoscaler.html Even in that world, packagers would have no access to Kubernetes configuration. Fortunately, we don't use Kubernetes for our package build infrastructure. That's a complication that I'm grateful to not have to deal with. -- 真実はいつも一つ！/ 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 on the list, report it: https://pagure.io/fedora-infrastructure
PSA: /usr/lib/rpm/redhat/brp-python-hardlink: No such file or directory [and how to solve it]
If you see the following error in a Rawhide mock build: ... + /usr/lib/rpm/redhat/brp-python-hardlink /var/tmp/rpm-tmp.WFxggi: line 65: /usr/lib/rpm/redhat/brp-python-hardlink: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WFxggi (%install) Update your mock chroot from the "local" repository: $ mock -r fedora-rawhide-x86_64 --enablerepo=local --update And don't clean it before running the build. If you see the error in Koji, please let me know ASAP. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
PSA: /usr/lib/rpm/redhat/brp-python-hardlink: No such file or directory [and how to solve it]
If you see the following error in a Rawhide mock build: ... + /usr/lib/rpm/redhat/brp-python-hardlink /var/tmp/rpm-tmp.WFxggi: line 65: /usr/lib/rpm/redhat/brp-python-hardlink: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WFxggi (%install) Update your mock chroot from the "local" repository: $ mock -r fedora-rawhide-x86_64 --enablerepo=local --update And don't clean it before running the build. If you see the error in Koji, please let me know ASAP. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 8:09 AM Ian McInerney wrote: > > On Wed, Jun 30, 2021 at 12:47 PM Neal Gompa wrote: >> >> On Wed, Jun 30, 2021 at 7:43 AM Ian McInerney >> wrote: >> > >> > On Tue, Jun 29, 2021 at 9:26 PM Ben Cotton wrote: >> >> >> >> https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications >> >> >> >> == Summary == >> >> Enabling third-party repositories will now create a Flathub remote >> >> that is a filtered view of Flathub. >> >> >> >> >> >> == Detailed Description == >> >> 'Note that this proposal is about user experience, procedures, and >> >> technology - the high-level concept has already been discussed and >> >> approved by the Fedora Council and FESCO.' >> >> >> >> Enabling third-party repositories will now create a Flathub remote >> >> that is a filtered view of Flathub. This means that applications on >> >> Flathub that have been explicitly approved (by a new process proposed >> >> here) will be available in GNOME Software and on the >> >> flatpak command line. If the user follows following the >> >> instructions on https://flatpak.org/setup/Fedora/, then the filter is >> >> removed, and the user gets a full view of Flathub. >> >> >> >> Roughly speaking, the criteria for including software is a) will not >> >> cause legal or other problems for Fedora to point to b) does not >> >> overlap Fedora Flatpaks or software in Fedora that could easily be >> >> made into a Flatpak c) works reasonably well. For Fedora 35, We expect >> >> to include all software from the top 50 most popular applications on >> >> Flathub that meet these criteria plus selected other software of >> >> interest to the Fedora target audience - Fedora community members are >> >> welcome to propose additions. >> > >> > >> > Does this mean that FESCO is now forcing Fedora packagers to maintain >> > Fedora Flatpaks and respond to their related issues when many of them seem >> > to be created without the packagers' knowledge/consent, and there is no >> > documentation in the packaging guidelines/wiki about how to actually do >> > anything for them, or information about where the manifests for them >> > actually live? >> > >> >> Of course not. This is a criteria for what we permit through the >> filter from Flathub. The idea is that nothing we offer from Flathub >> should be possible to ship in Fedora itself. That is, it's truly only >> possible to be available as a third-party app. >> >> Basically, if something is available in Fedora, it *cannot* be >> available through Flathub by default. > > > But that is exactly why it seems to me packagers are being forced to care > about the Fedora Flatpaks. Take the Audacity package as an example (since I > am one of the people maintaining it). There is a usable Flatpak for it on > Flathub, and I as a packager don't want to need to learn the Fedora systems > to build and maintain a Fedora Flatpak for it (since there seems to be little > to no documentation on how to do it). According to this policy - since there > is an Audacity package in Fedora, the Flathub version couldn't be included. > If we don't have a maintained version of the Flatpak in Fedora, then why are > we blocking it from Flathub? > Because most people are able to install RPMs *and* Flatpaks. And there's a process for auto-building Flatpaks from our RPM spec definitions that can use for apps packaged in Fedora. But most importantly, a large chunk of the applications on Flathub include stuff we can't directly recommend for various reasons (patent-encumbered stuff, etc.). -- 真実はいつも一つ！/ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Third-party Software Mechanism (System-Wide Change proposal)
Dne 30. 06. 21 v 13:52 Zbigniew Jędrzejewski-Szmek napsal(a): For packaged stuff, please do: s|/etc/fedora-third-party.conf|/usr/lib/fedora-third-party.conf| We shouldn't add yet more stuff in/etc/. I guess that /usr/lib is typo and you meant /var/lib/ Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 12:47 PM Neal Gompa wrote: > On Wed, Jun 30, 2021 at 7:43 AM Ian McInerney > wrote: > > > > On Tue, Jun 29, 2021 at 9:26 PM Ben Cotton wrote: > >> > >> https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications > >> > >> == Summary == > >> Enabling third-party repositories will now create a Flathub remote > >> that is a filtered view of Flathub. > >> > >> > >> == Detailed Description == > >> 'Note that this proposal is about user experience, procedures, and > >> technology - the high-level concept has already been discussed and > >> approved by the Fedora Council and FESCO.' > >> > >> Enabling third-party repositories will now create a Flathub remote > >> that is a filtered view of Flathub. This means that applications on > >> Flathub that have been explicitly approved (by a new process proposed > >> here) will be available in GNOME Software and on the > >> flatpak command line. If the user follows following the > >> instructions on https://flatpak.org/setup/Fedora/, then the filter is > >> removed, and the user gets a full view of Flathub. > >> > >> Roughly speaking, the criteria for including software is a) will not > >> cause legal or other problems for Fedora to point to b) does not > >> overlap Fedora Flatpaks or software in Fedora that could easily be > >> made into a Flatpak c) works reasonably well. For Fedora 35, We expect > >> to include all software from the top 50 most popular applications on > >> Flathub that meet these criteria plus selected other software of > >> interest to the Fedora target audience - Fedora community members are > >> welcome to propose additions. > > > > > > Does this mean that FESCO is now forcing Fedora packagers to maintain > Fedora Flatpaks and respond to their related issues when many of them seem > to be created without the packagers' knowledge/consent, and there is no > documentation in the packaging guidelines/wiki about how to actually do > anything for them, or information about where the manifests for them > actually live? > > > > Of course not. This is a criteria for what we permit through the > filter from Flathub. The idea is that nothing we offer from Flathub > should be possible to ship in Fedora itself. That is, it's truly only > possible to be available as a third-party app. > > Basically, if something is available in Fedora, it *cannot* be > available through Flathub by default. > But that is exactly why it seems to me packagers are being forced to care about the Fedora Flatpaks. Take the Audacity package as an example (since I am one of the people maintaining it). There is a usable Flatpak for it on Flathub, and I as a packager don't want to need to learn the Fedora systems to build and maintain a Fedora Flatpak for it (since there seems to be little to no documentation on how to do it). According to this policy - since there is an Audacity package in Fedora, the Flathub version couldn't be included. If we don't have a maintained version of the Flatpak in Fedora, then why are we blocking it from Flathub? -Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On Wed, Jun 30, 2021 at 10:40 AM Zbigniew Jędrzejewski-Szmek wrote: > > > Our definition of source-git is: > > * upstream release tarball > > * downstream code changes applied as patches during %prep > > * additional configs for sake of building and testing > > But that describes dist-git *exactly*. Where is the difference? Upstream git history and downstream patches tracked as git commits instead of files. > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Tue, Jun 29, 2021, at 4:25 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros > > == Summary == > Introduce macros, similar to openSUSE's > [https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints > memory-constraints]), for optionally limiting build parallelism for > build-time memory-bound packages If our RPM builds were Kubernetes pods (or executed via podman, which understands the same things), it'd make sense to use https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ Plus there's a whole ecosystem around that, like the vertical pod autoscaler: https://docs.openshift.com/container-platform/4.7/nodes/pods/nodes-pods-vertical-autoscaler.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Third-party Software Mechanism (System-Wide Change proposal)
> == Technical implementation == > > * There is a fedora-third-party package with a > fedora-third-party script with > enable/disable/refresh/query subcommands. The status is > stored in /etc/fedora-third-party.conf > * Packages like fedora-workstation-repositories that > include third-party repositories will drop config files into > /etc/fedora-third-party.d/*.conf. There will be a > post-transaction file trigger to run fedora-third-party > refresh, which applies the users opt-in status to newly > installed repository files. For packaged stuff, please do: s|/etc/fedora-third-party.conf|/usr/lib/fedora-third-party.conf| We shouldn't add yet more stuff in /etc/. Zbyszek > * We add a new page to GNOME Initial Setup that asks a single > question, *along the lines of*: > '''Enable Third Party Software repositories?''' > ☑ Access additional software from selected third party sources. Some > of this software is proprietary and therefore has restrictions on use, > sharing, and access to source code. > [Find out > more...](https://fedoraproject.org/wiki/Workstation/Third_Party_Software_Repositories) > * If the user leaves the box checked, GNOME Initial setup runs > `fedora-third-party enable`. > * For upgrades, GNOME Software shows an info-bar with the same > question if no status is stored in `/etc/fedora-thirdparty.conf` > > == Feedback == > > > == Benefit to Fedora == > > The main benefit of this proposal is the removal of the state where > the user has opted in to third party repositories but they are not > actually enabled. PackageKit supports the > enabled_metadata=1 key in a repository file, which allows > applications to be searched in this state, but this is not supported > by DNF. > > The new method is also easily extensible to Flatpaks, where there also > no equivalent to enabled_metadata=1, even in GNOME > Software. > > == Scope == > * Proposal owners: Create and test proposed > fedora-third-party package. Implement the graphical > controls for this in GNOME Software and gnome-initial-setup. > * Release engineering: [https://pagure.io/releng/issue/10186 #10186] > No changes are required. > * Policies and guidelines: Third-party Software guidelines will need > minor changes to remove references to `enabled_metadata=1`. Pending > finalization of technical implementation. > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: No real alignment > > == Upgrade/compatibility impact == > Because the "opt-in" status to 3rd party software is currently > represented by whether fedora-workstation-repositories is installed, > and because fedora-workstation-repositories will become an > installed-by-default package, users will need to opt-in again. > > They can do this either by responding in the infobar that will be > displayed in GNOME Software, or by running fedora-third-party > enable on the command line. > > == How To Test == > * A fresh install of Fedora Workstation where the user ''does not'' > opt-in should have all repositories disabled. > * A fresh install of Fedora Workstation where the user ''does'' opt-in > should have all 3rd-party repositories enabled. > * On an upgrade from F34, if the user opts-out, the enablement status > of third-party repositories should be ''unchanged'' (try enabling one > before the upgrade) > * On an upgrade from F35, if the user opts-in, all 3rd party > repositories should be enabled. > > == User Experience == > The user will get less confusing behavior around third-party > repositories - enabled will mean enabled and will take affect no > matter how they are installing packages. > > See https://hackmd.io/@owtaylor/fedora-third-party-repos for a > detailed description of the *current* experience along with some notes > about the desired behavior. > > == Dependencies == > The changes are limited to the following packages: > > * The new `fedora-third-party` package > * `fedora-workstation-repositories` > * `gnome-software` > * `gnome-initial-setup` > * `fedora-release-workstation` and other release packages that will > now require fedora-workstation-repositories. > > This change proposal is a prerequisite for a separate change proposal > to add a filtered view of Flathub to the set of third-party > repositories. > > == Contingency Plan == > * Contingency mechanism: revert all changes back to the F34 state. > (This will also require reverting the filtered-view-of-Flathub > change.) > * Contingency deadline: beta freeze > * Blocks release? Yes - this needs to be finished or reverted > > == Documentation == > '''This should be a link to a man page for the `fedora-third-party` tool''' > > == Release Notes == > Fedora optionally provides repository definitions allowing users to > install certain third-party software. This used to be done as a > two-step process where when the user asked to enable third-party > repositories, the repository definitions were installed but not > actually enabled, and they had to be
Re: F35 Change: Third-party Software Mechanism (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 6:50 AM Lars Seipel wrote: > >[Find out > >more...](https://fedoraproject.org/wiki/Workstation/Third_Party_Software_Repositories) > >* If the user leaves the box checked, GNOME Initial setup runs > >`fedora-third-party enable`. > > Leaves the box checked? Either I'm misunderstanding or this contradicts > the remaining text which talks about "opt-in". Thanks for noticing the discrepancy! The current mockup for how the page in GNOME Initial Setup should look is at the top of: https://hackmd.io/@owtaylor/fedora-third-party-repos and is in-fact a classic opt-in. (*) The mockup tries to reduce the risk of an inexperienced user being confused by terms like "third party" and "repository" by mentioning specific software.I'll look at embedding that in the change proposal and will make sure that the text is consistent. - Owen (*) The text of the Third-Party Repository policy is "the user must explicitly enable third-party repositories to install from them" - I don't think a checked-by-default box would be in agreement with that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 7:43 AM Ian McInerney wrote: > > On Tue, Jun 29, 2021 at 9:26 PM Ben Cotton wrote: >> >> https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications >> >> == Summary == >> Enabling third-party repositories will now create a Flathub remote >> that is a filtered view of Flathub. >> >> >> == Detailed Description == >> 'Note that this proposal is about user experience, procedures, and >> technology - the high-level concept has already been discussed and >> approved by the Fedora Council and FESCO.' >> >> Enabling third-party repositories will now create a Flathub remote >> that is a filtered view of Flathub. This means that applications on >> Flathub that have been explicitly approved (by a new process proposed >> here) will be available in GNOME Software and on the >> flatpak command line. If the user follows following the >> instructions on https://flatpak.org/setup/Fedora/, then the filter is >> removed, and the user gets a full view of Flathub. >> >> Roughly speaking, the criteria for including software is a) will not >> cause legal or other problems for Fedora to point to b) does not >> overlap Fedora Flatpaks or software in Fedora that could easily be >> made into a Flatpak c) works reasonably well. For Fedora 35, We expect >> to include all software from the top 50 most popular applications on >> Flathub that meet these criteria plus selected other software of >> interest to the Fedora target audience - Fedora community members are >> welcome to propose additions. > > > Does this mean that FESCO is now forcing Fedora packagers to maintain Fedora > Flatpaks and respond to their related issues when many of them seem to be > created without the packagers' knowledge/consent, and there is no > documentation in the packaging guidelines/wiki about how to actually do > anything for them, or information about where the manifests for them actually > live? > Of course not. This is a criteria for what we permit through the filter from Flathub. The idea is that nothing we offer from Flathub should be possible to ship in Fedora itself. That is, it's truly only possible to be available as a third-party app. Basically, if something is available in Fedora, it *cannot* be available through Flathub by default. -- 真実はいつも一つ！/ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On Tue, Jun 29, 2021 at 9:26 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications > > == Summary == > Enabling third-party repositories will now create a Flathub remote > that is a filtered view of Flathub. > > > == Detailed Description == > 'Note that this proposal is about user experience, procedures, and > technology - the high-level concept has already been discussed and > approved by the Fedora Council and FESCO.' > > Enabling third-party repositories will now create a Flathub remote > that is a filtered view of Flathub. This means that applications on > Flathub that have been explicitly approved (by a new process proposed > here) will be available in GNOME Software and on the > flatpak command line. If the user follows following the > instructions on https://flatpak.org/setup/Fedora/, then the filter is > removed, and the user gets a full view of Flathub. > > Roughly speaking, the criteria for including software is a) will not > cause legal or other problems for Fedora to point to b) does not > overlap Fedora Flatpaks or software in Fedora that could easily be > made into a Flatpak c) works reasonably well. For Fedora 35, We expect > to include all software from the top 50 most popular applications on > Flathub that meet these criteria plus selected other software of > interest to the Fedora target audience - Fedora community members are > welcome to propose additions. > Does this mean that FESCO is now forcing Fedora packagers to maintain Fedora Flatpaks and respond to their related issues when many of them seem to be created without the packagers' knowledge/consent, and there is no documentation in the packaging guidelines/wiki about how to actually do anything for them, or information about where the manifests for them actually live? -Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 12:46:59PM +0200, Miroslav Suchý wrote:
> Dne 30. 06. 21 v 12:29 Zbigniew Jędrzejewski-Szmek napsal(a):
> >The OP talks exclusively about "RAM". And I think RAM is what we need
>
> From:
>
> https://build.opensuse.org/package/view_file/openSUSE:Factory/memory-constraints/memory-constraints.macros?expand=1
>
> max_swapmem=$(awk '/SwapTotal/ { print $2 }' /proc/meminfo) \
> max_jobs="$((($max_physmem + $max_swapmem) / ($mem_per_process * 1000)))" \
Oops. Yeah, I don't think this implementation much sense ;(
> >to look at: even if there is bountiful swap, the build would be quite
> >slow if it was used to any significant degree. So we're probably
> >better of limiting parallelism rather than using all that swap.
>
> I agree.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
NeuroFedora package review swap: python-lfpykit
Hi folks, One of our NeuroFedora packages has added a new dep in its new version, which FTBFS as a result. Would someone like to swap reviews please? 1976640 – Review Request: python-lfpykit - Electrostatic models for multicompartment neuron models https://bugzilla.redhat.com/show_bug.cgi?id=1976640 Unofficial reviews from folks looking to practice their reviewing skills (to get sponsored to the package maintainer group perhaps) are most welcome. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On 30/06/2021 12:57, Miro Hrončok wrote: Similar situation as with the Fedora Project, I must say. Yes. Fedora's infra belongs to Red Hat, Inc. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On 30. 06. 21 12:41, Vitaly Zaitsev via devel wrote: I don't trust Flathub at all, because they don't want to register a non-profit organization. They can easily sell their business like FreeNode did recently. Similar situation as with the Fedora Project, I must say. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Third-party Software Mechanism (System-Wide Change proposal)
Dne 29. 06. 21 v 22:24 Ben Cotton napsal(a): ''Note that this proposal is about a change to how third-party repositories are enabled, not about including anything new in Fedora.' I completely missed the "Third party repos" thing. I had to google it. To save you some time: https://fedoramagazine.org/third-party-repositories-fedora/ Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Third-party Software Mechanism (System-Wide Change proposal)
On Tue, Jun 29, 2021 at 04:24:58PM -0400, Ben Cotton wrote: * We add a new page to GNOME Initial Setup that asks a single question, *along the lines of*: '''Enable Third Party Software repositories?''' ☑ Access additional software from selected third party sources. Some of this software is proprietary and therefore has restrictions on use, sharing, and access to source code. [Find out more...](https://fedoraproject.org/wiki/Workstation/Third_Party_Software_Repositories) * If the user leaves the box checked, GNOME Initial setup runs `fedora-third-party enable`. Leaves the box checked? Either I'm misunderstanding or this contradicts the remaining text which talks about "opt-in". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
Dne 30. 06. 21 v 12:29 Zbigniew Jędrzejewski-Szmek napsal(a):
The OP talks exclusively about "RAM". And I think RAM is what we need
From:
https://build.opensuse.org/package/view_file/openSUSE:Factory/memory-constraints/memory-constraints.macros?expand=1
max_swapmem=$(awk '/SwapTotal/ { print $2 }' /proc/meminfo) \
max_jobs="$((($max_physmem + $max_swapmem) / ($mem_per_process * 1000)))" \
to look at: even if there is bountiful swap, the build would be quite
slow if it was used to any significant degree. So we're probably
better of limiting parallelism rather than using all that swap.
I agree.
Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
rubygem-websocket-driver package license change
Hello, License changed from "MIT" to "ASL 2.0" for rubygem-websocket-driver package. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
On 29/06/2021 22:25, Ben Cotton wrote: Enabling third-party repositories will now create a Flathub remote that is a filtered view of Flathub. I don't trust Flathub at all, because they don't want to register a non-profit organization. They can easily sell their business like FreeNode did recently. Flathub relies on upstreams, not professional maintainers. Most of upstream developers don't know how to package software properly. They bundle lots of libraries, don't use C/C++ build hardening flags, etc. A lot of applications from Flathub uses --filesystem=host or --filesystem=home, which means they don't use Flatpak isolation at all. Due to the bundling of a large number of libraries, some applications have critical vulnerabilities with assigned CVE numbers: CVE-2020-12284, CVE-2019-17498, CVE-2018-11235, CVE-2018-17456, CVE-2017-9780. Roughly speaking, the criteria for including software is a) will not cause legal or other problems for Fedora to point to b) does not overlap Fedora Flatpaks or software in Fedora that could easily be made into a Flatpak c) works reasonably well. Should be added also: d) doesn't exists in Fedora RPM repositories. Fedora users who opt-in to third-party software repositories will have immediate access to more software out-of-the-box. Fedora Silverblue must have its own Flatpaks and do not rely on third-party repositories. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1977713] New: perl-Data-Dumper-2.182 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1977713 Bug ID: 1977713 Summary: perl-Data-Dumper-2.182 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Data-Dumper Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 2.182 Current version/release in rawhide: 2.181-1.fc35 URL: http://search.cpan.org/dist/Data-Dumper/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2760/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 12:08:44PM +0200, Miroslav Suchý wrote: > Dne 29. 06. 21 v 22:25 Ben Cotton napsal(a): > >When this proposal is implemented, they can instead declaratively > >specify the amount of RAM needed per build thread, e.g. > > > > %limit_build -m 8192 > > > >for declaring a build thread should be allocated 8GB of RAM. > > Do I understand it correctly that semantics will be: One process > will consume 8GB ram. And because we have only 16 GB RAM on this > host we will limit smp flag to 2 despite having 4 cores. Right? > > FYI Copr utilize heavily tmpfs plugin > > http://miroslav.suchy.cz/blog/archives/2015/05/28/increase_mock_performance_-_build_packages_in_memory/index.html > > we have ~100 GB swap which we use for tmpfs. > > This can provide misleading numbers for SwapTotal. The OP talks exclusively about "RAM". And I think RAM is what we need to look at: even if there is bountiful swap, the build would be quite slow if it was used to any significant degree. So we're probably better of limiting parallelism rather than using all that swap. (Note that this proposal is about limiting parallelism, i.e. tweaking an optimization. If instead the macro was about "what are the minimum memory reqs below which we will reject a build", the rules would be completely different and we should include swap in the calculation, because it's better to build slowly than not at all.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
Dne 29. 06. 21 v 22:25 Ben Cotton napsal(a): When this proposal is implemented, they can instead declaratively specify the amount of RAM needed per build thread, e.g. %limit_build -m 8192 for declaring a build thread should be allocated 8GB of RAM. Do I understand it correctly that semantics will be: One process will consume 8GB ram. And because we have only 16 GB RAM on this host we will limit smp flag to 2 despite having 4 cores. Right? FYI Copr utilize heavily tmpfs plugin http://miroslav.suchy.cz/blog/archives/2015/05/28/increase_mock_performance_-_build_packages_in_memory/index.html we have ~100 GB swap which we use for tmpfs. This can provide misleading numbers for SwapTotal. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On Tue, Jun 29, 2021 at 3:38 PM Tomas Tomecek wrote: > * Can you imagine maintaining Fedora's 30k+ packages in a single repo? > Without some git-fetch magic it would be unbearable to perform a > git-pull. I cannot imagine *not* doing this, maintaining a distro and preserving any sanity in the process. I cannot imagine having all your updates based on a moving target. I cannot imagine why have side-tags, why decouple building from committing, why make mass-rebuilds a big thing instead of a topical branch they are and why make composes a big thing and not just a commit in a repo of 'the state of Fedora'. Composing this email takes about the same time (3m) as cloning [1], the second largest package collection on repology, at full depth. The tip of it, which the users actually need to download when they update, weights <25M. --depth=1 clone takes 10 seconds. [1] time git clone g...@github.com:NixOS/nixpkgs ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: List of long term FTBFS packages to be retired in August
On Wed, Jun 30, 2021 at 01:36:40AM +0200, Miro Hrončok wrote: > On 30. 06. 21 1:32, Miro Hrončok wrote: > >Dear maintainers. > > > >Based on the current fail to build from source policy, the following packages > >will be retired from Fedora 35 approximately one week before > >branching (August 2021). > > > >Policy: > >https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ > > > > > >The packages in rawhide were not successfully built at least since Fedora 32. > > > >This report is based on dist tags. > > > >Packages collected via: > >https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb > > > > > >If you see a package that was built, please let me know. > >If you see a package that should be exempted from the process, > >please let me know and we can work together to get a FESCo > >approval for that. > > > >If you see a package that can be rebuilt, please do so. > > > > Package (co)maintainers Latest > > build > > > >cardpeek kalev Fedora 32 > > Has ASSIGNED bugzillas since Fedora 33: > > https://bugzilla.redhat.com/show_bug.cgi?id=1863309 > https://bugzilla.redhat.com/show_bug.cgi?id=1923409 > > >percona-xtrabackup slaanesh, slankes Fedora 32 > > Has a MODIFIED bugzilla since Fedora 33: > > https://bugzilla.redhat.com/show_bug.cgi?id=1865206 > > >php-opencloud-openstack lcts Fedora 32 > > Has CLOSED (but not fixed) and NEW bugzillas since Fedora 33: > > https://bugzilla.redhat.com/show_bug.cgi?id=1865221 > https://bugzilla.redhat.com/show_bug.cgi?id=1923428 > https://bugzilla.redhat.com/show_bug.cgi?id=1977297 > > >proxyfuzz psklenar Fedora 32 > > Had no bugzillas because it failed to build even the SRPM. > I've opened one quite recently: > > https://bugzilla.redhat.com/show_bug.cgi?id=1974327 > > >radamsa huzaifas, mrniranjan Fedora 32 > > Has no bugzillas, the mass rebuilds builds never finished (they hang for days) It'd be sad to lose radamsa from the distro. I pushed a snapshot build. > >sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora 31 > > tuxbrewr > > Fails to install, fails to build since Fedora 32, was exempted from > this policy last time with a promise of a fix. > > Has many bugzillas > https://bugzilla.redhat.com/buglist.cgi?component=sugar-view-slides=Fedora > > >zram pbrobinson Fedora 32 > > This might not actually be a FTBFS, but simply a package that has > not been built in 1.5 years. > It has a noautobuild file with: > > > it's a couple of bash scripts, no need for rebuilds > > I tend to disagree with that statement. The rebuilds are useful for: > > - new possible dependency generators > - new possible buildroot policy scripts > - new RPM/buildsystem features (compression, content signatures, etc.) > > I think it's worth rebuilding it at least once in a year. It's a case of "save a little bit of work for the machine by generating more work for the humans" ;) Yeah, a bad trade-off. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20210630.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20210629.0): ID: 919343 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/919343 ID: 919351 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/919351 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Tue, Jun 29, 2021 at 04:25:13PM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros > > == Summary == > Introduce macros, similar to openSUSE's > [https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints > memory-constraints]), for optionally limiting build parallelism for > build-time memory-bound packages > > == Owner == > * Name: [[User:salimma|Michel Alexandre Salim]] > * Email: michel AT michel-slm DOT name > > > == Detailed Description == > Some source packages have a memory usage per build thread higher than > the RAM:CPU ratio available in some of our builders. Further, this > ratio can be different for different build server on different > architectures. > > At the moment, such packages > ([https://src.fedoraproject.org/rpms/ceph/blob/d7454e4e0a98208dc569553b901a49733beff6b3/f/ceph.spec#_1269-1390 > ceph], > [https://src.fedoraproject.org/rpms/chromium/blob/baaf27b384295d6288ef367dd108ce9874543f2d/f/chromium.spec#_3-14 > chromium], > [https://src.fedoraproject.org/rpms/mcrouter/blob/a0f7ecad2ccc51c4214646b082358745c7882c86/f/mcrouter.spec#_68-82 > mcrouter]) have to implement their own logic for determining the safe > amount of parallelism, and redefine `_smp_build_ncpus`. > > When this proposal is implemented, they can instead declaratively > specify the amount of RAM needed per build thread, e.g. > > %limit_build -m 8192 > > for declaring a build thread should be allocated 8GB of RAM. > > Since Koji supports > [https://docs.pagure.org/koji/release_notes/release_notes_1.18/#system-changes > setting default values for macros], there will be a macro for the > default memory limit (name TBD) that, if set, will be used to cap > `_smp_build_ncpus` unless overridden by `%limit_build -m`. Is the default required? Wouldn't it be enough to make '%limit_build -m 8192' *lower* _smp_build_ncpus if it detects that not enough memory is present? I.e. keep status quo by default, optionally lower (and only lower) _smp_build_ncpus when '%limit_build -m …' is used? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On Tue, Jun 29, 2021 at 03:13:10PM +0200, Tomas Tomecek wrote: > On Thu, Jun 24, 2021 at 8:09 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Thu, Jun 24, 2021 at 03:48:54PM +0200, Tomas Tomecek wrote: > > > On Thu, Jun 24, 2021 at 12:41 PM Miro Hrončok wrote: > > > > > > > > On 24. 06. 21 11:16, Tomas Tomecek wrote: > > > > > ## Choosing git forge to host source-git repositories > > > > > We need to find a home for all the source-git repositories. This is > > > > > actually a really hard task because we have many options (github.com, > > > > > gitlab.com, pagure.io, src.fedoraproject.org, something custom or > > > > > on-premise) and different expectations: some projects already have > > > > > repos set up on different platforms while Pagure is the primary forge > > > > > now. Since the CPE team is investigating GitLab as a forge, it's even > > > > > harder for us to figure out the primary forge. We may end up > > > > > supporting both actually: pagure.io and gitlab.com. What are your > > > > > thoughts on this topic? Would you prefer pagure.io or gitlab.com > > > > > More info: > > > > > * https://pagure.io/fedora-source-git/sig/issue/1 > > > > > * https://pagure.io/fedora-source-git/sig/issue/7 > > > > > > > > I would expect that since the soruce git is just an intermediate thing, > > > > supporting "any forge" is nice to have, but hard. I'd start with some > > > > common > > > > options (Pagure + 1 other) and see where you'll get. > > > > > > Yep, that's exactly what I'd like us to do. As soon as we have the > > > service which accepts processes events up and running, it shouldn't be > > > that hard to teach it new fedora-messaging messages or webhook > > > payloads. > > > > > > > > ## High-level workflow proposal up for review > > > > > Hunor proposed a high-level workflow linked below and I strongly > > > > > recommend reading it. We have also started discussing many details in > > > > > the process, such as getting archives: should we generate one from the > > > > > source-git repo or use the official release archive from upstream? > > > > > > > > One thing to consider is that the upstream tarballs might be > > > > cryptographically > > > > signed and packages should verify the signature in %prep. > > > > > > This is a very good point - in such a case, we should always pull the > > > official upstream tarball instead of generating a new one downstream. > > > > Hmm, but how would that work? I thought that the whole point of > > source-git is to build from a commit that contains some upstream > > version + downstream patches + downstream distro config like the spec file, > > and that the build step of applying downstream patches just doesn't exist. > > If you reuse the upstream tarball, then by necessity those downstream > > patches need to be serialized and applied on top like in dist-git. So > > you lose the property that the checkout from version control is *the* > > source you build, but you also lose the property that the source you > > build is what was signed (since patches are applied). > > What you just described I understand as an (upstream) maintenance > branch and is not what we call source-git. It's an "upstream maintenance branch" PLUS the .spec bits that specify how to build a package. > Our definition of source-git is: > * upstream release tarball > * downstream code changes applied as patches during %prep > * additional configs for sake of building and testing But that describes dist-git *exactly*. Where is the difference? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Rebase firewalld to upstream v1.0.0 (System-Wide Change proposal)
On Mon, Jun 28, 2021 at 12:57:46PM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/firewalld-1.0.0 > > == Summary == > Firewalld upstream is about to release v1.0.0. As indicated by the > major version bump this includes behavioral changes. A major new version sounds good… New features look nice… but can can we please stop using the term "rebase"? The Change page is directed at the wider community, and "package rebase" is an obscure packaging term that is likely just confusing to users. Also, it doesn't really make sense anymore, for a great majority of packages, because we don't have dozens of patches and non-upstreamable tweaks in most packages. So there is no "rebase" in the update. And we have an "upstream first" policy too, so there is no need to underline the fact that it's an "upstream version". There is and should not be any other version. Just say: Update firewalld to version 1.0.0 Zbyszek > > == Owner == > * Name: [[User:erig0| Eric Garver]] > * Email: egar...@redhat.com > > > == Detailed Description == > Firewalld v1.0.0 includes breaking changes meant to improve the > overall health of the project. The majority of the changes are > centered around improving and strengthening the zone concept. All > breaking changes are detailed in depth in the > [https://firewalld.org/2021/06/the-upcoming-1-0-0 upstream blog]. > > Major changes: > > * Reduced dependencies > * Intra-zone forwarding by default > * NAT rules moved to inet family (reduced rule set) > * Default target is now similar to reject > * ICMP blocks and block inversion only apply to input, not forward > * tftp-client service has been removed > * iptables backend is deprecated > * Direct interface is deprecated > * CleanupModulesOnExit defaults to no (kernel modules not unloaded) > > > == Benefit to Fedora == > The major benefit to Fedora is more predictability in the stock > firewall. In particular, "Default target is now similar to reject" > addresses many subtle issues encountered by users. "NAT rules moved to > inet family" also significantly reduces the rule set size for users of > `ipset`s. > > == Scope == > * Proposal owners: Changes are isolated to firewalld, but given > firewalld is core a System Wide Change is being filed. > * Other developers: None. Isolated change. > > * Release engineering: > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: > > > == Upgrade/compatibility impact == > * Most configurations will migrate. No intervention required. > ** Exceptions > *** configurations that utilize `tftp-client` service will have > firewalld start in `failed` state because the service has been > removed. As noted in the upstream blog this service has ''never'' > worked properly. > * Zones that users have not modified will now have intra-zone > forwarding enabled. > ** for this to occur the user must ''not'' have added an interface, > service, port, etc. to the zone > ** minimal concern because this also means the zone was not in use, > the exception being an unmodified default zone, e.g. > `FedoraWorkstation` > > == How To Test == > Testing for this rebase should revolve around integrations. > > * libvirt > ** verify VMs still have network access > * podman > ** verify containers still have network access > ** verify forwarding ports via podman still works > * NetworkManager > ** verify connection sharing still works > > == User Experience == > N/A > > == Dependencies == > firewalld has yet to release v1.0.0. It is expected in early July. > > == Contingency Plan == > * Contingency mechanism: revert package to v0.9.z (what f34 uses) > * Contingency deadline: July 27, 2021 > * Blocks release? No > > == Documentation == > https://firewalld.org/2021/06/the-upcoming-1-0-0 > > == Release Notes == > firewalld has been rebased to v1.0.0. This includes some breaking > changes that may affect users. > > Major changes: > > * Reduced dependencies > * Intra-zone forwarding by default > * NAT rules moved to inet family (reduced rule set) > * Default target is now similar to reject > * ICMP blocks and block inversion only apply to input, not forward > * tftp-client service has been removed > * iptables backend is deprecated > * Direct interface is deprecated > * CleanupModulesOnExit defaults to no (kernel modules not unloaded) > > Full details on the upstream blog: > https://firewalld.org/2021/06/the-upcoming-1-0-0 > > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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: >
Re: Fedora Source-git SIG report #1 (June 2021)
This is a super update report, thanks for sharing CPE have activated an open source license for Gitlab to trial out some of the workflows and features. This is their top level SaaS offering which they grant to all open source projects so it has all the features we would need for testing. Stephen (on CC) and I have admin access. I'd love to grant folks in the SIG access, if someone can ping me a list of emails that are associated with a gitlab.com account (you need to register!) I can make that happen. Leigh On Thu 24 Jun 2021, 10:17 Tomas Tomecek, wrote: > Greetings from the Fedora source-git SIG! We are planning to start > publishing reports of what we are working on so everyone can easily > pay attention and get involved if interested. If you have any ideas, > comments or requests, don’t be shy and let us know :) > > Here’s a short list of things which we are working on. > > ## Choosing git forge to host source-git repositories > We need to find a home for all the source-git repositories. This is > actually a really hard task because we have many options (github.com, > gitlab.com, pagure.io, src.fedoraproject.org, something custom or > on-premise) and different expectations: some projects already have > repos set up on different platforms while Pagure is the primary forge > now. Since the CPE team is investigating GitLab as a forge, it's even > harder for us to figure out the primary forge. We may end up > supporting both actually: pagure.io and gitlab.com. What are your > thoughts on this topic? Would you prefer pagure.io or gitlab.com > More info: > * https://pagure.io/fedora-source-git/sig/issue/1 > * https://pagure.io/fedora-source-git/sig/issue/7 > > ## High-level workflow proposal up for review > Hunor proposed a high-level workflow linked below and I strongly > recommend reading it. We have also started discussing many details in > the process, such as getting archives: should we generate one from the > source-git repo or use the official release archive from upstream? > > Another big topic in terms of workflows are rebases (= updates to the > latest upstream release, which are very common in Rawhide). Rebases > are straightforward in dist-git, but when your source-git repo has > complete upstream git history, they are no longer trivial, especially > if one wants to get a review of a rebase. > > More info: > * https://pagure.io/fedora-source-git/sig/issue/2 > * Workflow proposal: > https://pagure.io/fedora-source-git/docs/pull-request/2 > * > https://pagure.io/fedora-source-git/docs/blob/main/f/resources/CommitRules.pdf > * https://pagure.io/fedora-source-git/sig/issue/8 > > ## Tooling > Packit is the tooling which will be used to work with source-git > repos. No surprise there I assume :D > * https://packit.dev/ > > We've done a lot of work here lately, mainly to polish the process of > creating source-git repos and doing updates of dist-git repositories > based on the source-git content. > * https://packit.dev/docs/source-git/work-with-source-git/ > * https://github.com/packit/packit/releases > > ## Interested? > We meet biweekly on Wednesdays via gmeet, 2:30 - 3:30 UTC, next one is > scheduled for July 7th. > * https://calendar.fedoraproject.org/SIGs/2021/7/5/#m9982 > > Everyone is welcome to join the SIG or provide any feedback on the > issues and PRs above. > > You can always find the latest information over here: > * https://fedoraproject.org/wiki/SIGs/Source-git > * https://pagure.io/fedora-source-git/sig/issues > > I'd like to thank all the SIG members for being so active, so happy to > work with all of you! > > Cheers, > Tomas > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Please Review: 4817 crypt pw bypass
https://github.com/389ds/389-ds-base/pull/4819 -- Sincerely, William Brown Senior Software Engineer, Identity and Access Management SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Need assistance to build Blender
It seems working on aarch64 version of Fedora 32 and 33 which lacks usd
dependency.
https://copr.fedorainfracloud.org/coprs/luya/blender-egl/build/2305553/
Maybe usd needs some trimming.
On 2021-06-24 10:04 a.m., Benjamin Beasley wrote:
The “pyconfig.h” header lives in a python-version-specific subdirectory. Some
of the compiler invocations earlier in the build log contain
“-I/usr/include/python3.10”, but the one that is failing does not.
I haven’t tried it, but I would guess that something like the following would
resolve the problem. The libraries may or may not be necessary—I didn’t take
time to investigate.
--- blender-2.93.0-original/source/blender/io/usd/CMakeLists.txt
2021-04-21 10:23:41.0 -0400
+++ blender-2.93.0/source/blender/io/usd/CMakeLists.txt 2021-06-24
13:02:05.568490263 -0400
@@ -53,6 +53,7 @@
${USD_INCLUDE_DIRS}
${BOOST_INCLUDE_DIR}
${TBB_INCLUDE_DIR}
+ ${PYTHON_INCLUDE_DIRS}
)
set(SRC
@@ -86,6 +87,8 @@
list(APPEND LIB
${BOOST_LIBRARIES}
+ ${PYTHON_LINKFLAGS}
+ ${PYTHON_LIBRARIES}
)
list(APPEND LIB
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210630.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210629.0): ID: 919327 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/919327 ID: 919335 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/919335 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1977590] New: perl-Inline-Python-0.56-16.fc35 FTBFS: all tests fail: Parse errors: Bad plan
https://bugzilla.redhat.com/show_bug.cgi?id=1977590 Bug ID: 1977590 Summary: perl-Inline-Python-0.56-16.fc35 FTBFS: all tests fail: Parse errors: Bad plan Product: Fedora Version: rawhide URL: https://koschei.fedoraproject.org/package/perl-Inline- Python?collection=f35 Status: NEW Component: perl-Inline-Python Assignee: j.k.nil...@usit.uio.no Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: j.k.nil...@usit.uio.no, perl-devel@lists.fedoraproject.org Blocks: 1927309 (F35FTBFS,RAWHIDEFTBFS) Target Milestone: --- Classification: Fedora perl-Inline-Python-0.56-16.fc35 fails to build in Fedora 35 bacause all tests file like this: + /usr/bin/perl Makefile.PL INSTALLDIRS=vendor 'OPTIMIZE=-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection' NO_PACKLIST=1 Found these python executables on your PATH: 1. /usr/bin/python3 Using the only python executable I could find Set the INLINE_PYTHON_EXECUTABLE environment variable to the full path to your python executable to override this selection. Using /usr/bin/python3 :1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives :1: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead :1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives :1: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead :1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives :1: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead :1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives :1: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead :1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives :1: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead This python's configuration files are messed up. You'll have have to answer the questions yourself. Here is what Python said: Extra Libs: -lcrypt -ldl -lutil -lm Python Library: /usr/lib64/python3.10/config-3.10-aarch64-linux-gnu/libpython3.10.a Include Path:/usr/include/python3.10 1. LIBS option. I need to know what extra libraries, if any, are required by this build of python. I recommend this: -lcrypt -ldl -lutil -lm Enter extra libraries (e.g. -lfoo -lbar) [-lcrypt -ldl -lutil -lm] -lcrypt -ldl -lutil -lm 2. LIBRARY option. The location of the python library. Inline::Python needs to link against it to use Python. Here are the libraries I know about: 1) /usr/lib64/libpython3.10.so 2) /usr/lib64/libpython3.so Which? Or enter another. [1] 1 3. INCLUDE option. The location of the python include files. Inline::Python needs these to compile. Here are the locations I know about: 1) /usr/include/python3.10 Which? Or enter another. [1] 1 Using These Settings: Extra Libs: -lcrypt -ldl -lutil -lm Python Lib: -L/usr/lib64 -lpython3.10 Includes:-I/usr/include/python3.10 Extra Flags: none (perl Makefile.PL --help for details) [...] + make test "/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- Python.bs blib/arch/auto/Inline/Python/Python.bs 644 PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/00init.t ok Failed to autogenerate /builddir/build/BUILD/Inline-Python-0.56/blib_test/config-aarch64-linux-thread-multi-5.034000. at t/01testpl.t line 6. BEGIN failed--compilation aborted at t/01testpl.t line 6. t/01testpl.t .. Dubious, test returned 255 (wstat 65280, 0xff00) [...] Test Summary Report --- t/01testpl.t(Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 8 tests but ran 0. [...] A difference between passing and failing build root is at
Re: F35 Change: Golang 1.17 (System-Wide Change proposal)
For context: https://groups.google.com/g/golang-dev/c/hGwvCceDr14/m/wbyNWwgNBgAJ On Tue, Jun 29, 2021 at 9:02 PM Alejandro Sáez Morollón wrote: > > According to upstream, they are not going to deprecate GOPATH yet in this > version. > > I built etcd with 1.17beta1 and everything went fine. > > > On 29 Jun 2021, at 20:42, Robert-André Mauchin wrote: > > > > On 6/28/21 6:57 PM, Ben Cotton wrote: > >> https://fedoraproject.org/wiki/Changes/golang1.17 > >> == Summary == > >> Rebase of Golang package to upcoming version 1.17 in Fedora 35, > >> including the rebuild of all dependent packages(the pre-release > >> version of Go will be used for the rebuild if released version will > >> not be available at the time of the mass rebuild). > >> == Owner == > >> * Name: [[User:alexsaezm| Alejandro Sáez Morollón]], [[User:Jcajka| > >> Jakub Čajka]] > >> * Email: a...@redhat.com, jca...@redhat.com > > > > Won't we have a problem since 1.17 is deprecating the gopath way to use Go > > modules instead. We didn't manage to port our macros to Go modules due to > > Nicolas Mailhot being MIA since last year, and even if we manage that, I > > personally won't have the time to rebuild the entire ecosystem. I'm already > > have problems dealing with all the updates, while taking care of the > > Package Reviews too. > > Won't this break our entire Go ecosystem? > > > > Best regards, > > > > Robert-André > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] 389 DS nightly 2021-06-30 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/06/30/report-389-ds-base-2.0.6-20210630git6b10f1795.fc34.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
