Fedora 42 compose report: 20250220.n.0 changes

[Fedora Branched Report]

OLD: Fedora-42-20250219.n.0
NEW: Fedora-42-20250220.n.0

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

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Updating python-aiohttp to 3.11.12 in F43/Rawhide and possibly F42/Branched

[Ben Beasley]

In one week, 2025-02-27, I plan to update python-aiohttp from 3.10.11 to 
3.11.12 in F43/Rawhide[1]. I impact-checked this update in COPR and 
found no regressions, but it does have documented breaking changes, so 
I’m going through the announcement process.


I would like to do the same update in F42/Branched, and I impact-checked 
it successfully. However, I would need to update python-uvloop from 
0.19.0 to 0.21.0 and python-yarl from 1.13.1 in the same side tag. 
(These are the versions already in Rawhide.) I included those updates in 
my impact check, so I feel confident that they’re safe enough. However, 
I’m not an individual or group co-maintainer of either package, and I 
don’t want to proceed without consent from individual maintainers of 
both packages. If you maintain one of these packages, please let me know 
if you agree. I am able to merge from Rawhide using provenpackager 
privilege, so I only need consent, not assistance.


[1] https://src.fedoraproject.org/rpms/python-aiohttp/pull-request/50

[2] 
https://github.com/aio-libs/aiohttp/blob/v3.11.12/CHANGES.rst#removals-and-backward-incompatible-breaking-changes


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: 20250220.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20250219.n.0
NEW: Fedora-Rawhide-20250220.n.0

= SUMMARY =
Added images:0
Dropped images:  7
Added packages:  8
Dropped packages:0
Upgraded packages:   115
Downgraded packages: 0

Size of added packages:  12.58 MiB
Size of dropped packages:0 B
Size of upgraded packages:   15.94 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -36.81 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-Rawhide-20250219.n.0.x86_64.iso
Image: Python_Classroom live aarch64
Path: 
Labs/aarch64/iso/Fedora-Python-Classroom-Live-Rawhide-20250219.n.0.aarch64.iso
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20250219.n.0.x86_64.vagrant-virtualbox.box
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20250219.n.0.iso
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20250219.n.0.x86_64.vagrant-libvirt.box
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20250219.n.0.iso
Image: Python_Classroom raw-xz aarch64
Path: 
Labs/aarch64/images/Fedora-Python-Classroom-Disk-Rawhide-20250219.n.0.aarch64.raw.xz

= ADDED PACKAGES =
Package: mivisionx-6.3.2-1.fc43
Summary: AMD's computer vision toolkit
RPMs:mivisionx mivisionx-devel
Size:11.78 MiB

Package: plexus-utils4-4.0.2-1.fc43
Summary: Plexus Common Utilities
RPMs:plexus-utils4 plexus-utils4-javadoc
Size:464.12 KiB

Package: rust-equator-0.4.2-1.fc43
Summary: Composable assertion library
RPMs:rust-equator+default-devel rust-equator-devel
Size:24.56 KiB

Package: rust-ironrdp-ainput-0.1.2-1.fc43
Summary: AInput dynamic channel implementation
RPMs:rust-ironrdp-ainput+default-devel rust-ironrdp-ainput-devel
Size:23.37 KiB

Package: rust-ironrdp-cliprdr-0.1.2-1.fc43
Summary: CLIPRDR static channel for clipboard implemented as described in 
MS-RDPECLIP
RPMs:rust-ironrdp-cliprdr+default-devel rust-ironrdp-cliprdr-devel
Size:39.67 KiB

Package: rust-ironrdp-displaycontrol-0.1.2-1.fc43
Summary: Display control dynamic channel extension implementation
RPMs:rust-ironrdp-displaycontrol+default-devel 
rust-ironrdp-displaycontrol-devel
Size:28.51 KiB

Package: rust-pixman-sys-0.1.0-1.fc43
Summary: Pixman is a low-level software library for pixel manipulation, 
providing features such as image compositing and trapezoid rasterization
RPMs:rust-pixman-sys+default-devel rust-pixman-sys-devel
Size:21.59 KiB

