Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Chris Murphy]

On Wed, May 10, 2023, at 7:36 PM, Owen Taylor wrote:
> 
> 
> On Wed, May 10, 2023 at 5:34 PM Chris Murphy  wrote:
>> __
>> 
>> 
>> On Wed, May 10, 2023, at 2:24 PM, Owen Taylor wrote:
>>> 
>>> 
>>> On Wed, May 10, 2023 at 12:02 PM Neal Gompa  wrote:
 
>>> Now, there's a second problem with reading everything from the ESP - it's 
>>> slow for two reasons. First, because read speeds when going through the 
>>> firmware are much slower than the Linux NVMe stack. And second, because we 
>>> have to read everything in order to checksum and verify it.
>>> 
>>> For that reason, Demi's suggestion of moving things onto a dm-verity 
>>> protected partition is intriguing. Could that even be a loopback file on 
>>> the ESP? It would be like a lazy-read system extension.
>>> 
>>> The performance geek in me thinks "we could see exciting speedups from 
>>> that!" - the practical side of me thinks "it might be a few second faster. 
>>> And much more complex! Let's just go with efifb, keep the initramfs small, 
>>> and accept any minor regressions".
>> 
>> GRUB doesn't support dm-verity, but I don't know if it would make a 
>> difference if it did. Once the kernel has the ability to interact with 
>> physical storage, understand partitions, initialize dm-verity, and read a 
>> file systemt... it could just mount `/` . I think the only way the current 
>> initial root file system works with the kernel is for the bootloader to read 
>> an entire initrd file into RAM, and then the kernel can randomly access 
>> things in that RAM disk.
> 
> In this idea, the dm-verity parition/file would only be accessed from the 
> initrd, once we have enough kernel to ability to interact with physical 
> storage, understand partitions, initialize dm-verity, and read *a* partition, 
> but potentially not enough to read from a bluetooth keyboard, show a 
> graphical prompt, mount / from the network, etc.
> 
> What dm-verity provides here is a way to trust content without requiring it 
> to be read ahead of time, checksumed, signature checked and put into ram.
> 
> To be clear, I don't think this is necessarily the right way to go - I think 
> using efifb, not prompting for a passphrase when possible, etc, are simpler 
> approaches.

OK got it. So it would be some kind of intermediate /usr that bridges between 
initramfs and /sysroot mounting? I'm not sure the added complexity helps 
significantly with authenticity over either LUKS or fscrypt.


>  
>> 
>> It's early still for UKI details but I assume we will need both a universal 
>> UKI (all use cases), and much smaller use case focused UKIs. I say that 
>> because the desktops in the default installation configuration are the 
>> largest single use case. With Btrfs built-into the kernel, we don't need 
>> that much in the initrd to setup block devices, discover their contents, and 
>> perform switch root.
>> 
>> The next most common use case(s), device-mapper and md based, require a pile 
>> of user space programs running to do all the work setting things up. Maybe 
>> we can just get away with two images, a simple fast one and the universal.
> 
> The elephant in the room is whether the "desktops in the default 
> installation" UKI requires piles of graphics firmware. It might not be at all 
> small in that case.

True. I don't know what the limitations/reasons are for firmware blobs needing 
to be available so early during boot.

But (a) we have chosen a file system by default that we can shrink online (b) 
have at least 128 partitions possible (c) we can extent Boot Loader Spec to 
permit multiple XBOOTLDR. So we can make room for these firmware blobs. It's 
just fricking ugly. And I'm not sure it'll be RPM's domain if these things 
really need to exist on /boot. Something will have to put them there, as needed.



--
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Chris Murphy]

On Wed, May 10, 2023, at 7:11 PM, Chris Adams wrote:
> Once upon a time, Chris Murphy  said:
>> Read-only drivers, which are the only drivers under discussion here, aren't 
>> a per se problem because they can't modify the file system. So they have no 
>> complaints about that.
>
> But those read-only drivers are incomplete and problematic, especially
> as filesystems get more complex.  I've been bitten before by an
> ill-timed unclean shutdown, where an update was still in the /boot ext4
> journal but not comitted, so the system would not boot, because the
> GRUB2 ext4 driver doesn't read the journal.

Right.

But is the program updating /boot doing it correctly? Given the decision to use 
a journaled file system but a bootloader that doesn't do journal replay, it 
means the program needs to use a write order and sync policy to ensure there's 
no expectation of journal replay. Otherwise inevitably it's going to break. So 
it's a series of mistakes.


> There should be _less_ put into GRUB2 filesystem support IMHO, not more.
> No more complex filesystems; keep /boot something simple like ext2 that
> GRUB2 can reasonably be expected to handle basically 100%, possibly
> mounted read-only during normal operation, mount with "sync", and with
> all updates as atomic as practical.

It still needs the program that modifies /boot to do the updates in the proper 
sequence. That's not happening right now so it's a risk no matter the file 
system. But if simpler is better, and ext2 is acceptable, then FAT should also 
be acceptable. It has the added benefit of all firmware supporting it. 


-- 
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

HEADS UP: gdal-3.7.0 coming to rawhide

[Sandro Mani]

Hi

I'm preparing the gdal-3.7.0 update which carries a soname bump. Il 
build it in the f39-build-side-67536 side-tag, and rebuild the following 
dependencies:


   GMT
   mapserver
   liblas
   python-fiona
   postgis
   merkaartor
   R-rgdal
   bes
   saga
   qmapshack
   PDAL
   ncl
   vfrnav
   python-rasterio
   vtk
   paraview
   kealib
   OpenSceneGraph
   cloudcompare
   grass
   mapnik
   opencv
   mingw-opencv
   osgearth
   qgis
   gazebo

Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-0989e83e8a   
chromium-113.0.5672.63-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-7f7029b90d   
tcpreplay-4.4.3-3.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

gfal2-2.21.4-2.el7
python-rosdep-0.22.2-1.el7
python-rosinstall_generator-0.1.23-1.el7
python-rospkg-1.5.0-1.el7
rpki-client-8.4-2.el7

Details about builds:



 gfal2-2.21.4-2.el7 (FEDORA-EPEL-2023-a1be81c983)
 Grid file access library 2.0

Update Information:

Upstream release v2.21.4

ChangeLog:

* Tue May  9 2023 Mihai Patrascoiu  - 2.21.4-2
- Patch to correctly find cryptopp dependency on 32-bit architectures
* Mon May  8 2023 Mihai Patrascoiu  - 2.21.4-1
- Upgrade to upstream release 2.21.4




 python-rosdep-0.22.2-1.el7 (FEDORA-EPEL-2023-703f2815b4)
 ROS System Dependency Installer

Update Information:

Update to the latest ROS infrastructure package releases.

ChangeLog:

* Tue May  9 2023 Scott K Logan  - 0.22.2-1
- Update to 0.22.2 (rhbz#2180331)

References:

  [ 1 ] Bug #2115320 - python-catkin_lint-1.6.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2115320
  [ 2 ] Bug #2170020 - python-osrf-pycommon-2.1.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2170020
  [ 3 ] Bug #2174298 - python-rosinstall_generator-0.1.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2174298
  [ 4 ] Bug #2180331 - python-rosdep-0.22.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180331
  [ 5 ] Bug #2180332 - python-rospkg-1.5.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180332




 python-rosinstall_generator-0.1.23-1.el7 (FEDORA-EPEL-2023-703f2815b4)
 Generates rosinstall files

Update Information:

Update to the latest ROS infrastructure package releases.

ChangeLog:

* Tue May  9 2023 Scott K Logan  - 0.1.23-1
- Update to 0.1.23 (rhbz#2174298)

References:

  [ 1 ] Bug #2115320 - python-catkin_lint-1.6.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2115320
  [ 2 ] Bug #2170020 - python-osrf-pycommon-2.1.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2170020
  [ 3 ] Bug #2174298 - python-rosinstall_generator-0.1.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2174298
  [ 4 ] Bug #2180331 - python-rosdep-0.22.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180331
  [ 5 ] Bug #2180332 - python-rospkg-1.5.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180332




 python-rospkg-1.5.0-1.el7 (FEDORA-EPEL-2023-703f2815b4)
 Utilities for ROS package, stack, and distribution information

Update Information:

Update to the latest ROS infrastructure package releases.

ChangeLog:

* Tue May  9 2023 Scott K Logan  - 1.5.0-1
- Update to 1.5.0 (rhbz#2180332)

References:

  [ 1 ] Bug #2115320 - python-catkin_lint-1.6.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2115320
  [ 2 ] Bug #2170020 - python-osrf-pycommon-2.1.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2170020
  [ 3 ] Bug #2174298 - python-rosinstall_generator-0.1.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2174298
  [ 4 ] Bug #2180331 - python-rosdep-0.22.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180331
  [ 5 ] Bug #2180332 - python-rospkg-1.5.0 is available

[Bug 2192251] ctstream-33 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2192251

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|ctstream-33-1.fc39  |ctstream-33-1.fc39
   |ctstream-33-1.fc36  |ctstream-33-1.fc36
   |ctstream-33-1.fc37  |ctstream-33-1.fc37
   |ctstream-33-1.fc38  |ctstream-33-1.fc38
   |ctstream-33-1.el9   |ctstream-33-1.el9
   |ctstream-33-1.el8   |ctstream-33-1.el8
   ||ctstream-33-1.el7



--- Comment #19 from Fedora Update System  ---
FEDORA-EPEL-2023-110e6035a5 has been pushed to the Fedora EPEL 7 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2192251
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2192251] ctstream-33 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2192251

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|ctstream-33-1.fc39  |ctstream-33-1.fc39
   |ctstream-33-1.fc36  |ctstream-33-1.fc36
   |ctstream-33-1.fc37  |ctstream-33-1.fc37
   |ctstream-33-1.fc38  |ctstream-33-1.fc38
   |ctstream-33-1.el9   |ctstream-33-1.el9
   ||ctstream-33-1.el8



--- Comment #18 from Fedora Update System  ---
FEDORA-EPEL-2023-3c36019bf2 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2192251
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  55  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1e00c3d01e   
cutter-re-2.2.0-1.el8 rizin-0.5.1-1.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f44d817bc9   
chromium-113.0.5672.63-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-6463a51c68   
tcpreplay-4.4.3-3.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

gfal2-2.21.4-2.el8
js-jsroot-7.3.1-1.el8
kitty-0.26.5-7.el8
mate-terminal-1.26.1-1.el8
python-catkin_lint-1.6.22-1.el8
python-osrf-pycommon-2.1.2-1.el8
python-rosdep-0.22.2-1.el8
python-rosinstall_generator-0.1.23-1.el8
python-rospkg-1.5.0-1.el8
resalloc-aws-1.4-1.el8
root-6.28.04-1.el8
rpki-client-8.4-2.el8
suricata-6.0.12-1.el8

Details about builds:



 gfal2-2.21.4-2.el8 (FEDORA-EPEL-2023-26ae7d0fb9)
 Grid file access library 2.0

Update Information:

Upstream release v2.21.4

ChangeLog:

* Tue May  9 2023 Mihai Patrascoiu  - 2.21.4-2
- Patch to correctly find cryptopp dependency on 32-bit architectures
* Mon May  8 2023 Mihai Patrascoiu  - 2.21.4-1
- Upgrade to upstream release 2.21.4




 js-jsroot-7.3.1-1.el8 (FEDORA-EPEL-2023-f235e125c8)
 JavaScript ROOT - Interactive numerical data analysis graphics

Update Information:

root 6.28.04

ChangeLog:

* Tue Mar 28 2023 Mattias Ellert  - 7.3.1-1
- Update to version 7.3.1




 kitty-0.26.5-7.el8 (FEDORA-EPEL-2023-1f39b04ca0)
 Cross-platform, fast, feature full, GPU based terminal emulator

Update Information:

fix clone-in-kitty + security fix #2196803

ChangeLog:

* Wed May 10 2023 Pavel Solovev  - 0.26.5-7
- add missing endif
* Wed May 10 2023 Pavel Solovev 
- RPMAUTOSPEC: unresolvable merge

References:

  [ 1 ] Bug #2196802 - kitty: should not handle application/x-sh mime type by 
executing the script
https://bugzilla.redhat.com/show_bug.cgi?id=2196802




 mate-terminal-1.26.1-1.el8 (FEDORA-EPEL-2023-73ccad1112)
 Terminal emulator for MATE

Update Information:

- update to 1.26.1

ChangeLog:

* Wed May 10 2023 Wolfgang Ulbrich  - 1.26.1-1
- update to 1.26.1




 python-catkin_lint-1.6.22-1.el8 (FEDORA-EPEL-2023-95959597f0)
 Check catkin packages for common errors

Update Information:

Update to the latest ROS infrastructure package releases.

ChangeLog:

* Tue May  9 2023 Scott K Logan  - 1.6.22-1
- Update to 1.6.22 (rhbz#2115320)

References:

  [ 1 ] Bug #2115320 - python-catkin_lint-1.6.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2115320
  [ 2 ] Bug #2170020 - python-osrf-pycommon-2.1.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2170020
  [ 3 ] Bug #2174298 - python-rosinstall_generator-0.1.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2174298
  [ 4 ] Bug #2180331 - python-rosdep-0.22.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180331
  [ 5 ] Bug #2180332 - python-rospkg-1.5.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180332




 python-osrf-pycommon-2.1.2-1.el8 (FEDORA-EPEL-2023-95959597f0)
 Commonly needed 

[Bug 2192251] ctstream-33 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2192251

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|ctstream-33-1.fc39  |ctstream-33-1.fc39
   |ctstream-33-1.fc36  |ctstream-33-1.fc36
   |ctstream-33-1.fc37  |ctstream-33-1.fc37
   |ctstream-33-1.fc38  |ctstream-33-1.fc38
   ||ctstream-33-1.el9



--- Comment #17 from Fedora Update System  ---
FEDORA-EPEL-2023-6ecd67385f has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2192251
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2192251] ctstream-33 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2192251

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|ctstream-33-1.fc39  |ctstream-33-1.fc39
   |ctstream-33-1.fc36  |ctstream-33-1.fc36
   |ctstream-33-1.fc37  |ctstream-33-1.fc37
   ||ctstream-33-1.fc38



--- Comment #16 from Fedora Update System  ---
FEDORA-2023-067ab75d79 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2192251
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2192251] ctstream-33 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2192251

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|ctstream-33-1.fc39  |ctstream-33-1.fc39
   |ctstream-33-1.fc36  |ctstream-33-1.fc36
   ||ctstream-33-1.fc37



--- Comment #15 from Fedora Update System  ---
FEDORA-2023-3e22970fa7 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2192251
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2192251] ctstream-33 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2192251

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|ctstream-33-1.fc39  |ctstream-33-1.fc39
   ||ctstream-33-1.fc36
 Resolution|--- |ERRATA
Last Closed||2023-05-11 01:30:24



--- Comment #14 from Fedora Update System  ---
FEDORA-2023-095fc66349 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2192251
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Luca Boccassi]

> On Wed, May 10, 2023 at 5:34 PM Chris Murphy  wrote:
> 
> 
> In this idea, the dm-verity parition/file would only be accessed from the
> initrd, once we have enough kernel to ability to interact with physical
> storage, understand partitions, initialize dm-verity, and read *a*
> partition, but potentially not enough to read from a bluetooth keyboard,
> show a graphical prompt, mount / from the network, etc.
> 
> What dm-verity provides here is a way to trust content without requiring it
> to be read ahead of time, checksumed, signature checked and put into ram.

We already support dm-verity for the rootfs, in both dracut and mkosi-initrd, 
not sure what's the issue here?

> The elephant in the room is whether the "desktops in the default
> installation" UKI requires piles of graphics firmware. It might not be at
> all small in that case.

We support optional extensions with UKIs exactly for this reason.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Owen Taylor]

On Wed, May 10, 2023 at 5:34 PM Chris Murphy 
wrote:

>
>
> On Wed, May 10, 2023, at 2:24 PM, Owen Taylor wrote:
>
>
>
> On Wed, May 10, 2023 at 12:02 PM Neal Gompa  wrote:
>
>
> Now, there's a second problem with reading everything from the ESP - it's
> slow for two reasons. First, because read speeds when going through the
> firmware are much slower than the Linux NVMe stack. And second, because we
> have to read everything in order to checksum and verify it.
>
> For that reason, Demi's suggestion of moving things onto a dm-verity
> protected partition is intriguing. Could that even be a loopback file on
> the ESP? It would be like a lazy-read system extension.
>
> The performance geek in me thinks "we could see exciting speedups from
> that!" - the practical side of me thinks "it might be a few second faster.
> And much more complex! Let's just go with efifb, keep the initramfs small,
> and accept any minor regressions".
>
>
> GRUB doesn't support dm-verity, but I don't know if it would make a
> difference if it did. Once the kernel has the ability to interact with
> physical storage, understand partitions, initialize dm-verity, and read a
> file systemt... it could just mount `/` . I think the only way the current
> initial root file system works with the kernel is for the bootloader to
> read an entire initrd file into RAM, and then the kernel can randomly
> access things in that RAM disk.
>

In this idea, the dm-verity parition/file would only be accessed from the
initrd, once we have enough kernel to ability to interact with physical
storage, understand partitions, initialize dm-verity, and read *a*
partition, but potentially not enough to read from a bluetooth keyboard,
show a graphical prompt, mount / from the network, etc.

