Schedule for Wednesday's FESCo Meeting (2020-07-15)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-07-15 14:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

#2431 F33 System-Wide Change: Cleanup GNOME Hidden Boot Menu Integration
https://pagure.io/fesco/issue/2431
APPROVED (+7, 0, 0)

#2432 F33 System-Wide Change: NetworkManager keyfile instead of ifcfg-rh
https://pagure.io/fesco/issue/2432
APPROVED (+5, 0, 0)

#2433 F33 System-Wide Change: Disable dmraid-activation.service on first run if 
no dmraid sets are found
https://pagure.io/fesco/issue/2433
APPROVED (+6, 0, 0)

#2434 F33 System-Wide Change: Remove device-mapper-multipath from the Fedora 
workstation livecd
https://pagure.io/fesco/issue/2434
APPROVED (+7, 0, 0)

Please note that there's a bunch of tickets which are close to
approval, but for which the one-week voting period ends in the
afternoon today. In the very likely case that they are approved, I'll
include their announcement in today's meeting summary.


= Followups =


= New business =

#2429 F33 System-Wide Change: Make btrfs the default file system for desktop 
variants
https://pagure.io/fesco/issue/2429

#2441 F34 System-Wide Change: RPM-level auto release and changelog bumping
https://pagure.io/fesco/issue/2441

#2440 F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached 
rpm changelogs
https://pagure.io/fesco/issue/2440

#2445 Proposal: Make the "shortcut" decision process require a specific request 
and assent
https://pagure.io/fesco/issue/2445


= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Outdated programs in rawhide

[Xose Vazquez Perez]

scala: https://bugzilla.redhat.com/1080923
libnetfilter_queue: https://bugzilla.redhat.com/1512736
nftables: https://bugzilla.redhat.com/1846663
libcap: https://bugzilla.redhat.com/1700167
ed: https://bugzilla.redhat.com/1805337
gawk: https://bugzilla.redhat.com/1823770
freetype: https://bugzilla.redhat.com/1725983
efibootmgr: https://bugzilla.redhat.com/1431340
pidgin: https://bugzilla.redhat.com/1856866
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Anyone using Tiled windows on Plasma out there ?

[Sergio Belkin]

El mar., 14 jul. 2020 a las 18:17, John Florian ()
escribió:

> On 2020-07-14 13:42, Sergio Belkin wrote:
>
> What is the better option to to get tiled windows in Plasma?
>
> I've tried a few kwin scripts with no luck, for example:
>
> - Grid-Tiling
> - Krohnkite
> - Tiling Extension
>
> The best I've tried so far is the last one, but can be too unstable...
>
> What is your experience about it?
> --
> --
> Sergio Belkin
> LPIC-2 Certified - http://www.lpi.org
>
>
> I'm using and mostly quite happy with
> https://github.com/kwin-scripts/kwin-tiling.  I didn't realize there were
> so many options, so if anyone has used kwin-tiling and any of the others,
> I'd be curious to hear opinions.
>

Yup, AFAIK  "Tiling Extension" is
https://github.com/kwin-scripts/kwin-tiling. In fact, I think is the best
option available, but it happens sometimes on non-weekend days that it
becomes buggy and unstable, and it's pain, kwin crashes, I have to use
openbox, to recover it the session control, but I think that is when I open
Thunderbird for my job...
-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Anyone using Tiled windows on Plasma out there ?

[Sergio Belkin]

El mar., 14 jul. 2020 a las 17:06, Robert-André Mauchin ()
escribió:

> On Tuesday, 14 July 2020 19:42:17 CEST Sergio Belkin wrote:
>
> I've never heard about Krohnkite, nor Tiling Extension? Where is it
> available?
>
>
> Krohnkite is available here  https://github.com/esjeon/krohnkite , well
it's funny I'm testing it again, and it behaves well so far. It would be
nice that kwin had full support for tiled windows :)


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

Re: Anyone using Tiled windows on Plasma out there ?

[Sergio Belkin]

El mar., 14 jul. 2020 a las 17:06, Robert-André Mauchin ()
escribió:

> On Tuesday, 14 July 2020 19:42:17 CEST Sergio Belkin wrote:
> > What is the better option to to get tiled windows in Plasma?
> >
> > I've tried a few kwin scripts with no luck, for example:
> >
> > - Grid-Tiling
> > - Krohnkite
> > - Tiling Extension
> >
> > The best I've tried so far is the last one, but can be too unstable...
> >
> > What is your experience about it?
>
> I use https://github.com/lingtjien/Grid-Tiling-Kwin I've got no issue
> with it
> except it doesn't work in Wayland.
>

I've tried with Grid-Tiling-Kwin, but the behavior it's bit weird or at
least I have to restart the session, I will do that and tell you if it gets
better.



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

Re: Btrfs in Silverblue

[Chris Murphy]

On Tue, Jul 14, 2020 at 7:45 AM Lennart Poettering  wrote:
>
> On Di, 14.07.20 07:09, Chris Murphy (li...@colorremedies.com) wrote:
>
> > > > Why at boot time? Well if your default subvolume contains a recent
> > > > update that for some reason renders it unbootable, it might be nice to
> > > > be able to pick a prior snapshot. That's how they do this. It isn't
> > > > how we have to do it, but that's the example that we know works
> > > > because it's actually designed, planned, implemented and maintained.
> > >
> > > Nah, this kind of selection you do in the initrd, not in the boot loader.
> >
> > There are two examples of the latter: (open)SUSE and rpm-ostree. I'm
> > not aware of any examples of the former.
>
> I am sorry, what? rpm-ostree has a grub module it needs to operate?

No.

You said "this kind of selection" - which suggests user action. The
user action to choose a particular tree version has two examples, and
both of them happen in the bootloader (really, the boot manager's menu
of boot entries). I don't know what selection of this would look like
if it were in the initrd - maybe some kind of automatic test for
successful boot and if it doesn't succeed it reboots and tries some
other tree automatically? But changing trees like this means you need
a way to specify them without depending on read-write mount. You may
not have read-write mount during the failed boot.

> > Note however that there's resistance supporting arbitrary partition
> > type GUIDs, due to tooling. The installer depends on 'parted' for
> > doing the partitioning and 'parted' has no concept of arbitrary
> > partition types, each one must be explicitly added, and they are way
> > behind where fdisk and gdisk are. As in, nothing in the Discoverable
> > Partition Spec is in 'parted' right now. I've asked multiple times
> > over the years.
>
> use libfdisk instead?

That's up to anaconda/blivet folks. I can't estimate the amount of
work to do that, versus the gains.


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

Re: Anyone using Tiled windows on Plasma out there ?

[John Florian]

On 2020-07-14 13:42, Sergio Belkin wrote:
> What is the better option to to get tiled windows in Plasma?
>
> I've tried a few kwin scripts with no luck, for example:
>
> - Grid-Tiling
> - Krohnkite
> - Tiling Extension
>
> The best I've tried so far is the last one, but can be too unstable...
>
> What is your experience about it?
> -- 
> --
> Sergio Belkin
> LPIC-2 Certified - http://www.lpi.org


I'm using and mostly quite happy with
https://github.com/kwin-scripts/kwin-tiling.  I didn't realize there
were so many options, so if anyone has used kwin-tiling and any of the
others, I'd be curious to hear opinions.

>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: Ditch RPM in favor of DPKG

[Dishant Pandya]

