Re: convert everything to rpmautospec?

On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote: > -1 for existing packages certainly - none of my git commit logs > are written with the expectation that they will double as package > changelogs so doing so may break the changelog. Yes, I think rpm changelog is for users of t

Re: convert everything to rpmautospec?

> Hi everyone, > > I'm revisting the topic of rpmautospec because I was doing some work > on various packages, and it's annoying that some packages are using > rpmautospec and others are not. > > All my packages have been converted, so in day-to-day work, I don't > even think about %changelog. Wh

Re: convert everything to rpmautospec?

On Sun, Apr 07, 2024 at 05:55:08PM +0100, Sérgio Basto wrote: > I also still see some issues in %autorelease , why fix a typo is a new > release ? Either the fix is important and you rebuild and then you _must_ have a new release, because koji requires a unique NEVRA. Or the fix can wait, so you

Re: convert everything to rpmautospec?

On Sun, Apr 07, 2024 at 12:58:04PM -0400, Neal Gompa wrote: > No. I do not want to use rpmautospec as it currently exists. It does > not help me. It does not achieve anything for me. It breaks my > packages for building outside of Fedora Koji. It doesn't even make > things better for supporting aut

Re: convert everything to rpmautospec?

On Sun, Apr 07, 2024 at 06:44:57PM +0200, Emmanuel Seyman wrote: > * Zbigniew Jędrzejewski-Szmek [07/04/2024 15:56] : > > > > On Sun, Apr 07, 2024 at 05:47:57PM +0200, Emmanuel Seyman wrote: > > > > > > This doesn't solve the problem you have so that's a no-go as well. > > > > In what way doesn't

Re: convert everything to rpmautospec?

Zbyszek While I am in favor of autospec, I agree with the comment that it doesn't work well outside of koji. - builds in copr work. The builds themselves work, but in my experience they do not increase the `release`, nor do they handle `autochangelog`. Are there ways around it if we want

Re: convert everything to rpmautospec?

On Mon, Apr 08, 2024 at 12:38:47AM +0200, Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > I'm revisting the topic of rpmautospec because I was doing some work > > on various packages, and it's annoying that some packages are using > > rpmautospec and others are not. > > The

Re: convert everything to rpmautospec?

On Sun, Apr 07, 2024 at 09:08:49PM -0700, Carlos Rodriguez-Fernandez wrote: > On 4/7/24 21:07, Carlos Rodriguez-Fernandez wrote: > > Not all commits correspond with a new release downstream, and not all > > commit messages are relevant to the end user to be part of the change > > log. For example,

Re: convert everything to rpmautospec?

On Mon, Apr 08, 2024 at 09:08:19AM +0200, Miroslav Lichvar wrote: > On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote: > > -1 for existing packages certainly - none of my git commit logs > > are written with the expectation that they will double as package > > changelogs so doing

Re: convert everything to rpmautospec?

On Mon, Apr 08, 2024 at 12:22:35AM +0200, Kevin Kofler via devel wrote: > Emmanuel Seyman wrote: > > I've noticed a trend in proposed changes in the way Fedora works. > > I am fed up of this salami tactic as well. When we complain about the new > stuff, we invariably get told "don't worry, you do

Re: Three steps we could take to make supply chain attacks a bit harder

On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote: > I wrote: > > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek > > wrote: > >> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special > >> detection of python, and it found /usr/bin/python3.13t that

Re: Three steps we could take to make supply chain attacks a bit harder

On Mon, Apr 8, 2024 at 5:37 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote: > > I wrote: > > > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek > > > wrote: > > >> Hmm, why? Oh, rpm uses cmake, and cmake has it

Re: "fedpkg local" builds fail for rust packages

On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote: > On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber > wrote: > > > > So you're saying that those packages are in the repos for everyone but > > not meant to be installed by anyone (besides mock chroots), and that is > > how and why th

Re: Three steps we could take to make supply chain attacks a bit harder

On Mon, Apr 08, 2024 at 05:52:07AM -0400, Neal Gompa wrote: > On Mon, Apr 8, 2024 at 5:37 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote: > > > I wrote: > > > > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-S

Re: convert everything to rpmautospec?

V Sun, Apr 07, 2024 at 03:15:16PM +, Zbigniew Jędrzejewski-Szmek napsal(a): > I think it's time to switch to rpmautospec completely. > Thus, the proposal: > - new packages MUST use rpmautospec > - packagers SHOULD convert their packages > - provenpackagers MAY convert existing packages > (e.g