What dm-verity provides here is a way to trust content without requiring it
to be read ahead of time, checksumed, signature checked and put into ram.

To be clear, I don't think this is necessarily the right way to go - I
think using efifb, not prompting for a passphrase when possible, etc, are
simpler approaches.

>
> It's early still for UKI details but I assume we will need both a
> universal UKI (all use cases), and much smaller use case focused UKIs. I
> say that because the desktops in the default installation configuration are
> the largest single use case. With Btrfs built-into the kernel, we don't
> need that much in the initrd to setup block devices, discover their
> contents, and perform switch root.
>
> The next most common use case(s), device-mapper and md based, require a
> pile of user space programs running to do all the work setting things up.
> Maybe we can just get away with two images, a simple fast one and the
> universal.
>

The elephant in the room is whether the "desktops in the default
installation" UKI requires piles of graphics firmware. It might not be at
all small in that case.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

[DJ Delorie]

Jens-Ulrik Petersen  writes:
> I have just now pushed fixes for all ghc*, so can you try to rebuild
> them again in your repo?

That's a good question, to which I know not the answer.  Fred?  Can MPB
be told to retest a specific set of packages?  Or do I have to start
from scratch and/or do them manually?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Stuck package - golang-github-prometheus-node-exporter

[Mark E. Fuller]

I'll try to push this along - there's a build error that needs resolving 
(but not at 2:30 AM)

see https://bugzilla.redhat.com/show_bug.cgi?id=2112130

Anyone from the golang list want to take a look?

-fuller

On 02/05/2023 19:25, Pat Riehecky wrote:

golang-github-prometheus-node-exporter seems to be unmaintained at this point.  
There are a few open CVEs that have been corrected upstream in the last year 
but not made it down to the fedora package.

In Feb I opened a maintainer check ticket : 
https://bugzilla.redhat.com/show_bug.cgi?id=2166945

Alas, I'm not able to maintain this package myself.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_0xD599E76CFFCABF60.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Chris Adams]

Once upon a time, Chris Murphy  said:
> Read-only drivers, which are the only drivers under discussion here, aren't a 
> per se problem because they can't modify the file system. So they have no 
> complaints about that.

But those read-only drivers are incomplete and problematic, especially
as filesystems get more complex.  I've been bitten before by an
ill-timed unclean shutdown, where an update was still in the /boot ext4
journal but not comitted, so the system would not boot, because the
GRUB2 ext4 driver doesn't read the journal.

There should be _less_ put into GRUB2 filesystem support IMHO, not more.
No more complex filesystems; keep /boot something simple like ext2 that
GRUB2 can reasonably be expected to handle basically 100%, possibly
mounted read-only during normal operation, mount with "sync", and with
all updates as atomic as practical.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Summary/Minutes from today's FESCo Meeting (2023-05-09)

[Kevin Kofler via devel]

Kevin Kofler via devel wrote:
> So you folks were not happy with the feedback on the mailing list, so you
> just made up a poll somewhere else.
[snip]
> Was that poll ever announced on the mailing list? Or did you just expect
> people to magically notice it has popped up in the FESCo ticket?

Sorry, looking at the FESCo ticket, I see the stats are actually just your 
subjective interpretation of the mailing list replies. Since I do not know 
who you counted in what category, I cannot tell whether your interpretation 
is correct or not.

But:
> Basically the same thing you are now doing with Discourse. Don't like the
> community feedback? Let's just make up a new community.

This part still stands, I see the forced use of Discourse as a way to 
silence community feedback. How about you actually let the community decide 
on which medium to bring up the feedback?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Summary/Minutes from today's FESCo Meeting (2023-05-09)

[Kevin Kofler via devel]

Zbigniew Jędrzejewski-Szmek wrote:
> Nope, that is actually not true. Matthew posted some stats in the
> fesco ticket [1], and the stats were fairly evenly split
> (supportive or open, neutral, opposed or concerned). In fact,
> "opposed" is the least popular option.

So you folks were not happy with the feedback on the mailing list, so you 
just made up a poll somewhere else. Basically the same thing you are now 
doing with Discourse. Don't like the community feedback? Let's just make up 
a new community.

Was that poll ever announced on the mailing list? Or did you just expect 
people to magically notice it has popped up in the FESCo ticket?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Chris Murphy]

On Wed, May 10, 2023, at 5:21 PM, Lennart Poettering wrote:
> So to add to this. I happen to be at LFSMMBPF at the moment, the Linux
> File System summit (among other things) where all the Linux FS people
> meet. I spoke to a couple of FS maintainers here, and well, let me
> make this very clear: using any of the major Linux file systems with
> drivers that are not the ones in the Linux kernel is a very bad idea,
> and expressly not supported by them. [They actually used much harsher
> words, that I'll not repeat here – this is the "friendly" version of
> their take on your idea.]
>
> So, unless you want to go against what the people who actually
> maintain the file systems expressly say please just get this idea out
> of your head that porting Linux file systems into EFI fs drivers was a
> good, supportable idea.
>
> And Neal, Chris, if you don't believe the above, then hey, I am happy
> to open a thread with them in CC where they can tell you in person how
> bad an idea that is.

I don't know what question you asked them. Any modifications (writes) performed 
outside kernel code is not supported, since forever.

Read-only drivers, which are the only drivers under discussion here, aren't a 
per se problem because they can't modify the file system. So they have no 
complaints about that.



-- 
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Lennart Poettering]

On Mi, 10.05.23 14:32, Neal Gompa (ngomp...@gmail.com) wrote:

> On Wed, May 10, 2023 at 2:24 PM Owen Taylor  wrote:
> >> As soon as you throw UKIs in the mix, you've completely broken that
> >> because now the absolutely most valuable code for your system is in a
> >> "hostile" environment. At least we can make /boot authenticated and
> >> tamper resistant as a Btrfs subvolume.
> >
> >
> > As other people have mentioned, we have a solution for the ESP being 
> > untrusted - secure boot. As far as I understand, there's no tamper 
> > resistance for /boot on btrfs unless it's encrypted, and that would be a 
> > whole other barrel of snakes :-)
>
> fsverity is separate from fscrypt. We can apply filesystem
> authentication today.

No that's just wrong. fsverity is *not* filesystem
authentication. It's authentication of the content of a single file,
and not more.

And that's just too little, because a complex file system such as
btrfs is simply not considered robust against rogue offline
modification. (Again, I am at LFSMMBPF and if you want I can get you a
quote from the btrfs maintainer about this). Thus you must
authenticate btrfs *before* you mount it, and fsverity is only
available after.

Sorry, fsverity has some usecases, but your usecase here is absolutely
not it.

Seriously, forget about this whole btrfs idea. It's wrong on many many
levels.

> No. It initializes the whole operating system, and then pivots the
> user-space later. That's why we have to everything in initramfs.
> UKIs attempt to standardize the early-stage image without attempting
> to solve this problem, because a two-stage boot process requires
> changing how we think about operating system initialization.

So the initrd is supposed to contain exactly what is necssary to get
access to the root fs, not more. Thing is that Linux is very very
flexible, and people put their root fs on crazy stuff. Now I
personally don't even care much about the crazy storage options people
want to back the rootfs, I only care about the non-crazy part (in my
eyes), i.e. encryption, fido2, tpm stuff, which possibly requires
interactivity so it probably also means a graphical session to some
point. While that generally ends up being a lot, it still is certainly
not *everything*.

You can stick your head in the sand and pretend that nothing of this
mattered, and you don't have to authenticate and things, but then you
simply didn't solve the problem at hand.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Lennart Poettering]

On Mi, 10.05.23 12:00, Neal Gompa (ngomp...@gmail.com) wrote:

> This proposal isn't better. Neither Windows nor macOS put critical
> operating system code in the ESP, and we shouldn't either.

This is nonsense. I am not sure what definition of "critical" you
have, but the ESP is the entrypoint to the OS, of course it contains
"critical" stuff in there, if you delete what windows places there you
cannot boot anymore.

> As soon as you throw UKIs in the mix, you've completely broken that
> because now the absolutely most valuable code for your system is in a
> "hostile" environment. At least we can make /boot authenticated and

"most valueable code"? what is that even supposed to mean?

> tamper resistant as a Btrfs subvolume.

What is a tamper resistent btrfs subvolume? I have not heard of such a
thing. And don't say "fsverity" now. Because that's really not
it. "fsverity" is not some secret sauce that you attach to an fs and
then it cannot be tempered with. It has a much more limited usecase
and requires userspace to first validate the file's metadata and it's
hash manually before using it.

Seriously, fsverity is not an answer for this. And you know what, the
person behind fsverity will tell you the same. (also here at lfsmmbpf,
and I can connect you if you want)

Moreover, you need to validate a complex file system before you access
it, it's too late if you do it the other way round. Hence, unless you
established trust in your btrfs fs *before* you go into and and look
for kernel you are not doing security, you are just doing nonsense.

> I would rather have a multi-stage boot process, where the first stage
> does just enough to unlock and load the OS volume to load the real
> boot environment.

And I'd like a pony!

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Chris Murphy]

On Wed, May 10, 2023, at 2:24 PM, Owen Taylor wrote:
> 
> 
> On Wed, May 10, 2023 at 12:02 PM Neal Gompa  wrote:
>> 
> Now, there's a second problem with reading everything from the ESP - it's 
> slow for two reasons. First, because read speeds when going through the 
> firmware are much slower than the Linux NVMe stack. And second, because we 
> have to read everything in order to checksum and verify it.
> 
> For that reason, Demi's suggestion of moving things onto a dm-verity 
> protected partition is intriguing. Could that even be a loopback file on the 
> ESP? It would be like a lazy-read system extension.
> 
> The performance geek in me thinks "we could see exciting speedups from that!" 
> - the practical side of me thinks "it might be a few second faster. And much 
> more complex! Let's just go with efifb, keep the initramfs small, and accept 
> any minor regressions".

GRUB doesn't support dm-verity, but I don't know if it would make a difference 
if it did. Once the kernel has the ability to interact with physical storage, 
understand partitions, initialize dm-verity, and read a file systemt... it 
could just mount `/` . I think the only way the current initial root file 
system works with the kernel is for the bootloader to read an entire initrd 
file into RAM, and then the kernel can randomly access things in that RAM disk.

It's early still for UKI details but I assume we will need both a universal UKI 
(all use cases), and much smaller use case focused UKIs. I say that because the 
desktops in the default installation configuration are the largest single use 
case. With Btrfs built-into the kernel, we don't need that much in the initrd 
to setup block devices, discover their contents, and perform switch root.

The next most common use case(s), device-mapper and md based, require a pile of 
user space programs running to do all the work setting things up. Maybe we can 
just get away with two images, a simple fast one and the universal.


--
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Lennart Poettering]

On Mi, 10.05.23 15:13, Lennart Poettering (mzerq...@0pointer.de) wrote:

> > We're generally looking toward encrypting subvolumes individually
> > using the upcoming Btrfs native encryption capability rather than
> > using LUKS. That allows us to
>
> How do you establish trust in the underlying file system? The thing
> that kernel fs maintainers made very clear is that they do not
> consider Linux file systems safe regarding rogue offline
> modification. Hence you must establish trust somehow *before* you
> mount the fs, which pretty much means LUKS.
>
> Linux fs maintainers also made very clear that they generally consider
> alternative implementations of their file systems as unsupported, and
> a problem. The big relevant Linux file systems consider only the
> implementation in the Linux kernel as defining the format. Which means
> that anything like an alternative implementation of btrfs or xfs or
> ext4 in things like grub or EFI is expressly against the wishes of the
> people who maintain the file systems.
>
> Or in other words: what you are proposing appears like a very bad
> idea, and in fact even upstream Grub wants to get away from
> maintaining thei own fs drivers for Linux fs as I hear, because it's
> so untenable to them, too.
>
> Seriously, bury this idea.

So to add to this. I happen to be at LFSMMBPF at the moment, the Linux
File System summit (among other things) where all the Linux FS people
meet. I spoke to a couple of FS maintainers here, and well, let me
make this very clear: using any of the major Linux file systems with
drivers that are not the ones in the Linux kernel is a very bad idea,
and expressly not supported by them. [They actually used much harsher
words, that I'll not repeat here – this is the "friendly" version of
their take on your idea.]

So, unless you want to go against what the people who actually
maintain the file systems expressly say please just get this idea out
of your head that porting Linux file systems into EFI fs drivers was a
good, supportable idea.

And Neal, Chris, if you don't believe the above, then hey, I am happy
to open a thread with them in CC where they can tell you in person how
bad an idea that 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Troy Dawson]

We discussed this in the weekly EPEL Steering Committee meeting. We broke
this into two separate votes.

*Allow the epel 7 update : Passed*
Votes: All who voted, voted in favor of this.
Notes: No notes.

*Allow the epel 8 and 9 update - with a stern warning : Passed*
Votes: 4 for, 2 against, 1 abstaining -
Notes: Although your argument was that these needed the same breaking
configurations to prevent future security issues, that wasn't what swayed
the votes. The first reason was that having older versions in epel 8 and 9
causes more problems. The second reason was that we felt we didn't give you
a stern enough warning last time.

*WARNING / ADVISEMENT / ATTENTION*
This is the second time that apptainer has had breaking updates. The EPEL
Steering Committee feels that if this happens again, then apptainer isn't a
good fit for EPEL. We will pull apptainer from EPEL and recommend that you
release it in COPR  instead of EPEL.
Please inform the upstream maintainers of this.


Troy

On Mon, May 8, 2023 at 7:29 AM Dave Dykstra  wrote:

> Hi Troy,
>
> If required, the epel8 & epel9 builds could have a patch added that
> changes the default of the new "allow setuid-mount extfs" to be "yes"
> instead of "no". That's all that would be required to disable the
> incompatible change.
>
> But as I said, I think it's a bad idea to make this behavior different
> on different OS versions.  Epel8 & 9 are still vulnerable to the same
> general issue; even though they're likely to get patches for future low
> or moderate level severity vulnerabilities, they don't get patches
> quickly and so admins will have to turn this off for the period of time
> between announcement and patch upstream.  Also the incompatibility is
> going to only affect a small percentage of epel8 & 9 users, and they
> should be able to quickly workaround it by adding the --userns option.
>
> The --userns option is already available everywhere.  Are you
> suggesting that it default to --userns option behavior on epel8 & 9, at
> least for ext3, when "allow setuid-mount extfs = no"?  I have thought
> of that but I believe that we cannot mix the setuid mode and the
> fuse2fs mount, at least not without a lot of major rework and careful
> investigation of the security implications.  I don't think it would be
> good to automatically switch fully to the --userns mode with a setuid
> installation and "allow setuid-mount extfs = no", because then users
> will get subtle differences with other behavior depending on whether or
> not they are requesting something that is using an ext3 filesystem.
>
> Dave
>
> On Mon, May 08, 2023 at 06:47:04AM -0700, Troy Dawson wrote:
> > That makes it more clear for epel7.
> > But it will be strange for epel7 to have a higher version than epel8 and
> 9.
> > Would the apptainer maintainers be willing to create an update that has
> the
> > --userns option, as well as the original option?
> > Then for epel7 the rpm's would have the original option turned off, but
> for
> > epel8 and 9 the option could be there and update wouldn't be a breaking
> > update.
> >
> > That would allow users that have machines on RHEL 7,8 and 9 to use the
> same
> > version and secure options.
> > Users that only have machines on RHEL 8 and 9, would then have the option
> > to move to the more secure option when the time is good for them.
> >
> > Troy
> >
> > On Fri, May 5, 2023 at 3:30 PM Dave Dykstra via epel-devel <
> > epel-devel@lists.fedoraproject.org> wrote:
> >
> > > The NVD analysis at
> > > https://nvd.nist.gov/vuln/detail/CVE-2023-30549
> > > is now finished and they agreed with the impact score that I gave it.
> > > They ended up with an even higher rating because they said the attack
> > > complexity was low.  I think the complexity is high, but in either
> case the
> > > overall severity is rated High.
> > >
> > > Dave
> > >
> > > On Thu, May 04, 2023 at 10:17:42AM -0500, Dave Dykstra wrote:
> > > > DT,
> > > >
> > > > I am not all arguing that CVE-2022-1184 impact score was incorrect.
> I
> > > can't imagine why you think that.
> > > >
> > > > By itself, CVE-2022-1184 is not a privilege escalation, because it
> can
> > > normally only be exploited by someone with write access to the
> filesystem
> > > boots, that is, root.  Only with setuid-root apptainer/singularity
> does it
> > > become a privilege escalation.
> > > >
> > > > I have said that I think that CVE-2022-1184's "Privileges Required"
> was
> > > incorrect.  It was you who suggested USB automounts being available to
> > > users may have been their reason for setting it to "low".  If that's
> what
> > > they meant, then I think it makes perfect sense that they don't count
> that
> > > as a privilege escalation because physical access already gives
> privilege
> > > escalation in much easier ways.  I said that that's probably why they
> only
> > > counted it as denial of service since that was the only thing new.
> > > >
> > > > Dave
> > > >
> 

Re: memtest86plus v6.00

[Jonathan Steffan]

On Tue, May 9, 2023 at 5:28 PM Jonathan Steffan 
wrote:

> * Location of shipped bins -- is there a better place now? I went with simple.
>
>
The active discussion about BiggerESP is relevant to this decision. It's
even directly asserted that RPMs should not be managing content in /boot.

