Re: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Daniel P . Berrangé
On Wed, Jul 01, 2020 at 12:01:08PM +0200, Vitaly Zaitsev via devel wrote:
> On 01.07.2020 11:28, Alexey A. wrote:
> > Stop using the L-word, please: BIOS is not "legacy", it's just
> > alternative way (one of many).
> 
> Using BIOS boot on UEFI-compatible systems is a legacy, because it works
> under the CSM compatibly layer.
> 
> More information about CSM you can find here:
> https://www.rodsbooks.com/efi-bootloaders/csm-good-bad-ugly.html

NB, with the OVMF UEFI firmware for KVM, there is *NO* CSM layer
provided.

IOW, If KVM is configured for UEFI, the guest OS must use UEFI boot;
if KVM is configured for legacy BIOS, the guest OS must use legacy BIOS.

Just something to be aware of if you're testing OS using KVM - it won't
replicate behaviour of bare metal UEFI setups with CSM.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Richard W.M. Jones
On Tue, Jun 30, 2020 at 04:25:58PM +0200, Marcin Juszkiewicz wrote:
> W dniu 30.06.2020 o 16:20, Tom Hughes via devel pisze:
> > On 30/06/2020 15:00, 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.
> > 
> > Good point. Certainly libvirt still defaults to legacy BIOS and I
> > don't think UEFI is even possible without manually editing the XML
> > definition for the machine.
> 
> New installs for x86-64 VM can be BIOS of UEFI for quite some years.
> For both i440fx and q35 variants. 
> 
> Migration from BIOS to UEFI would require edit of instance XML but
> should not be needed as you would not throw away working computer just
> because OS decided to not support it's method of booting.

If you mean migration of existing guests, then you need to repartition
them and reinstall the bootloader.  I doubt anyone has a practical
idea of how to do that either manually or automatically.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Tomasz Torcz
On Wed, Jul 01, 2020 at 08:03:11AM -0400, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha  wrote:
> >
> > On 6/30/20 9:35 PM, Igor Raits wrote:
> > > 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.
> > >
> >
> 
> I'll be honest, I don't get why this exists. Most folks expect this to
> be an aspect of UDisks, so why isn't it?

  Especially after http://storaged.org/ merge few years back.

-- 
Tomasz Torcz   “(…) today's high-end is tomorrow's embedded processor.”
to...@pipebreaker.pl  — Mitchell Blank on LKML
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Neal Gompa
On Wed, Jul 1, 2020 at 8:55 AM Stephen Gallagher  wrote:
>
> On Tue, Jun 30, 2020 at 9:03 PM Michael Catanzaro  
> wrote:
> >
> >
> > 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.
> >
>
> I think there has been a good deal of miscommunication on all sides
> (starting with me).
>
> What I was attempting to say in the first place was this: "It's not
> clear to me that this proposal has the blessing of the Workstation WG
> or Spins. I'm not willing to *assert* that they must do this work
> without hearing whether they are willing and have capacity to do so."
> I think I phrased this poorly initially.
>
> What I would like is just to have a statement added to the Change
> Proposal that "Workstation WG and the maintainers of Spins Foo, Bar
> and Baz are willing to make this the default if this Change Proposal
> is accepted." I just didn't want anyone getting *dictated* at without
> their input.

To me, this sounds weird, because the implication of this Change being
accepted is that we *would* do this. That's sort of the point of it.
The owners of the spins are listed as change owners because I talked
to all of them and they all accepted. I even have the pull request
ready for Anaconda to make the change as soon as the change is
accepted (I'm working on the other bits, kickstarts are
complicated...).

I would say that this is redundant with the statement that "the
default for new installs shall be btrfs" that is in the Change itself.

Nobody is being forced to do this in the manner I'm guessing you think.




--
真実はいつも一つ!/ 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: out of Koji disk space

2020-07-01 Thread Stephen John Smoogen
On Wed, 1 Jul 2020 at 08:09, Jan Kratochvil  wrote:
>
> On Wed, 01 Jul 2020 13:43:57 +0200, Stephen John Smoogen wrote:
> > In the end we have limited resources and you are running into those
> > limits. We can either have fewer builders with more disk space and a
> > long queue of builds or we can have more builders with smaller disk
> > space.
>
> Good to know disk space really is a limiting factor there (as it is in general
> cheap compared to CPUs+RAM).
>

Disk space is only cheap if you don't care about the speed or the
amount of usable disk space you have. [You can have a system with 200
TB of disk space from a bunch of 4TB sata disks but find that only 20
TB is speedy and the rest has a fall over in performance because none
of the drives or controllers have enough cache] Every time we have
tried to get larger disks, the amount of complaints for slow builders
goes up exponentially. Trying for other disk layouts to increase IO
ends up with other downtime complaints (oh look RAID-10 failed on 2
drives in the same pair.. there goes everything).

Disk space which meets the IO needs of builders ends up being as
expensive as CPU cores and RAM amounts. The faster the IO needs, the
smaller the disk space per disk. You can fix this by having more
disks, but the more disks per system, the higher the power and cooling
costs per system.

In the end, there is no such thing as a free lunch.


> Sure a best step would be to have multiple (two) kinds of builders with
> different disk sizes and blacklist/whitelist packages to them. I am aware that
> idea is obvious, is there a Koji patch needed or even administration of two
> kinds of builders is too much?
>

I believe we have done this in the past for the x86_64 arch. The s390,
ppc64le, and aarch64 architectures have exceedingly limited resources
to try this with. At the moment, we are still trying to bring up what
we had in PHX2 to IAD2.

At the moment, the sysadmin team for Fedora are running on fumes. We
have worked several months of 10+ hour days+weekends to make the move
a success and we will be working at least a month more to bring up the
rest of the servers. At the moment we have about 10% of the hardware
we shipped back in operation and there are at least 2 to 3 weeks to
get the rest up. Getting up larger builders is going to have to wait.

-- 
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: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Dominik 'Rathann' Mierzejewski
On Tuesday, 30 June 2020 at 21:19, 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.

That's not detailed at all. You should provide at least one example
here (or a direct link to one somewhere else on the wiki).

> == Benefit to Fedora ==
> 
> Autobumping removes a huge packager shore and makes timestamping in
  ^
Did you mean "chore"?

> changelogs more reliable.

What's "autobumping" here and how is it better than rpmdev-bumpsec?

[...]
> == 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/

A diff with changes and some explanation would be more accessible
than having to dig inside a copr repo.

Why is a separate "rpm-changelog.txt" file with manually maintained
changelog better than current manually maintained changelog inside .spec?

How about using git commit log for changelog instead?

[...]
> To get beautiful changelogs, you also need to add
> 
> 
> %buildsys_name  Your name
> %buildsys_email Your email
> 
> 
> in ~/.rpmmacros

What about having one macro called %buildsys_packager instead of two?
You're always using them together, anyway. It'd be similar to the
existing %packager macro, too.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Steven Whitehouse

Hi,

On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote:

So yes, I think an explicit "let's all test btrfs (as anaconda
configures it) before we make it default" period is warranted.

Perhaps one can argue that Fedora has already been doing that for the
past two years (since 2018-or-later-btrfs is what everyone with positive
results appears to be talking about), but it's still not clear that
those deployments utilize the same feature set as Fedora's defaults, and
how broad the hardware sample is.

Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34
could be good option. I know technically it is already opt-in, but it's not
very visible or popular. We could make the btrfs option more prominent and
ask people to pick it if they are ready to handle potential fallout.

Normally we just switch the default or we don't, without half measures. But
the fs is important enough and complicated enough to be extra careful about
any transitions.

Zbyszek
Indeed, it is an important point, and taking care is very important when 
dealing with other people's data, which is in effect what we are 
discussing here.


When we looked at btrfs support in RHEL, we took quite a long time over 
it. In fact I'm not quite sure how long, since the process had started 
before I was involved, but it was not a decision that was made quickly, 
and a great deal of thought went into it. It was difficult to get 
concrete information about the stability aspects at the time. Just like 
the discussions that have taken place on this thread, there was a lot of 
anecdotal evidence, but that is not always a good indicator. Since time 
has passed since then, and there is now more evidence, this part of the 
process should be easier. That said to get a meaningful comparison then 
ideally one would want to compare on the basis of user populations of 
similar size and technical skill level, and look not just at the overall 
number of bugs reported, but at the rate those bugs are being reported too.


It is often tricky to be sure of the root cause of bugs - just because a 
filesystem reports an error doesn't mean that it is at fault, it might 
be a hardware problem, or an issue with volume management. Figuring out 
where the real problem lies is often very time consuming work. Without 
that work though, the raw numbers of bugs reported can be very misleading.


It is also worth noting that when we made the decision for RHEL it was 
not just a question of stability, although that is obviously an 
important consideration. We looked at a wide range of factors, including 
the overall design and features. We had reached out to a number of 
potential users and asked them what features they wanted from their 
filesystems and tried to understand where we had gaps in our existing 
offerings. It would be worth taking that step here, and asking each of 
the spins what are the features that they would most like to see from 
the storage/fs stack. Comparing filesystems in the abstract is a 
difficult task, and it is much easier against a context. I know that 
some of the issues have already been discussed in this thread, but maybe 
if someone was to gather up a list of requirements from those messages 
then that would help to direct further discussion,


Steve.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Javier Martinez Canillas
On Wed, Jul 1, 2020 at 11:37 AM Lennart Poettering  wrote:

[snip]

>
> My suggestion would be: don't standardize on boot loaders, standardize
> on the boot loader spec. And I mean, the real boot loader spec, i.e

Agreed. In part that's already the case for Fedora, since now besides
GRUB the zipl (s390x) and Petitboot (ppc64le OPAL) bootloaders are
also using BLS snippets to populate their boot menu.

I don't see why one bootloader has to be dropped in favour of the
other, and not just allow users to choose what better fits their
needs.

Just like Anaconda currently provides an extlinux option to use as the
bootloader instead of GRUB for legacy BIOS installs, a sd-boot option
could be added to choose using this bootloader for EFI installs.

That way users who want a simple bootloader can use sd-boot and those
needing features like network boot, LUKS support, etc can choose to
use GRUB instead.

> not this terrible template language that Fedora now supports in Grub,
> which is just the same old grub complexity again. They stole the "Boot

Yes, not storing the kernel command line options in the BLS snippets
and using a GRUB variable was indeed a mistake that caused more harm
than good.

That has been fixed for F33, but there are other reasons why the GRUB
implementation needed variables. For instance to support
authentication and authorization of boot entries:

https://www.gnu.org/software/grub/manual/grub/html_node/Authentication-and-authorisation.html

But we can look at how the spec could be extended to cover that case
and stop using the templating for GRUB altogether to align with the
spec.

> Loader Spec" name and turned it into something that is not related at
> all to the real thing.
>

I'm not sure if this is completely fair, it's true that GRUB's blscfg
module diverged from the spec by adding support for variables but it
can also parse BLS snippets that follow the spec verbatim.

For example Fedora CoreOS uses it and the BLS snippets created by
OSTree are completely aligned with the spec as far as I can tell.
And since F33 I think that even the BLS snippets created for GRUB
could be parsed by sd-boot (or any other bootloader following the spec
like LinuxBoot)
since the options field doesn't have a variable anymore.

Best regards,
Javier
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: python-sphinx_rtd_theme update: comments requested

2020-07-01 Thread Miro Hrončok

On 01. 07. 20 2:07, Miro Hrončok wrote:

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.


I've worked on this in

https://src.fedoraproject.org/fork/churchyard/rpms/python-sphinx_rtd_theme/commits/generator

However, there is "tiny little problem" that makes it not work:

https://github.com/rpm-software-management/rpm/issues/1297

--
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-07-01 Thread Konstantin Kharlamov
On Sat, 2020-06-27 at 18:41 -0600, Chris Murphy wrote:
> On Sat, Jun 27, 2020 at 4:30 PM Konstantin Kharlamov 
> 
> > Good for you. But you're trying take take decision for all other peoples, so
> > you
> > need to take into account not everyone has NVMe or SSD. HDDs that many
> > people
> > are also using are much slower. This means your "1 second vs 0.5 second" can
> > easily turn into "5 seconds vs 10 seconds" (and not necessarily linearly).
> 
> I'm not making any claims about sysroot on HDD.

Okay, in this case, unless benchmarks prove BTRFS to be performant enough on HDD
are provided, I suggest the proposal should be modified to exclude HDDs from
being considered as a BTRFS target.

FWIW, I was just thinking about it, and I came up with example you may like
which shows exactly why BTRFS is bad for HDD. Consider development process. It
includes rewriting source files over and over: you do `git checkout foo` and
files are overwritten, you change a file in text editor, and it gets
overwritten. And since BTRFS is CoW, it will always write files to a new place.
As result, after some time, if you try to build the project, it gonna take much
longer time just because BTRFS has to read files from a bunch of different
places, and HDD are really bad at this.

If you take a non-CoW FS, this problem doesn't exist by design.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Stephen Gallagher
On Tue, Jun 30, 2020 at 9:03 PM Michael Catanzaro  wrote:
>
>
> 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.
>

I think there has been a good deal of miscommunication on all sides
(starting with me).

What I was attempting to say in the first place was this: "It's not
clear to me that this proposal has the blessing of the Workstation WG
or Spins. I'm not willing to *assert* that they must do this work
without hearing whether they are willing and have capacity to do so."
I think I phrased this poorly initially.

What I would like is just to have a statement added to the Change
Proposal that "Workstation WG and the maintainers of Spins Foo, Bar
and Baz are willing to make this the default if this Change Proposal
is accepted." I just didn't want anyone getting *dictated* at without
their input.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: module 'posix' not found when module load mpi/mpich-x86_64

2020-07-01 Thread Tom Callaway
Lmod needed a little patch to detect Lua 5.4 as a valid version, but it's
fixed and rebuilt in rawhide now (Lmod-8.3.17-2.fc33).

Thanks,
Tom

On Tue, Jun 30, 2020 at 6:24 PM Miro Hrončok  wrote:

> 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: out of Koji disk space

2020-07-01 Thread Stephen John Smoogen
On Wed, 1 Jul 2020 at 02:09, Jan Kratochvil  wrote:
>
> Hi,
>
> I have tried to enable debuginfo for Chromium but it cannot fit the disk.
> During local build it has 160GB (on x86_64) and Koji shows (moreover AFAIK
> shared for multiple builders):
> 
> https://kojipkgs.fedoraproject.org//work/tasks/7099/46377099/hw_info.log
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/vda2   138G   71G   67G  52% /
>
> Is there some way forward?
>
> In 2013:
> 
> https://lists.fedoraproject.org/pipermail/devel/2013-January/176673.html
> Looking at space we have, we are just going to bump them all to 150 or
> so. Hopefully that will keep us for a while.
>

In the end we have limited resources and you are running into those
limits. We can either have fewer builders with more disk space and a
long queue of builds or we can have more builders with smaller disk
space. We are especially limited during and after the move of hardware
because it takes a considerable amount of time to bring things back
up. People are going to have to be patient or find other ways to do
their work if that is not working. If this is not acceptable, please
bring it up with our management chain.