Package: rust-winnow0.6-0.6.26-1.fc43
Summary: Byte-oriented, zero-copy, parser combinators library
RPMs:rust-winnow0.6+alloc-devel rust-winnow0.6+debug-devel 
rust-winnow0.6+default-devel rust-winnow0.6+simd-devel rust-winnow0.6+std-devel 
rust-winnow0.6+unstable-doc-devel rust-winnow0.6+unstable-recover-devel 
rust-winnow0.6-devel
Size:208.46 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  Mayavi-4.8.2-11.fc43
Old package:  Mayavi-4.8.2-5.fc42
Summary:  Scientific data 3-dimensional visualizer
RPMs: Mayavi Mayavi-doc python3-mayavi
Size: 86.64 MiB
Size change:  584 B
Changelog:
  * Thu Feb 20 2025 Orion Poplawski  - 4.8.2-11
  - Drop i686 builds


Package:  amdsmi-6.3.3-1.fc43
Old package:  amdsmi-6.3.2-1.fc43
Summary:  AMD System Management Interface
RPMs: amdsmi amdsmi-devel
Size: 855.94 KiB
Size change:  2.96 KiB
Changelog:
  * Wed Feb 19 2025 Tom Rix  - 6.3.3-1
  - Update to 6.3.3


Package:  chicken-5.4.0-1.fc43
Old package:  chicken-5.3.0-9.fc42
Summary:  A practical and portable Scheme system
RPMs: chicken chicken-libs chicken-static
Size: 18.25 MiB
Size change:  223.88 KiB
Changelog:
  * Wed Feb 19 2025 Jani Juhani Sinervo  - 5.4.0-1
  - Update to 5.4.0


Package:  cifs-utils-7.2-1.fc43
Old package:  cifs-utils-7.1-3.fc42
Summary:  Utilities for mounting and managing CIFS mounts
RPMs: cifs-utils cifs-utils-devel cifs-utils-info pam_cifscreds
Size: 680.57 KiB
Size change:  6.07 KiB
Changelog:
  * Wed Feb 19 2025 Paulo Alcantara  - 7.2-1
  - resolves: rhbz#2345614 - Update to cifs-utils-7.2


Package:  deutex-5.2.3-1.fc43
Old package:  deutex-5.2.2-13.fc42
Summary:  DOOM wad file manipulator
RPMs: deutex
Size: 501.33 KiB
Size change:  552 B
Changelog:
  * Wed Feb 19 2025 Gwyn Ciesla  - 5.2.3-1
  - 5.2.3


Package:  emacs-1:29.4-52.fc43
Old package:  emacs-1:29.4-49.fc42
Summary:  GNU Emacs text editor
RPMs: emacs emacs-common emacs-devel emacs-gtk+x11 emacs-lucid emacs-nw 
emacsclient
Size: 1.95 GiB
Size change:  1.06 MiB
Changelog:
  * Mon Feb 03 2025 Peter Oliver  - 1:29.4-50
  - Rebuild against tree-sitter-0.25.1-3.fc42

  * Mon Feb 03 2025 Peter O

Fedora eln compose report: 20250221.n.0 changes

[Fedora ELN Report]

OLD: Fedora-eln-20250220.n.0
NEW: Fedora-eln-20250221.n.0

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

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   8.11 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   2.44 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  python-boto3-1.36.24-1.eln146
Old package:  python-boto3-1.36.23-1.eln146
Summary:  The AWS SDK for Python
RPMs: python3-boto3
Size: 417.20 KiB
Size change:  263 B
Changelog:
  * Wed Feb 19 2025 Gwyn Ciesla  - 1.36.24-1
  - 1.36.24


Package:  python-botocore-1.36.24-1.eln146
Old package:  python-botocore-1.36.23-1.eln146
Summary:  Low-level, data-driven core of boto 3
RPMs: python3-botocore
Size: 7.70 MiB
Size change:  2.19 KiB
Changelog:
  * Wed Feb 19 2025 Gwyn Ciesla  - 1.36.24-1
  - 1.36.24



= DOWNGRADED PACKAGES =
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Heads-up: Updating python-aiohttp to 3.11.12 in F43/Rawhide and possibly F42/Branched

[Ben Beasley]

Neither python-yarl nor python-uvloop is currently in EPEL10, so these 
would fall under the normal EPEL package request process, 
https://docs.fedoraproject.org/en-US/epel/epel-package-request/. I do 
agree that EPEL10 branching should be based on the latest versions in 
Rawhide in these cases.


On 2/20/25 7:05 AM, Romain Geissler via devel wrote:

Hi Ben,

I am not maintainer/co-maintainer for any of these packages so I cannot give 
you any consent.

On my side I had submitted the pytho-yarl & python-uvloop upgrades in 
anticipation of their branching in EPEL 10, as I would need these dependencies (and 
python-aiohttp) in RHEL 10. So would it be ok to include EPEL 10 in addition to 
Fedora 42/43 in your request ?