https://fedoraproject.org/wiki/Changes/BiggerESP
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/B4UAREAUA3TBR64ZVCAQLMR57AGGJ3YJ/


-- 
Jonathan Steffan
jonathanstef...@gmail.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora CoreOS Meeting Minutes 2023-05-10

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-05-10/fedora_coreos_meeting.2023-05-10-16.30.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-05-10/fedora_coreos_meeting.2023-05-10-16.30.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-05-10/fedora_coreos_meeting.2023-05-10-16.30.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:30:29 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-05-10/fedora_coreos_meeting.2023-05-10-16.30.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:30:33)

* Action items from last meeting  (dustymabe, 16:34:25)
  * dusty is working to get something scheduled - probably for June
(dustymabe, 16:34:37)

* New Package Request: ipcalc  (dustymabe, 16:36:33)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1460
(dustymabe, 16:36:39)
  * AGREED: we'll include ipcalc to aid in some advanced custom
networking calculations.  (dustymabe, 16:50:23)

* increase size of our /boot partition for new installs  (dustymabe,
  16:51:25)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1465
(dustymabe, 16:51:30)
  * For now the proposal is a 512M ESP and 1G /boot partition but we are
following discussions about UKI to determine if that will change
where (ESP or /boot) we put the large files (kernel+initramfs) in
the future.  (dustymabe, 17:07:15)

* open floor   (dustymabe, 17:28:12)
  * I created the F39 changes ticket
https://github.com/coreos/fedora-coreos-tracker/issues/1491
(dustymabe, 17:28:42)
  * LINK: https://github.com/coreos/ignition/issues/1289   (bgilbert,
17:33:59)

Meeting ended at 17:36:22 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (98)
* bgilbert (56)
* jlebon (35)
* zodbot (17)
* travier (5)
* Nemric (4)
* spresti[m] (2)
* mnguyen (1)
* ravanelli (1)
* quentin9696[m] (1)
* copperi (1)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Clement Verna]

On Tue, 9 May 2023, 17:51 Kevin Fenzi,  wrote:

> Just a general answer/info here at the bottom of the thread...
>
> I realize our container build pipeline is not great, but it's currently
> working and I will keep it working until we replace it.
>
> I agree we should replace it, and there's lots of options, but I don't
> think this thread is the place to go back and forth about them.
>
> I know of at least kiwi, osbuild, some other build systems that don't
> fully exist yet, switching to use quay.io, osbs2 (based on openshift4),
> and probibly others.
>

I also agree that we should replace it but that's not an easy task
unfortunately.
My understanding of osbuild is that it focuses on base images and not
layered images so that probably would not be a good candidate for replacing
OSBS. I might also be wrong :-)

>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Clement Verna]

On Tue, 9 May 2023, 15:42 Debarshi Ray via devel, <
devel@lists.fedoraproject.org> wrote:

> Hey Clement,
>
> On Tue, 2023-05-09 at 09:45 +0200, Clement Verna wrote:
> >
> >
> > On Mon, 8 May 2023 at 22:11, Kevin Fenzi  wrote:
> > > On Mon, May 08, 2023 at 07:57:30PM +, Zbigniew Jędrzejewski-
> > > Szmek wrote:
> > > >
> > > > I think we need some clarity wrt. to the dependency order here.
> > > > Let's say we:
> > > > > In order to do this at branch point, we will need to move
> > > > > building this
> > > > > image into the compose process and mark it blocking.
> > > > OK, so we build things, but then we need to publish to
> > > > registry.fp.o,
> > > > which is asynchrounous (?). When we test the newly built ISOs, do
> > >
> > > No, it happens at the end of the compose (if no blocking
> > > deliverables failed causing the compose to fail)
> >
> > If we do this, we should also make the container base images release
> > blocking since AFAIK they are currently not release blocking.
>
> Yes, that's a good point.
>
> The OCI base images aren't currently listed as release-blocking
> deliverables:
> https://docs.fedoraproject.org/en-US/releases/f39/blocking/
>
> ... but if this Change goes through, then they will implicitly become
> release-blocking deliverables because the fedora-toolbox images are
> based on them.
>
> Should we explicitly mention this in the Change?  Or, something else?
> Or, is it fine as it is?
>

I think mentioning explicitly in this change is good enough :)

>
> Thanks,
> Rishi
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Luca Boccassi]

> On Wed, May 10, 2023 at 2:24 PM Owen Taylor  
> fsverity is separate from fscrypt. We can apply filesystem authentication 
> today.

fsverity does not protect metadata, and most importantly it does not protect 
the filesystem superblock. It has its uses, but this is not it.

> No. It initializes the whole operating system, and then pivots the
> user-space later. That's why we have to everything in initramfs.
> UKIs attempt to standardize the early-stage image without attempting
> to solve this problem, because a two-stage boot process requires
> changing how we think about operating system initialization.
> 
> In Windows, the Windows Boot Manager loads the NT
> kernel stub from the NTFS volume, which then loads the minimal
> operating system environment, and bootstraps the full Windows
> experience. The Windows Boot Manager has just enough to handle
> BitLocker and NTFS, and then transfers the rest to Windows itself.

It is really not that different than the initrd approach. Just the storage is 
different, but that's easier when you own both filesystems implementations.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Neal Gompa]

On Wed, May 10, 2023 at 2:24 PM Owen Taylor  wrote:
>
>
>
> On Wed, May 10, 2023 at 12:02 PM Neal Gompa  wrote:
>>
>>
>> This proposal isn't better. Neither Windows nor macOS put critical
>> operating system code in the ESP, and we shouldn't either. But you
>> want to put kernels in the ESP? That's the wrong approach too.
>>
>> As soon as you throw UKIs in the mix, you've completely broken that
>> because now the absolutely most valuable code for your system is in a
>> "hostile" environment. At least we can make /boot authenticated and
>> tamper resistant as a Btrfs subvolume.
>
>
> As other people have mentioned, we have a solution for the ESP being 
> untrusted - secure boot. As far as I understand, there's no tamper resistance 
> for /boot on btrfs unless it's encrypted, and that would be a whole other 
> barrel of snakes :-)
>

fsverity is separate from fscrypt. We can apply filesystem authentication today.

> Now, there's a second problem with reading everything from the ESP - it's 
> slow for two reasons. First, because read speeds when going through the 
> firmware are much slower than the Linux NVMe stack. And second, because we 
> have to read everything in order to checksum and verify it.
>
> For that reason, Demi's suggestion of moving things onto a dm-verity 
> protected partition is intriguing. Could that even be a loopback file on the 
> ESP? It would be like a lazy-read system extension.
>
> The performance geek in me thinks "we could see exciting speedups from that!" 
> - the practical side of me thinks "it might be a few second faster. And much 
> more complex! Let's just go with efifb, keep the initramfs small, and accept 
> any minor regressions".
>
>> I would rather have a multi-stage boot process, where the first stage
>> does just enough to unlock and load the OS volume to load the real
>> boot environment.
>
>
> "unlock and load the OS volume" is pretty much what the initramfs does, right?
>

No. It initializes the whole operating system, and then pivots the
user-space later. That's why we have to everything in initramfs.
UKIs attempt to standardize the early-stage image without attempting
to solve this problem, because a two-stage boot process requires
changing how we think about operating system initialization.

In Windows, the Windows Boot Manager loads the NT
kernel stub from the NTFS volume, which then loads the minimal
operating system environment, and bootstraps the full Windows
experience. The Windows Boot Manager has just enough to handle
BitLocker and NTFS, and then transfers the rest to Windows itself.

This means that you can do interesting things by simply replacing the
Windows Boot Manager with another boot manager that includes more
features. As an example, Quibble[1] replaces the Windows Boot Manager
to enable booting Windows off Btrfs.

[1]: https://github.com/maharmstone/quibble





--
真実はいつも一つ！/ 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedora 38 - in witch timespan a net iso is build..??

[Samuel Sieb]

On 5/9/23 05:10, André verwijs wrote:

installed Fedora with "Fedora-Everything-netinst-x86_64-38-1.6.iso"  but hat 
small issues. (firewall packages) In witch timespan will a new iso be build..?? At least 
use the latest updates for  this (or any other) installation iso...


An issue with the installer or the installed system?  That's a netinst, 
so there are no packages included to update, only the installer itself. 
Any Fedora package updates will be automatically available to the 
installed system or to the installer if you use it again later.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Neal Gompa]

On Wed, May 10, 2023 at 2:00 PM Chris Murphy  wrote:
>
>
>
> On Mon, Apr 24, 2023, at 12:15 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/BiggerESP
>
> > This change will increase the minimum size of the ESP to be 500MB,
> > which is also the same value used by Microsoft for Windows 10 and
> > newer.
>
> Issue 1:  Currently anaconda calls mkdosfs on the ESP without any options and 
> historically are reluctant to add non-default mkfs options. By default, 
> mkdosfs will create a FAT 16 file system on a 500M (either SI or IEC units). 
> The UEFI spec clearly prefers FAT 32 for the ESP on built-in drives. To my 
> knowledge there haven't been any FAT 16 related bugs reported during the many 
> years Fedora created FAT 16 ESPs. But it's probably better to create it as 
> FAT 32.
>
> I don't know where the cutoff is in the mkdosfs code, but a 512MiB (IEC 
> units) does result in a FAT 32 file system. So you might make it 512MiB.
>
> Issue 2: Last I checked (about 12 months ago), Windows 10 and 11 images from 
> microsoft.com were still creating ~99M (I forget which units, and it may have 
> been 100). That's consistent with:
>
> https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11
>
> "The minimum size of this partition is 100 MB, and must be formatted using 
> the FAT32 file format."
>
> So I'm not sure if Microsoft got the memo, and it's actually vendors' OEM 
> images that are using large ESP size?
>

Microsoft has no reason to make it bigger. They have a system boot
architecture that avoids having OS code on the ESP. Some OEMs preload
extra recovery stuff and or extra environments, which might be where
the bigger sizes come from.




--
真実はいつも一つ！/ 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Owen Taylor]

On Wed, May 10, 2023 at 12:02 PM Neal Gompa  wrote:

>
> This proposal isn't better. Neither Windows nor macOS put critical
> operating system code in the ESP, and we shouldn't either. But you
> want to put kernels in the ESP? That's the wrong approach too.
>
> As soon as you throw UKIs in the mix, you've completely broken that
> because now the absolutely most valuable code for your system is in a
> "hostile" environment. At least we can make /boot authenticated and
> tamper resistant as a Btrfs subvolume.
>

As other people have mentioned, we have a solution for the ESP being
untrusted - secure boot. As far as I understand, there's no tamper
resistance for /boot on btrfs unless it's encrypted, and that would be a
whole other barrel of snakes :-)

Now, there's a second problem with reading everything from the ESP - it's
slow for two reasons. First, because read speeds when going through the
firmware are much slower than the Linux NVMe stack. And second, because we
have to read everything in order to checksum and verify it.

For that reason, Demi's suggestion of moving things onto a dm-verity
protected partition is intriguing. Could that even be a loopback file on
the ESP? It would be like a lazy-read system extension.

The performance geek in me thinks "we could see exciting speedups from
that!" - the practical side of me thinks "it might be a few second faster.
And much more complex! Let's just go with efifb, keep the initramfs small,
and accept any minor regressions".

I would rather have a multi-stage boot process, where the first stage
> does just enough to unlock and load the OS volume to load the real
> boot environment.
>

"unlock and load the OS volume" is pretty much what the initramfs does,
right?

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Chris Murphy]

On Wed, May 10, 2023, at 9:42 AM, Lennart Poettering wrote:

> You are arguing here into two opposing directions. One one hand you
> want to chainload multiple kernels+initrd (claiming this was a good idea out
> of the problem of sizing ESP/XBOOTLDR sufficientlly), and then on the
> other hand you claim there's too much kernel+initrd in the boot
> process?
>
> What is it now? Pick one: more initrd or less initrd?

I've only ever said I want faster boot and smaller initrd. Everything else is 
pointing out the consequences of alternatives, not advocacy of them.


-- 
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Chris Murphy]

On Mon, Apr 24, 2023, at 12:15 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/BiggerESP

> This change will increase the minimum size of the ESP to be 500MB,
> which is also the same value used by Microsoft for Windows 10 and
> newer.

Issue 1:  Currently anaconda calls mkdosfs on the ESP without any options and 
historically are reluctant to add non-default mkfs options. By default, mkdosfs 
will create a FAT 16 file system on a 500M (either SI or IEC units). The UEFI 
spec clearly prefers FAT 32 for the ESP on built-in drives. To my knowledge 
there haven't been any FAT 16 related bugs reported during the many years 
Fedora created FAT 16 ESPs. But it's probably better to create it as FAT 32.

I don't know where the cutoff is in the mkdosfs code, but a 512MiB (IEC units) 
does result in a FAT 32 file system. So you might make it 512MiB.

Issue 2: Last I checked (about 12 months ago), Windows 10 and 11 images from 
microsoft.com were still creating ~99M (I forget which units, and it may have 
been 100). That's consistent with:

https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11

"The minimum size of this partition is 100 MB, and must be formatted using the 
FAT32 file format."

So I'm not sure if Microsoft got the memo, and it's actually vendors' OEM 
images that are using large ESP size?



-- 
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Ewoud Kohl van Wijngaarden]

On Wed, May 10, 2023 at 07:09:49PM +0200, Peter Boy wrote:




Am 10.05.2023 um 18:45 schrieb Kevin Fenzi :

On Wed, May 10, 2023 at 12:21:51PM +0800, Jens-Ulrik Petersen wrote:

Thanks for all the helpful comments and feedback,
though more is still welcome of course.
So I am leaning now towards not installing fedora-repos-modular by default
(rather than disabling the modular repos by default): also for upgrade
compatibility.

I have started a Change proposal draft, which I think should be ready soon,
with current working title *"Turn off modular dnf repos by default"*.
Perhaps *"No default fedora-repos-modular"* would be more precise.
Or any better suggestions (that don't sound like modularity is being
removed)?

I think the actual work (PR's) required is not huge,
but if someone is particularly keen to join the effort let me know.


So, at the risk of opening a larger can of worms...and increasing the
scope here beyond what you have any desire to do...

Should we consider just retiring modular repos entirely?

I do know there's a number of active module builds, but I am not sure
how much users use them. While RHEL still uses modules, EPEL has retired
their epel8 modular repos.

Can the things using modules now switch to compat packages in the main
repository?

I realize we may want to just say 'no, not now' here, but I thought I
would bring it up.



I suppose I would belong to the latter. From a Server admin’s POV the modules 
are a great chance to keep some backwards compatibility with our fast pacing 
distro. The most prominent example is PostgreSQL. It is not so rare that the 
new major version requires an adjustment in the application programme or at 
least an extensive test. And every major update also requires a migration of 
the entire data stock. Modularisation is a welcome opportunity to quickly 
switch to a new release and use new capabilities, but to carry out the 
adaptation / tests with PostgreSQL at your leisure.

And that is just one example. Another example is changes in languages such as 
Ruby, where application programmes sometimes cannot keep up with the changes. 
Same is true for httpd or tomcat - just some other examples.

If we could manage compat packages or parallel use of different major versions 
(as, for example, the Java runtime environment has managed to provide perfectly 
for decades), then modularisation would probably no longer be needed.


Debian has parallel installation with PostgreSQL. It does mean the major 
versions show up in the DB paths, but I don't think that's a bad thing. 
I think various problems that modularity tries to solve could also be 
solved with parallel installs and sometimes provide a better user 
experience.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Jun Aruga (he / him)]

> And that is just one example. Another example is changes in languages such as 
> Ruby, where application programmes sometimes cannot keep up with the changes. 
> Same is true for httpd or tomcat - just some other examples.

I am in the Ruby SIG. In the case of Ruby, I don't think we have the
capacity of the older Ruby modules in the rawhide and supported
platforms.
You can see how the current Module Ruby builds look like from the Koji
build page below.
In my memory, we are struggling to build old Ruby, Ruby 2.7 to build
on the new environment, rawhide.
https://koji.fedoraproject.org/koji/packageinfo?packageID=125

If you want to use multiple versions of the Ruby in Linux, RVM (Ruby
Version Manager) can be an alternative.
https://rvm.io/

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: soname bump: libtraceevent and libtracefs

[John Kacur]

Any update on the rv tool ( tools/verification/rv)?

Thanks

John Kacur

On Mon, Apr 17, 2023 at 5:01 PM Justin Forbes  wrote:

> On Mon, Apr 17, 2023 at 2:45 PM John Kacur  wrote:
> >
> > There is a new tool that is dependent on these libs too. Also from
> Daniel Bristot (rtla)
> > tools/verification/rv
> >
> > I was wondering if we could get this into rawhide?
>
> Yes, I will get it in before the 6.3 release next Monday, that way it
> will automatically follow into stable Fedora as they get the 6.3
> rebase.
>
> Justin
>
> > John Kacur
> >
> > On Sun, Apr 9, 2023 at 12:12 AM Zamir SUN 
> wrote:
> >>
> >>
> >> On 4/5/23 23:49, Justin Forbes wrote:
> >> > On Wed, Apr 5, 2023 at 5:05 AM Zamir SUN 
> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I'm working on libtraceevent and libtracefs update. There will be
> soname
> >> >> bump happening to them. Namely,
> >> >>
> >> >> libtraceevent.so 1.6.3 -> 1.7.2
> >> >> libtracefs.so 1.5.0 -> 1.6.4
> >> >>
> >> >> IIRC only kernel-tools (for perf and rtla) and trace-cmd depends on
> >> >> them. So I'm also copying their corresponding contacts.
> >> >>
> >> >> As for libtraceevent, I've tried running trace-cmd/perf/rtla with the
> >> >> new version and they still works. So I've updated it in Rawhide,
> Fedora
> >> >> 38 and Fedora 37. They are now in Bodhi.
> >> >>
> >> >> As for libtracefs I've built it in side tag f39-build-side-65890. I
> plan
> >> >> to update it in both Rawhide and Fedora 38 this week.
> >> >
> >> > Given that we are in a freeze for F38, it might be better to wait
> >> > until GA, but I have rebuilt kernel-tools in the sidetag.  Please let
> >> > me know when this is merged back as we rebuild kernel-tools weekly in
> >> > rawhide.
> >> >
> >>
> >> Hi Justin,
> >>
> >> I think this is a good point. I will coordinate with you when I do it
> >> for Fedora 38.
> >>
> >> --
> >> Zamir SUN
> >> GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
> >> Want to know more about Fedora?
> >> Visit https://fedoraproject.org/wiki/
> >> Ready to contribute? See https://whatcanidoforfedora.org/
> >> 想了解更多中文资讯，访问 https://zh.fedoracommunity.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
> >> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Peter Boy]

> Am 10.05.2023 um 18:45 schrieb Kevin Fenzi :
> 
> On Wed, May 10, 2023 at 12:21:51PM +0800, Jens-Ulrik Petersen wrote:
>> Thanks for all the helpful comments and feedback,
>> though more is still welcome of course.
>> So I am leaning now towards not installing fedora-repos-modular by default
>> (rather than disabling the modular repos by default): also for upgrade
>> compatibility.
>> 
>> I have started a Change proposal draft, which I think should be ready soon,
>> with current working title *"Turn off modular dnf repos by default"*.
>> Perhaps *"No default fedora-repos-modular"* would be more precise.
>> Or any better suggestions (that don't sound like modularity is being
>> removed)?
>> 
>> I think the actual work (PR's) required is not huge,
>> but if someone is particularly keen to join the effort let me know.
> 
> So, at the risk of opening a larger can of worms...and increasing the
> scope here beyond what you have any desire to do...
> 
> Should we consider just retiring modular repos entirely?
> 
> I do know there's a number of active module builds, but I am not sure
> how much users use them. While RHEL still uses modules, EPEL has retired
> their epel8 modular repos. 
> 
> Can the things using modules now switch to compat packages in the main
> repository? 
> 
> I realize we may want to just say 'no, not now' here, but I thought I
> would bring it up.


I suppose I would belong to the latter. From a Server admin’s POV the modules 
are a great chance to keep some backwards compatibility with our fast pacing 
distro. The most prominent example is PostgreSQL. It is not so rare that the 
new major version requires an adjustment in the application programme or at 
least an extensive test. And every major update also requires a migration of 
the entire data stock. Modularisation is a welcome opportunity to quickly 
switch to a new release and use new capabilities, but to carry out the 
adaptation / tests with PostgreSQL at your leisure. 

And that is just one example. Another example is changes in languages such as 
Ruby, where application programmes sometimes cannot keep up with the changes. 
Same is true for httpd or tomcat - just some other examples.

If we could manage compat packages or parallel use of different major versions 
(as, for example, the Java runtime environment has managed to provide perfectly 
for decades), then modularisation would probably no longer be needed. 

With Fedora Server, we are not only aiming at the home lab, but also at an 
enterprise deployment. And there, backwards compatibility and long-term 
usability are an indispensable must. 




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

pghmcfc pushed to rpms/perl-Ref-Util (rawhide). "SPDX migration (..more)"

[notifications]

Notification time stamped 2023-05-10 16:57:36 UTC

From 645ca7c417022b4883e3e6da5b3af403946ddf81 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: May 10 2023 16:55:50 +
Subject: SPDX migration


Also:
- Use %license unconditionally
- Use author-independent source URL

---

diff --git a/perl-Ref-Util.spec b/perl-Ref-Util.spec
index 753abc0..77832cf 100644
--- a/perl-Ref-Util.spec
+++ b/perl-Ref-Util.spec
@@ -7,11 +7,11 @@
 
 Name:  perl-Ref-Util
 Version:   0.204
-Release:   16%{?dist}
+Release:   17%{?dist}
 Summary:   Utility functions for checking references
 License:   MIT
 URL:   https://metacpan.org/release/Ref-Util
-Source0:   
https://cpan.metacpan.org/authors/id/A/AR/ARC/Ref-Util-%{version}.tar.gz
+Source0:   
https://cpan.metacpan.org/modules/by-module/Ref/Ref-Util-%{version}.tar.gz
 BuildArch: noarch
 # Build
 BuildRequires: coreutils
@@ -50,7 +50,7 @@ BuildRequires:perl(B::Concise)
 BuildRequires: perl(CPAN::Meta) >= 2.120900
 BuildRequires: perl(Readonly)
 %endif
-# Runtime
+# Dependencies
 Requires:  perl(Ref::Util::XS)
 
 %description
@@ -73,17 +73,18 @@ find %{buildroot} -type f -name .packlist -delete
 make test
 
 %files
-%if 0%{?_licensedir:1}
 %license LICENSE
-%else
-%doc LICENSE
-%endif
 %doc Changes README
 %{perl_vendorlib}/Ref/
 %{_mandir}/man3/Ref::Util.3*
 %{_mandir}/man3/Ref::Util::PP.3*
 
 %changelog
+* Wed May 10 2023 Paul Howarth  - 0.204-17
+- SPDX migration
+- Use %%license unconditionally
+- Use author-independent source URL
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.204-16
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Ref-Util/c/645ca7c417022b4883e3e6da5b3af403946ddf81?branch=rawhide
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Daniel P . Berrangé]

On Wed, May 10, 2023 at 11:37:34AM -0500, Chris Adams wrote:
> Once upon a time, Daniel P. Berrangé  said:
> > If the idea to allow a UKI to contain multiple alternate, signed,
> > cmdline line profiles gets accepted
> 
> Are those of us who need boot-time kernel options (e.g. for hardware
> workarounds or such) just screwed in the signed command-line cases?

Today yes, but in future no. There's very active ongoing discussion
and coding to sort out how to securely allow local customization
of kernel command lines. Note, I said "local customization", I didn't
say "arbitrary interactive override at boot time". IOW, the way it is
achieved will probably look different to what we're used to historically.

Some form of local deployment level customization is clearly critical if
UKIs are to be viable beyond tightly constrained deployment scenarios.
Hardware specific workarounds is one use case that needs to be supported.

If you want to learn more, the systemd ticket I linked to in my mail
has all the discussion (sorry, a very long read, I know) and links to
pull requests where relevant.

With 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Lennart Poettering]

On Mi, 10.05.23 11:20, Simo Sorce (s...@redhat.com) wrote:

> It sounds reasonable for sure.
> The only concern is, given Microsoft creates at most 500MB ESP
> partitions, are we sure all UEFI systems out there will not choke on a
> 1GB one?

Well, I don't really think we have a reason to believe that a 1G ESP
was any more problematic than a 0.1G ESP. I am not aware of any
reports, and given that FAT32 is mandated by UEFI since basically
always, I think there's no immediate reason to believe we are in
trouble.

I think the only reasonable approach here is to pick a larger default
in a development distro, and collect feedback.

> Can't we reduce the number of kernels by having *only* one UKI and a
> rescue one that can be used to restore the previous working UKI from
> /root if the active one fails?

I'd kill the rescue concept as a separate kernel. Pre-compiled UKIs
provided by Fedora should be comprehensive and suitable enough to be
rescue images, I don't see why we need a second version of that. The
only difference between a rescue boot and a regular boot should be one
of parameterization, not of picking different kernel.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Kevin Fenzi]

On Wed, May 10, 2023 at 12:21:51PM +0800, Jens-Ulrik Petersen wrote:
> Thanks for all the helpful comments and feedback,
> though more is still welcome of course.
> So I am leaning now towards not installing fedora-repos-modular by default
> (rather than disabling the modular repos by default): also for upgrade
> compatibility.
> 
> I have started a Change proposal draft, which I think should be ready soon,
> with current working title *"Turn off modular dnf repos by default"*.
> Perhaps *"No default fedora-repos-modular"* would be more precise.
> Or any better suggestions (that don't sound like modularity is being
> removed)?
> 
> I think the actual work (PR's) required is not huge,
> but if someone is particularly keen to join the effort let me know.

So, at the risk of opening a larger can of worms...and increasing the
scope here beyond what you have any desire to do...

Should we consider just retiring modular repos entirely?

I do know there's a number of active module builds, but I am not sure
how much users use them. While RHEL still uses modules, EPEL has retired
their epel8 modular repos. 

Can the things using modules now switch to compat packages in the main
repository? 

I realize we may want to just say 'no, not now' here, but I thought I
would bring it up.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Luca Boccassi]

> On Wed, May 10, 2023 at 03:52:51PM -, Luca Boccassi wrote:
> 
> If the idea to allow a UKI to contain multiple alternate, signed,
> cmdline line profiles gets accepted [1], then a "rescue" image
> won't neccessarily need to be a separate image anymore. There could
> just be an alternative cmdline that caused the initrd to launch in
> a "rescue" / "safe" mode, and that would be nicely complemented by
> an A/B scheme to cope with bad kernel upgrades.
> 
> With regards,
> Daniel
> 
> [1] https://github.com/systemd/systemd/issues/24539

Yes, we should definitely have that. Had started scoping how to build it and 
encode it, but got distracted by other squirrels.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Chris Adams]

Once upon a time, Daniel P. Berrangé  said:
> If the idea to allow a UKI to contain multiple alternate, signed,
> cmdline line profiles gets accepted

Are those of us who need boot-time kernel options (e.g. for hardware
workarounds or such) just screwed in the signed command-line cases?

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Daniel P . Berrangé]

On Wed, May 10, 2023 at 12:00:36PM -0400, Neal Gompa wrote:
> On Wed, May 10, 2023 at 11:12 AM Simo Sorce  wrote:
> >
> > On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote:
> > > On Tue, May 9, 2023 at 12:31 PM Lennart Poettering  
> > > wrote:
> > > >
> > > > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> > > >
> > > > > I've been asked to consider converting /boot to a Btrfs subvolume so
> > > > > that it no longer has a fixed space allocation to deal with the ever
> > > > > increasing amount of firmware required for NVIDIA GPUs[1]. This is
> > > > > currently incompatible with how systemd views the world, because the
> > > > > "discoverable partition spec" is wired to partitions, and there is no
> > > > > equivalent spec for subvolumes of a volume. And I imagine that
> > > > > XBOOTLDR (whatever that is) also would have a problem with this.
> > > >
> > > > This makese no sense. If you want /boot to just be a subvolume of the
> > > > rootfs btrfs, then this would imply it's also covered by the same
> > > > security choices, i.e. encryption. We want to bind that sooner or
> > > > later to things like TPM2, FIDO2, PKCS11. And that's simply not
> > > > feasible from a boot loader environment.
> > > >
> > > > Hence, the place the kernel is loaded from (regardless if you call it
> > > > /efi or /boot or /boot/efi, and regardless what fs it is) must be
> > > > accessible from the boot loader easily, without requiring
> > > > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader.
> > > >
> > > > Hence: btrfs subvols won't work for this
> > >
> > > If we're not using LUKS for encryption, then this is not a problem.
> > > We're generally looking toward encrypting subvolumes individually
> > > using the upcoming Btrfs native encryption capability rather than
> > > using LUKS. That allows us to
> > >
> > > 1. Pick which subvolumes are encrypted
> > > 2. Pick the security binding method per subvolume
> > >
> > > For example, the root and home subvolumes would use TPM or some other
> > > non-interactive binding. The user subvolume in home would decrypt with
> > > user login.
> >
> > Neal,
> > I think you are barking up the wrong tree here.
> >
> > The design of the boot loader *nedds* to be simple.
> >
> > Simple means, VFAT and *no trust* in the filesystem, individual files
> > are signed and verified.
> > Only the bare minimum *necessary* is in the boot partition, which means
> > kernel images and the bare minimum init image needed to unlock and
> > mount the root partition.
> >
> > There is no point in building a more complex system than that and load
> > tons of garbage drivers in the EFI.
> >
> > Booting is a staged system, and should be kept as simple as possible to
> > avoid duplication (which means subtle bugs and a ton of maintenance
> > overhead).
> >
> 
> This proposal isn't better. Neither Windows nor macOS put critical
> operating system code in the ESP, and we shouldn't either. But you
> want to put kernels in the ESP? That's the wrong approach too.
> 
> As soon as you throw UKIs in the mix, you've completely broken that
> because now the absolutely most valuable code for your system is in a
> "hostile" environment. At least we can make /boot authenticated and
> tamper resistant as a Btrfs subvolume.

The firmware will start by booting a binary found in the ESP,
and thus given the ESP is untrusted (hostile) we need a means
to validate that binary's integrity no matter what, most likely
using SecureBoot & TPM PCR measurements. Using this mechanism
for validating the UKI makes sense since it has to exist no
matter what. There's no need for the filesystem to be authenticated
/ tamper resistant if the binaries themselves are authenticated
and tamper resistant.

> I would rather have a multi-stage boot process, where the first stage
> does just enough to unlock and load the OS volume to load the real
> boot environment.

With 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Gary Buhrmaster]

On Wed, May 10, 2023 at 3:56 PM Neal Gompa  wrote:

> At least in the upstream kiwi project, we encountered problems making
> bigger ESPs because not all UEFI implementations handle FAT32 (despite
> it being part of the spec). In particular, there were a few server
> boards and especially AWS EC2 that couldn't handle it.

As I recall, modern FAT16 implementations (and yes, not
all UEFI implementations might support modern FAT16)
support a 4GB disk size, which is more than the proposed
1GB size.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Neal Gompa]

On Wed, May 10, 2023 at 11:12 AM Simo Sorce  wrote:
>
> On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote:
> > On Tue, May 9, 2023 at 12:31 PM Lennart Poettering  
> > wrote:
> > >
> > > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> > >
> > > > I've been asked to consider converting /boot to a Btrfs subvolume so
> > > > that it no longer has a fixed space allocation to deal with the ever
> > > > increasing amount of firmware required for NVIDIA GPUs[1]. This is
> > > > currently incompatible with how systemd views the world, because the
> > > > "discoverable partition spec" is wired to partitions, and there is no
> > > > equivalent spec for subvolumes of a volume. And I imagine that
> > > > XBOOTLDR (whatever that is) also would have a problem with this.
> > >
> > > This makese no sense. If you want /boot to just be a subvolume of the
> > > rootfs btrfs, then this would imply it's also covered by the same
> > > security choices, i.e. encryption. We want to bind that sooner or
> > > later to things like TPM2, FIDO2, PKCS11. And that's simply not
> > > feasible from a boot loader environment.
> > >
> > > Hence, the place the kernel is loaded from (regardless if you call it
> > > /efi or /boot or /boot/efi, and regardless what fs it is) must be
> > > accessible from the boot loader easily, without requiring
> > > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader.
> > >
> > > Hence: btrfs subvols won't work for this
> >
> > If we're not using LUKS for encryption, then this is not a problem.
> > We're generally looking toward encrypting subvolumes individually
> > using the upcoming Btrfs native encryption capability rather than
> > using LUKS. That allows us to
> >
> > 1. Pick which subvolumes are encrypted
> > 2. Pick the security binding method per subvolume
> >
> > For example, the root and home subvolumes would use TPM or some other
> > non-interactive binding. The user subvolume in home would decrypt with
> > user login.
>
> Neal,
> I think you are barking up the wrong tree here.
>
> The design of the boot loader *nedds* to be simple.
>
> Simple means, VFAT and *no trust* in the filesystem, individual files
> are signed and verified.
> Only the bare minimum *necessary* is in the boot partition, which means
> kernel images and the bare minimum init image needed to unlock and
> mount the root partition.
>
> There is no point in building a more complex system than that and load
> tons of garbage drivers in the EFI.
>
> Booting is a staged system, and should be kept as simple as possible to
> avoid duplication (which means subtle bugs and a ton of maintenance
> overhead).
>

This proposal isn't better. Neither Windows nor macOS put critical
operating system code in the ESP, and we shouldn't either. But you
want to put kernels in the ESP? That's the wrong approach too.

As soon as you throw UKIs in the mix, you've completely broken that
because now the absolutely most valuable code for your system is in a
"hostile" environment. At least we can make /boot authenticated and
tamper resistant as a Btrfs subvolume.

I would rather have a multi-stage boot process, where the first stage
does just enough to unlock and load the OS volume to load the real
boot environment.





--
真実はいつも一つ！/ 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Daniel P . Berrangé]