>
> Jan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
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: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

2020-07-01 Thread Fabio Valentini
On Tue, Jun 30, 2020 at 9:52 AM Jiri Vanek  wrote:
>
> On 6/29/20 1:59 PM, Aleksandar Kurtakov wrote:
> >
> >
> > On Mon, Jun 29, 2020 at 2:39 PM Jiri Vanek  > > wrote:
> >
> > Current stats from my testing samples:
> > 408 failing
> > 263 passing
> >
> >
> > Are these numbers reversed ^^^ ? Looking at
> > https://copr.fedorainfracloud.org/coprs/g/java-maint-sig/java-11-default/monitor/
> >  I see a bit more
> > than 200 ftbfs.
>
> I'm afraid not. But if you are right, then maybe I'm doing something wrong, 
> and it is all a bit more
> positive then I think.
>
> Thanx!

I don't know if I've set up the Java SIG COPR for Java 11 rebuilds
differently than you set up yours. Maybe you haven't incorporated the
xmvn-javadoc change yet? It could explain the ~200 additional build
failures.

Looking at the latest state in our COPR test repo, I see 202 failing
packages and 461 building packages, which isn't looking too bad
considering how the numbers looked at the start.

> Since f29, about 1000 java packages died or were orphaned. I was removing 
> packages where upstream is
> dead and are orphaned (so no chance to make them reliable working with 
> jdk11), and I found that
> wildfly, jenkins, jboss, half of maven plugins, elastic search, 
> apach-emina, infinispan, cassandra,
> hibernate All are dead. What is javastack for now (no blame or evil 
> in that)?
>
> So maybe the system jdk11 can be used as just last death-blow to java 
> stack, rethink it,  and stat
> rebuilding on pretty fresh field

Why? If nobody needs those packages and nobody wants to maintain them,
then they should stay dead.

Right now, the core Java stack (including everything that's necessary
to build itself) amounts to about 200 packages, which is already a lot
of packages for limited manpower (Stewardship SIG / Java SIG). Unless
somebody wants to step up (or Red Hat actually wants its Java projects
packaged for fedora again), this is not going to change, I'm afraid.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Neal Gompa
On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha  wrote:
>
> On 6/30/20 9:35 PM, Igor Raits wrote:
> > 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 

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-07-01 Thread Peter Oliver

On Wed, 1 Jul 2020, Richard W.M. Jones wrote:


It has key bindings that are quite unlike any other program


Well, any other program that a newcomer is nowadays reasonably likely to be 
familiar with.  The keybindings are from the Pico text editor, and the Pine and 
Alpine email clients.

--
Peter Oliver
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Richard W.M. Jones
On Tue, Jun 30, 2020 at 10:30:21AM -0400, Owen Taylor wrote:
> So, this was discussed quite a bit in
> https://pagure.io/fedora-workstation/issue/71 and the conclusion that
> the Workstatopn Working Group came to 3 months ago was that we didn't
> want to do this. We basically understood that main way of using
> thermald was to use the proprietary dptfxtract tool to extract a
> profile from ACPI - and as such, thermald wasn't something Fedora
> should install by default. This functionality can't be properly
> integrated into Fedora and "just work" for users if it requires a
> proprietary tool and extra steps.

Is there some background about why dptfxtract is proprietary?  (I see
that it's a program provided by Intel.)  Is it just because no one's
done the work to make a free equivalent or does it require some
secret/patented/whatever knowledge to work?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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-07-01 Thread Richard W.M. Jones
On Tue, Jun 30, 2020 at 03:27:45PM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 30, 2020 at 04:00:00PM +0200, 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.
> 
> KVM virt on aarch64 and x86 can support EFI via AVMF / OVMF firmware
> built from the edk2 project from a technical POV.
> 
> The first challenge will be that many mgmt tools still default to
> using legacy BIOS when deploying guest OS. We've been trying to
> make it easier for mgmt apps to "do the right thing" by having
> libosinfo record metadata about whether each guest OS supports
> legacy BIOS, EFI or both. ie we want the mgmt apps to just pick
> EFI if they see the OS doesn't support legacy BIOS, instead of
> requiring users to manually tell them to use EFI.
> 
> Historically we've tended to discourage use of EFI on virt because,
> unless you wanted SecureBoot for your VMs, it hasn't offered much
> in the way of compelling benefits to users. The EDK2 project code
> is a much higher maint burden for virt than the seabios was, and
> there's no sign that situation will improve.

Also it's considerably slower to boot to the kernel, especially if you
enable debug messages on an emulated serial port which makes it almost
comically slow.

> 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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.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: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

2020-07-01 Thread Tom Hughes via devel

On 01/07/2020 11:53, Richard W.M. Jones wrote:

On Tue, Jun 30, 2020 at 10:30:21AM -0400, Owen Taylor wrote:

So, this was discussed quite a bit in
https://pagure.io/fedora-workstation/issue/71 and the conclusion that
the Workstatopn Working Group came to 3 months ago was that we didn't
want to do this. We basically understood that main way of using
thermald was to use the proprietary dptfxtract tool to extract a
profile from ACPI - and as such, thermald wasn't something Fedora
should install by default. This functionality can't be properly
integrated into Fedora and "just work" for users if it requires a
proprietary tool and extra steps.


Is there some background about why dptfxtract is proprietary?  (I see
that it's a program provided by Intel.)  Is it just because no one's
done the work to make a free equivalent or does it require some
secret/patented/whatever knowledge to work?


There is work being done to make thermald read the
tables from the BIOS directly, including supporting
more advanced features that dptfxtract doesn't. More
details here:

https://mjg59.dreamwidth.org/54923.html

and PR for thermald:

https://github.com/intel/thermal_daemon/pull/224

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Steven Whitehouse

Hi,

On 01/07/2020 12:09, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote:

Hi,

On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote:

So yes, I think an explicit "let's all test btrfs (as anaconda
configures it) before we make it default" period is warranted.

Perhaps one can argue that Fedora has already been doing that for the
past two years (since 2018-or-later-btrfs is what everyone with positive
results appears to be talking about), but it's still not clear that
those deployments utilize the same feature set as Fedora's defaults, and
how broad the hardware sample is.

Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34
could be good option. I know technically it is already opt-in, but it's not
very visible or popular. We could make the btrfs option more prominent and
ask people to pick it if they are ready to handle potential fallout.

Normally we just switch the default or we don't, without half measures. But
the fs is important enough and complicated enough to be extra careful about
any transitions.

Zbyszek

Indeed, it is an important point, and taking care is very important
when dealing with other people's data, which is in effect what we
are discussing here.

When we looked at btrfs support in RHEL, we took quite a long time
over it. In fact I'm not quite sure how long, since the process had
started before I was involved, but it was not a decision that was
made quickly, and a great deal of thought went into it. It was
difficult to get concrete information about the stability aspects at
the time. Just like the discussions that have taken place on this
thread, there was a lot of anecdotal evidence, but that is not
always a good indicator. Since time has passed since then, and there
is now more evidence, this part of the process should be easier.
That said to get a meaningful comparison then ideally one would want
to compare on the basis of user populations of similar size and
technical skill level, and look not just at the overall number of
bugs reported, but at the rate those bugs are being reported too.

Yeah. I have no doubt that the decision was made carefully back then.
That said, time has passed, and btrfs has evolved and our use cases
have evolved too, so a fresh look is good.

We have https://fedoraproject.org/wiki/Changes/DNF_Better_Counting,
maybe this could be used to collect some statistics about the fs type
too.


Yes, and also the questions that Fedora is trying to answer are 
different too. So I don't think that our analysis for RHEL is applicable 
here in general. The method that we went through, in general terms, may 
potentially be helpful.




It is often tricky to be sure of the root cause of bugs - just
because a filesystem reports an error doesn't mean that it is at
fault, it might be a hardware problem, or an issue with volume
management. Figuring out where the real problem lies is often very
time consuming work. Without that work though, the raw numbers of
bugs reported can be very misleading.
It would be worth taking that step here, and
asking each of the spins what are the features that they would most
like to see from the storage/fs stack. Comparing filesystems in the
abstract is a difficult task, and it is much easier against a
context. I know that some of the issues have already been discussed
in this thread, but maybe if someone was to gather up a list of
requirements from those messages then that would help to direct
further discussion,

Actually that part has been answered pretty comprehensively. The split
between / and /home is hurting users and we completely sidestep it
with this change. The change page lists a bunch of other benefits,
incl. better integration with the new resource allocation mechanisms
we have with cgroups2. So in a way this is a follow-up to the
cgroupsv2-by-default change in F31. Snapshots and subvolumes also give
additional powers to systemd-nspawn and other tools. I'd say that the
huge potential of btrfs is clear. It's the possibility of the loss of
stability that is my (and others') worry and the thing which is hard
to gauge.

Zbyszek


If the / and /home split is the main issue, then dm-thin might be an 
alternative solution, and we should check to see if some of the issues 
listed on the change page have been addressed. I'm copying in Jon for 
additional comment on that. Are those btrfs benefits which are listed on 
the change page in priority order?


File system resize is mentioned there, but pretty much all local 
filesystems support grow. Also, no use cases are listed for that 
benefit. Shrink is more tricky, and can easily result in poor file 
layouts, particularly if there are repeated grow/shrink operations, not 
to mention potential complications with NFS if the fs is exported. So is 
there some specific use case there that cannot be supported easily with 
the existing tools? There 

Re: out of Koji disk space

2020-07-01 Thread Kamil Dudka
On Wednesday, July 1, 2020 2:00:09 PM CEST Jan Kratochvil wrote:
> On Wed, 01 Jul 2020 13:43:57 +0200, Stephen John Smoogen wrote:
> 
> > In the end we have limited resources and you are running into those
> > limits. We can either have fewer builders with more disk space and a
> > long queue of builds or we can have more builders with smaller disk
> > space.
> 
> 
> Good to know disk space really is a limiting factor there (as it is in
> general cheap compared to CPUs+RAM).
> 
> Sure a best step would be to have multiple (two) kinds of builders with
> different disk sizes and blacklist/whitelist packages to them.

I like the idea but would suggest to rather implement denylist/allowlist
so that someone does not have to rename those lists later on:

https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language

Kamil

> I am aware that
> idea is obvious, is there a Koji patch needed or even administration
> of two kinds of builders is too much?
> 
> 
> Jan

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Jóhann B . Guðmundsson

On 1.7.2020 09:36, Lennart Poettering wrote:

On Di, 30.06.20 19:15, Gerd Hoffmann (kra...@redhat.com) 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.

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).

Nah, that's not true. Hasn't been for quite a while.

sd-boot checks for kernels in the ESP first, and then on a second
partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR
partition is simply a partition with type UUID
bc13c2ff-59e6-4262-a352-b275fd6f7172.

This means installers have two options:

1. Create a large ESP and just use that. Everything is nice and simple

2. If the ESP already exists and there's no interest in growing it,
just add in an XBOOTLDR partition and use that instead.



The latter (2) is presumably what manufactures would want OS and their 
installers to default to.


As in don't destroy or resize ( which could risk destroying it ) the 
existing ESP that comes from the factory and may contain manufacturers 
specific tools instead keep it as it is and place only the boot manager 
( sd-boot ) on the existing ESP while OS specific kernels ( and any 
other stuff the OS might want to place on the ESP ) is placed on a 
separate XBOOTLDR partition.


The above is probably also the best compatibility scenario for dual boot 
or multi boot scenarios.






Another problem is that grub2 covers more architectures than sd-boot.
What is the plan for armhfp, ppc64, s390x?

sd-boot is uefi only, but it should work fine with any arch that is
supported by uefi.


IMHO a better preparation for deprecating BIOS would be to make new
installs bootable with both BIOS and UEFI.  Which isn't hard at least
for the "[x] use all space" case where Fedora can partition the disk as
it pleases:  Use gpt.  Create a bios boot partition, install grun-pc
there.  Create a ESP partition, install grub-efi there.  Create a
partition for the /boot filesystem.  Have both grubs pick up BLS config
from /boot/loader.

My suggestion would be: don't standardize on boot loaders, standardize
on the boot loader spec. And I mean, the real boot loader spec, i.e
not this terrible template language that Fedora now supports in Grub,
which is just the same old grub complexity again. They stole the "Boot
Loader Spec" name and turned it into something that is not related at
all to the real thing.

Supporting the boot loader spec has various benefits, including that
systemd's "systemctl kexec" will just work and understand these tiems.

Yeah I was going to look at that as well ( how far off Fedora is from 
the boot loader specification and where it's going off the rails ) while 
I'm looking at this.



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-07-01 Thread Hans de Goede

Hi,

On 6/30/20 8:29 PM, 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 ).


So instead of replacing grub2 you are suggesting adding sd-boot to the
list of supported boot-loaders and using it as the default bootloader
on x86_64 UEFI installs, correct ?

I'm not in the bootloader-team, but I do work very closely with them,
so I have only one question: who is going to pick up the extra
maintenance load this is going to cause ?

Note this might sound like me being a bit snarky, but that is not
my intention here. This is a serious question and without a good
answer to that question I believe that any proposal to add sd-boot
to the list of supported bootloaders is pretty much dead in the
water.

Also note that this entails a lot more work then just maintaining sd-boot,
anaconda will need to be adjusted, kernel-install scripts will need to
be adjusted, etc. And what about upgrades, if upgrades stick with using grub2
then now we have 3 bootloader configs, including things like documentation on
how to change kernel commandline options, to maintain instead of 2.

Also I wonder, if you are not proposing to completely drop grub2 on x86_64
what does offering sd-boot in addition to grub2 actually offer as advantages?

sd-boot is simpler and a bit tighter integrated with systemd, which would
mean it is less work to maintain if we use it instead of grub, but if we
use it next to grub then all those advantages fall away. IOW if we use
it next to grub then all I see is a whole lot of extra work, with very
little gain.

AFAIK this (lot of extra work, very little gain) is exactly why we have
been sticking with grub2 so far. We need to maintain it anyway, at which
point we want to use it in as much cases as possible so that we can have
unified code and documentation for dealing with the bootloader.

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

2020-07-01 Thread Aleksandar Kurtakov
Fabio, does it mean that the Java SIG agrees with progressing with the
Change to Java 11 as a default?

On Wed, Jul 1, 2020 at 4:02 PM Fabio Valentini  wrote:

> On Tue, Jun 30, 2020 at 9:52 AM Jiri Vanek  wrote:
> >
> > On 6/29/20 1:59 PM, Aleksandar Kurtakov wrote:
> > >
> > >
> > > On Mon, Jun 29, 2020 at 2:39 PM Jiri Vanek  jva...@redhat.com>> wrote:
> > >
> > > Current stats from my testing samples:
> > > 408 failing
> > > 263 passing
> > >
> > >
> > > Are these numbers reversed ^^^ ? Looking at
> > >
> https://copr.fedorainfracloud.org/coprs/g/java-maint-sig/java-11-default/monitor/
> I see a bit more
> > > than 200 ftbfs.
> >
> > I'm afraid not. But if you are right, then maybe I'm doing something
> wrong, and it is all a bit more
> > positive then I think.
> >
> > Thanx!
>
> I don't know if I've set up the Java SIG COPR for Java 11 rebuilds
> differently than you set up yours. Maybe you haven't incorporated the
> xmvn-javadoc change yet? It could explain the ~200 additional build
> failures.
>
> Looking at the latest state in our COPR test repo, I see 202 failing
> packages and 461 building packages, which isn't looking too bad
> considering how the numbers looked at the start.
>
> > Since f29, about 1000 java packages died or were orphaned. I was
> removing packages where upstream is
> > dead and are orphaned (so no chance to make them reliable working
> with jdk11), and I found that
> > wildfly, jenkins, jboss, half of maven plugins, elastic search,
> apach-emina, infinispan, cassandra,
> > hibernate All are dead. What is javastack for now (no blame or
> evil in that)?
> >
> > So maybe the system jdk11 can be used as just last death-blow to
> java stack, rethink it,  and stat
> > rebuilding on pretty fresh field
>
> Why? If nobody needs those packages and nobody wants to maintain them,
> then they should stay dead.
>
> Right now, the core Java stack (including everything that's necessary
> to build itself) amounts to about 200 packages, which is already a lot
> of packages for limited manpower (Stewardship SIG / Java SIG). Unless
> somebody wants to step up (or Red Hat actually wants its Java projects
> packaged for fedora again), this is not going to change, I'm afraid.
>
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Vitaly Zaitsev via devel
On 01.07.2020 11:28, Alexey A. wrote:
> Stop using the L-word, please: BIOS is not "legacy", it's just
> alternative way (one of many).

Using BIOS boot on UEFI-compatible systems is a legacy, because it works
under the CSM compatibly layer.

More information about CSM you can find here:
https://www.rodsbooks.com/efi-bootloaders/csm-good-bad-ugly.html

-- 
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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-01 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote:
> Hi,
> 
> On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote:
> >On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote:
> >>So yes, I think an explicit "let's all test btrfs (as anaconda
> >>configures it) before we make it default" period is warranted.
> >>
> >>Perhaps one can argue that Fedora has already been doing that for the
> >>past two years (since 2018-or-later-btrfs is what everyone with positive
> >>results appears to be talking about), but it's still not clear that
> >>those deployments utilize the same feature set as Fedora's defaults, and
> >>how broad the hardware sample is.
> >Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34
> >could be good option. I know technically it is already opt-in, but it's not
> >very visible or popular. We could make the btrfs option more prominent and
> >ask people to pick it if they are ready to handle potential fallout.
> >
> >Normally we just switch the default or we don't, without half measures. But
> >the fs is important enough and complicated enough to be extra careful about
> >any transitions.
> >
> >Zbyszek
> Indeed, it is an important point, and taking care is very important
> when dealing with other people's data, which is in effect what we
> are discussing here.
> 
> When we looked at btrfs support in RHEL, we took quite a long time
> over it. In fact I'm not quite sure how long, since the process had
> started before I was involved, but it was not a decision that was
> made quickly, and a great deal of thought went into it. It was
> difficult to get concrete information about the stability aspects at
> the time. Just like the discussions that have taken place on this
> thread, there was a lot of anecdotal evidence, but that is not
> always a good indicator. Since time has passed since then, and there
> is now more evidence, this part of the process should be easier.
> That said to get a meaningful comparison then ideally one would want
> to compare on the basis of user populations of similar size and
> technical skill level, and look not just at the overall number of
> bugs reported, but at the rate those bugs are being reported too.

