Fedora-Cloud-33-20210311.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-20210310.0): ID: 808561 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/808561 ID: 808568 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/808568 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
Sorry for being not constructive. I'll try to explain my point of view. > Where are you seeing huge misunderstandings? In Fedora and other Linux communities (not eng, btw). > What misunderstandings are there? To my surprise, I saw how a person who perfectly knows the difference between Fedora Project and Fedora Linux distro, after reading the news about the renaming, only got confused in the difference. In discussions on news portals, I see that people do not understand the purpose of renaming. They discuss things like Linux vs GNU/Linux and Fedora distro vs Fedora Workstation (what?). This noise around does not contribute in any way to achive the main goal. > Are these misunderstandings the sole reason that your opinion is that > it's better to call the distribution just "Fedora", or are there other > reasons? There are few other reasons, of course. 1. Usually when I hear "Fedora", it is about Linux distro and it always clear from context. When it comes to EPEL, ELN and other things, most often other words are used (such as Fedora Project or Fedora EPEL). The difference can be understood from context anyway. 2. "Fedora" and "Fedora Linux" are understood and will be understood in the same way. People who are confused now will not stop confusing after renaming. 3. People will not stop talking "Fedora" instead of "Fedora Linux". There was a very good example about universuty renaming. Another example: 2001 - Mac OS X, 2012 - OS X, 2016 - MacOS. Apple returned to its roots, because many people did not even know that the correct name is OS X (and not Mac OS). And this despite the fact that they wrote everywhere OS X. 4. "Fedora" just nicer and simplier. Will "getfedora.org" be renamed to "getfedoralinux.org"? The devil is in the details here: general perception depends on little "nice and simple" things. > How would you address my concerns about messaging for > not-the-main-distro parts of the Fedora Project overall? I respect your concerns. But I think (and all my message about it) that renaming will not help. I have nothing against renaming by itself, but think it isn't really needed (according to Occam's razor). Initially, I did not want to discuss this at all, but after one incident with me in one of the Fedora-specific communities, I am now here and I am writing this. P. S. I'm new to the Fedora community. So I try to look at the problem from the outside. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] 389 DS nightly 2021-03-11 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/03/11/report-389-ds-base-2.0.3-20210311git19eb28db4.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On Wed, Mar 10, 2021 at 01:26:55PM +0100, Björn Persson wrote: > If we're going to name the distribution after some of its components, > why stop at one or two? ... > It's better to give the whole distribution its own name, and not name > it after any of its components. Fedora is a software distribution. It > contains Linux, many GNU components, RPM, MariaDB, Libreoffice and lots > of other things, but its name is "Fedora". Or call it "Fedora Software > Distribution" or anything else that doesn't single out any of the > components. That approach seems to minimize the political fighting. FreeBSD is just FreeBSD and BSD stands for Berkeley Software Distribution. Maybe we should use Fedora Software Distribution. But I rather like just plain "Fedora". signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1937584] New: perl-MooseX-Types-URI-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1937584 Bug ID: 1937584 Summary: perl-MooseX-Types-URI-0.09 is available Product: Fedora Version: rawhide Status: NEW Component: perl-MooseX-Types-URI Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.09 Current version/release in rawhide: 0.08-16.fc34 URL: https://metacpan.org/release/MooseX-Types-URI 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/18202/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On 3/10/21 11:21 PM, Ben Cotton wrote: On Wed, Mar 10, 2021 at 10:15 AM Robbi Nespu wrote: I got mixed feeling, I understand the reason why but I don't quite understand why you don't want to use "Fedora GNU/Linux". Read you comment on others email but the is not much details. Could you explain again in details? From the Community Blog post[1]: Why not use “Fedora GNU+Linux” or some similar name? We want to be easy to say. The more words we add, the harder that is. And while GNU is an important part of Fedora Linux, there are many other packages that make Fedora Linux what it is. “Linux” is, for better or worse, the commonly-understood phrasing, so let’s just use that. [1] https://communityblog.fedoraproject.org/fedora-is-a-community-fedora-linux-is-our-os/ Only for this reason? erk.. Never mind, just do the changes. I am happy as long "Fedora" keyword is there. We should stop wasting time about systemd OS identifier on which name to adopt. -- Email : Robbi Nespu PGP fingerprint : D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA PGP key : https://keybase.io/robbinespu/pgp_keys.asc OpenPGP_0x0C81FA303B3A80BA_and_old_rev.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
My vote: Fedora for the distro some want to rename Fedora Linux Fedora Project for the all-encompassing collection of things Fedora And now, back to more important things ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Reminder: Upcoming summer time changes
On Wed, 10 Mar 2021 10:56:52 -0500 Stephen Snow wrote: > On Wed, 2021-03-10 at 09:52 -0500, Ben Cotton wrote: > > > > 14 March — summer time begins in Canada, parts of Mexico, and the US > > Actually in Canada we have four seasons, so Springtime begins at or As do we in the UK, but BST isn't British Spring Time! Andrew ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Request to include package: coreboot
It has a build system in it to build the bios file then you flash it. It system can make more than one bios/uefi to flash to many different hardware. What is wrong with packaging the tool to do that? The worst you could get is a non-backdoor-ed firmware to boot from. *Shrugs* ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Schedule for Thursday's FPC Meeting (2021-03-11 17:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2021-03-11 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2021-03-11 09:00 PST US/Pacific 2021-03-11 12:00 EST --> US/Eastern <-- 2021-03-11 17:00 GMT Europe/London 2021-03-11 17:00 UTC UTC 2021-03-11 18:00 CET Europe/Berlin 2021-03-11 18:00 CET Europe/Paris 2021-03-11 22:30 IST Asia/Calcutta New Day: Friday - 2021-03-12 01:00 HKT Asia/Hong_Kong 2021-03-12 01:00 +08 Asia/Singapore 2021-03-12 02:00 JST Asia/Tokyo 2021-03-12 03:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting = Followup Actions = #topic #pr-814 * mhroncok talk to authors again, having a working example might help a lot #topic #1018 * mhroncok will help design the brp script = Followup Issues = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #1018 Review exception request: Xorg utility deaggregation .fpc 1018 https://pagure.io/packaging-committee/issue/1018 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 #topic #pr-1045 WIP: Add discussion of macro names beginning with underscores. https://pagure.io/packaging-committee/pull-request/1045 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1850772] Add perl-Email-Valid to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1850772 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Email-Valid-1.202-12.e ||l8 Resolution|--- |ERRATA Last Closed||2021-03-10 21:40:45 --- Comment #6 from Fedora Update System --- FEDORA-EPEL-2021-b314160e0b has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1890590] EPEL8 Request: perl-Coro
https://bugzilla.redhat.com/show_bug.cgi?id=1890590 Bug 1890590 depends on bug 1890585, which changed state. Bug 1890585 Summary: EPEL8 Request: perl-AnyEvent-AIO https://bugzilla.redhat.com/show_bug.cgi?id=1890585 What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1890585] EPEL8 Request: perl-AnyEvent-AIO
https://bugzilla.redhat.com/show_bug.cgi?id=1890585 Fedora Update System changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |ERRATA Last Closed|2020-12-21 09:43:55 |2021-03-10 21:40:42 --- Comment #8 from Fedora Update System --- FEDORA-EPEL-2021-478dc60d91 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] please review: PR 4668 - lib389 - Default path initialization should use dse.ldif if the server is down
https://github.com/389ds/389-ds-base/pull/4668 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora's GPG key in DNS(SEC)
Dne 10. 03. 21 v 19:28 Colin Walters napsal(a): With this model, the fingerprint changing is a hard failure. Yes. But the question is whether you can easily find that you have been attacked or you are under attack. Yes, fingerprint is better than comparing whole key, but the UX still sucks. Does COPR rotate keys today at all? Nope. Copr does not rotate keys. -- Miroslav Suchy, RHCA Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora's GPG key in DNS(SEC)
Dne 10. 03. 21 v 20:43 Petr Menšík napsal(a): If we finally fixed periodic gpg key breakage on new release branching, it should have been obtained by trusted way. F36 gpg key has been already released. I thin that this summer we will have correct gpg keys all the time and branching will be flawless. Finger crossed. -- Miroslav Suchy, RHCA Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On Thu, Mar 11, 2021 at 12:47:44AM +0500, Vladislav Kazakov wrote: > I can already see huge misunderstandings outside of mailing lists. > In my opinion, “Fedora” is better. Where are you seeing huge misunderstandings? What misunderstandings are there? Are these misunderstandings the sole reason that your opinion is that it's better to call the distribution just "Fedora", or are there other reasons? How would you address my concerns about messaging for not-the-main-distro parts of the Fedora Project overall? (For example: EPEL, Copr, plus non-distro activities that go towards our mission and vision?) -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
I can already see huge misunderstandings outside of mailing lists. In my opinion, “Fedora” is better. -1. Чт, 11 марта 2021 г. в 00:30, Vascom : > Please, keep simple "Fedora". > > Don't make us ridiculous. > > I vote -1. > > ср, 10 мар. 2021 г., 22:22 Reon Beon via devel < > devel@lists.fedoraproject.org>: > >> uname -a >> >> Linux fedora 5.12.0-0.rc2.165.fc35.x86_64 #1 SMP Sat Mar 6 16:32:15 UTC >> 2021 x86_64 x86_64 x86_64 GNU/Linux >> >> Shouldn't fedora be capitalized? >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On Wed, Mar 10, 2021 at 07:21:44PM -, Reon Beon via devel wrote: > uname -a > > Linux fedora 5.12.0-0.rc2.165.fc35.x86_64 #1 SMP Sat Mar 6 16:32:15 UTC 2021 > x86_64 x86_64 x86_64 GNU/Linux > > Shouldn't fedora be capitalized? No. The 2nd word of the output of "uname -a" is the nodename (hostname), so it just outputs the value of the system's hostname there. See also "uname -n". Hostnames are traditionally all lowercase, but if you want to change it feel free: hostnamectl set-hostname Fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora's GPG key in DNS(SEC)
On 3/10/21 5:43 PM, Colin Walters wrote: > > > On Wed, Mar 10, 2021, at 7:32 AM, Petr Menšík wrote: >> I think Björn's point is valid note. Because DNSSEC is used to verify >> email of used key, but fedora.repo does not contain any hint about how >> email in GPG key should look like. Also does not contain fingerprint of >> such key. It would be nice to include email of included GPG key in repo >> file itself. If actual email in GPG did not match, dnf would refuse such >> key unless explicitly requested by user. >> >> What if we added to repos: >> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch >> gpgkeyid=mailto:fedora-$releasever-prim...@fedoraproject.org > > See also https://github.com/rpm-software-management/libdnf/issues/43 - a > massive difference today between /usr/bin/dnf and libdnf-based things (like > rpm-ostree and PackageKit) is that libdnf auto-imports keys without prompting. > > For ostree we added support for doing the same, so that's how our rpm-ostree > based systems work by default (same set of GPG keys). > > There should really be an entirely separate flow for system repos versus 3rd > party. It's just plain dumb for us to prompt the user "Do you trust this > Fedora GPG key" if we already put the RPMs on disk! Agreed. System repositories should have been obtained via GPG signed packages. If we finally fixed periodic gpg key breakage on new release branching, it should have been obtained by trusted way. There should be no need to trust a new release key again manually. > > This is still today worked around in e.g. > https://pagure.io/fedora-kickstarts/blob/main/f/fedora-cloud-base.ks#_110 > for traditional yum/dnf based systems. > > For 3rd party repositories like COPR, as I noted in that issue I think the > best is to bootstrap trust over TLS - e.g. we have > ``` > gpgkeyfingerprint= > ``` How do I check what the correct fingerprint is on my system? How do I check it has not changed? Gpg fingerprint is related only to the single key. It does not allow safe roll of keys. If the key has to change, how can it *automatically* obtain the new fingerprint? DNSSEC and email allows the generation of a new key with the same email, which has trusted chain and can be just validated. New key would be imported if the old is invalid. How would you validate gpgkeyfingerprint? It would have to know authoritative URL to fetch current fingerprint (or the key itself) and compare it to the internal key. Does such url exist? Is it documented somewhere? Fingerprint helps only when installing a new repo. It does not contain signature of repo file, the only way is to trust ALL TLS authorities when fetching it. It would not be possible to supply trusted repo files on mirrors. If both repo and its key(s) are fetched from the same source, verification of fingerprint written in the repo file does not bring any more security IMHO. > > Having the full fingerprint supports fetching the key from anywhere too. Unless the fingerprint can be validated somehow, it creates just a false sense of security. > And the fingerprint+key is fetched via TLS, effectively a trust-on-first-use > style model. This exactly is a problem. You should not be asked to trust it on the first use, if there exists already trusted key chain able to validate it. I guess most people just hit Y once asked to trust a new key, because it is convenient. But unsafe. Regards, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
Please, keep simple "Fedora". Don't make us ridiculous. I vote -1. ср, 10 мар. 2021 г., 22:22 Reon Beon via devel < devel@lists.fedoraproject.org>: > uname -a > > Linux fedora 5.12.0-0.rc2.165.fc35.x86_64 #1 SMP Sat Mar 6 16:32:15 UTC > 2021 x86_64 x86_64 x86_64 GNU/Linux > > Shouldn't fedora be capitalized? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
uname -a Linux fedora 5.12.0-0.rc2.165.fc35.x86_64 #1 SMP Sat Mar 6 16:32:15 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Shouldn't fedora be capitalized? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Tue, Mar 09, 2021 at 09:15:23AM +, Tomasz Kłoczko wrote: > On Tue, 9 Mar 2021 at 06:57, Ondrej Dubaj wrote: > > > If any concerns about the autoconf2.69-2.69 compat package ? If needed it > > can be implemented as non-parallelly instalable, > > > > Really .. instead wasting time on packaging stuff which is ~7 years old it > would be better to use that time to fix one of those handful packages which Well the reason why it is 7 years old is there weren't any updates, so I think we should expect a reasonable amount of time to pass before upstreams transition. Like I said earlier, for parted we're not going to change until 2.71 is widely available, so I need something that either works with both or a compatibility package. > So .. anyone knows any other packages dist sources trees on which something > like "autoreconf -fiv" fails? THIS is what I needed. I hadn't tried -i so I continued to get failures when I worked on this a few weeks back. Adding -fiv did the trick and parted-3.4-3.fc35 will work with 2.69 or 2.71 so I no longer need the compatibility package, thanks. I still think having 2.69 is necessary though, and we should revisit convincing upstreams to use 2.71 after F36 or so. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-34-20210310.n.0 compose check report
No missing expected images. Failed openQA tests: 7/187 (x86_64), 19/126 (aarch64) New failures (same test not failed in Fedora-34-20210309.n.0): ID: 807568 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/807568 ID: 807623 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/807623 ID: 807624 Test: aarch64 Minimal-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/807624 ID: 807625 Test: aarch64 Minimal-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/807625 ID: 807626 Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/807626 ID: 807639 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/807639 ID: 807666 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/807666 ID: 807691 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/807691 ID: 80 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/80 ID: 807793 Test: aarch64 universal install_iscsi@uefi URL: https://openqa.fedoraproject.org/tests/807793 ID: 807803 Test: aarch64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/807803 ID: 807805 Test: aarch64 universal install_repository_http_graphical@uefi URL: https://openqa.fedoraproject.org/tests/807805 Old failures (same test failed in Fedora-34-20210309.n.0): ID: 807577 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/807577 ID: 807581 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/807581 ID: 807586 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/807586 ID: 807595 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/807595 ID: 807597 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/807597 ID: 807637 Test: aarch64 Server-dvd-iso install_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/807637 ID: 807657 Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi URL: https://openqa.fedoraproject.org/tests/807657 ID: 807665 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/807665 ID: 807670 Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi URL: https://openqa.fedoraproject.org/tests/807670 ID: 807688 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/807688 ID: 807704 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/807704 ID: 807781 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/807781 ID: 807815 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/807815 ID: 807820 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/807820 Soft failed openQA tests: 92/187 (x86_64), 55/126 (aarch64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-34-20210309.n.0): ID: 807580 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/807580 ID: 807641 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/807641 ID: 807645 Test: aarch64 Server-dvd-iso install_updates_nfs@uefi URL: https://openqa.fedoraproject.org/tests/807645 ID: 807679 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/807679 ID: 807800 Test: aarch64 universal install_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/807800 Old soft failures (same test soft failed in Fedora-34-20210309.n.0): ID: 807509 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/807509 ID: 807510 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/807510 ID: 807512 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/807512 ID: 807515 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home URL: https://openqa.fedoraproject.org/tests/807515 ID: 807516 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/807516 ID: 807517 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4 URL:
Fedora-34-20210310.0 compose check report
No missing expected images. Failed openQA tests: 8/176 (x86_64), 24/126 (aarch64) ID: 806874 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/806874 ID: 806875 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/806875 ID: 806886 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/806886 ID: 806906 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/806906 ID: 806910 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/806910 ID: 806915 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/806915 ID: 806926 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/806926 ID: 806938 Test: aarch64 Minimal-raw_xz-raw.xz base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/806938 ID: 806939 Test: aarch64 Minimal-raw_xz-raw.xz base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/806939 ID: 806940 Test: aarch64 Minimal-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/806940 ID: 806941 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/806941 ID: 806942 Test: aarch64 Minimal-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/806942 ID: 806943 Test: aarch64 Minimal-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/806943 ID: 806944 Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/806944 ID: 806946 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/806946 ID: 806955 Test: aarch64 Server-dvd-iso install_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/806955 ID: 806962 Test: aarch64 Server-dvd-iso install_repository_nfsiso_variation@uefi URL: https://openqa.fedoraproject.org/tests/806962 ID: 806967 Test: aarch64 Server-dvd-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/806967 ID: 806990 Test: aarch64 Server-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/806990 ID: 806994 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/806994 ID: 806995 Test: aarch64 Server-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/806995 ID: 806996 Test: aarch64 Server-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/806996 ID: 806998 Test: aarch64 Workstation-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/806998 ID: 807002 Test: aarch64 Workstation-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/807002 ID: 807003 Test: aarch64 Workstation-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/807003 ID: 807004 Test: aarch64 Workstation-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/807004 ID: 807006 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/807006 ID: 807009 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/807009 ID: 807022 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/807022 ID: 807099 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/807099 ID: 807133 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/807133 ID: 807138 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/807138 Soft failed openQA tests: 91/176 (x86_64), 57/126 (aarch64) (Tests completed, but using a workaround for a known bug) ID: 806838 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/806838 ID: 806839 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/806839 ID: 806841 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/806841 ID: 806844 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home URL: https://openqa.fedoraproject.org/tests/806844 ID: 806845 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/806845 ID: 806846 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4 URL:
Fedora-Rawhide-20210310.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 4 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 21/187 (x86_64), 19/110 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210309.n.1): ID: 806518 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/806518 ID: 806541 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/806541 ID: 806571 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/806571 ID: 806587 Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/806587 ID: 806623 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/806623 ID: 806624 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/806624 ID: 806633 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/806633 ID: 806636 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/806636 ID: 806640 Test: aarch64 Workstation-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/806640 ID: 806644 Test: aarch64 Workstation-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/806644 ID: 806645 Test: aarch64 Workstation-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/806645 ID: 806646 Test: aarch64 Workstation-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/806646 ID: 806730 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/806730 ID: 806731 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/806731 ID: 806735 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/806735 ID: 806782 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/806782 Old failures (same test failed in Fedora-Rawhide-20210309.n.1): ID: 806527 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/806527 ID: 806542 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/806542 ID: 806562 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/806562 ID: 806572 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/806572 ID: 806573 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/806573 ID: 806605 Test: aarch64 Server-dvd-iso install_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/806605 ID: 806629 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/806629 ID: 806648 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/806648 ID: 806650 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/806650 ID: 806663 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/806663 ID: 806664 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/806664 ID: 806677 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/806677 ID: 806686 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/806686 ID: 806725 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/806725 ID: 806726 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/806726 ID: 806727 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/806727 ID: 806728 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/806728 ID: 806740 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/806740 ID: 806741 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/806741 ID: 806748 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/806748 ID: 806752 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/806752 ID: 806760 Test: aarch64 universal install_with_swap@uefi URL:
Re: Fedora's GPG key in DNS(SEC)
On Wed, Mar 10, 2021, at 1:06 PM, Miroslav Suchý wrote: > Dne 10. 03. 21 v 17:43 Colin Walters napsal(a): > > For 3rd party repositories like COPR, as I noted in that issue I think the > > best is to bootstrap trust over TLS - e.g. we have > > ``` > > gpgkeyfingerprint= > > ``` > > Would you, as sysadmin, notice if the fingerprint changed (because of > attacker)? I definitelly not. > > That >gpgkeyid=iss...@email.com >gpgkey_dns_verification=1 > is IMO better approach. With this model, the fingerprint changing is a hard failure. Now if you're scoping in key rotation - that is indeed a hard problem. Does COPR rotate keys today at all? I think it's fair to say that key rotation is the most broken-by-design thing about GPG. It's not clear to me that DNS is the right answer though. We're having a parallel discussion about this in https://github.com/ostreedev/ostree/pull/2260 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-34-20210310.0 compose check report
No missing expected images. Failed openQA tests: 1/16 (x86_64), 2/15 (aarch64) Old failures (same test failed in Fedora-IoT-34-20210308.0): ID: 807873 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/807873 ID: 807882 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/807882 ID: 807889 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/807889 Soft failed openQA tests: 3/16 (x86_64), 1/15 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20210308.0): ID: 807865 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/807865 ID: 807866 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/807866 ID: 807867 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/807867 ID: 807881 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/807881 Passed openQA tests: 12/15 (aarch64), 12/16 (x86_64) New passes (same test not passed in Fedora-IoT-34-20210308.0): ID: 807883 Test: aarch64 IoT-dvd_ostree-iso iot_greenboot@uefi URL: https://openqa.fedoraproject.org/tests/807883 Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.20 to 0.07 Previous test data: https://openqa.fedoraproject.org/tests/804019#downloads Current test data: https://openqa.fedoraproject.org/tests/807881#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora's GPG key in DNS(SEC)
Dne 10. 03. 21 v 17:43 Colin Walters napsal(a): For 3rd party repositories like COPR, as I noted in that issue I think the best is to bootstrap trust over TLS - e.g. we have ``` gpgkeyfingerprint= ``` Would you, as sysadmin, notice if the fingerprint changed (because of attacker)? I definitelly not. That gpgkeyid=iss...@email.com gpgkey_dns_verification=1 is IMO better approach. -- Miroslav Suchy, RHCA Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On 10/03/21 03:22 -, Scott Williams wrote: I'm +1 on "Fedora Linux". I believe it adds clarity, especially when talking with software vendors. IE, "I'm running Fedora Linux" is less ambiguous than having to explain that Fedora is Linux after telling your ISP's support, etc., "I'm running Fedora." I was already +1 for this change, but that's a great point that makes me more strongly in favour of the change. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-35-20210310.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 8/15 (aarch64), 1/16 (x86_64) New failures (same test not failed in Fedora-IoT-35-20210308.0): ID: 807847 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/807847 ID: 807848 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/807848 ID: 807855 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/807855 ID: 807856 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/807856 Old failures (same test failed in Fedora-IoT-35-20210308.0): ID: 807836 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/807836 ID: 807845 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/807845 ID: 807849 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/807849 ID: 807852 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/807852 ID: 807858 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/807858 Soft failed openQA tests: 3/16 (x86_64), 1/15 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-35-20210308.0): ID: 807828 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/807828 ID: 807829 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/807829 ID: 807830 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/807830 ID: 807844 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/807844 Passed openQA tests: 12/16 (x86_64), 6/15 (aarch64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Used mem changed from 173 MiB to 193 MiB Previous test data: https://openqa.fedoraproject.org/tests/803549#downloads Current test data: https://openqa.fedoraproject.org/tests/807828#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Used mem changed from 174 MiB to 193 MiB Previous test data: https://openqa.fedoraproject.org/tests/803550#downloads Current test data: https://openqa.fedoraproject.org/tests/807829#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: Used mem changed from 184 MiB to 207 MiB Previous test data: https://openqa.fedoraproject.org/tests/803565#downloads Current test data: https://openqa.fedoraproject.org/tests/807844#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
OpenSSH SHA-1 deprecation, developing FAQ, etc
Hi all, I put some comments on the OpenSSH mailing list[1] about UpdateHostKeys and other SHA-1 related changes. The OpenSSH release notes simply tell people to update OpenSSH. In practice, people who use distributions like Fedora, RHEL and CentOS are going to wait for a package. Security conscious users who can't completely disable ssh may use the MACs parameter in ssh_config, sshd_config or both. What does it mean from a Fedora perspective? For example: - did anybody already write any wiki page, FAQ or guide for Fedora users to navigate the SHA-1 issue in SSH? - will Fedora be more proactive than upstream in disabling SHA-1 or will Fedora simply follow the timeline from upstream? Regards, Daniel 1. https://lists.mindrot.org/pipermail/openssh-unix-dev/2021-March/039194.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1933287] EPEL8 Request: perl-File-Touch
https://bugzilla.redhat.com/show_bug.cgi?id=1933287 Andrea Veri changed: What|Removed |Added Flags|needinfo?(andrea.veri@gmail | |.com) | --- Comment #2 from Andrea Veri --- Don't think I have an interest in maintaining either a branch for perl-File-Touch nor for perl-POSIX-strptime, you should be able to request a branch and work on that yourself just fine :-) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1933287] EPEL8 Request: perl-File-Touch
https://bugzilla.redhat.com/show_bug.cgi?id=1933287 Jakub Jedelsky changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Flags||needinfo?(andrea.veri@gmail ||.com) --- Comment #1 from Jakub Jedelsky --- Hello, could you please evaluate the request? I can help with building/maintaining if you want (kubo). -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora's GPG key in DNS(SEC)
On Wed, Mar 10, 2021, at 7:32 AM, Petr Menšík wrote: > I think Björn's point is valid note. Because DNSSEC is used to verify > email of used key, but fedora.repo does not contain any hint about how > email in GPG key should look like. Also does not contain fingerprint of > such key. It would be nice to include email of included GPG key in repo > file itself. If actual email in GPG did not match, dnf would refuse such > key unless explicitly requested by user. > > What if we added to repos: > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch > gpgkeyid=mailto:fedora-$releasever-prim...@fedoraproject.org See also https://github.com/rpm-software-management/libdnf/issues/43 - a massive difference today between /usr/bin/dnf and libdnf-based things (like rpm-ostree and PackageKit) is that libdnf auto-imports keys without prompting. For ostree we added support for doing the same, so that's how our rpm-ostree based systems work by default (same set of GPG keys). There should really be an entirely separate flow for system repos versus 3rd party. It's just plain dumb for us to prompt the user "Do you trust this Fedora GPG key" if we already put the RPMs on disk! This is still today worked around in e.g. https://pagure.io/fedora-kickstarts/blob/main/f/fedora-cloud-base.ks#_110 for traditional yum/dnf based systems. For 3rd party repositories like COPR, as I noted in that issue I think the best is to bootstrap trust over TLS - e.g. we have ``` gpgkeyfingerprint= ``` Having the full fingerprint supports fetching the key from anywhere too. And the fingerprint+key is fetched via TLS, effectively a trust-on-first-use style model. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
For me I go with your first suggestion: Keep it simple for the OS, just fedora, as it already is; and for the overall effort, Fedora Project. It works already. Em qua, 10 de mar de 2021 09:27, Björn Persson escreveu: > Vitaly Zaitsev via devel wrote: > > 2. Why Linux and not GNU/Linux? Linux is just a kernel. GNU/Linux is an > OS. > > It was very predictable that this argument would happen, and that's why > I've been quite happy that Fedora is just "Fedora" with no "Linux" in > the name. > > If we're going to name the distribution after some of its components, > why stop at one or two? Arguably the most central part of any software > distribution is its package manager. The programs that bring up the > whole system are also rather important. And none of the GUI programs > would exist without the windowing system so we need to mention X. Or > should that honor go to Wayland now? Better give them equal treatment. > > "Fedora GNU/Linux/RPM/Python/DNF/SystemD/Xorg/Wayland/..." > > It's better to give the whole distribution its own name, and not name > it after any of its components. Fedora is a software distribution. It > contains Linux, many GNU components, RPM, MariaDB, Libreoffice and lots > of other things, but its name is "Fedora". Or call it "Fedora Software > Distribution" or anything else that doesn't single out any of the > components. That approach seems to minimize the political fighting. > > Björn Persson > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On Wed, 2021-03-10 at 10:21 -0500, Ben Cotton wrote: > ...[snip] > From the Community Blog post[1]: > > > Why not use “Fedora GNU+Linux” or some similar name? We want to be > > easy to say. The more words we add, the harder that is. And while > > GNU is an important part of Fedora Linux, there are many other > > packages that make Fedora Linux what it is. “Linux” is, for better > > or worse, the commonly-understood phrasing, so let’s just use that. > > [1] > https://communityblog.fedoraproject.org/fedora-is-a-community-fedora-linux-is-our-os/ I would have to agree with Matthew and Ben regarding the name. Fedora began as a collection of like minded individuals who took the effort to establish the four foudation prinicpals before assembling a working distribution which itself is focused around FLOSS and is very specific and firm about licensing requirements WRT what is allowed to ship as part of the official distro. This Fedora community took on a greater role than merely a linux distirbution, often times having a direct impact on the greater linux community in the process. For my part, it is in my own thoughts that I inherently differentiate between the distro and some other aspect of the Fedora Project, when using the same name for different aspects of Fedora Project/Community/Magazine/Discussion/etc... So calling the distro, in it's many official releases, Fedora-Linux at the code base level, so the ID that packages/apps should be using to verify OS, is just a programatic change that will have little to no affect in user level usage, and minimal affect for dev's. Naming things is what people do, and by clearly naming things we can easier differentiate between the various aspects of what constitutes the Fedora Ecosystem. Just my two cents worth. Stephen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 34 compose report: 20210310.n.0 changes
OLD: Fedora-34-20210309.n.0 NEW: Fedora-34-20210310.n.0 = SUMMARY = Added images:8 Dropped images: 0 Added packages: 0 Dropped packages:1 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:929.32 KiB Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-34-20210310.n.0.s390x.raw.xz Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-34-20210310.n.0.iso Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-34-20210310.n.0.iso Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-34-20210310.n.0.iso Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-34-20210310.n.0.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-34-20210310.n.0.s390x.tar.xz Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-34-20210310.n.0.s390x.tar.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-34-20210310.n.0.s390x.qcow2 = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: switchboard-plug-onlineaccounts-2.0.1-11.20210218gita2a7bc3.fc34 Summary: Switchboard Online Accounts plug RPMs:switchboard-plug-onlineaccounts Size:929.32 KiB = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Reminder: Upcoming summer time changes
On Wed, 2021-03-10 at 09:52 -0500, Ben Cotton wrote: > [snip] > A global list of time changes is available by country[2] and by > date[3], but here are a few highlights: > > 14 March — summer time begins in Canada, parts of Mexico, and the US Actually in Canada we have four seasons, so Springtime begins at or around Mar 20-22 depending upon the spring equinox. However, speaking specifically about the (dreaded) daylight savings time, yes we will move our clocks ahead on Mar 14 of this year, to "save" some of that precious daylight. Stephen > > > > [1] https://apps.fedoraproject.org/calendar/ > [2] https://www.timeanddate.com/time/dst/2021.html > [3] https://www.timeanddate.com/time/dst/2021a.html > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Summary/Minutes from today's FESCo Meeting (2021-03-10)
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-2/2021-03-10/fesco.2021-03-10-15.02.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-2/2021-03-10/fesco.2021-03-10-15.02.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-2/2021-03-10/fesco.2021-03-10-15.02.log.html Meeting summary --- * init process (zbyszek, 15:02:41) * #2584 Fedora 34 incomplete changes: 100% complete dealine (zbyszek, 15:04:27) * ACTION: dcantrell to doublecheck the status of X.org Utility Deaggregation and update the ticket (zbyszek, 15:07:30) * Next week's chair (zbyszek, 15:21:27) * mhroncok will chair next meeting, bcotton as backup (mhroncok, 15:23:30) * Open Floor (zbyszek, 15:23:44) * Meetings will be held at 14:00 UTC since next week. (zbyszek, 15:30:37) * ACTION: mhroncok to update wiki (mhroncok, 15:30:47) * ACTION: mhroncok to update fedocal (mhroncok, 15:31:52) * ACTION: zbyszek to start a new whenisgood poll (zbyszek, 15:36:07) Meeting ended at 15:37:24 UTC. Action Items * dcantrell to doublecheck the status of X.org Utility Deaggregation and update the ticket * mhroncok to update wiki * mhroncok to update fedocal * zbyszek to start a new whenisgood poll ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On Wed, Mar 10, 2021 at 10:15 AM Robbi Nespu wrote: > > I got mixed feeling, I understand the reason why but I don't quite > understand why you don't want to use "Fedora GNU/Linux". Read you > comment on others email but the is not much details. Could you explain > again in details? From the Community Blog post[1]: > Why not use “Fedora GNU+Linux” or some similar name? We want to be easy to > say. The more words we add, the harder that is. And while GNU is an important > part of Fedora Linux, there are many other packages that make Fedora Linux > what it is. “Linux” is, for better or worse, the commonly-understood > phrasing, so let’s just use that. [1] https://communityblog.fedoraproject.org/fedora-is-a-community-fedora-linux-is-our-os/ -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On Wed, 10 Mar 2021 13:26:55 +0100 Björn Persson wrote: > It's better to give the whole distribution its own name, and not name > it after any of its components. Fedora is a software distribution. It > contains Linux, many GNU components, RPM, MariaDB, Libreoffice and > lots of other things, but its name is "Fedora". Or call it "Fedora > Software Distribution" or anything else that doesn't single out any > of the components. That approach seems to minimize the political > fighting. How about "Fedora Endeavors"? Nice double meaning, too. :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
Hi Matthew Miller, I got mixed feeling, I understand the reason why but I don't quite understand why you don't want to use "Fedora GNU/Linux". Read you comment on others email but the is not much details. Could you explain again in details? Perhaps explain on Wiki too.. p/s : - Can we have a vote which name we want to use? :P -- Email : Robbi Nespu PGP fingerprint : D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA PGP key : https://keybase.io/robbinespu/pgp_keys.asc OpenPGP_0x0C81FA303B3A80BA_and_old_rev.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Reminder: Upcoming summer time changes
As a reminder to the community, we've reached the point in the year where jurisdictions around the world begin or end summer time. Be sure to check your recurring meetings on Fedocal[1] to make sure you know when you're meeting. Some meetings are set to a fixed time UTC and others are set to a particular time zone. A global list of time changes is available by country[2] and by date[3], but here are a few highlights: 14 March — summer time begins in Canada, parts of Mexico, and the US 28 March — summer time begins in the EU and UK 4 April — summer time begins in most of Mexico, summer time ends in Australia [1] https://apps.fedoraproject.org/calendar/ [2] https://www.timeanddate.com/time/dst/2021.html [3] https://www.timeanddate.com/time/dst/2021a.html -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On Wed, Mar 10, 2021 at 09:20:21AM +0100, Vít Ondruch wrote: > However, I can imagine that somebody will correct me that the right > way is to say "I have installed Fedora Linux on my LP", because > "Fedora" does not exist in this context. Here's my suggestion: if you're writing formal Fedora Project documentation and someone corrects you in that way, say "Oh, thanks" and accept the change. In any other case, shrug, wink, ignore, acknowledge, whatever, and move on. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On Tue, Mar 09, 2021 at 08:04:01PM -0500, Christopher wrote: > I get the idea that it's useful to draw a distinction between the > project and the product, and agree with the goal. The upstream naming > preference wasn't really my point in those examples, though. My > examples were an attempt to show that the short name (colloquial name, > even if not the "official" name) often refers to the product, and the > community name is the longer of the two (often with the community > being named after the product, not the other way around). I was also > attempting to emphasize that there's already a distinction made > between Fedora and the Fedora Project that people are already using > that seems to be sufficient, in the same way that those other > projects/communities have a distinction. This is all fine; I'm not going to fight against colloquial use. This change is about one aspect of our own formal use. > Clarity can be achieved by context, the use of improper nouns, and > clear writing style (descriptive thinking). I think people put too > much emphasis in names to communicate meaning (nominative thinking). > Adding "Linux" doesn't really give any clarity, since it's implied > already... and... you can already append it to descriptively add > clarity without changing the name. /etc/os-release doesn't give much room for context like that. I mean, if it helps, you can think of it as us appending Linux descriptively to add clarity? > It doesn't matter to me much. I have expressed my opinion, but am > happy to go with the flow. :) And I do appreciate it. :) -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On Wed, Mar 10, 2021 at 01:24:36PM +0100, Björn Persson wrote: > I don't think "Linux" conveys the distinction between those things and > ELN. Someone who hears "Fedora Linux" won't understand that it comprises > both Workstation and CoreOS but not ELN. It would be better to come up > with another word to denote a collection of software distributions that > aren't "enterprise" distributions, and also not art, websites et cetera. > A word that captures the essence of how the things it covers differ from > all the other things. > > Maybe something like "Fedora Family", because it's a number of closely > related distributions which are suitable for use at home? > > Or something like "Fedora Flow", alluding to frequent releases and a > steady stream of updates? I'm not _completely_ oppposed to the idea of an entirely new name, but that's a big change, whereas this is just codifying something that has been in use inconsistently for years. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: How to handle nginx 3rd party modules?
On Tue, Mar 09, 2021 at 10:29:53AM -0500, Felix Kaechele via devel wrote: ... [snip great email] ... > So I'd appreciate some input here as to what the best way forward would be > from a distribution engineering perspective. Hi Felix, that's a fantastic write up! I think you have outlined the different options, the complexity and trade-offs involved there extremely well, that matches exactly how I see it. One thing I'd add - even for something as "simple" as the lua module, the OpenResty folks seem to not recommend it's used with upstream nginx, instead they recommend what is basically their own fork of nginx: https://github.com/openresty/lua-nginx-module#installation Hence it's never been obvious to me that if you start down this road, it you can easily stop. If you worked out how to ship the lua module, the next bug report will be that you need to adopt a handful of the OpenResty patches for nginx as well to make the lua module work properly. And then you end up packaging "OpenResty" rather than "nginx"? For RHEL we have maintained a hard line on your (4) - just don't do it. We ship "nginx", and that's it. Until NGINX upstream wants to support an external API/ABI and externally built third-party modules, we should not try to do it ourselves. (Apache httpd has supported this model for *over two decades*. It's not like it is rocket science, nor can it be unclear there is is some demand for this.) I think your option (1) - bundle some extra modules directly in the nginx SRPM - would be absolutely fine for Fedora *if* those maintaining that package have the time & effort to maintaining that. I'm afraid I'm not going to volunteer any time for that though :( Regards, Joe [Manager for team which owns RHEL HTTP servers, inter alia] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On Wed, Mar 10, 2021 at 09:27:49AM +0100, Vít Ondruch wrote:
> How about changing /etc/redhat-release ? I am specifically asking
> this in the context of Vagrant, which seems to use this file to
> detect Fedora.
That does seem to be set from NAME, and Vagrant does this:
https://github.com/hashicorp/vagrant/blob/main/plugins/guests/fedora/guest.rb
machine.communicate.test("grep 'Fedora release' /etc/redhat-release")
I'll file an issue. Thanks.
--
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[Bug 1932205] perl-IPTables-libiptc-0.52-36.fc35 FTBFS: iptables-detect-version.c:65:2: warning: #warning "This version of xtables is currently not supported by this Perl package
https://bugzilla.redhat.com/show_bug.cgi?id=1932205 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-IPTables-libiptc-0.52- ||37.fc35 Resolution|--- |RAWHIDE Last Closed||2021-03-10 14:09:23 --- Comment #1 from Petr Pisar --- iptables tool called at build time was moved from iptables to iptables-legacy packages. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora's GPG key in DNS(SEC)
On 3/10/21 1:32 PM, Petr Menšík wrote: I think Björn's point is valid note. Because DNSSEC is used to verify email of used key, but fedora.repo does not contain any hint about how email in GPG key should look like. Also does not contain fingerprint of such key. It would be nice to include email of included GPG key in repo file itself. If actual email in GPG did not match, dnf would refuse such key unless explicitly requested by user. What if we added to repos: gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch gpgkeyid=mailto:fedora-$releasever-prim...@fedoraproject.org This way dnf could map DNSSEC validated email to repository. It would be user-verifiable, when he or she would add a new repository downloaded from any site. Excuse me if I am overthinking this, but "from any site" is that detail wherein the proverbial devil is, I think. I'd say you would want DNF to a priori realize that the domain part from said "gpgkeyid=" indeed (partially) matches the domain you obtained this very repo file from (prior to redirections[*]) be it either in the form of "dnf install .rpm" or hypothetical "--repofromrepopath" counterpart of "--repofrompath" command (since baseurl= can generally differ from where you obtain the repo from, but the same logic could be applied when that's not the case). In turn, that would restrict the location from where you can obtain the repo file smoothly without alerts to only the domain(s) stricly bound to the domain used in the address within gpgkeyid= (creating thus a concept of authoritative repo file source). That would apply on the surfacing URL only[*]. Otherwise, I think someone could be tricked to start from installing https://rpmfusion-mirror.seams-leg.it/rpmfusion-free-release.noarch.rpm and crafted gpgkeyid= in the installed repo would not exactly help. Of course, applies only to cases of entirely foreign by then repositories, like RPM Fusion (use case: visit its web [DNS must have been trusted already], follow the instructions here, be spared from a fraudulent mirror right from the start). For Fedora (Linux) incremental versions, there should really be some kind of a seamless "rolling trust" mechanism as discussed in other part of the above message. [*] feels like a compromise of redirect chain would still be captured with the whole mechanism, but I might have missed something/a lot -- Jan (poki) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-IPTables-libiptc] PR #1: Tests
ppisar merged a pull-request against the project: `perl-IPTables-libiptc` that you are following. Merged pull-request: `` Tests `` https://src.fedoraproject.org/rpms/perl-IPTables-libiptc/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20210310.n.0 changes
OLD: Fedora-Rawhide-20210309.n.1
NEW: Fedora-Rawhide-20210310.n.0
= SUMMARY =
Added images:2
Dropped images: 7
Added packages: 0
Dropped packages:1
Upgraded packages: 61
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:929.81 KiB
Size of upgraded packages: 7.31 GiB
Size of downgraded packages: 0 B
Size change of upgraded packages: -72.49 MiB
Size change of downgraded packages: 0 B
= ADDED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20210310.n.0.iso
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20210310.n.0.iso
= DROPPED IMAGES =
Image: Python_Classroom live x86_64
Path:
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20210309.n.1.iso
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20210309.n.1.aarch64.raw.xz
Image: SoaS raw-xz armhfp
Path: Spins/armhfp/images/Fedora-SoaS-Rawhide-20210309.n.1.armhfp.raw.xz
Image: SoaS raw-xz aarch64
Path: Spins/aarch64/images/Fedora-SoaS-Rawhide-20210309.n.1.aarch64.raw.xz
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20210309.n.1.iso
Image: Container_Minimal_Base docker ppc64le
Path:
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20210309.n.1.ppc64le.tar.xz
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20210309.n.1.aarch64.raw.xz
= ADDED PACKAGES =
= DROPPED PACKAGES =
Package: switchboard-plug-onlineaccounts-2.0.1-11.20210218gita2a7bc3.fc35
Summary: Switchboard Online Accounts plug
RPMs:switchboard-plug-onlineaccounts
Size:929.81 KiB
= UPGRADED PACKAGES =
Package: authselect-1.2.2-4.fc35
Old package: authselect-1.2.2-3.fc35
Summary: Configures authentication and identity sources from supported
profiles
RPMs: authselect authselect-compat authselect-devel authselect-libs
Size: 2.09 MiB
Size change: 3.09 KiB
Changelog:
* Tue Mar 09 2021 Benjamin Berg - 1.2.2-4
- Add patch to make fingerprint-auth return non-failing pam_fprintd.so errors
Resolves: #1935331
Package: beakerlib-1.26-1.fc35
Old package: beakerlib-1.25-1.fc34
Summary: A shell-level integration testing library
RPMs: beakerlib beakerlib-vim-syntax
Size: 171.46 KiB
Size change: 426 B
Changelog:
* Tue Mar 09 2021 Dalibor Pospisil - 1.26-1
- fixed rlServiceDisable if called without rlServiceEnable beforehand
- few internal fixes
Package: dummy-test-package-gloster-0-3056.fc35
Old package: dummy-test-package-gloster-0-3052.fc35
Summary: Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 190.97 KiB
Size change: 252 B
Changelog:
* Tue Mar 09 2021 packagerbot - 0-3053
- rebuilt
* Tue Mar 09 2021 packagerbot - 0-3054
- rebuilt
* Wed Mar 10 2021 packagerbot - 0-3055
- rebuilt
* Wed Mar 10 2021 packagerbot - 0-3056
- rebuilt
Package: git-2.31.0-0.2.rc2.fc35
Old package: git-2.30.1-2.fc35
Summary: Fast Version Control System
RPMs: git git-all git-core git-core-doc git-credential-libsecret
git-cvs git-daemon git-email git-gui git-instaweb git-subtree git-svn gitk
gitweb perl-Git perl-Git-SVN
Size: 23.66 MiB
Size change: -163.98 KiB
Changelog:
* Tue Mar 02 2021 Zbigniew J??drzejewski-Szmek -
2.30.1-2.1
- Rebuilt for updated systemd-rpm-macros
See https://pagure.io/fesco/issue/2583.
* Tue Mar 02 2021 Todd Zullinger - 2.30.1-3
- use %{gpgverify} macro to verify tarball signature
* Tue Mar 02 2021 Todd Zullinger - 2.31.0-0.0.rc0
- update to 2.31.0-rc0
* Wed Mar 03 2021 Todd Zullinger - 2.31.0-0.1.rc1
- update to 2.31.0-rc1
* Tue Mar 09 2021 Todd Zullinger - 2.31.0-0.2.rc2
- update to 2.31.0-rc2
Package: holland-1.2.3-3.fc35
Old package: holland-1.2.3-2.fc35
Summary: Pluggable Backup Framework
RPMs: holland holland-common holland-commvault holland-lvm
holland-mariabackup holland-mongodump holland-mysql holland-mysqldump
holland-mysqllvm holland-pgdump holland-xtrabackup
Size: 382.57 KiB
Size change: 1.09 KiB
Changelog:
* Tue Mar 09 2021 Sam P - 1.2.3-3
- Incorporated changes from pull request #7 from fab for
python3-mysqlclient dependency.
Package: icewm-2.2.1-2.fc35
Old package: icewm-2.2.1-1.fc35
Summary: Window manager designed for speed, usability, and consistency
RPMs: icewm icewm-data icewm-fonts-settings icewm-minimal-session
icewm-themes
Size: 7.80 MiB
Size change: 886 B
Changelog:
* Tue Mar 09 2021 Artem Polishchuk - 2.2.1-2
- build: Remove volumeicon dep | RH#1695951
Package: java-1.8.0-openjdk-1:1.8.0.292.b05-0.0.ea.fc35
Old package: java-1.8.0-openjdk-1:1.8.0.292.b04-0.0.ea.fc35
Summary: OpenJDK 8 Runtime Environment
RPMs: java-1.8.0-openjdk
[Test-Announce] Fedora 34 Candidate Beta-1.1 Available Now!
According to the schedule [1], Fedora 34 Candidate Beta-1.1 is now available for testing. Please help us complete all the validation testing! For more information on release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/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_Beta_1.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_34_Beta_1.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_34_Beta_1.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_34_Beta_1.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_34_Beta_1.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_34_Beta_1.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_34_Beta_1.1_Security_Lab All Beta priority test cases for each of these test pages [2] must pass in order to meet the Beta Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-34/f-34-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_34_Beta_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-IPTables-libiptc] PR #1: Tests
ppisar opened a new pull-request against the project: `perl-IPTables-libiptc` that you are following: `` Tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-IPTables-libiptc/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
On Tue, Mar 09, 2021 at 10:19:53PM -0500, Neal Gompa wrote: > Fedora actually *has* other things branded Fedora today, and may do so > for more things in the future. They don't have the opportunity to get > attention because our ability to present ourselves beyond the Linux > distribution sucks. > > > Overall, ust. no. Deliberately breaking every ansible, chef, or > > other deployment tools that check /etc/os-release for a consistent > > operating system reference name is not a benefit to anyone. > > Ansible uses ID and VERSION_ID, which are not changing, so this will > have no impact there. No, ansible uses NAME from /etc/os-release. ID is used only from /usr/lib/os-release. See https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts/system/distribution.py#L390 But /etc/redhat-release seems to be preferred over /etc/os-release, so I guess this change won't have an impact on the "distribution" variable. -- Miroslav Lichvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora's GPG key in DNS(SEC)
Dne 10. 03. 21 v 13:32 Petr Menšík napsal(a): Is there reason why we consider new release keys as completely unrelated to previous keys? Is it technical decision or just lack of better implementation? No one done this yet. Feel free to take it. I will love to have this. -- Miroslav Suchy, RHCA Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package update requires modification of config file in users' home directories
On Tue, Mar 9, 2021, at 10:02 PM, Nico Kadel-Garcia wrote: > On Tue, Mar 9, 2021 at 7:46 AM Vitaly Zaitsev via devel > wrote: > > > > On 09.03.2021 00:10, Alexander Ploumistos wrote: > > > Is there something I can do to sed out the -qt5 suffix, or should I > > > just bite the bullet, build the update and wait for the bug reports to > > > come in? > > > > You cannot modify files in user home directories. > > Well, you *can*, but then you'd be Ubuntu with /home/apache, > /home/tomcat, and violating the File System Hierarchy in all sorts of > ways. It's also outrageous to expect or permit this kind of RPM based > manipulaiton, since "/home/" directories may be NFS mounted across a > wide array of systems.and represents userspace not system space. Not with rpm-ostree, we sandbox scripts: https://coreos.github.io/rpm-ostree/architecture-core/#sandboxing-scripts ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
Matthew Miller wrote: > Of course, the obvious response is that it hasn't stuck. That might be > partly true, but it also definitely _has_ for other people (see for example > the `httpd` package naming in our own repos) Debian, on the other hand, has an apache2 package, /usr/sbin/apache2, /etc/apache2, apache2.service and so on. That's a real nuisance. Working with both Debian and CentOS I always have trouble remembering whether it's /etc/apache2 or /etc/httpd, and apache2.service or httpd.service. Both have apachectl though, not httpctl. Björn Persson pgpM4JMCrkspm.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora's GPG key in DNS(SEC)
I think Björn's point is valid note. Because DNSSEC is used to verify email of used key, but fedora.repo does not contain any hint about how email in GPG key should look like. Also does not contain fingerprint of such key. It would be nice to include email of included GPG key in repo file itself. If actual email in GPG did not match, dnf would refuse such key unless explicitly requested by user. What if we added to repos: gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch gpgkeyid=mailto:fedora-$releasever-prim...@fedoraproject.org This way dnf could map DNSSEC validated email to repository. It would be user-verifiable, when he or she would add a new repository downloaded from any site. That is especially valid if user just changed --releasever, but repository file remains from trusted source. Installing unsigned package provides no way to ensure it cames from trusted source. There is anything we can do about that, admin either knows what he does or can be fooled to anything. I don't understand why old keys don't provide transition to new keys, while they are still valid. DNSSEC allows us to ensure they are still current and non-revoked. But still, when I use dnf install --releasever 35 , it asks me for confirmation of new f35 key. But If I already trust f33 key, it might sign f35 key before obsoleted itself. It would provide me safe upgrade path to new release keys. Is there reason why we consider new release keys as completely unrelated to previous keys? Is it technical decision or just lack of better implementation? Regards, Petr On 3/9/21 4:56 PM, Miroslav Suchý wrote: > Dne 08. 03. 21 v 15:01 Björn Persson napsal(a): >> Suppose a bad guy has somehow tricked you into downloading a malicious >> version of rpmfusion-free-release. The package is signed by >> brad.guy@malicious.example, and the key is published in the domain >> malicious.example. All the DNSsec signatures are in perfect order, so >> you can be quite sure that the key really does belong to >> brad.guy@malicious.example. Do you trust Brad? Should you install the >> package? > > Let's compare it to a current situation. I deleted F34 and F35 GPG keys > from my system. > > When I tried to run (and I used distribution-gpg-key package for the test): > > # dnf install > http://ftp.halifax.rwth-aachen.de/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/d/distribution-gpg-keys-1.51-1.fc35.noarch.rpm > > > Then DNF does not blink an eye and install this package even when the > GPG keys is not known. (it is because of default setting of > localpkg_gpgcheck). > > BTW when I try: > # rpm -i distribution-gpg-keys-1.51-1.fc35.noarch.rpm > warning: distribution-gpg-keys-1.51-1.fc35.noarch.rpm: Header V4 > RSA/SHA256 Signature, key ID 9867c58f: NOKEY > > I.e. the package have been installed. Though rpm emits a warning. But I > doubt that average sysadmin would treat this warning seriously. > > And if you download and install package containing .repo file where > baseurl points to malicious repo and the package install malicious GPG > key, then you are screwed anyway. > In postscriptlet, or unit file, you can import the GPG key to rpmdb and > do whatever you want. > > It does not matter if you used DNS(SEC) verification or not. You simple > should check the GPG key and you should not trust the key emmited by > brad.guy@malicious.example. > > >> Obviously we want a package signed by an attacker to fail the >> verification. Section 3 of your thesis describes how the modified DNF >> uses DNSsec to verify that the key is valid for the stated email >> address, but I don't see anything about how it decides whether the >> email address is correct for the repository, or whether the person >> behind that email address is trusted. You state that the DNS server >> isn't necessarily in the same domain as the repository, so it's not as >> simple as comparing the domain names. Could you explain how the email >> address is validated? > > The domain for the repository above is ftp.halifax.rwth-aachen.de, but > the GPG key for packages there use @fedoraproject.org. That's what an > author meant. > > > Now, lets try something little different. I still do not have F34 and > F35 GPG keys. I am on F33. And lets run: > > # dnf install --releasever=34 distribution-gpg-keys > ... > Installed size: 434 k > Is this ok [y/N]: y > Downloading Packages: > ... > Importing GPG key 0x45719A39: > Userid : "Fedora (34) " > Fingerprint: 8C5B A699 0BDB 26E1 9F2A 1A80 1161 AE69 4571 9A39 > From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64 > Is this ok [y/N]: > > That is interesting. Let pretend that attacker changed something by MITM > attack and tricked me to download his package. If he signed package > using brad.guy@malicious.example email. Then DNF will tell me: > > Importing GPG key 0x45719A39: > Userid : "hahah " > Fingerprint: some thing bad and not matching > From :
Re: F35 Change: "Fedora Linux" in /etc/os-release
Matthew Miller wrote: > leading to things like > people saying "Oh, that's in CoreOS, not Fedora", where the shorthand is > more confusing than helpful. What should that be instead? "That's in CoreOS, not Linux" is no better. "That's in Fedora CoreOS, not Fedora Linux" makes no sense either, because Fedora CoreOS would be a subset of Fedora Linux if I understand you correctly. Björn Persson pgp4m8hB5HQ1s.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
Vitaly Zaitsev via devel wrote: > 2. Why Linux and not GNU/Linux? Linux is just a kernel. GNU/Linux is an OS. It was very predictable that this argument would happen, and that's why I've been quite happy that Fedora is just "Fedora" with no "Linux" in the name. If we're going to name the distribution after some of its components, why stop at one or two? Arguably the most central part of any software distribution is its package manager. The programs that bring up the whole system are also rather important. And none of the GUI programs would exist without the windowing system so we need to mention X. Or should that honor go to Wayland now? Better give them equal treatment. "Fedora GNU/Linux/RPM/Python/DNF/SystemD/Xorg/Wayland/..." It's better to give the whole distribution its own name, and not name it after any of its components. Fedora is a software distribution. It contains Linux, many GNU components, RPM, MariaDB, Libreoffice and lots of other things, but its name is "Fedora". Or call it "Fedora Software Distribution" or anything else that doesn't single out any of the components. That approach seems to minimize the political fighting. Björn Persson pgpzWvb0QUWvj.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
> We make EPEL, ELN, and thousands of packages in Copr. These are all part of > Fedora — but aren't Fedora Linux. We also make artwork, music, > documentation, videos, websites, tools, and more. These things too are part > of our project, but aren't part of the Fedora Linux distribution. ELN also contains Linux, doesn't it? EPEL doesn't contain Linux, but Linux will always be present in the system when a package from EPEL is used. > When referring to our work, please use either a > specific name like Fedora Workstation, Fedora CoreOS, or > Fedora KDE Plasma Desktop; or use Fedora Linux to refer to > the OS distribution as a whole. I don't think "Linux" conveys the distinction between those things and ELN. Someone who hears "Fedora Linux" won't understand that it comprises both Workstation and CoreOS but not ELN. It would be better to come up with another word to denote a collection of software distributions that aren't "enterprise" distributions, and also not art, websites et cetera. A word that captures the essence of how the things it covers differ from all the other things. Maybe something like "Fedora Family", because it's a number of closely related distributions which are suitable for use at home? Or something like "Fedora Flow", alluding to frequent releases and a steady stream of updates? Björn Persson pgpQIZfjHla23.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Wed, 10 Mar 2021 at 09:28, Ondrej Dubaj wrote: > Hello, > > Thank you for your suggestions, but as you might understand, I do not have > the capacity to resolve problems of dependent packages when building with > autoconf-2.71. > As I wrote so far I found only two packages which are not ac 2.71 compliant which I've not been able to fix by adding a simple patch. IMO fixing found issues before f35 dev cycle is doable and can be finished without strain on anyone's capacity. In most of the cases people are not solving some issues because they don't know that actually it is some issue. In other words only pointing to/encircling the issues sometimes (IMO) it is +95% of success that issue will be solved quickly. it is another issue with Fedora that detecting such issues on massive scale could be a bit tricky because for some reasons instead fixing libtool and automake with explicit calling "autoreconf -fiv" before %configure JFDI/JFDIN approach has been chosen to fiddle in some ac/am/lt files. You can see that JFDI on https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_191 However by building all fedora packages only to check is package X still building or not by executing something like "rpmbuild -bc -D "_configure `autoreconf -fiv; configure' .spec" should be possible to probe probably +~98% cases when autoconf 2.71 may fail. .. ~+98% because in some cases %configure macro is used in spec file and in reality autoconf is not used in the exact source tree or because in some spec files %_configure macro is redefined and above commandline redefinition may collide with that. Such experiments can be done on copr builders. Probably similar experiments on the scale of all fedora packages are already done probably more than one time each month. So as you may already see *diagnosing *which Fedora packages are not ac 2.71 compliant it is *not *beyond anyone capacity .. because checking the whole distro against ac 2.71 effectively can be done by executing a single oneliner. At least after such a diag test build the exact list of problematic packages can be formed. Such list published will put enough/gentle pressure on exact source trees maintainer to fix such issues ASAP :P Those two packages which I've mention (gettext and openldap) I found by testing so far below number of packages: [tkloczko@barrel SPECS]$ grep "^autoreconf -fiv" *spec | wc -l 862 Initially there were more than two failing packages however only those two (gettext and openldap) did not end up with submitting MR/PR (in a few cases in the meantime new versions with merged fixes have been released). And yet another side comment. Necessary fix for ac 2.71 only if correctly done definitely will not break using source tree with ac 2.69. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Non-responsive maintainer check: nhorman - Neil Horman
Good morning, I'm initiating the non-responsive maintainer process for nhorman. I heard on the grapevine that he left Red Hat a few months ago, which - if true - would explain why some bugs for his packages were modified by RH employees so he is no longer the Assignee for them (and his email link is no longer colored red in BugZilla). Multiple open bugs exist, including unaddressed security issues and FTBFS issues: - dpdk: CVE-2020-14374 / RHBZ#1883273, CVE-2020-14375 / RHBZ#1883274, CVE-2020-14376 / RHBZ#1883275, CVE-2020-14377 / RHBZ#1883276, CVE-2020-143778 / RHBZ#1883277 - flannel: F34FTBFS / RHBZ#1923682 - jitterentropy: RHBZ#1925937 - rmd: F34FTBFS / RHBZ#1923470, RHBZ#1870539 - rng-tools: RHBZ#1891025 As I said, most of those were modified a few months ago so nhorman is no longer the Assignee, but he's still the main admin of all those packages (except only "admin" of flannel). I filed the non-responsive maintainer check ticket here: https://bugzilla.redhat.com/show_bug.cgi?id=1937303 Additional information: - src.fp.org lists only one activity during the last year, which was to merge one PR in January 2021 - koji shows regular builds until August 2020, but then only one build in January 21 (for the one PR merged in January) - last RHBZ activity (looking at comments on open + closed bugs) I could find was in August 2020 Does anybody know nhorman and/or can contact him about his Fedora packages? Or can anybody confirm that he left Red Hat, and if so, what should be done with the packages? Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Thanks for advice guys, setting commitish to back rawhide in copr. Sorry for the bad advice to other maintainers. Please use pull-requests against rawhide as Miro mentioned. Ondrej. On Wed, Mar 10, 2021 at 11:01 AM Miro Hrončok wrote: > On 10. 03. 21 10:47, Fabio Valentini wrote: > > On Wed, Mar 10, 2021 at 10:27 AM Ondrej Dubaj wrote: > >> > >> Hello, > >> > >> Thank you for your suggestions, but as you might understand, I do not > have the capacity to resolve problems of dependent packages when building > with autoconf-2.71. > >> > >> I can only prepare autoconf-2.71 and compat package autoconf2.69-2.69 > for other maintainers, so they are able to make appropriate changes and > test them in copr. Testing is possible by pushing the changes to a new > created branch "rawhide-autoconf-2.71", where in your package you can use > autoconf dependency (autoconf-2.71) or autoconf2.69 dependency (compat > package for autoconf-2.69). After pushing to the given branch, the package > will be built automatically in copr and you can test the update of your > package. You can do this many times until you are certain your package > works good. > >> > >> Thanks for understanding and cooperation. > > > > Please don't do branches like this in "official" dist-git > > repositories. It's a big PITA to clean up such branches. > > I concur. > > Set the committish of the packages in your copr to "rawhide". Packagers > can send > pull requests with changes and the results will appear in your Copr e.g. > in: > > > https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/builds/?dirname=autoconf-2.70:pr:18 > > Pull requests, unlike arbitrary branches, can be safely rebased until the > result > is good. Once merged, they are "gone" (technically, they remain in your > fork, > but that should not bother anybody and can be deleted if needed). > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On 10. 03. 21 10:47, Fabio Valentini wrote: On Wed, Mar 10, 2021 at 10:27 AM Ondrej Dubaj wrote: Hello, Thank you for your suggestions, but as you might understand, I do not have the capacity to resolve problems of dependent packages when building with autoconf-2.71. I can only prepare autoconf-2.71 and compat package autoconf2.69-2.69 for other maintainers, so they are able to make appropriate changes and test them in copr. Testing is possible by pushing the changes to a new created branch "rawhide-autoconf-2.71", where in your package you can use autoconf dependency (autoconf-2.71) or autoconf2.69 dependency (compat package for autoconf-2.69). After pushing to the given branch, the package will be built automatically in copr and you can test the update of your package. You can do this many times until you are certain your package works good. Thanks for understanding and cooperation. Please don't do branches like this in "official" dist-git repositories. It's a big PITA to clean up such branches. I concur. Set the committish of the packages in your copr to "rawhide". Packagers can send pull requests with changes and the results will appear in your Copr e.g. in: https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/builds/?dirname=autoconf-2.70:pr:18 Pull requests, unlike arbitrary branches, can be safely rebased until the result is good. Once merged, they are "gone" (technically, they remain in your fork, but that should not bother anybody and can be deleted if needed). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Wed, Mar 10, 2021 at 10:27 AM Ondrej Dubaj wrote: > > Hello, > > Thank you for your suggestions, but as you might understand, I do not have > the capacity to resolve problems of dependent packages when building with > autoconf-2.71. > > I can only prepare autoconf-2.71 and compat package autoconf2.69-2.69 for > other maintainers, so they are able to make appropriate changes and test them > in copr. Testing is possible by pushing the changes to a new created branch > "rawhide-autoconf-2.71", where in your package you can use autoconf > dependency (autoconf-2.71) or autoconf2.69 dependency (compat package for > autoconf-2.69). After pushing to the given branch, the package will be built > automatically in copr and you can test the update of your package. You can do > this many times until you are certain your package works good. > > Thanks for understanding and cooperation. Please don't do branches like this in "official" dist-git repositories. It's a big PITA to clean up such branches. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-32-20210310.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-20210309.0): ID: 806309 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/806309 ID: 806316 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/806316 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Hello, Thank you for your suggestions, but as you might understand, I do not have the capacity to resolve problems of dependent packages when building with autoconf-2.71. I can only prepare autoconf-2.71 and compat package autoconf2.69-2.69 for other maintainers, so they are able to make appropriate changes and test them in copr. Testing is possible by pushing the changes to a new created branch "rawhide-autoconf-2.71", where in your package you can use autoconf dependency (autoconf-2.71) or autoconf2.69 dependency (compat package for autoconf-2.69). After pushing to the given branch, the package will be built automatically in copr and you can test the update of your package. You can do this many times until you are certain your package works good. Thanks for understanding and cooperation. Ondrej On Tue, Mar 9, 2021 at 10:19 AM Tomasz Kłoczko wrote: > On Tue, 9 Mar 2021 at 06:57, Ondrej Dubaj wrote: > >> If any concerns about the autoconf2.69-2.69 compat package ? If needed it >> can be implemented as non-parallelly instalable, >> > > Really .. instead wasting time on packaging stuff which is ~7 years old it > would be better to use that time to fix one of those handful packages which > are still not ac 2.71 compliant (like openldap > https://bugs.openldap.org/show_bug.cgi?id=9485). > Listing all those failing packages + posting URL from where is possible to > upload ac 2.71 package would allow more people to work on those few > remaining packages which still needs to be cleaned/updated. > > Otherwise some stuff will end up like the firefox, mozjs, nss, nspr > packages which still are using even older autoconf :/ (which is in own > sense ridiculous that one of the most actively maintained source trees > still is using so old build tooling) > > Some time ago gcc, binutils IIRC received an update for ac 2.71 so at > least those two should be by now off-the-table (Am I right?). > > In many cases executing "autoupdate", adding patch out of the changes > generated by that command to spec and submitting PR/MR against the original > source tree is all what needs to be done. This is not rocket science .. > > So .. anyone knows any other packages dist sources trees on which > something like "autoreconf -fiv" fails? > So far I found only two like that: openldap and gettext (in that case most > of the issues are caused by using gnulib which is another swampy area). > > It is still plenty of time before the f35 cycle needs to be finished, and > still it can be done RightWay(tm) .. no rush. > > For now posting ~óne time a week with updates about progress on wiping out > ac 2.69 should allow IMO final upgrade autoconf to 2.71 relatively soon. > > kloczek > -- > Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Request to include package: coreboot
On Tuesday, 09 March 2021 at 21:17, Reon Beon via devel wrote: > coreboot-util is deprecated, no? https://src.fedoraproject.org/rpms/coreboot-utils is retired. Someone could still pick it up before F34 enters Final Freeze. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Schedule for Wednesday's FESCo Meeting (2021-03-10)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2021-03-10 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = (none) = Followups = #2584 Fedora 34 incomplete changes: 100% complete dealine https://pagure.io/fesco/issue/2584 = New business = #2582 F35 Change: rpmautospec - removing release and changelog fields from spec files https://pagure.io/fesco/issue/2582 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
How about changing /etc/redhat-release ? I am specifically asking this in the context of Vagrant, which seems to use this file to detect Fedora. Vít Dne 09. 03. 21 v 19:11 Matthew Miller napsal(a): On Tue, Mar 09, 2021 at 07:02:10PM +0100, Vít Ondruch wrote: Are we going to move from getfedora.org to getfedoralinux.org? Websites/design are still looking at the plan for the next generation of the user-oriented "brochure" websites. Remember, we don't have to solve all things immediately and at the same time. OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: "Fedora Linux" in /etc/os-release
I agree with David. While I am sure that we can fix every bit of the distribution and documentation to refer to "Fedora Linux", I don't think there is a way to change people to refer in colloquial language to Fedora, the operating system, as a Fedora Linux. I'll certainly keep using sentences such as "I have installed Fedora on my LP", because most of people will know what does it mean and it is shorted and well rooted. It won't be in bad faith, it'll be just simpler. Similarly people are using "I have installed Red Hat" referring to "Red Hat Enterprise Linux". However, I can imagine that somebody will correct me that the right way is to say "I have installed Fedora Linux on my LP", because "Fedora" does not exist in this context. Vít Dne 10. 03. 21 v 2:45 David Kaufmann napsal(a): On Tue, Mar 09, 2021 at 05:32:41PM -0500, Matthew Miller wrote: I agree that it's a little weird at first, but as Ben Cotton said, after the first hundred times or so it becomes natural. This is not necessarily true. Our university IT department changed its name about a decade ago, from three letters to four letters (both abbreviations). But now, about ten years later still noone apart from the officials use the new name. (Even they don't consistently use it, despite orders(!) to use the new name) I assume this is because the new name is clunkier - it could be pronounced as one syllable before and now all four letters need to be pronounced separately to not sound weird. I think this is similar to the Mandrake/Mandriva example. All the best, Astra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