Its ok to have something that builds deb packages on Fedora, but in my opinion 
RPM is far more better then debian packages. Also the Dnf and yum package 
manager on Fedora are far more advanced than apt on Ubuntu and other Debian 
Based system.
I have been using fedora for over 2 years now and I have never faced the 
package installation issues that I faced with apt and dpkg, for whatever 
unknown reasons, may be some corruption of  package file, installation state 
Ubuntu's package manager gets erroneous to an unrecoverable state, and I being 
a normal desktop user wasn't able to restore the state, and had to reinstall 
the whole OS from scratch. dpkg/apt is good when it works, but when it breaks 
its unrecoverable. RPM , dnf/yum are more reliable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ditch RPM in favor of DPKG

[Dishant Pandya]

Its ok to have something that builds deb packages on Fedora, but in my opinion 
RPM is far more better then debian packages. Also the Dnf and yum package 
manager on Fedora are far more advanced than apt on Ubuntu and other Debian 
Based system.
I have been using fedora for over 2 years now and I have never faced the 
package installation issues that I faced with apt and dpkg, for whatever 
unknown reasons, may be some corruption of  package file, installation state 
Ubuntu's package manager gets erroneous to an unrecoverable state, and I being 
a normal desktop user wasn't able to restore the state, and had to reinstall 
the whole OS from scratch. dpkg/apt is good when it works, but when it breaks 
its unrecoverable. RPM , dnf/yum are more reliable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Anyone using Tiled windows on Plasma out there ?

[Robbie Harwood]

Sergio Belkin  writes:

> What is the better option to to get tiled windows in Plasma?
>
> I've tried a few kwin scripts with no luck, for example:
>
> - Grid-Tiling
> - Krohnkite
> - Tiling Extension
>
> The best I've tried so far is the last one, but can be too unstable...
>
> What is your experience about it?

I've not tried (not a KDE user), but wanted to offer that it might be
easier to swap out the window manager completely completely rather than
using a script/extension.  KDE 4 + 5 look to have provisions for this by
making a script that does `export KDEWM=/path/to/your/wm` [1].

Thanks,
--Robbie

1: 
https://wiki.haskell.org/Xmonad/Using_xmonad_in_KDE#Make_xmonad_your_window_manager_in_KDE


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: Anyone using Tiled windows on Plasma out there ?

[Robert-André Mauchin]

On Tuesday, 14 July 2020 19:42:17 CEST Sergio Belkin wrote:
> What is the better option to to get tiled windows in Plasma?
> 
> I've tried a few kwin scripts with no luck, for example:
> 
> - Grid-Tiling
> - Krohnkite
> - Tiling Extension
> 
> The best I've tried so far is the last one, but can be too unstable...
> 
> What is your experience about it?

I use https://github.com/lingtjien/Grid-Tiling-Kwin I've got no issue with it 
except it doesn't work in Wayland.
Previously I've used https://github.com/Jazqa/kwin-quarter-tiling and https://
github.com/kwin-scripts/kwin-tiling (by faho) but it was a little unstable. 
I've never heard about Krohnkite, nor Tiling Extension? Where is it available?

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

Orphaning a number of Lua-related packages

[Tim Niemueller]

Dear Fedora Community.

Things have changed and I can no longer perform all maintainer duties. I 
have just orphaned several packages. I have given packages which had a 
co-maintainer to them (Thank you! Many already acted as primary 
maintainers for a while). If there is a package you care about or use 
please consider taking over maintainership.


The packages are:
https://src.fedoraproject.org/rpms/emacs-lua
https://src.fedoraproject.org/rpms/lua-copas
https://src.fedoraproject.org/rpms/lua-coxpcall
https://src.fedoraproject.org/rpms/luadoc
https://src.fedoraproject.org/rpms/lua-logging
https://src.fedoraproject.org/rpms/lua-sql
https://src.fedoraproject.org/rpms/lua-wsapi
https://src.fedoraproject.org/rpms/lua-xmlrpc
https://src.fedoraproject.org/rpms/xavante

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

Re: Btrfs in Silverblue

[Chris Murphy]

On Tue, Jul 14, 2020 at 1:45 AM Lennart Poettering  wrote:
>
> On Mo, 13.07.20 19:16, Chris Murphy (li...@colorremedies.com) wrote:
>
> > > Yes, because you have to propagate it everywhere, and if you omit it
> > > things break, since it's a secondary place you store information about
> > > the root disk in that you strictly need to have to be able to make
> > > sense of the file system.
> >
> > As it relates to Silverblue, how is the 'ostree=' parameter any
> > different or less fragile than 'root=' or 'rootflags=' and how could
> > it be made automatically discoverable? That information is currently
> > in the bootloader configuration file, and the means for switching
> > between roots is by bootloader menu item.
>
> I don't know how ostree works precisely.
>
> If they want different ostree versions show up in the boot menu, they
> of course have to synthesize boot menu items each time they add a new
> ostree version, and that boot menu item should then clearly be bound
> to the ostree hash, and for that kind of stuff using the ostree=
> kernel cmdline param makes things.

I'm suggesting the ostree= parameter is analogous to the
rootflags=subvol= parameter. Both point to (sub) trees that are
separate system roots.


> If however they share the same kernel/boot menu item between multiple
> versions of the OS tree, then I'd always embedd which version to boot
> in the fs itself by default, so that the OS file system is
> self-descriptive (and you thus can boot it consistently with
> systemd-nspawn --image=). It could be as simple as adding a symlink
> called "default" to the right ostree hash or so, i.e. taking
> inspiration from git. When you switch defaults you would then just
> update where the symlink points.

The kernel might be the same or different between ostrees. But if I
remove the ostree= hint, the system doesn't boot.


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

Re: PostgreSQL 13 - Fedora 33 Self-Contained Change proposal

[Fabio Valentini]

On Tue, Jul 7, 2020 at 9:17 PM Ben Cotton  wrote:
> == Upgrade/compatibility impact ==
> The PostgreSQL client library (libpq component) is compatible, so
> there shouldn't be any issues, but rebuild of the depended components
> is better to be sure. There is a
> [https://copr.fedorainfracloud.org/coprs/panovotn/postgresql-13beta2/
> COPR build] available for testing.

What does "is compatible but rebuild of dependencies is better to be
sure" mean here?
Is there an ABI / SONAME involved in the libpq update?

> Server plugins might require a newer version update, because they
> sometimes have explicit server requirements. PostgreSQL maintainer
> will help fixing/rebuilding any issues in the plugins.

I'd rather see an organized rebuild of dependent packages, preferably
in a koji side tag.
During the fedora 32 development cycle, this didn't happen at all and
postgresql plugins needed to be "rescued" shortly before the fedora 32
GA.

> == Dependencies ==
>
> There are some packages (mostly server plugins), that build on top of
> PostgreSQL. Since the separation of PostgreSQL client library (libpq
> component), only packages that build server plugins should use
> postgresql package in BuildRequires, others should use libpq. In both
> the cases, rebuild should be done to make sure all potential binary
> incompatibilities are handled.

Do you expect binary incompatibilities between libpq 12 and 13? I
would hope that not to be the case if there's not an SONAME bump ...
but if there *is* an ABI change, a targeted rebuild of those
dependencies should happen.

> == Contingency Plan ==
>
> Modules will provide the functional version of PostgreSQL 12,
> available to all users.

As Miro said - this is not a contingency plan.
We can't just ship a broken version of postgresql by default.