Thanks,
Romain

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Allow all packagers to push empty commits to any package

[Miro Hrončok]

On 20. 02. 25 14:02, Neal Gompa wrote:

On Thu, Feb 20, 2025 at 7:59 AM Miro Hrončok  wrote:


On 20. 02. 25 13:51, Michael J Gruber wrote:

With the wide adoption of %autorelease, such bump commits are empty,
which should be easy to verify.

Wide, well, ...


Roughly 39% based on a simple grep for %\{?autorelease



What does that number look like when we exclude rust2rpm managed packages?


When I delete all specs with "Generated by rust2rpm" in them, it's 30% of the 
rest.

--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok

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

Re: Proposal: Allow all packagers to push empty commits to any package

[Ben Beasley]

On 2/20/25 8:02 AM, Neal Gompa wrote:

What does that number look like when we exclude rust2rpm managed packages?


$ rg -l '%\{?autorelease' | while read -r spec; do if ! grep -Fq 
'Generated by rust2rpm' "${spec}"; then echo "${spec}"; fi; done | wc -l

6559

$ find . -name '*.spec' | while read -r spec; do if ! grep -Fq 
'Generated by rust2rpm' "${spec}"; then echo "${spec}"; fi; done | wc -l

21404

So about 30% of non-rust2rpm packages employ rpmautospec, if my 
heuristic is as reasonable as I think it is.


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Allow all packagers to push empty commits to any package

[Miro Hrončok]

On 20. 02. 25 14:08, Dmitry Belyavskiy wrote:



On Thu, Feb 20, 2025 at 1:17 PM Miro Hrončok > wrote:



What if we allowed all packagers to push empty commit to any package? That
should eliminate *some* need for provenpackager access. We would also
communicate in our policies that such bumps do not require prior agreement
with
the maintainers to avoid confusion about "what are we allowed to do".

I don't like this idea. It will cause stupid rebases that are completely missed 
until you suddenly have to push smth urgently and see that they can't just merge.


I have no idea what you mean by "stupid rebases" or "can't just merge".

The commits are empty. Rebases are trivial.

It's not a big deal for rawhide itself but if you use rawhide as a starting 
point to cherry-pick downwards, it's more problematic.


How?

--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok

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

soname bump: mupdf 1.25.4 coming to f41

[Michael J Gruber]

Hi there

mupdf 1.25.4 is the latest version from the release branch. It
collects several bugfixes but bumps soname as is typical with the way
upstreams versions this.

We (Ankur Sinha and me) have been going through updates of the
girara/zathura/mupdf ecosystem for rawhide and F42 already, all
updates as well as local production use have been successful so far.
We therefore feel confident that making use of the existing update
policy exceptions for girara/zathura and mupdf is in line with their
purpose and in the best interest of users. The update (in a side tag)
brings all related components to the same versions (from respective
release branches, after contemplating with fellow mainatiners).

I don't expect any further soname breaking updates for g/z/m on F41.

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: Proposal: Allow all packagers to push empty commits to any package

[Richard W.M. Jones]

On Thu, Feb 20, 2025 at 01:17:02PM +0100, Miro Hrončok wrote:
> Hello.
> 
> With the recent discussions about provenpackagers in Fedora, I
> recently got an idea.
> 
> One of the common needs for provenpackagers is to simply "bump and
> rebuild" a set of dependencies.
> 
> All packagers are already able to build anything (except a very
> specific and small set of specially-signed packages). However, to
> bump the package, they need commit rights. For that reason,
> provenpackager rights are often required.
> 
> With the wide adoption of %autorelease, such bump commits are empty,
> which should be easy to verify.
> 
> What if we allowed all packagers to push empty commit to any
> package? That should eliminate *some* need for provenpackager
> access. We would also communicate in our policies that such bumps do
> not require prior agreement with the maintainers to avoid confusion
> about "what are we allowed to do".

Seems like a sensible proposal.  Some possible modifications:

 - Limit this only to rawhide?

 - If we don't restrict it only to Rawhide, should we encourage the
   packager to preserve ffwd to the rawhide branch, if that is
   currently the case?  [Whatever the technical term for that is.]

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Allow all packagers to push empty commits to any package

[Miro Hrončok]

On 20. 02. 25 13:28, Richard W.M. Jones wrote:

On Thu, Feb 20, 2025 at 01:17:02PM +0100, Miro Hrončok wrote:

What if we allowed all packagers to push empty commit to any
package? That should eliminate *some* need for provenpackager
access. We would also communicate in our policies that such bumps do
not require prior agreement with the maintainers to avoid confusion
about "what are we allowed to do".


Seems like a sensible proposal.  Some possible modifications:

  - Limit this only to rawhide?


Sure, we can start with rawhide only.


  - If we don't restrict it only to Rawhide, should we encourage the
packager to preserve ffwd to the rawhide branch, if that is
currently the case?  [Whatever the technical term for that is.]


And we can allow to ff-merge empty commits from rawhide to rawhide-1 branch to 
support this in branched as well.


--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok

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

Re: Proposal: Allow all packagers to push empty commits to any package

[Dmitry Belyavskiy]

Hello,

On Thu, Feb 20, 2025 at 2:27 PM Miro Hrončok  wrote:

> On 20. 02. 25 14:08, Dmitry Belyavskiy wrote:
> >
> >
> > On Thu, Feb 20, 2025 at 1:17 PM Miro Hrončok  > > wrote:
> >
> >
> > What if we allowed all packagers to push empty commit to any
> package? That
> > should eliminate *some* need for provenpackager access. We would also
> > communicate in our policies that such bumps do not require prior
> agreement
> > with
> > the maintainers to avoid confusion about "what are we allowed to do".
> >
> > I don't like this idea. It will cause stupid rebases that are completely
> missed
> > until you suddenly have to push smth urgently and see that they can't
> just merge.
>
> I have no idea what you mean by "stupid rebases" or "can't just merge".
>
> The commits are empty. Rebases are trivial.
>

Yes. If I forgot git pull before branching and I found it on fedpkg build
stage, it distracts me on the main task.
I agree that merge is trivial, BTW

-- 
Dmitry Belyavskiy
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Orphaning java-diff-utils

[Jiri Vanek]

As far as I know, java-diff utils can work happily without jgit. Only they will 
miss one diff algorithm.
I had excluded it in past - 
https://src.fedoraproject.org/rpms/java-diff-utils/c/38304b943ffba9cdb0b83a062b1c95d6c2c2d09e?branch=epel9

Btw I seesm to be owner of that package. So please, do nto orphan it :)

