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

On Fri, Jun 26, 2020 at 10:03:12AM -0700, Adam Williamson wrote: > On Fri, 2020-06-26 at 12:58 -0400, Neil Horman wrote: > > > From this thread you can find at least two people (me and Ben > > > Rosser) > > > who definitely didn't keep using vi (my very next questions were > > > "what's an easier e

Re: fedora-minimal container and registry negative feedback

On Mon, 29 Jun 2020 at 16:55, Dridi Boukelmoune wrote: > > The blank pages are flatpaks. We are using the same registry for > containers and flatpaks and the upstream project[0] used for registry.fp.o > does not support flatpaks so the page is just blank. > > That can't be right, fedora-minimal i

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 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 > > > Are these numbers reversed ^^^ ? Looking at > https://copr.fedorainfraclo

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

On Fri, 26 Jun 2020 at 19:06, Neil Horman wrote: > > Right, and I acutally think thats great. You had a problem, you asked the > questions you needed answers to, and solved your problem. I personally think > the process of identifying whats bothering you, figuring out a solution (by > asking que

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

On Tuesday, 30 June 2020 00.56.23 WEST Alexander Ploumistos wrote: > I just tested it on F32 Workstation and for me it does. Have you > cleaned dnf's databases by any chance? I think either that or having > the packages as dependencies of something that was installed by the > user would prevent the

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

On Tuesday, 30 June 2020 00.56.23 WEST Alexander Ploumistos wrote: > I just tested it on F32 Workstation and for me it does. Have you > cleaned dnf's databases by any chance? I think either that or having > the packages as dependencies of something that was installed by the > user would prevent the

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

Hi, On 6/30/20 12:59 AM, Michael Catanzaro wrote: On Mon, Jun 29, 2020 at 3:37 pm, Samuel Sieb wrote: But that should be running concurrently.  Does the plot show anything important waiting for it?  Your desktop should be able to load before that service is finished starting. Well notably: p

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

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 problem of > dmraid.service still depending on the obsolete udev-settle service by > making dmraid.service disable itself if no suppo

Re: Lua 5.4.0

On 30. 06. 20 6:40, Tom Callaway wrote: Okay. I duct taped lua-posix into a "working" state. Also did builds for lua-argparse, lua-expat, lua-lpeg, and rpm (so that the macros say "5.4"). Any and all help is appreciated. Rebuilding what I can. So far: lua-cyrussasl luadoc lua-filesystem lua-

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

On Mon, Jun 29, 2020 at 05:52:07PM +0200, Till Maas wrote: > On Mon, Jun 29, 2020 at 08:16:29AM -0400, Gerald Henriksen wrote: > > > While it may be worth vim making themselves better, it really doesn't > > change the argument. > > > > Even a friendlier vim is still going to be far to strange and

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

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 problem of dmraid.service still depending on the obsolete udev-settle servi

Re: Remove device-mapper-multipath from the Fedora workstation livecd - Fedora 33 System-Wide Change proposal

Hi John, On 6/30/20 12:58 AM, John M. Harris Jr wrote: On Monday, June 29, 2020 1:04:48 PM MST Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkst ationLiveCD == Summary == The Fedora workstation livecd is the default Fedora variant getfedora.org advi

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 10:30 AM José Abílio Matos wrote: > > IIRC this is probably related with the dependencies of anaconda: Is there an easy suggestion we can make to our users other than play with "rpm -e" or nuking dnf's database? There's a bunch of threads over at askfedora where people are

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

On Mo, 29.06.20 16:04, Ben Cotton (bcot...@redhat.com) wrote: > https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun > > == Summary == > The Fedora workstation livecd is the default Fedora variant getfedora.org > advices people to download. > As such most Fedora workstation installs will

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

On 30.06.2020 11:04, Zdenek Kabelac wrote: > If the user does not need lvm2, then the package  should not be installed/ > However when lvm2 is installed - lvm2 monitoring service is supposed to > be there and enabled - it should not impact load time all that much... I use classic partitions, but l

Re: fedora-minimal container and registry negative feedback

> The tag page for fedora-minimal seems to be working > https://registry.fedoraproject.org/repo/fedora-minimal/tags/. Do you have a > link of the page that is blank ? That's the very link from which I get a blank page, and Firefox reports an empty resource (^U to view source). The developer con

Re: Remove device-mapper-multipath from the Fedora workstation livecd - Fedora 33 System-Wide Change proposal

On 30 June 2020 11:10:03 CEST, Hans de Goede wrote: >With livecd installs the livecd rootfs simply gets rsync-ed over, so >anything which is in the livecd will also end up on the real system. > >There is a post-install configuration phase, so I guess we could >disable things which are only brou

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 11:04 +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 > > >

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

Hi, On 27/06/2020 11:00, Florian Weimer wrote: * Josef Bacik: As for your ENOSPC issue, I've made improvements on that area. I see this in production as well, I have monitoring in place to deal with the machine before it gets to this point. That being said if you run the box out of metadata

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

On Mon, Jun 29, 2020 at 2:39 PM Jiri Vanek wrote: > Current stats from my testing samples: > 408 failing > 263 passing > > That is huge improvement. Thank you all. > I'm now running last rebuild n copr, and in week or two an mass rebuild > will be taken in koji. > > There was an discussion what t

undefined reference to `_gst_debug_min'

Hi, when compiling a new version of shutcut, I get the following error message on rawhide [1]: /usr/bin/ld: /usr/lib64/libQt5WebKit.so: undefined reference to `_gst_debug_min' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:782: shotcut] Error 1 make[1]: Leaving directory '/bui

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

On 30.06.2020 11:23, Igor Raits wrote: > Sadly you can't have lvm2 not installed: Yes, but it can be disabled. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email t

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

Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sadly you can't have lvm2 not installed: Yes, but it can be disabled. Of course, you can disable this yourself if you are skilled admin and you do not need it or use it (you can mask it which

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

Hi, On 29/06/2020 23:57, Markus Larsson wrote: On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote: On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote: Why not Stratis? Stratis cannot be used to build the root filesystem. (It's been answered elsewhere in the thread.) Are we sure? https://g

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

On 30.06.2020 11:42, Zdenek Kabelac wrote: > Default for unskilled users who may use lvm2  - should remain enabled. If LVM was not used during installation => Anakonda can automatically disable it. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___

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

* Steven Whitehouse: > On 27/06/2020 11:00, Florian Weimer wrote: >> * Josef Bacik: >> >>> As for your ENOSPC issue, I've made improvements on that area. I >>> see this in production as well, I have monitoring in place to deal >>> with the machine before it gets to this point. That being said if

Re: undefined reference to `_gst_debug_min'

You don't have to solve it! The issue is qt5-qtwebkit needs rebuilding against new gsteamer1-1.17.1 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https:

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

Dne 30. 06. 20 v 11:53 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:42, Zdenek Kabelac wrote: Default for unskilled users who may use lvm2  - should remain enabled. If LVM was not used during installation => Anakonda can automatically disable it. Hmm - I don't think this is a good p

Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)

Hi, On 6/30/20 11:42 AM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sadly you can't have lvm2 not installed: Yes, but it can be disabled. Of course, you can disable this yourself if you are skilled admin and you

Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)

Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a): Hi, On 6/30/20 11:42 AM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sadly you can't have lvm2 not installed: Yes, but it can be disabled. Of course, you can disab

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

On 30.06.2020 12:16, Zdenek Kabelac wrote: > The right plan is to fix all packaged dependencies and allow > installation of packages without lvm2. +1. This will be the best solution, I think. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ d

Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)

Hi, On 6/30/20 12:27 PM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a): Hi, On 6/30/20 11:42 AM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sadly you can't have lvm2 not installed: Yes, but

Re: Package Review SELinux help

On Monday, 29 June 2020 20:55:45 CEST Daniel Walsh wrote: > On 6/26/20 14:39, Robert-André Mauchin wrote: > > > Hello, > > > > > > > > > > I know next to nothing about SELinux so I'd like some help about the > > Bitcoin Package Review by negativo17: > > > > > > > > https://bugzilla.redhat.com/show

Schedule for Wednesday's FESCo Meeting (2020-07-01)

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-07-01 14:00 UTC' Links to all issues to

Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)

Dne 30. 06. 20 v 12:43 Hans de Goede napsal(a): Hi, On 6/30/20 12:27 PM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a): Hi, On 6/30/20 11:42 AM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sa

Re: undefined reference to `_gst_debug_min'

ah ok, i will wait for a new qt5-qtwebkit version. Thanks Martin ___ 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/proj

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

Le lundi 29 juin 2020 à 10:26 -0600, Chris Murphy a écrit : > > Come on. It's cleanly unmounted and doesn't mount? > > I guess you missed the other emails about dm-log-writes and xfstests, > but they directly relate here. Josef relayed that all of his deep > dives into Btrfs failures since the dm

Re: undefined reference to `_gst_debug_min'

> ah ok, i will wait for a new qt5-qtwebkit version. > Thanks > Martin It looks like they addressed with this build https://koji.fedoraproject.org/koji/buildinfo?buildID=1526223 * Mon Jun 22 2020 Wim Taymans - 1.17.1-2 - Enable debug again I tagged gstreamer1-1.17.1-1.fc33 into overrides for r

Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)

Hi, On 6/30/20 1:27 PM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 12:43 Hans de Goede napsal(a): Hi, On 6/30/20 12:27 PM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a): Hi, On 6/30/20 11:42 AM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal

Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)

Dne 30. 06. 20 v 14:08 Hans de Goede napsal(a): Hi, On 6/30/20 1:27 PM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 12:43 Hans de Goede napsal(a): Hi, On 6/30/20 12:27 PM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a): Hi, On 6/30/20 11:42 AM, Zdenek Kabelac wrote: Dne 3

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

On Tue, Jun 30, 2020 at 7:45 AM Nicolas Mailhot via devel wrote: > > Le lundi 29 juin 2020 à 10:26 -0600, Chris Murphy a écrit : > > > > Come on. It's cleanly unmounted and doesn't mount? > > > > I guess you missed the other emails about dm-log-writes and xfstests, > > but they directly relate her

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

On Tue, Jun 30, 2020 at 5:42 AM Steven Whitehouse wrote: > > Hi, > > On 29/06/2020 23:57, Markus Larsson wrote: > > On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote: > >> On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote: > >>> Why not Stratis? > >> Stratis cannot be used to build the root f

Make the unversioned %{__python} macro error by default - Fedora 33 Self-Contained Change proposal

https://fedoraproject.org/wiki/Changes/PythonMacroError == Summary == The %{__python} RPM macro (currently defined to /usr/bin/python for backwards compatibility reasons) will be defined to raise an error when used. Any derived macros (%{python}, %{python_version}, %{python_sitleib} etc.) will pro

OpenLDAP without Non-threaded Libraries - Fedora 33 System-Wide Change proposal

https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries == Summary == OpenLDAP will not ship non-threaded version of libldap. Instead, symlinks will be provided for runtime libraries to keep working, and all software built with libldap will be effectively built with libldap_r.

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

https://fedoraproject.org/wiki/Changes/ThermalManagementWS == Summary == Better thermal management and peak performance on Intel CPUs by including thermald in the default install. == Owner == * Name: [[User:benzea| Benjamin Berg]] * Email: bb...@redhat.com * Name: [[User:ckellner| Christian J. K

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

https://fedoraproject.org/wiki/Changes/KDEEarlyOOM == Summary == As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install earlyoom package, and enable it by default. If both RAM and swap go below 10% free, earlyoom issues SIGTERM to the process with the largest oom_score. If both RAM a

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

On Tue, Jun 30, 2020 at 9:26 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/KDEEarlyOOM > > == Summary == > As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install earlyoom > package, and enable it by default. If both RAM and swap go below 10% free, > earlyoom issue

The future of legacy BIOS support in Fedora.

Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been available on any common intel based x86 platform since atleast 2005. Now

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

On Tue, Jun 30, 2020 at 9:32 AM Neal Gompa wrote: > > * Has anyone reached out to the other spins to see if they'd like to > include it? I think it actually makes sense to do it for all Fedora > desktops. I reached out to the other KDE-based deliverables. If other spins owners want to sign on, I'

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 09:25 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/ThermalManagementWS > > == Summary == > Better thermal management and peak performance on Intel CPUs by > including > thermald in the default install. I h

Re: drop bfq scheduler, instead use mq-deadline across the board

On Tue, Jun 30, 2020 at 4:44 am, Tom Seewald wrote: In case you find it useful, Paolo has posted his own results from testing IO schedulers on Linux [1][2] as well as the scripts he used to generate the load [3]. I don't claim that these results have been independently verified or that they ar

Re: The future of legacy BIOS support in Fedora.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 13:34 +, 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 stop supporting > booting in legacy bios mode and move

Re: The future of legacy BIOS support in Fedora.

* 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 time to stop > supporting booting in legacy bios mode and move to uefi only supported > boot which has been available on any common intel based x86 platf

Re: Lua 5.4.0

On 30. 06. 20 11:02, Miro Hrončok wrote: On 30. 06. 20 6:40, Tom Callaway wrote: Okay. I duct taped lua-posix into a "working" state. Also did builds for lua-argparse, lua-expat, lua-lpeg, and rpm (so that the macros say "5.4"). Any and all help is appreciated. Rebuilding what I can. So far:

Re: User experience issue on btrfs

On 6/29/20 2:26 AM, John M. Harris Jr wrote: On Sunday, June 28, 2020 5:37:08 PM MST Chris Adams wrote: Once upon a time, John M. Harris Jr said: XFS proved to be troublesome, and still is up to the latest of RHEL7. It's not uncommon to have to run xfs_repair on smaller XFS partitions, espec

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

Hi, On 30/06/2020 13:58, Neal Gompa wrote: On Tue, Jun 30, 2020 at 5:42 AM Steven Whitehouse wrote: Hi, On 29/06/2020 23:57, Markus Larsson wrote: On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote: On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote: Why not Stratis? Stratis cannot be

Re: Lua 5.4.0

On 2020-06-29 21:30, Tom Callaway wrote: I just built lua 5.4.0 in Rawhide. As with previous major updates of lua, the package also includes a copy of the lua 5.3 libraries so that rawhide does not just become broken reps. If you depend on lua, please rebuild your packages in rawhide and let me

Re: The future of legacy BIOS support in Fedora.

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 beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been availab

Re: The future of legacy BIOS support in Fedora.

On 30/06/2020 14:56, Igor Raits wrote: I think there are many people still install OS in the legacy mode, but I don't really have numbers. One thing we should definitely do if we deprecate legacy BIOS is to properly warn users that still use this configuration, develop tooling for them if possib

Re: The future of legacy BIOS support in Fedora.

W dniu 30.06.2020 o 15:34, Jóhann B. Guðmundsson pisze: > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > changes it beg the question if now would not be the time to stop > supporting booting in legacy bios mode and move to uefi only > supported boot which has been available on a

Re: The future of legacy BIOS support in Fedora.

On Tue, Jun 30, 2020 at 4:01 PM 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 time to stop > > supporting booting in legacy bios mode and move to uefi only supported >

Re: Lua 5.4.0

On 30. 06. 20 16:06, Miro Hrončok wrote: One thing that I found surprising is that all of the packages have a in-spec-hardcoded Lua version macro that needs to be updated during the rebuild. Would you accept a PR for lua that adds lua-rpm-macros subpackage with %{lua_version} (now defined as 5

Re: The future of legacy BIOS support in Fedora.

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 beg the question if now would not be the time to stop >>> supporting booting in le

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

On Fri, Jun 26, 2020 at 11:00 AM Matthew Miller wrote: > > > > https://fedoraproject.org/wiki/Changes/BtrfsByDefault > > Wow! Is it 2010 already? Time flies! :) > > In seriousness: thanks for all of the effort put into this change proposal, > and the impressive list of change owners. I'm following

Re: The future of legacy BIOS support in Fedora.

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 time to stop > > supporting booting in legacy bios mode and move to uefi only sup

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

> Another way to consider this would be that we can stop arguing against these > changes, let the GNOME folks run the ship aground, and hope that the user > backlash will act as a wakeup call when it comes to these changes. I agree > that btrfs is far too unstable to be made a default, and I als

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

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 way of using thermald was to use the proprietary dptfxtract tool to ex

Re: The future of legacy BIOS support in Fedora.

W dniu 30.06.2020 o 16:27, Daniel P. Berrangé pisze: > KVM virt on aarch64 and x86 can support EFI via AVMF / OVMF firmware > built from the edk2 project from a technical POV. > > The first challenge will be that many mgmt tools still default to > using legacy BIOS when deploying guest OS. We've

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

Hi, On 29/06/2020 19:54, Igor Raits wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-29 at 12:26 -0400, Matthew Miller wrote: On Sun, Jun 28, 2020 at 09:59:52AM -0700, John M. Harris Jr wrote: We cannot include ZFS in Fedora for legal reasons. Additionally, ZFS is not re

Re: The future of legacy BIOS support in Fedora.

On Tue, Jun 30, 2020 at 04:32:44PM +0200, Marcin Juszkiewicz wrote: > W dniu 30.06.2020 o 16:27, Daniel P. Berrangé pisze: > > > KVM virt on aarch64 and x86 can support EFI via AVMF / OVMF firmware > > built from the edk2 project from a technical POV. > > > > The first challenge will be that many

Re: Lua 5.4.0

On 30. 06. 20 16:06, Miro Hrončok wrote: The current status is: $ comm -23 <(repoquery --refresh --repo=koji --whatrequires 'lua(abi) = 5.3' --source | pkgname | sort) <(repoquery --repo=koji --whatrequires 'lua(abi) = 5.4' --source | pkgname | sort) librs232 https://bugzilla.redhat.com/sh

Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

On Tue, Jun 30, 2020 at 08:43:34AM +0200, Markus Larsson wrote: > I have been using fedora since FC1 and there has been a few shifts. The > latest shift seems to be a strong desire to be just another Ubuntu. That's > fine, nothing wrong with that... Do we need more Ubuntus though? I don't know wha

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 beg

Re: The future of legacy BIOS support in Fedora.

On 30/06/2020 15:25, 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 beg the question if now would not be the time to

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

On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher wrote: For the record, as this directly affects the Workstation deliverable, I will be voting -1 until and unless the Workstation WG votes in favor. Yes, it's a large set of Change owners, but since only two of them are Workstation WG members,

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 13:56, Igor Raits wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 13:34 +, 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 stop supporting booti

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 14:18, Tom Hughes via devel wrote: On 30/06/2020 14:56, Igor Raits wrote: I think there are many people still install OS in the legacy mode, but I don't really have numbers. One thing we should definitely do if we deprecate legacy BIOS is to properly warn users that still use this

Re: The future of legacy BIOS support in Fedora.

On Tue, Jun 30, 2020 at 04:23:59PM +0200, Felipe Borges wrote: > On Tue, Jun 30, 2020 at 4:01 PM 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 time to stop >

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

On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro wrote: > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > wrote: > > For the record, as this directly affects the Workstation deliverable, > > I will be voting -1 until and unless the Workstation WG votes in > > favor. > > > > Yes, it's a lar

Re: The future of legacy BIOS support in Fedora.

On 6/30/20 8:07 AM, Jóhann B. Guðmundsson wrote: >>> I think there are many people still install OS in the legacy mode, but >>> I don't really have numbers. I've just started working with Fedora 32 ~ a week ago. Looking at it as a migration option, for imo a lot of _good_ reasons, from current d

Re: drop bfq scheduler, instead use mq-deadline across the board

On Mon, Jun 29, 2020 15:01:24 -0600, Chris Murphy wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1851783 > > The main argument is that for typical and varied workloads in Fedora, > mostly on consumer hardware, we should use mq-deadline scheduler > rather than either none or bfq. > > It may

Re: The future of legacy BIOS support in Fedora.

On Tue, 2020-06-30 at 13:34 +, 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 stop supporting > booting in legacy bios mode and move to uefi only supported boot > which > has been

Re: The future of legacy BIOS support in Fedora.

On Tue, 2020-06-30 at 16:23 +0200, Marcin Juszkiewicz wrote: > W dniu 30.06.2020 o 15:34, Jóhann B. Guðmundsson pisze: > > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > > changes it beg the question if now would not be the time to stop > > supporting booting in legacy bios mode

Re: The future of legacy BIOS support in Fedora.

On 6/30/20 8:24 AM, nick...@gmail.com wrote: > I've never tried UEFI in a VM, and I have no idea how stable it is. IME, works well in a variety of hypervisors; atm, my 'exploration' of Fedora32 is running solely in VirtualBox VMs ... booted UEFI. That said, their a lots of providers that have th

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

On Tue, Jun 30, 2020 at 10:00 AM Michael Catanzaro wrote: > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > wrote: > > For the record, as this directly affects the Workstation deliverable, > > I will be voting -1 until and unless the Workstation WG votes in > > favor. > > > > Yes, it's a

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

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 be extracted from DPTF ACPI tables only with *proprietary* dptfextract utility

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 14:27, 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 time to stop supporting booting in legacy b

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

On Tue, Jun 30, 2020 at 11:49 AM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> 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

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

All, As a long time user of Fedora I have run into nearly all the same issues as mentioned below by Antti. btrfs is not ready to be default: https://news.ycombinator.com/item?id=14907771 On Sun, Jun 28, 2020 at 5:21 AM Antti wrote: > Hello, > > I'm in total opposition to this proposal as a lon

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

On 30.06.2020 17:57, Jared Dominguez wrote: > Something that needs to be cleared up here: thermald has existed for the > better part of a decade and long before dptfxtract existed. Thermald will not work without config being installed. You can remove all configs from /etc/thermald and try to star

Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

On 30 June 2020 16:52:52 CEST, Matthew Miller wrote: >On Tue, Jun 30, 2020 at 08:43:34AM +0200, Markus Larsson wrote: >> I have been using fedora since FC1 and there has been a few shifts. The >> latest shift seems to be a strong desire to be just another Ubuntu. That's >> fine, nothing wrong wi

PSA: Sphinx 3 in rawhide

Hello, we have just updated Sphinx (python-sphinx, python3-sphinx) to 3.1.1 in rawhide. Packages that fail to build documentation with it have already been informed weeks ago via Bugzilla. https://bugzilla.redhat.com/showdependencytree.cgi?id=SPHINX3&hide_resolved=1 CPython documentation cann

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

On Tue, Jun 30, 2020 at 11:22 AM Stephen John Smoogen wrote: > > The problem is that the request as discussed reads as "FESCo says use > it for workstation" vs "FESCo has no problem with Workstation saying > they want btrfs" or "FESCo says use btrfs as default". Yes it says > "desktop variants" bu

Re: The future of legacy BIOS support in Fedora.

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 > > work to mitigate any downsides it brings. > > Right. > > Preferably the i

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

On Tue, Jun 30, 2020 at 12:10 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 30.06.2020 17:57, Jared Dominguez wrote: > > Something that needs to be cleared up here: thermald has existed for the > > better part of a decade and long before dptfxtract existed. > > Thermald

Re: drop bfq scheduler, instead use mq-deadline across the board

On Tue, Jun 30, 2020 at 04:25:23PM +0100, Ankur Sinha wrote: > On Mon, Jun 29, 2020 15:01:24 -0600, Chris Murphy wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1851783 > > > > The main argument is that for typical and varied workloads in Fedora, > > mostly on consumer hardware, we should u

Re: The future of legacy BIOS support in Fedora.

W dniu 30.06.2020 o 17:25, Adam Williamson pisze: > On Tue, 2020-06-30 at 16:23 +0200, Marcin Juszkiewicz wrote: >> W dniu 30.06.2020 o 15:34, Jóhann B. Guðmundsson pisze: >>> Given Hans proposal [1] introduced systemd/grub2/Gnome upstream >>> changes it beg the question if now would not be the tim

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

Hi, when building some of my mpi packages, I got the following error message: + module load mpi/mpich-x86_64 ++ /usr/share/lmod/lmod/libexec/lmod sh load mpi/mpich-x86_64 /usr/bin/lua: /usr/share/lmod/lmod/libexec/lmod:61: module 'posix' not found: no field package.preload['posix'] no file '/usr/s

Re: The future of legacy BIOS support in Fedora.

Igor Raits writes: > On Tue, 2020-06-30 at 13:34 +, 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 stop >> supporting booting in legacy bios mode and move to uefi only >> supporte

Re: The future of legacy BIOS support in Fedora.

On Tue, 2020-06-30 at 19:15 +0200, Gerd Hoffmann 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 > > > work to

  1   2   >