On Wed, May 10, 2023 at 03:52:51PM -, Luca Boccassi wrote:
> > On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
> > 
> > It sounds reasonable for sure.
> > The only concern is, given Microsoft creates at most 500MB ESP
> > partitions, are we sure all UEFI systems out there will not choke on a
> > 1GB one?
> > 
> > Can't we reduce the number of kernels by having *only* one UKI and a
> > rescue one that can be used to restore the previous working UKI from
> > /root if the active one fails?
> > 
> > Or perhaps just have always 2 UKI (current, and former working).
> > Do we actually need a separate dedicated rescue UKI? Can't rescue be
> > implemented by booting the previously working UKI with a "rescue"
> > command line option ?
> 
> Word of caution on 'rescue' images: MSFT just had to essentially
> render 10 years of recovery/install media unbootable due to the
> black lotus vulnerability. It was not (and still is not) pretty.
> 
> When there's signatures and verifications involved, you really
> want an upgradable system. But if you set that whole infrastructure
> up, there's really not that much difference left with an A/B scheme.

If the idea to allow a UKI to contain multiple alternate, signed,
cmdline line profiles gets accepted [1], then a "rescue" image
won't neccessarily need to be a separate image anymore. There could
just be an alternative cmdline that caused the initrd to launch in
a "rescue" / "safe" mode, and that would be nicely complemented by
an A/B scheme to cope with bad kernel upgrades.

With regards,
Daniel

[1] https://github.com/systemd/systemd/issues/24539
-- 
|: 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] Fedora-IoT 39 RC 20230510.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora-IoT 39 RC 20230510.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/39iot

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_39_RC_20230510.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_39_RC_20230510.0_General

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Neal Gompa]

On Wed, May 10, 2023 at 11:21 AM Simo Sorce  wrote:
>
> On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
> > On Di, 09.05.23 09:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
> > wrote:
> >
> > > > == Summary ==
> > > >
> > > > This change will increase the minimum size of the ESP to be 500MB,
> > > > which is also the same value used by Microsoft for Windows 10 and
> > > > newer.
> > >
> > > This is both too much and not enough. Essentially, this grows the ESP,
> > > but also leaves the XBOOTLDR partition large. Overall, the users pays
> > > twice, and on some systems 1.5GB is not insignificant. OTOH, 500 or
> > > 512 MB seems not enough: three big UKIs and a rescue kernel and and
> > > some Windows blobs and a firmware update would likely overflow.
> > >
> > > If we want to change the default here, let's do some proper cleanup:
> > > 1. the split between ESP and XBOOTLDR is only useful in the case where
> > >ESP already existed and was small. If the installer is *creating*
> > >an ESP, it should just make it large enough.
> > > 2. having a second partition with a second (different) file system
> > >implementation just increases the footprint and attack surface for
> > >no gain. If we create XBOOTLDR, make it like the ESP (i.e. VFAT
> > >in almost all realistic scenarios).
> > > 3. if there are bootloaders that don't read one or the other partition
> > >as they should, fix them.
> > >
> > > Then we can make the ESP 1 GB *and* save space compared to current
> > > defaults.
> > >
> > > (Point 2. is not really *necessary* for the size changes, but it'd be
> > > nice to get rid of this anachronism if this area is being touched.)
> >
> > I guess this might not be surprising, but this proposal makes a ton of
> > sense to me and has my full support, FWTW
>
> It sounds reasonable for sure.
> The only concern is, given Microsoft creates at most 500MB ESP
> partitions, are we sure all UEFI systems out there will not choke on a
> 1GB one?
>
> Can't we reduce the number of kernels by having *only* one UKI and a
> rescue one that can be used to restore the previous working UKI from
> /root if the active one fails?

At least in the upstream kiwi project, we encountered problems making
bigger ESPs because not all UEFI implementations handle FAT32 (despite
it being part of the spec). In particular, there were a few server
boards and especially AWS EC2 that couldn't handle it.

Reference: 
https://github.com/OSInside/kiwi/commit/4b17aaa8b545260bf26ab081d10dfb6a674621b9

I would be wary of issues like this.




--
真実はいつも一つ！/ 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Luca Boccassi]

> On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
> 
> It sounds reasonable for sure.
> The only concern is, given Microsoft creates at most 500MB ESP
> partitions, are we sure all UEFI systems out there will not choke on a
> 1GB one?
> 
> Can't we reduce the number of kernels by having *only* one UKI and a
> rescue one that can be used to restore the previous working UKI from
> /root if the active one fails?
> 
> Or perhaps just have always 2 UKI (current, and former working).
> Do we actually need a separate dedicated rescue UKI? Can't rescue be
> implemented by booting the previously working UKI with a "rescue"
> command line option ?

Word of caution on 'rescue' images: MSFT just had to essentially render 10 
years of recovery/install media unbootable due to the black lotus 
vulnerability. It was not (and still is not) pretty.

When there's signatures and verifications involved, you really want an 
upgradable system. But if you set that whole infrastructure up, there's really 
not that much difference left with an A/B scheme.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Leslie Satenstein via devel]

Leslie Satenstein    

Some end-user feedback.

I believe in the KISS approach (Keep It Simple S).
 I would consider /boot as a btrfs volume, and not a sub-volume, but why 
bother? 
For me, it being a btrfs partition is definitely not a priority or urgency, as 
I use rsync for backup/restore of the ext4 partition.
For my desktop setup, I have several disks with independent btrfs 
partitions.These are not sub-volumes, again, they are fully independent.
I manually add them to my /etc/fstab after I install the vanilla Fedora Linux 
distribution 
I make use of them as I independent volumes. They definitely are not 
sub-volumes.
Some common sense.=
Most user disks today are of size 500gigs or more.I do not concern myself with 
1024 megs for /boot.  I also reserve/use 500megs for /boot/efi 

Better to spend energy on other things.




On Wednesday, May 10, 2023 at 11:12:20 a.m. EDT, Simo Sorce 
 wrote:  
 
 On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote:
> On Tue, May 9, 2023 at 12:31 PM Lennart Poettering  
> wrote:
> > 
> > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> > 
> > > I've been asked to consider converting /boot to a Btrfs subvolume so
> > > that it no longer has a fixed space allocation to deal with the ever
> > > increasing amount of firmware required for NVIDIA GPUs[1]. This is
> > > currently incompatible with how systemd views the world, because the
> > > "discoverable partition spec" is wired to partitions, and there is no
> > > equivalent spec for subvolumes of a volume. And I imagine that
> > > XBOOTLDR (whatever that is) also would have a problem with this.
> > 
> > This makese no sense. If you want /boot to just be a subvolume of the
> > rootfs btrfs, then this would imply it's also covered by the same
> > security choices, i.e. encryption. We want to bind that sooner or
> > later to things like TPM2, FIDO2, PKCS11. And that's simply not
> > feasible from a boot loader environment.
> > 
> > Hence, the place the kernel is loaded from (regardless if you call it
> > /efi or /boot or /boot/efi, and regardless what fs it is) must be
> > accessible from the boot loader easily, without requiring
> > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader.
> > 
> > Hence: btrfs subvols won't work for this
> 
> If we're not using LUKS for encryption, then this is not a problem.
> We're generally looking toward encrypting subvolumes individually
> using the upcoming Btrfs native encryption capability rather than
> using LUKS. That allows us to
> 
> 1. Pick which subvolumes are encrypted
> 2. Pick the security binding method per subvolume
> 
> For example, the root and home subvolumes would use TPM or some other
> non-interactive binding. The user subvolume in home would decrypt with
> user login.

Neal,
I think you are barking up the wrong tree here.

The design of the boot loader *nedds* to be simple.

Simple means, VFAT and *no trust* in the filesystem, individual files
are signed and verified.
Only the bare minimum *necessary* is in the boot partition, which means
kernel images and the bare minimum init image needed to unlock and
mount the root partition.

There is no point in building a more complex system than that and load
tons of garbage drivers in the EFI.

Booting is a staged system, and should be kept as simple as possible to
avoid duplication (which means subtle bugs and a ton of maintenance
overhead).

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Simo Sorce]

On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
> On Di, 09.05.23 09:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> 
> > > == Summary ==
> > > 
> > > This change will increase the minimum size of the ESP to be 500MB,
> > > which is also the same value used by Microsoft for Windows 10 and
> > > newer.
> > 
> > This is both too much and not enough. Essentially, this grows the ESP,
> > but also leaves the XBOOTLDR partition large. Overall, the users pays
> > twice, and on some systems 1.5GB is not insignificant. OTOH, 500 or
> > 512 MB seems not enough: three big UKIs and a rescue kernel and and
> > some Windows blobs and a firmware update would likely overflow.
> > 
> > If we want to change the default here, let's do some proper cleanup:
> > 1. the split between ESP and XBOOTLDR is only useful in the case where
> >ESP already existed and was small. If the installer is *creating*
> >an ESP, it should just make it large enough.
> > 2. having a second partition with a second (different) file system
> >implementation just increases the footprint and attack surface for
> >no gain. If we create XBOOTLDR, make it like the ESP (i.e. VFAT
> >in almost all realistic scenarios).
> > 3. if there are bootloaders that don't read one or the other partition
> >as they should, fix them.
> > 
> > Then we can make the ESP 1 GB *and* save space compared to current
> > defaults.
> > 
> > (Point 2. is not really *necessary* for the size changes, but it'd be
> > nice to get rid of this anachronism if this area is being touched.)
> 
> I guess this might not be surprising, but this proposal makes a ton of
> sense to me and has my full support, FWTW

It sounds reasonable for sure.
The only concern is, given Microsoft creates at most 500MB ESP
partitions, are we sure all UEFI systems out there will not choke on a
1GB one?

Can't we reduce the number of kernels by having *only* one UKI and a
rescue one that can be used to restore the previous working UKI from
/root if the active one fails?

Or perhaps just have always 2 UKI (current, and former working).
Do we actually need a separate dedicated rescue UKI? Can't rescue be
implemented by booting the previously working UKI with a "rescue"
command line option ?

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

On Wed, May 10, 2023 at 9:48 AM Florian Weimer  wrote:

> * Aoife Moloney:
>
> > There are two types of Flatpak containers -
> > runtimes - which contain unmodified Fedora packages,
> > and applications - which contain Fedora packages rebuilt to relocate
> > them from /usr to /app.
>
> Is this relocation still required?
>

Yes - the /app vs. /usr split is pretty fundamental to the operation of
Flatpak, and this Change doesn't propose any changes to how Flatpak works,
just how Flatpaks are built in Fedora.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Simo Sorce]

On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote:
> On Tue, May 9, 2023 at 12:31 PM Lennart Poettering  
> wrote:
> > 
> > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> > 
> > > I've been asked to consider converting /boot to a Btrfs subvolume so
> > > that it no longer has a fixed space allocation to deal with the ever
> > > increasing amount of firmware required for NVIDIA GPUs[1]. This is
> > > currently incompatible with how systemd views the world, because the
> > > "discoverable partition spec" is wired to partitions, and there is no
> > > equivalent spec for subvolumes of a volume. And I imagine that
> > > XBOOTLDR (whatever that is) also would have a problem with this.
> > 
> > This makese no sense. If you want /boot to just be a subvolume of the
> > rootfs btrfs, then this would imply it's also covered by the same
> > security choices, i.e. encryption. We want to bind that sooner or
> > later to things like TPM2, FIDO2, PKCS11. And that's simply not
> > feasible from a boot loader environment.
> > 
> > Hence, the place the kernel is loaded from (regardless if you call it
> > /efi or /boot or /boot/efi, and regardless what fs it is) must be
> > accessible from the boot loader easily, without requiring
> > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader.
> > 
> > Hence: btrfs subvols won't work for this
> 
> If we're not using LUKS for encryption, then this is not a problem.
> We're generally looking toward encrypting subvolumes individually
> using the upcoming Btrfs native encryption capability rather than
> using LUKS. That allows us to
> 
> 1. Pick which subvolumes are encrypted
> 2. Pick the security binding method per subvolume
> 
> For example, the root and home subvolumes would use TPM or some other
> non-interactive binding. The user subvolume in home would decrypt with
> user login.

Neal,
I think you are barking up the wrong tree here.

The design of the boot loader *nedds* to be simple.

Simple means, VFAT and *no trust* in the filesystem, individual files
are signed and verified.
Only the bare minimum *necessary* is in the boot partition, which means
kernel images and the bare minimum init image needed to unlock and
mount the root partition.

There is no point in building a more complex system than that and load
tons of garbage drivers in the EFI.

Booting is a staged system, and should be kept as simple as possible to
avoid duplication (which means subtle bugs and a ton of maintenance
overhead).

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review of Python packages needed

[Felix Wang]

I'd like to take this two packages reviews and will review them in the next one 
or two days.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedora 38 - in witch timespan a net iso is build..??

[stan via devel]

On Tue, 09 May 2023 12:10:49 -
André verwijs  wrote:

> installed Fedora with "Fedora-Everything-netinst-x86_64-38-1.6.iso"
> but hat small issues. (firewall packages) In witch timespan will a
> new iso be build..?? At least use the latest updates for  this (or
> any other) installation iso... 

As I understand it, once the final isos have been released, they are
permanent.  They don't get rebuilt because it would require testing to
ensure that they pass all the QA tests, and that testing is being
conducted on the next release in rawhide instead.  So, to answer your
question, the new iso is built at the release of the next version of
fedora (in approximately 6 months).

Once the iso packages are installed, it is possible to access the
fedora repositories and get packages via the package manager of choice.
In a terminal, with an internet connection active, type
dnf update
to see the available updates.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Review of Python packages needed

[Kai A. Hiller]

Hello,

I need help getting the following two Python packages reviewed – they 
are dependencies of matrix-synapse:


 * python-immutabledict
   
 * python-hiredis 

Please let me know what you want in return for the review.

Best wishes
Kai
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: C-specific compiler parameters (was: Update on Changes/PortingToModernC)

[Björn Persson]

Jakub Jelinek wrote:
> On Wed, May 10, 2023 at 12:09:10AM +0200, Björn Persson wrote:
> > Florian Weimer wrote:  
> > > I am going to explore a way to land -Werror=implicit-int
> > > -Werror=implicit-function-declaration among the default compiler flags.
> > > There's a bit of an issue because the C++ front end warns on
> > > those flags, so we need another -specs= kludge that is incompatible with
> > > Clang.  
> > 
> > It sounds like those parameters should be added only to CFLAGS, not to
> > CXXFLAGS.
> > 
> > __global_compiler_flags already contains things that cause warnings
> > from the Ada and Fortran compilers. The Ada packages get the warning
> > “'-Werror=' argument '-Werror=format-security' is not valid for Ada”
> > over and over. It doesn't break any builds but it's annoying noise in
> > the build logs.  
> 
> GCC 13 has a solution for that, one can add
> -Wno-complain-wrong-lang
> to
> -Werror=format-security
> etc. and avoid such warnings (that some compiler option is only appropriate
> for a subset of GCC languages and it is compiling some other language).

Thanks. That's an acceptable workaround, and seems to work as
advertised. I may add it to build_adaflags if a central solution won't
be accepted.

It would still be better to use parameters only where they are
meaningful. Longer command lines make troubleshooting more difficult.

Björn Persson


pgpxBrQsHBX2P.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Bug 2188992 - Please branch and build sscep in epel8

[Troy Dawson]

I just noticed this went to the the wrong mailling list.
Not many people are going to see this on epel-devel-owners.

On Wed, May 10, 2023 at 7:02 AM Stephen Smoogen  wrote:

>
>
> On Wed, 10 May 2023 at 09:46, Troy Dawson  wrote:
>
>> For those EPEL maintainers deciding on whether to take this or not.
>> sscep looks like it is still maintained and active upstream.[1]
>> Although the request bug listed here looks new, there is a much older
>> duplicate bug requesting it. [2]
>> sscep has been orphaned and retired in Fedora, around F31.  The problem
>> with orphaning is that it doesn't tell you why it was orphaned.
>>
>
> Going from the emails I could find, it was the reason you outlined. At
> that time it was needing a version of openssl we were no longer going to
> support for security reasons.
>
>
>> But if we try to build the latest Fedora version on epel8, it's easy to
>> see that it requires compat-openssl10-devel.  In other words, at the time,
>> it wasn't compatible with the latest openssl.
>> That has been fixed upstream.
>> So whoever takes it will need to update the rpm to the latest upstream.
>>
>> I'm not trying to discourage anyone from taking this package.  It's
>> maintained upstream, so that's good.  I'm just letting ya'll know what will
>> be involved.
>>
>>
> Troy
>>
>> [1] - https://github.com/certnanny/sscep
>> [2] - https://bugzilla.redhat.com/show_bug.cgi?id=1741770
>>
>>
>>
>> On Wed, May 10, 2023 at 5:00 AM Kiran Suresh 
>> wrote:
>>
>>> Dear EPEL Community,
>>>
>>>
>>>
>>> Hope this email finds you well. I am writing to request your assistance
>>> with SSCEP package for EL8, looking for a packagers who would like to
>>> package and maintain SSCEP package on epel..
>>>
>>>
>>>
>>> We would like to request your help in addressing this issue so that we
>>> can proceed to utilize the package. If there are any packagers who would be
>>> willing to take over the maintenance of SSCEP package, we would be grateful
>>> for your support.
>>>
>>>
>>>
>>> We have submitted a bug for this request, and have not received any
>>> response on this.
>>>
>>>
>>>
>>> Here are some additional details about package request:
>>>
>>>
>>>
>>> Bug ID: 2188992
>>> Link to Bug: 2188992 – Please branch and build sscep in epel8
>>> (redhat.com) 
>>>
>>> Package name: sscep-0.6.1-5.20160525
>>>
>>> Purpose: Simple SCEP client
>>>
>>> Package for EL7: sscep-0.6.1-5.20160525git2052ee1.el7.src.rpm
>>>
>>>
>>>
>>> If someone from the community could pick up this bug and work on it, we
>>> would be more than happy to provide any additional information or
>>> assistance needed to resolve the issue. We believe that this package would
>>> be a valuable addition to the EPEL repository and would appreciate your
>>> help in making it available to others.
>>>
>>>
>>>
>>> Thank you for your time and consideration, and we look forward to
>>> hearing from you soon.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Thanks
>>>
>>> Kiran
>>>
>>> *Kiran Kumar Suresh*
>>>
>>> *TSS Infrastructure | *ksur...@vexcelco.com *| Mobile: (203) 822 3689*
>>>
>>>
>>>
>>>
>>>
>>
>
> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle.
> -- Ian MacClaren
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Florian Weimer]

