Re: F34 Cloud Amazon AMIs unbootable after updates
On Thu, Oct 07, 2021 at 08:18:44AM +0100, Richard W.M. Jones wrote: > On Thu, Oct 07, 2021 at 12:46:11AM -0400, Christopher wrote: > > Running on EC2, it's kinda hard to get good information from a system > > that won't boot. The machine won't boot to the point of being able to > > capture the system log, and the screenshot of the instance doesn't > > appear to be super helpful: https://imgur.com/a/4PWcRSg > > Can you hit shift + PgUp and capture as much of the preceeding output > as possible? Nb. console scrollback was removed in kernel 5.9, so shift+pgup no longer works. -- Tomasz Torcz Morality must always be based on practicality. to...@pipebreaker.pl — Baron Vladimir Harkonnen ___ 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 2012019] New: perl-Encode-3.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2012019 Bug ID: 2012019 Summary: perl-Encode-3.14 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Encode Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.14 Current version/release in rawhide: 3.13-481.fc36 URL: http://search.cpan.org/dist/Encode/ 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/2849/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2012019 ___ 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: Orphaning poco
On Fri, Oct 8, 2021 at 2:49 AM Scott Talbert wrote: > > I'm orphaning poco: https://src.fedoraproject.org/rpms/poco > > I'm not sure why I picked it up originally - I don't use it. It currently > FTBFS in rawhide due to OpenSSL 3.0 (and can't be fixed easily by going > back to OpenSSL 1.1 because one of its other BR's requires OpenSSL 3.0). > > Nothing in Fedora depends on it but there is one RPMFusion dependency I > believe (vdr-plex). It's not technically an orphaning as there is a > comaintainer, but that comaintainer hasn't done anything in several years. I take it. It is a great library and I use it even in my day job. > > Scott > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Strange soversion checks in rpmlint 2.x
Vitaly Zaitsev via devel wrote: > By the way, SOVERSION can consist of more than one digit. It can be > 0.5.2 and this is not an error: > https://autotools.io/libtool/version.html Other build systems such as CMake are even more flexible than libtool and allow arbitrary combinations of major version and full version, including: * non-numeric characters (e.g., you can have a version of .0.fedora.1), * the major version (the one encoded in the SONAME) not being a prefix or even a substring of the full version (the one encoded in the name of the regular, non-symlink file), e.g., a major version of .3 for a full version of .1.2.0. Rpmlint should really not complain about these. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]
Michal Srb wrote: > Unlike RPM repositories, Maven repositories can easily hold multiple > versions of libraries. Once a JAR is built, the resulting bytecode will > work with current and future JVMs. There is no need to mass-rebuild JARs > every 6 months. And there is certainly no need to try to run every single > Java application with a single "system-wide" version of a library. And that is actually a problem rather than a solution. Maven artifacts are basically write once only. Everything depends on a hardcoded version which, once uploaded, is normally never touched again. This means that security bugs and other bugs never get fixed (unless the application bumps the dependency version, which can take months or years or even just never happen). That is exactly what the RPM system is designed to avoid. > Fedora could ship just Java applications that would bundle JARs (whatever > version they need) from the Fedora Maven repository. I don't see this as a > problem, as long as it would be possible to track what JARs are bundled in > what application. So you propose to bundle a whole bunch of JARs, some of which have been built many Fedora releases ago and might not even be buildable in any currently supported Fedora anymore? I think this would be not only a huge waste of space, but also a gigantic security nightmare. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Test-Announce] ** UPDATE ** 2021-10-08 @ 16:00 UTC - Special Fedora QA Meeting: Wireplumber Decision
Have there been updated F35 wireplumber packages pushed somewhere? I haven't seen anything on Bodhi this week, so I have not done any testing. I see the meeting is scheduled for tomorrow morning in my timezone, so it's likely that I (and potentially many others) will be not be able to test wireplumber before a decision is made on its readiness. Perhaps I am not understanding the plan, any clarification would be appreciated. ___ 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: F34 Cloud Amazon AMIs unbootable after updates
On Wed, 2021-10-06 at 15:41 -0500, Joe Doss wrote: > > > Does anybody know how to fix a currently broken instance and can > > share > > their solution? > > Is there anything on the console log when you reboot it after the > updates? If you can share the log that would be helpful. There's the new "ISC" (interactive serial console) that can help if you have grub timeout set to non-0... Otherwise, you can detach the EBS volume, attach it to another instance, mount & fixup, then back the other way around (the magic to re-attach the root device is to call it "xvda" without number). Cheers, Ben. ___ 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 Linux 35 Final blocker review summary
I'm out of the office on Friday, so you get tomorrow's blocker summary today! Two notes: 1. This is a big list, so some bugs may have changed status while I was working on it. 2. Go/No-Go for the early target date is a week from today. Happy bug squashing! Action summary Accepted blockers - 1. mesa — gnome-shell: cogl_texture_get_gl_texture(): gnome-shell killed by SIGSEGV — ASSIGNED ACTION: Maintainers to apply patches from kherbst 2. abrt — abrt-dbus segmentation faulted in abrt_p2_service_dbus when shutting down, rebooting, or logging out of Plasma — VERIFIED ACTION: None 3. geoclue2 — time is transiently incorrect when Automatic Time Zone is enabled — ON_QA ACTION: QA to verify FEDORA-2021-532f05d2e3 4. bcm283x-firmware — sdhci_setup_cfg: Hardware does not specify base clock frequency — ON_QA ACTION: QA to verify FEDORA-2021-b1079b7042 5. selinux-policy — The switch for Fedora Third Party repositories does not switch them on. — POST ACTION: Maintainers to package upstream PR with candidate fix 6. distribution — Everything boot x86_64 image exceeds maximum size — POST ACTION: lorax maintainers to merge PR that removes unneeded firmware 7. distribution — Server boot x86_64 image exceeds maximum size — POST ACTION: see above 8. gnome-software — updates-testing repo can't be disabled — NEW ACTION: Maintainer to build an update with upstream PR 9. gnome-software — after enabling third-party repos, the included apps can't be found (except Chrome) — VERIFIED ACTION: None 10. kwin — Real cursor position is slightly offset from displayed position on Wayland in virtual machine (KDE case) — VERIFIED ACTION: None 11. mutter — Mouse cursor offset in VMs with Wayland (but not X11), due to use of Atomic API — VERIFIED ACTION: None 12. systemd — [DNS over TLS] following connection to a wifi AP, internet is not available for ~30s — NEW ACTION: Maintainers to fix issue NEEDINFO: lpoetter, zbyszek 13. wireplumber — sound card disappears after relogin — NEW ACTION: Maintainers to fix issue 14. gnome-software — flathub repo can't be added through gnome-software — NEW ACTION: Maintainers to package upstream fix 15. plasma-discover — Discover shows a misleading state of Flatpak repos, can't delete disabled repos — NEW ACTION: Maintainers to fix issue 16. plasma-discover — Discover can't enable/disable an RPM repo — VERIFIED ACTION: none 17. plasma-discover — Discover doesn't seem to find any RPM packages, neither locally installed nor in RPM repos — NEW ACTION: Maintainers to fix issue Proposed blockers - 1. gnome-shell — gnome-shell OSDs show invalid icons most of the time — NEW ACTION: Maintainers to package upstream MR 1983 2. gnome-software — certain apps are shown among system repos — NEW ACTION: Maintainers to package upstream MR 1023 3. kernel — 5.14.x defaults to acpi on aarch64 — POST ACTION: Maintainers to package 5.14.10 with fix 4. kernel — Fedora 35 aarch64 cloud image based openstack VM hangs — NEW ACTION: Maintainers to diagnose and fix issue 5. kwin — kwin_wayland segmentation faulted in KWin::LibInput::Context::closeRestricted when logging out of Plasma with libinput-1.18.901-1.fc35 — POST ACTION: Maintainers to package adamwill's backport of upstream fix 6. LiveCD - KDE — The KDE Live does freezes on Dell Precision Tower 7810 — NEW ACTION: Maintainers to diagnose and fix issue 7. openh264 — openh264 crashes for all videos — MODIFIED ACTION: Cisco to update repo with new builds 8. plasma-discover — Toggling repo in Discover doesn't redraw the checkbox, confusing users — NEW ACTION: Maintainers to diagnose and fix issue 9. plasma-systemsettings — HDMI Audio Device is invisible/inactive unless you manually assign it a profile — NEW ACTION: Maintainers to diagnose and fix issue 10. uboot-tools — uboot-tools-2021.10 is available — ON_QA ACTION: QA to verify FEDORA-2021-b1079b7042 Bug-by-bug detail = Accepted blockers - 1. mesa — https://bugzilla.redhat.com/show_bug.cgi?id=1989726 — ASSIGNED gnome-shell: cogl_texture_get_gl_texture(): gnome-shell killed by SIGSEGV The Tegra driver in mesa has a regression that causes this bug. Working with upstream on this. This bug was waived from F35 Beta. kherbst has a plan and will prepare patches for the maintainers to apply. 2. abrt — https://bugzilla.redhat.com/show_bug.cgi?id=1997315 — VERIFIED abrt-dbus segmentation faulted in abrt_p2_service_dbus when shutting down, rebooting, or logging out of Plasma The crash reporter crashes (preventing us from receiving a crash report from the crash reporter) when logging out or shutting down a graphical session. Update FEDORA-2021-418a00501f is confirmed to fix the issue. 3. geoclue2 — https://bugzilla.redhat.com/show_bug.cgi?id=1991075 — ON_QA time is transiently incorrect when Automatic Time Zone is enabled The displayed time is incorrect in some cases when Automatic Time Zone is enabled. Both `timedatectl` and
Packager mail bounce: pgier
Hi, I contacted the maintainers of a golang package using $package-maintain...@fedoraproject.org and got a bounce response from an email that I understand is part of go-sig: ext-mx.corp.redhat.com[10.4.204.10] said: 554 5.7.1 : Recipient address rejected: Access denied (in reply to RCPT TO command) I've checked RH's Rover/LDAP and it seems Paul doesn't continue at Red Hat. I've checked activity with fedora-active-user and last FAS login was on 2019-04. Following the "Non-responsive maintainer policy" I filled https://bugzilla.redhat.com/show_bug.cgi?id=2011992 - As his mail doesn't work, should I still wait for a week to open the FESCo ticket? Kind regards, Mikel ___ 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 poco
I'm orphaning poco: https://src.fedoraproject.org/rpms/poco I'm not sure why I picked it up originally - I don't use it. It currently FTBFS in rawhide due to OpenSSL 3.0 (and can't be fixed easily by going back to OpenSSL 1.1 because one of its other BR's requires OpenSSL 3.0). Nothing in Fedora depends on it but there is one RPMFusion dependency I believe (vdr-plex). It's not technically an orphaning as there is a comaintainer, but that comaintainer hasn't done anything in several years. Scott ___ 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: RISC-V -- are we ready for more, and what do we need to do it?
On Thu, Oct 7, 2021 at 1:30 AM Neal Gompa wrote: > > On Wed, Oct 6, 2021 at 1:50 PM Josh Stone wrote: > > > > On 10/4/21 12:12 PM, Neal Gompa wrote: > > > On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi wrote: > > >> * How good is emulation support > > > > > > The lack of real hardware for RISC-V has made it so almost everyone is > > > working with emulation. It's not realistic right now to work with real > > > hardware. > > > > > >> * What would it take to keep up with the other arches? Is that possible? > > > > > > The real hardware options do not have the performance to keep up with > > > the other architectures. > > > > Is it really so slow that emulation is preferable? > > > > In my opinion, yes. There's a dearth of so-called "server-class" > hardware, which have such useful characteristics like "large amounts > of RAM", "decent memory cache", "fast I/O", "PCIe lanes", and so on. > > The development boards typically are very I/O constrained and have > limited amounts of RAM, making them less useful than emulation for > doing builds. We tried to improve the situation with SiFive Unmatched: - 16GiB of RAM (twice more compared to SiFive Unleashed); - PCIe Gen 3; - M.2 NVMe (via PCIe switch); - M.2 for WiFi/BT card (via PCIe switch); - USB-As (via PCIe switch); - You can boot firmware (OpenSBI/DT/U-Boot) via microSD card instead of SPI-NOR Flash. With SD-Muxer you could update all those bits for testing; - mini-ITX (you can put those boards in the rackmount cases); - ATX power supply; - Front panel header connector; - Multiple fan headers; - and more. It's not perfect, but it's a decent upgrade for the 2nd generation SiFive board and the setup is way cheaper too. Pi KVM could provide some remote management (didn't try, might get one in the future to test). Cheers, david > > > -- > 真実はいつも一つ！/ 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 ___ 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 2010107] Provide perl-Mail-RFC822-Address for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2010107 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2021-40073b9b66 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-40073b9b66 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2010107 ___ 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 2011383] perl-CPANPLUS-Dist-Fedora-0.4.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2011383 --- Comment #4 from Fedora Update System --- FEDORA-2021-c7e5fc5c72 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-c7e5fc5c72` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-c7e5fc5c72 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2011383 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 20 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-f005e1b879 debmirror-2.35-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing R-littler-0.3.14-1.el7 eot-utils-1.1-21.el7 libfakekey-0.3-1.el7 Details about builds: R-littler-0.3.14-1.el7 (FEDORA-EPEL-2021-e1321904fb) littler: R at the Command-Line via 'r' Update Information: littler 0.3.14 ChangeLog: * Thu Oct 7 2021 Mattias Ellert - 0.3.14-1 - New upstream release 0.3.14 eot-utils-1.1-21.el7 (FEDORA-EPEL-2021-b36c1325d3) Create or examine EOT font format files Update Information: Initial package for EPEL7. ChangeLog: libfakekey-0.3-1.el7 (FEDORA-EPEL-2021-1547759735) Library for converting characters to X key-presses Update Information: Initial package for EPEL7 ChangeLog: ___ 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 2007039] perl-SNMP-Info-3.81 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2007039 --- Comment #5 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-SNMP-Info-3.81-1.fc34.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=76875445 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2007039 ___ 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 2007039] perl-SNMP-Info-3.81 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2007039 --- Comment #4 from Upstream Release Monitoring --- Created attachment 1830440 --> https://bugzilla.redhat.com/attachment.cgi?id=1830440=edit [patch] Update to 3.81 (#2007039) -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2007039 ___ 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 2007039] perl-SNMP-Info-3.81 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2007039 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-SNMP-Info-3.80 is |perl-SNMP-Info-3.81 is |available |available --- Comment #3 from Upstream Release Monitoring --- Latest upstream release: 3.81 Current version/release in rawhide: 3.78-1.fc36 URL: http://search.cpan.org/dist/SNMP-Info/ 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/3318/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2007039 ___ 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: Orphaned packages looking for new maintainers
Le lundi 04 octobre 2021 à 14:36 +0200, Miro Hrončok a écrit : > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will fail to install and/or build when the affected package gets > retired. > > Request package ownership via the *Take* button in he left column on > https://src.fedoraproject.org/rpms/ > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2021-10-04.txt > grep it for your FAS username and follow the dependency chain. > > For human readable dependency chains, > see https://packager-dashboard.fedoraproject.org/ > For all orphaned packages, > see https://packager-dashboard.fedoraproject.org/orphan > > Package (co)maintainers Status > Change > == > == > dnstracer orphan 4 weeks ago > fedmod nphilipp, orphan 1 weeks ago > golang-github-hanwen-fuse orphan 0 weeks ago > golang-github-jacobsa-crypto orphan 0 weeks ago > golang-github-jacobsa-oglemock orphan 0 weeks ago > golang-github-jacobsa-ogletest orphan 0 weeks ago > golang-github-jacobsa-reqtrace orphan 0 weeks ago > golang-github-rfjakob-gocryptfs orphan 0 weeks ago > golang-github-sabhiram- orphan 0 weeks ago > gitignore > jakarta-commons-httpclient java-maint-sig, mizdebsk, 6 weeks ago > orphan > kdevelop-python dvratil, jgrulich, kde-sig, 1 weeks ago > orphan > kdocker kde-sig, orphan, rdieter 1 weeks ago > mingw-brotli etrunko, orphan 1 weeks ago > mingw-libpsl etrunko, orphan 1 weeks ago > mingw-libunistring etrunko, orphan 1 weeks ago > perl-WebService-Dropbox mathstuf, orphan 1 weeks ago > python-email_reply_parser orphan, python-sig 1 weeks ago I want to maintain this package https://copr.fedorainfracloud.org/coprs/itotutona/First/ Anybody can sponsor me ? > python-first orphan, python-sig 1 weeks ago > python-graphene-sqlalchemy orphan 1 weeks ago > python-graphql-server orphan 1 weeks ago > python-opencensus orphan 5 weeks ago > python-parallel-ssh orphan 1 weeks ago > python-pipreqs orphan, python-sig 1 weeks ago > python-plette orphan, pkopkan, python-sig 1 weeks ago > python-power orphan, python-sig 1 weeks ago > python-ssh2-python orphan 1 weeks ago > python-yarg orphan, python-sig 1 weeks ago I want to maintain this package https://copr.fedorainfracloud.org/coprs/itotutona/Yarg/ Anybody can sponsor me ? > rubygem-ancestry jaruga, orphan 1 weeks ago > rubygem-cliver orphan 3 weeks ago > rubygem-gem-patch orphan 3 weeks ago > rubygem-scoped_search orphan 3 weeks ago > trac-customfieldadmin-plugin orphan 1 weeks ago > trac-watchlist-plugin orphan 1 weeks ago > waiverdb lholecek, lucarval, orphan, 1 weeks ago > ralph, vmaljulin > yarock kde-sig, martinkg, orphan 1 weeks ago > > The following packages require above mentioned packages: > Report too long, see the full version at > https://churchyard.fedorapeople.org/orphans-2021-10-04.txt > > See dependency chains of your packages at > https://packager-dashboard.fedoraproject.org/ > See all orphaned packages at > https://packager-dashboard.fedoraproject.org/orphan > > Affected (co)maintainers (either directly or via packages' dependencies): > berrange: mingw-libpsl,
Fedora-IoT-36-20211007.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 1/16 (x86_64), 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-36-20211004.0): ID: 1018548 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/1018548 ID: 1018563 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1018563 Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64) New passes (same test not passed in Fedora-IoT-36-20211004.0): ID: 1018542 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/1018542 ID: 1018556 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/1018556 ID: 1018565 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/1018565 ID: 1018566 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/1018566 Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Used mem changed from 229 MiB to 204 MiB Previous test data: https://openqa.fedoraproject.org/tests/1013061#downloads Current test data: https://openqa.fedoraproject.org/tests/1018541#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Used mem changed from 228 MiB to 201 MiB Previous test data: https://openqa.fedoraproject.org/tests/1013072#downloads Current test data: https://openqa.fedoraproject.org/tests/1018552#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.78 to 0.41 Previous test data: https://openqa.fedoraproject.org/tests/1013077#downloads Current test data: https://openqa.fedoraproject.org/tests/1018557#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
Re: F36 Change: Retired Packages (Self-Contained Change proposal)
On Thu, Oct 07, 2021 at 18:23:00 +0200, Miro Hrončok wrote: On 07. 10. 21 17:45, Ben Cotton wrote: * We suggest users to remove packages that are no longer maintained and may contain security vulnerabilities. This makes perfect sense. * We make sure that archaic packages do not break upgrade between two versions of Fedora. When are you supposed to run remove-retired-packages? If you run remove-retired-packages after the upgrade, you already managed to upgrade and nothing is broken, no? If the upgrade was done with distro-sync with deletes allowed, then the upgrade would have removed blocking packages. If just upgrade was used then the retired packages might have blocked upgrading some packages. Instead of checking retired packages, people might be better off running dnf list --extras to get a list of installed packages that aren't in any current repo they are using. ___ 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 2009939] perl-CPANPLUS-Dist-Fedora-0.4.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2009939 --- Comment #3 from Fedora Update System --- FEDORA-2021-f6d98de4ef has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f6d98de4ef` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f6d98de4ef See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2009939 ___ 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 2011114] perl-Encode-3.13 is available
https://bugzilla.redhat.com/show_bug.cgi?id=204 --- Comment #6 from Fedora Update System --- FEDORA-2021-974b321a83 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-974b321a83` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-974b321a83 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=204 ___ 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: F36 Change: PHP 8.1 (Self-Contained Change proposal)
On 29. 09. 21 19:08, Ben Cotton wrote: Fedora have a 6 months cycle, PHP and a 1 year, common practice for some years There seem to be some errors in this sentence. -- 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
[Bug 2011383] perl-CPANPLUS-Dist-Fedora-0.4.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2011383 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-2021-f6d98de4ef has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f6d98de4ef` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f6d98de4ef See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2011383 ___ 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] Re: To buildroot, or not to buildroot
On Thu, 7 Oct 2021 at 09:52, Neal Gompa wrote: > > > > > That is the theory, yes, that grobisplitter isn't required. > > But nobody was able to say that was for certain. Thus, it needs to be > > tested. > > > > I've verified this with my internal build infrastructure, so yes, I > know it's not required. > > Admittedly, it's not a Koji system, but I'm also not enabling any > modules in my build environment right now. I'm rebuilding content from > Rawhide targeting CentOS Stream 9 to get a list of initial EPEL 9 > packages to build for work, which is how some of my requests to add > stuff to CRB have come about[1][2][3]. Things have probably improved, but the lesson I learned from EPEL-8 and afterwords was that koji depsolving is weird no matter how set up. Koji sets up mock environments in a way that will do fine as long as there are NO modules in the repositories it is looking at. Once a module, even a non-default module, is there things start to go wonky because the way that koji depsolves will say that 'foobaz-3.10.1-3+module' is a better solution than 'foobax-3.9.4.' it will then try to pull that in and boom you end up with broken builds. You can change the method that koji chooses packages to be in the buildroot, but the other option ends up trying to insert things like foobax-3.9.4-i386 into an x86_64 or still does the modular change but chooses foobar-2 due to some depsolv quirk. At the moment I think building without grobisplitter will work, but I am thinking some other solution will need to be made when EL9.x starts rolling out with modules in it. > > This can also be verified when using something like mock with > mock-core-configs v36 or higher, because I made the necessary > adjustments to test building on CentOS Stream 9 the same way that > Fedora Koji and the CentOS CBS would. > > [1]: > https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/140 > [2]: > https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/139 > [3]: > https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/135 > -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ 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 2008958] CVE-2021-38562 rt: User enumeration through a timing side-channel attack [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2008958 --- Comment #12 from Fedora Update System --- FEDORA-2021-825dd1879f has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-825dd1879f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-825dd1879f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2008958 ___ 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: F36 Change: Retired Packages (Self-Contained Change proposal)
On 07. 10. 21 17:45, Ben Cotton wrote: * We suggest users to remove packages that are no longer maintained and may contain security vulnerabilities. This makes perfect sense. * We make sure that archaic packages do not break upgrade between two versions of Fedora. When are you supposed to run remove-retired-packages? If you run remove-retired-packages after the upgrade, you already managed to upgrade and nothing is broken, no? If you run remove-retired-packages before the upgrade, it might remove something that will be correctly obsoleted and provided by a replacement package that offers the same functionality under a different package name. -- 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
F36 Change: Retired Packages (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/RetiredPackages == Summary == Easy the task of removing packages, which were retired and no longer receives updates. == Owner == * Name: [[User:msuchy| Miroslav Suchý]] * Email: msu...@redhat.com == Detailed Description == This follows the [[Changes/Fedora-Retired-Packages]] which was withdrawn. This time I provide a script `remove-retired-packages` (presented in the package of the same name) which identifies packages retired between N-1 and current (N) version. Alternatively, user can run: remove-retired-packages 32 which will look for packages between Fedora Linux 32 and the current version. The packages are suggested to be removed one by one, which allows the admin to skip the package and keep it on their machine despite being retired. Part of this proposal is to change [https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#sect-optional-post-upgrade-tasks the documentation for the upgrade]. == Feedback == See [[Changes/Fedora-Retired-Packages#Feedback original feedback page]] [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/XQMUSHK7HX65LQUJBFDNY47YPMCPI5MG/#XQMUSHK7HX65LQUJBFDNY47YPMCPI5MG Discussion] on devel mailing list prior this proposal. == Benefit to Fedora == * We suggest users to remove packages that are no longer maintained and may contain security vulnerabilities. * We make sure that archaic packages do not break upgrade between two versions of Fedora. == Scope == * Proposal owners: Subpackage `remove-retired-packages` has been created (subpackage of `fedora-upgrade`). * Other developers: N/A (not needed for this Change) * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) Edit of https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#sect-optional-post-upgrade-tasks - will be done after approval from FESCO. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Packages that are no longer maintained are removed during a distribution upgrade. == Dependencies == None. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A == Documentation == N/A (not a System Wide Change) == Release Notes == TBD -- 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
Re: F36 Change: Retired Packages (Self-Contained Change proposal)
On 07/10/2021 17:45, Ben Cotton wrote: Subpackage `remove-retired-packages` has been created (subpackage of `fedora-upgrade`). I suggest integrating this functionality into dnf as a plugin. Example: sudo dnf clean-retired --releasever=32 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-35-20211007.n.0 compose check report
No missing expected images. Failed openQA tests: 13/204 (x86_64), 10/141 (aarch64) New failures (same test not failed in Fedora-35-20211006.n.0): ID: 1017531 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/1017531 ID: 1017554 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/1017554 ID: 1017563 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/1017563 ID: 1017567 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/1017567 ID: 1017571 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/1017571 ID: 1017577 Test: x86_64 Server-dvd-iso server_database_client URL: https://openqa.fedoraproject.org/tests/1017577 ID: 1017656 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1017656 ID: 1017674 Test: aarch64 Server-dvd-iso install_blivet_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1017674 ID: 1017680 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/1017680 ID: 1017750 Test: x86_64 universal install_blivet_with_swap URL: https://openqa.fedoraproject.org/tests/1017750 ID: 1017768 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1017768 ID: 1017792 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/1017792 ID: 1017819 Test: aarch64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/1017819 ID: 1017831 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1017831 ID: 1017842 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/1017842 ID: 1017862 Test: aarch64 universal install_anaconda_text@uefi URL: https://openqa.fedoraproject.org/tests/1017862 Old failures (same test failed in Fedora-35-20211006.n.0): ID: 1017614 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1017614 ID: 1017617 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1017617 ID: 1017627 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1017627 ID: 1017629 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/1017629 ID: 1017703 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1017703 ID: 1017726 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1017726 ID: 1017832 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1017832 Soft failed openQA tests: 2/204 (x86_64), 2/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-35-20211006.n.0): ID: 1017588 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1017588 ID: 1017642 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1017642 ID: 1017715 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1017715 ID: 1017733 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1017733 Passed openQA tests: 177/204 (x86_64), 128/141 (aarch64) New passes (same test not passed in Fedora-35-20211006.n.0): ID: 1017551 Test: x86_64 Server-dvd-iso install_resize_lvm URL: https://openqa.fedoraproject.org/tests/1017551 ID: 1017670 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/1017670 ID: 1017721 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1017721 ID: 1017812 Test: x86_64 universal upgrade_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1017812 ID: 1017860 Test: aarch64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/1017860 Skipped non-gating openQA tests: 13 of 345 Installed system changes in test x86_64 Server-dvd-iso install_default_upload: System load changed from 0.03 to 0.14 Previous test data: https://openqa.fedoraproject.org/tests/1016313#downloads Current test data: https://openqa.fedoraproject.org/tests/1017541#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 1 services(s) added since previous compose: fwupd.service System load changed from 1.50 to 0.62 Previous test data:
Re: [RFC] Remove supoort for NIS(+) from PAM
On 02/10/2021 15:27, James Szinger wrote: These days, I think FreeIPA or Active Directory are the best choices, but both are complicated and possibly too much for a SO/HO, workgroup, or departmental sysadmin. AD has the advantage of supporting Windows, MacOS, and Samba; the last time I looked FreeIPA was not good at this. While a FreeIPA server certainly doesn't come for free in regards to system resource consumption. And you need to relate to at least the webadmin at times. Under the hood it also surely is complicated, but from an every-day use is it that complicated? I'm running an IPA server at home on a VM which should have been given more memory, but it is functional and responsive enough. And I don't really think much about it. Adding new users is easy enough. And enrolling a new host and get it setup is also fairly straight forward (run `ipa-client-install` and optionally `ipa-client-automount`). Once the IPA client install has completed, logins usually work instantly with sudo access and whatever else you've configured in the domain. But it must be said ... I don't have any other hosts than Linux hosts at home. A more heterogeneous environment might bring in bigger challenges. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F36 Change: Retired Packages (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/RetiredPackages == Summary == Easy the task of removing packages, which were retired and no longer receives updates. == Owner == * Name: [[User:msuchy| Miroslav Suchý]] * Email: msu...@redhat.com == Detailed Description == This follows the [[Changes/Fedora-Retired-Packages]] which was withdrawn. This time I provide a script `remove-retired-packages` (presented in the package of the same name) which identifies packages retired between N-1 and current (N) version. Alternatively, user can run: remove-retired-packages 32 which will look for packages between Fedora Linux 32 and the current version. The packages are suggested to be removed one by one, which allows the admin to skip the package and keep it on their machine despite being retired. Part of this proposal is to change [https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#sect-optional-post-upgrade-tasks the documentation for the upgrade]. == Feedback == See [[Changes/Fedora-Retired-Packages#Feedback original feedback page]] [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XQMUSHK7HX65LQUJBFDNY47YPMCPI5MG/#XQMUSHK7HX65LQUJBFDNY47YPMCPI5MG Discussion] on devel mailing list prior this proposal. == Benefit to Fedora == * We suggest users to remove packages that are no longer maintained and may contain security vulnerabilities. * We make sure that archaic packages do not break upgrade between two versions of Fedora. == Scope == * Proposal owners: Subpackage `remove-retired-packages` has been created (subpackage of `fedora-upgrade`). * Other developers: N/A (not needed for this Change) * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) Edit of https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#sect-optional-post-upgrade-tasks - will be done after approval from FESCO. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Packages that are no longer maintained are removed during a distribution upgrade. == Dependencies == None. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A == Documentation == N/A (not a System Wide Change) == Release Notes == TBD -- 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: RISC-V -- are we ready for more, and what do we need to do it?
On 10/5/21 04:39, Richard W.M. Jones wrote: On Mon, Oct 04, 2021 at 12:07:30PM -0700, Kevin Fenzi wrote: On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote: Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk. In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck). We have avoided using emulation in the past because we would be chasing bugs in our emulation that aren't in real hardware and vice versa. How good is the emulation support? Do we know/have people who can fix things in it when we hit them? Tools folks: is emulation an option here? Or do we still forbid it? Qemu support for RISC-V is very good, it's actually used to develop some features (virtualization and SBI). We do know people who can fix it. If you have the money real hardware is also available now. Personally speaking I think the real barrier is someone with a large colourful hat putting up the money to hire a full time developer to work on the project. I know Wei FU(FAS: tekkamanninja) is actively working on porting Fedora to RISC-V. He has his BSP for D1 which he already put up a wiki[1]. I'm about to help him get LXQt desktop up on D1 soon. In current situation maybe it makes more sense to start thinking about making all RISC-V contributors work together rather than doing everything on each own, which would be much efficient. [1] https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner Rich. So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that. But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time? Well, one big thing is that it's been a while since we had any secondary arches and it's unclear how they would work today. In the distant past secondary arches had their own koji and builders and composes and releases and used koji-shadow to try and match up with primary koji. This was basically more than a full time job for someone and I am sure koji-shadow has atrophied in recent years, but perhaps at least some subset could be made to work again. On the other hand we could just add it into primary koji, but then it really really has to keep up or it's going to block everything else. So, probibly a 'secondary' koji and builders to start with to bootstrap and to gather info on how hard it is to keep up and good emulation is would be worthwhile, but it's gonna need some dedicated work. Perhaps we could get a up to date status report from folks working on this, answering such questions as: * How good is emulation support * What would it take to keep up with the other arches? Is that possible? * What device(s) would we want to target and could we get sufficent numbers of them for QA and devel folks to debug problems and test? * Are there folks who can bootstrap/shepard the koji shadowing process? I think RISC-V is pretty exciting, and I am happy to help as much as I can with adding it in. I think there's likely to be a lot of interest/growth in coming years for it. kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Zamir SUN GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E Want to know more about Fedora? Visit https://fedoraproject.org/wiki/ Ready to contribute? See https://whatcanidoforfedora.org/ 想了解更多中文资讯，访问 https://zh.fedoracommunity.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-35-20211007.0 compose check report
No missing expected images. Failed openQA tests: 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-35-20211005.0): ID: 1017889 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1017889 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-35-20211005.0): ID: 1017874 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/1017874 Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64) New passes (same test not passed in Fedora-IoT-35-20211005.0): ID: 1017868 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/1017868 ID: 1017882 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/1017882 Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: System load changed from 0.27 to 0.13 Previous test data: https://openqa.fedoraproject.org/tests/1015063#downloads Current test data: https://openqa.fedoraproject.org/tests/1017878#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.69 to 0.52 Previous test data: https://openqa.fedoraproject.org/tests/1015068#downloads Current test data: https://openqa.fedoraproject.org/tests/1017883#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
[EPEL-devel] Re: To buildroot, or not to buildroot
On Thu, Oct 7, 2021 at 9:44 AM Troy Dawson wrote: > > > > On Thu, Oct 7, 2021 at 6:28 AM Neal Gompa wrote: >> >> On Thu, Oct 7, 2021 at 9:24 AM Troy Dawson wrote: >> > >> > >> > >> > On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa wrote: >> >> >> >> On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson wrote: >> >> > >> >> > *this is worth a discussion in todays EPEL Steering Committee Meeting* >> >> > >> >> > It sounds like the epel9-next is going to startup by building against >> >> > the CS buildroot. Changing it at this time would cause a delay. >> >> > >> >> > Thus we need to write some "verify build deps are released" checker. I >> >> > have an idea of how to do this, so I'm willing to volunteer to write >> >> > and run something. >> >> > >> >> > But, it would be good to have some discussion to determine if we want >> >> > to keep using the CS buildroot for epel9-next, always. Or if we want >> >> > to use it just as a bootstrap mechanism, and then switch to building >> >> > just off the available CentOS Stream repos at some point. >> >> > >> >> > Thoughts? >> >> > Should we always use buildroot? Or just keep up until we're fairly >> >> > stable? >> >> > >> >> >> >> We should only use the buildroot repo for as long as we need to. The >> >> *sooner* we can switch to the published content, the better. >> > >> > >> > This was discussed at the EPEL Steering Committee meeting. Here is the >> > summary. >> > Someone correct me if I'm wrong. >> > >> > epel9-next: >> > - starts off building off CS buildroot >> > - I will write a "check if all build packages are in the normal repos" >> > checker, called "will it build" [1] >> > >> >> How are we going to know whether all the build-time and run-time >> packages are in the normal repos? We need to check generated >> dependencies too, especially now that it's possible to have dynamic >> BuildRequires! > > > run-time dependencies: > That's always been a problem, even without the buildroot. > But I will also be writing a "will it install" to go along with "will it > build" > > build-time dependencies: > Grab the root.log of the package build, and parse it. > This gets around any hidden and dynamic BuildRequires. > I've already written code that does this for Content Resolver, and checked it > against traditional dnf/libsolve dependency generation. > It was 98% equal, and those 2% were on packages where it was possible for > more than one package to be installed for a dependency, and for that, I'd > prefer going with the root.log. > > I think I've got everything I need already written, just in three separate > projects. > I really want to pull that code together and make "willit" > >> >> > epel9: >> > - Use normal RHEL 9 repos (AppStream, BaseOS, CRB) >> > >> > Checks/Tests/Future: (It's a little fuzzy on the timing of these) >> > >> > - grobisplitter >> > -- see if we really need to use grobisplitter >> > -- I'm a little fuzzy on how or when we are going to test this >> > >> >> With the retirement of the container-tools default module, >> grobisplitter will not be required at all unless we want to use it to >> support non-default modules. > > > That is the theory, yes, that grobisplitter isn't required. > But nobody was able to say that was for certain. Thus, it needs to be tested. > I've verified this with my internal build infrastructure, so yes, I know it's not required. Admittedly, it's not a Koji system, but I'm also not enabling any modules in my build environment right now. I'm rebuilding content from Rawhide targeting CentOS Stream 9 to get a list of initial EPEL 9 packages to build for work, which is how some of my requests to add stuff to CRB have come about[1][2][3]. This can also be verified when using something like mock with mock-core-configs v36 or higher, because I made the necessary adjustments to test building on CentOS Stream 9 the same way that Fedora Koji and the CentOS CBS would. [1]: https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/140 [2]: https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/139 [3]: https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/135 -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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] Re: To buildroot, or not to buildroot
On Thu, Oct 7, 2021 at 6:28 AM Neal Gompa wrote: > On Thu, Oct 7, 2021 at 9:24 AM Troy Dawson wrote: > > > > > > > > On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa wrote: > >> > >> On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson wrote: > >> > > >> > *this is worth a discussion in todays EPEL Steering Committee Meeting* > >> > > >> > It sounds like the epel9-next is going to startup by building against > the CS buildroot. Changing it at this time would cause a delay. > >> > > >> > Thus we need to write some "verify build deps are released" checker. > I have an idea of how to do this, so I'm willing to volunteer to write and > run something. > >> > > >> > But, it would be good to have some discussion to determine if we want > to keep using the CS buildroot for epel9-next, always. Or if we want to > use it just as a bootstrap mechanism, and then switch to building just off > the available CentOS Stream repos at some point. > >> > > >> > Thoughts? > >> > Should we always use buildroot? Or just keep up until we're fairly > stable? > >> > > >> > >> We should only use the buildroot repo for as long as we need to. The > >> *sooner* we can switch to the published content, the better. > > > > > > This was discussed at the EPEL Steering Committee meeting. Here is the > summary. > > Someone correct me if I'm wrong. > > > > epel9-next: > > - starts off building off CS buildroot > > - I will write a "check if all build packages are in the normal repos" > checker, called "will it build" [1] > > > > How are we going to know whether all the build-time and run-time > packages are in the normal repos? We need to check generated > dependencies too, especially now that it's possible to have dynamic > BuildRequires! > run-time dependencies: That's always been a problem, even without the buildroot. But I will also be writing a "will it install" to go along with "will it build" build-time dependencies: Grab the root.log of the package build, and parse it. This gets around any hidden and dynamic BuildRequires. I've already written code that does this for Content Resolver, and checked it against traditional dnf/libsolve dependency generation. It was 98% equal, and those 2% were on packages where it was possible for more than one package to be installed for a dependency, and for that, I'd prefer going with the root.log. I think I've got everything I need already written, just in three separate projects. I really want to pull that code together and make "willit" > > epel9: > > - Use normal RHEL 9 repos (AppStream, BaseOS, CRB) > > > > Checks/Tests/Future: (It's a little fuzzy on the timing of these) > > > > - grobisplitter > > -- see if we really need to use grobisplitter > > -- I'm a little fuzzy on how or when we are going to test this > > > > With the retirement of the container-tools default module, > grobisplitter will not be required at all unless we want to use it to > support non-default modules. > That is the theory, yes, that grobisplitter isn't required. But nobody was able to say that was for certain. Thus, it needs to be tested. 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
Fedora 35 compose report: 20211007.n.0 changes
OLD: Fedora-35-20211006.n.0 NEW: Fedora-35-20211007.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 4 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 144.95 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 3.74 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: gnome-software-41.0-2.fc35 Old package: gnome-software-41.0-1.fc35 Summary: A software center for GNOME RPMs: gnome-software gnome-software-devel gnome-software-rpm-ostree Size: 10.61 MiB Size change: 4.44 KiB Changelog: * Mon Oct 04 2021 Milan Crha - 41.0-2 - Resolves: #2009063 (Correct update notifications) Package: pew-1.2.0-13.fc35 Old package: pew-1.2.0-6.fc33 Summary: Tool to manage multiple virtualenvs written in pure Python RPMs: pew Size: 45.01 KiB Size change: 566 B Changelog: * Thu Jul 09 2020 Tadej Jane?? - 1.2.0-7 - Replace Python version glob with macro to support Python 3.10 - Drop conditionals for EOL Fedora releases * Tue Jul 28 2020 Fedora Release Engineering - 1.2.0-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Sat Aug 01 2020 Fedora Release Engineering - 1.2.0-9 - Second attempt - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Wed Jan 27 2021 Fedora Release Engineering - 1.2.0-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Fri Jun 04 2021 Python Maint - 1.2.0-11 - Rebuilt for Python 3.10 * Fri Jul 23 2021 Fedora Release Engineering - 1.2.0-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Fri Oct 01 2021 Tadej Jane?? - 1.2.0-13 - Backport upstream PR #214 to enable Pew to be used on recent Fedora versions - Simplify applying patches and remove obsolete if statement Package: python3-docs-3.10.0-1.fc35 Old package: python3-docs-3.10.0~rc2-1.fc35 Summary: Documentation for the Python 3 programming language RPMs: python3-docs Size: 6.99 MiB Size change: 2.91 KiB Changelog: * Mon Oct 04 2021 Miro Hron??ok - 3.10.0-1 - Update to 3.10.0 final Package: python3.10-3.10.0-1.fc35 Old package: python3.10-3.10.0~rc2-1.fc35 Summary: Version 3.10 of the Python interpreter RPMs: python-unversioned-command python3 python3-debug python3-devel python3-idle python3-libs python3-test python3-tkinter Size: 127.31 MiB Size change: -4.17 KiB Changelog: * Tue Sep 14 2021 Sahana Prasad - 3.10.0~rc2-2 - Rebuilt with OpenSSL 3.0.0 * Mon Oct 04 2021 Miro Hron??ok - 3.10.0-1 - Update to 3.10.0 final = DOWNGRADED PACKAGES =___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: To buildroot, or not to buildroot
On Thu, Oct 7, 2021 at 9:24 AM Troy Dawson wrote: > > > > On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa wrote: >> >> On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson wrote: >> > >> > *this is worth a discussion in todays EPEL Steering Committee Meeting* >> > >> > It sounds like the epel9-next is going to startup by building against the >> > CS buildroot. Changing it at this time would cause a delay. >> > >> > Thus we need to write some "verify build deps are released" checker. I >> > have an idea of how to do this, so I'm willing to volunteer to write and >> > run something. >> > >> > But, it would be good to have some discussion to determine if we want to >> > keep using the CS buildroot for epel9-next, always. Or if we want to use >> > it just as a bootstrap mechanism, and then switch to building just off the >> > available CentOS Stream repos at some point. >> > >> > Thoughts? >> > Should we always use buildroot? Or just keep up until we're fairly stable? >> > >> >> We should only use the buildroot repo for as long as we need to. The >> *sooner* we can switch to the published content, the better. > > > This was discussed at the EPEL Steering Committee meeting. Here is the > summary. > Someone correct me if I'm wrong. > > epel9-next: > - starts off building off CS buildroot > - I will write a "check if all build packages are in the normal repos" > checker, called "will it build" [1] > How are we going to know whether all the build-time and run-time packages are in the normal repos? We need to check generated dependencies too, especially now that it's possible to have dynamic BuildRequires! > epel9: > - Use normal RHEL 9 repos (AppStream, BaseOS, CRB) > > Checks/Tests/Future: (It's a little fuzzy on the timing of these) > > - grobisplitter > -- see if we really need to use grobisplitter > -- I'm a little fuzzy on how or when we are going to test this > With the retirement of the container-tools default module, grobisplitter will not be required at all unless we want to use it to support non-default modules. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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] Re: To buildroot, or not to buildroot
On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa wrote: > On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson wrote: > > > > *this is worth a discussion in todays EPEL Steering Committee Meeting* > > > > It sounds like the epel9-next is going to startup by building against > the CS buildroot. Changing it at this time would cause a delay. > > > > Thus we need to write some "verify build deps are released" checker. I > have an idea of how to do this, so I'm willing to volunteer to write and > run something. > > > > But, it would be good to have some discussion to determine if we want to > keep using the CS buildroot for epel9-next, always. Or if we want to use > it just as a bootstrap mechanism, and then switch to building just off the > available CentOS Stream repos at some point. > > > > Thoughts? > > Should we always use buildroot? Or just keep up until we're fairly > stable? > > > > We should only use the buildroot repo for as long as we need to. The > *sooner* we can switch to the published content, the better. > This was discussed at the EPEL Steering Committee meeting. Here is the summary. Someone correct me if I'm wrong. epel9-next: - starts off building off CS buildroot - I will write a "check if all build packages are in the normal repos" checker, called "will it build" [1] epel9: - Use normal RHEL 9 repos (AppStream, BaseOS, CRB) Checks/Tests/Future: (It's a little fuzzy on the timing of these) - grobisplitter -- see if we really need to use grobisplitter -- I'm a little fuzzy on how or when we are going to test this - "will it build" -- After a period of time, check and see if we are happy with the combination of CS buildroot + "will it build" ? --- Yes - determine if we want to keep it like this even after epel9 --- No - determine when the best/safest time to switch to normal repos Troy [1] - I plan on integrating "will it build" with a "will it install" checker. It will be called "will it" or "willit". I'm sorta excited about doing this. It's something I've wanted to do for a long time and I think I've finally got it figured out. ___ 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
Fedora Linux 35 Final Go/No-Go meeting next week
Hi everyone, It's that time already! The Fedora Linux 35 Fina Go/No-Go[1] meeting is scheduled for Thursday 14 October at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F35 Final for the 19 October early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10098/ [2] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- 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
[Test-Announce] Fedora Linux 35 Final Go/No-Go meeting next week
Hi everyone, It's that time already! The Fedora Linux 35 Fina Go/No-Go[1] meeting is scheduled for Thursday 14 October at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F35 Final for the 19 October early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10098/ [2] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
[Test-Announce] Fedora-IoT 35 RC 20211007.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora-IoT 35 RC 20211007.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_20211007.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_35_RC_20211007.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
[Fedocal] Reminder meeting : ELN SIG
Dear all, You are kindly invited to the meeting: ELN SIG on 2021-10-08 from 12:00:00 to 13:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: Source: https://calendar.fedoraproject.org//meeting/9920/ ___ 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: Get BR: %{py3_dist } working on EPEL7
On 07. 10. 21 4:43, Orion Poplawski wrote:
Would it be possible to get BuildRequires: %{py3_dist NAME} working on EPEL7?
At first I thought it was sufficient for epel-rpm-macros to require
python3-rpm-macros, but now I think we may need to override the definition of
py3_dist. In fedora it uses %python3_pkgversion, in RHEL7 it uses
%python3_version, and in RHEL8 "python3dist".
But %python3_version requires python to evaluate.
Presumably we're using %python3_version to allow for multiple python versions,
but I think we've given up on that in single spec files.
The use of %python3_version on RHEL7 was an attempted solution.
https://bugzilla.redhat.com/show_bug.cgi?id=1812665
But since it requires Python to evaluate, it didn't work.
https://bugzilla.redhat.com/show_bug.cgi?id=1812665#c11
I've suggested a new bugreport and than I forgot.
Not however that RHEL 7 is unlikely to get this fixed this late in the RHEL 7
lifetime, we would need to override the macro in EPEL.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
CPE Weekly Update - Week of October 04th 2021
Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on `#redhat-cpe` channel on libera.chat. - If you wish to read this in rendered markdown, check the post on discussion link https://discussion.fedoraproject.org/t/cpe-weekly-update-week-of-october-04th-2021/33558 . - *As October is the new quarter, we are about to overtake new projects, there are no new updates on non-rolling initiatives[0].* - *CentOS Stream team is continuing with their work:* - The work on the Mirror Manager has been completed - The work on the Automated Signing has been completed - Automatic Signing was broken on Monday night - Working on batch resigning packages still - Completed our October planning - aiming to work on - Content Resolver Docs - Compose Reporting - content changes between RHEL9/Stream 9 - Forming a plan of record for the work needed to align Stream 8 and Stream 9 workflows in the future - Technical debt movement - Jenkins updates, old image cleanups, etc. - *Infra and releng continues to take care of day to day business as initiatives team members are working with them to handover SOPs and maintenance tasks:* - *Fedora Infra* - 23 issue tickets were closed this week - Unfroze after beta and then froze again for F35 final - Merged a ton of pull requests that were pending - We have a possible fix to the sssd auth issues, many thanks sgallagh! - Updated all the proxies, including for the latest httpd CVE - Tracked down openQA worker instability to a kernel bug - We now have backups locally on netapp for Weblate content - *CentOS Infra* - Collaboration with Artwork SIG for new CentOS Stream 9 theme that will be pushed at release day. Preview at https://www.dev.centos.org and https://lists.dev.centos.org - CentOS Plus repo being worked on as a SIG (same process) through Core SIG (new GPG public key) and so building for Stream 8 (and eventually later Stream 9) on cbs.centos.org - Business as usual: - Sponsors leaving (decommissioning nodes in infra) - Relocate some services - Progress on the blocker for Stream 9 tests in CI - *Release Engineering* - Staging Bodhi deployment 5.7.1 - F35 final freeze - Removal of bot form `#releng` channel will happen after the freeze [0] With the rolling initiative, we mean the initiatives that will take longer than one quarter and they are not affected by the quarter cycle. That’s all of this week :) Kindest regards & on behalf of the CPE team, Thanks and regards, Akashdeep Dhar t0xic0...@fedoraproject.org akashd...@redhat.com ___ 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
flite update
Hi! I've updated flite from the ancient 1.3 to 2.2 in rawhide and I'm rebuilding speech-dispatcher in a side-tag (f36-build-side-46691). The other consumer is fawkes, which I'm not rebuilding as it doesn't use any of the new symbols and it should run with either 1.3 or 2.2 installed. flite 2.1 dropped some symbols (compared to 2.0 and 1.3) which was noticed by Debian (https://github.com/festvox/flite/issues/2) and upstream promised not to do it again, but they didn't bump the soname, either. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1997118] Upgrade perl-Proc-ProcessTable to 0.634
https://bugzilla.redhat.com/show_bug.cgi?id=1997118 Jitka Plesnikova changed: What|Removed |Added URL||https://metacpan.org/releas ||e/Proc-ProcessTable/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1997118 ___ 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 1997118] Upgrade perl-Proc-ProcessTable to 0.634
https://bugzilla.redhat.com/show_bug.cgi?id=1997118 Jitka Plesnikova changed: What|Removed |Added Summary|Upgrade |Upgrade |perl-Proc-ProcessTable to |perl-Proc-ProcessTable to |0.62|0.634 --- Comment #2 from Jitka Plesnikova --- Latest Fedora delivers 0.59 version. Upstream released 0.634. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1997118 ___ 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
Orphaning perl-Nagios-Plugin
I've just orphaned package perl-Nagios-Plugin. It was removed from CPAN by request of Nagios Enterprises, succeeded by Monitoring::Plugin which is in Fedora. Jitka -- Jitka Plesnikova Software Engineer Red Hat ___ 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: Get BR: %{py3_dist } working on EPEL7
On Wed, 2021-10-06 at 20:43 -0600, Orion Poplawski wrote:
> Would it be possible to get BuildRequires: %{py3_dist NAME} working
> on
> EPEL7? At first I thought it was sufficient for epel-rpm-macros to
> require python3-rpm-macros, but now I think we may need to override
> the
> definition of py3_dist. In fedora it uses %python3_pkgversion, in
> RHEL7
> it uses %python3_version, and in RHEL8 "python3dist".
>
> But %python3_version requires python to evaluate.
>
> Presumably we're using %python3_version to allow for multiple python
> versions, but I think we've given up on that in single spec files.
>
> Thoughts?
>
I think it is related with
https://bugzilla.redhat.com/show_bug.cgi?id=1812665
maybe we should open a new bug ...
--
Sérgio M. B.
___
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 2011755] New: Upgrade perl-DBIx-SearchBuilder to 1.71
https://bugzilla.redhat.com/show_bug.cgi?id=2011755 Bug ID: 2011755 Summary: Upgrade perl-DBIx-SearchBuilder to 1.71 Product: Fedora Version: rawhide Status: NEW Component: perl-DBIx-SearchBuilder Assignee: rc040...@freenet.de Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: lxt...@gmail.com, perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Latest Fedora delivers 1.69 version. Upstream released 1.71. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2011755 ___ 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-20211007.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-20211006.0): ID: 1017449 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1017449 ID: 1017457 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1017457 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 2011383] perl-CPANPLUS-Dist-Fedora-0.4.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2011383 --- Comment #1 from Fedora Update System --- FEDORA-2021-f6d98de4ef has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f6d98de4ef -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2011383 ___ 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 2011383] perl-CPANPLUS-Dist-Fedora-0.4.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2011383 --- Comment #2 from Fedora Update System --- FEDORA-2021-c7e5fc5c72 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c7e5fc5c72 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2011383 ___ 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 2011383] perl-CPANPLUS-Dist-Fedora-0.4.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2011383 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-CPANPLUS-Dist-Fedora-0 ||.4.4-1.fc36 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2011383 ___ 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 2011383] perl-CPANPLUS-Dist-Fedora-0.4.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2011383 Jitka Plesnikova changed: What|Removed |Added Doc Type|--- |If docs needed, set a value CC|i...@cicku.me, | |jples...@redhat.com | Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2011383 ___ 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: F34 Cloud Amazon AMIs unbootable after updates
On 10/7/21 3:52 AM, Richard Fearn wrote: > There is an issue with Xen instances (e.g. t2.small) - see > https://bugzilla.redhat.com/show_bug.cgi?id=2010058. > > What I saw was that it would hang for a couple of minutes waiting for > the disk to appear, then give up and go into emergency mode. > > The workaround is to edit the Dracut script that decides which modules > to include in the initramfs - to ensure that xen-blkfront is included. This also affects Qubes OS: https://github.com/QubesOS/qubes-issues/issues/6919. Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key 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 Java: The Death of Two SIGs
> Am 06.10.2021 um 17:04 schrieb Mikolaj Izdebski : > > On Tue, Oct 5, 2021 at 1:27 PM Peter Boy wrote: >> >> >> >>> Am 04.10.2021 um 15:29 schrieb Mikolaj Izdebski : >>> >>> On Mon, Oct 4, 2021 at 2:08 PM Peter Boy wrote: However, we lack concepts on how to proceed after removing java-maint-sig. What consequences do we draw from the analyses? >>> >>> … If you want >>> to improve docs, just do it. And so on. ... >>> ... or to plan editing the wiki. Whoever wants to clean up some wiki >>> pages can simply do so, without asking. >> >> It’s not as easy as you think of. That way you will end with the docs as >> Stephen Smoogen described 4 posts back, just chaos and misinformation. You >> need collaboration and agreement (shared plan) from participants in all >> affected areas - including you as the (main) developer of a core package >> (not writing text, but e.g check the concept, check technical correctness >> and completeness). It simply doesn’t work the way you are proposing. > > Sure, some major changes may indeed require planning or cooperation. > That's what we have the SIG and its communication channels for. For > example, if I wanted to rewrite Java documentation and move it from > the wiki to docs.fedoraproject.org at the same time, I would start > with sending a proposal to java-devel mailing list and ask for > feedback. We would discuss what should and what should not be > documented, who wants to document what and so on. Depending on how the > discussion goes there, I might propose an IRC meeting to ease the > discussion process. Thanks. I will make some suggestions once I get through my current backlog (in about 2 weeks). Of course, I'm also willing to actually write texts then (and keep them up to date). >> You are one of the developers without whose contributions the Fedora Java >> stack would probably collapse in a short time. I would really be interested >> in the same question as to Mat: With java-paint-sig removed, are you really >> completely content with the Fedora Java world? No change? No improvement >> anywhere? > > I'm happy with how Java SIG works in general - as an informal group > that does not limit packagers freedom, like by enforcing agile > processes, or mandating code review for every change. I like that Java > SIG doesn't have any authority to make any decisions - there can be > discussion, but ultimately each package owner makes decisions > …... > I also promise to document ongoing or planned projects that I am or > would like to be working on. Then anyone interested will be able to > more easily see what is going on, and possibly help with these > projects. Some of the projects that I have in mind: > Ongoing: > - MBI (Maven Bootstrap Initiative, an ability to build Maven and XMvn > fully from source from scratch, without reliance on pre-existing > binaries), > - Maven JDK bindings (ability to choose version of JDK used by Maven > at installation time), > - XMvn toolchains (ability to switch JDK used to build packages by > changing a single line of BuildRequires), > - embedded metadata for security scanners inside JARs (to reduce the > number of false-positives the scanners report), > - downstream patch tracking (similar to Debian DEP-3), > - updating Java packaging docs and moving them to docs.fedoraproject.org. > Planned or considered: > - redesign of auto-requires on JRE packages (bug 1993879), > - adding simple functional tests (smoke tests) for various packages, > - running upstream tests as gating tests (that allows running tests > that can't be ran during rpmbuild due to unpackaged dependencies), > - making use of gating and CI infrastructure to run generic Java tests > (that enforce packaging guidelines and bytecode version), > - browsable API documentation (javadocs extracted from RPMs and served > on a website), > - bringing back java-deptools (search engine for Java classes within > RPM packages that I used to host), > - updating Java Packaging HOWTO (writing missing sections, removing or > rewriting outdated parts). Many thanks for that valuable information! Am very glad (and think it's important) to read here such concrete and constructive perspectives alternatively to the posts that (overly) point out the weak points (which also exist, as in any somewhat more complex project) and that may spread a factually misleading message. >> And just in case you see some preferable improvement anywhere, what do you >> think should be done to promote and achieve this? > > I have no idea, other than doing the work myself and communicating > what I'm doing and why, hoping others will join the effort. I'm not > the best person to ask about promotion or community building. I hope I can help out here. Peter — Dr. Peter Boy Universität Bremen Mary-Sommerville-Str. 5 28359 Bremen Germany p...@uni-bremen.de www.uni-bremen.de Are you looking for a web content management system for scientific research
Re: F34 Cloud Amazon AMIs unbootable after updates
There is an issue with Xen instances (e.g. t2.small) - see https://bugzilla.redhat.com/show_bug.cgi?id=2010058. What I saw was that it would hang for a couple of minutes waiting for the disk to appear, then give up and go into emergency mode. The workaround is to edit the Dracut script that decides which modules to include in the initramfs - to ensure that xen-blkfront is included. Your issue might be something else - I didn't see a panic, like in the screenshot. You could try and get more of the log as plain text by going to Actions → Monitor and troubleshoot → Get system log. Regards, Rich On Thu, 7 Oct 2021 at 08:19, Richard W.M. Jones wrote: > > On Thu, Oct 07, 2021 at 12:46:11AM -0400, Christopher wrote: > > Running on EC2, it's kinda hard to get good information from a system > > that won't boot. The machine won't boot to the point of being able to > > capture the system log, and the screenshot of the instance doesn't > > appear to be super helpful: https://imgur.com/a/4PWcRSg > > Can you hit shift + PgUp and capture as much of the preceeding output > as possible? > > Also it's apparently possible to connect a serial console: > https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-serial-console.html > which would be the ideal way to debug this. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Richard Fearn richardfe...@gmail.com ___ 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-20211007.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-20211006.0): ID: 1017316 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1017316 ID: 1017324 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1017324 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: Onboarding package
Dne 06. 10. 21 v 20:06 Stephen Snow napsal(a): On Wed, 2021-10-06 at 18:39 +0200, Vít Ondruch wrote: --snip-- So it seems we are in agreement with the `dummy-onboarding-` prefix No, it should be something more appropriate like `entry-level-tutor-` Keep it coming please :) or something equally as nuetrally offensive. Dummy is a very negative word with no value of positive connotations in the English language. I have chosen this name mainly to be inline with what we already have: https://fedoraproject.org/wiki/DummyTestPackages and I'd like to avoid conflicts with other packages. However, you are right that there are probably better options. Vít regards, Stephen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 Cloud Amazon AMIs unbootable after updates
On Thu, Oct 07, 2021 at 12:46:11AM -0400, Christopher wrote: > Running on EC2, it's kinda hard to get good information from a system > that won't boot. The machine won't boot to the point of being able to > capture the system log, and the screenshot of the instance doesn't > appear to be super helpful: https://imgur.com/a/4PWcRSg Can you hit shift + PgUp and capture as much of the preceeding output as possible? Also it's apparently possible to connect a serial console: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-serial-console.html which would be the ideal way to debug this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 Cloud Amazon AMIs unbootable after updates
What appears to be our nightly AMI build for F34 with updates (125523088429/Fedora-Cloud-Base-34-20211006.0.x86_64-hvm-us-east-1-gp2-0) won't even start once (no updating required; it's immediately broken). The attachment won't go through on this list, but I captured the last lines from the system log on first boot. It looks like more lines like what was in the screenshot I previously shared. On Thu, Oct 7, 2021 at 12:46 AM Christopher wrote: > > Running on EC2, it's kinda hard to get good information from a system > that won't boot. The machine won't boot to the point of being able to > capture the system log, and the screenshot of the instance doesn't > appear to be super helpful: https://imgur.com/a/4PWcRSg > > On Wed, Oct 6, 2021 at 4:42 PM Joe Doss wrote: > > > > On 10/6/21 3:18 PM, Christopher wrote: > > > Hi, > > > > > > Has anybody else noticed that the Amazon Public Cloud images for F34 > > > (https://alt.fedoraproject.org/cloud/) no longer boot after the latest > > > updates? > > > > > > I had an instance that I've been keeping up-to-date with dnf system > > > upgrades and is now on F34, which is now unbootable after recent > > > updates within the last week. So I tried to create a new instance > > > using a newer base image at https://alt.fedoraproject.org/cloud/, and > > > that one is also now unbootable after doing a routine dnf update. > > > > > > Has anybody else seen this? > > > > > > Does anybody know which package update caused it? (I saw some > > > grub-related updates, but not sure if they are to blame) > > > > > > Does anybody know how to fix a currently broken instance and can share > > > their solution? > > > > Is there anything on the console log when you reboot it after the > > updates? If you can share the log that would be helpful. > > > > Joe > > > > > > > > > > -- > > Joe Doss > > j...@solidadmin.com > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [CoreOS] Fedora CoreOS Community Video Meeting 2021-10-06
Watching the recording now :) On Wed, Oct 6, 2021 at 8:53 PM Dusty Mabe wrote: > > > On 10/5/21 5:53 PM, Dusty Mabe wrote: > > Hi All, > > > > Tomorrow we will be holding a video meeting for the Fedora CoreOS > community. > > > > Harshal Patil will be joining us to give a brief overview of how Fedora > CoreOS is used > > for the e2e node tests in upstream Kubernetes. > https://github.com/coreos/fedora-coreos-tracker/issues/984 > > > > We'll also be discussing any meeting tickets and possibly revisit our > list of high level > > issues. > > > > > > Time: 16:30 UTC (same as normal) on Wednesday October 6th > > Location: https://meet.google.com/cgh-oxhd-axg (will be recorded) > > Agenda/Notes: https://hackmd.io/vMWlKGH5TAOsLKYiqce61Q > > > Thanks to everyone who attended! Here is a link to the meeting recording: > > > https://dustymabe.fedorapeople.org/meetings/2021-10-06_FCOS-Community-Meeting.mp4 > ___ > 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
