Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Wed, Jul 1, 2020 at 6:35 am, Zbigniew Jędrzejewski-Szmek wrote: 'sudo dnf install micro' ;) It seems to work nicely. I especially like the standard keyboard shortcuts. I can't figure out how to Undo in nano, but in micro I just Ctrl+Z. I have not much opinion on whether we should use

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On 01. 07. 20 16:24, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager == Summary == BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper library, which will set OpenBLAS as system-wide default backend, and at the same time will provide a

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Wed, 1 Jul 2020 at 17:53, Jerry James wrote: > > On Wed, Jul 1, 2020 at 8:25 AM Ben Cotton wrote: > > > > Mechanisms such as update-alternatives and modules have been discussed > > in the past, but were considered improper (the former) or faced > > technical issues (the former). > > I think

Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

On 7/1/20 4:09 PM, Fabio Valentini wrote: > On Wed, Jul 1, 2020 at 4:00 PM Jiri Vanek wrote: >> >> On 7/1/20 3:21 PM, Fabio Valentini wrote: >>> On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov >>> wrote: Fabio, does it mean that the Java SIG agrees with progressing with the

Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

On Wed, Jul 1, 2020 at 5:49 pm, Vitaly Zaitsev via devel wrote: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D4FVY3LLMNGUKNUOEIDXNOOAD577W5XN/ None of the comments in that thread support the claim that we cannot ship configuration files generated by

Re: Cleaning up comps packages in rawhide

On Tue, Jun 30, 2020 at 05:46:11PM -, Ian McInerney wrote: > I have been going through the packages listed in the comps file for rawhide > (given in here https://pagure.io/fedora-comps) to clean it up and remove any > packages that are currently not in any Fedora rawhide repos, and to update

Re: The future of legacy BIOS support in Fedora.

On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote: > I'm currently using BIOS, grub, grub2 basically everywhere, even on > fresh new machines, This won't be the case for much longer; Intel will finally drop CSM ("BIOS") support this year. Even putting that aside, for the past

Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

So the last two times thermald was proposed (first as a F32 change proposal, then more recently to the Workstation WG) it was rejected on the grounds that it was not useful without dptfxtract installed. Now it's clear that everybody was mistaken about that, so seems it makes sense to

Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

On 30.06.2020 22:38, Michael Catanzaro wrote: > Any references would be very interesting, thanks. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D4FVY3LLMNGUKNUOEIDXNOOAD577W5XN/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org)

Re: out of Koji disk space

On Wed, Jul 01, 2020 at 03:38:26PM +0200, Jan Kratochvil wrote: > On Wed, 01 Jul 2020 15:14:09 +0200, Stephen John Smoogen wrote: > > At the moment we have about 10% of the hardware > > we shipped back in operation and there are at least 2 to 3 weeks to > > get the rest up. Getting up larger

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Wed, Jul 1, 2020 at 8:25 AM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager > > == Summary == > BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper > library, which will set OpenBLAS as system-wide default backend, and > at the same

Re: python-sphinx_rtd_theme update: comments requested

On Wed, Jul 1, 2020 at 5:21 AM Miro Hrončok wrote: > I've worked on this in > > https://src.fedoraproject.org/fork/churchyard/rpms/python-sphinx_rtd_theme/commits/generator > > However, there is "tiny little problem" that makes it not work: > >

Re: The future of legacy BIOS support in Fedora.

On Wed, Jul 1, 2020 at 4:36 PM Lennart Poettering wrote: > > On Mi, 01.07.20 13:14, Javier Martinez Canillas (jav...@dowhile0.org) wrote: > > > I'm not sure if this is completely fair, it's true that GRUB's blscfg > > module diverged from the spec by adding support for variables but it > > can

Re: The future of legacy BIOS support in Fedora.

On 2020-06-30 15:34, Jóhann B. Guðmundsson wrote: Share your thoughts and comments on how such move might affect you so feedback can be collected for the future on why such a change might be bad, how it might affect the distribution and scope of such change can be determined for potential

Re: The future of legacy BIOS support in Fedora.

On Tue, Jun 30, 2020 at 12:35 PM Robbie Harwood wrote: > Igor Raits writes: > > > I think this is the only path forward that can actually work. Without > tooling, the only real way to "migrate" from legacy to UEFI is to > reinstall the operating system - much love to anaconda, but that's not >

Re: out of Koji disk space