Yeah. I have no doubt that the decision was made carefully back then.
That said, time has passed, and btrfs has evolved and our use cases
have evolved too, so a fresh look is good.

We have https://fedoraproject.org/wiki/Changes/DNF_Better_Counting,
maybe this could be used to collect some statistics about the fs type
too.

> It is often tricky to be sure of the root cause of bugs - just
> because a filesystem reports an error doesn't mean that it is at
> fault, it might be a hardware problem, or an issue with volume
> management. Figuring out where the real problem lies is often very
> time consuming work. Without that work though, the raw numbers of
> bugs reported can be very misleading.

> It would be worth taking that step here, and
> asking each of the spins what are the features that they would most
> like to see from the storage/fs stack. Comparing filesystems in the
> abstract is a difficult task, and it is much easier against a
> context. I know that some of the issues have already been discussed
> in this thread, but maybe if someone was to gather up a list of
> requirements from those messages then that would help to direct
> further discussion,

Actually that part has been answered pretty comprehensively. The split
between / and /home is hurting users and we completely sidestep it
with this change. The change page lists a bunch of other benefits,
incl. better integration with the new resource allocation mechanisms
we have with cgroups2. So in a way this is a follow-up to the
cgroupsv2-by-default change in F31. Snapshots and subvolumes also give
additional powers to systemd-nspawn and other tools. I'd say that the
huge potential of btrfs is clear. It's the possibility of the loss of
stability that is my (and others') worry and the thing which is hard
to gauge.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Neal Gompa
On Wed, Jul 1, 2020 at 4:55 AM Richard W.M. Jones  wrote:
>
>
> I might support this, but Nano is a terrible editor.  It has key
> bindings that are quite unlike any other program and conflict with
> normal bindings that newbies might be used to (eg. ^X is cut, not exit).
>
> If we're going to newbies how about a more MS-DOS-ish experience, eg:
>
>   https://en.wikipedia.org/wiki/LE_(text_editor)
>

Oh man, that takes me back! I started on DOS with the MS-DOS Editor,
then went onto the DOS port of Emacs and using DJGPP, then jumped to
Linux years later...



-- 
真実はいつも一つ!/ 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: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Peter Rajnoha
On 6/30/20 9:35 PM, Igor Raits wrote:
> 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

Re: out of Koji disk space

2020-07-01 Thread Jan Kratochvil
On Wed, 01 Jul 2020 13:43:57 +0200, Stephen John Smoogen wrote:
> In the end we have limited resources and you are running into those
> limits. We can either have fewer builders with more disk space and a
> long queue of builds or we can have more builders with smaller disk
> space.

Good to know disk space really is a limiting factor there (as it is in general
cheap compared to CPUs+RAM).

Sure a best step would be to have multiple (two) kinds of builders with
different disk sizes and blacklist/whitelist packages to them. I am aware that
idea is obvious, is there a Koji patch needed or even administration of two
kinds of builders is too much?


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

2020-07-01 Thread Ben Cotton
On Tue, Jun 30, 2020 at 6:30 PM Kevin Kofler  wrote:
>
> 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 don't disagree, but if that's not available, this is the best we
have. And it's tunable (or easy to disable) for people who don't want
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?
>
Because I was the one who said "hey, let's do this." :-) It was
discussed on the KDE mailing list prior to submission.

-- 
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


Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-07-01 Thread Jonathan Wakely

On 01/07/20 09:54 +0100, Richard W.M. Jones wrote:


I might support this, but Nano is a terrible editor.  It has key
bindings that are quite unlike any other program and conflict with
normal bindings that newbies might be used to (eg. ^X is cut, not exit).

If we're going to newbies how about a more MS-DOS-ish experience, eg:

 https://en.wikipedia.org/wiki/LE_(text_editor)


https://micro-editor.github.io/ was also suggested.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: out of Koji disk space

2020-07-01 Thread Richard W.M. Jones
On Wed, Jul 01, 2020 at 02:00:09PM +0200, Jan Kratochvil wrote:
> On Wed, 01 Jul 2020 13:43:57 +0200, Stephen John Smoogen wrote:
> > In the end we have limited resources and you are running into those
> > limits. We can either have fewer builders with more disk space and a
> > long queue of builds or we can have more builders with smaller disk
> > space.
> 
> Good to know disk space really is a limiting factor there (as it is in general
> cheap compared to CPUs+RAM).
>
> Sure a best step would be to have multiple (two) kinds of builders
> with different disk sizes and blacklist/whitelist packages to
> them. I am aware that idea is obvious, is there a Koji patch needed
> or even administration of two kinds of builders is too much?

I know from the RISC-V Koji instance that given enough permissions it
is possible to direct jobs to particular build hosts.  We do it
manually for jobs we know will be very large/long (hello there gcc!)

Maybe a way to direct jobs based on regexp of their name would be a
useful feature to propose/implement upstream?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Stephen John Smoogen
On Wed, 1 Jul 2020 at 07:19, Zbigniew Jędrzejewski-Szmek
 wrote:
>

> Yeah. I have no doubt that the decision was made carefully back then.
> That said, time has passed, and btrfs has evolved and our use cases
> have evolved too, so a fresh look is good.
>
> We have https://fedoraproject.org/wiki/Changes/DNF_Better_Counting,
> maybe this could be used to collect some statistics about the fs type
> too.
>

I am going to try and nix this one in the bud right here. DNF counting
is NOT the place to do this.

Starting to collect such information is a slippery slope and the more
you collect the harder it is to remove personal  identifiable data. If
this sort of data is going to be collected it needs to be done by a
specific program that does this, which can be audited, which can be
deleted, and which can be 'cleaned' to meet GDPR and other rules. The
DNF counting works because all it does is give a 'better guess' on
what is going on by randomly burping a countme over a week (if countme
is turned on). The data it collects in the end is not absolute but
fuzzy.. it is just supposedly better a better fuzzy than the previous
guesses.

The other information gathered in that transaction is stuff that
already has a business need to work.. our servers need to know what
architecture, what release and what ip to send data the appropriate
mirrorlist back to.. we also need to keep a log of the transaction to
debug why XYZ proxy decided to send the wrong thing or some other
issue.

Mirrormanager does not have a need to know what filesystem you are
using, it does not need to know what exact CPU, memory amount, or a
bunch of other things which would be useful for the project. Even
something like the packages you have installed which is sort of
closely aligned with a business need that other distros do collect, it
does not collect and adding it now would be a headache.

If the project wants this, then someone needs to make a smolt
replacement but with some people who truly understand privacy
programming well enough to not end up with a landmine field.

-- 
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: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Peter Rajnoha
On 7/1/20 9:50 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jun 30, 2020 at 03:18:57PM -0400, Ben Cotton wrote:
>> == 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
> 
> This sounds interesting. Assembling complex storage from udev rules is
> not easy, in particular because while it is easy to collect devices
> and handle the case where all awaited devices have been detected, it's
> much harder to do timeouts or partial assembly or conditional
> handling. A daemon can listen to hotplug events and have an internal
> state take decisions based on configuration and time and events.
> 

Exactly, that's also one of the areas we'd like to cover here - partial
activations based on policies. This is hard to do within pure udev... or at
least, at the moment, we'd need to put together several *external* pieces
together besides udev to make this working somehow at least. SID will try to
provide the infrastructure to implement this in one place.

> OTOH, based on this description, SID seems to want to take on some
> bigger role, e.g. by providing an alternate execution and device
> description mechanism. That sounds unnecessary (since udev does that
> part reasonably well) and complex (also because support would have to
> be added to consumers who currently get this data from udev). I would
> love to see a daemon to handle storage devices, but with close
> cooperation with udev and filling in the bits that udev cannot provide.
>
Not quite. If it sounds that SID is taking over most of udev's responsibility,
then no. It's trying to build on top of it - still considering udev as
low-level layer for event processing based on simple rules. Then SID adding
abstraction that we need for storage mainly - that is the grouping part, state
recording and delayed trigger/action part.

The issue with udev is that it's concentrated on single device processing and
on current state (yes, we have IMPORT{db}, but that's good for simple records
only). But this is OK as it is a low-level tool.

Also, udev's primary job is to record these single device properties and then
to create the /dev content so these devs are accessible. But there are actions
we don't need to execute within udev context at all - e.g. the device
activation itself. And there are other details where we come short with udev
like the udev rule language itself so if you need to define more complex
logic, you need to call out external commands to do that (and that is just
another fork, just another delay). Even comparing values of two variables is
not possible in udev (you can compare only with a literal constant).

With SID, for backwards compatibility and for udev db readers, we have still
the possibility to export selected information from SID to udev db, if needed
(importing and exporting from/to udev environment is just about using
dedicated namespace we have in SID db). But I think storage subsystems would
go for SID directly if it provides this domain specific information - it's
just adding more details to what udev can see.

What I would probably like to see in the future though is surely a more closer
cooperation of udevd and SID in a way where udevd could still record those
simple generic single device properties as it does today and if it sees that
this is a device that falls under certain domain (like "storage" here), udevd
itself can contact the domain-specific daemon/resource for more information
and then provide that through its interface. Similar logic could apply for
"network" domain, etc. All these domain-specific external resources could be
registered with udevd. But this is for later time and much more discussion...

>> * 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)
> I don't think such timeouts are common. Currently the default worker
> timeout is 180s, and this should be enough to handle any device hotplug
> event. And 

[SONAME BUMP] aom version 2.0.0

2020-07-01 Thread Robert-André Mauchin
Hi,

I intend to bump the SONAME of libaom from 0 to 2 next week.

Affected packages are the following:


PACKAGE DEPENDENT   
   DEPENDENCIES
libaom-1.0.0-9.20190810git9666276.fc32.x86_64   go-avif-0.1.0-4.fc32.x86_64 
   libaom.so.0()(64bit)

gstreamer1-plugins-bad-free-1.17.1-1.fc33.x86_64   libaom.so.0()(64bit)

cinelerra-gg-5.1-58.20191231git3878a69.fc32.x86_64 libaom.so.0()(64bit)

ffmpeg-libs-4.2.2-5.fc32.x86_64libaom.so.0()(64bit)

vlc-core-1:3.0.9.2-3.fc32.x86_64   libaom.so.0()(64bit)

xine-lib-1.2.10-3.fc32.x86_64  libaom.so.0()(64bit)



I'll bump gstreamer1-plugins-bad-free and go-avif in Fedora 
and seek the help of Leigh for the RPMFusion side.


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


Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-01 Thread Josef Bacik

On 7/1/20 7:49 AM, Steven Whitehouse wrote:

Hi,

On 01/07/2020 12:09, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote:

Hi,

On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote:

So yes, I think an explicit "let's all test btrfs (as anaconda
configures it) before we make it default" period is warranted.

Perhaps one can argue that Fedora has already been doing that for the
past two years (since 2018-or-later-btrfs is what everyone with positive
results appears to be talking about), but it's still not clear that
those deployments utilize the same feature set as Fedora's defaults, and
how broad the hardware sample is.

Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34
could be good option. I know technically it is already opt-in, but it's not
very visible or popular. We could make the btrfs option more prominent and
ask people to pick it if they are ready to handle potential fallout.

Normally we just switch the default or we don't, without half measures. But
the fs is important enough and complicated enough to be extra careful about
any transitions.

Zbyszek

Indeed, it is an important point, and taking care is very important
when dealing with other people's data, which is in effect what we
are discussing here.