> == Release Notes ==
>
> Release notes for PostgreSQL 13 release:
> https://www.postgresql.org/docs/13/index.html
>
> Overall overview of the changes and improvements:
> https://www.postgresql.org/docs/13/release-13.html

It looks like the final release of PostgreSQL 13 will happen not long
before the fedora 33 release date (sometime in "Q3 2020" according to
upstream).

I would suggest to wait with the PostgreSQL 13 update until the final
release, and then do the necessary builds and rebuilds of dependent
packages in a side tag, and check the results. If they're bad, hold
off on the PostgreSQL 13 update until fedora 34 (or fix broken
dependencies). If the results are good, merge the side tag and ship
PostgreSQL 13 with fedora 33 (preferably before the beta release).
Everything else is asking for trouble (particularly looking back at
the corresponding f32 Change).

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: X.org Utility Deaggregation - Fedora 33 Self-Contained Change proposal

[Adam Jackson]

On Sat, Jul 11, 2020 at 6:22 AM Zbigniew Jędrzejewski-Szmek
 wrote:

> Repoquery:
> $ for i in xorg-x11-{apps,font-utils,server-utils,utils,xkb-utils}; do echo 
> == $i; dnf repoquery --whatrequires $i; echo; done

This is a bit of an overcount since you're not using --exactdeps.

datura:~% for i in
xorg-x11-{apps,font-utils,server-utils,utils,xkb-utils}; do echo ==
$i; dnf -q repoquery --exactdeps --whatrequires $i --qf %{sourcerpm} |
sort -u; echo; done
== xorg-x11-apps
arcem-1.50.2-6.fc31.src.rpm
ddd-3.3.12-33.fc31.src.rpm
freenx-server-0.7.3-47.fc31.src.rpm
squeak-vm-4.10.2.2614-22.fc31.src.rpm
xmonad-0.15-3.fc31.src.rpm

== xorg-x11-font-utils
nethack-3.6.6-1.fc31.src.rpm
nx-libs-3.5.99.24-1.fc31.src.rpm
urw-base35-fonts-20170801-13.fc31.src.rpm

== xorg-x11-server-utils
arandr-0.1.10-1.fc31.src.rpm
classification-banner-1.7.0-4.fc31.src.rpm
gdm-3.34.1-1.fc31.src.rpm
i-nex-7.6.1-1.fc31.src.rpm
lutris-0.5.7-1.fc31.src.rpm
lxde-common-0.99.2-8.fc31.src.rpm
lxrandr-0.3.2-2.fc31.src.rpm
ocaml-camlimages-4.2.5-11.fc31.src.rpm
plasma-workspace-5.18.5-2.fc31.src.rpm
urw-base35-fonts-20170801-13.fc31.src.rpm
xfce4-session-4.14.2-1.fc31.src.rpm
xkeycaps-2.46-26.fc31.src.rpm

== xorg-x11-utils
backintime-1.2.0-6.fc31.src.rpm
boswars-2.7-19.svn160110.fc31.src.rpm
compiz-manager-0.7.0-9.fc31.src.rpm
compton-0.1-0.5.beta3.fc31.src.rpm
cros-guest-tools-1.0-0.35.20200611git5ab8724.fc31.src.rpm
ddd-3.3.12-33.fc31.src.rpm
gnome-shell-extension-unite-8-5.fc31.src.rpm
gyazo-1.2-9.fc31.src.rpm
inxi-3.1.03-1.fc31.src.rpm
java-atk-wrapper-0.33.2.1-0.pre01.fc31.src.rpm
kodi-18.6-1.fc31.src.rpm
lxde-common-0.99.2-8.fc31.src.rpm
plasma-workspace-5.18.5-2.fc31.src.rpm
surf-2.0-8.fc31.src.rpm
wallpapoz-0.6.2-11.fc31.src.rpm

== xorg-x11-xkb-utils
bicon-0.5-9.fc31.src.rpm
calamares-3.2.11-7.fc31.src.rpm
ibus-1.5.21-9.fc31.src.rpm
tigervnc-1.10.1-5.fc31.src.rpm
x2goserver-4.1.0.3-5.fc31.src.rpm

36 packages is a little more than I was hoping for, but still not bad.
I'll start going through this list to figure out what needs to change.

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

Anyone using Tiled windows on Plasma out there ?

[Sergio Belkin]

What is the better option to to get tiled windows in Plasma?

I've tried a few kwin scripts with no luck, for example:

- Grid-Tiling
- Krohnkite
- Tiling Extension

The best I've tried so far is the last one, but can be too unstable...

What is your experience about it?
-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs in Silverblue

[Colin Walters]

On Tue, Jul 14, 2020, at 3:44 AM, Lennart Poettering wrote:

> If however they share the same kernel/boot menu item between multiple
> versions of the OS tree, then I'd always embedd which version to boot
> in the fs itself by default, 

Yep, that's how it works today - ostree only touches the BLS configs if it 
needs to, which is:
- If you are changing the kernel/initramfs or kernel arguments
- If you are changing the number of "deployments"

> I am sorry, what? rpm-ostree has a grub module it needs to operate?

No, but ostree does have "bootloader backends" which regenerate bootloader 
configs from BLS because it needs to support bootloaders that haven't yet 
implemented it.  E.g. we shipped OSTree since RHEL7 and I didn't want to 
require patching GRUB there, plus u-boot is widely used still (with ostree too) 
and apparently doesn't support it yet either.

The real nightmare was https://github.com/ostreedev/ostree/pull/2044 when we 
found out the hard way that because we don't update BIOS grub (neither with 
`yum update` nor `rpm-ostree`) when we tried to hard require BLS some people 
lost all the ostree bootloader entries...

Anyways, we don't use that in FCOS (or FIoT as Peter mentioned).  
Silverblue-with-Anaconda still does but I think it's just a matter of adding 
https://github.com/coreos/coreos-assembler/commit/311768c2b14775f4ad18dad05a9e4dfd2e6387b6
 to Anaconda.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs in Silverblue

[Peter Robinson]

On Tue, Jul 14, 2020 at 2:45 PM Lennart Poettering  wrote:
>
> On Di, 14.07.20 07:09, Chris Murphy (li...@colorremedies.com) wrote:
>
> > > > Why at boot time? Well if your default subvolume contains a recent
> > > > update that for some reason renders it unbootable, it might be nice to
> > > > be able to pick a prior snapshot. That's how they do this. It isn't
> > > > how we have to do it, but that's the example that we know works
> > > > because it's actually designed, planned, implemented and maintained.
> > >
> > > Nah, this kind of selection you do in the initrd, not in the boot loader.
> >
> > There are two examples of the latter: (open)SUSE and rpm-ostree. I'm
> > not aware of any examples of the former.
>
> I am sorry, what? rpm-ostree has a grub module it needs to operate?
>
> Really?

It's not needed with BLS, we don't ship it in the IoT Edition.

