Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen wrote:
>
> On 7/3/20 1:41 PM, Chris Murphy wrote:
> > SSDs can fail in weird ways. Some spew garbage as they're failing,
> > some go read-only. I've seen both. I don't have stats on how common it
> > is for an SSD to go read-only as it fails, but once it happens you
> > cannot fsck it. It won't accept writes. If it won't mount, your only
> > chance to recover data is some kind of offline scrape tool. And Btrfs
> > does have a very very good scrape tool, in terms of its success rate -
> > UX is scary. But that can and will improve.
>
> Ok, you and Josef have both recommended the btrfs restore ("scrape")
> tool as a next recovery step after fsck fails, and I figured we should
> check that out, to see if that alleviates the concerns about
> recoverability of user data in the face of corruption.
>
> I also realized that mkfs of an image isn't representative of an SSD
> system typical of Fedora laptops, so I added "-m single" to mkfs,
> because this will be the mkfs.btrfs default on SSDs (right?). Based
> on Josef's description of fsck's algorithm of throwing away any
> block with a bad CRC this seemed worth testing.
>
> I also turned fuzzing /down/ to hitting 2048 bytes out of the 1G
> image, or a bit less than 1% of the filesystem blocks, at random.
> This is 1/4 the fuzzing rate from the original test.
>
> So: -m single, fuzz 2048 bytes of 1G image, run btrfsck --repair,
> mount, mount w/ recovery, and then restore ("scrape") if all that
> fails, see what we get.
What's the probability of this kind of corruption occurring in the
real world? If the probability is so low it can't practically be
computed, how do we assess the risk? And if we can't assess risk,
what's the basis of concern?
> I ran 50 loops, and got:
>
> 46 btrfsck failures
> 20 mount failures
>
> So it ran btrfs restore 20 times; of those, 11 runs lost all or
> substantially all of the files; 17 runs lost at least 1/3 of the
> files.
Josef states reliability of ext4, xfs, and Btrfs are in the same
ballpark. He also reports one case in 10 years in which he failed to
recover anything. How do you square that with 11 complete failures,
trivially produced? Is there even a reason to suspect there's residual
risk?
When metadata is single profile, Btrfs is basically an early warning
system. The available research on uncorrectable errors, errors that
drive ECC does not catch, suggests that users are decently likely to
experience at least one block of corruption in the life of the drive.
And that it tends to get worse up until drive failure. But there is
much less chance to detect this, if the file system isn't also
checksumming the vastly larger payload on a drive: the data.
--
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Fri, Jul 3, 2020 at 9:14 AM Josef Bacik wrote: > > On 7/3/20 9:37 AM, Eric Sandeen wrote: > > Does btrfsck really never attempt to salvage a metadata block with a bad > > CRC by > > validating its fields? > > No, I suppose we could, I'll add it to the list. Generally speaking if > there's > a bad checksum detected we just attempt to recover based on what we couldn't > get > access to. However that's difficult if it's a node. If it's a leaf then > usually you just lose some metadata that can be inferred from other data. For > example if you lose a leaf in the extent tree, well we can add all that > information back once we've scanned the rest of the file system and know what > extents are missing in the extent tree. > > Same goes for directory items, we detect that we are missing directory items, > but we have references for them and so we add the missing directory items that > were lost from that corrupt block. > > But again, if you lose a node you lose access to many leaves, which makes it > more likely we'll lose somehting because we'll lose the other information we > can > use to recover what was lost. The extent tree and checksum trees are > exceptions > to this, since they can be rebuilt from scratch, provided everything else is > fine. > > And then if we did decide to validate nodes, we _might_ be ok, but we might > end > up with old versions of leaves because it happens to point at something that > appears to be correct, but isn't really. Our metadata changes all the time, > so > it's not outside the realm of possiblities that the corruption points at a > seemlingly valid piece of metadata, but isn't and thus makes us do something > _really_ wrong. Thanks, Maybe it's reasonable to expect 'btrfs check --repair' to look for plausible alternatives when using non-crypto checksums that mismatch. But I'm not certain it's OK when using cryptographic checksums - how do you distinguish between incidental corruption and a malicious attack? The repair might be the attack vector. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1853992] New: perl-Test-Compile-2.4.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1853992 Bug ID: 1853992 Summary: perl-Test-Compile-2.4.1 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Compile Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 2.4.1 Current version/release in rawhide: 2.4.0-1.fc33 URL: http://search.cpan.org/dist/Test-Compile/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3388/ -- 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
[389-devel] 389 DS nightly 2020-07-06 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/06/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
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b1a8a3c29a putty-0.74-1.el6 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7b550f6ce5 python-gnupg-0.4.6-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing python-rsa-3.4.2-1.el6 Details about builds: python-rsa-3.4.2-1.el6 (FEDORA-EPEL-2020-8c3e76982e) Pure-Python RSA implementation Update Information: Fix CVE-2020-13757 ChangeLog: * Sun Jul 5 2020 Fabio Alessandro Locati - 3.4.2-1 - Update to 3.4.2 - Fix CVE-2020-13757 - Enable python3 tests * Wed Apr 29 2020 Jason Montleon - 3.4.1-3 - Rebuild * Fri Feb 14 2020 Steve Traylen - 3.4.1-2 - Add python3 build References: [ 1 ] Bug #1848507 - CVE-2020-13757 python-rsa: decryption of ciphertext leads to DoS https://bugzilla.redhat.com/show_bug.cgi?id=1848507 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 691 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 430 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 140 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 80 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19d171a465 python34-3.4.10-5.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c438b9fb89 lynis-3.0.0-1.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d749373a67 znc-1.8.1-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-af9b2ac861 alpine-2.23-2.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6ad4894c0c jbig2dec-0.12-5.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0078f6abc1 xpdf-3.04-10.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-af9c6001d1 ngircd-26-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5d348316dd chromium-83.0.4103.116-3.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-afd5c42fd6 coturn-4.5.1.3-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6949cf3502 xrdp-0.9.13.1-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2f70f49092 putty-0.74-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-28cc1451e0 python-gnupg-0.4.6-2.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing python-ansible-tower-cli-3.3.9-1.el7 python-rsa-3.4.2-1.el7 python-vcstool-0.2.12-1.el7 Details about builds: python-ansible-tower-cli-3.3.9-1.el7 (FEDORA-EPEL-2020-b5484a8f44) A CLI tool for Ansible Tower Update Information: Update ChangeLog: * Sun Jul 5 2020 Fabio Alessandro Locati - 3.3.9-1 - Update to 3.3.9 References: [ 1 ] Bug #1618786 - tower-cli ignores name provided while copying objects https://bugzilla.redhat.com/show_bug.cgi?id=1618786 python-rsa-3.4.2-1.el7 (FEDORA-EPEL-2020-0f25da8099) Pure-Python RSA implementation Update Information: Fix CVE-2020-13757 ChangeLog: * Sun Jul 5 2020 Fabio Alessandro Locati - 3.4.2-1 - Update to 3.4.2 - Fix CVE-2020-13757 - Enable python3 tests References: [ 1 ] Bug #1848507 - CVE-2020-13757 python-rsa: decryption of ciphertext leads to DoS https://bugzilla.redhat.com/show_bug.cgi?id=1848507 python-vcstool-0.2.12-1.el7 (FEDORA-EPEL-2020-8815a08804) Tool to invoke vcs commands on multiple repositories Update Information: Update to the latest `vcstool` release ChangeLog: * Thu Jul 2 2020 Scott K Logan - 0.2.12-1 - Update to 0.2.12 (rhbz#1853214) References: [ 1 ] Bug #1853214 - python-vcstool-0.2.12 is available https://bugzilla.redhat.com/show_bug.cgi?id=1853214 ___ 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-packaging] Re: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
Hi Nicolas, Nicolas Mailhot writes: >> How do I let rpm generate the changelog automatically? > > This feature is not changelog generation, just changelog bumping on > build events. You still need some other method to put non-build events > in the changelog. > > The detached changelog is just one more file in SRPM sources, which is > modified by rpmbuild at `%build` time with other files rpmbuild > modifies. The tricky part is to modify the source file as a source file > so rpmbuild adds the result to the produced SRPM (and, that does not > work in mock right now, because mock serves the SRPM that existed at > the start, not at the end of the build. Though it’s probably just a > matter of getting mock to call again its SRPM creation method at the > end of the build). So essentially you store the changelog in a separate file (like it is done in openSUSE) and use that to calculate the next release field? Given the other replies to this thread (that this is all local only, unless koji does git commits), does that mean that it's still: dist-git commit = rebuild. The "only" difference to the current state of affairs being, that I don't have to specify the Release field myself? > > The packager does not have to request the modification in his spec, > it’s done as part of the various %auto_foo calls the change introduced Could you provide an example how this would look in practice? > >> And is this related to Piere/Pingou's work on the same topic that was >> deployed to koji staging? > > It’s a different implementation, at the rpm level, that does not tie > bumping to Fedora infra (koji included). Though, it is probably > complementary to what pingou did on the changelog alimentation front. > > IMHO the design mistake so far was to conflate bumping and non-build > event changelog filling. You need to do both of course but build event > should be a build event driven by the lowest common denominator > (rpmbuild) with koji/infra scrapping rpmbuild results as usual and > exposing them to users. This is a good point imho: not every rebuild warrants a changelog entry and having both separated appears sensible to me. What I am currently missing from this proposal though is: - How is this actually even implemented? - How will this look in practice? - Given that additional files would be put into dist-git, how do we roll this back in case things go wrong? (Having thousands of "remove %autorelease" commits by releng could be an option here, albeit not a pretty one). Cheers, Dan ___ 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: Can we do away with release and changelog bumping?
Nicolas Mailhot via devel wrote: > Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit : > > It seems that several problems would just disappear if a rebuild > > would generate a unique package ID without a Git commit. > > That’s exacly what the change does. No it's not. Your key/value file must be updated in Git. Otherwise it won't remember previous release bumps. You seem to want to do the commit after building instead of before, but it's still a commit to Git that changes only the release number and the changelog. My idea is a way to *not* do that commit, neither before nor after building. Björn Persson pgp_iMlQVE_gO.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
CPE Weekly: 2020-07-05
--- title: CPE Weekly status email tags: CPE Weekly, email --- # CPE Weekly: 2020-06-218 Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. See our wiki page here for more information:https://docs.fedoraproject.org/en-US/cpe/ ## General Project Updates The CPE team have finished our Quarterly Planning for Q3, July - September, and will begin work on the following projects starting from Monday: * Data Centre Move - Final Works * CentOS Stream Phase 3 * Noggin Phase 3 * Packager Workflow Healthcare * Fedora Messaging Schemas Details of the above projects, and of projects currently in progress, done and what projects are in our backlog, can be found on our taiga board per project card: https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null We also have an updated initiative timetable for briefing in new projects to our team & key dates here:https://docs.fedoraproject.org/en-US/cpe/time_tables/ *Note: Initiatives are large pieces of work that require a team of people and weeks/months to complete. Please continue to open tickets in the normal way for bugs, issues, etc. Look out for our Q2 project achievements blog post coming soon! ### CPE Product Owner Office Hours #fedora-meeting-1 * Weekly on Thursdays @ 1300 UTC on #fedora-meeting-1 * Next Meeting: 2020-07-09 #centos-meeting * Every second Tuesday @ 1500 UTC on #centos-meeting * Next Meeting: 2020-07-07 ## Fedora Updates ### Data Centre Move * We are now officially operating under reduced Fedora services until est 28th July to facilitate the final shipment of hardware to the new data centre. * Please View project card on taiga for builder - staging - remaining app bringup dates here https://tree.taiga.io/project/amoloney1-cpe-team-projects/us/42?kanban-status=2139945 * A list of affected services is available here https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA?view * Details on what this move may mean for you can be found here https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/27U6YT73556KYW2RIFJO6J2HYMYVP22U/ * If an application is not working correctly at all, please check this list https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA?view before opening a ticket to make sure its not listed as being moved. If it is being moved, please wait a day or two, then try again. * Similarly, please be patient when opening tickets for service issues in general as we have now reached the critical point in this move and all of our sys-admins and wider teams will be assisting in the successful bringup of the reduced Fedora service and facilitation of the final hardware shipment and move. * Most recent update to devel-announce is here https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/5DNRZ4OUUNGSUJONQLEXXP3CKME43SCE/ ### AAA Replacement * User agreements for both CentOS and Fedora accounts are nearly complete. We will be able to test this in more detail once staging has been reinstalled (est July 25th due to colo move) * Fasjson now supports search feature * App migreations work still ongoing * Spam detection service is being investigated and scoped for Q3 work * Please feel free to check out the team kanban board for more information on the features the team are working on and have already completed here https://github.com/orgs/fedora-infra/projects/6 ### Mbbox * Project Dashboard here https://github.com/fedora-infra/mbbox/projects/1 * Tasks completed in the project currently * MBBox handover to CentOS Stream * The only thing that remains is putting the operator in the public operator registry which is pending Stream team feedback * MBox shared CRD is done * Deployment guide - https://mbbox-operator.readthedocs.io/en/latest/ * Blog post published - check it out here https://communityblog.fedoraproject.org/mbbox-module-building-in-a-box/ ### Gitforge We are still discussing technical aspects of the project and these are tracked here: https://gitlab.com/gitlab-org/gitlab/-/issues/217350 Planning a date in late August for an AMA session with GitLab that will be run through IRC for any questions the Fedora and CentOS communities may have to ask direct. We will keep you up to date with the developments as and when we have information to share and thank you again for your patience. ## CentOS Updates ### CentOS * New website went live (https://www.centos.org) * A new AWS CDN setup for Stream composes (https://composes.centos.org) is being worked on with a goal to have the latest stream artifacts to be publicly available and at faster speed than through normal mirror.centos.org cdn (and/or external mirrors) ### Centos Other * CentOS CI began onboarding Fedora
Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Nicolas Mailhot via devel writes: > Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit : >> Nicolas Mailhot via devel wrote: >> > So if you want to push Fedora release logic to its ultimate >> > conclusion, >> > the thing that should be in charge of committing the new >> > release/changelog build state to package history in git is bodhi, >> > not >> > koji. >> >> Why do build events need to be recorded in the Git history in the >> first place? > > The changelog is built-in the rpm format. Therefore, it needs to exists > at rpmbuild stage. Therefore, you need to record past changelog state > so new builds are consistent with previous builds. The changelog should be consistent, but it needn't record every single build event. Otherwise OBS would not work at all: the build system bumps the release field automatically on each rebuild, but it does not touch the changelog at all. Cheers, Dan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Sun, 2020-07-05 at 11:50 -0700, John M. Harris Jr wrote: > On Sunday, July 5, 2020 11:31:41 AM MST Solomon Peachy wrote: > > On Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote: > > > Chromebook devices are neither UEFI nor BIOS. You can use GPT > > > disk layout > > > while still booting BIOS, which they also don't do. Chromebook > > > devices > > > either boot with uboot -> depthcharge or Coreboot -> uboot -> > > > depthcharge. I don't see how this helps your argument. > > > > If one adds ChromeOS devices into the numbers I posted, then the > > proportion of BIOS-boot-capable, BIOS-boot-enabled, and/or BIOS- > > only > > devices on the market (and their portion of the total install base) > > goes > > down, not up. > > > > So using the absense of chromebooks in the numbers I referenced > > actually > > boosts, rather than undermines, my argument. Oh, there were > > supposedly > > 17 million chromebooks shipped in 2019, versus 261 million "PCs" > > and > > 12-ish million "servers". > > > > ...Is this horse sufficiently dead yet? > > > > - Solomon > > Actually, Coreboot has a SeaBIOS payload as well, so the x86_64 > Chromebooks > are "BIOS-boot-capable" systems. (Coreboot also has a GRUB payload, > which is > used by early Purism devices, before they switched to SeaBIOS, and is > used by > all x86_64 Libreboot systems). I can also confirm that my Acer C720 Chromebook has a SeaBIOS payload, which is the only way to go, if you want to boot something other than ChromeOS: https://www.chromium.org/a/chromium.org/dev/chromium-os/developer-information-for-chrome-os-devices/acer-c720-chromebook#TOC-Legacy-Boot The default boot method that ChromeOS uses requires the OS to be signed by Google's private key, which is a secret, so you can't boot Fedora or any other distro with it. And AFAIK, you can't install other keys, you're just supposed to use SeaBIOS for other operating systems. I don't know much about newer chromebooks, though. But I wouldn't be surprised if they are the same, since Google doesn't have much reason to adopt UEFI, provided that they control both the software and the hardware and that they have already developed a system that works. Btw, this machine is from 2013. I use it for Coreboot+SeaBIOS experiments. 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 Sunday, July 5, 2020 12:18:46 PM MST Solomon Peachy wrote: > On Sat, Jul 04, 2020 at 09:51:30PM -0700, John M. Harris Jr wrote: > > Many people on this very thread are still using BIOS boot systems, and one > > person provided a source for a NEW system they're using which is BIOS > > boot, > > while another provided factory-default BIOS configurations on hardware > > supporting UEFI. That's hardly similar the case you're referencing. > > When have I ever said those systems don't exist? All I've ever said is > that those systems represent a miniscule (and ever-shrinking) portion of > the market. > > I'd wager that more 32-bit-only x86 systems are still sold than > BIOS-boot-only ones, and Fedora already dropped support for the former. > > (btw, You keep mixing up "bios-boot-only" and "bios-boot-capable" -- > please pick one and stick with it; it'll make your arguments more > coherent) I don't keep mixing them up, but they're similar cases. As mentioned elsewhere in the thread, if the vendor disabled UEFI on UEFI-capable systems, the end user is likely to leave it that way. > > It can actually do both, I can dig up the solution that was provided to > > me, > > using GRUB2, from the thread where they tried to kill off optical media. > > Does the Fedora installer actually do this, or is it a brittle > manually-applied hack that could get trashed by anything that wants to > manipulate the MBR? (eg gparted) No, the Fedora installer doesn't create a USB boot entry.. Why would it? It was used to chainload the Fedora installer on systems that don't support USB boot. Also, it's not a hack. This is just one of the many things GRUB2 supports. It's a very powerful bootloader. > (What I did to get around this the last time was to use a small > IDE-attached CF card for /boot. That system used mdraid so it also > made for a vastly simpler partitioning layout) > > > Intel has NOT ended support for it. Anyone claiming as much is delusional > > at best. > > I'm sorry, I'm going to trust Intel's word over yours. Where has Intel actually published anything saying BIOS boot will no longer be available? I can only find articles from 2017, where it was proposed in a presentation. > > > Every one of those shipped Apple and Windows-based systems boots using > > > UEFI. > > > > That's not the case, as cited earlier in this thread. > > Please actually *read* what I am writing. That 94% market share > represents *new systems* *shipped* with Apple or Microsoft operating > systems. > > Macs have been UEFI-only since 2007, and since 2012 Microsoft has > required UEFI for systems shipping with Windows 8 (or newer) Thus, every > one of the 253 million Windows and Mac systems shipped in 2019 were > booting with UEFI. Furthermore, starting in November 2016 Microsoft > disallowed new system sales with Windows 7 (ie the last of the > non-EFI-required-for-preinstalls version) -- so every system shipped > with Windows or MacOS in the past *four years* has required use of UEFI. > (That's more than a *billion* systems!) That's simply false, that "every system shipped with Windows or MacOS in the past *four years* has required use of UEFI." Whether you want to accept it or not, vendors are still selling systems with Windows installed with BIOS boot. It may be true for MacOS, but that's its own little walled garden. I can't say when they started using UEFI, and it doesn't really matter. When a proprietary software vendor started using something doesn't have any bearing on what we should support in the Fedora project. > ...Seriously, these are hard facts, and not something up for debate. See above. > > Based on what? Are you assuming Linux is only on servers? > > No, as I wrote, I assumed Linux is on all servers and 2% of non-server > PCs, for a combined total of aobut 6% of 2019 shipped units. The real > numbers are less than this, as not all servers are shipped with/for > Linux, and that 2% desktop linux represents the estimated install base > rather than shipping market share. > > > As cited elsewhere in this thread, most servers, in fact, do have > > better BIOS support than UEFI support, with some weird quirks. > > You act like there have never been "wierd quirks" with BIOS-based > systems, especially in the takes-five-minutes-to-get-to-grub server > realm. That's not a bug or quirk, some servers just take a long time to do checks with their BMC and other internals. It doesn't take 5 minutes, however. > Vendor firmware bugs are a fact of life. Some get fixed; most others > have to be worked around one way or another. I've not run into a case where using GRUB didn't work around vendor firmware bugs related to booting a given system. > > As well as any small to medium OEM. Most OEMs don't actually care about > > Windows Certification. > > Anyone selling systems with Windows preinstalled will care, which means > their suppliers and OEMs will care, because they don't want to get > locked out of
Re: The future of legacy BIOS support in Fedora.
On Sun, Jul 05, 2020 at 07:18:47PM -, Tom Seewald wrote: > In terms of physical x86 systems, you are right that UEFI is the > overwhelming majority. But as stated elsewhere in this thread, a lot > of cloud providers and virtualization software default to using BIOS. > So I think Fedora should only start considering dropping BIOS support > once the default is UEFI on most virtualization platforms. FWIW, I completely agree with this. - 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: The future of legacy BIOS support in Fedora.
On Sat, Jul 04, 2020 at 09:51:30PM -0700, John M. Harris Jr wrote: > Many people on this very thread are still using BIOS boot systems, and one > person provided a source for a NEW system they're using which is BIOS boot, > while another provided factory-default BIOS configurations on hardware > supporting UEFI. That's hardly similar the case you're referencing. When have I ever said those systems don't exist? All I've ever said is that those systems represent a miniscule (and ever-shrinking) portion of the market. I'd wager that more 32-bit-only x86 systems are still sold than BIOS-boot-only ones, and Fedora already dropped support for the former. (btw, You keep mixing up "bios-boot-only" and "bios-boot-capable" -- please pick one and stick with it; it'll make your arguments more coherent) > It can actually do both, I can dig up the solution that was provided to me, > using GRUB2, from the thread where they tried to kill off optical media. Does the Fedora installer actually do this, or is it a brittle manually-applied hack that could get trashed by anything that wants to manipulate the MBR? (eg gparted) (What I did to get around this the last time was to use a small IDE-attached CF card for /boot. That system used mdraid so it also made for a vastly simpler partitioning layout) > Intel has NOT ended support for it. Anyone claiming as much is delusional at > best. I'm sorry, I'm going to trust Intel's word over yours. (Now if Intel has backtracked or changed their plans to "require UEFI class 3 on all client and datacenter platforms by 2020", they've not seemed to have publicly stated that anywhere) > > Every one of those shipped Apple and Windows-based systems boots using > > UEFI. > > That's not the case, as cited earlier in this thread. Please actually *read* what I am writing. That 94% market share represents *new systems* *shipped* with Apple or Microsoft operating systems. Macs have been UEFI-only since 2007, and since 2012 Microsoft has required UEFI for systems shipping with Windows 8 (or newer) Thus, every one of the 253 million Windows and Mac systems shipped in 2019 were booting with UEFI. Furthermore, starting in November 2016 Microsoft disallowed new system sales with Windows 7 (ie the last of the non-EFI-required-for-preinstalls version) -- so every system shipped with Windows or MacOS in the past *four years* has required use of UEFI. (That's more than a *billion* systems!) ...Seriously, these are hard facts, and not something up for debate. > Based on what? Are you assuming Linux is only on servers? No, as I wrote, I assumed Linux is on all servers and 2% of non-server PCs, for a combined total of aobut 6% of 2019 shipped units. The real numbers are less than this, as not all servers are shipped with/for Linux, and that 2% desktop linux represents the estimated install base rather than shipping market share. > As cited elsewhere in this thread, most servers, in fact, do have > better BIOS support than UEFI support, with some weird quirks. You act like there have never been "wierd quirks" with BIOS-based systems, especially in the takes-five-minutes-to-get-to-grub server realm. Vendor firmware bugs are a fact of life. Some get fixed; most others have to be worked around one way or another. > As well as any small to medium OEM. Most OEMs don't actually care about > Windows Certification. Anyone selling systems with Windows preinstalled will care, which means their suppliers and OEMs will care, because they don't want to get locked out of the massive market that Windows represents. (Small Boutique OEMs and embedded/industrial niches notwithstanding, of course. There's a _very_ long tail of stuff like that. FFS, look at the diehard Amiga folks..) > Let's be honest, neither my numbers nor yours even matter in this, > beyond subjective arguments. If we want to make objective claims based > on numbers, we'd need to figure out how many Fedora users have systems > 1) supporting UEFI 2) using UEFI. Of course. We need actual numbers if we're to make informed decisions. Anectdotally, of the sxiteen physical Fedora/CentOS x86 systems I'm directly responsible for, all but two support (and also boot from) UEFI. I hope to finally re-retire the older of the two in a few weeks, replacing it with a machine only half its age. (There's also a small pile of VMs too, generally used as build hosts or for QA-type work. Nearly all are considered disposable and can be easily recreated) For the record, I think any notion of auto-migrating systems from BIOS to UEFI booting is insane. And any talk of retiring BIOS support in Fedora should probably be put off until the F40 timeframe. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature
Re: The future of legacy BIOS support in Fedora.
> BIOS-based systems make up a miniscule minority of the current market. > Pretending otherwise is delusional, and delusions are no basis for > technical decisions. > > - Solomon In terms of physical x86 systems, you are right that UEFI is the overwhelming majority. But as stated elsewhere in this thread, a lot of cloud providers and virtualization software default to using BIOS. So I think Fedora should only start considering dropping BIOS support once the default is UEFI on most virtualization platforms. ___ 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 Sun, Jul 5, 2020 at 12:41 PM Nicolas Mailhot via devel wrote: > > Le dimanche 05 juillet 2020 à 12:21 -0600, Chris Murphy a écrit : > > > > specification != standard > > I, for one, am very happy that the systemd project makes the effort of > documenting its formats so others can write competing implementations > or write software that interacts with the systemd implementation. > > That’s several orders of magnitude better than the usual my code is the > best, copy whatever undocumented thing I did by accident in my last > commit, this is the reference implementation, I won’t commit to > anything and I will change it at will without notification in the > future. > > Thank you Lennart for understanding what we meant when we asked you to > engage with standards like the FHS years ago, and for not embarking > upon blackbox unspecified coding. > > We all hate writing documentation and formal specifications are among > the most exhausting documentation one may write. > > And, nothing wrong with writing a spec for things not specified yet, > quite the countrary. Agreed. This is a better response. Thanks Lennart! -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Sunday, July 5, 2020 11:31:41 AM MST Solomon Peachy wrote: > On Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote: > > Chromebook devices are neither UEFI nor BIOS. You can use GPT disk layout > > while still booting BIOS, which they also don't do. Chromebook devices > > either boot with uboot -> depthcharge or Coreboot -> uboot -> > > depthcharge. I don't see how this helps your argument. > > If one adds ChromeOS devices into the numbers I posted, then the > proportion of BIOS-boot-capable, BIOS-boot-enabled, and/or BIOS-only > devices on the market (and their portion of the total install base) goes > down, not up. > > So using the absense of chromebooks in the numbers I referenced actually > boosts, rather than undermines, my argument. Oh, there were supposedly > 17 million chromebooks shipped in 2019, versus 261 million "PCs" and > 12-ish million "servers". > > ...Is this horse sufficiently dead yet? > > - Solomon Actually, Coreboot has a SeaBIOS payload as well, so the x86_64 Chromebooks are "BIOS-boot-capable" systems. (Coreboot also has a GRUB payload, which is used by early Purism devices, before they switched to SeaBIOS, and is used by all x86_64 Libreboot systems). People are still using systems from before 2019. More importantly, people are still using systems from 2010-2012 in Fedora, as demonstrated by this thread. -- 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.
Le dimanche 05 juillet 2020 à 12:21 -0600, Chris Murphy a écrit : > > specification != standard I, for one, am very happy that the systemd project makes the effort of documenting its formats so others can write competing implementations or write software that interacts with the systemd implementation. That’s several orders of magnitude better than the usual my code is the best, copy whatever undocumented thing I did by accident in my last commit, this is the reference implementation, I won’t commit to anything and I will change it at will without notification in the future. Thank you Lennart for understanding what we meant when we asked you to engage with standards like the FHS years ago, and for not embarking upon blackbox unspecified coding. We all hate writing documentation and formal specifications are among the most exhausting documentation one may write. And, nothing wrong with writing a spec for things not specified yet, quite the countrary. 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: The future of legacy BIOS support in Fedora.
On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering wrote: [snip] > > Please submit additions to the spec as PRs to systemd github. We added > a number of new keys in the past that sd-boot itself doesn't make use > of (devicetree and such), and we'd be delighted to add more if they > make sense and that helps. > Thanks. I'll discuss this with the rest of the bootloader folks and think how the spec could be extended to cover the remaining cases where variable expansion is still used for GRUB. The new keys could be generic and even benefit other bootloaders if they implement these features at some point (e.g: boot entries protection). Best regards, Javier ___ 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 Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote: > Chromebook devices are neither UEFI nor BIOS. You can use GPT disk layout > while still booting BIOS, which they also don't do. Chromebook devices either > boot with uboot -> depthcharge or Coreboot -> uboot -> depthcharge. I don't > see how this helps your argument. If one adds ChromeOS devices into the numbers I posted, then the proportion of BIOS-boot-capable, BIOS-boot-enabled, and/or BIOS-only devices on the market (and their portion of the total install base) goes down, not up. So using the absense of chromebooks in the numbers I referenced actually boosts, rather than undermines, my argument. Oh, there were supposedly 17 million chromebooks shipped in 2019, versus 261 million "PCs" and 12-ish million "servers". ...Is this horse sufficiently dead yet? - 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: The future of legacy BIOS support in Fedora.
On Sun, Jul 5, 2020 at 11:26 AM John M. Harris Jr wrote: > > On Sunday, July 5, 2020 3:07:44 AM MST Lennart Poettering wrote: > > On Sa, 04.07.20 18:11, John M. Harris Jr (joh...@splentity.com) wrote: > > > > > > > That systemd throws some crap out doesn't make it a standard. There's no > > > reason for GRUB to adopt this, or for anyone else to use this. > > > > > > "bloat", "crap", … > > > > I am sorry, but you are apparently just a troll and this is the point > > where I will now ignore you. > > > > Just stop being so awful and dismissive, this is not constructive. > > Lennart, > > This behavior, which is identical to what has drawn attention to your handling > of GitHub issues recently, simply dismissing them as trolls or conspiracy > theorists, is why I'm saying that. systemd is not a standards body. It's an > init system. specification != standard You're calling it something it doesn't claim to be and then criticizing it. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Sunday, July 5, 2020 8:12:33 AM MST Markus Larsson wrote: > I have no problem with GRUB2 or sd-boot. I have much more problems with > refind and their ilk. While things can look pretty, that's fine, as soon as > it gets in my way when I try to get things done it stops being fine. I don't think there's anything visually wrong with systemd-boot, so long as it's showing a menu like gummiboot did. > As I said earlier, I have no problems with sd-boot or the looks of it (it > seems that is what we are discussing now). I see no real problems with > using it as default for EFI systems. That's just an opinion though. It does > what it does and shows what is needed. Actually, it doesn't do enough to be able to actually boot Fedora systems. Please note that full disk encryption is a supported scenario in Fedora, as is encrypted /boot or /boot on Btrfs. systemd-boot is not capable of getting bootloader configuration files in this case, so your system will never boot. As for making it the default, I can't see any reason to do that. Standardizing on the best bootloader seems like the safe bet, i.e. use GRUB2 everywhere possible, and support boot from u-boot, zipl, petitboot, etc. where it's not available. -- 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 Sunday, July 5, 2020 3:07:44 AM MST Lennart Poettering wrote: > On Sa, 04.07.20 18:11, John M. Harris Jr (joh...@splentity.com) wrote: > > > > That systemd throws some crap out doesn't make it a standard. There's no > > reason for GRUB to adopt this, or for anyone else to use this. > > > "bloat", "crap", … > > I am sorry, but you are apparently just a troll and this is the point > where I will now ignore you. > > Just stop being so awful and dismissive, this is not constructive. Lennart, This behavior, which is identical to what has drawn attention to your handling of GitHub issues recently, simply dismissing them as trolls or conspiracy theorists, is why I'm saying that. systemd is not a standards body. It's an init system. -- 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 Sunday, July 5, 2020 6:18:50 AM MST Solomon Peachy wrote: > On Sun, Jul 05, 2020 at 08:52:12AM +0200, Nicolas Mailhot via devel wrote: > > So you want to discuss Linux desktop deployments, excluding the only > > sucessful mass Linux desktop deployment to date? Why? > > Because the raw data I had access to excludes chromebooks, only listing > "traditional" PCs and servers. They lumped chromebooks in with tablets > and other such things, and I'm not going to spend several thousand > dollars to buy market reports just for a stupid thread on fedora-devel. > > Additionally, all chromebooks boot with u-boot on top of a UEFI/GPT disk > layout. The x86 ones supposedly use coreboot to load u-boot: > > https://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format > > Needless to say, this actually *helps* my argument, as including > ChromeOS systems into those numbers will further decrease the overall > BIOS-capable (and thus, BIOS-only) market share. Chromebook devices are neither UEFI nor BIOS. You can use GPT disk layout while still booting BIOS, which they also don't do. Chromebook devices either boot with uboot -> depthcharge or Coreboot -> uboot -> depthcharge. I don't see how this helps your argument. -- 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: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Le dimanche 05 juillet 2020 à 18:41 +0200, Nicolas Mailhot a écrit : > > While timestamping would remove the need to pass the last build info > to the next one it would also break all the workflows where several > rebuilds are done in parallel for separate needs, and the latest > rebuild is not necessarily the one you want to keep. (This is why git is not relying on timestamps to construct commit timelines, for example. A reliable timeline system knows what change occured before the next one.) -- 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: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit : > Nicolas Mailhot via devel wrote: > > So if you want to push Fedora release logic to its ultimate > > conclusion, > > the thing that should be in charge of committing the new > > release/changelog build state to package history in git is bodhi, > > not > > koji. > > Why do build events need to be recorded in the Git history in the > first place? The changelog is built-in the rpm format. Therefore, it needs to exists at rpmbuild stage. Therefore, you need to record past changelog state so new builds are consistent with previous builds. You may argue that the existence of scms like git makes built-in changelogs irrelevant. People that have to debug problems in systems that mix packages sources will disagree – they have no wish to comb multiple external scms to find what was changed in a package set that breaks (hard to do when the thing that broke is networking for example). And, even if you removed completely the changelog from the rpm format, you’d still need to manage package releases. > So why is NEVR required to change when nothing in the package source > has changed? The NEVR is required to change because you need to publish a new package ID to clients, so clients know they have an update to deploy. That has nothing to do with koji limitations, it’s a requirement or the rpm update system, or pretty much any change management system for that matter. > It seems that several problems would just disappear if a rebuild > would generate a unique package ID without a Git commit. That’s exacly what the change does. > Here's an idea: We could mandate that Release must expand a macro > called buildtag. This macro would have a new value every time, > monotonically increasing. A timestamp seems easiest, but that should > bean implementation detail that could be changed without breaking > things. Because things are slightly more complex than you think they are, the counter is not just a timestamp, and there are two not one counter, but yes, again, that’s exacly what the change does. > (The build time is already stored in packages, and could > theoretically be used to tell builds apart, but that would require > changes to lots of tools I guess.) The build time by itself is not sufficient because you have branches, and scratch builds (which are basically abandonware branches) so parallel package history exists and a single monotonic timeline can not represent that. Nevertheless the last build time is useful (for changelog bumping, if nothing else) and is one of the things the change stores as past state (you could try to deduce it from other things, but why bother, a timestamp variable is cheap and easy to manipulate). > Mass rebuilds would no longer make any Git commits. They would just > take the latest version and submit it for building. Again, that’s basically what the change does. A build stores counters and date as they existed as the time of the build in one of the SRPM source files. The next build reads this file and computes a higher release. No external bump script involved. No spec file change required. The spec file can be left unchanged forever, the release info in there is just the last release someone made a change to the spec files, and everything autobumps from there. All you need is to pass the "last build" info from one build to another, which is done via importing the results of last build at the start of the new build. Since the import relies on SRPM content and nothing else you can even move the build chain from one buildsystem to another it will still work. While timestamping would remove the need to pass the last build info to the next one it would also break all the workflows where several rebuilds are done in parallel for separate needs, and the latest rebuild is not necessarily the one you want to keep. 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: The future of legacy BIOS support in Fedora.
On Sun, 5 Jul 2020 at 11:23, Markus Larsson wrote: > > > > On 5 July 2020 16:27:07 CEST, Stephen John Smoogen wrote: > >On Sat, 4 Jul 2020 at 11:34, Neal Gompa wrote: > >> > >> On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering > >> wrote: > >> > > >> > On Mi, 01.07.20 21:06, Neal Gompa (ngomp...@gmail.com) wrote: > >> > > > > >There is a very different car from what a gear head will design from a > >person who wants to enjoy driving their car. A gear head will want an > >easy to fix car with very few things hard to get to. The problem is > >that usually makes the vehicle noisy, uncomfortable and ugly. The > >majority of car drivers want something where all those parts are > >nicely hidden because they like a quiet smooth ride. The same is with > >computers.. If we want to be able to work on the computers we want a > >lot of places we can get into the deep internals and mess around. If > >we want to use the computer day to day without needing to spend 10 > >years learning how to take it apart and put it together.. We want > >something completely different. In the end, the vast majority of > >people want things which are hidden away and just do the thing they > >are supposed to do.. we computer grease monkeys just need to charge > >more to work on them. > > There's no reason there can't be a glossy front hiding what techs really > wants. Just look at the bootsplash. Looks pretty but just push a button and > you will get actual useful data instead, everybody wins. > That said, I don't think you are wrong per se. I just think there can we can > coexist with the help of smart solutions. > Usually the only time I deal with the bootsplash is when the system is broken in a way that hitting a key won't remove it... so I end up removing rhgb/quiet and other things. The fact that I can do that is all I care about.. I get grumpy when proposals want to make that impossible to be done for whatever reasons. Especially since I will somehow have to fix it when it breaks but have to get an arc welder to cut open parts first. That said, I am not against sd-boot, btrfs, nano or a bunch of other changes which seem to have gotten every 'stop the change' advocate out there. I understand a little of where they are coming from... fixing things are hard enough at times. I also understand what it is like to be overloaded with everything going on these days and just want things to stop for a bit. The problem is that doesn't happen, and it definitely doesn't happen in Fedora. If people need a slower or stopped OS, there is CentOS or Debian Stable. Fedora isn't as bleeding edge as other Linux distributions... but it is constantly moving and it is always going to be a bumpy road. > As I said earlier, I have no problems with sd-boot or the looks of it (it > seems that is what we are discussing now). I see no real problems with using > it as default for EFI systems. That's just an opinion though. It does what it > does and shows what is needed. > As for keeping BIOS, yes of course but that seems settled 100 mails ago :) > I generally argue that I want Fedora to run on as much different things as > possible and devices and motherboards with defective UEFI or no UEFI will be > here for a while. > > M > > > > > > ___ > 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 -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] apcupsd now available on EPEL 8
Good day, package "apcupsd" (client for APC Uninterruptible Power Supply) is now available on EPEL 8. So if you own such UPS and an Enterprise Linux 8 workstation you can enjoy using this service. Best regards ___ 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
Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Nicolas Mailhot via devel wrote:
> So if you want to push Fedora release logic to its ultimate conclusion,
> the thing that should be in charge of committing the new
> release/changelog build state to package history in git is bodhi, not
> koji.
Why do build events need to be recorded in the Git history in the first
place? A version control system is supposed to track changes to the
source code. A rebuild that doesn't change any sources, patches,
scriptlets or metadata shouldn't need to change anything in Git.
As far as I can tell, this happens only because Koji refuses to build a
NEVR that has been built before, so a rebuild requires a new release
number, which requires an RPM changelog entry, and both of those are
defined in the spec, which is stored in Git.
So why is NEVR required to change when nothing in the package source
has changed? Apparently because *other* packages are likely to have
changed: new versions of libraries, compiler et cetera causing
differences in the generated code. That's the usual reason for rebuilds
after all. But if one takes a source package and rebuilds it locally,
then one won't have the same version of every other package, so one
gets another binary package with the same NEVR but probably different
binary code.
It seems that several problems would just disappear if a rebuild would
generate a unique package ID without a Git commit. Instead of a lot of
complex tooling to automate release and changelog bumping, I would like
to see the need for release and changelog bumping go away.
Here's an idea: We could mandate that Release must expand a macro
called buildtag. This macro would have a new value every time,
monotonically increasing. A timestamp seems easiest, but that should be
an implementation detail that could be changed without breaking things.
The macro could be defined like this for example:
%buildtag .%(date +%%s)
It would be used in each spec like this:
Release: 1%{?dist}%{?buildtag}
Putting the buildtag after the disttag makes it possible to change how
the buildtag is generated in a future Fedora release without breaking
upgrade paths.
(The build time is already stored in packages, and could theoretically
be used to tell builds apart, but that would require changes to lots of
tools I guess.)
Mass rebuilds would no longer make any Git commits. They would just
take the latest version and submit it for building. The release number
would remain as a downstream version number. Packagers would update the
release number when they make actual changes to the package. When one
wants a specific version of a package, one would look at the version
and release numbers, ignoring the buildtag. The buildtag would
distinguish between different builds of the same version-release.
What flaws can you all find in this idea?
Björn Persson
pgpIGk2i3K6iH.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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Sun, Jul 5, 2020 at 12:46 AM John M. Harris Jr wrote: > > On Saturday, July 4, 2020 11:27:47 PM MST Alexey Avramov wrote: > > >Linux handles low memory situations just fine, but it's much better if you > > > > have an appropriately sized swap partition and let the kernel do its job > > > > No, by default Linux can hang at low memory condition. Huge swap space will > > not help you if a leak occurs. With a large swap space, the hang can happen > > later, but it can still happen. Another point is that the swap space is > > slow. With fast leaks and slow swap space, freezing is possible throughout > > the entire swap filling time. A typical problem: "once all the ram is used > > up the whole system freezes as swap starts getting full, but really the > > whole system is completely locked-up. I thought my swapfile was too small > > so I made it match my ram (12 GB) but the system still gets frozen" [1]. > > Sure, swap is slower than RAM. That's fine. We don't need it to be as fast as > RAM, that's not what it's for. It's for things that can be swapped out, > because it's loaded into memory, but not actively used. RAM doesn't "fill" > until long after unused things have been swapped out. Eviction of inactive anonymous pages isn't what causes the problem under discussion. That's fairly efficient and exactly what swap is well suited for. The problem is when the workload has greater demand for memory, than there is RAM. That can cause two events to happen: reclaim (file page faults), and eviction of active anonymous pages. Both lead to "thrashing" and can completely clobber all responsibility of a system, for more than a few reasons, but one of those is by directly causing significant IO pressure. In these cases, you simply need more RAM right now. The idea of resource control suggests providing a minimum guarantee of IO for the processes required to maintain system responsiveness, thereby restricting IO demand by other processes. The same is applied to memory and CPU. > > > >If you didn't mean for the program to use as much memory as it tried to, > > >the correct solution would be to use cgroups. > > > > > > 1. This is not configured by default. > > 2. This can be inconvenient even for advanced users. > > 3. Quick leaks can happen unexpectedly. > > What software in the default image leads to low memory issues? Web browsers? > If so, there's a simple solution to this. We can put a default cgroup on web > browsers so they don't take over the OS. Pretty much. It'll actually work in reverse where a specific stack is "protected" or given minimum resource guarantees via cgroups - and that will automagically translate into everything else having resources clamped down. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 5 July 2020 16:27:07 CEST, Stephen John Smoogen wrote: >On Sat, 4 Jul 2020 at 11:34, Neal Gompa wrote: >> >> On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering >> wrote: >> > >> > On Mi, 01.07.20 21:06, Neal Gompa (ngomp...@gmail.com) wrote: >> > >> > > The user-interactive portion of sd-boot is *awful*. I know our GRUB >> > > looks ugly by default these days too, but it doesn't have to be, and >> > > most distros actually do make it look semi-decent. >> > >> > BTW, the current look of systemd-boot was proposed by some GNOME >> > designers back in the day. We just implemented what they wanted. >> > >> >> Now I'm even less surprised. It was probably designed with the idea >> that it would never be seen. If any designer people actually wanted to >> make a good boot manager experience, they should take cues from >> Windows, macOS, or even rEFInd. >> >> > >It was probably designed on that idea by people who don't spend as >much time staring at bootloaders as they do operating systems. For the >overwhelming majority of people using computers they are not going to >spend a lot of time making choices in a bootloader or things like >that. For system administrators and operating system developers.. that >is not the case. For most of the computers I manage, I never actually >log onto them UNLESS I am going to be dealing with the boot loader. So >of course the UI is going to be very important to me and I want it to >do a lot of things it probably shouldn't. Mainly because if I have >been called to deal with said computer, something has gone very wrong >and I am going to be trying to make it right. I have no problem with GRUB2 or sd-boot. I have much more problems with refind and their ilk. While things can look pretty, that's fine, as soon as it gets in my way when I try to get things done it stops being fine. > >There is a very different car from what a gear head will design from a >person who wants to enjoy driving their car. A gear head will want an >easy to fix car with very few things hard to get to. The problem is >that usually makes the vehicle noisy, uncomfortable and ugly. The >majority of car drivers want something where all those parts are >nicely hidden because they like a quiet smooth ride. The same is with >computers.. If we want to be able to work on the computers we want a >lot of places we can get into the deep internals and mess around. If >we want to use the computer day to day without needing to spend 10 >years learning how to take it apart and put it together.. We want >something completely different. In the end, the vast majority of >people want things which are hidden away and just do the thing they >are supposed to do.. we computer grease monkeys just need to charge >more to work on them. There's no reason there can't be a glossy front hiding what techs really wants. Just look at the bootsplash. Looks pretty but just push a button and you will get actual useful data instead, everybody wins. That said, I don't think you are wrong per se. I just think there can we can coexist with the help of smart solutions. As I said earlier, I have no problems with sd-boot or the looks of it (it seems that is what we are discussing now). I see no real problems with using it as default for EFI systems. That's just an opinion though. It does what it does and shows what is needed. As for keeping BIOS, yes of course but that seems settled 100 mails ago :) I generally argue that I want Fedora to run on as much different things as possible and devices and motherboards with defective UEFI or no UEFI will be here for a while. M > > ___ 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 Sat, 4 Jul 2020 at 11:34, Neal Gompa wrote: > > On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering > wrote: > > > > On Mi, 01.07.20 21:06, Neal Gompa (ngomp...@gmail.com) wrote: > > > > > The user-interactive portion of sd-boot is *awful*. I know our GRUB > > > looks ugly by default these days too, but it doesn't have to be, and > > > most distros actually do make it look semi-decent. > > > > BTW, the current look of systemd-boot was proposed by some GNOME > > designers back in the day. We just implemented what they wanted. > > > > Now I'm even less surprised. It was probably designed with the idea > that it would never be seen. If any designer people actually wanted to > make a good boot manager experience, they should take cues from > Windows, macOS, or even rEFInd. > > It was probably designed on that idea by people who don't spend as much time staring at bootloaders as they do operating systems. For the overwhelming majority of people using computers they are not going to spend a lot of time making choices in a bootloader or things like that. For system administrators and operating system developers.. that is not the case. For most of the computers I manage, I never actually log onto them UNLESS I am going to be dealing with the boot loader. So of course the UI is going to be very important to me and I want it to do a lot of things it probably shouldn't. Mainly because if I have been called to deal with said computer, something has gone very wrong and I am going to be trying to make it right. There is a very different car from what a gear head will design from a person who wants to enjoy driving their car. A gear head will want an easy to fix car with very few things hard to get to. The problem is that usually makes the vehicle noisy, uncomfortable and ugly. The majority of car drivers want something where all those parts are nicely hidden because they like a quiet smooth ride. The same is with computers.. If we want to be able to work on the computers we want a lot of places we can get into the deep internals and mess around. If we want to use the computer day to day without needing to spend 10 years learning how to take it apart and put it together.. We want something completely different. In the end, the vast majority of people want things which are hidden away and just do the thing they are supposed to do.. we computer grease monkeys just need to charge more to work on them. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Sun, Jul 05, 2020 at 08:41:16AM +0200, Nicolas Mailhot via devel wrote: > Those things are not meant to run ancient software. They are meant to > run a very long time. And yes at the end of this time the software is > ancient. Of course. > That does not mean it is ancient at the start of the system lifecycle If the new embeded or industrial-type system being deployed is BIOS-only (you know, the entire point of this silly thread) then its underlying hardware platform (and the software running on top of it) is nowhere near the start of its lifecycle, ie it's relatively "ancient". (See my ealier point about Intel continuing to produce 80386 and 80486 CPUs until 2007) (In 2011 the folks I worked for purchased a brand-new bit of kit for their PCB production line. The system booted up into Windows NT4, which had been completely EOL'd in 2004, because it used custom hardware that relied on drivers that didn't run on anything newer. This same line had a reflow oven powered by a 386 running DOS..) - 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: Problem with auto CMake out-of-source builds?
On Sun, Jul 5, 2020 at 8:20 AM Neal Gompa wrote: > Temporarily, we have %__cmake_in_source_build set, which forces back > the legacy behavior. You can switch to the upcoming out of source > default by adding the following to the top of your spec: > Ok, so during this transition period the current CMake guidelines are wrong? # Force out of source build > %undefine __cmake_in_source_build > > With that, you can use %cmake with no arguments and everything should work > fine. > Will this work for all current Fedora and EPEL releases? 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: The future of legacy BIOS support in Fedora.
I don't know about how important EFI and reducing the bootloader technical debt is for the project, but at least for me personally, it will be a straight way out. My hard disk has a traditional MBR based structure with about a TB of very important data. I don't know of a 100% reliable way of converting it to GPT. While I do have backup for most important files, not everything is backed up nor do I have means to do so. The system works perfectly fine for me and I see no reason why I should opt for EFI. What is the value add for me, at least till I don't upgrade to a newer system? which I won't be at least for next 2 years. So forcing such a no-value-add change to existing user will drive them away. At least I would opt for a different distro in such case even though it's not something I want to do. I feel the better approach would be to use it as default for new installations, if the disks are appropriately formatted or are empty at the time of installation. Else a fall back to grub should be transparently done. Just my 2 cents from a user's perspective. ___ 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: Problem with auto CMake out-of-source builds?
On Sun, Jul 5, 2020 at 9:16 AM Richard Shaw wrote:
>
> I saw the change notification but didn't know it went in to "production". I
> was trying to build OpenImageIO in rawhide and it failed, because I was
> already doing an out of source build which it appended
> "%{_arch}-redhat-linux-gnu" or something like that to.
>
> So I looked up the guidelines for CMake which state:
>
> %build
> %cmake .
> %make_build
>
>
> Oookay... Now OIIO CMake config is giving me:
>
> CMake Error at CMakeLists.txt:50 (message):
> Not allowed to run in-source build!
>
> And low and behold I see new options being passed to CMake...
>
> + /usr/bin/cmake -S . -B .
>
> Which point the source and binary locations to the same directory.
>
> So I was all for the change other than the fact I was already doing
> out-of-source builds for all of the CMake packages I maintain, which this
> breaks, and right now the "automagic" seems to be broken as well.
>
Temporarily, we have %__cmake_in_source_build set, which forces back
the legacy behavior. You can switch to the upcoming out of source
default by adding the following to the top of your spec:
# Force out of source build
%undefine __cmake_in_source_build
With that, you can use %cmake with no arguments and everything should work fine.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Sun, Jul 05, 2020 at 08:52:12AM +0200, Nicolas Mailhot via devel wrote: > So you want to discuss Linux desktop deployments, excluding the only > sucessful mass Linux desktop deployment to date? Why? Because the raw data I had access to excludes chromebooks, only listing "traditional" PCs and servers. They lumped chromebooks in with tablets and other such things, and I'm not going to spend several thousand dollars to buy market reports just for a stupid thread on fedora-devel. Additionally, all chromebooks boot with u-boot on top of a UEFI/GPT disk layout. The x86 ones supposedly use coreboot to load u-boot: https://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format Needless to say, this actually *helps* my argument, as including ChromeOS systems into those numbers will further decrease the overall BIOS-capable (and thus, BIOS-only) market share. > Also your data conflates systems sold in with systems in use in > . No, it does not; these commercial market report previews I used cover revenue and units shipped in 2019, not total install base. (those are also available, but I'm not going to fork over several thousand dollars over a stupid fedora-devel thread) That said, I did deliberately conflate the two in one place -- I used the "2%" linux desktop install base as a proxy for "market share", but acknowledged that, and assigned those numbers to the "BIOS" side. If someone has numbers that show the actual install base of in-use BIOS-boot and BIOS-only systems, I'd love to see them. And I'll gladly donate the contents of my wallet to the EFF if the BIOS numbers are still growing in absolute terms -- ie new systems being deployed faster than old ones are retired. - 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
Problem with auto CMake out-of-source builds?
I saw the change notification but didn't know it went in to "production". I
was trying to build OpenImageIO in rawhide and it failed, because I was
already doing an out of source build which it appended
"%{_arch}-redhat-linux-gnu" or something like that to.
So I looked up the guidelines for CMake which state:
%build
%cmake .
%make_build
Oookay... Now OIIO CMake config is giving me:
CMake Error at CMakeLists.txt:50 (message):
Not allowed to run in-source build!
And low and behold I see new options being passed to CMake...
+ /usr/bin/cmake -S . -B .
Which point the source and binary locations to the same directory.
So I was all for the change other than the fact I was already doing
out-of-source builds for all of the CMake packages I maintain, which this
breaks, and right now the "automagic" seems to be broken as well.
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: Help (or take over) hedgewars?
Thanks for the offers everyone, and let me know if you just REALLY want to help maintain it, but I found a new contributor who's a core developer of Pascal, which is 90% of what hedgewars is written in, who is interested in the job. 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: Strange rpmbuild begaveour
On 7/5/20 2:21 PM, TI_Eugene wrote:
> Two builds for tests:
> 1. https://koji.fedoraproject.org/koji/taskinfo?taskID=46635276
> 2. https://koji.fedoraproject.org/koji/taskinfo?taskID=46635342
>
> The deferrence between them - libraries permissions.
>
> Problems are:
> 1. %{make_install} installs libraries with 0755 flags
> 2. After changing library files mode into 0644 rpmbuild not extracts
> debug info
Yes, the exec bits are used as indicators whether those files should be
processed or not. It takes the permission bits from the disk so you can
change them in the file list independently.
> Where I'm wrong?
> ___
> 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
--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill,
Thomas Savage
___
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: Self Introduction: Nikolay Nikolov
On Sun, 2020-07-05 at 07:09 -0500, Richard Shaw wrote: > On Sat, Jul 4, 2020 at 8:48 PM wrote: > > Hello, > > > > My name is Nikolay Nikolov. I'm a software developer and free/open > > source enthusiast. I've been using Linux since Red Hat Linux 5.0. > > After > > Red Hat Linux 9, I upgraded to Fedora Core 1 and I've used every > > Fedora > > version since then. :) I'm a core developer of the Free Pascal > > Compiler > > ( https://www.freepascal.org/ ). My Free Pascal contributions > > include > > code generator support for some legacy platforms, such as 16-bit > > x86 > > and Z80, as well as modern stuff, such as GDB/MI debugger support > > integration in the Free Pascal IDE, x86 optimizations (for all x86 > > flavours - 16-bit, 32-bit and 64-bit). > > > > I also develop and maintain several open source projects, written > > in > > Pascal. > > > > Things I'm interested in contributing to Fedora: > > > > - co-maintaining the Free Pascal package (fpc) and adding > > crosscompiler > > support for additional targets (e.g. crosscompiling to i386-linux > > from > > x86_64, crosscompiling to win32 and win64, etc.). > > - packaging the DOSBox-X fork of DOSBox: > > https://github.com/joncampbell123/dosbox-x > > - packaging some of my Pascal projects, when they get a release > > - eventually, packaging other programs, written in Free Pascal > > Your timing is impeccable! I'm looking for a co/new maintainer for > the Hedgwars package. I have a couple of offers, but as it's written > mostly in Pascal, I think you would be a good fit! :) > > I can sponsor you if you like unless you really would rather submit > some of your pascal packages first, I wouldn't be the best one for > that. Yes, I can co-maintain Hedgewars as well. :) I still haven't figured out how everything works with the packaging yet, so it'd be much easier for me to start with an existing package, that already conforms to the packaging guidelines and that requires little changes, besides updating to new versions and rebuilding. :) Best regards, Nikolay > > 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 ___ 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
Strange rpmbuild begaveour
Two builds for tests:
1. https://koji.fedoraproject.org/koji/taskinfo?taskID=46635276
2. https://koji.fedoraproject.org/koji/taskinfo?taskID=46635342
The deferrence between them - libraries permissions.
Problems are:
1. %{make_install} installs libraries with 0755 flags
2. After changing library files mode into 0644 rpmbuild not extracts
debug info
Where I'm wrong?
___
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
Le mercredi 01 juillet 2020 à 12:27 +0200, Dominik 'Rathann' Mierzejewski a écrit : > > > To get beautiful changelogs, you also need to add > > > > > > %buildsys_name Your name > > %buildsys_email Your email > > > > > > in ~/.rpmmacros > > What about having one macro called %buildsys_packager instead of two? > You're always using them together, anyway. It'd be similar to the > existing %packager macro, too. This is now done in the latest code refresh and in the test copr https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/bc4e6a79355f3a2b73abeea7e5c0e1f53b09579e?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/ I fleshed out the change page a little too https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping 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: Self Introduction: Nikolay Nikolov
On Sat, Jul 4, 2020 at 8:48 PM wrote: > Hello, > > My name is Nikolay Nikolov. I'm a software developer and free/open > source enthusiast. I've been using Linux since Red Hat Linux 5.0. After > Red Hat Linux 9, I upgraded to Fedora Core 1 and I've used every Fedora > version since then. :) I'm a core developer of the Free Pascal Compiler > ( https://www.freepascal.org/ ). My Free Pascal contributions include > code generator support for some legacy platforms, such as 16-bit x86 > and Z80, as well as modern stuff, such as GDB/MI debugger support > integration in the Free Pascal IDE, x86 optimizations (for all x86 > flavours - 16-bit, 32-bit and 64-bit). > > I also develop and maintain several open source projects, written in > Pascal. > > Things I'm interested in contributing to Fedora: > > - co-maintaining the Free Pascal package (fpc) and adding crosscompiler > support for additional targets (e.g. crosscompiling to i386-linux from > x86_64, crosscompiling to win32 and win64, etc.). > - packaging the DOSBox-X fork of DOSBox: > https://github.com/joncampbell123/dosbox-x > - packaging some of my Pascal projects, when they get a release > - eventually, packaging other programs, written in Free Pascal > Your timing is impeccable! I'm looking for a co/new maintainer for the Hedgwars package. I have a couple of offers, but as it's written mostly in Pascal, I think you would be a good fit! :) I can sponsor you if you like unless you really would rather submit some of your pascal packages first, I wouldn't be the best one for that. 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: The future of legacy BIOS support in Fedora.
On Sa, 04.07.20 12:49, Chris Murphy (li...@colorremedies.com) wrote: > Why do the security folks want POSIX and SELinux labels on the > contents of /boot? I've never really gotten a straight answer on this, > but I know it's considered important and a sticking point for why some > folks do not want the kernel and initramfs and bootloader > configuration files on FAT. And can it be mitigated some other way? > Maybe not persistently mounting /boot and /boot/efi or mounting them > on-demand elsewhere only when they need to be modified? You can assign an SELinux label onto a whole file system at mount time via the context= mount option and related ones. Hence the question is why it is supposedly so essential to be able to label the initrd differently than the kernel itself... Note that systemd can automatically mount the ESP and XBOOTLDR partition for you if you let it. If done so it will set it up via automounts, so that the file systems are: 1) automatically fsck'ed on first mount 2) only mounted when actually accessed 3) very quickly after the last access unmounted again This should provide the best data integrity guarantees on those file systems as the file system is almost always unmounted, and thus in a clean state, and automatically fixed in the unlikely case that the system was turned off right at the moment the fs was accessed. Note that this mechanism is independent of the boot loader spec, or sd-boot or anything like that. It's automatically used if /boot or /efi are not listed in /etc/fstab and if partitions of the right type are found in the partition table. (Note that this automatism doesn't support /boot/efi/, first of al because it's weird, but mostly because in order to establish the second automount point we'd have to activate the first one, which defeats the whole excercise of having file systems that are never mounted, except if they are accessed) Hence, a couple of changes independent of the sd-boot/grub/boot loader spec situation would make a lot of sense for Fedora: 1) Use the XBOOTLDR uuid for /boot 2) Mount ESP to /efi instead of /boot/efi (you can keep a symlink in /boot/efi/ if you like) 3) Drop generation of ESP and /boot entries in /etc/fstab in the installer, and let the automatic logic do its thing. > There are other use cases folks are interested in. Here's one: > https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Boot_on_Btrfs You know using a journalling file system on /boot means means you drastically complicate things if you want to implement boot counting, because then you need a writable fs, and then things become complex because you need a ful fs implementation in grub. Do the btrfs upstream folks commit to support an alternative writable btrfs implementation in grub? I doubt so? > That aims to make it possible to support a snapshot/rollback regime. > There needs to be a way to pair the states of /boot and / so that the > kernel we're using to boot a rollback, has modules available on the > rolledback /usr. That does not need to be done with Btrfs, even > though You are just reimplementing OSTree/Atomic/FedoraCoreOS with that... Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Sa, 04.07.20 18:11, John M. Harris Jr (joh...@splentity.com) wrote: > That systemd throws some crap out doesn't make it a standard. There's no > reason for GRUB to adopt this, or for anyone else to use this. "bloat", "crap", … I am sorry, but you are apparently just a troll and this is the point where I will now ignore you. Just stop being so awful and dismissive, this is not constructive. Thank you, Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20200704.n.1 changes
OLD: Fedora-Rawhide-20200703.n.0 NEW: Fedora-Rawhide-20200704.n.1 = SUMMARY = Added images:6 Dropped images: 1 Added packages: 17 Dropped packages:0 Upgraded packages: 113 Downgraded packages: 0 Size of added packages: 14.99 MiB Size of dropped packages:0 B Size of upgraded packages: 4.08 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 41.13 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20200704.n.1.ppc64le.tar.xz Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20200704.n.1.iso Image: LXDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXDE-armhfp-Rawhide-20200704.n.1-sda.raw.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200704.n.1.ppc64le.qcow2 Image: Cloud_Base vmdk ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200704.n.1.ppc64le.vmdk Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200704.n.1.ppc64le.raw.xz = DROPPED IMAGES = Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20200703.n.0.s390x.tar.xz = ADDED PACKAGES = Package: RediSearch-1.2.2-2.fc33 Summary: Full-text search over Redis RPMs:RediSearch Size:1.26 MiB Package: golang-github-anacrolix-stm-0.2.0-1.fc33 Summary: Software Transactional Memory in Go RPMs:golang-github-anacrolix-stm-devel Size:24.39 KiB Package: golang-github-graphql-0.7.9-1.fc33 Summary: Implementation of GraphQL for Go RPMs:golang-github-graphql-devel Size:163.80 KiB Package: golang-github-jedib0t-pretty-6.0.4-1.fc33 Summary: Pretty print Tables and more in golang RPMs:golang-github-jedib0t-pretty-devel Size:89.88 KiB Package: golang-github-snowflakedb-gosnowflake-1.3.6-1.fc33 Summary: Go Snowflake Driver RPMs:golang-github-snowflakedb-gosnowflake-devel Size:234.44 KiB Package: golang-github-viant-assertly-0.5.4-1.fc33 Summary: Arbitrary datastructure validation RPMs:golang-github-viant-assertly-devel Size:35.69 KiB Package: golang-github-xwb1989-sqlparser-0-0.1.20200703git1203878.fc33 Summary: SQL Parser implemented in Go RPMs:golang-github-xwb1989-sqlparser-devel Size:114.54 KiB Package: golang-uber-config-1.4.0-1.fc33 Summary: Configuration for Go applications RPMs:golang-uber-config-devel Size:34.65 KiB Package: golang-uber-dig-1.10.0-1.fc33 Summary: A reflection based dependency injection toolkit for Go RPMs:golang-uber-dig-devel Size:61.32 KiB Package: libgamerzilla-0.0.1-2.fc33 Summary: Gamerzilla Integration Library RPMs:libgamerzilla libgamerzilla-devel Size:268.42 KiB Package: meshbird-2.3-1.fc33 Summary: Distributed private networking RPMs:golang-github-meshbird-devel meshbird Size:7.56 MiB Package: python-httpx-0.13.3-1.fc33 Summary: Python HTTP client RPMs:python3-httpx Size:103.31 KiB Package: python-promise-2.3.0-3.fc33 Summary: Promises/A+ implementation for Python RPMs:python3-promise Size:47.22 KiB Package: rubygem-rmail-1.1.3-3.fc33 Summary: A MIME mail parsing and generation library RPMs:rubygem-rmail rubygem-rmail-doc Size:373.31 KiB Package: rust-assert_cli-0.6.3-1.fc33 Summary: Test CLI Applications RPMs:assert_cli rust-assert_cli+default-devel rust-assert_cli-devel Size:1.05 MiB Package: rust-cargo-readme-3.2.0-1.fc33 Summary: Cargo subcommand to generate README.md content from doc comments RPMs:cargo-readme rust-cargo-readme+default-devel rust-cargo-readme-devel Size:3.59 MiB Package: rust-environment-0.1.1-1.fc33 Summary: Helper to deal with environment variables RPMs:rust-environment+default-devel rust-environment-devel Size:17.72 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: 2ping-4.5-1.fc33 Old package: 2ping-4.3-7.fc33 Summary: Bi-directional ping utility RPMs: 2ping Size: 72.15 KiB Size change: 1.33 KiB Changelog: * Thu Jun 18 2020 Ryan Finnie - 4.5-1 - Update to 4.5 - Install supplied systemd 2ping.service - Use pytest for test suite Package: Lmod-8.3.17-2.fc33 Old package: Lmod-8.3.17-1.fc33 Summary: Environmental Modules System in Lua RPMs: Lmod Size: 1.05 MiB Size change: 389 B Changelog: * Wed Jul 01 2020 Tom Callaway - 8.3.17-2 - add support for lua 5.4 Package: R-GenomicAlignments-1.22.1-2.fc33 Old package: R-GenomicAlignments-1.22.1-1.fc33 Summary: Representation and manipulation of short genomic alignments RPMs: R-GenomicAlignments Size: 10.83 MiB Size change: -17.13 KiB Changelog: * Sat Jul 04 2020 Jos?? Ab??lio Matos - 1.22.1-2 - rebuild for R 4 Package: R-data.table-1.12.8-4.fc33 Old package: R-data.table-1.12.8-3.fc33 Summary: Extension of `data.frame`
Re: Help (or take over) hedgewars?
Hedgewars is mostly Pascal, so with me maintaining FPC and Lazarus, I'd be willing to take it over. However, I don't know any Haskell, so some help from someone who does would be appreciated. ___ 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 Sunday, July 5, 2020 1:03:34 AM MST Luya Tshimbalanga wrote: > It would be great that the installer, Anaconda, enables sd-boot for > users running on UEFI system. The method was done before with both LILO > and Grub decades ago and it was very surprising very few thought of that > process especially for a distribution aiming to use latest technology. > > The question is for contributors running on legacy BIOS if they are > willing to maintain it while the installer can focus to effectively use > sd-boot. systemd-boot isn't really an option. It doesn't have the features that are necessary for Fedora systems to actually be able to boot. It'd work on Workstation, maybe, if they think their users will never need to know they're even using a bootloader, and won't put /boot on LVM or LUKs encrypt it. Additionally, the theoretical proposal discussed earlier in the thread was to add it as an alternate option, which users could ELECT to trying out, not to make it the default bootloader. Probably because it doesn't meet the needs of actually being able to boot Fedora 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.
It would be great that the installer, Anaconda, enables sd-boot for users running on UEFI system. The method was done before with both LILO and Grub decades ago and it was very surprising very few thought of that process especially for a distribution aiming to use latest technology. The question is for contributors running on legacy BIOS if they are willing to maintain it while the installer can focus to effectively use sd-boot. -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ 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 software in the default image leads to low memory issues? Web browsers? For example, browsers, electron-based apps, blender, compilation, VM, openings files, opening file manager (once I came across this: when I opened the file manager, an uncontrolled leak occurred somewhere in the thumbnail.so, and tand the system froze). It can leak anywhere, and it can happen unexpectedly. ___ 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.
Le samedi 04 juillet 2020 à 23:10 -0400, Solomon Peachy a écrit : > (Note this explicitly excludes Chromebooks) So you want to discuss Linux desktop deployments, excluding the only sucessful mass Linux desktop deployment to date? Why? Also your data conflates systems sold in with systems in use in . That’s a very misleading assumption to make, computer systems have matured a lot, and hardware lifetime has gone up with this maturing (much to manufacturer’s despair, the maturing is starting to affect smartphones now). It’s no longer early days when you replaced last year’s experimental system with current year’s experimentalk system because nothing had settled yet. 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Saturday, July 4, 2020 11:27:47 PM MST Alexey Avramov wrote: > >Linux handles low memory situations just fine, but it's much better if you > > have an appropriately sized swap partition and let the kernel do its job > > No, by default Linux can hang at low memory condition. Huge swap space will > not help you if a leak occurs. With a large swap space, the hang can happen > later, but it can still happen. Another point is that the swap space is > slow. With fast leaks and slow swap space, freezing is possible throughout > the entire swap filling time. A typical problem: "once all the ram is used > up the whole system freezes as swap starts getting full, but really the > whole system is completely locked-up. I thought my swapfile was too small > so I made it match my ram (12 GB) but the system still gets frozen" [1]. Sure, swap is slower than RAM. That's fine. We don't need it to be as fast as RAM, that's not what it's for. It's for things that can be swapped out, because it's loaded into memory, but not actively used. RAM doesn't "fill" until long after unused things have been swapped out. > >If you didn't mean for the program to use as much memory as it tried to, > >the correct solution would be to use cgroups. > > > 1. This is not configured by default. > 2. This can be inconvenient even for advanced users. > 3. Quick leaks can happen unexpectedly. What software in the default image leads to low memory issues? Web browsers? If so, there's a simple solution to this. We can put a default cgroup on web browsers so they don't take over the OS. -- 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.
Le samedi 04 juillet 2020 à 23:10 -0400, Solomon Peachy a écrit : > folks that make very long-lifecycle industrial systems > meant to run generally ancient software Those things are not meant to run ancient software. They are meant to run a very long time. And yes at the end of this time the software is ancient. That does not mean it is ancient at the start of the system lifecycle (I’ve seen crazy people building such systems from a Fedora image, because they knew they would accumulate enough technical debt during the system lifecycle, without taking the centos debt from the start up) 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
>Linux handles low memory situations just fine, but it's much better if you >have an appropriately sized swap partition and let the kernel do its job No, by default Linux can hang at low memory condition. Huge swap space will not help you if a leak occurs. With a large swap space, the hang can happen later, but it can still happen. Another point is that the swap space is slow. With fast leaks and slow swap space, freezing is possible throughout the entire swap filling time. A typical problem: "once all the ram is used up the whole system freezes as swap starts getting full, but really the whole system is completely locked-up. I thought my swapfile was too small so I made it match my ram (12 GB) but the system still gets frozen" [1]. >If you didn't mean for the program to use as much memory as it tried to, the >correct solution would be to use cgroups. 1. This is not configured by default. 2. This can be inconvenient even for advanced users. 3. Quick leaks can happen unexpectedly. [1] https://github.com/hakavlad/nohang/issues/85#issue-564348496 ___ 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