* Aoife Moloney:

> There are two types of Flatpak containers -
> runtimes - which contain unmodified Fedora packages,
> and applications - which contain Fedora packages rebuilt to relocate
> them from /usr to /app.

Is this relocation still required?

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Lennart Poettering]

On Di, 09.05.23 15:22, Chris Murphy (li...@colorremedies.com) wrote:

>
>
> On Tue, May 9, 2023, at 2:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, May 09, 2023 at 01:31:01PM -0500, Chris Adams wrote:
> >> Once upon a time, Chris Murphy  said:
> >> > What about the increasing growth in linux-firmware and in particular the 
> >> > NVIDIA firmware requirements? My reading suggests it's significant and 
> >> > the future growth also significant.
> >>
> >> Could we use a dumb framebuffer in initrd and get rid of all the GPU
> >> firmware from the image?
> >
> > Maybe, probably, who knows… But it's not just the video. The pressure
> > to add more stuff and more drivers will only grow: bluetooth for keyboards
> > and FIDO2, sound support for voice assistance, network for remote 
> > attestation
> > or clevis, etc. We can push this can down the road, but it seems we need
> > to be ready to add move stuff before root is available anyway.
>
> I still think we need less kernel and initramfs in order to get more
> by having `/` available faster. Fast enough that the user isn't
> looking for or expecting interactivity in the few seconds it should
> take to get to `/` being mounted.

Aren't you the one who just proposed LinuxBoot, i.e. having one kernel
with initrd that includes complex storage, crypto, drivers, auth and
things chainload a second kernel with initrd that includes all that?

If you want fast boots and minimal disk space usage, then maybe have
tiny boot loader and a single UKI element after that and not play
games of setting up complex storage to load a secondary kernel that
then has to set up complex storage again.

You are arguing here into two opposing directions. One one hand you
want to chainload multiple kernels+initrd (claiming this was a good idea out
of the problem of sizing ESP/XBOOTLDR sufficientlly), and then on the
other hand you claim there's too much kernel+initrd in the boot
process?

What is it now? Pick one: more initrd or less initrd?

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

On Wed, May 10, 2023 at 8:06 AM Milan Crha  wrote:

> On Wed, 2023-05-10 at 11:54 +0100, Aoife Moloney wrote:
> > Additionally a couple of packages (evolution-data-services and
> > tracker-miners) are set up so they can be
> > built with an application-specific D-Bus prefix. Evolution has:
> >
> >   buildopts:
> > rpms:
> >   macros: |
> > %_eds_dbus_services_prefix org.gnome.Evolution
> >
> > This will need to be redone so that evolution-data-services doesn't
> > need recompilation
> > and the prefixing can be done by changing configuration files at
> > container build time.
>
> Hi,
> I cannot speak for the tracker-miners, but in case of the Evolution, it
> runs in its own sandbox, separated from the host system, with bundled
> evolution-data-server (eds) services, thus when the user installs the
> Flatpak version, he/she gets the expected Evolution and eds versions,
> independent of what the host system has installed. Advantage: the user
> gets all fixes, not only client-side (Evolution) fixes. It's important,
> from my point of view.
>

We'll still have an evolution-data-server that runs inside the sandbox and
has prefixed names, it will just have to be done a different way. My best
current idea is that for the (single) Flatpak build, the
evolution-data-services would have

-DDBUS_SERVICES_PREFIX=com.example.FlatpakApp

Then we'd change things (preferably upstream) so instead of building
DBUS_SERVICES_PREFIX into the source code,


com.example.FlatpakApp.org.gnome.evolution.dataserver.AddressBook10.service

would have:

 Exec=/app/libexec/evolution-addressbook-factory
--dbus-services-prefix=com.example.FlatpakApp

Then container.yaml would have something like:

 dbus-service-substitute=com.example.FlatpakApp:org.gnome.evolution

And that would do that substitution in the names and contents of any
service files when building the container. Does that sound workable? Are
there better ways we could do it?

> In many cases, this should consist of just a few minor changes to
> > container.yaml.
>
> Do you mean the `evolution.yaml` is gone with this change and the
> dependencies are taken directly from the .spec file? The eds dependency
> is a problem here, as you noted, not talking that not everything from
> the .spec file requires a rebuild for the flatpak (most dependencies
> are part of the runtime).
>

Yeah, evolution.yaml is gone with the change. Any dependency that is not
part of the runtime will have to have been rebuilt in the f39-app target,
or the container build will fail. Then we'll have some convenience at the
fedpkg level to make that not too painful. ('fedpkg flatpak-build' will
check that things seem ok before starting the build, and there will be
'fedpkg flatpak-build-rpms --all-missing' to rebuild the missing
dependencies.)

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Lennart Poettering]

On Di, 09.05.23 15:04, Chris Murphy (li...@colorremedies.com) wrote:

> > This makese no sense. If you want /boot to just be a subvolume of the
> > rootfs btrfs, then this would imply it's also covered by the same
> > security choices, i.e. encryption. We want to bind that sooner or
> > later to things like TPM2, FIDO2, PKCS11. And that's simply not
> > feasible from a boot loader environment.
>
> Windows and macOS do this, so it is feasible, the question is what
> are the consequences of this and are we willing to live with them?

They focus on a much more limited set of functionality.

Also, are you volunteering to implement and maintain a full LUKS2, TPM2,
FIDO2 and PKCS11 stack in UEFI mode? Good luck, man! And it's not
getting any simpler. Next thing coming up is probably PassKey support,
which means networking support. That's going to be fun in UEFI to support!

I mean, these things tend to grow and become more complicated over
time, and if you avoid Linux userspace then you make your life
impossibly hard. And I really don't see Chris Murphy stepping up and
maintaining that mess. Or are you?

As someone who actually occasionally writes UEFI code: ffs, give up on
the idea to reimplement complex auth protocols in UEFI mode! You want
to do *less* stuff in UEFI, not pile on and pile on. Grub's reputation
suffered because they are basically reimplementing a crappy version of
Linux in their boot loader. Get yourself out of that Grub mindset, man!

This idea appears so "out there" to me, I am sorry, but I somehow
can't believe you seriously are proposing this.

> One obvious consequence, it further creates dependency on a single
> bootloader, GRUB. Or we need an independent project that provides an
> EFI program for unlocking LUKS volumes within the pre-boot
> environment, thus making plaintext view available to any bootloader.

Sorry, this is *such* *a* *bad* *idea*.

> > Hence, the place the kernel is loaded from (regardless if you call
> > it /efi or /boot or /boot/efi, and regardless what fs it is) must
> > be accessible from the boot loader easily, without requiring
> > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader.
>
> I understand that might be difficult and something we don't want to
> do for resource reasons, but there isn't a technical impediment for
> it.

Well, that's true, you can hack anything up that a Turing machine can
execute and also run it in UEFI mode, but I seriously hope that you
are not actually suggesting this.

> FAT isn't resizable. The growth requirement for /boot is greater for
> some use cases more than others, so there is pressure building
> because it will create waste for some use cases and
> underprovisioning in other use cases. Those unverprovisioned being
> told they can't upgrade but need to reprovision to solve this is
> kindof annoying.

If you don't want to resize VFAT and XBOOTLDR is not enough to address
this problem we can relatively easily extend XBOOTLDR to allow more than one
additional such partition we can search through. The code in the boot
loader is relatively straightforward. The limiting factor is more
figuring out where to mount those.

But seriously, you are making up synthetic probems. If ESP is too
small add a large XBOOTLDR and I am pretty sure we'll be fine for a
long long time before this comes an issue again. So long in fact it
might never become.

> Right. Hence Linux Boot. Dump all the toy drivers in favor of real
> ones. And a real user space.

I mean you understand that this just adds another chain to the boot
process? if you do what you are proposing then you need to build a
kernel that supports all that, i.e. all the complex storage, graphics
and so on that you want to boot from, and thus you'll also have alrge
images, and then what did you gain? You ave to put that in the ESP
too, and the size limits still apply. It's illusionary to believe that
the size constraints for a kernel + drivers + complex storage stack +
crypto stack + auth stack would not apply to kernel that just runs in
uefi mode instead of native mode...

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Richard Hughes]

On Wed, 10 May 2023 at 11:55, Zbigniew Jędrzejewski-Szmek
 wrote:
> Especially not by making some small change contingent on moonshot proposals.
> But I think that a) the current proposal is just a band-aid, and
> b) to make things better we don't need to make huge changes.

Okay, please open a _new_ change proposal with what you want to
happen: expanding the scope like you suggest feels like me getting
tricked to work on your much bigger change that's not terribly
well-defined or tested.

> ...Anaconda needs to *lose* a feature where it
> refuses VFAT for /boot [1], the various places which create partitions
> need to be modified to inject the right partition-type UUID instead of
> made-up one, and instead of creating two partitions with different fs
> types, create just one. None of this is rocket science.

Perhaps you'd like to push this feature. I'd happily retract my
smaller proposal if you've got patches ready for anaconda, have tested
this on all platforms, and have all the votes.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Lennart Poettering]

On Di, 09.05.23 12:37, Neal Gompa (ngomp...@gmail.com) wrote:

> On Tue, May 9, 2023 at 12:31 PM Lennart Poettering  
> wrote:
> >
> > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > I've been asked to consider converting /boot to a Btrfs subvolume so
> > > that it no longer has a fixed space allocation to deal with the ever
> > > increasing amount of firmware required for NVIDIA GPUs[1]. This is
> > > currently incompatible with how systemd views the world, because the
> > > "discoverable partition spec" is wired to partitions, and there is no
> > > equivalent spec for subvolumes of a volume. And I imagine that
> > > XBOOTLDR (whatever that is) also would have a problem with this.
> >
> > This makese no sense. If you want /boot to just be a subvolume of the
> > rootfs btrfs, then this would imply it's also covered by the same
> > security choices, i.e. encryption. We want to bind that sooner or
> > later to things like TPM2, FIDO2, PKCS11. And that's simply not
> > feasible from a boot loader environment.
> >
> > Hence, the place the kernel is loaded from (regardless if you call it
> > /efi or /boot or /boot/efi, and regardless what fs it is) must be
> > accessible from the boot loader easily, without requiring
> > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader.
> >
> > Hence: btrfs subvols won't work for this
>
> If we're not using LUKS for encryption, then this is not a problem.

So you basically want to rebuild Fedora so that FDE is not available?

> We're generally looking toward encrypting subvolumes individually
> using the upcoming Btrfs native encryption capability rather than
> using LUKS. That allows us to

How do you establish trust in the underlying file system? The thing
that kernel fs maintainers made very clear is that they do not
consider Linux file systems safe regarding rogue offline
modification. Hence you must establish trust somehow *before* you
mount the fs, which pretty much means LUKS.

Linux fs maintainers also made very clear that they generally consider
alternative implementations of their file systems as unsupported, and
a problem. The big relevant Linux file systems consider only the
implementation in the Linux kernel as defining the format. Which means
that anything like an alternative implementation of btrfs or xfs or
ext4 in things like grub or EFI is expressly against the wishes of the
people who maintain the file systems.

Or in other words: what you are proposing appears like a very bad
idea, and in fact even upstream Grub wants to get away from
maintaining thei own fs drivers for Linux fs as I hear, because it's
so untenable to them, too.

Seriously, bury this idea.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Jens-Ulrik Petersen]

On Wed, May 10, 2023 at 8:39 PM Debarshi Ray via devel <
devel@lists.fedoraproject.org> wrote:

> On Tue, 2023-05-09 at 12:31 +0800, Jens-Ulrik Petersen wrote:
> If we do decide to disable the fedora-cisco-openh264 repository on the
> base fedora OCI image, then we might have to enable it separately for
> the fedora-toolbox images, because the OpenH264 codec is something that
> applications running inside the container might want to use.


Right, so I already dropped that idea based on the feedback given so far,
thanks. :+1:

An initial draft (I will rename the page later before submitting) is here
btw for those really interested:
https://fedoraproject.org/wiki/Changes/TurnOffModularRepos
(At this point I would probably prefer critical feedback/suggestions in
private until it is submitted. :-)

Jens
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Zbigniew Jędrzejewski-Szmek]

On Wed, May 10, 2023 at 11:54:39AM +0100, Aoife Moloney wrote:
> https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules

> For each Fedora release, we'll have two additional targets
> 
>  f39-flatpak-runtime (inherits f39), tags: f39-flatpak-runtime-build,
> f39-flatpak-runtime
>  f39-app (inherits f39-flatpak-runtime), tags: f39-app-build, f39-app
> 
> The f39-flatpak-runtime target has a limited use -
> it's used to build packages that go into the Flatpak runtimes
> (standard and KDE).
> This would include flatpak-runtime-config, flatpak-rpm-macros,
> but also rebuilds of standard packages if needed to prune dependencies:
> currently this is done for gstreamer-plugins-good.
> 
> The f39-app target is the main target that is used for prefix=/app rebuilds.
> flatpak-rpm-macros is part of the build group for this target,
> resulting in builds that target /app.
> As currently, spec files can be conditionalized with '%if 0%{?flatpak}'
> 
> Builds in f39-flatpak-runtime and f39-app have the dist tags
> .f39runtime and .f39app respectively.
> This is necessary so that we can automatically rebuild a package
> without having to bump the release in the specfile.
> (Koji requires everything to have a unique NVR.)
> It also allows humans and tools to easily distinguish these specialized 
> builds.

I love how simple this is. Mostly just using koji as it's supposed to be used.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Debarshi Ray via devel]

Hey Jens,

On Tue, 2023-05-09 at 12:31 +0800, Jens-Ulrik Petersen wrote:
> ps I think it would be a good idea to disable the cisco-h264 repo too
> by default in the fedora container image, and maybe also for headless
> Fedora editions.

If we do decide to disable the fedora-cisco-openh264 repository on the
base fedora OCI image, then we might have to enable it separately for
the fedora-toolbox images, because the OpenH264 codec is something that
applications running inside the container might want to use.

Coincidentally, changes like these is one of the motivations for:
https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker  :)

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Milan Crha]

On Wed, 2023-05-10 at 11:54 +0100, Aoife Moloney wrote:
> Additionally a couple of packages (evolution-data-services and
> tracker-miners) are set up so they can be
> built with an application-specific D-Bus prefix. Evolution has:
> 
>   buildopts:
>     rpms:
>   macros: |
>     %_eds_dbus_services_prefix org.gnome.Evolution
> 
> This will need to be redone so that evolution-data-services doesn't
> need recompilation
> and the prefixing can be done by changing configuration files at
> container build time.

Hi,
I cannot speak for the tracker-miners, but in case of the Evolution, it
runs in its own sandbox, separated from the host system, with bundled
evolution-data-server (eds) services, thus when the user installs the
Flatpak version, he/she gets the expected Evolution and eds versions,
independent of what the host system has installed. Advantage: the user
gets all fixes, not only client-side (Evolution) fixes. It's important,
from my point of view.

> In many cases, this should consist of just a few minor changes to
> container.yaml.

Do you mean the `evolution.yaml` is gone with this change and the
dependencies are taken directly from the .spec file? The eds dependency
is a problem here, as you noted, not talking that not everything from
the .spec file requires a rebuild for the flatpak (most dependencies
are part of the runtime).

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20230510.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230509.n.0
NEW: Fedora-Rawhide-20230510.n.0

= SUMMARY =
Added images:0
Dropped images:  2
Added packages:  4
Dropped packages:0
Upgraded packages:   85
Downgraded packages: 0

Size of added packages:  603.81 KiB
Size of dropped packages:0 B
Size of upgraded packages:   11.91 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230509.n.0.iso
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20230509.n.0.iso

= ADDED PACKAGES =
Package: qm-0.1.0-1.fc39
Summary: Containerized environment for running Quality Management software
RPMs:qm
Size:42.43 KiB

Package: rust-brownstone-3.0.0-1.fc39
Summary: Utilities for building fixed-size arrays
RPMs:rust-brownstone+default-devel rust-brownstone-devel
Size:25.06 KiB

Package: rust-indent_write-2.2.0-1.fc39
Summary: Simple Write adapters to add line indentation
RPMs:rust-indent_write+default-devel rust-indent_write+std-devel 
rust-indent_write-devel
Size:33.26 KiB