> > > i.e. if /home is split out into its own fs, then you give it the home
> > > partition uuid type, but if not, then it is just part of the root
> > > partition (as that is the immedate parent directory) and thus sits in
> > > the same partition as the root fs.
> >
> > In the case of Btrfs, sysroot and home are in their own subvolumes
> > (separate namespace, separate btrees). Neither is a parent of the
> > other.
>
> Well, still, /home is conceptually ultimately a child of /, regardless
> how you organize stuff on the lowest layer...
>
> > > That all said, it might make sense to define a new partition type uuid
> > > for "btrfs-all-in-one" file systems, because for that it might make
> > > sense to even allow multiple OS archs in the same btrfs file system,
> > > e.g. have a subvol /_root.fedora32.x86_64 for the x86_64 version of
> > > the OS, but /_root.fedora32.arm64 for the ARM version and then have a
> > > single fs that can be booted on either arch.
> >
> > OK. Roll the dice, add another GUID to the spec.
> >
> > Note however that there's resistance supporting arbitrary partition
> > type GUIDs, due to tooling. The installer depends on 'parted' for
> > doing the partitioning and 'parted' has no concept of arbitrary
> > partition types, each one must be explicitly added, and they are way
> > behind where fdisk and gdisk are. As in, nothing in the Discoverable
> > Partition Spec is in 'parted' right now. I've asked multiple times
> > over the years.
>
> use libfdisk instead?
>
> > > Well, that's very old, I would't do it like that anymore. But yeah,
> > > there are ideas there that are related.
> >
> > The naming schema would be nice to get figured out. Right now the
> > naming of subvolumes is user domain in the installer. This concept
> > necessarily takes that away, it becomes system domain. And what
> > happens if a user changes the name? Is it a bad idea to stuff a copy
> > of this information in an XATTR so it can be restored? The schema
> > needs to account for snapshotting and rollbacks. I'm not sure how much
> > information really should be encoded in a subvolume name.
>
> We manage to name RPMs with versions, epochs, archs and so on, I doubt
> we need much more for naming subvolumes to auto-assemble.
>
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs in Silverblue

[Lennart Poettering]

On Di, 14.07.20 07:09, Chris Murphy (li...@colorremedies.com) wrote:

> > > Why at boot time? Well if your default subvolume contains a recent
> > > update that for some reason renders it unbootable, it might be nice to
> > > be able to pick a prior snapshot. That's how they do this. It isn't
> > > how we have to do it, but that's the example that we know works
> > > because it's actually designed, planned, implemented and maintained.
> >
> > Nah, this kind of selection you do in the initrd, not in the boot loader.
>
> There are two examples of the latter: (open)SUSE and rpm-ostree. I'm
> not aware of any examples of the former.

I am sorry, what? rpm-ostree has a grub module it needs to operate?

Really?

> > i.e. if /home is split out into its own fs, then you give it the home
> > partition uuid type, but if not, then it is just part of the root
> > partition (as that is the immedate parent directory) and thus sits in
> > the same partition as the root fs.
>
> In the case of Btrfs, sysroot and home are in their own subvolumes
> (separate namespace, separate btrees). Neither is a parent of the
> other.

Well, still, /home is conceptually ultimately a child of /, regardless
how you organize stuff on the lowest layer...

> > That all said, it might make sense to define a new partition type uuid
> > for "btrfs-all-in-one" file systems, because for that it might make
> > sense to even allow multiple OS archs in the same btrfs file system,
> > e.g. have a subvol /_root.fedora32.x86_64 for the x86_64 version of
> > the OS, but /_root.fedora32.arm64 for the ARM version and then have a
> > single fs that can be booted on either arch.
>
> OK. Roll the dice, add another GUID to the spec.
>
> Note however that there's resistance supporting arbitrary partition
> type GUIDs, due to tooling. The installer depends on 'parted' for
> doing the partitioning and 'parted' has no concept of arbitrary
> partition types, each one must be explicitly added, and they are way
> behind where fdisk and gdisk are. As in, nothing in the Discoverable
> Partition Spec is in 'parted' right now. I've asked multiple times
> over the years.

use libfdisk instead?

> > Well, that's very old, I would't do it like that anymore. But yeah,
> > there are ideas there that are related.
>
> The naming schema would be nice to get figured out. Right now the
> naming of subvolumes is user domain in the installer. This concept
> necessarily takes that away, it becomes system domain. And what
> happens if a user changes the name? Is it a bad idea to stuff a copy
> of this information in an XATTR so it can be restored? The schema
> needs to account for snapshotting and rollbacks. I'm not sure how much
> information really should be encoded in a subvolume name.

We manage to name RPMs with versions, epochs, archs and so on, I doubt
we need much more for naming subvolumes to auto-assemble.

Lennart

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

Fedora rawhide compose report: 20200714.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200713.n.0
NEW: Fedora-Rawhide-20200714.n.0

= SUMMARY =
Added images:1
Dropped images:  9
Added packages:  11
Dropped packages:6
Upgraded packages:   101
Downgraded packages: 0

Size of added packages:  87.56 MiB
Size of dropped packages:1.22 MiB
Size of upgraded packages:   1.64 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   100.82 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20200714.n.0.s390x.tar.xz

= DROPPED IMAGES =
Image: Cloud_Base vmdk s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200713.n.0.s390x.vmdk
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20200713.n.0.aarch64.raw.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200713.n.0.s390x.qcow2
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20200713.n.0.aarch64.tar.xz
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20200713.n.0.aarch64.raw.xz
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20200713.n.0.aarch64.raw.xz
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200713.n.0.s390x.raw.xz
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-Rawhide-20200713.n.0.aarch64.tar.xz
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200713.n.0.ppc64le.tar.xz

= ADDED PACKAGES =
Package: 7kaa-2.15.4-1.fc33
Summary: Seven Kingdoms: Ancient Adversaries
RPMs:7kaa 7kaa-data
Size:36.37 MiB

Package: eclipse-webtools-3.18.0-2.fc33
Summary: Eclipse Webtools Projects
RPMs:eclipse-webtools-common eclipse-webtools-servertools 
eclipse-webtools-sourceediting
Size:16.78 MiB

Package: golang-github-instrumenta-kubeval-0.15.0-1.fc33
Summary: Validate your Kubernetes configuration files
RPMs:golang-github-instrumenta-kubeval 
golang-github-instrumenta-kubeval-devel
Size:16.62 MiB

Package: libx86-1.1-30.fc33
Summary: Library for making real-mode x86 calls
RPMs:libx86 libx86-devel
Size:129.57 KiB

Package: mingw-drmingw-0.9.2-1.fc33
Summary: Just-in-Time (JIT) debugger for MinGW
RPMs:mingw32-drmingw mingw32-drmingw-devel mingw64-drmingw 
mingw64-drmingw-devel
Size:594.51 KiB

Package: mingw-sparsehash-2.0.3-1.fc33
Summary: MinGW Extremely memory-efficient C++ hash_map implementation
RPMs:mingw32-sparsehash mingw64-sparsehash
Size:113.90 KiB

Package: opencsd-0.14.1-1.fc33
Summary: An open source CoreSight(tm) Trace Decode library
RPMs:opencsd opencsd-devel
Size:3.17 MiB

Package: python-gcsfs-0.6.2-2.fc33
Summary: Convenient Filesystem interface over GCS
RPMs:python-gcsfs-doc python3-gcsfs
Size:4.72 MiB

Package: python-simpleaudio-1.0.4-1.fc33
Summary: Simple, asynchronous audio playback module for Python 3
RPMs:python3-simpleaudio
Size:9.05 MiB

Package: python-wavio-0.0.4-2.fc33
Summary: Read and write WAV files as numpy arrays
RPMs:python3-wavio
Size:16.79 KiB

Package: tex-cjw-20090907-5.fc33
Summary: LaTeX class for writing resumes and cover letters
RPMs:tex-cjw
Size:12.51 KiB


= DROPPED PACKAGES =
Package: python-cltk-0.1.111-3.fc33
Summary: NLP support for Ancient Greek and Latin
RPMs:python3-cltk
Size:987.80 KiB