Re: "fedpkg local" builds fail for rust packages

On Mon, Apr 8, 2024 at 6:17 AM Richard W.M. Jones wrote: > > On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote: > > On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber > > wrote: > > > > > > So you're saying that those packages are in the repos for everyone but > > > not meant to be in

No Open NeuroFedora Meeting: Monday, 08 April 2024 (today) at 13:00 UTC

Hi folks, We won't have the NeuroFedora meeting today. We'll continue in 2 weeks as per our schedule. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature -- ___

Re: convert everything to rpmautospec?

On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote: > V Sun, Apr 07, 2024 at 03:15:16PM +, Zbigniew Jędrzejewski-Szmek > napsal(a): > > I think it's time to switch to rpmautospec completely. > > Thus, the proposal: > > - new packages MUST use rpmautospec > > - packagers SHOULD convert

Re: convert everything to rpmautospec?

V Mon, Apr 08, 2024 at 10:49:42AM +, Zbigniew Jędrzejewski-Szmek napsal(a): > On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote: > > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL > > minor > > releases). > > Hmm, can you provide describe the workflow that

Re: convert everything to rpmautospec?

On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar wrote: > > V Mon, Apr 08, 2024 at 10:49:42AM +, Zbigniew Jędrzejewski-Szmek > napsal(a): > > On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote: > > > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL > > > minor > > >

Re: convert everything to rpmautospec?

On Mon, Apr 08, 2024 at 01:11:22PM +0200, Petr Pisar wrote: > V Mon, Apr 08, 2024 at 10:49:42AM +, Zbigniew Jędrzejewski-Szmek > napsal(a): > > On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote: > > > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL > > > mino

Re: convert everything to rpmautospec?

On 08/04/2024 11.31, Richard W.M. Jones wrote: On Mon, Apr 08, 2024 at 12:22:35AM +0200, Kevin Kofler via devel wrote: Emmanuel Seyman wrote: I've noticed a trend in proposed changes in the way Fedora works. I am fed up of this salami tactic as well. When we complain about the new stuff, we in

Re: convert everything to rpmautospec?

On neděle 7. dubna 2024 17:15:16 CEST Zbigniew Jędrzejewski-Szmek wrote: > Hi everyone, > > I'm revisting the topic of rpmautospec because I was doing some work > on various packages, and it's annoying that some packages are using > rpmautospec and others are not. > > All my packages have been co

Re: convert everything to rpmautospec?

* Zbigniew Jędrzejewski-Szmek [08/04/2024 09:02] : > > Well, you and Kevin see "salami tactics" (whatever that may be), FTR, I have no idea what "salami tactics" is. > while I see normal engineering practice: some new idea is hatched, > it's implemented and used narrowly, them it's applied by def

Re: F41 Change Proposal: Pytest 8 (self-contained)

On Sat, Apr 6, 2024 at 12:46 PM Sandro wrote: > On 05-04-2024 23:45, Aoife Moloney wrote: > > == Summary == > > > > Update to a new upstream release of pytest that is not completely > > compatible with previous releases. Pytest 8 is a major upstream > > release removing a lot of deprecated functi

Fedora rawhide compose report: 20240408.n.0 changes

OLD: Fedora-Rawhide-20240407.n.0 NEW: Fedora-Rawhide-20240408.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 6 Dropped packages:8 Upgraded packages: 132 Downgraded packages: 0 Size of added packages: 477.63 KiB Size of dropped packages

Re: F41 Change Proposal: Pytest 8 (self-contained)

I got a list of all packages BuildRequiring pytest using this command: $ repoquery --repo=rawhide{,-source} --whatrequires python3-pytest --recursive | grep src$ | pkgname | sort | uniq > packages.txt FreeIPA is not there because pytest build time dependency is disabled via bcond. On Mon, Apr 8,

Re: convert everything to rpmautospec?

So someone wanted to use rpmautospec and was willing to do the work, putting things together as an opt-in feature. Perfect. Now, I don't see any problem if some time later someone revisits the topic and proposes to go further. I don't see anything unfriendly here. Everything was set or decided at

Re: convert everything to rpmautospec?

-1 as well, for all the reasons already mentioned. On Mon, Apr 8, 2024 at 8:28 AM Iñaki Ucar wrote: > So someone wanted to use rpmautospec and was willing to do the work, > putting things together as an opt-in feature. Perfect. > > Now, I don't see any problem if some time later someone revisits

