[Bug 1976426] perl-Data-Dump-1.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1976426 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Data-Dump-1.24 is |perl-Data-Dump-1.25 is |available |available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 1.25 Current version/release in rawhide: 1.23-17.fc35 URL: http://search.cpan.org/dist/Data-Dump/ 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/6648/ -- 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 1976426] New: perl-Data-Dump-1.24 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1976426 Bug ID: 1976426 Summary: perl-Data-Dump-1.24 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Data-Dump Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.24 Current version/release in rawhide: 1.23-17.fc35 URL: http://search.cpan.org/dist/Data-Dump/ 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/6648/ -- 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a6e2c9bc8c radare2-5.3.1-1.el8 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0209079fce aom-3.1.1-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-698907eb45 quassel-0.13.1-8.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing openbgpd-7.1-1.el8 Details about builds: openbgpd-7.1-1.el8 (FEDORA-EPEL-2021-d70d94d1f8) OpenBGPD Routing Daemon Update Information: OpenBGPD 7.1 This release includes the following changes to the previous release:* OpenBSD 6.9 errata 009 During `bgpd(8)` config reloads prefixes of the wrong address family could leak to peers resulting in session resets.* Support for RFC 7313 - Enhanced Route Refresh Disabled by default, to enable use `announce enhanced refresh yes`.* Improve output of Adj-RIB-Out by updating nexthop and `ASPATH` before adding the prefix to the RIB. This improves `bgpctl show rib out` output.* Add command line option to show the version ChangeLog: * Fri Jun 25 2021 Robert Scheck 7.1-1 - Upgrade to 7.1 (#1976160) References: [ 1 ] Bug #1976160 - openbgpd-7.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1976160 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 29 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef openjpeg2-2.3.1-11.el7 29 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-9eaea6f65c audacious-plugins-4.0.5-4.el7 fluidsynth-2.1.8-4.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c4678a5e4b radare2-5.3.1-1.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-49226a1ff0 aom-3.1.1-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-92a8baa028 tor-0.3.5.15-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d4d814b358 quassel-0.12.5-2.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1ad14f84b0 ansible-2.9.23-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing openbgpd-7.1-1.el7 Details about builds: openbgpd-7.1-1.el7 (FEDORA-EPEL-2021-f2f7cc64c9) OpenBGPD Routing Daemon Update Information: OpenBGPD 7.1 This release includes the following changes to the previous release:* OpenBSD 6.9 errata 009 During `bgpd(8)` config reloads prefixes of the wrong address family could leak to peers resulting in session resets.* Support for RFC 7313 - Enhanced Route Refresh Disabled by default, to enable use `announce enhanced refresh yes`.* Improve output of Adj-RIB-Out by updating nexthop and `ASPATH` before adding the prefix to the RIB. This improves `bgpctl show rib out` output.* Add command line option to show the version ChangeLog: * Fri Jun 25 2021 Robert Scheck 7.1-1 - Upgrade to 7.1 (#1976160) References: [ 1 ] Bug #1976160 - openbgpd-7.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1976160 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1972385] perl-POE-Component-IRC-6.93 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1972385 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-POE-Component-IRC-6.93 |perl-POE-Component-IRC-6.93 |-1.fc35 |-1.fc35 |perl-POE-Component-IRC-6.93 |perl-POE-Component-IRC-6.93 |-1.fc34 |-1.fc34 ||perl-POE-Component-IRC-6.93 ||-1.fc33 --- Comment #7 from Fedora Update System --- FEDORA-2021-e69f1c2e75 has been pushed to the Fedora 33 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 1972385] perl-POE-Component-IRC-6.93 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1972385 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-POE-Component-IRC-6.93 |perl-POE-Component-IRC-6.93 |-1.fc35 |-1.fc35 ||perl-POE-Component-IRC-6.93 ||-1.fc34 Resolution|--- |ERRATA Last Closed||2021-06-26 01:00:59 --- Comment #6 from Fedora Update System --- FEDORA-2021-777c04ebc1 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
Re: RFC: Banning bots from submitting automated koji builds
On Fri, 2021-06-25 at 15:42 -0400, Daniel Walsh wrote: > > And sometimes this breakage is caused by other parts of the system. For > example a kernel update caused breakage in Podman when it suddenly > enabled overlay mounts, which no one had tried. We quickly fixed the > container-selinux package to handle it, and got the fixes in F33 and F34 > before the kernel showed up. > > If we remove Podman updates from Rawhide other then when we prepare for > release. Their will be errors that do not get caught early. > > Forcing us to treat Rawhide like we do F34 makes Rawhide less > interesting to the container effort. I don't believe anyone suggested anything of the sort, though. The initial post in this thread proposed banning automated builds. The discussion has touched on the problems of automated dumps of random git snapshots with no manual involvement and the lack of any kind of attention to Bodhi comments. The actual issues raised in the thread can all be addressed without "treat[ing] Rawhide like we do F34". -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Requesting missing devel packages: How to request one be put in RHEL 8 CRB
On Fri, Jun 25, 2021 at 2:02 PM Josh Boyer wrote: > On Thu, Jun 24, 2021 at 4:32 PM Troy Dawson wrote: > > > > During our last round of proposals for solutions to missing devel > packages, it was noted that EPEL and CentOS has very different > documentation for requesting a package be put into RHEL 8.[1][2] > > > > I am betting that CentOS's documentation is correct. It was written > after ours. > > > > When I was talking to the Red Hat people who know, it was noted that Red > Hat has much better communication with the Fedora and CentOS communities > than the EPEL community.[3] They wanted to start fixing that communication > gap, and figured this would be a good way to start. So I'm asking Josh > Boyer to answer this question on behalf of Red Hat. > > Thanks, Troy! > > > How would Red Hat like us, EPEL maintainers and developers, to request > missing devel packages? (devel packages that are built at the same time as > a released library in RHEL8, but not released in RHEL8. Such as lmdb-devel) > > The process as documented on the CentOS wiki page is the best route. > Filing a bug against the package in the Red Hat Enterprise Linux > product family with the CentOS Stream version set will ensure that > both the team maintaining the package in RHEL and some from the CentOS > Stream team are looped in. Getting the request in front of the owning > RHEL team is key, as they will need to evaluate the request and > consider the implications of providing the devel package. > > I would like to make sure and clarify that this is the best approach > for devel packages from SRPMs that are already part of RHEL. > Completely new package requests for things that are not in RHEL at all > are RFEs that should likely come through a case filed in the Customer > Portal for those that have a valid subscription. > > > If we follow Red Hat's procedure, what are the odds that the package > will make it into RHEL 8 CRB? > > This one is harder to answer in a general sense. I don't want to be > misleading, so I won't give odds because it will vary depending on the > package. I'll certainly say the odds are better if the requests are > made than if they aren't :) We have grown the CRB content set by over > 100 packages since the initial RHEL 8.0 release, and continue to add > packages even today. I'd like to also describe some of the > considerations at play as we work on this. > > Essentially, the team that owns the package will evaluate the request > to ensure it's consistent with the manner in which the package is > intended to be used as part of RHEL. Often enabling other software to > build against a RHEL package, particularly for things like EPEL > enablement, is a perfectly valid use case. Once a valid use case has > been established the team will ensure they can meet any obligations > required by adding it as part of the RHEL product and sign off. After > the team has agreed, the package will first appear in CentOS Stream > PowerTools (or occasionally AppStream), and then in a future RHEL > minor release. > > At times, we have included a library or package as an internal > implementation detail and do not encourage wider use of that package > for other software. This is a relatively rare case. I can only think > of one stand-out package that comes to mind thus far. If it does > happen the team may decide not to provide the devel package. Filing > the request is often the best way to begin that dialog. This helps us > understand how a package is being used and take that into > consideration for future RHEL releases, and also allows discussion and > suggestions for alternative packages that may be more suitable in the > long term. > > I'm sure there are many that would simply like all subpackages of all > SRPMs to be shipped, however that is not the approach RHEL is taking > from a product perspective. Blanket requests for everything are not > likely to go far. It's simply not actionable at the same level as > targeted requests. > > As an aside, I am particularly encouraged to see EPEL-Next come to > fruition and combined with CentOS Stream and the broader set of > packages available in that project buildroot I think there is a lot of > potential to grow the overall ecosystem. I believe EPEL has discussed > this recently with some hesitation, but I would encourage you to > consider if and how EPEL-Next and CentOS Stream might be leveraged to > help EPEL proper as well. From what I've seen, this community is > amazing and I think there are opportunities there. > > Thanks again Troy, for giving me the opportunity to interact with the > EPEL community. This is quite overdue. > > josh > > Thank you Josh for your reply. This will help us as we move forward. We have updated out EPEL FAQ concerning this. Troy [1] -
[EPEL-devel] Re: Requesting missing devel packages: How to request one be put in RHEL 8 CRB
On Thu, Jun 24, 2021 at 4:32 PM Troy Dawson wrote: > > During our last round of proposals for solutions to missing devel packages, > it was noted that EPEL and CentOS has very different documentation for > requesting a package be put into RHEL 8.[1][2] > > I am betting that CentOS's documentation is correct. It was written after > ours. > > When I was talking to the Red Hat people who know, it was noted that Red Hat > has much better communication with the Fedora and CentOS communities than the > EPEL community.[3] They wanted to start fixing that communication gap, and > figured this would be a good way to start. So I'm asking Josh Boyer to > answer this question on behalf of Red Hat. Thanks, Troy! > > How would Red Hat like us, EPEL maintainers and developers, to request > missing devel packages? (devel packages that are built at the same time as a > released library in RHEL8, but not released in RHEL8. Such as lmdb-devel) The process as documented on the CentOS wiki page is the best route. Filing a bug against the package in the Red Hat Enterprise Linux product family with the CentOS Stream version set will ensure that both the team maintaining the package in RHEL and some from the CentOS Stream team are looped in. Getting the request in front of the owning RHEL team is key, as they will need to evaluate the request and consider the implications of providing the devel package. I would like to make sure and clarify that this is the best approach for devel packages from SRPMs that are already part of RHEL. Completely new package requests for things that are not in RHEL at all are RFEs that should likely come through a case filed in the Customer Portal for those that have a valid subscription. > If we follow Red Hat's procedure, what are the odds that the package will > make it into RHEL 8 CRB? This one is harder to answer in a general sense. I don't want to be misleading, so I won't give odds because it will vary depending on the package. I'll certainly say the odds are better if the requests are made than if they aren't :) We have grown the CRB content set by over 100 packages since the initial RHEL 8.0 release, and continue to add packages even today. I'd like to also describe some of the considerations at play as we work on this. Essentially, the team that owns the package will evaluate the request to ensure it's consistent with the manner in which the package is intended to be used as part of RHEL. Often enabling other software to build against a RHEL package, particularly for things like EPEL enablement, is a perfectly valid use case. Once a valid use case has been established the team will ensure they can meet any obligations required by adding it as part of the RHEL product and sign off. After the team has agreed, the package will first appear in CentOS Stream PowerTools (or occasionally AppStream), and then in a future RHEL minor release. At times, we have included a library or package as an internal implementation detail and do not encourage wider use of that package for other software. This is a relatively rare case. I can only think of one stand-out package that comes to mind thus far. If it does happen the team may decide not to provide the devel package. Filing the request is often the best way to begin that dialog. This helps us understand how a package is being used and take that into consideration for future RHEL releases, and also allows discussion and suggestions for alternative packages that may be more suitable in the long term. I'm sure there are many that would simply like all subpackages of all SRPMs to be shipped, however that is not the approach RHEL is taking from a product perspective. Blanket requests for everything are not likely to go far. It's simply not actionable at the same level as targeted requests. As an aside, I am particularly encouraged to see EPEL-Next come to fruition and combined with CentOS Stream and the broader set of packages available in that project buildroot I think there is a lot of potential to grow the overall ecosystem. I believe EPEL has discussed this recently with some hesitation, but I would encourage you to consider if and how EPEL-Next and CentOS Stream might be leveraged to help EPEL proper as well. From what I've seen, this community is amazing and I think there are opportunities there. Thanks again Troy, for giving me the opportunity to interact with the EPEL community. This is quite overdue. josh > > Thanks > Troy Dawson > > [1] - > https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8.2B_has_binaries_in_the_release.2C_but_is_missing_some_corresponding_-devel_package._How_do_I_build_a_package_that_needs_that_missing_-devel_package.3F > [2] - https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages > [3] - Yes, I write my emails here from my redhat email address, but I do not > represent Red Hat in my EPEL capacities. ___ epel-devel mailing list --
Re: RFC: Banning bots from submitting automated koji builds
On Fri, Jun 25, 2021 at 9:43 PM Daniel Walsh wrote: > (snip) > > And sometimes this breakage is caused by other parts of the system. For > example a kernel update caused breakage in Podman when it suddenly > enabled overlay mounts, which no one had tried. We quickly fixed the > container-selinux package to handle it, and got the fixes in F33 and F34 > before the kernel showed up. > > If we remove Podman updates from Rawhide other then when we prepare for > release. Their will be errors that do not get caught early. > > Forcing us to treat Rawhide like we do F34 makes Rawhide less > interesting to the container effort. That's not what we're asking for. Pushing Betas or RCs into Rawhide makes sense. But *only if* anybody is actually noticing that, for example, the last few dozen podman builds didn't even get pushed into rawhide repos because they failed gating tests. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: use unit names in systemd output by default?
* Colin Walters: > On Fri, Jun 25, 2021, at 6:21 AM, Zbigniew Jędrzejewski-Szmek wrote: >> Hi, >> >> systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat= >> / -Dstatus-unit-format-default= option to use unit names instead of the >> Description in messages on the kernel console and in logs: > > I meant to get back to https://github.com/systemd/systemd/pull/15957 > which I still think is the best. Is the unit ID already logged as LOG_UNIT_ID? Maybe users can be offered a choice when they invoke journalctl? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFC: Banning bots from submitting automated koji builds
On 6/25/21 16:13, Neal Gompa wrote: On Fri, Jun 25, 2021 at 3:43 PM Daniel Walsh wrote: On 6/25/21 10:25, Neal Gompa wrote: On Fri, Jun 25, 2021 at 10:15 AM Lokesh Mandvekar wrote: Hi list, I own the rhcontainerbot account. Apologies it took so long to respond to this thread. A number of legitimate concerns have been raised about the bot, so let me address those below on behalf of the Containers team. We have disabled all autobuilds for now. The podman RC build landing in updates a month ago was a one-off and it has been discussed at: https://lists.podman.io/archives/list/pod...@lists.podman.io/thread/WYNTH224D5MVBC2RFOG6RPIC52JZFKAB/ The fuse-overlayfs downgrade occurred unintendedly during the upstream branch rename from master to main. That has been fixed at: https://koji.fedoraproject.org/koji/buildinfo?buildID=1775442 Disabling autobuilds during the branch rename phase would’ve evidently avoided this issue. Going forward: We will only manually build upstream release tags for Fedora releases. We would prefer to send RC tags to Fedora rawhide as that will trigger gating tests and allow us to test podman with FCOS and toolbox CIs, so please let us know if that would be a deal-breaker. RCs and final releases are generally okay IMO even for stable releases, as long as you're prepared to address feedback brought up in bodhi updates. The problem here is nobody is paying attention to Bodhi at all. We may look at re-enabling the bot only for koji builds of upstream releases, while bodhi updates will still be manual. We’ll make sure to check for breakages / version downgrades before re-enablement. The bot has so far compared upstream tags, rpm installability, version number sanity, but evidently it has missed a lot of cases including git branch changes. If we re-enable the bot, we will mention the human’s name and email for every changelog entry in every relevant package as well as regularly monitor the bot’s email. Please let us know if there are any concerns with this approach. We will use openSUSE’s OBS for builds of the latest upstream commits for our users who need the latest packages. We would need this to check if the latest commits in podman work well with new kernel features and selinux. Team members will not add karma to containers’ packages, with the exception of our QE Engineer who owns our gating tests and is in charge of final testing of our builds. Currently Ed Santiago (FAS: @santiago) owns that responsibility. The important aspect isn't who is doing it, but that it's actually *tested* to work. Very serious breakages have happened in the past, and that's we want to avoid going forward. And sometimes this breakage is caused by other parts of the system. For example a kernel update caused breakage in Podman when it suddenly enabled overlay mounts, which no one had tried. We quickly fixed the container-selinux package to handle it, and got the fixes in F33 and F34 before the kernel showed up. If we remove Podman updates from Rawhide other then when we prepare for release. Their will be errors that do not get caught early. Forcing us to treat Rawhide like we do F34 makes Rawhide less interesting to the container effort. But none of you are paying attention to Rawhide anyway. As far as I know, none of you actively run Rawhide, none of you test it, and nobody is paying attention to when stuff is pushed into Rawhide. This is the difference between what your team is doing and what I do when I push snapshots into Rawhide. If you're going to push stuff into Rawhide, *care* about it. I ran rawhide for > 10 years so I know the joy and sometimes pain, but I will have the team focus more on it going forward. ___ 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: RFC: Banning bots from submitting automated koji builds
On Fri, Jun 25, 2021 at 3:43 PM Daniel Walsh wrote: > > On 6/25/21 10:25, Neal Gompa wrote: > > On Fri, Jun 25, 2021 at 10:15 AM Lokesh Mandvekar > > wrote: > >> Hi list, > >> > >> > >> I own the rhcontainerbot account. Apologies it took so long to respond to > >> this thread. A number of legitimate concerns have been raised about the > >> bot, so let me address those below on behalf of the Containers team. > >> > >> > >> We have disabled all autobuilds for now. > >> > >> The podman RC build landing in updates a month ago was a one-off and it > >> has been discussed at: > >> https://lists.podman.io/archives/list/pod...@lists.podman.io/thread/WYNTH224D5MVBC2RFOG6RPIC52JZFKAB/ > >> > >> The fuse-overlayfs downgrade occurred unintendedly during the upstream > >> branch rename from master to main. That has been fixed at: > >> https://koji.fedoraproject.org/koji/buildinfo?buildID=1775442 > >> Disabling autobuilds during the branch rename phase would’ve evidently > >> avoided this issue. > >> > >> > >> Going forward: > >> > >> We will only manually build upstream release tags for Fedora releases. We > >> would prefer to send RC tags to Fedora rawhide as that will trigger gating > >> tests and allow us to test podman with FCOS and toolbox CIs, so please let > >> us know if that would be a deal-breaker. > >> > > RCs and final releases are generally okay IMO even for stable > > releases, as long as you're prepared to address feedback brought up in > > bodhi updates. The problem here is nobody is paying attention to Bodhi > > at all. > > > >> We may look at re-enabling the bot only for koji builds of upstream > >> releases, while bodhi updates will still be manual. We’ll make sure to > >> check for breakages / version downgrades before re-enablement. The bot has > >> so far compared upstream tags, rpm installability, version number sanity, > >> but evidently it has missed a lot of cases including git branch changes. > >> > >> If we re-enable the bot, we will mention the human’s name and email for > >> every changelog entry in every relevant package as well as regularly > >> monitor the bot’s email. Please let us know if there are any concerns with > >> this approach. > >> > >> We will use openSUSE’s OBS for builds of the latest upstream commits for > >> our users who need the latest packages. We would need this to check if the > >> latest commits in podman work well with new kernel features and selinux. > >> > >> > >> Team members will not add karma to containers’ packages, with the > >> exception of our QE Engineer who owns our gating tests and is in charge of > >> final testing of our builds. Currently Ed Santiago (FAS: @santiago) owns > >> that responsibility. > >> > > The important aspect isn't who is doing it, but that it's actually > > *tested* to work. Very serious breakages have happened in the past, > > and that's we want to avoid going forward. > > And sometimes this breakage is caused by other parts of the system. For > example a kernel update caused breakage in Podman when it suddenly > enabled overlay mounts, which no one had tried. We quickly fixed the > container-selinux package to handle it, and got the fixes in F33 and F34 > before the kernel showed up. > > If we remove Podman updates from Rawhide other then when we prepare for > release. Their will be errors that do not get caught early. > > Forcing us to treat Rawhide like we do F34 makes Rawhide less > interesting to the container effort. > But none of you are paying attention to Rawhide anyway. As far as I know, none of you actively run Rawhide, none of you test it, and nobody is paying attention to when stuff is pushed into Rawhide. This is the difference between what your team is doing and what I do when I push snapshots into Rawhide. If you're going to push stuff into Rawhide, *care* about it. -- 真実はいつも一つ！/ 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: Orphaned packages looking for new maintainers
Thanks Mikolaj - Just saw your reply and have added you as an admin. ___ 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: RFC: Banning bots from submitting automated koji builds
On 6/25/21 10:25, Neal Gompa wrote: On Fri, Jun 25, 2021 at 10:15 AM Lokesh Mandvekar wrote: Hi list, I own the rhcontainerbot account. Apologies it took so long to respond to this thread. A number of legitimate concerns have been raised about the bot, so let me address those below on behalf of the Containers team. We have disabled all autobuilds for now. The podman RC build landing in updates a month ago was a one-off and it has been discussed at: https://lists.podman.io/archives/list/pod...@lists.podman.io/thread/WYNTH224D5MVBC2RFOG6RPIC52JZFKAB/ The fuse-overlayfs downgrade occurred unintendedly during the upstream branch rename from master to main. That has been fixed at: https://koji.fedoraproject.org/koji/buildinfo?buildID=1775442 Disabling autobuilds during the branch rename phase would’ve evidently avoided this issue. Going forward: We will only manually build upstream release tags for Fedora releases. We would prefer to send RC tags to Fedora rawhide as that will trigger gating tests and allow us to test podman with FCOS and toolbox CIs, so please let us know if that would be a deal-breaker. RCs and final releases are generally okay IMO even for stable releases, as long as you're prepared to address feedback brought up in bodhi updates. The problem here is nobody is paying attention to Bodhi at all. We may look at re-enabling the bot only for koji builds of upstream releases, while bodhi updates will still be manual. We’ll make sure to check for breakages / version downgrades before re-enablement. The bot has so far compared upstream tags, rpm installability, version number sanity, but evidently it has missed a lot of cases including git branch changes. If we re-enable the bot, we will mention the human’s name and email for every changelog entry in every relevant package as well as regularly monitor the bot’s email. Please let us know if there are any concerns with this approach. We will use openSUSE’s OBS for builds of the latest upstream commits for our users who need the latest packages. We would need this to check if the latest commits in podman work well with new kernel features and selinux. Team members will not add karma to containers’ packages, with the exception of our QE Engineer who owns our gating tests and is in charge of final testing of our builds. Currently Ed Santiago (FAS: @santiago) owns that responsibility. The important aspect isn't who is doing it, but that it's actually *tested* to work. Very serious breakages have happened in the past, and that's we want to avoid going forward. And sometimes this breakage is caused by other parts of the system. For example a kernel update caused breakage in Podman when it suddenly enabled overlay mounts, which no one had tried. We quickly fixed the container-selinux package to handle it, and got the fixes in F33 and F34 before the kernel showed up. If we remove Podman updates from Rawhide other then when we prepare for release. Their will be errors that do not get caught early. Forcing us to treat Rawhide like we do F34 makes Rawhide less interesting to the container effort. We will also notify the containers’ communities that rawhide will no longer contain the latest builds as some of them are accustomed to using. Having a COPR would be nice for this. With tools like Packit and such able to continuously build in COPR for every PR and every commit, you can provide a fairly nice experience here. I do this with rpmlint, for example. ___ 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-IoT-35-20210625.0 compose check report
No missing expected images. Failed openQA tests: 6/15 (aarch64), 2/16 (x86_64) New failures (same test not failed in Fedora-IoT-35-20210623.0): ID: 916461 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/916461 ID: 916462 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/916462 ID: 916469 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/916469 Old failures (same test failed in Fedora-IoT-35-20210623.0): ID: 916454 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/916454 ID: 916458 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/916458 ID: 916460 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/916460 ID: 916467 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/916467 ID: 916471 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/916471 Soft failed openQA tests: 3/16 (x86_64), 1/15 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-35-20210623.0): ID: 916443 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/916443 ID: 916444 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/916444 ID: 916449 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/916449 ID: 916459 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/916459 Passed openQA tests: 11/16 (x86_64), 8/15 (aarch64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Used mem changed from 170 MiB to 188 MiB Previous test data: https://openqa.fedoraproject.org/tests/914894#downloads Current test data: https://openqa.fedoraproject.org/tests/916443#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Used mem changed from 168 MiB to 188 MiB Previous test data: https://openqa.fedoraproject.org/tests/914895#downloads Current test data: https://openqa.fedoraproject.org/tests/916444#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: Used mem changed from 182 MiB to 204 MiB System load changed from 0.68 to 3.84 Average CPU usage changed from 3.55238095 to 95.23809524 Previous test data: https://openqa.fedoraproject.org/tests/914910#downloads Current test data: https://openqa.fedoraproject.org/tests/916459#downloads -- 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 1976330] New: ctstream-30 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1976330 Bug ID: 1976330 Summary: ctstream-30 is available Product: Fedora Version: rawhide Status: NEW Component: ctstream Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 30 Current version/release in rawhide: 29-6.fc34 URL: http://xpisar.wz.cz/ctstream/ 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/377/ -- 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: use unit names in systemd output by default?
On Fri, Jun 25, 2021 at 12:52:48PM -0400, Colin Walters wrote: > > > On Fri, Jun 25, 2021, at 6:21 AM, Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > > > systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat= > > / -Dstatus-unit-format-default= option to use unit names instead of the > > Description in messages on the kernel console and in logs: > > I meant to get back to https://github.com/systemd/systemd/pull/15957 > which I still think is the best. I forgot about that pull request. So yeah, maybe that'd be an option. Then you'd get the Description at once, and the short identifier afterwards. On Fri, Jun 25, 2021 at 06:49:32PM +0200, Aleksandra Fedorova wrote: > I would vote for unit-names over description, as I can use them to > search information in the logs or in docs. > > But I wonder why don't we consider having both unit name and description > > Could something like > >Jun 20 22:04:48 krowka systemd[1]: Starting systemd-udevd.service - > Rule-based Manager for Device Events... >Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service. > > be an option? > > You mention brevity, but do we really need to save space here? For log messages, the longer form is fine. But on the console, it's likely not fit in 80 characters. And there's more to this, which I didn't mention so far: I want to propagate the starting/stopping information from the user managers to the system manager. So the system manager can show on the console: "Stopping user@1000.service (stopping gvfs-daemon.service)" [formatting details to be figured out…]. This should work with unit names, but with unit descriptions there is no way to meaningfully fit this on one line. 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: use unit names in systemd output by default?
On Fri, Jun 25, 2021 at 05:23:08PM +0100, Daniel P. Berrangé wrote: > On Fri, Jun 25, 2021 at 10:21:05AM +, Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > > > systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat= > > / -Dstatus-unit-format-default= option to use unit names instead of the > > Description in messages on the kernel console and in logs: > > > > - Jun 20 22:04:48 krowka systemd[1]: Started Rule-based Manager for Device > > Events and Files. > > + Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service. > > > > I find this more convenient because it's briefer, so it fits better on > > a terminal, but primarily because I can select the unit name for > > further lookup. When Description is used, and I'm not familiar with > > the unit, I'll often use grep first to figure out what the unit name > > actually is. Finally, unit Descriptions are often not very good, and > > the name is at least as informative… > > IIUC, the descriptions are not translated / localized. So perhaps > the unit file names are more meaningful for non-english speakers > too ? Logs are not localized in general, because they are "global", shared between all users. This is a valid point: I'm pretty sure that 99% of people will immediately have a rough idea what lighttppd.service is. But "Lightning Fast Webserver With Light System Requirements"? This baroque description will be even more confusing to non-native speakers. 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
[Test-Announce] Fedora-IoT 35 RC 20210625.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora-IoT 35 RC 20210625.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/35iot You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_35_RC_20210625.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_35_RC_20210625.0_General Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-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/test-annou...@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: "The fedora 34 iso/installer still hasn't been updated/is broken since November 2020 to install to MD raid arrays"
On Fri, 2021-06-25 at 19:00 +0200, Robert-André Mauchin wrote: > Hello, > > Some popular tech youtuber is encountering problems to install Fedora on > MD raid arrays: > > https://twitter.com/tekwendell/status/1408255117506326529 1 Retweet 1 Quote Tweet 50 Likes You've got a generous definition of popular. :P > The related bug is https://bugzilla.redhat.com/show_bug.cgi?id=1897350 Is it, though? That bug still doesn't actually have any logs attached to it that demonstrate any clear issue besides the naming one. It's not clear if that's the bug this person is hitting or not. > > Is there any thing that can be done to alleviate this issue faster? Someone could provide the logs the devs keep asking for? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora-Rawhide-20210625.n.0 compose check report
On Fri, 2021-06-25 at 16:56 +, Fedora compose checker wrote: > No missing expected images. > > Compose FAILS proposed Rawhide gating check! > 2 of 43 required tests failed > openQA tests matching unsatisfied gating requirements shown with **GATING** > below > > Failed openQA tests: 16/134 (aarch64), 6/199 (x86_64) So I didn't post analysis of these for a while, sorry about that...to give a quick snapshot of current state: most of the x86_64 failures are a result of an anaconda bug with timezone math that means it winds up setting the clock an hour fast if the selected timezone is in daylight savings: https://bugzilla.redhat.com/show_bug.cgi?id=1965718 This causes FreeIPA client enrolment via kickstart during install and remote system logging to fail. The other failure is a longstanding bug with krfb in the KDE 'start and stop all installed apps' test: https://bugzilla.redhat.com/show_bug.cgi?id=1899803 The aarch64 failures seem to be mostly timing issues - the tests run slower on aarch64 and this seems to be tripping various things up. I'll try and look into improving some of those next week. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
"The fedora 34 iso/installer still hasn't been updated/is broken since November 2020 to install to MD raid arrays"
Hello, Some popular tech youtuber is encountering problems to install Fedora on MD raid arrays: https://twitter.com/tekwendell/status/1408255117506326529 The related bug is https://bugzilla.redhat.com/show_bug.cgi?id=1897350 Is there any thing that can be done to alleviate this issue faster? 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
Fedora-Rawhide-20210625.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 2 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 16/134 (aarch64), 6/199 (x86_64) New failures (same test not failed in Fedora-Rawhide-20210624.n.0): ID: 916183 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/916183 ID: 916202 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi URL: https://openqa.fedoraproject.org/tests/916202 ID: 916206 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/916206 ID: 916207 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/916207 ID: 916208 Test: aarch64 Workstation-raw_xz-raw.xz unwanted_packages@uefi URL: https://openqa.fedoraproject.org/tests/916208 ID: 916210 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/916210 ID: 916211 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/916211 ID: 916300 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/916300 ID: 916420 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/916420 ID: 916423 Test: aarch64 universal install_kickstart_nfs@uefi URL: https://openqa.fedoraproject.org/tests/916423 Old failures (same test failed in Fedora-Rawhide-20210624.n.0): ID: 916054 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/916054 ID: 916056 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/916056 ID: 916062 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/916062 ID: 916065 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/916065 ID: 916098 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/916098 ID: 916107 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/916107 ID: 916145 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/916145 ID: 916181 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/916181 ID: 916185 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/916185 ID: 916186 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/916186 ID: 916311 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/916311 ID: 916312 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/916312 Soft failed openQA tests: 3/199 (x86_64), 3/134 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20210624.n.0): ID: 916125 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/916125 ID: 916132 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/916132 ID: 916189 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/916189 ID: 916215 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/916215 ID: 916224 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/916224 ID: 916254 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/916254 Passed openQA tests: 115/134 (aarch64), 190/199 (x86_64) New passes (same test not passed in Fedora-Rawhide-20210624.n.0): ID: 916170 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/916170 ID: 916179 Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi URL: https://openqa.fedoraproject.org/tests/916179 ID: 916187 Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi URL: https://openqa.fedoraproject.org/tests/916187 ID: 916198 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/916198 ID: 916199 Test: aarch64 Workstation-raw_xz-raw.xz base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/916199 ID: 916200 Test: aarch64 Workstation-raw_xz-raw.xz release_identification@uefi URL:
[Bug 1976029] perl-IPC-Shareable-1.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1976029 --- Comment #3 from Upstream Release Monitoring --- An HTTP error occurred downloading the package's new Source URLs: Getting https://cpan.metacpan.org/authors/id/M/MS/MSOUTH/IPC-Shareable-1.03.tar.gz to ./IPC-Shareable-1.03.tar.gz -- 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 1976029] perl-IPC-Shareable-1.01 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1976029 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-IPC-Shareable-1.01 is |perl-IPC-Shareable-1.03 is |available |available --- Comment #2 from Upstream Release Monitoring --- Latest upstream release: 1.03 Current version/release in rawhide: 1.00-1.fc35 URL: http://search.cpan.org/dist/IPC-Shareable 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/7130/ -- 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: use unit names in systemd output by default?
On Fri, Jun 25, 2021, at 6:21 AM, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat= > / -Dstatus-unit-format-default= option to use unit names instead of the > Description in messages on the kernel console and in logs: I meant to get back to https://github.com/systemd/systemd/pull/15957 which I still think is the best. ___ 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: use unit names in systemd output by default?
Hi, On Fri, Jun 25, 2021 at 12:21 PM Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat= > / -Dstatus-unit-format-default= option to use unit names instead of the > Description in messages on the kernel console and in logs: > > - Jun 20 22:04:48 krowka systemd[1]: Started Rule-based Manager for Device > Events and Files. > + Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service. > > I find this more convenient because it's briefer, so it fits better on > a terminal, but primarily because I can select the unit name for > further lookup. When Description is used, and I'm not familiar with > the unit, I'll often use grep first to figure out what the unit name > actually is. Finally, unit Descriptions are often not very good, and > the name is at least as informative… I would vote for unit-names over description, as I can use them to search information in the logs or in docs. But I wonder why don't we consider having both unit name and description Could something like Jun 20 22:04:48 krowka systemd[1]: Starting systemd-udevd.service - Rule-based Manager for Device Events... Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service. be an option? You mention brevity, but do we really need to save space here? > Would people be opposed to making this the default (setting > -Dstatus-unit-format-default=name in build options)? People who like > the old default could set StatusUnitFormat=description in systemd.conf > > 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 -- Aleksandra Fedorova bookwar on Libera Chat ___ 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: Optimal LUKS Encryption Sector Size (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/LUKSEncryptionSectorSize == Summary == Autodetect optimal encryption sector size during Fedora installation with LUKS/dm-crypt encryption. On devices with 4k (physical) sector size, this will make sure we use 4096 sector size which is optimal for these devices. == Owner == * Name: [[User:okozina|Ondrej Kozina]], [[User:vtrefny|Vojtech Trefny]] * Email: okozina AT redhat.com, vtrefny AT redhat.com == Detailed Description == Anaconda installer (or to be more precise, the libraries Anaconda uses for storage configuration) currently sets sector size for LUKS devices to 512 regardless the of actual physical sector size of the underlying disk device. The latest cryptsetup release added an option to let cryptsetup automatically detect the optimal sector size based on the (physical) sector size of the backing device. By using this new option we can make sure that Anaconda uses the optimal sector size for newly created LUKS devices during installation. This means we will use sector size of 4096 for devices with 4k physical sector size increasing IO performance with these devices. == Scope == * Proposal owners: Changes for both cryptsetup and libblockdev (low-level storage library used by Anaconda) are already merged ([https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/135 cryptsetup]) or submitted ([https://github.com/storaged-project/libblockdev/pull/638 libblockdev]) upstream. We only need to package new versions of these two projects for Fedora 35. No changes will be needed in Anaconda. * Other developers: No work from other developers is needed. * 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 == Upgraded systems will not be affected by this change, this affects only new LUKS containers created during Fedora installation. Support for specifying custom sector size is one of the features available in LUKS2 ([[Changes/SwitchCryptsetupDefaultToLUKS2|default since Fedora 30]]), no additional changes or special support is needed when working with LUKS2 devices with sector sizes different than 512. == How To Test == Disk with 4k physical sectors is required for testing this change. You can check block size of your drive using `blockdev` from `util-linux` package: # blockdev --getpbsz /dev/nvme0n1 4096 This can be also tested in a virtual machine. You can configure any disk to appear as 4k block size disk in libvirt by adding the following option to the disk XML specification: Install Fedora with disk encryption enabled. Using automatic partition with '''Encrypt my data''' enabled is enough for testing. In the installed system use `cryptsetup luksDump /dev/` to check that correct sector size was selected for your device (4096 for disks with 4096 physical sector size): # cryptsetup luksDump /dev/nvme0n1p1 LUKS header information Version:2 ... Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-xts-plain64 '''sector: 4096 [bytes]''' == User Experience == Fedora users shouldn't notice the change, other than a small IO performance boost (IO testing on a 4k sectors NVMe shows around 2-3 % gain when using 4k sectors instead of 512 sectors). == Dependencies == None. == Contingency Plan == * Contingency mechanism: Keep existing behaviour (512 sector size for all devices) * Contingency deadline: Beta Freeze * Blocks release? No -- 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 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
F35 Change: Optimal LUKS Encryption Sector Size (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/LUKSEncryptionSectorSize == Summary == Autodetect optimal encryption sector size during Fedora installation with LUKS/dm-crypt encryption. On devices with 4k (physical) sector size, this will make sure we use 4096 sector size which is optimal for these devices. == Owner == * Name: [[User:okozina|Ondrej Kozina]], [[User:vtrefny|Vojtech Trefny]] * Email: okozina AT redhat.com, vtrefny AT redhat.com == Detailed Description == Anaconda installer (or to be more precise, the libraries Anaconda uses for storage configuration) currently sets sector size for LUKS devices to 512 regardless the of actual physical sector size of the underlying disk device. The latest cryptsetup release added an option to let cryptsetup automatically detect the optimal sector size based on the (physical) sector size of the backing device. By using this new option we can make sure that Anaconda uses the optimal sector size for newly created LUKS devices during installation. This means we will use sector size of 4096 for devices with 4k physical sector size increasing IO performance with these devices. == Scope == * Proposal owners: Changes for both cryptsetup and libblockdev (low-level storage library used by Anaconda) are already merged ([https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/135 cryptsetup]) or submitted ([https://github.com/storaged-project/libblockdev/pull/638 libblockdev]) upstream. We only need to package new versions of these two projects for Fedora 35. No changes will be needed in Anaconda. * Other developers: No work from other developers is needed. * 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 == Upgraded systems will not be affected by this change, this affects only new LUKS containers created during Fedora installation. Support for specifying custom sector size is one of the features available in LUKS2 ([[Changes/SwitchCryptsetupDefaultToLUKS2|default since Fedora 30]]), no additional changes or special support is needed when working with LUKS2 devices with sector sizes different than 512. == How To Test == Disk with 4k physical sectors is required for testing this change. You can check block size of your drive using `blockdev` from `util-linux` package: # blockdev --getpbsz /dev/nvme0n1 4096 This can be also tested in a virtual machine. You can configure any disk to appear as 4k block size disk in libvirt by adding the following option to the disk XML specification: Install Fedora with disk encryption enabled. Using automatic partition with '''Encrypt my data''' enabled is enough for testing. In the installed system use `cryptsetup luksDump /dev/` to check that correct sector size was selected for your device (4096 for disks with 4096 physical sector size): # cryptsetup luksDump /dev/nvme0n1p1 LUKS header information Version:2 ... Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-xts-plain64 '''sector: 4096 [bytes]''' == User Experience == Fedora users shouldn't notice the change, other than a small IO performance boost (IO testing on a 4k sectors NVMe shows around 2-3 % gain when using 4k sectors instead of 512 sectors). == Dependencies == None. == Contingency Plan == * Contingency mechanism: Keep existing behaviour (512 sector size for all devices) * Contingency deadline: Beta Freeze * Blocks release? No -- 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: 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: use unit names in systemd output by default?
On Fri, Jun 25, 2021 at 10:21:05AM +, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat= > / -Dstatus-unit-format-default= option to use unit names instead of the > Description in messages on the kernel console and in logs: > > - Jun 20 22:04:48 krowka systemd[1]: Started Rule-based Manager for Device > Events and Files. > + Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service. > > I find this more convenient because it's briefer, so it fits better on > a terminal, but primarily because I can select the unit name for > further lookup. When Description is used, and I'm not familiar with > the unit, I'll often use grep first to figure out what the unit name > actually is. Finally, unit Descriptions are often not very good, and > the name is at least as informative… IIUC, the descriptions are not translated / localized. So perhaps the unit file names are more meaningful for non-english speakers too ? Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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 Prioritized Bugs status
Hi everyone, We have two open prioritized bugs that could use some extra help: * Akonadi does not start due to DB failure — https://bugzilla.redhat.com/show_bug.cgi?id=1953675 * A glibc test hangs upon pthread cancellation when glibc is compiled with annobin turned on — https://bugzilla.redhat.com/show_bug.cgi?id=1951492 If you can help with diagnosing or fixing these issues, please jump in and help. As a reminder, you can read more about the Prioritized Bugs process at https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/ -- 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: 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: use unit names in systemd output by default?
On 6/25/21 7:19 AM, Neal Gompa wrote: I personally prefer the description myself, actually. Many unit names are more meaningless than the descriptions. One point ... It's far easier to get the description from the unit name than vice versa. -- In Soviet Russia, Google searches 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: RFC: Banning bots from submitting automated koji builds
Dne 25. 06. 21 v 16:25 Neal Gompa napsal(a): We will use openSUSE’s OBS for builds of the latest upstream commits for our users who need the latest packages. We would need this to check if the latest commits in podman work well with new kernel features and selinux. We will also notify the containers’ communities that rawhide will no longer contain the latest builds as some of them are accustomed to using. Having a COPR would be nice for this. With tools like Packit and such able to continuously build in COPR for every PR and every commit, you can provide a fairly nice experience here. I do this with rpmlint, for +1 If you hesitate to use Copr for some reason or you want to help with initial setup then you can contact me privately and I will do my best to help you. 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 Fri, Jun 25, 2021 at 10:43:17AM -0400, Neal Gompa wrote: > On Fri, Jun 25, 2021 at 9:04 AM Frédéric Pierret > wrote: > > > > > > > > Le 6/25/21 à 2:51 PM, Neal Gompa a écrit : > > > On Fri, Jun 25, 2021 at 3:43 AM Zbigniew Jędrzejewski-Szmek > > > wrote: > > >> > > >> On Fri, Jun 25, 2021 at 03:49:23AM +, Dan Čermák wrote: > > >>> > > >>> > > >>> On June 24, 2021 9:22:51 PM UTC, "Miro Hrončok" > > >>> wrote: > > On 24. 06. 21 23:07, Miroslav Suchý wrote: > > > Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a): > > >>> 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 > > > > > > Does it matter? If you are able to generate byte2byte identical > > tarball then > > > you can choose any of them. > > > > AFAIK git does not grantee to produce byte2byte identical archives > > across > > different versions of git, zlib, gzip etc. So even if upstream signs > > the git > > generated archive, generating a byte2byte identical one might be > > tricky. > > >>> > > >>> Especially with xz, which iirc has reproducibility issues in parallel > > >>> mode. > > >> > > >> I think we should try to push upstream to sign git tags, instead or in > > >> addition to tarballs. For upstreams, this is actually much easier > > >> (just 'git tag' → 'git tag -s' and you're done) compared to e.g. signing > > >> a tarball on github which requires some interaction with the web service. > > >> > > > > > > As an upstream, I would literally *never* GPG sign git tags. If you > > > ask me to do that, I won't. It's far too annoying to deal with for me > > > to be willing to suffer through that. > > > > > > I'm not going to ask people to do something I would be unwilling to do > > > myself. > > > > What about only version tags? You could do some git/bash alias to create > > commit version + signed tag at once. For example, we do that on Qubes OS > > and that's not more work that just committing the version. > > > > The problem is that the workflow for tag signatures sucks for Git. And > I'd need to get it registered in the forges or whatever systems are > used to consume and verify signatures. That's Herculean in a way that > I'm unwilling to deal with. I guess I'm missing something. What is hard about doing signed tags? 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 Fri, Jun 25, 2021 at 9:04 AM Frédéric Pierret wrote: > > > > Le 6/25/21 à 2:51 PM, Neal Gompa a écrit : > > On Fri, Jun 25, 2021 at 3:43 AM Zbigniew Jędrzejewski-Szmek > > wrote: > >> > >> On Fri, Jun 25, 2021 at 03:49:23AM +, Dan Čermák wrote: > >>> > >>> > >>> On June 24, 2021 9:22:51 PM UTC, "Miro Hrončok" > >>> wrote: > On 24. 06. 21 23:07, Miroslav Suchý wrote: > > Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a): > >>> 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 > > > > Does it matter? If you are able to generate byte2byte identical > tarball then > > you can choose any of them. > > AFAIK git does not grantee to produce byte2byte identical archives > across > different versions of git, zlib, gzip etc. So even if upstream signs > the git > generated archive, generating a byte2byte identical one might be > tricky. > >>> > >>> Especially with xz, which iirc has reproducibility issues in parallel > >>> mode. > >> > >> I think we should try to push upstream to sign git tags, instead or in > >> addition to tarballs. For upstreams, this is actually much easier > >> (just 'git tag' → 'git tag -s' and you're done) compared to e.g. signing > >> a tarball on github which requires some interaction with the web service. > >> > > > > As an upstream, I would literally *never* GPG sign git tags. If you > > ask me to do that, I won't. It's far too annoying to deal with for me > > to be willing to suffer through that. > > > > I'm not going to ask people to do something I would be unwilling to do > > myself. > > What about only version tags? You could do some git/bash alias to create > commit version + signed tag at once. For example, we do that on Qubes OS and > that's not more work that just committing the version. > The problem is that the workflow for tag signatures sucks for Git. And I'd need to get it registered in the forges or whatever systems are used to consume and verify signatures. That's Herculean in a way that I'm unwilling 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
Re: RFC: Banning bots from submitting automated koji builds
On Fri, Jun 25, 2021 at 10:15 AM Lokesh Mandvekar wrote: > > Hi list, > > > I own the rhcontainerbot account. Apologies it took so long to respond to > this thread. A number of legitimate concerns have been raised about the bot, > so let me address those below on behalf of the Containers team. > > > We have disabled all autobuilds for now. > > The podman RC build landing in updates a month ago was a one-off and it has > been discussed at: > https://lists.podman.io/archives/list/pod...@lists.podman.io/thread/WYNTH224D5MVBC2RFOG6RPIC52JZFKAB/ > > The fuse-overlayfs downgrade occurred unintendedly during the upstream branch > rename from master to main. That has been fixed at: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1775442 > Disabling autobuilds during the branch rename phase would’ve evidently > avoided this issue. > > > Going forward: > > We will only manually build upstream release tags for Fedora releases. We > would prefer to send RC tags to Fedora rawhide as that will trigger gating > tests and allow us to test podman with FCOS and toolbox CIs, so please let us > know if that would be a deal-breaker. > RCs and final releases are generally okay IMO even for stable releases, as long as you're prepared to address feedback brought up in bodhi updates. The problem here is nobody is paying attention to Bodhi at all. > We may look at re-enabling the bot only for koji builds of upstream releases, > while bodhi updates will still be manual. We’ll make sure to check for > breakages / version downgrades before re-enablement. The bot has so far > compared upstream tags, rpm installability, version number sanity, but > evidently it has missed a lot of cases including git branch changes. > > If we re-enable the bot, we will mention the human’s name and email for every > changelog entry in every relevant package as well as regularly monitor the > bot’s email. Please let us know if there are any concerns with this approach. > > We will use openSUSE’s OBS for builds of the latest upstream commits for our > users who need the latest packages. We would need this to check if the latest > commits in podman work well with new kernel features and selinux. > > > Team members will not add karma to containers’ packages, with the exception > of our QE Engineer who owns our gating tests and is in charge of final > testing of our builds. Currently Ed Santiago (FAS: @santiago) owns that > responsibility. > The important aspect isn't who is doing it, but that it's actually *tested* to work. Very serious breakages have happened in the past, and that's we want to avoid going forward. > > We will also notify the containers’ communities that rawhide will no longer > contain the latest builds as some of them are accustomed to using. > Having a COPR would be nice for this. With tools like Packit and such able to continuously build in COPR for every PR and every commit, you can provide a fairly nice experience here. I do this with rpmlint, for example. -- 真実はいつも一つ！/ 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: Fedora Source-git SIG report #1 (June 2021)
On Fri, Jun 25, 2021 at 02:40:22PM +0200, Miroslav Suchý wrote: > Dne 24. 06. 21 v 23:22 Miro Hrončok napsal(a): > > AFAIK git does not grantee to produce byte2byte identical archives > > across different versions of git, zlib, gzip etc. So even if upstream > > signs the git generated archive, generating a byte2byte identical one > > might be tricky. > > Neither git nor tar can do that. But it is not impossible. E.g. Tito [1] has > some hacks on top of git-archive which produces identical tar-balls. > > [1] https://github.com/rpm-software-management/tito/ FWIW, pristine-tar (http://joeyh.name/code/pristine-tar/) can handle almost all upstream tarballs, and it also has support for storing detached signatures alongside its metadata. I keep hearing people say that there are cases when it fails, but it has worked for me for dozens of packages. Of course, it does have its own expectations about the structure of the Git repository, but those are mostly limited to "give me a branch to play in, I'll take care of the rest". G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 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: RFC: Banning bots from submitting automated koji builds
Hi list, I own the rhcontainerbot account. Apologies it took so long to respond to this thread. A number of legitimate concerns have been raised about the bot, so let me address those below on behalf of the Containers team. 1. We have disabled all autobuilds for now. 2. The podman RC build landing in updates a month ago was a one-off and it has been discussed at: https://lists.podman.io/archives/list/pod...@lists.podman.io/thread/WYNTH224D5MVBC2RFOG6RPIC52JZFKAB/ 3. The fuse-overlayfs downgrade occurred unintendedly during the upstream branch rename from master to main. That has been fixed at: https://koji.fedoraproject.org/koji/buildinfo?buildID=1775442 Disabling autobuilds during the branch rename phase would’ve evidently avoided this issue. 1. Going forward: 1. We will only manually build upstream release tags for Fedora releases. We would prefer to send RC tags to Fedora rawhide as that will trigger gating tests and allow us to test podman with FCOS and toolbox CIs, so please let us know if that would be a deal-breaker. 2. We may look at re-enabling the bot only for koji builds of upstream releases, while bodhi updates will still be manual. We’ll make sure to check for breakages / version downgrades before re-enablement. The bot has so far compared upstream tags, rpm installability, version number sanity, but evidently it has missed a lot of cases including git branch changes. 3. If we re-enable the bot, we will mention the human’s name and email for every changelog entry in every relevant package as well as regularly monitor the bot’s email. Please let us know if there are any concerns with this approach. 4. We will use openSUSE’s OBS for builds of the latest upstream commits for our users who need the latest packages. We would need this to check if the latest commits in podman work well with new kernel features and selinux. 1. Team members will not add karma to containers’ packages, with the exception of our QE Engineer who owns our gating tests and is in charge of final testing of our builds. Currently Ed Santiago (FAS: @santiago) owns that responsibility. 1. We will also notify the containers’ communities that rawhide will no longer contain the latest builds as some of them are accustomed to using. Please let us know if there are any concerns that were left unaddressed or if you have any further recommendations or feedback. -- Lokesh On Fri, Jun 25, 2021 at 12:13 AM Dan Čermák wrote: > > > On June 22, 2021 1:26:30 PM UTC, "Miroslav Suchý" > wrote: > >Dne 20. 06. 21 v 10:42 Miro Hrončok napsal(a): > >> Rather than "no bots allowed" policy, we might need a "bots that > >violate our policies and guidelines or have a > >> tendency to break things will be disabled until fixed" policy. > > > >Every bot has been written by somebody. 1) it should be always clear > >who is responsible for the bot 2) The owner should > >take conseq^H^H^H responsibility for it. > > I'd prefer this policy over an outright ban. > ___ > 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
Fedora rawhide compose report: 20210625.n.0 changes
OLD: Fedora-Rawhide-20210624.n.0 NEW: Fedora-Rawhide-20210625.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 3 Dropped packages:0 Upgraded packages: 69 Downgraded packages: 0 Size of added packages: 3.74 MiB Size of dropped packages:0 B Size of upgraded packages: 3.20 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 3.79 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: jsonnet-0.17.0-1.fc35 Summary: Diff JSON and JSON-like structures RPMs:jsonnet jsonnet-devel jsonnet-doc jsonnet-libs python3-jsonnet Size:2.44 MiB Package: python-cocotb-1.5.2-1.fc35 Summary: Coroutine Co-simulation Test Bench RPMs:python3-cocotb Size:1.25 MiB Package: python-environs-9.3.2-3.fc35 Summary: Python library for parsing environment variables RPMs:python3-environs python3-environs+django python3-environs-examples Size:55.57 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: 389-ds-base-2.0.6-1.fc35 Old package: 389-ds-base-2.0.5-1.fc35.1 Summary: 389 Directory Server (base) RPMs: 389-ds-base 389-ds-base-devel 389-ds-base-libs 389-ds-base-snmp cockpit-389-ds python3-lib389 Size: 24.85 MiB Size change: -139.78 KiB Changelog: * Thu Jun 24 2021 Thierry Bordaz - 2.0.6-1 - Bump version to 2.0.6 - Issue 4803 - Improve DB Locks Monitoring Feature Descriptions - Issue 4803 - Improve DB Locks Monitoring Feature Descriptions (#4810) - Issue 4169 - UI - Migrate Typeaheads to PF4 (#4808) - Issue 4414 - disk monitoring - prevent division by zero crash - Issue 4788 - CLI should support Temporary Password Rules attributes (#4793) - Issue 4656 - Fix replication plugin rename dependency issues - Issue 4656 - replication name change upgrade code causes crash with dynamic plugins - Issue 4506 - Improve SASL logging - Issue 4709 - Fix double free in dbscan - Issue 4093 - Fix MEP test case - Issue 4747 - Remove unstable/unstatus tests (followup) (#4809) - Issue 4791 - Missing dependency for RetroCL RFE (#4792) - Issue 4794 - BUG - don't capture container output (#4798) - Issue 4593 - Log an additional message if the server certificate nickname doesn't match nsSSLPersonalitySSL value - Issue 4797 - ACL IP ADDRESS evaluation may corrupt c_isreplication_session connection flags (#4799) - Issue 4169 - UI Migrate checkbox to PF4 (#4769) - Issue 4447 - Crash when the Referential Integrity log is manually edited - Issue 4773 - Add CI test for DNA interval assignment - Issue 4789 - Temporary password rules are not enforce with local password policy (#4790) - Issue 4379 - fixing regression in test_info_disclosure - Issue 4379 - Allow more than 1 empty AttributeDescription for ldapsearch, without the risk of denial of service - Issue 4379 - Allow more than 1 empty AttributeDescription for ldapsearch, without the risk of denial of service - Issue 4575 Update test docstrings metadata - Issue 4753 - Adjust our tests to 389-ds-base-snmp missing in RHEL 9 Appstream - removed the snmp_present() from utils.py as we have get_rpm_version() in conftest.py - Issue 4753 - Adjust our tests to 389-ds-base-snmp missing in RHEL 9 Appstream Package: NFStest-2.1.5-11.fc35 Old package: NFStest-2.1.5-10.fc34 Summary: NFS Testing Tool RPMs: NFStest Size: 505.86 KiB Size change: 4.13 KiB Changelog: * Fri Jun 11 2021 Miro Hron??ok - 2.1.5-11 - Remove unused BuildRequires on python2-setuptools Package: alt-ergo-2.2.0-11.fc35 Old package: alt-ergo-2.2.0-10.fc35 Summary: Automated theorem prover including linear arithmetic RPMs: alt-ergo alt-ergo-gui ocaml-alt-ergo ocaml-alt-ergo-devel Size: 74.81 MiB Size change: -758.33 KiB Changelog: * Tue Jun 22 2021 Jerry James - 2.2.0-11 - Rebuild for ocaml-lablgtk without gnomeui Package: awscli-1.19.100-1.fc35 Old package: awscli-1.19.99-1.fc35 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 2.06 MiB Size change: 136 B Changelog: * Thu Jun 24 2021 Gwyn Ciesla - 1.19.100-1 - 1.19.100 Package: chromium-91.0.4472.114-1.fc35 Old package: chromium-91.0.4472.77-1.fc35 Summary: A WebKit (Blink) powered web browser that Google doesn't want you to use RPMs: chrome-remote-desktop chromedriver chromium chromium-common chromium-headless Size: 446.05 MiB Size change: 75.93 KiB Changelog: * Wed Jun 23 2021 Tom Callaway - 91.0.4472.114-1 - update to 91.0.4472.114 Package: cryptlib-3.4.5-18.fc35 Old package: cryptlib-3.4.5-17.fc35 Summary: Security library and toolkit for encryption and authentication services RPMs: cryptlib cryptlib-devel cryptlib-java cryptlib-javadoc cryptlib-perl cryptlib-python3 cryptlib-test Size: 5.37 MiB Size change: 1.78 KiB
[EPEL-devel] Re: help request: libksysguard build failure on Stream 8
On Thu, Jun 24, 2021 at 8:31 PM Yaakov Selkowitz wrote: > On Thu, 2021-06-24 at 15:40 -0700, Troy Dawson wrote: > > On Wed, Jun 23, 2021 at 9:25 AM Yaakov Selkowitz > > wrote: > > > > > On Wed, 2021-06-23 at 08:56 -0700, Troy Dawson wrote: > > > > I'm updating/ rebuilding KDE Plasma Desktop on CentOS Stream 8, for > the > > > > updated qt5 that is there. I am using what is in F34 for the update. > > > > I've got all the qt5 5.15.2 and kf5 5.83.0 packages built and in the > > > > buildroot. > > > > For libksysguard I believe I have all other dependencies built and > in the > > > > buildroot. > > > > But it just keeps failing, despite everything I've tried.[1][2] > > > > I get the same error on all arches. The same error on version > 5.22.1, > > > > 5.22.2 and even 5.21.4. > > > > I've tried passing build parameters that I thought went along with > the > > > > error, but nothing changed. > > > > > > > > I think this is the critical error, but it's possible I'm wrong > > > > > > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > > > .localalias.209]': > > > > /usr/include/c++/8/bits/fs_path.h:185: undefined reference to > > > > `std::filesystem::__cxx11::path::_M_split_cmpts()' > > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > > > .localalias.209]': > > > > /usr/include/c++/8/bits/fs_dir.h:371: undefined reference to > > > > > > > > `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::files > > > ys > > > > tem::__cxx11::path > > > > const&, std::filesystem::directory_options, std::error_code*)' > > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*)': > > > > /builddir/build/BUILD/libksysguard- > > > > 5.22.2.1/processcore/cgroup_data_model.cpp:447: > > > > undefined reference to > > > > `std::filesystem::__cxx11::directory_iterator::operator*() const' > > > > /builddir/build/BUILD/libksysguard- > > > > 5.22.2.1/processcore/cgroup_data_model.cpp:447: > > > > undefined reference to > > > > `std::filesystem::__cxx11::directory_iterator::operator++()' > > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > > > .localalias.209]': > > > > /usr/include/c++/8/bits/fs_dir.h:260: undefined reference to > > > > `std::filesystem::status(std::filesystem::__cxx11::path const&)' > > > > collect2: error: ld returned 1 exit status > > > > > > std::filesystem was originally added as an experimental extension to > C++, > > > and > > > at first required explicitly linking with -lstdc++fs. GCC 9 removed > the > > > requirement for the additional link library [1], but RHEL 8's default > > > compiler > > > is GCC 8. Therefore, for EPEL 8, you would have to create a patch > which > > > adds > > > stdc++fs to the target_link_libraries of the processcore target. > > > > > > [1] https://gcc.gnu.org/gcc-9/changes.html > > > > > > HTH, > > > > > > > My cmake skills are not up to snuff. A little more help is needed. > > I seems -lstdc++fs needs to be added at the end of the compile command > > /usr/bin/c++ -lstdc++fs > > instead of at the beginning or middle of the options > > /usr/bin/c++ -lstdc++fs > > > > I can do that manually, and it compiles correctly. > > > > But getting cmake to do it, I'm clearly missing something. > > Is there a cmake command line option to put -lstdc++fs at the end? > > There are several cmake and cmake.in files. Would I put it in one, and > if > > so, what is the syntax? > > Add stdc++fs to the end of this list: > > > https://github.com/KDE/libksysguard/blob/master/processcore/CMakeLists.txt#L29-L39 > That did it. Thank you very much. Not only am I unblocked, but my cmake skills are a little bit better. Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
Le 6/25/21 à 2:51 PM, Neal Gompa a écrit : On Fri, Jun 25, 2021 at 3:43 AM Zbigniew Jędrzejewski-Szmek wrote: On Fri, Jun 25, 2021 at 03:49:23AM +, Dan Čermák wrote: On June 24, 2021 9:22:51 PM UTC, "Miro Hrončok" wrote: On 24. 06. 21 23:07, Miroslav Suchý wrote: Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a): 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 Does it matter? If you are able to generate byte2byte identical tarball then you can choose any of them. AFAIK git does not grantee to produce byte2byte identical archives across different versions of git, zlib, gzip etc. So even if upstream signs the git generated archive, generating a byte2byte identical one might be tricky. Especially with xz, which iirc has reproducibility issues in parallel mode. I think we should try to push upstream to sign git tags, instead or in addition to tarballs. For upstreams, this is actually much easier (just 'git tag' → 'git tag -s' and you're done) compared to e.g. signing a tarball on github which requires some interaction with the web service. As an upstream, I would literally *never* GPG sign git tags. If you ask me to do that, I won't. It's far too annoying to deal with for me to be willing to suffer through that. I'm not going to ask people to do something I would be unwilling to do myself. What about only version tags? You could do some git/bash alias to create commit version + signed tag at once. For example, we do that on Qubes OS and that's not more work that just committing the version. Best, Frédéric OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On 25. 06. 21 14:54, Miroslav Suchý wrote: Dne 25. 06. 21 v 14:50 Miro Hrončok napsal(a): AFAIK git does not grantee to produce byte2byte identical archives across different versions of git, zlib, gzip etc. So even if upstream signs the git generated archive, generating a byte2byte identical one might be tricky. Neither git nor tar can do that. But it is not impossible. E.g. Tito [1] has some hacks on top of git-archive which produces identical tar-balls. That would require our upstreams to use tito (or similar), which we are in many case unlikely to affect. I do not expect that. I rather meant that it is technically possible and Packit can "steal" that code from Tito. What I meant is that even if Packit has an ability to create reproducible git tarballs, upstream would need to sign Packit-generated tarballs, which would require much higher level of Fedora's involvement to the upstream release process than is usual for independent upstreams. -- 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: Fedora Source-git SIG report #1 (June 2021)
Dne 25. 06. 21 v 14:50 Miro Hrončok napsal(a): AFAIK git does not grantee to produce byte2byte identical archives across different versions of git, zlib, gzip etc. So even if upstream signs the git generated archive, generating a byte2byte identical one might be tricky. Neither git nor tar can do that. But it is not impossible. E.g. Tito [1] has some hacks on top of git-archive which produces identical tar-balls. That would require our upstreams to use tito (or similar), which we are in many case unlikely to affect. I do not expect that. I rather meant that it is technically possible and Packit can "steal" that code from Tito. 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 Fri, Jun 25, 2021 at 3:43 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Jun 25, 2021 at 03:49:23AM +, Dan Čermák wrote: > > > > > > On June 24, 2021 9:22:51 PM UTC, "Miro Hrončok" wrote: > > >On 24. 06. 21 23:07, Miroslav Suchý wrote: > > >> Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a): > > 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 > > >> > > >> Does it matter? If you are able to generate byte2byte identical > > >tarball then > > >> you can choose any of them. > > > > > >AFAIK git does not grantee to produce byte2byte identical archives > > >across > > >different versions of git, zlib, gzip etc. So even if upstream signs > > >the git > > >generated archive, generating a byte2byte identical one might be > > >tricky. > > > > Especially with xz, which iirc has reproducibility issues in parallel mode. > > I think we should try to push upstream to sign git tags, instead or in > addition to tarballs. For upstreams, this is actually much easier > (just 'git tag' → 'git tag -s' and you're done) compared to e.g. signing > a tarball on github which requires some interaction with the web service. > As an upstream, I would literally *never* GPG sign git tags. If you ask me to do that, I won't. It's far too annoying to deal with for me to be willing to suffer through that. I'm not going to ask people to do something I would be unwilling to do myself. -- 真実はいつも一つ！/ 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: Fedora Source-git SIG report #1 (June 2021)
On 25. 06. 21 14:40, Miroslav Suchý wrote: Dne 24. 06. 21 v 23:22 Miro Hrončok napsal(a): AFAIK git does not grantee to produce byte2byte identical archives across different versions of git, zlib, gzip etc. So even if upstream signs the git generated archive, generating a byte2byte identical one might be tricky. Neither git nor tar can do that. But it is not impossible. E.g. Tito [1] has some hacks on top of git-archive which produces identical tar-balls. That would require our upstreams to use tito (or similar), which we are in many case unlikely to affect. -- 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: Fedora Source-git SIG report #1 (June 2021)
Dne 24. 06. 21 v 23:22 Miro Hrončok napsal(a): AFAIK git does not grantee to produce byte2byte identical archives across different versions of git, zlib, gzip etc. So even if upstream signs the git generated archive, generating a byte2byte identical one might be tricky. Neither git nor tar can do that. But it is not impossible. E.g. Tito [1] has some hacks on top of git-archive which produces identical tar-balls. [1] https://github.com/rpm-software-management/tito/ 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: use unit names in systemd output by default?
On Fri, Jun 25, 2021 at 6:21 AM Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat= > / -Dstatus-unit-format-default= option to use unit names instead of the > Description in messages on the kernel console and in logs: > > - Jun 20 22:04:48 krowka systemd[1]: Started Rule-based Manager for Device > Events and Files. > + Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service. > > I find this more convenient because it's briefer, so it fits better on > a terminal, but primarily because I can select the unit name for > further lookup. When Description is used, and I'm not familiar with > the unit, I'll often use grep first to figure out what the unit name > actually is. Finally, unit Descriptions are often not very good, and > the name is at least as informative… > > Would people be opposed to making this the default (setting > -Dstatus-unit-format-default=name in build options)? People who like > the old default could set StatusUnitFormat=description in systemd.conf > I personally prefer the description myself, actually. Many unit names are more meaningless than the descriptions. It is nice that it is configurable though. Now we just need a verbose mode for systemctl to print that output when you call it to start/stop/restart services. :) -- 真実はいつも一つ！/ 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
Orphaning rubygem-expression_parser
Hi, I am orphaning rubygem-expression_parser. This used to be dependency of rubygem-wikicloth, which was retired some while ago already. This package is mostly dead upstream and I don't have any other use. Vít ___ 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: use unit names in systemd output by default?
On Fri, Jun 25, 2021 at 10:21:05AM +, Zbigniew Jędrzejewski-Szmek wrote: systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat= / -Dstatus-unit-format-default= option to use unit names instead of the Description in messages on the kernel console and in logs: - Jun 20 22:04:48 krowka systemd[1]: Started Rule-based Manager for Device Events and Files. + Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service. I find this more convenient because it's briefer, so it fits better on a terminal, but primarily because I can select the unit name for further lookup. When Description is used, and I'm not familiar with the unit, I'll often use grep first to figure out what the unit name actually is. Finally, unit Descriptions are often not very good, and the name is at least as informative… I agree with this preference. You could consider both. Would people be opposed to making this the default (setting -Dstatus-unit-format-default=name in build options)? People who like the old default could set StatusUnitFormat=description in systemd.conf I think Fedora should stick to upstream defaults in most places. Especially with systemd it's nice if all distros align (which is one of the big benefits of systemd over sysvinit IMHO). What does upstream think about this change? What do other distros think about this change? ___ 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: use unit names in systemd output by default?
Hi, On Fri, 2021-06-25 at 10:21 +, Zbigniew Jędrzejewski-Szmek wrote: > - Jun 20 22:04:48 krowka systemd[1]: Started Rule-based Manager for Device > Events and Files. > + Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service. > > [SNIP] > > Would people be opposed to making this the default (setting > -Dstatus-unit-format-default=name in build options)? People who like > the old default could set StatusUnitFormat=description in > systemd.conf I am in favour of that change. In my view it is also improves consistency, as other log messages such as the ones emitted using LOG_UNIT_MESSAGE will use the unit name rather than the description. Benjamin signature.asc Description: This is a digitally signed message part ___ 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
use unit names in systemd output by default?
Hi, systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat= / -Dstatus-unit-format-default= option to use unit names instead of the Description in messages on the kernel console and in logs: - Jun 20 22:04:48 krowka systemd[1]: Started Rule-based Manager for Device Events and Files. + Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service. I find this more convenient because it's briefer, so it fits better on a terminal, but primarily because I can select the unit name for further lookup. When Description is used, and I'm not familiar with the unit, I'll often use grep first to figure out what the unit name actually is. Finally, unit Descriptions are often not very good, and the name is at least as informative… Would people be opposed to making this the default (setting -Dstatus-unit-format-default=name in build options)? People who like the old default could set StatusUnitFormat=description in systemd.conf 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 Fri, Jun 25, 2021 at 10:51:11AM +0200, Florian Weimer wrote: > * Zbigniew Jędrzejewski-Szmek: > > > I think we should try to push upstream to sign git tags, instead or in > > addition to tarballs. For upstreams, this is actually much easier > > (just 'git tag' → 'git tag -s' and you're done) compared to e.g. signing > > a tarball on github which requires some interaction with the web service. > > Would anyone recognize these signatures today, given that they are > essentially SHA-1 based? git has a reasonably recent sha1 implementation… It's time to move on, but afaik it isn't currently compromised. The switch to sha256 is ongoing. It seems … stalled (?), but it'll happen sooner or later. So I think we can tell people to sign commits, and then at some point in the future this will magically work with sha256. > Fedora has already disabled SHA-1 signatures by default elsewhere, so > such an encouragement would just result in wasted work. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1976133] New: perl-Config-AutoConf-0.320 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1976133 Bug ID: 1976133 Summary: perl-Config-AutoConf-0.320 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Config-AutoConf Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, mspa...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.320 Current version/release in rawhide: 0.319-4.fc35 URL: http://search.cpan.org/dist/Config-AutoConf/ 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/5876/ -- 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
Fedora-Cloud-34-20210625.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-20210624.0): ID: 915995 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/915995 ID: 916004 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/916004 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 1974288] perl-5.34.0-479.fc35 FTBFS with gdbm-devel-1.20-1.fc35: ext/GDBM_File/t/gdbm.t: gdbm_firstkey: Item not found at ../../t/lib/dbmt_common.pl line 52.
https://bugzilla.redhat.com/show_bug.cgi?id=1974288 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-5.34.0-480.fc35 Resolution|--- |RAWHIDE Last Closed||2021-06-25 09:04:14 -- 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: Fedora Source-git SIG report #1 (June 2021)
* Zbigniew Jędrzejewski-Szmek: > I think we should try to push upstream to sign git tags, instead or in > addition to tarballs. For upstreams, this is actually much easier > (just 'git tag' → 'git tag -s' and you're done) compared to e.g. signing > a tarball on github which requires some interaction with the web service. Would anyone recognize these signatures today, given that they are essentially SHA-1 based? Fedora has already disabled SHA-1 signatures by default elsewhere, so such an encouragement would just result in wasted work. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On Thu, Jun 24, 2021 at 11:07:45PM +0200, Miroslav Suchý wrote: > Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a): > > > 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 > > Does it matter? If you are able to generate byte2byte identical > tarball then you can choose any of them. If the upstream tarball contains generated files, chances of re-creating bytewise identical tarball is low, and for autotools based projects it is essentially zero. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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 Fri, Jun 25, 2021 at 03:49:23AM +, Dan Čermák wrote: > > > On June 24, 2021 9:22:51 PM UTC, "Miro Hrončok" wrote: > >On 24. 06. 21 23:07, Miroslav Suchý wrote: > >> Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a): > 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 > >> > >> Does it matter? If you are able to generate byte2byte identical > >tarball then > >> you can choose any of them. > > > >AFAIK git does not grantee to produce byte2byte identical archives > >across > >different versions of git, zlib, gzip etc. So even if upstream signs > >the git > >generated archive, generating a byte2byte identical one might be > >tricky. > > Especially with xz, which iirc has reproducibility issues in parallel mode. I think we should try to push upstream to sign git tags, instead or in addition to tarballs. For upstreams, this is actually much easier (just 'git tag' → 'git tag -s' and you're done) compared to e.g. signing a tarball on github which requires some interaction with the web service. 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-33-20210625.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-20210624.0): ID: 915751 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/915751 ID: 915760 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/915760 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: Why doesn't iconv know ISO-8859-2 in rawhide?
On Fri, Jun 25, 2021 at 10:47 AM Zdenek Dohnal wrote: > Aha, it seems the rawhide buildroot from 6/23 still contained glibc with > recommends on new package and not hard requires. Sorry yes, we haven't done a build yet. I expect one to come out next week with this fix and the fix for some other breakages. > I've explicitly added glibc-gconv-extra as a buildrequires for vim now - > although as you told it is unnecessary right now, I guess it is a good > thing to track what the package actually needs (dependencies can change > with time, as I found out painfully over the years :D ). I've got a releng ticket[1] out to pull glibc-gconv-extra into the minimal buildroot so that we can weaken the dependency again. That way every package won't have to explicitly mention this dependency. Thanks, Siddhesh [1] https://pagure.io/releng/issue/10176 ___ 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
