Fedora eln compose report: 20250121.n.0 changes

[Fedora ELN Report]

OLD: Fedora-eln-20250120.n.0
NEW: Fedora-eln-20250121.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   29
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   7.74 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  cinnamon-6.4.6-3.eln145
Old package:  cinnamon-6.4.6-1.eln145
Summary:  Window management and application launching for GNOME
RPMs: cinnamon
Size: 7.74 MiB
Size change:  77.41 KiB
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering  - 
6.4.6-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Mon Jan 20 2025 Leigh Scott  - 6.4.6-3
  - Add recommends tuned-ppd for power applet power levels


Package:  coreutils-9.6-1.eln145
Old package:  coreutils-9.5-12.eln145
Summary:  A set of basic GNU tools commonly used in shell scripts
RPMs: coreutils coreutils-common coreutils-single
Size: 15.81 MiB
Size change:  957.17 KiB
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering  - 
9.5-13
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Mon Jan 20 2025 Luk Zaoral  - 9.6-1
  - rebase to latest upstream version (rhbz#2338620)
  - sync i18n patch with SUSE (Kudos to Berny V??lker!)


Package:  dotnet8.0-8.0.112-1.eln145
Old package:  dotnet8.0-8.0.111-2.eln144
Summary:  .NET Runtime and SDK
RPMs: aspnetcore-runtime-8.0 aspnetcore-runtime-dbg-8.0 
aspnetcore-targeting-pack-8.0 dotnet-apphost-pack-8.0 dotnet-hostfxr-8.0 
dotnet-runtime-8.0 dotnet-runtime-dbg-8.0 dotnet-sdk-8.0 
dotnet-sdk-8.0-source-built-artifacts dotnet-sdk-dbg-8.0 
dotnet-targeting-pack-8.0 dotnet-templates-8.0
Size: 2.74 GiB
Size change:  1.81 MiB
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering 
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Thu Jan 16 2025 Omair Majid  - 8.0.112-1
  - Update to .NET SDK 8.0.112 and Runtime 8.0.12


Package:  dotnet9.0-9.0.102-1.eln145
Old package:  dotnet9.0-9.0.101-2.eln144
Summary:  .NET Runtime and SDK
RPMs: aspnetcore-runtime-9.0 aspnetcore-runtime-dbg-9.0 
aspnetcore-targeting-pack-9.0 dotnet-apphost-pack-9.0 dotnet-host 
dotnet-hostfxr-9.0 dotnet-runtime-9.0 dotnet-runtime-dbg-9.0 dotnet-sdk-9.0 
dotnet-sdk-9.0-source-built-artifacts dotnet-sdk-aot-9.0 dotnet-sdk-dbg-9.0 
dotnet-targeting-pack-9.0 dotnet-templates-9.0 netstandard-targeting-pack-2.1
Size: 2.63 GiB
Size change:  9.62 MiB
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering  - 
9.0.101-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Thu Jan 16 2025 Omair Majid  - 9.0.102-1
  - Update to .NET SDK 9.0.102 and Runtime 9.0.1


Package:  edk2-20241117-9.eln145
Old package:  edk2-20241117-5.eln144
Summary:  UEFI firmware for 64-bit virtual machines
RPMs: edk2-aarch64 edk2-ovmf edk2-tools edk2-tools-doc
Size: 12.62 MiB
Size change:  -113.03 KiB
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering  - 
20241117-6
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Mon Jan 20 2025 Gerd Hoffmann  - 20241117-7
  - add copr build id to release

  * Mon Jan 20 2025 Gerd Hoffmann  - 20241117-8
  - openssl update

  * Mon Jan 20 2025 Gerd Hoffmann  - 20241117-9
  - gcc-15 fixes


Package:  glibc-2.40.9000-30.eln145
Old package:  glibc-2.40.9000-28.eln145
Summary:  The GNU libc libraries
RPMs: glibc glibc-all-langpacks glibc-benchtests glibc-common 
glibc-devel glibc-doc glibc-gconv-extra glibc-langpack-aa glibc-langpack-af 
glibc-langpack-agr glibc-langpack-ak glibc-langpack-am glibc-langpack-an 
glibc-langpack-anp glibc-langpack-ar glibc-langpack-as glibc-langpack-ast 
glibc-langpack-ayc glibc-langpack-az glibc-langpack-be glibc-langpack-bem 
glibc-langpack-ber glibc-langpack-bg glibc-langpack-bhb glibc-langpack-bho 
glibc-langpack-bi glibc-langpack-bn glibc-langpack-bo glibc-langpack-br 
glibc-langpack-brx glibc-langpack-bs glibc-langpack-byn glibc-langpack-ca 
glibc-langpack-ce glibc-langpack-chr glibc-langpack-ckb glibc-langpack-cmn 
glibc-langpack-crh glibc-langpack-cs glibc-langpack-csb glibc-langpack-cv 
glibc-langpack-cy glibc-langpack-da glibc-langpack-de glibc-langpack-doi 
glibc-langpack-dsb glibc-langpack-dv glibc-langpack-dz glibc-langpack-el 
glibc-langpack-en glibc-langpack-eo glibc-langpack-es glibc-langpack-et 
glibc-langpack-eu glibc-langpack-fa glibc-langpack-ff glibc-langpack-fi 
glibc-langpack-fil glibc-langpack-fo glibc-langpack-fr glibc-langpack-fur 
glibc-langpack-fy glibc-langpack-ga glibc-langpack-gd glibc-langpack-gez 
glibc-langpack-gl glibc-langpack-gu

Re: Proposal for vendoring/bundling golang packages by default

[Florian Weimer]

* Mikel Olasagasti:

> Go-SIG has raised a ticket with FESCo [1] to propose a significant
> shift in Fedora's packaging approach for Go dependencies: moving to
> vendoring/bundling by default. This would represent a major departure
> from our current guidelines [2].

> [1] https://pagure.io/fesco/issue/3330
> [2] 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_bundled_or_unbundled

What's the benefit of vendoring over a build system that supports
offline builds against un-vendored dependencies?

I expect Konflux  to have this capability
(although the documentation is a bit buzzword-heavy, so it's hard to
tell whether it's actually included).  There's a Fedora SIG for it:


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

Build order

[Vít Ondruch]

Dne 18. 01. 25 v 11:01 Mattia Verga via devel napsal(a):

I have an idea I'd like to hear you out on how to reduce failures on
mass rebuilds.

I think some of the build failures are due to building things out of
sequence. I mean, package A buildrequires package B, but since the mass
rebuild is performed (AFAIK) alphabetically, package B is rebuilt after,
so package A rebuild may fail.

The optimal solution would be to have some script that periodically
creates a tree of buildrequires dependency for all Fedora packages...
but that would require some work. So, I was just thinking, what about to
set up a simple repository where we put some text files like:

- tier1.txt:
      - libindi
      - kpmcore

- tier2.txt:
      - indi-3rdparty-libraries

(possibly a tier3.txt too)

On mass rebuilds, all packages specified in tier1.txt are rebuilt first,
then all packages in tier2.txt (and so on), then all other packages like
the current mass rebuild does.
In my example this would mean that the correct sequences on rebuild are
maintained:

- T1: libindi -> T2: indi-3rdparty-libraries -> mass rebuild:
indi-3rdparty-drivers (and kstars, stellarium, etc.)
- T1: kpmcore -> mass rebuild: kde-partitionmanager

I think this could be a simple and quick solution to maintain build
chains on mass rebuilds. Thoughts?



While I am not sure this is strictly needed for mass rebuild, having 
build order is generally useful. In modular days, we were able to 
specify the build order:


https://docs.fedoraproject.org/en-US/modularity/building-modules/fedora/defining-modules/#_building_in_a_specific_order_optional

I also know the Mikolaj has some tooling for defining build order, which 
he use for Maven rebuilds:


https://github.com/mizdebsk/mbici-workflow/?tab=readme-ov-file#build-plan

While we never had any metadata, build order was also required for 
Software Collections for those who remember.


Just FTR, working on Ruby on Rails 8 for Fedora, possibility to have 
build order specified would help with the rebuilds as well as bootstraps.



Vít



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

Re: Proposal for vendoring/bundling golang packages by default

[Daniel P . Berrangé]

On Mon, Jan 20, 2025 at 11:29:55AM +0100, Michael J Gruber wrote:
> Mikel Olasagasti venit, vidit, dixit 2025-01-20 08:02:18:
> > Hi,
> > 
> > Go-SIG has raised a ticket with FESCo [1] to propose a significant
> > shift in Fedora's packaging approach for Go dependencies: moving to
> > vendoring/bundling by default. This would represent a major departure
> > from our current guidelines [2].
> > 
> > Given the potential impact, it was suggested that we bring this topic
> > to the devel-list for broader input and an open discussion.
> > 
> > The rationale for this proposal stems from the increasing challenges
> > in maintaining Go dependencies under the current model, including
> > issues with timely reviews, dependency management, and the impact of
> > some "core" orphaned packages. Allowing vendoring by default could
> > help alleviate these bottlenecks and improve the stability of Go-based
> > packages in Fedora.
> 
> I understand that these are challenges, and they are increasing because
> there are so many upcoming ecosystems which build their own distribution
> channels and tools, be it Go, Rust, Julia, even Python to some degree
> (think pip, conda and the like).
> 
> And indeed, as Jan's reply shows, once we allow bundling in general for
> one language people will want it for other language ecosystems, and
> "rightly" so, at least as long as the same reasoning applies.

Yes, I think we should apply the logic consistently across languages.
They might not have all reached the same point of frustration, but
the challenges are clearly common across many of these languages which
are dealing with non-ELF packages with upstream bundling or locked
dep versions as the default.

> Following the Go-SIG proposal would be the can-opener to deviate from
> our distribution model in general. I mean, if I can pull in a myriad of
> Go or Rust modules for my package to build (without individual review or
> re-review in case of changed dependencies), then why should I bother
> unbundling a library such as zlib, regex, openssl, ... ?

IMHO comparing/equating these non-C/non-ELF language modules, to traditional
ELF libraries was/is a mistake.

The biggest difference is simply one of granularity. A non-trivial ELF
library will provide 1000's of APIs across a vast range of functionality
in a single library. In these non-C languages, modules are often incredibly
small just providing a handful of APIs. IOW, functionality that was a
single ELF library, may be spread across 100's of python/go/rust modules.

This granularity then feeds the other problems and/or design approaches.
Many deps are fast moving with a somewhat more relaxed approach to API
compat than traditional ELF libraries. With 100's of deps, fixing on
specific versions quickly becomes requirement to get a stable foundation
for the app which can be tested without deps changes breaking stuff too
often.

Fedora went down the route of applying our existing unbundling practices
from ELF libraries across these non-C ecosystems for various good reasons,
but this level of module granularity & differing attitudes to the module
API lifecycle is drowning the distro maintainers in work. At the same
time it risks delivering something which is of worse quality than that
from upstream, because our versions won't  match what upstream has
validated in their CI systems.

IMHO it is right to ask whether we have the right trade-off here.

We rely on the heroics of small numbers of SIG members to keep this all
working, and when key members of the SIGs change their focus it is at
risk of falling apart. See NodeJS, or Java ecosystem changes in Fedora.
This isn't a sustainable model. Any 3rd parties who want to build on top
of what Fedora ships have a foundation that could collapse with any new
major Fedora release.

It is no surprise that application developers have embraced containers as
a delivery mechanism in a way that they rarely embraced distros directly
in the past. 

If we spent less time unbundling all these non-ELF modules, our maintainers
would be freed up to work on other things that could potentially be more
beneficial Fedora users.



That isn't to say Fedora's process is without value. There are key parts
of our review process that are critically beneficial. Most notabley license
scanning has had clear benefits both to Fedora and the upstreams, with
many problems uncovered & fixed over the years. Fedora & upstream aligned
in their desirables in this case (mostly), so it has been a success.

With unbundling by contrast, Fedora & upstreams are essentially completely
non-aligned, and I can't see that changing - all signs are that we are
getting further apart for non-infrastructure components of the OS in the
non-C/ELF world.

The biggest challenge with bundling is the constraint it imposes on our
ability to deliver security fixes. Identifying the existance flawed code
can be automated to a reasonable degree since we have metadata to track
what bundled versions exist. It is t

Fedora rawhide compose report: 20250120.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20250119.n.0
NEW: Fedora-Rawhide-20250120.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  3
Dropped packages:0
Upgraded packages:   96
Downgraded packages: 0

Size of added packages:  900.56 KiB
Size of dropped packages:0 B
Size of upgraded packages:   2.33 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20250120.n.0.iso

= DROPPED IMAGES =
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20250119.n.0.iso

= ADDED PACKAGES =
Package: freetalk-4.2-1.fc42
Summary: Terminal XMPP client
RPMs:freetalk
Size:379.55 KiB

Package: qarma-1.0.0-1.fc42
Summary: Tool for creating Qt dialog boxes
RPMs:qarma
Size:414.61 KiB

Package: rust-x509-parser-0.16.0-1.fc42
Summary: Parser for the X.509 v3 format (RFC 5280 certificates)
RPMs:rust-x509-parser+default-devel rust-x509-parser+ring-devel 
rust-x509-parser+validate-devel rust-x509-parser+verify-devel 
rust-x509-parser-devel
Size:106.40 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  2048-cli-0.9.1-23.fc42
Old package:  2048-cli-0.9.1-21.fc41
Summary:  The game 2048 for your Linux terminal
RPMs: 2048-cli 2048-cli-nocurses 2048-cli-sdl
Size: 246.02 KiB
Size change:  -1.39 KiB
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering  - 
0.9.1-22
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Sun Jan 19 2025 Bj??rn Esser  - 0.9.1-23
  - Add patch to properly #include where needed
  - Add patch to fix -Wformat
  - Drop old cruft from spec file


Package:  R-date-1.2.42-1.fc42
Old package:  R-date-1.2.39-16.fc41
Summary:  Functions for Handling Dates
RPMs: R-date
Size: 294.24 KiB
Size change:  -3.97 KiB
Changelog:
  * Mon Jul 29 2024 Miroslav Such??  - 1.2.39-17
  - convert license to SPDX

  * Thu Jan 16 2025 Fedora Release Engineering  - 
1.2.39-18
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Sun Jan 19 2025 Elliott Sales de Andrade  - 
1.2.42-1
  - Update to latest version


Package:  R-gee-4.13.29-1.fc42
Old package:  R-gee-4.13.23-8.fc41
Summary:  Generalized Estimation Equation Solver
RPMs: R-gee
Size: 274.80 KiB
Size change:  -1.42 KiB
Changelog:
  * Mon Jul 29 2024 Miroslav Such??  - 4.13.23-9
  - convert license to SPDX

  * Thu Jan 16 2025 Fedora Release Engineering  - 
4.13.23-10
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Sun Jan 19 2025 Elliott Sales de Andrade  - 
4.13.29-1
  - Update to latest version


Package:  R-mapproj-1.2.11-1.fc42
Old package:  R-mapproj-1.2.8-8.fc41
Summary:  Map Projections
RPMs: R-mapproj
Size: 287.67 KiB
Size change:  -1.92 KiB
Changelog:
  * Wed Aug 07 2024 Miroslav Such??  - 1.2.8-9
  - convert license to SPDX

  * Thu Jan 16 2025 Fedora Release Engineering  - 
1.2.8-10
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Sun Jan 19 2025 Elliott Sales de Andrade  - 
1.2.8-12
  - Add Packit configuration

  * Sun Jan 19 2025 Elliott Sales de Andrade  - 
1.2.11-1
  - Update to latest version (#2138677)


Package:  R-pbdZMQ-0.3.13-1.fc42
Old package:  R-pbdZMQ-0.3.7-8.fc41
Summary:  Programming with Big Data -- Interface to ZeroMQ
RPMs: R-pbdZMQ
Size: 2.24 MiB
Size change:  -6.79 KiB
Changelog:
  * Mon Jul 29 2024 Miroslav Such??  - 0.3.7-9
  - convert license to SPDX

  * Thu Jan 16 2025 Fedora Release Engineering  - 
0.3.7-10
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Sun Jan 19 2025 Elliott Sales de Andrade  - 
0.3.7-13
  - Add Packit configuration

  * Sun Jan 19 2025 Elliott Sales de Andrade  - 
0.3.13-1
  - Update to latest version


Package:  R-ragg-1.3.3-1.fc42
Old package:  R-ragg-1.2.4-8.fc41
Summary:  Graphic Devices Based on AGG
RPMs: R-ragg
Size: 1.94 MiB
Size change:  320.99 KiB
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering  - 
1.2.4-9
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Sun Jan 19 2025 Elliott Sales de Andrade  - 
1.2.4-11
  - Add Packit configuration

  * Sun Jan 19 2025 Elliott Sales de Andrade  - 
1.3.3-1
  - Update to latest version (#2131070)


Package:  ansible-collection-ansible-netcommon-7.1.0-1.fc42
Old package:  ansible-collection-ansible-netcommon-6.1.3-1.fc42
Summary:  Ansible Network Collection for Common Code
RPMs: ansible-collection-ansible-netcommon 
ansible-collection-ansible-netcommon-doc
Size: 226.09 KiB
Size change:  422 B
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering  - 
6.1.3-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild


Package:  archlinux

Re: Proposal for vendoring/bundling golang packages by default

[Michael J Gruber]

Mikel Olasagasti venit, vidit, dixit 2025-01-20 08:02:18:
> Hi,
> 
> Go-SIG has raised a ticket with FESCo [1] to propose a significant
> shift in Fedora's packaging approach for Go dependencies: moving to
> vendoring/bundling by default. This would represent a major departure
> from our current guidelines [2].
> 
> Given the potential impact, it was suggested that we bring this topic
> to the devel-list for broader input and an open discussion.
> 
> The rationale for this proposal stems from the increasing challenges
> in maintaining Go dependencies under the current model, including
> issues with timely reviews, dependency management, and the impact of
> some "core" orphaned packages. Allowing vendoring by default could
> help alleviate these bottlenecks and improve the stability of Go-based
> packages in Fedora.

I understand that these are challenges, and they are increasing because
there are so many upcoming ecosystems which build their own distribution
channels and tools, be it Go, Rust, Julia, even Python to some degree
(think pip, conda and the like).

And indeed, as Jan's reply shows, once we allow bundling in general for
one language people will want it for other language ecosystems, and
"rightly" so, at least as long as the same reasoning applies.

Following the Go-SIG proposal would be the can-opener to deviate from
our distribution model in general. I mean, if I can pull in a myriad of
Go or Rust modules for my package to build (without individual review or
re-review in case of changed dependencies), then why should I bother
unbundling a library such as zlib, regex, openssl, ... ?

There is a second point to that, and that is Fedora as a development
platform (not just as an "app" platform). If we expect developers to
install dependencies of their project via the ecosystem tools (pip, ...)
locally (envs, containers) and "app packages" do the same during build
then it is time to change the fundamental approach to our distribution
and view it "merely" as a platform.

I don't mean to connotate "merely" negatively - but the proposed change
has impact overall, and we should *really want it* as a direction to go
in generally.

> If this proposal gains consensus, we could aim to implement the change
> as part of Fedora 43, with the development phase used for migration
> and retiring packages that may no longer fit within the updated
> framework.

How would packages "not fit"? By not bundling, i.e. by following our
packaging guidelines so far? To put it differently: Do you intend to
discourage/disallow "not bundling", or packaging dependencies?

> On a related note, I recently highlighted how the introduction of
> Golang 1.24 has caused significant breakage in over 200 packages [3],
> an issue that underscores the urgency of addressing these challenges.

How would bundling alleviate this issue? By assuming that all upstreams
have adjusted to Golang 1.24 already so that you don't have to wait for
package updates but just pull in with your package?

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

Re: A fix for the FTBFS issue with the jed text editor

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jan 19, 2025 at 02:49:36AM -0800, Loren M. Lang wrote:
> > > Steps to join the packager group:
> > > https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
> 
> I have gone through most of those steps now, though I think I still need
> to send an introduction email. Right now, I'm just working on developing
> a list of good quality contributions for buildling my credibility.

Hi Loren,

It sounds like you're on a good path. If you have have some
in-progress packaging work, please submit it. I'm one of packager
sponsors in Fedora and I'd be happy to sponsor you.

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: A fix for the FTBFS issue with the jed text editor

[Vít Ondruch]

Dne 19. 01. 25 v 11:49 Loren M. Lang napsal(a):

On Sun, Jan 19, 2025 at 07:16:57PM +0900, Mamoru TASAKA wrote:

Benson Muite wrote on 2025/01/19 19:04:

Hi Loren,

On Sun, Jan 19, 2025, at 12:50 PM, Loren M. Lang wrote:

I just noticed that jed was on the FTBFS list and was failing to build
on Fedora and due to be removed. I've created a fix that should resolve
the issue and put together a Pull Request for review here:

https://src.fedoraproject.org/rpms/jed/pull-request/1

I am not yet in the packagers group so I will need a sponsor to upload
it. Also, I am willing to take over maintainership of this package if it
is currently orphaned.


It does not seem to be orphaned, please contact the maintainer, most 
maintainers welcome a co-maintainer..

jed is marked in "List of long term FTBFS packages to be retired in 2 weeks"
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2P77TH7L3E63ODMWMMG23MIGFSL3IQTS/

Perhaps current maintainers are unresponsive.

Yes, and looking through the commit history, it doesn't look like
there's evidence of any regular maintainer going back years unless that
is Fedora Release Engineer. Actually, the bigger item is I'd like to be
subscribed to any events I'd need to respond to with issues.



To this particular issue, I think it should be enough to click the 
"watch" icon here:


https://src.fedoraproject.org/rpms/jed

Vít



  There isn't
much development needed with this package, but I would like to know how
to subscribe to the jed component on Bugzilla or other feed in case
there are future bugs that need to be resolved.

I also contributed a fix for apt-cacher-ng for a different FTBFS bug
last week that had been open for a couple of months. However, that
package does appear to have a maintainer that, while busy at times, is
responsive to help.


Please let me know what the next steps are.


Steps to join the packager group:
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/

I have gone through most of those steps now, though I think I still need
to send an introduction email. Right now, I'm just working on developing
a list of good quality contributions for buildling my credibility.

Thanks!


An informal guide:
https://jamezone.org/pleasure/software/Fedora/packager/


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

Re: tree-sitter build broke Emacs

[Fabio Valentini]

On Mon, Jan 20, 2025, 12:27 Andreas Schneider  wrote:

> On Wednesday, 15 January 2025 22:31:22 CET Jerry James wrote:
> > On Wed, Jan 15, 2025 at 2:34 AM Andreas Schneider 
> wrote:
> > > On Wednesday, 15 January 2025 01:06:19 CET Jerry James wrote:
> > > > Emacs is uninstallable in Rawhide due to a tree-sitter soname bump.
> > > > Are the tree-sitter maintainers planning to rebuild (quickly!) the
> > > > broken dependencies soon?  The mass rebuild is about to start...
> > >
> > > emacs and neovim already have been rebuilt.
> >
> > Thank you.  Would you please update tree-sitter, emacs, etc. in a side
> > tag next time?
>
> I just followed orders ...
>
> https://src.fedoraproject.org/rpms/tree-sitter/pull-request/2
>
> See also
> https://src.fedoraproject.org/rpms/tree-sitter/pull-request/3



"we could let the mass rebuild take care of it? It starts tomorrow."

yeah that is not good 😅

dependencies and rebuilds should all be done *before* the mass rebuild to
avoid followup failures due to FTI / FTBFS issues.

(see also discussion in the other mass rebuild related thread)

Fabio



>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 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: Proposal for vendoring/bundling golang packages by default

[Jan Drögehoff]

I'm generally in favor of this, especially since it would establish a status 
quo that could benefit other languages where the usual way of dealing with 
dependencies is incompatible with distributions.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: FTB due to 'too many arguments to function'

[Florian Weimer]

* Artur Frenszek-Iwicki:

>> indi-3rdparty-drivers:
>> error: expected ‘;’, identifier or ‘(’ before ‘bool’
>> Looks like the syntax 'typedef enum { FALSE, TRUE } bool;' is no more 
>> accepted, but searching in the net it was perfectly fine.
>
> Looking at the build logs, it seems that while a standard is explicitly
> provided for C++ sources (-std=gnu++14), this is not the case for C sources.
> GCC15 changed the default standard to gnu23, and the C23 standard made "bool"
> a keyword, so it's disallowed to define a custom type with the name "bool".

And this definition isn't really ABI-compatible with the one used by the
C++ sources.  I'm pretty sure this package is partially broken as a
result.

For a long time, we've warned about this:

…/indi-eqmod/align/chull.h:85:13: warning: type of ‘AddOne’ does not match 
original declaration [-Wlto-type-mismatch]
   85 | extern bool AddOne(tVertex p);
  | ^
…/indi-eqmod/align/chull/chull.c:416:6: note: return value type mismatch
  416 | bool AddOne(tVertex p)
  |  ^
…/indi-eqmod/align/chull/chull.c:416:6: note: type ‘bool’ should match type 
‘bool’
…/indi-eqmod/align/chull/chull.c:416:6: note: ‘AddOne’ was previously declared 
here
…/indi-eqmod/align/chull/chull.c:416:6: note: code may be misoptimized unless 
‘-fno-strict-aliasing’ is used
…/indi-eqmod/align/chull.h:76:14: warning: type of ‘faces’ does not match 
original declaration [-Wlto-type-mismatch]
   76 | extern tFace faces;
  |  ^
…/indi-eqmod/align/chull/chull.c:83:7: note: ‘faces’ was previously declared 
here
   83 | tFace faces  = NULL;
  |   ^

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

End of Life of github2fedmsg

[Michal Konecny via devel-announce]

Hi everyone,

as was already announced in Announcing Webhook To Fedora Messaging 
 
Fedora Infrastructure team is working on replacement of github2fedmsg 
 service. As the 
replacement is already deployed and users already had a few months to 
migrate to webhook2fedmsg we decided to say goodbye to github2fedmsg. 
The date that github2fedmsg will be decommissioned in fedora infra is 
3rd February.


If you are using github2fedmsg and didn’t migrate to webhook2fedmsg yet, 
please follow the steps in the previous announcement mentioned at the 
beginning of this article.


Following are the reasons for the replacement of github2fedmsg:
* Old codebase with not much test coverage
* Last version released 10 years ago
* Running on now EOL RHEL7 machine
* Last service still using deprecated fedmsg (fedmsg will go away with 
github2fedmsg)

* Support only for GitHub

On behalf of Fedora Infrastructure team,
Michal (zlopez)-- 
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
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: GCC 15 for Fedora 42 in a side-tag

[Justin Forbes]

On Wed, Jan 15, 2025 at 4:10 PM Jakub Jelinek  wrote:
>
> On Wed, Jan 15, 2025 at 12:53:29PM -0700, Justin Forbes wrote:
> > On Wed, Jan 15, 2025 at 11:51 AM Miro Hrončok  wrote:
> > >
> > > On 15. 01. 25 17:15, Zbigniew Jędrzejewski-Szmek wrote:
> > > > On Wed, Jan 15, 2025 at 05:06:47PM +0100, Karolina Surma wrote:
> > > >> Hi,
> > > >>
> > > >> My Python 3.14 builds have started pulling gcc 15 in Fedora Rawhide (no
> > > >> side-tag). Is this intentional?
> > > >
> > > > It seems so. 
> > > > https://bodhi.fedoraproject.org/updates/FEDORA-2025-920722dc45
> > > > is the update based on the side tag, and it is now stable.
> > >
> > > Once again, this landed out of nowhere and broke many packages, just in 
> > > time
> > > for the mass rebuild :(
> >
> > It broke kernel as well, I thought kernel was supposed to be tested
> > with a new toolchain before the toolchain was landed?
>
> Most likely it got put into the same bucket as all the other
> packages which aren't valid C23.
>
> Guess you want to wrap include/linux/stddef.h
> +#if __STDC_VERSION__ < 202311L
>  enum {
>  false   = 0,
>  true= 1
>  };
> +#endif
> and similarly in include/linux/types.h
> +#if __STDC_VERSION__ < 202311L
>  typedef _Bool   bool;
> +#endif
>
> Jakub


That certainly fixes some problems. We only fail on 3 arches now...
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Proposal for vendoring/bundling golang packages by default

[Stephen Smoogen]

On Mon, 20 Jan 2025 at 07:31, Florian Weimer  wrote:

> * Mikel Olasagasti:
>
> > Go-SIG has raised a ticket with FESCo [1] to propose a significant
> > shift in Fedora's packaging approach for Go dependencies: moving to
> > vendoring/bundling by default. This would represent a major departure
> > from our current guidelines [2].
>
> > [1] https://pagure.io/fesco/issue/3330
> > [2]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_bundled_or_unbundled
>
> What's the benefit of vendoring over a build system that supports
> offline builds against un-vendored dependencies?
>
> I expect Konflux  to have this capability
> (although the documentation is a bit buzzword-heavy, so it's hard to
> tell whether it's actually included).  There's a Fedora SIG for it:
> 
>
>
My guess is time. This is a proposal which could be implemented in a
release cycle and is fairly 'known' in what problems it would bring in. It
is not clear when konflux would be available in Fedora, how it would be
incorporated into the build system or a ton of other things which makes the
time to get it implemented into Fedora an 'unknown'.

Going from how long smaller components to the Fedora build system took in
maintenance, production and planning (pdc, various container building
systems which came and went, modularity, packagedb, etc) a large system
like Konflux would likely take multiple releases both to get into the
Fedora 'build flow' and into the developer workflows.




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


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Schedule for Tuesday's FESCo Meeting (2025-01-21)

[Kevin Fenzi]

Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org
on Matrix.

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

or run:
  date -d '2025-01-21 17:00 UTC'

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

= Discussed and Voted in the Ticket =

#3320 Switch to git core
https://pagure.io/fesco/issue/3320
Change is approved with the clarification that a proven packager will merge
all the pull requests which remain unanswered after 4 weeks. (+6, 0, -0)

= Followups =

None

= New business =

#3331 Schedule mass rebuilds in the end of January for even numbered Fedora (44 
and later) 
https://pagure.io/fesco/issue/3331

= Open Floor = 

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

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 


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: Proposal for vendoring/bundling golang packages by default

[Carlos Rodriguez-Fernandez]

These are all great points. I also second the Golang change. However, 
just to clarify, Go and Rust both generate ELF binaries as well, but 
Golang is not comparable to the some of the other examples mentioned. If 
you have a vulnerability in a package in Python, for example, you can 
deliver one single package update and remove the vulnerability from 
many. If you have a vulnerability in a Golang package, you have to 
deliver *many* packages updates, because Golang binaries are statically 
linked during the build. Golang is ... well, ... *different*...



On 1/20/25 4:20 AM, Daniel P. Berrangé wrote:

On Mon, Jan 20, 2025 at 11:29:55AM +0100, Michael J Gruber wrote:

Mikel Olasagasti venit, vidit, dixit 2025-01-20 08:02:18:

Hi,

Go-SIG has raised a ticket with FESCo [1] to propose a significant
shift in Fedora's packaging approach for Go dependencies: moving to
vendoring/bundling by default. This would represent a major departure
from our current guidelines [2].

Given the potential impact, it was suggested that we bring this topic
to the devel-list for broader input and an open discussion.

The rationale for this proposal stems from the increasing challenges
in maintaining Go dependencies under the current model, including
issues with timely reviews, dependency management, and the impact of
some "core" orphaned packages. Allowing vendoring by default could
help alleviate these bottlenecks and improve the stability of Go-based
packages in Fedora.

I understand that these are challenges, and they are increasing because
there are so many upcoming ecosystems which build their own distribution
channels and tools, be it Go, Rust, Julia, even Python to some degree
(think pip, conda and the like).

And indeed, as Jan's reply shows, once we allow bundling in general for
one language people will want it for other language ecosystems, and
"rightly" so, at least as long as the same reasoning applies.

Yes, I think we should apply the logic consistently across languages.
They might not have all reached the same point of frustration, but
the challenges are clearly common across many of these languages which
are dealing with non-ELF packages with upstream bundling or locked
dep versions as the default.


Following the Go-SIG proposal would be the can-opener to deviate from
our distribution model in general. I mean, if I can pull in a myriad of
Go or Rust modules for my package to build (without individual review or
re-review in case of changed dependencies), then why should I bother
unbundling a library such as zlib, regex, openssl, ... ?

IMHO comparing/equating these non-C/non-ELF language modules, to traditional
ELF libraries was/is a mistake.

The biggest difference is simply one of granularity. A non-trivial ELF
library will provide 1000's of APIs across a vast range of functionality
in a single library. In these non-C languages, modules are often incredibly
small just providing a handful of APIs. IOW, functionality that was a
single ELF library, may be spread across 100's of python/go/rust modules.

This granularity then feeds the other problems and/or design approaches.
Many deps are fast moving with a somewhat more relaxed approach to API
compat than traditional ELF libraries. With 100's of deps, fixing on
specific versions quickly becomes requirement to get a stable foundation
for the app which can be tested without deps changes breaking stuff too
often.

Fedora went down the route of applying our existing unbundling practices
from ELF libraries across these non-C ecosystems for various good reasons,
but this level of module granularity & differing attitudes to the module
API lifecycle is drowning the distro maintainers in work. At the same
time it risks delivering something which is of worse quality than that
from upstream, because our versions won't  match what upstream has
validated in their CI systems.

IMHO it is right to ask whether we have the right trade-off here.

We rely on the heroics of small numbers of SIG members to keep this all
working, and when key members of the SIGs change their focus it is at
risk of falling apart. See NodeJS, or Java ecosystem changes in Fedora.
This isn't a sustainable model. Any 3rd parties who want to build on top
of what Fedora ships have a foundation that could collapse with any new
major Fedora release.

It is no surprise that application developers have embraced containers as
a delivery mechanism in a way that they rarely embraced distros directly
in the past.

If we spent less time unbundling all these non-ELF modules, our maintainers
would be freed up to work on other things that could potentially be more
beneficial Fedora users.



That isn't to say Fedora's process is without value. There are key parts
of our review process that are critically beneficial. Most notabley license
scanning has had clear benefits both to Fedora and the upstreams, with
many problems uncovered & fixed over the years. Fedora & upstream aligned
in their desirables in this case (mostly),

Re: Proposal for vendoring/bundling golang packages by default

[Mikel Olasagasti]

Hau idatzi du Michael J Gruber (m...@fedoraproject.org) erabiltzaileak
(2025 urt. 20(a), al. (11:29)):
>
> Following the Go-SIG proposal would be the can-opener to deviate from
> our distribution model in general. I mean, if I can pull in a myriad of
> Go or Rust modules for my package to build (without individual review or
> re-review in case of changed dependencies), then why should I bother
> unbundling a library such as zlib, regex, openssl, ... ?
>
> There is a second point to that, and that is Fedora as a development
> platform (not just as an "app" platform). If we expect developers to
> install dependencies of their project via the ecosystem tools (pip, ...)
> locally (envs, containers) and "app packages" do the same during build
> then it is time to change the fundamental approach to our distribution
> and view it "merely" as a platform.

AFAIK it was never the intention of go-sig to provide packages as
development modules.

> I don't mean to connotate "merely" negatively - but the proposed change
> has impact overall, and we should *really want it* as a direction to go
> in generally.
>
> > If this proposal gains consensus, we could aim to implement the change
> > as part of Fedora 43, with the development phase used for migration
> > and retiring packages that may no longer fit within the updated
> > framework.
>
> How would packages "not fit"? By not bundling, i.e. by following our
> packaging guidelines so far?

If a binary package is bundled, some packages could become leave
packages that no other package require. I refer to these packages, as
maintaining them wouldn't make much sense.

> To put it differently: Do you intend to
> discourage/disallow "not bundling", or packaging dependencies?

Packages with minimal dependencies could still be maintained, but
those with a complex dependency chain would be discouraged. For
instance, if a package relies on golang-x-* modules and pkg/errors for
example, it remains feasible to maintain. However, if the required
stack includes frameworks like docker, k8s, moby, or otel, it would be
discouraged.

In any case, this is something we should clarify further during this discussion.

> > On a related note, I recently highlighted how the introduction of
> > Golang 1.24 has caused significant breakage in over 200 packages [3],
> > an issue that underscores the urgency of addressing these challenges.
>
> How would bundling alleviate this issue? By assuming that all upstreams
> have adjusted to Golang 1.24 already so that you don't have to wait for
> package updates but just pull in with your package?

Many of the failing packages are source-only packages that are
required to build binary containing packages. If binary packages are
bundled, many of the failing source packages could be retired.

Regards,
Mikel
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Proposal for vendoring/bundling golang packages by default

[Björn Persson]

Mikel Olasagasti wrote:
> Hau idatzi du Michael J Gruber (m...@fedoraproject.org) erabiltzaileak
> (2025 urt. 20(a), al. (11:29)):
> > > On a related note, I recently highlighted how the introduction of
> > > Golang 1.24 has caused significant breakage in over 200 packages [3],
> > > an issue that underscores the urgency of addressing these challenges.  
> >
> > How would bundling alleviate this issue? By assuming that all upstreams
> > have adjusted to Golang 1.24 already so that you don't have to wait for
> > package updates but just pull in with your package?  
> 
> Many of the failing packages are source-only packages that are
> required to build binary containing packages. If binary packages are
> bundled, many of the failing source packages could be retired.

So instead of one source-only package with format string bugs, there
would be multiple bundled copies with those same format string bugs,
which would all have to be updated – multiplied by over 200.

Note that format string bugs are potential vulnerabilities, which Go
programmers apparently weren't fixing until the tooling started forcing
them.

· Ideally all the upstreams will quickly make bugfix releases, all the
using programs will update their bundled copies, and everything will
work right away without any problems caused by API instability or the
like. In this ideal case all the source-only packages can also be
updated to the latest release without problems. There are tools that
help make the ideal case quick and easy, so there's no problem for
bundling to solve.

· If upstreams release the bugfixes together with incompatible API
changes, then the using programs must be adapted to those changes with
or without bundling. API instability is always a problem. Bundling can
hide the problem in other cases, by keeping old and vulnerable versions
of bundled libraries, but when tools start rejecting vulnerable code,
then bundling can't hide the problem anymore. Unless you bundle old
versions of the entire toolchain in every package.

· If nobody fixes the bugs, then the using programs will continue to
fail to build, and will remain vulnerable in those cases where the bugs
are exploitable. Bundling makes no difference in this case.

· If the bugs must be patched downstream because upstreams don't fix
them, that's when you want unbundled packages. Patching over 200
packages is certainly a lot of work, but patching multiple bundled
copies is even more work.

Thus I don't see how bundling would help with those format string bugs.

Björn Persson


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

Re: Proposal for vendoring/bundling golang packages by default

[Fabio Valentini]

On Mon, Jan 20, 2025 at 8:02 AM Mikel Olasagasti  wrote:
>
> Hi,
>
> Go-SIG has raised a ticket with FESCo [1] to propose a significant
> shift in Fedora's packaging approach for Go dependencies: moving to
> vendoring/bundling by default. This would represent a major departure
> from our current guidelines [2].
>
> Given the potential impact, it was suggested that we bring this topic
> to the devel-list for broader input and an open discussion.
>
> The rationale for this proposal stems from the increasing challenges
> in maintaining Go dependencies under the current model, including
> issues with timely reviews, dependency management, and the impact of
> some "core" orphaned packages. Allowing vendoring by default could
> help alleviate these bottlenecks and improve the stability of Go-based
> packages in Fedora.
>
> If this proposal gains consensus, we could aim to implement the change
> as part of Fedora 43, with the development phase used for migration
> and retiring packages that may no longer fit within the updated
> framework.
>
> On a related note, I recently highlighted how the introduction of
> Golang 1.24 has caused significant breakage in over 200 packages [3],
> an issue that underscores the urgency of addressing these challenges.
>
> We invite all Fedora contributors, maintainers, and stakeholders to
> share their perspectives, concerns, and suggestions on this topic.

Thank you for opening this discussion!

I do understand the problems that the Go SIG is facing here, and I've
had the same experience.

I used to need to poke golang-* library maintainers to update to a new
git snapshot of libraries just so I could ship a bugfix update for
syncthing.
(Tagged releases? Apparently blasphemy in the Go world, though not as
bad as it used to be, I hear.)

This got bad to the point where almost every upstream release added
new dependencies, bumped others, and removed others, which was when I
just gave up and started building against the vendored sources (which
are actually included in the source release tarballs published by the
upstream project). This reduced the number of bugs caused by building
against versions of libraries that don't match what the upstream
project builds / tests against, and allowed shipping security and
bugfix updates faster.

[/preface]

That said, reading other posts in this thread, I just don't think this
is a good model for *all* "non-ELF" languages, and it shouldn't serve
as a precedent.
The Go ecosystem is a little bit special, in that there is no package
manager in the real sense - dependencies are basically just pointers
at "". Mapping this "scheme" (or lack
thereof) to RPM packages has proven to be difficult.

Speaking for the Rust package ecosystem, we just don't have many of
the same problems outlined here for Go. There is one central registry
for libraries (crates.io), with a flat (for now) namespace that we can
map 1:1 to RPM package names. Additionally, it is almost trivially
easy to ship multiple versions of the same library in
parallel-installable RPMs, because the build tooling already natively
namespaces dependencies by both name *and* version in its expected
directory layout - so there is no "dependency hell", like in Go.

I also don't understand the argument of "bundling would let us solve
200 broken packages caused by Go compiler changes faster". If the
libraries fail to compile in standalone packages, then they should
fail to compile in any Go application that vendors them as
dependencies too, right? So it just moves and multiplies the problem
(into all applications that vendor this dependency).

Also, in my experience, patching vendored dependencies downstream is
*really really annoying*, at least in the Rust world - because the
tools are just not made to handle the case of "vendor this dependency,
but apply this unverified patch on top of it - trust me, it's fine".
So if you need to apply any patch to a Rust library that is vendored
... well, good luck. It *is* possible, with workarounds (disabling
checksum checks, etc.) but it's very gnarly.

On the other hand, applying a security update for a packaged Rust
crate is basically trivial. This requires only *one* package to be
changed, and applications that statically link the library can be
rebuilt against the new version without requiring any spec changes.

(Before somebody responds with "but konflux!": No, konflux would not
make the Rust workflow significantly easier. If you think the file
format of the "shippable unit" or the build system behind the scenes
are the hard part, then you don't understand the problem.)

Another downside of using vendored dependencies (and it's a pretty big
downside, IMO) is that - at least for Rust - it's not possible to run
the test suites of those libraries - for one, because test-only
dependencies of dependencies aren't included in vendored sources.
Running tests for Rust crates (where possible) has proven very
valuable to find architecture-specific bugs in libraries, LLVM

Re: sdl2-compat problem?

[Julian Sikorski]

Am 19.01.25 um 18:24 schrieb Neal Gompa:

On Sun, Jan 19, 2025 at 6:07 AM Neal Gompa  wrote:


On Sun, Jan 19, 2025 at 3:28 AM Julian Sikorski  wrote:


Hello,

I tried building mame against sdl2-compat which has replaced SDL2 in
rawhide. After some fixes I managed to get further but the build still
fails:

Compiling src/osd/sdl/window.cpp...
g++-MMD -MP -MP -DPTR64=1 -DNDEBUG -DCRLF=2 -DLSB_FIRST -DXMD_H
-DFLAC__NO_DLL -DNATIVE_DRC=drcbe_x64 -DLUA_COMPAT_ALL -DLUA_COMPAT_5_1
-DLUA_COMPAT_5_2 -DUSE_NETWORK -DOSD_NET_USE_TAPTUN
-D'INI_PATH="/etc/mame;"' -DSDLMAME_X11 -DSDLMAME_USE_WAYLAND
-DUSE_XINPUT=1 -DUSE_XINPUT_DEBUG=0 -DUSE_XINPUT_WII_LIGHTGUN_HACK=0
-DSDLMAME_SDL2=1 -DOSD_SDL -DSDLMAME_UNIX -DUSE_OPENGL=1
-D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS
-DBX_CONFIG_DEBUG=0 -DUSE_QTDEBUG=1
-I"../../../../../../../../../../usr/X11/include"
-I"../../../../../../../../../../usr/X11R6/include"
-I"../../../../../../../../../../usr/openwin/include"
-I"../../../../../src/osd" -I"../../../../../scripts/src/osd"
-I"../../../../../3rdparty/bgfx/examples/common"
-I"../../../../../3rdparty/bgfx/include"
-I"../../../../../3rdparty/bgfx/3rdparty"
-I"../../../../../3rdparty/bgfx/3rdparty/khronos"
-I"../../../../../3rdparty/bx/include" -I"../../../../../src/emu"
-I"../../../../../src/devices" -I"../../../../../src/lib"
-I"../../../../../src/lib/util" -I"../../../../../src/osd/modules/file"
-I"../../../../../src/osd/modules/render" -I"../../../../../3rdparty"
-I"../../../../../src/osd/sdl"  -m64 -std=c++17 -pipe -O2
-fno-strict-aliasing -O2 -fexceptions -g1 -grecord-gcc-switches -pipe
-Wall -Wno-complain-wrong-lang -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -Wno-unknown-pragmas -Wall -Wcast-align
-Wformat-security -Wundef -Wwrite-strings -Wno-conversion
-Wno-sign-compare -Wno-error=deprecated-declarations
-Wno-error=unused-result -Wno-error=array-bounds -Wno-error=attributes
-Wno-error=stringop-truncation -Wno-stringop-overflow -Wno-nonnull
-Wno-stringop-overread -Wno-error=maybe-uninitialized
-Wno-error=uninitialized -m64  -I/usr/include/SDL2 -D_GNU_SOURCE=1
-D_REENTRANT -I/usr/include/freetype2 -I/usr/include/libpng16
-I/usr/include/harfbuzz -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-6 -pthread
-I/usr/include/libxml2 -DWITH_GZFILEOP -I/usr/include/qt6 -std=c++17
-Woverloaded-virtual -Wvla -Wimplicit-fallthrough
-Wno-error=class-memaccess -Wno-xor-used-as-pow -include
/builddir/build/BUILD/mame-0.273-build/mame-mame0273/src/osd/sdl/sdlprefix.h
-o "../../../../linux_gcc/obj/x64/Release/osd_sdl/src/osd/sdl/window.o"
-c "../../../../../src/osd/sdl/window.cpp"
../../../../../src/osd/sdl/window.cpp: In member function ‘int
sdl_window_info::complete_create()’:
../../../../../src/osd/sdl/window.cpp:904:56: error: ‘union
SDL_SysWMinfo::’ has no member named ‘x11’
904 |
XSelectInput(swmi.info.x11.display, swmi.info.x11.window,
|^~~
../../../../../src/osd/sdl/window.cpp:904:79: error: ‘union
SDL_SysWMinfo::’ has no member named ‘x11’
904 |
XSelectInput(swmi.info.x11.display, swmi.info.x11.window,
|
^~~
../../../../../src/osd/sdl/window.cpp:905:41: error: ‘FocusChangeMask’
was not declared in this scope
905 | FocusChangeMask |
EnterWindowMask | LeaveWindowMask |
| ^~~
../../../../../src/osd/sdl/window.cpp:905:59: error: ‘EnterWindowMask’
was not declared in this scope
905 | FocusChangeMask |
EnterWindowMask | LeaveWindowMask |
|
^~~
../../../../../src/osd/sdl/window.cpp:905:77: error: ‘LeaveWindowMask’
was not declared in this scope
905 | FocusChangeMask |
EnterWindowMask | LeaveWindowMask |
|
  ^~~
../../../../../src/osd/sdl/window.cpp:906:41: error: ‘PointerMotionMask’
was not declared in this scope
906 | PointerMotionMask |
KeyPressMask | KeyReleaseMask |
| ^
../../../../../src/osd/sdl/window.cpp:906:61: error: ‘KeyPressMask’ was
not declared in this scope
906 | PointerMotionMask |
KeyPressMask | KeyReleaseMask |
|
^~~~
../../../../../src/osd/sdl/window.cpp:906:76: error: ‘KeyReleaseMask’
was not declared in this scope
906 | PointerMotionMask |
KeyPressMask | KeyReleaseMask |
|
 ^~

Re: Proposal for vendoring/bundling golang packages by default

[Mikel Olasagasti]

Hau idatzi du Fabio Valentini (decatho...@gmail.com) erabiltzaileak
(2025 urt. 20(a), al. (21:27)):
>
> I also don't understand the argument of "bundling would let us solve
> 200 broken packages caused by Go compiler changes faster". If the
> libraries fail to compile in standalone packages, then they should
> fail to compile in any Go application that vendors them as
> dependencies too, right? So it just moves and multiplies the problem
> (into all applications that vendor this dependency).

Let me try to clarify this scenario a bit further.

Imagine a complex application like doctl, which has numerous
dependencies listed in its go.mod file. To ship an unbundled version
of doctl in Fedora, the number of required packages far exceeds the
set defined in go.mod. This is because each dependency in go.mod has
its own dependencies, which would also need to be included in Fedora.
However, if doctl uses vendored dependencies, it might not require
these additional packages, as they wouldn't be part of the bundled
application.

Here are the same details with numbers: while doctl has 122
dependencies listed in its go.mod file, Fedora requires 752 packages
to be installed to build the package of which 629 are golang-*-devel
packages.

For example, doctl's go.mod file defines 3 indirect dependencies in
the containerd modules (console, containerd, and log). However, for
Fedora, at least 16 containerd modules would need to be included
(aufs, btrfs, cgroups, cni, console, containerd, continuity, fifo,
fuse-overlayfs-snapshotter, imgcrypt, nri, runc, stargz-snapshotter,
ttrpc, typeurl, and zfs).

Additionally, in the Go 1.24 scenario where many packages break, the
issue arises only during the %check phase, not during the binary
build. Since creating a binary with bundled dependencies doesn't test
those dependencies, only the main packages would need to be fixed,
simplifying the scenario considerably.

The downside, as you mentioned, is that if two packages share a
dependency and a fix is required for both but no downstream patch is
carried, then both packages would need changes if bundled. By
contrast, in an unbundled scenario, only one package would need to be
updated.

Regards,
Mikel
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Proposal for vendoring/bundling golang packages by default

[Fabio Alessandro Locati via devel]

On Mon, Jan 20, 2025, at 21:27, Fabio Valentini wrote:
> That said, reading other posts in this thread, I just don't think this
> is a good model for *all* "non-ELF" languages, and it shouldn't serve
> as a precedent.
> The Go ecosystem is a little bit special, in that there is no package
> manager in the real sense - dependencies are basically just pointers
> at "". Mapping this "scheme" (or lack
> thereof) to RPM packages has proven to be difficult.

I totally agree on this point.
As shown in this thread, the go ecosystem is unique and the conversation is 
based on those unique characteristics of go, so we should keep the conversation 
purely on go and potential packaging changes that only apply to go.


More generally, I think that - although vendoring for go is not a perfect 
solution with only advanatages, once considered all the points raised so far in 
the conversation, the advantages of vendoring are far more than the 
disadvantages, so I would personally see favorably moving go packages to a 
vendored approach.

-- 
Fabio Alessandro "Fale" Locati
fale.io
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Proposal for vendoring/bundling golang packages by default

[Miroslav Suchý]

Dne 20. 01. 25 v 11:29 dop. Michael J Gruber napsal(a):

There is a second point to that, and that is Fedora as a development
platform (not just as an "app" platform). If we expect developers to
install dependencies of their project via the ecosystem tools (pip, ...)
locally (envs, containers) and "app packages" do the same during build
then it is time to change the fundamental approach to our distribution
and view it "merely" as a platform.


Or we can work on the idea of Rings that Matt proposed ages ago [1]. I would be +1 for allowing bundling if we allowed 
it only in a ring N+1 and no package from ring N is dependent on package from ring N+1. And each ring has its own 
compose (yum repo).


[1] 
https://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-update-part-ii-whats-happening/

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Proposal for vendoring/bundling golang packages by default

[Benson Muite]

On Mon, Jan 20, 2025, at 6:24 PM, Miroslav Suchý wrote:
> Dne 20. 01. 25 v 11:29 dop. Michael J Gruber napsal(a):
>> There is a second point to that, and that is Fedora as a development
>> platform (not just as an "app" platform). If we expect developers to
>> install dependencies of their project via the ecosystem tools (pip, ...)
>> locally (envs, containers) and "app packages" do the same during build
>> then it is time to change the fundamental approach to our distribution
>> and view it "merely" as a platform.
>
> Or we can work on the idea of Rings that Matt proposed ages ago [1]. I 
> would be +1 for allowing bundling if we allowed 
> it only in a ring N+1 and no package from ring N is dependent on 
> package from ring N+1. And each ring has its own 
> compose (yum repo).
>

This is a good idea. Would be great to minimize bundling at the core.  Bundled 
packages do not get the same level of review as unbundled packages. Want to 
encourage upstreams to move used features into releases so that bundling is not 
a required option.  A relatively stable development platform is needed.  
Containers, virtual environments are available when one needs/wants to break 
things.

> [1] 
> https://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-update-part-ii-whats-happening/
>
> -- 
> Miroslav Suchy, RHCA
> Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
>
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Orphaned magic-wormhole + its python deps

[Blaise Pabon]

Hi I'm working on the upstream Tahoe-LAFS project (upstream from wormhole)
and two of us are interested in Fedora packaging, so please feel free to
let me know if you're not getting what you need to move forward.

Blaise

On Sun, Jan 19, 2025 at 5:13 AM Benson Muite 
wrote:

> On Sat, Jan 18, 2025, at 5:56 PM, Fabio Valentini wrote:
> > On Sat, Jan 18, 2025 at 2:40 PM Kyle Bloom  wrote:
> >>
> >> Hello Fabio (or whom it may concern),
> >>
> >> I am interested in maintaining the python-magic-wormhole package,
> >> and it is along with its dependencies. I continue to use and love
> >> the project. There has been an uptick in activity in the project and I
> >> have started maintaining a Copr package (linked at the bottom) for it.
> >> It does seem that I would need a sponsor to be able to do the
> >> packaging.
> >>
> >> Looking forward to the next steps
> >
> > Hello!
> >
> > The package has been removed from the Fedora repositories almost 2
> > years ago, so they will need to go through re-review.
> > That would be your next step, if you would like them to be added back :)
> >
> > See also
> >
> https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
> .
> >
>
> It is under review:
> https://bugzilla.redhat.com/show_bug.cgi?id=2327756
>
> co-maintainers and people to push the review for it and its dependencies
> forward are likely welcome.
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>


-- 
LinkedIn    |  Github

“If you want to go fast, go alone. If you want to go far, go
together.” --African
proverb
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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