When we looked at btrfs support in RHEL, we took quite a long time
over it. In fact I'm not quite sure how long, since the process had
started before I was involved, but it was not a decision that was
made quickly, and a great deal of thought went into it. It was
difficult to get concrete information about the stability aspects at
the time. Just like the discussions that have taken place on this
thread, there was a lot of anecdotal evidence, but that is not
always a good indicator. Since time has passed since then, and there
is now more evidence, this part of the process should be easier.
That said to get a meaningful comparison then ideally one would want
to compare on the basis of user populations of similar size and
technical skill level, and look not just at the overall number of
bugs reported, but at the rate those bugs are being reported too.

Yeah. I have no doubt that the decision was made carefully back then.
That said, time has passed, and btrfs has evolved and our use cases
have evolved too, so a fresh look is good.

We have https://fedoraproject.org/wiki/Changes/DNF_Better_Counting,
maybe this could be used to collect some statistics about the fs type
too.


Yes, and also the questions that Fedora is trying to answer are different too. 
So I don't think that our analysis for RHEL is applicable here in general. The 
method that we went through, in general terms, may potentially be helpful.




It is often tricky to be sure of the root cause of bugs - just
because a filesystem reports an error doesn't mean that it is at
fault, it might be a hardware problem, or an issue with volume
management. Figuring out where the real problem lies is often very
time consuming work. Without that work though, the raw numbers of
bugs reported can be very misleading.
It would be worth taking that step here, and
asking each of the spins what are the features that they would most
like to see from the storage/fs stack. Comparing filesystems in the
abstract is a difficult task, and it is much easier against a
context. I know that some of the issues have already been discussed
in this thread, but maybe if someone was to gather up a list of
requirements from those messages then that would help to direct
further discussion,

Actually that part has been answered pretty comprehensively. The split
between / and /home is hurting users and we completely sidestep it
with this change. The change page lists a bunch of other benefits,
incl. better integration with the new resource allocation mechanisms
we have with cgroups2. So in a way this is a follow-up to the
cgroupsv2-by-default change in F31. Snapshots and subvolumes also give
additional powers to systemd-nspawn and other tools. I'd say that the
huge potential of btrfs is clear. It's the possibility of the loss of
stability that is my (and others') worry and the thing which is hard
to gauge.

Zbyszek


If the / and /home split is the main issue, then dm-thin might be an alternative 
solution, and we should check to see if some of the issues listed on the change 
page have been addressed. I'm copying in Jon for additional comment on that. Are 
those btrfs benefits which are listed on the change page in priority order?


File system resize is mentioned there, but pretty much all local filesystems 
support grow. Also, no use cases are listed for that benefit. Shrink is more 
tricky, and can easily result in poor file layouts, particularly if there are 
repeated grow/shrink operations, not to mention potential complications with NFS 
if the fs is exported. So is there some specific use case there that cannot be 

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-01 Thread Nicolas Mailhot via devel
Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-Szmek
a écrit :
> 
> Actually that part has been answered pretty comprehensively. The
> split between / and /home is hurting users 

Actually this split is a godsend because you can convince anaconda to
leave your home alone when reinstalling, while someone always seems too
invent a new Fedora change that justifies the reformatting of /.

Good luck dealing with user data the next time workstation (or any
other group) feels the / filesystem should change, once you've put user
data on the same mount point

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: out of Koji disk space

2020-07-01 Thread Kevin Fenzi
On Wed, Jul 01, 2020 at 03:38:26PM +0200, Jan Kratochvil wrote:
> On Wed, 01 Jul 2020 15:14:09 +0200, Stephen John Smoogen wrote:
> > At the moment we have about 10% of the hardware
> > we shipped back in operation and there are at least 2 to 3 weeks to
> > get the rest up. Getting up larger builders is going to have to wait.
> 
> Sure there is no hurry with larger builders. I watch this problem of missing
> debuginfo for years.

So, there's a lot of things we could do here... but I'd like to know
more details:

* Is this only on x86_64 that you need this? Or all arches?
* you're guessing you need 160GB? Is that pretty accurate?

The space on the builders currently has been somewhat constrained by the
space we have available along with a desire to keep things pretty
similar so we don't have 'special' machines. 

Of course thats already out the window as different arches and all the
buildhw's are different machines. 

Short term we can probibly spin up a x86_64 builder with more disk space
and direct chromium scratch builds there? Or... the buildhw-x86*
machines actually have more disk than the buildvm-x86 vm's... but it's
not fully allocated. I can fix that and they would have ~300GB or so
each, would that be enough? in that case you could submit and cancel
until you got a buildhw-x86 ? 

Finally as people mentioned upthread, koji has a concept called
'channels'. We already have a number of them. The hub has a policy
config that can direct things to builders subscribed to specific
channels. For example, all the livemedia tasks run on hosts in the
livemedia channel. 

Before the move I created a 'heavybuilder' channel for chromium
(official builds). This is because our normal aarch64 buildvm's take
about 24-30 hours to build it, but we have 2 buildhw-a64's that have a
ton of cpu and memory (but not much disk space so we can't put a lot of
vm's on them). I just yesterday got this resetup. These builders take an
hour or two to build aarch64 chromium. 

Anyhow, I'd suggest filing an infrastructure ticket with your needs and
we can see what we can come up with either short or long term for you. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

2020-07-01 Thread Michael Catanzaro
On Wed, Jul 1, 2020 at 5:49 pm, Vitaly Zaitsev via devel 
 wrote:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D4FVY3LLMNGUKNUOEIDXNOOAD577W5XN/



None of the comments in that thread support the claim that we cannot 
ship configuration files generated by dptfxtract. (That said, as the 
current version of the change proposal doesn't propose doing so, it's a 
bit of a moot point.)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Michael Catanzaro
On Wed, Jul 1, 2020 at 6:35 am, Zbigniew Jędrzejewski-Szmek 
 wrote:

'sudo dnf install micro' ;)


It seems to work nicely. I especially like the standard keyboard 
shortcuts. I can't figure out how to Undo in nano, but in micro I just 
Ctrl+Z. I have not much opinion on whether we should use this vs. nano.


I notice that when I copy text it instructs me to "install xclip for 
external clipboard." That's not OK since xclip won't do anything in 
Wayland. Could be avoided by checking $DISPLAY before printing the 
message.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Vojtěch Trefný


On 2020-07-01 14:03, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha  wrote:
>>
>> On 6/30/20 9:35 PM, Igor Raits wrote:
>>> 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 

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

2020-07-01 Thread Vojtěch Trefný


On 2020-07-01 15:43, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 9:40 AM Peter Rajnoha  wrote:
>>
>> On 7/1/20 2:03 PM, Neal Gompa wrote:
>>> On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha  wrote:

 On 6/30/20 9:35 PM, Igor Raits wrote:
> 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
>> 

Re: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Lennart Poettering
On Mi, 01.07.20 00:38, Kevin Kofler (kevin.kof...@chello.at) wrote:

> In addition, as far as I know, systemd-boot is not compatible with the
> "Secure Boot" shim.

You are wrong. It is.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Alek Paunov

On 2020-06-30 14:34, Jóhann B. Guðmundsson wrote:
Share your thoughts and comments on how such move might affect you so 
feedback can be collected for the future on why such a change might be 
bad, how it might affect the distribution and scope of such change can 
be determined for potential system wide proposal.




Just in case if someone is not aware: syslinux (pxe, ext) shipped with 
Fedora is in very good state - form about 2016 I am using the package 
for all my booting needs (grub2 is too complex for me):


 * PXE/Legacy,UEFI
 * Physical (partition) Legacy, ESP-UEFI
 * VM Legacy - for VMs (and USB sticks) usually it is not even needed
   to partition the VM disk, just extlinux the VM FS volume.
   I do not tried VM/UEFI so far.

so (in my experience) any instance will have easy switchable 
UEFI/Non-UEFI boot option even if the other bootloaders discontinue 
legacy mode support.


I do not know if syslinux/extlinux have support in Anaconda, since I am 
not using Anaconda for my imaging needs.


Kind Regards,
Alek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-01 Thread Neal Gompa
On Wed, Jul 1, 2020 at 10:26 AM Nicolas Mailhot via devel
 wrote:
>
> Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-Szmek
> a écrit :
> >
> > Actually that part has been answered pretty comprehensively. The
> > split between / and /home is hurting users
>
> Actually this split is a godsend because you can convince anaconda to
> leave your home alone when reinstalling, while someone always seems too
> invent a new Fedora change that justifies the reformatting of /.
>
> Good luck dealing with user data the next time workstation (or any
> other group) feels the / filesystem should change, once you've put user
> data on the same mount point
>

Anaconda does this behavior correctly with btrfs with / and /home as
separate subvolumes on the same btrfs volume. So the preservation of
/home would still work, while we get flexible storage allocation at
the volume level.



-- 
真実はいつも一つ!/ 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-07-01 Thread Roberto Ragusa

On 2020-06-30 15:34, Jóhann B. Guðmundsson wrote:


Share your thoughts and comments on how such move might affect you so feedback 
can be collected for the future on why such a change might be bad, how it might 
affect the distribution and scope of such change can be determined for 
potential system wide proposal.

I've never really seen any reason to switch to UEFI since it appeared years ago.
It just looked much more complicated (and buggy at the time), for no reasonable
gain.

I'm currently using BIOS, grub, grub2 basically everywhere, even on fresh new 
machines,
for the simple reason that grub2 is really flexible; recently with GPT and 
code-EF02 bios boot partition.
(GPT scheme 21686148-6449-6E6F-744E-656564454649: "Hah!IdontNeedEFI")

In some cases I have complex setups where grub2 is installed two times, with 
the first one offering
some entries, including chainloading the second one for additional entries 
(possibly on a different
drive not always connected and which each operating system having their own 
grub2 and /boot).
These things are either impossible with UEFI or would require learning 
everything again.

I've seen lilo, grub and grub2, which has matured for years; we have finally 
started to understand it
fully, we got the new blscfg thing too, and now... everything reinvented again?
IMHO the firmware (BIOS/UEFI/something) should just be able to run a 
bootloader, everything else
added is not an advantage.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Javier Martinez Canillas
On Wed, Jul 1, 2020 at 4:36 PM Lennart Poettering  wrote:
>
> On Mi, 01.07.20 13:14, Javier Martinez Canillas (jav...@dowhile0.org) wrote:
>
> > I'm not sure if this is completely fair, it's true that GRUB's blscfg
> > module diverged from the spec by adding support for variables but it
> > can also parse BLS snippets that follow the spec verbatim.
>
> You missed the point of the whole spec:
>
> the spec was that every party which interfaces with boot loaders knows
> where to find and how to deal with boot loader entries, and to make
> them as simple that every party can easily parse them and make sense
> of them, and share them. This means that many parties can *read* them
> without trouble and *drop-in* them without trouble either.
>
> By turning them into a programming language you broke that contract,
> because suddenly your files cannot be read without any embedded
> tremplating language interpretor. You own your files, but everyone
> else cannot make sense of it.
>

I've already acknowledged that using variables in the options field
was a mistake, since that is a known field according to the spec and
so it broke the contract. And also mentioned that this was already
fixed in F33, other boot loaders should now be able to parse the BLS
snippets (assuming that ignore other fields only relevant to GRUB for
boot entries auth).

> Note that the spec has extension points (i.e. it's permissible to add
> new fields without this breaking the spec), but turning it into a
> programming lnaguage is wy outside of it...
>

I wouldn't consider adding variable expansion support to turn them
into a programming language. But yes, you are right that we diverged
from the spec and that caused issues to other bootloaders (i.e: I had
this same conversation with the LinuxBoot folks).

But rather than keep pointing out what we got wrong, I would prefer to
figure out how to make the GRUB implementation to align with the spec
while still supporting all the features that are available in a
non-BLS configuration. This could also allow to have a single
kernel-install plugin instead of having specific plugins for
GRUB/Petitboot and zipl.

Best regards,
Javier
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Jerry James
On Wed, Jul 1, 2020 at 8:25 AM Ben Cotton  wrote:
> https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager
>
> == Summary ==
> BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper
> library, which will set OpenBLAS as system-wide default backend, and
> at the same time will provide a proper switching mechanism that
> currently Fedora lacks.

I like this idea.  Comments below.

> # '''Fedora lacks a system-wide default'''. Due to implementation
> differences, it is important that all components of a particular
> software stack link to the same BLAS/LAPACK implementation. Although
> there have been [[Changes/OpenBLAS_as_default_BLAS|efforts]] to
> standardize OpenBLAS as a system-wide default, they are incomplete.
> # '''Fedora lacks a proper switching mechanism'''. Different
> implementations work differently depending on the workload, but also
> depending on whether the consumer of this API implements some kind of
> parallelization, for instance. Therefore, users may want to choose a
> particular implementation that works best for them at run time.
> Mechanisms such as update-alternatives and modules have been discussed
> in the past, but were considered improper (the former) or faced
> technical issues (the former).

I think the latter instance of "the former" should be "the latter". :-)

> # Recompilation of all BLAS/LAPACK-dependent packages linking against
> FlexiBLAS instead of the current implementation they are using (just
> changing a BuildRequires line should be sufficient in most cases,
> unless a SPEC has something hardcoded somewhere else).

Speaking as maintainer of several packages that use BLAS/LAPACK, I
think the effort required may be a bit more than this paragraph
suggests, but it is worth doing.  Thanks for working on this, Iñaki!
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

2020-07-01 Thread Jiri Vanek
On 7/1/20 4:09 PM, Fabio Valentini wrote:
> On Wed, Jul 1, 2020 at 4:00 PM Jiri Vanek  wrote:
>>
>> On 7/1/20 3:21 PM, Fabio Valentini wrote:
>>> On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov  
>>> wrote:

 Fabio, does it mean that the Java SIG agrees with progressing with the 
 Change to Java 11 as a default?
>>>
>>> Speaking for myself, yes.
>>>
>>> I can't speak for all other SIG members (we haven't formally voted on
>>> this or something like that), but from conversations we've had I
>>> gather that all active package maintainers are looking forward to
>>> finally getting Java 11 by default.
>>
>> Yes, despite many soon FTBFS and thus soon orphaned pkgs, It looks taht 
>> active people wish to
>> proceed with change, rather then doing the possibly clumsy step back.
>>
>> I'm progressing toward the mass rebuild in side tag.
>>
>> I'm aware about three packages needing  commits to change - java-11-openjdk, 
>> java-1.8.0-openjdk and
>> javapackages-tools.
>>
>> Fabio, saying "you have not got xmvn change", Is tere something I need to 
>> check for?
> 
> I was wondering whether you had included javapackages-tools in the
> COPR with the second commit from the PR:
> https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/3#commit_list

The PR do not bump the release, so hard to say, but form:
https://copr.fedorainfracloud.org/coprs/jvanek/java11/package/javapackages-tools/
I guess yes, becasue there wasautobuild 21days ago. Same age as commit landed 
to javapackages-tools
ava11 branch, and autorebuild is enabled.

Thanx for heads up!

J.


> 
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 


-- 
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jva...@redhat.comM: +420775390109
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Marcin Juszkiewicz
W dniu 01.07.2020 o 12:57, Richard W.M. Jones pisze:

> If you mean migration of existing guests, then you need to repartition
> them and reinstall the bootloader.  I doubt anyone has a practical
> idea of how to do that either manually or automatically.

Add second drive with 32-64MB size. Create ESP partition there. Install
grub-efi. Power off, switch to UEFI mode, power on, boot to grub-efi.

Much easier than with real hardware machines where you indeed need to
play with partitions. On my laptop I have space available in /boot/ 
partition so could shrink it and create ESP from there. But already have
ESP so no need.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Lennart Poettering
On Mi, 01.07.20 13:14, Javier Martinez Canillas (jav...@dowhile0.org) wrote:

> I'm not sure if this is completely fair, it's true that GRUB's blscfg
> module diverged from the spec by adding support for variables but it
> can also parse BLS snippets that follow the spec verbatim.

You missed the point of the whole spec:

the spec was that every party which interfaces with boot loaders knows
where to find and how to deal with boot loader entries, and to make
them as simple that every party can easily parse them and make sense
of them, and share them. This means that many parties can *read* them
without trouble and *drop-in* them without trouble either.

By turning them into a programming language you broke that contract,
because suddenly your files cannot be read without any embedded
tremplating language interpretor. You own your files, but everyone
else cannot make sense of it.

Note that the spec has extension points (i.e. it's permissible to add
new fields without this breaking the spec), but turning it into a
programming lnaguage is wy outside of it...

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

2020-07-01 Thread Vitaly Zaitsev via devel
On 30.06.2020 22:38, Michael Catanzaro wrote:
> Any references would be very interesting, thanks.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D4FVY3LLMNGUKNUOEIDXNOOAD577W5XN/

-- 
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: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Miro Hrončok

On 01. 07. 20 16:24, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager

== Summary ==
BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper
library, which will set OpenBLAS as system-wide default backend, and
at the same time will provide a proper switching mechanism that
currently Fedora lacks.

...

== Scope ==
* Proposal owners: Modify the SPECs of the BLAS/LAPACK-dependent
packages to build against FlexiBLAS instead of the current backend
they are using.


I wonder, given FlexiBLAS is released under GPL (and not LGPL), whether this 
means we would need to change the licenses of all non-GPL packages that will be 
linked to FlexiBLAS to GPL.


CCing legal.

--
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 nano the default editor

2020-07-01 Thread Michael Catanzaro
On Wed, Jul 1, 2020 at 11:28 am, Michael Catanzaro 
 wrote:

I have not much opinion on whether we should use this vs. nano.


Actually, playing with it for an extra three minutes... it's *really* 
nice.


I know micro is not nearly as standard or popular as nano, but... this 
is worth serious additional consideration.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Miro Hrončok

On 01. 07. 20 17:37, Jerry James wrote:

On Wed, Jul 1, 2020 at 5:21 AM Miro Hrončok  wrote:

I've worked on this in

https://src.fedoraproject.org/fork/churchyard/rpms/python-sphinx_rtd_theme/commits/generator

However, there is "tiny little problem" that makes it not work:

https://github.com/rpm-software-management/rpm/issues/1297


Nice!  Thank you, Miro, I like what you've done.  I'll wait to see the
resolution of your "tiny little problem" before doing anything more.


Well I think that before this is resolved, we can only add the requirement 
manually to all the affected Fedora packages and check newly added packages 
regularly.



Should the %{?python_provide...} line be removed?  It seems to be
redundant with the new python dependency generator.


Yes, if this will not be backported (I assume it won't, my generator for example 
only targets rawhide+).



I'm also thinking of purging all traces of html5shiv from the spec
file, and rewriting the reference to it in layout.html to something
like this:

   {# JAVASCRIPTS #}
   {%- block scripts %}
   

What do you think?


Given the /usr/share font links in CSS won't work when the documentation is 
exposed via a webserver, I assume the docs are mostly intended to be browsed 
(possibly offline) from within Fedora anyway. As such, I would be inclined to 
simply drop the html5shiv part entirely, rather than pointing to a code that's 
outside of Fedora's area of influence. Whoever wants to browse the docs online 
will do it on readthedocs anyway.


--
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-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

2020-07-01 Thread Alex Scheel
- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, July 1, 2020 9:21:31 AM
> Subject: Re: [fedora-java] Re: java stack is dead, long live the javastack 
> (was "500 packages FTBFS in rawhide with
> java-11-openjdk as system JDK")
> 
> On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov 
> wrote:
> >
> > Fabio, does it mean that the Java SIG agrees with progressing with the
> > Change to Java 11 as a default?
> 
> Speaking for myself, yes.
> 
> I can't speak for all other SIG members (we haven't formally voted on
> this or something like that), but from conversations we've had I
> gather that all active package maintainers are looking forward to
> finally getting Java 11 by default.

Speaking on behalf of the Dogtag team, we too are fine with Java 11 change.

(Technically we're the next most active members of the Stewardship SIG,
 and I guess we're part of Java Maint SIG but we've not yet contributed
 in that capacity).

We're mostly there, but still need upstream CI in place to prevent
regressions and ensure we fix problems before they get started.

Plus, Debian has already made this change so we're going to need this
eventually. RHEL will get there too.


My personal preference is to get the Stewardship SIG's top-level packages
building (iirc, Eclipse, Dogtag, and Libreoffice) on Java 11 and then we'll
let the rest drop. IIRC most of the 200 packages not building in our COPR
aren't pulled in by Dogtag so we're mostly fine once we fix our top-level
Dogtag package.



- Alex



> 
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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-07-01 Thread Lennart Poettering
On Mi, 01.07.20 14:45, Hans de Goede (hdego...@redhat.com) wrote:

> I'm not in the bootloader-team, but I do work very closely with them,
> so I have only one question: who is going to pick up the extra
> maintenance load this is going to cause ?

There are distros already using it. And so far we have been pretty OK
with supporting it upstream and downstream. At least upstream I am not
aware of any big issues left open.

Note that sd-boot is a lot simpler than grub, i.e. it doesn't contain
Turing complete programming languages, module loaders, file system
drivers, storage stacks and such. There's simply not that much to
maintain!

> Also note that this entails a lot more work then just maintaining sd-boot,
> anaconda will need to be adjusted, kernel-install scripts will need to
> be adjusted, etc.

kernel-install itself is actually maintained in the same repo as
sd-boot: systemd upstream. They are developed along the same lines
already.

> Also I wonder, if you are not proposing to completely drop grub2 on
> x86_64 what does offering sd-boot in addition to grub2 actually
> offer as advantages?

Primarily simplicity, and that it implements the boot loader spec
correctly.

it automatically discovers windows and Macos installations at each
boot, without any userspace involvement. You can talk to it very
nicely, i.e. implement trivially "boot-into-windows" buttons and such
in GNOME and so on. It makes things very robust, since you don't need
a script that generates a script that generates a script (yeah, that's
how grub is hooked up). it just works on its own. You drop in boot
menu items, and that's it. You don't need to regenerate stuff, and you
never have to run an interpretor for a turing complete language.

By using sd-boot, you can do stuff like "systemctl reboot
--boot-loader-entry=windows", you can do "systemctl reboot
--boot-loader-menu=0", you can do "systemctl kexec" and it boots the
right thing, and so on.

It also implements boot time assessement that is simple and just works
(i.e. automatic revert to previous boot menu choice when the one
selected doesn't work).

Oh, and it as support for seeding the Linux random seed pre-boot
already, in a safe and simple fashion.

Moreover, it communicates which ESP is used to the host OS, so that
the host can automatically discover what other partitions to mount.

And the list goes on and on and on.

All these features are very simple individually, but put together they
are just a much nicer and expose a much more integrated behaviour
than Grub ever did.

> sd-boot is simpler and a bit tighter integrated with systemd, which would
> mean it is less work to maintain if we use it instead of grub, but if we
> use it next to grub then all those advantages fall away. IOW if we use
> it next to grub then all I see is a whole lot of extra work, with very
> little gain.

Well, you appear to believe in the race to the bottom, i.e. that the
lowest common denominator should be where the future is. I am pretty
sure it's the wrong approach: pick the simple contender that can do
all the nice things, and has the nice integration, and use it as a
blueprint for the other archs where Grub is still needed, and make
them catch up.

I mean, I understand you are interested in exotic platforms that lack
modern things like UEFI, but it kinda sucks to hold the boot loader
hostage due to that, and just stick to the terrible ways of yesteryear
because of it.

> AFAIK this (lot of extra work, very little gain) is exactly why we have
> been sticking with grub2 so far. We need to maintain it anyway, at which
> point we want to use it in as much cases as possible so that we can have
> unified code and documentation for dealing with the bootloader.

I don't see "very little gain". I see a lot of gain, and all while
things become simpler. Much simpler.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: out of Koji disk space

2020-07-01 Thread Stephen John Smoogen
On Wed, 1 Jul 2020 at 09:38, Jan Kratochvil  wrote:
>
> On Wed, 01 Jul 2020 15:14:09 +0200, Stephen John Smoogen wrote:
> > At the moment we have about 10% of the hardware
> > we shipped back in operation and there are at least 2 to 3 weeks to
> > get the rest up. Getting up larger builders is going to have to wait.
>
> Sure there is no hurry with larger builders. I watch this problem of missing
> debuginfo for years.
>

I would like to apologize for my tone in earlier emails. I should have
said that we are going to look at doing this once we had gotten the
move done and instead I went into lecturing and condescending mode.

>
> Thanks,
> Jan
>


-- 
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-07-01 Thread Jóhann B . Guðmundsson

On 1.7.2020 16:10, Solomon Peachy wrote:

On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:

I'm currently using BIOS, grub, grub2 basically everywhere, even on
fresh new machines,

This won't be the case for much longer; Intel will finally drop CSM
("BIOS") support this year.

Even putting that aside, for the past several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.


AMD is "strongly" recommending UEFI for the windows [1]

So Apple dropped CSM in 2006

Intel in 2020

AMD is against it's use

Windows has moved on with the curve...


JBG


1. https://www.amd.com/en/support/kb/faq/cpu-uefi-mode
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Miro Hrončok

On 01. 07. 20 18:33, Michael Catanzaro wrote:

On Wed, Jul 1, 2020 at 11:28 am, Michael Catanzaro  wrote:

I have not much opinion on whether we should use this vs. nano.


Actually, playing with it for an extra three minutes... it's *really* nice.

I know micro is not nearly as standard or popular as nano, but... this is worth 
serious additional consideration.


I love micro. The problematic part is it's rather big.

nano: 670 k
micro: 4.7 M

(sizes from repoquery --info)

BTW My keyboard bindings for micro that resemble a standard (modern) terminal 
session more: https://gist.github.com/hroncok/f7bc01080e3b72320b858c437af92151


--
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: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Gerd Hoffmann
  Hi,

> Also note that this entails a lot more work then just maintaining sd-boot,
> anaconda will need to be adjusted, kernel-install scripts will need to
> be adjusted, etc. And what about upgrades, if upgrades stick with using grub2
> then now we have 3 bootloader configs, including things like documentation on
> how to change kernel commandline options, to maintain instead of 2.

It is all there and working, except for the anaconda bits (as far I know
there is no way to ask anaconda install sd-boot instead of grub2).

If you wanna play with it qemu images (f31 only, no time yet for f32)
are here: https://www.kraxel.org/repos/images/
The '-systemd' variants use sd-boot.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

2020-07-01 Thread Fabio Valentini
On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov  wrote:
>
> Fabio, does it mean that the Java SIG agrees with progressing with the Change 
> to Java 11 as a default?

Speaking for myself, yes.

I can't speak for all other SIG members (we haven't formally voted on
this or something like that), but from conversations we've had I
gather that all active package maintainers are looking forward to
finally getting Java 11 by default.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: List of long term FTBFS packages to be retired in August

2020-07-01 Thread Vít Ondruch
Hi Alexandre,

Thank you for your offer. I just wonder, are you sponsored into packager
group?


Vít



Dne 29. 06. 20 v 17:57 alexandrebfar...@gmail.com napsal(a):
> I'm interested in helping with those NodeJS packages. 
>
> -- 
> Alexandre de Farias / etinin
>
> On Mon, Jun 29, 2020, 12:50 Vít Ondruch  > wrote:
>
>
> Dne 29. 06. 20 v 17:21 Miro Hrončok napsal(a):
> > js-jquery1 nodejs-sig, patches, vondruch   Fedora 30
> > js-jquery2 vondruch    Fedora 30
> > js-sizzle  nodejs-sig, patches, vondruch   Fedora 30
> >
>
> I was ranting about js-jquery (and js-sizzle is dependency of
> js-jquery)
> on this list already several times. I picked it up just to keep it
> alive
> in whatever state, because bundling it everywhere won't make things
> better. So is there anybody who would like to give it some love? Or
> should I let the packages finally go and let everybody else to bundle
> whatever they want?
>
>
>
> Vít
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: out of Koji disk space

2020-07-01 Thread Jan Kratochvil
On Wed, 01 Jul 2020 15:14:09 +0200, Stephen John Smoogen wrote:
> At the moment we have about 10% of the hardware
> we shipped back in operation and there are at least 2 to 3 weeks to
> get the rest up. Getting up larger builders is going to have to wait.

Sure there is no hurry with larger builders. I watch this problem of missing
debuginfo for years.


Thanks,
Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-01 Thread Fabio Valentini
On Sun, Jun 28, 2020 at 7:54 PM Gerald B. Cox  wrote:
> And?  I don't know about you, when dealing with file systems a chart with OK, 
> Mostly OK and Unstable doesn't give me the warm and fuzzies.  Especially when 
> OK is defined as:  "should be safe to use, no known major defficiencies" .  
> "Should" raises a red flag with me, especially given the history of BTRFS.  
> Again, if we're going to be making something the DEFAULT, it should have at 
> least 1 production release.  Where is it?  I haven't been able to find one 
> and I've asked multiple people and the response has always ducked the issue 
> or been crickets.

I'm wondering, how do you actually want to define a "production
release" of a kernel module?
Does being part of an upstream kernel release (not in staging modules)
not qualify?
Because that's already the case, and has been for years. The
introduction of the btrfs module even predates all six currently
maintained LTS branches.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-java] Questions on an update to javamail in ursine

2020-07-01 Thread Fabio Valentini
On Mon, Jun 29, 2020 at 4:06 PM Jie Kang  wrote:
>
> Hi all,
>
> javamail ursine is using version 1.5.2 while there are some module
> streams at 1.6.x
>
> The upstream project also moved to the eclipse foundation and these
> 1.6.x releases have different exports for OSGi, making an update to
> them potentially breaking for users.
>
> I'd like to update ursine to 1.6.x, but I understand packages
> depending on them should be notified or some such. However I realized
> I don't know what commands to run to get a list of such and then where
> to send it. Could anyone advise?
>
> Also, upstream repo was renamed: https://github.com/eclipse-ee4j/mail
> so maybe a new package 'mail' can be introduced to use it? Any
> thoughts there?

I use this command to check for dependent packages:

$ dnf --repo rawhide --repo rawhide-source --releasever rawhide
repoquery --whatrequires javamail

Which is enough, since there are no other subpackages except -javadoc.
The command yielded (on July 1):

ant-0:1.10.8-1.fc33.src
ant-javamail-0:1.10.8-1.fc33.noarch
bouncycastle-0:1.65-2.fc33.src
httpunit-0:1.7-29.fc32.src
log4j-0:2.13.1-1.fc33.src
log4j12-0:1.2.17-26.fc32.src
openas2-0:2.10.0-2.fc33.src
openas2-lib-0:2.10.0-2.fc33.noarch

So the list of affected packages seems to be:

- ant (Stewardship / Java SIG will deal with this)
- bouncycastle (?)
- httpunit (?)
- log4j (Stewardship / Java SIG will deal with this)
- log4j12 (Stewardship / Java SIG will deal with this)
- openas2 (?)

I already had to adapt ant to use the "legacy" coordinates of
javamail, so those changes can be reverted once it's updated. I'm not
sure whether the other packages are similarly affected (I assume they
are, and will require some `%pom_change_dep` or sed magic).

I suggest notifying the maintainers of the three "(?)" packages directly.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Nicolas Mailhot via devel
Le mercredi 01 juillet 2020 à 10:27 -0400, Neal Gompa a écrit :
> On Wed, Jul 1, 2020 at 10:26 AM Nicolas Mailhot via devel
>  wrote:
> > 
> > Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-
> > Szmek
> > a écrit :
> > > 
> > > Actually that part has been answered pretty comprehensively. The
> > > split between / and /home is hurting users
> > 
> > Actually this split is a godsend because you can convince anaconda
> > to
> > leave your home alone when reinstalling, while someone always seems
> > too
> > invent a new Fedora change that justifies the reformatting of /.
> > 
> > Good luck dealing with user data the next time workstation (or any
> > other group) feels the / filesystem should change, once you've put
> > user
> > data on the same mount point
> > 
> 
> Anaconda does this behavior correctly with btrfs with / and /home as
> separate subvolumes on the same btrfs volume. So the preservation of
> /home would still work, while we get flexible storage allocation at
> the volume level.

That only works as long as btrfs is the next shiny thing, or as long as
no one decides the options Fedora used to create btrfs volumes with are
crap and it’s a good idea to recreate them with new better options.

(btrfs may offer migration to new volume options like ext4 did in the
past, I still would not want anaconda to touch my existing user data
volumes, especially when doing emergency reinstalls because the kernel,
systemd, glibc or any other core component crapped itself).

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Gerd Hoffmann
> > 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).
> 
> Nah, that's not true. Hasn't been for quite a while.
> 
> sd-boot checks for kernels in the ESP first, and then on a second
> partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR
> partition is simply a partition with type UUID
> bc13c2ff-59e6-4262-a352-b275fd6f7172.

Ah, this is news to me.  XBOOTLDR must be formated with a filesystem the
uefi firmware can read (i.e. vfat in practice) I assume?

> > Another problem is that grub2 covers more architectures than sd-boot.
> > What is the plan for armhfp, ppc64, s390x?
> 
> sd-boot is uefi only, but it should work fine with any arch that is
> supported by uefi.

Seems it isn't built for armhfp in Fedora (/usr/lib/systemd/boot/efi
doesn't exist ...).

> > IMHO a better preparation for deprecating BIOS would be to make new
> > installs bootable with both BIOS and UEFI.  Which isn't hard at least
> > for the "[x] use all space" case where Fedora can partition the disk as
> > it pleases:  Use gpt.  Create a bios boot partition, install grun-pc
> > there.  Create a ESP partition, install grub-efi there.  Create a
> > partition for the /boot filesystem.  Have both grubs pick up BLS config
> > from /boot/loader.
> 
> My suggestion would be: don't standardize on boot loaders, standardize
> on the boot loader spec.

Using the above partition scheme probably works with sd-boot (instead of
grub-efi) too if you tag /boot as XBOOTLDR.

The point I was tring to make is that you can install fedora in a way
that the disk can be booted in both bios and uefi mode.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The future of legacy BIOS support in Fedora.

2020-07-01 Thread nickysn
On Wed, 2020-07-01 at 16:30 +0200, Lennart Poettering wrote:
> On Mi, 01.07.20 14:45, Hans de Goede (hdego...@redhat.com) wrote:
> 
> > I'm not in the bootloader-team, but I do work very closely with
> > them,
> > so I have only one question: who is going to pick up the extra
> > maintenance load this is going to cause ?
> 
> There are distros already using it. And so far we have been pretty OK
> with supporting it upstream and downstream. At least upstream I am
> not
> aware of any big issues left open.
> 
> Note that sd-boot is a lot simpler than grub, i.e. it doesn't contain
> Turing complete programming languages, module loaders, file system
> drivers, storage stacks and such. There's simply not that much to
> maintain!
> 
> > Also note that this entails a lot more work then just maintaining
> > sd-boot,
> > anaconda will need to be adjusted, kernel-install scripts will need
> > to
> > be adjusted, etc.
> 
> kernel-install itself is actually maintained in the same repo as
> sd-boot: systemd upstream. They are developed along the same lines
> already.
> 
> > Also I wonder, if you are not proposing to completely drop grub2 on
> > x86_64 what does offering sd-boot in addition to grub2 actually
> > offer as advantages?
> 
> Primarily simplicity, and that it implements the boot loader spec
> correctly.
> 
> it automatically discovers windows and Macos installations at each
> boot, without any userspace involvement. You can talk to it very
> nicely, i.e. implement trivially "boot-into-windows" buttons and such
> in GNOME and so on. It makes things very robust, since you don't need
> a script that generates a script that generates a script (yeah,
> that's
> how grub is hooked up). it just works on its own. You drop in boot
> menu items, and that's it. You don't need to regenerate stuff, and
> you
> never have to run an interpretor for a turing complete language.
> 
> By using sd-boot, you can do stuff like "systemctl reboot
> --boot-loader-entry=windows", you can do "systemctl reboot
> --boot-loader-menu=0", you can do "systemctl kexec" and it boots the
> right thing, and so on.
> 
> It also implements boot time assessement that is simple and just
> works
> (i.e. automatic revert to previous boot menu choice when the one
> selected doesn't work).
> 
> Oh, and it as support for seeding the Linux random seed pre-boot
> already, in a safe and simple fashion.
> 
> Moreover, it communicates which ESP is used to the host OS, so that
> the host can automatically discover what other partitions to mount.
> 
> And the list goes on and on and on.
> 
> All these features are very simple individually, but put together
> they
> are just a much nicer and expose a much more integrated behaviour
> than Grub ever did.
> 
> > sd-boot is simpler and a bit tighter integrated with systemd, which
> > would
> > mean it is less work to maintain if we use it instead of grub, but
> > if we
> > use it next to grub then all those advantages fall away. IOW if we
> > use
> > it next to grub then all I see is a whole lot of extra work, with
> > very
> > little gain.
> 
> Well, you appear to believe in the race to the bottom, i.e. that the
> lowest common denominator should be where the future is. I am pretty
> sure it's the wrong approach: pick the simple contender that can do
> all the nice things, and has the nice integration, and use it as a
> blueprint for the other archs where Grub is still needed, and make
> them catch up.
> 
> I mean, I understand you are interested in exotic platforms that lack
> modern things like UEFI, but it kinda sucks to hold the boot loader
> hostage due to that, and just stick to the terrible ways of
> yesteryear
> because of it.

Note that this is not only about exotic platforms. I can give you
examples with:

1. My 2019 HP laptop with an AMD Ryzen CPU. Purchased without Windows,
so it came with FreeDOS preinstalled. Obviously, FreeDOS only runs in
legacy mode. I just booted from an USB flash drive and installed Fedora
on it, without changing the BIOS settings.
2. A 2017 Dell laptop, purchased also without Windows. Came with Ubuntu
preinstalled, also in legacy mode. I installed Fedora on it, also
without changing the BIOS settings.

It's not unrealistic to expect that a lot of people would buy laptops
such as these, if they specifically want to run Linux. And it's not
unrealistic to expect many users to just install Fedora without
changing any BIOS settings, related to legacy vs UEFI boot mode. In
fact, most users wouldn't probably know anything about these settings.

Both of these computers are very far away from being considered legacy
or exotic. They can be switched to UEFI mode, but that requires
repartitioning and an OS reinstall (and that gets very complicated when
you consider multiboot scenarios with Windows 10 as well). Upgrading
these systems without reinstall is possible, but *very* difficult and
can't be automated, because, even if in the single OS scenario, it
requires the user to change the 

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-07-01 Thread Miro Hrončok

On 01. 07. 20 18:28, Michael Catanzaro wrote:
I notice that when I copy text it instructs me to "install xclip for external 
clipboard." That's not OK since xclip won't do anything in Wayland. Could be 
avoided by checking $DISPLAY before printing the message.


See https://github.com/zyedidia/micro#linux-clipboard-support

--
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: Mass spec change: Replace Python version globs with macros to support 3.10

2020-07-01 Thread Fabio Valentini
On Mon, Jun 29, 2020 at 2:50 PM Tomas Hrnciar  wrote:
>
> Hello everyone,
>
> with the upcoming Python 3.10 update we need to update Python 3 version globs 
> in Fedora specfiles. The reason is simple, Python version will be one 
> character longer so the currently omnipresent ?.? glob won't work anymore. We 
> will replace such globs with %{python_version} (or %{python_version_nodots}) 
> macros using:
>
>   sed -i -e '/python2\|python3_other/!s/??/%{python3_version_nodots}/g' \
>  -e '/python2\|python3_other/!s/?\.?/%{python3_version}/g' *.spec
>
> There are currently 402 affected packages.
>
>   $ grep -l 'py?.?\|python?.?\|python-??\|Python??' *.spec | wc -l
>   404
>
> We have manually removed pygtk2 and tomoe, because the hit was a false 
> positive.

Great, thank you for doing this.
I've tried to switch from ?.? to %{python3_version} every time I touch
one of my packages, but it looks like I missed some :)

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Neal Gompa
On Wed, Jul 1, 2020 at 9:40 AM Peter Rajnoha  wrote:
>
> On 7/1/20 2:03 PM, Neal Gompa wrote:
> > On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha  wrote:
> >>
> >> On 6/30/20 9:35 PM, Igor Raits wrote:
> >>> 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

Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

2020-07-01 Thread Jiri Vanek
On 7/1/20 3:21 PM, Fabio Valentini wrote:
> On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov  
> wrote:
>>
>> Fabio, does it mean that the Java SIG agrees with progressing with the 
>> Change to Java 11 as a default?
> 
> Speaking for myself, yes.
> 
> I can't speak for all other SIG members (we haven't formally voted on
> this or something like that), but from conversations we've had I
> gather that all active package maintainers are looking forward to
> finally getting Java 11 by default.

Yes, despite many soon FTBFS and thus soon orphaned pkgs, It looks taht active 
people wish to
proceed with change, rather then doing the possibly clumsy step back.

I'm progressing toward the mass rebuild in side tag.

I'm aware about three packages needing  commits to change - java-11-openjdk, 
java-1.8.0-openjdk and
javapackages-tools.

Fabio, saying "you have not got xmvn change", Is tere something I need to check 
for?

Thanx!
 J.
> 
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 


-- 
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jva...@redhat.comM: +420775390109
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Justin Forbes
On Wed, Jul 1, 2020 at 7:54 AM Stephen Gallagher  wrote:
>
> On Tue, Jun 30, 2020 at 9:03 PM Michael Catanzaro  
> wrote:
> >
> >
> > 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.
> >
>
> I think there has been a good deal of miscommunication on all sides
> (starting with me).
>
> What I was attempting to say in the first place was this: "It's not
> clear to me that this proposal has the blessing of the Workstation WG
> or Spins. I'm not willing to *assert* that they must do this work
> without hearing whether they are willing and have capacity to do so."
> I think I phrased this poorly initially.
>
> What I would like is just to have a statement added to the Change
> Proposal that "Workstation WG and the maintainers of Spins Foo, Bar
> and Baz are willing to make this the default if this Change Proposal
> is accepted." I just didn't want anyone getting *dictated* at without
> their input.

So why not word the proposal "The Workstation WG and maintainers of
Spins Foo, Bar, and Baz are free to make btrfs the default file system
if they so choose"?

Justin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

2020-07-01 Thread Fabio Valentini
On Wed, Jul 1, 2020 at 4:00 PM Jiri Vanek  wrote:
>
> On 7/1/20 3:21 PM, Fabio Valentini wrote:
> > On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov  
> > wrote:
> >>
> >> Fabio, does it mean that the Java SIG agrees with progressing with the 
> >> Change to Java 11 as a default?
> >
> > Speaking for myself, yes.
> >
> > I can't speak for all other SIG members (we haven't formally voted on
> > this or something like that), but from conversations we've had I
> > gather that all active package maintainers are looking forward to
> > finally getting Java 11 by default.
>
> Yes, despite many soon FTBFS and thus soon orphaned pkgs, It looks taht 
> active people wish to
> proceed with change, rather then doing the possibly clumsy step back.
>
> I'm progressing toward the mass rebuild in side tag.
>
> I'm aware about three packages needing  commits to change - java-11-openjdk, 
> java-1.8.0-openjdk and
> javapackages-tools.
>
> Fabio, saying "you have not got xmvn change", Is tere something I need to 
> check for?

I was wondering whether you had included javapackages-tools in the
COPR with the second commit from the PR:
https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/3#commit_list

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager

== Summary ==
BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper
library, which will set OpenBLAS as system-wide default backend, and
at the same time will provide a proper switching mechanism that
currently Fedora lacks.

== Owner ==
* Name: [[User:iucar| Iñaki Úcar]]
* Email: i.ucar86 at gmail


== Detailed Description ==

BLAS and LAPACK are API standards for basic linear algebra operations
(such as vector and matrix multiplication). Fedora packages the
reference implementation from Netlib as well as several optimized
backends, such as ATLAS, BLIS and OpenBLAS. Historically, there have
been two unresolved issues regarding this API:

# '''Fedora lacks a system-wide default'''. Due to implementation
differences, it is important that all components of a particular
software stack link to the same BLAS/LAPACK implementation. Although
there have been [[Changes/OpenBLAS_as_default_BLAS|efforts]] to
standardize OpenBLAS as a system-wide default, they are incomplete.
# '''Fedora lacks a proper switching mechanism'''. Different
implementations work differently depending on the workload, but also
depending on whether the consumer of this API implements some kind of
parallelization, for instance. Therefore, users may want to choose a
particular implementation that works best for them at run time.
Mechanisms such as update-alternatives and modules have been discussed
in the past, but were considered improper (the former) or faced
technical issues (the former).

This change proposal aims to solve both issues at the same time with
minimal changes and minimal impact by using FlexiBLAS.

FlexiBLAS is a framework that wraps the BLAS/LAPACK API with
interfaces for both 32- and 64-bit integers. It provides runtime
exchangeable backends without recompilation, with a transparent
fallback mechanism to Netlib's reference implementation if a certain
symbol is not present in the selected backend. It also supports
flexible per-system/user/host configuration files and basic profiling.

