Fedora-Cloud-33-20201216.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20201215.0): ID: 741415 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/741415 ID: 741422 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/741422 Passed openQA tests: 6/7 (x86_64), 6/7 (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
[389-devel] 389 DS nightly 2020-12-16 - 93% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/12/16/report-389-ds-base-1.4.4.9-1.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[Bug 1908211] New: perl-Test2-Suite-0.000139 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1908211 Bug ID: 1908211 Summary: perl-Test2-Suite-0.000139 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test2-Suite Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.000139 Current version/release in rawhide: 0.000138-1.fc34 URL: http://search.cpan.org/dist/Test2-Suite/ 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/9536/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: gpg-agents all over the place
Kevin Kofler via devel writes:
Sam Varshavchik wrote:
> I miss the days when gpg needed a passphrase it simply prompted a message
> on standard output, turned off tty echo, and just read the password that I
> typed in.
>
> But that was too simple, primitive, and bulletproof. I guess that things
> can't be as simple any more, and the forward march of progress is
> unstoppable.
That approach simply does not work for GUI applications.
Sure. But it seems that more often that not making things work for GUI
applications must mean that plain text interface ends up being broken.
if (isatty(2))
{
/* Existing code, that prompts for a password or reads it from stdin */
}
else
{
/* The GUI equivalent */
}
Now, your terminal interface continues to work as before, and you can
provide a GUI interface too.
But, for some reason that I do not understand, the existing terminal
interface always gets broken.
pgpZndKZe7ZHK.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1907739] perl-DateTime-Locale-1.29 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1907739 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2020-1c831f619c has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-1c831f619c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1c831f619c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: heads up: nss 3.59 breaks firefox add-ons
On Wed, 2020-12-16 at 02:40 +0100, Alexander Ploumistos wrote: > Sorry to be a bother, but is there another side effect from having > this update installed on a server? As far as I could tell from the > discussion on the update page, only the sha1 signed firefox add-ons > are concerned, but I could be missing something. From the comments on the update I'm not sure *precisely* what the scope of the change is, but it's at least possible that the behaviour of anything that uses NSS for cryptography could have changed with this update. Things that don't use NSS won't be affected of course. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gpg-agents all over the place
Sam Varshavchik wrote: > I miss the days when gpg needed a passphrase it simply prompted a message > on standard output, turned off tty echo, and just read the password that I > typed in. > > But that was too simple, primitive, and bulletproof. I guess that things > can't be as simple any more, and the forward march of progress is > unstoppable. That approach simply does not work for GUI applications. Believe it or not, GNU/Linux is no longer a text-only operating system, nor are window managers just a container for terminal emulators. :-) 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
[Bug 1902872] perl-Date-Manip-6.83 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1902872 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Date-Manip-6.83-1.fc33 Resolution|--- |ERRATA Last Closed||2020-12-16 01:42:53 --- Comment #3 from Fedora Update System --- FEDORA-2020-81f2d61744 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1905896] perl-libnet-3.12 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1905896 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-libnet-3.12-1.fc34 |perl-libnet-3.12-1.fc34 ||perl-libnet-3.12-1.fc33 Resolution|--- |ERRATA Last Closed||2020-12-16 01:42:19 --- Comment #5 from Fedora Update System --- FEDORA-2020-e307fe0d5e has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1903541] perl-Encode-3.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1903541 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Encode-3.08-458.fc34 |perl-Encode-3.08-458.fc34 ||perl-Encode-3.08-458.fc33 Resolution|--- |ERRATA Last Closed||2020-12-16 01:41:19 --- Comment #5 from Fedora Update System --- FEDORA-2020-d9d43bbfe0 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: heads up: nss 3.59 breaks firefox add-ons
Sorry to be a bother, but is there another side effect from having this update installed on a server? As far as I could tell from the discussion on the update page, only the sha1 signed firefox add-ons are concerned, but I could be missing something. ___ 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
Release rpkg-1.62 and fedpkg-1.40
Hi all, a new version rpkg-1.62 together with fedpkg-1.40 are released containing both features and bugfixes. Currently, Fedora 33 and Fedora 32 are present in stable repositories. epel7, epel8 are in the testing repositories, feel free to try these waiting distributions in Bodhi. Version for epel6 won't be released (the previous version wasn't released either). Changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.62.html https://docs.pagure.org/fedpkg/releases/1.40.html Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.62-1.el8=rpkg-1.62-1.el7=rpkg-1.62-1.fc32=rpkg-1.62-1.fc33=rpkg-1.62-1.fc34=fedpkg-1.40-1.el8=fedpkg-1.40-1.el7=fedpkg-1.40-1.fc32=fedpkg-1.40-1.fc33=fedpkg-1.40-1.fc34 Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg=1 https://bodhi.fedoraproject.org/updates/?packages=fedpkg=1 rpkg is also available from PyPI. Thanks to all contributors. Regards ___ 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
Re: gpg-agents all over the place
Marius Schwarz writes: Hi, I sorry to tell you, that gpg-agents are inflating on numbers in Fedora systems: I miss the days when gpg needed a passphrase it simply prompted a message on standard output, turned off tty echo, and just read the password that I typed in. But that was too simple, primitive, and bulletproof. I guess that things can't be as simple any more, and the forward march of progress is unstoppable. The most simple interface I could get working these days is the curses pinentry. And that was no easy task to set up. I had to do some serious googling around, and sifting through the manual pages, to come up with the right set of spells and magic woids and phrases (I'm channeling Bugs Bunny) to make it happen. it would be more effective, if you give any programm who needs it, the password directly, instead of having useless processes laying around ;) Nah. That's too simple of a solution. https://bugzilla.redhat.com/show_bug.cgi?id=1895012 Any changes will likely need to originate upstream; I'll be surprised if there'll be any Fedora-originated development on this topic. Systemd opens gpg-agents even for mailserver daemons, which do not need nor know how to use them. Oh, sure. I had a nagging feeling something was missing, here. systemd, that's it. No idea what caused this invasion lately, but bugreports about it, get ignored. The drive to fix this needs to come upstream. But nobody pays attention any more to the simpletons like us, who like to work in a terminal or, heavens forbid, an ssh connection. Or (and I know how this can be shocking to hear) run build scripts. Everyone expects to have pretty windows, menu, dialogs, and animated gophers to join them on their quest to use gpg. Hence, the agent. Could someone please take a look and fix it, if it's bug. I would be very happy if someday I can simply run gpg(2) and have it simply prompt me for my password, by default, without me having to fiddle anything, not gpg-agent.conf, not anything else. Alas, I've resigned to those simpler days being just a fond memory. pgpendVy3XHgz.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: heads up: nss 3.59 breaks firefox add-ons
Hi Jerry, > On Tue, Dec 15, 2020 at 5:08 PM Alexander Ploumistos > > You're a gmail user like me. Between approximately 90 and 30 minutes > ago, I had several people call me to ask why I had deleted my email > account. Email sent to me was bouncing back with a message that the > account did not exist. Then I started receiving email again about 30 > minutes ago. I don't know what happened, but something seems to have > hiccupped over at Google. You're right, another Google outage has been reported and after managing to figure out the time zones in the reports, it does coincide with the time frame of the missing messages. Mystery solved. Thank you! A. ___ 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e44d8312da rclone-1.53.3-1.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-37ef75d1ce chromium-87.0.4280.88-1.el8 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c82583d07e pngcheck-2.4.0-5.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing cacti-1.2.16-1.el8 cacti-spine-1.2.16-1.el8 gfal2-2.18.2-2.el8 mbedtls-2.16.9-1.el8 mock-2.8-1.el8 python-colcon-bundle-0.1.0-1.el8 python-colcon-lcov-result-0.5.0-1.el8 python-deprecated-1.2.10-1.el8 python-kubernetes-11.0.0-6.el8 Details about builds: cacti-1.2.16-1.el8 (FEDORA-EPEL-2020-29c3568efc) An rrd based graphing tool Update Information: Update to 1.2.16 Release notes: https://www.cacti.net/release_notes.php?version=1.2.16 ChangeLog: * Mon Dec 14 2020 Morten Stevens - 1.2.16-1 - Update to 1.2.16 cacti-spine-1.2.16-1.el8 (FEDORA-EPEL-2020-29c3568efc) Threaded poller for Cacti written in C Update Information: Update to 1.2.16 Release notes: https://www.cacti.net/release_notes.php?version=1.2.16 ChangeLog: * Mon Dec 14 2020 Morten Stevens - 1.2.16-1 - Update to 1.2.16 gfal2-2.18.2-2.el8 (FEDORA-EPEL-2020-5b569bb89f) Grid file access library 2.0 Update Information: Upgrade to upstream release 2.18.2 ChangeLog: * Tue Dec 15 2020 Michal Simon - 2.18.2-1 - Upgrade to upstream release 2.18.2 mbedtls-2.16.9-1.el8 (FEDORA-EPEL-2020-fe42686452) Light-weight cryptographic and SSL/TLS library Update Information: Update to 2.16.9 Release notes: https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.9 ChangeLog: * Mon Dec 14 2020 Morten Stevens - 2.16.9-1 - Update to 2.6.19 * Thu Oct 15 2020 Morten Stevens - 2.16.8-2 - Drop support for pkcs11 and zlib mock-2.8-1.el8 (FEDORA-EPEL-2020-e8977f0629) Builds packages inside chroots Update Information: fix use of nspawn https://github.com/rpm-software-management/mock/pull/679 Mock v2.7 Release notes: https://github.com/rpm-software- management/mock/wiki/Release-Notes-2.7 - bootstrap: copy-in katello CA pem file if exists - early error when bootstrap is off and external buildrequires are detected (msu...@redhat.com) - hotfix preexec_fn traceback on RHEL 8 s390x (issue 653) - introduce external buildrequires (msu...@redhat.com) - add rpkg spec preprocessing capability (cl...@fedoraproject.org) - sign plugin: don't ignore signing command failure - don't setsid() twice with --shell - better logging when dynamic BR detected (msu...@redhat.com) - do not TB if rpmbuild fails with exit code 11 (msu...@redhat.com) - fix addrepo when repo is missing (markus.linn...@gmail.com) - own the cheat directory - Allow percent-sign in config_opts['resultdir'] - add a new "postupdate" hook (dture...@redhat.com) - log mock's NVR ChangeLog: * Tue Dec 15 2020 Pavel Raiskup 2.8-1 - fix use of nspawn (#678) (awill...@redhat.com) - file_util: Improve an error message (tbae...@redhat.com) * Mon Nov 30 2020 Pavel Raiskup 2.7-1 - bootstrap: copy-in katello CA pem file if exists - early error when bootstrap is off and external buildrequires are detected (msu...@redhat.com) - hotfix preexec_fn traceback on RHEL 8 s390x (issue 653) - introduce external buildrequires (msu...@redhat.com) - add rpkg spec preprocessing capability (cl...@fedoraproject.org) - sign plugin: don't
Re: heads up: nss 3.59 breaks firefox add-ons
On Tue, Dec 15, 2020 at 5:08 PM Alexander Ploumistos wrote: > Off topic, is there a way to see the message headers in Hyperkitty? > I'm trying to figure out why 4 messages in this thread were never > delivered to me. You're a gmail user like me. Between approximately 90 and 30 minutes ago, I had several people call me to ask why I had deleted my email account. Email sent to me was bouncing back with a message that the account did not exist. Then I started receiving email again about 30 minutes ago. I don't know what happened, but something seems to have hiccupped over at Google. If anybody tried to send me email over the last couple of hours, I probably didn't get it. Please try again. -- Jerry James http://www.jamezone.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
Re: heads up: nss 3.59 breaks firefox add-ons
Off topic, is there a way to see the message headers in Hyperkitty? I'm trying to figure out why 4 messages in this thread were never delivered to me. ___ 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
Re: heads up: nss 3.59 breaks firefox add-ons
On Wed, Dec 16, 2020 at 12:45 AM Adam Williamson wrote: > > On Tue, 2020-12-15 at 17:59 -0500, Steven A. Falco wrote: > > On 12/15/20 5:09 PM, Adam Williamson wrote: > > > On Tue, 2020-12-15 at 22:38 +0100, Alexander Ploumistos wrote: > > > > On Tue, Dec 15, 2020 at 9:04 PM Alexander Ploumistos > > > > wrote: > > > > > > > > > > On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi wrote: > > > > > > > > > > > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox > > > > > > add-ons > > > > > > will stop working. Worse they will appear corrupted, so you will > > > > > > have to > > > > > > remove them and re-install them (after downgrading nss). > > > > > > > > > > I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33 > > > > > installed since it hit my local updates-testing mirror and all my > > > > > add-ons are looking good. > > > > > > > > So, I spoke too soon. I just got notified that one of my add-ons is > > > > misbehaving and it has been disabled. I'm still on the same session I > > > > was when I sent the previous message, nothing was installed or updated > > > > in the meantime. Is this bug time-based or something? > > > > > > You didn't answer the question whether you had restarted Firefox since > > > installing the new nss. I never received the above message. To answer the question, according to my dnf history the update to nss was installed almost 24 hours ago and by the time the bug appeared I had already shut down and restarted my computer at least three times, firefox itself had been restarted a few times more. > > > > > > Either way, probably Firefox is doing a periodic check of installed > > > add-ons and that fails whenever it happens now. The issue is they're > > > signed with SHA-1 certs, but nss is now not accepting SHA-1 per the > > > current system-wide policy. Since I did not want to reconfigure all of my add-ons, I restored a two-day-old backup of the ~/.mozilla folder (after renaming the existing one) and oddly, the toolbar buttons of my add-ons were invisible. I had to disable and re-enable them to get them to appear. Firefox containers still had to be reinstalled and I can't understand why. The backup was from before the problematic nss update, is something else stored outside ~/.mozilla ? ___ 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
Re: What is the most time consuming task for you as packager?
On Tue, 2020-12-15 at 18:29 -0500, Matthew Miller wrote: > On Tue, Dec 15, 2020 at 04:44:49PM -0600, Michael Cronenworth wrote: > > Can we make the Bodhi update notes part of the git repo? Ex. ChangeLog.md > > I would definitely like to see a consolidated changelog. I don't know if it > should be part of the git repo, or just a changelog convention. (Like: > any lines starting with > get put into the notes for the next bodhi update?) My traditional note that anything along these lines should be optional. I frequently submit multi-package updates, and want to write the update text directly, separate from package commit messages and changelogs. For me, the description of "this update containing five new package builds" is completely different from the package-level description of any one of those new builds. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: heads up: nss 3.59 breaks firefox add-ons
On Tue, 2020-12-15 at 17:59 -0500, Steven A. Falco wrote: > On 12/15/20 5:09 PM, Adam Williamson wrote: > > On Tue, 2020-12-15 at 22:38 +0100, Alexander Ploumistos wrote: > > > On Tue, Dec 15, 2020 at 9:04 PM Alexander Ploumistos > > > wrote: > > > > > > > > On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi wrote: > > > > > > > > > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons > > > > > will stop working. Worse they will appear corrupted, so you will have > > > > > to > > > > > remove them and re-install them (after downgrading nss). > > > > > > > > I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33 > > > > installed since it hit my local updates-testing mirror and all my > > > > add-ons are looking good. > > > > > > So, I spoke too soon. I just got notified that one of my add-ons is > > > misbehaving and it has been disabled. I'm still on the same session I > > > was when I sent the previous message, nothing was installed or updated > > > in the meantime. Is this bug time-based or something? > > > > You didn't answer the question whether you had restarted Firefox since > > installing the new nss. > > > > Either way, probably Firefox is doing a periodic check of installed > > add-ons and that fails whenever it happens now. The issue is they're > > signed with SHA-1 certs, but nss is now not accepting SHA-1 per the > > current system-wide policy. > > Since there is no great way for end-users to motivate the various add-on > creators to update their certs, this sounds like a serious problem. > > For now I've put an exclude in my dnf.conf to prevent any nss upgrades, but > that is also not a great solution, for obvious reasons. Perhaps there will > have to be a way for end-users to override the check for critical add-ons. > Hopefully the add-on creators will eventually switch certs, but that could > take a very long time. To be clear, the update is not stable for F33 and should not go stable. It's only in updates-testing. I wrote in the update that in my opinion the solution for this bug can't involve expecting add-ons to suddenly get re-signed en masse, or users to change their local configuration. It needs to keep working as it did before. If the policy is ahead of the real world, the policy needs to be loosened. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the most time consuming task for you as packager?
On Tue, Dec 15, 2020 at 6:29 pm, Matthew Miller wrote: I would definitely like to see a consolidated changelog. I don't know if it should be part of the git repo, or just a changelog convention. (Like: any lines starting with > get put into the notes for the next bodhi update?) +1 to consolidated changelog. Changelog should really not be part of the spec file anymore. ___ 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
Re: What is the most time consuming task for you as packager?
On Tue, Dec 15, 2020 at 04:44:49PM -0600, Michael Cronenworth wrote: > Can we make the Bodhi update notes part of the git repo? Ex. ChangeLog.md I would definitely like to see a consolidated changelog. I don't know if it should be part of the git repo, or just a changelog convention. (Like: any lines starting with > get put into the notes for the next bodhi update?) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: heads up: nss 3.59 breaks firefox add-ons
On 12/15/20 5:09 PM, Adam Williamson wrote: On Tue, 2020-12-15 at 22:38 +0100, Alexander Ploumistos wrote: On Tue, Dec 15, 2020 at 9:04 PM Alexander Ploumistos wrote: On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi wrote: If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons will stop working. Worse they will appear corrupted, so you will have to remove them and re-install them (after downgrading nss). I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33 installed since it hit my local updates-testing mirror and all my add-ons are looking good. So, I spoke too soon. I just got notified that one of my add-ons is misbehaving and it has been disabled. I'm still on the same session I was when I sent the previous message, nothing was installed or updated in the meantime. Is this bug time-based or something? You didn't answer the question whether you had restarted Firefox since installing the new nss. Either way, probably Firefox is doing a periodic check of installed add-ons and that fails whenever it happens now. The issue is they're signed with SHA-1 certs, but nss is now not accepting SHA-1 per the current system-wide policy. Since there is no great way for end-users to motivate the various add-on creators to update their certs, this sounds like a serious problem. For now I've put an exclude in my dnf.conf to prevent any nss upgrades, but that is also not a great solution, for obvious reasons. Perhaps there will have to be a way for end-users to override the check for critical add-ons. Hopefully the add-on creators will eventually switch certs, but that could take a very long time. Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the most time consuming task for you as packager?
On Tue, Dec 15, 2020, 5:29 PM Miroslav Suchý wrote: > I am looking for challenges for upcoming year - what I and my team should > enhance. I have some ideas, but I want to hear > yours. > > What you - as Fedora packager - find most time consuming on packaging? > Where you will welcome more simplicity or automation? > Deciphering whatever packaging guidelines have changed since the last time I looked and trying to figure out how to update packages to adhere to them even though nobody audits the package set anyway. Followed closely by taking whatever the upstream tracking service does and manually applying it and rebuilding it. It would be so much better if it just filed a PR and kicked off a scratch build as part of the ci. josh ___ 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
Re: What is the most time consuming task for you as packager?
On 12/15/20 11:29 PM, Miroslav Suchý wrote: I am looking for challenges for upcoming year - what I and my team should enhance. I have some ideas, but I want to hear yours. Thanks for doing this! What you - as Fedora packager - find most time consuming on packaging? Coordination and communication ;) Where you will welcome more simplicity or automation? In testing an impact of a change. E.g. a simple "upgrade to newer version" change might be a problem if it breaks other packages. I usually spin up a copr repo and try to rebuild every dependent package in it. However, there are time consuming challenges with this: 1) False failures. Sometimes, the copr build fails for random reason (Koji repo is not available, etc.). I need to read the logs and figure it out, resubmit the build. 2) Unrelated failures. Many packages FTBFS for unrelated reasons. I need to spin up another (control) copr and rebuild all failures there as well to make sure it's indeed unrelated. 3) Cross-related failures. Some packages only fail in the test copr because they "see" other packages from that test copr and some of them are different from what Fedora rawhide offers (e.g. because git HEAD is newer than what has been built in Koji / passed CI in github). I sometimes need to create more isolated coprs with my change to rule this out. Ideally, I'd like to see a CI job for this that handles this on the background. If you'd like to hear more about the manual workflow, I'd be happy to meet over video. (The workflow is heavily based on https://github.com/fedora-stewardship/fedora-stewardship.github.io/blob/master/scripts/review_pr.py but recently, I prefer the new Copr's dist-git option.) -- 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
Re: What is the most time consuming task for you as packager?
On 12/15/20 4:29 PM, Miroslav Suchý wrote: What you - as Fedora packager - find most time consuming on packaging? Where you will welcome more simplicity or automation? Pushing updates requires too many steps, IMHO. 1. 2. fedpkg mockbuild 3. 4. fedpkg commit -p 5. fedpkg build 6. fedpkg update ... Can we make the Bodhi update notes part of the git repo? Ex. ChangeLog.md If not, could a file be referenced instead of a "--notes" argument? Ex. --notes-file ChangeLog.md Stretch goal: Bodhi update defaults (inc. notes?) as part of git, too. Ex. update.yml Step 4 could then become the final step: fedpkg commit -p -b -u (-b = build, -u = send update if build is successful) Regards, Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: MinGW environment and toolchain update (System-Wide Change proposal)
On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/F34MingwEnvToolchainUpdate > > == Summary == > Update the MinGW base environment and toolchain to the latest upstream > stable releases. > > == Owner == > * Name: [[User:smani|Sandro Mani]] > * Email: manisan...@gmail.com > > > == Detailed Description == > > The following packages will be updated > > * mingw-gcc to version 11.x > * mingw-w64-tools to version 8.x > * mingw-winpthreads to version 8.x > * mingw-crt to version 8.x > * mingw-headers to version 8.x > * mingw-binutils to version 2.36 > * mingw-gdb to version 10.x This would be great, thanks Sandro. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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
What is the most time consuming task for you as packager?
I am looking for challenges for upcoming year - what I and my team should enhance. I have some ideas, but I want to hear yours. What you - as Fedora packager - find most time consuming on packaging? Where you will welcome more simplicity or automation? -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Epel 8 (and 9) build against what?
On Tue, Dec 15, 2020 at 02:36:40PM -0700, Jeff Sheltren wrote: > Is nobody concerned with the implications (or irony?) of building an open > source project on top of a proprietary platform? I assume you mean RHEL. RHEL is not a proprietary platform — it's silly to call it that. Look at Rocky Linux and CloudLinux. And, you know, the Oracle one. And Amazon Linux. And all of the source code is 100% available. But also, ironic or not, EPEL is already built on RHEL. -- Matthew Miller Fedora Project Leader ___ 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
Re: koji buildsystem changes
Dne 15. 12. 20 v 11:39 Panu Matilainen napsal(a): > BTW, I'm not aware of the details how the images are built these days, but of > course *something* will still need to > build those images, That is normal podman image of Fedora. Strictly speaking you will still need to have compatibility with latest released Fedora (I guess we do not have rawhide podman images, right?). But once you have that image you can run the Mock on anything archaic. As long as the thing is capable of running podman. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: heads up: nss 3.59 breaks firefox add-ons
On Tue, 2020-12-15 at 22:38 +0100, Alexander Ploumistos wrote: > On Tue, Dec 15, 2020 at 9:04 PM Alexander Ploumistos > wrote: > > > > On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi wrote: > > > > > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons > > > will stop working. Worse they will appear corrupted, so you will have to > > > remove them and re-install them (after downgrading nss). > > > > I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33 > > installed since it hit my local updates-testing mirror and all my > > add-ons are looking good. > > So, I spoke too soon. I just got notified that one of my add-ons is > misbehaving and it has been disabled. I'm still on the same session I > was when I sent the previous message, nothing was installed or updated > in the meantime. Is this bug time-based or something? You didn't answer the question whether you had restarted Firefox since installing the new nss. Either way, probably Firefox is doing a periodic check of installed add-ons and that fails whenever it happens now. The issue is they're signed with SHA-1 certs, but nss is now not accepting SHA-1 per the current system-wide policy. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Epel 8 (and 9) build against what?
Am 15.12.20 um 18:02 schrieb Matthew Miller: On Tue, Dec 15, 2020 at 05:43:28PM +0100, Pavel Raiskup wrote: Notable problem if we switched from CentOS to RHEL in Mock configuration is that several build dependencies will be missing. RHEL 8 doesn't e.g. ship e.g. the *-devel packages (this problem, if I understand it correctly, is slowly worked-around by CentOS-only packages). As I understand it, these are available as part of "CodeReady Linux Builder" with the developer subscription. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/package_manifest/codereadylinuxbuilder-repository not all - there are still missing devel packages (intentionally). -- Leon ___ 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
[Bug 1908132] New: perl-DateTime-Format-Strptime-1.78 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1908132 Bug ID: 1908132 Summary: perl-DateTime-Format-Strptime-1.78 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DateTime-Format-Strptime Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.78 Current version/release in rawhide: 1.77-3.fc33 URL: http://search.cpan.org/dist/DateTime-Format-Strptime/ 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/7088/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[EPEL-devel] Re: Epel 8 (and 9) build against what?
On Tue, Dec 15, 2020 at 11:00:15AM +0100, Miroslav Suchý wrote: > Regarding the recent announcement of CentOS 8 flipping to CentOS Stream - > What will be the configs for building EPEL 8? > I mean mock configs? And I ask as Mock maintainer - because I have no idea. I don't think you need to panic and try and decide something now. I'd stick with the way it is now, and perhaps revisit it in 6months or so when things might be more clear. > Are we going to build EPEL 8 against CentOS stream? What will happen when > CentOS stream flip to RHEL 9 based content > > https://wiki.centos.org/FAQ/CentOSStream#What_happens_when_CentOS_Stream_switches_from_RHEL_8_to_RHEL_9_based_content.3F > ? There will still be centos8 stream for a year... kevin signature.asc Description: PGP signature ___ 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
Re: heads up: nss 3.59 breaks firefox add-ons
On Tue, Dec 15, 2020 at 9:04 PM Alexander Ploumistos wrote: > > On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi wrote: > > > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons > > will stop working. Worse they will appear corrupted, so you will have to > > remove them and re-install them (after downgrading nss). > > I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33 > installed since it hit my local updates-testing mirror and all my > add-ons are looking good. So, I spoke too soon. I just got notified that one of my add-ons is misbehaving and it has been disabled. I'm still on the same session I was when I sent the previous message, nothing was installed or updated in the meantime. Is this bug time-based or something? ___ 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
[EPEL-devel] Re: Epel 8 (and 9) build against what?
On Tue, Dec 15, 2020 at 2:16 PM Miroslav Suchý wrote: > Dne 15. 12. 20 v 16:44 Matthew Miller napsal(a): > > Or just the no-cost RHEL developer subscription? > > From Terms and conditions: > https://developers.redhat.com/terms-and-conditions > > ``` > Examples of such violations include, but are not limited to ... > * using the services provided under the Program for a production > installation, > ``` > > Is Copr production installation? > > Even if we solve this for Copr (yeah doable) then it is huge complication > for 3rd party ISV as anyone building localy > package for RHEL on top of EPEL will need Developer subscription. :( > > > Is nobody concerned with the implications (or irony?) of building an open source project on top of a proprietary platform? -Jeff ___ 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
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
Wim Taymans wrote on Tue, Dec 15, 2020: > > In particular I'm worried alsa programs will stop working. > > There is a pipewire-alsa package to support alsa programs Aha! I had missed it, thanks. > > Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's > > pulseaudio implementation? > > It is but then you go through an extra layer of emulation, it's better to > remove the pulseaudio one and use the pipewire one if you remove the > pulseaudio daemon. Definitely, I agree pipewire-alsa suffices and is better (although I'm not sure alsa-plugins-pulseaudio should have unfullfilled dependncies from pipewire-pulseaudio, it's probably saner to have it autoremoved by default to avoid multiple interfaces to the same service) > > or some new alsa-plugins-pipewire should be pulled in at least to > > keep things working one way or another) > > Yes, it should somehow be pulled in, how should that be done? A Suggests: > for pipewire-pulse maybe? I'm not too familiar on this, but a recommends (rather than suggests which will likely be ignored by dnf afaiu) on pipewire-pulseaudio sounds good despite being not directly related to pulseaudio. I'm honestly not sure what would be best, but pulling it without the pipewire service enable sounds more harmful than good... pipewire-pulseaudio sounds like a good reinsurance that pipewire will likely be running. Note: I've now switched packages and also had to enable/start the service: systemctl --user enable --now pipewire-pulse.socket I would suggest installing a preset file that would tell systemd to enable it by default if possible? It looks like pipewire.socket has one from /usr/lib/systemd/user-preset/90-default-user.preset (in fedora-release-common-33-2.noarch) which wasn't obvious to find, I didn't check if fedora34 also enables pipewire-pulse but if not it definitely should (or pipewire should ship its own presets) Thanks, -- Dominique ___ 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
[Bug 1908112] New: perl-DateTime-Locale-1.30 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1908112 Bug ID: 1908112 Summary: perl-DateTime-Locale-1.30 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DateTime-Locale Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.30 Current version/release in rawhide: 1.29-1.fc34 URL: http://search.cpan.org/dist/DateTime-Locale/ 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/6477/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/golang1.16
== Summary ==
Rebase of Golang package to upcoming version 1.16 in Fedora 34,
including the rebuild of all dependent packages(the pre-release
version of Go will be used for the rebuild if released version will
not be available at the time of the mass rebuild).
== Owner ==
* Name: [[User:Jcajka| Jakub Čajka]], [[User:alexsaezm| Alejandro Sáez
Morollón]]
* Email: jca...@redhat.com, alexsa...@redhat.com
== Detailed Description ==
Rebase of Golang package to upcoming version 1.16 in Fedora 34. Golang
1.16 is scheduled to be released in February 2021.
Due to Go packages' current nature and state, the rebuild of dependent
packages will be required.
== Benefit to Fedora ==
Stay closely behind upstream by providing the latest release of Go,
which includes improved support of the risc-v processor architecture
and added support for aarch64 based darwin(macOS) machines, among
other bug fixes, enhancements and new features. For a complete list of
changes, see upstream change notes at
https://tip.golang.org/doc/go1.16 . Therefore Fedora will be providing
a reliable development platform for Go language and projects written
in it.
== Scope ==
* Proposal owners: Rebase Golang package in Fedora 34, help resolve
possible issues found
* Other developers: Fix possible issues, with help from Golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild. Tracking
issue.[https://pagure.io/releng/issue/9904]
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
;0.
:a) Install golang 1.16 from rawhide and use it to build your
application(s)/package(s).
:b) Scratch build against rawhide.
;1.
:Your application/package built using golang 1.16 should work as expected.
== User Experience ==
None
== Dependencies ==
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
Omitted due to the number of packages listed ~1600.
Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.
== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.15.X if
significant issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No
== Documentation ==
https://tip.golang.org/doc/go1.16
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
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
Fedora 34 Change: MinGW environment and toolchain update (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/F34MingwEnvToolchainUpdate == Summary == Update the MinGW base environment and toolchain to the latest upstream stable releases. == Owner == * Name: [[User:smani|Sandro Mani]] * Email: manisan...@gmail.com == Detailed Description == The following packages will be updated * mingw-gcc to version 11.x * mingw-w64-tools to version 8.x * mingw-winpthreads to version 8.x * mingw-crt to version 8.x * mingw-headers to version 8.x * mingw-binutils to version 2.36 * mingw-gdb to version 10.x == Benefit to Fedora == Ship the latest available MinGW environment and GNU toolchain. == Scope == * Proposal owners: The above mentioned packages will be updated. Build failures following the mass rebuild will be inspected. * Other developers: * Release engineering: Impact check [https://pagure.io/releng/issue/9903] * Release engineering: Mass rebuild requested * Policies and guidelines: No policies need to be changed == Upgrade/compatibility impact == No impact == How To Test == Update the system once the updated packages land, look out for new build failures etc. == User Experience == The features of the newest MinGW environment and GNU Toolchain will be available to the users. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert to older versions of environment / toolchain, mass rebuild mingw packages again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No == Release Notes == Fedora 34 comes with the mingw-w64-8 environment, mingw-gcc-11, mingw-gdb-10' and mingw-binutils 2.36. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream 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
Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/golang1.16
== Summary ==
Rebase of Golang package to upcoming version 1.16 in Fedora 34,
including the rebuild of all dependent packages(the pre-release
version of Go will be used for the rebuild if released version will
not be available at the time of the mass rebuild).
== Owner ==
* Name: [[User:Jcajka| Jakub Čajka]], [[User:alexsaezm| Alejandro Sáez
Morollón]]
* Email: jca...@redhat.com, alexsa...@redhat.com
== Detailed Description ==
Rebase of Golang package to upcoming version 1.16 in Fedora 34. Golang
1.16 is scheduled to be released in February 2021.
Due to Go packages' current nature and state, the rebuild of dependent
packages will be required.
== Benefit to Fedora ==
Stay closely behind upstream by providing the latest release of Go,
which includes improved support of the risc-v processor architecture
and added support for aarch64 based darwin(macOS) machines, among
other bug fixes, enhancements and new features. For a complete list of
changes, see upstream change notes at
https://tip.golang.org/doc/go1.16 . Therefore Fedora will be providing
a reliable development platform for Go language and projects written
in it.
== Scope ==
* Proposal owners: Rebase Golang package in Fedora 34, help resolve
possible issues found
* Other developers: Fix possible issues, with help from Golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild. Tracking
issue.[https://pagure.io/releng/issue/9904]
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
;0.
:a) Install golang 1.16 from rawhide and use it to build your
application(s)/package(s).
:b) Scratch build against rawhide.
;1.
:Your application/package built using golang 1.16 should work as expected.
== User Experience ==
None
== Dependencies ==
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
Omitted due to the number of packages listed ~1600.
Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.
== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.15.X if
significant issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No
== Documentation ==
https://tip.golang.org/doc/go1.16
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
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
Fedora 34 Change: MinGW environment and toolchain update (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/F34MingwEnvToolchainUpdate == Summary == Update the MinGW base environment and toolchain to the latest upstream stable releases. == Owner == * Name: [[User:smani|Sandro Mani]] * Email: manisan...@gmail.com == Detailed Description == The following packages will be updated * mingw-gcc to version 11.x * mingw-w64-tools to version 8.x * mingw-winpthreads to version 8.x * mingw-crt to version 8.x * mingw-headers to version 8.x * mingw-binutils to version 2.36 * mingw-gdb to version 10.x == Benefit to Fedora == Ship the latest available MinGW environment and GNU toolchain. == Scope == * Proposal owners: The above mentioned packages will be updated. Build failures following the mass rebuild will be inspected. * Other developers: * Release engineering: Impact check [https://pagure.io/releng/issue/9903] * Release engineering: Mass rebuild requested * Policies and guidelines: No policies need to be changed == Upgrade/compatibility impact == No impact == How To Test == Update the system once the updated packages land, look out for new build failures etc. == User Experience == The features of the newest MinGW environment and GNU Toolchain will be available to the users. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert to older versions of environment / toolchain, mass rebuild mingw packages again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No == Release Notes == Fedora 34 comes with the mingw-w64-8 environment, mingw-gcc-11, mingw-gdb-10' and mingw-binutils 2.36. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream 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
Re: heads up: nss 3.59 breaks firefox add-ons
On Tuesday, December 15, 2020 8:04:24 PM WET Alexander Ploumistos wrote: > > I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33 > installed since it hit my local updates-testing mirror and all my > add-ons are looking good. Could there be something else that's causing > trouble? I have the following from the nss family: > nss-3.59.0-2.fc33.i686 > nss-3.59.0-2.fc33.x86_64 > nss-softokn-3.59.0-2.fc33.i686 > nss-softokn-3.59.0-2.fc33.x86_64 > nss-softokn-freebl-3.59.0-2.fc33.i686 > nss-softokn-freebl-3.59.0-2.fc33.x86_64 > nss-sysinit-3.59.0-2.fc33.x86_64 > nss-util-3.59.0-2.fc33.i686 > nss-util-3.59.0-2.fc33.x86_64 Did you restart firefox since updating? -- José Abílio___ 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
Re: heads up: nss 3.59 breaks firefox add-ons
On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi wrote: > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons > will stop working. Worse they will appear corrupted, so you will have to > remove them and re-install them (after downgrading nss). I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33 installed since it hit my local updates-testing mirror and all my add-ons are looking good. Could there be something else that's causing trouble? I have the following from the nss family: nss-3.59.0-2.fc33.i686 nss-3.59.0-2.fc33.x86_64 nss-softokn-3.59.0-2.fc33.i686 nss-softokn-3.59.0-2.fc33.x86_64 nss-softokn-freebl-3.59.0-2.fc33.i686 nss-softokn-freebl-3.59.0-2.fc33.x86_64 nss-sysinit-3.59.0-2.fc33.x86_64 nss-util-3.59.0-2.fc33.i686 nss-util-3.59.0-2.fc33.x86_64 ___ 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
Re: heads up: nss 3.59 breaks firefox add-ons
On Tuesday, December 15, 2020 7:17:21 PM WET Kevin Fenzi wrote: > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons > will stop working. Worse they will appear corrupted, so you will have to > remove them and re-install them (after downgrading nss). > > For now, downgrade nss or avoid updating to it until things can get > sorted out. > > https://bugzilla.redhat.com/show_bug.cgi?id=1908018 > > kevin Thank you Kevin for the note. I had updated by I downgraded thanks to you. :-) Regards, -- José Abílio___ 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
heads up: nss 3.59 breaks firefox add-ons
If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons will stop working. Worse they will appear corrupted, so you will have to remove them and re-install them (after downgrading nss). For now, downgrade nss or avoid updating to it until things can get sorted out. https://bugzilla.redhat.com/show_bug.cgi?id=1908018 kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: drop "Test installation media" from live media
On Mon, Dec 14, 2020 at 11:03:03PM -0700, Chris Murphy wrote: > Right. The two I've previously suggested: btrfs seed and dm-verity. > Every read is verified, the user can't opt out, and they are more > performant than checkisomd5. Upon detecting error, both emit EIO which > is handled at the application level, i.e. stop the installation and > notify the user. Those would require significant changes to how live works though. Simple is better. If squashfs has integrity checking it would be perfect :) It looks like zstd has support for checksums but it doesn't look like that's supported in any of the tools, or the kernel squashfs module. Another possibility is for lmc to add a sha256sum of the rootfs image that can be checked by dracut when booting, or anaconda before installing. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ 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
Re: Reducing noise on devel list
On Sat, Dec 5, 2020 at 6:24 PM Kevin Fenzi wrote: > I'm a bit torn by this. The rawhide report has actually triggered > conversation (less than 3 weeks ago) and I find it usefull to point out > things. I also find the rawhide reports (at least occasionally) useful, as being the early canaries for potentially more interesting issues. However, subscribing to one more list is not really that hard, so if most people find those reports to be only noise, eliminating sending them to devel (which the project encourages one to do) is probably the right thing to do. ___ 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
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
> Gary Buhrmaster wrote on Mon, Dec 14, 2020: > > With updates-testing enabled here, it's much better than last month (no > more gdm being removed), but there still are a few pulseaudio direct > dependencies: Steam from rpmfusion still conflicts with pipewire-pulseaudio as well. Until that conflict is resolved it is going to prevent a lot of people from being able to test pipewire since it will mean removing their ability to use steam and all of the games tied to it. ___ 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
Re: Reducing noise on devel list
On Tue, 2020-12-15 at 13:07 -0500, Robbie Harwood wrote: > Mauricio Tavares writes: > > > On Tue, Dec 15, 2020 at 12:18 PM Robbie Harwood wrote: > > > > > > Vít Ondruch writes: > > > > > > > I have setup filter ages ago and it moves such emails into subfolder. I > > > > still think this is preferable to moving them into different ML. > > > > > > I would like to disagree with the idea that everyone needing to create > > > their own filtration is preferable to putting them on a separate list. > > > > So giving people the option to decide what to do with their > > emails is less preferable than having 4-5 people decide for every > > single subscriber? > > Subscribing to two mailing lists instead of one isn't preventing you > from deciding what to do with your email. Well, the potential problem I see is that you have to *know* the other list exists. For a new Fedora user this isn't trivial. I've no idea how people find out about devel@ but I imagine it's linked all over the intarwebs, having existed for literal decades at this point. Right now if you sign up for devel@ for *whatever* reason, you find out about these report emails because they start showing up in your mailbox. If we move them to a separate list which *won't* be linked all over the intarwebs, how will people know the reports exist? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reducing noise on devel list
Mauricio Tavares writes: > On Tue, Dec 15, 2020 at 12:18 PM Robbie Harwood wrote: >> >> Vít Ondruch writes: >> >> > I have setup filter ages ago and it moves such emails into subfolder. I >> > still think this is preferable to moving them into different ML. >> >> I would like to disagree with the idea that everyone needing to create >> their own filtration is preferable to putting them on a separate list. > > So giving people the option to decide what to do with their > emails is less preferable than having 4-5 people decide for every > single subscriber? Subscribing to two mailing lists instead of one isn't preventing you from deciding what to do with your email. Let's keep this in proportion, please. This isn't oppression. Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
Hi, > In particular I'm worried alsa programs will stop working. There is a pipewire-alsa package to support alsa programs > Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's > pulseaudio implementation? It is but then you go through an extra layer of emulation, it's better to remove the pulseaudio one and use the pipewire one if you remove the pulseaudio daemon. > (I see there's also an alsa-plugins-jack, I guess that might work but I > don't have it installed right now; This should also work but again using an extra layer of emulation. > or some new alsa-plugins-pipewire > should be pulled in at least to keep things working one way or another) Yes, it should somehow be pulled in, how should that be done? A Suggests: for pipewire-pulse maybe? Wim On Tue, Dec 15, 2020 at 8:09 AM Dominique Martinet wrote: > Gary Buhrmaster wrote on Mon, Dec 14, 2020: > > On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab > > wrote: > > > > > # dnf swap pulseaudio pipewire-pulseaudio --allowerasing > > > > I needed to add --enablerepo=updates-testing > > With updates-testing enabled here, it's much better than last month (no > more gdm being removed), but there still are a few pulseaudio direct > dependencies: > # dnf swap pulseaudio pipewire-pulseaudio --allowerasing > Last metadata expiration check: 0:10:19 ago on Tue 15 Dec 2020 07:52:26 > CET. > Dependencies resolved. > > == > Package ArchVersion Repository > Size > > == > Installing: > pipewire-pulseaudio x86_64 0.3.17-3.fc33 updates-testing > 14 k > Upgrading: > pipewire x86_64 0.3.17-3.fc33 updates-testing > 118 k > pipewire-gstreamer x86_64 0.3.17-3.fc33 updates-testing > 52 k > pipewire-libsx86_64 0.3.17-3.fc33 updates-testing > 922 k > Removing: > pulseaudio x86_64 14.0-2.fc33 @updates-testing > 4.0 M > Removing dependent packages: > alsa-plugins-pulseaudio x86_64 1.2.2-3.fc33@fedora > 121 k > pulseaudio-module-bluetooth x86_64 14.0-2.fc33 @updates-testing > 231 k > pulseaudio-module-x11x86_64 14.0-2.fc33 @updates-testing > 78 k > xfce4-pulseaudio-plugin x86_64 0.4.3-3.fc33@fedora > 447 k > > > In particular I'm worried alsa programs will stop working. > Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's > pulseaudio implementation? > (I see there's also an alsa-plugins-jack, I guess that might work but I > don't have it installed right now; or some new alsa-plugins-pipewire > should be pulled in at least to keep things working one way or another) > > -- > Dominique > ___ > 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 > ___ 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
Re: Reducing noise on devel list
On Tue, Dec 15, 2020 at 12:18 PM Robbie Harwood wrote: > > Vít Ondruch writes: > > > I have setup filter ages ago and it moves such emails into subfolder. I > > still think this is preferable to moving them into different ML. > > I would like to disagree with the idea that everyone needing to create > their own filtration is preferable to putting them on a separate list. > So giving people the option to decide what to do with their emails is less preferable than having 4-5 people decide for every single subscriber? > Thanks, > --Robbie > ___ > 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 ___ 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
Re: Reducing noise on devel list
Vít Ondruch writes: > I have setup filter ages ago and it moves such emails into subfolder. I > still think this is preferable to moving them into different ML. I would like to disagree with the idea that everyone needing to create their own filtration is preferable to putting them on a separate list. Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: drop "Test installation media" from live media
On Tue, Dec 15, 2020 at 8:36 AM Matthew Miller wrote: > > On Mon, Dec 14, 2020 at 11:35:12PM -0700, Chris Murphy wrote: > > But also, we're not using unsquashfs for boot or installation. The > > squashfs image is loop mounted and treated as a random access file > > system. Decompression of blocks is on demand. > > Well, maybe we should? It makes a pretty fast test. :) It'll still boot as a random access device on loop. There's no place to unsquash it at this point. This change for Fedora 34 originally planned to use unsquashfs instead of rsync, but it's now optional. I'm not sure whether it will happen. https://fedoraproject.org/wiki/Changes/OptimizeSquashFSOnDVDByRemovingEXT4FilesystemImageLayer https://github.com/rhinstaller/anaconda/pull/2292 -- Chris Murphy ___ 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
[EPEL-devel] Re: Epel 8 (and 9) build against what?
On Tuesday, December 15, 2020 4:44:58 PM CET Matthew Miller wrote: > On Tue, Dec 15, 2020 at 08:30:21AM -0500, Stephen John Smoogen wrote: > > Honestly I don't know how to deal with regular EPEL-8 development after > > this. EPEL is going to add an epel-next which they would ask for additional > > targets in mock for. However that does not fix building against the regular > > EPEL-8 target. I expect it will depend on what programs come up for > > development in the coming year and if the new -devel RHEL UBI images can be > > used for mock. > > Or just the no-cost RHEL developer subscription? It seems like this is a > good use case for that, if it could be made easy enough that it isn't > painful for EPEL packagers. That would be sort of good for Copr (we now can not support EPEL s390x for example because there's no CentOS s390x). Could we use the devel subscriptions (on copr builders) for building epel-* targets against RHEL? Or could we get some special subscription for Copr purposes? Yes, so far we (copr) build EPEL against CentOS+EPEL (ditto users locally, with mock-core-configs.rpm). Pavel ___ 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
New Mock release v2.8
Just a quick heads-up, there is a new set of Bodhi updates with Mock 2.8 for rather important isolation regression, no matter configuration - mock 2.7 always used --isolation=simple. Otherwise it is small release. Please upgrade. Release notes: https://github.com/rpm-software-management/mock/wiki/Release-Notes-2.8 Fedora 33: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a2af39da40 Fedora 32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-96e2aa675f EPEL 8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e8977f0629 EPEL 7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3361ef3fc2 Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
gpg-agents all over the place
Hi, I sorry to tell you, that gpg-agents are inflating on numbers in Fedora systems: As far as I understand ssh-agents, you start ONE for each user, but here, one for each repo is opened by PackageKit: (today) root 2530 0.0 0.0 151908 892 ? Ss 14:32 0:00 gpg-agent --homedir /var/cache/PackageKit/32/metadata/updates-modular-32-x86_64.tmp/gpgdir --use-standard-socket --daemon root 2637 0.0 0.0 151908 896 ? Ss 14:32 0:00 gpg-agent --homedir /var/cache/PackageKit/32/metadata/rpmfusion-free-32-x86_64.tmp/gpgdir --use-standard-socket --daemon root 2653 0.0 0.0 151908 796 ? Ss 14:32 0:00 gpg-agent --homedir /var/cache/PackageKit/32/metadata/rpmfusion-nonfree-32-x86_64.tmp/gpgdir --use-standard-socket --daemon root 2668 0.0 0.0 151908 816 ? Ss 14:32 0:00 gpg-agent --homedir /var/cache/PackageKit/32/metadata/updates-32-x86_64.tmp/gpgdir --use-standard-socket --daemon root 2693 0.0 0.0 151908 860 ? Ss 14:32 0:00 gpg-agent --homedir /var/cache/PackageKit/32/metadata/fedora-32-x86_64.tmp/gpgdir --use-standard-socket --daemon root 2710 0.0 0.0 151908 708 ? Ss 14:32 0:00 gpg-agent --homedir /var/cache/PackageKit/33/metadata/updates-modular-33-x86_64.tmp/gpgdir --use-standard-socket --daemon root 2723 0.0 0.0 151908 896 ? Ss 14:32 0:00 gpg-agent --homedir /var/cache/PackageKit/33/metadata/updates-33-x86_64.tmp/gpgdir --use-standard-socket --daemon root 3393 0.0 0.0 151908 892 ? Ss 14:32 0:00 gpg-agent --homedir /var/cache/PackageKit/31/metadata/fedora-modular-31-x86_64.tmp/gpgdir --use-standard-socket --daemon root 3404 0.0 0.0 151908 712 ? Ss 14:32 0:00 gpg-agent --homedir /var/cache/PackageKit/31/metadata/rpmfusion-free-updates-31-x86_64.tmp/gpgdir --use-standard-socket --daemon root 3417 0.0 0.0 151908 800 ? Ss 14:32 0:00 gpg-agent --homedir /var/cache/PackageKit/31/metadata/updates-modular-31-x86_64.tmp/gpgdir --use-standard-socket --daemon root 3438 0.0 0.0 151908 812 ? Ss 14:32 0:00 gpg-agent --homedir /var/cache/PackageKit/31/metadata/rpmfusion-free-31-x86_64.tmp/gpgdir --use-standard-socket --daemon root 3451 0.0 0.0 151908 808 ? Ss 14:33 0:00 gpg-agent --homedir /var/cache/PackageKit/31/metadata/rpmfusion-nonfree-31-x86_64.tmp/gpgdir --use-standard-socket --daemon root 3464 0.0 0.0 151908 936 ? Ss 14:33 0:00 gpg-agent --homedir /var/cache/PackageKit/31/metadata/updates-31-x86_64.tmp/gpgdir --use-standard-socket --daemon root 3474 0.0 0.0 151908 948 ? Ss 14:33 0:00 gpg-agent --homedir /var/cache/PackageKit/31/metadata/rpmfusion-nonfree-updates-31-x86_64.tmp/gpgdir --use-standard-socket --daemon root 3492 0.0 0.0 151908 768 ? Ss 14:33 0:00 gpg-agent --homedir /var/cache/PackageKit/31/metadata/teamviewer-31-x86_64.tmp/gpgdir --use-standard-socket --daemon root 3512 0.0 0.0 151908 884 ? Ss 14:33 0:00 gpg-agent --homedir /var/cache/PackageKit/31/metadata/fedora-31-x86_64.tmp/gpgdir --use-standard-socket --daemon root 3526 0.0 0.0 151908 888 ? Ss 14:33 0:00 gpg-agent --homedir /var/cache/PackageKit/31/metadata/fedora-cisco-openh264-31-x86_64.tmp/gpgdir --use-standard-socket --daemon it would be more effective, if you give any programm who needs it, the password directly, instead of having useless processes laying around ;) https://bugzilla.redhat.com/show_bug.cgi?id=1895012 it's not even doing this for every system, as my private pc does not have those (upgraded by dnf, and yes, it's installed), but others do (upgraded by packagekit). Systemd opens gpg-agents even for mailserver daemons, which do not need nor know how to use them. https://bugzilla.redhat.com/show_bug.cgi?id=1877308 No idea what caused this invasion lately, but bugreports about it, get ignored. Could someone please take a look and fix it, if it's bug. best regards, Marius Schwarz ___ 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
Re: Proposal: drop "Test installation media" from live media
On Mon, Dec 14, 2020 at 11:35:12PM -0700, Chris Murphy wrote: > Squashfs doesn't have error detection for its metadata or the data > contained in it. I'm not sure why you're having such a high success > rate. Whether lossy or lossless compression algorithms in images, my > experience it is only sometimes results in an error, often we just get > artifacts. i.e. a bit flip turns into multiple wrong bytes of image > data, sometimes an entire row of pixels gets obliterated (thousands). > It just depends on what gets hit. But maybe lzma, which is what xz is > based on and what's used in squashfs images currently, could be > particularly susceptible to bit flips translating into something > detectable. It seems so. I mean, I can do more than a thousand tests if it helps, but that was enough to convince _me_. > But also, we're not using unsquashfs for boot or installation. The > squashfs image is loop mounted and treated as a random access file > system. Decompression of blocks is on demand. So I guess the next thing is: what's the error handling when the kernel hits an uncompress error when reading a compressed squashfs on the fly? It'd be kind of exciting if it logs an error we could actually watch for and pop up a message saying "so, yeah, your USB stick is bad" -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reducing noise on devel list
I have setup filter ages ago and it moves such emails into subfolder. I still think this is preferable to moving them into different ML. Vít Dne 05. 12. 20 v 19:23 Kevin Fenzi napsal(a): On Fri, Dec 04, 2020 at 03:43:04PM -0600, Dennis Gilmore wrote: Hi all, I filed https://pagure.io/fesco/issue/2512 asking FESCo to move all automated emails to a separate list where people who want to follow can, while I was part of the proliferation of compose reports coming here, there is now a great deal of them, and they no longer seem to trigger any conversation. I think that devel list would benefit from having all automated reports sent to a reports-list and letting people bring reports over when there is something to discuss. I was asked to bring the request to the list for people to weigh in. I'm a bit torn by this. The rawhide report has actually triggered conversation (less than 3 weeks ago) and I find it usefull to point out things. Perhaps we could keep the traditional rawhide report, but send the qa/compose test reports to another list? 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 OpenPGP_0x0CE09EE79917B87C.asc Description: application/pgp-keys 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
Re: Proposal: drop "Test installation media" from live media
On Mon, Dec 14, 2020 at 11:35:12PM -0700, Chris Murphy wrote: > But also, we're not using unsquashfs for boot or installation. The > squashfs image is loop mounted and treated as a random access file > system. Decompression of blocks is on demand. Well, maybe we should? It makes a pretty fast test. :) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rawhide Repo needs downgradeable packages
Dne 09. 12. 20 v 0:34 Kevin Kofler via devel napsal(a): That said, will "dnf downgrade" offer you cached versions that are no longer in the repos? Last I checked, it only offered me whatever was still in the repos, and I had to dig up the cached RPMs manually. Yes, right, that is why there was the other part of the email: Now if there was some dnf plugin, which would make repository from the cache, that would be super helpful. Vít OpenPGP_0x0CE09EE79917B87C.asc Description: application/pgp-keys 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
Fedora-Rawhide-20201215.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 6 of 43 required tests failed, 1 result missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 20/180 (x86_64), 16/122 (aarch64) New failures (same test not failed in Fedora-Rawhide-20201214.n.0): ID: 740695 Test: x86_64 Server-dvd-iso server_cockpit_default **GATING** URL: https://openqa.fedoraproject.org/tests/740695 ID: 740713 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/740713 ID: 740720 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/740720 ID: 740820 Test: aarch64 Server-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/740820 ID: 740925 Test: aarch64 universal install_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/740925 Old failures (same test failed in Fedora-Rawhide-20201214.n.0): ID: 740674 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/740674 ID: 740676 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/740676 ID: 740677 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/740677 ID: 740681 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/740681 ID: 740687 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/740687 ID: 740717 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/740717 ID: 740719 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/740719 ID: 740726 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/740726 ID: 740742 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/740742 ID: 740745 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/740745 ID: 740747 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/740747 ID: 740752 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/740752 ID: 740791 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/740791 ID: 740797 Test: aarch64 Server-dvd-iso server_cockpit_default@uefi URL: https://openqa.fedoraproject.org/tests/740797 ID: 740809 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/740809 ID: 740811 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/740811 ID: 740814 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/740814 ID: 740815 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/740815 ID: 740828 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/740828 ID: 740835 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/740835 ID: 740836 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/740836 ID: 740876 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/740876 ID: 740880 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/740880 ID: 740910 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/740910 ID: 740915 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/740915 ID: 740920 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/740920 ID: 740938 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/740938 ID: 740940 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/740940 ID: 740958 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/740958 ID: 740962 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/740962 ID: 740966 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/740966 Soft failed openQA tests: 80/180 (x86_64), 53/122 (aarch64) (Tests completed, but using a
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On Tue, Dec 15, 2020 at 5:06 AM Andrew C Aitchison
wrote:
>
> On Tue, 15 Dec 2020, Miro Hrončok wrote:
>
> > On 12/13/20 7:52 PM, Andrew C Aitchison wrote:
> >>
> >> On Sun, 13 Dec 2020, Miro Hrončok wrote:
> >>
> >>> Also, since you might want to bump the release independently in EPEL (e.g.
> >>> if we discover something was wrong in the way we have packaged this), I
> >>> recommend doing:
> >>>
> >>> %global rhelrelease 10
> >>> %global baserelease 1
> >>> Release: %{rhelrelease}.%{baserelease}%{?dist}
> >>> ...
> >>> Requires: qpdf-libs%{?_isa} = %{version}-%{rhelrelease}%{?dist}
> >>>
> >>> (Assuming qpdf has regular %{dist} and not some modularity artificial
> >>> value.)
> >>>
> >>> Note that I've named the EPEL part of the release "baserelease", so
> >>> rpmdev-bumpspec does the right thing.
> >>
> >> If rhelrelease updates to 10.1 which will win ?
> >> ... and if we have already bumped baserelease to 2 ?
> >>
> >> rhelreleasename
> >> baserelease
> >> 102qpdf-devel-10.2.epel.rpm
> >> 10.1qpdf-devel-10.1.rhel.rpm
> >>
> >> Which will win ?
> >
> > Right. Can we use ^ in EL8 to separate the RHEL and EPEL parts?
>
> "^" sorts after digits (at least in ASCII and Basic Latin), so
> can anyone check whether
> qpdf-devel-10^2.epel.rpm
> will trump
> qpdf-devel-100.1.rhel.rpm
> or
> qpdf-devel-10.3.rhel.rpm
> ?
> My recollection is that there have been several different
> implementations of parsers for version-release checks with different
> twisty paths for splitting sub-components.
> My last RedHat based system is SL6 (sorry I moved to Ubuntu to match
> work) so I couldn't do a reliable test myself.
>
Sorry I'm late in replying, but why don't you use
Release: %{rhelrelease}%{?dist}.%{baserelease}
rhelrelease baserelease name
10 2 qpdf-devel-10.el8.2.rpm
10.1 2qpdf-devel-10.1.el8.2.rpm
$ rpmdev-vercmp 10.el8.2 10.1.el8.2
10.el8.2 < 10.1.el8.2
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
[EPEL-devel] Re: Epel 8 (and 9) build against what?
On Tue, 15 Dec 2020 at 05:00, Miroslav Suchý wrote: > Regarding the recent announcement of CentOS 8 flipping to CentOS Stream - > What will be the configs for building EPEL 8? > I mean mock configs? And I ask as Mock maintainer - because I have no idea. > > Are we going to build EPEL 8 against CentOS stream? What will happen when > CentOS stream flip to RHEL 9 based content > > https://wiki.centos.org/FAQ/CentOSStream#What_happens_when_CentOS_Stream_switches_from_RHEL_8_to_RHEL_9_based_content.3F > ? > > Honestly I don't know how to deal with regular EPEL-8 development after this. EPEL is going to add an epel-next which they would ask for additional targets in mock for. However that does not fix building against the regular EPEL-8 target. I expect it will depend on what programs come up for development in the coming year and if the new -devel RHEL UBI images can be used for mock. -- Stephen J Smoogen. ___ 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
Fedora rawhide compose report: 20201215.n.0 changes
OLD: Fedora-Rawhide-20201214.n.0 NEW: Fedora-Rawhide-20201215.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 4 Dropped packages:1 Upgraded packages: 113 Downgraded packages: 0 Size of added packages: 882.31 KiB Size of dropped packages:9.69 MiB Size of upgraded packages: 1.72 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 390.02 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20201215.n.0-sda.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: cgreen-1.3.0-1.fc34 Summary: Modern unit test and mocking framework for C and C++ RPMs:cgreen cgreen-devel cgreen-runner Size:508.65 KiB Package: golang-github-nrdcg-desec-0.5.0-1.fc34 Summary: Go library for accessing the deSEC API RPMs:golang-github-nrdcg-desec-devel Size:21.62 KiB Package: gxkb-0.9.0-1.fc34 Summary: X11 keyboard indicator and switcher RPMs:gxkb Size:333.04 KiB Package: python-templated-dictionary-1.1-1.fc34 Summary: Dictionary with Jinja2 expansion RPMs:python3-templated-dictionary Size:19.00 KiB = DROPPED PACKAGES = Package: petsc4py-3.14.0-1.fc34 Summary: Python bindings for MPI PETSc RPMs:petsc4py-mpich-devel petsc4py-openmpi-devel python3-petsc4py-mpich python3-petsc4py-openmpi Size:9.69 MiB = UPGRADED PACKAGES = Package: R-servr-0.21-1.fc34 Old package: R-servr-0.20-1.fc34 Summary: Simple HTTP Server to Serve Static Files or Dynamic Documents RPMs: R-servr Size: 101.76 KiB Size change: -234 B Changelog: * Mon Dec 14 2020 Elliott Sales de Andrade - 0.21-1 - Update to latest version (#1907321) Package: R-tinytex-0.28-1.fc34 Old package: R-tinytex-0.27-1.fc34 Summary: Helper Functions to Install and Maintain TeX Live, and Compile LaTeX Documents RPMs: R-tinytex Size: 129.04 KiB Size change: 183 B Changelog: * Mon Dec 14 2020 Elliott Sales de Andrade - 0.28-1 - Update to latest version (#1907324) Package: abook-0.6.1-17.fc34 Old package: abook-0.6.1-16.fc33 Summary: Text-based addressbook program for mutt RPMs: abook Size: 518.18 KiB Size change: -6.67 KiB Changelog: * Mon Dec 14 2020 Dominik Mierzejewski 0.6.1-17 - add explicit BR on make - use modern macros - mark license text accordingly Package: aom-2.0.1-2.fc34 Old package: aom-2.0.1-1.fc34 Summary: Royalty-free next-generation video format RPMs: aom libaom libaom-devel Size: 9.68 MiB Size change: -91.32 KiB Changelog: * Tue Dec 15 2020 Robert-Andr?? Mauchin - 2.0.1-2 - Disable tests Package: argparse-manpage-1.5-1.fc34 Old package: argparse-manpage-1.4-4.fc33 Summary: Build manual page from Python ArgumentParser object RPMs: argparse-manpage python3-argparse-manpage Size: 46.56 KiB Size change: -8 B Changelog: * Mon Dec 14 2020 Pavel Raiskup - 1.5-1 - new release Package: atkmm-2.28.1-1.fc34 Old package: atkmm-2.24.3-6.fc33 Summary: C++ interface for the ATK library RPMs: atkmm atkmm-devel atkmm-doc Size: 1.26 MiB Size change: -75.76 KiB Changelog: * Mon Dec 14 2020 Kalev Lember - 2.28.1-1 - Update to 2.28.1 - Switch to meson build system - Update source URLs - Tighten -devel subpackage deps - Tighten soname globs Package: awscli-1.18.195-1.fc34 Old package: awscli-1.18.192-1.fc34 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.95 MiB Size change: 309 B Changelog: * Fri Dec 11 2020 Gwyn Ciesla - 1.18.193-1 - 1.18.193 * Mon Dec 14 2020 Gwyn Ciesla - 1.18.194-1 - 1.18.194 * Mon Dec 14 2020 Gwyn Ciesla - 1.18.195-1 - 1.18.195 Package: blueberry-1.4.1-1.fc34 Old package: blueberry-1.4.0-1.fc34 Summary: Bluetooth configuration tool RPMs: blueberry Size: 1.22 MiB Size change: 2.13 KiB Changelog: * Mon Dec 14 2020 Kevin Fenzi - 1.4.1-1 - Update to 1.4.1. Fixes bug #1906622 Package: cacti-1.2.16-1.fc34 Old package: cacti-1.2.15-1.fc34 Summary: An rrd based graphing tool RPMs: cacti Size: 20.33 MiB Size change: 24.66 KiB Changelog: * Mon Dec 14 2020 Morten Stevens - 1.2.16-1 - Update to 1.2.16 Package: cacti-spine-1.2.16-1.fc34 Old package: cacti-spine-1.2.15-1.fc34 Summary: Threaded poller for Cacti written in C RPMs: cacti-spine Size: 395.79 KiB Size change: 340 B Changelog: * Mon Dec 14 2020 Morten Stevens - 1.2.16-1 - Update to 1.2.16 Package: chrpath-0.16-14.fc34 Old package: chrpath-0.16-13.fc33 Summary: Modify rpath of compiled programs RPMs: chrpath Size: 148.35 KiB Size change: 199 B Changelog: * Mon Dec 14 2020 Jeff Law - 0.16-14 - Use autosetup and enable testsuite Package: cockpit-234
[EPEL-devel] Re: Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)
On Wed, Dec 9, 2020 at 6:15 AM Christopher Engelhard wrote: > > On 09.12.20 11:17, Miro Hrončok wrote: > > However, since CentOS Linux 8 (and 9!) will be no more, do we have some > > ideas how to handle this? Do we require all EPEL contributors to obtain > > the developer RHEL subscription (seems like a huge pain)? Do we switch > > to Oracle Linux (only half joking)? Do we try to fight this decision > > (however I am afraid I've exhausted my fight capacity on different > > decisions)? > > Intuitively, I think that requiring RHEL dev subscriptions would pretty > much kill EPEL packaging on Copr. Unless you specifically want to > create EPEL packages, why would you get and keep a RHEL dev subscription > when you could just not check the EPEL-boxes? > > From a purely technical perspective, i.e. pretending it were CentFork > Community Linux, are there reasons not to use Oracle Linux? Ignoring that Oracle gives me the heebie-jeebies, at this time, the only two reasonable options are: * CloudLinux's Project Lenix: https://blog.cloudlinux.com/announcing-open-sourced-community-driven-rhel-fork-by-cloudlinux * Oracle (Unmentionable) Linux: http://public-yum.oracle.com/index.html Oracle's variant is available now, but... yeah. The CloudLinux offering is supposed to become available in the next month or so. They don't seem to be terrible people and a lot of companies have been using their stuff for a while now, so I'm reasonably confident in their continual existence. If they're true to their word on their free RHEL clone offering, we could probably switch to it as the input for Mock and the Fedora COPR service. -- 真実はいつも一つ！/ 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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On Tue, 15 Dec 2020, Miro Hrončok wrote:
On 12/13/20 7:52 PM, Andrew C Aitchison wrote:
On Sun, 13 Dec 2020, Miro Hrončok wrote:
Also, since you might want to bump the release independently in EPEL (e.g.
if we discover something was wrong in the way we have packaged this), I
recommend doing:
%global rhelrelease 10
%global baserelease 1
Release: %{rhelrelease}.%{baserelease}%{?dist}
...
Requires: qpdf-libs%{?_isa} = %{version}-%{rhelrelease}%{?dist}
(Assuming qpdf has regular %{dist} and not some modularity artificial
value.)
Note that I've named the EPEL part of the release "baserelease", so
rpmdev-bumpspec does the right thing.
If rhelrelease updates to 10.1 which will win ?
... and if we have already bumped baserelease to 2 ?
rhelrelease name
baserelease
10 2 qpdf-devel-10.2.epel.rpm
10.1 qpdf-devel-10.1.rhel.rpm
Which will win ?
Right. Can we use ^ in EL8 to separate the RHEL and EPEL parts?
"^" sorts after digits (at least in ASCII and Basic Latin), so
can anyone check whether
qpdf-devel-10^2.epel.rpm
will trump
qpdf-devel-100.1.rhel.rpm
or
qpdf-devel-10.3.rhel.rpm
?
My recollection is that there have been several different
implementations of parsers for version-release checks with different
twisty paths for splitting sub-components.
My last RedHat based system is SL6 (sorry I moved to Ubuntu to match
work) so I couldn't do a reliable test myself.
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk___
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
[EPEL-devel] Re: Epel 8 (and 9) build against what?
On 12/15/20 11:00 AM, Miroslav Suchý wrote: Regarding the recent announcement of CentOS 8 flipping to CentOS Stream - What will be the configs for building EPEL 8? I mean mock configs? And I ask as Mock maintainer - because I have no idea. Are we going to build EPEL 8 against CentOS stream? What will happen when CentOS stream flip to RHEL 9 based content https://wiki.centos.org/FAQ/CentOSStream#What_happens_when_CentOS_Stream_switches_from_RHEL_8_to_RHEL_9_based_content.3F ? See this thread: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/WCFRJJ3JJFTGD6UMX7WOMCS4F2EVUM5X/ -- 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
[Test-Announce] Fedora 34 Rawhide 20201215.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 34 Rawhide 20201215.n.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 Notable package version changes: parted - 20201212.n.0: parted-3.3-8.fc34.src, 20201215.n.0: parted-3.3.52-1.fc34.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/34 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_34_Rawhide_20201215.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201215.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201215.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201215.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201215.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201215.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201215.n.0_Security_Lab 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 ___ 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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On 12/13/20 7:52 PM, Andrew C Aitchison wrote:
On Sun, 13 Dec 2020, Miro Hrončok wrote:
Also, since you might want to bump the release independently in EPEL (e.g. if
we discover something was wrong in the way we have packaged this), I recommend
doing:
%global rhelrelease 10
%global baserelease 1
Release: %{rhelrelease}.%{baserelease}%{?dist}
...
Requires: qpdf-libs%{?_isa} = %{version}-%{rhelrelease}%{?dist}
(Assuming qpdf has regular %{dist} and not some modularity artificial value.)
Note that I've named the EPEL part of the release "baserelease", so
rpmdev-bumpspec does the right thing.
If rhelrelease updates to 10.1 which will win ?
... and if we have already bumped baserelease to 2 ?
rhelrelease name
baserelease
10 2 qpdf-devel-10.2.epel.rpm
10.1 qpdf-devel-10.1.rhel.rpm
Which will win ?
Right. Can we use ^ in EL8 to separate the RHEL and EPEL parts?
--
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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On 12/13/20 7:21 PM, Stephen John Smoogen wrote:
Don't forget to move the following metadata to the main package:
Summary: Development files for QPDF library
Requires: qpdf-libs%{?_isa} = %{version}-%{release}
Do you mean the main package as qpdf ? We don't control that package.
No. I mean the main qpdf-devel package of the qpdf-devel component.
So when I've said "move" I should have said "copy" instead, sorry.
--
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
Fedora-IoT-33-20201215.0 compose check report
No missing expected images. Failed openQA tests: 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-33-20201204.0): ID: 740601 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/740601 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-33-20201204.0): ID: 740587 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/740587 Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: System load changed from 0.06 to 0.20 Previous test data: https://openqa.fedoraproject.org/tests/735776#downloads Current test data: https://openqa.fedoraproject.org/tests/740581#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
[Bug 1902203] perl-SNMP-Info-3.71 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1902203 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED CC||jples...@redhat.com Fixed In Version||perl-SNMP-Info-3.71-1.fc34 Resolution|--- |RAWHIDE Assignee|w...@gouldfamily.org|jples...@redhat.com Doc Type|--- |If docs needed, set a value Last Closed||2020-12-15 12:09:22 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1897829] perl-CDB_File-1.05 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1897829 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED CC||jples...@redhat.com Fixed In Version||perl-CDB_File-1.05-1.fc34 Resolution|--- |RAWHIDE Assignee|mmcki...@umich.edu |jples...@redhat.com Doc Type|--- |If docs needed, set a value Last Closed||2020-12-15 11:57:57 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1907739] perl-DateTime-Locale-1.29 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1907739 Jitka Plesnikova changed: What|Removed |Added Status|CLOSED |MODIFIED Resolution|RAWHIDE |--- Keywords||Reopened -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1907342] Upgrade perl-Test-WWW-Mechanize to 1.54
https://bugzilla.redhat.com/show_bug.cgi?id=1907342 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Test-WWW-Mechanize-1.5 ||4-1.fc34 ||perl-Test-WWW-Mechanize-1.5 ||4-1.fc33 Resolution|--- |RAWHIDE Last Closed||2020-12-15 11:11:14 --- Comment #1 from Jitka Plesnikova --- Built by corsepiu -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1907739] perl-DateTime-Locale-1.29 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1907739 --- Comment #1 from Fedora Update System --- FEDORA-2020-1c831f619c has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1c831f619c -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1907739] perl-DateTime-Locale-1.29 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1907739 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-DateTime-Locale-1.29-1 ||.fc34 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-12-15 11:07:44 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: koji buildsystem changes
On 12/15/20 12:25 PM, Panu Matilainen wrote: On 12/15/20 11:54 AM, Miroslav Suchý wrote: Dne 14. 12. 20 v 11:22 Panu Matilainen napsal(a): When I started working on rpm back in 2007, landing new features to rpm meant looking 5+ years in the horizon to have said feature running on a released RHEL running in the builder so people could start trying it out on rawhide, which meant that by then it was far, far too late to address any of the inevitable design flaws you get when doing something ... For me this is a career-long dream come true. THANK YOU for everybody in the involved in making it happen, one step at a time, over the years! Nice to hear :) But it is important to know that as long as bootstrap is big step, there is still hidden caveat: When any RPM or DNF package or any package they requires use some nice fancy feature which host's rpm does not recognize, then the bootstrap > will fail anyway. This is solved by bootstrap image feature https://github.com/rpm-software-management/mock/wiki/Feature-container-for-bootstrap which is still fresh feature - just one year old :) And so far not enabled in Koji. When *this* will be enabled in Koji, we can finally boost the RPM development to levels previously unimaginable. :) Ooh, nice! I thought there was that caveat but wasn't aware of this work. We came up with the basic idea about reusing existing pre-built images for the purpose on internal #rpm in early 2013 but I don't know if it ever got to mock developers ears back then. At any rate it's just awesome to see this all coming together now after all that time, what a nice x-mas present :) BTW, I'm not aware of the details how the images are built these days, but of course *something* will still need to build those images, and for all features to be usable in the "bootstrap package set", that something needs to be running latest rawhide, otherwise there are still limits to the feature set available to rpm itself and its dependencies. But these days, running a set of scripts in a container on rawhide is a very different goal from the olden days where it would've entailed booting an actual system running rawhide - people used to laugh hysterically for days at the mere idea... - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: koji buildsystem changes
> On Mon, Dec 14, 2020 at 12:08:59PM +0100, Vitaly Zaitsev via devel wrote: > > Feel free to convince maintainers: > > https://pagure.io/rpmdevtools/issue/63 > > kevin It's easier to provide my own rpmdevtools than convince the 'closed minded' maintainer. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: koji buildsystem changes
On 12/15/20 11:54 AM, Miroslav Suchý wrote: Dne 14. 12. 20 v 11:22 Panu Matilainen napsal(a): When I started working on rpm back in 2007, landing new features to rpm meant looking 5+ years in the horizon to have said feature running on a released RHEL running in the builder so people could start trying it out on rawhide, which meant that by then it was far, far too late to address any of the inevitable design flaws you get when doing something ... For me this is a career-long dream come true. THANK YOU for everybody in the involved in making it happen, one step at a time, over the years! Nice to hear :) But it is important to know that as long as bootstrap is big step, there is still hidden caveat: When any RPM or DNF package or any package they requires use some nice fancy feature which host's rpm does not recognize, then the bootstrap > will fail anyway. This is solved by bootstrap image feature https://github.com/rpm-software-management/mock/wiki/Feature-container-for-bootstrap which is still fresh feature - just one year old :) And so far not enabled in Koji. When *this* will be enabled in Koji, we can finally boost the RPM development to levels previously unimaginable. :) Ooh, nice! I thought there was that caveat but wasn't aware of this work. We came up with the basic idea about reusing existing pre-built images for the purpose on internal #rpm in early 2013 but I don't know if it ever got to mock developers ears back then. At any rate it's just awesome to see this all coming together now after all that time, what a nice x-mas present :) - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Epel 8 (and 9) build against what?
Regarding the recent announcement of CentOS 8 flipping to CentOS Stream - What will be the configs for building EPEL 8? I mean mock configs? And I ask as Mock maintainer - because I have no idea. Are we going to build EPEL 8 against CentOS stream? What will happen when CentOS stream flip to RHEL 9 based content https://wiki.centos.org/FAQ/CentOSStream#What_happens_when_CentOS_Stream_switches_from_RHEL_8_to_RHEL_9_based_content.3F ? -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ 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
Re: koji buildsystem changes
Dne 14. 12. 20 v 11:22 Panu Matilainen napsal(a): > > When I started working on rpm back in 2007, landing new features to rpm meant > looking 5+ years in the horizon to have > said feature running on a released RHEL running in the builder so people > could start trying it out on rawhide, which > meant that by then it was far, far too late to address any of the inevitable > design flaws you get when doing something ... > For me this is a career-long dream come true. THANK YOU for everybody in the > involved in making it happen, one step at a > time, over the years! Nice to hear :) But it is important to know that as long as bootstrap is big step, there is still hidden caveat: When any RPM or DNF package or any package they requires use some nice fancy feature which host's rpm does not recognize, then the bootstrap will fail anyway. This is solved by bootstrap image feature https://github.com/rpm-software-management/mock/wiki/Feature-container-for-bootstrap which is still fresh feature - just one year old :) And so far not enabled in Koji. When *this* will be enabled in Koji, we can finally boost the RPM development to levels previously unimaginable. :) -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-32-20201215.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20201214.0): ID: 740567 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/740567 ID: 740574 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/740574 Passed openQA tests: 6/7 (x86_64), 6/7 (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