Package: python-pip-shims-0.3.2-5.fc33
Summary: Pip-shims is a set of compatibility access shims to the pip internal 
API
RPMs:python3-pip-shims
Size:22.67 KiB

Package: python-pythonfinder-1.2.1-5.fc33
Summary: Python library for finding Python interpreter files
RPMs:python3-pythonfinder
Size:63.63 KiB

Package: python-tgext-crud-0.8.2-10.fc33
Summary: Crud Controller Extension for TG2
RPMs:python3-tgext-crud
Size:42.54 KiB

Package: python-vistir-0.4.3-6.fc33
Summary: Python library full of utility functions
RPMs:python3-vistir
Size:90.25 KiB

Package: python-yaspin-0.14.3-6.fc33
Summary: Python library for terminal spinners
RPMs:python3-yaspin
Size:37.32 KiB


= UPGRADED PACKAGES =
Package:  NetworkManager-1:1.26.0-1.fc33
Old package:  NetworkManager-1:1.26.0-0.1.fc33
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs 
NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi 
NetworkManager-wwan
Size: 28.30 MiB
Size change:  47.93 KiB
Changelog:
  * Mon Jul 13 2020 Thomas Haller  - 1:1.26.0-1
  - update to 1.26.0

Re: Btrfs in Silverblue

[Chris Murphy]

On Tue, Jul 14, 2020 at 1:39 AM Lennart Poettering  wrote:
>
> On Mo, 13.07.20 19:07, Chris Murphy (li...@colorremedies.com) wrote:
>
> Yes, the kernel also supports an initrd-less mode, where it's the
> kernel itself that parses root=/rootflags=, but we don't use that in
> Fedora (and because btrfs.ko is a module on Fedora can't be done at
> all if your rootfs is btrfs). In this mode the syntax of root= is a
> lot simpler, as the kernel itself doesn't grok all syntaxes we support
> in libblkid/udev.
>
> So yes, root=/rootflags= is territory of udev/dracut/systemd on
> Fedora. On Fedora the kernel does *not* parse that itself. The kernel
> will ultimately get the parsed data passed back in, via the mount()
> syscall, but that's all.

:facepalm: OK now I'm getting some idea why you like no initrd capable
boot. BTW, btrfs is built-in as of kernel 5.8.0-0.rc5.1.fc33
(yesterday).


>
> > In the single existing example of a distribution using btrfs default
> > subvolumes, (open)SUSE, the bootloader automatically discovers the
> > read only snapshots, and understands how to do rollback by specifying
> > the proper /boot and / snapshot pairing.
>
> Are you sure?

Yes.

>
> > Why at boot time? Well if your default subvolume contains a recent
> > update that for some reason renders it unbootable, it might be nice to
> > be able to pick a prior snapshot. That's how they do this. It isn't
> > how we have to do it, but that's the example that we know works
> > because it's actually designed, planned, implemented and maintained.
>
> Nah, this kind of selection you do in the initrd, not in the boot loader.

There are two examples of the latter: (open)SUSE and rpm-ostree. I'm
not aware of any examples of the former.


> > Ok but my home, server and variable data are all on the same volume,
> > each in their own subvolume. Why does this file system get the Root
> > partition type GUID and not the home, server, or var partition type
> > GUIDs?
>
> There's a hierarchy here: You put the root of the file system tree in
> some partition, and then if you decide to split off some subtree of
> it, that subtree will get its own fs with its own partition type
> UUID, but only then.
>
> i.e. if /home is split out into its own fs, then you give it the home
> partition uuid type, but if not, then it is just part of the root
> partition (as that is the immedate parent directory) and thus sits in
> the same partition as the root fs.

In the case of Btrfs, sysroot and home are in their own subvolumes
(separate namespace, separate btrees). Neither is a parent of the
other.

In the case of Silverblue, it is the same except they are separate
directories, but still neither is a parent of the other regardless of
what file system is used.


> That all said, it might make sense to define a new partition type uuid
> for "btrfs-all-in-one" file systems, because for that it might make
> sense to even allow multiple OS archs in the same btrfs file system,
> e.g. have a subvol /_root.fedora32.x86_64 for the x86_64 version of
> the OS, but /_root.fedora32.arm64 for the ARM version and then have a
> single fs that can be booted on either arch.

OK. Roll the dice, add another GUID to the spec.

Note however that there's resistance supporting arbitrary partition
type GUIDs, due to tooling. The installer depends on 'parted' for
doing the partitioning and 'parted' has no concept of arbitrary
partition types, each one must be explicitly added, and they are way
behind where fdisk and gdisk are. As in, nothing in the Discoverable
Partition Spec is in 'parted' right now. I've asked multiple times
over the years.

> > I regularly install multiple Fedora's, each in their own subvolume, on
> > a single Btrfs file system. That's way easier and much more space
> > efficient to deal with than using separate partitions and file systems
> > for each one. So you're saying, that's not a valid enough use case,
> > just use separate file systems for that?
>
> Well, as a matter of fact OSes like to fully own stuff, i.e. the boot
> loader, a file system and so on. If you want them to cooperate extra
> work needs to be done, i.e. specs written so that they don't fight for
> ownership but cooperate. For boot loaders the Boot Loader Spec can do
> that. But if you actually want to go as far sharing the same fs
> between multiple OSes, then you better have a very good spec in place
> that clarifies how they are supposed to cooperate and name stuff so
> that they don't constantly step on each other's toes.

Things are better in F33. I've got a proof of concept for F32 and F33
sharing the ESP and /boot volumes.


> > This is different in detail, but not altogether different from
> > http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
>
> Well, that's very old, I would't do it like that anymore. But yeah,
> there are ideas there that are related.

The naming schema would be nice to get figured out. Right now the
naming of subvolumes is user domain in the ins

Re: [fedora-java] Re: Announcement: Aim to remove libdb-java from Fedora-rawhide

[Ondrej Dubaj]

Hello everyone,

today I am removing libdb-java subpackage from Fedora-rawhide (see messages
above for more info). If someone of you will face any problems, please let
us know.

Thanks! Regards,

Ondrej

On Wed, Jun 24, 2020 at 11:27 AM Ondrej Dubaj  wrote:

> I don;t think this is a reason not removing libdb-java subpackage from
> Fedora-Rawhide. If you are an active user of it, or you know somebody who
> actively uses it, we can discuss more about these issues.
>
> Thanks,
> Ondrej
>
> On Mon, Jun 15, 2020 at 9:54 AM Florian Weimer  wrote:
>
>> * Jiri Vanek:
>>
>> > Is there some replacemnt for this subpackage? At least theoretical?
>>
>> For the JDBC connector to SQLite, there's sqlite-jdbc and javasqlite.
>> But the on-disk format will be different.
>>
>> For the key-value store, there is the je package, but again the on-disk
>> format is different.
>>
>> Thanks,
>> Florian
>>
>>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Firefox 78.0.2 for F32

[Bojan Smojver via devel]

Cool, thanks!

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

List of long term FTBFS packages to be retired in August

[Miro Hrončok]

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 33 approximately one week before branching (August 
2020).


Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


Note that some listed packages are orphaned and hence may be retired even 
sooner.

The packages in rawhide were not successfully built at least since Fedora 31.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.


  Package (co)maintainers  Latest build