Re: convert everything to rpmautospec?

On Mon, Apr 8, 2024 at 3:28 PM Iñaki Ucar wrote: > > So someone wanted to use rpmautospec and was willing to do the work, putting > things together as an opt-in feature. Perfect. > > Now, I don't see any problem if some time later someone revisits the topic > and proposes to go further. I don't

Re: convert everything to rpmautospec?

V Mon, Apr 08, 2024 at 11:37:48AM +, Zbigniew Jędrzejewski-Szmek napsal(a): > On Mon, Apr 08, 2024 at 01:11:22PM +0200, Petr Pisar wrote: > > RHEL do updates into older minor distribution versions. E.g. you might want > > to > > build for RHEL 9.2 and RHEL 9.3. Users staying on 9.2 should upda

Re: convert everything to rpmautospec?

On Mon, 8 Apr 2024 at 15:47, Fabio Valentini wrote: > On Mon, Apr 8, 2024 at 3:28 PM Iñaki Ucar wrote: > > > > So someone wanted to use rpmautospec and was willing to do the work, > putting things together as an opt-in feature. Perfect. > > > > Now, I don't see any problem if some time later som

Re: convert everything to rpmautospec?

V Mon, Apr 08, 2024 at 11:37:48AM +, Zbigniew Jędrzejewski-Szmek napsal(a): > OK, so you mean that the approach with '.' at the end of Release > doesn't work. Yes, that case is not supported very well. > > There is no great solution here, but there are a few options. Which > one makes the most

Re: convert everything to rpmautospec?

On 08/04/2024 10:28, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Apr 08, 2024 at 09:08:19AM +0200, Miroslav Lichvar wrote: On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote: -1 for existing packages certainly - none of my git commit logs are written with the expectation that t

Re: convert everything to rpmautospec?

Dne 08. 04. 24 v 2:55 odp. Emmanuel Seyman napsal(a): FTR, I have no idea what "salami tactics" is. https://en.wikipedia.org/wiki/Salami_slicing_tactics Something that would be unacceptable to be done in one step is possible when you do that in tiny steps. You cannot eat whole salami, but you

Re: convert everything to rpmautospec?

On 08/04/2024 14:47, Fabio Valentini wrote: It is already supposed to be default / preferred since this Fedora 38 Change: https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default I find that quite interesting because while I may have read it at the time I had certainly long since forgotte

Re: convert everything to rpmautospec?

On Mon, Apr 8, 2024 at 2:26 PM Tom Hughes via devel wrote: > > On 08/04/2024 14:47, Fabio Valentini wrote: > > > It is already supposed to be default / preferred since this Fedora 38 > > Change: > > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default > > I find that quite interesting be

Fedora 40 compose report: 20240408.n.0 changes

OLD: Fedora-40-20240407.n.0 NEW: Fedora-40-20240408.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 3 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded

Re: convert everything to rpmautospec?

Thank you Zbigniew and Miro for the link. On 4/8/24 02:18, Zbigniew Jędrzejewski-Szmek wrote: On Sun, Apr 07, 2024 at 09:08:49PM -0700, Carlos Rodriguez-Fernandez wrote: On 4/7/24 21:07, Carlos Rodriguez-Fernandez wrote: Not all commits correspond with a new release downstream, and not all com

Orphaning some Java packages

Hi, I'm orphaning a couple of packages of mine which I no longer use or were used as a dependency of a package I've maintained before and am no longer using: Packages without co-maintainers: jolokia-jvm-agent prometheus-simpleclient-java prometheus-jmx-exporter P

Re: convert everything to rpmautospec?

Zbigniew Jędrzejewski-Szmek venit, vidit, dixit 2024-04-07 17:15:16: > Hi everyone, > > I'm revisting the topic of rpmautospec because I was doing some work > on various packages, and it's annoying that some packages are using > rpmautospec and others are not. > > All my packages have been conver

Re: convert everything to rpmautospec?

Am 08.04.24 um 14:55 schrieb Emmanuel Seyman: Well, you and Kevin see "salami tactics" (whatever that may be), FTR, I have no idea what "salami tactics" is. Since apperently multiple people don't know the term: https://en.wikipedia.org/wiki/Salami_slicing_tactics Regards Kilian --

Re: convert everything to rpmautospec?