Therefore, this change proposal requires:

# Recompilation of all BLAS/LAPACK-dependent packages linking against
FlexiBLAS instead of the current implementation they are using (just
changing a BuildRequires line should be sufficient in most cases,
unless a SPEC has something hardcoded somewhere else).
# Changing the packaging guidelines to reflect this new requirement
for BLAS/LAPACK consumers (there is [[PackagingDrafts/BLAS_LAPACK| a
draft]] already.

In this way, all the BLAS/LAPACK-dependent packages will automatically
use the system-wide default backend, set and centralized in the
FlexiBLAS SPEC, and will benefit from the straightforward switching
mechanism that FlexiBLAS provides.


== Benefit to Fedora ==

* '''Packaging of BLAS/LAPACK-dependent packages will be easier and
safer'''. FlexiBLAS is 100% compatible with the reference API. It uses
optimized symbols that are present in the selected backend and
transparently falls back to Netlib for the missing ones, so
compatibility is always guaranteed.
* '''Provides a centralized way of managing the system-wide
default''', just by changing a global variable in the FlexiBLAS SPEC.
* '''Provides sysadmins with tools to manage the system-wide
configuration'''. FlexiBLAS ships system-wide configuration files to,
e.g., change the default or point to new backends. A CLI tool is also
provided to easily manage such configurations.
* '''Provides users with tools to switch the backend'''. This can be
managed by the same CLI tool too in user mode, and it generates
per-user configuration files.
* '''Provides developers with an API to hook into the BLAS/LAPACK API
calls'''. E.g., FlexiBLAS comes with a plugin that enables basic
profiling support.

== Scope ==
* Proposal owners: Modify the SPECs of the BLAS/LAPACK-dependent
packages to build against FlexiBLAS instead of the current backend
they are using.
* Other developers: Maintainers of the affected packages need to merge
the changes and rebuild. Alternatively, a provenpackager could help
with this process (it's 30-40 packages).

* Release engineering: N/A
* Policies and guidelines:
[https://pagure.io/packaging-committee/issue/995 #995] Package
guidelines should be updated to require BLAS/LAPACK-dependent packages
to link against FlexiBLAS.
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
There is no upgrade/compatibility impact.

== How To Test ==
BLAS/LAPACK-dependent packages should work normally, without any (new)
issue. To test the switching capabilities, testers may want to run a
BLAS/LAPACK benchmark. There are many out there for different
software, but we will describe the workflow for R as an example:

* Install R, which requires BLAS/LAPACK for operations with matrices.
* Run any benchmark involving calculations with matrices (e.g.,
R-benchmark-25.R provided by an R-core member
[https://mac.r-project.org/benchmarks 

Re: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Solomon Peachy
On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
> I'm currently using BIOS, grub, grub2 basically everywhere, even on 
> fresh new machines,

This won't be the case for much longer; Intel will finally drop CSM 
("BIOS") support this year.

Even putting that aside, for the past several years CSM/BIOS has been 
slowly bitrotting due to a lack of real testing, as the last few Windows 
releases have mandated use of UEFI for preinstalled systems, plus the 
EOLing of Windows 7 and (especially) XP.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Jerry James
On Wed, Jul 1, 2020 at 10:26 AM Iñaki Ucar  wrote:
> BTW, I would also like to discuss here, as part of this proposal,
> which backend should be the system-wide default. I believe we all
> would agree that OpenBLAS nowadays is the best choice. But then, the
> serial or the openmp version?

First, I want to make sure I understand the current openblas
packaging.  Is this correct?

openblas-openmp: use if the application uses OpenMP
openblas-serial: use if the application is multithreaded
openblas-threads: use if the application is single-threaded

I've always found the naming of the openblas packages to be confusing,
so that may not be right.  Somebody set me straight if so.

The question of the default is a hard one.  What happens if a
multithreaded application that does not use OpenMP is linked with the
OpenMP build of OpenBLAS?
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-01 Thread Michael Catanzaro
On Wed, Jul 1, 2020 at 4:25 pm, Nicolas Mailhot via devel 
 wrote:

Actually this split is a godsend because you can convince anaconda to
leave your home alone when reinstalling, while someone always seems 
too

invent a new Fedora change that justifies the reformatting of /.

Good luck dealing with user data the next time workstation (or any
other group) feels the / filesystem should change, once you've put 
user

data on the same mount point


So for the avoidance of doubt: if the btrfs change is rejected, we are 
almost certain to put everything on the same mount point. We haven't 
approved this yet, but odds are very high IMO. The options we are 
seriously considering for our default going forward are (a) btrfs, (b) 
failing that, probably ext4 all one big partition without LVM, (c) 
less-likely, maybe xfs all one big partition without LVM. This is being 
discussed in https://pagure.io/fedora-workstation/issue/152


We have a high number of complaints from developers running out of 
space on / with plenty of space left on /home (happens to me all the 
time). The opposite scenario is a problem too. Separate mountpoints by 
default is just not a good default, sorry. Ensuring users don't run out 
of space due to bad partitioning is more important than keeping /home 
during reinstall IMO. But with btrfs, then /home will just be a 
subvolume so we can have our cake and eat it too.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

2020-07-01 Thread Aleksandar Kurtakov
On Wed, Jul 1, 2020 at 4:50 PM Alex Scheel  wrote:

> - Original Message -
> > From: "Fabio Valentini" 
> > To: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org>
> > Sent: Wednesday, July 1, 2020 9:21:31 AM
> > Subject: Re: [fedora-java] Re: java stack is dead, long live the
> javastack (was "500 packages FTBFS in rawhide with
> > java-11-openjdk as system JDK")
> >
> > On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov 
> > wrote:
> > >
> > > Fabio, does it mean that the Java SIG agrees with progressing with the
> > > Change to Java 11 as a default?
> >
> > Speaking for myself, yes.
> >
> > I can't speak for all other SIG members (we haven't formally voted on
> > this or something like that), but from conversations we've had I
> > gather that all active package maintainers are looking forward to
> > finally getting Java 11 by default.
>
> Speaking on behalf of the Dogtag team, we too are fine with Java 11 change.
>
> (Technically we're the next most active members of the Stewardship SIG,
>  and I guess we're part of Java Maint SIG but we've not yet contributed
>  in that capacity).
>
> We're mostly there, but still need upstream CI in place to prevent
> regressions and ensure we fix problems before they get started.
>
> Plus, Debian has already made this change so we're going to need this
> eventually. RHEL will get there too.
>
>
> My personal preference is to get the Stewardship SIG's top-level packages
> building (iirc, Eclipse, Dogtag, and Libreoffice) on Java 11 and then we'll
> let the rest drop.


Eclipse stack (incl. build deps) should be Java 11 ready as we speak (minus
few dependencies in the work).
Furthermore Eclipse will require Java 11 in its September release upstream .


> IIRC most of the 200 packages not building in our COPR
> aren't pulled in by Dogtag so we're mostly fine once we fix our top-level
> Dogtag package.
>
>
>
> - Alex
>
>
>
> >
> > Fabio
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/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
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Nicolas Mailhot via devel
Le mercredi 01 juillet 2020 à 12:27 +0200, Dominik 'Rathann'
Mierzejewski a écrit :

Hi,

> That's not detailed at all. You should provide at least one example
> here (or a direct link to one somewhere else on the wiki).

Thank you for your attention and kind review. yes the wiki page was
completely insufficient, I did it at the last minute to honor
deadlines. Please check if it is ok for you now.

Anyway here are some answers I added to the wiki


> 
> What's "autobumping" here 

The change will make packages that use the %auto_ redhat-rpm-
config macros auto-bump and auto-changelog at the rpm level, in an
infrastructure-independent way. The %auto_ framework is proposed
in
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs

In that context, auto-bumping means that a SRPM, produced in any
compatible build system (that is, any build system that does not
inhibit low-level rpmbuild behaviour), will rebuild by default to a
release higher, than the last build release, in the next build system
it is imported into, without any manual change to the SRPM source
files.

Auto-changelog means that the build event will also be traced in the
rpm changelog (again, without any manual change). 

> and how is it better than rpmdev-bumpsec?

Unlike rpmdev-bumpsec, the feature is automatic.

It does not require explicit human action. Releases get bumped even if
the human forgot a particular release has already been built.

It does not rely on an external tool, nor requires this external tool
to be able to parse a spec file (which can be difficult for heavily
automated spec files like the ones that take advantage of %auto
macros).

A rebuild does not touch the spec file at all. That means, the spec
files changes tracked by your favorite scm, will show only spec logic
changes, without drowning those in no-logic-change build events. 


> [...]
> > == 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/
> 
> A diff with changes

The current code state is visible in

https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/commits/forge-with-patches

It’s one small commit on top of the huge change queued in:
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/95

That PR can still evolve based on feedback and testing. Therefore, I
can’t promise that the auto-bumping logic will always apply directly,
just that it will look more or less this way after rebasing. I do not
rebase it on every change to the other PR.

This is very young code, there are probably lots of easy things to tidy
up in there. However it works. 


> 
> Why is a separate "rpm-changelog.txt" file with manually maintained
> changelog better than current manually maintained changelog inside
> .spec?

This change does not separates the changelog. The separation is already
done in

https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
that this change builds upon

Without separation, we would lose the benefit of auto-bumping at the
SCM level, since no-logic-change rebuilds would still result in a spec
file change.

Separation makes automation a lot easier since adding to the changelog
is just pre-pending some lines, and does not require any knowledge of
rpm syntax. Auto-bumping will add a "* date name evr" line on the next
rebuild, so changelog additions can limit themselves to plain text
descriptions of new changes at the top of the existing file.

Separation is a requirement for auto-changelog bumping at the rpm
level. Once rpmbuilt is lauched, it can not modify the processed spec
file. Therefore making the changelog modifiable by the build process
requires splitting it out of the spec file first. 

> How about using git commit log for changelog instead?

This is a low level change that does not depend on any specific
infrastructure, git included. It works directly at the rpm level. 

An infrastructure that uses git, can feed git commit events to the
detached changelog file, using dumb or elaborate git commit hooks, and
any other method it wants to implement. The auto-bump logic does not
care, it will use the detached changelog file in the state it exists at
the start of the build process.

Because the logic catches all rebuilds, regular manual trimming of the
lines that add no value is recommended. 

> [...]
> > To get beautiful changelogs, you also need to add
> > 
> > 
> > %buildsys_name  Your name
> > %buildsys_email Your email
> > 
> > 
> > in ~/.rpmmacros
> 
> What about having one macro called %buildsys_packager instead of two?
> You're always using them together, anyway. It'd be similar to the
> existing %packager macro, too.

This is certainly doable and 

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-01 Thread Chuck Anderson
On Wed, Jul 01, 2020 at 04:25:31PM +0200, Nicolas Mailhot via devel wrote:
> Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-Szmek
> a écrit :
> > 
> > Actually that part has been answered pretty comprehensively. The
> > split between / and /home is hurting users 
> 
> Actually this split is a godsend because you can convince anaconda to
> leave your home alone when reinstalling, while someone always seems too
> invent a new Fedora change that justifies the reformatting of /.
> 
> Good luck dealing with user data the next time workstation (or any
> other group) feels the / filesystem should change, once you've put user
> data on the same mount point

The whole point of the btrfs change is to keep / and /home on separate 
subvolumes to avoid the anaconda requirement to reformat / from affecting /home 
while also avoiding the problem of running out of space on one while still 
having tons of free space on the other.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Jerry James
On Wed, Jul 1, 2020 at 5:21 AM Miro Hrončok  wrote:
> I've worked on this in
>
> https://src.fedoraproject.org/fork/churchyard/rpms/python-sphinx_rtd_theme/commits/generator
>
> However, there is "tiny little problem" that makes it not work:
>
> https://github.com/rpm-software-management/rpm/issues/1297

Nice!  Thank you, Miro, I like what you've done.  I'll wait to see the
resolution of your "tiny little problem" before doing anything more.

Should the %{?python_provide...} line be removed?  It seems to be
redundant with the new python dependency generator.

I'm also thinking of purging all traces of html5shiv from the spec
file, and rewriting the reference to it in layout.html to something
like this:

  {# JAVASCRIPTS #}
  {%- block scripts %}
  

What do you think?  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: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

2020-07-01 Thread Michael Catanzaro
So the last two times thermald was proposed (first as a F32 change 
proposal, then more recently to the Workstation WG) it was rejected on 
the grounds that it was not useful without dptfxtract installed. Now 
it's clear that everybody was mistaken about that, so seems it makes 
sense to reconsider.


I have a couple questions. First, why is thermal management occurring 
in userspace? Can you please provide a technical explanation as to why 
the kernel is not the right place for this code?


On Wed, Jul 1, 2020 at 11:53 am, Richard W.M. Jones  
wrote:

Is there some background about why dptfxtract is proprietary?  (I see
that it's a program provided by Intel.)  Is it just because no one's
done the work to make a free equivalent or does it require some
secret/patented/whatever knowledge to work?


I'm also interested in this question. In particular, since thermald and 
dptfxtract are both the same upstream, it seems really hostile to the 
open source community for thermald to perform better if you have this 
extra proprietary portion of the project installed.


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: Cleaning up comps packages in rawhide

2020-07-01 Thread Kevin Fenzi
On Tue, Jun 30, 2020 at 05:46:11PM -, Ian McInerney wrote:
> 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.

As Adam mentioned on the pr... this is possibly a little too correct. 

ie, firefox might be excluding armv7 for a short time, but it's
indending to re-add it and with this they would have to re-add it here
also.

Not sure what the best way forward is here... I guess we could do this,
but note to people to adjust these special cases?

Or perhaps secondary arch folks know what the corner cases are and can
suggest changes?

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Iñaki Ucar
On Wed, 1 Jul 2020 at 17:53, Jerry James  wrote:
>
> On Wed, Jul 1, 2020 at 8:25 AM Ben Cotton  wrote:
> >
> > Mechanisms such as update-alternatives and modules have been discussed
> > in the past, but were considered improper (the former) or faced
> > technical issues (the former).
>
> I think the latter instance of "the former" should be "the latter". :-)

Yes, already fixed in the change page, thanks. :)

> > # Recompilation of all BLAS/LAPACK-dependent packages linking against
> > FlexiBLAS instead of the current implementation they are using (just
> > changing a BuildRequires line should be sufficient in most cases,
> > unless a SPEC has something hardcoded somewhere else).
>
> Speaking as maintainer of several packages that use BLAS/LAPACK, I
> think the effort required may be a bit more than this paragraph
> suggests, but it is worth doing.  Thanks for working on this, Iñaki!

I just did the easy part. :) Thanks to the upstream maintainer,
Martin, who has listened to all the feedback I had, fixed a bunch of
things and prepared a new release ready for this proposal in no time.

BTW, I would also like to discuss here, as part of this proposal,
which backend should be the system-wide default. I believe we all
would agree that OpenBLAS nowadays is the best choice. But then, the
serial or the openmp version?

-- 
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 33 System-Wide Change proposal: Make nano the default editor

2020-07-01 Thread Michael Catanzaro
On Wed, Jul 1, 2020 at 6:42 pm, Miro Hrončok  
wrote:

I love micro. The problematic part is it's rather big.

nano: 670 k
micro: 4.7 M

(sizes from repoquery --info)


rpm -qi micro says 16007158 bytes installed... that's 15.3 MiB, 
compared to nano at 2.5 MiB, and vim-minimal at 1.3 MiB. I've been 
reminded in IRC that micro was previously considered but passed over 
out of concern that this would be too much for containers.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Peter Rajnoha
On 7/1/20 2:03 PM, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha  wrote:
>>
>> On 6/30/20 9:35 PM, Igor Raits wrote:
>>> 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 

Introducing modulemd-tools

2020-07-01 Thread Jakub Kadlcik
Hello,

I would like to let you know, that we started a project called
modulemd-tools. It is a collection of small tools for parsing and
generating modulemd YAML files.

At this moment, it provides two scripts - one for generating a
modulemd YAML file based on an existing YUM repository, the other one
is even simpler, and generates a module for all packages in a given
directory. If you would like to see any other use-cases covered,
please let us know.

The project upstream is here

https://github.com/rpm-software-management/modulemd-tools

It is already packaged for Fedora, so just `dnf install
modulemd-tools` to get it.

You can read some additional information in my blog post

http://frostyx.cz/posts/introducing-modulemd-tools


Any feedback is appreciated,
Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Richard Shaw
On Tue, Jun 30, 2020 at 12:35 PM Robbie Harwood  wrote:

> Igor Raits  writes:
>
>
> 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.
>

I converted my system from BIOS to UEFI and can confirm that it was a
nightmare. I found problems months later even after it "worked" that had to
be resolved. I don't recommend it.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-07-01 Thread Iñaki Ucar
On Wed, 1 Jul 2020 at 18:54, Miro Hrončok  wrote:
>
> On 01. 07. 20 18:33, Michael Catanzaro wrote:
> > On Wed, Jul 1, 2020 at 11:28 am, Michael Catanzaro  
> > wrote:
> >> I have not much opinion on whether we should use this vs. nano.
> >
> > Actually, playing with it for an extra three minutes... it's *really* nice.
> >
> > I know micro is not nearly as standard or popular as nano, but... this is 
> > worth
> > serious additional consideration.
>
> I love micro. The problematic part is it's rather big.
>
> nano: 670 k
> micro: 4.7 M
>
> (sizes from repoquery --info)

To be fair, we should add ncurses-libs and file-libs as dependencies:
330 k + 570 k = 900 k more. But yes, micro is still bigger, as its
name suggests. :)

> BTW My keyboard bindings for micro that resemble a standard (modern) terminal
> session more: https://gist.github.com/hroncok/f7bc01080e3b72320b858c437af92151

That's very useful, thanks!

-- 
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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

2020-07-01 Thread Alexey A.
>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

Fedora's earlyoom package is provided with the changed default settings:

```
EARLYOOM_ARGS="-r 0 -m 4 -M 409600 --prefer '^Web Content$' --avoid
'^(dnf|packagekitd|gnome-shell|gnome-session-c|gnome-session-b|lightdm|sddm|sddm-helper|gdm|gdm-wayland-ses|gdm-session-wor|gdm-x-session|Xorg|Xwayland|systemd|systemd-logind|dbus-daemon|dbus-broker|cinnamon|cinnamon-sessio|kwin_x11|kwin_wayland|plasmashell|ksmserver|plasma_session|startplasma-way|xfce4-session|mate-session|marco|lxqt-session|openbox)$'"
```

It means that:

1. SIGTERM threshold for MemAvailable is 4% (but not more than 400 MiB) and
SIGKILL threshold for MemAvailable is 2% (but not more than 200 MiB) by
default. The change was due to the fact that earlyoom tree was criticized
for too aggressive thresholds by default, and this was taken into account.
Please update description in the proposal.

2. Firefox's children processes "Web Content" gets +300 to its oom_score.
It means that earlyoom will prefer to kill firefox tabs rather than entire
browser. Similar behavior is already practiced in chromium and
electron-based apps by default.

3. Processes, the killing of which can lead to the killing of the entire
session (kwin_x11|kwin_wayland|plasmashell|ksmserver|plasma_session etc),
receive reduced priority in choosing a victim. dnf also gets low prio. This
is yet another advantage that you can mention in the proposal.

see https://pagure.io/fedora-workstation/issue/119#comment-638366

вт, 30 июн. 2020 г. в 22:26, Ben Cotton :

> 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 

[Bug 1852856] perl-Template-Toolkit depends on mod_perl, which eventually installs httpd

2020-07-01 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1852856

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-EPEL-2020-b01f134c3e has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b01f134c3e


-- 
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


Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-07-01 Thread Stephen John Smoogen
On Wed, 1 Jul 2020 at 13:14, Iñaki Ucar  wrote:
>
> On Wed, 1 Jul 2020 at 18:54, Miro Hrončok  wrote:
> >
> > On 01. 07. 20 18:33, Michael Catanzaro wrote:
> > > On Wed, Jul 1, 2020 at 11:28 am, Michael Catanzaro  
> > > wrote:
> > >> I have not much opinion on whether we should use this vs. nano.
> > >
> > > Actually, playing with it for an extra three minutes... it's *really* 
> > > nice.
> > >
> > > I know micro is not nearly as standard or popular as nano, but... this is 
> > > worth
> > > serious additional consideration.
> >
> > I love micro. The problematic part is it's rather big.
> >
> > nano: 670 k
> > micro: 4.7 M
> >
> > (sizes from repoquery --info)
>
> To be fair, we should add ncurses-libs and file-libs as dependencies:
> 330 k + 570 k = 900 k more. But yes, micro is still bigger, as its
> name suggests. :)
>
> > BTW My keyboard bindings for micro that resemble a standard (modern) 
> > terminal
> > session more: 
> > https://gist.github.com/hroncok/f7bc01080e3b72320b858c437af92151
>
> That's very useful, thanks!
>

On a side note.. I went looking to see if someone had an editor name
smaller than nano.
pico was the editor that nano replaces.
femto is an editor on Apple phones written in javascript
atto is an editor in the Moodle web app.
there is a zepto which is at https://github.com/hughbarney/zepto (and
also has an atto which is emacs like)

https://github.com/hughbarney/zepto#comparisons-with-other-emacs-implementations
gives size estimates from 3 years ago.

that leaves yocto which is a different distribution.. and nothing is
defined smaller than a yocto

in the end, we should just probably choose something.. we can always
change our minds in 6 months to something else.

-- 
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-07-01 Thread Lennart Poettering
On Mi, 01.07.20 18:31, Gerd Hoffmann (kra...@redhat.com) wrote:

> > > 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).
> >
> > Nah, that's not true. Hasn't been for quite a while.
> >
> > sd-boot checks for kernels in the ESP first, and then on a second
> > partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR
> > partition is simply a partition with type UUID
> > bc13c2ff-59e6-4262-a352-b275fd6f7172.
>
> Ah, this is news to me.  XBOOTLDR must be formated with a filesystem the
> uefi firmware can read (i.e. vfat in practice) I assume?

