Re: rawhide - glibc/pthreads/... - broken pending mass rebuild?

2020-06-30 Thread Florian Weimer
* 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

2020-06-30 Thread Sumantro Mukherjee
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

2020-06-30 Thread Dennis Keefe
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

2020-06-30 Thread Tom Seewald
> 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

2020-06-30 Thread Chris Murphy
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

2020-06-30 Thread Nico Kadel-Garcia
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

2020-06-30 Thread bugzilla
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

2020-06-30 Thread bugzilla
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

2020-06-30 Thread bugzilla
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

2020-06-30 Thread bugzilla
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

2020-06-30 Thread bugzilla
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

2020-06-30 Thread Michael Catanzaro


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

2020-06-30 Thread Miro Hrončok

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

2020-06-30 Thread Tom Seewald
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

2020-06-30 Thread Chris Murphy
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.

2020-06-30 Thread Jóhann B . Guðmundsson

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

2020-06-30 Thread Stephen John Smoogen
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

2020-06-30 Thread Emmanuel Seyman
* 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

2020-06-30 Thread Jerry James
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.

2020-06-30 Thread Kevin Kofler
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

2020-06-30 Thread Jerry James
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

2020-06-30 Thread Neal Gompa
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.

2020-06-30 Thread Jóhann B . Guðmundsson

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.

2020-06-30 Thread Kevin Kofler
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?

2020-06-30 Thread 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


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

2020-06-30 Thread James Cassell
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.

2020-06-30 Thread nickysn
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

2020-06-30 Thread Kevin Kofler
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

2020-06-30 Thread bugzilla
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

2020-06-30 Thread Miro Hrončok

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

2020-06-30 Thread Alex Scheel
- 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

2020-06-30 Thread James Cassell
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

2020-06-30 Thread Tom Callaway
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.

2020-06-30 Thread Jóhann B . Guðmundsson

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

2020-06-30 Thread bugzilla
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

2020-06-30 Thread bugzilla
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

2020-06-30 Thread Justin Forbes
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

2020-06-30 Thread Neal Gompa
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

2020-06-30 Thread Justin Forbes
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.

2020-06-30 Thread nickysn
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

2020-06-30 Thread Nicolas Mailhot via devel
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

2020-06-30 Thread Neal Gompa
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

2020-06-30 Thread Zbigniew Jędrzejewski-Szmek
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

2020-06-30 Thread drago01
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.

2020-06-30 Thread Brian C. Lane
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

2020-06-30 Thread Antonio T. sagitter
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

2020-06-30 Thread Antonio T. sagitter
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

2020-06-30 Thread Michael Catanzaro
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

2020-06-30 Thread Stephen John Smoogen
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.

2020-06-30 Thread Jóhann B . Guðmundsson

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

2020-06-30 Thread Nicolas Mailhot via devel
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

2020-06-30 Thread Justin Forbes
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

2020-06-30 Thread Jerry James
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.

2020-06-30 Thread Jóhann B . Guðmundsson

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

2020-06-30 Thread Jared Dominguez
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.

2020-06-30 Thread Jóhann B . Guðmundsson

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

2020-06-30 Thread Igor Raits
-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

2020-06-30 Thread Iñaki Ucar
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

2020-06-30 Thread Igor Raits
-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

2020-06-30 Thread Vitaly Zaitsev via devel
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

2020-06-30 Thread Igor Raits
-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

2020-06-30 Thread Igor Raits
-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

2020-06-30 Thread Ben Cotton
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

2020-06-30 Thread Ben Cotton
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


Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

2020-06-30 Thread Ben Cotton
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 

RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

2020-06-30 Thread Ben Cotton
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.

2020-06-30 Thread Robbie Harwood
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

2020-06-30 Thread Ben Cotton
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

2020-06-30 Thread Ben Cotton
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

2020-06-30 Thread Ben Cotton
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

2020-06-30 Thread Ben Cotton
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

2020-06-30 Thread Robert-André Mauchin
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)

2020-06-30 Thread Miro Hrončok

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)

2020-06-30 Thread Miro Hrončok

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)

2020-06-30 Thread Kevin Fenzi
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.

2020-06-30 Thread PGNet Dev
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.

2020-06-30 Thread Mauricio Tavares
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)

2020-06-30 Thread Neal Gompa
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

2020-06-30 Thread Neal Gompa
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

2020-06-30 Thread Neal Gompa
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)

2020-06-30 Thread Miro Hrončok
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.

2020-06-30 Thread Tom Seewald
> 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

2020-06-30 Thread John M. Harris Jr
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

2020-06-30 Thread Scott Talbert

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.

2020-06-30 Thread John M. Harris Jr
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.

2020-06-30 Thread 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.


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

2020-06-30 Thread Ankur Sinha
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

2020-06-30 Thread Stasiek Michalski
> 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

2020-06-30 Thread Christopher
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.

2020-06-30 Thread Jiří Eischmann
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

2020-06-30 Thread John M. Harris Jr
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.

2020-06-30 Thread Jóhann B . Guðmundsson

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.

2020-06-30 Thread John M. Harris Jr
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.

2020-06-30 Thread John M. Harris Jr
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.

2020-06-30 Thread Robbie Harwood
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

2020-06-30 Thread Ian McInerney
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.

2020-06-30 Thread Jóhann B . Guðmundsson

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

2020-06-30 Thread Antonio T. sagitter
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

2020-06-30 Thread Antonio T. sagitter
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

2020-06-30 Thread Hans de Goede

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


  1   2   3   >