Re: It’s time to transform the Fedora devel list into something new
On 4/20/23 17:20, Matthew Miller wrote: Most of the conversation was under the subject “Schedule for Tuesday's FESCo Meeting (2023-01-03)”, because everything started as a reply to that. That’s pretty easy to overlook. It’s possible for replies to change the subject when replying, but that can’t be done retroactively, and then isn’t consistent (and it breaks threading in Gmail, too). At the risk of causing at least one of the problems that Matthew pointed out, this is the most important one for me: lots of people say "I decide what to read based on what I see in my email client", but when the subject of the emails doesn't reflect their contents, that's a losing proposition. I completely ignored the thread in question until a *different* thread referred to it and I learned about the conversation going on there. On another note: I've been an active Discourse user since the 'early adopter' days, and frequent at least six Discourse sites of varying content volumes. I've learned good ways to stay on top of what is going on without having to open each site on a daily basis, and while it's not as low-effort as mailing lists are, I've found the benefits to be worth the increased effort. In fact many of the replies in this thread have complaints/concerns about aspects of Discourse usage which have been 'solved' already, but the person making the complaint/voicing the concern just isn't aware of the solutions available yet... so for those people I encourage you to ask for assistance learning how to address the problems you perceive, instead of claiming the problems can't be solved. A case in point is the statement "it's so hard to know what's new": I struggled with this as well, until I learned about configuring the behavior of the 'New' tab in Discourse, and aggressively filtering out categories and tags I do not care about. Now I can click 'refresh' while looking at the 'New' tab on a highly active site and I will see *all* of the New topics that are of potential interest to me. In the end this is very similar to taking the same actions in a local mail client, but more capable since it is based on metadata about the topics and not just the often-incorrect subject lines in email threads. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: invalid 'sshpubkey': invalid SSH public key
On 4/19/23 15:42, Kevin Fenzi wrote: On Wed, Apr 19, 2023 at 06:45:57PM +, Kenneth Goldman wrote: Newbie - first time . I'm trying to upload my SSH public key to my fedora project account. The web page gives me the above error. My key is an RSA 4096 key. ssh-rsa B3NzaC1yc2EDAQABAAACAQ . y4lWQ==kgold...@us.ibm.com <mailto:kgold...@us.ibm.com> Is that the wrong format? Is RSA-4096 invalid. In the file, the key has no newlines. Is that a problem? It works on github and our internal git repo. No, that should work fine. Make sure you put it all on one line and it has the full format... ie, ssh-rsa the-key-ending-with== comment Maybe the bit at the end is causing the issue? -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fwd: License: GPL-3.0-or-later AND GPL-2.0-or-later
On 3/14/23 10:04, Caolán McNamara wrote: On Tue, 2023-03-14 at 08:47 -0500, Michael Catanzaro wrote: ... LibreOffice ... FWIW I updated the LibreOffice one a while ago and ended up with: MPL-2.0 AND Apache-2.0 AND LGPL-3.0-only AND LGPL-3.0-or-later AND CC0- 1.0 AND BSD-3-Clause AND (LGPL-2.1-only OR SISSL) AND (MPL-2.0 OR LGPL- 3.0-or-later) AND (MPL-2.0 OR LGPL-2.1-or-later) AND (MPL-1.1 OR GPL- 2.0-only OR LGPL-2.1-only) Pardon the small digression... One of the benefits of switching to this sort of license tag in the RPMs is that it is purely objective fact; there are no subjective determinations or opinions involved. So, for example, if that expression above applies to the source tarball (or repository tag) for LibreOffice 7.5.2.1, that expression is not in any way specific to Fedora; it's the same for everyone who consumes that source release, no matter how they are packaging it. This opens the door to sharing the burden across all those who consume the source releases, and even reaching community consensus on what the proper license expression is for any given source release, sharing that expression with the upstream project so that it can be used by anyone else in the future who needs it, and collaborative updates to the expression when new source releases are made. This was (and still is) the goal of the OSI's ClearlyDefined project: community collaboration to produce consensus license expressions for a given source artifact, including separation into facets (content which ends up in the binaries, content which is used for build and/or test, content which is documentation, etc.). It hasn't really taken off like many had hoped it would, but it also hasn't died... it just needs more large projects (like Fedora) to decide that it would be better for the overall community if the results of the license scans were contributed to a global database instead of just stored with the project's sources. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changes to Bugzilla API key requirements
On 2/24/23 11:55, Solomon Peachy via devel wrote: (I admit I'm surprised that "Free Software for Everything" Red Hat is chosing to base something so fundamental to their business on a highly proprietary tool. I suppose O365 is just a matter of time...) Not O365, but Google Workspace... that ship sailed some time ago (I'm sending this using Thunderbird going through Google Workspace, so at least I don't have to *see* GMail...) -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: drop delta rpms (for real this time)
On 2/21/23 15:53, Fabio Valentini wrote: It's been a long, long, time since any dnf transaction I ran printed positive news about deltarpms ... most of the time there either aren't any, or using them actually increased data download. A recent transaction went so poorly that it prompted me to disable deltarpms completely on my system. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When to close CVE's
On 1/20/23 11:47, Gary Buhrmaster wrote: I agree, and that seems to be an artifact of the single Fedora component in RHBZ, which treats Fedora as one thing. I supposed (in theory again) that there could be a master bugzilla for the CVE which depends on child bugzillas for each impacted Fedora release, and would get (auto) closed only when all the child bugzillas are resolved (either by updates or the Fedora release aging out). Alternatively, an entirely different bugzilla for each Fedora release (but as Fedora is just a single component, unlike each RHEL which has different components for each version, I don't think that works). Small clarification: where you wrote 'component' you meant 'product' :-) BZ has both Products and Components, forming two levels. RHEL 7/8/9 are Products, on the same level as Fedora. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: -Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python
On 1/16/23 13:39, Miro Hrončok wrote: Isn't Python built e.g. with -Werror=format-security or -Wsign-compare binary compatible with extension modules built without it? That's a good question, it's almost as if "extension_flags" should be named "abi_compatibility_flags" or something similar. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
On 10/13/22 11:28, Demi Marie Obenour wrote: systemd (yes, systemd) is considering using Rust, though it has not yet started including it, and there is already Rust code in Mesa IIRC. Don't forget the Python 'cryptography' package... also a Rust user. It's here to stay, at least for the foreseeable future. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
On 10/12/22 08:59, Stephen Smoogen wrote: Maybe call it the Fedora Update Manager 'FUM' ? Unless we're going to call it RUM when it makes its way into RHEL, that name may not be the best choice :-) -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mesa in F37- vaapi support disabled for h264/h265/vc1
On 9/28/22 22:42, Gary Buhrmaster wrote: So, for CPU's with iGPUs sold retail to people like me, does Intel (and now including AMD) include the IP license? If not, how can I get one from Intel (who sold me a CPU/iGPU that states it can decode the codecs in question)? To be pedantic... the CPU manufacturer claims that the GPU/iGPU provides *acceleration* for decoding of content that has been encoded with the codecs in question. The distinction is important, because the GPU/iGPU cannot do the job on its own, software is required to set it up, feed the data in the right format, and other things, and as has been noted in this thread earlier it's the final combination that appears to trigger patent infringement. A patent lawyer could probably make the case that if the functionality in the GPU/iGPU has no other useful purpose *except* for decoding this type of content, then the hardware alone is infringing, but that's a totally different discussion. Since Intel and AMD employ large numbers of highly-trained patent lawyers, presumably they've decided that they do not need to address this concern. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Joining Fedora Chat from own Homeserver
On 9/12/22 06:44, Michel Alexandre Salim wrote: That unfortunately seems typical -- I'm joining the space from a different server too (Element One, ironically*also* hosted by EMS). Joining from a different homeserver seems to be a bit unreliable no matter which two servers are involved, especially for larger rooms (getting this issue joining Debian, FOSDEM, and Linux Plumbers rooms too). This is an area of active development by the Matrix team; joining *large* rooms (either large numbers of participants, large numbers of messages, or both) is currently slow because it's a synchronous operation. Your client waits for your server, which waits for the complete backfill of the participant list and some amount of the message history. There are changes coming shortly to make this process asynchronous, which should help significantly. For now, what I've seen is that you attempt to join the room, after 60 seconds or so your client reports a failure, and then 5-10 minutes later you attempt to join again and it works; I believe this is happening because the backfill process continues on your server even though your client gave up. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Emacs 28 (Self-Contained Change proposal)
On 7/20/22 14:57, Marcus Müller wrote: Oh! That comes as a surprise. Let me try a rebuild! :( I was really looking forward to emacs-pgtk. Forgive my relative newbie-ness here, but this proposal is to upgrade Emacs to version 28 in F37. That seems fine. This week my F36 system got upgraded to Emacs version 28, so it's already in F36. How is that possible? -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On 6/30/22 11:08, Vitaly Zaitsev via devel wrote: On 30/06/2022 17:47, Gary Buhrmaster wrote: If you do not understand this, talk to*your* lawyer (only your lawyer is responsible to you) and have them explain the details and distinctions and reasonings to you. Each court publishes the reasoning part of the decision. This is not a court. It is a group of attorneys providing advice to their client (which happens to be their employer). -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
On 6/22/22 15:05, Vipul Siddharth wrote: == Benefit to Fedora == This proposal ensures than no new packages in Fedora will rely on the deprecated OpenSSL version that will cause an overall increase of security/stability, and will reduce the amount of old packages relying on OpenSSL 1.1 series. This sentence is too long, and as a result I don't think readers will understand it the way it was intended. I suggest simplifying to: --- This proposal ensures that no new packages in Fedora will rely on the deprecated OpenSSL version. That change will cause an overall increase in security/stability, and will reduce the amount of old packages relying on OpenSSL 1.1 series. --- In addition to the wording changes, do you mean 'package-versions' here where you say 'packages'? Is a new version of OpenSSH, for example, considered a 'new package' for the purposes of this proposal? -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: SPDX identifiers in old branches?
On 5/26/22 15:00, Gary Buhrmaster wrote: Other than the MIT case (and it should not be swept under the rug), are there any substantial use of licenses in Fedora where the Fedora license id and the SPDX license id can lead to confusion as to which is being specified? Fedora uses 'BSD' for a variety of licenses, many of which have specific SPDX identifiers. MIT and BSD are the most common problem areas for this situation. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/26/22 11:06, Stephen Smoogen wrote: 2. Are there ways that a non-TCK compliant version could be distributed? I would suggest phrasing that slightly differently: the version being distributed could very well be fully compliant (would pass the TCK if tested), but may not have been tested. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: remove-retired-packages feedback
On 5/26/22 09:52, Miroslav Suchý wrote: If you already upgraded to Fedora 36 - what is your feedback about https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/sysadmin/System_Utilities/#remove-retired-packages Did you run the command `remove-retired-packages`? Do you find it useful? Comments and ideas are welcome either here or at: https://github.com/xsuchy/fedora-upgrade/issues Just be sure that you have latest version, i.e., remove-retired-packages-36.3. Well, thanks for posting this: I hadn't been aware of this tool at all :-) I just installed it and ran it, and it found just two Intel wireless firmware packages to remove. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 5/17/22 14:35, David Cantrell wrote: I think a better thing to do would be to use a scanner like scancode[1] to check the source tree in question and then construct a License expression for the spec file from its results. In many cases it will be the same as what we have in the spec file, just with different identifiers. But we would be using the opportunity to both move to new license identifiers and audit the information at the same time. Note that scancode isn't perfect, but it would be used as a workflow tool here as the contributor audits the licensing information in a package. I realize this is a lot of work. It would be best done in hackfest type sessions with work divided up in the subsets of packages. It would be a good opportunity for new contributors to learn how things are structured and send PRs to existing packages. [1] https://github.com/nexB/scancode-licensedb In addition to that, in an ideal world the results of this scan-and-analyze operation would not live *in* Fedora, but would be pushed upstream so that the canonical distribution of the software has the proper SPDX expression for its license(s). There are various community efforts under way to attack the problem in this fashion (ClearlyDefined[1] being one of them), and pushing the results of the license analysis as far 'left' as possible benefits everyone. [1] https://clearlydefined.io/about -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/10/22 09:29, Ben Cotton wrote: We already made a heavy testing of the behavior, and user should not face negative experience. I'm not sure if this is Might be a copy-paste error there, the last sentence is incomplete. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
On Mon, May 2, 2022 at 3:28 PM Chris Adams wrote: > Once upon a time, Florian Weimer said: > > At least that's a solvable problem: perform DNSSEC validation (to > > prevent actual attacks) and pretend to clients that you didn't do it (to > > avoid relying on signatures which aren't policy-confiorming). DNSSEC > > supports that approach quite well for ordinary record types. It's > > different from the web, where https:// and http:// are not equivalent in > > practice for many domains, and the schema is also visible to Javascript. > > A validating resolver only returns validated results to clients. > There's no "validate but pretend you didn't" mode - if you are a > validating resolver, you either return the record and NOERROR, or you > set SERVFAIL. > > Different servers have some ways to override validation, typically on a > per-name basis (so when foo.com breaks their DNSSEC but you have too > many customers that need to get to foo.com to leave it broken). I'm not > aware of any that any policy hooks to do something similar on an > algorithm basis, and definitely not to do the validation but then > pretend you didn't. If you want to propose such behavior, you'll need > to get that upstream first (at least in BIND, Unbound, and dnsmasq). > > And that behavior would also require that the underlying library be able to expose the fact that the signature validation failed due to local policy, so that the resolver could make use of that information. It sounds like the proposal here would be: * Do the validation; if it succeeds, tell the client (if they asked). * If it fails, but due to local policy, then tell the client no validation was attempted (if they asked). * If it fails, but not due to local policy, then tell the client SERVFAIL. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
On Sun, May 1, 2022 at 12:14 PM Dan Čermák wrote: > > They are going to break things, but Ubuntu 22.04 deprecated SHA1 > signatures already, so it's very likely that a good chunk of the fallout > will be cleared by the time Fedora 38 and 39 ship. > > In a similar (parallel) discussion related to future RHEL, it has been found this change also breaks resolution of many DNSSEC-secured domains which are still using SHA1 signatures. It is impossible to know how long it will be before those domains upgrade to better signatures, and at the moment it's rather challenging for resolvers to be able to determine that the resolution failure was caused by local policy instead of an actual invalid 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
F35 -> F36 Beta: Previously-masked systemd services were unmasked during upgrade
(moving thread here from Ask Fedora) I use `tlp` and `tlp-rdw` on my laptop to manage power/performances modes, and enable/disable the WiFi radio. With F35 this was working fine. On Friday I did an in-place upgrade to F36 Beta, and this morning I realized that two default services that I had masked (so that `tlp` could do its job) were unmasked during the upgrade. Specifically, `power-profiles-daemon.service` and `systemd-rfkill.service` were unmasked. Since masking creates a symlink (to /dev/null) in /etc/systemd/system, which is a user-managed directory, I was quite surprised that the upgrade removed the symlinks. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: unsafe systemd setup in Fedora
On Thu, Mar 3, 2022 at 8:24 AM Lennart Poettering wrote: > > badly. One good example for that is crond: you never know what cron > jobs intend to do, hence you cannot sandbox crond as a whole > reasonably. Moreover, runtime matters: short-lived stuff is much less > > I've also run into another complication with sandboxed units: using the 'normal' override processes to, for example, add one or two ExecStartPre commands to a service means that those commands will *also* be run in the sandboxed environment. The solution of course is to put those into their own service unit and setup proper dependencies so that they will be run at the proper time, but it can definitely surprise the user (it certainly surprised me). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Is NetworkManager-wait-online.service necessary by default?
On Wed, Feb 23, 2022 at 4:25 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > So this is the culprit. iscsi.service has Before=remote-fs-pre.target, > After=network-online.target, which means that it'll delay the boot. > remote-fs-pre.target is Before remote-fs.target which is Before > multi-user.target. > (Also see the chart in bootup(7).) > > There's a chain of deps that goes all the way to gnome-boxes and tmt: > iscsi-initiator-utils ← libvirt-daemon-driver-storage-iscsi ← > libvirt-daemon-driver-storage ← libvirt-daemon-kvm ← gnome-boxes, > > iscsi-initiator-utils ← libvirt-daemon-driver-storage-iscsi ← > libvirt-daemon-driver-storage ← libvirt ← python3-testcloud ← > tmt-provision-virtual > ← tmt-all. > > At least the dependency in gnome-boxes means it'll be installed > e.g. on Workstation. > > I see three+ solutions: > a) change libvirt-daemon-driver-storage > Requires:libvirt-daemon-driver-storage-iscsi >to Suggests:libvirt-daemon-driver-storage-iscsi, > b) change the preset for iscsi.service to disabled, > c) drop the ordering in iscsi.service, > d) some combination of the above > > Can confirm; 'systemctl disable iscsi.service' and a reboot of my F35 laptop resulted in a GDM login prompt before the network connection had even been completed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: dnf install removes /etc/systemd/system/multi-user.wants/myservice.target symlink
On Mon, Feb 7, 2022 at 5:52 PM Barry wrote: > > > On 7 Feb 2022, at 19:19, Kevin P. Fleming wrote: > > > Slightly off-topic, but I think it's relevant: > > If 'myservice' and 'ods-prx' are referring to the same thing, I think > you're supposed to use 'systemctl preset' instead of 'systemctl enable'. > This allows the admin to decide whether the installed > service/target/timer/etc. should be enabled during package installation. I > recently learned about this feature and am using it to good effect on my > own systems to stop packages from auto-starting the services they install > :-) > > > Yes myservice and ods-prx are the same. > > Yes preset is nice providing defaults for the admin. > > But this is for production system and it must be symlinked. > > Are you saying that there is code in dnf/rpm that is undoing the symlinking > becuase the preset is not in place? > > > No, I'm not, but it could be possible for such code to exist :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: dnf install removes /etc/systemd/system/multi-user.wants/myservice.target symlink
Slightly off-topic, but I think it's relevant: If 'myservice' and 'ods-prx' are referring to the same thing, I think you're supposed to use 'systemctl preset' instead of 'systemctl enable'. This allows the admin to decide whether the installed service/target/timer/etc. should be enabled during package installation. I recently learned about this feature and am using it to good effect on my own systems to stop packages from auto-starting the services they install :-) On Mon, Feb 7, 2022 at 1:55 PM Barry Scott wrote: > This is not for a package in Fedora, its for a package I'm > working on for Oracle Linux 8. > > I install /usr/lib/systemd/system/myservice.target > that has: > > [Install] > WantedBy=multi-user.target > > In %post I run this: > > ls -l /etc/systemd/system/multi-user.target.wants > /usr/bin/systemctl --no-reload enable ods-prx.target > ls -l /etc/systemd/system/multi-user.target.wants > echo "Info: post done" > > When I dnf install myservice I see that the symlink is > setup from the ls -l output in the %post section. > > But later in the output I see this line: > > Info: post done > > Running scriptlet: myservice-2022.1-20220207180603.noarch > Removed /etc/systemd/system/multi-user.target.wants/myservice.target. > > Is this expected? > > How can I stop this happening? > > If its not expected how can I pull apart the RPM to find the code that is > running? > > Barry > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?
I just saw this today, btrfs+LUKS, Micron MTFDHBA256TDV. May not have been five minutes, but it was a long time, and DNF consumed an entire CPU during that time. On Sat, Jan 29, 2022 at 3:39 PM Chris Murphy wrote: > On Sat, Jan 29, 2022 at 4:12 AM Vitaly Zaitsev via devel > wrote: > > > > On 24/01/2022 01:52, Tom Hughes via devel wrote: > > > Probably so the file is replaced atomically, and you either > > > have the old or new version but never a partial version. > > > > Can be easily reproduced with FEDORA-2022-a581f05398 update: > > installation of breeze-icon-theme will hang dnf for 5 minutes. Tested on > > 2 different PCs. Both has NVMe SSD and ext4+LUKS. > > Huh, interesting we're getting such mixed results with ext4. We need > more data to see what the pattern is. Some flash drives, as fast as > they are in normal write workloads, can get extremely bogged down and > take minutes to recover. So I wouldn't discount hardware as a > contributing factor, even if it is also a regression. > > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > 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