On Wed, 1 Jul 2020 at 09:38, Jan Kratochvil wrote: > > On Wed, 01 Jul 2020 15:14:09 +0200, Stephen John Smoogen wrote: > > At the moment we have about 10% of the hardware > > we shipped back in operation and there are at least 2 to 3 weeks to > > get the rest up. Getting up larger builders is

Re: The future of legacy BIOS support in Fedora.

On Mi, 01.07.20 13:14, Javier Martinez Canillas (jav...@dowhile0.org) wrote: > I'm not sure if this is completely fair, it's true that GRUB's blscfg > module diverged from the spec by adding support for variables but it > can also parse BLS snippets that follow the spec verbatim. You missed the

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

Le mercredi 01 juillet 2020 à 10:27 -0400, Neal Gompa a écrit : > On Wed, Jul 1, 2020 at 10:26 AM Nicolas Mailhot via devel > wrote: > > > > Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski- > > Szmek > > a écrit : > > > > > > Actually that part has been answered pretty

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On Wed, Jul 01, 2020 at 04:25:31PM +0200, Nicolas Mailhot via devel wrote: > Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-Szmek > a écrit : > > > > Actually that part has been answered pretty comprehensively. The > > split between / and /home is hurting users > > Actually

Re: The future of legacy BIOS support in Fedora.

On Mi, 01.07.20 14:45, Hans de Goede (hdego...@redhat.com) wrote: > I'm not in the bootloader-team, but I do work very closely with them, > so I have only one question: who is going to pick up the extra > maintenance load this is going to cause ? There are distros already using it. And so far we

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On Wed, Jul 1, 2020 at 10:26 AM Nicolas Mailhot via devel wrote: > > Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-Szmek > a écrit : > > > > Actually that part has been answered pretty comprehensively. The > > split between / and /home is hurting users > > Actually this split

Re: The future of legacy BIOS support in Fedora.

On 2020-06-30 14:34, Jóhann B. Guðmundsson wrote: Share your thoughts and comments on how such move might affect you so feedback can be collected for the future on why such a change might be bad, how it might affect the distribution and scope of such change can be determined for potential

FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager == Summary == BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper library, which will set OpenBLAS as system-wide default backend, and at the same time will provide a proper switching mechanism that currently

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/1/20 7:49 AM, Steven Whitehouse wrote: Hi, On 01/07/2020 12:09, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote: Hi, On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-Szmek a écrit : > > Actually that part has been answered pretty comprehensively. The > split between / and /home is hurting users Actually this split is a godsend because you can convince anaconda to leave your home alone when

FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager == Summary == BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper library, which will set OpenBLAS as system-wide default backend, and at the same time will provide a proper switching mechanism that currently

Introducing modulemd-tools

Hello, I would like to let you know, that we started a project called modulemd-tools. It is a collection of small tools for parsing and generating modulemd YAML files. At this moment, it provides two scripts - one for generating a modulemd YAML file based on an existing YUM repository, the other

[SONAME BUMP] aom version 2.0.0

Hi, I intend to bump the SONAME of libaom from 0 to 2 next week. Affected packages are the following: PACKAGE DEPENDENT DEPENDENCIES libaom-1.0.0-9.20190810git9666276.fc32.x86_64

Re: The future of legacy BIOS support in Fedora.

On Mi, 01.07.20 00:38, Kevin Kofler (kevin.kof...@chello.at) wrote: > In addition, as far as I know, systemd-boot is not compatible with the > "Secure Boot" shim. You are wrong. It is. Lennart -- Lennart Poettering, Berlin ___ devel mailing list --

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On Wed, Jul 1, 2020 at 7:54 AM Stephen Gallagher wrote: > > On Tue, Jun 30, 2020 at 9:03 PM Michael Catanzaro > wrote: > > > > > > On Tue, Jun 30, 2020 at 7:16 pm, Stephen John Smoogen > > wrote: > > > The issue isn't that you haven't done your work. It is that it looks > > > like you were set

Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

On Wed, Jul 1, 2020 at 4:00 PM Jiri Vanek wrote: > > On 7/1/20 3:21 PM, Fabio Valentini wrote: > > On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov > > wrote: > >> > >> Fabio, does it mean that the Java SIG agrees with progressing with the > >> Change to Java 11 as a default? > > > >

Re: [Fedora-packaging] Re: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