On 7/31/24 4:48 AM, Christiano Anderson wrote:

Hi,

I have orphaned the java-diff-utils package, which fails to build due to broken 
and unmaintained dependency jgit.

Thanks

Christiano


--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Allow all packagers to push empty commits to any package

[Miro Hrončok]

On 20. 02. 25 13:51, Michael J Gruber wrote:

With the wide adoption of %autorelease, such bump commits are empty,
which should be easy to verify.

Wide, well, ...


Roughly 39% based on a simple grep for %\{?autorelease

--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok

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

Re: Proposal: Allow all packagers to push empty commits to any package

[Ben Beasley]

Note that as long as we’re on Pagure, it’s impossible to make a PR for 
an empty commit.


On 2/20/25 8:51 AM, Cristian Le via devel wrote:


On 2025/02/20 13:17, Miro Hrončok wrote:

What if we allowed all packagers to push empty commit to any package? 
That should eliminate *some* need for provenpackager access. We would 
also communicate in our policies that such bumps do not require prior 
agreement with the maintainers to avoid confusion about "what are we 
allowed to do".


The wording and responsibility of such power would be important. I 
think it would still be preferred to try an make a PR and communicate 
with the maintainers first to figure out if they have any plans for 
other changes before/after the bump. But otherwise it could be a good 
workaround for needing provenpackager access.


How would such a check be enforced though?

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Allow all packagers to push empty commits to any package

[Cristian Le via devel]

On 2025/02/20 14:54, Ben Beasley wrote:

Note that as long as we’re on Pagure, it’s impossible to make a PR for 
an empty commit.



Right, that is indeed a nuisance. There is a dirty hack to it [1]:
1. Try to create the PR as normal and be greeted by a disabled "Create 
Pull Request"

2. Enter developer mode on the browser and inspect the disabled button
3. Delete the `disabled` field in the `input` object
4. Press the now enabled button

Result: 
https://src.fedoraproject.org/rpms/python-scikit-build-core/pull-request/73


[1]: https://pagure.io/pagure/issue/5270#comment-918447
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Allow all packagers to push empty commits to any package

[Ben Beasley]

I would also point out that incompatible updates are still supposed to 
be announced a week in advance, with all impacted packages’ maintainers 
CC’ed or BCC’ed. This allows a week for someone to read their email and 
speak up about any special circumstances.


For updates with more than a handful of packages that need to be 
rebuilt, making affirmative contact with a maintainer of each package is 
*much* harder than just making an announcement and saying “I’ll rebuild 
all of these packages unless I hear otherwise.” I’ve never had someone 
ask me not to rebuild a package, but the opportunity is there.


On 2/20/25 8:54 AM, Ben Beasley wrote:


Note that as long as we’re on Pagure, it’s impossible to make a PR for 
an empty commit.


On 2/20/25 8:51 AM, Cristian Le via devel wrote:


On 2025/02/20 13:17, Miro Hrončok wrote:

What if we allowed all packagers to push empty commit to any 
package? That should eliminate *some* need for provenpackager 
access. We would also communicate in our policies that such bumps do 
not require prior agreement with the maintainers to avoid confusion 
about "what are we allowed to do".


The wording and responsibility of such power would be important. I 
think it would still be preferred to try an make a PR and communicate 
with the maintainers first to figure out if they have any plans for 
other changes before/after the bump. But otherwise it could be a good 
workaround for needing provenpackager access.


How would such a check be enforced though?


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

[Orion Poplawski]

Yes, nothing seems to require it anymore.

On 2/20/25 05:22, Jiri Vanek wrote:

Right, Orion, may you confirm?

I;m quite surprised you hit it, as it was done before f43 forked, and 
all jdks in f42 got the support already removed. I had also did some 
builds in koji since that time, and tehy looks corrreclty copy-jdk- 
configs-free.


TY!!!
  J.

On 2/5/25 2:52 PM, Mikolaj Izdebski wrote:

On Sun, Feb 2, 2025 at 4:20 PM Orion Poplawski  wrote:


copy-jdk-configs was just retired with this note:

Paralel installs are going to be remove from JDK. Package existed only
to support that

but some packages still require it:

java-21-openjdk-headless-1:21.0.6.0.7-1.fc42.x86_64
java-21-openjdk-headless-fastdebug-1:21.0.6.0.7-1.fc42.x86_64
java-21-openjdk-headless-slowdebug-1:21.0.6.0.7-1.fc42.x86_64
java-latest-openjdk-headless-1:23.0.2.0.7-1.rolling.fc42.x86_64
java-latest-openjdk-headless- 
fastdebug-1:23.0.2.0.7-1.rolling.fc42.x86_64
java-latest-openjdk-headless- 
slowdebug-1:23.0.2.0.7-1.rolling.fc42.x86_64


This is broken the install of octave (and I imagine others) that require
java-21-openjdk-headless.


Is this still a problem?
 From what I can see java-21-openjdk was updated to no longer require
copy-jdk-configs.

--
Mikolaj



--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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







--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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

Re: Guidelines for packaging icons for other themes?

[Orion Poplawski]

On 2/20/25 00:49, Miro Hrončok wrote:

On 20. 02. 25 3:37, Orion Poplawski wrote:

While poking at f3d 3.0.0 I see that it installs:

/usr/share/icons/HighContrast/scalable/apps/f3d.svg

How are we supposed to handle this?  require highcontrast-icon-theme?

I would handle that as a general case:

  1) either require highcontrast-icon-theme
  2) or co-own /usr/share/icons/HighContrast(/scalable(/apps))