Package: veristat-0.1-1.fc39
Summary: Tool for loading, verifying, and debugging BPF object files
RPMs:veristat
Size:503.05 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  anaconda-39.14-1.fc39
Old package:  anaconda-39.12-1.fc39
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui 
anaconda-webui anaconda-widgets anaconda-widgets-devel
Size: 19.74 MiB
Size change:  179.64 KiB
Changelog:
  * Thu May 04 2023 Packit  - 39.13-1
  - WebUI: fix eslint error (jvanderwaa)
  - WebUI: run eslint in CI (jvanderwaa)
  - Update translations from Weblate

  * Tue May 09 2023 Packit  - 39.14-1
  - webui: better source maps (kkoukiou)
  - conf: Missing geolocation provider URL disables it (vslavik)
  - webui: [pixel tests] update review screen for v1 of autopartiotioning
(rvykydal)
  - webui: update review screen for v1 of autopartiotioning (rvykydal)
  - webui: reset partitioning on going Back from review screen (rvykydal)
  - webui: don't use global scope for translated strings (kkoukiou)
  - Move from webpack to esbuild bundler (kkoukiou)
  - webui: some invalid code fixes (kkoukiou)
  - Update translations from Weblate


Package:  ansible-lint-1:6.16.0-1.fc39
Old package:  ansible-lint-1:6.15.0-1.fc39
Summary:  Best practices checker for Ansible
RPMs: python3-ansible-lint
Size: 603.49 KiB
Size change:  5.17 KiB
Changelog:
  * Wed May 10 2023 Parag Nemade  - 1:6.16.0-1
  - Update to 6.16.0 version (#2196454)


Package:  awscli-1.27.131-1.fc39
Old package:  awscli-1.27.130-1.fc39
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 3.31 MiB
Size change:  -344 B
Changelog:
  * Tue May 09 2023 Gwyn Ciesla  - 1.27.131-1
  - 1.27.131


Package:  cinnamon-5.6.8-3.fc39
Old package:  cinnamon-5.6.8-2.fc39
Summary:  Window management and application launching for GNOME
RPMs: cinnamon cinnamon-calendar-server cinnamon-devel-doc
Size: 9.31 MiB
Size change:  175 B
Changelog:
  * Tue May 09 2023 Leigh Scott  - 5.6.8-3
  - Rebuild for cjs-5.7.0


Package:  cjs-1:5.7.0-0.1^git20230508.1ef6934.fc39
Old package:  cjs-1:5.6.1-1.fc39
Summary:  Javascript Bindings for Cinnamon
RPMs: cjs cjs-devel cjs-tests
Size: 3.49 MiB
Size change:  296.62 KiB
Changelog:
  * Tue May 09 2023 Leigh Scott  - 
1:5.7.0-0.1^git20230508.1ef6934
  - Update to 5.7.0 git snapshot


Package:  cri-o-1.27.0-1.fc39
Old package:  cri-o-1.26.1-1.fc38
Summary:  Open Container Initiative-based implementation of Kubernetes 
Container Runtime Interface
RPMs: cri-o
Size: 97.91 MiB
Size change:  -6.84 MiB
Changelog:
  * Wed Jan 25 2023 Peter Hunt~  - 0:1.26.1-2
  - update for obs

  * Tue Apr 25 2023 Peter Hunt  - 0:1.27.0-1
  - bump to v1.27.0


Package:  dnstwist-20230509-1.fc39
Old package:  dnstwist-20230413-2.fc39
Summary:  Domain name permutation engine
RPMs: dnstwist
Size: 34.86 KiB
Size change:  809 B
Changelog:
  * Tue May 09 2023 Artur Frenszek-Iwicki  - 20230509-1
  - Update to v20230509


Package:  fasterxml-oss-parent-51-1.fc39
Old package:  fasterxml-oss-parent-50-1.fc39
Summary:  FasterXML parent pom
RPMs: fasterxml-oss-parent
Size: 18.21 KiB
Size change:  13 B
Changelog:
  * Tue May 09 2023 Chris Kelley  - 51-1
  - Update to version 51


Package:  gdm-1:44.1-1.fc39
Old package:  gdm-1:44.0-1.fc39
Summary:  The GNOME Display Manager
RPMs: gdm gdm-devel gdm-pam-extensions-devel
Size: 4.64 MiB
Size change:  35.12 KiB

[EPEL-devel] Re: Ansible in EPEL 9

[Josh Boyer]

On Tue, May 9, 2023 at 11:24 PM Maxwell G  wrote:
>
> Hello EPEL users and developers,
>
>
> RHEL 9.2 was released today,
> so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL
> 9.2's ansible-core bump from 2.13.3 to 2.14.2.
> Each ansible major version is tied to a specific major version of
> ansible-core, and we keep them in sync.
>
> Along with this change, RHEL 9.2 builds ansible-core for the python3.11
> stack instead of the default python3 (3.9) stack.
> Therefore, ansible in EPEL now built for python3.11 as well.
>
> Here is the Bodhi update: 
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f51a0ff8a1
> Please help test and give karma.

Thank you for your efforts and clear communication!  It is very much
appreciated.

josh

>
> Until this update is pushed to stable, you may receive an error like
> this when running dnf upgrade
>
> ```
> Error:
>  Problem: package ansible-6.3.0-2.el9.noarch requires 
> python3.9dist(ansible-core) >= 2.13.3, but none of the providers can be 
> installed
>   - cannot install both ansible-core-2.14.2-4.el9.x86_64 and 
> ansible-core-2.13.3-2.el9_1.x86_64
>   - cannot install both ansible-core-2.14.2-4.el9.x86_64 and 
> ansible-core-2.13.3-1.el9.x86_64
>   - cannot install the best update candidate for package 
> ansible-core-2.13.3-2.el9_1.x86_64
>   - cannot install the best update candidate for package 
> ansible-6.3.0-2.el9.noarch
> (try to add '--allowerasing' to command line to replace conflicting packages 
> or '--skip-broken' to skip uninstallable packages or '--nobest' to use not 
> only best candidate packages)
> ```
>
> There are a couple potential solutions:
>
> 1. Run
>  $ dnf upgrade --exclude ansible-core
>to skip ansible-core and upgrade everything else.
> 2. In a couple hours from from now (now is 3:15 UTC), you'll be able to 
> install
>ansible 7.2.0 from testing with
>  $ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core
>and then run a plain `dnf upgrade` as usual.
>
>
> --
> Happy automating,
>
>
> Maxwell G (@gotmax23)
> Pronouns: He/They
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Zbigniew Jędrzejewski-Szmek]

On Wed, May 10, 2023 at 01:07:55PM +0200, Jun Aruga (he / him) wrote:
> > "No fedora-repos-modular in default installation" ?
> 
> I feel that's a better way than disabling (enabled=0) module repos by default.

To clarify: I fully agree. My earlier comment was about how to better reflect
this in the name. ("Disable" is not a good word because suggests "enabled=0".)

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Jun Aruga (he / him)]

> "No fedora-repos-modular in default installation" ?

I feel that's a better way than disabling (enabled=0) module repos by default.

/etc/yum.repos.d/fedora-modular.repo
/etc/yum.repos.d/fedora-updates-modular.repo

#enabled=1
enabled=0

For people who want to use the modularity, once they install the RPM
package fedora-repos-modular, they can install the modules without the
dnf command line option to enable the module repos.

```
$ sudo dnf install fedora-repos-modular
$ sudo dnf install 
```

Jun

On Wed, May 10, 2023 at 10:42 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, May 10, 2023 at 12:21:51PM +0800, Jens-Ulrik Petersen wrote:
> > Thanks for all the helpful comments and feedback,
> > though more is still welcome of course.
> > So I am leaning now towards not installing fedora-repos-modular by default
> > (rather than disabling the modular repos by default): also for upgrade
> > compatibility.
> >
> > I have started a Change proposal draft, which I think should be ready soon,
> > with current working title *"Turn off modular dnf repos by default"*.
> > Perhaps *"No default fedora-repos-modular"* would be more precise.
> > Or any better suggestions (that don't sound like modularity is being
> > removed)?
>
> "No fedora-repos-modular in default installation" ?
>
> > I think the actual work (PR's) required is not huge,
> > but if someone is particularly keen to join the effort let me know.
>
> The discussion is the work ;)
>
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Aoife Moloney]

https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Owner ==
* Name: [[User:Otaylor|Owen Taylor]]
* Email: otay...@redhat.com


== Detailed Description ==
There are two types of Flatpak containers -
runtimes - which contain unmodified Fedora packages,
and applications - which contain Fedora packages rebuilt to relocate
them from /usr to /app.
Currently, the rebuild process is done using modules -
packages are either rebuilt in a shared flatpak-common module, or in a
module specific to the application.
This change replaces this with a separate build target that all
rebuilds are done in.

=== Rebuilding RPMs ===
For each Fedora release, we'll have two additional targets

 f39-flatpak-runtime (inherits f39), tags: f39-flatpak-runtime-build,
f39-flatpak-runtime
 f39-app (inherits f39-flatpak-runtime), tags: f39-app-build, f39-app

The f39-flatpak-runtime target has a limited use -
it's used to build packages that go into the Flatpak runtimes
(standard and KDE).
This would include flatpak-runtime-config, flatpak-rpm-macros,
but also rebuilds of standard packages if needed to prune dependencies:
currently this is done for gstreamer-plugins-good.

The f39-app target is the main target that is used for prefix=/app rebuilds.
flatpak-rpm-macros is part of the build group for this target,
resulting in builds that target /app.
As currently, spec files can be conditionalized with '%if 0%{?flatpak}'

Builds in f39-flatpak-runtime and f39-app have the dist tags
.f39runtime and .f39app respectively.
This is necessary so that we can automatically rebuild a package
without having to bump the release in the specfile.
(Koji requires everything to have a unique NVR.)
It also allows humans and tools to easily distinguish these specialized builds.

Any Fedora packager can rebuild a package into f39-app using 'fepdkg
build --target=f39-app'.
There will also be a new convenience subcommands of fedpkg 'fedpkg
build-flatpak-rpms',
'fedpkg build-flatpak-rpms-local' that can be used to rebuild all
missing bundled dependencies of a Flatpak,
in Koji or locally.

Once a package exists in f39-app or f38-app, then
[[https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync
distrobuildsync]] will be used to do a build into f39-app each time a
standard build completes.

=== Container Versioning ===

Currently, the version is based on the module version:

  firefox:stable:3820230427145713:b1edb643 =>
firefox-stable-3820230427145713.b1edb643

Where the module version is created from platform versions and git
commit timestamps
for the module repository.
We could reproduce something very much like this based on the runtime branch and
git commit timestamp, but since application Flatpaks have an
identifiable "Main RPM"
(unlike the general case of modules and containers), a better scheme is:

  firefox-112.0.2-1.fc38 => firefox-flatpak-112.0.2-1
  name: main RPM name + -flatpak
  version: main RPM version
  release: automatically incremented based on existing Koji builds

Because upgrades are done on Flatpak ID (org.mozilla.Firefox),
there is no compatibility impact of switching Flatpaks from 'firefox'
to 'firefox-flatpak'.

There is considerable implementation complexity within OSBS to implement this,
because the N/V/R need to be written into generated Dockerfile as
labels ''before'' building it,
but it should be manageable. If not, we'll need to switch to a different scheme.
(Running dnf with --best when building the container will
help make this reliable
and would be a general improvement.)

=== Updates ===

The current plan is that builds of RPMs will be tagged directly into f39-app and
containers will be composed from the contents of  f39-app with no
involvement of Bodhi.
Bodhi is only involved in releasing the container.

We can add CI checks on container updates to compare the rebuilt
packages in the container
to the latest released versions for Fedora, though it's not always
easy to distinguish:

* Newer because of a RPM change that hasn't passed testing yet
* vs. Newer because a spec file was needed to get the package to
rebuild with prefix=/app

Since Fedora does not embargo builds,
there's no potential information leak if a change to dist-git is
released via container before it is released by RPM.

=== Disadvantages and issues===
In moving to this system, we lose the ability to take advantage of the
capabilities of modularity -
to use a different stream branch of a library for an application than
the one shipped in F39, say.
There are essentially no examples of this being used in all the
Flatpaks created for Fedora over the last 5 years,
probably because modularity has gained little traction within Fedora
more broadly.

Some Flatpak modules strip down bundled 

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 09, 2023 at 01:20:54PM +0100, Richard Hughes wrote:
> On Tue, 9 May 2023 at 10:22, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > This is both too much and not enough.
> 
> Right; and I think a different Fedora feature proposal would be a good
> idea for the version of Fedora when we switch to UKIs. Where we can
> just have /boot/efi and not /boot -- but that's not what this proposal
> is about. This is primarily to keep firmware updates working, and as a
> secondary measure maybe more people can test UKIs. I don't want this
> simple feature of "unbreak future firmware updates" to become
> "completely rework how we boot the system".
> 
> > (Point 2. is not really *necessary* for the size changes, but it'd be
> > nice to get rid of this anachronism if this area is being touched.)
> 
> I think that's fine -- but I don't think the onus should be on me to
> push it through. Like I said to Lennart, if you want to do a Fedora
> proposal to rework all this stuff to remove /boot that's fine, but
> please don't hijack this one and make me responsible for doing the
> work.

I don't see reply to Lennart anywhere; did you maybe not send to the list?

I wouldn't want to force you (or anyone else) to take on huge tasks.
Especially not by making some small change contingent on moonshot proposals.
But I think that a) the current proposal is just a band-aid, and
b) to make things better we don't need to make huge changes.
And c), there is a real cost to doing a band-aid solution now and
starting another solution in a slightly different direction immediately
after. The layout of partitions generally remains unchanged over the
lifetime of installations, so if we introduce some new layout, we'll have
to make it work over the next 10 years. Every time we introduce a
new scheme, we introduce one more combination that'll need to be
supperted.

To expand on b): we don't really to do anything *new*. It's mostly
about stopping to do things or changing some setting from one value
to another. In particular, Anaconda needs to *lose* a feature where it
refuses VFAT for /boot [1], the various places which create partitions
need to be modified to inject the right partition-type UUID instead of
made-up one, and instead of creating two partitions with different fs
types, create just one. None of this is rocket science. I don't
understand why this needs to be dragged out over multiple years. If
we're already touching this code, it would be really great to make
some real progress, instead of doing the minimal thing that delivers
minimal progress.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2106706

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Aoife Moloney]

https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Owner ==
* Name: [[User:Otaylor|Owen Taylor]]
* Email: otay...@redhat.com


== Detailed Description ==
There are two types of Flatpak containers -
runtimes - which contain unmodified Fedora packages,
and applications - which contain Fedora packages rebuilt to relocate
them from /usr to /app.
Currently, the rebuild process is done using modules -
packages are either rebuilt in a shared flatpak-common module, or in a
module specific to the application.
This change replaces this with a separate build target that all
rebuilds are done in.

=== Rebuilding RPMs ===
For each Fedora release, we'll have two additional targets

 f39-flatpak-runtime (inherits f39), tags: f39-flatpak-runtime-build,
f39-flatpak-runtime
 f39-app (inherits f39-flatpak-runtime), tags: f39-app-build, f39-app

The f39-flatpak-runtime target has a limited use -
it's used to build packages that go into the Flatpak runtimes
(standard and KDE).
This would include flatpak-runtime-config, flatpak-rpm-macros,
but also rebuilds of standard packages if needed to prune dependencies:
currently this is done for gstreamer-plugins-good.

The f39-app target is the main target that is used for prefix=/app rebuilds.
flatpak-rpm-macros is part of the build group for this target,
resulting in builds that target /app.
As currently, spec files can be conditionalized with '%if 0%{?flatpak}'

Builds in f39-flatpak-runtime and f39-app have the dist tags
.f39runtime and .f39app respectively.
This is necessary so that we can automatically rebuild a package
without having to bump the release in the specfile.
(Koji requires everything to have a unique NVR.)
It also allows humans and tools to easily distinguish these specialized builds.

Any Fedora packager can rebuild a package into f39-app using 'fepdkg
build --target=f39-app'.
There will also be a new convenience subcommands of fedpkg 'fedpkg
build-flatpak-rpms',
'fedpkg build-flatpak-rpms-local' that can be used to rebuild all
missing bundled dependencies of a Flatpak,
in Koji or locally.

Once a package exists in f39-app or f38-app, then
[[https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync
distrobuildsync]] will be used to do a build into f39-app each time a
standard build completes.

=== Container Versioning ===

Currently, the version is based on the module version:

  firefox:stable:3820230427145713:b1edb643 =>
firefox-stable-3820230427145713.b1edb643

Where the module version is created from platform versions and git
commit timestamps
for the module repository.
We could reproduce something very much like this based on the runtime branch and
git commit timestamp, but since application Flatpaks have an
identifiable "Main RPM"
(unlike the general case of modules and containers), a better scheme is:

  firefox-112.0.2-1.fc38 => firefox-flatpak-112.0.2-1
  name: main RPM name + -flatpak
  version: main RPM version
  release: automatically incremented based on existing Koji builds

Because upgrades are done on Flatpak ID (org.mozilla.Firefox),
there is no compatibility impact of switching Flatpaks from 'firefox'
to 'firefox-flatpak'.

There is considerable implementation complexity within OSBS to implement this,
because the N/V/R need to be written into generated Dockerfile as
labels ''before'' building it,
but it should be manageable. If not, we'll need to switch to a different scheme.
(Running dnf with --best when building the container will
help make this reliable
and would be a general improvement.)

=== Updates ===

The current plan is that builds of RPMs will be tagged directly into f39-app and
containers will be composed from the contents of  f39-app with no
involvement of Bodhi.
Bodhi is only involved in releasing the container.