Le mercredi 01 juillet 2020 à 12:27 +0200, Dominik 'Rathann' Mierzejewski a écrit : Hi, > That's not detailed at all. You should provide at least one example > here (or a direct link to one somewhere else on the wiki). Thank you for your attention and kind review. yes the wiki page was

Re: [fedora-java] Questions on an update to javamail in ursine

On Mon, Jun 29, 2020 at 4:06 PM Jie Kang wrote: > > Hi all, > > javamail ursine is using version 1.5.2 while there are some module > streams at 1.6.x > > The upstream project also moved to the eclipse foundation and these > 1.6.x releases have different exports for OSGi, making an update to >

Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

On 7/1/20 3:21 PM, Fabio Valentini wrote: > On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov > wrote: >> >> Fabio, does it mean that the Java SIG agrees with progressing with the >> Change to Java 11 as a default? > > Speaking for myself, yes. > > I can't speak for all other SIG members (we

Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

On 2020-07-01 15:43, Neal Gompa wrote: > On Wed, Jul 1, 2020 at 9:40 AM Peter Rajnoha wrote: >> >> On 7/1/20 2:03 PM, Neal Gompa wrote: >>> On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha wrote: On 6/30/20 9:35 PM, Igor Raits wrote: > On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton

Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

On Wed, Jul 1, 2020 at 4:50 PM Alex Scheel wrote: > - Original Message - > > From: "Fabio Valentini" > > To: "Development discussions related to Fedora" < > devel@lists.fedoraproject.org> > > Sent: Wednesday, July 1, 2020 9:21:31 AM > > Subject: Re: [fedora-java] Re: java stack is dead,

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On Sun, Jun 28, 2020 at 7:54 PM Gerald B. Cox wrote: > And? I don't know about you, when dealing with file systems a chart with OK, > Mostly OK and Unstable doesn't give me the warm and fuzzies. Especially when > OK is defined as: "should be safe to use, no known major defficiencies" . >

Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

- Original Message - > From: "Fabio Valentini" > To: "Development discussions related to Fedora" > > Sent: Wednesday, July 1, 2020 9:21:31 AM > Subject: Re: [fedora-java] Re: java stack is dead, long live the javastack > (was "500 packages FTBFS in rawhide with > java-11-openjdk as

Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

On Wed, Jul 1, 2020 at 9:40 AM Peter Rajnoha wrote: > > On 7/1/20 2:03 PM, Neal Gompa wrote: > > On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha wrote: > >> > >> On 6/30/20 9:35 PM, Igor Raits wrote: > >>> On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote: >

Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

On 7/1/20 2:03 PM, Neal Gompa wrote: > On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha wrote: >> >> On 6/30/20 9:35 PM, Igor Raits wrote: >>> On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/SID >>> == Summary == Introduce Storage

Re: out of Koji disk space

On Wed, 01 Jul 2020 15:14:09 +0200, Stephen John Smoogen wrote: > At the moment we have about 10% of the hardware > we shipped back in operation and there are at least 2 to 3 weeks to > get the rest up. Getting up larger builders is going to have to wait. Sure there is no hurry with larger

Re: List of long term FTBFS packages to be retired in August

Hi Alexandre, Thank you for your offer. I just wonder, are you sponsored into packager group? Vít Dne 29. 06. 20 v 17:57 alexandrebfar...@gmail.com napsal(a): > I'm interested in helping with those NodeJS packages.  > > --  > Alexandre de Farias / etinin > > On Mon, Jun 29, 2020, 12:50 Vít

Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

On 2020-07-01 14:03, Neal Gompa wrote: > On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha wrote: >> >> On 6/30/20 9:35 PM, Igor Raits wrote: >>> On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/SID >>> == Summary == Introduce Storage

Re: The future of legacy BIOS support in Fedora.

W dniu 01.07.2020 o 12:57, Richard W.M. Jones pisze: > If you mean migration of existing guests, then you need to repartition > them and reinstall the bootloader. I doubt anyone has a practical > idea of how to do that either manually or automatically. Add second drive with 32-64MB size. Create

Re: Mass spec change: Replace Python version globs with macros to support 3.10

On Mon, Jun 29, 2020 at 2:50 PM Tomas Hrnciar wrote: > > Hello everyone, > > with the upcoming Python 3.10 update we need to update Python 3 version globs > in Fedora specfiles. The reason is simple, Python version will be one > character longer so the currently omnipresent ?.? glob won't work

Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

On 7/1/20 9:50 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jun 30, 2020 at 03:18:57PM -0400, Ben Cotton wrote: >> == Benefit to Fedora == >> The main benefit is all about centralizing the solution to solve >> issues that storage subsystem maintainers have been hitting with udev, >> that is:

Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov wrote: > > Fabio, does it mean that the Java SIG agrees with progressing with the Change > to Java 11 as a default? Speaking for myself, yes. I can't speak for all other SIG members (we haven't formally voted on this or something like that),

Re: out of Koji disk space

On Wed, 1 Jul 2020 at 08:09, Jan Kratochvil wrote: > > On Wed, 01 Jul 2020 13:43:57 +0200, Stephen John Smoogen wrote: > > In the end we have limited resources and you are running into those > > limits. We can either have fewer builders with more disk space and a > > long queue of builds or we

Re: out of Koji disk space

On Wednesday, July 1, 2020 2:00:09 PM CEST Jan Kratochvil wrote: > On Wed, 01 Jul 2020 13:43:57 +0200, Stephen John Smoogen wrote: > > > In the end we have limited resources and you are running into those > > limits. We can either have fewer builders with more disk space and a > > long queue of

Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

Fabio, does it mean that the Java SIG agrees with progressing with the Change to Java 11 as a default? On Wed, Jul 1, 2020 at 4:02 PM Fabio Valentini wrote: > On Tue, Jun 30, 2020 at 9:52 AM Jiri Vanek wrote: > > > > On 6/29/20 1:59 PM, Aleksandar Kurtakov wrote: > > > > > > > > > On Mon, Jun

[Bug 1852856] New: perl-Template-Toolkit depends on mod_perl, which eventually installs httpd

https://bugzilla.redhat.com/show_bug.cgi?id=1852856 Bug ID: 1852856 Summary: perl-Template-Toolkit depends on mod_perl, which eventually installs httpd Product: Fedora EPEL Version: epel8 OS: Linux

Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

On Tue, Jun 30, 2020 at 9:52 AM Jiri Vanek wrote: > > On 6/29/20 1:59 PM, Aleksandar Kurtakov wrote: > > > > > > On Mon, Jun 29, 2020 at 2:39 PM Jiri Vanek > > wrote: > > > > Current stats from my testing samples: > > 408 failing > > 263 passing > > > > > >

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On Wed, Jul 1, 2020 at 8:55 AM Stephen Gallagher wrote: > > On Tue, Jun 30, 2020 at 9:03 PM Michael Catanzaro > wrote: > > > > > > On Tue, Jun 30, 2020 at 7:16 pm, Stephen John Smoogen > > wrote: > > > The issue isn't that you haven't done your work. It is that it looks > > > like you were set

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On Tue, Jun 30, 2020 at 9:03 PM Michael Catanzaro wrote: > > > On Tue, Jun 30, 2020 at 7:16 pm, Stephen John Smoogen > wrote: > > The issue isn't that you haven't done your work. It is that it looks > > like you were set up to fail. The email from Michael comes across that > > Workstation

[Bug 1852414] perl-Email-MIME-ContentType 1.024.1 appears to break bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1852414 --- Comment #1 from Tom "spot" Callaway --- This is the change that caused the issue: https://github.com/rjbs/Email-MIME-ContentType/commit/ed2a0311dbaa268dc575a0eb55ddaace8038571e Essentially, one of the subtypes is not matching this

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On Wed, 1 Jul 2020 at 07:19, Zbigniew Jędrzejewski-Szmek wrote: > > Yeah. I have no doubt that the decision was made carefully back then. > That said, time has passed, and btrfs has evolved and our use cases > have evolved too, so a fresh look is good. > > We have

Re: out of Koji disk space

On Wed, Jul 01, 2020 at 02:00:09PM +0200, Jan Kratochvil wrote: > On Wed, 01 Jul 2020 13:43:57 +0200, Stephen John Smoogen wrote: > > In the end we have limited resources and you are running into those > > limits. We can either have fewer builders with more disk space and a > > long queue of

Re: The future of legacy BIOS support in Fedora.