On Mon, Apr 08, 2024 at 07:21:40AM -0400, Neal Gompa wrote: > On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar wrote: > > It's bascially the same problem as Fedora has when users upgrade from > > Fredora > > 40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade > > path > > between F

Re: Schedule for Monday's FESCo Meeting (2024-04-08)

On Sat, Apr 06, 2024 at 10:45:52AM -0700, Kevin Fenzi wrote: > = Discussed and Voted in the Ticket = > > Change: GNU Toolchain F41 > https://pagure.io/fesco/issue/3181 > APPROVED (+6, 3, -0) Not that it matters for anything, but it's actually (+6, 0, 0), i.e. there were no abstaining votes. (I wa

Re: convert everything to rpmautospec?

Am 08.04.24 um 20:12 schrieb Michel Lind: (this might require coordination with RH's Leapp developers and AlmaLinux's ELevate developers, to make sure those support upgrading to lower NEVRAs too) Would have a major EL release have a lower package NEVRA? Mmmh, how many fedora releases a

Re: Schedule for Monday's FESCo Meeting (2024-04-08)

On Mon, Apr 08, 2024 at 06:19:31PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Apr 06, 2024 at 10:45:52AM -0700, Kevin Fenzi wrote: > > = Discussed and Voted in the Ticket = > > > > Change: GNU Toolchain F41 > > https://pagure.io/fesco/issue/3181 > > APPROVED (+6, 3, -0) > > Not that it m

Re: convert everything to rpmautospec?

Zbigniew Jędrzejewski-Szmek wrote: > And sorry, but saying to "process pull requests quickly" is just naive. > Busy packages often have many different pull requests concurrently, and > some of them need discussion and fixes and work in other places before > they can be merged. Generally, there sho

Re: Three steps we could take to make supply chain attacks a bit harder

Zbigniew Jędrzejewski-Szmek wrote: > So… this is what I'm talking about: there is no obvious way to > figure out what to set. Looking at the logs and trying to figure out > some variables from that is not very attractive. The comments at the top of the relevant Find*.cmake module are the best sou

Re: convert everything to rpmautospec?

On Mon, Apr 08, 2024 at 08:47:20PM +0200, Leon Fauster via devel wrote: > Am 08.04.24 um 20:12 schrieb Michel Lind: > >(this might require coordination with RH's Leapp developers and > >AlmaLinux's ELevate developers, to make sure those support upgrading > >to lower NEVRAs too) > > Wou

Summary/Minutes from today's FESCo Meeting (2024-04-08)

Text Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-08/fesco.2024-04-08-19.30.log.txt HTML Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-08/fesco.2024-04-08-19.30.log.html Text Minutes: https://meetbot.fedoraproject.org/meeting_m

Re: convert everything to rpmautospec?

Am 08.04.24 um 22:22 schrieb Michel Lind: On Mon, Apr 08, 2024 at 08:47:20PM +0200, Leon Fauster via devel wrote: Am 08.04.24 um 20:12 schrieb Michel Lind: (this might require coordination with RH's Leapp developers and AlmaLinux's ELevate developers, to make sure those support upgradin

[Test-Announce] Fedora Linux 40 Go/No-Go Meeting: 2024-11-04

Happy Monday folks! On Thursday 11th April, the Fedora Linux 40 Final Go/No-Go meeting[1] will be held at 1700 UTC in #meeting:fedoraproject.org channel on Matrix. At this time, we will determine the status of the F40 Final release for the 16th April, which is the early target date[2]. For more i

Re: convert everything to rpmautospec?

On Mon, Apr 8, 2024 at 5:22 PM Leon Fauster via devel wrote: > > Am 08.04.24 um 22:22 schrieb Michel Lind: > > On Mon, Apr 08, 2024 at 08:47:20PM +0200, Leon Fauster via devel wrote: > >> Am 08.04.24 um 20:12 schrieb Michel Lind: > >>> (this might require coordination with RH's Leapp developer

Help Needed for a tricky bug for Fedora Linux 40

Hi folks, There is a bug in the Fedora Blocker Bugs app that has a lot of us stumped on how to resolve it, so I wanted to highlight it in the hopes that someone might know how to either fix it or maybe even verify if a few of th

[Test-Announce] [Now Playing] Intel Open CL Test Day

Hey All, We're hosting an Intel OpenCL Test Day[0] and we need your expertise! Join us on 2024-04-09 to put Intel's OpenCL through its paces. Your feedback will be invaluable in shaping the future of this technology. Together, let's push the boundaries of performance and innovation. Intel's OpenC