Re: The future of legacy BIOS support in Fedora.
On Wednesday, July 1, 2020 7:30:37 AM MST Lennart Poettering wrote: > 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 have been pretty OK > with supporting it upstream and downstream. At least upstream I am not > aware of any big issues left open. > > Note that sd-boot is a lot simpler than grub, i.e. it doesn't contain > Turing complete programming languages, module loaders, file system > drivers, storage stacks and such. There's simply not that much to > maintain! > > > > Also note that this entails a lot more work then just maintaining > > sd-boot, > > anaconda will need to be adjusted, kernel-install scripts will need to > > be adjusted, etc. > > > kernel-install itself is actually maintained in the same repo as > sd-boot: systemd upstream. They are developed along the same lines > already. > > > > Also I wonder, if you are not proposing to completely drop grub2 on > > x86_64 what does offering sd-boot in addition to grub2 actually > > offer as advantages? > > > Primarily simplicity, and that it implements the boot loader spec > correctly. > > it automatically discovers windows and Macos installations at each > boot, without any userspace involvement. You can talk to it very > nicely, i.e. implement trivially "boot-into-windows" buttons and such > in GNOME and so on. It makes things very robust, since you don't need > a script that generates a script that generates a script (yeah, that's > how grub is hooked up). it just works on its own. You drop in boot > menu items, and that's it. You don't need to regenerate stuff, and you > never have to run an interpretor for a turing complete language. > > By using sd-boot, you can do stuff like "systemctl reboot > --boot-loader-entry=windows", you can do "systemctl reboot > --boot-loader-menu=0", you can do "systemctl kexec" and it boots the > right thing, and so on. > > It also implements boot time assessement that is simple and just works > (i.e. automatic revert to previous boot menu choice when the one > selected doesn't work). > > Oh, and it as support for seeding the Linux random seed pre-boot > already, in a safe and simple fashion. > > Moreover, it communicates which ESP is used to the host OS, so that > the host can automatically discover what other partitions to mount. > > And the list goes on and on and on. > > All these features are very simple individually, but put together they > are just a much nicer and expose a much more integrated behaviour > than Grub ever did. > > > > sd-boot is simpler and a bit tighter integrated with systemd, which would > > mean it is less work to maintain if we use it instead of grub, but if we > > use it next to grub then all those advantages fall away. IOW if we use > > it next to grub then all I see is a whole lot of extra work, with very > > little gain. > > > Well, you appear to believe in the race to the bottom, i.e. that the > lowest common denominator should be where the future is. I am pretty > sure it's the wrong approach: pick the simple contender that can do > all the nice things, and has the nice integration, and use it as a > blueprint for the other archs where Grub is still needed, and make > them catch up. > > I mean, I understand you are interested in exotic platforms that lack > modern things like UEFI, but it kinda sucks to hold the boot loader > hostage due to that, and just stick to the terrible ways of yesteryear > because of it. > > > > AFAIK this (lot of extra work, very little gain) is exactly why we have > > been sticking with grub2 so far. We need to maintain it anyway, at which > > point we want to use it in as much cases as possible so that we can have > > unified code and documentation for dealing with the bootloader. > > > I don't see "very little gain". I see a lot of gain, and all while > things become simpler. Much simpler. > > Lennart > > -- > Lennart Poettering, Berlin Lennart, We don't need more systemd-bloat just to boot our systems. However your bootloader works, it doesn't really matter if it's not up to snuff with GRUB2. When it supports LUKS, LVM, LUKS+LVM, a recovery console and several filesystems, then it'll be more of a viable option, and I still wouldn't recommend having yet another systemd component as a core part of our systems. At what point is systemd large enough that you'll stop adding more cruft? -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
Le mercredi 01 juillet 2020 à 23:48 +0200, Dan Čermák a écrit : > Hi Nicolas, Hi Dan > This is a system-wide change because all packages build with > > redhat-rpm-config, but it only concerns packages that opted to use > > this part of redhat-rpm-config (auto framework). > > > > The change will make those packages auto-bump and auto-changelog at > > the rpm level, in an infrastructure-independent way. > > Please forgive the silly questions (it's getting late here…), but how > does this look in practice? There are no silly questions, do ask if you have more. > How do I let rpm generate the changelog automatically? This feature is not changelog generation, just changelog bumping on build events. You still need some other method to put non-build events in the changelog. The detached changelog is just one more file in SRPM sources, which is modified by rpmbuild at `%build` time with other files rpmbuild modifies. The tricky part is to modify the source file as a source file so rpmbuild adds the result to the produced SRPM (and, that does not work in mock right now, because mock serves the SRPM that existed at the start, not at the end of the build. Though it’s probably just a matter of getting mock to call again its SRPM creation method at the end of the build). The packager does not have to request the modification in his spec, it’s done as part of the various %auto_foo calls the change introduced > Is the old changelog discarded? The old changelog file is replaced in srpm sources with a new file containing new build event lines before the old lines. It is not done before the build is effective and %build has been started (ie a rpmbuild -bs or rpmspec -P will show the future bump, but nothing will be stored before the build is effective) > And is this related to Piere/Pingou's work on the same topic that was > deployed to koji staging? It’s a different implementation, at the rpm level, that does not tie bumping to Fedora infra (koji included). Though, it is probably complementary to what pingou did on the changelog alimentation front. IMHO the design mistake so far was to conflate bumping and non-build event changelog filling. You need to do both of course but build event should be a build event driven by the lowest common denominator (rpmbuild) with koji/infra scrapping rpmbuild results as usual and exposing them to users. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, Jul 1, 2020 at 8:24 PM James Cassell wrote: > > > On Wed, Jul 1, 2020, at 9:43 PM, Neal Gompa wrote: > > On Wed, Jul 1, 2020 at 9:27 PM James Cassell > > > Or maybe make all metadata raid 1, even on single disk set up? > > > > > > > Not that isn't interesting, but what would be the mirror target on a > > single disk setup? > > > > The idea is that the second copy of metadata on the same disk might be > readable in case the first copy has a checksum error, in case of fault > hardware. I haven't tried it, but I'd gladly give up a little space for more > robustness, especially if btrfs is sensitive to metadata corruption by the > hardware. If btrfs demands a separate device for raid1 metadata, I wonder if > a small 1G partition could be dedicated for purely mirrored metadata use. This is called 'dup' profile in Btrfs. Two copies of a block group. It can be set on metadata only, or both metadata and data block groups. It is the default mkfs option for HDDs. It is not enabled by default on SSDs because concurrent writes of metadata i.e. they happen essentially at the exact same time, means the data is likely to end up on the same erase block, and typical corruptions affect the whole block so it's widely considered to be pointless to use dup on flash media. You can use it anyway, either with mkfs, or by converting the block group from the single profile to dup. This is a safe procedure. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wednesday, July 1, 2020 6:32:15 AM MST Marcin Juszkiewicz wrote: > 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 ESP partition there. Install > grub-efi. Power off, switch to UEFI mode, power on, boot to grub-efi. > > Much easier than with real hardware machines where you indeed need to > play with partitions. On my laptop I have space available in /boot/ > partition so could shrink it and create ESP from there. But already have > ESP so no need. It's not that simple, in many cases. For example, both the virtualization setup I use at work, and my home virtualization setup, employs iSCSI so that I can migrate VMs between my various virtualization hosts. In order to create a new drive, I'd have to create a new LUN just for a 32-64MiB block device.. Not impossible by any means, but not as simple as the above. This would be similarly "more complex" in OpenStack environments. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wednesday, July 1, 2020 11:26:48 AM MST Jóhann B. Guðmundsson wrote: > On 1.7.2020 17:17, Peter Robinson wrote: > >> The use of legacy or uefi are changes that users have to manually change > >> themselves in their bios from manufactures default settings. There is no > >> tool that can do that for them or migrate those settings however users > >> should be able to change this for hardware around 2010. > >> > >> The Installer would have to try to detect and make a choise sd-boot ( If > >> settings equall UEFI ) or grub2 ( If setting not equals UEFI ) depending > >> on it's results. > > > > grub2 supports UEFI, doesn't have to be sd-boot > > Javier already has provide the best path forward for now and that is for > Anaconda to provide an sd-boot option in same/similar manner as extlinux > exist today so people will have the option to chose to use sd-boot instead > of GRUB. > > Those who want a simple modern bootloader will then have the ability to use > it while those need or prefer a boot manager OS and all it bells and > whistles it brings along with it can continue to use that. > > After what one or two releases of Fedora the idea of making sd-boot the > default for EFI installs can be visited and or WG decide that for > themselves. GRUB2 is not a "boot manager OS", it's a fairly simple, but modular, single threaded boot management application. GRUB2 supports UEFI well, probably better than systemd-bloat. At the same time, it's much more flexible in other aspects, providing users with the ability to boot their system in a number of situations that systemd-bloat doesn't support, as well as providing a recovery console in the event that there are issues loading the kernel and initramfs. GRUB2 also supports Secure Boot. Does systemd-bloat? -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Questions about installing epel-release
On 1/07/20 10:07 pm, Dominik 'Rathann' Mierzejewski wrote: This looks fine, although it seems it was re-signed with CentOS signing key. CentOS packages epel-release in the extras repo, so this is normal when it's installed that way. Peter ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Questions about installing epel-release
On 30/06/20 8:13 am, Dominik 'Rathann' Mierzejewski wrote: On Monday, 29 June 2020 at 03:27, Wei, Catherine wrote: Thanks. I fixed this by changing the reposdir=/etc/yum.163.yum.repos.d to /etc/yum.repos.d/, then the epel repository can be found. There are no such references in the epel-release package. This would have been a change made by the user before installing epel-release, or possibly it came from some panel software, or a VPS vendor or ... who knows, but crazy things get done by prior admins, clueless vendors, etc. Peter ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2020-07-02 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/02/report-389-ds-base-1.4.4.3-20200701git53f9218.fc32.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: Is allowed in certain cases to override default Fedora compiler flags?
On Wed, Jul 1, 2020 at 2:49 PM Sergio Belkin wrote: > So the question is: in this case I can override the Fedora compiler flags? There may be a solution that doesn't require overriding the Fedora compiler flags, but it is hard to tell without seeing more of the code. Where is the source code in question? -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, Jul 1, 2020 at 12:06 PM Susi Lehtola wrote: > On Wed, 1 Jul 2020 10:54:16 -0600 > Jerry James wrote: > > openblas-serial: use if the application is multithreaded > > openblas-threads: use if the application is single-threaded > > No, this is exactly the wrong way around. You should use the serial > library for code that you want to be running in serial (this way you > can get several instances of the program running efficiently), and the > pthreads version if you want to run the BLAS/LAPACK regions in parallel > (but are somehow opposed to OpenMP!).. Okay, I think the wiki's wording is hard to understand (https://github.com/xianyi/OpenBLAS/wiki/faq#multi-threaded), at least for me. Let me see if I've got this straight. 1. openblas-opemp computes on subranges in parallel using OpenMP 2. openblas-threads computes on subranges in parallel using pthreads 3. openblas-serial uses a single thread for the entire computation Right? What I'm looking for is a set of rules I can apply when I've got a package that uses BLAS, but upstream has given no guidance on what kind of BLAS library is suitable. I've got several of those, so I want to check that they're linking with the best version of the library. How should I make that determination? Also, how do I know whether to use, say, openblas-openmp vs. openblas-openmp64 vs. openblas-openmp64_? -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, Jul 1, 2020, at 9:43 PM, Neal Gompa wrote: > On Wed, Jul 1, 2020 at 9:27 PM James Cassell > wrote: > > > > > > On Wed, Jul 1, 2020, at 9:03 PM, Przemek Klosowski via devel wrote: > > > On 7/1/20 3:50 PM, Josef Bacik wrote: > > > > This sounds like a "wtf, why are you doing this btrfs?" sort of thing, > > > > but this is just the reality of using checksums. It's a checksum, not > > > > ECC. > > > > > > Yes, exactly---why isn't it ECC? Wouldn't it work better, especially in > > > the context of faulty hardware? > > > > > > I do realize it would require changing the on-disk format, and maybe > > > slow the critical path... > > > > > > > Or maybe make all metadata raid 1, even on single disk set up? > > > > Not that isn't interesting, but what would be the mirror target on a > single disk setup? > The idea is that the second copy of metadata on the same disk might be readable in case the first copy has a checksum error, in case of fault hardware. I haven't tried it, but I'd gladly give up a little space for more robustness, especially if btrfs is sensitive to metadata corruption by the hardware. If btrfs demands a separate device for raid1 metadata, I wonder if a small 1G partition could be dedicated for purely mirrored metadata use. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wed, Jul 1, 2020 at 10:08 PM Jóhann B. Guðmundsson wrote: > > On 2.7.2020 01:42, Neal Gompa wrote: > > On Wed, Jul 1, 2020 at 9:23 PM Jóhann B. Guðmundsson > > wrote: > >> On 2.7.2020 01:06, Neal Gompa wrote: > >>> On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson > >>> wrote: > On 1.7.2020 23:28, Neal Gompa wrote: > > On Wed, Jul 1, 2020 at 7:19 PM Björn Persson > > wrote: > >> Jóhann B. Guðmundsson wrote: > >>> More user friendly than Grub ( has lilo like interface easier to > >>> change > >>> kernel entry, which goes nicely with the default editor change ) > >> This made me go "What?!". I used Lilo back in the day. Its user > >> interface was nothing but a prompt. You had to know what to type or > >> you'd be stuck. > >> > >> Information for others like me who haven't seen Lilo since Grub came > >> along: Apparently development of Lilo continued until just five years > >> ago, and it grew a menu at some point. I guess that menu is the image > >> of user-friendliness that Johann was trying to invoke. > >> > > If I ever wanted to switch to another boot manager, I'd seriously like > > us to consider rEFInd: https://www.rodsbooks.com/refind/ > > > > It's a very nice boot manager that looks good and doesn't suck. And > > purportedly is somewhat (if not fully) compatible with bls. > > > > sd-boot is too barebones and unfriendly to use, which makes sense > > since it was designed for non-interactive machines and not humans to > > use. > If there is this general feel that sd-boots configuration syntax is much > harder to read and the ability of not having to run additional command > once the file has been edited or the ability to be able to easily > maintain and manage multiple kernels or multiple operating systems due > those being a drop-in configuration text files, is considered being too > bare bone and *less* user-friendly than grub, then obviously me creating > a change proposal based on what Javier suggested along with other > cleanups to provide as best user experience as can be had with sd-boot > would be doing the distribution a great disservice would it not? > > >>> Oh, I don't care about the configuration syntax. That part would be > >>> the same across grub, refind, and sd-boot anyway. > >>> > >>> The user-interactive portion of sd-boot is *awful*. I know our GRUB > >>> looks ugly by default these days too, but it doesn't have to be, and > >>> most distros actually do make it look semi-decent. > >>> > >>> But alas, nobody cares about making that part look nice, because they > >>> hope people don't have to go there at all. But even Windows makes > >>> their boot manager not look ugly and relatively easy to navigate. And > >>> obviously Apple has done this forever with macOS. > >>> > >>> I honestly don't get why everyone is okay with butt-ugly and > >>> user-unfriendly UX. > >> Because the end user should never find himself in the boot manager to > >> begin with that's why no boot manager invest any time in being "pretty". > >> > >> The end user should find himself ending up in some form of shiny nice > >> user friendly rescue environment that helps him troubleshoot his problem > >> would you agree? > >> > > I would, except, we can't have that either, because nobody cares to > > make that either. > > Well if anything I would have expected atleast the Gnome community to > care deeply about that and build a a rescue environment consistent with > the overall Gnome experience. > This is the first time I'm hearing of GNOME being interested in preboot environments. > If we implement sd-boot in conjunction with the automatic boot > assessment we should be able to boot into such environment if the end > users boot fails but if people oppose sd-boot and see that as unusable > root of all evil or there is no interest within the Workstation WG and > or Gnome community ( Team Anaconda might be the right place for such > work? ) working on to provide such an rescue environment then obviously > nothing will change. > This could still work. But you really shouldn't accept butt-ugliness from any user-facing technology, even sd-boot. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 2.7.2020 01:42, Neal Gompa wrote: On Wed, Jul 1, 2020 at 9:23 PM Jóhann B. Guðmundsson wrote: On 2.7.2020 01:06, Neal Gompa wrote: On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson wrote: On 1.7.2020 23:28, Neal Gompa wrote: On Wed, Jul 1, 2020 at 7:19 PM Björn Persson wrote: Jóhann B. Guðmundsson wrote: More user friendly than Grub ( has lilo like interface easier to change kernel entry, which goes nicely with the default editor change ) This made me go "What?!". I used Lilo back in the day. Its user interface was nothing but a prompt. You had to know what to type or you'd be stuck. Information for others like me who haven't seen Lilo since Grub came along: Apparently development of Lilo continued until just five years ago, and it grew a menu at some point. I guess that menu is the image of user-friendliness that Johann was trying to invoke. If I ever wanted to switch to another boot manager, I'd seriously like us to consider rEFInd: https://www.rodsbooks.com/refind/ It's a very nice boot manager that looks good and doesn't suck. And purportedly is somewhat (if not fully) compatible with bls. sd-boot is too barebones and unfriendly to use, which makes sense since it was designed for non-interactive machines and not humans to use. If there is this general feel that sd-boots configuration syntax is much harder to read and the ability of not having to run additional command once the file has been edited or the ability to be able to easily maintain and manage multiple kernels or multiple operating systems due those being a drop-in configuration text files, is considered being too bare bone and *less* user-friendly than grub, then obviously me creating a change proposal based on what Javier suggested along with other cleanups to provide as best user experience as can be had with sd-boot would be doing the distribution a great disservice would it not? Oh, I don't care about the configuration syntax. That part would be the same across grub, refind, and sd-boot anyway. The user-interactive portion of sd-boot is *awful*. I know our GRUB looks ugly by default these days too, but it doesn't have to be, and most distros actually do make it look semi-decent. But alas, nobody cares about making that part look nice, because they hope people don't have to go there at all. But even Windows makes their boot manager not look ugly and relatively easy to navigate. And obviously Apple has done this forever with macOS. I honestly don't get why everyone is okay with butt-ugly and user-unfriendly UX. Because the end user should never find himself in the boot manager to begin with that's why no boot manager invest any time in being "pretty". The end user should find himself ending up in some form of shiny nice user friendly rescue environment that helps him troubleshoot his problem would you agree? I would, except, we can't have that either, because nobody cares to make that either. Well if anything I would have expected atleast the Gnome community to care deeply about that and build a a rescue environment consistent with the overall Gnome experience. If we implement sd-boot in conjunction with the automatic boot assessment we should be able to boot into such environment if the end users boot fails but if people oppose sd-boot and see that as unusable root of all evil or there is no interest within the Workstation WG and or Gnome community ( Team Anaconda might be the right place for such work? ) working on to provide such an rescue environment then obviously nothing will change. JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1849996] perl-ExtUtils-MakeMaker-7.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1849996 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-ExtUtils-MakeMaker-7.4 |perl-ExtUtils-MakeMaker-7.4 |6-1.fc33|6-1.fc33 |perl-ExtUtils-MakeMaker-7.4 |perl-ExtUtils-MakeMaker-7.4 |6-1.fc32|6-1.fc32 ||perl-ExtUtils-MakeMaker-7.4 ||6-1.fc31 --- Comment #7 from Fedora Update System --- FEDORA-2020-4e08d6a0c7 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1849342] perl-Module-CoreList-5.20200620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1849342 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020 |0620-1.fc33 |0620-1.fc33 |perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020 |0620-1.fc32 |0620-1.fc32 ||perl-Module-CoreList-5.2020 ||0620-1.fc31 --- Comment #7 from Fedora Update System --- FEDORA-2020-f3b47f7af8 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
Once upon a time, Josef Bacik said: > This sounds like a "wtf, why are you doing this btrfs?" sort of > thing, but this is just the reality of using checksums. It's a > checksum, not ECC. We don't know _which_ bits are fucked, we just > know somethings fucked, so we throw it all away. If you have RAID > or DUP then we go read the other copy, and fix the broken copy if we > find a good copy. If we don't, well then there's nothing really we > can do. That's where an fsck and a lost+found type directory should come into play. Maybe punt to user space, but still try to see what you can make sense of to try to salvage. If you are saying a single bit error in the wrong place can basically lop off a good chunk of a filesystem, then I'm going to say that's not an improvement in reliability. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, Jul 1, 2020 at 9:27 PM James Cassell wrote: > > > On Wed, Jul 1, 2020, at 9:03 PM, Przemek Klosowski via devel wrote: > > On 7/1/20 3:50 PM, Josef Bacik wrote: > > > This sounds like a "wtf, why are you doing this btrfs?" sort of thing, > > > but this is just the reality of using checksums. It's a checksum, not > > > ECC. > > > > Yes, exactly---why isn't it ECC? Wouldn't it work better, especially in > > the context of faulty hardware? > > > > I do realize it would require changing the on-disk format, and maybe > > slow the critical path... > > > > Or maybe make all metadata raid 1, even on single disk set up? > Not that isn't interesting, but what would be the mirror target on a single disk setup? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wed, Jul 1, 2020 at 9:23 PM Jóhann B. Guðmundsson wrote: > > On 2.7.2020 01:06, Neal Gompa wrote: > > On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson > > wrote: > >> On 1.7.2020 23:28, Neal Gompa wrote: > >>> On Wed, Jul 1, 2020 at 7:19 PM Björn Persson wrote: > Jóhann B. Guðmundsson wrote: > > More user friendly than Grub ( has lilo like interface easier to change > > kernel entry, which goes nicely with the default editor change ) > This made me go "What?!". I used Lilo back in the day. Its user > interface was nothing but a prompt. You had to know what to type or > you'd be stuck. > > Information for others like me who haven't seen Lilo since Grub came > along: Apparently development of Lilo continued until just five years > ago, and it grew a menu at some point. I guess that menu is the image > of user-friendliness that Johann was trying to invoke. > > >>> If I ever wanted to switch to another boot manager, I'd seriously like > >>> us to consider rEFInd: https://www.rodsbooks.com/refind/ > >>> > >>> It's a very nice boot manager that looks good and doesn't suck. And > >>> purportedly is somewhat (if not fully) compatible with bls. > >>> > >>> sd-boot is too barebones and unfriendly to use, which makes sense > >>> since it was designed for non-interactive machines and not humans to > >>> use. > >> If there is this general feel that sd-boots configuration syntax is much > >> harder to read and the ability of not having to run additional command > >> once the file has been edited or the ability to be able to easily > >> maintain and manage multiple kernels or multiple operating systems due > >> those being a drop-in configuration text files, is considered being too > >> bare bone and *less* user-friendly than grub, then obviously me creating > >> a change proposal based on what Javier suggested along with other > >> cleanups to provide as best user experience as can be had with sd-boot > >> would be doing the distribution a great disservice would it not? > >> > > Oh, I don't care about the configuration syntax. That part would be > > the same across grub, refind, and sd-boot anyway. > > > > The user-interactive portion of sd-boot is *awful*. I know our GRUB > > looks ugly by default these days too, but it doesn't have to be, and > > most distros actually do make it look semi-decent. > > > > But alas, nobody cares about making that part look nice, because they > > hope people don't have to go there at all. But even Windows makes > > their boot manager not look ugly and relatively easy to navigate. And > > obviously Apple has done this forever with macOS. > > > > I honestly don't get why everyone is okay with butt-ugly and > > user-unfriendly UX. > > Because the end user should never find himself in the boot manager to > begin with that's why no boot manager invest any time in being "pretty". > > The end user should find himself ending up in some form of shiny nice > user friendly rescue environment that helps him troubleshoot his problem > would you agree? > I would, except, we can't have that either, because nobody cares to make that either. In the Windows and macOS world, these two things are paramount and they're combined with a more solid boot manager experience. We have none of that on the Linux side because all the incentives are wrong in the Linux world: we're driven exclusively by people who know what they're doing and don't like change. We have less of this problem in Fedora, but all the *money* in Linux is pushed for *not changing*, so that makes life very difficult. The server world uses automation and APIs as a substitute for making good user experiences. And it shows. That's why we get more dumb services further stratifying the landscape of interfaces needed to do something meaningful rather than actually *changing* things to be better. That's why GUI tools keep getting retired for complex web applications. That's why we can't have nice things. Because nobody with power cares enough. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d2ea82902e python-httplib2-0.18.1-1.el6 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b1a8a3c29a putty-0.74-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing php-getid3-1.9.20-1.el6 Details about builds: php-getid3-1.9.20-1.el6 (FEDORA-EPEL-2020-bdc6d54981) The PHP media file parser Update Information: **Version 1.9.20**: [2020-06-30] James Heinrich :: 1.9.20-202006061653 * add support for DSDIFF audio * add support for TAK lossess audio * add support for IVF video * add detection support for EPUB files * add detection support for HPK archives * add demo.mysqli.php, remove demo.mysql.php * QuickTime.uuid now returned as an array (may contain multiple entries) * improved PDF support, including page count * bugfix (G:247) array_min incorrect return value * bugfix (G:242) filepointer analysis errors * bugfix (G:238) comments_html may not match comments * bugfix (G:235) prevent disclosing paths when accessing modules directly * bugfix (G:233) Quicktime duplicate attached images * bugfix (G:229) Quicktime timestamps easy access * bugfix (G:228) master.zip did not contain demos * bugfix (G:227) Quicktime check subatoms data length * bugfix (G:226) uuid parsing based on UUID * bugfix (G:225) use comments_html content already generated by modules * bugfix (G:223) ID3v2 slashed genre names * bugfix (G:222) demo.browse filesystem character encoding * bugfix (G:221) option_tags_html=false ignored * bugfix (G:219) Quicktime.UUID now parsed more discriminately for XML and other data types * bugfix (G:218) QuickTime not copying covr to comments * bugfix (G:217) mp3 array offsets of type bool * bugfix (G:216) ID3v2.write allow WMP rating in POPM * bugfix (G:210) PHP 7.4 deprecated get_magic_quotes * bugfix: Quicktime detect null-terminated strings used where Pascal strings should be * bugfix: Quicktime GPS uninitialized array keys ChangeLog: * Wed Jul 1 2020 Remi Collet - 1.9.20-1 - update to 1.9.20 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 687 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 428 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 426 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 136 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 76 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19d171a465 python34-3.4.10-5.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f33a36b2c4 python-httplib2-0.18.1-3.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c438b9fb89 lynis-3.0.0-1.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d749373a67 znc-1.8.1-1.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-af9b2ac861 alpine-2.23-2.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6ad4894c0c jbig2dec-0.12-5.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0078f6abc1 xpdf-3.04-10.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-af9c6001d1 ngircd-26-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5d348316dd chromium-83.0.4103.116-3.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-afd5c42fd6 coturn-4.5.1.3-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6949cf3502 xrdp-0.9.13.1-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2f70f49092 putty-0.74-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing baresip-0.6.6-2.el7 knot-resolver-5.1.2-1.el7 openhantek-3.1.1-1.el7 php-getid3-1.9.20-1.el7 Details about builds: baresip-0.6.6-2.el7 (FEDORA-EPEL-2020-3bc4661dcf) Modular SIP user-agent with audio and video support Update Information: A modular SIP user-agent with support for audio and video, and many IETF standards such as SIP, RTP, STUN, TURN, and ICE for both, IPv4 and IPv6. Additional modules provide support for audio codecs like G.711, G.722, G.726, GSM, L16, MPA, and Opus, audio drivers like ALSA, GStreamer, JACK Audio Connection Kit, Portaudio, and PulseAudio, video codecs like VP8 or VP9, video sources like Video4Linux and X11 grabber, video outputs like SDL2 or X11, NAT traversal via STUN, TURN, ICE, NATBD, and NAT-PMP, media encryption via SRTP or DTLS-SRTP, management features like embedded web-server with HTTP interface, command-line console and interface, and MQTT. ChangeLog: References: [ 1 ] Bug #1843279 - Review Request: baresip - Modular SIP user-agent with audio and video support https://bugzilla.redhat.com/show_bug.cgi?id=1843279 knot-resolver-5.1.2-1.el7 (FEDORA-EPEL-2020-479f029a98) Caching full DNS Resolver Update Information: - update to new upstream version ChangeLog: * Wed Jul 1 2020 Tomas Krizek - 5.1.2-1 - update to upstream version 5.1.2 openhantek-3.1.1-1.el7 (FEDORA-EPEL-2020-2a5d5bf440) Hantek and compatible USB digital signal oscilloscope Update Information: Update to 3.1.1. ChangeLog: * Wed Jul 1 2020 Vasiliy N. Glazov - 3.1.1-1 - Update to 3.1.1 php-getid3-1.9.20-1.el7 (FEDORA-EPEL-2020-0217ac6286) The PHP media file parser Update Information: **Version 1.9.20**: [2020-06-30] James Heinrich :: 1.9.20-202006061653 * add support for DSDIFF audio * add support for TAK lossess audio * add support for IVF video * add detection support for EPUB files * add detection support for HPK archives * add demo.mysqli.php, remove demo.mysql.php * QuickTime.uuid now returned as an array (may contain multiple entries) * improved PDF support, including page
[Bug 1852856] perl-Template-Toolkit depends on mod_perl, which eventually installs httpd
https://bugzilla.redhat.com/show_bug.cgi?id=1852856 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2020-b01f134c3e has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b01f134c3e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-232e4f7411 python-django-2.2.13-1.el8 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-18fb909316 znc-1.8.1-1.el8 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3c9503ab68 libmp4v2-2.1.0-0.21.trunkREV507.el8 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f64e687c3f lynis-3.0.0-1.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c047cbdfd0 hostapd-2.9-4.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4d185f6e16 alpine-2.23-2.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-da42cd0f70 ngircd-26-3.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6e0d8564ec chromium-83.0.4103.116-3.el8 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8e909a0e81 coturn-4.5.1.3-1.el8 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f1828228be xrdp-0.9.13.1-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing aqbanking-6.1.4-1.el8 baresip-0.6.6-2.el8 gnucash-4.0-1.el8 gnucash-docs-4.0-1.el8 gwenhywfar-5.3.0-2.el8 haveged-1.9.13-2.el8 knot-resolver-5.1.2-1.el8 ktoblzcheck-1.49-3.el8 libofx-0.9.13-4.el8 openhantek-3.1.1-1.el8 perl-DateTimeX-Easy-0.089-25.el8 perl-Template-Toolkit-2.29-4.el8 Details about builds: aqbanking-6.1.4-1.el8 (FEDORA-EPEL-2020-b1c000c190) A library for online banking functions and financial data import/export Update Information: This is the initial build of GnuCash for EPEL 8, and is the latest upstream version, 4.0. ChangeLog: References: [ 1 ] Bug #1794161 - Request to package gnucash for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1794161 [ 2 ] Bug #1828052 - Please build gwenhywfar for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1828052 [ 3 ] Bug #1828053 - Please build aqbanking for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1828053 baresip-0.6.6-2.el8 (FEDORA-EPEL-2020-b24e67db35) Modular SIP user-agent with audio and video support Update Information: A modular SIP user-agent with support for audio and video, and many IETF standards such as SIP, RTP, STUN, TURN, and ICE for both, IPv4 and IPv6. Additional modules provide support for audio codecs like G.711, G.722, G.726, GSM, L16, MPA, and Opus, audio drivers like ALSA, GStreamer, JACK Audio Connection Kit, Portaudio, and PulseAudio, video codecs like VP8 or VP9, video sources like Video4Linux and X11 grabber, video outputs like SDL2 or X11, NAT traversal via STUN, TURN, ICE, NATBD, and NAT-PMP, media encryption via SRTP or DTLS-SRTP, management features like embedded web-server with HTTP interface, command-line console and interface, and MQTT. ChangeLog: References: [ 1 ] Bug #1843279 - Review Request: baresip - Modular SIP user-agent with audio and video support https://bugzilla.redhat.com/show_bug.cgi?id=1843279 gnucash-4.0-1.el8 (FEDORA-EPEL-2020-b1c000c190) Finance management application Update Information: This is the initial build of GnuCash for EPEL 8, and is the latest upstream version, 4.0. ChangeLog: References: [ 1 ] Bug #1794161 - Request to package gnucash for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1794161 [ 2 ] Bug #1828052 - Please build gwenhywfar for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1828052 [ 3 ] Bug #1828053 - Please build aqbanking for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1828053 gnucash-docs-4.0-1.el8
Re: The future of legacy BIOS support in Fedora.
On 2.7.2020 01:06, Neal Gompa wrote: On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson wrote: On 1.7.2020 23:28, Neal Gompa wrote: On Wed, Jul 1, 2020 at 7:19 PM Björn Persson wrote: Jóhann B. Guðmundsson wrote: More user friendly than Grub ( has lilo like interface easier to change kernel entry, which goes nicely with the default editor change ) This made me go "What?!". I used Lilo back in the day. Its user interface was nothing but a prompt. You had to know what to type or you'd be stuck. Information for others like me who haven't seen Lilo since Grub came along: Apparently development of Lilo continued until just five years ago, and it grew a menu at some point. I guess that menu is the image of user-friendliness that Johann was trying to invoke. If I ever wanted to switch to another boot manager, I'd seriously like us to consider rEFInd: https://www.rodsbooks.com/refind/ It's a very nice boot manager that looks good and doesn't suck. And purportedly is somewhat (if not fully) compatible with bls. sd-boot is too barebones and unfriendly to use, which makes sense since it was designed for non-interactive machines and not humans to use. If there is this general feel that sd-boots configuration syntax is much harder to read and the ability of not having to run additional command once the file has been edited or the ability to be able to easily maintain and manage multiple kernels or multiple operating systems due those being a drop-in configuration text files, is considered being too bare bone and *less* user-friendly than grub, then obviously me creating a change proposal based on what Javier suggested along with other cleanups to provide as best user experience as can be had with sd-boot would be doing the distribution a great disservice would it not? Oh, I don't care about the configuration syntax. That part would be the same across grub, refind, and sd-boot anyway. The user-interactive portion of sd-boot is *awful*. I know our GRUB looks ugly by default these days too, but it doesn't have to be, and most distros actually do make it look semi-decent. But alas, nobody cares about making that part look nice, because they hope people don't have to go there at all. But even Windows makes their boot manager not look ugly and relatively easy to navigate. And obviously Apple has done this forever with macOS. I honestly don't get why everyone is okay with butt-ugly and user-unfriendly UX. Because the end user should never find himself in the boot manager to begin with that's why no boot manager invest any time in being "pretty". The end user should find himself ending up in some form of shiny nice user friendly rescue environment that helps him troubleshoot his problem would you agree? JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1850795] Add perl-DateTimeX-Easy to EPEL8 / co-maintainer request
https://bugzilla.redhat.com/show_bug.cgi?id=1850795 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2020-290e37916e has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-290e37916e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Solomon Peachy writes: Even putting that aside, for the past several years CSM/BIOS has been slowly bitrotting due to a lack of real testing, as the last few Windows releases have mandated use of UEFI for preinstalled systems, plus the EOLing of Windows 7 and (especially) XP. That's only because it's Microsoft. I have ten year old hardware that runs just fine, and boots Fedora just fine. It's built like a tank, it's just as zippy as the day it was new, and this old Thinkpad will probably outlive me. It will be a sad day when I can continue to order minor replacement parts off Amazon, to replace the few worn out ones, but I can't install Fedora on it. pgpESjd6k6Vfl.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, Jul 1, 2020, at 9:03 PM, Przemek Klosowski via devel wrote: > On 7/1/20 3:50 PM, Josef Bacik wrote: > > This sounds like a "wtf, why are you doing this btrfs?" sort of thing, > > but this is just the reality of using checksums. It's a checksum, not > > ECC. > > Yes, exactly---why isn't it ECC? Wouldn't it work better, especially in > the context of faulty hardware? > > I do realize it would require changing the on-disk format, and maybe > slow the critical path... > Or maybe make all metadata raid 1, even on single disk set up? V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1849342] perl-Module-CoreList-5.20200620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1849342 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020 |0620-1.fc33 |0620-1.fc33 ||perl-Module-CoreList-5.2020 ||0620-1.fc32 Resolution|--- |ERRATA Last Closed||2020-07-02 01:11:18 --- Comment #6 from Fedora Update System --- FEDORA-2020-91e8735192 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson wrote: > > On 1.7.2020 23:28, Neal Gompa wrote: > > On Wed, Jul 1, 2020 at 7:19 PM Björn Persson wrote: > >> Jóhann B. Guðmundsson wrote: > >>> More user friendly than Grub ( has lilo like interface easier to change > >>> kernel entry, which goes nicely with the default editor change ) > >> This made me go "What?!". I used Lilo back in the day. Its user > >> interface was nothing but a prompt. You had to know what to type or > >> you'd be stuck. > >> > >> Information for others like me who haven't seen Lilo since Grub came > >> along: Apparently development of Lilo continued until just five years > >> ago, and it grew a menu at some point. I guess that menu is the image > >> of user-friendliness that Johann was trying to invoke. > >> > > If I ever wanted to switch to another boot manager, I'd seriously like > > us to consider rEFInd: https://www.rodsbooks.com/refind/ > > > > It's a very nice boot manager that looks good and doesn't suck. And > > purportedly is somewhat (if not fully) compatible with bls. > > > > sd-boot is too barebones and unfriendly to use, which makes sense > > since it was designed for non-interactive machines and not humans to > > use. > > If there is this general feel that sd-boots configuration syntax is much > harder to read and the ability of not having to run additional command > once the file has been edited or the ability to be able to easily > maintain and manage multiple kernels or multiple operating systems due > those being a drop-in configuration text files, is considered being too > bare bone and *less* user-friendly than grub, then obviously me creating > a change proposal based on what Javier suggested along with other > cleanups to provide as best user experience as can be had with sd-boot > would be doing the distribution a great disservice would it not? > Oh, I don't care about the configuration syntax. That part would be the same across grub, refind, and sd-boot anyway. The user-interactive portion of sd-boot is *awful*. I know our GRUB looks ugly by default these days too, but it doesn't have to be, and most distros actually do make it look semi-decent. But alas, nobody cares about making that part look nice, because they hope people don't have to go there at all. But even Windows makes their boot manager not look ugly and relatively easy to navigate. And obviously Apple has done this forever with macOS. I honestly don't get why everyone is okay with butt-ugly and user-unfriendly UX. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 1.7.2020 23:28, Neal Gompa wrote: On Wed, Jul 1, 2020 at 7:19 PM Björn Persson wrote: Jóhann B. Guðmundsson wrote: More user friendly than Grub ( has lilo like interface easier to change kernel entry, which goes nicely with the default editor change ) This made me go "What?!". I used Lilo back in the day. Its user interface was nothing but a prompt. You had to know what to type or you'd be stuck. Information for others like me who haven't seen Lilo since Grub came along: Apparently development of Lilo continued until just five years ago, and it grew a menu at some point. I guess that menu is the image of user-friendliness that Johann was trying to invoke. If I ever wanted to switch to another boot manager, I'd seriously like us to consider rEFInd: https://www.rodsbooks.com/refind/ It's a very nice boot manager that looks good and doesn't suck. And purportedly is somewhat (if not fully) compatible with bls. sd-boot is too barebones and unfriendly to use, which makes sense since it was designed for non-interactive machines and not humans to use. If there is this general feel that sd-boots configuration syntax is much harder to read and the ability of not having to run additional command once the file has been edited or the ability to be able to easily maintain and manage multiple kernels or multiple operating systems due those being a drop-in configuration text files, is considered being too bare bone and *less* user-friendly than grub, then obviously me creating a change proposal based on what Javier suggested along with other cleanups to provide as best user experience as can be had with sd-boot would be doing the distribution a great disservice would it not? JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/1/20 3:50 PM, Josef Bacik wrote: This sounds like a "wtf, why are you doing this btrfs?" sort of thing, but this is just the reality of using checksums. It's a checksum, not ECC. Yes, exactly---why isn't it ECC? Wouldn't it work better, especially in the context of faulty hardware? I do realize it would require changing the on-disk format, and maybe slow the critical path... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 1.7.2020 23:18, Björn Persson wrote: Jóhann B. Guðmundsson wrote: More user friendly than Grub ( has lilo like interface easier to change kernel entry, which goes nicely with the default editor change ) This made me go "What?!". I used Lilo back in the day. Its user interface was nothing but a prompt. You had to know what to type or you'd be stuck. Information for others like me who haven't seen Lilo since Grub came along: Apparently development of Lilo continued until just five years ago, and it grew a menu at some point. I guess that menu is the image of user-friendliness that Johann was trying to invoke. What I was referring to was that systemd uses split configuration text files which can easily be copy or edited like lilo.conf was but OK. JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
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 > I'm wondering, how do you actually want to define a "production > release" of a kernel module? > Does being part of an upstream kernel release (not in staging modules) > not qualify? > Because that's already the case, and has been for years. The > introduction of the btrfs module even predates all six currently > maintained LTS branches. > > Fabio Hey Fabio, No being part of an upstream kernel would be an important consideration for make a file system available for use (see F2FS) but default status requires a higher level of scrutiny. Many people appear to be going straight to the weeds on this proposal without backing up and seeing the big picture. It's the classic can't see the forest for the trees paradigm. Under Matt's leadership and repeating his words "we've worked hard to get Fedora a reputation of being problem-free and something that leads without being "bleeding edge". It's a tricky balance." I've posted my concerns and will wait until when and if there is a FESCo ticket to formally submit them. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: out of Koji disk space
On Wed, Jul 01, 2020 at 11:22:26PM +0200, Jan Kratochvil wrote: > On Wed, 01 Jul 2020 17:46:23 +0200, Kevin Fenzi wrote: > > * Is this only on x86_64 that you need this? Or all arches? > > Sure we should have this on all arches but I haven't tested non-x86_64 yet. > There possibly may be also some memory problems even on x86_64 (it builds on > my machine w/64GB but Koji has only 16GB + big swap). > > > > * you're guessing you need 160GB? Is that pretty accurate? > > $ du -shc `git ls-files` `cat sources |sed 's/^.*(\(.*\)).*$/\1/'` > chromium-83.0.4103.116-2/ BUILDROOT/ > ... ... > 161G chromium-83.0.4103.116/ > 14G BUILDROOT/ > 176G total > > > > I can fix that and they would have ~300GB or so each, would that be enough? > > It depends what other packages are being built on the same host, doesn't it? Yes, somewhat. The vast majority of the time that is the empty set. It's only when there's a mass build of something do all the builders really fill up. > > in that case you could submit and cancel until you got a buildhw-x86 ? > > I am not Chromium maintainer (Tom 'spot' Callaway is). I am not even sure Spot > will accept this change (although then why not). I do not want to talk for > Spot if he likes to do the builds this way. I have fixed the buildhw-x86 boxes, they all now have ~365GB now. Sorry, I misunderstood you... I thought you were wanting to test a scratch build that needed more space. You are proposing a change that will make official chromium builds take that extra space always? Our very fast a64 builders do not always have that amount of space, so it would have to fall back to the aarch64 buildvm's in that arch. > > Anyhow, I'd suggest filing an infrastructure ticket with your needs and > > we can see what we can come up with either short or long term for you. > > I will file a ticket after Spot says his opinion (or not). Sure. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wed, Jul 1, 2020 at 7:19 PM Björn Persson wrote: > > Jóhann B. Guðmundsson wrote: > > More user friendly than Grub ( has lilo like interface easier to change > > kernel entry, which goes nicely with the default editor change ) > > This made me go "What?!". I used Lilo back in the day. Its user > interface was nothing but a prompt. You had to know what to type or > you'd be stuck. > > Information for others like me who haven't seen Lilo since Grub came > along: Apparently development of Lilo continued until just five years > ago, and it grew a menu at some point. I guess that menu is the image > of user-friendliness that Johann was trying to invoke. > If I ever wanted to switch to another boot manager, I'd seriously like us to consider rEFInd: https://www.rodsbooks.com/refind/ It's a very nice boot manager that looks good and doesn't suck. And purportedly is somewhat (if not fully) compatible with bls. sd-boot is too barebones and unfriendly to use, which makes sense since it was designed for non-interactive machines and not humans to use. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Jóhann B. Guðmundsson wrote: > More user friendly than Grub ( has lilo like interface easier to change > kernel entry, which goes nicely with the default editor change ) This made me go "What?!". I used Lilo back in the day. Its user interface was nothing but a prompt. You had to know what to type or you'd be stuck. Information for others like me who haven't seen Lilo since Grub came along: Apparently development of Lilo continued until just five years ago, and it grew a menu at some point. I guess that menu is the image of user-friendliness that Johann was trying to invoke. Björn Persson pgpD3F8m6oPGh.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Jóhann B. Guðmundsson wrote: > Such proposal would never be about stop supporting older hardware that's > just a misconception people are getting When you write "stop supporting booting in legacy bios mode and move to uefi only supported boot", then you shouldn't be too surprised if people believe that you're proposing to stop supporting BIOS and support only UEFI. Björn Persson pgpifrbSgXICa.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wed, Jul 1, 2020 at 6:45 PM Jóhann B. Guðmundsson wrote:
>
> On 1.7.2020 21:50, Neal Gompa wrote:
> > On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson
> > wrote:
> >> On 1.7.2020 21:00, Neal Gompa wrote:
> >>> On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> >>> wrote:
> On 1.7.2020 16:10, Solomon Peachy wrote:
> > 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 several years CSM/BIOS has been
> > slowly bitrotting due to a lack of real testing, as the last few Windows
> > releases have mandated use of UEFI for preinstalled systems, plus the
> > EOLing of Windows 7 and (especially) XP.
> AMD is "strongly" recommending UEFI for the windows [1]
>
> So Apple dropped CSM in 2006
>
> Intel in 2020
>
> AMD is against it's use
>
> Windows has moved on with the curve...
>
> >>> That's great and all, but of all the cloud providers, only Microsoft's
> >>> Azure / Hyper-V platform actually requires UEFI support. Nobody else
> >>> even supports it! Okay, AWS only supports it for AArch64, but not x86.
> >>>
> >>> KVM guys here are still recommending BIOS.
> >>>
> >>> We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
> >>> kernel configuration is too strict for that. I personally consider it
> >>> a good thing, but that's a problem for others.
> >>>
> >>> Fix all the other problems we have with UEFI environments before
> >>> suggesting we drop "legacy BIOS".
> >>>
> >>> It's absolutely shameful that despite us being first to the UEFI
> >>> Secure Boot support, we *still* can't get things working fully in that
> >>> environment. And frankly, from what I can tell from all the people
> >>> involved: nobody cares except for the couple of people who ask every
> >>> few months why we can't have the NVIDIA driver signed and auto-trusted
> >>> so it works. I know every time I ask, people respond with "it's not
> >>> that simple" and more mumbles of Koji architecture problems.
> >>>
> >>> At this point, I personally don't want to see this proposal *ever*
> >>> come up again unless somebody cares about fixing the user experience
> >>> with UEFI.
> >> Based on the feedback here there are atleast 5 - 10 years before we can
> >> even consider removing it so no worries this wont come up again for a
> >> looong time but hopefully there are other areas we can improve upon
> >> which helps us improve the overall UEFI experience in Fedora etc.
> >>
> >> Perhaps it's not that people dont care and more that they are unaware of
> >> those problems I mean I personally was unaware of those problem and
> >> probably whole lot of other people here as well so could you list in
> >> more detail what exactly those user experience problems with UEFI are
> >> that you are aware of and we can try to compile a todo list to work with.
> >>
> > I suspect you may not be aware because nobody ever bothered to bubble
> > it up to you.
> >
> > I think most people are satisfied with the situation, but I'm not. I
> > despise NVIDIA, but guess what, there's no choice in the marketplace
> > anymore. Everyone ships NVIDIA GPUs, even with AMD CPUs on laptops.
> > And no laptop lets you swap GPUs like you can on desktops.
> >
> > Red Hat probably doesn't care because most server users are not using
> > UEFI yet. That proportion goes down a lot as people transition from on
> > premises to AWS. So this doesn't hurt their partnership with NVIDIA
> > where they tacitly encourage proprietary kernel module usage at scale.
> >
> > Since KVM in RHEL doesn't support UEFI properly either, nobody is
> > seriously looking at the issues caused by multiplexing NVIDIA GPUs and
> > exposing them into virtual machines running in UEFI Secure Boot,
> > because this just doesn't happen there. I've tried it on my Fedora
> > systems, they don't work.
> >
> > On the desktop side, most PC makers shipping Linux are turning UEFI or
> > UEFI Secure Boot off, which lets the NVIDIA driver work. But if you're
> > shipping Secure Boot on by default, as I suspect Lenovo will with
> > their Linux laptops, then the NVIDIA drivers will simply fail to
> > function.
> >
> > Nouveau obviously works (for some definition of works...), but because
> > NVIDIA is awful, it is not a useful driver like amdgpu is.
> >
> > The Fedora Koji Build System is not capable of building kernel module
> > packages and signing them so that they are trusted. The Koji Build
> > System *itself* does not make it easy to offer this functionality in
> > the same way that other build systems (like SUSE's OBS) do. Moreover,
> > we rely on RPM Fusion to build the driver package, which is fine,
> > except nobody can get RPM Fusion's Koji
Re: The future of legacy BIOS support in Fedora.
On 1.7.2020 21:50, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson wrote:
On 1.7.2020 21:00, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
wrote:
On 1.7.2020 16:10, Solomon Peachy wrote:
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 several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.
AMD is "strongly" recommending UEFI for the windows [1]
So Apple dropped CSM in 2006
Intel in 2020
AMD is against it's use
Windows has moved on with the curve...
That's great and all, but of all the cloud providers, only Microsoft's
Azure / Hyper-V platform actually requires UEFI support. Nobody else
even supports it! Okay, AWS only supports it for AArch64, but not x86.
KVM guys here are still recommending BIOS.
We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
kernel configuration is too strict for that. I personally consider it
a good thing, but that's a problem for others.
Fix all the other problems we have with UEFI environments before
suggesting we drop "legacy BIOS".
It's absolutely shameful that despite us being first to the UEFI
Secure Boot support, we *still* can't get things working fully in that
environment. And frankly, from what I can tell from all the people
involved: nobody cares except for the couple of people who ask every
few months why we can't have the NVIDIA driver signed and auto-trusted
so it works. I know every time I ask, people respond with "it's not
that simple" and more mumbles of Koji architecture problems.
At this point, I personally don't want to see this proposal *ever*
come up again unless somebody cares about fixing the user experience
with UEFI.
Based on the feedback here there are atleast 5 - 10 years before we can
even consider removing it so no worries this wont come up again for a
looong time but hopefully there are other areas we can improve upon
which helps us improve the overall UEFI experience in Fedora etc.
Perhaps it's not that people dont care and more that they are unaware of
those problems I mean I personally was unaware of those problem and
probably whole lot of other people here as well so could you list in
more detail what exactly those user experience problems with UEFI are
that you are aware of and we can try to compile a todo list to work with.
I suspect you may not be aware because nobody ever bothered to bubble
it up to you.
I think most people are satisfied with the situation, but I'm not. I
despise NVIDIA, but guess what, there's no choice in the marketplace
anymore. Everyone ships NVIDIA GPUs, even with AMD CPUs on laptops.
And no laptop lets you swap GPUs like you can on desktops.
Red Hat probably doesn't care because most server users are not using
UEFI yet. That proportion goes down a lot as people transition from on
premises to AWS. So this doesn't hurt their partnership with NVIDIA
where they tacitly encourage proprietary kernel module usage at scale.
Since KVM in RHEL doesn't support UEFI properly either, nobody is
seriously looking at the issues caused by multiplexing NVIDIA GPUs and
exposing them into virtual machines running in UEFI Secure Boot,
because this just doesn't happen there. I've tried it on my Fedora
systems, they don't work.
On the desktop side, most PC makers shipping Linux are turning UEFI or
UEFI Secure Boot off, which lets the NVIDIA driver work. But if you're
shipping Secure Boot on by default, as I suspect Lenovo will with
their Linux laptops, then the NVIDIA drivers will simply fail to
function.
Nouveau obviously works (for some definition of works...), but because
NVIDIA is awful, it is not a useful driver like amdgpu is.
The Fedora Koji Build System is not capable of building kernel module
packages and signing them so that they are trusted. The Koji Build
System *itself* does not make it easy to offer this functionality in
the same way that other build systems (like SUSE's OBS) do. Moreover,
we rely on RPM Fusion to build the driver package, which is fine,
except nobody can get RPM Fusion's Koji system to sign the driver
correctly and have the Fedora kernel trust the RPM Fusion certificate
automatically. Nor is there a straightforward way for packages to get
installed and have their signatures trusted so that kernel modules
that are properly signed will work.
The core of it is that nobody cares. It comes up at least once or
twice every development cycle in the Workstation Working Group
meetings, but there's nothing we can do. Sometimes I'll get bullshit
answers from people. Sometimes they'll just say stuff about security.
Sometimes they'll
Re: The future of legacy BIOS support in Fedora.
I've got a pair of admittedly old desktop machines that are BIOS-only that run Fedora 32 just fine. No reason they can't continue to run Fedora into the future - unless BIOS boot is eliminated. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wed, Jul 1, 2020 at 5:51 PM Neal Gompa wrote: > The core of it is that nobody cares. It comes up at least once or > twice every development cycle in the Workstation Working Group > meetings, but there's nothing we can do. Sometimes I'll get bullshit > answers from people. Sometimes they'll just say stuff about security. > Sometimes they'll say something about it being NVIDIA's problem. Is there a bug filed for this that I can follow? I didn't see one from a quick search. Personally, I use my own Secure Boot keys and sign the modules from akmods with that. It works fine with the cert in db since that gets it loaded into the platform keyring. I'd like to see the extract-vmlinux and/or insert-sys-cert kernel programs learn how to repack vmlinux back into an existing vmlinuz so that CONFIG_SYSTEM_EXTRA_CERTIFICATE can be useful with UEFI, and I could have a separate module signing key and Secure Boot key. Thanks. David ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson wrote:
>
> On 1.7.2020 21:00, Neal Gompa wrote:
> > On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> > wrote:
> >> On 1.7.2020 16:10, Solomon Peachy wrote:
> >>> 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 several years CSM/BIOS has been
> >>> slowly bitrotting due to a lack of real testing, as the last few Windows
> >>> releases have mandated use of UEFI for preinstalled systems, plus the
> >>> EOLing of Windows 7 and (especially) XP.
> >> AMD is "strongly" recommending UEFI for the windows [1]
> >>
> >> So Apple dropped CSM in 2006
> >>
> >> Intel in 2020
> >>
> >> AMD is against it's use
> >>
> >> Windows has moved on with the curve...
> >>
> > That's great and all, but of all the cloud providers, only Microsoft's
> > Azure / Hyper-V platform actually requires UEFI support. Nobody else
> > even supports it! Okay, AWS only supports it for AArch64, but not x86.
> >
> > KVM guys here are still recommending BIOS.
> >
> > We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
> > kernel configuration is too strict for that. I personally consider it
> > a good thing, but that's a problem for others.
> >
> > Fix all the other problems we have with UEFI environments before
> > suggesting we drop "legacy BIOS".
> >
> > It's absolutely shameful that despite us being first to the UEFI
> > Secure Boot support, we *still* can't get things working fully in that
> > environment. And frankly, from what I can tell from all the people
> > involved: nobody cares except for the couple of people who ask every
> > few months why we can't have the NVIDIA driver signed and auto-trusted
> > so it works. I know every time I ask, people respond with "it's not
> > that simple" and more mumbles of Koji architecture problems.
> >
> > At this point, I personally don't want to see this proposal *ever*
> > come up again unless somebody cares about fixing the user experience
> > with UEFI.
>
> Based on the feedback here there are atleast 5 - 10 years before we can
> even consider removing it so no worries this wont come up again for a
> looong time but hopefully there are other areas we can improve upon
> which helps us improve the overall UEFI experience in Fedora etc.
>
> Perhaps it's not that people dont care and more that they are unaware of
> those problems I mean I personally was unaware of those problem and
> probably whole lot of other people here as well so could you list in
> more detail what exactly those user experience problems with UEFI are
> that you are aware of and we can try to compile a todo list to work with.
>
I suspect you may not be aware because nobody ever bothered to bubble
it up to you.
I think most people are satisfied with the situation, but I'm not. I
despise NVIDIA, but guess what, there's no choice in the marketplace
anymore. Everyone ships NVIDIA GPUs, even with AMD CPUs on laptops.
And no laptop lets you swap GPUs like you can on desktops.
Red Hat probably doesn't care because most server users are not using
UEFI yet. That proportion goes down a lot as people transition from on
premises to AWS. So this doesn't hurt their partnership with NVIDIA
where they tacitly encourage proprietary kernel module usage at scale.
Since KVM in RHEL doesn't support UEFI properly either, nobody is
seriously looking at the issues caused by multiplexing NVIDIA GPUs and
exposing them into virtual machines running in UEFI Secure Boot,
because this just doesn't happen there. I've tried it on my Fedora
systems, they don't work.
On the desktop side, most PC makers shipping Linux are turning UEFI or
UEFI Secure Boot off, which lets the NVIDIA driver work. But if you're
shipping Secure Boot on by default, as I suspect Lenovo will with
their Linux laptops, then the NVIDIA drivers will simply fail to
function.
Nouveau obviously works (for some definition of works...), but because
NVIDIA is awful, it is not a useful driver like amdgpu is.
The Fedora Koji Build System is not capable of building kernel module
packages and signing them so that they are trusted. The Koji Build
System *itself* does not make it easy to offer this functionality in
the same way that other build systems (like SUSE's OBS) do. Moreover,
we rely on RPM Fusion to build the driver package, which is fine,
except nobody can get RPM Fusion's Koji system to sign the driver
correctly and have the Fedora kernel trust the RPM Fusion certificate
automatically. Nor is there a straightforward way for packages to get
installed and have their signatures trusted so that kernel modules
that are properly signed will work.
The core of it is that nobody cares. It comes up at least once or
twice every development cycle
Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
Hi Nicolas, Ben Cotton writes: > 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 == > > * Name: [[User:nim| Nicolas Mailhot]] > * Email: > > == Detailed Description == > > This is a system-wide change because all packages build with > redhat-rpm-config, but it only concerns packages that opted to use > this part of redhat-rpm-config (auto framework). > > The change will make those packages auto-bump and auto-changelog at > the rpm level, in an infrastructure-independent way. Please forgive the silly questions (it's getting late here…), but how does this look in practice? How do I let rpm generate the changelog automatically? Is the old changelog discarded? And is this related to Piere/Pingou's work on the same topic that was deployed to koji staging? Cheers, Dan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 1.7.2020 21:39, Ricky Zhang wrote: I second your point. I don't see any upside to discontinue support of legacy BIOS. Even my latest machine support legacy BIOS. UEFI caused more headache to me than bringing in any real positive user experiences. What headache exactly? You had bad user experience with UEFI because ? JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 1.7.2020 20:31, Ralf Corsepius wrote: On 6/30/20 3:34 PM, 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 available on any common intel based x86 platform since atleast 2005. This statement is simply not true - With all due respect, I for one consider this statement of yours to be close to a blatant cheat and a lie. Well I got this from the internet it was not as I intentionally meant to cheat or lie. Obviously I did not do a proper research or enough digging on Intel website to obtain correct information or this simply was some form of marketing speak from Intel, I mean what is "common intel based x86 platform"? JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
I second your point. I don't see any upside to discontinue support of legacy BIOS. Even my latest machine support legacy BIOS. UEFI caused more headache to me than bringing in any real positive user experiences. Fix all your bugs not even securities bugs before you concern the securities features brought by UEFI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
No, I strongly disagree your proposal. Don't break something that works. I have several home machines installing in legacy BIOS way. I have followed upgrade path **SMOOTHLY** from Fedora Core 14 up to Fedora 32 today. Your change will break my dual-boot / multi-boot machines. Please don't. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 at 21:00, Iñaki Ucar wrote: > > On Wed, 1 Jul 2020 at 20:24, Susi Lehtola > wrote: > > > > On Wed, 1 Jul 2020 19:28:53 +0200 > > Iñaki Ucar wrote: > > > I'm no expert, but the FAQ says: > > > > > > "You have a GPLed program that I'd like to link with my code to build > > > a proprietary program. Does the fact that I link with your program > > > mean I have to GPL my program? (#LinkingWithGPL) > > > > > > Not exactly. It means you must release your program under a license > > > compatible with the GPL (more precisely, compatible with one or more > > > GPL versions accepted by all the rest of the code in the combination > > > that you link). The combination itself is then available under those > > > GPL versions." > > > > > > So my understanding is that it's ok for a program to link to FlexiBLAS > > > if its license is GPL-compatible, not necessarily GPL. But of course > > > we would need confirmation from legal. > > > > The library is GPLv3 only > > > > https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release#license > > > > which already makes it incompatible with many GNU Licenses > > > > https://fedoraproject.org/wiki/Licensing:Main#GPL_Compatibility_Matrix > > With many? With GPLv2 only. But most interestingly, GPLv3 states: > > "Corresponding Source includes interface definition files associated > with source files for the work, and the source code for shared > libraries and dynamically linked subprograms that the work is > specifically designed to require" > > Technically, there's nothing in FlexiBLAS that a BLAS/LAPACK > application would require to work. These are designed to require > BLAS/LAPACK, and FlexiBLAS just duplicates that interface and glues > symbols together. > > Maybe I'm completely misunderstanding the sentence above, but GPL > restrictions of course apply to any program that uses the FlexiBLAS > API for profiling, etc., but not to those that just use the > BLAS/LAPACK API. In line with this, can FlexiBLAS be considered a "system library"? It sounds reasonable to me, but I read the definition in section 1 several times and still don't know. -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 1.7.2020 21:00, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
wrote:
On 1.7.2020 16:10, Solomon Peachy wrote:
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 several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.
AMD is "strongly" recommending UEFI for the windows [1]
So Apple dropped CSM in 2006
Intel in 2020
AMD is against it's use
Windows has moved on with the curve...
That's great and all, but of all the cloud providers, only Microsoft's
Azure / Hyper-V platform actually requires UEFI support. Nobody else
even supports it! Okay, AWS only supports it for AArch64, but not x86.
KVM guys here are still recommending BIOS.
We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
kernel configuration is too strict for that. I personally consider it
a good thing, but that's a problem for others.
Fix all the other problems we have with UEFI environments before
suggesting we drop "legacy BIOS".
It's absolutely shameful that despite us being first to the UEFI
Secure Boot support, we *still* can't get things working fully in that
environment. And frankly, from what I can tell from all the people
involved: nobody cares except for the couple of people who ask every
few months why we can't have the NVIDIA driver signed and auto-trusted
so it works. I know every time I ask, people respond with "it's not
that simple" and more mumbles of Koji architecture problems.
At this point, I personally don't want to see this proposal *ever*
come up again unless somebody cares about fixing the user experience
with UEFI.
Based on the feedback here there are atleast 5 - 10 years before we can
even consider removing it so no worries this wont come up again for a
looong time but hopefully there are other areas we can improve upon
which helps us improve the overall UEFI experience in Fedora etc.
Perhaps it's not that people dont care and more that they are unaware of
those problems I mean I personally was unaware of those problem and
probably whole lot of other people here as well so could you list in
more detail what exactly those user experience problems with UEFI are
that you are aware of and we can try to compile a todo list to work with.
JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: out of Koji disk space
On Wed, 01 Jul 2020 17:46:23 +0200, Kevin Fenzi wrote: > * Is this only on x86_64 that you need this? Or all arches? Sure we should have this on all arches but I haven't tested non-x86_64 yet. There possibly may be also some memory problems even on x86_64 (it builds on my machine w/64GB but Koji has only 16GB + big swap). > * you're guessing you need 160GB? Is that pretty accurate? $ du -shc `git ls-files` `cat sources |sed 's/^.*(\(.*\)).*$/\1/'` chromium-83.0.4103.116-2/ BUILDROOT/ ... ... 161Gchromium-83.0.4103.116/ 14G BUILDROOT/ 176Gtotal > I can fix that and they would have ~300GB or so each, would that be enough? It depends what other packages are being built on the same host, doesn't it? > in that case you could submit and cancel until you got a buildhw-x86 ? I am not Chromium maintainer (Tom 'spot' Callaway is). I am not even sure Spot will accept this change (although then why not). I do not want to talk for Spot if he likes to do the builds this way. > Anyhow, I'd suggest filing an infrastructure ticket with your needs and > we can see what we can come up with either short or long term for you. I will file a ticket after Spot says his opinion (or not). Thanks, Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/1/20 4:08 PM, Neal Gompa wrote: > On Wed, Jul 1, 2020 at 5:06 PM Eric Sandeen wrote: >> >> On 7/1/20 11:53 AM, Michael Catanzaro wrote: >>> On Wed, Jul 1, 2020 at 4:25 pm, Nicolas Mailhot via devel >>> wrote: Actually this split is a godsend because you can convince anaconda to leave your home alone when reinstalling, while someone always seems too invent a new Fedora change that justifies the reformatting of /. Good luck dealing with user data the next time workstation (or any other group) feels the / filesystem should change, once you've put user data on the same mount point >>> >>> So for the avoidance of doubt: if the btrfs change is rejected, we are >>> almost certain to put everything on the same mount point. We haven't >>> approved this yet, but odds are very high IMO. The options we are seriously >>> considering for our default going forward are (a) btrfs, (b) failing that, >>> probably ext4 all one big partition without LVM, (c) less-likely, maybe xfs >>> all one big partition without LVM. This is being discussed in >>> https://pagure.io/fedora-workstation/issue/152 >>> >>> We have a high number of complaints from developers running out of space on >>> / with plenty of space left on /home (happens to me all the time). The >>> opposite scenario is a problem too. Separate mountpoints by default is just >>> not a good default, sorry. Ensuring users don't run out of space due to bad >>> partitioning is more important than keeping /home during reinstall IMO. But >>> with btrfs, then /home will just be a subvolume so we can have our cake and >>> eat it too. >> >> This can be mitigated with directory (project) quotas, btw. >> >> On XFS, exceeding a directory tree quota even yields ENOSPC. >> (on ext4, it's EDQUOT right now.) >> >> So one big / partition including /home, with a directory quota set >> on /home at 20G, will yield ENOSPC when home contains 20G and will now >> allow / to get filled with user files. >> >> It's also trivial to adjust the directory quota on /home up or down, as >> needed. >> >> It's another cake eating-and-having option which is a pretty trivial >> thing to implement. > > This does not solve the "Anaconda will blow away /home because it's > technically part of /" problem, though. Btrfs subvolumes do. > > Directory quotas only protect against space contention, and while > Btrfs quotas do the same thing, we're deliberately not proposing > setting those up because we want space allocation to be flexible. I was not proposing directory quotas as any protection against mkfs of the root device, of course. Changing that behavior in Anaconda would be another rather minor change as well, i.e. the equivalent of "rm -rf /usr /var/ ..." instead of mkfs at reinstall time. -Eric ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, Jul 1, 2020 at 5:06 PM Eric Sandeen wrote: > > On 7/1/20 11:53 AM, Michael Catanzaro wrote: > > On Wed, Jul 1, 2020 at 4:25 pm, Nicolas Mailhot via devel > > wrote: > >> Actually this split is a godsend because you can convince anaconda to > >> leave your home alone when reinstalling, while someone always seems too > >> invent a new Fedora change that justifies the reformatting of /. > >> > >> Good luck dealing with user data the next time workstation (or any > >> other group) feels the / filesystem should change, once you've put user > >> data on the same mount point > > > > So for the avoidance of doubt: if the btrfs change is rejected, we are > > almost certain to put everything on the same mount point. We haven't > > approved this yet, but odds are very high IMO. The options we are seriously > > considering for our default going forward are (a) btrfs, (b) failing that, > > probably ext4 all one big partition without LVM, (c) less-likely, maybe xfs > > all one big partition without LVM. This is being discussed in > > https://pagure.io/fedora-workstation/issue/152 > > > > We have a high number of complaints from developers running out of space on > > / with plenty of space left on /home (happens to me all the time). The > > opposite scenario is a problem too. Separate mountpoints by default is just > > not a good default, sorry. Ensuring users don't run out of space due to bad > > partitioning is more important than keeping /home during reinstall IMO. But > > with btrfs, then /home will just be a subvolume so we can have our cake and > > eat it too. > > This can be mitigated with directory (project) quotas, btw. > > On XFS, exceeding a directory tree quota even yields ENOSPC. > (on ext4, it's EDQUOT right now.) > > So one big / partition including /home, with a directory quota set > on /home at 20G, will yield ENOSPC when home contains 20G and will now > allow / to get filled with user files. > > It's also trivial to adjust the directory quota on /home up or down, as > needed. > > It's another cake eating-and-having option which is a pretty trivial > thing to implement. This does not solve the "Anaconda will blow away /home because it's technically part of /" problem, though. Btrfs subvolumes do. Directory quotas only protect against space contention, and while Btrfs quotas do the same thing, we're deliberately not proposing setting those up because we want space allocation to be flexible. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/1/20 11:53 AM, Michael Catanzaro wrote: > On Wed, Jul 1, 2020 at 4:25 pm, Nicolas Mailhot via devel > wrote: >> Actually this split is a godsend because you can convince anaconda to >> leave your home alone when reinstalling, while someone always seems too >> invent a new Fedora change that justifies the reformatting of /. >> >> Good luck dealing with user data the next time workstation (or any >> other group) feels the / filesystem should change, once you've put user >> data on the same mount point > > So for the avoidance of doubt: if the btrfs change is rejected, we are almost > certain to put everything on the same mount point. We haven't approved this > yet, but odds are very high IMO. The options we are seriously considering for > our default going forward are (a) btrfs, (b) failing that, probably ext4 all > one big partition without LVM, (c) less-likely, maybe xfs all one big > partition without LVM. This is being discussed in > https://pagure.io/fedora-workstation/issue/152 > > We have a high number of complaints from developers running out of space on / > with plenty of space left on /home (happens to me all the time). The opposite > scenario is a problem too. Separate mountpoints by default is just not a good > default, sorry. Ensuring users don't run out of space due to bad partitioning > is more important than keeping /home during reinstall IMO. But with btrfs, > then /home will just be a subvolume so we can have our cake and eat it too. This can be mitigated with directory (project) quotas, btw. On XFS, exceeding a directory tree quota even yields ENOSPC. (on ext4, it's EDQUOT right now.) So one big / partition including /home, with a directory quota set on /home at 20G, will yield ENOSPC when home contains 20G and will now allow / to get filled with user files. It's also trivial to adjust the directory quota on /home up or down, as needed. It's another cake eating-and-having option which is a pretty trivial thing to implement. -Eric ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 2020-07-01 18:53, Michael Catanzaro wrote: The options we are seriously considering for our default going forward are (a) btrfs, (b) failing that, probably ext4 all one big partition without LVM, (c) less-likely, maybe xfs all one big partition without LVM. This is being discussed in https://pagure.io/fedora-workstation/issue/152 One partition without LVM? Maybe labeling this partition C:\ The real solution would be to make wise usage of LVM, for example by not allocating 100% of the extents at the beginning (or even dm-thin) and/or using filesystems where a shrink is supported (I'm here blaming xfs for not having this, while ext4 has). -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
wrote:
>
> On 1.7.2020 16:10, Solomon Peachy wrote:
> > 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 several years CSM/BIOS has been
> > slowly bitrotting due to a lack of real testing, as the last few Windows
> > releases have mandated use of UEFI for preinstalled systems, plus the
> > EOLing of Windows 7 and (especially) XP.
>
> AMD is "strongly" recommending UEFI for the windows [1]
>
> So Apple dropped CSM in 2006
>
> Intel in 2020
>
> AMD is against it's use
>
> Windows has moved on with the curve...
>
That's great and all, but of all the cloud providers, only Microsoft's
Azure / Hyper-V platform actually requires UEFI support. Nobody else
even supports it! Okay, AWS only supports it for AArch64, but not x86.
KVM guys here are still recommending BIOS.
We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
kernel configuration is too strict for that. I personally consider it
a good thing, but that's a problem for others.
Fix all the other problems we have with UEFI environments before
suggesting we drop "legacy BIOS".
It's absolutely shameful that despite us being first to the UEFI
Secure Boot support, we *still* can't get things working fully in that
environment. And frankly, from what I can tell from all the people
involved: nobody cares except for the couple of people who ask every
few months why we can't have the NVIDIA driver signed and auto-trusted
so it works. I know every time I ask, people respond with "it's not
that simple" and more mumbles of Koji architecture problems.
At this point, I personally don't want to see this proposal *ever*
come up again unless somebody cares about fixing the user experience
with UEFI.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 2020-07-01 04:07, Nico Kadel-Garcia wrote: On Sun, Jun 28, 2020 at 6:21 AM Antti wrote: Hello, I'm in total opposition to this proposal as a long-time Fedora user. The btrfs is unstable and not ready for production. Most of what I'm about to write is admittedly anecdotal but it's the only file system in Linux which has actively and regularly caused me to lose data on desktops, laptops, servers and even on mobile phones when I haven't taken precautions and done regular backups. Something I don't have to actively do when using ext4 in my workstations and notebooks. We had similar excitement back when reiserfs was popular. My limited play with btrfs reminds me of reiserfs: feature-filled but fragile and unsuitable for "/" partitions. My experience with reiserfs has been very different. It was a wonderful filesystem, with journaling when nobody had it (ext3 did not exist, we only had ext2). It was able to raise the disk capacity of the disk (thanks to tail-packing) and the performance was great (I was able to immediately notice if the filesystem was ext2 or reiserfs, as soon as you deleted a big iso: reiserfs was immediate, thanks to extents vs blocks, I think). I've never had filesystem corruption on reiserfs even on very hard workloads. A specific episode remains in my mind: I had rsync hardlink based backups on a server with software RAID disks. One day I decided to delete about one year of backups, at four per day it was around 1000 directories, each of them with 100,000 files (heavily cross hardlinked, of course). To try to get good parallelism out of the RAID and the elevator, I submitted 1000 rm commands in background and then realized that I was deleting 100,000,000 files with an enormous lock and refcount stress testing on the fs. After a few hours, operation completed, no issue. The same production server was switched years later to ext4, since continuing with a mostly world-forgotten reiserfs option had no point. After a few days with ext4... fs corruption and data loss, simply because of an online expansion that was nothing special on reiserfs. Turns out ext4 kernel/tools combination was bugged. I've been able to find my comments on bugzilla (year 2012). https://bugzilla.redhat.com/show_bug.cgi?id=852833#c25 including this: (BTW, ...spent the weekend restoring a couple terabytes from backups...) (As a tribute to justice in the world, I want to say, so that search engines index it, that this system has been in production since 2005 on reiserfs and abused and resized without any similar issues; it was rebuild recently on new hardware and switched to ext4 and now I really risked to lose the data, as the remote versioned backup is also (resized) ext4, and the remote-remote backup is also (resized) ext4. I'm not complaining, but reiserfs really has a much worse reputation than actually deserved). -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Is allowed in certain cases to override default Fedora compiler flags?
Hi, I'm trying to build a package for resubmission. However it fails with messages like that In file included from ./include/UpTools/UpLog.h:77, from UpLog.cc:46: UpLog.cc: In function 'void upOpenLogFileInternal(const char*, int, const char*, int, int (*)(char*))': ./include/UpTools/UpLog.inl:63:30: error: format not a string literal and no format arguments [-Werror=format-security] 63 |syslog(level, __VA_ARGS__ ); \ | ^ End of message The line in the code is: n += snprintf(logbuf+n,MAXLOGLINE-1-n, __VA_ARGS__ ); \ And also this warning: UpLog.cc: In function 'void upOpenLogInternal(const char*, int, int, int)': ./include/UpTools/UpLog.inl:69:11: warning: ignoring return value of 'ssize_t write(int, const void*, size_t)' declared with attribute 'warn_unused_result' [-Wunused-result] 69 |::write(upLogFd,logbuf,n); \ |~~~^~ ./include/UpTools/UpLog.h:115:26: note: in expansion of macro '_UPLOG_' 115 | #define UPLOG(level,...) _UPLOG_(level, __VA_ARGS__ ) End of message The line in the code is : if(upLogPerror) ::write(2,logbuf,n); \ Regarding to " format not a string literal and no format arguments [-Werror=format-security]" message. Afaik instructions of kind printf(format,var1,var2,...) always be fail, since it can't verify in compile time that the format includes the number of variables that appears later. If the developer does not use entered formats by the user, the exploit disappear, doesn't it? So the question is: in this case I can override the Fedora compiler flags? Thanks in advance! -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 7/1/20 6:10 PM, Solomon Peachy wrote:
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 several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.
Win 10 still runs on BIOS systems and (Unlike Fedora) on 32bit systems.
Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 6/30/20 3:34 PM, 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 available on any common intel based x86 platform since atleast 2005. This statement is simply not true - With all due respect, I for one consider this statement of yours to be close to a blatant cheat and a lie. I definitely own BIOS-only systems, which have been sold long after 2005 and which are still in everyday use. Now in 2017 Intel's technical marketing engineer Brian Richardson revealed in a presentation that the company will require UEFI Class 3 and above as in it would remove legacy BIOS support from its client and datacenter platforms by 2020 and one might expect AMD to follow Intel in this regard. Fedora should not care Intel's plans, but about the systems users use. IMNSHO, this inevitably must comprise to continueg supporting BIOS-systems for at least another decade. This post is just to gather feed back why Fedora should still continue to support legacy BIOS boot as opposed to stop supporting it and potentially drop grub2 and use sd-boot instead. Definitely the former. 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 system wide proposal. Dropping BIOS would render Fedora entire unsuitable for me and will like cause me to stop supporting Fedora. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/1/20 2:24 PM, Matthew Miller wrote: On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote: Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34 could be good option. I know technically it is already opt-in, but it's not very visible or popular. We could make the btrfs option more prominent and ask people to pick it if they are ready to handle potential fallout. I'm leaning towards recommending this as well. I feel like we don't have good data to make a decision on -- the work that Red Hat did previously when making a decision was 1) years ago and 2) server-focused, and the Facebook production usage is encouraging but also not the same use case. I'm particularly concerned about metadata corruption fragility as noted in the Usenix paper. (It'd be nice if we could do something about that!) There's only so much we can do about this. I've sent up patches to ignore failed global trees to allow users to more easily recover data in case of corruption in the case of global trees, but as they say if only 1 bit is off in a node, we throw the whole node away. And throwing a node away means you lose access to any of its children, which could be a large chunk of the file system. This sounds like a "wtf, why are you doing this btrfs?" sort of thing, but this is just the reality of using checksums. It's a checksum, not ECC. We don't know _which_ bits are fucked, we just know somethings fucked, so we throw it all away. If you have RAID or DUP then we go read the other copy, and fix the broken copy if we find a good copy. If we don't, well then there's nothing really we can do. As for their complaint about DIR_INDEX vs DIR_ITEM recovery, that's been around for a while now. A lot of these things have been added over the last year. Another thing to keep in mind is that fsck is _very_ conservative for a reason. It's only job is to get the fs back to the point that it can be mounted, it has no knowledge of what data is important and which is not. So by default it doesn't do much, because we want the user to be able to use the rescue tools to pull off any data they can before they run repair. Because it's possible that fsck decides to delete problematic entries, and maybe those entries are to data you cared about. I've stated this many times before, btrfs is more vulnerable to things going wrong. It's also more likely to notice things going wrong. There's things we can do to make it easier in the face of these issues, they're patches I've written and submitted in the last few days. There's bigger, more complex things that I can do to make us more resilient in the face of these corruptions. But even with all of the things I have in my head, I could still go do one or two things and render the file system unusable. Would these things happen in practice? Unlikely. Is it impossible? Unfortunately no. Thanks, Josef ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
I like this approach, a lot. I'm all in favour of switching to btrfs (I've been using it for a while, on server & desktop), and I think this would be a safe approach to do so. Christopher On 01.07.20 20:24, Matthew Miller wrote: > On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote: >> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34 >> could be good option. I know technically it is already opt-in, but it's not >> very visible or popular. We could make the btrfs option more prominent and >> ask people to pick it if they are ready to handle potential fallout. > > I'm leaning towards recommending this as well. I feel like we don't have > good data to make a decision on -- the work that Red Hat did previously when > making a decision was 1) years ago and 2) server-focused, and the Facebook > production usage is encouraging but also not the same use case. I'm > particularly concerned about metadata corruption fragility as noted in the > Usenix paper. (It'd be nice if we could do something about that!) > > Given the number of Fedora desktop users, even an increase of 0.1% in > now-I-can't-boot situations would be a catastrophe. Is that a risk? I > literally don't know. Maybe it's not -- but we've worked hard to get Fedora > a reputation of being problem-free and something that leads without being > "bleeding edge". It's a tricky balance. > >> Normally we just switch the default or we don't, without half measures. But >> the fs is important enough and complicated enough to be extra careful about >> any transitions. > > Exactly. > > Maybe we could add an "Automatically configure with btrfs (experimental)" > option to the Installation Destination screen, and then feature that in > Fedora Magazine and schedule a number of test days? > > To be clear, I'm not suggesting this as a blocking tactic. The assumption > would be that we'd go ahead with flipping the defaults (as you say above) > for F34 unless the results come back in a way that gives us pause. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] please review: PR 51199 - Stop importing cockpit's base1/patternfly.css
https://pagure.io/389-ds-base/pull-request/51199 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Tue, Jun 30, 2020, at 9:34 AM, 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 Among other clouds, AWS doesn't support it and has no plans to do so. So...yeah, we're not going to be removing BIOS support from Fedora CoreOS at least. (GCP does support UEFI and even has a virtual TPM, which is pretty cool) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 1 July 2020 20:24:37 CEST, Matthew Miller wrote: >On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote: >> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34 >> could be good option. I know technically it is already opt-in, but it's not >> very visible or popular. We could make the btrfs option more prominent and >> ask people to pick it if they are ready to handle potential fallout. > >I'm leaning towards recommending this as well. I feel like we don't have >good data to make a decision on -- the work that Red Hat did previously when >making a decision was 1) years ago and 2) server-focused, and the Facebook >production usage is encouraging but also not the same use case. I'm >particularly concerned about metadata corruption fragility as noted in the >Usenix paper. (It'd be nice if we could do something about that!) > >Given the number of Fedora desktop users, even an increase of 0.1% in >now-I-can't-boot situations would be a catastrophe. Is that a risk? I >literally don't know. Maybe it's not -- but we've worked hard to get Fedora >a reputation of being problem-free and something that leads without being >"bleeding edge". It's a tricky balance. > >> Normally we just switch the default or we don't, without half measures. But >> the fs is important enough and complicated enough to be extra careful about >> any transitions. > >Exactly. > >Maybe we could add an "Automatically configure with btrfs (experimental)" >option to the Installation Destination screen, and then feature that in >Fedora Magazine and schedule a number of test days? > >To be clear, I'm not suggesting this as a blocking tactic. The assumption >would be that we'd go ahead with flipping the defaults (as you say above) >for F34 unless the results come back in a way that gives us pause. > This is pretty much exactly how I would like this to happen. It has a schedule so it doesn't just slip while still being as cautious as one should be about fs changes. The only way that would make it even better is a clear definition of what severity of problem is needed to not implement as default in F34 and what happens then. This to avoid the inevitable discussion before F34. With this plan I have no problems. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 at 20:24, Susi Lehtola wrote: > > On Wed, 1 Jul 2020 19:28:53 +0200 > Iñaki Ucar wrote: > > I'm no expert, but the FAQ says: > > > > "You have a GPLed program that I'd like to link with my code to build > > a proprietary program. Does the fact that I link with your program > > mean I have to GPL my program? (#LinkingWithGPL) > > > > Not exactly. It means you must release your program under a license > > compatible with the GPL (more precisely, compatible with one or more > > GPL versions accepted by all the rest of the code in the combination > > that you link). The combination itself is then available under those > > GPL versions." > > > > So my understanding is that it's ok for a program to link to FlexiBLAS > > if its license is GPL-compatible, not necessarily GPL. But of course > > we would need confirmation from legal. > > The library is GPLv3 only > > https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release#license > > which already makes it incompatible with many GNU Licenses > > https://fedoraproject.org/wiki/Licensing:Main#GPL_Compatibility_Matrix With many? With GPLv2 only. But most interestingly, GPLv3 states: "Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require" Technically, there's nothing in FlexiBLAS that a BLAS/LAPACK application would require to work. These are designed to require BLAS/LAPACK, and FlexiBLAS just duplicates that interface and glues symbols together. Maybe I'm completely misunderstanding the sentence above, but GPL restrictions of course apply to any program that uses the FlexiBLAS API for profiling, etc., but not to those that just use the BLAS/LAPACK API. -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Tue, 30 Jun 2020 at 17:26, Adam Williamson wrote: > 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 and move to uefi only > > > supported boot which has been available on any common intel based x86 > > > platform since atleast 2005. > > > > Will you provide replacement for laptop I bought in 2013? Still has some > > use, runs Fedora 31 just fine. BIOS mode only. > > > > My other PC at home is BIOS mode only too. Sure, it is FX-6300 so quite > > old but with some hard drives and 16GB of ram it has a use. > > I'm also still using a laptop from 2010: > > > https://www.trustedreviews.com/reviews/sony-vaio-z-series-vpc-z11z9e-b-13-1in-laptop > > it has outlived one 'replacement' so far, and my 3.5 year old XPS 13 > (9360 gen) recently stopped booting so unless I can fix that, it will > have outlived two... > > it has no UEFI support either. > > HP EliteBook 8570p here. A perfectly capable machine, great for coding, allowing up to 16GB RAM. I wouldn't just wave off any machine from around 2010-2012, because many are quite sturdy and still useful. The other thing is virtualization as many have mentioned. It defaults to BIOS, because it Just Works. I think the idea to get rid of the legacy "burden" of BIOS is a good one in the long-term, but I don't think the ecosystem is ready for it yet :(. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 1.7.2020 17:17, Peter Robinson wrote: The use of legacy or uefi are changes that users have to manually change themselves in their bios from manufactures default settings. There is no tool that can do that for them or migrate those settings however users should be able to change this for hardware around 2010. The Installer would have to try to detect and make a choise sd-boot ( If settings equall UEFI ) or grub2 ( If setting not equals UEFI ) depending on it's results. grub2 supports UEFI, doesn't have to be sd-boot Javier already has provide the best path forward for now and that is for Anaconda to provide an sd-boot option in same/similar manner as extlinux exist today so people will have the option to chose to use sd-boot instead of GRUB. Those who want a simple modern bootloader will then have the ability to use it while those need or prefer a boot manager OS and all it bells and whistles it brings along with it can continue to use that. After what one or two releases of Fedora the idea of making sd-boot the default for EFI installs can be visited and or WG decide that for themselves. JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, Jul 01, 2020 at 08:48:57AM -0400, Stephen John Smoogen wrote: > > We have https://fedoraproject.org/wiki/Changes/DNF_Better_Counting, > > maybe this could be used to collect some statistics about the fs type > > too. > I am going to try and nix this one in the bud right here. DNF counting > is NOT the place to do this. Yeah -- that feature is explicitly limited. I know Christian is interested in an system-information-collection system developed by Endless Computing as presented at GUADEC ... was that just last year? Sometime. (What is time anyway?) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [EPEL] rpmconf question for EPEL7 on Amazon Linux 2
Dne 30. 06. 20 v 20:17 Christopher napsal(a): > 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 No, I was not aware of that :) > updated to python-3.7, whereas rpmconf has a direct dependency on > python(abi)=3.6. If it's possible to use '>=3.6' instead, and the > package maintainer is willing to update it so it works with python 3.7 > on Amazon Linux 2, that would be great for my use case. As other said, it is not as easy. Rebuild for EPEL will still put there python(abi)=3.6 You have two options: * contact Amazon, to put (and build) rpmconf into their extras * take rpmconf.src.rpm and build it localy for AL2. Fortunately, Mock has config for AL2 : mock -r amazonlinux-2-x86_64 rpmconf.src.rpm -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote: > Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34 > could be good option. I know technically it is already opt-in, but it's not > very visible or popular. We could make the btrfs option more prominent and > ask people to pick it if they are ready to handle potential fallout. I'm leaning towards recommending this as well. I feel like we don't have good data to make a decision on -- the work that Red Hat did previously when making a decision was 1) years ago and 2) server-focused, and the Facebook production usage is encouraging but also not the same use case. I'm particularly concerned about metadata corruption fragility as noted in the Usenix paper. (It'd be nice if we could do something about that!) Given the number of Fedora desktop users, even an increase of 0.1% in now-I-can't-boot situations would be a catastrophe. Is that a risk? I literally don't know. Maybe it's not -- but we've worked hard to get Fedora a reputation of being problem-free and something that leads without being "bleeding edge". It's a tricky balance. > Normally we just switch the default or we don't, without half measures. But > the fs is important enough and complicated enough to be extra careful about > any transitions. Exactly. Maybe we could add an "Automatically configure with btrfs (experimental)" option to the Installation Destination screen, and then feature that in Fedora Magazine and schedule a number of test days? To be clear, I'm not suggesting this as a blocking tactic. The assumption would be that we'd go ahead with flipping the defaults (as you say above) for F34 unless the results come back in a way that gives us pause. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [EPEL] rpmconf question for EPEL7 on Amazon Linux 2
On Wed, Jul 1, 2020 at 4:52 AM Nico Kadel-Garcia wrote: > > 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, whereas rpmconf has a direct dependency on > > python(abi)=3.6. If it's possible to use '>=3.6' instead, and the > > package maintainer is willing to update it so it works with python 3.7 > > on Amazon Linux 2, that would be great for my use case. > > You need to talk to Amazon. They have their own EPEL repository, > inconsistently forked from EPEL and enabled with the > "amazon-linux-extras" command, along with a variety of other > not-really-yum-repo-managed tools like mock and ansible. It's > problematic.. And don't let that incomplete EPEL channel get mixed > with the official EPEL repository in your configurations. Yeah, I noticed the same problem for rpmconf in both EPEL lines. Somehow, I don't think this is a problem Amazon is likely to prioritize. I'd probably be better off rebuilding rpmconf from source for my instance (using a modified EPEL SRPM). > > The time spent hunting for workarounds might be better spent migrating > to RHEL or CentOS, which is likely to be more compatible with Fedora > packages backported through EPEL. The decision to leapfrog to python > 3.7 was problematic, since it also puts them ahead of RHEL 8 and > CentOS 8's releases of python 3.6 and complicates EPEL support > profoundly. I would *love* to be using CentOS, but this is for an "Amazon Workspaces" instance, which only supports Amazon Linux 2 or Windows, because of the driver support needed for the PCoIP features inherent to the service. There are tons of other problems with Amazon Linux, too, such as the complete lack of USB support in the kernel... which makes forwarding USB devices over PCoIP (which is a supported feature) a completely useless feature. These problems don't exist in CentOS... but I'm stuck with the shitty Amazon instance I'm forced to use in my environment for now. Thanks for the suggestions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 at 20:13, Susi Lehtola wrote: > > On Wed, 1 Jul 2020 10:54:16 -0600 > Jerry James wrote: > > > On Wed, Jul 1, 2020 at 10:26 AM Iñaki Ucar > > wrote: > > > BTW, I would also like to discuss here, as part of this proposal, > > > which backend should be the system-wide default. I believe we all > > > would agree that OpenBLAS nowadays is the best choice. But then, the > > > serial or the openmp version? > > > > First, I want to make sure I understand the current openblas > > packaging. Is this correct? > > > > openblas-openmp: use if the application uses OpenMP > > Yes; then OpenBLAS calls get run in parallel in single-threaded regions > of the code, and if sequential mode in regions that are already > running parallel. > > > openblas-serial: use if the application is multithreaded > > openblas-threads: use if the application is single-threaded > > No, this is exactly the wrong way around. You should use the serial > library for code that you want to be running in serial (this way you > can get several instances of the program running efficiently), and the > pthreads version if you want to run the BLAS/LAPACK regions in parallel > (but are somehow opposed to OpenMP!).. I think I'm more confused than before. :D > > The question of the default is a hard one. What happens if a > > multithreaded application that does not use OpenMP is linked with the > > OpenMP build of OpenBLAS? > > Then you get too much parallellism, i.e. every call to OpenBLAS will > launch several threads, and this will naturally ruin your scaling. So would you say that openblas-serial is the most sensible system-wide default? -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 19:28:53 +0200 Iñaki Ucar wrote: > I'm no expert, but the FAQ says: > > "You have a GPLed program that I'd like to link with my code to build > a proprietary program. Does the fact that I link with your program > mean I have to GPL my program? (#LinkingWithGPL) > > Not exactly. It means you must release your program under a license > compatible with the GPL (more precisely, compatible with one or more > GPL versions accepted by all the rest of the code in the combination > that you link). The combination itself is then available under those > GPL versions." > > So my understanding is that it's ok for a program to link to FlexiBLAS > if its license is GPL-compatible, not necessarily GPL. But of course > we would need confirmation from legal. The library is GPLv3 only https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release#license which already makes it incompatible with many GNU Licenses https://fedoraproject.org/wiki/Licensing:Main#GPL_Compatibility_Matrix not to mention many other free licenses that are allowed in Fedora https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 10:54:16 -0600 Jerry James wrote: > On Wed, Jul 1, 2020 at 10:26 AM Iñaki Ucar > wrote: > > BTW, I would also like to discuss here, as part of this proposal, > > which backend should be the system-wide default. I believe we all > > would agree that OpenBLAS nowadays is the best choice. But then, the > > serial or the openmp version? > > First, I want to make sure I understand the current openblas > packaging. Is this correct? > > openblas-openmp: use if the application uses OpenMP Yes; then OpenBLAS calls get run in parallel in single-threaded regions of the code, and if sequential mode in regions that are already running parallel. > openblas-serial: use if the application is multithreaded > openblas-threads: use if the application is single-threaded No, this is exactly the wrong way around. You should use the serial library for code that you want to be running in serial (this way you can get several instances of the program running efficiently), and the pthreads version if you want to run the BLAS/LAPACK regions in parallel (but are somehow opposed to OpenMP!).. > The question of the default is a hard one. What happens if a > multithreaded application that does not use OpenMP is linked with the > OpenMP build of OpenBLAS? Then you get too much parallellism, i.e. every call to OpenBLAS will launch several threads, and this will naturally ruin your scaling. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
Neal Gompa writes: > Oh man, that takes me back! I started on DOS with the MS-DOS Editor, > then went onto the DOS port of Emacs and using DJGPP, then jumped to > Linux years later... Now *that* takes me back to the days when I wrote DJGPP ;-) And for anyone who thinks vi is hard to use, try the original ed (not edlin) on CP/M. IMHO the default editor should have the following characteristics: * arrow keys always move the cursor * insert, delete, and backspace always do what they say * ASCII keys always mean "add this character" (insert or overwrite) * Every other option should have an obvious hint on the screen, such as a menu bar or hotkey line, like: [F1] exit [F2] save [Ctrl-Z] undo [Ctrl-X] cut if it doesn't fit on one line, it's too complicated. (ed did the opposite of all those, btw ;) (nano seems to hit most of these, although it's two lines of hints and INSERT didn't do what I expected - and it wasn't obvious how to get out of the mode INSERT put me in) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
>EarlyOOM being a >userspace process that races with the memory-consuming processes and that >may end up not getting scheduled due to the very impending OOM condition >that it is trying to prevent. earlyoom consumes 1 MiB VmRSS and all memory is locked by mlockall(). earlyoom works pretty fast and selects victim in 5-50 ms even with intense swapping. >It is also unclear that it can prevent full OOM (both >RAM and swap completely full) It's clear: earlyoom forks pretty fast and well. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, Jul 1, 2020 at 5:49 AM Steven Whitehouse wrote: > > If the / and /home split is the main issue, then dm-thin might be an > alternative solution, and we should check to see if some of the issues > listed on the change page have been addressed. I'm copying in Jon for > additional comment on that. Are those btrfs benefits which are listed on > the change page in priority order? They are of equal priority, from the perspective of both feature owners and the working group, based on many months of discussion. Individual users definitely have their own priorities, that also vary. There is perhaps an emphasis on solving /home and / free space competition, because it is one of the most pernicious issues that really leaves users on an island to fend for themselves in order to resolve it. Importantly dm-thin doesn't fix this problem by avoiding it in the first place, which Btrfs does. On dm-thin, the user must still identify which file system is out of space, and grow the file system. Once file systems are either snapshot or over provisioned, the only arbiter of used and free space truth is the thin pool. File system sizes are virtual that currently CLI and GUI apps are unprepared to deal with. And that sets up a prerequisite solution before anything dm-thin based could be used, because having fantasy free space reporting is objectively a UX regression. The transparent compression feature is perhaps understated. It's configurable per directory and per file. That includes algorithm selection. A future feature includes configurable compression level in the XATTR. The simplest use case is selective compression of high value targets like /usr and flatpaks. Future feature ideas include user selection of directories, and UI that shows compression efficacy. Reflinks are permitted between Btrfs subvolumes, where neither reflinks nor hard links are possible between dm-thin snapshots. One use case is cheaply restoring individual files from snapshots. Also thin snapshots currently pin the file system journal inside, making them rather expensive in terms of space consumption, compared to Btrfs snapshots. Again, the cost of thin snapshots is only revealed by the thin pool, not the file system. Where as on Btrfs 'df' and friends are expected to properly report free space, and they do. Also, cgroup2 developers report that the IO isolation features of any file system are lost on anything device-mapper based. And while that work is in progress, it's not there yet. Integrity checking is highly valued by some and less by others. Considering that we know hardware isn't 100% reliable, and doesn't always report its own failures as expected, and hence why most file systems now at least checksum metadata, it's not persuasive to me that the data should be left unchecked, and corruption ought to be handled by user space somehow. > File system resize is mentioned there, but pretty much all local > filesystems support grow. Also, no use cases are listed for that > benefit. Windows and macOS support online shrink and grow for more than a decade. While it doesn't often come up on the desktop, if you don't have it and need it, it's aggravating. The typical use case today is to reprovision a system with an additional or eventual substitute OS, without first having to destroy another. I'd call it rare. But it's also essentially expected. The much more common use case is for systemd-homed for managing authentication and user homes, including when encrypted. It's not decided whether to integrate sd-homed but it supports multiple storage types. One of those storage types, LUKS on loop, does effectively depend on file system shrink capability. While the use case for Fedora is mainly single user, and to optimize for that case, it is not exclusively single user so the chosen solution shouldn't cause difficult regressions. And we get a number of free and used space knock on effects here if the file system can't do online shrink. Is lack of online shrink disqualifying? No, but having it significantly improves UX. So whether LUKS or future fscrypt/Btrfs encryption, this road points to Btrfs. Yes, we could drop LVM and go with one big file system, that too was discussed. The main knock on effect there is a significant minority of users want to do a clean install of Fedora from time to time while preserving user home. The installer permits this behavior with LVM layouts, and Btrfs by only requiring a new root subvolume be created for mounting at /. It doesn't mean Btrfs applies to 100% of Fedora use cases. No single layout does. But Btrfs consistently solves more problems than causing more knock on effects. This doesn't make the alternatives bad. It just leaves a variety of problems unsolved. That too isn't inherently bad or disqualifying, but it's an opportunity that begs for a more complete picture. >Shrink is more tricky, and can easily result in poor file > layouts, particularly if there are repeated grow/shrink operations, not >
Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
>10% and 5% to 1% and 0% Default values is already changed to 4% (but not more than 400 MiB) and 2% (but not more than 200 MiB). A nonzero threshold helps maintain disk cache and speeds up system recovery after correction. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-sphinx_rtd_theme update: comments requested
Le mercredi 01 juillet 2020 à 18:35 +0200, Miro Hrončok a écrit : > > Given the /usr/share font links in CSS won't work when the > documentation is > exposed via a webserver, I assume the docs are mostly intended to be > browsed > (possibly offline) from within Fedora anyway. It’s not that hard to expose /usr/share/fonts in a webserver (and pretty risk-free). However old IE browsers are a plague security-wise, it’s much better to remove IE workarounds than help users keep an insecure browser that does not work all that well on free software webapps. Also, making the browser walk a remote location is not good for performance and will have all kind of interesting effects in restricted networks Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, Jul 1, 2020 at 11:20 AM Iñaki Ucar wrote: > On Wed, 1 Jul 2020 at 19:03, Jerry James wrote: > > openblas-openmp: use if the application uses OpenMP > > openblas-serial: use if the application is multithreaded > > openblas-threads: use if the application is single-threaded > > > > I've always found the naming of the openblas packages to be confusing, > > so that may not be right. Somebody set me straight if so. > > The naming means (the same for BLIS): > > -serial: runs single-threaded. > -openmp: some parts use OpenMP. > -threads: runs multi-threaded. > > So it's a property of the OpenBLAS build, not a property of the > application. In fact, the serial version is not thread-safe unless you > activate a particular option at build time. We found that issue > recently and fixed it, and BTW the workaround was to switch to > openblas-openmp. I think the way the OpenBLAS wiki is written confuses me: https://github.com/xianyi/OpenBLAS/wiki/faq#multi-threaded It starts with "If your application is already multi-threaded", implying that the default case is suitable for a single-threaded application. The default would be USE_THREAD=1, which corresponds to the openblas-threads package. The wiki's remedy for an application that is multi-threaded is to build OpenBLAS with USE_THREAD=0 USE_LOCKING=1, which corresponds to the openblas-serial package. If the list I wrote above is wrong, I blame the wiki. > > The question of the default is a hard one. What happens if a > > multithreaded application that does not use OpenMP is linked with the > > OpenMP build of OpenBLAS? > > That combination is fine AFAIK. But I don't know whether the serial > version would perform better in that situation or not at all. > > I'll bother the FlexiBLAS maintainer about this. :) They use FlexiBLAS > as a research tool in high-performance computing, so maybe he knows > better about all these possible combinations. As long as the default can be overridden, it doesn't matter all that much, I think. It's probably best to pick the "safest" option as the default, although I confess that I'm not sure which one that is. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wed, 2020-07-01 at 16:32 +, Jóhann B. Guðmundsson wrote:
> On 1.7.2020 16:10, Solomon Peachy wrote:
> > 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 several years CSM/BIOS has
> > been
> > slowly bitrotting due to a lack of real testing, as the last few
> > Windows
> > releases have mandated use of UEFI for preinstalled systems, plus
> > the
> > EOLing of Windows 7 and (especially) XP.
>
> AMD is "strongly" recommending UEFI for the windows [1]
>
> So Apple dropped CSM in 2006
And Apple makes what percentage of the computers, used by Fedora users?
:)
>
> Intel in 2020
Which will only apply to new computers. Existing installs from 2017-
2019 will need to be supported for a long time. Like I said in a
different email, top tier PC manufacturers such as Dell and HP have
been selling PCs without Windows, configured in legacy mode by default
and that's probably what most people, who purchased them, use.
>
> AMD is against it's use
Only a recommendation, they aren't mandating it. What matters is what
PC manufacturers will actually ship. AMD doesn't have much control over
that, compared to Intel. But I suspect PC manufacturers will follow
Intel and move to UEFI only as well. But, once again, this is for new
systems. Systems, purchased in 2017-2019 aren't "legacy" and you can't
force people to reinstall their operating systems or risk losing their
data.
>
> Windows has moved on with the curve...
Only for new computers, sold with Windows preinstalled. Existing
Windows 10 installs are still supported. In fact, Fedora has dropped
i686 support before Windows. You can download the latest Windows 10 for
32-bit computers. They've only dropped 32-bit support for OEMs. But
anyhow 32-bit vs 64-bit is a whole different story, this is about the
bootloader.
Best regards,
Nikolay
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 at 18:39, Miro Hrončok wrote: > > 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 proper switching mechanism that > > currently Fedora lacks. > > > > ... > > > > == Scope == > > * Proposal owners: Modify the SPECs of the BLAS/LAPACK-dependent > > packages to build against FlexiBLAS instead of the current backend > > they are using. > > I wonder, given FlexiBLAS is released under GPL (and not LGPL), whether this > means we would need to change the licenses of all non-GPL packages that will > be > linked to FlexiBLAS to GPL. > > CCing legal. I'm no expert, but the FAQ says: "You have a GPLed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program? (#LinkingWithGPL) Not exactly. It means you must release your program under a license compatible with the GPL (more precisely, compatible with one or more GPL versions accepted by all the rest of the code in the combination that you link). The combination itself is then available under those GPL versions." So my understanding is that it's ok for a program to link to FlexiBLAS if its license is GPL-compatible, not necessarily GPL. But of course we would need confirmation from legal. -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Wed, 1 Jul 2020 at 13:14, Iñaki Ucar wrote: > > On Wed, 1 Jul 2020 at 18:54, Miro Hrončok wrote: > > > > On 01. 07. 20 18:33, Michael Catanzaro wrote: > > > On Wed, Jul 1, 2020 at 11:28 am, Michael Catanzaro > > > wrote: > > >> I have not much opinion on whether we should use this vs. nano. > > > > > > Actually, playing with it for an extra three minutes... it's *really* > > > nice. > > > > > > I know micro is not nearly as standard or popular as nano, but... this is > > > worth > > > serious additional consideration. > > > > I love micro. The problematic part is it's rather big. > > > > nano: 670 k > > micro: 4.7 M > > > > (sizes from repoquery --info) > > To be fair, we should add ncurses-libs and file-libs as dependencies: > 330 k + 570 k = 900 k more. But yes, micro is still bigger, as its > name suggests. :) > > > BTW My keyboard bindings for micro that resemble a standard (modern) > > terminal > > session more: > > https://gist.github.com/hroncok/f7bc01080e3b72320b858c437af92151 > > That's very useful, thanks! > On a side note.. I went looking to see if someone had an editor name smaller than nano. pico was the editor that nano replaces. femto is an editor on Apple phones written in javascript atto is an editor in the Moodle web app. there is a zepto which is at https://github.com/hughbarney/zepto (and also has an atto which is emacs like) https://github.com/hughbarney/zepto#comparisons-with-other-emacs-implementations gives size estimates from 3 years ago. that leaves yocto which is a different distribution.. and nothing is defined smaller than a yocto in the end, we should just probably choose something.. we can always change our minds in 6 months to something else. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
>If both RAM and swap go below 10% free, earlyoom issues SIGTERM to the process with the largest oom_score. If both RAM and swap go below 5% free, earlyoom issues SIGKILL Fedora's earlyoom package is provided with the changed default settings: ``` EARLYOOM_ARGS="-r 0 -m 4 -M 409600 --prefer '^Web Content$' --avoid '^(dnf|packagekitd|gnome-shell|gnome-session-c|gnome-session-b|lightdm|sddm|sddm-helper|gdm|gdm-wayland-ses|gdm-session-wor|gdm-x-session|Xorg|Xwayland|systemd|systemd-logind|dbus-daemon|dbus-broker|cinnamon|cinnamon-sessio|kwin_x11|kwin_wayland|plasmashell|ksmserver|plasma_session|startplasma-way|xfce4-session|mate-session|marco|lxqt-session|openbox)$'" ``` It means that: 1. SIGTERM threshold for MemAvailable is 4% (but not more than 400 MiB) and SIGKILL threshold for MemAvailable is 2% (but not more than 200 MiB) by default. The change was due to the fact that earlyoom tree was criticized for too aggressive thresholds by default, and this was taken into account. Please update description in the proposal. 2. Firefox's children processes "Web Content" gets +300 to its oom_score. It means that earlyoom will prefer to kill firefox tabs rather than entire browser. Similar behavior is already practiced in chromium and electron-based apps by default. 3. Processes, the killing of which can lead to the killing of the entire session (kwin_x11|kwin_wayland|plasmashell|ksmserver|plasma_session etc), receive reduced priority in choosing a victim. dnf also gets low prio. This is yet another advantage that you can mention in the proposal. see https://pagure.io/fedora-workstation/issue/119#comment-638366 вт, 30 июн. 2020 г. в 22:26, Ben Cotton : > 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 and swap go below 5% free, earlyoom issues SIGKILL > to the process with the largest oom_score. The idea is to recover from out > of memory situations sooner, rather than the typical complete system hang > in which the user has no other choice but to force power off. > > == Owner == > * Name: [[User:bcotton|Ben Cotton]] > * Email: bcot...@redhat.com > > == Detailed Description == > Shamelessly copied from Workstation, which did it in the last release: > > Certain workloads have heavy memory demands, quickly consume all of RAM, > and start to heavily page out to swap. (Heavy paging, is often called "swap > thrashing" for added descriptive effect, probably because it's noticeable > and annoying). Incidental swap usage is a good thing, it frees up memory > for active pages used by a process. Heavy swap usage quickly leads to a > very negative UX, because it's slow, even on modern SSDs. Due to installer > defaults, the swap partition is made the same size as available memory (at > install time), which can be huge. This just extends swap thrashing time. > > On the one hand, we want this resource hungry job to complete. On the > other hand, we want our system to be responsive while that other work is > going on. But once the GUI stutters or even comes to an apparent stand > still (hang), we're really wishing the kernel oom-killer would kick in and > free up memory, so we can start over (maybe using memory or thread limiting > options - which arguably should be more intelligently figured out, and that > too is a work in progress but beyond the scope of this feature). > > However, once in a heavy swap scenario, it's relatively common the system > gets stuck in it, where GUI interactivity is terrible to non-existent, and > also the kernel oom-killer doesn't trigger. From a certain point of view, > this is working as intended. The kernel oom-killer is concerned about > keeping the kernel running. It's not at all concerned about user space > responsiveness. > > Instead of the system becoming completely unresponsive for tens of > minutes, hours or days, this feature expects that an offending process > (determined by oom_score, same as the kernel oom-killer) will be killed off > within seconds or a few minutes. > > == Benefit to Fedora == > > KDE users will be able to take advantage of the benefits Workstation users > got from enabling earlyOOM in Fedora 32: > > * improved user experience by more quickly regaining control over one's > system, rather than having to force power off in low-memory situations > where there's aggressive swapping. Once a system becomes unresponsive, it's > completely reasonable for the user to assume the system is lost, but that > includes high potential for data loss. > * reducing forced poweroff as the main work around will increase data > collection, improving understanding of low memory situations and how to > handle them better > * earlyoom first sends SIGTERM to the chosen process, so it has a chance > of a proper shutdown, unlike the
[Bug 1852856] perl-Template-Toolkit depends on mod_perl, which eventually installs httpd
https://bugzilla.redhat.com/show_bug.cgi?id=1852856 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-EPEL-2020-b01f134c3e has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b01f134c3e -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Mi, 01.07.20 18:31, Gerd Hoffmann (kra...@redhat.com) wrote: > > > One problem with sd-boot is that the kernels must stay on the ESP, which > > > can be a problem for dual-boot installs (where Fedora has to run with > > > the existing ESP and can't just create one which is big enouth). > > > > Nah, that's not true. Hasn't been for quite a while. > > > > sd-boot checks for kernels in the ESP first, and then on a second > > partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR > > partition is simply a partition with type UUID > > bc13c2ff-59e6-4262-a352-b275fd6f7172. > > Ah, this is news to me. XBOOTLDR must be formated with a filesystem the > uefi firmware can read (i.e. vfat in practice) I assume? The spec doesn't strictly mandate that in the general case. I think it would still be wise to stick to vfat, given that this means all kind of firmware can easily read it, but if your boot loader/firmware can read something else that's OK too. > > sd-boot is uefi only, but it should work fine with any arch that is > > supported by uefi. > > Seems it isn't built for armhfp in Fedora (/usr/lib/systemd/boot/efi > doesn't exist ...). Hmm, I know that people build it on ARM, I guess we could enable that in Fedora too. I am not an ARM pro myself, not sure what happens there right now. Upstream sd-boot has support for UEFI ia32, x64, arm and aa64. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 at 19:03, Jerry James wrote: > > On Wed, Jul 1, 2020 at 10:26 AM Iñaki Ucar wrote: > > BTW, I would also like to discuss here, as part of this proposal, > > which backend should be the system-wide default. I believe we all > > would agree that OpenBLAS nowadays is the best choice. But then, the > > serial or the openmp version? > > First, I want to make sure I understand the current openblas > packaging. Is this correct? > > openblas-openmp: use if the application uses OpenMP > openblas-serial: use if the application is multithreaded > openblas-threads: use if the application is single-threaded > > I've always found the naming of the openblas packages to be confusing, > so that may not be right. Somebody set me straight if so. The naming means (the same for BLIS): -serial: runs single-threaded. -openmp: some parts use OpenMP. -threads: runs multi-threaded. So it's a property of the OpenBLAS build, not a property of the application. In fact, the serial version is not thread-safe unless you activate a particular option at build time. We found that issue recently and fixed it, and BTW the workaround was to switch to openblas-openmp. Potentially, you could run every version regardless of the application, but some combinations are clearly a no-go, like a threaded OpenBLAS in a threaded application. > The question of the default is a hard one. What happens if a > multithreaded application that does not use OpenMP is linked with the > OpenMP build of OpenBLAS? That combination is fine AFAIK. But I don't know whether the serial version would perform better in that situation or not at all. I'll bother the FlexiBLAS maintainer about this. :) They use FlexiBLAS as a research tool in high-performance computing, so maybe he knows better about all these possible combinations. -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20200701.n.0 changes
OLD: Fedora-Rawhide-20200630.n.0 NEW: Fedora-Rawhide-20200701.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 18 Dropped packages:1 Upgraded packages: 123 Downgraded packages: 0 Size of added packages: 61.88 MiB Size of dropped packages:541.47 KiB Size of upgraded packages: 2.89 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 104.82 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20200701.n.0.x86_64.vagrant-libvirt.box Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20200701.n.0.x86_64.vagrant-virtualbox.box = DROPPED IMAGES = = ADDED PACKAGES = Package: abcMIDI-2020.06.29-1.fc33 Summary: ABC to/from MIDI conversion utilities RPMs:abcMIDI Size:2.23 MiB Package: flexiblas-3.0.0-2.fc33 Summary: A BLAS/LAPACK wrapper library with runtime exchangeable backends RPMs:flexiblas flexiblas-atlas flexiblas-blis-openmp flexiblas-blis-openmp64 flexiblas-blis-serial flexiblas-blis-serial64 flexiblas-blis-threads flexiblas-blis-threads64 flexiblas-devel flexiblas-netlib flexiblas-netlib64 flexiblas-openblas-openmp flexiblas-openblas-openmp64 flexiblas-openblas-serial flexiblas-openblas-serial64 flexiblas-openblas-threads flexiblas-openblas-threads64 Size:30.20 MiB Package: ghc-cborg-json-0.2.2.0-1.fc33 Summary: A library for encoding JSON as CBOR RPMs:ghc-cborg-json ghc-cborg-json-devel ghc-cborg-json-doc ghc-cborg-json-prof Size:517.55 KiB Package: ghc-lukko-0.1.1.2-1.fc33 Summary: File locking RPMs:ghc-lukko ghc-lukko-devel ghc-lukko-doc ghc-lukko-prof Size:932.38 KiB Package: ghc-serialise-0.2.2.0-1.fc33 Summary: A binary serialisation library for Haskell values RPMs:ghc-serialise ghc-serialise-devel ghc-serialise-doc ghc-serialise-prof Size:3.14 MiB Package: golang-github-ory-dockertest-3.6.0-1.fc33 Summary: Support for ephermal Docker images for Go tests RPMs:golang-github-ory-dockertest-devel Size:181.65 KiB Package: golang-github-valyala-tcplisten-0-0.1.20200630gitceec8f9.fc33 Summary: Customizable TCP Listener RPMs:golang-github-valyala-tcplisten-devel Size:13.59 KiB Package: golang-goftp-server-0.3.4-1.fc33 Summary: FTP server framework written in Go RPMs:compat-golang-github-goftp-server-devel golang-goftp-server-devel Size:38.51 KiB Package: mesaflash-3.4.0-0.3.20200608git946725c.fc33 Summary: Configuration and diagnostic tool for Mesa Electronics boards RPMs:mesaflash Size:323.43 KiB Package: onednn-1.5-1.fc33 Summary: Deep Neural Network Library RPMs:onednn onednn-devel Size:5.74 MiB Package: php-composer-semver3-3.0.0-1.fc33 Summary: Semver library version 3 RPMs:php-composer-semver3 Size:26.65 KiB Package: python-adb-1.3.0-3.fc33 Summary: Python implementation of the Android ADB and Fastboot protocols RPMs:python3-adb Size:64.93 KiB Package: rust-osmesa-sys-0.1.2-1.fc33 Summary: OSMesa library bindings for Rust RPMs:rust-osmesa-sys+default-devel rust-osmesa-sys-devel Size:16.22 KiB Package: rust-servo-fontconfig-0.5.0-1.fc33 Summary: Rust bindings for fontconfig RPMs:rust-servo-fontconfig+default-devel rust-servo-fontconfig-devel Size:25.53 KiB Package: rust-servo-fontconfig-sys-5.0.2-1.fc33 Summary: Font configuration and customization library RPMs:rust-servo-fontconfig-sys+default-devel rust-servo-fontconfig-sys-devel Size:1.33 MiB Package: swappy-1.1.0-3.fc33 Summary: Wayland native snapshot editing tool, inspired by Snappy on macOS RPMs:swappy Size:191.37 KiB Package: theme-switcher-2.0.4-4.fc33 Summary: Switch dark/light GTK theme automatically during day/night RPMs:theme-switcher Size:575.17 KiB Package: xtb-6.3.1-5.fc33 Summary: Semiempirical Extended Tight-Binding Program Package RPMs:xtb xtb-devel xtb-libs Size:16.40 MiB = DROPPED PACKAGES = Package: drawtk-2.0-10.fc32 Summary: A C library to perform efficient 3D drawings RPMs:drawtk drawtk-devel Size:541.47 KiB = UPGRADED PACKAGES = Package: Lmod-8.3.17-1.fc33 Old package: Lmod-8.3.16-1.fc33 Summary: Environmental Modules System in Lua RPMs: Lmod Size: 1.05 MiB Size change: 758 B Changelog: * Wed Jun 24 2020 Orion Poplawski - 8.3.17-1 - Update to 8.3.17 Package: aqsis-1.8.2-37.fc33 Old package: aqsis-1.8.2-36.fc32 Summary: Open source 3D rendering solution adhering to the RenderMan standard RPMs: aqsis aqsis-core aqsis-data aqsis-devel aqsis-libs Size: 16.00 MiB Size change: -170.01 KiB Changelog: * Tue Jun 30 2020 Nicolas Chauvet - 1.8.2-37 - Fix FTBFS Package: asterisk-17.5.0-2.fc33.1 Old package: asterisk-17.4.0-2.fc33 Summary: The Open Source PBX RPMs: asterisk asterisk-ael
Re: The future of legacy BIOS support in Fedora.
> The use of legacy or uefi are changes that users have to manually change > themselves in their bios from manufactures default settings. There is no > tool that can do that for them or migrate those settings however users > should be able to change this for hardware around 2010. > > The Installer would have to try to detect and make a choise sd-boot ( If > settings equall UEFI ) or grub2 ( If setting not equals UEFI ) depending > on it's results. grub2 supports UEFI, doesn't have to be sd-boot > As an example here's the BIOS/UEFI history for Apple hardware. > > 2012 and older models only support legacy BIOS Mode > > 2013-2014 models support both EFI and BIOS with the default setting > being set on BIOS > > 2015 and later models only support EFI > > Different manufacturers have different timelines and different default > settings but I think it's safe to presume from this year onwards they > will all drop the legacy support and default to UEFI. Microsoft has been actively moving requirements to UEFI for some time to in both server and workstation side of things as well as other security improvements like the requirements for TPM2 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Wed, 1 Jul 2020 at 18:54, Miro Hrončok wrote: > > On 01. 07. 20 18:33, Michael Catanzaro wrote: > > On Wed, Jul 1, 2020 at 11:28 am, Michael Catanzaro > > wrote: > >> I have not much opinion on whether we should use this vs. nano. > > > > Actually, playing with it for an extra three minutes... it's *really* nice. > > > > I know micro is not nearly as standard or popular as nano, but... this is > > worth > > serious additional consideration. > > I love micro. The problematic part is it's rather big. > > nano: 670 k > micro: 4.7 M > > (sizes from repoquery --info) To be fair, we should add ncurses-libs and file-libs as dependencies: 330 k + 570 k = 900 k more. But yes, micro is still bigger, as its name suggests. :) > BTW My keyboard bindings for micro that resemble a standard (modern) terminal > session more: https://gist.github.com/hroncok/f7bc01080e3b72320b858c437af92151 That's very useful, thanks! -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Wed, Jul 1, 2020 at 6:42 pm, Miro Hrončok wrote: I love micro. The problematic part is it's rather big. nano: 670 k micro: 4.7 M (sizes from repoquery --info) rpm -qi micro says 16007158 bytes installed... that's 15.3 MiB, compared to nano at 2.5 MiB, and vim-minimal at 1.3 MiB. I've been reminded in IRC that micro was previously considered but passed over out of concern that this would be too much for containers. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Hi, > Also note that this entails a lot more work then just maintaining sd-boot, > anaconda will need to be adjusted, kernel-install scripts will need to > be adjusted, etc. And what about upgrades, if upgrades stick with using grub2 > then now we have 3 bootloader configs, including things like documentation on > how to change kernel commandline options, to maintain instead of 2. It is all there and working, except for the anaconda bits (as far I know there is no way to ask anaconda install sd-boot instead of grub2). If you wanna play with it qemu images (f31 only, no time yet for f32) are here: https://www.kraxel.org/repos/images/ The '-systemd' variants use sd-boot. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
On 01. 07. 20 18:28, Michael Catanzaro wrote: I notice that when I copy text it instructs me to "install xclip for external clipboard." That's not OK since xclip won't do anything in Wayland. Could be avoided by checking $DISPLAY before printing the message. See https://github.com/zyedidia/micro#linux-clipboard-support -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wed, 2020-07-01 at 16:30 +0200, Lennart Poettering wrote: > 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 have been pretty OK > with supporting it upstream and downstream. At least upstream I am > not > aware of any big issues left open. > > Note that sd-boot is a lot simpler than grub, i.e. it doesn't contain > Turing complete programming languages, module loaders, file system > drivers, storage stacks and such. There's simply not that much to > maintain! > > > Also note that this entails a lot more work then just maintaining > > sd-boot, > > anaconda will need to be adjusted, kernel-install scripts will need > > to > > be adjusted, etc. > > kernel-install itself is actually maintained in the same repo as > sd-boot: systemd upstream. They are developed along the same lines > already. > > > Also I wonder, if you are not proposing to completely drop grub2 on > > x86_64 what does offering sd-boot in addition to grub2 actually > > offer as advantages? > > Primarily simplicity, and that it implements the boot loader spec > correctly. > > it automatically discovers windows and Macos installations at each > boot, without any userspace involvement. You can talk to it very > nicely, i.e. implement trivially "boot-into-windows" buttons and such > in GNOME and so on. It makes things very robust, since you don't need > a script that generates a script that generates a script (yeah, > that's > how grub is hooked up). it just works on its own. You drop in boot > menu items, and that's it. You don't need to regenerate stuff, and > you > never have to run an interpretor for a turing complete language. > > By using sd-boot, you can do stuff like "systemctl reboot > --boot-loader-entry=windows", you can do "systemctl reboot > --boot-loader-menu=0", you can do "systemctl kexec" and it boots the > right thing, and so on. > > It also implements boot time assessement that is simple and just > works > (i.e. automatic revert to previous boot menu choice when the one > selected doesn't work). > > Oh, and it as support for seeding the Linux random seed pre-boot > already, in a safe and simple fashion. > > Moreover, it communicates which ESP is used to the host OS, so that > the host can automatically discover what other partitions to mount. > > And the list goes on and on and on. > > All these features are very simple individually, but put together > they > are just a much nicer and expose a much more integrated behaviour > than Grub ever did. > > > sd-boot is simpler and a bit tighter integrated with systemd, which > > would > > mean it is less work to maintain if we use it instead of grub, but > > if we > > use it next to grub then all those advantages fall away. IOW if we > > use > > it next to grub then all I see is a whole lot of extra work, with > > very > > little gain. > > Well, you appear to believe in the race to the bottom, i.e. that the > lowest common denominator should be where the future is. I am pretty > sure it's the wrong approach: pick the simple contender that can do > all the nice things, and has the nice integration, and use it as a > blueprint for the other archs where Grub is still needed, and make > them catch up. > > I mean, I understand you are interested in exotic platforms that lack > modern things like UEFI, but it kinda sucks to hold the boot loader > hostage due to that, and just stick to the terrible ways of > yesteryear > because of it. Note that this is not only about exotic platforms. I can give you examples with: 1. My 2019 HP laptop with an AMD Ryzen CPU. Purchased without Windows, so it came with FreeDOS preinstalled. Obviously, FreeDOS only runs in legacy mode. I just booted from an USB flash drive and installed Fedora on it, without changing the BIOS settings. 2. A 2017 Dell laptop, purchased also without Windows. Came with Ubuntu preinstalled, also in legacy mode. I installed Fedora on it, also without changing the BIOS settings. It's not unrealistic to expect that a lot of people would buy laptops such as these, if they specifically want to run Linux. And it's not unrealistic to expect many users to just install Fedora without changing any BIOS settings, related to legacy vs UEFI boot mode. In fact, most users wouldn't probably know anything about these settings. Both of these computers are very far away from being considered legacy or exotic. They can be switched to UEFI mode, but that requires repartitioning and an OS reinstall (and that gets very complicated when you consider multiboot scenarios with Windows 10 as well). Upgrading these systems without reinstall is possible, but *very* difficult and can't be automated, because, even if in the single OS scenario, it requires the user to change the
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, Jul 1, 2020 at 4:25 pm, Nicolas Mailhot via devel wrote: Actually this split is a godsend because you can convince anaconda to leave your home alone when reinstalling, while someone always seems too invent a new Fedora change that justifies the reformatting of /. Good luck dealing with user data the next time workstation (or any other group) feels the / filesystem should change, once you've put user data on the same mount point So for the avoidance of doubt: if the btrfs change is rejected, we are almost certain to put everything on the same mount point. We haven't approved this yet, but odds are very high IMO. The options we are seriously considering for our default going forward are (a) btrfs, (b) failing that, probably ext4 all one big partition without LVM, (c) less-likely, maybe xfs all one big partition without LVM. This is being discussed in https://pagure.io/fedora-workstation/issue/152 We have a high number of complaints from developers running out of space on / with plenty of space left on /home (happens to me all the time). The opposite scenario is a problem too. Separate mountpoints by default is just not a good default, sorry. Ensuring users don't run out of space due to bad partitioning is more important than keeping /home during reinstall IMO. But with btrfs, then /home will just be a subvolume so we can have our cake and eat it too. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, Jul 1, 2020 at 10:26 AM Iñaki Ucar wrote: > BTW, I would also like to discuss here, as part of this proposal, > which backend should be the system-wide default. I believe we all > would agree that OpenBLAS nowadays is the best choice. But then, the > serial or the openmp version? First, I want to make sure I understand the current openblas packaging. Is this correct? openblas-openmp: use if the application uses OpenMP openblas-serial: use if the application is multithreaded openblas-threads: use if the application is single-threaded I've always found the naming of the openblas packages to be confusing, so that may not be right. Somebody set me straight if so. The question of the default is a hard one. What happens if a multithreaded application that does not use OpenMP is linked with the OpenMP build of OpenBLAS? -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
On 01. 07. 20 18:33, Michael Catanzaro wrote: On Wed, Jul 1, 2020 at 11:28 am, Michael Catanzaro wrote: I have not much opinion on whether we should use this vs. nano. Actually, playing with it for an extra three minutes... it's *really* nice. I know micro is not nearly as standard or popular as nano, but... this is worth serious additional consideration. I love micro. The problematic part is it's rather big. nano: 670 k micro: 4.7 M (sizes from repoquery --info) BTW My keyboard bindings for micro that resemble a standard (modern) terminal session more: https://gist.github.com/hroncok/f7bc01080e3b72320b858c437af92151 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-sphinx_rtd_theme update: comments requested
On 01. 07. 20 17:37, Jerry James wrote:
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:
https://github.com/rpm-software-management/rpm/issues/1297
Nice! Thank you, Miro, I like what you've done. I'll wait to see the
resolution of your "tiny little problem" before doing anything more.
Well I think that before this is resolved, we can only add the requirement
manually to all the affected Fedora packages and check newly added packages
regularly.
Should the %{?python_provide...} line be removed? It seems to be
redundant with the new python dependency generator.
Yes, if this will not be backported (I assume it won't, my generator for example
only targets rawhide+).
I'm also thinking of purging all traces of html5shiv from the spec
file, and rewriting the reference to it in layout.html to something
like this:
{# JAVASCRIPTS #}
{%- block scripts %}
What do you think?
Given the /usr/share font links in CSS won't work when the documentation is
exposed via a webserver, I assume the docs are mostly intended to be browsed
(possibly offline) from within Fedora anyway. As such, I would be inclined to
simply drop the html5shiv part entirely, rather than pointing to a code that's
outside of Fedora's area of influence. Whoever wants to browse the docs online
will do it on readthedocs anyway.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Wed, Jul 1, 2020 at 11:28 am, Michael Catanzaro wrote: I have not much opinion on whether we should use this vs. nano. Actually, playing with it for an extra three minutes... it's *really* nice. I know micro is not nearly as standard or popular as nano, but... this is worth serious additional consideration. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 1.7.2020 16:10, Solomon Peachy wrote:
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 several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.
AMD is "strongly" recommending UEFI for the windows [1]
So Apple dropped CSM in 2006
Intel in 2020
AMD is against it's use
Windows has moved on with the curve...
JBG
1. https://www.amd.com/en/support/kb/faq/cpu-uefi-mode
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
> > One problem with sd-boot is that the kernels must stay on the ESP, which > > can be a problem for dual-boot installs (where Fedora has to run with > > the existing ESP and can't just create one which is big enouth). > > Nah, that's not true. Hasn't been for quite a while. > > sd-boot checks for kernels in the ESP first, and then on a second > partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR > partition is simply a partition with type UUID > bc13c2ff-59e6-4262-a352-b275fd6f7172. Ah, this is news to me. XBOOTLDR must be formated with a filesystem the uefi firmware can read (i.e. vfat in practice) I assume? > > Another problem is that grub2 covers more architectures than sd-boot. > > What is the plan for armhfp, ppc64, s390x? > > sd-boot is uefi only, but it should work fine with any arch that is > supported by uefi. Seems it isn't built for armhfp in Fedora (/usr/lib/systemd/boot/efi doesn't exist ...). > > IMHO a better preparation for deprecating BIOS would be to make new > > installs bootable with both BIOS and UEFI. Which isn't hard at least > > for the "[x] use all space" case where Fedora can partition the disk as > > it pleases: Use gpt. Create a bios boot partition, install grun-pc > > there. Create a ESP partition, install grub-efi there. Create a > > partition for the /boot filesystem. Have both grubs pick up BLS config > > from /boot/loader. > > My suggestion would be: don't standardize on boot loaders, standardize > on the boot loader spec. Using the above partition scheme probably works with sd-boot (instead of grub-efi) too if you tag /boot as XBOOTLDR. The point I was tring to make is that you can install fedora in a way that the disk can be booted in both bios and uefi mode. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