Hi, On 6/30/20 8:29 PM, Jóhann B. Guðmundsson wrote: On 30.6.2020 17:49, John M. Harris Jr wrote: On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Tue, Jun 30, 2020 at 6:30 PM Kevin Kofler wrote: > > I strongly believe that this kernel problem can only be solved within the > kernel, by a synchronous (hence race-free) hook on all allocations. > I don't disagree, but if that's not available, this is the best we have. And it's tunable (or

Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

On Wed, Jul 01, 2020 at 08:03:11AM -0400, Neal Gompa wrote: > On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha wrote: > > > > On 6/30/20 9:35 PM, Igor Raits wrote: > > > On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote: > > >> https://fedoraproject.org/wiki/Changes/SID > > > > > >> == Summary == >

Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha wrote: > > On 6/30/20 9:35 PM, Igor Raits wrote: > > On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote: > >> https://fedoraproject.org/wiki/Changes/SID > > > >> == Summary == > >> Introduce Storage Instantiation Daemon (SID) that aims to provide a >

Re: out of Koji disk space

On Wed, 01 Jul 2020 13:43:57 +0200, Stephen John Smoogen wrote: > In the end we have limited resources and you are running into those > limits. We can either have fewer builders with more disk space and a > long queue of builds or we can have more builders with smaller disk > space. Good to know

Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

On 6/30/20 9:35 PM, Igor Raits wrote: > On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/SID > >> == Summary == >> Introduce Storage Instantiation Daemon (SID) that aims to provide a >> central event-driven engine to write modules for identifying

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

Hi, On 01/07/2020 12:09, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote: Hi, On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote: So yes, I think an explicit "let's all

Re: out of Koji disk space

On Wed, 1 Jul 2020 at 02:09, Jan Kratochvil wrote: > > Hi, > > I have tried to enable debuginfo for Chromium but it cannot fit the disk. > During local build it has 160GB (on x86_64) and Koji shows (moreover AFAIK > shared for multiple builders): > >

Re: module 'posix' not found when module load mpi/mpich-x86_64

Lmod needed a little patch to detect Lua 5.4 as a valid version, but it's fixed and rebuilt in rawhide now (Lmod-8.3.17-2.fc33). Thanks, Tom On Tue, Jun 30, 2020 at 6:24 PM Miro Hrončok wrote: > On 30. 06. 20 19:34, Christoph Junghans wrote: > > Adding > > BuildRequires: lua-posix > > doesn't

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On Sat, 2020-06-27 at 18:41 -0600, Chris Murphy wrote: > On Sat, Jun 27, 2020 at 4:30 PM Konstantin Kharlamov > > > Good for you. But you're trying take take decision for all other peoples, so > > you > > need to take into account not everyone has NVMe or SSD. HDDs that many > > people > > are

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Wed, Jul 1, 2020 at 4:55 AM Richard W.M. Jones wrote: > > > I might support this, but Nano is a terrible editor. It has key > bindings that are quite unlike any other program and conflict with > normal bindings that newbies might be used to (eg. ^X is cut, not exit). > > If we're going to

Re: python-sphinx_rtd_theme update: comments requested

On 01. 07. 20 2:07, Miro Hrončok wrote: On 01. 07. 20 0:47, Jerry James wrote: Third, any package that includes documentation generated from this package will need this: Requires:   font(fontawesome) Requires:   font(lato) Requires:   font(robotoslab) Quick idea: Package an RPM

Re: The future of legacy BIOS support in Fedora.

On Wed, Jul 1, 2020 at 11:37 AM Lennart Poettering wrote: [snip] > > My suggestion would be: don't standardize on boot loaders, standardize > on the boot loader spec. And I mean, the real boot loader spec, i.e Agreed. In part that's already the case for Fedora, since now besides GRUB the zipl

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote: > Hi, > > On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote: > >On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote: > >>So yes, I think an explicit "let's all test btrfs (as anaconda > >>configures it) before we

Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

On 01/07/2020 11:53, Richard W.M. Jones wrote: On Tue, Jun 30, 2020 at 10:30:21AM -0400, Owen Taylor wrote: So, this was discussed quite a bit in https://pagure.io/fedora-workstation/issue/71 and the conclusion that the Workstatopn Working Group came to 3 months ago was that we didn't want to

Re: The future of legacy BIOS support in Fedora.

On Tue, Jun 30, 2020 at 03:27:45PM +0100, Daniel P. Berrangé wrote: > On Tue, Jun 30, 2020 at 04:00:00PM +0200, Florian Weimer wrote: > > * Jóhann B. Guðmundsson: > > > > > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > > > changes it beg the question if now would not be the