We can add CI checks on container updates to compare the rebuilt
packages in the container
to the latest released versions for Fedora, though it's not always
easy to distinguish:

* Newer because of a RPM change that hasn't passed testing yet
* vs. Newer because a spec file was needed to get the package to
rebuild with prefix=/app

Since Fedora does not embargo builds,
there's no potential information leak if a change to dist-git is
released via container before it is released by RPM.

=== Disadvantages and issues===
In moving to this system, we lose the ability to take advantage of the
capabilities of modularity -
to use a different stream branch of a library for an application than
the one shipped in F39, say.
There are essentially no examples of this being used in all the
Flatpaks created for Fedora over the last 5 years,
probably because modularity has gained little traction within Fedora
more broadly.

Some Flatpak modules strip down bundled 

Re: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

[Jarek Prokop]

On 5/9/23 21:27, DJ Delorie wrote:

Jarek Prokop  writes:

Are the libffi/rebuilt packages available anywhere for us to
experiment with?

MPB uses COPR, so..

"before" 
builds:https://copr.fedorainfracloud.org/coprs/djdelorie/libffi-3.4.4.checker/
"after" builds:https://copr.fedorainfracloud.org/coprs/djdelorie/libffi-3.4.4/

Great! Thanks for the links, I've done manual testing with the reproducer:
~~~
require 'fiddle/closure'
require 'fiddle/struct'

Fiddle::Closure.new(Fiddle::TYPE_VOID, [])

fork { }

GC.start
~~~

And with the copr build of libffi 3.4.4-3 , Ruby indeed no longer 
crashes on this code.





We have a reasonably reliable reproducer in Ruby [0] (also included in
commit message [1]), but it is not executed as part of test suite,

Yes, fork-without-exec case is a known "that should never have worked"
case that only happens to work when your closure's backing store is also
forked, which file-based mappings are *not*.  You need either really old
(rwx mmap, which security disables) or really new (static trampolines,
which are r-x/rw- mmap'ed) libffi to support that.  Hopefully that means
your reproducers should not reproduce with the new libffi.


Moreover, rebuild with current Ruby specfiles won't tell you much as
we commented out the tests [2] to have less flaky builds. I'd
recommend uncommenting the lines and run 5 to 10 builds (or just run
any of the 2 reproducers).

Well, if you comment out the tests, I have no way of knowing I broke
anything, so have to rely on posting Change Requests and letting you let
me know ;-)

And it is great to see :)

Not saying you did anything wrong; if you have tests that pass or fail
depending on system configurations outside your control, it's difficult
to reliably test what you want to test.  I'm just saying that when you
disable tests, automated processes have no insight into those failures.
We are aware of this downside :/, we worked with relevant upstream, but 
a proper fix on the side of rubygem-fiddle would require nontrivial rewrite.
(rubygem-ffi conversely has a closure pool that, AFAICT, prevents the 
issue altogether.)


This was a long-running issue (read: spanning a few Fedora releases) and 
doing a rebuild 10 times to have 1 not segfault and go through the rest 
of the pipeline just for a teeny version rebase got really tiring.


Thanks,
Jarek Prokop___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] Fedora 39 Rawhide 20230510.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 39 Rawhide 20230510.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20230507.n.0: anaconda-39.12-1.fc39.src, 20230510.n.0: 
anaconda-39.14-1.fc39.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/39

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230510.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230510.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230510.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230510.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230510.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230510.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230510.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: it builds in copr epel-9 (with RHEL-9) but fail to build on koji

[Sérgio Basto]

On Wed, 2023-05-10 at 09:44 +0200, Petr Pisar wrote:
> V Tue, May 09, 2023 at 09:20:30PM +0100, Sérgio Basto napsal(a):
> > I tested with Centos Stream 9.
> > xvfb-run have been fixed somehow in Centos Stream first,
> 
> CentOS Stream is a preview of the next RHEL minor release. It works
> as
> designed.
> 
> > any idea how xvfb-ruu was fixed ? I'd like understand the part of
> > running
> > graphics tests in the koji build why we got the segfault with
> > 1.20.11-
> > 11.el9 and now with 1.20.11-17.el9 not ? if there is a simple
> > explanation ?
> > 
> Read the RPM package changelog.
> 

yeah, may be is this one 

* Wed Jan 26 2022 Adam Jackson  - 1.20.11-8
- Only disable the PCI-specific driver probe, since we do still want
fallback
to fbdev to work.
Resolves: #2029769

https://bugzilla.redhat.com/show_bug.cgi?id=2029769


> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

[Jens-Ulrik Petersen]

On Wed, May 10, 2023 at 3:13 AM DJ Delorie  wrote:

> Jens-Ulrik Petersen  writes:
> MPB uses BuildRequires to collect all packages that *might* be affected
> by your change.  It builds all those packages with and without your
> change, and lets you know what you broke.  In this case, one broke (cjs,
> since fixed), ten didn't build before my change anyway[*], and the rest
> were OK.  So if your package doesn't already FTBFS, you're good.
>

Okay thanks for the clarification and explanations.
(I got now that by "affected packages" you didn't mean "failed":)

"after" builds:
> https://copr.fedorainfracloud.org/coprs/djdelorie/libffi-3.4.4/


Okay I was already aware of all the ghc failures: mostly due to the new
sphinx version in Rawhide
(which I had already fixed for ghc9.4). So it looks fine from my pov so
far, thanks.
I have just now pushed fixes for all ghc*, so can you try to rebuild them
again in your repo?
Jens
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Zbigniew Jędrzejewski-Szmek]

On Wed, May 10, 2023 at 12:21:51PM +0800, Jens-Ulrik Petersen wrote:
> Thanks for all the helpful comments and feedback,
> though more is still welcome of course.
> So I am leaning now towards not installing fedora-repos-modular by default
> (rather than disabling the modular repos by default): also for upgrade
> compatibility.
> 
> I have started a Change proposal draft, which I think should be ready soon,
> with current working title *"Turn off modular dnf repos by default"*.
> Perhaps *"No default fedora-repos-modular"* would be more precise.
> Or any better suggestions (that don't sound like modularity is being
> removed)?

"No fedora-repos-modular in default installation" ?

> I think the actual work (PR's) required is not huge,
> but if someone is particularly keen to join the effort let me know.

The discussion is the work ;)

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Summary/Minutes from today's FESCo Meeting (2023-05-09)

[Zbigniew Jędrzejewski-Szmek]

On Wed, May 10, 2023 at 01:26:37AM +0200, Kevin Kofler via devel wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > * #2989 Proposal to adjust Changes Policy to use Fedora Discussion
> >   instead of the devel list   (zbyszek, 17:03:21)
> >   * AGREED: APPROVED (+6, 0, 0):
> > Subsequent Fedora Changes for F40 and later will be discussed on
> > discussions.fedoraproject.org
> 
> So here we go, Discourse is now being forced on us despite all the 
> overwhelmingly negative feedback in the thread. 

Nope, that is actually not true. Matthew posted some stats in the
fesco ticket [1], and the stats were fairly evenly split
(supportive or open, neutral, opposed or concerned). In fact,
"opposed" is the least popular option.

You may note that what we're doing now (or in two weeks really) is to
only move Change discussion. This is very much a *trial*, the great
majority of use of fedora-devel will continue as it was.

[1] https://pagure.io/fesco/issue/2989

> I really wonder why feedback is being asked for at all. It seems to
> be just a way to make it LOOK like we are in some kind of
> democracy. In reality, the decisions are already made before the
> thread is even started.

You keep repeating this. It is tiring. It is also very much false.

*I* am quite sure that the six people who voted yesterday in the FESCo
meeting are doing their best for Fedora, the project and the community.
Various votes may go different ways and I may at times vehemently disagree
with some of the decisions, but even then, I'm certain of the good intent.

> So now you are forcing change feedback to go through an inconvenient 
> mechanism in the hope to prevent it from coming up to begin with, so you do 
> not have to so blatantly ignore it.

You lost me here.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Gerd Hoffmann]

> > /boot/efi is clearly not ideal for a number of reasons, but this is what
> > we have today and changing this opens up another can of worms.  For
> > starters this will stop working:
> > 
> > # rpm -ql shim-x64
> > /boot/efi/EFI/BOOT/BOOTX64.EFI
> > /boot/efi/EFI/BOOT/fbx64.efi
> > /boot/efi/EFI/fedora/BOOTX64.CSV
> 
> That's actually an anti-feature that needs to go. Packages should not
> use rpm to put files directly in /boot. Systemd doesn't do this, the
> kernel doesn't do this (except for %ghost files). grub2 does some
> directories, but thankfully no files,

Nope:

# rpm -ql grub2-efi-x64 | grep EFI
/boot/efi/EFI/fedora/grub.cfg
/boot/efi/EFI/fedora/grubx64.efi

Only systemd-boot gets this right today, with files packaged in /usr and
bootctl updating the ESP.  Oh, and fwupd handles it correctly too.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: it builds in copr epel-9 (with RHEL-9) but fail to build on koji

[Petr Pisar]

V Tue, May 09, 2023 at 09:20:30PM +0100, Sérgio Basto napsal(a):
> I tested with Centos Stream 9.
> xvfb-run have been fixed somehow in Centos Stream first,

CentOS Stream is a preview of the next RHEL minor release. It works as
designed.

> any idea how xvfb-ruu was fixed ? I'd like understand the part of running
> graphics tests in the koji build why we got the segfault with 1.20.11-
> 11.el9 and now with 1.20.11-17.el9 not ? if there is a simple
> explanation ?
> 
Read the RPM package changelog.

-- Petr


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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Type-Tiny] PR #1: Add conditions for build with/without big frameworks

[Ralf Corsépius]

corsepiu commented on the pull-request: `Add conditions for build with/without 
big frameworks` that you are following:
``
I am hesitant, because I fail to understand the rationale behind it and am 
close to consider it "featuritis".


``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Type-Tiny/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Type-Tiny] PR #1: Add conditions for build with/without big frameworks

[Michal Josef Špaček]

mspacek commented on the pull-request: `Add conditions for build with/without 
big frameworks` that you are following:
``
@corsepiu Is it ok for you or not? :-)
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Type-Tiny/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2196756] perl-Class-Autouse-2.01-34.fc39 FTBFS: Can't locate inc/Module/Install/DSL.pm

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2196756



--- Comment #2 from Jitka Plesnikova  ---
*** Bug 2196757 has been marked as a duplicate of this bug. ***


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2196756
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2196757] perl-Class-Autouse: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2196757

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |DUPLICATE
Last Closed||2023-05-10 06:58:57



--- Comment #2 from Jitka Plesnikova  ---


*** This bug has been marked as a duplicate of bug 2196756 ***


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2196757
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2196756] perl-Class-Autouse-2.01-34.fc39 FTBFS: Can't locate inc/Module/Install/DSL.pm

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2196756

Jitka Plesnikova  changed:

   What|Removed |Added

 CC||jples...@redhat.com



--- Comment #1 from Jitka Plesnikova  ---
I created a pull request with a possible fix:
https://src.fedoraproject.org/rpms/perl-Class-Autouse/pull-request/1


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2196756
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2196757] perl-Class-Autouse: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2196757



--- Comment #1 from Jitka Plesnikova  ---
I created a pull request with a possible fix:
https://src.fedoraproject.org/rpms/perl-Class-Autouse/pull-request/1


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2196757
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2196757] New: perl-Class-Autouse: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2196757

Bug ID: 2196757
   Summary: perl-Class-Autouse: FTBFS: Can't locate
inc/Module/Install/DSL.pm in @INC
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-Class-A
utouse
OS: Linux
Status: NEW
 Component: perl-Class-Autouse
  Severity: medium
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: lkund...@v3.sk, lxt...@gmail.com,
perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



Description of problem:
Package perl-Class-Autouse fails to build from source in Fedora Rawhide.

Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the
inc::Module::Install::DSL module) (@INC contains: /usr/local/lib64/perl5/5.36
/usr/local/share/perl5/5.36 /usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at Makefile.PL
line 1.
BEGIN failed--compilation aborted at Makefile.PL line 1.


It is caused by updating perl-Module-Install to version >= 1.20.
Module::Install::DSL has been removed in version 1.20.


Version-Release number of selected component (if applicable):
2.01-34.fc38

Steps to Reproduce:
koji build --scratch f39 perl-Class-Autouse-2.01-34.fc38.src.rpm

Additional info:
This package is tracked by Koschei. See:
https://koschei.fedoraproject.org/package/perl-Class-Autouse

Reproducible: Always


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2196757
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2196756] perl-Class-Autouse-2.01-34.fc39 FTBFS: Can't locate inc/Module/Install/DSL.pm

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2196756

Petr Pisar  changed:

   What|Removed |Added

 Blocks||2168842
   ||(F39FTBFS,RAWHIDEFTBFS)





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2168842
[Bug 2168842] Fedora 39 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2196756
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2196756] New: perl-Class-Autouse-2.01-34.fc39 FTBFS: Can't locate inc/Module/Install/DSL.pm

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2196756

Bug ID: 2196756
   Summary: perl-Class-Autouse-2.01-34.fc39 FTBFS: Can't locate
inc/Module/Install/DSL.pm
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-Class-A
utouse
OS: Linux
Status: NEW
 Component: perl-Class-Autouse
  Severity: medium
  Assignee: rc040...@freenet.de
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: lkund...@v3.sk, lxt...@gmail.com,
perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



perl-Class-Autouse-2.01-34.fc39 fails to build in Fedora 39:

+ /usr/bin/perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 NO_PERLLOCAL=1
Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the
inc::Module::Install::DSL module) (@INC contains: /usr/local/lib64/perl5/5.36
/usr/local/share/perl5/5.36 /usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at Makefile.PL
line 1.
BEGIN failed--compilation aborted at Makefile.PL line 1.
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.2aG8mg (%build)

This is triggered by upgrading perl-Module-Install from 1.19-24.fc38 to
1.21-1.fc39:

Changes for Perl programming language extension Module-Install

1.21  2023-04-28
  - fix tests broken by Module::Install::DSL removal

1.20  2023-04-27
  - Module::Install::DSL has been removed, as its use is highly discouraged.

Reproducible: Always


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2196756
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Class-Autouse] PR #1: Update Makefile.PL to not use Module::Install::DSL

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-Class-Autouse` 
that you are following:
``
Update Makefile.PL to not use Module::Install::DSL
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Class-Autouse/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2113577] perl-IO-Async: FTBFS in Fedora rawhide/f37: t/70future-io.t fails: Nothing was ready after 10 second wait; called at /builddir/build/BUILD/IO-Async-0.801/blib/lib/IO/Async/Test.pm line 2

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2113577

Petr Pisar  changed:

   What|Removed |Added

Summary|perl-IO-Async: FTBFS in |perl-IO-Async: FTBFS in
   |Fedora rawhide/f37  |Fedora rawhide/f37:
   ||t/70future-io.t fails:
   ||Nothing was ready after 10
   ||second wait; called at
   ||/builddir/build/BUILD/IO-As
   ||ync-0.801/blib/lib/IO/Async
   ||/Test.pm line 214
 CC||ppi...@redhat.com



--- Comment #5 from Petr Pisar  ---
From a build.log:

t/64handle-bind.t  ok
Nothing was ready after 10 second wait; called at
/builddir/build/BUILD/IO-Async-0.801/blib/lib/IO/Async/Test.pm line 214
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 3.
t/70future-io.t .. 
Dubious, test returned 255 (wstat 65280, 0xff00)
All 3 subtests passed


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2113577
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2196755] perl-IO-Async-0.802-2.fc39 FTBFS: A build dependency on Test::Future::IO::Impl is not declared

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2196755

Petr Pisar  changed:

   What|Removed |Added

 Blocks||2168842
   ||(F39FTBFS,RAWHIDEFTBFS)





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2168842
[Bug 2168842] Fedora 39 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2196755
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2196755] New: perl-IO-Async-0.802-2.fc39 FTBFS: A build dependency on Test::Future::IO::Impl is not declared

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2196755

Bug ID: 2196755
   Summary: perl-IO-Async-0.802-2.fc39 FTBFS: A build dependency
on Test::Future::IO::Impl is not declared
   Product: Fedora
   Version: rawhide
OS: Linux
Status: NEW
 Component: perl-IO-Async
  Severity: medium
  Assignee: emman...@seyman.fr
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, kwiz...@gmail.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



perl-IO-Async-0.802-2.fc39 fails to build in Fedora 39 because a test fails:

t/64handle-bind.t  ok
Can't locate Test/Future/IO/Impl.pm in @INC (you may need to install the
Test::Future::IO::Impl module)
 (@INC contains: /builddir/build/BUILD/IO-Async-0.802/blib/lib
/builddir/build/BUILD/IO-Async-0.802/bli
b/arch /usr/local/lib64/perl5/5.36 /usr/local/share/perl5/5.36
/usr/lib64/perl5/vendor_perl /usr/share/
perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at t/70future-io.t line
9.
BEGIN failed--compilation aborted at t/70future-io.t line 9.
t/70future-io.t .. 
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 

It seems that a spec file is missing a build dependency on that module.

This failure is triggered by upgrading perl-Future-IO from 0.13-1.fc39 to
0.14-1.fc39:

Revision history for Future-IO

0.142023-04-25
[CHANGES]
 * Moved `Test::Future::IO::Impl` into its own distribution, so that
   downstream packages don't have to runtime-depend on `Test2`

Reproducible: Always


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2196755
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue