Re: rawhide - glibc/pthreads/... - broken pending mass rebuild?
* Alex Scheel: > Is Fedora Rawhide unstable at the moment, pending a mass rebuild? > > I've seen a lot of random problems related to pthreads at the > moment, such as: > > 16/78 Test #12: JSS_DER_Encoding_of_Enumeration_regression_test ...Child > aborted***Exception: 0.99 sec > FINE: CryptoManager: loading JSS library > FINE: CryptoManager: loaded JSS library from java.library.path > java: ../nptl/pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion > `mutex->__data.__owner == 0' failed. > > > Another, different stack trace here (pthreads fails to lock, > triggering a bug in opencryptoki): > > https://pagure.io/dogtagpki/issue/3181#comment-661911 I don't see why this would be fixed by a mass rebuild. This is probably some sort of memory corruption: something has overwritten the mutex data structure, and glibc happens to detect that. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] [Test Day] F33 SwapOnZRAM 2020-07-06
Hey Testers, Monday, 2020-07-06 will be SwapOnZRAM Test Day[0]! This Test Day will focus on SwapOnZRAM[1]. Swap partition is useful, except when it's slow. Zram is a RAM drive that uses compression. Create a swap-on-zram during start-up. And no longer use swap partitions by default. The zram module creates RAM based block devices named /dev/zram ( = 0, 1, ...). Pages written to these disks are compressed and stored in memory itself. These disks allow very fast I/O and compression provides good amounts of memory savings. It's also pretty easy to join in and contribute, you can submit your test day results here[2] As always, the event will be in #fedora-test-day on Freenode IRC. [0] https://fedoraproject.org/wiki/Test_Day:F33_SwapOnZRAM [1] https://fedoraproject.org/wiki/Changes/SwapOnZRAM [2] https://testdays.fedorainfracloud.org/events/86 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-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/test-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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
Stratis allows users to manage XFS filesystems using a pool of block devices. Features include: thin-provisioning, snapshots, and encryption Stratis does come under the Springfield umbrella. We are an active team and happy to respond to our public mailing list, if anyone has questions at stratis-de...@lists.fedorahosted.org, or visit our webpage at https://stratis-storage.github.io/, or contribute at https://github.com/stratis-storage. We have been carefully developing Stratis with many of the mentioned features in mind. We welcome positive and constructive input and feedback. - Dennis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: drop bfq scheduler, instead use mq-deadline across the board
> I'm not convinced it's the domain of an IO scheduler to be involved, > rather than it being explicit UX intended by the desktop environment. > Seems to me the desktop environment is in a better position to know > what users expect. Well wouldn't bfq just be enforcing the bandwidth weights, if any, that were explicitly set in the various groups? If something is already creating and modifying control groups, then that something should have total control over setting the bandwidth weights. It's not obvious to me how the IO scheduler would be bypassing or otherwise ignoring whatever manages control groups. It's also not clear to me how anything except an IO scheduler would be able to directly control how device bandwidth is shared. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: drop bfq scheduler, instead use mq-deadline across the board
On Tue, Jun 30, 2020 at 6:02 PM Tom Seewald wrote: > > I forgot to mention that bfq appears to be the only IO scheduler that > supports cgroups-v2 IO controllers [1]. Perhaps I am wrong, but I wasn't able > to find documentation indicating that mq-deadline is cgroup-aware, at the > very least it's not documented in the official deadline tunables section [2]. > I'm not convinced it's the domain of an IO scheduler to be involved, rather than it being explicit UX intended by the desktop environment. Seems to me the desktop environment is in a better position to know what users expect. > I'm mentioning this because btrfs' support for cgroups-v2 (and the IO > isolation/fairness capability it provides) was listed as one of the key > reasons to move to btrfs. While I am not clear on exactly how the IO > scheduler and files system interact when it comes to IO cgroups, I thought it > was worth bringing up. It is and it's very relevant. I think there are more questions than answers, to what degree there may be unexpected conflicts. In this particular case I'm not that concerned about the majority. I'm in fact concerned about a distinct minority who could end up having a significantly worse experience, and have no idea why, and then being told it is they who should do more testing and provide bug reports to prove it's the IO scheduler causing the problem. -- 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 Sun, Jun 28, 2020 at 6:21 AM Antti wrote: > > Hello, > > I'm in total opposition to this proposal as a long-time Fedora user. The > btrfs is unstable and not ready for production. Most of what I'm about to > write is admittedly anecdotal but it's the only file system in Linux which > has actively and regularly caused me to lose data on desktops, laptops, > servers and even on mobile phones when I haven't taken precautions and done > regular backups. Something I don't have to actively do when using ext4 in my > workstations and notebooks. We had similar excitement back when reiserfs was popular. My limited play with btrfs reminds me of reiserfs: feature-filled but fragile and unsuitable for "/" partitions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 1851453] Add perl-DateTime-Format-ICal to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1851453 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2020-fa10e53bce has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa10e53bce See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1851457] Add perl-DateTime-Event-ICal into EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1851457 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2020-fa10e53bce has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa10e53bce See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1850757] Add perl-DateTime-Event-Recurrence to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1850757 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2020-6e5fac6fdf has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6e5fac6fdf See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1849339] perl-CPAN-Perl-Releases-5.20200620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1849339 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0200620-1.fc33 |0200620-1.fc33 |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0200620-1.fc31 |0200620-1.fc31 ||perl-CPAN-Perl-Releases-5.2 ||0200620-1.fc32 --- Comment #6 from Fedora Update System --- FEDORA-2020-0cc18eac5d has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1849339] perl-CPAN-Perl-Releases-5.20200620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1849339 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0200620-1.fc33 |0200620-1.fc33 ||perl-CPAN-Perl-Releases-5.2 ||0200620-1.fc31 Resolution|--- |ERRATA Last Closed||2020-07-01 01:36:22 --- Comment #5 from Fedora Update System --- FEDORA-2020-73d122d5d9 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Tue, Jun 30, 2020 at 7:16 pm, Stephen John Smoogen wrote: The issue isn't that you haven't done your work. It is that it looks like you were set up to fail. The email from Michael comes across that Workstation couldn't make a decision and told you to go see if FESCO would approve it... but even then they don't have to follow through on it because they are independent. So all that work, all the tantrums from people who just love to fly off the handle on anything, all that bull.. is for essentially nothing. Because in the end, if FESCO does approve it, it means every spin etc is stuck with it while Workstation can decide not to... even though they sent you to get the decision. That is where if I was on FESCO I would say this proposal is dead. Either a Working Group wants something and will fight for it, or they don't. If they don't and have veto authority over anything FESCO says.. then it doesn't matter what FESCO decides. At this point, we're discussing a weird corner case where FESCo approves this change proposal and then the WG does not. I guess it's my fault for suggesting that might occur, but it's really not a very likely scenario. Reality is that the WG members are not filesystem experts and after several weeks of discussing the issue, it became clear that we need more feedback from a larger group of developers. That's what the systemwide change proposal process is designed for. And to be clear, FESCo has veto authority over the WG, not the other way around. The WG was actually created by FESCo itself. I think technically we're a subcommittee of FESCo. Of course we certainly expect that we can ship Fedora Workstation with different defaults than the rest of Fedora, to the extent FESCo continues to allow that. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-sphinx_rtd_theme update: comments requested
On 01. 07. 20 0:47, Jerry James wrote: Third, any package that includes documentation generated from this package will need this: Requires: font(fontawesome) Requires: font(lato) Requires: font(robotoslab) Quick idea: Package an RPM dependency generator into python3-sphinx_rtd_theme that matches *.css files and when it find the "sphinx_rtd_theme" comment in them, it adds the requires. I can help with that. If we want to get fancy, we can add a more general CSS-font requirements generator used for all packaged *.css files in Fedora, but frankly, I don't have the energy to spare for this. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: drop bfq scheduler, instead use mq-deadline across the board
I forgot to mention that bfq appears to be the only IO scheduler that supports cgroups-v2 IO controllers [1]. Perhaps I am wrong, but I wasn't able to find documentation indicating that mq-deadline is cgroup-aware, at the very least it's not documented in the official deadline tunables section [2]. I'm mentioning this because btrfs' support for cgroups-v2 (and the IO isolation/fairness capability it provides) was listed as one of the key reasons to move to btrfs. While I am not clear on exactly how the IO scheduler and files system interact when it comes to IO cgroups, I thought it was worth bringing up. [1] https://www.kernel.org/doc/html/latest/block/bfq-iosched.html#group-scheduling-with-bfq [2] https://www.kernel.org/doc/html/latest/block/deadline-iosched.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Tue, Jun 30, 2020 at 4:42 PM Neal Gompa wrote: > > On Tue, Jun 30, 2020 at 6:30 PM Kevin Kofler wrote: > > > > I am opposed to this change, for the same reasons I was opposed to EarlyOOM > > to begin with: this solution kills processes under arbitrary conditions that > > are neither necessary nor sufficient to prevent a swap thrashing collapse > > (i.e., it can both kill processes unnecessarily (false positives) and fail > > to kill processes when it would be necessary to prevent swap thrashing > > (false negatives)). It is also unclear that it can prevent full OOM (both > > RAM and swap completely full) in all cases, due to EarlyOOM being a > > userspace process that races with the memory-consuming processes and that > > may end up not getting scheduled due to the very impending OOM condition > > that it is trying to prevent. > > > > I strongly believe that this kernel problem can only be solved within the > > kernel, by a synchronous (hence race-free) hook on all allocations. > > > > I still believe that too, except *nobody cares in the Linux kernel > community*. This problem has existed for a decade, and nobody in the > Linux kernel community is interested in fixing it. At this point, I've > given up. Most of us have given up. If they ever get around to doing > the right thing, I'll happily punt all this stuff, but they won't, so > here we are. To put a fine nuance on this, the best oversimplification I've come up with that squares with mm kernel developers in this area is: kernel's built-in oomkiller cares about the kernel's survival. It's not concerned about user space directly, insofar as it's being reasonably fair (i.e. approximately equal misery for all processes even though one in particular does deserve to be killed off the most). Once the kernel's ability to manage the system itself comes under pressure? That's when oomkiller will knock that shit off. What the mm and cgroups2 folks have done is provide some knobs to make it possible to (a) control processes consumption of resources with a very granular level and (b) provide the necessary isolation for a user space oom killer to do things more intelligently. That's oomd today, and might be systemd-oomd down the road in a form that's simpler and doesn't require any tuning - it can in effect come just from proper resource control being applied. So... like. You're both correct as weird as that might seem at first and second gances. But yeah, earlyoom is known and intended to be a bit simplistic and it's not always going to do what you want but really we're trying to knock off the worst instances of these problems. Because frankly the resource control picture isn't yet complete, so not all this cgroup2 stuff is done on the desktop. And also it's one of the top 3 reasons for btrfs by default because it's the only file system right now the cgroup2 guys tell us they know does IO isolation properly. It is not a hard requirement to use btrfs to get improved resource control, but since memory and io pressures are tightly coupled, to have a complete picture we need IO isolation. That doesn't mean every time you're lost without btrfs. But some percent of the time (whatever it is) the workload will be such that IO isolation is needed and if we don't have it, the control won't be quite as good. And yeah, we'll have to test it and try to break it because that's fun! So I think it's a good idea to use earlyoom, and it's simple enough for folks to tweak, if they want to tweak, and learn more about oom stuff. And maybe they decide they want to know even more, and end up looking at nohang, which is a more sophisticated user space oom killer. And they can learn a ton more about how this is actually a hard problem and people are learning all kinds of new things about solving it. And then if they get really down into the rabbit hole maybe they want to do some more cgroup2 and resource control work with their own apps, or even contribute at the desktop or kernel level. Why not? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 30.6.2020 22:38, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: sd-boot is already installed on end users system, is light weight compared to Grub ( sd-boot only supports uefi,smaller code size, easier to maintain ). And that is exactly the problem, systemd-boot has only a small fraction of the feature set of GRUB. That is what makes it so small. I do not see what value it would provide over GRUB-EFI. In addition, as far as I know, systemd-boot is not compatible with the "Secure Boot" shim. sd-boot works fine with secure boot but good point I'll add a test case for that and check if it's not working. ( This might actually have been one of those case that I might have forgotten so good catch ) JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Tue, 30 Jun 2020 at 17:09, Neal Gompa wrote: > > On Tue, Jun 30, 2020 at 4:30 PM Justin Forbes wrote: > > > > On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr > > wrote: > > > > > > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote: > > > > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro > > > > wrote: > > > > > > > > > > > > > > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > > > > > wrote: > > > > > > > > > > > For the record, as this directly affects the Workstation > > > > > > deliverable, > > > > > > I will be voting -1 until and unless the Workstation WG votes in > > > > > > favor. > > > > > > > > > > > > > > > > > > > > > > > > Yes, it's a large set of Change owners, but since only two of them > > > > > > are > > > > > > Workstation WG members, they are not representative of that group. > > > > > > > > > > > > > > > > > > > > Workstation WG hat on: > > > > > > > > > > > > > > > > > > > > I don't think there's any need to vote -1 for that reason alone. The > > > > > Workstation WG has discussed the change proposal at several meetings > > > > > recently (really, we've spent a long time on this), and frankly we > > > > > were > > > > > not making a ton of progress towards reaching a decision either way, > > > > > so > > > > > going forward with the change proposal and moving the discussion to > > > > > devel@ to get feedback from a wider audience and from FESCo seemed > > > > > like > > > > > a good idea. Most likely, we'll wind up doing whatever FESCo chooses > > > > > here, but unless FESCo were to explicitly indicate intent to override > > > > > the Workstation WG, we would not consider a FESCo decision to limit > > > > > what the Workstation WG can do with the Workstation product. At least, > > > > > my understanding of the power structure FESCo has established is that > > > > > the WG can make product-specific decisions that differ from FESCo's > > > > > decisions whenever we want, unless FESCo says otherwise (because FESCo > > > > > always has final say). That is, if FESCo were to approve btrfs by > > > > > default, but Workstation WG were to vote to stick with ext4, then we > > > > > would stick with ext4 unless FESCo were to say "no really, you need to > > > > > switch to btfs" (which I highly doubt would happen). So I don't see > > > > > any > > > > > reason to vote -1 here out of concern for overriding the WG. > > > > > > > > > > > > > > > > > > > > > > The problem is that the request as discussed reads as "FESCo says use > > > > it for workstation" vs "FESCo has no problem with Workstation saying > > > > they want btrfs" or "FESCo says use btrfs as default". Yes it says > > > > "desktop variants" but only 1 variant really counts and that is > > > > Workstation. So yes, either Workstation agrees to it or it isn't > > > > getting voted on. If Workstation can't come to an agreement on it, > > > > then the proposal is dead. Anything else is an end-run and a useless > > > > trolling of people to see how many rants LWN counts in its weekly > > > > messages. > > > > > > Well, it's not only Workstation that this proposal is trying to throw > > > btrfs > > > on, but the other desktops as well, such as KDE Spin. > > > > How is that even a thing? Shouldn't a spin maintainer be responsible > > for choosing the defaults of their spin? This proposal seems fairly > > absurd in the regard of dictating what other people should do. > > For what it's worth, I asked spin owners from each one before adding > them. That's why the change covers them all, they all assented to it. > I am doing all the work for it, but I asked for their approval to be > covered under this. > > Please don't assume such absurd things like that, especially given the > list of change owners and listed responsible entities. > > The issue isn't that you haven't done your work. It is that it looks like you were set up to fail. The email from Michael comes across that Workstation couldn't make a decision and told you to go see if FESCO would approve it... but even then they don't have to follow through on it because they are independent. So all that work, all the tantrums from people who just love to fly off the handle on anything, all that bull.. is for essentially nothing. Because in the end, if FESCO does approve it, it means every spin etc is stuck with it while Workstation can decide not to... even though they sent you to get the decision. That is where if I was on FESCO I would say this proposal is dead. Either a Working Group wants something and will fight for it, or they don't. If they don't and have veto authority over anything FESCO says.. then it doesn't matter what FESCO decides. -- 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:
Re: Lua 5.4.0
* Tom Callaway [30/06/2020 18:00] : > > lua-event seems to be broken because of broken deps unrelated to Lua > 5.4: nothing provides perl(:MODULE_COMPAT_5.30.1) needed by > perl-Monotone-1.1-34.fc32.x86_64, so I left it alone. FTR, We've moved on to Perl 5.32.x so monotone needs to be rebuild against that so that we get a new perl-Monotone package. Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Lua 5.4.0
On Tue, Jun 30, 2020 at 4:01 PM Tom Callaway wrote: > lua-event seems to be broken because of broken deps unrelated to Lua 5.4: > nothing provides perl(:MODULE_COMPAT_5.30.1) needed by > perl-Monotone-1.1-34.fc32.x86_64, so I left it alone. I opened this pull request against monotone to try to unblock lua-event: https://src.fedoraproject.org/rpms/monotone/pull-request/1 -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Jóhann B. Guðmundsson wrote: > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes > it beg the question if now would not be the time to stop supporting > booting in legacy bios mode and move to uefi only supported boot which > has been available on any common intel based x86 platform since atleast > 2005. No, it would not. It would mean desupporting a wide range of existing hardware and some VM environments (even with QEMU/KVM, I found the SeaBIOS legacy BIOS to be much less quirky than the OVMF UEFI implementation, and other VM environments might not support UEFI at all, including older QEMU versions that may still be in use as hosts for modern Fedora guests). And for what gain? I do not think switching from GRUB-EFI to systemd-boot as you propose would be of any benefit for UEFI users. (It would actually mean fewer features for no tangible benefit.) Hence, we are dealing with GRUB in both enviroments. So I do not see the maintenance burden of continued BIOS support, also considering that, in my experience, the environment that keeps causing problems is actually UEFI, not BIOS. > This post is just to gather feed back why Fedora should still continue > to support legacy BIOS boot as opposed to stop supporting it and > potentially drop grub2 and use sd-boot instead. Fedora should still continue to support legacy BIOS boot. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
python-sphinx_rtd_theme update: comments requested
sphinx_rtd_theme 0.5.0 is out. I have taken the unprecedented step (for me!) of creating a pull request instead of just updating the package, because I'm taking a few steps that I would like to have other eyes on. Pull request: https://src.fedoraproject.org/rpms/python-sphinx_rtd_theme/pull-request/2 The first issue is that, with this release, upstream defaults to building the Javascript and CSS files from source. This is a laudable move. I'm glad upstream did that. Unfortunately, the build process requires quite a few things we don't have in Fedora right now, so I've had to figure out how to subvert upstream's build system and use the prebuilt bits instead. I have neither the time nor the expertise to add the missing bits to Fedora. There are quite a lot of them. The second issue is that the package has not been in compliance with the recently revised font guidelines. With this pull request, I am attempting to bring this package into compliance. This means no longer using fonts in eot, svg, woff, or woff2 formats, but going with straight ttf. I'm worried about the impact this might have on dependent packages. Third, any package that includes documentation generated from this package will need this: Requires: font(fontawesome) Requires: font(lato) Requires: font(robotoslab) In addition, if that documentation is put anywhere that an old Internet Explorer might see it, then this will also be needed: Requires: js-html5shiv How should that information be conveyed to consumers? Thank you for any help you can give me. If you see something that makes you wonder what I was thinking, that's probably an indication that I don't know what I'm doing and you should tell me how to do it the right way. Regards, -- 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Tue, Jun 30, 2020 at 6:30 PM Kevin Kofler wrote: > > Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/KDEEarlyOOM > > > > == Summary == > > As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install > > earlyoom package, and enable it by default. If both RAM and swap go below > > 10% free, earlyoom issues SIGTERM to the process with the largest > > oom_score. If both RAM and swap go below 5% free, earlyoom issues SIGKILL > > to the process with the largest oom_score. The idea is to recover from out > > of memory situations sooner, rather than the typical complete system hang > > in which the user has no other choice but to force power off. > > I am opposed to this change, for the same reasons I was opposed to EarlyOOM > to begin with: this solution kills processes under arbitrary conditions that > are neither necessary nor sufficient to prevent a swap thrashing collapse > (i.e., it can both kill processes unnecessarily (false positives) and fail > to kill processes when it would be necessary to prevent swap thrashing > (false negatives)). It is also unclear that it can prevent full OOM (both > RAM and swap completely full) in all cases, due to EarlyOOM being a > userspace process that races with the memory-consuming processes and that > may end up not getting scheduled due to the very impending OOM condition > that it is trying to prevent. > > I strongly believe that this kernel problem can only be solved within the > kernel, by a synchronous (hence race-free) hook on all allocations. > I still believe that too, except *nobody cares in the Linux kernel community*. This problem has existed for a decade, and nobody in the Linux kernel community is interested in fixing it. At this point, I've given up. Most of us have given up. If they ever get around to doing the right thing, I'll happily punt all this stuff, but they won't, so here we are. You can believe it until you're blue in the face, it doesn't matter if they don't care. Unless you are going to fix it? :) > > == Owner == > > * Name: [[User:bcotton|Ben Cotton]] > > * Email: bcot...@redhat.com > > Why is this not owned by Rex Dieter and/or some other KDE SIG member? > If you want, I'll happily attach my name to it if that's what it takes to feel "blessed". I'm a KDE SIG member as well. -- 真実はいつも一つ！/ 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 30.6.2020 22:31, nick...@gmail.com wrote: On Tue, 2020-06-30 at 21:55 +, Jóhann B. Guðmundsson wrote: On 30.6.2020 21:14, nick...@gmail.com wrote: On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote: Grub discourages users who have tried sd-boot from coming/returning to Fedora [1]. Bottom line I think this will be a good move for the distribution and a good time to start looking into and make that move. JBG 1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/ I read the whole reddit link, but I couldn't understand what's wrong with grub. The poster admits to having an obsession with keeping the number of packages to a minimum (I don't know what that has to do with grub), and doesn't like grub for some unexplained reason. Note that I have never used sd-boot. So far, I've used LILO (starting with Red Hat Linux 5.0), grub1 and grub2. These days, I don't even notice the boot loader. This means it's doing its job properly. :) Maybe I should try sd-boot in a UEFI VM and see for myself, but can someone explain what's the difference? I have one system where I run Fedora Server in UEFI mode and I haven't ever had the need to mess with the bootloader. It just shows its menu for 5 seconds and that's all that it does. I don't understand how can something like that discourage a user from using Fedora? :) Given that you have not changed an entry in your boot loader for quite sometime or perhaps ever it would actually be better that you yourself setup Fedora using sd-boot as the boot manager and compare changing an configuration entry in sd-boot with doing the exact same thing in Grub2 and share your feedback and experience of doing so with the rest of the community rather then someone provide you with an answer. I would try it, but I don't know how, since Fedora uses GRUB2. Should I install ArchLinux in a VM or is there a way to try it with Fedora? Is there any documentation for how to install it and how to use it? Good point I was not planning on doing that until I had some feedback on how big of scope this could turn out to be but I see if I cant setup a minimal test image you can build locally with mkosi and write some documentation. It's almost 23:00 here so it wont be until tomorrow. 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.
Jóhann B. Guðmundsson wrote: > sd-boot is already installed on end users system, is light weight > compared to Grub ( sd-boot only supports uefi,smaller code size, easier > to maintain ). And that is exactly the problem, systemd-boot has only a small fraction of the feature set of GRUB. That is what makes it so small. I do not see what value it would provide over GRUB-EFI. In addition, as far as I know, systemd-boot is not compatible with the "Secure Boot" shim. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
rawhide - glibc/pthreads/... - broken pending mass rebuild?
Is Fedora Rawhide unstable at the moment, pending a mass rebuild? I've seen a lot of random problems related to pthreads at the moment, such as: 16/78 Test #12: JSS_DER_Encoding_of_Enumeration_regression_test ...Child aborted***Exception: 0.99 sec FINE: CryptoManager: loading JSS library FINE: CryptoManager: loaded JSS library from java.library.path java: ../nptl/pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. Another, different stack trace here (pthreads fails to lock, triggering a bug in opencryptoki): https://pagure.io/dogtagpki/issue/3181#comment-661911 And others. They don't reproduce consistently though. Should I go ahead and file a bug or just wait and be patient? :) This is blocking some rebuilds on rawhide at the moment for us. - Alex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, Jun 29, 2020, at 6:57 PM, Markus Larsson wrote: > On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote: > > On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote: > > > Why not Stratis? > > > > Stratis cannot be used to build the root filesystem. (It's been > > answered elsewhere in the thread.) > > Are we sure? > https://github.com/stratis-storage/stratisd/issues/635 > While it might not be super there yet it seems it is technically > working (I may be wrong I have done 0 tests). > But given how new that is and that tolling around it isn't there it > pretty far from being a viable default. > Indeed, a comment there says, "Yes this should work for root fs. No write up has been done other than what is mentioned in this issue already." So the stratis folks say it's possible. I'd say it's safe to say there's no Anaconda installer support for it (yet?), though... Once upon a time, I opened a Red Hat case asking how to use stratis for boot and they provided nothing useful. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Tue, 2020-06-30 at 21:55 +, Jóhann B. Guðmundsson wrote: > On 30.6.2020 21:14, nick...@gmail.com wrote: > > On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote: > > > Grub discourages users who have tried sd-boot from > > > coming/returning > > > to > > > Fedora [1]. > > > > > > Bottom line I think this will be a good move for the distribution > > > and > > > a > > > good time to start looking into and make that move. > > > > > > JBG > > > > > > 1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/ > > I read the whole reddit link, but I couldn't understand what's > > wrong > > with grub. The poster admits to having an obsession with keeping > > the > > number of packages to a minimum (I don't know what that has to do > > with > > grub), and doesn't like grub for some unexplained reason. Note that > > I > > have never used sd-boot. So far, I've used LILO (starting with Red > > Hat > > Linux 5.0), grub1 and grub2. These days, I don't even notice the > > boot > > loader. This means it's doing its job properly. :) > > > > Maybe I should try sd-boot in a UEFI VM and see for myself, but can > > someone explain what's the difference? > > > > I have one system where I run Fedora Server in UEFI mode and I > > haven't > > ever had the need to mess with the bootloader. It just shows its > > menu > > for 5 seconds and that's all that it does. I don't understand how > > can > > something like that discourage a user from using Fedora? :) > > Given that you have not changed an entry in your boot loader for > quite > sometime or perhaps ever it would actually be better that you > yourself > setup Fedora using sd-boot as the boot manager and compare changing > an > configuration entry in sd-boot with doing the exact same thing in > Grub2 > and share your feedback and experience of doing so with the rest of > the > community rather then someone provide you with an answer. I would try it, but I don't know how, since Fedora uses GRUB2. Should I install ArchLinux in a VM or is there a way to try it with Fedora? Is there any documentation for how to install it and how to use it? Best regards, Nikolay ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/KDEEarlyOOM > > == Summary == > As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install > earlyoom package, and enable it by default. If both RAM and swap go below > 10% free, earlyoom issues SIGTERM to the process with the largest > oom_score. If both RAM and swap go below 5% free, earlyoom issues SIGKILL > to the process with the largest oom_score. The idea is to recover from out > of memory situations sooner, rather than the typical complete system hang > in which the user has no other choice but to force power off. I am opposed to this change, for the same reasons I was opposed to EarlyOOM to begin with: this solution kills processes under arbitrary conditions that are neither necessary nor sufficient to prevent a swap thrashing collapse (i.e., it can both kill processes unnecessarily (false positives) and fail to kill processes when it would be necessary to prevent swap thrashing (false negatives)). It is also unclear that it can prevent full OOM (both RAM and swap completely full) in all cases, due to EarlyOOM being a userspace process that races with the memory-consuming processes and that may end up not getting scheduled due to the very impending OOM condition that it is trying to prevent. I strongly believe that this kernel problem can only be solved within the kernel, by a synchronous (hence race-free) hook on all allocations. > == Owner == > * Name: [[User:bcotton|Ben Cotton]] > * Email: bcot...@redhat.com Why is this not owned by Rex Dieter and/or some other KDE SIG member? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 1852622] perl-Astro-FITS-CFITSIO-1.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1852622 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Astro-FITS-CFITSIO-1.14-1.fc32.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=46400599 -- 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: module 'posix' not found when module load mpi/mpich-x86_64
On 30. 06. 20 19:34, Christoph Junghans wrote: Adding BuildRequires: lua-posix doesn't help. lua-posix was rebuilt for Lua 5.4 hence it is installed into /usr/share/lua/5.4 lmod searches in /usr/share/lua/5.3 Any ideas? Does lmod need a rebuild for lua-5.3? Given the above I assume Lmod needs to be rebuilt and/or switched to use Lua 5.4. Note that /usr/share/lmod/lmod/libexec/lmod has: local sys_lua_path = "/usr/share/lua/5.3/?.lua;/usr/share/lua/5.3/?/init.lua;/usr/lib64/lua/5.3/?.lua;/usr/lib64/lua/5.3/?/init.lua" I don't if that's generated on build time or whether it will require patching. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
- Original Message - > From: "James Cassell" > To: "Fedora Development List" > Sent: Tuesday, June 30, 2020 6:08:30 PM > Subject: Re: Fedora 33 System-Wide Change proposal: Make btrfs the default > file system for desktop variants > > On Tue, Jun 30, 2020, at 10:18 AM, Steven Whitehouse wrote: > > I know it has been rather confined to Red Hat internally, however that > > was not the intention, and in fact I would like to strongly encourage > > community involvement. There is an upstream mailing list, which > > currently has almost no traffic: springfi...@sourceware.org so please > > do join and ask questions, if anybody is interested in finding out more. > > > > Indeed, this is the first I've heard of "Project Springfield" -- it looks > like the list only had a couple of messages at its start in 2018 and nothing > since. > > https://springfield-project.github.io/ > > The "subscribe" link is broken... it should probably point to > https://sourceware.org/mailman/listinfo/springfield > > I'd send a pull request, but I couldn't find the github repo associated with > the page. https://github.com/springfield-project/springfield-project.github.io/blob/master/index.md#so-youd-like-to-contribute https://.github.io/ -- you'll almost always find it at https://github.com//github.io, unless it is a repo-specific GH pages. Then it'd be: https://.github.io// -- which you'll find somewhere in the https://github.com// repo (either docs/ folder in the default branch or gh-pages branch). https://help.github.com/en/github/working-with-github-pages/about-github-pages - Alex > > > V/r, > James Cassell > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Tue, Jun 30, 2020, at 10:18 AM, Steven Whitehouse wrote: > I know it has been rather confined to Red Hat internally, however that > was not the intention, and in fact I would like to strongly encourage > community involvement. There is an upstream mailing list, which > currently has almost no traffic: springfi...@sourceware.org so please > do join and ask questions, if anybody is interested in finding out more. > Indeed, this is the first I've heard of "Project Springfield" -- it looks like the list only had a couple of messages at its start in 2018 and nothing since. https://springfield-project.github.io/ The "subscribe" link is broken... it should probably point to https://sourceware.org/mailman/listinfo/springfield I'd send a pull request, but I couldn't find the github repo associated with the page. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lua 5.4.0
All of these are now fixed, except for lua-luv and lua-event. Lua-luv needs a fixed cmake (FindLua.cmake needed patching to find Lua 5.4). I've been trying to build a new cmake in rawhide all afternoon, but s390x fails to get a buildroot established each time (not due to cmake issues). The lua-luv fixes are checked into git, I'll keep trying. lua-event seems to be broken because of broken deps unrelated to Lua 5.4: nothing provides perl(:MODULE_COMPAT_5.30.1) needed by perl-Monotone-1.1-34.fc32.x86_64, so I left it alone. Thanks, Tom On Tue, Jun 30, 2020 at 10:46 AM Miro Hrončok wrote: > On 30. 06. 20 16:06, Miro Hrončok wrote: > > > > The current status is: > > > > $ comm -23 <(repoquery --refresh --repo=koji --whatrequires 'lua(abi) = > 5.3' > > --source | pkgname | sort) <(repoquery --repo=koji --whatrequires > 'lua(abi) = > > 5.4' --source | pkgname | sort) > > > > librs232 > https://bugzilla.redhat.com/show_bug.cgi?id=1852144 > > > lua-cqueues > https://bugzilla.redhat.com/show_bug.cgi?id=1852147 > > > lua-event > https://bugzilla.redhat.com/show_bug.cgi?id=1852150 > > > lua-ldap > https://bugzilla.redhat.com/show_bug.cgi?id=1852154 > > > lua-luaossl > https://bugzilla.redhat.com/show_bug.cgi?id=1852157 > > > lua-luv > https://bugzilla.redhat.com/show_bug.cgi?id=1852158 > > > prosody > https://bugzilla.redhat.com/show_bug.cgi?id=1852234 > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 30.6.2020 21:14, nick...@gmail.com wrote: On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote: Grub discourages users who have tried sd-boot from coming/returning to Fedora [1]. Bottom line I think this will be a good move for the distribution and a good time to start looking into and make that move. JBG 1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/ I read the whole reddit link, but I couldn't understand what's wrong with grub. The poster admits to having an obsession with keeping the number of packages to a minimum (I don't know what that has to do with grub), and doesn't like grub for some unexplained reason. Note that I have never used sd-boot. So far, I've used LILO (starting with Red Hat Linux 5.0), grub1 and grub2. These days, I don't even notice the boot loader. This means it's doing its job properly. :) Maybe I should try sd-boot in a UEFI VM and see for myself, but can someone explain what's the difference? I have one system where I run Fedora Server in UEFI mode and I haven't ever had the need to mess with the bootloader. It just shows its menu for 5 seconds and that's all that it does. I don't understand how can something like that discourage a user from using Fedora? :) Given that you have not changed an entry in your boot loader for quite sometime or perhaps ever it would actually be better that you yourself setup Fedora using sd-boot as the boot manager and compare changing an configuration entry in sd-boot with doing the exact same thing in Grub2 and share your feedback and experience of doing so with the rest of the community rather then someone provide you with an answer. 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
[Bug 1852622] perl-Astro-FITS-CFITSIO-1.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1852622 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1699392 --> https://bugzilla.redhat.com/attachment.cgi?id=1699392=edit [patch] Update to 1.14 (#1852622) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1852622] New: perl-Astro-FITS-CFITSIO-1.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1852622 Bug ID: 1852622 Summary: perl-Astro-FITS-CFITSIO-1.14 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Astro-FITS-CFITSIO Keywords: FutureFeature, Triaged Assignee: or...@nwra.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: or...@nwra.com, perl-devel@lists.fedoraproject.org, scitech-b...@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.14 Current version/release in rawhide: 1.12-5.fc32 URL: http://search.cpan.org/dist/Astro-FITS-CFITSIO/ 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/11580/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Tue, Jun 30, 2020 at 4:29 PM Neal Gompa wrote: > > On Tue, Jun 30, 2020 at 5:19 PM Justin Forbes wrote: > > > > On Tue, Jun 30, 2020 at 4:02 PM Neal Gompa wrote: > > > > > > On Tue, Jun 30, 2020 at 4:30 PM Justin Forbes > > > wrote: > > > > > > > > On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr > > > > wrote: > > > > > > > > > > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote: > > > > > > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > > > > > > > wrote: > > > > > > > > > > > > > > > For the record, as this directly affects the Workstation > > > > > > > > deliverable, > > > > > > > > I will be voting -1 until and unless the Workstation WG votes in > > > > > > > > favor. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, it's a large set of Change owners, but since only two of > > > > > > > > them are > > > > > > > > Workstation WG members, they are not representative of that > > > > > > > > group. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Workstation WG hat on: > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't think there's any need to vote -1 for that reason alone. > > > > > > > The > > > > > > > Workstation WG has discussed the change proposal at several > > > > > > > meetings > > > > > > > recently (really, we've spent a long time on this), and frankly > > > > > > > we were > > > > > > > not making a ton of progress towards reaching a decision either > > > > > > > way, so > > > > > > > going forward with the change proposal and moving the discussion > > > > > > > to > > > > > > > devel@ to get feedback from a wider audience and from FESCo > > > > > > > seemed like > > > > > > > a good idea. Most likely, we'll wind up doing whatever FESCo > > > > > > > chooses > > > > > > > here, but unless FESCo were to explicitly indicate intent to > > > > > > > override > > > > > > > the Workstation WG, we would not consider a FESCo decision to > > > > > > > limit > > > > > > > what the Workstation WG can do with the Workstation product. At > > > > > > > least, > > > > > > > my understanding of the power structure FESCo has established is > > > > > > > that > > > > > > > the WG can make product-specific decisions that differ from > > > > > > > FESCo's > > > > > > > decisions whenever we want, unless FESCo says otherwise (because > > > > > > > FESCo > > > > > > > always has final say). That is, if FESCo were to approve btrfs by > > > > > > > default, but Workstation WG were to vote to stick with ext4, then > > > > > > > we > > > > > > > would stick with ext4 unless FESCo were to say "no really, you > > > > > > > need to > > > > > > > switch to btfs" (which I highly doubt would happen). So I don't > > > > > > > see any > > > > > > > reason to vote -1 here out of concern for overriding the WG. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The problem is that the request as discussed reads as "FESCo says > > > > > > use > > > > > > it for workstation" vs "FESCo has no problem with Workstation saying > > > > > > they want btrfs" or "FESCo says use btrfs as default". Yes it says > > > > > > "desktop variants" but only 1 variant really counts and that is > > > > > > Workstation. So yes, either Workstation agrees to it or it isn't > > > > > > getting voted on. If Workstation can't come to an agreement on it, > > > > > > then the proposal is dead. Anything else is an end-run and a > > > > > > useless > > > > > > trolling of people to see how many rants LWN counts in its weekly > > > > > > messages. > > > > > > > > > > Well, it's not only Workstation that this proposal is trying to throw > > > > > btrfs > > > > > on, but the other desktops as well, such as KDE Spin. > > > > > > > > How is that even a thing? Shouldn't a spin maintainer be responsible > > > > for choosing the defaults of their spin? This proposal seems fairly > > > > absurd in the regard of dictating what other people should do. > > > > > > For what it's worth, I asked spin owners from each one before adding > > > them. That's why the change covers them all, they all assented to it. > > > I am doing all the work for it, but I asked for their approval to be > > > covered under this. > > > > > > Please don't assume such absurd things like that, especially given the > > > list of change owners and listed responsible entities. > > > > > > > I honestly hadn't considered it until it came up that the Workstation > > WG has not come to agreement on this change yet. Either way, it is my > > belief that the spins should be able to decide what they want to use, > > when they want to use it. If they have bought in, that's great. > > From a kernel standpoint, the only change being asked here is to make > > btrfs inline instead of a module. If it is to become the default fs > > for any spin, I don't have a problem with that.
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Tue, Jun 30, 2020 at 5:19 PM Justin Forbes wrote: > > On Tue, Jun 30, 2020 at 4:02 PM Neal Gompa wrote: > > > > On Tue, Jun 30, 2020 at 4:30 PM Justin Forbes wrote: > > > > > > On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr > > > wrote: > > > > > > > > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote: > > > > > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro > > > > > wrote: > > > > > > > > > > > > > > > > > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > > > > > > wrote: > > > > > > > > > > > > > For the record, as this directly affects the Workstation > > > > > > > deliverable, > > > > > > > I will be voting -1 until and unless the Workstation WG votes in > > > > > > > favor. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, it's a large set of Change owners, but since only two of > > > > > > > them are > > > > > > > Workstation WG members, they are not representative of that group. > > > > > > > > > > > > > > > > > > > > > > > > Workstation WG hat on: > > > > > > > > > > > > > > > > > > > > > > > > I don't think there's any need to vote -1 for that reason alone. The > > > > > > Workstation WG has discussed the change proposal at several meetings > > > > > > recently (really, we've spent a long time on this), and frankly we > > > > > > were > > > > > > not making a ton of progress towards reaching a decision either > > > > > > way, so > > > > > > going forward with the change proposal and moving the discussion to > > > > > > devel@ to get feedback from a wider audience and from FESCo seemed > > > > > > like > > > > > > a good idea. Most likely, we'll wind up doing whatever FESCo chooses > > > > > > here, but unless FESCo were to explicitly indicate intent to > > > > > > override > > > > > > the Workstation WG, we would not consider a FESCo decision to limit > > > > > > what the Workstation WG can do with the Workstation product. At > > > > > > least, > > > > > > my understanding of the power structure FESCo has established is > > > > > > that > > > > > > the WG can make product-specific decisions that differ from FESCo's > > > > > > decisions whenever we want, unless FESCo says otherwise (because > > > > > > FESCo > > > > > > always has final say). That is, if FESCo were to approve btrfs by > > > > > > default, but Workstation WG were to vote to stick with ext4, then we > > > > > > would stick with ext4 unless FESCo were to say "no really, you need > > > > > > to > > > > > > switch to btfs" (which I highly doubt would happen). So I don't see > > > > > > any > > > > > > reason to vote -1 here out of concern for overriding the WG. > > > > > > > > > > > > > > > > > > > > > > > > > > > The problem is that the request as discussed reads as "FESCo says use > > > > > it for workstation" vs "FESCo has no problem with Workstation saying > > > > > they want btrfs" or "FESCo says use btrfs as default". Yes it says > > > > > "desktop variants" but only 1 variant really counts and that is > > > > > Workstation. So yes, either Workstation agrees to it or it isn't > > > > > getting voted on. If Workstation can't come to an agreement on it, > > > > > then the proposal is dead. Anything else is an end-run and a useless > > > > > trolling of people to see how many rants LWN counts in its weekly > > > > > messages. > > > > > > > > Well, it's not only Workstation that this proposal is trying to throw > > > > btrfs > > > > on, but the other desktops as well, such as KDE Spin. > > > > > > How is that even a thing? Shouldn't a spin maintainer be responsible > > > for choosing the defaults of their spin? This proposal seems fairly > > > absurd in the regard of dictating what other people should do. > > > > For what it's worth, I asked spin owners from each one before adding > > them. That's why the change covers them all, they all assented to it. > > I am doing all the work for it, but I asked for their approval to be > > covered under this. > > > > Please don't assume such absurd things like that, especially given the > > list of change owners and listed responsible entities. > > > > I honestly hadn't considered it until it came up that the Workstation > WG has not come to agreement on this change yet. Either way, it is my > belief that the spins should be able to decide what they want to use, > when they want to use it. If they have bought in, that's great. > From a kernel standpoint, the only change being asked here is to make > btrfs inline instead of a module. If it is to become the default fs > for any spin, I don't have a problem with that. I submitted it because it was agreed to submit it[1]. I would have waited otherwise. [1]: https://meetbot.fedoraproject.org/teams/workstation/workstation.2020-06-25-04.07.log.html -- 真実はいつも一つ！/ 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
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Tue, Jun 30, 2020 at 4:02 PM Neal Gompa wrote: > > On Tue, Jun 30, 2020 at 4:30 PM Justin Forbes wrote: > > > > On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr > > wrote: > > > > > > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote: > > > > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro > > > > wrote: > > > > > > > > > > > > > > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > > > > > wrote: > > > > > > > > > > > For the record, as this directly affects the Workstation > > > > > > deliverable, > > > > > > I will be voting -1 until and unless the Workstation WG votes in > > > > > > favor. > > > > > > > > > > > > > > > > > > > > > > > > Yes, it's a large set of Change owners, but since only two of them > > > > > > are > > > > > > Workstation WG members, they are not representative of that group. > > > > > > > > > > > > > > > > > > > > Workstation WG hat on: > > > > > > > > > > > > > > > > > > > > I don't think there's any need to vote -1 for that reason alone. The > > > > > Workstation WG has discussed the change proposal at several meetings > > > > > recently (really, we've spent a long time on this), and frankly we > > > > > were > > > > > not making a ton of progress towards reaching a decision either way, > > > > > so > > > > > going forward with the change proposal and moving the discussion to > > > > > devel@ to get feedback from a wider audience and from FESCo seemed > > > > > like > > > > > a good idea. Most likely, we'll wind up doing whatever FESCo chooses > > > > > here, but unless FESCo were to explicitly indicate intent to override > > > > > the Workstation WG, we would not consider a FESCo decision to limit > > > > > what the Workstation WG can do with the Workstation product. At least, > > > > > my understanding of the power structure FESCo has established is that > > > > > the WG can make product-specific decisions that differ from FESCo's > > > > > decisions whenever we want, unless FESCo says otherwise (because FESCo > > > > > always has final say). That is, if FESCo were to approve btrfs by > > > > > default, but Workstation WG were to vote to stick with ext4, then we > > > > > would stick with ext4 unless FESCo were to say "no really, you need to > > > > > switch to btfs" (which I highly doubt would happen). So I don't see > > > > > any > > > > > reason to vote -1 here out of concern for overriding the WG. > > > > > > > > > > > > > > > > > > > > > > The problem is that the request as discussed reads as "FESCo says use > > > > it for workstation" vs "FESCo has no problem with Workstation saying > > > > they want btrfs" or "FESCo says use btrfs as default". Yes it says > > > > "desktop variants" but only 1 variant really counts and that is > > > > Workstation. So yes, either Workstation agrees to it or it isn't > > > > getting voted on. If Workstation can't come to an agreement on it, > > > > then the proposal is dead. Anything else is an end-run and a useless > > > > trolling of people to see how many rants LWN counts in its weekly > > > > messages. > > > > > > Well, it's not only Workstation that this proposal is trying to throw > > > btrfs > > > on, but the other desktops as well, such as KDE Spin. > > > > How is that even a thing? Shouldn't a spin maintainer be responsible > > for choosing the defaults of their spin? This proposal seems fairly > > absurd in the regard of dictating what other people should do. > > For what it's worth, I asked spin owners from each one before adding > them. That's why the change covers them all, they all assented to it. > I am doing all the work for it, but I asked for their approval to be > covered under this. > > Please don't assume such absurd things like that, especially given the > list of change owners and listed responsible entities. > I honestly hadn't considered it until it came up that the Workstation WG has not come to agreement on this change yet. Either way, it is my belief that the spins should be able to decide what they want to use, when they want to use it. If they have bought in, that's great. From a kernel standpoint, the only change being asked here is to make btrfs inline instead of a module. If it is to become the default fs for any spin, I don't have a problem with that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote: > > > Grub discourages users who have tried sd-boot from coming/returning > to > Fedora [1]. > > Bottom line I think this will be a good move for the distribution and > a > good time to start looking into and make that move. > > JBG > > 1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/ I read the whole reddit link, but I couldn't understand what's wrong with grub. The poster admits to having an obsession with keeping the number of packages to a minimum (I don't know what that has to do with grub), and doesn't like grub for some unexplained reason. Note that I have never used sd-boot. So far, I've used LILO (starting with Red Hat Linux 5.0), grub1 and grub2. These days, I don't even notice the boot loader. This means it's doing its job properly. :) Maybe I should try sd-boot in a UEFI VM and see for myself, but can someone explain what's the difference? I have one system where I run Fedora Server in UEFI mode and I haven't ever had the need to mess with the bootloader. It just shows its menu for 5 seconds and that's all that it does. I don't understand how can something like that discourage a user from using Fedora? :) Best regards, Nikolay ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Fedora-packaging] Re: Patches in Forge macros - Auto macros - Detached rpm changelogs - Fedora 33 System-Wide Change proposal
Le mardi 30 juin 2020 à 21:45 +0200, Igor Raits a écrit : > On Tue, 2020-06-30 at 15:19 -0400, Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > > > == Summary == > > > > redhat-rpm-config will be updated to add patching support to forge > > macros, a plug-able framework to register macros to execute in > > specific sections, and rpm changelogs in detached files. > > > > == Owner == > > * Name: [[User:nim| Nicolas Mailhot]] > > * Email: > > > > == Detailed Description == > > > > This is a system-wide change because all packages build with > > redhat-rpm-config, but it only concerns packages that opted to use > > this part of redhat-rpm-config (users of forge, fonts and go > > macros). > > > > It was driven first, by the need to make the underlying macro > > infrastructure robust enough to package Go modules, and second, by > > an > > unfortunate rpm 4.15 regression that proved it was foolish to > > depend > > on rpmbuild to parse Tags in anything except canonical order. > > I think this would be already at least 30 times we mentioned that RPM > works as expected and the bug was just in the spec files that relied > on Name being parsed before expanding ~/.rpmmacros. Yes, rpm broke existing specs and you insisted it was normal it broke them and the 10+ years during which the pattern they used worked was an anomaly. You told me nothing would be fixed, and I just had to generate tags in the exact undocumented order you wanted them generated, and that you did not care about my problems (to the point, you proposed reverting whole parts of the distribution to the level they were years ago just so you did not have to deal with them). So here is the code that does exactly that. You got your wish, it caused me a lot of work and pain to implement, get out of your defensive mode, people are not doing things to make you miserable they are doing things to solve their own problems. All the things you pretend discovering today have been hashed and re- hashed to death with rpm upstream (to the point, Panu once dismissed a ticket, stating I had already asked the same thing many times and the answer was still no). So now I solved *my* packager problems at the macro level with no rpm maintainer help whatsoever and I don’t care if rpm maintainers suddenly feel they could do better. I spent litterally decades asking them to look at those things, and they did not care (Florian excepted, thank you Florian). > > > A packager that needs custom processing can add custom code above > > or > > bellow the various `%auto_foo` calls, and check with `rpmspec -P` > > that > > the result does what he wants it to do. For obvious reliability > > reasons injecting custom code in the middle of an `%auto_foo` > > sequence > > is not allowed. > > What about rpmdev-bumpspec, vim plugin and such tools adoption that > expect Version/Release/%changelog to be present in spec? That’s why a second change deals with autobumping. That’s why I objected vigorously when you and Panu told me two months ago to generate tags values instead of pointing out that changes in Tag evaluation rules made them useless for my specs. So now everything is generated, and removing the Tag obstruction enabled solving other problems. It was a lot of work I could have done without, but the work is done now, and I *will* use it to its full capabilities, because I did not do this work to make a point, I did it to solve my Fedora packager problems, and it solves them nicely. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Tue, Jun 30, 2020 at 4:30 PM Justin Forbes wrote: > > On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr > wrote: > > > > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote: > > > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro > > > wrote: > > > > > > > > > > > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > > > > wrote: > > > > > > > > > For the record, as this directly affects the Workstation deliverable, > > > > > I will be voting -1 until and unless the Workstation WG votes in > > > > > favor. > > > > > > > > > > > > > > > > > > > > Yes, it's a large set of Change owners, but since only two of them are > > > > > Workstation WG members, they are not representative of that group. > > > > > > > > > > > > > > > > Workstation WG hat on: > > > > > > > > > > > > > > > > I don't think there's any need to vote -1 for that reason alone. The > > > > Workstation WG has discussed the change proposal at several meetings > > > > recently (really, we've spent a long time on this), and frankly we were > > > > not making a ton of progress towards reaching a decision either way, so > > > > going forward with the change proposal and moving the discussion to > > > > devel@ to get feedback from a wider audience and from FESCo seemed like > > > > a good idea. Most likely, we'll wind up doing whatever FESCo chooses > > > > here, but unless FESCo were to explicitly indicate intent to override > > > > the Workstation WG, we would not consider a FESCo decision to limit > > > > what the Workstation WG can do with the Workstation product. At least, > > > > my understanding of the power structure FESCo has established is that > > > > the WG can make product-specific decisions that differ from FESCo's > > > > decisions whenever we want, unless FESCo says otherwise (because FESCo > > > > always has final say). That is, if FESCo were to approve btrfs by > > > > default, but Workstation WG were to vote to stick with ext4, then we > > > > would stick with ext4 unless FESCo were to say "no really, you need to > > > > switch to btfs" (which I highly doubt would happen). So I don't see any > > > > reason to vote -1 here out of concern for overriding the WG. > > > > > > > > > > > > > > > > > The problem is that the request as discussed reads as "FESCo says use > > > it for workstation" vs "FESCo has no problem with Workstation saying > > > they want btrfs" or "FESCo says use btrfs as default". Yes it says > > > "desktop variants" but only 1 variant really counts and that is > > > Workstation. So yes, either Workstation agrees to it or it isn't > > > getting voted on. If Workstation can't come to an agreement on it, > > > then the proposal is dead. Anything else is an end-run and a useless > > > trolling of people to see how many rants LWN counts in its weekly > > > messages. > > > > Well, it's not only Workstation that this proposal is trying to throw btrfs > > on, but the other desktops as well, such as KDE Spin. > > How is that even a thing? Shouldn't a spin maintainer be responsible > for choosing the defaults of their spin? This proposal seems fairly > absurd in the regard of dictating what other people should do. For what it's worth, I asked spin owners from each one before adding them. That's why the change covers them all, they all assented to it. I am doing all the work for it, but I asked for their approval to be covered under this. Please don't assume such absurd things like that, especially given the list of change owners and listed responsible entities. -- 真実はいつも一つ！/ 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: drop bfq scheduler, instead use mq-deadline across the board
On Tue, Jun 30, 2020 at 07:28:53PM +0100, Ankur Sinha wrote: > On Tue, Jun 30, 2020 17:23:16 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Jun 30, 2020 at 04:25:23PM +0100, Ankur Sinha wrote: > > > On Mon, Jun 29, 2020 15:01:24 -0600, Chris Murphy wrote: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1851783 > > > > > > > > The main argument is that for typical and varied workloads in Fedora, > > > > mostly on consumer hardware, we should use mq-deadline scheduler > > > > rather than either none or bfq. > > > > > > > > It may be true most folks with NVMe won't see anything bad with none, > > > > but those who have heavier IO workloads are likely to be better off > > > > with mq-deadline. > > > > > > > > Further details are in the bug, but let's discuss it on list. Thanks! > > > > > > There was this thread about our systems hanging, and the workaround was > > > to revert to mq-deadline from bfq: > > > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MJJFT5AOYUFZ3SO2EDVLJSDAZMZI4HAP/#DA7RCQFIAD4Z3Q7HQBW2ELPTLPYDKJMT > > > > To clarify: you could reliably reproduce the issue when building steps in > > mock. > > Did you verify that it is reliably fixed simply by switching > > bfq→mq-deadline? > > Yes, that was the first change I had made and it had stopped the > hanging. As a permanent fix, though, I switched to using isolation = > simple in mock, and since that works, I've not changed it since. OK, thanks. > (I make it a point to provide the needed information for bugs, but this > release my quota is currently being used up on getting Docker + minikube > to work on F32 for $dayjob) > > > > There are a few threads on AskFedora about systems hanging. They're not > > > the easiest to debug but we did suggest people try switching to > > > mq-deadline to see if it helps: > > > > > > https://ask.fedoraproject.org/t/whole-os-freezes-watching-a-video-with-mpv/6770/10 > > > > > > I don't know enough about this to say if it's a bug and if it has been > > > fixed. > > > > There's a lot of noise in those bug reports. For heisenbugs, the fact > > that something was an issue and after a flurry of half-random changes > > to the system isn't, does not allow us conclude _anything_. We need > > somebody who understands what they are doing to isolate the issue. In > > particular, if this is a kernel hang, than we need a proper traceback > > from the kernel, and not just assume it's the scheduler. > > There is a kernel trace in the related bug that was cited there: > https://bugzilla.redhat.com/show_bug.cgi?id=1767097#c7 > > which links to another bfq bug here that's currently needinfo: > https://bugzilla.redhat.com/show_bug.cgi?id=1767539 > > > (In particular, if this is a race condition, changing the scheduler > > could be just making the condition less likely because the system is > > slower or faster or just schedules processes in a different order, > > without the scheduler being relevant to the bug). > > Like I said, I don't know. I'm a fairly advanced Linux user but you can > hardly me to also be kernel hacker. :) > > For kernel bugs, I'd strongly suggest giving reporters steps by step > instructions or links to using a "serial console" or a "netconsole". > These are not part of my working vocabulary (I cannot speak for others). Thanks for the links. This seems to be a tough cookie and I hope it gets resolved as some point. And to clarify: my comment about debugging was not directed to you in particular, apart from the question above which you have already answered. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Tuesday, June 30, 2020, Justin Forbes wrote: > On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr > wrote: > > > > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote: > > > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro > > > wrote: > > > > > > > > > > > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > > > > wrote: > > > > > > > > > For the record, as this directly affects the Workstation > deliverable, > > > > > I will be voting -1 until and unless the Workstation WG votes in > > > > > favor. > > > > > > > > > > > > > > > > > > > > Yes, it's a large set of Change owners, but since only two of them > are > > > > > Workstation WG members, they are not representative of that group. > > > > > > > > > > > > > > > > Workstation WG hat on: > > > > > > > > > > > > > > > > I don't think there's any need to vote -1 for that reason alone. The > > > > Workstation WG has discussed the change proposal at several meetings > > > > recently (really, we've spent a long time on this), and frankly we > were > > > > not making a ton of progress towards reaching a decision either way, > so > > > > going forward with the change proposal and moving the discussion to > > > > devel@ to get feedback from a wider audience and from FESCo seemed > like > > > > a good idea. Most likely, we'll wind up doing whatever FESCo chooses > > > > here, but unless FESCo were to explicitly indicate intent to override > > > > the Workstation WG, we would not consider a FESCo decision to limit > > > > what the Workstation WG can do with the Workstation product. At > least, > > > > my understanding of the power structure FESCo has established is that > > > > the WG can make product-specific decisions that differ from FESCo's > > > > decisions whenever we want, unless FESCo says otherwise (because > FESCo > > > > always has final say). That is, if FESCo were to approve btrfs by > > > > default, but Workstation WG were to vote to stick with ext4, then we > > > > would stick with ext4 unless FESCo were to say "no really, you need > to > > > > switch to btfs" (which I highly doubt would happen). So I don't see > any > > > > reason to vote -1 here out of concern for overriding the WG. > > > > > > > > > > > > > > > > > The problem is that the request as discussed reads as "FESCo says use > > > it for workstation" vs "FESCo has no problem with Workstation saying > > > they want btrfs" or "FESCo says use btrfs as default". Yes it says > > > "desktop variants" but only 1 variant really counts and that is > > > Workstation. So yes, either Workstation agrees to it or it isn't > > > getting voted on. If Workstation can't come to an agreement on it, > > > then the proposal is dead. Anything else is an end-run and a useless > > > trolling of people to see how many rants LWN counts in its weekly > > > messages. > > > > Well, it's not only Workstation that this proposal is trying to throw > btrfs > > on, but the other desktops as well, such as KDE Spin. > > How is that even a thing? Shouldn't a spin maintainer be responsible > for choosing the defaults of their spin? This proposal seems fairly > absurd in the regard of dictating what other people should do. That argument can be used against any change not restricted to a specific spin. Treating all desktop based spins the same unless there is a reason not to makes sense. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject. > org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists. > fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Tue, Jun 30, 2020 at 01:34:42PM -0400, Robbie Harwood wrote: > Igor Raits writes: > > > On Tue, 2020-06-30 at 13:34 +, Jóhann B. Guðmundsson wrote: > > [snip] > > I think there are many people still install OS in the legacy mode, but > > I don't really have numbers. One thing we should definitely do if we > > deprecate legacy BIOS is to properly warn users that still use this > > configuration, develop tooling for them if possible for migration and > > do not allow upgrades that will simply break their system. > > I think this is the only path forward that can actually work. Without > tooling, the only real way to "migrate" from legacy to UEFI is to > reinstall the operating system - much love to anaconda, but that's not > reasonable as a migration path. > > Consider the partitioning. A fairly reasonable legacy setup looks like: > > /dev/sda > \-> /boot > \-> dm_crypt > \-> LVM > \-> / (FS root) > \-> other partitions if you like to live dangerously > > UEFI needs different partitions at the top level, with different size > requirements. So, since we've partitioned the entire disk, that > dm_crypt area needs to shrink... which means the LVM needs to > shrink... which means we need to shrink the filesystems in it. I'm sure > there are people who feel comfortable enough with parted and whatnot to > accomplish this, but I sure don't.[1] I guess I'll throw my opinion into the ring as well. BIOS systems are going to be with us for a very long time. Supporting a single clean bootloader would be wonderful, but that's not the reality of the systems that are out there, and will continue to be out there for decades. grub2, for all of its flaws, covers a very wide range of use cases. I also don't recommend trying to 'migrate' a perfectly working system to a new bootloader. It seems like a giant waste of effort for zero gain, and a high potential for failure. You can't use parted to change a msdos disk to GPT, you'll have to re-partition it. And move the partitions around, as well as shift the data around, add more partitions, etc. It *may* work, but why take the chance? If you care that much about your bootloader just backup your system and reinstall. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-reportlab: undefined-non-weak-symbol
Thank you Jerry. On 30/06/20 22:22, Jerry James wrote: > On Tue, Jun 30, 2020 at 11:45 AM Antonio T. sagitter > wrote: >> Are these `undefined-non-weak-symbol` expected in python-reportlab? >> >> https://pastebin.com/dRZUbpJx > > Yes, see this thread: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IAIUO5XU54FQM64TDXWF4YMHHWGQFNXT/#TT2PQ7UAJDHYUEKBJAQKKCR43FMKOJRH > -- --- 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: python-reportlab: undefined-non-weak-symbol
Thank you Jerry. On 30/06/20 22:22, Jerry James wrote: > On Tue, Jun 30, 2020 at 11:45 AM Antonio T. sagitter > wrote: >> Are these `undefined-non-weak-symbol` expected in python-reportlab? >> >> https://pastebin.com/dRZUbpJx > > Yes, see this thread: > > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/IAIUO5XU54FQM64TDXWF4YMHHWGQFNXT/#TT2PQ7UAJDHYUEKBJAQKKCR43FMKOJRH > -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, Jun 30, 2020 at 9:40 pm, Vitaly Zaitsev via devel wrote: The legal status of the extracted tables was discussed a few months ago with members of the Fedora legal team. You can check archives. I tried: https://lists.fedoraproject.org/archives/search?mlist=legal%40lists.fedoraproject.org=dptfxtract And: https://lists.fedoraproject.org/archives/search?mlist=legal%40lists.fedoraproject.org=thermald Any references would be very interesting, thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, 30 Jun 2020 at 16:14, Jared Dominguez wrote: > > > > On Tue, Jun 30, 2020 at 3:41 PM Vitaly Zaitsev via devel > wrote: >> >> On 30.06.2020 19:43, Hans de Goede wrote: >> > That is the first time I have heard that. Do you have a source for that ? >> >> https://github.com/intel/dptfxtract - no sources, only proprietary binaries. >> >> The legal status of the extracted tables was discussed a few months ago >> with members of the Fedora legal team. You can check archives. > > > Regardless of the legality of tables output from dptfxtract, that doesn't > really address the fact that thermald, as is in Fedora 32 today (version > 1.9.1 from December) doesn't have dptfxtract (nor do later versions bundle > it) and results in an improvement in thermal behavior on supported systems > without any thermal tables in /etc/thermald. > I am going to say citation is needed here as much as Vitaly's comments. What systems does it work with? How does it work on these systems? What systems does it not work on? Are the various problems from the last time this was discussed to death https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/D4FVY3LLMNGUKNUOEIDXNOOAD577W5XN/ been dealt with? -- 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 30.6.2020 19:22, Robbie Harwood wrote: Jóhann B. Guðmundsson writes: On 30.6.2020 17:49, John M. Harris Jr wrote: On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been available on any common intel based x86 platform since atleast 2005. This is simply false. I'm currently writing this email on a ThinkPad X200 Tablet, which does not support UEFI. I can get dropping x86 support, but dropping BIOS boot support? Such proposal would never be about stop supporting older hardware that's just a misconception people are getting And it's quite evident by the response here that hw that is atleast 2010 and older is still quite happily being used and that hw does not support UEFI and no one is talking about taking that away anytime soon. The first step ( The actual change proposal ) would simply be about replace grub2 with sd-boot for UEFI strictly on the x86 architecture which has UEFI available and enabled ( is not using legacy bios ) and see what issue are encountered, solve those then consider moving to different architectures and further integration if relevant etc. ( baby steps ) Next I would suggest looking at UEFI supported ARM systems ( but I personally would have to obtain such hardware before doing so ). But... why? It's not like grub2 doesn't work for booting UEFI. Doesn't seem like there's a point in running through all the issues that grub2 already solved again. I think we put different meaning in maintainance,usability and issues if you think grub solves anything but I mentioned this elsewhere in the thread and justification/selling points usually end up on the change proposals but I'll repeat it here ;) sd-boot is already installed on end users system, is light weight compared to Grub ( sd-boot only supports uefi,smaller code size, easier to maintain ). It already integrates with the service management framework (systemd). More user friendly than Grub ( has lilo like interface easier to change kernel entry, which goes nicely with the default editor change ) Gnome related changes such as Hans is proposing might be easier to integrate for the desktop team ( less work, problem being fixed where it arguably should be as opposed to systemd,grub and gnome for his feature to work and more future proof work for the desktop team). Could help further adapt UEFI and secure boot which the industry is moving towards which helps keep Fedora moving along with it. If correctly implemented ( baby steps and without excluding anyone) should be a win win for Fedora, developers and end users alike. Grub discourages users who have tried sd-boot from coming/returning to Fedora [1]. Bottom line I think this will be a good move for the distribution and a good time to start looking into and make that move. JBG 1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Fedora-packaging] Re: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
Le mardi 30 juin 2020 à 21:33 +0200, Igor Raits a écrit :
> On Tue, 2020-06-30 at 15:19 -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping
> >
> > The change will make those packages auto-bump and auto-changelog at
> > the rpm level, in an infrastructure-independent way.
>
> So how exactly is this supposed to work? From where will it get old
> changelog, how packagers will migrate to this, how does it affect
> reproducibility?
The changelog is just one file in SRPM sources, and bumping is done
from last build state which is just one key = value file in sources
(storing the evr components, the last built time, and last build
packager id).
In reproducible mode last evr and packager id and build time are
applied without bumping. You need to set
%reproducible_build = true (or anything except false) in your
~/.rpmmacros (or config_opts['macros'], or as rpmbuild --define flags).
The auto framework (and %new_package) split Release in separate
%{source_release} %{dist} and %{post_release} components, which makes
the implementation way easier than multiplexing things in a single
Release tag and trying to untangle the mess later.
A production implementation would probably split %{dist} in %{distcore}
and %{distprefix} (the .gitdatehash things we stuff in Releases and in
rpm changelogs as opposed to the fcX part we want to appear in Release
but not in changelogs). I know where the offending code is in fedora-
release and the split up is trivial to implement, but there’s no point
in worrying about this level of detail before the core of the feature
is approved (or not).
The implementation is really simple and easy, it took me two days to
write and test it because it reuses all the building blocks I had
already done for my other change (without those jungling all the bits
involved at various points of the spec file would have been challenging
to say the least).
>
> So are you asking mock and koji people to implement something? Did
> you
> talk to them before submitting this proposal?
>
> > * Mock issue:
> > https://github.com/rpm-software-management/mock/issues/599
I filled the mock issue to inform them. Again, this is a feature that
took me two days to code (it did not exist, even in thought, last
saturday). I was actually surprised at how easy it was to implement,
given the months if was discussed on this list.
At the mock level, there are two issues.
The main one (and only critical one) is that bumping MUST occur when
%build is executed, because a spectool or rpmbuild -bs is not a build
event, only a full build is. That means the SRPM produced by
rpmbuild -bs
is not the bumped SRPM, only the SRPM produced by
rpmbuild -ba
is bumped. My (imperfect) understanding of the mock issue is that mock
serves the first, not the second one at the end of the build process.
The second issue is that bumping changelog requires filling a builder
name and mail in the changelog line, and mock provides not easy way to
pass those to the build process.
If those two problems are lifted I see no special problem copr side
(except using the new mock plumbing to pass builder iname & mail to
mock).
For koji/fedpkg things are a bit more challenging because you will want
to back-commit the bumping to git once a build succeeds. Which is the
main point clime and me disagreed earlier on this year. Though, it is
not a show-stopper initially, a packager can back-commit manually if he
wants the bump recorded till tooling catches up.
While that adds constrains on the koji/git interface, that gives you a
bumping mecanism totally generic and independant of the build infra,
that does not rely on external python/ruby/whatever scripts to bum, and
does not require messing with someone else’s spec just to trace and
bump a rebuild.
Just importing an srpm from one system to another will preserve the
bumping state without any data loss.
> >
> > == Contingency Plan ==
> >
> > There is no contingency plan because the change will happen or not
> > at all.
>
> This is not true. If it will happen but then something will be
> entirely broken we need to revert it.
Thank you for your vote of confidence. I hope you realise that by that
yardstick, nothing would be accepted, including your own changes,
because something may always happen someday causing someone to revisit
something. And, the last time a problem occurred, it was traced to an
undocumented and unannounced rpm change that no one knew how to fix
rpm-side, and that you spent more energy proving it need not be fixed
than on constructive solution-finding.
I freely admit that my code sucks and is way worse than the perfect
code no one has written yet nor intends to write any day soon.
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr wrote: > > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote: > > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro > > wrote: > > > > > > > > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > > > wrote: > > > > > > > For the record, as this directly affects the Workstation deliverable, > > > > I will be voting -1 until and unless the Workstation WG votes in > > > > favor. > > > > > > > > > > > > > > > > Yes, it's a large set of Change owners, but since only two of them are > > > > Workstation WG members, they are not representative of that group. > > > > > > > > > > > > Workstation WG hat on: > > > > > > > > > > > > I don't think there's any need to vote -1 for that reason alone. The > > > Workstation WG has discussed the change proposal at several meetings > > > recently (really, we've spent a long time on this), and frankly we were > > > not making a ton of progress towards reaching a decision either way, so > > > going forward with the change proposal and moving the discussion to > > > devel@ to get feedback from a wider audience and from FESCo seemed like > > > a good idea. Most likely, we'll wind up doing whatever FESCo chooses > > > here, but unless FESCo were to explicitly indicate intent to override > > > the Workstation WG, we would not consider a FESCo decision to limit > > > what the Workstation WG can do with the Workstation product. At least, > > > my understanding of the power structure FESCo has established is that > > > the WG can make product-specific decisions that differ from FESCo's > > > decisions whenever we want, unless FESCo says otherwise (because FESCo > > > always has final say). That is, if FESCo were to approve btrfs by > > > default, but Workstation WG were to vote to stick with ext4, then we > > > would stick with ext4 unless FESCo were to say "no really, you need to > > > switch to btfs" (which I highly doubt would happen). So I don't see any > > > reason to vote -1 here out of concern for overriding the WG. > > > > > > > > > > > > The problem is that the request as discussed reads as "FESCo says use > > it for workstation" vs "FESCo has no problem with Workstation saying > > they want btrfs" or "FESCo says use btrfs as default". Yes it says > > "desktop variants" but only 1 variant really counts and that is > > Workstation. So yes, either Workstation agrees to it or it isn't > > getting voted on. If Workstation can't come to an agreement on it, > > then the proposal is dead. Anything else is an end-run and a useless > > trolling of people to see how many rants LWN counts in its weekly > > messages. > > Well, it's not only Workstation that this proposal is trying to throw btrfs > on, but the other desktops as well, such as KDE Spin. How is that even a thing? Shouldn't a spin maintainer be responsible for choosing the defaults of their spin? This proposal seems fairly absurd in the regard of dictating what other people should do. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-reportlab: undefined-non-weak-symbol
On Tue, Jun 30, 2020 at 11:45 AM Antonio T. sagitter wrote: > Are these `undefined-non-weak-symbol` expected in python-reportlab? > > https://pastebin.com/dRZUbpJx Yes, see this thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IAIUO5XU54FQM64TDXWF4YMHHWGQFNXT/#TT2PQ7UAJDHYUEKBJAQKKCR43FMKOJRH -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 30.6.2020 18:32, John M. Harris Jr wrote: On Tuesday, June 30, 2020 11:29:13 AM MST Jóhann B. Guðmundsson wrote: On 30.6.2020 17:49, John M. Harris Jr wrote: On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been available on any common intel based x86 platform since atleast 2005. This is simply false. I'm currently writing this email on a ThinkPad X200 Tablet, which does not support UEFI. I can get dropping x86 support, but dropping BIOS boot support? Such proposal would never be about stop supporting older hardware that's just a misconception people are getting And it's quite evident by the response here that hw that is atleast 2010 and older is still quite happily being used and that hw does not support UEFI and no one is talking about taking that away anytime soon. The first step ( The actual change proposal ) would simply be about replace grub2 with sd-boot for UEFI strictly on the x86 architecture which has UEFI available and enabled ( is not using legacy bios ) and see what issue are encountered, solve those then consider moving to different architectures and further integration if relevant etc. ( baby steps ) Next I would suggest looking at UEFI supported ARM systems ( but I personally would have to obtain such hardware before doing so ). JBG Why do you prefer sd-boot over GRUB2? I don't understand how you'd boot from an SD card on most x86 hardware. ;) Jokes aside, what's the call for the preference of even more systemd bloat? Do we not have enough yet? sd-boot is already installed on end users system, is light weight compared to Grub ( sd-boot only supports uefi,smaller code size, easier to maintain ). It already integrates with the service management framework (systemd). More user friendly than Grub ( has lilo like interface easier to change kernel entry, which goes nicely with the default editor change ) Gnome related changes such as Hans is proposing might be easier to integrate for the desktop team ( less work, problem being fixed where it arguably should be as opposed to systemd,grub and gnome for his feature to work and more future proof work for the desktop team). Could help further adapt UEFI and secure boot which the industry is moving towards which helps keep Fedora moving along with it. If correctly implemented ( baby steps and without excluding anyone) should be a win win for Fedora, developers and end users alike. Grub discourages users who have tried sd-boot from coming/returning to Fedora [1]. Bottom line I think this will be a good move for the distribution and a good time to start looking into and make that move. JBG 1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, Jun 30, 2020 at 3:41 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 30.06.2020 19:43, Hans de Goede wrote: > > That is the first time I have heard that. Do you have a source for that ? > > https://github.com/intel/dptfxtract - no sources, only proprietary > binaries. > > The legal status of the extracted tables was discussed a few months ago > with members of the Fedora legal team. You can check archives. > Regardless of the legality of tables output from dptfxtract, that doesn't really address the fact that thermald, as is in Fedora 32 today (version 1.9.1 from December) doesn't have dptfxtract (nor do later versions bundle it) and results in an improvement in thermal behavior on supported systems without any thermal tables in /etc/thermald. -- 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 Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 30.6.2020 18:45, Reindl Harald (privat) wrote: Am 30.06.20 um 20:29 schrieb Jóhann B. Guðmundsson: On 30.6.2020 17:49, John M. Harris Jr wrote: On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been available on any common intel based x86 platform since atleast 2005. This is simply false. I'm currently writing this email on a ThinkPad X200 Tablet, which does not support UEFI. I can get dropping x86 support, but dropping BIOS boot support? Such proposal would never be about stop supporting older hardware that's just a misconception people are getting And it's quite evident by the response here that hw that is atleast 2010 and older is still quite happily being used and that hw does not support UEFI and no one is talking about taking that away anytime soon you are the one talking about "why Fedora should still continue to support legacy BIOS boot as opposed to stop supporting it and potentially drop grub2 and use sd-boot instead" sd-boot requires the kernel and initrd on FAT32 - creep away until you realized about grub2 even support UEFI if someoen with a @redhat.com email would have come up with your inital mail you would have cried fire and conspirancy to be honest: what is worjng with you? I was in contact with Hans who is a Red Hat employee and the owner of the change proposal whom I reference in my original post to the list privately prior to me posting my question to the list in which he himself encourage me to go ahead and propose Fedora x86 UEFI installs to sd-boot if I was up for it along with another Red Hat employee who was relevant to our discussion so I have no idea what you are referring to. to be clear: if you again refelct a private message on a public forum i will seek you and i will find you - if you want sue me, but in private! The best way to deal with individuals like you who are threatening people behind the scene, is exposing them, something that I should have done when I managed the sysv to systemd feature in Fedora and ask again like I did last time you how many mails like this do you send privately to persons inside and outside of the Fedora community everyday? That said I first and foremost suggest you seek help and familiarize yourself with Fedora's code of conduct [1] and strongly encourage the entity within the Fedora community to take a close look at this. JBG 1. https://docs.fedoraproject.org/en-US/project/code-of-conduct/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: IBus 1.5.23 - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 15:20 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/IBus_1.5.23 > > == Summary == > IBus 1.5.23 will replace the allowlist of XKB engines with the > blocklist of XKB ones. > > == Owner == > * Name: [[User:Fujiwara| Takao Fujiwara]] > * Email: fujiwara [at] redhat [dot] com > > == Detailed Description == > IBus currently provides the allowlist of XKB engines in > `/usr/share/ibus/component/simple.xml` and `ibus-setup` utility can > show the XKB engines indicated in only that file in most desktops. > (gnome-control-center shows XKB list from gnome-desktop3 in GNOME > desktop instead.) The allowlist includes the limited XKB layouts and > variants. E.g. 'gb(dvorak)' is included but 'gb' is not. And the > allowlist has been supported to customize by sysadmin localy since > the > simple.xml is a simple text file and the default list has been > updated > upon the request. > > IBus 1.5.23 will replace the allowlist with the blocklist which > includes the disabled XKB engines and `ibus-setup` will shows all the > XKB engines which are '''not''' indicated in that file. The > blocklist > will includes 'cn' layout, 'cn' layout + any variants, 'nec_vndr/jp' > layouts at the moment. > > I.e. the change won't effect GNOME desktop. So I do not fully understand this change. Is it actually breaking something or not? If so, I am surprised it happens when bumping micro version (.23). If not, does it have to be System-Wide change? > == Benefit to Fedora == > The users don't have to request the desired XKB layouts and variants > in IBus upstream and most XKB keymaps will be shown in ibus-setup. > > == Scope == > * Proposal owners: > * Other developers: N/A > * Release engineering: [https://pagure.io/releng/issue/9563 #9563] > * Policies and guidelines: N/A > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > If a keymap is shown in ibus-setup in the previous version, it will > be > shown in the new one. > > == How To Test == > # Log into XFCE desktop > # Run ibus-setup > > It will show 'English (UK)' keymap by default. > > == User Experience == > If a user customize `/usr/share/ibus/component/simple.xml` in the > previous version, the file will be replaced with new one. I think it is pretty much expected that if you modify something in /usr, it will be overriden by an update, no? > == Dependencies == > The change effects XKB engines only but does not input method engines > (E.g. libpinyin, hangul, and so on.) > > == Contingency Plan == > * Contingency mechanism: Drop the feature in Fedora 33 and postpone > it > to Fedora 34 > * Contingency deadline: Beta freeze > * Blocks release? No > > == Documentation == > TBD > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77lt4ACgkQEV1auJxc Hh7vKA//VigWO3Dx/Aj52Nb1zVUY6CluDKLwaYEJ1c3j6LYwNhH6LVYMLQUPRlw2 gNUHe5n7k2C1kiFP2s1+u/MEQXGxZwjzGgPxwVLNl9bOFfk8HnXrwHuTquucDC3T 0amg4G0x3LynbhCrzrzBxfOSy/GnlElUGKY66izaTMPnsHtGjrmHzb0eCOsaIYvl D4TxBJ7pTqJh6XG41UFHsyT82yuMAwjeS8mow7XsQY3a29wWN7A9cxyNBpv0Uhtb rXbN9ti5pk3qmc+XjSbbqNvS3ufVAOLGv9FOXmkOG3iY0uhSjLJXkSPesDkJdzYp EQR+W5nmFFsUEKKFUb4fwTJ5TEz1OjNtUYW09Ahuqq5S6xJv6IA7rMPkU05rxeMM Qac7q3LJ+cQM0vk9HKVIDfXmqX47tqCNpcrC5uDLb6MwBGvz7A9WJWdu71shuTAi Bmya4/yISh7C/5+pfpO4y2h+z7RYiA2visNdp3oYRWQ7o+8SMUjPHGzyIvX3TcF5 pZlmKrYsoyEiltyMoyhJTosOZ+wWpMhZQhjVNT3vq3nUYnSe3xAX7aGUoIF750O9 HOvjyDcpptCMjVr/b2pcQt7usLG+ISzta8LxZkm38RkFGSG3aewRTJGSTK+K7XQQ iUCRYGKePePPxtYZwNT212Hft1vBaN7hGzA7P3oXdYOblWuk9w4= =9bCf -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Tue, 30 Jun 2020 at 21:24, Robert-André Mauchin wrote: > > May I suggest another option? > I provide a package for Micro, an editor written in Go with a discoverable > interface. https://micro-editor.github.io/ > > It is compiled as a static binary of 4.6 MB with no dependency. Probably > bigger than nano, but it's nicer overall, with mouse support and syntax > highlighting. I didn't know it. I've just tried it and absolutely loved it. +1 to this suggestion. -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Fedora-packaging] Patches in Forge macros - Auto macros - Detached rpm changelogs - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-30 at 15:19 -0400, Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
>
> == Summary ==
>
> redhat-rpm-config will be updated to add patching support to forge
> macros, a plug-able framework to register macros to execute in
> specific sections, and rpm changelogs in detached files.
>
> == Owner ==
> * Name: [[User:nim| Nicolas Mailhot]]
> * Email:
>
> == Detailed Description ==
>
> This is a system-wide change because all packages build with
> redhat-rpm-config, but it only concerns packages that opted to use
> this part of redhat-rpm-config (users of forge, fonts and go macros).
>
> It was driven first, by the need to make the underlying macro
> infrastructure robust enough to package Go modules, and second, by an
> unfortunate rpm 4.15 regression that proved it was foolish to depend
> on rpmbuild to parse Tags in anything except canonical order.
I think this would be already at least 30 times we mentioned that RPM
works as expected and the bug was just in the spec files that relied on
Name being parsed before expanding ~/.rpmmacros.
> === Forge ===
>
> * forge macro now process patches, including in multi-source spec
> files, in a natural way
> * all dependencies on source/patch numbering were eradicated, you can
> write a whole multi-source/multi-patch spec without worrying about
> source or patch numbers
> * zero suffix is no longer special (à la Source/Source0 way), you can
> declare forge blocks starting at 42 if that‘s your preference
>
> === Fully automated packaging ===
>
> A framework was added so macro subsystems can register execution
> blocks in specific parts or the spec file. Execution blocks are
> orchestrated (using KISS rules) so for example the forge part of
> %prep
> is executed before the go parts that depend on forge archives being
> unpacked and patched, and macros that want to create srpm headers are
> executed before macros that want to create subpackage headers.
RPM upstream is working on generated subpackages, how does it play with
this black magic?
> Such a framework is a requirement to control the generation order
> within the spec file and make sure rpm maintainers are not cross with
> you.
>
> That means a spec with no special custom processing is reduced to a
> set of %global control variables that activate specific execution
> blocks, and everything bellow those control variable is short and
> unchanging boilerplate.
So essentially you are saying that we should not use RPM preamble. Did
you talk to upstream about this idea?
> A packager that needs custom processing can add custom code above or
> bellow the various `%auto_foo` calls, and check with `rpmspec -P`
> that
> the result does what he wants it to do. For obvious reliability
> reasons injecting custom code in the middle of an `%auto_foo`
> sequence
> is not allowed.
What about rpmdev-bumpspec, vim plugin and such tools adoption that
expect Version/Release/%changelog to be present in spec?
>
> %global source_name …
> %global source_release …
> %global source_post_release …
>
> %global forge_url0 …
> %global forge_commit0 …
>
> %global forge_url1 …
> %global forge_tag1 …
>
> %global go_module33 …
> %global go_description33 …
>
> %global font_family22 …
> %global font_conf22 …
>
> %auto_init
> %auto_pkg
>
> %sourcelist
> %auto_sources
>
> %patchlist
> %auto_patches
>
> %prep
> %auto_prep
>
> %generate_buildrequires
> %auto_generate_buildrequires
>
> %build
> %auto_build
>
> %install
> %auto_install
>
> %check
> %auto_check
>
> %auto_files
>
> %changelog
> %auto_changelog
>
>
> === Detached changelogs ===
>
> This framework was used to implement detached rpm changelogs in a
> reliable way.
>
> === Generic -doc creation ===
>
> This framework was used to implement automated -doc subpackage
> creation, because creating them by hand gets annoying after the nth
> upstream that wants you do distribute heavy PDF documentation files.
>
> === Huge refactoring and fleshing out of the lua library ===
>
> Writing high-level features like the above required defining a
> library
> of lua routines like an expand that expands fully, an unset that
> actually undefines, a read that tells you if a variable exists or is
> set to "", a `fedora.echo()` wrapper around
> `rpm.expand("%{echo:%{expand:" .. text .. "}}")`, etc. Those are now
> available for others to use should they want to.
>
> My coding skills are not up to navigating the upstream low level rpm
> lua API without blowing up on the landmines it is littered with.
> Therefore, I abstracted landmine avoidance in a single place.
>
> === Drawbacks ===
>
> Nothing is free, and a higher level of automation required using
> rigid
> naming for control variables. Because software is a lot less tolerant
> of fuzzy naming than human beings.
>
> So, all forge control variables are renamed, fonts control
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On 30.06.2020 19:43, Hans de Goede wrote: > That is the first time I have heard that. Do you have a source for that ? https://github.com/intel/dptfxtract - no sources, only proprietary binaries. The legal status of the extracted tables was discussed a few months ago with members of the Fedora legal team. You can check archives. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/SID > > == Summary == > Introduce Storage Instantiation Daemon (SID) that aims to provide a > central event-driven engine to write modules for identifying specific > Linux storage devices, their dependencies, collecting information and > state tracking while > being aware of device groups forming layers and layers forming whole > stacks or simply creating custom groups of enumerated devices. SID > will provide mechanisms to retrieve and query collected information > and a possibility to bind predefined or custom triggers with actions > for each group. > > == Owner == > * Name: [[User:prajnoha | Peter Rajnoha]] > * Email: prajn...@redhat.com > > == Detailed Description == > Over the years, various storage subsystems have been installing hooks > within udev rules and calling out numerous external commands for them > to be able to react on events like device presence, removal or a > change in general. However, this approach ended up with very complex > rules that are hard to maintain and debug if we are considering > storage setups where we build layers consisting of several underlying > devices (horizontal scope) and where we can stack one layer on top of > another (vertical scope), building up diverse storage stacks where we > also need to track progression of states either at device level or > group level. > > SID extends udevd functionality here in a way that it incorporates a > notion of device grouping directly in its core which helps with > tracking devices in storage subsystems like LVM, multipath, MD... > Also, it provides its own database where records are separated into > per-device, per-module, global or udev namespace. The udev namespace > keeps per-device records that are imported and/or exported to/from > udev environment and this is used as compatible communication channel > with udevd. The records can be marked with restriction flags that aid > record separation and it prevents other modules to read, write or > create a record with the same key, hence making sure that only a > single module can create the records with certain keys (reserving a > key). > > Currently, SID project provides a companion command called 'usid' > which is used for communication between udev and SID itself. After > calling the usid command in a udev rule, device processing is > transferred to SID and SID strictly separates the processing into > discrete phases (device identificaton, pre-scan, device scan, > post-scan). Within these phases, it is possible to decide whether the > next phase is executed and it is possible to schedule delayed actions > or set records in the database that can fire triggers with associated > actions or records which are then exported to udev environment > (mainly > for backwards compatibility and for other udev rules to have a chance > to react). The scheduled actions and triggers are executed out of > udev > context and hence not delaying the udev processing itself and > improving issues with udev timeouts where unnecessary work is done. > > A module writer can hook into the processing phases and use SID's API > to access the database as well as set the triggers with actions or > schedule separate actions and mark devices as ready or not for use in > next layers. The database can be used within any phase to retrieve > and > store key-value records (where value could be any binary value in > general) and the records can be marked as transient (only available > during processing phases for current event) or persistent so they can > be accessed while processing subsequent events. > > == Benefit to Fedora == > The main benefit is all about centralizing the solution to solve > issues that storage subsystem maintainers have been hitting with > udev, > that is: > > * providing a central infrastructure for storage event processing, > currently targeted at udev events > > * improving the way storage events and their sequences are recognized > and for which complex udev rules were applied before > > * single notion of device readiness shared among various storage > subsystems (single API to set the state instead of setting various > variables by different subsystems) > > * providing more enhanced possibilities to store and retrieve > storage-device-related records when compared to udev database > > * direct support for generic device grouping (matching > subsystem-related groups like LVM, multipath, MD... or creating > arbitrary groups of devices) > > * centralized solution for scheduling triggers with associated > actions > defined on groups of storage devices > > * adding a centralized solution for delayed actions on storage > devices > and groups of devices (avoiding unnecessary work done within udev > context and hence avoiding frequent udev timeouts when processing > events for such devices) Is this purely about adding some package into
Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 15:19 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping > > == Summary == > > redhat-rpm-config will be updated so users of the auto framework get > automated release and changelog bumping. > > == Owner == > > * Name: [[User:nim| Nicolas Mailhot]] > * Email: > > == Detailed Description == > > This is a system-wide change because all packages build with > redhat-rpm-config, but it only concerns packages that opted to use > this part of redhat-rpm-config (auto framework). > > The change will make those packages auto-bump and auto-changelog at > the rpm level, in an infrastructure-independent way. So how exactly is this supposed to work? From where will it get old changelog, how packagers will migrate to this, how does it affect reproducibility? > == Benefit to Fedora == > > Autobumping removes a huge packager shore and makes timestamping in > changelogs more reliable. > > == Scope == > * Proposal owners: The feature is coded and works at the rpm level. > Unfortunately, mock filters away the srpms containing the bump state, > so it does not work in upper layers. > > * Other developers: The feature requires buy-in by mock developers > (and probably koji developers) to lift the restrictions that block it > above the rpm level. Also, it requires a mechanism to pass the user > name and email that will be used in bumped changelogs (defining two > variables in ~/.rpmmacros is sufficient at rpm level) So are you asking mock and koji people to implement something? Did you talk to them before submitting this proposal? > * Mock issue: > https://github.com/rpm-software-management/mock/issues/599 > > * Release engineering: https://pagure.io/releng/issue/9567 > * Policies and guidelines: maybe eventually if things work out on the > technical level > * FPC issue: https://pagure.io/packaging-committee/issue/998 > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > > This is a pure build tooling update, it changes how things are built > not what is built. > > == How To Test == > > A redhat-rpm-config packages with the changes and some example > packages are available in > > https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/ > > Since the mock/copr layer is currently blocking the feature, you need > to install the redhat-rpm-config and forge macro packages available > in > this repo locally. Afterwards you can take any of the example > packages > in the repo and rebuild them with rpmbuild -ba to your heart content, > and see the releases bump and the changelogs being updated > accordingly. > > To get beautiful changelogs, you also need to add > > > %buildsys_name Your name > %buildsys_email Your email > > > in ~/.rpmmacros > > == User Experience == > > N/A Packager experience change only > > == Dependencies == > > The change is a spin-off of > > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > Therefore, it depends on the success of that other change and will > probably need rebasing if the code in this other change evolves > during > the redhat-rpm-config merge. > > It also depends on mock / copr/ koji buy-in and changes, that may add > their own requirements. > > == Contingency Plan == > > There is no contingency plan because the change will happen or not at > all. This is not true. If it will happen but then something will be entirely broken we need to revert it.. And we need to know when, how and who will do that. > == Documentation == > > There is as much documentation as the average redhat-rpm-config > change > (ie comments in the macro files themselves) > > == Release Notes == > > N/A Packager productivity change only > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > packaging mailing list -- packag...@lists.fedoraproject.org > To unsubscribe send an email to > packaging-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77k5MACgkQEV1auJxc Hh5U4xAAq12qjd3UImlWtshF6wil2f7DnC92TcoKifzWFNm2/FJGZw5RfvFJwy0n 6xFcyF+E8mtGLDG0l5xVi4lxfxkyErAiIzmBxZWc17h3G3gL6PeSBCgJRURJSh/e 1bXtOJb847bRfjbcMjoPKIc6Gcl+kA6C+kLr4QpTV7GDeHdEbeYX/xjGVTr6RbeN ZxBBM7h0Cvwj8LIN6uXJsJKVz92lalElyY4GYHAUuNyCNztdxARB93sNT4MdbbJ4 gsVHAFiep6g3A7HflaBgTsRelvbpmmdIj1XC3SSwrw3eD4nZ5c+ET0F/M2nv2hVx
Patches in Forge macros - Auto macros - Detached rpm changelogs - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
== Summary ==
redhat-rpm-config will be updated to add patching support to forge
macros, a plug-able framework to register macros to execute in
specific sections, and rpm changelogs in detached files.
== Owner ==
* Name: [[User:nim| Nicolas Mailhot]]
* Email:
== Detailed Description ==
This is a system-wide change because all packages build with
redhat-rpm-config, but it only concerns packages that opted to use
this part of redhat-rpm-config (users of forge, fonts and go macros).
It was driven first, by the need to make the underlying macro
infrastructure robust enough to package Go modules, and second, by an
unfortunate rpm 4.15 regression that proved it was foolish to depend
on rpmbuild to parse Tags in anything except canonical order.
=== Forge ===
* forge macro now process patches, including in multi-source spec
files, in a natural way
* all dependencies on source/patch numbering were eradicated, you can
write a whole multi-source/multi-patch spec without worrying about
source or patch numbers
* zero suffix is no longer special (à la Source/Source0 way), you can
declare forge blocks starting at 42 if that‘s your preference
=== Fully automated packaging ===
A framework was added so macro subsystems can register execution
blocks in specific parts or the spec file. Execution blocks are
orchestrated (using KISS rules) so for example the forge part of %prep
is executed before the go parts that depend on forge archives being
unpacked and patched, and macros that want to create srpm headers are
executed before macros that want to create subpackage headers.
Such a framework is a requirement to control the generation order
within the spec file and make sure rpm maintainers are not cross with
you.
That means a spec with no special custom processing is reduced to a
set of %global control variables that activate specific execution
blocks, and everything bellow those control variable is short and
unchanging boilerplate.
A packager that needs custom processing can add custom code above or
bellow the various `%auto_foo` calls, and check with `rpmspec -P` that
the result does what he wants it to do. For obvious reliability
reasons injecting custom code in the middle of an `%auto_foo` sequence
is not allowed.
%global source_name …
%global source_release …
%global source_post_release …
%global forge_url0 …
%global forge_commit0 …
%global forge_url1 …
%global forge_tag1 …
%global go_module33 …
%global go_description33 …
%global font_family22 …
%global font_conf22 …
%auto_init
%auto_pkg
%sourcelist
%auto_sources
%patchlist
%auto_patches
%prep
%auto_prep
%generate_buildrequires
%auto_generate_buildrequires
%build
%auto_build
%install
%auto_install
%check
%auto_check
%auto_files
%changelog
%auto_changelog
=== Detached changelogs ===
This framework was used to implement detached rpm changelogs in a reliable way.
=== Generic -doc creation ===
This framework was used to implement automated -doc subpackage
creation, because creating them by hand gets annoying after the nth
upstream that wants you do distribute heavy PDF documentation files.
=== Huge refactoring and fleshing out of the lua library ===
Writing high-level features like the above required defining a library
of lua routines like an expand that expands fully, an unset that
actually undefines, a read that tells you if a variable exists or is
set to "", a `fedora.echo()` wrapper around
`rpm.expand("%{echo:%{expand:" .. text .. "}}")`, etc. Those are now
available for others to use should they want to.
My coding skills are not up to navigating the upstream low level rpm
lua API without blowing up on the landmines it is littered with.
Therefore, I abstracted landmine avoidance in a single place.
=== Drawbacks ===
Nothing is free, and a higher level of automation required using rigid
naming for control variables. Because software is a lot less tolerant
of fuzzy naming than human beings.
So, all forge control variables are renamed, fonts control variables
have been renamed too, and go control variables will need renaming (in
that last case, that’s not a problem because moving to go modules
requires reworking variables anyway, so it will be done as part of the
module effort in F34).
To ease the transition a compatibility layer was added to forge macros
so old variables and new variables are aliased both ways (this will
eventually go away because it’s quite a lot of compatibility code to
maintain). Mixing syntaxes (old and new) is not supported, you need to
convert your spec file to new forge variables or not at all (if not at
all, do not try to use new features like patching).
== Benefit to Fedora ==
Spec files that do more with less manual expensive to maintain spec code.
Without this productivity win, complex efforts like converting Fedora
Go packages to Go modules, or draining the Font packages swamp given
that legacy
IBus 1.5.23 - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/IBus_1.5.23 == Summary == IBus 1.5.23 will replace the allowlist of XKB engines with the blocklist of XKB ones. == Owner == * Name: [[User:Fujiwara| Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == IBus currently provides the allowlist of XKB engines in `/usr/share/ibus/component/simple.xml` and `ibus-setup` utility can show the XKB engines indicated in only that file in most desktops. (gnome-control-center shows XKB list from gnome-desktop3 in GNOME desktop instead.) The allowlist includes the limited XKB layouts and variants. E.g. 'gb(dvorak)' is included but 'gb' is not. And the allowlist has been supported to customize by sysadmin localy since the simple.xml is a simple text file and the default list has been updated upon the request. IBus 1.5.23 will replace the allowlist with the blocklist which includes the disabled XKB engines and `ibus-setup` will shows all the XKB engines which are '''not''' indicated in that file. The blocklist will includes 'cn' layout, 'cn' layout + any variants, 'nec_vndr/jp' layouts at the moment. I.e. the change won't effect GNOME desktop. == Benefit to Fedora == The users don't have to request the desired XKB layouts and variants in IBus upstream and most XKB keymaps will be shown in ibus-setup. == Scope == * Proposal owners: * Other developers: N/A * Release engineering: [https://pagure.io/releng/issue/9563 #9563] * Policies and guidelines: N/A * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == If a keymap is shown in ibus-setup in the previous version, it will be shown in the new one. == How To Test == # Log into XFCE desktop # Run ibus-setup It will show 'English (UK)' keymap by default. == User Experience == If a user customize `/usr/share/ibus/component/simple.xml` in the previous version, the file will be replaced with new one. == Dependencies == The change effects XKB engines only but does not input method engines (E.g. libpinyin, hangul, and so on.) == Contingency Plan == * Contingency mechanism: Drop the feature in Fedora 33 and postpone it to Fedora 34 * Contingency deadline: Beta freeze * Blocks release? No == Documentation == TBD -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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
RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping == Summary == redhat-rpm-config will be updated so users of the auto framework get automated release and changelog bumping. == Owner == * Name: [[User:nim| Nicolas Mailhot]] * Email: == Detailed Description == This is a system-wide change because all packages build with redhat-rpm-config, but it only concerns packages that opted to use this part of redhat-rpm-config (auto framework). The change will make those packages auto-bump and auto-changelog at the rpm level, in an infrastructure-independent way. == Benefit to Fedora == Autobumping removes a huge packager shore and makes timestamping in changelogs more reliable. == Scope == * Proposal owners: The feature is coded and works at the rpm level. Unfortunately, mock filters away the srpms containing the bump state, so it does not work in upper layers. * Other developers: The feature requires buy-in by mock developers (and probably koji developers) to lift the restrictions that block it above the rpm level. Also, it requires a mechanism to pass the user name and email that will be used in bumped changelogs (defining two variables in ~/.rpmmacros is sufficient at rpm level) * Mock issue: https://github.com/rpm-software-management/mock/issues/599 * Release engineering: https://pagure.io/releng/issue/9567 * Policies and guidelines: maybe eventually if things work out on the technical level * FPC issue: https://pagure.io/packaging-committee/issue/998 * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This is a pure build tooling update, it changes how things are built not what is built. == How To Test == A redhat-rpm-config packages with the changes and some example packages are available in https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/ Since the mock/copr layer is currently blocking the feature, you need to install the redhat-rpm-config and forge macro packages available in this repo locally. Afterwards you can take any of the example packages in the repo and rebuild them with rpmbuild -ba to your heart content, and see the releases bump and the changelogs being updated accordingly. To get beautiful changelogs, you also need to add %buildsys_name Your name %buildsys_email Your email in ~/.rpmmacros == User Experience == N/A Packager experience change only == Dependencies == The change is a spin-off of https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs Therefore, it depends on the success of that other change and will probably need rebasing if the code in this other change evolves during the redhat-rpm-config merge. It also depends on mock / copr/ koji buy-in and changes, that may add their own requirements. == Contingency Plan == There is no contingency plan because the change will happen or not at all. == Documentation == There is as much documentation as the average redhat-rpm-config change (ie comments in the macro files themselves) == Release Notes == N/A Packager productivity change only -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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: The future of legacy BIOS support in Fedora.
Jóhann B. Guðmundsson writes: > On 30.6.2020 17:49, John M. Harris Jr wrote: >> On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote: >>> Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes >>> it beg the question if now would not be the time to stop supporting >>> booting in legacy bios mode and move to uefi only supported boot which >>> has been available on any common intel based x86 platform since atleast >>> 2005. >> This is simply false. I'm currently writing this email on a ThinkPad X200 >> Tablet, which does not support UEFI. I can get dropping x86 support, but >> dropping BIOS boot support? >> > Such proposal would never be about stop supporting older hardware that's > just a misconception people are getting > > And it's quite evident by the response here that hw that is atleast 2010 > and older is still quite happily being used and that hw does not support > UEFI and no one is talking about taking that away anytime soon. > > The first step ( The actual change proposal ) would simply be about > replace grub2 with sd-boot for UEFI strictly on the x86 architecture > which has UEFI available and enabled ( is not using legacy bios ) and > see what issue are encountered, solve those then consider moving to > different architectures and further integration if relevant etc. ( > baby steps ) Next I would suggest looking at UEFI supported ARM > systems ( but I personally would have to obtain such hardware before > doing so ). But... why? It's not like grub2 doesn't work for booting UEFI. Doesn't seem like there's a point in running through all the issues that grub2 already solved again. Thanks, --Robbie 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
RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping == Summary == redhat-rpm-config will be updated so users of the auto framework get automated release and changelog bumping. == Owner == * Name: [[User:nim| Nicolas Mailhot]] * Email: == Detailed Description == This is a system-wide change because all packages build with redhat-rpm-config, but it only concerns packages that opted to use this part of redhat-rpm-config (auto framework). The change will make those packages auto-bump and auto-changelog at the rpm level, in an infrastructure-independent way. == Benefit to Fedora == Autobumping removes a huge packager shore and makes timestamping in changelogs more reliable. == Scope == * Proposal owners: The feature is coded and works at the rpm level. Unfortunately, mock filters away the srpms containing the bump state, so it does not work in upper layers. * Other developers: The feature requires buy-in by mock developers (and probably koji developers) to lift the restrictions that block it above the rpm level. Also, it requires a mechanism to pass the user name and email that will be used in bumped changelogs (defining two variables in ~/.rpmmacros is sufficient at rpm level) * Mock issue: https://github.com/rpm-software-management/mock/issues/599 * Release engineering: https://pagure.io/releng/issue/9567 * Policies and guidelines: maybe eventually if things work out on the technical level * FPC issue: https://pagure.io/packaging-committee/issue/998 * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This is a pure build tooling update, it changes how things are built not what is built. == How To Test == A redhat-rpm-config packages with the changes and some example packages are available in https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/ Since the mock/copr layer is currently blocking the feature, you need to install the redhat-rpm-config and forge macro packages available in this repo locally. Afterwards you can take any of the example packages in the repo and rebuild them with rpmbuild -ba to your heart content, and see the releases bump and the changelogs being updated accordingly. To get beautiful changelogs, you also need to add %buildsys_name Your name %buildsys_email Your email in ~/.rpmmacros == User Experience == N/A Packager experience change only == Dependencies == The change is a spin-off of https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs Therefore, it depends on the success of that other change and will probably need rebasing if the code in this other change evolves during the redhat-rpm-config merge. It also depends on mock / copr/ koji buy-in and changes, that may add their own requirements. == Contingency Plan == There is no contingency plan because the change will happen or not at all. == Documentation == There is as much documentation as the average redhat-rpm-config change (ie comments in the macro files themselves) == Release Notes == N/A Packager productivity change only -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
IBus 1.5.23 - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/IBus_1.5.23 == Summary == IBus 1.5.23 will replace the allowlist of XKB engines with the blocklist of XKB ones. == Owner == * Name: [[User:Fujiwara| Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == IBus currently provides the allowlist of XKB engines in `/usr/share/ibus/component/simple.xml` and `ibus-setup` utility can show the XKB engines indicated in only that file in most desktops. (gnome-control-center shows XKB list from gnome-desktop3 in GNOME desktop instead.) The allowlist includes the limited XKB layouts and variants. E.g. 'gb(dvorak)' is included but 'gb' is not. And the allowlist has been supported to customize by sysadmin localy since the simple.xml is a simple text file and the default list has been updated upon the request. IBus 1.5.23 will replace the allowlist with the blocklist which includes the disabled XKB engines and `ibus-setup` will shows all the XKB engines which are '''not''' indicated in that file. The blocklist will includes 'cn' layout, 'cn' layout + any variants, 'nec_vndr/jp' layouts at the moment. I.e. the change won't effect GNOME desktop. == Benefit to Fedora == The users don't have to request the desired XKB layouts and variants in IBus upstream and most XKB keymaps will be shown in ibus-setup. == Scope == * Proposal owners: * Other developers: N/A * Release engineering: [https://pagure.io/releng/issue/9563 #9563] * Policies and guidelines: N/A * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == If a keymap is shown in ibus-setup in the previous version, it will be shown in the new one. == How To Test == # Log into XFCE desktop # Run ibus-setup It will show 'English (UK)' keymap by default. == User Experience == If a user customize `/usr/share/ibus/component/simple.xml` in the previous version, the file will be replaced with new one. == Dependencies == The change effects XKB engines only but does not input method engines (E.g. libpinyin, hangul, and so on.) == Contingency Plan == * Contingency mechanism: Drop the feature in Fedora 33 and postpone it to Fedora 34 * Contingency deadline: Beta freeze * Blocks release? No == Documentation == TBD -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Patches in Forge macros - Auto macros - Detached rpm changelogs - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
== Summary ==
redhat-rpm-config will be updated to add patching support to forge
macros, a plug-able framework to register macros to execute in
specific sections, and rpm changelogs in detached files.
== Owner ==
* Name: [[User:nim| Nicolas Mailhot]]
* Email:
== Detailed Description ==
This is a system-wide change because all packages build with
redhat-rpm-config, but it only concerns packages that opted to use
this part of redhat-rpm-config (users of forge, fonts and go macros).
It was driven first, by the need to make the underlying macro
infrastructure robust enough to package Go modules, and second, by an
unfortunate rpm 4.15 regression that proved it was foolish to depend
on rpmbuild to parse Tags in anything except canonical order.
=== Forge ===
* forge macro now process patches, including in multi-source spec
files, in a natural way
* all dependencies on source/patch numbering were eradicated, you can
write a whole multi-source/multi-patch spec without worrying about
source or patch numbers
* zero suffix is no longer special (à la Source/Source0 way), you can
declare forge blocks starting at 42 if that‘s your preference
=== Fully automated packaging ===
A framework was added so macro subsystems can register execution
blocks in specific parts or the spec file. Execution blocks are
orchestrated (using KISS rules) so for example the forge part of %prep
is executed before the go parts that depend on forge archives being
unpacked and patched, and macros that want to create srpm headers are
executed before macros that want to create subpackage headers.
Such a framework is a requirement to control the generation order
within the spec file and make sure rpm maintainers are not cross with
you.
That means a spec with no special custom processing is reduced to a
set of %global control variables that activate specific execution
blocks, and everything bellow those control variable is short and
unchanging boilerplate.
A packager that needs custom processing can add custom code above or
bellow the various `%auto_foo` calls, and check with `rpmspec -P` that
the result does what he wants it to do. For obvious reliability
reasons injecting custom code in the middle of an `%auto_foo` sequence
is not allowed.
%global source_name …
%global source_release …
%global source_post_release …
%global forge_url0 …
%global forge_commit0 …
%global forge_url1 …
%global forge_tag1 …
%global go_module33 …
%global go_description33 …
%global font_family22 …
%global font_conf22 …
%auto_init
%auto_pkg
%sourcelist
%auto_sources
%patchlist
%auto_patches
%prep
%auto_prep
%generate_buildrequires
%auto_generate_buildrequires
%build
%auto_build
%install
%auto_install
%check
%auto_check
%auto_files
%changelog
%auto_changelog
=== Detached changelogs ===
This framework was used to implement detached rpm changelogs in a reliable way.
=== Generic -doc creation ===
This framework was used to implement automated -doc subpackage
creation, because creating them by hand gets annoying after the nth
upstream that wants you do distribute heavy PDF documentation files.
=== Huge refactoring and fleshing out of the lua library ===
Writing high-level features like the above required defining a library
of lua routines like an expand that expands fully, an unset that
actually undefines, a read that tells you if a variable exists or is
set to "", a `fedora.echo()` wrapper around
`rpm.expand("%{echo:%{expand:" .. text .. "}}")`, etc. Those are now
available for others to use should they want to.
My coding skills are not up to navigating the upstream low level rpm
lua API without blowing up on the landmines it is littered with.
Therefore, I abstracted landmine avoidance in a single place.
=== Drawbacks ===
Nothing is free, and a higher level of automation required using rigid
naming for control variables. Because software is a lot less tolerant
of fuzzy naming than human beings.
So, all forge control variables are renamed, fonts control variables
have been renamed too, and go control variables will need renaming (in
that last case, that’s not a problem because moving to go modules
requires reworking variables anyway, so it will be done as part of the
module effort in F34).
To ease the transition a compatibility layer was added to forge macros
so old variables and new variables are aliased both ways (this will
eventually go away because it’s quite a lot of compatibility code to
maintain). Mixing syntaxes (old and new) is not supported, you need to
convert your spec file to new forge variables or not at all (if not at
all, do not try to use new features like patching).
== Benefit to Fedora ==
Spec files that do more with less manual expensive to maintain spec code.
Without this productivity win, complex efforts like converting Fedora
Go packages to Go modules, or draining the Font packages swamp given
that legacy
Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/SID == Summary == Introduce Storage Instantiation Daemon (SID) that aims to provide a central event-driven engine to write modules for identifying specific Linux storage devices, their dependencies, collecting information and state tracking while being aware of device groups forming layers and layers forming whole stacks or simply creating custom groups of enumerated devices. SID will provide mechanisms to retrieve and query collected information and a possibility to bind predefined or custom triggers with actions for each group. == Owner == * Name: [[User:prajnoha | Peter Rajnoha]] * Email: prajn...@redhat.com == Detailed Description == Over the years, various storage subsystems have been installing hooks within udev rules and calling out numerous external commands for them to be able to react on events like device presence, removal or a change in general. However, this approach ended up with very complex rules that are hard to maintain and debug if we are considering storage setups where we build layers consisting of several underlying devices (horizontal scope) and where we can stack one layer on top of another (vertical scope), building up diverse storage stacks where we also need to track progression of states either at device level or group level. SID extends udevd functionality here in a way that it incorporates a notion of device grouping directly in its core which helps with tracking devices in storage subsystems like LVM, multipath, MD... Also, it provides its own database where records are separated into per-device, per-module, global or udev namespace. The udev namespace keeps per-device records that are imported and/or exported to/from udev environment and this is used as compatible communication channel with udevd. The records can be marked with restriction flags that aid record separation and it prevents other modules to read, write or create a record with the same key, hence making sure that only a single module can create the records with certain keys (reserving a key). Currently, SID project provides a companion command called 'usid' which is used for communication between udev and SID itself. After calling the usid command in a udev rule, device processing is transferred to SID and SID strictly separates the processing into discrete phases (device identificaton, pre-scan, device scan, post-scan). Within these phases, it is possible to decide whether the next phase is executed and it is possible to schedule delayed actions or set records in the database that can fire triggers with associated actions or records which are then exported to udev environment (mainly for backwards compatibility and for other udev rules to have a chance to react). The scheduled actions and triggers are executed out of udev context and hence not delaying the udev processing itself and improving issues with udev timeouts where unnecessary work is done. A module writer can hook into the processing phases and use SID's API to access the database as well as set the triggers with actions or schedule separate actions and mark devices as ready or not for use in next layers. The database can be used within any phase to retrieve and store key-value records (where value could be any binary value in general) and the records can be marked as transient (only available during processing phases for current event) or persistent so they can be accessed while processing subsequent events. == Benefit to Fedora == The main benefit is all about centralizing the solution to solve issues that storage subsystem maintainers have been hitting with udev, that is: * providing a central infrastructure for storage event processing, currently targeted at udev events * improving the way storage events and their sequences are recognized and for which complex udev rules were applied before * single notion of device readiness shared among various storage subsystems (single API to set the state instead of setting various variables by different subsystems) * providing more enhanced possibilities to store and retrieve storage-device-related records when compared to udev database * direct support for generic device grouping (matching subsystem-related groups like LVM, multipath, MD... or creating arbitrary groups of devices) * centralized solution for scheduling triggers with associated actions defined on groups of storage devices * adding a centralized solution for delayed actions on storage devices and groups of devices (avoiding unnecessary work done within udev context and hence avoiding frequent udev timeouts when processing events for such devices) == Scope == * Proposal owners: ** complete SID's infrastructure to fully support stabilized API for other developers to start writing modules for SID; ** document all of current SID's functionality, including the module API and explain the difference (extension) to udev, write and complete man pages; ** provide udev rules responsible for
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Thursday, 25 June 2020 19:18:59 CEST Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/UseNanoByDefault > > == Summary == > > Let's make Fedora more approachable, by having a default editor that > doesn't require specialist knowledge to use. > > == Owner == > * Name: [[User:chrismurphy| Chris Murphy]] > * Email: chrismur...@fedoraproject.org > > > == Detailed Description == > > Users are exposed to the default editor when they use commands that > call it. The main example here is something like git > commit. > > Fedora does not currently have a default terminal text editor, because > the $EDITOR environment variable is unset by default. But a common > scenario where users wind up in a terminal text editor is when using > 'git commit'. By default, git picks vi. You need to spend time > learning how to use it, for even basic editing tasks. This increases > the barrier to entry for those who are switching to Fedora and don't > know how to use vi. It also makes things hard for those who don't > particularly want to learn how to use vi. (These arguments would apply > just as well if git picked Vim. vi is like hard mode for Vim, with > fewer features, missing syntax highlighting, and no indication of what > mode you are in. Even Vim users may feel lost and bewildered when > using vi.) > > In contrast, Nano offers the kind of graphical text editing experience > that people are used to, and therefore doesn't require specialist > knowledge to use. It is already installed across most Fedora Editions > and Spins. This proposal will make Nano the default editor, while > continuing to install vim-minimal (which provides vi, but > not Vim). People will still be able to call vi if they > want to edit a file. It will also obviously be possible to change the > default editor to vi or Vim, for those who want it. > > Why make Nano default and vi optional, rather than the other way > round? Because Nano is the option that everyone can use. > > == Feedback == > > Pending ... > > == Benefit to Fedora == > > * Makes the default editor across all of Fedora more approachable. > * Nano is also mostly self-documenting, by displaying common keyboard > shortcuts on-screen. > * More in line with the default editor of other distributions. > > == Scope == > * Proposal owners: > ** Modify comps to include nano Fedora wide. > ** Create a new subpackage of nano, called > nano-editor. > ** nano-editor to include > /usr/lib/environment.d/10-nano.conf, which sets > $EDITOR to nano. > > With this approach, if nano is uninstalled, the > configuration will be removed with it. At the same time, installing > nano on its own won't install the conf. > > * Other developers: N/A > > * Release engineering: [https://pagure.io/releng/issue/9522 #9522] > > * Policies and guidelines: N/A > > * Trademark approval: N/A > > == Upgrade/compatibility impact == > > Will not apply to upgrades. > > == How To Test == > > Run export EDITOR="/usr/bin/nano". > > == User Experience == > > Users running git commit will be able to just type their > commit message, rather than having to learn about insert mode, and > they'll be able to cut and paste without having to learn special > shortcuts. > > == Dependencies == > > No additional dependencies are required. > > == Contingency Plan == > The contingency plan is to revert the change by removing the > nano-editor package. > > * Contingency deadline: probably the beta? It's an easy change to revert. > * Blocks release? If the change breaks the redirection to an editor, > it should block the release. However, this is unlikely. > * Blocks product? Potentially all. > > == Documentation == > As part of this change, it would be good to add instructions for > changing the default editor to the > [https://docs.fedoraproject.org/en-US/quick-docs/ quick docs]. > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis May I suggest another option? I provide a package for Micro, an editor written in Go with a discoverable interface. https://micro-editor.github.io/ It is compiled as a static binary of 4.6 MB with no dependency. Probably bigger than nano, but it's nicer overall, with mouse support and syntax highlighting. Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: EPEL repos packaged for Fedora (for repoquery)
On 30. 06. 20 21:03, Kevin Fenzi wrote: I don't think a package-review is needed? It would just be unretiring the fedora branches of an existing package? Technically, the package is "retired for 8+ weeks" on Fedora. Hence a new review request. That said, I am -1 on the idea. You have no idea how many people try to install epel packages on fedora. We had to explicitly add a Conflicts to try and reduce this, and that was with them in another repo entirely! I fear if we do this more people will start installing stuff from epel on fedora and cause a lot of breakage. I understand the concern, but am not considering it a blocker for this, especially since people will find a way to download the epel packages anyway. This does not allow `dnf install epel-release` on Fedora neither are the repos enabled. The amount of work to actually use this package to install epel packages on Fedora is more or less the same as downloading the packages from Koji or EPEL mirrors. Whats your goal here? To have them easily available to query from fedora installs? Yes. See the README: https://src.fedoraproject.org/fork/churchyard/rpms/epel-release/blob/fedora-package/f/README.md -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL repos packaged for Fedora (for repoquery)
On 30. 06. 20 20:57, Neal Gompa wrote: I'm not sure this is a good idea. Also, queries and figuring out dependencies still requires having RHEL/CentOS repositories, which this package would not provide. That is a known limitation, but I wouldn't say this makes it "not a good idea". Would you mind telling why so consider it bad? I like the repos packaged, so I don't have to explain to others how to get them. This way, it's a magnitude easier. It solves a problem I have. Some time ago, I wrote rpmdistro-repoquery wrapper around dnf repoquery[1] for doing stuff like this. That might help for you too. [1]:https://pagure.io/rpmdistro-repoquery I've actually seen this (when mentioned couple week ago somewhere on a mailing list) and while powerful, it was a bit more complicated for me to use. For my own problems, having the epel repos is what I need. rpmdistro-repoquery wrapper can optionally use the packaged repos as well if desired (but doesn't have to). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL repos packaged for Fedora (for repoquery)
On Tue, Jun 30, 2020 at 06:46:43PM -, Miro Hrončok wrote: > To scratch my own itch I've packaged EPEL repos for Fedora. I've decided to > use the existing epel-release component for this (but I am OK to get a > different name, such as epel-repos). > > See https://src.fedoraproject.org/rpms/epel-release/pull-request/9 > And https://bugzilla.redhat.com/show_bug.cgi?id=1852583 > > Package review and any other feedback is appreciated. I don't think a package-review is needed? It would just be unretiring the fedora branches of an existing package? That said, I am -1 on the idea. You have no idea how many people try to install epel packages on fedora. We had to explicitly add a Conflicts to try and reduce this, and that was with them in another repo entirely! I fear if we do this more people will start installing stuff from epel on fedora and cause a lot of breakage. Whats your goal here? To have them easily available to query from fedora installs? > (Side note: I'm using the hyperkitty web interface to send this email, as I > cannot connect to my email from Thunderbird, sorry if the email is somewhat > weird.) Seems fine to me. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 6/30/20 11:38 AM, Tom Seewald wrote: > The primary areas of concern I have about Fedora dropping grub2 and BIOS boot > support are: nicely summarized. > 4. Support documentation for sd-boot > > Would this result in changes to how users access the boot menu, select a boot > entry, or edit the kernel command line, etc? These actions of course aren't > expected to be common but when they are needed it tends to be when a user is > already experiencing problems and is under stress. Therefore if there are > changes, hopefully these will be clearly documented to avoid confusion. Is this proposed dropping of grub only for 'desktop' Fedora? iiuc, server/workstation instances share the same underpinnings? For server/workstation, "access the boot menu, select a boot entry, or edit the kernel command line" are certainly NOT _uncommon_. Very often, particularly when tracking closely with upstream latest releases, they're very often _necessary_. re: sd-boot docs, grub -- for both BIOS & UEFI -- has available encyclopedic & thorough documentation. its configs are also wonderfully portable. including/across the countless other distros that (will) continue to use/support it. *dropping* grub for the next bright-n-shiny seems to make little sense. *adding* "sd-boot" (tbh, i've never come across an instance of it in use. anywhere.), and support *both* -- whether or not it's 'bloat -- doesn't make much sense either. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Tue, Jun 30, 2020 at 2:39 PM Tom Seewald wrote: > > > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes > > it beg the question if now would not be the time to stop supporting > > booting in legacy bios mode and move to uefi only supported boot which > > has been available on any common intel based x86 platform since atleast > > 2005. > > > > Now in 2017 Intel's technical marketing engineer Brian Richardson > > revealed in a presentation that the company will require UEFI Class 3 > > and above as in it would remove legacy BIOS support from its client and > > datacenter platforms by 2020 and one might expect AMD to follow Intel in > > this regard. > > > > So Intel platforms produced this year presumably will be unable to run > > 32-bit operating systems, unable to use related software (at least > > natively), and unable to use older hardware, such as RAID HBAs (and > > therefore older hard drives that are connected to those HBAs), network > > cards, and even graphics cards that lack UEFI-compatible vBIOS (launched > > before 2012 – 2013) etc. > > > > This post is just to gather feed back why Fedora should still continue > > to support legacy BIOS boot as opposed to stop supporting it and > > potentially drop grub2 and use sd-boot instead. > > > > Share your thoughts and comments on how such move might affect you so > > feedback can be collected for the future on why such a change might be > > bad, how it might affect the distribution and scope of such change can > > be determined for potential system wide proposal. > > > > > > Regards > > > > Jóhann B. > > > > > > 1. > > https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration > > The primary areas of concern I have about Fedora dropping grub2 and BIOS boot > support are: > > 1. Users that are on systems that do not support UEFI, or that knowingly (or > unknowingly) use BIOS boot on UEFI-capable systems. > > These people are likely to form a lasting negative impression of Fedora, as > removing BIOS boot support would ostensibly mean that Fedora no longer runs > on their systems (at least as configured). I have heard that the UEFI > implementations on some (typically older) motherboards can be buggy, so many > users may have a legitimate reason to still use BIOS boot on boards that > advertise support for both. > > 2. How would dropping grub2 affect users that boot multiple operating systems? > > What manual steps, if any, would users need to take if they were previously > using grub2 to support booting multiple operating systems. Would this change > break existing multi-boot setups? What would happen if some of those multiple operating systems do not support UEFI for whatever reason? > > 3. Virtual machines typically default to BIOS boot. > > It's my understanding that libvirt, Virtual Box, Hyper-V (gen1 VMs only?), > and many cloud providers default to using BIOS boot when creating virtual > machines. If Fedora no longer works *by default* with common virtualization > stacks I'd imagine many users will simply choose to no longer run or > recommend Fedora. I think this is a place to handhold user, not to tell, say, libvirt it should drop BIOS boot altogether like others in this thread suggested. > 4. Support documentation for sd-boot > > Would this result in changes to how users access the boot menu, select a boot > entry, or edit the kernel command line, etc? These actions of course aren't > expected to be common but when they are needed it tends to be when a user is > already experiencing problems and is under stress. Therefore if there are > changes, hopefully these will be clearly documented to avoid confusion. > > 5. What does Fedora gain by dropping BIOS boot support? > > Perhaps it is obvious to others, but I think it is worth fully spelling out > what the expected benefits are. This would help everyone more clearly see the > trade-offs of this change. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
[EPEL-devel] Re: EPEL repos packaged for Fedora (for repoquery)
On Tue, Jun 30, 2020 at 2:46 PM Miro Hrončok wrote: > > To scratch my own itch I've packaged EPEL repos for Fedora. I've decided to > use the existing epel-release component for this (but I am OK to get a > different name, such as epel-repos). > > See https://src.fedoraproject.org/rpms/epel-release/pull-request/9 > And https://bugzilla.redhat.com/show_bug.cgi?id=1852583 > > Package review and any other feedback is appreciated. > I'm not sure this is a good idea. Also, queries and figuring out dependencies still requires having RHEL/CentOS repositories, which this package would not provide. Some time ago, I wrote rpmdistro-repoquery wrapper around dnf repoquery[1] for doing stuff like this. That might help for you too. [1]: https://pagure.io/rpmdistro-repoquery -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Tue, Jun 30, 2020 at 2:39 PM John M. Harris Jr wrote: > > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote: > > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro > > wrote: > > > > > > > > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > > > wrote: > > > > > > > For the record, as this directly affects the Workstation deliverable, > > > > I will be voting -1 until and unless the Workstation WG votes in > > > > favor. > > > > > > > > > > > > > > > > Yes, it's a large set of Change owners, but since only two of them are > > > > Workstation WG members, they are not representative of that group. > > > > > > > > > > > > Workstation WG hat on: > > > > > > > > > > > > I don't think there's any need to vote -1 for that reason alone. The > > > Workstation WG has discussed the change proposal at several meetings > > > recently (really, we've spent a long time on this), and frankly we were > > > not making a ton of progress towards reaching a decision either way, so > > > going forward with the change proposal and moving the discussion to > > > devel@ to get feedback from a wider audience and from FESCo seemed like > > > a good idea. Most likely, we'll wind up doing whatever FESCo chooses > > > here, but unless FESCo were to explicitly indicate intent to override > > > the Workstation WG, we would not consider a FESCo decision to limit > > > what the Workstation WG can do with the Workstation product. At least, > > > my understanding of the power structure FESCo has established is that > > > the WG can make product-specific decisions that differ from FESCo's > > > decisions whenever we want, unless FESCo says otherwise (because FESCo > > > always has final say). That is, if FESCo were to approve btrfs by > > > default, but Workstation WG were to vote to stick with ext4, then we > > > would stick with ext4 unless FESCo were to say "no really, you need to > > > switch to btfs" (which I highly doubt would happen). So I don't see any > > > reason to vote -1 here out of concern for overriding the WG. > > > > > > > > > > > > The problem is that the request as discussed reads as "FESCo says use > > it for workstation" vs "FESCo has no problem with Workstation saying > > they want btrfs" or "FESCo says use btrfs as default". Yes it says > > "desktop variants" but only 1 variant really counts and that is > > Workstation. So yes, either Workstation agrees to it or it isn't > > getting voted on. If Workstation can't come to an agreement on it, > > then the proposal is dead. Anything else is an end-run and a useless > > trolling of people to see how many rants LWN counts in its weekly > > messages. > > Well, it's not only Workstation that this proposal is trying to throw btrfs > on, but the other desktops as well, such as KDE Spin. > And I am driving this as a member of the KDE SIG, though I am a member of both groups. Both the Workstation WG and KDE SIG are responsible groups for this Change. Chris Murphy is the primary driver of this from the Workstation WG side, and I am from the KDE SIG side. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Tue, Jun 30, 2020 at 10:30 AM Antti wrote: > > > Another way to consider this would be that we can stop arguing against these > > changes, let the GNOME folks run the ship aground, and hope that the user > > backlash will act as a wakeup call when it comes to these changes. I agree > > that btrfs is far too unstable to be made a default, and I also agree that > > ZFS > > would be a much better option. However, there is always going to be pushback > > on ZFS. If you want the best, there's a price to pay, and that's licensing > > headaches in this case. > > I understand you but I'd like to help btrfs guys to get their stuff working. > And for two days now I've tried to write a reasonable honest truthful reply > for their questions backed by facts and confirmed data unable to come up with > concise answers. After following this topic it became clear to me that I'm > not sufficiently prepared to give a proper technical presentation of my > issues or to have an in-depth discussion of btrfs while they are very well > prepared to defend their position. This is happening so suddenly too. I > didn't expect Fedora to start considering this at all because Red Hat isn't > at least publicly discussing it. I'd also like to avoid writing massive dozen > page emails about my personal issues with btrfs when the central question > here is if btrfs is good enough for majority of Fedora's user base. It could > be even if it isn't ready for my use. > > I can only offer descriptions of symptoms of trouble from the web back-end > developer / desktop end-user PoW which starts to appear in personal computers > where I have used or currently do use btrfs if not full-time. I made a long > list of these yesterday and only some of them can be linked to existing known > issues which are yet to be fixed so I didn't send that list to Chris Murphy > and Stasiek Michalski yet and might not do so. Not publicly at least. Some of > the issues have been fixed but not yet present in openSUSE Leap 15.1 where I > previously experienced just how broken btrfs can be at its worst and I don't > have that particular setup right now to even test if these changes would aid > me in upcoming openSUSE Leap 15.2 release. I just have to let my head cool > down before trying btrfs full-time again in a year or two. > There will likely be significant improvement with openSUSE Leap 15.2, as the kernel has been rebased from 4.12 to 5.4. With that rebase, virtually all the stabilization work done upstream that hasn't already been backported to the SUSE Linux Enterprise 15 kernel will be included. That said, as one of the change owners, I *want* to know about your issues. I want to be able to solve them. We have an upstream Btrfs developer who wants to resolve issues people discover, and the only way we can is if we know about them and get details to pin them down and fix them. It's how this goes with any piece of software, really. I've been using it for five years on desktops, VMs, and servers with no issues for at least the last three. But I am not so blind as to say that Btrfs is perfect. But there's nothing I can do about things I don't know about, and that's true for anything in open source. You should feel free to file bug reports so that we can address them. > Furthermore some of the things the proponents of this change have written > just throw me back into my chair because after all I've gone through with > btrfs and after all the lost time I could have spent better producing code, I > know what they're writing is simply not true. Or not true in my case and I > have major disbelief regarding for example there being no need to run btrfs > balance when on my ThinkPad T430 I know for a fact that btrfs constantly will > start running out of disk space and the solutions to it only temporarily > solve it through regular use of btrfs balance, disabling snapshots which tend > to get corrupted anyway and fine tuning the file system. But then again I > don't think they're lying and I don't want to accuse them of that. There are > visibly big gaps in how btrfs is experienced by different people in different > working environments on different hardware. Based on what I've read lately, > btrfs seems to work at really big scales very well. Where it fails to work > are smaller > individual setups and small businesses. This makes it a controversial file > system. > > Like I explained in another message, btrfs to me is highly visible file > system and a source of stress as I have to eventually babysit it which to me > proves it is unstable and not production ready. And this variation in how > btrfs is experienced by different people is perhaps just another sign of it > not being production ready yet even if huge progress has been made recent > times. That is a good reason not to make it the default choice in Fedora. > > Yesterday I went through my past emails where I discuss btrfs with my > colleagues. It was some years
[EPEL-devel] EPEL repos packaged for Fedora (for repoquery)
To scratch my own itch I've packaged EPEL repos for Fedora. I've decided to use the existing epel-release component for this (but I am OK to get a different name, such as epel-repos). See https://src.fedoraproject.org/rpms/epel-release/pull-request/9 And https://bugzilla.redhat.com/show_bug.cgi?id=1852583 Package review and any other feedback is appreciated. (Side note: I'm using the hyperkitty web interface to send this email, as I cannot connect to my email from Thunderbird, sorry if the email is somewhat weird.) Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
> Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes > it beg the question if now would not be the time to stop supporting > booting in legacy bios mode and move to uefi only supported boot which > has been available on any common intel based x86 platform since atleast > 2005. > > Now in 2017 Intel's technical marketing engineer Brian Richardson > revealed in a presentation that the company will require UEFI Class 3 > and above as in it would remove legacy BIOS support from its client and > datacenter platforms by 2020 and one might expect AMD to follow Intel in > this regard. > > So Intel platforms produced this year presumably will be unable to run > 32-bit operating systems, unable to use related software (at least > natively), and unable to use older hardware, such as RAID HBAs (and > therefore older hard drives that are connected to those HBAs), network > cards, and even graphics cards that lack UEFI-compatible vBIOS (launched > before 2012 – 2013) etc. > > This post is just to gather feed back why Fedora should still continue > to support legacy BIOS boot as opposed to stop supporting it and > potentially drop grub2 and use sd-boot instead. > > Share your thoughts and comments on how such move might affect you so > feedback can be collected for the future on why such a change might be > bad, how it might affect the distribution and scope of such change can > be determined for potential system wide proposal. > > > Regards > > Jóhann B. > > > 1. > https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration The primary areas of concern I have about Fedora dropping grub2 and BIOS boot support are: 1. Users that are on systems that do not support UEFI, or that knowingly (or unknowingly) use BIOS boot on UEFI-capable systems. These people are likely to form a lasting negative impression of Fedora, as removing BIOS boot support would ostensibly mean that Fedora no longer runs on their systems (at least as configured). I have heard that the UEFI implementations on some (typically older) motherboards can be buggy, so many users may have a legitimate reason to still use BIOS boot on boards that advertise support for both. 2. How would dropping grub2 affect users that boot multiple operating systems? What manual steps, if any, would users need to take if they were previously using grub2 to support booting multiple operating systems. Would this change break existing multi-boot setups? 3. Virtual machines typically default to BIOS boot. It's my understanding that libvirt, Virtual Box, Hyper-V (gen1 VMs only?), and many cloud providers default to using BIOS boot when creating virtual machines. If Fedora no longer works *by default* with common virtualization stacks I'd imagine many users will simply choose to no longer run or recommend Fedora. 4. Support documentation for sd-boot Would this result in changes to how users access the boot menu, select a boot entry, or edit the kernel command line, etc? These actions of course aren't expected to be common but when they are needed it tends to be when a user is already experiencing problems and is under stress. Therefore if there are changes, hopefully these will be clearly documented to avoid confusion. 5. What does Fedora gain by dropping BIOS boot support? Perhaps it is obvious to others, but I think it is worth fully spelling out what the expected benefits are. This would help everyone more clearly see the trade-offs of this change. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote: > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro > wrote: > > > > > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > > wrote: > > > > > For the record, as this directly affects the Workstation deliverable, > > > I will be voting -1 until and unless the Workstation WG votes in > > > favor. > > > > > > > > > > > > Yes, it's a large set of Change owners, but since only two of them are > > > Workstation WG members, they are not representative of that group. > > > > > > > > Workstation WG hat on: > > > > > > > > I don't think there's any need to vote -1 for that reason alone. The > > Workstation WG has discussed the change proposal at several meetings > > recently (really, we've spent a long time on this), and frankly we were > > not making a ton of progress towards reaching a decision either way, so > > going forward with the change proposal and moving the discussion to > > devel@ to get feedback from a wider audience and from FESCo seemed like > > a good idea. Most likely, we'll wind up doing whatever FESCo chooses > > here, but unless FESCo were to explicitly indicate intent to override > > the Workstation WG, we would not consider a FESCo decision to limit > > what the Workstation WG can do with the Workstation product. At least, > > my understanding of the power structure FESCo has established is that > > the WG can make product-specific decisions that differ from FESCo's > > decisions whenever we want, unless FESCo says otherwise (because FESCo > > always has final say). That is, if FESCo were to approve btrfs by > > default, but Workstation WG were to vote to stick with ext4, then we > > would stick with ext4 unless FESCo were to say "no really, you need to > > switch to btfs" (which I highly doubt would happen). So I don't see any > > reason to vote -1 here out of concern for overriding the WG. > > > > > > > The problem is that the request as discussed reads as "FESCo says use > it for workstation" vs "FESCo has no problem with Workstation saying > they want btrfs" or "FESCo says use btrfs as default". Yes it says > "desktop variants" but only 1 variant really counts and that is > Workstation. So yes, either Workstation agrees to it or it isn't > getting voted on. If Workstation can't come to an agreement on it, > then the proposal is dead. Anything else is an end-run and a useless > trolling of people to see how many rants LWN counts in its weekly > messages. Well, it's not only Workstation that this proposal is trying to throw btrfs on, but the other desktops as well, such as KDE Spin. -- 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: [EPEL] rpmconf question for EPEL7 on Amazon Linux 2
On Tue, 30 Jun 2020, Christopher wrote: I know Fedora doesn't directly support Amazon Linux, but I was wondering if the package maintainer for rpmconf on EPEL was aware that the latest version doesn't work on Amazon Linux 2, which recently updated to python-3.7, whereas rpmconf has a direct dependency on python(abi)=3.6. If it's possible to use '>=3.6' instead, and the package maintainer is willing to update it so it works with python 3.7 on Amazon Linux 2, that would be great for my use case. I don't think it would be that easy. rpmconf is byte-compiled for Python 3.6 and everything. I don't think you can just upgrade a major Python version like that and expect modules built for the previous version to continue to work. rpmconf would have to be built for Python 3.7 *also* and since it's not in EPEL, I don't see how that could happen. Scott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Tuesday, June 30, 2020 11:29:13 AM MST Jóhann B. Guðmundsson wrote: > On 30.6.2020 17:49, John M. Harris Jr wrote: > > On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote: > >> Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes > >> it beg the question if now would not be the time to stop supporting > >> booting in legacy bios mode and move to uefi only supported boot which > >> has been available on any common intel based x86 platform since atleast > >> 2005. > > > > This is simply false. I'm currently writing this email on a ThinkPad X200 > > Tablet, which does not support UEFI. I can get dropping x86 support, but > > dropping BIOS boot support? > > Such proposal would never be about stop supporting older hardware that's > just a misconception people are getting > > And it's quite evident by the response here that hw that is atleast 2010 > and older is still quite happily being used and that hw does not support > UEFI and no one is talking about taking that away anytime soon. > > The first step ( The actual change proposal ) would simply be about > replace grub2 with sd-boot for UEFI strictly on the x86 architecture > which has UEFI available and enabled ( is not using legacy bios ) and > see what issue are encountered, solve those then consider moving to > different architectures and further integration if relevant etc. ( baby > steps ) Next I would suggest looking at UEFI supported ARM systems ( but > I personally would have to obtain such hardware before doing so ). > > JBG Why do you prefer sd-boot over GRUB2? I don't understand how you'd boot from an SD card on most x86 hardware. ;) Jokes aside, what's the call for the preference of even more systemd bloat? Do we not have enough yet? -- 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 30.6.2020 17:49, John M. Harris Jr wrote: On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been available on any common intel based x86 platform since atleast 2005. This is simply false. I'm currently writing this email on a ThinkPad X200 Tablet, which does not support UEFI. I can get dropping x86 support, but dropping BIOS boot support? Such proposal would never be about stop supporting older hardware that's just a misconception people are getting And it's quite evident by the response here that hw that is atleast 2010 and older is still quite happily being used and that hw does not support UEFI and no one is talking about taking that away anytime soon. The first step ( The actual change proposal ) would simply be about replace grub2 with sd-boot for UEFI strictly on the x86 architecture which has UEFI available and enabled ( is not using legacy bios ) and see what issue are encountered, solve those then consider moving to different architectures and further integration if relevant etc. ( baby steps ) Next I would suggest looking at UEFI supported ARM systems ( but I personally would have to obtain such hardware before doing so ). 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: drop bfq scheduler, instead use mq-deadline across the board
On Tue, Jun 30, 2020 17:23:16 +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jun 30, 2020 at 04:25:23PM +0100, Ankur Sinha wrote: > > On Mon, Jun 29, 2020 15:01:24 -0600, Chris Murphy wrote: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1851783 > > > > > > The main argument is that for typical and varied workloads in Fedora, > > > mostly on consumer hardware, we should use mq-deadline scheduler > > > rather than either none or bfq. > > > > > > It may be true most folks with NVMe won't see anything bad with none, > > > but those who have heavier IO workloads are likely to be better off > > > with mq-deadline. > > > > > > Further details are in the bug, but let's discuss it on list. Thanks! > > > > There was this thread about our systems hanging, and the workaround was > > to revert to mq-deadline from bfq: > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MJJFT5AOYUFZ3SO2EDVLJSDAZMZI4HAP/#DA7RCQFIAD4Z3Q7HQBW2ELPTLPYDKJMT > > To clarify: you could reliably reproduce the issue when building steps in > mock. > Did you verify that it is reliably fixed simply by switching bfq→mq-deadline? Yes, that was the first change I had made and it had stopped the hanging. As a permanent fix, though, I switched to using isolation = simple in mock, and since that works, I've not changed it since. (I make it a point to provide the needed information for bugs, but this release my quota is currently being used up on getting Docker + minikube to work on F32 for $dayjob) > > There are a few threads on AskFedora about systems hanging. They're not > > the easiest to debug but we did suggest people try switching to > > mq-deadline to see if it helps: > > > > https://ask.fedoraproject.org/t/whole-os-freezes-watching-a-video-with-mpv/6770/10 > > > > I don't know enough about this to say if it's a bug and if it has been > > fixed. > > There's a lot of noise in those bug reports. For heisenbugs, the fact > that something was an issue and after a flurry of half-random changes > to the system isn't, does not allow us conclude _anything_. We need > somebody who understands what they are doing to isolate the issue. In > particular, if this is a kernel hang, than we need a proper traceback > from the kernel, and not just assume it's the scheduler. There is a kernel trace in the related bug that was cited there: https://bugzilla.redhat.com/show_bug.cgi?id=1767097#c7 which links to another bfq bug here that's currently needinfo: https://bugzilla.redhat.com/show_bug.cgi?id=1767539 > (In particular, if this is a race condition, changing the scheduler > could be just making the condition less likely because the system is > slower or faster or just schedules processes in a different order, > without the scheduler being relevant to the bug). Like I said, I don't know. I'm a fairly advanced Linux user but you can hardly me to also be kernel hacker. :) For kernel bugs, I'd strongly suggest giving reporters steps by step instructions or links to using a "serial console" or a "netconsole". These are not part of my working vocabulary (I cannot speak for others). -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
> I can only offer descriptions of symptoms of trouble from the web back-end > developer / > desktop end-user PoW which starts to appear in personal computers where I > have used or > currently do use btrfs if not full-time. I made a long list of these > yesterday and only > some of them can be linked to existing known issues which are yet to be fixed > so I > didn't send that list to Chris Murphy and Stasiek Michalski yet and might not > do so. > Not publicly at least. Some of the issues have been fixed but not yet present > in openSUSE > Leap 15.1 where I previously experienced just how broken btrfs can be at its > worst and I > don't have that particular setup right now to even test if these changes > would aid me > in upcoming openSUSE Leap 15.2 release. I just have to let my head cool down > before trying > btrfs full-time again in a year or two. Leap 15.2 might be a good choice in this case, since it will suffer that mid-life kernel rebase of Leap 15. You kinda got me, because despite technically being a Leap developer, I don't use it, because I don't have any use for it anywhere outside of the parts I contribute to. My experience with Leap might therefore be limited. Whatever isn't being posted on Reddit, Bugzilla, Discord or Matrix about btrfs on Leap I am going to miss, because my entire experience of btrfs has been through interacting with Tumbleweed and derivatives (Kubic, MicroOS). Considering the schedule at which Fedora and Tumbleweed upgrade the kernels is closer, this should actually be a more fair comparison though. > Furthermore some of the things the proponents of this change have written > just throw me > back into my chair because after all I've gone through with btrfs and after > all the > lost time I could have spent better producing code, I know what they're > writing is > simply not true. Or not true in my case and I have major disbelief regarding > for example > there being no need to run btrfs balance when on my ThinkPad T430 I know for > a fact that > btrfs constantly will start running out of disk space and the solutions to it > only > temporarily solve it through regular use of btrfs balance, disabling > snapshots which tend > to get corrupted anyway and fine tuning the file system. But then again I > don't think > they're lying and I don't want to accuse them of that. There are visibly big > gaps > in how btrfs is experienced by different people in different working > environments on > different hardware. Based on what I've read lately, btrfs seems to work at > really big > scales very well. Where it fails to work are smaller > individual setups and small businesses. This makes it a controversial file > system. Snapshots aren't a part of this proposal, and frankly they do require a little bit more UX work, since they tend to cause people to run out of space too, because we don't cap that well enough. You can make snapshots work in a way that won't annoy you, because there are ways to set them up correctly, but for that you shouldn't rely on openSUSE distros defaults in that regard. Also I doubt openSUSE distros are used on big scale very often, I can think of very few examples, but they certainly don't match the sheer amount of users we have on various communication channels otherwise. > If it was easy to choose e.g. plain lvm+ext4 or Stratis lvm+xfs instead of > btrfs during > Fedora installation like it is in openSUSE I probably wouldn't be in total > opposition > to this proposal. I still would be against it but I wouldn't be here writing > these > messages about this issue and expressing my opposition to this proposal. And > it would have > to be fixed first before making btrfs the default file system. Which openSUSE do you mean, our custom partitioning is a nightmare, to the point that even YaST developers started to want to make it easier recently. LCP [Stasiek] https://lcp.world ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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] rpmconf question for EPEL7 on Amazon Linux 2
Hi, I know Fedora doesn't directly support Amazon Linux, but I was wondering if the package maintainer for rpmconf on EPEL was aware that the latest version doesn't work on Amazon Linux 2, which recently updated to python-3.7, whereas rpmconf has a direct dependency on python(abi)=3.6. If it's possible to use '>=3.6' instead, and the package maintainer is willing to update it so it works with python 3.7 on Amazon Linux 2, that would be great for my use case. Regards, Christopher ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Adam Williamson píše v Út 30. 06. 2020 v 08:25 -0700: > On Tue, 2020-06-30 at 16:23 +0200, Marcin Juszkiewicz wrote: > > W dniu 30.06.2020 o 15:34, Jóhann B. Guðmundsson pisze: > > > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > > > changes it beg the question if now would not be the time to stop > > > supporting booting in legacy bios mode and move to uefi only > > > supported boot which has been available on any common intel based > > > x86 > > > platform since atleast 2005. > > > > Will you provide replacement for laptop I bought in 2013? Still has > > some > > use, runs Fedora 31 just fine. BIOS mode only. > > > > My other PC at home is BIOS mode only too. Sure, it is FX-6300 so > > quite > > old but with some hard drives and 16GB of ram it has a use. > > I'm also still using a laptop from 2010: > > https://www.trustedreviews.com/reviews/sony-vaio-z-series-vpc-z11z9e-b-13-1in-laptop > > it has outlived one 'replacement' so far, and my 3.5 year old XPS 13 > (9360 gen) recently stopped booting so unless I can fix that, it will > have outlived two... > > it has no UEFI support either. I maintain the following laptops in our family: ThinkPad R61 ThinkPad T400s ThinkPad X201 Macbook Pro 2010 All of them don't support UEFI, but run Fedora 32 just fine and are still useful to my relatives. I think one of the important roles of Linux distributions is that they allow you to keep using hardware that has been obsoleted by its vendors, help you fight the planned obsolescence. I know that supporting old hardware comes at a cost and at some point we just have to make a cut, but doing it for hardware that is 8-10 years old is not much better than the planned obsolescence. Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Tuesday, June 30, 2020 6:25:02 AM MST Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/KDEEarlyOOM
>
> == Summary ==
> As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install
> earlyoom package, and enable it by default. If both RAM and swap go below
> 10% free, earlyoom issues SIGTERM to the process with the largest
> oom_score. If both RAM and swap go below 5% free, earlyoom issues SIGKILL
> to the process with the largest oom_score. The idea is to recover from out
> of memory situations sooner, rather than the typical complete system hang
> in which the user has no other choice but to force power off.
>
> == Owner ==
> * Name: [[User:bcotton|Ben Cotton]]
> * Email: bcot...@redhat.com
>
> == Detailed Description ==
> Shamelessly copied from Workstation, which did it in the last release:
>
> Certain workloads have heavy memory demands, quickly consume all of RAM,
> and start to heavily page out to swap. (Heavy paging, is often called "swap
> thrashing" for added descriptive effect, probably because it's noticeable
> and annoying). Incidental swap usage is a good thing, it frees up memory
> for active pages used by a process. Heavy swap usage quickly leads to a
> very negative UX, because it's slow, even on modern SSDs. Due to installer
> defaults, the swap partition is made the same size as available memory (at
> install time), which can be huge. This just extends swap thrashing time.
>
> On the one hand, we want this resource hungry job to complete. On the other
> hand, we want our system to be responsive while that other work is going
> on. But once the GUI stutters or even comes to an apparent stand still
> (hang), we're really wishing the kernel oom-killer would kick in and free
> up memory, so we can start over (maybe using memory or thread limiting
> options - which arguably should be more intelligently figured out, and that
> too is a work in progress but beyond the scope of this feature).
>
> However, once in a heavy swap scenario, it's relatively common the system
> gets stuck in it, where GUI interactivity is terrible to non-existent, and
> also the kernel oom-killer doesn't trigger. From a certain point of view,
> this is working as intended. The kernel oom-killer is concerned about
> keeping the kernel running. It's not at all concerned about user space
> responsiveness.
>
> Instead of the system becoming completely unresponsive for tens of minutes,
> hours or days, this feature expects that an offending process (determined
> by oom_score, same as the kernel oom-killer) will be killed off within
> seconds or a few minutes.
>
> == Benefit to Fedora ==
>
> KDE users will be able to take advantage of the benefits Workstation users
> got from enabling earlyOOM in Fedora 32:
>
> * improved user experience by more quickly regaining control over one's
> system, rather than having to force power off in low-memory situations
> where there's aggressive swapping. Once a system becomes unresponsive, it's
> completely reasonable for the user to assume the system is lost, but that
> includes high potential for data loss.
> * reducing forced poweroff as the main work around will increase data
> collection, improving understanding of low memory situations and how to
> handle them better
> * earlyoom first sends SIGTERM to the chosen process, so it has a chance of
> a proper shutdown, unlike the kernel's oom-killer
>
> == Scope ==
> * Proposal owners:
> ** Modify {{code|
> https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in}} to include
> earlyoom package for in {{code|kde-desktop}} section.
> ** Add {{code|
> https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-kde.prese
> t}} to include:
>
> # enable earlyoom by default on KDE
> enable earlyoom.service
>
>
> * Other developers: None, unless KDE-based Spins/Labs want to opt out
>
> * Release engineering: N/A
> * Policies and guidelines: N/A
> * Trademark approval: N/A
>
> == Upgrade/compatibility impact ==
> earlyoom.service will be enabled on upgrade. An upgraded system should
> exhibit the same behaviors as a newly-installed system.
>
> == How To Test ==
> * Fedora 31/32 KDE users can test today:
> ** {{code|sudo dnf install earlyoom}}
> ** {{code|sudo systemctl enable --now earlyoom}}
>
> And then attempt to cause an out of memory situation. Examples:
> ** {{code|tail /dev/zero}}
> ** https://lkml.org/lkml/2019/8/4/15
>
> == User Experience ==
> earlyoom sends SIGTERM to processes based on oom_score when both memory and
> swap have less than 10% free and SIGKILL when below 5%.
>
> == Dependencies ==
> None
>
> == Contingency Plan ==
>
> * Contingency mechanism: (What to do? Who will do it?) Owner reverts
> changes
> * Contingency deadline: Final freeze
> * Blocks release? No
>
> == Documentation ==
> * {{code|man earlyoom}}
> * https://github.com/rfjakob/earlyoom
> * https://www.kernel.org/doc/gorman/html/understand/understand016.html
>
> == Release Notes ==
> The earlyoom service
Re: The future of legacy BIOS support in Fedora.
On 30.6.2020 17:47, Robbie Harwood wrote: Jóhann B. Guðmundsson writes: On 30.6.2020 13:56, Igor Raits wrote: On Tue, 2020-06-30 at 13:34 +, Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been available on any common intel based x86 platform since atleast 2005. Now in 2017 Intel's technical marketing engineer Brian Richardson revealed in a presentation that the company will require UEFI Class 3 and above as in it would remove legacy BIOS support from its client and datacenter platforms by 2020 and one might expect AMD to follow Intel in this regard. So Intel platforms produced this year presumably will be unable to run 32-bit operating systems, unable to use related software (at least natively), and unable to use older hardware, such as RAID HBAs (and therefore older hard drives that are connected to those HBAs), network cards, and even graphics cards that lack UEFI-compatible vBIOS (launched before 2012 – 2013) etc. This post is just to gather feed back why Fedora should still continue to support legacy BIOS boot as opposed to stop supporting it and potentially drop grub2 and use sd-boot instead. Share your thoughts and comments on how such move might affect you so feedback can be collected for the future on why such a change might be bad, how it might affect the distribution and scope of such change can be determined for potential system wide proposal. I think there are many people still install OS in the legacy mode, but I don't really have numbers. One thing we should definitely do if we deprecate legacy BIOS is to properly warn users that still use this configuration, develop tooling for them if possible for migration and do not allow upgrades that will simply break their system. The use of legacy or uefi are changes that users have to manually change themselves in their bios from manufactures default settings. There is no tool that can do that for them or migrate those settings however users should be able to change this for hardware around 2010. The Installer would have to try to detect and make a choise sd-boot ( If settings equall UEFI ) or grub2 ( If setting not equals UEFI ) depending on it's results. As an example here's the BIOS/UEFI history for Apple hardware. 2012 and older models only support legacy BIOS Mode 2013-2014 models support both EFI and BIOS with the default setting being set on BIOS 2015 and later models only support EFI Different manufacturers have different timelines and different default settings but I think it's safe to presume from this year onwards they will all drop the legacy support and default to UEFI. I don't think it contradicts your point that "this stuff is really complicated", but my desktop is a 2009/2010 MacPro 4,1 running Fedora booted using EFI. (I didn't ask it one way or the other - this is how anaconda installed it for me.) I was bit surprised by this given that I got that EFI Apple integration timeframe from the OS-X forum but further digging through Apple documents has revealed that UEFI has been supported since 2006 on Mac computers with an Intel-based CPU [1]. So Anaconda did the right thing ;) JBG 1. https://support.apple.com/en-is/guide/security/seced055bcf6/web ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Tuesday, June 30, 2020 7:00:00 AM MST Florian Weimer wrote: > * Jóhann B. Guðmundsson: > > > > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > > changes it beg the question if now would not be the time to stop > > supporting booting in legacy bios mode and move to uefi only supported > > boot which has been available on any common intel based x86 platform > > since atleast 2005. > > > Even for virtualization? Not sure if that can be done. It's possible, and actually surprisingly simple, but not in virtualization hosts based on RHEL7. I'm not sure about RHEL8, but in Fedora, you can install edk2-ovmf, if it's not already installed, to get UEFI support. -- 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 Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote: > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes > it beg the question if now would not be the time to stop supporting > booting in legacy bios mode and move to uefi only supported boot which > has been available on any common intel based x86 platform since atleast > 2005. This is simply false. I'm currently writing this email on a ThinkPad X200 Tablet, which does not support UEFI. I can get dropping x86 support, but dropping BIOS boot support? > Now in 2017 Intel's technical marketing engineer Brian Richardson > revealed in a presentation that the company will require UEFI Class 3 > and above as in it would remove legacy BIOS support from its client and > datacenter platforms by 2020 and one might expect AMD to follow Intel in > this regard. Good for them. That just means that, on those next-generation systems, once they're out, people will be using UEFI boot. > So Intel platforms produced this year presumably will be unable to run > 32-bit operating systems, unable to use related software (at least > natively), and unable to use older hardware, such as RAID HBAs (and > therefore older hard drives that are connected to those HBAs), network > cards, and even graphics cards that lack UEFI-compatible vBIOS (launched > before 2012 – 2013) etc. What does BIOS boot have to do with 32 bit operating systems? RAID HBAs will also continue to work, though you may not be able to boot from them. Network cards will *also* continue to work, you just might not be able to PXE. > This post is just to gather feed back why Fedora should still continue > to support legacy BIOS boot as opposed to stop supporting it and > potentially drop grub2 and use sd-boot instead. So that people can continue to boot their systems, and so that users and cloud providers can still boot Fedora VMs. Why in the world would GRUB2 be dropped? > Share your thoughts and comments on how such move might affect you so > feedback can be collected for the future on why such a change might be > bad, how it might affect the distribution and scope of such change can > be determined for potential system wide proposal. This would mean that every single one of the systems that I own, every system on Linode, DigitalOcean, and most other cloud providers would cease to be able to boot Fedora. I'm very much against this proposal. -- 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.
Jóhann B. Guðmundsson writes: > On 30.6.2020 13:56, Igor Raits wrote: >> On Tue, 2020-06-30 at 13:34 +, Jóhann B. Guðmundsson wrote: >>> >>> Given Hans proposal [1] introduced systemd/grub2/Gnome upstream >>> changes it beg the question if now would not be the time to stop >>> supporting booting in legacy bios mode and move to uefi only >>> supported boot which has been available on any common intel based >>> x86 platform since atleast 2005. >>> >>> Now in 2017 Intel's technical marketing engineer Brian Richardson >>> revealed in a presentation that the company will require UEFI Class >>> 3 and above as in it would remove legacy BIOS support from its >>> client and datacenter platforms by 2020 and one might expect AMD to >>> follow Intel in this regard. >>> >>> So Intel platforms produced this year presumably will be unable to >>> run 32-bit operating systems, unable to use related software (at >>> least natively), and unable to use older hardware, such as RAID HBAs >>> (and therefore older hard drives that are connected to those HBAs), >>> network cards, and even graphics cards that lack UEFI-compatible >>> vBIOS (launched before 2012 – 2013) etc. >>> >>> This post is just to gather feed back why Fedora should still >>> continue to support legacy BIOS boot as opposed to stop supporting >>> it and potentially drop grub2 and use sd-boot instead. >>> >>> Share your thoughts and comments on how such move might affect you >>> so feedback can be collected for the future on why such a change >>> might be bad, how it might affect the distribution and scope of such >>> change can be determined for potential system wide proposal. >> >> I think there are many people still install OS in the legacy mode, >> but I don't really have numbers. One thing we should definitely do if >> we deprecate legacy BIOS is to properly warn users that still use >> this configuration, develop tooling for them if possible for >> migration and do not allow upgrades that will simply break their >> system. > > The use of legacy or uefi are changes that users have to manually > change themselves in their bios from manufactures default > settings. There is no tool that can do that for them or migrate those > settings however users should be able to change this for hardware > around 2010. > > The Installer would have to try to detect and make a choise sd-boot ( > If settings equall UEFI ) or grub2 ( If setting not equals UEFI ) > depending on it's results. > > As an example here's the BIOS/UEFI history for Apple hardware. > > 2012 and older models only support legacy BIOS Mode > > 2013-2014 models support both EFI and BIOS with the default setting > being set on BIOS > > 2015 and later models only support EFI > > Different manufacturers have different timelines and different default > settings but I think it's safe to presume from this year onwards they > will all drop the legacy support and default to UEFI. I don't think it contradicts your point that "this stuff is really complicated", but my desktop is a 2009/2010 MacPro 4,1 running Fedora booted using EFI. (I didn't ask it one way or the other - this is how anaconda installed it for me.) Thanks, --Robbie 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
Cleaning up comps packages in rawhide
I have been going through the packages listed in the comps file for rawhide (given in here https://pagure.io/fedora-comps) to clean it up and remove any packages that are currently not in any Fedora rawhide repos, and to update the architectures for packages that are only available on certain ones. A summary of the changes is below. If you see any issues with these changes, then I would suggest checking the package source, since this list is based on the current state of the repositories. Modifying package architectures: 0ad only available on aarch64, armv7hl, ppc64le, x86_64 LabPlot only available on aarch64, armv7hl, ppc64le, x86_64 YafaRay only available on x86_64 YafaRay-blender only available on x86_64 akregator only available on aarch64, armv7hl, x86_64 alienarena only available on aarch64, armv7hl, ppc64le, x86_64 apricots only available on armv7hl, s390x, x86_64 arduino only available on aarch64, armv7hl, x86_64 astromenace only available on aarch64, armv7hl, ppc64le, x86_64 bcm283x-firmware only available on aarch64, armv7hl berusky2 only available on aarch64, armv7hl, x86_64 blender-luxcorerender only available on x86_64 bochs only available on aarch64, armv7hl, ppc64le, x86_64 bowtie only available on aarch64, ppc64le, s390x, x86_64 calibre only available on aarch64, armv7hl, x86_64 ceph only available on aarch64, ppc64le, s390x, x86_64 chromium only available on aarch64, x86_64 cmospwd only available on x86_64 coan only available on aarch64, armv7hl, ppc64le, x86_64 compiz-plugins-experimental only available on aarch64, armv7hl, ppc64le, x86_64 darktable only available on aarch64, ppc64le, x86_64 dvgrab only available on aarch64, armv7hl, ppc64le, x86_64 eclipse-egit only available on aarch64, ppc64le, s390x, x86_64 eclipse-findbugs only available on aarch64, ppc64le, s390x, x86_64 eclipse-jdt only available on aarch64, ppc64le, s390x, x86_64 eclipse-m2e-core only available on aarch64, ppc64le, s390x, x86_64 eclipse-mpc only available on aarch64, ppc64le, s390x, x86_64 eclipse-pde only available on aarch64, ppc64le, s390x, x86_64 eclipse-pydev only available on aarch64, ppc64le, s390x, x86_64 efax only available on aarch64, armv7hl, ppc64le, x86_64 falkon only available on aarch64, armv7hl, x86_64 fawkes only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-core only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-devel only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-doc only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-firevision only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-firevision-tools only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-guis only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-lua only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-bblogger only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-bbsync only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-flite only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-joystick only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-katana only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-laser only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-laser-lines only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-luaagent only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-pantilt only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-refboxcomm only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-skiller only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-ttmainloop only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-webview only available on aarch64, armv7hl, ppc64le, x86_64 fawkes-plugin-xmlrpc only available on aarch64, armv7hl, ppc64le, x86_64 ffado only available on aarch64, armv7hl, ppc64le, x86_64 firefox only available on aarch64, ppc64le, x86_64 flterm only available on aarch64, armv7hl, ppc64le, x86_64 fprintd-pam only available on aarch64, armv7hl, ppc64le, x86_64 freetennis only available on aarch64, armv7hl, ppc64le, x86_64 frescobaldi only available on aarch64, armv7hl, x86_64 ghdl only available on aarch64, ppc64le, s390x, x86_64 gnucash only available on aarch64, armv7hl, ppc64le, x86_64 grub2-tools-efi only available on x86_64 gvfs-afc only available on aarch64, armv7hl, ppc64le, x86_64 hedgewars only available on aarch64, armv7hl, ppc64le, x86_64 hlint only available on aarch64, ppc64le, x86_64 hyperv-daemons only available on x86_64 ibus-mozc only available on aarch64, armv7hl, ppc64le, x86_64 icaro only available on aarch64, armv7hl, ppc64le, x86_64 irqbalance only available on aarch64, armv7hl, ppc64le,
Re: The future of legacy BIOS support in Fedora.
On 30.6.2020 17:15, Gerd Hoffmann wrote: Hi, So I can't say I'm thrilled about a future that depends on EFI for virt, but I'm resigned to the fact this is the direction the world is taking. So we're not likely to have any choice and will have to work to mitigate any downsides it brings. Right. Preferably the installer should detect and setup the system either with sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI ) I have my doubts that building on sd-boot and drop grub2 is going to fly. Grub 2 cant be dropped anytime soon. One problem with sd-boot is that the kernels must stay on the ESP, which can be a problem for dual-boot installs (where Fedora has to run with the existing ESP and can't just create one which is big enouth). Hmm I dont follow people usually use multiple ESP partition for multiple os installs on the same hw so the size of one esp partion for one OS should not affect the other and there should nothing be preventing that from working except maybe some obscure hw bug from manufactures but I'm not a dual boot person so I would have to test that for myself to figure out any limitations it might have. Another problem is that grub2 covers more architectures than sd-boot. What is the plan for armhfp, ppc64, s390x? The first step ( change proposal ) would simply be about replace grub2 with sd-boot for UEFI strictly on the x86 architecture and see what issue are encountered, solve those then consider moving to different architectures and further integration if relevant. 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
python-reportlab: undefined-non-weak-symbol
Hi all. Are these `undefined-non-weak-symbol` expected in python-reportlab? https://pastebin.com/dRZUbpJx -- --- 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
python-reportlab: undefined-non-weak-symbol
Hi all. Are these `undefined-non-weak-symbol` expected in python-reportlab? https://pastebin.com/dRZUbpJx -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
Hi, On 6/30/20 5:48 PM, Vitaly Zaitsev via devel wrote: On 30.06.2020 15:25, Ben Cotton wrote: Better thermal management and peak performance on Intel CPUs by including thermald in the default install. Good, but thermald is absolutely useless without configs. Configs can be extracted from DPTF ACPI tables only with *proprietary* dptfextract utility. Also Fedora cannot ship extracted by dptfextract configs due to their legal status. That is the first time I have heard that. Do you have a source for that ? 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
Re: The future of legacy BIOS support in Fedora.
W dniu 30.06.2020 o 16:40, Daniel P. Berrangé pisze: > On Tue, Jun 30, 2020 at 04:32:44PM +0200, Marcin Juszkiewicz wrote: >> Can we also default to Q35 and forget that i440fx existed? >> >> Do all the pain in one step. > That's upto the various mgmt apps using libvirt to decide. Q35 > is *NOT* a drop-in replacement for i440fx. IOW if libvirt flipped > the switch existing mgmt apps would certainly break. For example, you > can't hotplug with Q35, unless the mgmt app pre-populated a bunch of > pcie-root-port devices. If the mgmt app is using IDE (eg for CDROM) > it'll break because Q35 requires SATA. There's various other areas > of pain. So we must let the mgmt apps decide when they are ready > to switch to use Q35 instead of i440fx. I am aware of those issues. AArch64 default mode is like Q35. Wrote few words about that in past: https://marcin.juszkiewicz.com.pl/2018/02/01/everyone-loves-90s-pc-hardware/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