OpenCoarrays   jussilehtolaFedora 30
js-jquery-jqplot   xavierb Fedora 30
js-jquery1 nodejs-sig, patches, vondruch   Fedora 30
js-jquery2 vondruchFedora 30
js-sizzle  nodejs-sig, patches, vondruch   Fedora 30
nodejs-path-type   nodejs-sig, orphan  Fedora 30
nodejs-temp-write  orphan  Fedora 30
nodejs-unique-stream   jsmith, nodejs-sig  Fedora 30
orpie  bowlofeggs, orphan  Fedora 30
rubygem-ruby-hmac  humaton, mmorsi Fedora 30


The following packages require above mentioned packages:
Depending on: js-jquery-jqplot (1)
sympa (maintained by: xavierb)
sympa-6.2.56-1.fc33.src requires js-jquery-jqplot = 1.0.9-3.fc30
sympa-6.2.56-1.fc33.x86_64 requires js-jquery-jqplot = 
1.0.9-3.fc30

Depending on: js-jquery1 (70)
R-profvis (maintained by: qulogic)
R-profvis-0.3.6-3.fc33.src requires js-jquery1 = 1.12.4-7.fc30
R-profvis-0.3.6-3.fc33.x86_64 requires js-jquery1 = 
1.12.4-7.fc30

R-rmarkdown (maintained by: qulogic)
R-rmarkdown-2.2-1.fc33.noarch requires js-jquery1 = 
1.12.4-7.fc30
R-rmarkdown-2.2-1.fc33.src requires js-jquery1 = 1.12.4-7.fc30

copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, 
msuchy, praiskup)
copr-frontend-1.166-1.fc33.noarch requires js-jquery1 = 
1.12.4-7.fc30

ghc-pretty-show (maintained by: mathstuf)
ghc-pretty-show-1.9.5-3.fc32.x86_64 requires js-jquery1 = 
1.12.4-7.fc30

mkdocs (maintained by: cheeselee)
mkdocs-1.1.2-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30
mkdocs-1.1.2-1.fc33.src requires js-jquery1 = 1.12.4-7.fc30

python-XStatic-jQuery (maintained by: mrunge, openstack-sig, rdopiera)
python3-XStatic-jQuery-3.4.1.0-2.fc33.noarch requires 
js-jquery1 = 1.12.4-7.fc30

python-sphinx-bootstrap-theme (maintained by: besser82, sic)
		python3-sphinx-bootstrap-theme-0.8.0-3.fc33.noarch requires js-jquery1 = 
1.12.4-7.fc30


rubygem-apipie-rails (maintained by: jaruga, ruby-packagers-sig, 
vondruch)
rubygem-apipie-rails-0.5.5-6.fc32.noarch requires js-jquery1 = 
1.12.4-7.fc30

R-BiocFileCache (maintained by: spot)
R-BiocFileCache-1.12.0-2.fc33.src requires R-rmarkdown = 
2.2-1.fc33

R-DBItest (maintained by: qulogic)
R-DBItest-1.7.0-1.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-V8 (maintained by: qulogic)
R-V8-3.1.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-broom (maintained by: qulogic)
R-broom-0.5.6-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-cellranger (maintained by: qulogic)
R-cellranger-1.1.0-6.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-clipr (maintained by: qulogic)
R-clipr-0.7.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-dbplyr (maintained by: qulogic)
R-dbplyr-1.4.3-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-devtools (maintained by: qulogic)
R-devtools-2.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-diffobj (maintained by: qulogic)
R-diffobj-0.3.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-dplyr (maintained by: qulogic)
R-dplyr-0.8.5-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-dtplyr (maintained by: qulogic)
R-dtplyr-1.0.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-foghorn (maintained by: qulogic)
R-foghorn-1.1.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-forcats (maintained by: qulogic)
R-forcats-0.5.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

 

Re: Firefox 78.0.2 for F32

[Jiří Eischmann]

Kevin Fenzi píše v Po 13. 07. 2020 v 16:37 -0700:
> On Tue, Jul 14, 2020 at 08:33:04AM +1000, Bojan Smojver via devel
> wrote:
> > Would someone with sufficient powers mind queueing up this update?
> 
> I would assume that person would be the one who built it... 
> 
> perhaps there's some reason for not wanting to push it yet. 
> (CCing builder here)

Jan is on holidays this week, so is the other Firefox maintainer
(Martin Stransky). We looked at the update, it built fine, runs fine,
Jan just probably forgot to push it before he left.
It's being pushed to F32/F31 updates-testing as we speak. Feedback
welcome ;)

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

Nest with Fedora CfP is open!

[Marie Nordin]

Nest with Fedora call for participation is open! We welcome you to submit a
session.

Conference website: https://flocktofedora.org/
Submission repo: https://pagure.io/flock/issues
CfP info: https://communityblog.fedoraproject.org/nest-with-fedora-cfp-open/
Conference dates: August 7th-9th
Submission deadline: Monday July 20th rolling, Monday July 27th final

Cheers,

--

Marie Nordin

Fedora Community Action and Impact Coordinator

Red Hat  • Fedora Project 

She/Her/Hers

T: +1.973.800.4967

IRC: riecatnor



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

Re: Btrfs in Silverblue

[Neal Gompa]

On Tue, Jul 14, 2020 at 5:31 AM Lennart Poettering  wrote:
>
> On Di, 14.07.20 04:35, Neal Gompa (ngomp...@gmail.com) wrote:
> > > Nah, this kind of selection you do in the initrd, not in the boot loader.
> >
> > Yes. SUSE does this at the bootloader time. A *huge* part of the code
> > they added to GRUB is to automatically discover all this and populate
> > the menu and boot selection. None of this code exists in the upstream
> > GRUB codebase. This is done so that when snapper automatically creates
> > snapshots, it's created and stored in a structure that GRUB knows to
> > traverse and enumerate for the menu. It *is* GRUB dependent, but in
> > practice, this is fine since they only use GRUB. And for that matter,
> > that's mostly true for us too...
>
> Oh, christ. So they have to replicate their whole frickin storage
> stack in Grub, with LUKS, iscsi, DM, MD, LVM and whatnot to make this
> work. This sounds like a maintainance nightmare.
>
> I am pretty sure we shouldn't try to replicate that. Boot loaders
> should be simple, and we should leave the initrd do such logic using
> our usual Linux storage stacks.
>
> > I am growing to understand that this is increasingly fundamentally
> > incompatible with the way Red Hat has been going with this. In the Red
> > Hat world with the Bootloader Spec, this *has* to be managed at the
> > initramfs/OS level and explicitly generated and configured. Things
> > like Boom (remember that?) are supposed to generate bootloader entry
> > configuration snippets when OS snapshots are made.
>
> Given that boot loader spec entries are just single drop-in files it
> should be reasonably safe and simple to add them and remove them
> atomically.
>
> > > The current GPT partition types for the root fs are defined for each
> > > arch separately, so that you can have a single GPT disk image with one
> > > root fs partition for each arch, but that doesn't fit anymore if
> > > suddenly one of the root fs can hold the data for multiple archs,
> > > because its btrfs with multiple subvols.
> >
> > It would be good to develop a scheme for this sort of thing and see if
> > we can also get openSUSE on board too, especially in time for SLE
> > 16.
>
> Do they document how they name stuff for this snapper thing anywhere?
>

I think it's documented somewhere, but I'll have to look for it...

> > > By doing that correctly now, you can easily extend things later
> > > incrementally without breaking stuff, just by *adding* stuff. And you
> > > gain immediate compat with "systemd-nspawn --image=" right-away as the
> > > basic minimum, which already is great.
> >
> > I would love to do that now, but right now I want to make sure
> > everything *works* before we jumble up the scheme we use to set up the
> > subvolumes.
>
> Maybe delay this feature one iteration if things aren't clear?
>