Re: The future of legacy BIOS support in Fedora.

On Tue, Jun 30, 2020 at 04:25:58PM +0200, Marcin Juszkiewicz wrote: > W dniu 30.06.2020 o 16:20, Tom Hughes via devel pisze: > > On 30/06/2020 15:00, Florian Weimer wrote: > >> * Jóhann B. Guðmundsson: > >> > >>> Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > >>> changes it

Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

On Tue, Jun 30, 2020 at 10:30:21AM -0400, Owen Taylor wrote: > So, this was discussed quite a bit in > https://pagure.io/fedora-workstation/issue/71 and the conclusion that > the Workstatopn Working Group came to 3 months ago was that we didn't > want to do this. We basically understood that main

Re: The future of legacy BIOS support in Fedora.

On 1.7.2020 09:36, Lennart Poettering wrote: On Di, 30.06.20 19:15, Gerd Hoffmann (kra...@redhat.com) wrote: Hi, So I can't say I'm thrilled about a future that depends on EFI for virt, but I'm resigned to the fact this is the direction the world is taking. So we're not likely to have any

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Wed, 1 Jul 2020, Richard W.M. Jones wrote: It has key bindings that are quite unlike any other program Well, any other program that a newcomer is nowadays reasonably likely to be familiar with. The keybindings are from the Pico text editor, and the Pine and Alpine email clients. --

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

Hi, On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote: So yes, I think an explicit "let's all test btrfs (as anaconda configures it) before we make it default" period is warranted. Perhaps one can argue that Fedora has

Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

On Tuesday, 30 June 2020 at 21:19, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping > > == Summary == > > redhat-rpm-config will be updated so users of the auto framework get > automated release and changelog bumping. > > == Owner == > > *

Re: The future of legacy BIOS support in Fedora.

On Wed, Jul 01, 2020 at 12:01:08PM +0200, Vitaly Zaitsev via devel wrote: > On 01.07.2020 11:28, Alexey A. wrote: > > Stop using the L-word, please: BIOS is not "legacy", it's just > > alternative way (one of many). > > Using BIOS boot on UEFI-compatible systems is a legacy, because it works >

[EPEL-devel] Re: Questions about installing epel-release

Hi, On Tuesday, 30 June 2020 at 04:17, Wei, Catherine wrote: [...] > * Results of rpm -V epel-release and rpm -qi epel-release > [root@katt-shanghai katt-server-install]# rpm -V epel-release > [root@katt-shanghai katt-server-install]# rpm -qi epel-release > Name: epel-release >

Re: The future of legacy BIOS support in Fedora.

On 01.07.2020 11:28, Alexey A. wrote: > Stop using the L-word, please: BIOS is not "legacy", it's just > alternative way (one of many). Using BIOS boot on UEFI-compatible systems is a legacy, because it works under the CSM compatibly layer. More information about CSM you can find here:

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On 01/07/20 09:54 +0100, Richard W.M. Jones wrote: I might support this, but Nano is a terrible editor. It has key bindings that are quite unlike any other program and conflict with normal bindings that newbies might be used to (eg. ^X is cut, not exit). If we're going to newbies how about a

Re: The future of legacy BIOS support in Fedora.

On Di, 30.06.20 19:15, Gerd Hoffmann (kra...@redhat.com) wrote: > Hi, > > > > So I can't say I'm thrilled about a future that depends on EFI for > > > virt, but I'm resigned to the fact this is the direction the world > > > is taking. So we're not likely to have any choice and will have to > >

Re: The future of legacy BIOS support in Fedora.

>legacy BIOS Stop using the L-word, please: BIOS is not "legacy", it's just alternative way (one of many). All my laptops use BIOS, by the way. ср, 1 июл. 2020 г. в 18:26, Leigh Scott : > Has UEFI support improved in the last 2 - 3 years? > My last experience with it was so poor on a multi-boot

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Wednesday, July 1, 2020 10:54:46 AM CEST Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jul 01, 2020 at 09:44:12AM +0200, Kamil Dudka wrote: > > > On Tuesday, June 30, 2020 9:16:40 PM CEST Robert-André Mauchin wrote: > > > > > May I suggest another option? > > > I provide a package for Micro,

Re: The future of legacy BIOS support in Fedora.

Has UEFI support improved in the last 2 - 3 years? My last experience with it was so poor on a multi-boot system I switched to legacy and haven't bothered trying it since. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an

Re: IBus 1.5.23 - Fedora 33 System-Wide Change proposal

On 2020/07/01 4:47, Igor Raits-san wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 15:20 -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/IBus_1.5.23 == Summary == IBus 1.5.23 will replace the allowlist of XKB engines with the blocklist of XKB ones.

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

While this isn't a problem for Fedora per se, it's worth noting. OpenSUSE uses btrfs by default and as a result we're unable to open SUSE guest images from distros that don't include btrfs in the kernel (ie. RHEL, and maybe CentOS unless you use an alternate kernel). So that would apply to

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

I might support this, but Nano is a terrible editor. It has key bindings that are quite unlike any other program and conflict with normal bindings that newbies might be used to (eg. ^X is cut, not exit). If we're going to newbies how about a more MS-DOS-ish experience, eg:

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Wed, Jul 01, 2020 at 09:44:12AM +0200, Kamil Dudka wrote: > On Tuesday, June 30, 2020 9:16:40 PM CEST Robert-André Mauchin wrote: > > May I suggest another option? > > I provide a package for Micro, an editor written in Go with a discoverable > > interface. https://micro-editor.github.io/ > >

Re: [EPEL] rpmconf question for EPEL7 on Amazon Linux 2

On Tue, Jun 30, 2020 at 2:18 PM Christopher wrote: > > Hi, > > I know Fedora doesn't directly support Amazon Linux, but I was > wondering if the package maintainer for rpmconf on EPEL was aware that > the latest version doesn't work on Amazon Linux 2, which recently > updated to python-3.7,

Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal

Dne 01. 07. 20 v 10:29 Zbigniew Jędrzejewski-Szmek napsal(a): On Tue, Jun 30, 2020 at 11:04:26AM +0200, Zdenek Kabelac wrote: Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a): On 29.06.2020 22:04, Ben Cotton wrote: Fedora only support these RAID sets when they are already configured

Re: Please BuildRequire python3-setuptools explicitly

On Tue, Jun 23, 2020 at 06:28:00PM -, Miro Hrončok wrote: > > On Tue, Jun 23, 2020 at 06:26:23PM +0200, Tomas Hrnciar wrote: > > > > This package depends on python3-devel. However the last build.log: > > > > > > https://kojipkgs.fedoraproject.org//packages/qemu/5.0.0/2.fc33/data/logs/...

Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

On Tue, 2020-06-30 at 17:48 +0200, Vitaly Zaitsev via devel wrote: > On 30.06.2020 15:25, Ben Cotton wrote: > > Better thermal management and peak performance on Intel CPUs by > > including thermald in the default install. > > Good, but thermald is absolutely useless without configs. Configs can

Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal

On Tue, Jun 30, 2020 at 11:04:26AM +0200, Zdenek Kabelac wrote: > Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a): > >On 29.06.2020 22:04, Ben Cotton wrote: > >>Fedora only support these RAID sets when they are already configured in > >>the BIOS at installation time. So we can solve the

Re: The future of legacy BIOS support in Fedora.

Yes...Dropping support for BIOS will enable us to switch to systemd-boot, which is the benefit. But just out of curiosity, what is the benefit of switching from GRUB to systemd-boot. Dropping support for 32-bit x86 surely can make maintainers be free from one old platform (and less package to

Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

On Tue, Jun 30, 2020 at 03:18:57PM -0400, Ben Cotton wrote: > == Benefit to Fedora == > The main benefit is all about centralizing the solution to solve > issues that storage subsystem maintainers have been hitting with udev, > that is: > > * providing a central infrastructure for storage event

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Tuesday, June 30, 2020 9:16:40 PM CEST Robert-André Mauchin wrote: > May I suggest another option? > I provide a package for Micro, an editor written in Go with a discoverable > interface. https://micro-editor.github.io/ > > It is compiled as a static binary of 4.6 MB with no dependency. How

Re: The future of legacy BIOS support in Fedora.

On Tuesday, June 30, 2020 2:55:42 PM MST Jóhann B. Guðmundsson wrote: > On 30.6.2020 21:14, nick...@gmail.com wrote: > > > On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote: > > > >> > >> > >> Grub discourages users who have tried sd-boot from coming/returning > >> to > >> Fedora

<    1   2   3   >