I guess my question boils down to which of these is preferable?  Is 
highcontrast-icon-theme something that should be installed on most 
machines?  It's decently large at 4.5M so I could see the attraction of 
not requiring it.


Should there be a highcontrast-icon-theme-filesystem package?

--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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

Re: tree-sitter build broke Emacs

[Jerry James]

On Wed, Jan 15, 2025 at 2:31 PM Jerry James  wrote:
> Thank you.  Would you please update tree-sitter, emacs, etc. in a side
> tag next time?

Except you didn't.  Emacs is again broken in Rawhide due to a
tree-sitter update.  Meaning I can't do the work I was planning to do
this morning because the build I am working on BuildRequires emacs.
Do you not understand why using a side tag is a good idea?  Do you not
understand how to use a side tag?  I'm happy to walk you through the
answers to either question if lack of education is the issue here.
-- 
Jerry James
http://www.jamezone.org/
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proposal: Allow all packagers to push empty commits to any package

[Mattia Verga via devel]

Il 20/02/25 13:17, Miro Hrončok ha scritto:
> Hello.
>
> With the recent discussions about provenpackagers in Fedora, I recently got an
> idea.
>
> One of the common needs for provenpackagers is to simply "bump and rebuild" a
> set of dependencies.
>
> All packagers are already able to build anything (except a very specific and
> small set of specially-signed packages). However, to bump the package, they
> need commit rights. For that reason, provenpackager rights are often required.
>
> With the wide adoption of %autorelease, such bump commits are empty, which
> should be easy to verify.
>
> What if we allowed all packagers to push empty commit to any package? That
> should eliminate *some* need for provenpackager access. We would also
> communicate in our policies that such bumps do not require prior agreement 
> with
> the maintainers to avoid confusion about "what are we allowed to do".
>
Well, I think it's a bit more complex: we would need to be sure the 
empty commit rebuild is really "empty".

