Re: out of Koji disk space
On Fri, 03 Jul 2020 14:52:00 +0200, Jan Kratochvil wrote: > On Thu, 02 Jul 2020 02:04:48 +0200, Kevin Fenzi wrote: > > On Wed, Jul 01, 2020 at 11:22:26PM +0200, Jan Kratochvil wrote: > > > I will file a ticket after Spot says his opinion (or not). > > > > Sure. > > https://src.fedoraproject.org/rpms/chromium/pull-request/27 So Spot says: I'm not sure that the additional build time and storage demands of this are worthwhile in practice. Not sure what to do when after all the compiler tools effort the debuginfo is not worth even the time building it. Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2020-07-07 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/07/report-389-ds-base-1.4.4.3-20200706git017fda0.fc32.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Thu, Jul 2, 2020 at 4:53 AM Benjamin Berg wrote: > On Wed, 2020-07-01 at 11:07 -0500, Michael Catanzaro wrote: > > So the last two times thermald was proposed (first as a F32 change > > proposal, then more recently to the Workstation WG) it was rejected on > > the grounds that it was not useful without dptfxtract installed. Now > > it's clear that everybody was mistaken about that, so seems it makes > > sense to reconsider. > > > > I have a couple questions. First, why is thermal management occurring > > in userspace? Can you please provide a technical explanation as to why > > the kernel is not the right place for this code? > > The thermal daemon has a bit of information: > > https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon > > It lists the following reasons: > * A short time to market > * Proactively controlled temperature > * Use of existing kernel infrastructure > * A defined architecture, which can be easily enhanced. > > In general, I don't see a problem with moving some logic into > userspace. It is not like the kernel is in a much better position to > make decisions. It only is closer to the hardware from an architectural > point of view and will only be in a better position if decisions must > not be delayed (e.g. protecting the hardware from overheating). > It's also a design meant to mimic Intel's Windows implementation, which allows for more advanced control based on workloads as desired in some of the more advanced flavors of DPTF (i.e. not Passive). > On Wed, Jul 1, 2020 at 11:53 am, Richard W.M. Jones > > wrote: > > > Is there some background about why dptfxtract is proprietary? (I see > > > that it's a program provided by Intel.) Is it just because no one's > > > done the work to make a free equivalent or does it require some > > > secret/patented/whatever knowledge to work? > > > > I'm also interested in this question. In particular, since thermald and > > dptfxtract are both the same upstream, it seems really hostile to the > > open source community for thermald to perform better if you have this > > extra proprietary portion of the project installed. > > My interpretation is that, Intel is trying to protect their IP around > thermal management and how DPTF works in particular. > Some additional context: When I was at Dell, I helped push for Intel to start supporting more DPTF features on Linux in order for Dell to be able to ship Linux on our more thermally constrained mechanical designs. DPTF Passive 1.0 (and some other stuff? can't remember the state back then) was already supported by thermald. Due to Intel's IP concerns, we couldn't get an open source implementation of the userspace logic used for other DPTF policies, but we could get someone at Intel to write dptfxtract, which tries to make a smart interpretation of some of the otherwise unsupported (on Linux) tables and output tables that are usable on Linux. Unfortunately, I cannot share details of Intel's IP concerns due to NDA I'm still beholden to. Note however that dptfxtract wasn't meant to be a be-all-end-all but rather a solution to the immediate problem of Linux being behind in support DPTF, which is widely implemented by Intel-based laptops in the market. It was released with the understanding that it's an imperfect solution, and that is part of why it was made to be an _optional_ addition to thermald. I can't speak for Intel, but I trust that they'll come forward when they are ready to release to the community better Linux solutions for supporting DPTF. I suspect that would largely come as additions to thermald. > So, for me, the hostile part here is that we are dealing with a > hardware platform that contains components for which the manufacturer > is not willing to provide proper documentation. > > The thermald upstream on the other hand is trying to provide the best > possible experience while working under these imposed constraints. So > thermald will use all the information that it can get, and dptfxtract > allows exporting proprietary information encoded in the DPTF related > data stored in ACPI. > > Benjamin > ___ > 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 > -- Jared Dominguez (he/him) Laptop/Desktop Hardware Enablement Manager RHEL Workstation Engineering ___ 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
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Mon, Jul 6, 2020 at 5:30 PM Samuel Sieb wrote: > > On 7/6/20 4:24 PM, Adam Williamson wrote: > > If you mean the EFI boot manager entry, just renaming the existing one > > something other than "Fedora" ought to do the trick, I think. So far as > > /boot/efi goes...well, you have two choices. You can have the two > > installs share one, or have two separate ones. I *think* both options > > at least in theory ought to work, I'm not sure if anyone's tested... > > Adding another EFI partition should work, but I don't see how they could > share one. There's a single Fedora directory in there, so each install > would overwrite the files of the other. The grub.cfg can only point to > one set of boot loader entries. And that means sharing one ESP means sharing /boot - yeah. Hmm. I'll have to test it but I'm pretty sure it's a fairly simple post-install fix to get that to work. I'm not totally certain how blscfg.mod parses /boot/loader/entries containing bls snippets with two machine IDs. O I just thought of something. F32 and older depend on grubenv to store part of the kernel command line variables. So I think it will be necessary to do an F32 F33 side by side install for it to work. Two F32's side by side will compete over the single grubenv. -- 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 Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen wrote: > > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote: > > >On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek wrote: > >> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for > >> F34 > >> could be good option. I know technically it is already opt-in, but it's not > >> very visible or popular. We could make the btrfs option more prominent and > >> ask people to pick it if they are ready to handle potential fallout. > > > >I'm leaning towards recommending this as well. I feel like we don't have > >good data to make a decision on -- the work that Red Hat did previously when > >making a decision was 1) years ago and 2) server-focused, and the Facebook > >production usage is encouraging but also not the same use case. I'm > >particularly concerned about metadata corruption fragility as noted in the > >Usenix paper. (It'd be nice if we could do something about that!) > > So if one has a spare partition to play with btrfs, is there an easy > way to install a second copy of Fedora without having the /boot/efi/ > entries overwrite the existing Fedora installation? Or fix it to have > 2 separate entries after the fact? It's possible but has challenges. Separate ESP's you'll need to either (a) use the firmware's built-in boot manager to choose what will probably appear to be identically named Fedora's (b) add new NVRAM entries, and names, and switch between them before reboot by using efibootmgr --bootorder or --bootnext. Another option is shared ESP and /boot but my vague recollection is some things go away. For sure /boot/efi/EFI/fedora is replaced, and then possibly /boot/loader/entries are replaced. But that might be easier to deal with than the above, and more efficient. -- 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
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b1a8a3c29a putty-0.74-1.el6 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8c3e76982e python-rsa-3.4.2-1.el6 1 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 munin-2.0.63-1.el6 php-horde-kronolith-4.2.28-1.el6 Details about builds: munin-2.0.63-1.el6 (FEDORA-EPEL-2020-d07b60a4ec) Network-wide resource monitoring tool Update Information: Upstream update to 2.0.63. Also includes some minor crontab, logrotate and systemd improvements. ChangeLog: * Mon Jul 6 2020 Kim B. Heino - 2.0.63-1 - Upgrade to 2.0.63 - Don't use systemd-run in munin-run, rhbz #1852345 - Use "Type=notify" for munin-node and munin-asyncd * Thu Jun 25 2020 Jitka Plesnikova - 2.0.54-5 - Perl 5.32 rebuild * Tue Mar 24 2020 Jitka Plesnikova - 2.0.54-4 - Specify all perl's dependencies for build * Wed Jan 29 2020 Fedora Release Engineering - 2.0.54-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Fri Jan 24 2020 Kim B. Heino - 2.0.54-2 - Convert cronjob to systemd timer and tmpfiles References: [ 1 ] Bug #1852345 - munin-run cannot be executed https://bugzilla.redhat.com/show_bug.cgi?id=1852345 php-horde-kronolith-4.2.28-1.el6 (FEDORA-EPEL-2020-cf2168a68d) A web based calendar Update Information: **kronolith 4.2.28** * [mjr] **SECURITY**: Don't leak private details when sending notifications for private events (Bug #15011). * [mjr] Fix regression in display of clickable event URL property (Bug #14941). ChangeLog: * Mon Jul 6 2020 Remi Collet - 4.2.28-1 - update to 4.2.28 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Mon, Jul 6, 2020 at 9:52 AM Stephen John Smoogen wrote:
>
> On Mon, 6 Jul 2020 at 01:19, Chris Murphy wrote:
> >
> > 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?
> >
>
> Aren't most disk failure tests 'huh it somehow happened at least once
> and I think this explains all these other failures too?' I know that
> with giant clusters you can do more testing but you also have a lot of
> things like
>
> What is the chance that a disk will die over time? 100%
> What is the chance that a disk died from this particular scenario?
> 0.0 %
> reword the question slightly differently.. What is the chance this
> disk died from that scenario? 100%.
Yes. Also in fuzzing there is the concept of "when to stop fuzzing"
because it's a rabbit hole, you have to come up for air at some point,
and work on other things. But you raise a good and subtle point which
is also that ext4 has a very good fsck built up over decades, they
succeed today from past failures. It's no different with Btrfs.
But also there is a bias. ext4 needs fsck to succeed in the worst
cases in order to mount the file system. Btrfs doesn't need that.
Often it can tolerate a read-only mount without any other mount
option; and optionally can be made more tolerant to errors while still
mounting read-only. This is a significant difference in recovery
strategy. An fsck is something of a risk because it is writing changes
to the file system. It is irreversible. Btrfs takes a different view,
which is to increase the chance of recovery without needing a risky
repair as the first step. Once your important data is out, now try the
repair. Good chance it works, but maybe not as good as ext4's.
--
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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 692 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 431 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 141 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 81 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19d171a465 python34-3.4.10-5.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c438b9fb89 lynis-3.0.0-1.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d749373a67 znc-1.8.1-1.el7 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-af9b2ac861 alpine-2.23-2.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6ad4894c0c jbig2dec-0.12-5.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0078f6abc1 xpdf-3.04-10.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-af9c6001d1 ngircd-26-1.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5d348316dd chromium-83.0.4103.116-3.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-afd5c42fd6 coturn-4.5.1.3-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6949cf3502 xrdp-0.9.13.1-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2f70f49092 putty-0.74-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0f25da8099 python-rsa-3.4.2-1.el7 1 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 abcMIDI-2020.06.29-1.el7 httrack-3.49.2-8.el7 munin-2.0.63-1.el7 php-horde-kronolith-4.2.28-1.el7 Details about builds: abcMIDI-2020.06.29-1.el7 (FEDORA-EPEL-2020-03d207806f) ABC to/from MIDI conversion utilities Update Information: This project has a new upstream maintainer, and I have unretired it. ChangeLog: httrack-3.49.2-8.el7 (FEDORA-EPEL-2020-2814e29b51) Website copier and offline browser Update Information: update ChangeLog: * Mon Jul 6 2020 Fabio Alessandro Locati - 3.49.2-8 - Do not rely on incidental default values * Wed Jan 29 2020 Fedora Release Engineering - 3.49.2-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Thu Jul 25 2019 Fedora Release Engineering - 3.49.2-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Fri Feb 1 2019 Fedora Release Engineering - 3.49.2-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Fri Jul 13 2018 Fedora Release Engineering - 3.49.2-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Fri Feb 9 2018 Igor Gnatenko - 3.49.2-3 - Escape macros in %changelog * Wed Feb 7 2018 Fedora Release Engineering - 3.49.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Thu Aug 31 2017 Fabio Alessandro Locati - 3.49.2-1 - Bump to 3.49.2 * Wed Aug 2 2017 Fedora Release Engineering - 3.48.22-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild * Wed Jul 26 2017 Fedora Release Engineering - 3.48.22-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild * Fri Feb 10 2017 Fedora Release Engineering - 3.48.22-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild munin-2.0.63-1.el7 (FEDORA-EPEL-2020-d617f42f36) Network-wide resource monitoring tool Update Information: Upstream update to 2.0.63. Also includes some minor crontab, logrotate and systemd improvements. ChangeLog: * Mon Jul 6 2020 Kim B. Heino - 2.0.63-1 - Upgrade to 2.0.63 - Don't use systemd-run in munin-run, rhbz #1852345 - Use "Type=notify" for munin-node and munin-asyncd * Thu Jun 25 2020 Jitka Plesnikova - 2.0.54-5 - Perl 5.32 rebuild * Tue Mar 24 2020 Jitka Plesnikova - 2.0.54-4 - Specify all perl's dependencies for build * Wed Jan 29 2020 Fedora Release Engineering - 2.0.54-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
yuv2png and vpxenc (webm) in fedora ?
Hi, Would it be ok, to create a png2vuy and vpxenc package in fedora ? With png2vuy and vpxenc it would be possible to create a webm-movie from a sequence of image files. Can the fedora firefox show a .webm file (youtube use the .webm format) ? A program, that could use png2yuv and vpxenc for movie creation would be white_dune so long MUFTI ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/6/20 4:24 PM, Adam Williamson wrote: If you mean the EFI boot manager entry, just renaming the existing one something other than "Fedora" ought to do the trick, I think. So far as /boot/efi goes...well, you have two choices. You can have the two installs share one, or have two separate ones. I *think* both options at least in theory ought to work, I'm not sure if anyone's tested... Adding another EFI partition should work, but I don't see how they could share one. There's a single Fedora directory in there, so each install would overwrite the files of the other. The grub.cfg can only point to one set of boot loader entries. ___ 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 Mon, 2020-07-06 at 16:24 -0700, Adam Williamson wrote: > On Mon, 2020-07-06 at 18:48 -0400, Gerald Henriksen wrote: > > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote: > > > > > On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek > > > wrote: > > > > Making btrfs opt-in for F33 and (assuming the result go well) opt-out > > > > for F34 > > > > could be good option. I know technically it is already opt-in, but it's > > > > not > > > > very visible or popular. We could make the btrfs option more prominent > > > > and > > > > ask people to pick it if they are ready to handle potential fallout. > > > > > > I'm leaning towards recommending this as well. I feel like we don't have > > > good data to make a decision on -- the work that Red Hat did previously > > > when > > > making a decision was 1) years ago and 2) server-focused, and the Facebook > > > production usage is encouraging but also not the same use case. I'm > > > particularly concerned about metadata corruption fragility as noted in the > > > Usenix paper. (It'd be nice if we could do something about that!) > > > > So if one has a spare partition to play with btrfs, is there an easy > > way to install a second copy of Fedora without having the /boot/efi/ > > entries overwrite the existing Fedora installation? Or fix it to have > > 2 separate entries after the fact? > > If you mean the EFI boot manager entry, just renaming the existing one > something other than "Fedora" ought to do the trick, I think. So far as > /boot/efi goes...well, you have two choices. You can have the two > installs share one, or have two separate ones. I *think* both options > at least in theory ought to work, I'm not sure if anyone's tested... actually, no, thinking about it harder, I think sharing one wouldn't work right. I think you have to have a new /boot/efi for the second install, as well as a separate /boot. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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 Mon, 2020-07-06 at 18:48 -0400, Gerald Henriksen wrote: > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote: > > > On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek wrote: > > > Making btrfs opt-in for F33 and (assuming the result go well) opt-out for > > > F34 > > > could be good option. I know technically it is already opt-in, but it's > > > not > > > very visible or popular. We could make the btrfs option more prominent and > > > ask people to pick it if they are ready to handle potential fallout. > > > > I'm leaning towards recommending this as well. I feel like we don't have > > good data to make a decision on -- the work that Red Hat did previously when > > making a decision was 1) years ago and 2) server-focused, and the Facebook > > production usage is encouraging but also not the same use case. I'm > > particularly concerned about metadata corruption fragility as noted in the > > Usenix paper. (It'd be nice if we could do something about that!) > > So if one has a spare partition to play with btrfs, is there an easy > way to install a second copy of Fedora without having the /boot/efi/ > entries overwrite the existing Fedora installation? Or fix it to have > 2 separate entries after the fact? If you mean the EFI boot manager entry, just renaming the existing one something other than "Fedora" ought to do the trick, I think. So far as /boot/efi goes...well, you have two choices. You can have the two installs share one, or have two separate ones. I *think* both options at least in theory ought to work, I'm not sure if anyone's tested... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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 Monday, July 6, 2020 3:03:05 PM MST Peter Robinson wrote: > > > It's less complex to maintain one solution for both types of boot, I'd > > > imagine. I'm not the one that'd be doing the work to support it, so far > > > be it from me to prevent somebody from doing so, but that's just what > > > it sounds like. Right now, we have one solution that works well for > > > both. > > > > > > > > > > > > > > If we wanted to be UEFI first, we could make BIOS boots emulate UEFI > > and boot through the UEFI chain all the way through. We already do > > this for some boards on ARM with U-Boot, if I remember correctly. If > > that were possible on x86, then we could get down to one boot chain > > path regardless. > > > No, U-Boot is the firmware, it now implements a UEFI interface as a > means of interacting with OS/bootloaders for booting OSes in a generic > manner. It's not emulated, it is the interface between the firmware > (U-Boot) and the computer, for aarch64 it's mandated that the board > firmware implement UEFI to be supported in Fedora, whether that's the > Tianocore, U-Boot or another third party implementation, open or > proprietary we don't care. > > Why would you wrap BIOS with another firmware implementation? You're > just making the problem worse. Fact is that while it won't go away > particularly fast we should actually be looking at sunsetting > traditional BIOS support, it's not secure or securable. MS has > mandated it for the Windows logo program to be certified HW since > Windows 8, they've now mandated that for server as well, in both cases > now requiring TPM2. > > Don't hack up BIOS support, it vaguely sort of works now, leave it > vaguely working and just let it be, it's not evolving. One day we'll > wake up and no one will be using it, the sooner the better. That day is still decades away, as others in this list have noted. I agree with the rest, of course. Just let it be. -- 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Monday, July 6, 2020 8:47:24 AM MST Przemek Klosowski via devel wrote: > On 7/4/20 8:18 PM, John M. Harris Jr wrote: > > > I've never managed to get one of my own Fedora machines to the point of > > OOMing, and, when I have seen others do it, it's a problem that would > > have > > been solved by having more swap space. > > > I am a tab hoarder so I used to wedge the browser due to memory leaks > (some live ad pages would blow up into gigabytes of RAM). I think recent > browser versions are more resistant to that---I haven't locked up in a > while, although it may be because I also tend to have a Task Manager > open, sorted by Memory size, and I kill pages that keep growing. Unless you're actively using all of those tabs (I don't know how you would be, but it's certainly possible), swap sounds like the perfect solution. Unless Firefox keeps JS running in there, and it's updating the DOM, these would likely be able to get swapped out. Firefox will actually unload tabs that you haven't done anything with in a while under specific circumstances, but I don't know what those are. You may notice, for example, that the page "reloads" without network traffic, when going to a tab you haven't had open in a while. I've seen this on my system recently. > More swap doesn't necessarily solve this problem: remember that 1GB/min > is a ballpark HD speed so if you have 10GB swap that your system is > actually trying to use, you will just sit there for 10 minutes. I don't really understand how that'd be the case. For that to happen, you'd have to load all of those into memory, have them swap out, then try to swap them all back in at the same time. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, 1 Jul 2020 14:24:37 -0400, you wrote: >On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek wrote: >> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34 >> could be good option. I know technically it is already opt-in, but it's not >> very visible or popular. We could make the btrfs option more prominent and >> ask people to pick it if they are ready to handle potential fallout. > >I'm leaning towards recommending this as well. I feel like we don't have >good data to make a decision on -- the work that Red Hat did previously when >making a decision was 1) years ago and 2) server-focused, and the Facebook >production usage is encouraging but also not the same use case. I'm >particularly concerned about metadata corruption fragility as noted in the >Usenix paper. (It'd be nice if we could do something about that!) So if one has a spare partition to play with btrfs, is there an easy way to install a second copy of Fedora without having the /boot/efi/ entries overwrite the existing Fedora installation? Or fix it to have 2 separate entries after the fact? ___ 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's less complex to maintain one solution for both types of boot, I'd > > imagine. I'm not the one that'd be doing the work to support it, so far be > > it > > from me to prevent somebody from doing so, but that's just what it sounds > > like. Right now, we have one solution that works well for both. > > > > If we wanted to be UEFI first, we could make BIOS boots emulate UEFI > and boot through the UEFI chain all the way through. We already do > this for some boards on ARM with U-Boot, if I remember correctly. If > that were possible on x86, then we could get down to one boot chain > path regardless. No, U-Boot is the firmware, it now implements a UEFI interface as a means of interacting with OS/bootloaders for booting OSes in a generic manner. It's not emulated, it is the interface between the firmware (U-Boot) and the computer, for aarch64 it's mandated that the board firmware implement UEFI to be supported in Fedora, whether that's the Tianocore, U-Boot or another third party implementation, open or proprietary we don't care. Why would you wrap BIOS with another firmware implementation? You're just making the problem worse. Fact is that while it won't go away particularly fast we should actually be looking at sunsetting traditional BIOS support, it's not secure or securable. MS has mandated it for the Windows logo program to be certified HW since Windows 8, they've now mandated that for server as well, in both cases now requiring TPM2. Don't hack up BIOS support, it vaguely sort of works now, leave it vaguely working and just let it be, it's not evolving. One day we'll wake up and no one will be using it, the sooner the better. Peter ___ 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
Soname bumps and rebuilds of math packages
I will update several of our math packages in the next couple of days,
once I finish doing test builds. Multiple soname bumps are involved.
I will rebuild all affected packages. This will be my first attempt
at building in a side tag. Wish me luck!
The following will be updated, in "round" order:
Round 1:
- ecl: update to version 20.4.24, with an soname bump
- flint: update to version 2.6.0, with an soname bump
- libfplll: update to version 5.3.3, no soname bump but contains
backwards incompatible changes
- lrslib: update to version 071, with an soname bump
- memtailor: update to 20200526 git snapshot
Round 2:
- arb: update to version 2.18.1 (depends on flint)
- eclib: rebuild (depends on flint)
- gap-pkg-float: rebuild (depends on libfplll)
- linbox: rebuild (depends on flint and libfplll)
- mathic: update to 20200526 git snapshot (depends on memtailor)
- maxima: rebuild (depends on ecl)
- normaliz: update to version 3.8.6, no soname bump but contains
backwards incompatible changes (depends on flint)
- symbol: rebuild (depends on lrslib)
Round 3:
- mathicgb: update to 20200526 git snapshot (depends on mathic)
Round 4:
- Singular: rebuild without polymake support (depends on flint,
mathicgb, and normaliz)
Round 5:
- polymake: update to version 4.1 (depends on flint, lrslib, normaliz,
Singular, and sympol)
Round 6:
- Singular: rebuild with polymake support (depends on polymake)
Round 7:
- Macaulay2: rebuild (depends on libfplll, lrslib, normaliz, polymake,
and Singular): I have tried to build this package a couple of times
already in 2020, and it keeps failing on i386. The failures are very
weird, suggesting memory corruption. I'm not seeing the issue on any
other architecture, and my attempts to track it down have so far
failed to bear fruit. If Rex Dieter, the maintainer of this package,
does not object, I just might ExcludeArch: %{ix86} for now until I can
figure out what's going on.
- pynac: rebuild (depends on flint and Singular)
Round 8:
- sagemath: update to version 9.1 (depends on every package above
except Macaulay2)
--
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 7/6/20 1:48 PM, Sergio Belkin wrote: At https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_systemd_zram-generator.3F it says: "Do not create swap partition/LV with default installations." I don't understand if it is a description or a prescription :)I mean, can coexist swap partition/LV and zram? Yes, zram is just a compressed block device in RAM and it's being used here as swap. You can have multiple swap devices active at the same time. That's what I'm currently using. I have a zram swap device and a disk swap partition as overflow. But the plan is to avoid having any swap on disk by default. ___ 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 Mon, Jul 6, 2020 at 5:05 PM John M. Harris Jr wrote: > > On Monday, July 6, 2020 1:34:05 PM MST Neal Gompa wrote: > > On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr > > wrote: > > > > > > > > > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > > > > > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot > > > > and > > > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > > > are not. Which makes sense to me. Why would you encrypt /boot? The > > > > files you can find there are public anyway, you can download them from > > > > the fedora servers. Encrypting /boot would make the boot process more > > > > fragile for no benefit. > > > > > > > > > > > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > > > encrypt /boot to ensure that your boot images have not been tampered with, > > > or config files haven't been read by somebody other than the end user. > > > > > > Encryption != integrity/authentication. The only thing encryption > > guarantees is that the data is not visible, not that it hasn't been > > tampered with. Usually, dm-verity or dm-integrity is used for what > > you're asking for. Android uses dm-verity, if I remember correctly. > > That's true, in an ideal world, one of these modules would be used. However, > LUKS is often sufficient to know that it hasn't been modified, depending on > the ciphers used, if it does load correctly. > It's not guaranteed though, and you shouldn't rely on that for verifying integrity if you care about that. You either will want an authenticated filesystem or use a dm stack configuration that includes authentication. > > > > sd-boot still wouldn't work out-of-the-box though, due to /boot being > > > > xfs not vfat and firmware typically not shipping with xfs drivers. > > > > > > > > > > > > If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still > > > used for /boot in Fedora, by default. > > > > > > > > > > > > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > > > filesystems. > > > > > > > > > > > > Is there a notable benefit to using that over GRUB2, which already has > > > support on both UEFI and BIOS? > > > > > > > > > > > > Less complexity in the boot chain, mainly. But the EFI drivers would > > need to be signed by MS, I think? That would massively complicate > > things. > > It's less complex to maintain one solution for both types of boot, I'd > imagine. I'm not the one that'd be doing the work to support it, so far be it > from me to prevent somebody from doing so, but that's just what it sounds > like. Right now, we have one solution that works well for both. > If we wanted to be UEFI first, we could make BIOS boots emulate UEFI and boot through the UEFI chain all the way through. We already do this for some boards on ARM with U-Boot, if I remember correctly. If that were possible on x86, then we could get down to one boot chain path regardless. -- 真実はいつも一つ！/ 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 Monday, July 6, 2020 1:34:05 PM MST Neal Gompa wrote: > On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr > wrote: > > > > > > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > > > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot > > > and > > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > > are not. Which makes sense to me. Why would you encrypt /boot? The > > > files you can find there are public anyway, you can download them from > > > the fedora servers. Encrypting /boot would make the boot process more > > > fragile for no benefit. > > > > > > > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > > encrypt /boot to ensure that your boot images have not been tampered with, > > or config files haven't been read by somebody other than the end user. > > > Encryption != integrity/authentication. The only thing encryption > guarantees is that the data is not visible, not that it hasn't been > tampered with. Usually, dm-verity or dm-integrity is used for what > you're asking for. Android uses dm-verity, if I remember correctly. That's true, in an ideal world, one of these modules would be used. However, LUKS is often sufficient to know that it hasn't been modified, depending on the ciphers used, if it does load correctly. > > > sd-boot still wouldn't work out-of-the-box though, due to /boot being > > > xfs not vfat and firmware typically not shipping with xfs drivers. > > > > > > > > If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still > > used for /boot in Fedora, by default. > > > > > > > > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > > filesystems. > > > > > > > > Is there a notable benefit to using that over GRUB2, which already has > > support on both UEFI and BIOS? > > > > > > > Less complexity in the boot chain, mainly. But the EFI drivers would > need to be signed by MS, I think? That would massively complicate > things. It's less complex to maintain one solution for both types of boot, I'd imagine. I'm not the one that'd be doing the work to support it, so far be it from me to prevent somebody from doing so, but that's just what it sounds like. Right now, we have one solution that works well for both. -- 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.
> > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > > encrypt /boot to ensure that your boot images have not been tampered with, > > or > > config files haven't been read by somebody other than the end user. > > > > Encryption != integrity/authentication. The only thing encryption > guarantees is that the data is not visible, not that it hasn't been > tampered with. Usually, dm-verity or dm-integrity is used for what > you're asking for. Android uses dm-verity, if I remember correctly. Or measurement and attestation via TPM2. > > > sd-boot still wouldn't work out-of-the-box though, due to /boot being > > > xfs not vfat and firmware typically not shipping with xfs drivers. > > > > If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still used > > for /boot in Fedora, by default. > > > > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > > filesystems. > > > > Is there a notable benefit to using that over GRUB2, which already has > > support > > on both UEFI and BIOS? > > > > Less complexity in the boot chain, mainly. But the EFI drivers would > need to be signed by MS, I think? That would massively complicate > things. I believe that to be correct, of could Apply has control over that for their platform, you'd also need to load them some how, I'm guessing sd-boot could try loading/locking if it can't read a file system... suddenly things start to head towards complexity again. ___ 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: swap on zram
El vie., 5 jun. 2020 a las 16:10, John M. Harris Jr () escribió: > On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 11:47 AM John M. Harris Jr > > wrote: > > > > > > > > > On Thursday, June 4, 2020 11:54:37 PM MST Kevin Kofler wrote: > > > > > > > > > > Also -1 to adding something to the core system that is written in a > > > > language for which we do not even have dynamic linking support. Or > > > > even real static linking support, as opposed to packaging libraries > as > > > > source code.> > > > > > Kevin Kofler > > > > > > > > > > > > Agreed. Besides, GNOME already has this enabled, right? It's definitely > > > not right for servers, as I brought up the last time this was thrown > > > around. > > > > In discussions with both cloud and server folks, their use cases often > > do not even create disk-based swap at all. A small swap-on-zram > > provides all the benefits of inactive anonymous page eviction, > > including reducing reclaim of file pages, without the black hole > > performance problems of swap-on-drive. > > > > So yes it's well suited for these cases and the proposal does include > > them. If they wish to be left out, that's up to those working groups. > > It's possible to make sure /etc/systemd/zram-generator is not present. > > That doesn't seem to reflect reality. If you download the Server image > right > now, and go with its automatic partitioning scheme generation, it'll give > you > a swap partition on LVM. This is correct for most servers, not necessarily > the > LVM part, but having swap on disk. > > It really seems like this is wrong for most of Fedora, but that individual > parts, such as Fedora GNOME or IoT, should be left to make the decision > for > themselves, without affecting the rest. > > -- > 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 > At https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_systemd_zram-generator.3F it says: "Do not create swap partition/LV with default installations." I don't understand if it is a description or a prescription :)I mean, can coexist swap partition/LV and zram? Thanks in advance! -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr wrote: > > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > are not. Which makes sense to me. Why would you encrypt /boot? The > > files you can find there are public anyway, you can download them from > > the fedora servers. Encrypting /boot would make the boot process more > > fragile for no benefit. > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > encrypt /boot to ensure that your boot images have not been tampered with, or > config files haven't been read by somebody other than the end user. > Encryption != integrity/authentication. The only thing encryption guarantees is that the data is not visible, not that it hasn't been tampered with. Usually, dm-verity or dm-integrity is used for what you're asking for. Android uses dm-verity, if I remember correctly. > > > sd-boot still wouldn't work out-of-the-box though, due to /boot being > > xfs not vfat and firmware typically not shipping with xfs drivers. > > If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still used > for /boot in Fedora, by default. > > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > filesystems. > > Is there a notable benefit to using that over GRUB2, which already has support > on both UEFI and BIOS? > Less complexity in the boot chain, mainly. But the EFI drivers would need to be signed by MS, I think? That would massively complicate things. -- 真実はいつも一つ！/ 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 Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > are not. Which makes sense to me. Why would you encrypt /boot? The > files you can find there are public anyway, you can download them from > the fedora servers. Encrypting /boot would make the boot process more > fragile for no benefit. I guess that shows how unfamiliar I am with UEFI boot Fedora. You would encrypt /boot to ensure that your boot images have not been tampered with, or config files haven't been read by somebody other than the end user. > sd-boot still wouldn't work out-of-the-box though, due to /boot being > xfs not vfat and firmware typically not shipping with xfs drivers. If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still used for /boot in Fedora, by default. > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > filesystems. Is there a notable benefit to using that over GRUB2, which already has support on both UEFI and BIOS? -- 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.
Hi,
On 7/6/20 9:36 PM, John M. Harris Jr wrote:
On Monday, July 6, 2020 5:51:40 AM MST Gerd Hoffmann wrote:
Image boots in both uefi (sd-boot) and bios (grub2) mode, and the config
file for the latter is so short that I can include it here without
hitting the mailing list size limit ;)
-- cut here --
function load_video {
insmod all_video
}
insmod part_gpt
insmod fat
insmod serial
insmod terminal
insmod blscfg
serial --unit=0 --speed=115200
terminal_output console serial
terminal_input console serial
set boot='hd0,gpt2'
set timeout=3
blscfg
-- cut here --
Does that actually include the drivers necessary to use your keyboard?
Somebody pointed out to me, in private, that the drivers for their keyboard
weren't loaded in the current Workstation GRUB2 config.
UEFI grub uses the EFI provided keyboard drivers, if the keyboard
does not work in grub then that someone likely has "fastboot" enabled
in his BIOS and he has a BIOS which skips all USB device setup when
this is enabled.
UEFI firmware which supports some form of fastboot is supposed to delay
scanning the USB bus until we ask for input (and we currently always
ask for input) but many BIOS-es do not delay, but instead entirely skip,
scanning the USB bus when their fastboot or equivalent option is on.
Regards,
Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Modules again
On Tue, 19 May 2020 19:00:25 +0100 Paul Howarth wrote: > On Tue, 19 May 2020 09:21:46 -0700 > Kevin Fenzi wrote: > > > On Tue, May 19, 2020 at 11:48:04AM -0400, Stephen John Smoogen > > wrote: > > > On Tue, 19 May 2020 at 11:05, Paul Howarth > > > wrote: > > > > On Tue, 19 May 2020 09:07:30 -0400 > > > > Stephen John Smoogen wrote: > > > > > > > > > On Tue, 19 May 2020 at 06:05, Paul Howarth > > > > > wrote: > > > > > > > > Yes, I'm using vanilla configs straight from mock-core-configs > > > > for this, and that has epel-8-x86_64.cfg, which pulls in > > > > centos-8.tpl, which has the PowerTools repo defined and not > > > > disabled. > > > > > > > > (I generally use my own configs and don't touch the original > > > > ones, so I know that if I try the original ones from upstream > > > > then they should work as intended) > > > > > > > > Note that the error message doesn't say it can't find > > > > Judy-devel, it says that it (and Judy) is/are excluded. I don't > > > > know why that is. > > > > > > > > > > > Ohhh sorry. I missed the obvious. I am going to guess from past > > > problems, the system is trying to pull in mariadb which filters it > > > out and mariadb-devel which has it in. So when it sees the filters > > > it says 'nope can't do this sorry'. I wish there was a 'no I know > > > it might break my system do it anyway!' flag but I don't see one > > > looking through /usr/share/doc/mock/site-defaults.cfg . This was > > > one of the reasons for grobisplitter being used. > > > > You should be able to set: > > > > module_hotfixes = True > > > > in your dnf/yum/mock config. > > > > From the dnf man page: > > > > "Set this to True to disable module RPM filtering and make all RPMs > > from the repository available. The default is False. This allows > > user to create a repository with cherry-picked hotfixes that are > > included in a package set on a modular system." > > Ah, setting that option for the PowerTools repo allows the build to > work. Now if only there was a way to do that from the command line so > I didn't have to touch the mock config. And now in CentOS 8.2 Judy-devel is missing from the PowerTools repo and so it doesn't work again. Ho hum. Paul. ___ 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: Packagers with no corresponding valid bugzilla accounts
On Thu, Jun 25, 2020 at 02:55:50PM +0200, Pierre-Yves Chibon wrote: > On Sat, Jun 13, 2020 at 10:10:36PM +0200, Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > > > If you are a packagers or are watching tickets on dist-git (ie: asked to be > > cc'ed on tickets on bugzilla for a given package), you must have a valid > > bugzilla account associated with the email address you have set in FAS. > > > > There are currently 66 users and groups who do not satisfy this requirement. > > This has a direct impact as the script syncing from dist-git to bugzilla the > > information about the default assignee and the CC list updates components in > > bugzilla in a single request to reduce the load on the server. > > So if someone in the CC list does not have a valid bugzilla account, the > > entire request will fail to update both the CC list and the default > > assignee. > > > > Accounts in this state may at some point be removed from packages/cc, so > > it's > > important to correct your account soon! > > > > So, if your name is listed here, please take a minute and create a bugzilla > > for the email you have associated with your FAS account: > Good Morning Everyone, The list is slowly going down, we have now 38 accounts that are still problematic, they have all received several personal emails over the last few weeks and none but one reacted. I will likely start to ping FESCo about them starting next week. Here is the updated list: affix alen amitshah andreyma avesh dmsimard etingof gnikandrov @graphics-sig ignotusp itsbill jefferson2z kir luismartingil marcdeop mbartos mhabrnal mildew mmahut nguzman pgibson robled romal rpitonak rspanton sakalosj squallbayu sspreitz sturivnyi svahl tnorth tstclair usercont vbatts vicodan vpolasek @weldr-sig yuwata Thanks, Pierre pgpnV2FY7HgVL.pgp Description: PGP signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packagers with no corresponding valid bugzilla accounts
On Thu, Jun 25, 2020 at 02:55:50PM +0200, Pierre-Yves Chibon wrote: > On Sat, Jun 13, 2020 at 10:10:36PM +0200, Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > > > If you are a packagers or are watching tickets on dist-git (ie: asked to be > > cc'ed on tickets on bugzilla for a given package), you must have a valid > > bugzilla account associated with the email address you have set in FAS. > > > > There are currently 66 users and groups who do not satisfy this requirement. > > This has a direct impact as the script syncing from dist-git to bugzilla the > > information about the default assignee and the CC list updates components in > > bugzilla in a single request to reduce the load on the server. > > So if someone in the CC list does not have a valid bugzilla account, the > > entire request will fail to update both the CC list and the default > > assignee. > > > > Accounts in this state may at some point be removed from packages/cc, so > > it's > > important to correct your account soon! > > > > So, if your name is listed here, please take a minute and create a bugzilla > > for the email you have associated with your FAS account: > Good Morning Everyone, The list is slowly going down, we have now 38 accounts that are still problematic, they have all received several personal emails over the last few weeks and none but one reacted. I will likely start to ping FESCo about them starting next week. Here is the updated list: affix alen amitshah andreyma avesh dmsimard etingof gnikandrov @graphics-sig ignotusp itsbill jefferson2z kir luismartingil marcdeop mbartos mhabrnal mildew mmahut nguzman pgibson robled romal rpitonak rspanton sakalosj squallbayu sspreitz sturivnyi svahl tnorth tstclair usercont vbatts vicodan vpolasek @weldr-sig yuwata Thanks, Pierre pgpjxWMnYL3YO.pgp Description: PGP signature ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
Re: Could not execute build: database outage
On Monday, 6 July 2020 18.55.11 WEST Kevin Fenzi wrote: > I restarted the database server this morning. It usually takes about 1.5 > seconds to restart, so you must have just hit it in that window. > > kevin My only concern was if there was any kind of (hidden) consequence of the error. From your answer I conclude that everything is OK and I just found a digital four-leaf clover. :-) Thank you Kevin for your prompt answer. -- José Abílio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Swap on ZRAM thank you
I have been playing with swap on ZRAM some in the past days, and more formally running it through it's paces during today's test day[0], and I just want to say thank you to everyone involved in getting it ready for release. It has made a marked difference in desktop responsiveness when doing memory intensive tasks on memory constrained systems. It really does feel like magic. Thanks again! 0 - https://fedoraproject.org/wiki/Test_Day:F33_SwapOnZRAM ___ 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 Monday, July 6, 2020 2:10:18 AM MST Jóhann B. Guðmundsson wrote: > On 5.7.2020 19:31, Solomon Peachy wrote: > > > 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. > > > > As do I. > > Hopefully Daniel's response of the poor state those tools are in, will > raise some red flags within Red Hat in which it starts throwing some > resources ( money,workforce) to have this addressed before RHEL 9 gets > released. > > Atleast that is what I would do if I was a person in power within Red > Hat ( or a company that provides or relies on a solution based on those > tools) and had read his response which described quite the "alarming > situation" for products within the company in relation where the > industry is heading. I don't understand why you're trying to light fires for no reason. What we have now works on all platforms already, including UEFI. If every existing system dropped BIOS support *today*, we'd still be fine. Please don't exaggerate the importance of these issues. We have a working UEFI solution with GRUB2, which also works well for BIOS. There is no reason for RHEL to drop BIOS either, in fact, they have more reason to support it than Fedora: So their customers can continue to use their product. -- 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 6.7.2020 12:07, Tomasz Torcz wrote: On Mon, Jul 06, 2020 at 01:31:30PM +0200, Gerd Hoffmann wrote: The BIOS provides block device access at sector level, so the boot loader has little choice but implementing drivers for all kinds of stuff. Or use fragile block lists like lilo did in the last century. With UEFI much more functionality is provided by the firmware and there is little reason for a bootloader to have tons of drivers. With the exception of filesystem drivers in case you want boot from something != vfat. But even that should ideally be implemented as uefi driver not as grub2 module. FWIW, there seem to be UEFI driver for btrfs, ZFS, XFS and others: https://efi.akeo.ie/ Thanks this was very helpful. JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Monday, July 6, 2020 5:51:40 AM MST Gerd Hoffmann wrote:
> Image boots in both uefi (sd-boot) and bios (grub2) mode, and the config
> file for the latter is so short that I can include it here without
> hitting the mailing list size limit ;)
>
> -- cut here --
> function load_video {
> insmod all_video
> }
>
> insmod part_gpt
> insmod fat
> insmod serial
> insmod terminal
> insmod blscfg
>
> serial --unit=0 --speed=115200
> terminal_output console serial
> terminal_input console serial
>
> set boot='hd0,gpt2'
> set timeout=3
> blscfg
> -- cut here --
Does that actually include the drivers necessary to use your keyboard?
Somebody pointed out to me, in private, that the drivers for their keyboard
weren't loaded in the current Workstation GRUB2 config.
--
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 6.7.2020 18:39, Javier Martinez Canillas wrote: On Mon, Jul 6, 2020 at 10:39 AM Jóhann B. Guðmundsson wrote: On 5.7.2020 18:34, Javier Martinez Canillas wrote: 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). Since you are in contact with and thus presumably you are one of the "bootloader folks" could you clarify who those individual are and what role they play and which bootloaders they represent in the distribution and on which arch etc. and where they can be contacted ( mailinglist ) since I don't find any documentation about any bootloader WG existing within Fedora yet such a team seems to exist since it's being mentioned. Sure, I meant the members of the Red Hat bootloader team (Peter Jones, Jan Hlavac and me) and people who are not part of the bootloader team but work very closely with us and help to improve the boot stack in general. Mostly Hans de Goede and Christian Kellner but also others. Peter maintains all the projects in https://github.com/orgs/rhboot and their respective packages in Fedora. And I help him with that work. We are also involved in the upstream communities of the bootloaders that are used in the architectures supported by Fedora. These are: - GRUB (x86_64 legacy BIOS and EFI, aarch64 EFI and ppc64le OF) - Petitboot (ppc64le OPAL) - zipl (s390x) - u-boot (armv7). But for the last two most of the work and the package maintenance is done by Dan Horák (s390utils-base) and Peter Robinson (uboot-images-armv7). All these people can be contacted in the Fedora devel mailing list. I hope this answers your question, please let me know if you need more details. This was precisely the info I was looking for. Thanks JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] please review: PR 51202 - Completely move backend monitors to BDB backend code
https://pagure.io/389-ds-base/pull-request/51202 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: [fedora-java] Questions on an update to javamail in ursine
Hey Mat, On further investigation, the compatibility changes that require attention are made in javamail 1.6.3 and later, see: https://eclipse-ee4j.github.io/mail/docs/COMPAT.txt The maven coordinates are changed, generally javax -> jakarta. This also affects the osgi provides. Regards, Jie Kang On Thu, Jul 2, 2020 at 5:54 AM Mat Booth wrote: > > > > On Wed, 1 Jul 2020 at 15:05, Fabio Valentini wrote: >> >> On Mon, Jun 29, 2020 at 4:06 PM Jie Kang wrote: >> > >> > Hi all, >> > >> > javamail ursine is using version 1.5.2 while there are some module >> > streams at 1.6.x >> > >> > The upstream project also moved to the eclipse foundation and these >> > 1.6.x releases have different exports for OSGi, making an update to >> > them potentially breaking for users. >> > >> > I'd like to update ursine to 1.6.x, but I understand packages >> > depending on them should be notified or some such. However I realized >> > I don't know what commands to run to get a list of such and then where >> > to send it. Could anyone advise? >> > >> > Also, upstream repo was renamed: https://github.com/eclipse-ee4j/mail >> > so maybe a new package 'mail' can be introduced to use it? Any >> > thoughts there? >> >> I use this command to check for dependent packages: >> >> $ dnf --repo rawhide --repo rawhide-source --releasever rawhide >> repoquery --whatrequires javamail >> >> Which is enough, since there are no other subpackages except -javadoc. >> The command yielded (on July 1): >> >> ant-0:1.10.8-1.fc33.src >> ant-javamail-0:1.10.8-1.fc33.noarch >> bouncycastle-0:1.65-2.fc33.src >> httpunit-0:1.7-29.fc32.src >> log4j-0:2.13.1-1.fc33.src >> log4j12-0:1.2.17-26.fc32.src >> openas2-0:2.10.0-2.fc33.src >> openas2-lib-0:2.10.0-2.fc33.noarch >> >> So the list of affected packages seems to be: >> >> - ant (Stewardship / Java SIG will deal with this) >> - bouncycastle (?) > > > Bouncycastle is me (it is a dep of jgit). From reading the javamail "compat" > document: https://javaee.github.io/javamail/docs/COMPAT.txt it looks like I > probably will need to take no action at all. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Out of the 2 computers I own, 2 only boot through legacy BIOS. One claims to have UEFI support but I haven't managed to get it running with tens of hours of work over the years. In other words: I think it is too early to drop support for this legacy technology. ___ 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 Mon, Jul 6, 2020 at 10:39 AM Jóhann B. Guðmundsson wrote: > > On 5.7.2020 18:34, Javier Martinez Canillas wrote: > > 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). > > Since you are in contact with and thus presumably you are one of the > "bootloader folks" could you clarify who those individual are and what > role they play and which bootloaders they represent in the distribution > and on which arch etc. and where they can be contacted ( mailinglist ) > since I don't find any documentation about any bootloader WG existing > within Fedora yet such a team seems to exist since it's being mentioned. > Sure, I meant the members of the Red Hat bootloader team (Peter Jones, Jan Hlavac and me) and people who are not part of the bootloader team but work very closely with us and help to improve the boot stack in general. Mostly Hans de Goede and Christian Kellner but also others. Peter maintains all the projects in https://github.com/orgs/rhboot and their respective packages in Fedora. And I help him with that work. We are also involved in the upstream communities of the bootloaders that are used in the architectures supported by Fedora. These are: - GRUB (x86_64 legacy BIOS and EFI, aarch64 EFI and ppc64le OF) - Petitboot (ppc64le OPAL) - zipl (s390x) - u-boot (armv7). But for the last two most of the work and the package maintenance is done by Dan Horák (s390utils-base) and Peter Robinson (uboot-images-armv7). All these people can be contacted in the Fedora devel mailing list. I hope this answers your question, please let me know if you need more details. 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
Fedora rawhide compose report: 20200706.n.0 changes
OLD: Fedora-Rawhide-20200704.n.1 NEW: Fedora-Rawhide-20200706.n.0 = SUMMARY = Added images:0 Dropped images: 4 Added packages: 1 Dropped packages:0 Upgraded packages: 27 Downgraded packages: 0 Size of added packages: 1.27 MiB Size of dropped packages:0 B Size of upgraded packages: 4.09 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 20.69 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200704.n.1.s390x.raw.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200704.n.1.s390x.qcow2 Image: Comp_Neuro live x86_64 Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20200704.n.1.iso Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200704.n.1.s390x.vmdk = ADDED PACKAGES = Package: libvirt-test-API-1.1-1.fc33 Summary: Python based regression tests for libvirt API RPMs:libvirt-test-API libvirt-test-API-doc Size:1.27 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: 4diac-forte-1.12.0-1.fc33 Old package: 4diac-forte-1.11.0-2.fc32 Summary: IEC 61499 runtime environment RPMs: 4diac-forte Size: 2.15 MiB Size change: 18.25 KiB Changelog: * Sun Jul 05 2020 Neal Gompa - 1.12.0-1 - Update to release 1.12.0 to fix with CMake 3.17+ Package: GMT-6.1.0-1.fc33 Old package: GMT-6.0.0-4.fc33 Summary: Generic Mapping Tools RPMs: GMT GMT-common GMT-devel GMT-doc Size: 65.71 MiB Size change: 10.91 MiB Changelog: * Sun Jul 05 2020 Orion Poplawski - 6.1.0-1 - Update to 6.1.0 Package: R-qvalue-2.18.0-3.fc33 Old package: R-qvalue-2.18.0-2.fc32 Summary: Q-value estimation for false discovery rate control RPMs: R-qvalue Size: 2.68 MiB Size change: -583 B Changelog: * Sat Jul 04 2020 Jos?? Ab??lio Matos - 2.18.0-3 - rebuild for R 4 Package: R-rprintf-0.2.1-9.fc33 Old package: R-rprintf-0.2.1-8.fc33 Summary: Adaptive Builder for Formatted Strings RPMs: R-rprintf Size: 29.09 KiB Size change: 280 B Changelog: * Fri Jul 03 2020 Jos?? Matos - 0.2.1-9 - add bootstrap support (for new R releases) Package: candy-icon-theme-0-14.20200704git8c144f59.fc33 Old package: candy-icon-theme-0-13.20200620git4be1a05e.fc33 Summary: Sweet gradient icon theme RPMs: candy-icon-theme Size: 520.35 KiB Size change: 18.69 KiB Changelog: * Sun Jul 05 2020 Artur Iwicki - 0.14.20200704git8c144f59 - Update to latest upstream snapshot Package: dummy-test-package-crested-0-749.fc33 Old package: dummy-test-package-crested-0-740.fc33 Summary: Dummy Test Package called Crested RPMs: dummy-test-package-crested Size: 53.79 KiB Size change: 540 B Changelog: * Sat Jul 04 2020 packagerbot - 0-741 - rebuilt * Sun Jul 05 2020 packagerbot - 0-742 - rebuilt * Sun Jul 05 2020 packagerbot - 0-743 - rebuilt * Sun Jul 05 2020 packagerbot - 0-744 - rebuilt * Sun Jul 05 2020 packagerbot - 0-745 - rebuilt * Sun Jul 05 2020 packagerbot - 0-746 - rebuilt * Sun Jul 05 2020 packagerbot - 0-747 - rebuilt * Sun Jul 05 2020 packagerbot - 0-748 - rebuilt * Mon Jul 06 2020 packagerbot - 0-749 - rebuilt Package: dummy-test-package-gloster-0-828.fc33 Old package: dummy-test-package-gloster-0-818.fc33 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 58.38 KiB Size change: 600 B Changelog: * Sun Jul 05 2020 packagerbot - 0-819 - rebuilt * Sun Jul 05 2020 packagerbot - 0-820 - rebuilt * Sun Jul 05 2020 packagerbot - 0-821 - rebuilt * Sun Jul 05 2020 packagerbot - 0-822 - rebuilt * Sun Jul 05 2020 packagerbot - 0-823 - rebuilt * Sun Jul 05 2020 packagerbot - 0-824 - rebuilt * Sun Jul 05 2020 packagerbot - 0-825 - rebuilt * Sun Jul 05 2020 packagerbot - 0-826 - rebuilt * Mon Jul 06 2020 packagerbot - 0-827 - rebuilt * Mon Jul 06 2020 packagerbot - 0-828 - rebuilt Package: dummy-test-package-rubino-0-749.fc33 Old package: dummy-test-package-rubino-0-740.fc33 Summary: Dummy Test Package called Rubino RPMs: dummy-test-package-rubino Size: 53.82 KiB Size change: 546 B Changelog: * Sat Jul 04 2020 packagerbot - 0-741 - rebuilt * Sun Jul 05 2020 packagerbot - 0-742 - rebuilt * Sun Jul 05 2020 packagerbot - 0-743 - rebuilt * Sun Jul 05 2020 packagerbot - 0-744 - rebuilt * Sun Jul 05 2020 packagerbot - 0-745 - rebuilt * Sun Jul 05 2020 packagerbot - 0-746 - rebuilt * Sun Jul 05 2020 packagerbot - 0-747 - rebuilt * Sun Jul 05 2020 packagerbot - 0-748 - rebuilt * Mon Jul 06 2020 packagerbot - 0-749 - rebuilt Package: elementary-xfce-icon
Re: Could not execute build: database outage
On Mon, Jul 06, 2020 at 03:03:07PM +0100, José Abílio Matos wrote: > While calling "fedpkg build" I got the warning (error?) displayed in the > title: > > ... > Could not execute build: database outage > > Apparently the build is over and well. :-) > https://koji.fedoraproject.org/koji/taskinfo?taskID=46677172 > > This is just a report since everything is OK, I have used a side tag and the > build shows there. I restarted the database server this morning. It usually takes about 1.5 seconds to restart, so you must have just hit it in that window. ;( kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
SCons-4.0.0 coming on Rawhide
Hi all. SCons-4.0.0 [1] is coming on Rawhide branch. Involved packages: $ repoquery --release rawhide --whatrequires python3-scons --disablerepo=* --enablerepo=fedora-source --enablerepo=updates-source Last metadata expiration check: 0:00:02 ago on lun 6 lug 2020, 19:27:21. boswars-0:2.7-22.svn160110.fc33.src compat-tolua++-0:1.0.93-13.fc33.src galera-0:26.4.4-2.fc33.src glob2-0:0.9.4.4-51.fc33.src gpsd-1:3.20-1.fc33.src libffado-0:2.4.3-2.fc33.src libserf-0:1.3.9-15.fc32.src mingw-nsis-0:3.05-2.fc33.src mypaint-0:2.0.0-0.6.beta.0.fc32.src netpanzer-0:0.8.7-14.fc32.src pingus-0:0.7.6-36.fc32.src powdertoy-0:95.0-2.fc33.src sunpinyin-0:3.0.0-0.2.20190805git.fc32.src tolua++-0:1.0.93-29.fc33.src vdrift-0:20141020-21.fc33.src wesnoth-0:1.15.3-4.fc33.src [1] https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1518967/ -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/2/20 4:38 PM, Eric Sandeen wrote: Running 10 loops on each of btrfs, ext4, and xfs I got results that look like this (ext4 always creates empty lost+found so it will always find at least 1 file there) btrfs ... == 4 fsck failures, 2 mount failures ext4 ... == 0 fsck failures, 0 mount failures xfs ... == 0 fsck failures, 0 mount failures Did you check the content of the filesystem, to make sure that the files restored by fsck are actually correct? I think ext4/xfs may be showing 0 files lost but they may or may not contain the pre-damage content, while btrfs would just fess up that it lost them if the checksums didn't agree. ___ 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?
Adam Saleh wrote: > Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this > problem few months ago. > It is a koji plugin as well as CLI tool that makes bumping the release > field and generating changelog problem of Koji, > instead of package-maintainer. Currently it sits deployed in staging koji, > so you can give it a test-drive :-) What will the release value be when a package that uses autorel is built with fedpkg local? Or fedpkg mockbuild? Björn Persson pgpbSFrl37n3U.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Mon, 6 Jul 2020 at 01:19, Chris Murphy wrote:
>
> 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?
>
Aren't most disk failure tests 'huh it somehow happened at least once
and I think this explains all these other failures too?' I know that
with giant clusters you can do more testing but you also have a lot of
things like
What is the chance that a disk will die over time? 100%
What is the chance that a disk died from this particular scenario?
0.0 %
reword the question slightly differently.. What is the chance this
disk died from that scenario? 100%.
For the HPC computers we had a score of Phd staticians coming up with
all kinds of papers on disk failure modes which if asked in one way
would come up with practically 0% odds it would happen. However all of
the disk failures had happened at least once over a time frame...
sometimes a short one, sometimes a long one, sometimes so often that
someone had to retract a paper because it was clear that while the
maths said it shouldn't happen .. it did in real life.
--
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: Can we do away with release and changelog bumping?
On 7/6/20 8:27 AM, Björn Persson wrote:
> Florian Weimer wrote:
>> * Björn Persson:
>>
>>> The macro could be defined like this for example:
>>>
>>>%buildtag .%(date +%%s)
>>
>> Using time for synchronization is always a bit iffy.
>
> Well, if somebody manages to build a package twice within a second,
> using two different versions of a compiler ... then they still won't be
> any worse off than they are today. Koji should still not allow it.
>
>>> It would be used in each spec like this:
>>>
>>>Release: 1%{?dist}%{?buildtag}
fwiw, I've just been cobbling together a couple of specs with date tagging for
version mgmt between repos.
once I was pleasantly reminded to double-%% the date formats inside specs, it's
complicated only a bit by the occasional need to redefine %dist after multiple
forgemeta pulls.
otherwise, it's really handy.
currently this, e.g., works nicely 4 me:
https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01518639-nginx/nginx.spec
for my workflow,
-- get it working locally with rpmbuild
-- prove it works and is a properly closed build env in mock, locally
-- move local mock result into a local repo
-- push spec/srpm to COPR for build
I can effectively manage 'same' pkg+version, with builds differentiated by time
stamps. (for me, 1 sec min time slice is certainly good enuf!)
entirely possible that my 'kludge' hits an example of "a bit iffy"; hasn't
quite yet, tho ...
___
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 7/4/20 8:18 PM, John M. Harris Jr wrote: I've never managed to get one of my own Fedora machines to the point of OOMing, and, when I have seen others do it, it's a problem that would have been solved by having more swap space. I am a tab hoarder so I used to wedge the browser due to memory leaks (some live ad pages would blow up into gigabytes of RAM). I think recent browser versions are more resistant to that---I haven't locked up in a while, although it may be because I also tend to have a Task Manager open, sorted by Memory size, and I kill pages that keep growing. More swap doesn't necessarily solve this problem: remember that 1GB/min is a ballpark HD speed so if you have 10GB swap that your system is actually trying to use, you will just sit there for 10 minutes. ___ 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 Mon, 2020-07-06 at 14:51 +0200, Gerd Hoffmann wrote: > Hi, > > > My real problem with grub2 is not that it's complex, but the fact > > that > > it exposes its complexities to the user. > > The config file syntax is a mess indeed. The fact that you need a > config generator tool in the first place speaks volumes ... > > But note that grub config files don't have to be as complex as the > grub2-mkconfig generated ones. > > > I'm willing to try systemd-boot on a virtual machine, to see if it > > makes things easier, but the fact it doesn't support BIOS makes it > > not > > very usable for me. > > https://www.kraxel.org/repos/images/fedora-31-efi-systemd-x86_64.qcow2.xz > Thanks! I downloaded the image and will check it out as soon as I find some free time... :) 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
[EPEL-devel] Re: Can anyone help me build or build and share gnome-pomodoro for Centos 8.2?
On Sat, Jul 4, 2020 at 2:33 AM david wrote: > > Hi, I am participating in https://github.com/codito/gnome-pomodoro/issues/456 > thread and it was mentioned by @mbooth101 to ask for advice here. > > Is it possible to build gnome-pomodoro on Centos 8.2? > I believe this is the fedora package gnome-shell-extension-pomodoro I did a quick test build of it, and it didn't build. It was missing gom-devel and telepathy-glib-devel I have no idea why it want's telepathy-glib-devel, but telepathy-glib looks like it should build in EPEL8. gom-devel will be harder. gom is in RHEL8, but gom-devel is one of those "missing devel" packages. You'd need to get it into CentOS 8 Devel repo. But maybe gom-devel is optional, I don't know. > I am a total newb at building packages, and this is my first attempt. The > best possible result would be if someone was willing to build this and upload > it to EPEL8? > To get packages into RHEL8, the best way is to open a bug requesting it[1]. If it already isn't in an earlier EPEL version (which gnome-shell-extension-pomodoro isn't) then you need to open it in Fedora / Fedora instead of Fedora / EPEL When you open the bug, you need to remember that just because someone maintains a package, doesn't mean they want to maintain it in EPEL also.. Troy [1] - https://bugzilla.redhat.com/ ___ 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: Can we do away with release and changelog bumping?
Florian Weimer wrote:
> * Björn Persson:
>
> > The macro could be defined like this for example:
> >
> > %buildtag .%(date +%%s)
>
> Using time for synchronization is always a bit iffy.
Well, if somebody manages to build a package twice within a second,
using two different versions of a compiler ... then they still won't be
any worse off than they are today. Koji should still not allow it.
> > It would be used in each spec like this:
> >
> > Release: 1%{?dist}%{?buildtag}
>
> We could put the Koji task ID directly into the %dist tag. We know that
> this works in principle. If we are worried that the number gets too
> large, we could subtract the current task ID at the time the fcNN part
> of the %dist tag changes.
That could also work. Locally rebuilt packages would of course lack the
task ID, so they would compare as less than the official package. Is
that desirable? It could work as an incentive for the user to add some
local tag to the release value, making it clearer that the package has
been modified locally.
Or would we want to modify the disttag so that locally rebuilt packages
would compare as greater than the corresponding official package? Then
Yum would replace the official package with the rebuilt one, but would
still install an official update with a greater release number.
Björn Persson
pgpTBEyG2fROW.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/3/20 10:39 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.
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.
Hmm I wonder if some of my "ignore X failures" stuff got lost over the years, we
should be able to recover far more than that. I'll add it to the list of things
to dig into this week. Thanks,
Josef
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: modular and personal koji
On Mon, 6 Jul 2020 at 10:33, Didier Fabert wrote: > > Hi all, > > With my personal koji (on el8), I cannot build some packages for my el8 > tag. All failures are about modular metadata packages which cannot be > installed. > Koji doesn't really understand modules and the depsolver has problems. For setting up EPEL we needed to do 2 things to make this work. 1. At first we needed to use grobisplitter to flatten the repos a bit so that koji could understand them: https://github.com/fedora-modularity/GrobiSplitter 2. We then followed https://smoogespace.blogspot.com/2019/07/epel-8-production-layout.html 3. In koji itself we needed to tell the depsolver to use dnf versus its own solver. 4. We also had to have koji to turn on the hotpatch flag so dnf would pull in items. > DEBUG util.py:621: No available modular metadata for modular package > 'httpd-2.4.37-21.module_el8.2.0+382+15b0afa8.x86_64', it cannot be > installed on the system > DEBUG util.py:621: No available modular metadata for modular package > 'httpd-devel-2.4.37-21.module_el8.2.0+382+15b0afa8.x86_64', it cannot be > installed on the system > DEBUG util.py:621: No available modular metadata for modular package > 'httpd-filesystem-2.4.37-21.module_el8.2.0+382+15b0afa8.noarch', it > cannot be installed on the system > DEBUG util.py:621: No available modular metadata for modular package > 'httpd-tools-2.4.37-21.module_el8.2.0+382+15b0afa8.x86_64', it cannot be > installed on the system > DEBUG util.py:621: No available modular metadata for modular package > 'mod_http2-1.11.3-3.module_el8.2.0+307+4d18d695.x86_64', it cannot be > installed on the system > DEBUG util.py:621: No available modular metadata for modular package > 'mysql-common-8.0.17-3.module_el8.0.0+181+899d6349.x86_64', it cannot be > installed on the system > DEBUG util.py:621: No available modular metadata for modular package > 'mysql-devel-8.0.17-3.module_el8.0.0+181+899d6349.x86_64', it cannot be > installed on the system > DEBUG util.py:621: No available modular metadata for modular package > 'mysql-libs-8.0.17-3.module_el8.0.0+181+899d6349.x86_64', it cannot be > installed on the system > > Any idea to solve this problem ? I miss somthing ? > > I setup my el8 tag like this > > koji add-tag centos-8 > koji add-tag --parent "centos-8" --arches 'x86_64' centos-8-build > koji add-group centos-8-build build > koji add-group centos-8-build srpm-build > > koji add-external-repo -t centos-8-build -p 10 centos-8-external-baseos > http://mirrors.ircam.fr/pub/CentOS/8/BaseOS/\$arch/os > koji add-external-repo -t centos-8-build -p 15 centos-8-external-epel > http://mirrors.ircam.fr/pub/fedora/epel/8/Everything/\$arch > koji add-external-repo -t centos-8-build -p 11 > centos-8-external-appstream > http://mirrors.ircam.fr/pub/CentOS/8/AppStream/\$arch/os > koji add-external-repo -t centos-8-build -p 12 > centos-8-external-powertools > http://mirrors.ircam.fr/pub/CentOS/8/PowerTools/\$arch/os > koji add-external-repo -t centos-8-build -p 13 centos-8-external-extras > http://mirrors.ircam.fr/pub/CentOS/8/extras/\$arch/os > > koji add-target centos-8 centos-8-build > > koji add-group-pkg centos-8-build build bash bash bzip2 coreutils cpio > diffutils findutils gawk gcc grep sed gcc-c++ gzip info patch > redhat-rpm-config rpm-build shadow-utils tar unzip util-linux which make > centos-release xz > koji add-group-pkg centos-8-build srpm-build bash redhat-release > centos-release make redhat-rpm-config rpm-build shadow-utils wget > rpmdevtools > > Thanks, > > Didier (tartare) > ___ > 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
Re: The future of legacy BIOS support in Fedora.
Le 2020-07-06 16:33, Gerd Hoffmann a écrit :
On Mon, Jul 06, 2020 at 03:45:45PM +0200, Nicolas Mailhot via devel
wrote:
Le lundi 06 juillet 2020 à 15:33 +0200, Gerd Hoffmann a écrit :
> Â Â Hi,
>
> See above. sd-boot allows to edit the kernel command line too. Same
> hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one is
> actually listed if you hit '?' or 'h'.
Given the mess boot input and display are on a lot of systems, any
keypress should pause the boot and display boot options (including
editing the boot CLI).
Sure. All bootloaders I have seen in recent years (including sd-boot)
behave that way.
I was mostly reacting to
And unlike the 'l' and 'w' hotkeys that one is actually listed if you
hit '?' or 'h'.
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 Mon, Jul 06, 2020 at 03:45:45PM +0200, Nicolas Mailhot via devel wrote:
> Le lundi 06 juillet 2020 à 15:33 +0200, Gerd Hoffmann a écrit :
> > Â Â Hi,
> >
> > See above. sd-boot allows to edit the kernel command line too. Same
> > hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one is
> > actually listed if you hit '?' or 'h'.
>
> Given the mess boot input and display are on a lot of systems, any
> keypress should pause the boot and display boot options (including
> editing the boot CLI).
Sure. All bootloaders I have seen in recent years (including sd-boot)
behave that way. Even if a key has no specific function attached
pressing it will at least stop the timeout countdown. So I'm not sure
why you are bringing that up and what you are trying to say ...
take care,
Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1854141] New: perl-Socket-2.030 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1854141 Bug ID: 1854141 Summary: perl-Socket-2.030 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Socket Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 2.030 Current version/release in rawhide: 2.029-5.fc32 URL: http://search.cpan.org/dist/Socket/ 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/3321/ -- 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
modular and personal koji
Hi all, With my personal koji (on el8), I cannot build some packages for my el8 tag. All failures are about modular metadata packages which cannot be installed. DEBUG util.py:621: No available modular metadata for modular package 'httpd-2.4.37-21.module_el8.2.0+382+15b0afa8.x86_64', it cannot be installed on the system DEBUG util.py:621: No available modular metadata for modular package 'httpd-devel-2.4.37-21.module_el8.2.0+382+15b0afa8.x86_64', it cannot be installed on the system DEBUG util.py:621: No available modular metadata for modular package 'httpd-filesystem-2.4.37-21.module_el8.2.0+382+15b0afa8.noarch', it cannot be installed on the system DEBUG util.py:621: No available modular metadata for modular package 'httpd-tools-2.4.37-21.module_el8.2.0+382+15b0afa8.x86_64', it cannot be installed on the system DEBUG util.py:621: No available modular metadata for modular package 'mod_http2-1.11.3-3.module_el8.2.0+307+4d18d695.x86_64', it cannot be installed on the system DEBUG util.py:621: No available modular metadata for modular package 'mysql-common-8.0.17-3.module_el8.0.0+181+899d6349.x86_64', it cannot be installed on the system DEBUG util.py:621: No available modular metadata for modular package 'mysql-devel-8.0.17-3.module_el8.0.0+181+899d6349.x86_64', it cannot be installed on the system DEBUG util.py:621: No available modular metadata for modular package 'mysql-libs-8.0.17-3.module_el8.0.0+181+899d6349.x86_64', it cannot be installed on the system Any idea to solve this problem ? I miss somthing ? I setup my el8 tag like this koji add-tag centos-8 koji add-tag --parent "centos-8" --arches 'x86_64' centos-8-build koji add-group centos-8-build build koji add-group centos-8-build srpm-build koji add-external-repo -t centos-8-build -p 10 centos-8-external-baseos http://mirrors.ircam.fr/pub/CentOS/8/BaseOS/\$arch/os koji add-external-repo -t centos-8-build -p 15 centos-8-external-epel http://mirrors.ircam.fr/pub/fedora/epel/8/Everything/\$arch koji add-external-repo -t centos-8-build -p 11 centos-8-external-appstream http://mirrors.ircam.fr/pub/CentOS/8/AppStream/\$arch/os koji add-external-repo -t centos-8-build -p 12 centos-8-external-powertools http://mirrors.ircam.fr/pub/CentOS/8/PowerTools/\$arch/os koji add-external-repo -t centos-8-build -p 13 centos-8-external-extras http://mirrors.ircam.fr/pub/CentOS/8/extras/\$arch/os koji add-target centos-8 centos-8-build koji add-group-pkg centos-8-build build bash bash bzip2 coreutils cpio diffutils findutils gawk gcc grep sed gcc-c++ gzip info patch redhat-rpm-config rpm-build shadow-utils tar unzip util-linux which make centos-release xz koji add-group-pkg centos-8-build srpm-build bash redhat-release centos-release make redhat-rpm-config rpm-build shadow-utils wget rpmdevtools Thanks, Didier (tartare) pEpkey.asc Description: application/pgp-keys ___ 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
Could not execute build: database outage
While calling "fedpkg build" I got the warning (error?) displayed in the title: ... Could not execute build: database outage Apparently the build is over and well. :-) https://koji.fedoraproject.org/koji/taskinfo?taskID=46677172 This is just a report since everything is OK, I have used a side tag and the build shows there. Regards, -- José Abílio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Mon, 2020-07-06 at 15:33 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > default entry highlighted, a few seconds timeout with countdown. Both
> > > support editing boot entries.
> > Anecdata, but I definitely never (maybe once 15 years ago?) had grub
> > install issue, but plenty of dracut reconfiguration/upgrade failures
> > over the years and the ability to edit the command line has been a life
> > sacver.
>
> See above. sd-boot allows to edit the kernel command line too. Same
> hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one is
> actually listed if you hit '?' or 'h'.
Ah this is good, sorry I must have misunderstood what you were saying.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
___
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 lundi 06 juillet 2020 à 15:33 +0200, Gerd Hoffmann a écrit :
> Hi,
>
> > > default entry highlighted, a few seconds timeout with countdown.
> > > Both
> > > support editing boot entries.
>
> > Anecdata, but I definitely never (maybe once 15 years ago?) had
> > grub
> > install issue, but plenty of dracut reconfiguration/upgrade
> > failures
> > over the years and the ability to edit the command line has been a
> > life
> > sacver.
>
> See above. sd-boot allows to edit the kernel command line too. Same
> hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one is
> actually listed if you hit '?' or 'h'.
Given the mess boot input and display are on a lot of systems, any
keypress should pause the boot and display boot options (including
editing the boot CLI).
Otherwise you end up in keypress & display timing hell (not to mention
that non-qwerty users have the additional hurdle of guessing where keys
are mapped, which is why using anything except escape/space and
function keys will break hard in the field).
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.
Hi,
> > default entry highlighted, a few seconds timeout with countdown. Both
> > support editing boot entries.
> Anecdata, but I definitely never (maybe once 15 years ago?) had grub
> install issue, but plenty of dracut reconfiguration/upgrade failures
> over the years and the ability to edit the command line has been a life
> sacver.
See above. sd-boot allows to edit the kernel command line too. Same
hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one is
actually listed if you hit '?' or 'h'.
take care,
Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Hi, On Mon, 2020-07-06 at 13:31 +0200, Gerd Hoffmann wrote: > Hi, > > > > btw, sd-boot has a few tricks up its sleeve: if during boot you keep > > > "w" pressed down it will automatically boot into windows, similar if > > > you keep "l" pressed down it will automaticall boot into linux, "a" > > > will boot into macos, all without showing any UI at all. This means > > > the boot menu can be hidden entirely during boot with a zero timeout, > > > but you can still boot into a specific boot entry. > > > > That's actually awful, in my opinion, > > Why? It's nice to have them and I can't see any downsides. I have lots of machines that fail to show the exact time boot happens (external monitor still powering up or blanking out) and will disable/ignore keys if you press too early. You won't see this with laptops as they are integrated machines and manufacturers pay a lot more attention to having a smooth display experience, but with workstations or servers the boot time is not the best experience ... > > and objectively undiscoverable.. > > Indeed. Would be nice to show these hotkeys somewhere. Extend the > help line which is shown when you press '?' for example. > > > If you'd like to see how it should be done, boot a VM with GRUB2 as > > the bootloader. For a short period of time, you'll see a list of > > options, with the default option highlighted. If you don't pick > > something different, or don't need to enter a prompt to recover your > > device, it'll automatically boot. > > Well, seems you have never actually used sd-boot ... > > There actually isn't much of a difference between grub2 and systemd-boot > here. Both can be configured to show or not show a menu. The menu > screen doesn't look fundamentally different either: List of boot > entries for the kernels installed, entry to boot into firmware setup, > default entry highlighted, a few seconds timeout with countdown. Both > support editing boot entries. > > Yes, unlike grub2 sd-boot has no command prompt. I have not missed that > so far. The vast majority of cases where I've actually needed the grub2 > prompt have been grub2 install problems, like grub2 failing to find its > config file for some reason. That is clearly not something I account in > favor of grub2 ... Anecdata, but I definitely never (maybe once 15 years ago?) had grub install issue, but plenty of dracut reconfiguration/upgrade failures over the years and the ability to edit the command line has been a life sacver. It is kind of a must have feature to do development on kernels so you can quickly change something w/o breaking your written down configuration for good if you make a mistake. Definitely not a fan of having to try a rescue disk, when you are 1000 miles from a server that you can access only via a remote console. That said I do not love grub, but being able to change the boot line is really a basic required feature for a developer OS. > > GRUB2 is nice in that it's powerful enough for those that need it, but > > simple enough for those who don't want the complex features. > > Well, alot of the complex grub features are dragged forward from the > BIOS world to the UEFI world and are somewhat awkward there. > > The BIOS provides block device access at sector level, so the boot > loader has little choice but implementing drivers for all kinds of > stuff. Or use fragile block lists like lilo did in the last century. > > With UEFI much more functionality is provided by the firmware and there > is little reason for a bootloader to have tons of drivers. With the > exception of filesystem drivers in case you want boot from something != > vfat. But even that should ideally be implemented as uefi driver not as > grub2 module. > > If you insist on comparing bloat it will be grub2 which is bloated, > and it comes from being stuck in its own world and carrying its own > implementation for everything instead of using firmware services. > > -rwxr-xr-x. 1 root root 93803 Jun 2 08:19 systemd-bootx64.efi > -rwx--. 1 root root 2513224 Jun 19 18:24 grubx64.efi > > (binaries as shipped by fedora 32). > > take care, > Gerd > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: The future of legacy BIOS support in Fedora.
Hi,
> My real problem with grub2 is not that it's complex, but the fact that
> it exposes its complexities to the user.
The config file syntax is a mess indeed. The fact that you need a
config generator tool in the first place speaks volumes ...
But note that grub config files don't have to be as complex as the
grub2-mkconfig generated ones.
> I'm willing to try systemd-boot on a virtual machine, to see if it
> makes things easier, but the fact it doesn't support BIOS makes it not
> very usable for me.
https://www.kraxel.org/repos/images/fedora-31-efi-systemd-x86_64.qcow2.xz
Image boots in both uefi (sd-boot) and bios (grub2) mode, and the config
file for the latter is so short that I can include it here without
hitting the mailing list size limit ;)
-- cut here --
function load_video {
insmod all_video
}
insmod part_gpt
insmod fat
insmod serial
insmod terminal
insmod blscfg
serial --unit=0 --speed=115200
terminal_output console serial
terminal_input console serial
set boot='hd0,gpt2'
set timeout=3
blscfg
-- cut here --
take care,
Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Mon, Jul 06, 2020 at 08:08:48AM -0400, Stephen John Smoogen wrote: > On Mon, 6 Jul 2020 at 07:38, Gerd Hoffmann wrote: > > > > Hi, > > > > > > btw, sd-boot has a few tricks up its sleeve: if during boot you keep > > > > "w" pressed down it will automatically boot into windows, similar if > > > > you keep "l" pressed down it will automaticall boot into linux, "a" > > > > will boot into macos, all without showing any UI at all. This means > > > > the boot menu can be hidden entirely during boot with a zero timeout, > > > > but you can still boot into a specific boot entry. > > > > > > That's actually awful, in my opinion, > > > > Why? It's nice to have them and I can't see any downsides. > > > > It isn't that you put the keyboard strokes, it is that you are saying > you can do a zero-timeout without problems. Ah, ok. I meant specifically the hotkey existing. I clearly can see that hiding the boot menu has its downsides and in fact most of my machines are configured to show it (and I think server actually defaults to menu=on, only workstatiion has menu=off by default). That is doesn't matter much for the uefi/bios and grub2/sd-boot discussion though, both boot loaders can be configured to whatever timeout you like. > 4. Screen flickering and paused screens. The lenovos I have do weird > things when attached to external monitors. Screens will stick on > monitors during the boot up sequence sometimes.. or they will do sync > tests which drop the entire video for 3-5 seconds at a time. I have a 4k monitor connected to a intel nuc, and grub has a 30s timeout there because it takes *ages* for the screen to sync. And even with the 30s timeout I don't see the menu now and then. The other extreme are laptop panels which typically sync within the fraction of a second where all this is not a problem at all. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Sun, Jul 05, 2020 at 01:11:08AM -0700, John M. Harris Jr wrote: > 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. Default fedora disk layout in UEFI mode is partitions for ESP, /boot and LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot are not. Which makes sense to me. Why would you encrypt /boot? The files you can find there are public anyway, you can download them from the fedora servers. Encrypting /boot would make the boot process more fragile for no benefit. sd-boot still wouldn't work out-of-the-box though, due to /boot being xfs not vfat and firmware typically not shipping with xfs drivers. We could that by using vfat for /boot. Or by shipping & using xfs.efi, simliar to how apple ships & uses apfs.efi to boot macOS from apfs filesystems. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Mon, 2020-07-06 at 13:31 +0200, Gerd Hoffmann wrote: > Hi, > > > > btw, sd-boot has a few tricks up its sleeve: if during boot you > > > keep > > > "w" pressed down it will automatically boot into windows, similar > > > if > > > you keep "l" pressed down it will automaticall boot into linux, > > > "a" > > > will boot into macos, all without showing any UI at all. This > > > means > > > the boot menu can be hidden entirely during boot with a zero > > > timeout, > > > but you can still boot into a specific boot entry. > > > > That's actually awful, in my opinion, > > Why? It's nice to have them and I can't see any downsides. > > > and objectively undiscoverable.. > > Indeed. Would be nice to show these hotkeys somewhere. Extend the > help line which is shown when you press '?' for example. > > > If you'd like to see how it should be done, boot a VM with GRUB2 as > > the bootloader. For a short period of time, you'll see a list of > > options, with the default option highlighted. If you don't pick > > something different, or don't need to enter a prompt to recover > > your > > device, it'll automatically boot. > > Well, seems you have never actually used sd-boot ... > > There actually isn't much of a difference between grub2 and systemd- > boot > here. Both can be configured to show or not show a menu. The menu > screen doesn't look fundamentally different either: List of boot > entries for the kernels installed, entry to boot into firmware setup, > default entry highlighted, a few seconds timeout with > countdown. Both > support editing boot entries. > > Yes, unlike grub2 sd-boot has no command prompt. I have not missed > that > so far. The vast majority of cases where I've actually needed the > grub2 > prompt have been grub2 install problems, like grub2 failing to find > its > config file for some reason. That is clearly not something I account > in > favor of grub2 ... > > > GRUB2 is nice in that it's powerful enough for those that need it, > > but > > simple enough for those who don't want the complex features. > > Well, alot of the complex grub features are dragged forward from the > BIOS world to the UEFI world and are somewhat awkward there. > > The BIOS provides block device access at sector level, so the boot > loader has little choice but implementing drivers for all kinds of > stuff. Or use fragile block lists like lilo did in the last century. > > With UEFI much more functionality is provided by the firmware and > there > is little reason for a bootloader to have tons of drivers. With the > exception of filesystem drivers in case you want boot from something > != > vfat. But even that should ideally be implemented as uefi driver not > as > grub2 module. > > If you insist on comparing bloat it will be grub2 which is bloated, > and it comes from being stuck in its own world and carrying its own > implementation for everything instead of using firmware services. > > -rwxr-xr-x. 1 root root 93803 Jun 2 08:19 systemd-bootx64.efi > -rwx--. 1 root root 2513224 Jun 19 18:24 grubx64.efi > > (binaries as shipped by fedora 32). You're right, and that's yet another reason it's not a good idea to use childish names as "systemd-bloat". I agree that grub2 is more bloated and that it doesn't make sense to bring all the complexities of BIOS boot to UEFI. However, the real question is, why does it matter? It's only a boot loader. It does its job in a fraction of a second and then it's all done, and the kernel takes it up from there. None of the "bloated" bootloader code stays in memory. And wasting 2.5 MB instead of 94 KB of disk space would only matter if we lived in the times when hard drives were 10 MB or 20 MB :) It's true that the extra complexity means it's more prone to bugs, but it has already been debugged fairly well and does its job just fine, so what's the problem? My real problem with grub2 is not that it's complex, but the fact that it exposes its complexities to the user. I wish it had an "easy" mode, where you could configure it easily for the common things that 99% of the users would do, such as: 1. setting the boot menu timeout 2. choosing the default boot option - e.g. always Fedora, or always Windows, or always a single entry, or, alternatively, as an option, remember the last chosen option, and just repeat it, if the timeout expires - this is invaluable when you dual boot Windows and have to install Windows updates, because they are notorious for rebooting the system several times, and you can't always sit in front the computer for hours, so that you can catch the 5 seconds when the boot menu appears, so you can choose Windows again. :) 3. changing the kernel boot options 4. adding passwords to certain menu entries These are common things, that I'm reluctant to do, because I'm put off by the complexities of grub2 configuration. I wish it had an easy mode that just covers these common scenarios. I don't want to remove features from it, I think it's
Re: Can we do away with release and changelog bumping?
Le lundi 06 juillet 2020 à 13:06 +0200, Nicolas Mailhot a écrit : > > Because the build state exists in koji only, there is no need to > commit back to git. BTW I’m fairly certain I could have managed to implement the thing without adding source files to the SRPM, removing the need for mock changes of for back commits. It would have involved creating a separate subpackage for the state payload (à la debuginfo) with past state floating in this subpackage without ever being commited back. Much like the koji implementation makes changelog and release state float in a koji alternate dimension that is not Fedora git or the package sources. I decided against it because that would have made importing from one buildsystem to another quite inconvenient, and because it would have added a lot of (brittle) implementation complexity. These days my coding is very data-model driven, the right data model means a smaller and more future-proof implementation, the fact the autobump implementation is such a small diff shows the data model is right, IMHO 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 Mon, 6 Jul 2020 at 07:38, Gerd Hoffmann wrote: > > Hi, > > > > btw, sd-boot has a few tricks up its sleeve: if during boot you keep > > > "w" pressed down it will automatically boot into windows, similar if > > > you keep "l" pressed down it will automaticall boot into linux, "a" > > > will boot into macos, all without showing any UI at all. This means > > > the boot menu can be hidden entirely during boot with a zero timeout, > > > but you can still boot into a specific boot entry. > > > > That's actually awful, in my opinion, > > Why? It's nice to have them and I can't see any downsides. > It isn't that you put the keyboard strokes, it is that you are saying you can do a zero-timeout without problems. The assumption being that you are saying this is what should be a default.. and now you say there are no downsides. I assume that people are talking past each other, but in case not, there are always problems 1. Various systems blank out keyboard strokes in case of stuck key. I have seen this on a lot of servers, workstations and some laptops. Basically hold a key too short and it gets cleared, hold a key too long and the system assumes stuck key and ignores keyboard for 30 seconds. 2. Other systems blank out keyboard strokes from before the beginning of OS boot sections and expect that your OS will give you time to press some keystrokes before booting. My parents 2 laptops with different vendors (Dell and ASUS) do that. [They wanted to try what their son works on... and I found this out while trying to debug things remotely over the years. We push out bad kernels every now and then] 3. Some hardware is controlled by things like Serial over LAN (SOL) which a lot of mgmt ports use. That puts a limit on repeated character strokes and will break a connection and such. I have spent way too long this last week dealing with Fedora 30+ systems with short boot menus over serial over lan and having to power cycle the server (a 3 to 5 minute wait) to get back to the boot menu for one more attempt of a 2 second keyboard section which SOL may scrub. Trying to debug a problem over a phone with a parent is similar. 4. Screen flickering and paused screens. The lenovos I have do weird things when attached to external monitors. Screens will stick on monitors during the boot up sequence sometimes.. or they will do sync tests which drop the entire video for 3-5 seconds at a time. I can see where a zero timeout is a good thing on hardware which allows it and if the person is ok with it. It is a complete nightmare on hardware or remote support. > > and objectively undiscoverable.. > > Indeed. Would be nice to show these hotkeys somewhere. Extend the > help line which is shown when you press '?' for example. > Again, in a zero boot timeout how would hotkeys be seen? A lot of systems (even new ones :( ) are still recovering from hardware video tests with screens flashing and such. If I have an external monitor hooked up to my laptop, I rarely see the grub menu with a default timeout.. the screen steadies only by the time the system has reached the enter a password to decrypt drive. My issues here are not with sd-boot or grub. It is with assuming that a fast seen by menu is a good thing by default. I think it would be great as a config option to shoot yourself in the foot by choice.. but I spend too much time debugging other people's problems to like it by default :). -- 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 Mon, Jul 06, 2020 at 01:31:30PM +0200, Gerd Hoffmann wrote: > The BIOS provides block device access at sector level, so the boot > loader has little choice but implementing drivers for all kinds of > stuff. Or use fragile block lists like lilo did in the last century. > > With UEFI much more functionality is provided by the firmware and there > is little reason for a bootloader to have tons of drivers. With the > exception of filesystem drivers in case you want boot from something != > vfat. But even that should ideally be implemented as uefi driver not as > grub2 module. FWIW, there seem to be UEFI driver for btrfs, ZFS, XFS and others: https://efi.akeo.ie/ -- Tomasz Torcz “Never underestimate the bandwidth of a station to...@pipebreaker.plwagon filled with backup tapes.” — Jim Gray ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Hi, > 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. "getting into the way" IMO includes "doesn't show up on the serial console". Both sd-boot and grub2 are doing fine here, the standard uefi text console works on both vga and serial line. Anything doing something fancy on the framebuffer is problematic here ... take care, Gerd PS: yes, you can configure grub2 to do fancy graphics, but fedora doesn't do that by default. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Hi, > > btw, sd-boot has a few tricks up its sleeve: if during boot you keep > > "w" pressed down it will automatically boot into windows, similar if > > you keep "l" pressed down it will automaticall boot into linux, "a" > > will boot into macos, all without showing any UI at all. This means > > the boot menu can be hidden entirely during boot with a zero timeout, > > but you can still boot into a specific boot entry. > > That's actually awful, in my opinion, Why? It's nice to have them and I can't see any downsides. > and objectively undiscoverable.. Indeed. Would be nice to show these hotkeys somewhere. Extend the help line which is shown when you press '?' for example. > If you'd like to see how it should be done, boot a VM with GRUB2 as > the bootloader. For a short period of time, you'll see a list of > options, with the default option highlighted. If you don't pick > something different, or don't need to enter a prompt to recover your > device, it'll automatically boot. Well, seems you have never actually used sd-boot ... There actually isn't much of a difference between grub2 and systemd-boot here. Both can be configured to show or not show a menu. The menu screen doesn't look fundamentally different either: List of boot entries for the kernels installed, entry to boot into firmware setup, default entry highlighted, a few seconds timeout with countdown. Both support editing boot entries. Yes, unlike grub2 sd-boot has no command prompt. I have not missed that so far. The vast majority of cases where I've actually needed the grub2 prompt have been grub2 install problems, like grub2 failing to find its config file for some reason. That is clearly not something I account in favor of grub2 ... > GRUB2 is nice in that it's powerful enough for those that need it, but > simple enough for those who don't want the complex features. Well, alot of the complex grub features are dragged forward from the BIOS world to the UEFI world and are somewhat awkward there. The BIOS provides block device access at sector level, so the boot loader has little choice but implementing drivers for all kinds of stuff. Or use fragile block lists like lilo did in the last century. With UEFI much more functionality is provided by the firmware and there is little reason for a bootloader to have tons of drivers. With the exception of filesystem drivers in case you want boot from something != vfat. But even that should ideally be implemented as uefi driver not as grub2 module. If you insist on comparing bloat it will be grub2 which is bloated, and it comes from being stuck in its own world and carrying its own implementation for everything instead of using firmware services. -rwxr-xr-x. 1 root root 93803 Jun 2 08:19 systemd-bootx64.efi -rwx--. 1 root root 2513224 Jun 19 18:24 grubx64.efi (binaries as shipped by fedora 32). take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
Le lundi 06 juillet 2020 à 10:19 +0200, Adam Saleh a écrit : > Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve > this problem few months ago. > It is a koji plugin as well as CLI tool that makes bumping the > release field and generating changelog problem of Koji, > instead of package-maintainer. Currently it sits deployed in staging > koji, so you can give it a test-drive :-) > > We hope we can return to it later this year, to have it deployed in > prod koji. > > [1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html I think it is good to have alternative implementations that show what the real consequences and costs of doing something one way or another are. The abovementioned implementation is tied to koji and will never work outside koji, and involves quite a lot of spec munging (that may work or not, I suspect it won’t work so well on my spec files for example). And it takes a lot of moving pieces to do so. Because the build state exists in koji only, there is no need to commit back to git. Conversely, this is what makes it a koji-only solution that does not export well to other build systems. My implementation is much simpler (6 files changed. 179 lines added. 5 lines removed) https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/bc4e6a79355f3a2b73abeea7e5c0e1f53b09579e?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump However it relies on another redhat-rpm-config change which is definitely not simple (30 files changed. 2163 lines added. 619 lines removed). Though probably still quite less than the whole of rpmautospec + rpmautospec macros + koji plugin https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/213995c8371837f3689c0d053ed055c25de287c9?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump The other redhat-rpm-config change was done for other reasons, and contains code to address totally different needs, and I will need it whether the bumping change is done or not (but, I’m sure the rpmautospec guys will state a lot of their code was also written for other reasons). I suspect my implementation wins on genericity and on the other features it unlocks within spec files, while the rpmautospec implementation wins if you want to keep things within a little team of Fedora infra people. I’d call my implementation more elegant, because it tries to fix things within spec files first, and uses the fixes to make it easier to implement higher level features. While the rpmautospec solutions tries to take spec files as they are and force a high level feature over and from outside a packager spec file. But I will be the first to admit I am biaised. Had I not been convinced it was the right approach, I would not have invested the coding time in the first place. 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
[Bug 1854078] New: perl-Parse-CPAN-Packages required in EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1854078 Bug ID: 1854078 Summary: perl-Parse-CPAN-Packages required in EPEL 8 Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-Parse-CPAN-Packages Assignee: jples...@redhat.com Reporter: heinrich.mis...@univie.ac.at QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, ktdre...@ktdreyer.com, perl-devel@lists.fedoraproject.org, st...@silug.org, strob...@strobe.net Target Milestone: --- Classification: Fedora Please add perl-Parse-CPAN-Packages to EPEL8. This package is required by cpanspec. Thanks -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: [Fedora-packaging] Re: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
Le 2020-07-05 23:55, Dan Čermák a écrit : Hi Dan So essentially you store the changelog in a separate file The changelog is already detached in the F33 change https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs This F34 change adds bumping to the detached file https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping and use that to calculate the next release field? The changelog file is not used as source of data, except as a reference state that will be added to. Using the changelog file as source of data would require quite a lot of complex and unreliable changelog format parsing, so the bumping data is taken from another key = value file (that uses the same persistence mechanisms). Also the packager may decide to trim quite a lot of intermediary changelog events, so the EVR and date in the last changelog entry are not necessarily the EVR and date of the last build. 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. To be part of official Fedora history the result of a build needs to be committed yes. The change does not force you to build every commit, nor to commit every build out there. The "only" difference to the current state of affairs being, that I don't have to specify the Release field myself? Once you've modified a spec, and set a starting evr point in this spec, further rebuilds do not involve touching the spec. Spec changes are real spec changes, not spec changes to bump a release or bump a changelog. 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? If you want a demonstration of the auto framework and of changelog detaching, you can take any of the non macro builds in https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-changelog-fonts/builds/ If you want to see a demonstration of autobumping, you need to rpmbuild -ba manually right now, because of the two small limitations mock side. So you need to take the redhat-rpm-config and fonts macro packages in: https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/ and rebuild one of the other packages in there. The only difference between the two coprs is the redhat-rpm-config package, there is no change in the fonts macro package or in the automated packages themselves. Autobumping can be implemented without any spec file change once the auto framework is used. (The mock limitations are first, the fact that mock currently collects the SRPM at the start, not end of the build process, and second, the fact you need to pass packager ID that will end up in the changelog bump to the build process and there is no way in the copr/copr UI do do that.) What I am currently missing from this proposal though is: - How is this actually even implemented? - How will this look in practice? See above ↑ - 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). Since bumping is a feature over the auto framework, and does not require any additional spec change, it is enabled by registering bumping processing in this framework, and disabled by removing this registration. There is no need to change spec files or history. In fact I use the same spec files to QA the auto framework and bumping, and depending if the redhat-rpm-config version I test includes the bumping or not, they will bump or not. When bumping code is not present the additional key=value file bumping uses is not auto-added to sources, so the next srpm import will clear it from sources the same way patches disappear from sources once no longer used (and can linger forever if a packager does not import srpms and does not git rm those files explicitly). Removing the auto framework is something else altogether. Because its aim is to massively simplify spec files (in opt-in, not mandatory mode), you can not go back without undoing the spec simplifications. However, because great care was taken to define a clean and generic spec syntax when using the auto framework, you could replace it will multiple reimplementations without changing spec files. The %auto framework spec API is basically %prep %auto_prep ← automated processing It’s hard to go more generic than that. (You might want to remove the %auto calls altogether and have %prep, for example, call %prep by default, but that would remove the packager choice to use or not the %auto calls, and to insert custom processing before those calls). The only "irregularity" is that the %auto
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 à 23:36 +0200, Dan Čermák a écrit : > 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. Well just bumping the changelog by default, and letting the packager remove unecessary lines when he has the time to look at the changelog, is a much friendlier workflow than asking the packager to think about it on every single build, redoing builds when he forgot about it because redoing builds is the only way to get a new changelog included in the binary payload. 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 5.7.2020 19:31, Solomon Peachy wrote: 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. As do I. Hopefully Daniel's response of the poor state those tools are in, will raise some red flags within Red Hat in which it starts throwing some resources ( money,workforce) to have this addressed before RHEL 9 gets released. Atleast that is what I would do if I was a person in power within Red Hat ( or a company that provides or relies on a solution based on those tools) and had read his response which described quite the "alarming situation" for products within the company in relation where the industry is heading. JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 5.7.2020 18:34, Javier Martinez Canillas wrote: 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). Since you are in contact with and thus presumably you are one of the "bootloader folks" could you clarify who those individual are and what role they play and which bootloaders they represent in the distribution and on which arch etc. and where they can be contacted ( mailinglist ) since I don't find any documentation about any bootloader WG existing within Fedora yet such a team seems to exist since it's being mentioned. JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
problem few months ago.
It is a koji plugin as well as CLI tool that makes bumping the release
field and generating changelog problem of Koji,
instead of package-maintainer. Currently it sits deployed in staging koji,
so you can give it a test-drive :-)
We hope we can return to it later this year, to have it deployed in prod
koji.
[1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html
On Mon, Jul 6, 2020 at 8:22 AM Florian Weimer wrote:
> * Björn Persson:
>
> > The macro could be defined like this for example:
> >
> > %buildtag .%(date +%%s)
>
> Using time for synchronization is always a bit iffy.
>
> > It would be used in each spec like this:
> >
> > Release: 1%{?dist}%{?buildtag}
>
> We could put the Koji task ID directly into the %dist tag. We know that
> this works in principle. If we are worried that the number gets too
> large, we could subtract the current task ID at the time the fcNN part
> of the %dist tag changes.
>
> The %dist tag is not recorded in the changelog by most packages, so the
> changelog does not need changing.
>
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
* Björn Persson:
> The macro could be defined like this for example:
>
> %buildtag .%(date +%%s)
Using time for synchronization is always a bit iffy.
> It would be used in each spec like this:
>
> Release: 1%{?dist}%{?buildtag}
We could put the Koji task ID directly into the %dist tag. We know that
this works in principle. If we are worried that the number gets too
large, we could subtract the current task ID at the time the fcNN part
of the %dist tag changes.
The %dist tag is not recorded in the changelog by most packages, so the
changelog does not need changing.
Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