Changing the names for the subvolumes is *easy*, but right now I'm
working on getting ARM disk images built. Everything else is basically
done. I only really have bandwidth to work on one thing at a time
right now, so I'm literally talking about days or a week or so before
I can think about changing the scheme. It's not a "feature delay"
thing, it's a "Neal can only do one thing at a time" thing. :)



-- 
真実はいつも一つ！/ 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: Btrfs in Silverblue

[Lennart Poettering]

On Di, 14.07.20 04:35, Neal Gompa (ngomp...@gmail.com) wrote:
> > Nah, this kind of selection you do in the initrd, not in the boot loader.
>
> Yes. SUSE does this at the bootloader time. A *huge* part of the code
> they added to GRUB is to automatically discover all this and populate
> the menu and boot selection. None of this code exists in the upstream
> GRUB codebase. This is done so that when snapper automatically creates
> snapshots, it's created and stored in a structure that GRUB knows to
> traverse and enumerate for the menu. It *is* GRUB dependent, but in
> practice, this is fine since they only use GRUB. And for that matter,
> that's mostly true for us too...

Oh, christ. So they have to replicate their whole frickin storage
stack in Grub, with LUKS, iscsi, DM, MD, LVM and whatnot to make this
work. This sounds like a maintainance nightmare.

I am pretty sure we shouldn't try to replicate that. Boot loaders
should be simple, and we should leave the initrd do such logic using
our usual Linux storage stacks.

> I am growing to understand that this is increasingly fundamentally
> incompatible with the way Red Hat has been going with this. In the Red
> Hat world with the Bootloader Spec, this *has* to be managed at the
> initramfs/OS level and explicitly generated and configured. Things
> like Boom (remember that?) are supposed to generate bootloader entry
> configuration snippets when OS snapshots are made.

Given that boot loader spec entries are just single drop-in files it
should be reasonably safe and simple to add them and remove them
atomically.

> > The current GPT partition types for the root fs are defined for each
> > arch separately, so that you can have a single GPT disk image with one
> > root fs partition for each arch, but that doesn't fit anymore if
> > suddenly one of the root fs can hold the data for multiple archs,
> > because its btrfs with multiple subvols.
>
> It would be good to develop a scheme for this sort of thing and see if
> we can also get openSUSE on board too, especially in time for SLE
> 16.

Do they document how they name stuff for this snapper thing anywhere?

> > By doing that correctly now, you can easily extend things later
> > incrementally without breaking stuff, just by *adding* stuff. And you
> > gain immediate compat with "systemd-nspawn --image=" right-away as the
> > basic minimum, which already is great.
>
> I would love to do that now, but right now I want to make sure
> everything *works* before we jumble up the scheme we use to set up the
> subvolumes.

Maybe delay this feature one iteration if things aren't clear?

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: Btrfs in Silverblue

[Neal Gompa]

On Tue, Jul 14, 2020 at 3:39 AM Lennart Poettering  wrote:
>
> On Mo, 13.07.20 19:07, Chris Murphy (li...@colorremedies.com) wrote:
>
> > On Mon, Jul 13, 2020 at 12:14 PM Lennart Poettering
> >  wrote:
> >
> > > Quite frankly, I don't see why the boot loader should care about the
> > > btrfs subvolume the initrd later picks at all.
> >
> > As far as I'm aware, rootflags= is a kernel boot parameter, and it
> > informs the kernel of mount options for the file system defined by the
> > root= boot parameter. Neither are initrd related. None of Btrfs
> > options or assembly are done by initrd or dracut magic.
>
> No, this is not how this works on Fedora or any other modern distro.
>
> The initrd parses root= and rootflags=. Then waits with udev until the
> device that is specified with root= shows up (much of the syntax that
> root= accepts is actually defined by libblkid/udev, not the
> kernel). As soon as the device shows up the initrd mounts the file
> system, passing the mount opts from rootflags= to the kernel's mount()
> call.
>
> On Fedora/dracut this is mostly implemented in systemd itself,
> i.e. the "systemd-fstab-generator" parses root=/rootflags= and a
> couple of other things and then generates .mount units from that.
>
> IIRC suse also uses dracut, hence there it's the same.
>
> Yes, the kernel also supports an initrd-less mode, where it's the
> kernel itself that parses root=/rootflags=, but we don't use that in
> Fedora (and because btrfs.ko is a module on Fedora can't be done at
> all if your rootfs is btrfs). In this mode the syntax of root= is a
> lot simpler, as the kernel itself doesn't grok all syntaxes we support
> in libblkid/udev.
>
> So yes, root=/rootflags= is territory of udev/dracut/systemd on
> Fedora. On Fedora the kernel does *not* parse that itself. The kernel
> will ultimately get the parsed data passed back in, via the mount()
> syscall, but that's all.
>
> > In the single existing example of a distribution using btrfs default
> > subvolumes, (open)SUSE, the bootloader automatically discovers the
> > read only snapshots, and understands how to do rollback by specifying
> > the proper /boot and / snapshot pairing.
>
> Are you sure?
>
> > Why at boot time? Well if your default subvolume contains a recent
> > update that for some reason renders it unbootable, it might be nice to
> > be able to pick a prior snapshot. That's how they do this. It isn't
> > how we have to do it, but that's the example that we know works
> > because it's actually designed, planned, implemented and maintained.
>
> Nah, this kind of selection you do in the initrd, not in the boot loader.
>

Yes. SUSE does this at the bootloader time. A *huge* part of the code
they added to GRUB is to automatically discover all this and populate
the menu and boot selection. None of this code exists in the upstream
GRUB codebase. This is done so that when snapper automatically creates
snapshots, it's created and stored in a structure that GRUB knows to
traverse and enumerate for the menu. It *is* GRUB dependent, but in
practice, this is fine since they only use GRUB. And for that matter,
that's mostly true for us too...

I am growing to understand that this is increasingly fundamentally
incompatible with the way Red Hat has been going with this. In the Red
Hat world with the Bootloader Spec, this *has* to be managed at the
initramfs/OS level and explicitly generated and configured. Things
like Boom (remember that?) are supposed to generate bootloader entry
configuration snippets when OS snapshots are made.

One part of the reason why I'm *not* pushing for automatic snapshots
for all this right now is because I seriously have no idea how I'm
going to do this in a BLS-friendly way yet.

> > > > And it is currently. I don't see how it's any more safe and robust by
> > > > eliminating only rootflags, but not the root parameter.
> > >
> > > You don't need the root parameter, actually. systemd automatically
> > > finds the root fs for you, it can do that if the root fs is properly
> > > advertised via the GPT partition type, according to the Discoverable
> > > Partition Spec.
> > >
> > > https://systemd.io/DISCOVERABLE_PARTITIONS
> >
> > Ok but my home, server and variable data are all on the same volume,
> > each in their own subvolume. Why does this file system get the Root
> > partition type GUID and not the home, server, or var partition type
> > GUIDs?
>
> There's a hierarchy here: You put the root of the file system tree in
> some partition, and then if you decide to split off some subtree of
> it, that subtree will get its own fs with its own partition type
> UUID, but only then.
>
> i.e. if /home is split out into its own fs, then you give it the home
> partition uuid type, but if not, then it is just part of the root
> partition (as that is the immedate parent directory) and thus sits in
> the same partition as the root fs.
>
> That all said, it might make sense to define a new partition type uuid
> for "btrfs-all-in-o

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