Example: the package maintainer applies changes to the spec file, but 
doesn't build the package because they're still tweaking it (or just 
because they're building it in a side tag with other pieces). Now any 
packager can jump in, trigger an empty commit and build the package. I 
know that the same problem may happen with provenpackagers, but, 
ideally, provenpackagers are usually considered more "responsible"...

Mattia


-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Allow all packagers to push empty commits to any package

[Kashyap Chamarthy]

On Thu, Feb 20, 2025 at 01:17:02PM +0100, Miro Hrončok wrote:
> Hello.
> 
> With the recent discussions about provenpackagers in Fedora, I recently got
> an idea.
> 
> One of the common needs for provenpackagers is to simply "bump and rebuild"
> a set of dependencies.

I guess this "common need" is an example that be grouped under the
heading of "packagers should be considered as custodians" (or
"guardians"), instead of "owners".  It was described in the
thread[1] that you allude to.

> All packagers are already able to build anything (except a very specific and
> small set of specially-signed packages). However, to bump the package, they
> need commit rights. For that reason, provenpackager rights are often
> required.
> 
> With the wide adoption of %autorelease, such bump commits are empty, which
> should be easy to verify.
> 
> What if we allowed all packagers to push empty commit to any package? That
> should eliminate *some* need for provenpackager access. We would also
> communicate in our policies that such bumps do not require prior agreement
> with the maintainers to avoid confusion about "what are we allowed to do".

FWIW, sounds reasonable to me, assuming it's limited to Rawhide only for
now.  If that works well, then probably it can be extended to stable
branches, based on the feedback from more active packagers.  (I don't
pretend to understand all the implications here :))

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/URVJB22ITA7RPCMVOUBTQ6SB5D6JI4JX/

-- 
/kashyap

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

[Peter Oliver]

On Thu, 20 Feb 2025, Jerry James wrote:


Except you didn't.


We did.  https://bodhi.fedoraproject.org/updates/FEDORA-2025-52be0b6b4f


Do you not understand how to use a side tag?


It turns out that I did not.  Apologies.


I'm happy to walk you through the
answers to either question if lack of education is the issue here.


I think 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#_side_tags
 would benefit from a “Building in a side tag” section including the “…to 
ensure that the respective build is available in the build root for subsequent 
builds” text that is currently buried in the “Creating a side tag” section.

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

dnf: terminate called after throwing an instance of 'std::length_error'

[Richard Hughes via devel]

Hi all,

My CI has been failing for the last 24h with:

