Review Request: Wult + Pepc

Hi all, https://bugzilla.redhat.com/show_bug.cgi?id=2099771 https://bugzilla.redhat.com/show_bug.cgi?id=2099789 Wult: Tool for measuring Intel CPU C-state wake latency Pepc: Power, Energy, and Performance configuration tool (wult dep) Happy to review in exchange. Cheers Ali

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

On Fri, Jun 24, 2022 at 01:20:27PM +0200, Dmitry Belyavskiy wrote: > Dear Richard, > > If the only problem is legacy (and unsafe) ciphersuites, loading the legacy > provider will solve this problem. Any clues on how to do that? Rich. > On Fri, Jun 24, 2022 at 1:11 PM Richard W.M. Jones wrote:

Re: Suggestion: Use a unified kernel image by default in the future.

* Neal Gompa: > I treat Secure Boot purely as a compatibility interface. We need to do > just enough to get through the secure boot environment. Right. It's not even clear to me why we enforce kernel module signatures in Secure Boot mode, and disable a few other kernel features. Thanks, Florian

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On Sun, Jun 26, 2022 at 12:36:14AM +0530, Vipul Siddharth wrote: > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

On 27/06/2022 08:53, Richard W.M. Jones wrote: On Fri, Jun 24, 2022 at 01:20:27PM +0200, Dmitry Belyavskiy wrote: Dear Richard, If the only problem is legacy (and unsafe) ciphersuites, loading the legacy provider will solve this problem. Any clues on how to do that? https://wiki.openssl.org

Re: Suggestion: Use a unified kernel image by default in the future.

On Sun, Jun 19, 2022 at 08:54:51PM -, Sharpened Blade via devel wrote: > Use unified kernel images by default for new releases. This can allow > for the local installation to sign the kernel and the initrd, so the > boot chain can be verified until after the uefi. Currently, the initrd > can be

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On Mon, Jun 27, 2022 at 10:10:31AM +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Jun 26, 2022 at 12:36:14AM +0530, Vipul Siddharth wrote: > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feed

Re: Suggestion: Use a unified kernel image by default in the future.

On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote: > On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour > wrote: > > > > On 6/25/22 07:56, Roberto Ragusa wrote: > > > On 6/19/22 22:54, Sharpened Blade via devel wrote: > > > > > >> Use unified kernel images by default for new releases. Thi

Fedora-Cloud-35-20220627.0 compose check report

No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20220626.0): ID: 1307561 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

On Mon, Jun 27, 2022 at 09:11:29AM +0100, Tom Hughes wrote: > On 27/06/2022 08:53, Richard W.M. Jones wrote: > >On Fri, Jun 24, 2022 at 01:20:27PM +0200, Dmitry Belyavskiy wrote: > >>Dear Richard, > >> > >>If the only problem is legacy (and unsafe) ciphersuites, loading the legacy > >>provider will

All maven RPM builds no longer possible

Hi all, I just tried to start from "probably simplest spec file possible” as described below in order to package a maven artefact properly as an RPM: https://docs.fedoraproject.org/en-US/java-packaging-howto/packaging_maven_project/ The build failed because the maven-javadoc-plugin package no l

Re: All maven RPM builds no longer possible

Hi, thanks for pointing this out, we have already been planning to update the howto guide soon™. On 27. 6. 2022 11:02, Graham Leggett via devel wrote: Hi all, I just tried to start from "probably simplest spec file possible” as described below in order to package a maven artefact properly as a

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

On 27/06/2022 10:02, Richard W.M. Jones wrote: On Mon, Jun 27, 2022 at 09:11:29AM +0100, Tom Hughes wrote: On 27/06/2022 08:53, Richard W.M. Jones wrote: On Fri, Jun 24, 2022 at 01:20:27PM +0200, Dmitry Belyavskiy wrote: Dear Richard, If the only problem is legacy (and unsafe) ciphersuites, l

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

Hi, Richard W.M. Jones wrote: On Mon, Jun 27, 2022 at 09:11:29AM +0100, Tom Hughes wrote: On 27/06/2022 08:53, Richard W.M. Jones wrote: On Fri, Jun 24, 2022 at 01:20:27PM +0200, Dmitry Belyavskiy wrote: Dear Richard, If the only problem is legacy (and unsafe) ciphersuites, loading the l

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

Hi, On 6/27/22 10:10, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Jun 26, 2022 at 12:36:14AM +0530, Vipul Siddharth wrote: >> This document represents a proposed Change. As part of the Changes >> process, proposals are publicly announced in order to receive >> community feedback. This proposal wi

Fedora rawhide compose report: 20220627.n.0 changes

OLD: Fedora-Rawhide-20220626.n.0 NEW: Fedora-Rawhide-20220627.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 33 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On Mon, Jun 27, 2022 at 11:20:13AM +0200, Hans de Goede wrote: > Hi, > > On 6/27/22 10:10, Zbigniew Jędrzejewski-Szmek wrote: > > On Sun, Jun 26, 2022 at 12:36:14AM +0530, Vipul Siddharth wrote: > >> This document represents a proposed Change. As part of the Changes > >> process, proposals are pub

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

On Mon, Jun 27, 2022 at 11:15:01AM +0200, Clemens Lang wrote: > Hi, > > Richard W.M. Jones wrote: > > >On Mon, Jun 27, 2022 at 09:11:29AM +0100, Tom Hughes wrote: > >>On 27/06/2022 08:53, Richard W.M. Jones wrote: > >>>On Fri, Jun 24, 2022 at 01:20:27PM +0200, Dmitry Belyavskiy wrote: > Dear

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On Mon, Jun 27, 2022 at 09:40:53AM +0100, Daniel P. Berrangé wrote: > On Mon, Jun 27, 2022 at 10:10:31AM +0200, Zbigniew Jędrzejewski-Szmek wrote: > > On Sun, Jun 26, 2022 at 12:36:14AM +0530, Vipul Siddharth wrote: > > > This document represents a proposed Change. As part of the Changes > > > proc

Re: Suggestion: Use a unified kernel image by default in the future.

On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé wrote: > > On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote: > > On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour > > wrote: > > > > > > On 6/25/22 07:56, Roberto Ragusa wrote: > > > > On 6/19/22 22:54, Sharpened Blade via devel wrote

Re: Suggestion: Use a unified kernel image by default in the future.

On Mon, Jun 27, 2022 at 07:46:29AM -0400, Neal Gompa wrote: > On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé > wrote: > > > > On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote: > > > On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour > > > wrote: > > > > > > > > On 6/25/22 07:56, Ro