[Benjamin Berg]

On Mon, 2020-07-13 at 19:25 -0600, Chris Murphy wrote:
> On Mon, Jul 13, 2020 at 12:00 PM Benjamin Berg  wrote:
> > If MemAvailable drops below 250MiB (roughly 6GiB * 4%), then this means
> > that we have less than 500MiB left for file caches. If we can't swap
> > (remember, swap is already pretty full too), then a big chunk of these
> > caches need to be dropped to make the memory available to applications.
> 
> I regularly see impressively low MemAvailable before earlyoom does
> SIGTERM, it's almost always swap available (amount of total that's not
> used) that's the defining factor. Well below 100MiB. This doesn't tend
> to last very long. Once memory is under this kind of pressure, so is
> swap, and as swap on zram is so fast, it gets to threshold fast as
> well.

Yep, EarlyOOM doesn't apply the limit if there is swap available. That
makes a lot of sense. When swap page is available, the kernel has the
choice which memory to reclaim (anonymous pages, i.e. swap, or file
backed pages, i.e. drop caches). So MemAvailable may drop much lower
temporarily and depending on the workload.

You could say that when swap is available you assume the kernel has the
ability to keep the system running reasonably well. Once swap runs out,
the kernel stops having a choice. It can only make room by reclaiming
important caches. And this will turn bad quickly, as it will eventually
include the executables/libraries that must be loaded as they are doing
work!

So, we don't want to get the kernel into the situation where it must
remove executables/libraries from main memory. If that happens, you can
end up hitting the disk for *every* function call.

Benjamin


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

Re: Btrfs in Silverblue

[Lennart Poettering]

On Mo, 13.07.20 19:16, Chris Murphy (li...@colorremedies.com) wrote:

> > Yes, because you have to propagate it everywhere, and if you omit it
> > things break, since it's a secondary place you store information about
> > the root disk in that you strictly need to have to be able to make
> > sense of the file system.
>
> As it relates to Silverblue, how is the 'ostree=' parameter any
> different or less fragile than 'root=' or 'rootflags=' and how could
> it be made automatically discoverable? That information is currently
> in the bootloader configuration file, and the means for switching
> between roots is by bootloader menu item.

I don't know how ostree works precisely.

If they want different ostree versions show up in the boot menu, they
of course have to synthesize boot menu items each time they add a new
ostree version, and that boot menu item should then clearly be bound
to the ostree hash, and for that kind of stuff using the ostree=
kernel cmdline param makes things.

If however they share the same kernel/boot menu item between multiple
versions of the OS tree, then I'd always embedd which version to boot
in the fs itself by default, so that the OS file system is
self-descriptive (and you thus can boot it consistently with
systemd-nspawn --image=). It could be as simple as adding a symlink
called "default" to the right ostree hash or so, i.e. taking
inspiration from git. When you switch defaults you would then just
update where the symlink points.

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: Btrfs in Silverblue

[Lennart Poettering]

On Mo, 13.07.20 19:07, Chris Murphy (li...@colorremedies.com) wrote:

> On Mon, Jul 13, 2020 at 12:14 PM Lennart Poettering
>  wrote:
>
> > Quite frankly, I don't see why the boot loader should care about the
> > btrfs subvolume the initrd later picks at all.
>
> As far as I'm aware, rootflags= is a kernel boot parameter, and it
> informs the kernel of mount options for the file system defined by the
> root= boot parameter. Neither are initrd related. None of Btrfs
> options or assembly are done by initrd or dracut magic.

No, this is not how this works on Fedora or any other modern distro.

The initrd parses root= and rootflags=. Then waits with udev until the
device that is specified with root= shows up (much of the syntax that
root= accepts is actually defined by libblkid/udev, not the
kernel). As soon as the device shows up the initrd mounts the file
system, passing the mount opts from rootflags= to the kernel's mount()
call.

On Fedora/dracut this is mostly implemented in systemd itself,
i.e. the "systemd-fstab-generator" parses root=/rootflags= and a
couple of other things and then generates .mount units from that.

IIRC suse also uses dracut, hence there it's the same.

Yes, the kernel also supports an initrd-less mode, where it's the
kernel itself that parses root=/rootflags=, but we don't use that in
Fedora (and because btrfs.ko is a module on Fedora can't be done at
all if your rootfs is btrfs). In this mode the syntax of root= is a
lot simpler, as the kernel itself doesn't grok all syntaxes we support
in libblkid/udev.

So yes, root=/rootflags= is territory of udev/dracut/systemd on
Fedora. On Fedora the kernel does *not* parse that itself. The kernel
will ultimately get the parsed data passed back in, via the mount()
syscall, but that's all.

> In the single existing example of a distribution using btrfs default
> subvolumes, (open)SUSE, the bootloader automatically discovers the
> read only snapshots, and understands how to do rollback by specifying
> the proper /boot and / snapshot pairing.

Are you sure?

> Why at boot time? Well if your default subvolume contains a recent
> update that for some reason renders it unbootable, it might be nice to
> be able to pick a prior snapshot. That's how they do this. It isn't
> how we have to do it, but that's the example that we know works
> because it's actually designed, planned, implemented and maintained.

Nah, this kind of selection you do in the initrd, not in the boot loader.

> > > And it is currently. I don't see how it's any more safe and robust by
> > > eliminating only rootflags, but not the root parameter.
> >
> > You don't need the root parameter, actually. systemd automatically
> > finds the root fs for you, it can do that if the root fs is properly
> > advertised via the GPT partition type, according to the Discoverable
> > Partition Spec.
> >
> > https://systemd.io/DISCOVERABLE_PARTITIONS
>
> Ok but my home, server and variable data are all on the same volume,
> each in their own subvolume. Why does this file system get the Root
> partition type GUID and not the home, server, or var partition type
> GUIDs?

There's a hierarchy here: You put the root of the file system tree in
some partition, and then if you decide to split off some subtree of
it, that subtree will get its own fs with its own partition type
UUID, but only then.

i.e. if /home is split out into its own fs, then you give it the home
partition uuid type, but if not, then it is just part of the root
partition (as that is the immedate parent directory) and thus sits in
the same partition as the root fs.

That all said, it might make sense to define a new partition type uuid
for "btrfs-all-in-one" file systems, because for that it might make
sense to even allow multiple OS archs in the same btrfs file system,
e.g. have a subvol /_root.fedora32.x86_64 for the x86_64 version of
the OS, but /_root.fedora32.arm64 for the ARM version and then have a
single fs that can be booted on either arch.

The current GPT partition types for the root fs are defined for each
arch separately, so that you can have a single GPT disk image with one
root fs partition for each arch, but that doesn't fit anymore if
suddenly one of the root fs can hold the data for multiple archs,
because its btrfs with multiple subvols.

> I regularly install multiple Fedora's, each in their own subvolume, on
> a single Btrfs file system. That's way easier and much more space
> efficient to deal with than using separate partitions and file systems
> for each one. So you're saying, that's not a valid enough use case,
> just use separate file systems for that?

Well, as a matter of fact OSes like to fully own stuff, i.e. the boot
loader, a file system and so on. If you want them to cooperate extra
work needs to be done, i.e. specs written so that they don't fight for
ownership but cooperate. For boot loaders the Boot Loader Spec can do
that. But if you actually want to go as far sharing the same fs
between multiple OSes