Re: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
On Friday, July 3, 2020 3:00:48 AM CEST PGNet Dev wrote:
> https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516680-nginx/nginx.spec
There are things like:
%global forgeurl1 https://github.com/openresty/headers-more-nginx-module
%define _ctag1HEAD
%global commit1 %( git ls-remote %{forgeurl1} | grep %{_ctag1} | cut -f1 )
So basically it needs to have the /bin/git installed in the chroot (it is
not by default), and it needs to have the internet enabled at that time to
get the contents of %commitX.
So the alternative local mock command would be:
mock --buildsrpm --spec nginx.spec --enable-network
I'm not familiar with the %forge* macros, but I don't think it is expected
that you will add commands that need the Internet into the macro
definition. Simply do:
- %global commit1 %( git ls-remote %{forgeurl1} | grep %{_ctag1} | cut
-f1 )
+ %global commit1
Alternatively, if you really need the dynamic %commitX generator -- you
can use one of the Copr SCM methods to "generate" the spec file and bake
the _static_ %commitX one step before (before the package is imported into
the Copr DistGit).
> builds locally, on F32, via rpmbuild or mock build, from spec or srpm,
> with NO error. resulting rpms are installable, usable & pass testing.
I'm not sure how `/bin/git` got installed into your mock chroot, and how
it comes you have the Internet there.
> FAILED COPR BUILD
> copr-cli build nginx-mainline ~/rpmbuild/SPECS/nginx.spec
>
> https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516674-nginx/builder-live.log.gz
>
> The goal is to have the same spec generate the same Mock build,
> regardless of environment.
Already deleted.
> Do I need additional prep of the spec prior to submit? Something in my
> foregemeta/scm usage that's env-dependent? Something else I've missed?
Probably, see above.
Pavel
___
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: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-02 at 18:00 -0700, PGNet Dev wrote: > (i'd been discussing this issue with praiskup @ copr-devel/buildsys; > he suggested that I bring it here ...) > > This spec > > > https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516680-nginx/nginx.spec > > which uses forgemeta to pull multiple SCM sources, and uses some > git/bash scripting in %defines, > > builds locally, on F32, via rpmbuild or mock build, from spec or > srpm, with NO error. resulting rpms are installable, usable & pass > testing. > > submitting the _same_ spec to COPR for online build FAILS @, > supposedly, similar Mock build By default COPR does not allow you to use internet though it can be enabled in the project settings. > Here's a diff > > https://www.diffchecker.com/izjQYkUF > > comparing the log output of > > SUCCESSFUL LOCAL BUILD > mock --buildsrpm --spec=~/rpmbuild/SPECS/nginx.spec -- > sources=~/rpmbuild/SOURCES > cat build.log > > and > > FAILED COPR BUILD > copr-cli build nginx-mainline ~/rpmbuild/SPECS/nginx.spec > > https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516674-nginx/builder-live.log.gz > > The goal is to have the same spec generate the same Mock build, > regardless of environment. > > Why does the COPR build's Mock build stage fail? > > IIUC, mock builds _should_ be portable between mock envs, at least > for the same chroot. > > Do I need additional prep of the spec prior to submit? Something in > my foregemeta/scm usage that's env-dependent? Something else I've > missed? > > Or is there an issue with the Mock build env @ COPR? > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7+vesACgkQEV1auJxc Hh6few//fpCK/6V7F+7FWmo5l6e+kXJgtl3KZZfsusAo07ETto5meeOjZibjM13N 4adwQMY83uUJkD13jQwfWBzrcuK8ER6rhAGZ8SnTLKo7wrCWuvO2b2OBZxyXgaVW 1TcJzZsLLxEvBX1OPzYYlymyZSFfvePul6K1ByFLkYVpAn1xtYOCiB1QUT0BmX4m AQihgGJ7w0P8BY8f4crERM4U/pmxzBH6TeSMiTyq4JQSqfeloVvdFjzAiZ6MBp1Z rb+XtMhu6vu6ZYYYFf4bqPzYann5Bu8KGylhanuS+Tvvo9TmfKEQYz1Ec5XFkWwL wyw3QrlqcfllcX3zd3bgQYpPLuJST1PJho6Pv2lYyFVjhj8GC9kjXskm42CXeauz oF4D3m/Iz6kN+YQw/w+tg2BAnD+BOJVZaaI/T3dQIo2WE7fZVQ7fPCCtOkwiZYbc +eoBybumEFspShLKykoi5ENWbi3qA95qE69h+286btdgakKX+zv4RfMa2/k4jmMj r/Qohlph20mHJYJXf3VBO3Sng+pB2+fp2nhf46JE7OjcXefMMBuyja7ko7wBAMC1 vdfQc1ppCAQMvxxc+O17TNdP3f5sitzlf7J1XeiaPWHsPVv1XbZjnQTER7lYMYTy PqvDnoIEYfY2pVXHmvczYxeCGtbjA04bRPpmx1PLC1wZl2jcL/s= =KWRR -END 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: User experience issue on btrfs
On Sun, Jun 28, 2020 at 03:40:11PM -0600, Chris Murphy wrote: > Databases and VM images are things btrfs is bad at out of the box. > Most of this has to do with fsync dependency of other file systems. > Btrfs is equipped to deal with an fsync heavy world out of the box, > using treelog enabled by default. But can still be slow for some > workloads. Does this also impact mariadb databases? I've noticed that since reinstalling my machine with mediawiki installed, the performance of the wiki has dropped noticeably when the cache is cold (just loading the pages, not editing 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
[389-devel] 389 DS nightly 2020-07-03 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/03/report-389-ds-base-1.4.3.10-1.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
[Bug 1852622] perl-Astro-FITS-CFITSIO-1.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1852622 Orion Poplawski changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-07-03 02:38:01 -- 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 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-18fb909316 znc-1.8.1-1.el8 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3c9503ab68 libmp4v2-2.1.0-0.21.trunkREV507.el8 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f64e687c3f lynis-3.0.0-1.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c047cbdfd0 hostapd-2.9-4.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4d185f6e16 alpine-2.23-2.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-da42cd0f70 ngircd-26-3.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6e0d8564ec chromium-83.0.4103.116-3.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8e909a0e81 coturn-4.5.1.3-1.el8 2 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 bashmount-4.3.0-1.el8 blivet-gui-2.1.15-1.el8 certwatch-1.2-1.el8 check_postgres-2.25.0-1.el8 gnucobol-3.1-4.rc1.el8 netdata-1.23.1-1.el8 pgbouncer-1.13.0-2.el8 python-aiohue-2.2.0-2.el8 syslog-ng-3.23.1-2.el8 transmission-3.00-1.el8 Details about builds: bashmount-4.3.0-1.el8 (FEDORA-EPEL-2020-567924a4c4) A menu-driven bash script for mounting removable media Update Information: Update to upstream release 4.3.0 ChangeLog: * Thu Jul 2 2020 Jamie Nguyen - 4.3.0-1 - Update to upstream release 4.3.0 blivet-gui-2.1.15-1.el8 (FEDORA-EPEL-2020-82cc3846a3) Tool for data storage configuration Update Information: New upstream release 2.1.15 with multiple bugfixes ChangeLog: * Thu Jul 2 2020 Vojtech Trefny - 2.1.15-1 - Use "raw_device" instead of "slave" for getting LUKS backing device (vtrefny) - Update translation files (noreply) - Translated using Weblate (Chinese (Simplified)) (tiansworld) - POT file update (vtrefny) - Translated using Weblate (Hebrew) (sh.yaron) - Fix setting visibility for EncryptionChooser (vtrefny) - Make data paths in setup.py relative (vtrefny) - Add alternative paths to look for UI and CSS files (vtrefny) - Set default position of the main window to the center of the screen (vtrefny) - Correctly set data and metadata level when creating Btrfs volumes (vtrefny) - Grammar fix (sh.yaron) - Update translation files (noreply) - Translated using Weblate (Bengali (India)) (akarshan.biswas) - Translated using Weblate (Hebrew) (sh.yaron) - Update POT file before doing a release (vtrefny) - Added translation using Weblate (Bengali (India)) (akarshan.biswas) - Translated using Weblate (Hebrew) (sh.yaron) - Remove dependency on adwaita-icon-theme (vtrefny) - Add daily builds badge (jkonecny) - Use tests instead of COPR build in packit for PRs (jkonecny) - Use packit actions instead of commands (jkonecny) - Remove not needed packit configuration values (jkonecny) - Move packit general configuration to the top of .packit file (jkonecny) - Translated using Weblate (German) (mail) - Fix unlocking raw format LUKS devices in Anaconda (#1846517) (vtrefny) - Translated using Weblate (Portuguese (Brazil)) (lucas.af88) - Translated using Weblate (French) (julroy67) - Translated using Weblate (Portuguese (Brazil)) (noreply) - Translated using Weblate (Portuguese (Brazil)) (lucas.af88) - Update translation files (noreply) - Translated using Weblate (Turkish) (oguzersen) - Translated using Weblate (Ukrainian) (yurchor) - Translated using Weblate (Polish) (piotrdrag) - Translated using Weblate (Portuguese (Brazil)) (lucas.af88) - Translated using Weblate (Portuguese (Brazil)) (noreply) - Translated using Weblate (Portuguese (Brazil)) (lucas.af88) - Refactor checking for device resizability (vtrefny) - Update translation files (noreply) - Translated using Weblate (Italian) (alciregi) - Ellipse the device name using the GTK cell render (15699466+TownCube) - Fix names for icons in the password entry (vtrefny) - Try harder to load correct icon when applying actions (vtrefny) - Fix pylint failure when disabling found-_-in-module-class warning (vtrefny) - Fix ordering of the edit submenu in the context menu for devices (vtrefny) References: [ 1 ] Bug #1846517 - AttributeError: 'RawFormatDevice' object has no
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 688 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 430 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 427 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 137 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 77 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19d171a465 python34-3.4.10-5.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f33a36b2c4 python-httplib2-0.18.1-3.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c438b9fb89 lynis-3.0.0-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d749373a67 znc-1.8.1-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-af9b2ac861 alpine-2.23-2.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6ad4894c0c jbig2dec-0.12-5.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0078f6abc1 xpdf-3.04-10.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-af9c6001d1 ngircd-26-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5d348316dd chromium-83.0.4103.116-3.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-afd5c42fd6 coturn-4.5.1.3-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6949cf3502 xrdp-0.9.13.1-1.el7 1 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 barman-2.10-5.el7 check_postgres-2.25.0-1.el7 netdata-1.23.1-1.el7 pgbouncer-1.13.0-2.el7 Details about builds: barman-2.10-5.el7 (FEDORA-EPEL-2020-6ab1a3707c) Backup and Recovery Manager for PostgreSQL Update Information: Update SPEC file, make it build on Fedora/EPEL 8 with the latest Python 3 guidelines and on EPEL 7 using Python 2. ChangeLog: check_postgres-2.25.0-1.el7 (FEDORA-EPEL-2020-de7889bc6b) PostgreSQL monitoring script Update Information: Update to 2.25.0. Also build for RHEL 7 and 8. ChangeLog: netdata-1.23.1-1.el7 (FEDORA-EPEL-2020-3f994d0881) Real-time performance monitoring Update Information: Update from upstream ChangeLog: * Thu Jul 2 2020 Didier Fabert 1.23.1-1 - Update from upstream References: [ 1 ] Bug #1851012 - netdata-1.23.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1851012 pgbouncer-1.13.0-2.el7 (FEDORA-EPEL-2020-de15e180f6) Lightweight connection pooler for PostgreSQL Update Information: - Enable Systemd notify. - Update to 1.13.0 on RHEL/CentOS 6. ChangeLog: * Thu Jul 2 2020 Simone Caronni - 1.13.0-2 - Enable notify in systemd unit. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Thu, Jul 02, 2020 at 02:00:16PM -0700, John M. Harris Jr wrote: > If it doesn't have any reported CVEs, that's because nobody uses it. You may be right, but one can't have vulnerabilies in functionality that doesn't exist. (I find it hilarious that "small, simple, single-purpose" is suddenly a bad thing when it's in systemd's favor..) - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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
[Bug 1842917] Add perl-VM-EC2 to EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1842917 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2020-07-03 01:52:07 --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2020-63e20981ea has been pushed to the Fedora EPEL 7 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 1842921] Add perl-String-Approx to EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1842921 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2020-07-03 01:52:05 --- Comment #6 from Fedora Update System --- FEDORA-EPEL-2020-a27bb85c32 has been pushed to the Fedora EPEL 7 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 1842917] Add perl-VM-EC2 to EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1842917 Bug 1842917 depends on bug 1842921, which changed state. Bug 1842921 Summary: Add perl-String-Approx to EPEL7 https://bugzilla.redhat.com/show_bug.cgi?id=1842921 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- 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 1842892] Add perl-VM-EC2-Security-CredentialCache to EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1842892 Bug 1842892 depends on bug 1842917, which changed state. Bug 1842917 Summary: Add perl-VM-EC2 to EPEL7 https://bugzilla.redhat.com/show_bug.cgi?id=1842917 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- 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 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d2ea82902e python-httplib2-0.18.1-1.el6 1 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 pgbouncer-1.13.0-2.el6 Details about builds: pgbouncer-1.13.0-2.el6 (FEDORA-EPEL-2020-514e762788) Lightweight connection pooler for PostgreSQL Update Information: - Enable Systemd notify. - Update to 1.13.0 on RHEL/CentOS 6. ChangeLog: * Thu Jul 2 2020 Simone Caronni - 1.13.0-2 - Enable notify in systemd unit. * Fri May 29 2020 Fabian Affolter - 1.13.0-1 - Update to new upstream version 1.13.0 ___ 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
[Bug 1850424] perl-libwww-perl-6.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1850424 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-libwww-perl-6.46-1.fc3 |perl-libwww-perl-6.46-1.fc3 |3 |3 |perl-libwww-perl-6.46-1.fc3 |perl-libwww-perl-6.46-1.fc3 |2 |2 ||perl-libwww-perl-6.46-1.fc3 ||1 --- Comment #7 from Fedora Update System --- FEDORA-2020-b3f40b7ddd 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: The future of legacy BIOS support in Fedora.
On 2020-07-02 13:08, Peter Robinson wrote: I suppose "very good state" is a relative term, upstream hasn't seen a release since 2016 so is essentially "unmaintained", not sure it supports secure boot, probably has a bunch of CVEs (see point about maintenance). I think it only lives on in Fedora is because I think it's used for some (.iso?) install method, AFIACT it's eventually glued back together when it fails to build and is generally ignored. As "very good state" I meant that the subpackages contain everything needed, and the binaries work flawlessly for the above use cases. Before, in some cases I was forced to use binaries from the upstream tarball. I started to collect the sources (the upstream repo, various branches like [1]), Fedora patchset, the "dist-gits" from other distributions listed in Repology [2], bug trackers), and will try to give more informed answer to your questions once I manage to asemble something ala src-git with pair of branches (patches/applied) per distribution. Kind Regards, Alek [1] https://github.com/awalls-cx18/syslinux/commits/master [2] https://repology.org/project/syslinux/versions ___ 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: orphaned nuttcp
Nikos Mavrogiannopoulos 于2020年7月2日周四 下午8:17写道： > > Hi, > I've orphaned the nuttcp component. It is long time since I last used > it, and I do not plan updating it again. If you like networking tools > this may be a package for you! OKay, I am taking this. > > regards, > Nikos > ___ > 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 ___ 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 1850702] perl-Net-SFTP-Foreign-1.91 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1850702 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Net-SFTP-Foreign-1.91- ||1.fc32 Resolution|--- |ERRATA Last Closed||2020-07-03 01:18:30 --- Comment #4 from Fedora Update System --- FEDORA-2020-0b4a921457 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
[Bug 1847506] perl-Rose-DB-Object-0.819 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1847506 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Rose-DB-Object-0.819-1 ||.fc32 Resolution|RAWHIDE |ERRATA --- Comment #7 from Fedora Update System --- FEDORA-2020-1e2e3f3088 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
[Bug 1850424] perl-libwww-perl-6.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1850424 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-libwww-perl-6.46-1.fc3 |perl-libwww-perl-6.46-1.fc3 |3 |3 ||perl-libwww-perl-6.46-1.fc3 ||2 Resolution|--- |ERRATA Last Closed||2020-07-03 01:18:11 --- Comment #6 from Fedora Update System --- FEDORA-2020-a70875f2cb 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
mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
(i'd been discussing this issue with praiskup @ copr-devel/buildsys; he suggested that I bring it here ...) This spec https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516680-nginx/nginx.spec which uses forgemeta to pull multiple SCM sources, and uses some git/bash scripting in %defines, builds locally, on F32, via rpmbuild or mock build, from spec or srpm, with NO error. resulting rpms are installable, usable & pass testing. submitting the _same_ spec to COPR for online build FAILS @, supposedly, similar Mock build Here's a diff https://www.diffchecker.com/izjQYkUF comparing the log output of SUCCESSFUL LOCAL BUILD mock --buildsrpm --spec=~/rpmbuild/SPECS/nginx.spec --sources=~/rpmbuild/SOURCES cat build.log and FAILED COPR BUILD copr-cli build nginx-mainline ~/rpmbuild/SPECS/nginx.spec https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516674-nginx/builder-live.log.gz The goal is to have the same spec generate the same Mock build, regardless of environment. Why does the COPR build's Mock build stage fail? IIUC, mock builds _should_ be portable between mock envs, at least for the same chroot. Do I need additional prep of the spec prior to submit? Something in my foregemeta/scm usage that's env-dependent? Something else I've missed? Or is there an issue with the Mock build env @ COPR? ___ 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
Yeah I mean the general discussion, not you specifically. Thanks, Josef On Thu, Jul 2, 2020 at 8:38 PM Eric Sandeen wrote: > On 7/2/20 4:44 PM, Josef Bacik wrote: > > We're talking about this issue like it's reasonable that xfs and ext4 > are going to allow the user to get back a bunch of data they don't know is > ok or not. We're also talking about it like the user should be able to > carry on his happy merry way. In these cases the drive is dying and needs > to be shredded, and a new install needs to happen and a restore from > backups needs to happen. Is the btrfs failure much less user friendly? No > doubt about it. Is it any comfort at all when a user shows up and we say > "where are your backups" and they say "what backups?", no. But if we're > going to talk about this like ext4 and xfs are much better because they > give you the _appearance_ that your data is fine, that's a bit disingenuous. > > If I had talked about it like that, it would have been disingenuous. > > But I didn't; this was an investigation of resiliency to metadata > corruption, not data error detection, and to what degree metadata > corruption can render files or even entire filesystems unreachable after > normal administrative recovery efforts. > > -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 > ___ 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/2/20 4:44 PM, Josef Bacik wrote: > We're talking about this issue like it's reasonable that xfs and ext4 are > going to allow the user to get back a bunch of data they don't know is ok or > not. We're also talking about it like the user should be able to carry on his > happy merry way. In these cases the drive is dying and needs to be shredded, > and a new install needs to happen and a restore from backups needs to happen. > Is the btrfs failure much less user friendly? No doubt about it. Is it any > comfort at all when a user shows up and we say "where are your backups" and > they say "what backups?", no. But if we're going to talk about this like > ext4 and xfs are much better because they give you the _appearance_ that your > data is fine, that's a bit disingenuous. If I had talked about it like that, it would have been disingenuous. But I didn't; this was an investigation of resiliency to metadata corruption, not data error detection, and to what degree metadata corruption can render files or even entire filesystems unreachable after normal administrative recovery efforts. -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
[Bug 1846493] perl-Sereal-Decoder-4.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1846493 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Decoder-4.014-1 |perl-Sereal-Decoder-4.014-1 |.fc33 |.fc33 |perl-Sereal-Decoder-4.014-1 |perl-Sereal-Decoder-4.014-1 |.fc32 |.fc32 |perl-Sereal-Decoder-4.014-1 |perl-Sereal-Decoder-4.014-1 |.fc31 |.fc31 ||perl-Sereal-Decoder-4.014-1 ||.el8 --- Comment #14 from Fedora Update System --- FEDORA-EPEL-2020-7b41ac8c13 has been pushed to the Fedora EPEL 8 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 1846149] perl-Sereal-Encoder-4.012 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1846149 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Encoder-4.012-1 |perl-Sereal-Encoder-4.012-1 |.fc33 |.fc33 |perl-Sereal-Encoder-4.014-1 |perl-Sereal-Encoder-4.014-1 |.fc32 |.fc32 |perl-Sereal-Encoder-4.014-1 |perl-Sereal-Encoder-4.014-1 |.fc31 |.fc31 ||perl-Sereal-Encoder-4.014-1 ||.el8 --- Comment #21 from Fedora Update System --- FEDORA-EPEL-2020-7b41ac8c13 has been pushed to the Fedora EPEL 8 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 1846491] perl-Sereal-Encoder-4.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1846491 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Encoder-4.014-1 |perl-Sereal-Encoder-4.014-1 |.fc33 |.fc33 |perl-Sereal-Encoder-4.014-1 |perl-Sereal-Encoder-4.014-1 |.fc32 |.fc32 |perl-Sereal-Encoder-4.014-1 |perl-Sereal-Encoder-4.014-1 |.fc31 |.fc31 ||perl-Sereal-Encoder-4.014-1 ||.el8 --- Comment #14 from Fedora Update System --- FEDORA-EPEL-2020-7b41ac8c13 has been pushed to the Fedora EPEL 8 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 1846147] perl-Sereal-4.012 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1846147 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-4.012-1.fc33|perl-Sereal-4.012-1.fc33 |perl-Sereal-4.014-1.fc32|perl-Sereal-4.014-1.fc32 |perl-Sereal-4.014-1.fc31|perl-Sereal-4.014-1.fc31 ||perl-Sereal-4.014-1.el8 --- Comment #17 from Fedora Update System --- FEDORA-EPEL-2020-7b41ac8c13 has been pushed to the Fedora EPEL 8 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 1846490] perl-Sereal-4.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1846490 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-4.014-1.fc33|perl-Sereal-4.014-1.fc33 |perl-Sereal-4.014-1.fc32|perl-Sereal-4.014-1.fc32 |perl-Sereal-4.014-1.fc31|perl-Sereal-4.014-1.fc31 ||perl-Sereal-4.014-1.el8 --- Comment #14 from Fedora Update System --- FEDORA-EPEL-2020-7b41ac8c13 has been pushed to the Fedora EPEL 8 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 1846148] perl-Sereal-Decoder-4.012 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1846148 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Decoder-4.012-1 |perl-Sereal-Decoder-4.012-1 |.fc33 |.fc33 |perl-Sereal-Decoder-4.014-1 |perl-Sereal-Decoder-4.014-1 |.fc32 |.fc32 |perl-Sereal-Decoder-4.014-1 |perl-Sereal-Decoder-4.014-1 |.fc31 |.fc31 ||perl-Sereal-Decoder-4.014-1 ||.el8 --- Comment #22 from Fedora Update System --- FEDORA-EPEL-2020-7b41ac8c13 has been pushed to the Fedora EPEL 8 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
On Thu, 2020-07-02 at 21:37 +0300, Konstantin Kharlamov wrote: > On Thu, 2020-07-02 at 09:44 +0200, Florian Weimer wrote: > > * Konstantin Kharlamov: > > > > > FWIW, I was just thinking about it, and I came up with example you > > > may like which shows exactly why BTRFS is bad for HDD. Consider > > > development process. It includes rewriting source files over and > > > over: you do `git checkout foo` and files are overwritten, you > > > change a file in text editor, and it gets overwritten. And since > > > BTRFS is CoW, it will always write files to a new place. > > > > Editors that make a backup copy typically do not overwrite files in > > place. They rename the file to the backup location and then write the > > new file. > > > > git checkout unlinks changed files first, before writing them anew > > from scratch. > > > > A COW file system does not make a difference for these use cases > > because there is already COW at the application level. > > > > The GNU assembler truncates the output object file first. On XFS, > > that triggers relocation to a new file system location as well, even > > if the output file size (or contents) does not change. So that > > scenario is essentially COW as well today. > > Per my understanding what happens when you write a new file and delete an old > one is that a block that old file was taking gets freed. > > Then, if you copy the file again, file system should find a free block to > write this copy into. And this block likely would be the one that got freed > previously. > > So, well, it is indeed COW, but not the one BTRFS does. It's a COW that copies > a file back and forth between two blocks :) This is kinda HDD-friendly COW :) > > BTRFS on the other hand will not rewrite older block unless it's out of new > ones. Just to clarify: I do not claim this is how ext4 or xfs works. This simplistic explanation is just something obvious regarding how a non-COW fs would work, but of course there can be reasons for them to behave differently. If someone knows better, they're welcome. What I do know though, is how a COW FS works, because I did work a little with ZFS at dayjob. ___ 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 Fri, Jul 3, 2020 at 12:49 AM John M. Harris Jr wrote: > > On Thursday, July 2, 2020 3:47:00 PM MST Alexander Ploumistos wrote: > > On Fri, Jul 3, 2020 at 12:22 AM John M. Harris Jr > > wrote: > > > > > > > > > That's a link to the release announcement. If you follow the thread, > > > you'll find that I was provided a link to two bugzilla links are to meta > > > links to blockers, where the items that are blocking are not issues > > > preventing x86 systems from actually functioning. Source: My 5 remaining, > > > functional, F30 x86 systems. > > > > > > I had told you then what went wrong with the i686 SIG and since you > > had asked for open issues to work on in your free time, I gave you the > > links to the two trackers. I guess you haven't found the time to > > spare. > > None of the linked blockers are core packages, and some of them are outright > not designed to work on anything other than 64 bit. I really don't understand > how you can see that as justification. Even though both trackers still receive reports, many packagers just stopped bothering with i686, because there was little response and there were long-lasting breakages in rawhide. A distro arch is more than the kernel; what good is having a 32-bit kernel and nothing to run on it? See how many i686 bugs are closed as WONTFIX or INSUFFICIENT_DATA. ___ 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 On Thu, Jul 2, 2020 at 6:49 PM John M. Harris Jr wrote: >That's a link to the release announcement. Hardly the first time it was announced. It refers to x86_32 sig that was formed much earlier which itself was a response to an earlier warning that x86_32 support is going away unless people stepped up to support it. Feel free to look up the threads on that and read up on that history. There was plenty of time and opportunity for people to step in. Noone was interested enough AND had the time/skills to do it. What you earlier claimed was -> I asked for a list of issues that warranted > > ending 32 bit support while it still worked, and got nothing. This isn't true. You did get a response with links to bugs and your other claim that these systems worked perfectly isn't correct objectively. Rahul ___ 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 Thursday, July 2, 2020 3:47:00 PM MST Alexander Ploumistos wrote: > On Fri, Jul 3, 2020 at 12:22 AM John M. Harris Jr > wrote: > > > > > > That's a link to the release announcement. If you follow the thread, > > you'll find that I was provided a link to two bugzilla links are to meta > > links to blockers, where the items that are blocking are not issues > > preventing x86 systems from actually functioning. Source: My 5 remaining, > > functional, F30 x86 systems. > > > I had told you then what went wrong with the i686 SIG and since you > had asked for open issues to work on in your free time, I gave you the > links to the two trackers. I guess you haven't found the time to > spare. None of the linked blockers are core packages, and some of them are outright not designed to work on anything other than 64 bit. I really don't understand how you can see that as justification. -- 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 Fri, Jul 3, 2020 at 12:22 AM John M. Harris Jr wrote: > > That's a link to the release announcement. If you follow the thread, you'll > find that I was provided a link to two bugzilla links are to meta links to > blockers, where the items that are blocking are not issues preventing x86 > systems from actually functioning. Source: My 5 remaining, functional, F30 x86 > systems. I had told you then what went wrong with the i686 SIG and since you had asked for open issues to work on in your free time, I gave you the links to the two trackers. I guess you haven't found the time to spare. ___ 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.
Ok thought I had read somewhere that is was in the pipeline but had not merged. Must be old data. On Thu, Jul 2, 2020 at 5:34 PM Neal Gompa wrote: > > On Thu, Jul 2, 2020 at 6:24 PM Alex Thomas wrote: > > > > Question about systemd-boot vs GRUB2. > > One of the current stumbling blocks is the lack of LUKS2 support in > > GRUB2. Does sytemd-boot support LUKS2? > > GRUB2 supports LUKS2 in v2.06. sd-boot does not support it. > > > > -- > 真実はいつも一つ！/ 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 ___ 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 Thu, Jul 2, 2020 at 6:24 PM Alex Thomas wrote: > > Question about systemd-boot vs GRUB2. > One of the current stumbling blocks is the lack of LUKS2 support in > GRUB2. Does sytemd-boot support LUKS2? GRUB2 supports LUKS2 in v2.06. sd-boot does not support it. -- 真実はいつも一つ！/ 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.
Question about systemd-boot vs GRUB2. One of the current stumbling blocks is the lack of LUKS2 support in GRUB2. Does sytemd-boot support LUKS2? ___ 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 Thursday, July 2, 2020 3:09:14 PM MST Alexander Ploumistos wrote: > On Thu, Jul 2, 2020 at 10:54 PM John M. Harris Jr > wrote: > > > > > > On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote: > > > > > On 7/2/20 3:16 AM, nick...@gmail.com wrote: > > > > > > > > > > > > > Note that, even though Microsoft is pushing for UEFI on new systems > > > > in > > > > the OEM version of Windows, they still support booting in legacy BIOS > > > > mode in the latest Windows 10 version and they even support a 32-bit > > > > version of Windows 10, which Fedora no longer does > > > > ... > > > > I'm by no means a Microsoft fan, but these are facts. Fedora is > > > > pushing > > > > for hardware obsolescence faster than Microsoft in this regard.:( > > > > > > > > > > > > > > > > > > I think that as far as 32-bit support is concerned, the issue was less > > > that Fedora pushed for "hardware obsolescence" and more that no one > > > "pushed" for support. Fedora is a collection of the work of > > > volunteers, > > > and supporting 32-bit hardware requires more than simply sending SRPMs > > > through the build pipeline. Things break, and over time there were > > > fewer volunteers willing and able to fix those problems. The way I > > > remember it, there were plenty of statements to the effect that as long > > > as someone was willing to do that work, Fedora would continue to > > > publish > > > a 32-bit release. > > > > > > > > > > > > That doesn't strictly apply to discussions about dropping BIOS boot > > > support, but that doesn't look like it will happen any time soon. > > > > > > > > That's not really true. When it came down to it, it was dropped while 32 > > bit Fedora still worked perfectly. I'm left with 5 systems that will > > never be updated as a result. I asked for a list of issues that warranted > > ending 32 bit support while it still worked, and got nothing. > > > That's certainly not true: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ > thread/MVOBCE4G7DKZ56CQXF3B53WXF7LXHYXJ/ That's a link to the release announcement. If you follow the thread, you'll find that I was provided a link to two bugzilla links are to meta links to blockers, where the items that are blocking are not issues preventing x86 systems from actually functioning. Source: My 5 remaining, functional, F30 x86 systems. -- 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 Thu, Jul 2, 2020 at 10:54 PM John M. Harris Jr wrote: > > On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote: > > On 7/2/20 3:16 AM, nick...@gmail.com wrote: > > > > > Note that, even though Microsoft is pushing for UEFI on new systems in > > > the OEM version of Windows, they still support booting in legacy BIOS > > > mode in the latest Windows 10 version and they even support a 32-bit > > > version of Windows 10, which Fedora no longer does > > > ... > > > I'm by no means a Microsoft fan, but these are facts. Fedora is pushing > > > for hardware obsolescence faster than Microsoft in this regard.:( > > > > > > > > I think that as far as 32-bit support is concerned, the issue was less > > that Fedora pushed for "hardware obsolescence" and more that no one > > "pushed" for support. Fedora is a collection of the work of volunteers, > > and supporting 32-bit hardware requires more than simply sending SRPMs > > through the build pipeline. Things break, and over time there were > > fewer volunteers willing and able to fix those problems. The way I > > remember it, there were plenty of statements to the effect that as long > > as someone was willing to do that work, Fedora would continue to publish > > a 32-bit release. > > > > That doesn't strictly apply to discussions about dropping BIOS boot > > support, but that doesn't look like it will happen any time soon. > > That's not really true. When it came down to it, it was dropped while 32 bit > Fedora still worked perfectly. I'm left with 5 systems that will never be > updated as a result. I asked for a list of issues that warranted ending 32 bit > support while it still worked, and got nothing. That's certainly not true: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MVOBCE4G7DKZ56CQXF3B53WXF7LXHYXJ/ ___ 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/2/20 4:38 PM, Eric Sandeen wrote: On 7/1/20 12:50 PM, Chris Murphy wrote: ... 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. There's a flip side to this coin - in my experience, if the right btrfs metadata blocks experience this disk corruption, there can be a complete inability to recover the btrfs filesystem from that error - i.e. it won't mount, and btrfsck --repair won't get it to a mountable state. So if we're saying disk corruption happens often enough that data checksumming is critical, then it happens often enough that metadata recovery is at least as critical. I've been trying to quantify this and have not come up with a particularly compelling test scenario, because it involves purposefully (though at random) corrupting enough blocks on a filesystem image that a critical block gets hit, so it looks synthetic. But the net result is frequently a filesystem where btrfsck and/or mount fails, and at first blush this type of failure happens much more often than on other filesystems.[1] I think Josef has alluded to this situation as well. To me, that's a big concern. Not trying to be a wet blanket here but I think this needs to be carefully investigated and evaluated to understand what impact it may have on Fedora btrfs users and their ability to recover their data in the face of metadata corruption, because it looks to me like a definite btrfs weak spot. Yeah this is what I've said many times over the last 3 weeks. Btrfs is more vulnerable to metadata corruption. Now there's things that we can do to mitigate this. I have one patch up to handle one of the main cases (a corrupt global tree). The next patch set will be to keep entire metadata tree's around for longer as long as we have space to handle it. These two things will drastically improve the situation, but of course if I'm being evil we can still end up in a bad spot. These patches are not hard or controversial, they'll likely land in 5.9 which will be what F33 ships with (if I'm doing my math right). And this sort of ignores the other side of the coin. fsfuzzer isn't just corrupting metadata, it's corrupting data. Btrfs is the only file system that's going to notice that and let the user know. Checksumming is great because it lets the user know things are going wrong before they go catastrophically wrong. However just because we know something went wrong doesn't mean we can do anything about it, it just means that the user knows now that they need to restore from backups and find a new drive. These features do not mean you are absolved of good practices. If you care about data, you need to have it in multiple places. End of story. Btrfs is just going to let you know in advance that things are going wrong. We're talking about this issue like it's reasonable that xfs and ext4 are going to allow the user to get back a bunch of data they don't know is ok or not. We're also talking about it like the user should be able to carry on his happy merry way. In these cases the drive is dying and needs to be shredded, and a new install needs to happen and a restore from backups needs to happen. Is the btrfs failure much less user friendly? No doubt about it. Is it any comfort at all when a user shows up and we say "where are your backups" and they say "what backups?", no. But if we're going to talk about this like ext4 and xfs are much better because they give you the _appearance_ that your data is fine, that's a bit disingenuous. "Well what if it was just /usr." Sure, then you got lucky and you could copy things off. But what if it wasn't? That's the measure that's being applied to btrfs here. Is it likely that random corruption is going to be so bad that you end up with an unmountable file system? It's about as likely that the random corruption is on your dissertation or your family photographs. The difference is that btrfs will tell you that your dissertation or your family photographs are now bad, whereas ext4 and xfs will not. These are tradeoffs no doubt. Every file system choice is a series of trade offs. We're arguing/optimizing for the narrowest usecase. Arguments can be made either way, but in the end is it important enough to not move ahead with btrfs? 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:
[EPEL-devel] Re: [Fedocal] Reminder meeting : EPEL Steering Committee
Due to US holidays, and others on vacation, this weeks EPEL Steering Committee Meeting has been canceled. On Thu, Jul 2, 2020 at 2:00 PM wrote: > > Dear all, > > You are kindly invited to the meeting: >EPEL Steering Committee on 2020-07-03 from 21:00:00 to 22:00:00 UTC >At freenode@fedora-meeting > > The meeting will be about: > This is the weekly EPEL Steering Committee Meeting. > > A general agenda is the following: > > #meetingname EPEL > #topic Intros > #topic Old Business > #topic EPEL-6 > #topic EPEL-7 > #topic EPEL-8 > #topic Openfloor > #endmeeting > > > > > Source: https://apps.fedoraproject.org/calendar/meeting/9722/ > > ___ > 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 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
Re: The future of legacy BIOS support in Fedora.
On 7/2/20 3:42 PM, John M. Harris Jr wrote: GRUB2, which is a UEFI bootloader as well, is a far superior bootloader to systemd-bloat, and it supports usecases that are supported by Anaconda (the Fedora installer framework) that systemd-bloat doesn't, as addressed elsewhere in this thread by myself and several others. There is no way that supporting BIOS can be a cause for UEFI feature development being "held back". It's got nothing to do with UEFI stuff. Again with "systemd-bloat"... I guess I don't see how something that is responsible for booting the system, taking on more responsibility for booting the system, could ever be argued to be bloat? How is GRUB2 superior? I would like to see a list of pros, or alternatively, a list of things systemd-boot doesn't do. I see plenty of discussion in this thread about things not supporting UEFI, but not things that only GRUB2 can do (except boot both UEFI and BIOS machines). As for systemd-boot advantages: 1) It is simpler to configure and interact with from a running system than GRUB2 2) Supports seeding entropy generation before the Linux boot process proceeds 3) Can integrate easily with Gnome, other DEs 4) Has boot assessment, which could potentially integrate nicely with the ability to boot into a read-only recovery type mode that's been proposed[0] 5) Has hooks for automatically booting a newly installed kernel systemd-boot disadvantages: 1) No BIOS support 2) Ugly 3) Boot counting support doesn't seem real configurable? It only reverts to a previous kernel. 4) Additional testing / maintenance burden until BIOS is dropped completely 5) Limited boot entry templating ability 0 - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NZ7UVG4TA4GWNDOIUQGK3UD4B5ZUKWUJ/ ___ 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/2/20 3:58 PM, José Abílio Matos wrote: > On Thursday, 2 July 2020 21.38.46 WEST Eric Sandeen wrote: >> 3 files in lost+found, -1 files gone/unreachable > > This last line from the xfs test seems suspicious (the -1 file gone). :-) It is weird, but it shows I didn't fudge the numbers ;) directory repair may have inadvertently created a file or something, not sure. -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: The future of legacy BIOS support in Fedora.
On 02/07/20 07:08 -0500, Brandon Nielsen wrote: On 7/2/20 12:55 AM, John M. Harris Jr wrote: 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? Can you please stop calling features of systemd you don't like "systemd-bloat" at every given opportunity? It is not being respectful to those who work on the project and doesn't help your argument. Seconded. Please stop 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.
HI On Thu, Jul 2, 2020 at 4:54 PM John M. Harris Jr > That's not really true. When it came down to it, it was dropped while 32 > bit > Fedora still worked perfectly. I'm left with 5 systems that will never be > updated as a result. I asked for a list of issues that warranted ending 32 > bit > support while it still worked, and got nothing. Two weeks after the > proposal, > the announcement was made, and support was dropped. > This is just not true at all. 32-bit was bitrotting and community support didn't pan out https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels "This was last proposed with Fedora 27, but it was deferred as an i686 SIG was to be created to handle issues going forward. That SIG has been largely unresponsive." Rahul ___ 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
sd-boot vs. grub (WAS: The future of legacy BIOS support in Fedora.)
On Thu, Jul 2, 2020 at 6:01 AM Neal Gompa wrote: > > Here's the thing: systemd-boot is very good at what it does. The > Gummiboot project was a great demonstration of a nice, simple boot > manager. Kay decided to fold it into the systemd project, which is > fine. It has benefited from the tighter integration with tools like > systemctl. > > I have two problems with sd-boot: > > 1. It is absolutely butt-ugly. > 2. It is absolutely horrible for people who need to navigate this "by > surprise". > I don't disagree with either of those points, but I'm frustrated with grub due to this: grub2-editenv: Error: Environment-Block is too small https://bugzilla.redhat.com/show_bug.cgi?id=1625124 It should be trivial for a decent C programmer to come up with some logic to fix this. Something like: if < 1024 bytes but the last character is a # (after excluding white space or newlines) -> Adjust (pad) to 1024 bytes. If > 1024 bytes and the 1024th bit is a #, then truncate to the correct length. But this BZ has been open since 2018. I like the simplicity of sd-boot and it was the only way I could get my MS Surface GO to boot Fedora. For whatever reason it refuses to cooperate with grub2. I opted for a 1GB vfat partition and used it as /boot. Thanks, Richard ___ 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
On Wednesday, July 1, 2020 10:44:03 AM MST Alexey Avramov wrote: > >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. Sorry, that wasn't meant to be taken seriously, and I should have clarified. My actual suggestion is, "If it's going to be forced to be installed, it should be disabled so it doesn't kill our software." -- 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 Thursday, July 2, 2020 7:50:25 AM MST Solomon Peachy wrote: > On Thu, Jul 02, 2020 at 02:07:17PM -, Ivan Ivanov wrote: > > hopefully those which don't have a SystemD security-vulnerable > > bloatware > > Oh, FFS. > > In this comparison, grub2 is the _highly_ bloated, > everything-AND-the-kitchen-sink solution with multiple CVEs under its > belt, and systemd-boot is the lean, tightly-focused do-only-one-thing > tool without any reported CVEs. > > (seriously, the most recent systemd tarball is over 2.5MB smaller than > the most recent grub2 tarball) > > - Solomon If it doesn't have any reported CVEs, that's because nobody uses it. -- 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] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2020-07-03 from 21:00:00 to 22:00:00 UTC At freenode@fedora-meeting The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-6 #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9722/ ___ 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
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Thursday, 2 July 2020 21.38.46 WEST Eric Sandeen wrote: > 3 files in lost+found, -1 files gone/unreachable This last line from the xfs test seems suspicious (the -1 file gone). :-) -- José Abílio ___ 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 Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote: > On 7/2/20 3:16 AM, nick...@gmail.com wrote: > > > Note that, even though Microsoft is pushing for UEFI on new systems in > > the OEM version of Windows, they still support booting in legacy BIOS > > mode in the latest Windows 10 version and they even support a 32-bit > > version of Windows 10, which Fedora no longer does > > ... > > I'm by no means a Microsoft fan, but these are facts. Fedora is pushing > > for hardware obsolescence faster than Microsoft in this regard.:( > > > > I think that as far as 32-bit support is concerned, the issue was less > that Fedora pushed for "hardware obsolescence" and more that no one > "pushed" for support. Fedora is a collection of the work of volunteers, > and supporting 32-bit hardware requires more than simply sending SRPMs > through the build pipeline. Things break, and over time there were > fewer volunteers willing and able to fix those problems. The way I > remember it, there were plenty of statements to the effect that as long > as someone was willing to do that work, Fedora would continue to publish > a 32-bit release. > > That doesn't strictly apply to discussions about dropping BIOS boot > support, but that doesn't look like it will happen any time soon. That's not really true. When it came down to it, it was dropped while 32 bit Fedora still worked perfectly. I'm left with 5 systems that will never be updated as a result. I asked for a list of issues that warranted ending 32 bit support while it still worked, and got nothing. Two weeks after the proposal, the announcement was made, and support was dropped. -- 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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 2020-07-01 23:04, Michael Catanzaro wrote: On Wed, Jul 1, 2020 at 11:01 pm, Roberto Ragusa wrote: 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). Leaving space unallocated doesn't gain us anything because the user still has to manually resize both logical volumes and the partitions inside them. Our default needs to be something that doesn't require users to resize partitions. But those are things that can be done in a few seconds with one or two commands. Attempts to make easy things easier lead to making other things difficult: some not so inexperienced users will find themselves with their disk having only one big partition, no LVM, everything inside (system+data) and trying to decipher the suggestion found on a forum "with btrfs you can sort of format / without losing /home even if you do not have separate partitions". -- 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 Thursday, July 2, 2020 1:30:41 PM MST Brandon Nielsen wrote: > On 7/2/20 3:19 PM, Martin Jackson wrote: > > > > > > >> 5-10 years? A better estimate would be 15-20 years. People aren't > >> going to > >> throw away perfectly fine systems and jump to new "cloud" platforms just > >> because the OS they were using dropped BIOS support. They'll just stop > >> updating, and likely move to something that is still supporting BIOS, > >> if they > >> don't write their own installer and just continue using Fedora, given > >> that > >> this is an entirely artificial limitation. > >> > >> > >> > > While I completely hear you on the fact that people will often sweat > > assets for years longer than accounting schedules suggest they should, > > do you really think they're going to write custom installers??? I think > > it's far more likely that they would move to other distros more amenable > > to supporting the hardware they have. > > > > There are many distros that cater to this kind of market already, some > > by design and some by inclination.?? I don't think we want to drive them > > there. > > > > For what it's worth, I do not think that removing legacy BIOS support > > from Fedora is the right thing to do.?? I don't see significant benefit, > > and I see lots of potential harm. > > > > Thanks, > > > > Marty > > > I don't think removing BIOS support _today_ is the right answer either. > I have BIOS only hardware kicking around, and quite a bit of my UEFI > hardware still supports legacy BIOS booting as well (though I don't use > it). > However, I'm concerned about UEFI feature development / quality > assurance being held hostage by BIOS support for, based on above > comments, 5 to 20 years? Surely as a somewhat leading-edge distribution, > we need to start thinking about some kind of post-BIOS world. > > Perhaps one small step toward that future would be enabling systemd-boot > on new UEFI installs, relegating GRUB2 to BIOS and upgrade installs > only? This split configuration could hang around until support for GRUB2 > / BIOS wanes to the point it can no longer stand under its own weight > (much like 32bit install media). GRUB2, which is a UEFI bootloader as well, is a far superior bootloader to systemd-bloat, and it supports usecases that are supported by Anaconda (the Fedora installer framework) that systemd-bloat doesn't, as addressed elsewhere in this thread by myself and several others. There is no way that supporting BIOS can be a cause for UEFI feature development being "held back". It's got nothing to do with UEFI stuff. -- 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 Thursday, July 2, 2020 1:19:22 PM MST Martin Jackson wrote: > > 5-10 years? A better estimate would be 15-20 years. People aren't going > > to > > throw away perfectly fine systems and jump to new "cloud" platforms just > > because the OS they were using dropped BIOS support. They'll just stop > > updating, and likely move to something that is still supporting BIOS, if > > they don't write their own installer and just continue using Fedora, > > given that this is an entirely artificial limitation. > > > > > > While I completely hear you on the fact that people will often sweat > assets for years longer than accounting schedules suggest they should, > do you really think they're going to write custom installers??? I think > it's far more likely that they would move to other distros more amenable > to supporting the hardware they have. > > There are many distros that cater to this kind of market already, some > by design and some by inclination.?? I don't think we want to drive them > there. > > For what it's worth, I do not think that removing legacy BIOS support > from Fedora is the right thing to do.?? I don't see significant benefit, > and I see lots of potential harm. Considering that a custom installer for Fedora could just be a bash script that partitions disks, then runs `dnf`, then grub2-install.. It's not out of the question. I've considered it myself, so that I could install to root on ZFS without hacky kickstarts, for example. -- 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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/1/20 12:50 PM, Chris Murphy wrote: ... > 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. There's a flip side to this coin - in my experience, if the right btrfs metadata blocks experience this disk corruption, there can be a complete inability to recover the btrfs filesystem from that error - i.e. it won't mount, and btrfsck --repair won't get it to a mountable state. So if we're saying disk corruption happens often enough that data checksumming is critical, then it happens often enough that metadata recovery is at least as critical. I've been trying to quantify this and have not come up with a particularly compelling test scenario, because it involves purposefully (though at random) corrupting enough blocks on a filesystem image that a critical block gets hit, so it looks synthetic. But the net result is frequently a filesystem where btrfsck and/or mount fails, and at first blush this type of failure happens much more often than on other filesystems.[1] I think Josef has alluded to this situation as well. To me, that's a big concern. Not trying to be a wet blanket here but I think this needs to be carefully investigated and evaluated to understand what impact it may have on Fedora btrfs users and their ability to recover their data in the face of metadata corruption, because it looks to me like a definite btrfs weak spot. -Eric [1] some details - I used the mangle.c fuzzer from fsfuzzer, and modified it so that it corrupts 8192 bytes of an image, which in fs terms can be up to 8192 filesystem blocks. I also avoided the first 4k so that any filesystem signature was not damaged. I then ran a loop where I created a 1G base image, populated it, fuzzed it in this way, (so up to 3% of blocks were damaged) and ran the filesystem's fsck utility (in btrfs' case, btrfsck --repair) and then tried to mount (in btrfs' case, with bare mount, then -o usebackuproot if mount failed). If it mounted, I used "find | wc" to see how many files were reachable vs the original image. If either fsck or mount reports an exit code that reflects failure to complete properly, I recorded that. It was a quick hack, and it's not beautiful, so there are probably holes to be poked in it; if you want to look, I threw the bash script and the C source up at https://people.redhat.com/esandeen/fsckfuzzer/ Running 10 loops on each of btrfs, ext4, and xfs I got results that look like this (ext4 always creates empty lost+found so it will always find at least 1 file there) btrfs fsck failed 0 files in lost+found, 628 files gone/unreachable 0 files in lost+found, 0 files gone/unreachable 526 files in lost+found, 9 files gone/unreachable 595 files in lost+found, 55 files gone/unreachable 53 files in lost+found, 8 files gone/unreachable 57 files in lost+found, 44 files gone/unreachable fsck failed 7 files in lost+found, 1491 files gone/unreachable fsck failed, mount failed fsck failed, mount failed 88 files in lost+found, 40 files gone/unreachable == 4 fsck failures, 2 mount failures ext4 1 files in lost+found, 0 files gone/unreachable 1 files in lost+found, 0 files gone/unreachable 164 files in lost+found, 2 files gone/unreachable 1 files in lost+found, 0 files gone/unreachable 1 files in lost+found, 0 files gone/unreachable 1 files in lost+found, 1 files gone/unreachable 1 files in lost+found, 0 files gone/unreachable 9 files in lost+found, 1 files gone/unreachable 1 files in lost+found, 0 files gone/unreachable 1 files in lost+found, 0 files gone/unreachable == 0 fsck failures, 0 mount failures xfs 0 files in lost+found, 1 files gone/unreachable 0 files in lost+found, 0 files gone/unreachable 958 files in lost+found, 629 files gone/unreachable 0 files in lost+found, 0 files gone/unreachable 2 files in lost+found, 0 files gone/unreachable 0 files in lost+found, 1 files gone/unreachable 0 files in lost+found, 0 files gone/unreachable 0 files in lost+found, 0 files gone/unreachable 8 files in lost+found, 1 files gone/unreachable 3 files in lost+found, -1 files gone/unreachable == 0 fsck failures, 0 mount failures ___ 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 Thu, 2020-07-02 at 08:24 -0700, Gordon Messmer wrote: > On 7/2/20 3:16 AM, nick...@gmail.com wrote: > > Note that, even though Microsoft is pushing for UEFI on new systems > > in > > the OEM version of Windows, they still support booting in legacy > > BIOS > > mode in the latest Windows 10 version and they even support a 32- > > bit > > version of Windows 10, which Fedora no longer does > > ... > > I'm by no means a Microsoft fan, but these are facts. Fedora is > > pushing > > for hardware obsolescence faster than Microsoft in this regard.:( > > I think that as far as 32-bit support is concerned, the issue was > less > that Fedora pushed for "hardware obsolescence" and more that no one > "pushed" for support. Fedora is a collection of the work of > volunteers, > and supporting 32-bit hardware requires more than simply sending > SRPMs > through the build pipeline. Things break, and over time there were > fewer volunteers willing and able to fix those problems. The way Im > remember it, there were plenty of statements to the effect that as > long > as someone was willing to do that work, Fedora would continue to > publish > a 32-bit release. Yes, I understand the complexities of the issue and the extra maintenance work. I was just correcting something I perceived as misinformation or misunderstanding of what Microsoft supports. They've only disallowed PC vendors such as HP, Dell, Lenovo, etc. from selling *new* computers with the 32-bit version of Windows preinstalled, but they continue to support and update the 32-bit version of Windows 10, even though they've dropped support for Windows 7 and Windows XP. I, personally, am happy with what Fedora supports - the oldest computer I still use regularly is a 2004-2006 Socket 939 desktop with an AMD Athlon 64 X2 4800+ dual core CPU with 4 GB of DDR1 RAM, a PCI Express graphics card, a SATA hard drive and 2 floppies - a 3.5-inch and a 5.25-inch (I've added them just for fun, just because the motherboard has a floppy controller, I don't seriously use them :) ). The x86_64 version of Fedora runs just fine on this computer. And so does the 32- bit of Windows 10, but the 64-bit version has dropped support for it, because it doesn't support a single instruction, that was added later to the AMD64 architecture. Luckily, 64-bit Fedora doesn't require it, so I'm a happy Fedora user! :) And yes, I know it's high time that I upgrade, but this is my last desktop computer (all my newer and more powerful computers have been laptops), and it's just more convenient to use the desktop, while sitting on my desk at home. :) And if I had a 32-bit system still in use, I'd probably have volunteered to help keep the 32-bit x86 Fedora alive, but since the 64- bit version works for me, I don't have much incentive to do it. :) > > That doesn't strictly apply to discussions about dropping BIOS boot > support, but that doesn't look like it will happen any time soon. Yes, these are separate issues and the legacy BIOS support affects much newer systems. And it is also less work to maintain legacy BIOS support, compared to an entire 32-bit version of the operating system. And btw, I generally agree that grub2 is a little overengineered and difficult to configure and I think it would benefit if it supported something like a simpler configuration mode. I like how powerful it is, but I think the main problem is that it exposes too much complexity in its configuration file. 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: The future of legacy BIOS support in Fedora.
On 7/2/20 3:19 PM, Martin Jackson wrote: 5-10 years? A better estimate would be 15-20 years. People aren't going to throw away perfectly fine systems and jump to new "cloud" platforms just because the OS they were using dropped BIOS support. They'll just stop updating, and likely move to something that is still supporting BIOS, if they don't write their own installer and just continue using Fedora, given that this is an entirely artificial limitation. While I completely hear you on the fact that people will often sweat assets for years longer than accounting schedules suggest they should, do you really think they're going to write custom installers??? I think it's far more likely that they would move to other distros more amenable to supporting the hardware they have. There are many distros that cater to this kind of market already, some by design and some by inclination.?? I don't think we want to drive them there. For what it's worth, I do not think that removing legacy BIOS support from Fedora is the right thing to do.?? I don't see significant benefit, and I see lots of potential harm. Thanks, Marty I don't think removing BIOS support _today_ is the right answer either. I have BIOS only hardware kicking around, and quite a bit of my UEFI hardware still supports legacy BIOS booting as well (though I don't use it). However, I'm concerned about UEFI feature development / quality assurance being held hostage by BIOS support for, based on above comments, 5 to 20 years? Surely as a somewhat leading-edge distribution, we need to start thinking about some kind of post-BIOS world. Perhaps one small step toward that future would be enabling systemd-boot on new UEFI installs, relegating GRUB2 to BIOS and upgrade installs only? This split configuration could hang around until support for GRUB2 / BIOS wanes to the point it can no longer stand under its own weight (much like 32bit install media). ___ 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.
5-10 years? A better estimate would be 15-20 years. People aren't going to throw away perfectly fine systems and jump to new "cloud" platforms just because the OS they were using dropped BIOS support. They'll just stop updating, and likely move to something that is still supporting BIOS, if they don't write their own installer and just continue using Fedora, given that this is an entirely artificial limitation. While I completely hear you on the fact that people will often sweat assets for years longer than accounting schedules suggest they should, do you really think they're going to write custom installers??? I think it's far more likely that they would move to other distros more amenable to supporting the hardware they have. There are many distros that cater to this kind of market already, some by design and some by inclination.?? I don't think we want to drive them there. For what it's worth, I do not think that removing legacy BIOS support from Fedora is the right thing to do.?? I don't see significant benefit, and I see lots of potential harm. Thanks, Marty ___ 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: booting successfully with read-only file system
On 7/2/20 3:10 PM, Christopher Engelhard wrote: On 02.07.20 17:53, Zbigniew Jędrzejewski-Szmek wrote: It would be great if we could fairly reliably boot with a read-only root file system, all the way to the graphical environment. Obviously, such a machine will not be fully functional, but for users, debugging a disk problem when they have the normal environment with windows, tabbed terminals, graphical editors, and internet is vastly easier. It also creates an image of robustness. Imagine that instead of being rudely dropped to a terminal prompt, the user is instead able to log in as usual and see a popup like Your home directory is read-only. Do this and that. See https://... That would be fantastic, and would be miles ahead from any UX I had on any computer, ever. I hope we can all cooperate to make read-only boots nicely robust and functional. Please play with this and report bugs. I'll try to solve any that relate to systemd. The systemd version with udev.blockdev-read-only is not released yet, but is available from koji ci builds [11]. Thanks for working on this, I will definitely give it a try myself. Christopher This sounds excellent! Could we somehow provide a list of links that may be helpful to recover from certain common failures? Maybe in a MOTD? ___ 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 2:28:39 PM MST 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.
5-10 years? A better estimate would be 15-20 years. People aren't going to
throw away perfectly fine systems and jump to new "cloud" platforms just
because the OS they were using dropped BIOS support. They'll just stop
updating, and likely move to something that is still supporting BIOS, if they
don't write their own installer and just continue using Fedora, given that
this is an entirely artificial limitation.
--
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: booting successfully with read-only file system
On 02.07.20 17:53, Zbigniew Jędrzejewski-Szmek wrote: > It would be great if we could fairly reliably boot with a read-only > root file system, all the way to the graphical environment. Obviously, > such a machine will not be fully functional, but for users, debugging a > disk problem when they have the normal environment with windows, > tabbed terminals, graphical editors, and internet is vastly easier. > > It also creates an image of robustness. Imagine that instead of being > rudely dropped to a terminal prompt, the user is instead able to log in > as usual and see a popup like >> Your home directory is read-only. Do this and that. See https://... That would be fantastic, and would be miles ahead from any UX I had on any computer, ever. > I hope we can all cooperate to make read-only boots nicely robust and > functional. Please play with this and report bugs. I'll try to solve any > that relate to systemd. The systemd version with udev.blockdev-read-only > is not released yet, but is available from koji ci builds [11]. Thanks for working on this, I will definitely give it a try myself. Christopher ___ 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/2/20 2:56 PM, John M. Harris Jr wrote: On Thursday, July 2, 2020 5:08:14 AM MST Brandon Nielsen wrote: On 7/2/20 12:55 AM, John M. Harris Jr wrote: 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? Can you please stop calling features of systemd you don't like "systemd-bloat" at every given opportunity? It is not being respectful to those who work on the project and doesn't help your argument. It works well with this one. It's part of systemd, for some reason. It's bloat. It's one letter off from the actual name of the software. It doesn't need to be part of systemd to integrate with it. We don't need to make our system more exclusive to make use of some systemd features, we can just use the more powerful bootloader, GRUB2, and implement what it needs to make use of these systemd "features". If your issue is with the architecture of systemd, I recommend taking an objective argument to the systemd development list. If your issue is with Fedora making use of features already implemented in systemd, I recommend making an objective argument detailing why those features shouldn't be used. If there are better alternatives that can enable Gnome is easily integrate with the bootloader (to enable say, a "Reboot to Windows" or "Reboot to UEFI" option), I would love to hear about them. I'm also interested in how further modifying GRUB2 to to enable features (that were previously bloat?) that systemd-boot supports today is better for the future of Fedora's UEFI support. Especially in regards to testing and maintenance burden. ___ 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 Thursday, July 2, 2020 5:08:31 AM MST Peter Robinson wrote: > On Wed, Jul 1, 2020 at 3:29 PM Alek Paunov wrote: > > > > > > > On 2020-06-30 14:34, Jóhann B. Guðmundsson wrote: > > > > > Share your thoughts and comments on how such move might affect you so > > > feedback can be collected for the future on why such a change might be > > > bad, how it might affect the distribution and scope of such change can > > > be determined for potential system wide proposal. > > > > > > > > > > > > > > Just in case if someone is not aware: syslinux (pxe, ext) shipped with > > Fedora is in very good state - form about 2016 I am using the package > > > I suppose "very good state" is a relative term, upstream hasn't seen a > release since 2016 so is essentially "unmaintained", not sure it > supports secure boot, probably has a bunch of CVEs (see point about > maintenance). I think it only lives on in Fedora is because I think > it's used for some (.iso?) install method, AFIACT it's eventually > glued back together when it fails to build and is generally ignored. It's used for ISO boot by Fedora itself, and is the preferred PXE method, the alternative being GRUB. It's a powerful bootloader, I don't see anything that needs changing in it. -- 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 Thursday, July 2, 2020 5:08:14 AM MST Brandon Nielsen wrote: > On 7/2/20 12:55 AM, John M. Harris Jr wrote: > > > > > > > > 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? > > > Can you please stop calling features of systemd you don't like > "systemd-bloat" at every given opportunity? It is not being respectful > to those who work on the project and doesn't help your argument. It works well with this one. It's part of systemd, for some reason. It's bloat. It's one letter off from the actual name of the software. It doesn't need to be part of systemd to integrate with it. We don't need to make our system more exclusive to make use of some systemd features, we can just use the more powerful bootloader, GRUB2, and implement what it needs to make use of these systemd "features". -- 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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/1/20 9:49 PM, Chris Adams wrote: 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. We do, the recovery tools allow you to just ignore checksums. This is specifically separate from everything else because there's the expectation of results. The user is acknowledging that things are bad and the tools are going to do their very best. If you know you only have a single bit off then hooray, you got everything back (probably), but if not then you don't. 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: booting successfully with read-only file system
On Thu, Jul 02, 2020 at 06:27:44PM +0200, Vitaly Zaitsev via devel wrote: > On 02.07.2020 17:53, Zbigniew Jędrzejewski-Szmek wrote: > > It would be great if we could fairly reliably boot with a read-only > > root file system, all the way to the graphical environment. > > Already implemented - Silverblue. If you read past the first sentence, you'd notice that I'm talking about a system in failure conditions. If you looked in at earlier replies to my mail, you'd also notice that your idea was already discussed upthread. But instead of just replying to the subject, you actually got as far as the first sentence, so ... there is hope ;) Zbyszek PS. I wrote quite seriously about a real problem. I don't need quick replies that don't answer anything. ___ 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: Is allowed in certain cases to override default Fedora compiler flags?
Sergio Belkin wrote: > Thanks everyone, I guess the same thing goes for: > > warning: ignoring return value of 'ssize_t write(int, const void*, size_t)' > declared with attribute 'warn_unused_result' > > (The line in the source code is if(upLogPerror) ::write(2,logbuf,n); \ ) > > doesn't it? Ignoring the result of write is usually a serious bug. However, that line looks like it writes a log message to the standard error stream, and in that specific case there might not be anything meaningful the program can do if write fails, if it doesn't want to terminate with an error status. Logging an error message about how logging failed could easily lead to infinite recursion. So depending on what other error reporting mechanisms are available to the program, it may be reasonable to ignore the function result in this case, but it should be done by tweaking the code to silence the compiler warning for that call only. Disabling -Wunused-result for the whole program is not a good idea. Björn Persson pgpmAzjiNZ85n.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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Thu, 2020-07-02 at 09:44 +0200, Florian Weimer wrote: > * Konstantin Kharlamov: > > > FWIW, I was just thinking about it, and I came up with example you > > may like which shows exactly why BTRFS is bad for HDD. Consider > > development process. It includes rewriting source files over and > > over: you do `git checkout foo` and files are overwritten, you > > change a file in text editor, and it gets overwritten. And since > > BTRFS is CoW, it will always write files to a new place. > > Editors that make a backup copy typically do not overwrite files in > place. They rename the file to the backup location and then write the > new file. > > git checkout unlinks changed files first, before writing them anew > from scratch. > > A COW file system does not make a difference for these use cases > because there is already COW at the application level. > > The GNU assembler truncates the output object file first. On XFS, > that triggers relocation to a new file system location as well, even > if the output file size (or contents) does not change. So that > scenario is essentially COW as well today. Per my understanding what happens when you write a new file and delete an old one is that a block that old file was taking gets freed. Then, if you copy the file again, file system should find a free block to write this copy into. And this block likely would be the one that got freed previously. So, well, it is indeed COW, but not the one BTRFS does. It's a COW that copies a file back and forth between two blocks :) This is kinda HDD-friendly COW :) BTRFS on the other hand will not rewrite older block unless it's out of new ones. ___ 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: Is allowed in certain cases to override default Fedora compiler flags?
On 02/07/20 14:41 -0300, Sergio Belkin wrote: El jue., 2 jul. 2020 a las 13:30, Vitaly Zaitsev via devel (< devel@lists.fedoraproject.org>) escribió: On 01.07.2020 22:47, Sergio Belkin wrote: > So the question is: in this case I can override the Fedora compiler flags? Don't do this, please. You should fix such potentially vulnerable parts of code and send your patch to upstream. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Thanks everyone, I guess the same thing goes for: warning: ignoring return value of 'ssize_t write(int, const void*, size_t)' declared with attribute 'warn_unused_result' (The line in the source code is if(upLogPerror) ::write(2,logbuf,n); \ ) doesn't it? That's only a warning. Ideally the code should check the write, but it's not actually preventing you building the package. ___ 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: Is allowed in certain cases to override default Fedora compiler flags?
El jue., 2 jul. 2020 a las 13:30, Vitaly Zaitsev via devel (< devel@lists.fedoraproject.org>) escribió: > On 01.07.2020 22:47, Sergio Belkin wrote: > > So the question is: in this case I can override the Fedora compiler > flags? > > Don't do this, please. You should fix such potentially vulnerable parts > of code and send your patch to upstream. > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.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 > Thanks everyone, I guess the same thing goes for: warning: ignoring return value of 'ssize_t write(int, const void*, size_t)' declared with attribute 'warn_unused_result' (The line in the source code is if(upLogPerror) ::write(2,logbuf,n); \ ) doesn't it? -- -- 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: WebRTC packaging
On Thu, Jul 2, 2020 at 12:41 PM Vitaly Zaitsev via devel
wrote:
>
> Hello all!
>
> Is it okay to package Google's static-only WebRTC library? This package
> will provide only webrtc-static and webrtc-devel subpackages.
>
> I need this library to build another packages. Bundling it directly is
> not a good idea, because this library is very big and significantly
> slows down the build process especially on different low-memory
> architectures, such as ARM.
>
> Dependent packages will require it with BuildRequires: webrtc-devel
> webrtc-static and include Provides: bundled(webrtc) = %{webrtc_version}.
>
It is permitted, but you don't need bundled() Provides on packages
that do this, since we're tracking through BRs instead.
--
真実はいつも一つ！/ 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
WebRTC packaging
Hello all!
Is it okay to package Google's static-only WebRTC library? This package
will provide only webrtc-static and webrtc-devel subpackages.
I need this library to build another packages. Bundling it directly is
not a good idea, because this library is very big and significantly
slows down the build process especially on different low-memory
architectures, such as ARM.
Dependent packages will require it with BuildRequires: webrtc-devel
webrtc-static and include Provides: bundled(webrtc) = %{webrtc_version}.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.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
Fedora rawhide compose report: 20200702.n.0 changes
OLD: Fedora-Rawhide-20200701.n.0 NEW: Fedora-Rawhide-20200702.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 11 Dropped packages:0 Upgraded packages: 73 Downgraded packages: 0 Size of added packages: 34.52 MiB Size of dropped packages:0 B Size of upgraded packages: 3.94 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 2.30 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200701.n.0.ppc64le.tar.xz = ADDED PACKAGES = Package: ghc-filepattern-0.1.2-1.fc33 Summary: File path glob-like matching RPMs:ghc-filepattern ghc-filepattern-devel ghc-filepattern-prof Size:1.50 MiB Package: golang-github-dravenk-webthing-0.0.1-1.fc33 Summary: Go implementation of a Web Thing server RPMs:golang-github-dravenk-webthing-devel Size:28.63 KiB Package: mingw-opencv-4.3.0-3.fc33 Summary: MinGW Windows OpenCV library RPMs:mingw32-opencv mingw32-opencv-tools mingw32-python3-opencv mingw64-opencv mingw64-opencv-tools mingw64-python3-opencv Size:26.79 MiB Package: rust-askama-0.10.0-1.fc33 Summary: Type-safe, compiled Jinja-like templates for Rust RPMs:rust-askama+config-devel rust-askama+default-devel rust-askama+humansize-devel rust-askama+mime-devel rust-askama+mime_guess-devel rust-askama+num-traits-devel rust-askama+serde-json-devel rust-askama+serde-yaml-devel rust-askama+urlencode-devel rust-askama+with-actix-web-devel rust-askama+with-gotham-devel rust-askama+with-iron-devel rust-askama+with-rocket-devel rust-askama+with-warp-devel rust-askama-devel Size:117.29 KiB Package: rust-askama_derive-0.10.0-1.fc33 Summary: Procedural macro package for Askama RPMs:rust-askama_derive+actix-web-devel rust-askama_derive+default-devel rust-askama_derive+gotham-devel rust-askama_derive+iron-devel rust-askama_derive+rocket-devel rust-askama_derive+warp-devel rust-askama_derive-devel Size:58.16 KiB Package: rust-askama_escape-0.10.1-1.fc33 Summary: Optimized HTML escaping code, extracted from Askama RPMs:rust-askama_escape+default-devel rust-askama_escape-devel Size:24.06 KiB Package: rust-askama_shared-0.10.2-1.fc33 Summary: Shared code for Askama RPMs:rust-askama_shared+config-devel rust-askama_shared+default-devel rust-askama_shared+humansize-devel rust-askama_shared+json-devel rust-askama_shared+num-traits-devel rust-askama_shared+percent-encoding-devel rust-askama_shared+serde-devel rust-askama_shared+serde_derive-devel rust-askama_shared+serde_json-devel rust-askama_shared+serde_yaml-devel rust-askama_shared+toml-devel rust-askama_shared+yaml-devel rust-askama_shared-devel Size:124.33 KiB Package: rust-pem-0.8.1-1.fc33 Summary: Parse and encode PEM-encoded data RPMs:rust-pem+default-devel rust-pem-devel Size:23.75 KiB Package: rust-wasm-bindgen-shared-0.2.64-1.fc33 Summary: Shared support between wasm-bindgen and wasm-bindgen cli, an internal dependency RPMs:rust-wasm-bindgen-shared+default-devel rust-wasm-bindgen-shared-devel Size:22.09 KiB Package: rust-wasm-bindgen-test-macro-0.3.14-1.fc33 Summary: Internal testing macro for wasm-bindgen RPMs:rust-wasm-bindgen-test-macro+default-devel rust-wasm-bindgen-test-macro-devel Size:22.32 KiB Package: vgrep-2.3.1-2.fc33 Summary: User-friendly pager for grep RPMs:golang-github-vrothberg-vgrep-devel vgrep Size:5.82 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: FlightGear-2020.1.3-1.fc33 Old package: FlightGear-2020.1.2-1.fc33 Summary: The FlightGear Flight Simulator RPMs: FlightGear Size: 34.32 MiB Size change: -816 B Changelog: * Tue Jun 30 2020 Fabrice Bellet - 2020.1.3-1 - new upstream release - cmake: revert automatic translations detection Package: FlightGear-Atlas-0.5.0-0.58.cvs20141002.fc33 Old package: FlightGear-Atlas-0.5.0-0.57.cvs20141002.fc33 Summary: Flightgear map tools RPMs: FlightGear-Atlas Size: 3.68 MiB Size change: 27 B Changelog: * Wed Jul 01 2020 Fabrice Bellet - 0.5.0-0.58.cvs20141002 - rebuild with newer SimGear Package: FlightGear-data-2020.1.3-1.fc33 Old package: FlightGear-data-2020.1.2-1.fc33 Summary: FlightGear base scenery and data files RPMs: FlightGear-data Size: 1.75 GiB Size change: 4.98 KiB Changelog: * Tue Jun 30 2020 Fabrice Bellet - 2020.1.3-1 - new upstream release Package: SimGear-2020.1.3-1.fc33 Old package: SimGear-2020.1.2-1.fc33 Summary: Simulation library components RPMs: SimGear SimGear-devel Size: 13.59 MiB Size change: 5.03 KiB Changelog: * Tue Jun 30 2020 Fabrice Bellet - 2020.1.3-1 - new upstream release Package: aircrack-ng-1.6-3.fc33 Old package: aircrack-ng-1.6-2.fc33 Summary: 802.11
Re: Is allowed in certain cases to override default Fedora compiler flags?
On 01.07.2020 22:47, Sergio Belkin wrote: > So the question is: in this case I can override the Fedora compiler flags? Don't do this, please. You should fix such potentially vulnerable parts of code and send your patch to upstream. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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: booting successfully with read-only file system
On 02.07.2020 17:53, Zbigniew Jędrzejewski-Szmek wrote: > It would be great if we could fairly reliably boot with a read-only > root file system, all the way to the graphical environment. Already implemented - Silverblue. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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: booting successfully with read-only file system
On Thu, Jul 02, 2020 at 05:05:09PM +0100, Daniel P. Berrangé wrote: > On Thu, Jul 02, 2020 at 03:53:26PM +, Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > > > this is partially an outgrowth of the discussion about btrfs as > > default, but makes sense independently too... > > > > It would be great if we could fairly reliably boot with a read-only > > root file system, all the way to the graphical environment. Obviously, > > such a machine will not be fully functional, but for users, debugging a > > disk problem when they have the normal environment with windows, > > tabbed terminals, graphical editors, and internet is vastly easier. > > > > It also creates an image of robustness. Imagine that instead of being > > rudely dropped to a terminal prompt, the user is instead able to log in > > as usual and see a popup like > > > Your home directory is read-only. Do this and that. See https://... > > > > Is the goal to have *everything* working? No. Some services will and > > should fail. If I have a database or anything else which only makes > > sense with permanent storage, failing early and loudly is appropriate. > > But services which need writable storage only tangentially or not at > > all should be robust and not fail. Journald behaves in a fashion where > > it stores logs to /run during early boot and them flushes them to /var/log > > when that becomes available. If /var/log never become available, we > > have a functional logs, with journalctl showing previous and current boot > > just fine. The only caveat is that logs for current boot will be lost > > upon reboot. Such graceful failure should be the norm. > > I presume you're referring to regular Fedora here, but this description > feels like it is approx asking for what Fedora Silverblue has delivered, > only with the writable area for apps being just a ram disk with no > persistence. No, quite the opposite. I am talking about making the best out of a failure situation on a normal Fedora installation. I don't want to boot routinely in such a mode. I want to boot ro, look for help on the internet and in man pages, do some fsck operations on the read-only disk, and finally remount the disk rw and carry on with my day. Zbyszek > https://docs.fedoraproject.org/en-US/fedora-silverblue/ > > "Silverblue is a variant of Fedora Workstation. It looks, >feels and behaves like a regular desktop operating system, >and the experience is similar to what you find with using >a standard Fedora Workstation. > >However, unlike other operating systems, Silverblue is >immutable. This means that every installation is identical >to every other installation of the same version. The operating >system that is on disk is exactly the same from one machine to >the next, and it never changes as it is used. > >Silverblue’s immutable design is intended to make it more >stable, less prone to bugs, and easier to test and develop. >Finally, Silverblue’s immutable design also makes it an >excellent platform for containerized applications as well >as container-based software development. In each case, >applications (apps) and containers are kept separate from >the host system, improving stability and reliability." > > > Regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > ___ > 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 ___ 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: Is allowed in certain cases to override default Fedora compiler flags?
Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jul 01, 2020 at 05:47:51PM -0300, Sergio Belkin wrote: > > So the question is: in this case I can override the Fedora compiler flags? > > Other people replied with suggestions how to make the code better, but > let me also answer this question directly: > > yes you can, the guidelines say: > > > Adding to and overriding or filtering parts of these flags is > > permitted if there’s a good reason to do so; the rationale for > > doing so must be documented in the specfile. Note the words "good reason". As I understand it, Sergio's question is whether this case is a good reason. In my opinion, incorrect use of snprintf and write are bad reasons for overriding the compiler flags. It's better to fix the actual problem than to silence the alarm. Björn Persson pgpf9I2zAvuwr.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: booting successfully with read-only file system
On Thu, Jul 2, 2020 at 12:05 PM Daniel P. Berrangé wrote: > > On Thu, Jul 02, 2020 at 03:53:26PM +, Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > > > this is partially an outgrowth of the discussion about btrfs as > > default, but makes sense independently too... > > > > It would be great if we could fairly reliably boot with a read-only > > root file system, all the way to the graphical environment. Obviously, > > such a machine will not be fully functional, but for users, debugging a > > disk problem when they have the normal environment with windows, > > tabbed terminals, graphical editors, and internet is vastly easier. > > > > It also creates an image of robustness. Imagine that instead of being > > rudely dropped to a terminal prompt, the user is instead able to log in > > as usual and see a popup like > > > Your home directory is read-only. Do this and that. See https://... > > > > Is the goal to have *everything* working? No. Some services will and > > should fail. If I have a database or anything else which only makes > > sense with permanent storage, failing early and loudly is appropriate. > > But services which need writable storage only tangentially or not at > > all should be robust and not fail. Journald behaves in a fashion where > > it stores logs to /run during early boot and them flushes them to /var/log > > when that becomes available. If /var/log never become available, we > > have a functional logs, with journalctl showing previous and current boot > > just fine. The only caveat is that logs for current boot will be lost > > upon reboot. Such graceful failure should be the norm. > > I presume you're referring to regular Fedora here, but this description > feels like it is approx asking for what Fedora Silverblue has delivered, > only with the writable area for apps being just a ram disk with no > persistence. > Silverblue fails when the disk can't mount as read-write either. So this benefits Silverblue by making it possible for those failure modes to work properly. -- 真実はいつも一つ！/ 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: booting successfully with read-only file system
On Thu, Jul 02, 2020 at 03:53:26PM +, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > this is partially an outgrowth of the discussion about btrfs as > default, but makes sense independently too... > > It would be great if we could fairly reliably boot with a read-only > root file system, all the way to the graphical environment. Obviously, > such a machine will not be fully functional, but for users, debugging a > disk problem when they have the normal environment with windows, > tabbed terminals, graphical editors, and internet is vastly easier. > > It also creates an image of robustness. Imagine that instead of being > rudely dropped to a terminal prompt, the user is instead able to log in > as usual and see a popup like > > Your home directory is read-only. Do this and that. See https://... > > Is the goal to have *everything* working? No. Some services will and > should fail. If I have a database or anything else which only makes > sense with permanent storage, failing early and loudly is appropriate. > But services which need writable storage only tangentially or not at > all should be robust and not fail. Journald behaves in a fashion where > it stores logs to /run during early boot and them flushes them to /var/log > when that becomes available. If /var/log never become available, we > have a functional logs, with journalctl showing previous and current boot > just fine. The only caveat is that logs for current boot will be lost > upon reboot. Such graceful failure should be the norm. I presume you're referring to regular Fedora here, but this description feels like it is approx asking for what Fedora Silverblue has delivered, only with the writable area for apps being just a ram disk with no persistence. https://docs.fedoraproject.org/en-US/fedora-silverblue/ "Silverblue is a variant of Fedora Workstation. It looks, feels and behaves like a regular desktop operating system, and the experience is similar to what you find with using a standard Fedora Workstation. However, unlike other operating systems, Silverblue is immutable. This means that every installation is identical to every other installation of the same version. The operating system that is on disk is exactly the same from one machine to the next, and it never changes as it is used. Silverblue’s immutable design is intended to make it more stable, less prone to bugs, and easier to test and develop. Finally, Silverblue’s immutable design also makes it an excellent platform for containerized applications as well as container-based software development. In each case, applications (apps) and containers are kept separate from the host system, improving stability and reliability." Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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: booting successfully with read-only file system
On Thu, Jul 2, 2020 at 11:54 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > Hi, > > this is partially an outgrowth of the discussion about btrfs as > default, but makes sense independently too... > > It would be great if we could fairly reliably boot with a read-only > root file system, all the way to the graphical environment. Obviously, > such a machine will not be fully functional, but for users, debugging a > disk problem when they have the normal environment with windows, > tabbed terminals, graphical editors, and internet is vastly easier. > > It also creates an image of robustness. Imagine that instead of being > rudely dropped to a terminal prompt, the user is instead able to log in > as usual and see a popup like > > Your home directory is read-only. Do this and that. See https://... > > Is the goal to have *everything* working? No. Some services will and > should fail. If I have a database or anything else which only makes > sense with permanent storage, failing early and loudly is appropriate. > But services which need writable storage only tangentially or not at > all should be robust and not fail. Journald behaves in a fashion where > it stores logs to /run during early boot and them flushes them to /var/log > when that becomes available. If /var/log never become available, we > have a functional logs, with journalctl showing previous and current boot > just fine. The only caveat is that logs for current boot will be lost > upon reboot. Such graceful failure should be the norm. > > systemd upstream recently gained a cool feature [1] which allows all > block devices to be toggled read-only as soon as they are detected by > udev. The primary use case is forensics and recovery, but it is also > great for testing read-only boot ;) > > It turns out that systemd itself is not very good in this situation. > For example, any unit with PrivateTmp=yes would fail to start :( > But it turns out that this is fairly easy to solve. I opened two > PRs today [2, 3], and with that, systemd boots to a working > multi-user.target with no services bundled with systemd failing! > > But I was not able to go all the way to a gnome session :( > I have been opening bugs as I went along: dnf [4], python [5], sssd [6], > gssproxy [7], gdm [8], btrfs [9], xfs[10]. The good new is that the > first is almost solved, the second is already solved, the next two > seem fairly easy, and the btrfs one is being handled. The one for gdm > unfortunately looks tougher :( > > I hope we can all cooperate to make read-only boots nicely robust and > functional. Please play with this and report bugs. I'll try to solve any > that relate to systemd. The systemd version with udev.blockdev-read-only > is not released yet, but is available from koji ci builds [11]. > > [1] https://github.com/systemd/systemd/commit/95ac523030 > [2] https://github.com/systemd/systemd/pull/16340 > [3] https://github.com/systemd/systemd/pull/16344 > [4] https://bugzilla.redhat.com/show_bug.cgi?id=1852365 > [5] https://bugzilla.redhat.com/show_bug.cgi?id=1852941 > [6] https://bugzilla.redhat.com/show_bug.cgi?id=1853261 > [7] https://bugzilla.redhat.com/show_bug.cgi?id=1853293 > [8] https://bugzilla.redhat.com/show_bug.cgi?id=1853409 > [9] https://bugzilla.redhat.com/show_bug.cgi?id=1851608 > [10] https://bugzilla.redhat.com/show_bug.cgi?id=1829792 > [11] https://src.fedoraproject.org/rpms/systemd/pull-request/29 > > Zbyszek > +about a billion or so! Particularly fun if you forget to set the root password after install and can't even get to the prompt. langdon > ___ > 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 > ___ 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
booting successfully with read-only file system
Hi, this is partially an outgrowth of the discussion about btrfs as default, but makes sense independently too... It would be great if we could fairly reliably boot with a read-only root file system, all the way to the graphical environment. Obviously, such a machine will not be fully functional, but for users, debugging a disk problem when they have the normal environment with windows, tabbed terminals, graphical editors, and internet is vastly easier. It also creates an image of robustness. Imagine that instead of being rudely dropped to a terminal prompt, the user is instead able to log in as usual and see a popup like > Your home directory is read-only. Do this and that. See https://... Is the goal to have *everything* working? No. Some services will and should fail. If I have a database or anything else which only makes sense with permanent storage, failing early and loudly is appropriate. But services which need writable storage only tangentially or not at all should be robust and not fail. Journald behaves in a fashion where it stores logs to /run during early boot and them flushes them to /var/log when that becomes available. If /var/log never become available, we have a functional logs, with journalctl showing previous and current boot just fine. The only caveat is that logs for current boot will be lost upon reboot. Such graceful failure should be the norm. systemd upstream recently gained a cool feature [1] which allows all block devices to be toggled read-only as soon as they are detected by udev. The primary use case is forensics and recovery, but it is also great for testing read-only boot ;) It turns out that systemd itself is not very good in this situation. For example, any unit with PrivateTmp=yes would fail to start :( But it turns out that this is fairly easy to solve. I opened two PRs today [2, 3], and with that, systemd boots to a working multi-user.target with no services bundled with systemd failing! But I was not able to go all the way to a gnome session :( I have been opening bugs as I went along: dnf [4], python [5], sssd [6], gssproxy [7], gdm [8], btrfs [9], xfs[10]. The good new is that the first is almost solved, the second is already solved, the next two seem fairly easy, and the btrfs one is being handled. The one for gdm unfortunately looks tougher :( I hope we can all cooperate to make read-only boots nicely robust and functional. Please play with this and report bugs. I'll try to solve any that relate to systemd. The systemd version with udev.blockdev-read-only is not released yet, but is available from koji ci builds [11]. [1] https://github.com/systemd/systemd/commit/95ac523030 [2] https://github.com/systemd/systemd/pull/16340 [3] https://github.com/systemd/systemd/pull/16344 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1852365 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1852941 [6] https://bugzilla.redhat.com/show_bug.cgi?id=1853261 [7] https://bugzilla.redhat.com/show_bug.cgi?id=1853293 [8] https://bugzilla.redhat.com/show_bug.cgi?id=1853409 [9] https://bugzilla.redhat.com/show_bug.cgi?id=1851608 [10] https://bugzilla.redhat.com/show_bug.cgi?id=1829792 [11] https://src.fedoraproject.org/rpms/systemd/pull-request/29 Zbyszek ___ 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 9:24 AM, Josef Bacik wrote: > On 7/1/20 7:49 AM, Steven Whitehouse wrote: >> Hi, >> >> On 01/07/2020 12:09, Zbigniew Jędrzejewski-Szmek wrote: >>> On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote: Hi, On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote: >> So yes, I think an explicit "let's all test btrfs (as anaconda >> configures it) before we make it default" period is warranted. >> >> Perhaps one can argue that Fedora has already been doing that for the >> past two years (since 2018-or-later-btrfs is what everyone with positive >> results appears to be talking about), but it's still not clear that >> those deployments utilize the same feature set as Fedora's defaults, and >> how broad the hardware sample is. > 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. > > 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. > > Zbyszek Indeed, it is an important point, and taking care is very important when dealing with other people's data, which is in effect what we are discussing here. When we looked at btrfs support in RHEL, we took quite a long time over it. In fact I'm not quite sure how long, since the process had started before I was involved, but it was not a decision that was made quickly, and a great deal of thought went into it. It was difficult to get concrete information about the stability aspects at the time. Just like the discussions that have taken place on this thread, there was a lot of anecdotal evidence, but that is not always a good indicator. Since time has passed since then, and there is now more evidence, this part of the process should be easier. That said to get a meaningful comparison then ideally one would want to compare on the basis of user populations of similar size and technical skill level, and look not just at the overall number of bugs reported, but at the rate those bugs are being reported too. >>> Yeah. I have no doubt that the decision was made carefully back then. >>> That said, time has passed, and btrfs has evolved and our use cases >>> have evolved too, so a fresh look is good. >>> >>> We have https://fedoraproject.org/wiki/Changes/DNF_Better_Counting, >>> maybe this could be used to collect some statistics about the fs type >>> too. >> >> Yes, and also the questions that Fedora is trying to answer are different >> too. So I don't think that our analysis for RHEL is applicable here in >> general. The method that we went through, in general terms, may potentially >> be helpful. >> >> It is often tricky to be sure of the root cause of bugs - just because a filesystem reports an error doesn't mean that it is at fault, it might be a hardware problem, or an issue with volume management. Figuring out where the real problem lies is often very time consuming work. Without that work though, the raw numbers of bugs reported can be very misleading. It would be worth taking that step here, and asking each of the spins what are the features that they would most like to see from the storage/fs stack. Comparing filesystems in the abstract is a difficult task, and it is much easier against a context. I know that some of the issues have already been discussed in this thread, but maybe if someone was to gather up a list of requirements from those messages then that would help to direct further discussion, >>> Actually that part has been answered pretty comprehensively. The split >>> between / and /home is hurting users and we completely sidestep it >>> with this change. The change page lists a bunch of other benefits, >>> incl. better integration with the new resource allocation mechanisms >>> we have with cgroups2. So in a way this is a follow-up to the >>> cgroupsv2-by-default change in F31. Snapshots and subvolumes also give >>> additional powers to systemd-nspawn and other tools. I'd say that the >>> huge potential of btrfs is clear. It's the possibility of the loss of >>> stability that is my (and others') worry and the thing which is hard >>> to gauge. >>> >>> Zbyszek >> >> 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
Re: The future of legacy BIOS support in Fedora.
On 7/2/20 3:16 AM, nick...@gmail.com wrote: Note that, even though Microsoft is pushing for UEFI on new systems in the OEM version of Windows, they still support booting in legacy BIOS mode in the latest Windows 10 version and they even support a 32-bit version of Windows 10, which Fedora no longer does ... I'm by no means a Microsoft fan, but these are facts. Fedora is pushing for hardware obsolescence faster than Microsoft in this regard.:( I think that as far as 32-bit support is concerned, the issue was less that Fedora pushed for "hardware obsolescence" and more that no one "pushed" for support. Fedora is a collection of the work of volunteers, and supporting 32-bit hardware requires more than simply sending SRPMs through the build pipeline. Things break, and over time there were fewer volunteers willing and able to fix those problems. The way I remember it, there were plenty of statements to the effect that as long as someone was willing to do that work, Fedora would continue to publish a 32-bit release. That doesn't strictly apply to discussions about dropping BIOS boot support, but that doesn't look like it will happen any time soon. ___ 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/2/20 4:46 AM, Peter Robinson wrote: On Wed, Jul 1, 2020 at 12:19 AM Jóhann B. Guðmundsson wrote: On 30.6.2020 22:38, Kevin Kofler wrote: In addition, as far as I know, systemd-boot is not compatible with the "Secure Boot" shim. sd-boot works fine with secure boot but good point I'll add a test case for that and check if it's not working. Is that with self enrolled keys or is it now signed with the MS keys through the official process? Correct me if I'm wrong, but I think only shim is signed with the MS keys and the boot loader that it loads (grub2 or sd-boot) is signed by Red Hat. https://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guide/sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim.html ___ 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: Is allowed in certain cases to override default Fedora compiler flags?
On Wed, Jul 01, 2020 at 05:47:51PM -0300, Sergio Belkin wrote: > So the question is: in this case I can override the Fedora compiler flags? Other people replied with suggestions how to make the code better, but let me also answer this question directly: yes you can, the guidelines say: > Adding to and overriding or filtering parts of these flags is > permitted if there’s a good reason to do so; the rationale for > doing so must be documented in the specfile. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags ___ 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 Thu, Jul 02, 2020 at 02:07:17PM -, Ivan Ivanov wrote: > hopefully those which don't have a SystemD security-vulnerable > bloatware Oh, FFS. In this comparison, grub2 is the _highly_ bloated, everything-AND-the-kitchen-sink solution with multiple CVEs under its belt, and systemd-boot is the lean, tightly-focused do-only-one-thing tool without any reported CVEs. (seriously, the most recent systemd tarball is over 2.5MB smaller than the most recent grub2 tarball) - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
On 02.07.2020 11:27, Nicolas Mailhot wrote: > Why? Koji schedules a build. The build registers its own build date in > the produced packages. Koji decides to keep and commit the result, or > drop it (scratch build, failed side tag, whatever). Koji is still in > charge, the bumping is just integrated in the build process with the > rest of the package creation. Koji was just an example. %changelog section should be auto-generated from commits messages. I don't want to maintain a separate file with the changelog. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Thu, Jul 2, 2020 at 9:49 AM Peter Robinson wrote:
>
> On Wed, Jul 1, 2020 at 10:01 PM 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.
>
> Google Compute does as well I believe.
>
> > 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.
>
> I believe you need to disable secure-boot and it should work, I don't
> believe the issue is actual UEFI in this case, of course BIOS boot
> doesn't have any form of boot security.
>
> > Fix all the other problems we have with UEFI environments before
> > suggesting we drop "legacy BIOS".
>
> That's a very grand sweeping gesture with no details, I suspect most
> of the "problems" (what ever that means) are shity firmware
> implementations of the UEFI spec, we use to have that with BIOS all
> the time too, I suspect the reason we have it less so is that all the
> vendors have long left that code well alone and are only "enhancing"
> UEFI
>
> > 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.
>
> Is that a Fedora specific problem? Are other distros allowing the
> loading of unsigned kernel modules to work around the problem while
> potentially compromising user's security? I feel this is a Linux wide
> issue with a single vendor, and not specific to Fedora at all.
>
It is Fedora-specific. Neither Ubuntu nor openSUSE mandate that all
kmods need to be signed to load. They *warn* on it, but they don't
*block*.
Even with that, openSUSE makes it easy for kernel module packages to
include signed kernel modules. I think openSUSE will eventually switch
to blocking because the reason for not doing it doesn't apply these
days.
> Well there's lots of "reasons" I can think of but experience in the
> Fedora community and my experience in IoT fields and related security
> over the last few years the big ones IMO tend to be:
> * A lot of people would be opposed to Fedora keys signing closed
> source binary drivers, community, Red Hatters, probably legal (but I'm
> not legal) and it may even affect the ability to sign shim and hence
> use secure-boot at all (I've zero insight into this as I'm to lazy too
> even begin to look for how I'd do that) to name but a few.
This is false. The openSUSE builds of the nvidia driver are
auto-signed properly too, because their build system actually
*supports* signing kernel modules.
Use a secondary key instead of the primary one if you want. If I
remember correctly, that's what openSUSE does.
> * Nvidia could sign their binary kernel modules, and the public key
> could be enrolled into the kernel using mokutil likely even
> automatically using some hook, the user would get a prompt each boot
> with a new kernel but it wouldn't be a completely terrible experience.
> You'd have to ask nvidia why this isn't possible
>
They *do* sign it. Their installer actually autogenerates the cert,
signs the kernel modules, and enrolls the cert for you.
So our experience is strictly *worse* than nvidia's.
> > 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.
>
> I think you're being very harsh and short sighted here TBH, like
> things like AVX2 it's useful to have these conversations in a civil
> manner, even
Re: The future of legacy BIOS support in Fedora.
> > If you need Secure Boot feature to be enabled, you must sign the > > compiled kmod packages with your own CA. > > > > This is what's wrong with everything. *This is not okay*. This is > intentionally a poisonous user experience because we provide no > automatic or easy way for this to be done. I understand and agree with > the reasons for why it is this way, but you can't have it both ways if > you want an easy user experience. So you expect Fedora to provide a signing service using the Fedora keys for anyone to abuse just so you can run UEFI with secure boot enabled with your Nvidia GPU. I mean that's like locking the front door right before you blow the entire back of the building off! I strongly suspect that would be a violation of the MS secure boot agreement (I have no idea if this actually is, just widely guessing). > Either you sign the drivers server side and auto-trust that > certificate (prebuilt kmods), or you sign the drivers device-side > (akmods) and auto-trust that certificate. Or see my other reply for the third option which nvidia could do themselves. ___ 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.
Dropping the "legacy BIOS" support is a horrible idea: Not just there are a lot of "legacy BIOS" PCs, especially in a corporate world where the upgrades are slower than in the domestic environments. There are also a lot of really modern PCs running a coreboot firmware with a SeaBIOS payload - which is a modern "legacy BIOS" written in C. SeaBIOS has just 50k code lines: infinitely slimmer and much more efficient than a bloated UEFI abomination, even a Tianocore opensource one. UEFI is a "SystemD of a BIOS world", in a horrible way. Well, if you'd drop a Legacy BIOS support, more of the coreboot opensource BIOS people will move to the other distros, hopefully those which don't have a SystemD security-vulnerable bloatware - for example, Artix Linux, great user-friendly Arch without SystemD. So please go ahead and drop "legacy BIOS" support, so there would be one more reason for us to abandon Fedora with a SystemD hardcoded into 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 10:01 PM 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.
Google Compute does as well I believe.
> 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.
I believe you need to disable secure-boot and it should work, I don't
believe the issue is actual UEFI in this case, of course BIOS boot
doesn't have any form of boot security.
> Fix all the other problems we have with UEFI environments before
> suggesting we drop "legacy BIOS".
That's a very grand sweeping gesture with no details, I suspect most
of the "problems" (what ever that means) are shity firmware
implementations of the UEFI spec, we use to have that with BIOS all
the time too, I suspect the reason we have it less so is that all the
vendors have long left that code well alone and are only "enhancing"
UEFI
> 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.
Is that a Fedora specific problem? Are other distros allowing the
loading of unsigned kernel modules to work around the problem while
potentially compromising user's security? I feel this is a Linux wide
issue with a single vendor, and not specific to Fedora at all.
Well there's lots of "reasons" I can think of but experience in the
Fedora community and my experience in IoT fields and related security
over the last few years the big ones IMO tend to be:
* A lot of people would be opposed to Fedora keys signing closed
source binary drivers, community, Red Hatters, probably legal (but I'm
not legal) and it may even affect the ability to sign shim and hence
use secure-boot at all (I've zero insight into this as I'm to lazy too
even begin to look for how I'd do that) to name but a few.
* Nvidia could sign their binary kernel modules, and the public key
could be enrolled into the kernel using mokutil likely even
automatically using some hook, the user would get a prompt each boot
with a new kernel but it wouldn't be a completely terrible experience.
You'd have to ask nvidia why this isn't possible
> 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.
I think you're being very harsh and short sighted here TBH, like
things like AVX2 it's useful to have these conversations in a civil
manner, even if the original proposal was short sighted and missed a
lot of details and won't happen for years to come.
When aarch64 came along I made the decision that the only way Fedora
would ever support SBCs (like the Pine64, 96boards 410c the first
early boards we supported) was to use UEFI, and one of the SUSE people
agreed, most of the rest of the distros followed along. It makes
things a *LOT* easier for support because we have *one* boot option,
*one* installer path in anaconda so on and so forth. We could have
bodged up extlinux support like armv7 uses, and I got a lot of
pressure to do that. The little extra time it took has overwhelmingly
worth while and actually changed, and continues to, the arm eco-system
(watch the Fedora Arm space over the the next 6+ months for even more
examples of this).
From a Fedora IoT PoV we only support UEFI on any arch we support, the
reason for that is functionality IoT requires to be actually useful in
the field, and for security. While I believe BIOS boot works on x86_64
it's AFAICT
Re: Is allowed in certain cases to override default Fedora compiler flags?
On Wednesday, July 1, 2020 4:47:51 PM EDT Sergio Belkin wrote:
> 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?
This is pointing to a potential exploit in the code. In general, this is the
pattern its detecting
char user_input[BUF_SIZE];
get_user_input(user_input);
printf(user_input);
The fix is to change the printf to
printf("%s", user_input);
Hope this helps...
-Steve
___
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: rawhide - glibc/pthreads/... - broken pending mass rebuild?
Just to revisit this, my issue turned out to be a bug in a p11-kit component, opencryptoki, that failed to lock, causing its deinitialization routine to trample some stuff. That's been fixed now. Sorry for blaming glibc, Florian! :) - Alex - Original Message - > From: "Vít Ondruch" > To: devel@lists.fedoraproject.org > Sent: Thursday, July 2, 2020 4:35:27 AM > Subject: Re: rawhide - glibc/pthreads/... - broken pending mass rebuild? > > I just met something which might be of similar nature. Recent FF > 78.0-1.fc33.x86_64 fails to start with older glibc: > > > ~~~ > > $ firefox > XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so: > /usr/lib64/firefox/libxul.so: undefined symbol: pthread_getattr_np, > version GLIBC_2.32 > Couldn't load XPCOM. > > ~~~ > > > Update of glibc from glibc-2.31.9000-13.fc33.x86_64 to > glibc-common-2.31.9000-16.fc33.x86_64 resolved the issue. Nevertheless > issues like this are unexpected. There should be something, what would > force glibc update if FF requires more recent one. > > > Vít > > > Dne 01. 07. 20 v 6:57 Florian Weimer napsal(a): > > * Alex Scheel: > > > >> Is Fedora Rawhide unstable at the moment, pending a mass rebuild? > >> > >> I've seen a lot of random problems related to pthreads at the > >> moment, such as: > >> > >> 16/78 Test #12: JSS_DER_Encoding_of_Enumeration_regression_test ...Child > >> aborted***Exception: 0.99 sec > >> FINE: CryptoManager: loading JSS library > >> FINE: CryptoManager: loaded JSS library from java.library.path > >> java: ../nptl/pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion > >> `mutex->__data.__owner == 0' failed. > >> > >> > >> Another, different stack trace here (pthreads fails to lock, > >> triggering a bug in opencryptoki): > >> > >> https://pagure.io/dogtagpki/issue/3181#comment-661911 > > I don't see why this would be fixed by a mass rebuild. > > > > This is probably some sort of memory corruption: something has > > overwritten the mutex data structure, and glibc happens to detect that. > > > > Thanks, > > Florian > > ___ > > 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 > ___ > 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 > ___ 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-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
On Thursday, July 2, 2020 1:02:05 PM CEST Nicolas Mailhot via devel wrote: > If there is buy-in, it will be implemented by goodwill people. If there > is no buy-in, it won’t, normal community development process. Put > yourself in the category you want to be in, your choice, not mine. I believe that Change submission guidance is pretty clear on this: "If you have improvement in mind, work to get implementers committed to the effort _before_ filing a Change proposal, rather than expecting them to show up for work once the Change is accepted." See https://docs.fedoraproject.org/en-US/program_management/changes_guide/ Kamil > Implementation is moving the call to SRPM creation at the end of the > build process instead of relying on the SRPM as it existed at the start > of the build process. So, while it is work, it is not complex work (I’m > sure there is more than that because tuning a production process is more > than the "it works" POC stage, but that’s tuning, not reconception). > > 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 11:01 pm, Roberto Ragusa wrote: 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). Leaving space unallocated doesn't gain us anything because the user still has to manually resize both logical volumes and the partitions inside them. Our default needs to be something that doesn't require users to resize partitions. ___ 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:31 pm, Ralf Corsepius wrote: I definitely own BIOS-only systems, which have been sold long after 2005 and which are still in everyday use. If we're looking for more data points, my System76 laptop is from 2015 (still just under five years old!) and only supports legacy BIOS. ___ 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 Thu, Jul 02, 2020 at 01:16:43PM +0300, nick...@gmail.com wrote: > The only Windows that no longer supports 32-bit systems is Windows > Server. So the obsolescence of Windows 7 and XP is irrelevant. I'm not talking about *old* hardware here, which obviously works as well now as it did before. I'm talking about *new* hardware, which is vanishingly unlikely to have been tested with anything other than the current Win10 release. As Win10 certification does not mandate testing of BIOS/CSM modes, and all Windows versions that did require that have been completely EOL'd, new hardware purchased today is likely to only have had the most cursory testing in BIOS/CSM mode.. if it has BIOS/CSM support at all. (see: "Intel Dropping BIOS mode by 2020") So, yes, BIOS/CSM mode works fine for older hardware, but the simple fact of the matter is that it is going away for new hardware, so it is no longer something that can be assumed to be there or be more functionally stable than UEFI. In other words, if there are bugs/quirks/UX flaws/whatever in the Fedora's UEFI boot flow, we can no longer just say "oh, just switch to BIOS/CSM booting instead" as a functionally-acceptible workaround. But take away BIOS/CSM, and the massive complexity of grub2 becomes simply unnecessary. Simpler alternatives _should_ be considered. (Of course, Fedora will need to continue supporting BIOS-based systems for some time into the future. Speaking for myseelf, I still have two running systems that that lack UEFI; both are AMD-platform server boards, and the newer of the two was first made in 2007 and was EOL'd in 2011. Plus a small pile of VMs..) - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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
orphaned nuttcp
Hi, I've orphaned the nuttcp component. It is long time since I last used it, and I do not plan updating it again. If you like networking tools this may be a package for you! regards, Nikos ___ 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
>What about /usr/lib64/qt5/libexec/QtWebEngineProcess processes? These processes get oom_score_adj=300 out of the box, see https://pastebin.com/AFVU9U8X ___ 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 3:29 PM Alek Paunov wrote: > > On 2020-06-30 14:34, Jóhann B. Guðmundsson wrote: > > Share your thoughts and comments on how such move might affect you so > > feedback can be collected for the future on why such a change might be > > bad, how it might affect the distribution and scope of such change can > > be determined for potential system wide proposal. > > > > Just in case if someone is not aware: syslinux (pxe, ext) shipped with > Fedora is in very good state - form about 2016 I am using the package I suppose "very good state" is a relative term, upstream hasn't seen a release since 2016 so is essentially "unmaintained", not sure it supports secure boot, probably has a bunch of CVEs (see point about maintenance). I think it only lives on in Fedora is because I think it's used for some (.iso?) install method, AFIACT it's eventually glued back together when it fails to build and is generally ignored. > for all my booting needs (grub2 is too complex for me): > > * PXE/Legacy,UEFI > * Physical (partition) Legacy, ESP-UEFI > * VM Legacy - for VMs (and USB sticks) usually it is not even needed > to partition the VM disk, just extlinux the VM FS volume. > I do not tried VM/UEFI so far. > > so (in my experience) any instance will have easy switchable > UEFI/Non-UEFI boot option even if the other bootloaders discontinue > legacy mode support. > > I do not know if syslinux/extlinux have support in Anaconda, since I am > not using Anaconda for my imaging needs. > > Kind Regards, > Alek > ___ > 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 ___ 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/2/20 12:55 AM, John M. Harris Jr wrote: 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? Can you please stop calling features of systemd you don't like "systemd-bloat" at every given opportunity? It is not being respectful to those who work on the project and doesn't help your argument. ___ 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