Re: F37 Change Proposal: MAC Address Policy none (System-Wide

On Sat, Jun 25, 2022 at 08:39:22PM +, devel-requ...@lists.fedoraproject.org wrote: > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

As I said before I don't care that much what the policy is but I do care very much that Fedora keeps changing it. Twice now I have had to go and reconfigure my networks after a Fedora upgrade has changed the MAC assignment policy. My vote is therefore to leave it as it is so that I don't have to

Re: Suggestion: Use a unified kernel image by default in the future.

On Mon, Jun 27, 2022 at 7:59 AM Daniel P. Berrangé wrote: > > On Mon, Jun 27, 2022 at 07:46:29AM -0400, Neal Gompa wrote: > > On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé > > wrote: > > > > > > On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote: > > > > On Sat, Jun 25, 2022 at 4:14

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

Richard W.M. Jones wrote: I somehow thought that loading the legacy provider would be the same as the LEGACY crypto policy, except just for Python 2.7 rather than for the entire system. It’s a common misconception. So common that I recently wrote a blog post to explain the difference: http

Re: Suggestion: Use a unified kernel image by default in the future.

On Mon, Jun 27, 2022 at 08:12:08AM -0400, Neal Gompa wrote: > On Mon, Jun 27, 2022 at 7:59 AM Daniel P. Berrangé > wrote: > > > > On Mon, Jun 27, 2022 at 07:46:29AM -0400, Neal Gompa wrote: > > > On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé > > > wrote: > > > > > > > > On Sat, Jun 25, 202

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On 6/27/22 04:10, Zbigniew Jędrzejewski-Szmek wrote: > > > Re variant 2: the proposal limited to brige/bond devices seems much more > reasonable. In particular, the case described below of a server (virtualized > or not) in a big datacenter is the one case where the benefits of > MACAddressPolic

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On 6/27/22 07:34, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jun 27, 2022 at 09:40:53AM +0100, Daniel P. Berrangé wrote: >> On Mon, Jun 27, 2022 at 10:10:31AM +0200, Zbigniew Jędrzejewski-Szmek wrote: >>> On Sun, Jun 26, 2022 at 12:36:14AM +0530, Vipul Siddharth wrote: This document repres

Fedora-Rawhide-20220627.n.0 compose check report

Missing expected images: Minimal raw-xz armhfp Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 13/163 (aarch64), 12/233 (x86_64) New failures (same test not failed in Fedora-Rawhide-20220626.n.0): ID: 1307774 Test: aarch64 Workstation-raw_xz-raw

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

Hi, On Mon, 2022-06-27 at 13:09 +0100, Tom Hughes via devel wrote: > > Twice now I have had to go and reconfigure my networks after a Fedora > upgrade has changed the MAC assignment policy. Interesting. Are you sure it was twice? I thought it changed "only" once in F31 (2019). Thomas _

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On Mon, 2022-06-27 at 10:10 +0200, Zbigniew Jędrzejewski-Szmek wrote: > > > > - Deviate from upstream systemd. > > It is also important to mention that Fedora will "deviate" from > itself > (it's former self). We would be changing a default in place since > ~2013 [1]. > > [1] https://github.com/

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On 27/06/2022 17:05, Thomas Haller wrote: On Mon, 2022-06-27 at 13:09 +0100, Tom Hughes via devel wrote: Twice now I have had to go and reconfigure my networks after a Fedora upgrade has changed the MAC assignment policy. Interesting. Are you sure it was twice? I thought it changed "only" on

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On 27/06/2022 17:09, Tom Hughes via devel wrote: On 27/06/2022 17:05, Thomas Haller wrote: On Mon, 2022-06-27 at 13:09 +0100, Tom Hughes via devel wrote: Twice now I have had to go and reconfigure my networks after a Fedora upgrade has changed the MAC assignment policy. Interesting. Are you

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On Mon, Jun 27, 2022 at 06:08:13PM +0200, Thomas Haller wrote: > On Mon, 2022-06-27 at 10:10 +0200, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > - Deviate from upstream systemd. > > > > It is also important to mention that Fedora will "deviate" from > > itself > > (it's former self). We would b

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On Mon, 2022-06-27 at 10:10 +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Jun 26, 2022 at 12:36:14AM +0530, Vipul Siddharth wrote: > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feedback. T

Re: Meld directory compare still broken in f36

On 6/24/22 10:49, Andrea Musuruane wrote: Hi,     meld directory compare in f36 is broken. I opened a bug report last month: https://bugzilla.redhat.com/show_bug.cgi?id=2091377 Some days later, kiilerix provided a PR to fix this issue: ht

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On Mon, 2022-06-27 at 13:34 +0200, Zbigniew Jędrzejewski-Szmek wrote: > > I'm not "blaming" the tools, I completely understand that they were > written a long time ago. But in fact the issue is fairly generic: any > software which interacts with devices that udev also touches MUST > wait > for ude

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On Mon, 2022-06-27 at 17:26 +0100, Tom Hughes wrote: > On 27/06/2022 17:09, Tom Hughes via devel wrote: > > On 27/06/2022 17:05, Thomas Haller wrote: > > > > > On Mon, 2022-06-27 at 13:09 +0100, Tom Hughes via devel wrote: > > > > > > > > Twice now I have had to go and reconfigure my networks aft

Re: Suggestion: Use a unified kernel image by default in the future.

On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer wrote: > > * Neal Gompa: > > > I treat Secure Boot purely as a compatibility interface. We need to do > > just enough to get through the secure boot environment. > > Right. It's not even clear to me why we enforce kernel module > signatures in Secure

Re: F37 change proposal: Make Fedora CoreOS a Fedora Edition (System-Wide change)

On Sat, Jun 25, 2022 at 12:17 PM Vipul Siddharth wrote: > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steeri

Re: F37 change proposal: Make Fedora CoreOS a Fedora Edition (System-Wide change)

On 6/27/22 13:36, Chris Murphy wrote: > On Sat, Jun 25, 2022 at 12:17 PM Vipul Siddharth > wrote: >> >> This document represents a proposed Change. As part of the Changes >> process, proposals are publicly announced in order to receive >> community feedback. This proposal will only be implemente

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On 6/27/22 13:03, Thomas Haller wrote: > On Mon, 2022-06-27 at 10:10 +0200, Zbigniew Jędrzejewski-Szmek wrote: > >> - For "big" users (the datacenter case), changing the policy make >> sense, >>   but at the same time, those folks can just insert a policy >> override, >>   they're most likely u

Re: Suggestion: Use a unified kernel image by default in the future.

This is a good idea, but some users might want to modify or need to modify the command line to boot, if it was signed using fedoras key, then you cant do that. Also some users dont like keeping their trust in fedora and would like to modify their kernel freely. Also, though the private key is so

Re: Suggestion: Use a unified kernel image by default in the future.

The latest akmods version can automatically sign kernel modules, it could even be enabled by default. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: htt

Re: Suggestion: Use a unified kernel image by default in the future.

Secure boot itself, when used right, actually helps your privacy. Microsoft doesn't require oems to allow the keys to be changed, so it sometimes prevents your freedom, but when implemented right, it can stop evil maid attacks. Also, even when you cant remove Microsoft keys, you can still use th

Re: Suggestion: Use a unified kernel image by default in the future.

Akmods can automatically sign kernel modules, its just a few commands and then every version will be signed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduc

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On 6/27/22 13:03, Thomas Haller wrote: > On Mon, 2022-06-27 at 10:10 +0200, Zbigniew Jędrzejewski-Szmek wrote: >> On Sun, Jun 26, 2022 at 12:36:14AM +0530, Vipul Siddharth wrote: >>> This document represents a proposed Change. As part of the Changes >>> process, proposals are publicly announced in

Re: Suggestion: Use a unified kernel image by default in the future.

> How big is the demand for this kind of lockdown? It can help users security, but most users have no idea what this is. Software should be secure by itself, without users needing extra effort. > As a since-last-century Linux user, I'm choosing Fedora > exactly to NOT have all this signing/trust

Re: Suggestion: Use a unified kernel image by default in the future.

If the system owner wanted to, they could use their own firmware/ comprimise firmware, then fake the firmware version to something new, the vm could not even be interacting with the cpu at all. Also, if the keys are in the cpu, then the keys can be extracted.

Re: All maven RPM builds no longer possible

On Mon, Jun 27, 2022 at 3:04 AM Graham Leggett via devel wrote: > I just tried to start from "probably simplest spec file possible” as > described below in order to package a maven artefact properly as an RPM: > > https://docs.fedoraproject.org/en-US/java-packaging-howto/packaging_maven_project/

Re: Suggestion: Use a unified kernel image by default in the future.

On 6/27/22 13:34, Chris Murphy wrote: > On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer wrote: >> >> * Neal Gompa: >> >>> I treat Secure Boot purely as a compatibility interface. We need to do >>> just enough to get through the secure boot environment. >> >> Right. It's not even clear to me why we

Re: Permission errors with fedora-review and mock

On Sat, Jun 25, 2022 at 12:33 PM Mark E. Fuller wrote: > Up to a couple days ago, mock and fedora-review were working fine for > me, but just recently I have started getting permission errors: > > ``` > ... > Building target platforms: x86_64 > Building for target x86_64 > setting SOURCE_DATE_EPOC

Re: Permission errors with fedora-review and mock

Thank you very much - that fixed it On 27/06/2022 22:50, Jerry James wrote: On Sat, Jun 25, 2022 at 12:33 PM Mark E. Fuller wrote: > Up to a couple days ago, mock and fedora-review were working fine for > me, but just recently I have started getting permission errors: > > ``` > ... > Building

RFC: squashfuse multi-threaded rewrite

Hi all, Kevin has a PR that rewrites squashfuse to be multi-threaded: https://github.com/vasi/squashfuse/pull/70 I've put up a PR backporting this on top of the recently released 0.1.105 which is now built for Rawhide: https://src.fedoraproject.org/rpms/squashfuse/pull-request/3 Does anyone have

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

> The `systemd-udev` package installs > `"/usr/lib/systemd/network/99-default.link"`, > which sets `Link.MACAddressPolicy=persistent`. This proposal is to > change it to set `Link.MACAddressPolicy=none` to stop changing the MAC > address. This is particularly important for bridge and bond devices.

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

On Sat, Jun 25, 2022 at 3:06 PM Vipul Siddharth wrote: > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steerin

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

Once upon a time, Neal Gompa said: > I'd be interested in seeing the justification for the revert in RHEL > 9. From my perspective, it doesn't make sense to disable this because > it makes bonds/teams/etc. device dependent. This can be particularly > bad if you've got a bond and then you swap out

Re: Suggestion: Use a unified kernel image by default in the future.

On 27/06/2022 21:18, Sharpened Blade via devel wrote: Also, even when you cant remove Microsoft keys, you can still use the shim. If you can't remove Microsoft keys, you're nullifying the whole purpose of secure boot, because anyone can use a signed shim to boot whatever they want. Also, if

Re: Suggestion: Use a unified kernel image by default in the future.

On 27/06/2022 21:19, Sharpened Blade via devel wrote: Akmods can automatically sign kernel modules, its just a few commands and then every version will be signed. Yes, but anyone can read your private keys to sign anything. Someone needs to implement support for hardware tokens, or at least T