The spec doesn't strictly mandate that in the general case. I think it
would still be wise to stick to vfat, given that this means all kind
of firmware can easily read it, but if your boot loader/firmware can
read something else that's OK too.

> > sd-boot is uefi only, but it should work fine with any arch that is
> > supported by uefi.
>
> Seems it isn't built for armhfp in Fedora (/usr/lib/systemd/boot/efi
> doesn't exist ...).

Hmm, I know that people build it on ARM, I guess we could enable that
in Fedora too. I am not an ARM pro myself, not sure what happens there
right now.

Upstream sd-boot has support for UEFI ia32, x64, arm and aa64.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Susi Lehtola
On Wed, 1 Jul 2020 10:54:16 -0600
Jerry James  wrote:

> On Wed, Jul 1, 2020 at 10:26 AM Iñaki Ucar 
> wrote:
> > BTW, I would also like to discuss here, as part of this proposal,
> > which backend should be the system-wide default. I believe we all
> > would agree that OpenBLAS nowadays is the best choice. But then, the
> > serial or the openmp version?  
> 
> First, I want to make sure I understand the current openblas
> packaging.  Is this correct?
> 
> openblas-openmp: use if the application uses OpenMP

Yes; then OpenBLAS calls get run in parallel in single-threaded regions
of the code, and if sequential mode in regions that are already
running parallel.

> openblas-serial: use if the application is multithreaded
> openblas-threads: use if the application is single-threaded

No, this is exactly the wrong way around. You should use the serial
library for code that you want to be running in serial (this way you
can get several instances of the program running efficiently), and the
pthreads version if you want to run the BLAS/LAPACK regions in parallel
(but are somehow opposed to OpenMP!)..

> The question of the default is a hard one.  What happens if a
> multithreaded application that does not use OpenMP is linked with the
> OpenMP build of OpenBLAS?

Then you get too much parallellism, i.e. every call to OpenBLAS will
launch several threads, and this will naturally ruin your scaling.
-- 
Susi Lehtola
Fedora Project Contributor
jussileht...@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-07-01 Thread Ralf Corsepius

On 6/30/20 3:34 PM, 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 statement is simply not true - With all due respect, I for one 
consider this statement of yours to be close to a blatant cheat and a lie.


I definitely own BIOS-only systems, which have been sold long after 2005 
and which are still in everyday use.


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.


Fedora should not care Intel's plans, but about the systems users use.

IMNSHO, this inevitably must comprise to continueg supporting 
BIOS-systems for at least another decade.


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.


Definitely the former.

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.


Dropping BIOS would render Fedora entire unsuitable for me and will like 
cause me to stop supporting Fedora.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-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-07-01 Thread Eric Sandeen
On 7/1/20 11:53 AM, Michael Catanzaro wrote:
> On Wed, Jul 1, 2020 at 4:25 pm, Nicolas Mailhot via devel 
>  wrote:
>> Actually this split is a godsend because you can convince anaconda to
>> leave your home alone when reinstalling, while someone always seems too
>> invent a new Fedora change that justifies the reformatting of /.
>>
>> Good luck dealing with user data the next time workstation (or any
>> other group) feels the / filesystem should change, once you've put user
>> data on the same mount point
> 
> So for the avoidance of doubt: if the btrfs change is rejected, we are almost 
> certain to put everything on the same mount point. We haven't approved this 
> yet, but odds are very high IMO. The options we are seriously considering for 
> our default going forward are (a) btrfs, (b) failing that, probably ext4 all 
> one big partition without LVM, (c) less-likely, maybe xfs all one big 
> partition without LVM. This is being discussed in 
> https://pagure.io/fedora-workstation/issue/152
> 
> We have a high number of complaints from developers running out of space on / 
> with plenty of space left on /home (happens to me all the time). The opposite 
> scenario is a problem too. Separate mountpoints by default is just not a good 
> default, sorry. Ensuring users don't run out of space due to bad partitioning 
> is more important than keeping /home during reinstall IMO. But with btrfs, 
> then /home will just be a subvolume so we can have our cake and eat it too.

This can be mitigated with directory (project) quotas, btw.

On XFS, exceeding a directory tree quota even yields ENOSPC.
(on ext4, it's EDQUOT right now.)

So one big / partition including /home, with a directory quota set
on /home at 20G, will yield ENOSPC when home contains 20G and will now
allow / to get filled with user files.

It's also trivial to adjust the directory quota on /home up or down, as
needed.

It's another cake eating-and-having option which is a pretty trivial
thing to implement.

-Eric
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: out of Koji disk space

2020-07-01 Thread Jan Kratochvil
On Wed, 01 Jul 2020 17:46:23 +0200, Kevin Fenzi wrote:
> * Is this only on x86_64 that you need this? Or all arches?

Sure we should have this on all arches but I haven't tested non-x86_64 yet.
There possibly may be also some memory problems even on x86_64 (it builds on
my machine w/64GB but Koji has only 16GB + big swap).


> * you're guessing you need 160GB? Is that pretty accurate?

$ du -shc `git ls-files` `cat sources |sed 's/^.*(\(.*\)).*$/\1/'` 
chromium-83.0.4103.116-2/ BUILDROOT/
... ...
161Gchromium-83.0.4103.116/
14G BUILDROOT/
176Gtotal


> I can fix that and they would have ~300GB or so each, would that be enough?

It depends what other packages are being built on the same host, doesn't it?


> in that case you could submit and cancel until you got a buildhw-x86 ? 

I am not Chromium maintainer (Tom 'spot' Callaway is). I am not even sure Spot
will accept this change (although then why not). I do not want to talk for
Spot if he likes to do the builds this way.


> Anyhow, I'd suggest filing an infrastructure ticket with your needs and
> we can see what we can come up with either short or long term for you. 

I will file a ticket after Spot says his opinion (or not).


Thanks,
Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Iñaki Ucar
On Wed, 1 Jul 2020 at 21:00, Iñaki Ucar  wrote:
>
> On Wed, 1 Jul 2020 at 20:24, Susi Lehtola
>  wrote:
> >
> > On Wed, 1 Jul 2020 19:28:53 +0200
> > Iñaki Ucar  wrote:
> > > I'm no expert, but the FAQ says:
> > >
> > > "You have a GPLed program that I'd like to link with my code to build
> > > a proprietary program. Does the fact that I link with your program
> > > mean I have to GPL my program? (#LinkingWithGPL)
> > >
> > > Not exactly. It means you must release your program under a license
> > > compatible with the GPL (more precisely, compatible with one or more
> > > GPL versions accepted by all the rest of the code in the combination
> > > that you link). The combination itself is then available under those
> > > GPL versions."
> > >
> > > So my understanding is that it's ok for a program to link to FlexiBLAS
> > > if its license is GPL-compatible, not necessarily GPL. But of course
> > > we would need confirmation from legal.
> >
> > The library is GPLv3 only
> >
> > https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release#license
> >
> > which already makes it incompatible with many GNU Licenses
> >
> > https://fedoraproject.org/wiki/Licensing:Main#GPL_Compatibility_Matrix
>
> With many? With GPLv2 only. But most interestingly, GPLv3 states:
>
> "Corresponding Source includes interface definition files associated
> with source files for the work, and the source code for shared
> libraries and dynamically linked subprograms that the work is
> specifically designed to require"
>
> Technically, there's nothing in FlexiBLAS that a BLAS/LAPACK
> application would require to work. These are designed to require
> BLAS/LAPACK, and FlexiBLAS just duplicates that interface and glues
> symbols together.
>
> Maybe I'm completely misunderstanding the sentence above, but GPL
> restrictions of course apply to any program that uses the FlexiBLAS
> API for profiling, etc., but not to those that just use the
> BLAS/LAPACK API.

In line with this, can FlexiBLAS be considered a "system library"? It
sounds reasonable to me, but I read the definition in section 1
several times and still don't know.

-- 
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


  1   2   3   >