[ 4/48] Installing fwupd-0:2.0.7-0.1alpha.fc41.x86_64 100% |  39.9 MiB
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_M_replace_aux
contrib/ci/fedora-test.sh: line 3: 7 Aborted (core dumped) 
dnf install -y dist/*.rpm

Has anyone else seen this? Frustratingly I can't reproduce locally.

I'm *guessing* it's a regression in dnf5-5.2.10.0-2.fc41 -- i.e. 
https://bodhi.fedoraproject.org/updates/FEDORA-2025-665751b0e4

Ideas welcome, thanks,

Richard.

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

Re: Proposal: Allow all packagers to push empty commits to any package

[Miro Hrončok]

On 20. 02. 25 17:59, Mattia Verga via devel wrote:

Example: the package maintainer applies changes to the spec file, but
doesn't build the package because they're still tweaking it (or just
because they're building it in a side tag with other pieces). Now any
packager can jump in, trigger an empty commit and build the package. I
know that the same problem may happen with provenpackagers, but,
ideally, provenpackagers are usually considered more "responsible"...


In that case, they can already build the package today. Except without the 
commit.

An even as a provenpackager, I would not usually think of that situation when 
bump-builidng stuff.


--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok

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

Re: Orphaning java-diff-utils

[Christiano Anderson]

Hi,

Good to hear that it works without jgit, and that you adopted 
java-diff-utils :)


Best,

Christiano

On 20/02/2025 13:25, Jiri Vanek wrote:
As far as I know, java-diff utils can work happily without jgit. Only 
they will miss one diff algorithm.
I had excluded it in past - https://src.fedoraproject.org/rpms/java- 
diff-utils/c/38304b943ffba9cdb0b83a062b1c95d6c2c2d09e?branch=epel9


Btw I seesm to be owner of that package. So please, do nto orphan it :)

On 7/31/24 4:48 AM, Christiano Anderson wrote:

Hi,

I have orphaned the java-diff-utils package, which fails to build due 
to broken and unmaintained dependency jgit.


Thanks

Christiano




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

ELN SIG meeting minutes for 20 Feb

[Yaakov Selkowitz]

Text Log: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-02-20/eln.2025-02-20-20.00.log.txt
HTML Log: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-02-20/eln.2025-02-20-20.00.log.html
Text Minutes: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-02-20/eln.2025-02-20-20.00.txt
HTML Minutes: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-02-20/eln.2025-02-20-20.00.html



=
# #meeting:fedoraproject.org: eln
=

Meeting started by @yselkowitz:fedora.im at 2025-02-20 20:00:42


Meeting summary
---
* TOPIC: Init process (@yselkowitz:fedora.im, 20:00:59)
* TOPIC: New business (@yselkowitz:fedora.im, 20:05:01)
* TOPIC: Old business (@yselkowitz:fedora.im, 20:20:53)
* LINK: https://github.com/fedora-eln/eln/issues/192 
(@yselkowitz:fedora.im, 20:22:36)
* INFO: desktop artwork submissions are open for one more week, 
options will come up for vote next week (@yselkowitz:fedora.im, 20:26:30)
* LINK: https://github.com/fedora-eln/eln/issues/206 
(@yselkowitz:fedora.im, 20:26:36)
* LINK: https://github.com/fedora-eln/eln/issues/211 
(@yselkowitz:fedora.im, 20:35:33)

* TOPIC: Open floor (@yselkowitz:fedora.im, 20:52:17)

Meeting ended at 2025-02-20 21:01:05

Action items


People Present (lines said)
---
* @yselkowitz:fedora.im (59)
* @tdawson:fedora.im (24)
* @conan_kudo:matrix.org (16)
* @nhanlon:beeper.com (16)
* @zodbot:fedora.im (5)
* @salimma:fedora.im (3)
* @meetbot:fedora.im (3)
* @davide:cavalca.name (1)


--
Yaakov Selkowitz
Principal Software Engineer, Emerging RHEL
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: Heads-up: Updating python-aiohttp to 3.11.12 in F43/Rawhide and possibly F42/Branched

[Romain Geissler via devel]

Hi Ben,

I am not maintainer/co-maintainer for any of these packages so I cannot give 
you any consent.

On my side I had submitted the pytho-yarl & python-uvloop upgrades in 
anticipation of their branching in EPEL 10, as I would need these dependencies 
(and python-aiohttp) in RHEL 10. So would it be ok to include EPEL 10 in 
addition to Fedora 42/43 in your request ?

Thanks,
Romain
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: copy-jdk-configs

[Jiri Vanek]

Right, Orion, may you confirm?

I;m quite surprised you hit it, as it was done before f43 forked, and all jdks 
in f42 got the support already removed. I had also did some builds in koji 
since that time, and tehy looks corrreclty copy-jdk-configs-free.

TY!!!
 J.

On 2/5/25 2:52 PM, Mikolaj Izdebski wrote:

On Sun, Feb 2, 2025 at 4:20 PM Orion Poplawski  wrote:


copy-jdk-configs was just retired with this note:

Paralel installs are going to be remove from JDK. Package existed only
to support that

but some packages still require it:

java-21-openjdk-headless-1:21.0.6.0.7-1.fc42.x86_64
java-21-openjdk-headless-fastdebug-1:21.0.6.0.7-1.fc42.x86_64
java-21-openjdk-headless-slowdebug-1:21.0.6.0.7-1.fc42.x86_64
java-latest-openjdk-headless-1:23.0.2.0.7-1.rolling.fc42.x86_64
java-latest-openjdk-headless-fastdebug-1:23.0.2.0.7-1.rolling.fc42.x86_64
java-latest-openjdk-headless-slowdebug-1:23.0.2.0.7-1.rolling.fc42.x86_64

This is broken the install of octave (and I imagine others) that require
java-21-openjdk-headless.


Is this still a problem?
 From what I can see java-21-openjdk was updated to no longer require
copy-jdk-configs.

--
Mikolaj



--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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




--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Allow all packagers to push empty commits to any package

[Michael J Gruber]

Am Do., 20. Feb. 2025 um 13:28 Uhr schrieb Richard W.M. Jones
:
>
> On Thu, Feb 20, 2025 at 01:17:02PM +0100, Miro Hrončok wrote:
> > Hello.
> >
> > With the recent discussions about provenpackagers in Fedora, I
> > recently got an idea.
> >
> > One of the common needs for provenpackagers is to simply "bump and
> > rebuild" a set of dependencies.
> >
> > All packagers are already able to build anything (except a very
> > specific and small set of specially-signed packages). However, to
> > bump the package, they need commit rights. For that reason,
> > provenpackager rights are often required.
> >
> > With the wide adoption of %autorelease, such bump commits are empty,
> > which should be easy to verify.

Wide, well, ...

> > What if we allowed all packagers to push empty commit to any
> > package? That should eliminate *some* need for provenpackager
> > access. We would also communicate in our policies that such bumps do
> > not require prior agreement with the maintainers to avoid confusion
> > about "what are we allowed to do".
>
> Seems like a sensible proposal.  Some possible modifications:

Good so far.

>  - Limit this only to rawhide?
>
>  - If we don't restrict it only to Rawhide, should we encourage the
>packager to preserve ffwd to the rawhide branch, if that is
>currently the case?  [Whatever the technical term for that is.]
>

That is an issue due to how we use git to drive builds without a
common guideline for branch usage (fast forward merges only, arbitrary
merges, merge down vs up, cherry-picks with diverging branches,...).

For example:
Package A in F42 has a mass rebuild commit on top of F41.
Packager B wants to bump both with an empty commit for a rebuild.
Does maintainer of A want non-diverging branches at the expense of a
bogus "f42 mass rebuild" commit in the f41 branch?

Also, %autorelease does not quite fly with merges yet (release
numbering, exclusion of bogus commits from changelog).

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: Proposal: Allow all packagers to push empty commits to any package

[Neal Gompa]

On Thu, Feb 20, 2025 at 7:59 AM Miro Hrončok  wrote:
>
> On 20. 02. 25 13:51, Michael J Gruber wrote:
> >>> With the wide adoption of %autorelease, such bump commits are empty,
> >>> which should be easy to verify.
> > Wide, well, ...
>
> Roughly 39% based on a simple grep for %\{?autorelease
>

What does that number look like when we exclude rust2rpm managed packages?



-- 
真実はいつも一つ！/ 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: Proposal: Allow all packagers to push empty commits to any package

[Dmitry Belyavskiy]

On Thu, Feb 20, 2025 at 1:17 PM Miro Hrončok  wrote:

>
> What if we allowed all packagers to push empty commit to any package? That
> should eliminate *some* need for provenpackager access. We would also
> communicate in our policies that such bumps do not require prior agreement
> with
> the maintainers to avoid confusion about "what are we allowed to do".
>

I don't like this idea. It will cause stupid rebases that are completely
missed until you suddenly have to push smth urgently and see that they
can't just merge.
It's not a big deal for rawhide itself but if you use rawhide as a starting
point to cherry-pick downwards, it's more problematic.

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

Proposal: Allow all packagers to push empty commits to any package

[Miro Hrončok]

Hello.

With the recent discussions about provenpackagers in Fedora, I recently got an 
idea.


One of the common needs for provenpackagers is to simply "bump and rebuild" a 
set of dependencies.


All packagers are already able to build anything (except a very specific and 
small set of specially-signed packages). However, to bump the package, they 
need commit rights. For that reason, provenpackager rights are often required.


With the wide adoption of %autorelease, such bump commits are empty, which 
should be easy to verify.


What if we allowed all packagers to push empty commit to any package? That 
should eliminate *some* need for provenpackager access. We would also 
communicate in our policies that such bumps do not require prior agreement with 
the maintainers to avoid confusion about "what are we allowed to do".


--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok

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

Re: Proposal: Allow all packagers to push empty commits to any package

[Cristian Le via devel]

On 2025/02/20 13:17, Miro Hrončok wrote:

What if we allowed all packagers to push empty commit to any package? 
That should eliminate *some* need for provenpackager access. We would 
also communicate in our policies that such bumps do not require prior 
agreement with the maintainers to avoid confusion about "what are we 
allowed to do".


The wording and responsibility of such power would be important. I think 
it would still be preferred to try an make a PR and communicate with the 
maintainers first to figure out if they have any plans for other changes 
before/after the bump. But otherwise it could be a good workaround for 
needing provenpackager access.


How would such a check be enforced though?
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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