subject:"Re\: convert everything to rpmautospec\?"

On Mon, Apr 08, 2024 at 01:12:38PM -0500, Michel Lind wrote:
> 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 Fedoras is not maintained anymore and users need to do "dnf
> > > distro-sync" to ignore the RPM versioning.
> > >
> > > All that stems from tha fact that a number of commits between parallelly
> > > supported braches is not monotonic.
> > >
> > 
> > We did this long before rpmautospec existed. We switched to this
> > behavior in Fedora 23 because we have never fully maintained "upgrade
> > paths" across releases.
> > 
> 
> Per private message with Neal this seems to be the Change that brought
> it about:
> 
> https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades
> 
> I'm ... a bit surprised that we don't seem to have any documentation
> stating explicitly that the assumption that NEVRAs in a newer release
> are no longer assumed to be monotonically higher.

That Change was primarily about replacing fedup with dnf-plugin-system-upgrade,
changing from a custom-initrd-based solution that was rather fragile, to
a special systemd target during early boot.

dnf-plugin-system-upgrade uses 'distro-sync' because that's the most
reliable and easy way to do the upgrade, suitable for end users.
But this doesn't necessarilly mean that this is the only upgrade
method that can be used. That Change certainly wasn't intended to
change the packaging guidelines.

In general, we still keep the upgrade path. It's not enforced all
the time, but I think it's still good style.

There is a lot of code out there that doesn't handle downgrades
very well, in particular if there is data in files or state.
So it seems always a bit iffy when a version is downgraded during
a system upgrade. It seems that in practice, this actually happens
mostly when people forget to build for rawhide or branched, not
when they intentionally update a package in older releases only.

> e.g. packaging guidelines still say "Rawhide is allowed to lag
> *temporarily*" (emphasis mine)
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily
> 
> I suppose the user facing documentation does say that upgrading using
> only DNF is not tested -- but there's no guideline about loosening
> monotonicity provided to packagers as far as I can tell.
> 
> https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/#_can_i_upgrade_between_fedora_releases_using_only_dnf

And I think that's all good ;)

> - should we update the packaging docs? Does this need to be a new Change
>   Proposal or does this just need to go through the Fedora packaging
>   committee? (Those involved in the Change like zbyszek can probably
>   advise here)

IMO, no.

> - should we extend this further and say, if we no longer assume NEVRAs
>   are monotonically increasing in a new release, we should allow
>   packagers to use this opportunity to drop epochs in Rawhide? (likely
>   with proper announcement beforehand in devel@)

IMO, no. The fact that you can upgrade between versions and mix
packages from different releases, for testing or other purposes, is
great. I wouldn't throw this out just to save the bit of hassle
that is required to deal with Epochs.

>   (this might require coordination with RH's Leapp developers and
>   AlmaLinux's ELevate developers, to make sure those support upgrading
>   to lower NEVRAs too)

It'd probably cause pain for our downstreams. While not a strict
blocker, it's yet anothe reason to not do this.

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: convert everything to rpmautospec?

On Mon, Apr 08, 2024 at 04:11:14PM +0200, Petr Pisar wrote:
> 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 sense depends a lot on the package. But in particular:
> > - just switch to non-autorelease numbering when introducing the
> >   minorbump, e.g. just do Release: 15%{?dist}.1 and then .2, etc.
> > 
> > Looking at the docs again, the docs are not great, and we should
> > support this case better. This certainly needs looking into.
> > 
> Now I recalled yet another downstream issue: Importing without a git history
> will reset release numbers. That hashes RPM-dependencies which refer to
> a specific release (like "Conflicts: foo < 1-20" after a package split). One
> should of course carefully check them on import, but forking whole
> distribution like that into a new downstream distribution warrants there will
> remain gems like this.

I can feel the pain, but realistically, with 31% of specs in Fedora using
rpmautospec (as discussed in another leg of the thread), any downstream will
need to solve this issue programatically. Whether it's 15%, 30%, or 90%
of packages, doesn't matter at this point… it must be handled by a script.
Essentially this ship sailed when rpmautospec was officially allowed
in Fedora and was used in the first hundred packages. At that point,
downstream has no choice but to adapt.

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: convert everything to rpmautospec?

On Tue, Apr 09, 2024 at 12:57:33PM -0400, Neal Gompa wrote:
> On Tue, Apr 9, 2024 at 12:56 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote:
> > >
> > > Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a):
> > > > And we already have a significant fraction of packages using 
> > > > rpmautospec,
> > >
> > >
> > > Actually, could you quantify the "significant fraction"?
> >
> > 7399 / 23912 = 31%.
>
> How much of it is non-Rust and non-Go?

3720 / 19454 = 19% when '^(rust|golang)-.*\.spec' is filtered out
(which matches most but not all rust packages).

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: convert everything to rpmautospec?

2024-04-09 Thread Fabio Valentini

On Tue, Apr 9, 2024 at 6:58 PM Neal Gompa  wrote:
>
> On Tue, Apr 9, 2024 at 12:56 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote:
> > >
> > > Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a):
> > > > And we already have a significant fraction of packages using 
> > > > rpmautospec,
> > >
> > >
> > > Actually, could you quantify the "significant fraction"?
> >
> > 7399 / 23912 = 31%.
> >
>
> How much of it is non-Rust and non-Go?

There's ~3000 Rust packages, 99.9% of which use rpmautospec, so you
can subtract about 3000 from that number.

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

Re: convert everything to rpmautospec?

On Tue, Apr 09, 2024 at 03:38:07PM +0200, Gerd Hoffmann wrote:
> > In particular:
> > - local builds work, I do them all the time, with 'fedpkg local' or
> >   through an srpm.
> 
> Using rpmbuild directly needs some adaption though:
> 
>  (1) Use 'rpmautospec calculate-release' to figure what the release
>  number is.
>  (2) Pass that to rpmbuild using --define "_rpmautospec_release_number $nr".

I don't use rpmbuild directly very often, but:
  fedpgk srpm
  fedpkg local
work fine both when there are uncommitted modifications and when not.
I actually use "fedpkg srpm && mock $options $(ls -1tr *.src.rpm|tail -n1)"
all the time, and that also works with and without uncommitted modifications.

What goes wrong if _rpmautospec_release_number is not difined?

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: convert everything to rpmautospec?

2024-04-09 Thread Neal Gompa

On Tue, Apr 9, 2024 at 12:56 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote:
> >
> > Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a):
> > > And we already have a significant fraction of packages using rpmautospec,
> >
> >
> > Actually, could you quantify the "significant fraction"?
>
> 7399 / 23912 = 31%.
>

How much of it is non-Rust and non-Go?



-- 
真実はいつも一つ！/ 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: convert everything to rpmautospec?

On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote:
> 
> Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a):
> > And we already have a significant fraction of packages using rpmautospec,
> 
> 
> Actually, could you quantify the "significant fraction"?

7399 / 23912 = 31%.

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: convert everything to rpmautospec?

On Tue, Apr 09, 2024 at 10:04:11AM +0200, Remi Collet wrote:
> Le 07/04/2024 à 17:15, Zbigniew Jędrzejewski-Szmek a écrit :
> > Thus, the proposal:
> > - new packages MUST use rpmautospec
> > - packagers SHOULD convert their packages
> > - provenpackagers MAY convert existing packages
> >(e.g. when they want to push some fix or separately from other
> > work)
> > - people submitting pull requests against src.fp.o MAY also
> >include a conversion in the pull request and packagers SHOULD
> >merge it.
> 
> Big -1 to all
> 
> git log IS NOT a package changelog
> 
> Read https://keepachangelog.com/en/1.1.0/

Then it's great the %autochangelog is designed to produce a
human-readable changelog that omits what should be omitted and lists
the things that are relevant to users. It even adds dates and version
information and authorship just like described on the page you linked
;--]

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: convert everything to rpmautospec?

2024-04-09 Thread Michel Lind

On Tue, Apr 09, 2024 at 02:20:37PM +0200, Petr Pisar wrote:
> > - should we extend this further and say, if we no longer assume NEVRAs
> >   are monotonically increasing in a new release, we should allow
> >   packagers to use this opportunity to drop epochs in Rawhide? (likely
> >   with proper announcement beforehand in devel@)
> > 
> Who will check reverse dependncies? E.g. perl will drop "Epoch: 4". Who will
> check that no other package "Requires: perl > 4:..."? I remind that
> fedora-ci.koji-build.rpmdeplint.functional gating test is still not enforced
> globally.
> 
Good point. I'm still following up on trying to get the current gating
tests enabled for EPEL -- and there are still occasions where they don't
run on Fedora too.

There's also the issue that, AIUI, the installability check tests
whether the packages in the update set are installable, but does not
check whether they break any revdep... room for improvement there, and
maybe that can be tackled first.

Best regards,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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: convert everything to rpmautospec?

2024-04-09 Thread Gerd Hoffmann

> In particular:
> - local builds work, I do them all the time, with 'fedpkg local' or
>   through an srpm.

Using rpmbuild directly needs some adaption though:

 (1) Use 'rpmautospec calculate-release' to figure what the release
 number is.
 (2) Pass that to rpmbuild using --define "_rpmautospec_release_number $nr".

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

Re: convert everything to rpmautospec?

2024-04-09 Thread Petr Pisar

V Mon, Apr 08, 2024 at 01:12:38PM -0500, Michel Lind napsal(a):
> - should we update the packaging docs? Does this need to be a new Change
>   Proposal or does this just need to go through the Fedora packaging
>   committee? (Those involved in the Change like zbyszek can probably
>   advise here)
> 
FPC with an anouncement on devel list should be enough.

> - should we extend this further and say, if we no longer assume NEVRAs
>   are monotonically increasing in a new release, we should allow
>   packagers to use this opportunity to drop epochs in Rawhide? (likely
>   with proper announcement beforehand in devel@)
> 
Who will check reverse dependncies? E.g. perl will drop "Epoch: 4". Who will
check that no other package "Requires: perl > 4:..."? I remind that
fedora-ci.koji-build.rpmdeplint.functional gating test is still not enforced
globally.

-- Petr


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

Re: convert everything to rpmautospec?

2024-04-09 Thread Remi Collet


Le 08/04/2024 à 18:43, Michael J Gruber a écrit :


How absurd!


That is rude, and ONLY your PoV.


To summarize, there is no agreement on a unique
workflow, and having one to become the only allowed
seems to me as a terrible idea.


Remi
--
___
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: convert everything to rpmautospec?

2024-04-09 Thread Remi Collet


Le 07/04/2024 à 17:15, Zbigniew Jędrzejewski-Szmek a écrit :

Thus, the proposal:
- new packages MUST use rpmautospec
- packagers SHOULD convert their packages
- provenpackagers MAY convert existing packages
   (e.g. when they want to push some fix or separately from other
work)
- people submitting pull requests against src.fp.o MAY also
   include a conversion in the pull request and packagers SHOULD
   merge it.


Big -1 to all

git log IS NOT a package changelog

Read https://keepachangelog.com/en/1.1.0/



Remi

--
___
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: convert everything to rpmautospec?

2024-04-09 Thread Vít Ondruch



Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a):

And we already have a significant fraction of packages using rpmautospec,



Actually, could you quantify the "significant fraction"?


Thx


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: convert everything to rpmautospec?

2024-04-08 Thread Neal Gompa

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 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 are in between? :-)
> >>
> > If, say, EL9 inherits a Fedora 34 package with epoch set to 1, and we
> > allow Fedora epoch to be reset in Rawhide, and EL10 then inherits a
> > Fedora 40 package with epoch reset to 0 (change as suitable - more
> > likely to be EL10 from F40 and EL11 from F46, but in general there are 6
> > Fedora releases in between) -- then even if the version is higher
> > because the epoch is dropped, the EL(N+1) NEVRA will be lower.
>
>
> Fair enough. Such change could be scoped just for fedora and keeping
> the epoch for RHEL (I know it contradicts the plan). Anyway, as far as
> I understand it, epoch support will still be available and its not
> forbidden to use it, right? For some cases similar to xz-5.6-to-xz-5.4
> downgrades even necessary. Just wondering, why a reset of epoch in
> rawhide is desirable?
>

When the RHEL people notice, they conditionally drop the Epoch for
RHEL already. Epochs are not really necessary at all across
distribution release boundaries.



-- 
真実はいつも一つ！/ 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: convert everything to rpmautospec?

2024-04-08 Thread Leon Fauster via devel


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 upgrading
to lower NEVRAs too)


Would have a major EL release have a lower package NEVRA?
Mmmh, how many fedora releases are in between? :-)


If, say, EL9 inherits a Fedora 34 package with epoch set to 1, and we
allow Fedora epoch to be reset in Rawhide, and EL10 then inherits a
Fedora 40 package with epoch reset to 0 (change as suitable - more
likely to be EL10 from F40 and EL11 from F46, but in general there are 6
Fedora releases in between) -- then even if the version is higher
because the epoch is dropped, the EL(N+1) NEVRA will be lower.



Fair enough. Such change could be scoped just for fedora and keeping
the epoch for RHEL (I know it contradicts the plan). Anyway, as far as
I understand it, epoch support will still be available and its not
forbidden to use it, right? For some cases similar to xz-5.6-to-xz-5.4 
downgrades even necessary. Just wondering, why a reset of epoch in 
rawhide is desirable?


--
Leon







--
___
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: convert everything to rpmautospec?

2024-04-08 Thread 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 upgrading
> >to lower NEVRAs too)
> 
> Would have a major EL release have a lower package NEVRA?
> Mmmh, how many fedora releases are in between? :-)
> 
If, say, EL9 inherits a Fedora 34 package with epoch set to 1, and we
allow Fedora epoch to be reset in Rawhide, and EL10 then inherits a
Fedora 40 package with epoch reset to 0 (change as suitable - more
likely to be EL10 from F40 and EL11 from F46, but in general there are 6
Fedora releases in between) -- then even if the version is higher
because the epoch is dropped, the EL(N+1) NEVRA will be lower.

Cheers,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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: convert everything to rpmautospec?

2024-04-08 Thread Kevin Kofler via devel

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 should be no room for discussion there. Either the pull 
request is good, then merge it immediately, or it is not, then reject it 
immediately. People who want to contribute to Fedora packaging ought to know 
what they are doing, if not, just reject and let them submit a new pull 
request when they have done their homework.

> I guess we'll just have to agree to disagree. In the other part of the
> thread, a proposal that was floated to allow opt-out. I hope that's
> acceptable.

You have received a lot of all-negative feedback and one single message of 
support. So for me there is a clear consensus to NOT implement your proposal 
at all, not even with an opt-out option.

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

Re: convert everything to rpmautospec?

2024-04-08 Thread Leon Fauster via devel


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 are in between? :-)

--
Leon
--
___
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: convert everything to rpmautospec?

2024-04-08 Thread Michel Lind

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 Fedoras is not maintained anymore and users need to do "dnf
> > distro-sync" to ignore the RPM versioning.
> >
> > All that stems from tha fact that a number of commits between parallelly
> > supported braches is not monotonic.
> >
> 
> We did this long before rpmautospec existed. We switched to this
> behavior in Fedora 23 because we have never fully maintained "upgrade
> paths" across releases.
> 

Per private message with Neal this seems to be the Change that brought
it about:

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

I'm ... a bit surprised that we don't seem to have any documentation
stating explicitly that the assumption that NEVRAs in a newer release
are no longer assumed to be monotonically higher.

e.g. packaging guidelines still say "Rawhide is allowed to lag
*temporarily*" (emphasis mine)

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily

I suppose the user facing documentation does say that upgrading using
only DNF is not tested -- but there's no guideline about loosening
monotonicity provided to packagers as far as I can tell.

https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/#_can_i_upgrade_between_fedora_releases_using_only_dnf

So, questions:

- should we update the packaging docs? Does this need to be a new Change
  Proposal or does this just need to go through the Fedora packaging
  committee? (Those involved in the Change like zbyszek can probably
  advise here)

- should we extend this further and say, if we no longer assume NEVRAs
  are monotonically increasing in a new release, we should allow
  packagers to use this opportunity to drop epochs in Rawhide? (likely
  with proper announcement beforehand in devel@)

  (this might require coordination with RH's Leapp developers and
  AlmaLinux's ELevate developers, to make sure those support upgrading
  to lower NEVRAs too)

Best regards,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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: convert everything to rpmautospec?

2024-04-08 Thread Kilian Hanich via devel


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
--
___
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: convert everything to rpmautospec?

2024-04-08 Thread Michael J Gruber

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 converted, so in day-to-day work, I don't
> even think about %changelog. When working with other packages, I'll
> forget to update the Relase and/or %changelog. Today I was rebasing
> some pull requests in pagure, and the _only_ conflicts that I had were
> about Release and %changelog.
> 
> 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. when they want to push some fix or separately from other
>work)
> - people submitting pull requests against src.fp.o MAY also
>   include a conversion in the pull request and packagers SHOULD
>   merge it.
> 
> (FTR, 'rpmautospec convert' does the conversion, incl. the commit
> to dist-git. Manual conversion should not be used.)

An interesting proposal with unsurprising reactions from the expected
people ;)

Can I add +200 if others add -100, and what does that even mean? Kidding
aside, and putting the obvious "Makes my workflow work", "Destroys my
workflow", "Change? Hell no" aside, too, I think it's worthwhile to
take a step back and widen one's view towards the question:

Do we consider dist-git to be a version control system (vcs) for spec
files?

Historically we have not quite, which is no wonder given the cvs
heritage.  But, assuming for a moment that we do mean version control
seriously and look at the status quo ante rpmautospec ("legacy specs")
and what we do there:

- We put the version ("release" in our terms) of the spec file in the
  version controlled spec file.
- We put the log of the changes in the version controlled files.

How absurd!

Really, from the point of view of version control, anything that takes
this version information out of the versioned spec is better than legacy
specs. rpmautospec is the only such thing which we have right now.

On the practical side, I was sceptical about some shortcomings of
rpmautospec in the beginning, but it's really such a time (and nerve)
saver whenever you need to pick changes - be it from merge requests
against a moved head, from your own feature branches in dist-git forks
where you prepare changes, etc. All information is where it belongs
(change+log), and there are no artificial conflicts (release,
changelog) and no bogus dates.

Also, I find that many packages treat the dist-git log as more or less
worthless nuisance. rpmautospec helps you put both packager and user
info in one place (the commit message) and encourages to care about
both. Since some may not know:
```
Rebase to upstream x.y.z

- shiny new feature S
- various bug fixes

Also, we clean-up the spec file (white space, patch macros).
```
is a commit message which has both user info ("changelog", the first
line/header plus the dashed lines) and the info for other packagers -
how neat is that? You want it, too, admit it :)

We have other "vcs short-comings", of course, such as the fact that we
don't really use merges and feature branches in dist-git. Almost
consequently, rpmautospec does not deal well with merges. It does work
well with cherry-picks, though.

Since it's been mentioned: While (fast forward) merging the ubiquitious
"rebuild for..." commits down to lower releases does not do any "harm",
having a message like "rebuild for bar 24.7" in a release branch where
"bar" is at "23.3" is quite misleading. It's rooted in "cvs think" and
not using feature branches properly. rpmautospec can solves this easily
with cherry-picks now and, possibly, with merges later once it supports
merges better and we accept a true branch model in dist-git ;)

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: convert everything to rpmautospec?

2024-04-08 Thread Carlos Rodriguez-Fernandez

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
commit messages are relevant to the end user to be part of the change
log. For example, commits related with increasing gating test coverage
efforts, or setting up gating.yaml itself. Another example is linting
setting and/or configurations. How is that handled with autochangelog?
Can we tell it to skip certain commits? Or should we include it all?

Yes, you can skip %changelog for some commits with '[skip changelog]'
and provide additional content in the commit message which is not part
of the changelog. See
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.

Zbyszek

On 4/7/24 23:01, Miro Hrončok wrote:
> On 08. 04. 24 6:08, 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, commits related with increasing gating test coverage
>> efforts, or setting up gating.yaml itself. Another example is linting
>> setting and/or configurations. How is that handled with autochangelog?
>> Can we tell it to skip certain commits? Or should we include it all?
>
> Put [skip changelog] in the commit message.
>
> 
https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries

>

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: convert everything to rpmautospec?

2024-04-08 Thread Gary Buhrmaster

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 because while I may have read it at
> the time I had certainly long since forgotten that.

I read it at the time, and it was promised (at the time)
that rpmautospec would be a recommendation, and
not a requirement.  I would have strongly objected to
a MUST.

That rpmautospec works fine for some is great
(for them).  And it can be a good default for many
(if someone asked me how to package something
new, I would suggest they consider rpmautospec).
However, as long as it does not work 100% of the
time in 100% of the use cases (and by it's nature,
it can't) means that it should never (can never)
move forward to a MUST.
--
___
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: convert everything to rpmautospec?

2024-04-08 Thread Tom Hughes via devel


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 forgotten that.

The problem I think what that change is that it's essentially about
changing policy and getting all packagers to move to a new way of
doing things but at a practical level all it did was update some
documentation - nothing it in actual provides for outreach or bringing
the change to the attention of packagers in any way so it's perhaps
not surprising that it seemingly didn't really achieve it's objective
leading us to this attempt to try again.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
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: convert everything to rpmautospec?

2024-04-08 Thread Miroslav Suchý


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 can eat one slice of salami. And repeat 
until whole salami is gone.

--
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: convert everything to rpmautospec?

2024-04-08 Thread Tom Hughes via devel


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 they will double as package
changelogs so doing so may break the changelog.


Yes, I think rpm changelog is for users of the package and git log
is for the maintainers. Most of the time the entries apply to both,
but sometimes they don't.


This was already answered to some extent, but since it seems to a
common misconception, I'll reply here again:

%autochangelog is designed to keep the separation between git log and
%changelog. Generally, only some git log entries end up with a
matching entry in the autogenerated %changelog, see
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#skipping-changelog-entries.


Yes I read the documentation last night after some of the clarifications
and I'm much less opposed now and considering trying it out next time
there is a new release for one of my packages.

I think things might have gone better if things had been phrased
as reminding people of how it all worked, and that it is in fact now
policy to use it (which had passed me by) rather than coming straight
out with threats to use proven packagers which I suspect got people's
backs up and led to some of the swift negative responses.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
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: 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 sense depends a lot on the package. But in particular:
> - just switch to non-autorelease numbering when introducing the
>   minorbump, e.g. just do Release: 15%{?dist}.1 and then .2, etc.
> 
> Looking at the docs again, the docs are not great, and we should
> support this case better. This certainly needs looking into.
> 
Now I recalled yet another downstream issue: Importing without a git history
will reset release numbers. That hashes RPM-dependencies which refer to
a specific release (like "Conflicts: foo < 1-20" after a package split). One
should of course carefully check them on import, but forking whole
distribution like that into a new downstream distribution warrants there will
remain gems like this.

I don't say it's Fedora's problem. I only try to show why some people are not
keen to adopt rpmautospec.

-- Petr


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

Re: convert everything to rpmautospec?

2024-04-08 Thread Iñaki Ucar

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 someone revisits the
> topic and proposes to go further. I don't see anything unfriendly here.
> Everything was set or decided at some point, and nothing could ever be
> changed if we don't allow ourselves to change our minds and be free to make
> new proposals.
> >
> > That said, we are also free to reject those proposals, and I'm -1 here.
> As of today, I think it's fine as an opt-in feature, and I'm even using it
> for some small uncomplicated packages. But I don't think it should be the
> default with an opt-out.
>
> It is already supposed to be default / preferred since this Fedora 38
> Change:
> https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default


Described as preferred in the docs != default. Also versioning and
changelog are described separately, so some could use autochangelog but not
autorelease, or the other way around, or not at all. In the same way that
one could use autosetup or not. But here it has been proposed that
autochangelog + autorelease are not options anymore, and that you would
need to add a file to the repo to opt-out. -1 to this. The current status
is fine for me.

-- 
Iñaki Úcar
--
___
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: 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 update to that
> > build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading
> > from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated 
> > to
> > the 9.2 build before or not.
> 
> 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 sense depends a lot on the package. But in particular:
> - just switch to non-autorelease numbering when introducing the
>   minorbump, e.g. just do Release: 15%{?dist}.1 and then .2, etc.
>
That's what people probably do, but it's not ideal because people need not to
forget to do it and it means a larger churn in dist-git than would be otherwise
necessary.

> > > > - I sometimes need a different commit message from an RPM changelog 
> > > > entry.
> > > 
> > > That's not a problem, the %changelog entry is customziable, see
> > > https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.
> > >
> > If I understand it correctly
> 
> You understand incorrectly ;) Please see the docs linked above.
> 
I see. A multi-line commit message without ellipsis reproduces only the first
line into the RPM changlog. That would do. Thanks for insisting on the
documentation.

> > With preserving the release numbers. Last time it subsituted the release
> > number with a dummy value. Part of the development is comparing old and new
> > builds and testing an upgrade path. A dummy release number is not 
> > sufficient.
> 
> No. I don't know what "last time" means, but it hasn't been like that
> since it was officially introduced in Fedora.

Indeed. I probably mistaken it with building from a source package in mock.

-- Petr


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

Re: convert everything to rpmautospec?

2024-04-08 Thread Fabio Valentini

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 see anything unfriendly here. Everything 
> was set or decided at some point, and nothing could ever be changed if we 
> don't allow ourselves to change our minds and be free to make new proposals.
>
> That said, we are also free to reject those proposals, and I'm -1 here. As of 
> today, I think it's fine as an opt-in feature, and I'm even using it for some 
> small uncomplicated packages. But I don't think it should be the default with 
> an opt-out.

It is already supposed to be default / preferred since this Fedora 38 Change:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default

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

Re: convert everything to rpmautospec?

2024-04-08 Thread Jonathan Wright via devel

-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 the topic
> and proposes to go further. I don't see anything unfriendly here.
> Everything was set or decided at some point, and nothing could ever be
> changed if we don't allow ourselves to change our minds and be free to make
> new proposals.
>
> That said, we are also free to reject those proposals, and I'm -1 here. As
> of today, I think it's fine as an opt-in feature, and I'm even using it for
> some small uncomplicated packages. But I don't think it should be the
> default with an opt-out.
>
> Iñaki
>
> On Mon, 8 Apr 2024 at 14:56, Emmanuel Seyman  wrote:
>
>> * 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 default
>> > and more widely, and possibly at the end previous methods are
>> > deprecated.
>>
>> This sounds acceptable but is not at all how these changes are proposed.
>>
>> An proposal is made, stating explicity that it will be opt-in or target
>> a subset of the target audience and never even suggesting that the scope
>> might one day be expanded.
>>
>> It is accepted based on that premise and, after a while, changes are
>> made to make the change default or opt-out, leaving the people who would
>> not have accepted it had they known they would be forced to use it with
>> no recourse.
>>
>> This is unfriendly (thus violating one of Fedora's core principles) at
>> best and deceitful at worst.
>>
>> > The alternative would be to have "grand plans" where we decide that
>> > some technology will be used by default and mandatory before we deploy
>> > it widely and get feedback.
>>
>> Another alternative would be not lie to the target audience by
>> initially claiming that the change is opt-in. Yet another alternative
>> would be to not go back on this claim.
>>
>> > I think that if you think this through, you'll realize that the
>> > "salami tactic" is quite reasonable.
>>
>> I don't but wish to thank you for the condescending tone nonetheless.
>>
>> Emmanuel
>> --
>> ___
>> 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
>>
>
>
> --
> Iñaki Úcar
> --
> ___
> 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
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
--
___
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: convert everything to rpmautospec?

2024-04-08 Thread Iñaki Ucar

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 some point, and nothing could ever be
changed if we don't allow ourselves to change our minds and be free to make
new proposals.

That said, we are also free to reject those proposals, and I'm -1 here. As
of today, I think it's fine as an opt-in feature, and I'm even using it for
some small uncomplicated packages. But I don't think it should be the
default with an opt-out.

Iñaki

On Mon, 8 Apr 2024 at 14:56, Emmanuel Seyman  wrote:

> * 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 default
> > and more widely, and possibly at the end previous methods are
> > deprecated.
>
> This sounds acceptable but is not at all how these changes are proposed.
>
> An proposal is made, stating explicity that it will be opt-in or target
> a subset of the target audience and never even suggesting that the scope
> might one day be expanded.
>
> It is accepted based on that premise and, after a while, changes are
> made to make the change default or opt-out, leaving the people who would
> not have accepted it had they known they would be forced to use it with
> no recourse.
>
> This is unfriendly (thus violating one of Fedora's core principles) at
> best and deceitful at worst.
>
> > The alternative would be to have "grand plans" where we decide that
> > some technology will be used by default and mandatory before we deploy
> > it widely and get feedback.
>
> Another alternative would be not lie to the target audience by
> initially claiming that the change is opt-in. Yet another alternative
> would be to not go back on this claim.
>
> > I think that if you think this through, you'll realize that the
> > "salami tactic" is quite reasonable.
>
> I don't but wish to thank you for the condescending tone nonetheless.
>
> Emmanuel
> --
> ___
> 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
>


-- 
Iñaki Úcar
--
___
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: convert everything to rpmautospec?

2024-04-08 Thread Emmanuel Seyman

* 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 default
> and more widely, and possibly at the end previous methods are
> deprecated.

This sounds acceptable but is not at all how these changes are proposed.

An proposal is made, stating explicity that it will be opt-in or target
a subset of the target audience and never even suggesting that the scope
might one day be expanded.

It is accepted based on that premise and, after a while, changes are
made to make the change default or opt-out, leaving the people who would
not have accepted it had they known they would be forced to use it with
no recourse.

This is unfriendly (thus violating one of Fedora's core principles) at
best and deceitful at worst.

> The alternative would be to have "grand plans" where we decide that
> some technology will be used by default and mandatory before we deploy
> it widely and get feedback.

Another alternative would be not lie to the target audience by
initially claiming that the change is opt-in. Yet another alternative
would be to not go back on this claim.

> I think that if you think this through, you'll realize that the
> "salami tactic" is quite reasonable.

I don't but wish to thank you for the condescending tone nonetheless.

Emmanuel
--
___
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: convert everything to rpmautospec?

2024-04-08 Thread Pavel Raiskup

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 converted, so in day-to-day work, I don't
> even think about %changelog. When working with other packages, I'll
> forget to update the Relase and/or %changelog. Today I was rebasing
> some pull requests in pagure, and the _only_ conflicts that I had were
> about Release and %changelog.
> 
> 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. when they want to push some fix or separately from other
>work)
> - people submitting pull requests against src.fp.o MAY also
>   include a conversion in the pull request and packagers SHOULD
>   merge it.
> 
> (FTR, 'rpmautospec convert' does the conversion, incl. the commit
> to dist-git. Manual conversion should not be used.)

I'm -1 here.

I'm also -1 for baking the "actual build source data" into a git-log
history, instead of just plain checkout.  One of the reasons:
https://pagure.io/fedora-infra/rpmautospec/issue/227

Then retro: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2G6OSOSM76O2V6K4COIE2QHNXIBSXPFR/

1. git-log is not a %changelog, "generated like we do it" it has close
   to zero value.  Can we finally state that %changelog is not needed?
   Or just point at forge's git-log?

2. Release could be made build-system specific, and IMO _should_ be.

Pavel

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



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

Re: convert everything to rpmautospec?

2024-04-08 Thread Christopher Klooz

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 invariably get told "don't worry, you don't have to use it, it's
all optional", but the plan is always to make it mandatory later. See also
2FA that they are now trying to force on us, taking as an excuse an incident
that was demonstrably NOT stopped by 2FA.

They start off as as things packagers will not have to use if they do
not want to and, over time, become default/forced (Matrix vs IRC,

To be fair, part of the blame there is to be put on Libera.Chat that
unilaterally turned off their Matrix bridge. (Yes, they did give Matrix some
time to address the demands they had, but when Matrix told them it was not
feasible in such a short time frame, they just first suspended, then
permanently blocked the Matrix bridge.) But, and here is where I blame
Fedora, instead of just letting the chans on Libera.Chat die and moving
everything to Matrix, they should have moved the IRC chans to a network with
a working Matrix bridge, such as OFTC (or pretty much anything other than
Libera.Chat – I guess even Freenode under its new owners might be an
option), then we could still be happily using both technologies
interoperably. Instead, we get told to just use Matrix and shut up, which I
do not consider acceptable.

Discourse, ...).

There too, I do not see why some discussions are now being directed to
Discourse instead of the mailing list. And it is not even working. Most of
the pertinent feedback for new Changes still comes on this list, not on
Discourse. The developers use this list, Discourse is only for users who do
not know how to use a mailing list.

The massive & central problem with discourse (and it's amazing that it
still has not been fixed) is that there's no way to reliably get it to
send me an email when there's a new topic, or even when there's a new
message on an existing topic. As a result it's completely useless and
invisible to me.

Rich.

I am also not a fan to merge everything into one piece of centralized infra
because discourse may develop into a big single point of failure.

But the email issue has **partly** been solved: I work with email for about a year with
**limited** problems **when** it comes to keep informed about topics I am already
involved in and also for topics that contain a tag that I am watching (major problem 2
below makes the "limited" in this case).

But once a new topic that is interesting for me is created, I need to set it to
watched in discourse before I can rely on getting informed (which means I need
to know about the topic), because of major problem 1:

Major problem 1: you cannot rely that people who open new topics always set the
right tags. I guess it would take months if not longer before people get used
to that and it would cause a lot of devastating confusion till then, if people
get used to it at all (especially those who work mostly in other communities
that do not centralize at discourse).

Major problem 2: people can change their posts, and nearly everyone gets used
to that quickly, and you will NOT be informed by email if a post is changed.

Major problem 3: many people will have a hard time to get into setting the right properties in their discourse
configuration so that it behaves in the "email"-like way. (e.g., you need to subscribe to related
tags/topics as "watched", not only "tracked" or so -> **maybe this is related to your
problem** ). I am not sure if that is comprehensible if people are not used to it.

(Major?) problem 4: afaik, it is still not possible to add openpgp signatures
to emails (I am not sure if that was fixed in the meantime). We don't use that
yet but at least the possibility to use that possibility on short notice if we
want or need to is not possible. We trust in any case 100% on discourse's
centralized crypto, integrity and availability.

Major problem 5: I still don't know a comprehensible way to add myself to a
topic without becoming active on web discourse if the topic does not contain
one of my subscribed tags. The same for creating new topics. If there is a way,
I am quite sure it is not an intuitive one. In any case, if people can open a
topic in a way I get not informed about, I can miss it.

Major problem 6: in urgent / intensive discussions, 5 minutes can contain
several messages, and thus it will be not possible to discuss among email and
web posts because email posts will be always 5 minutes late (and miss changed
posts at all).

(Major?) problem 7: cross-community topics. I am not sure if that is used at
the moment in devel. But if so, I think this is next to the centralized
trust/crypto issue the one that cannot be solved effectively.

But since we are now an Enterprise customer of discourse, I could

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 
> > > minor
> > >   releases).
> > 
> > Hmm, can you provide describe the workflow that is broken in more
> > detail?
> > 
> 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 update to that
> build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading
> from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated to
> the 9.2 build before or not.

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 sense depends a lot on the package. But in particular:
- just switch to non-autorelease numbering when introducing the
  minorbump, e.g. just do Release: 15%{?dist}.1 and then .2, etc.

Looking at the docs again, the docs are not great, and we should
support this case better. This certainly needs looking into.

> 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 Fedoras is not maintained anymore and users need to do "dnf
> distro-sync" to ignore the RPM versioning.
> 
> All that stems from tha fact that a number of commits between parallelly
> supported braches is not monotonic.
> 
> > > - I sometimes need a different commit message from an RPM changelog entry.
> > 
> > That's not a problem, the %changelog entry is customziable, see
> > https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.
> >
> If I understand it correctly

You understand incorrectly ;) Please see the docs linked above.

> the customization is actually dumping a changelog
> into a static file. So instead of a few-line commit one would need to review
> the complete changelog. No, thanks.
> 
> > > - I prefer "fedpkg local" over mock (faster, smaller, easier to debug).
> > 
> > That also just works.
> > 
> With preserving the release numbers. Last time it subsituted the release
> number with a dummy value. Part of the development is comparing old and new
> builds and testing an upgrade path. A dummy release number is not sufficient.

No. I don't know what "last time" means, but it hasn't been like that
since it was officially introduced in Fedora.

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: convert everything to rpmautospec?

2024-04-08 Thread Neal Gompa

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
> > >   releases).
> >
> > Hmm, can you provide describe the workflow that is broken in more
> > detail?
> >
> 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 update to that
> build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading
> from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated to
> the 9.2 build before or not.
>
> 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 Fedoras is not maintained anymore and users need to do "dnf
> distro-sync" to ignore the RPM versioning.
>
> All that stems from tha fact that a number of commits between parallelly
> supported braches is not monotonic.
>

We did this long before rpmautospec existed. We switched to this
behavior in Fedora 23 because we have never fully maintained "upgrade
paths" across releases.

RHEL is *even worse* in this regard because there is no active testing
or handling of distribution upgrades within the distribution itself
(hence why no equivalent to fedora-obsolete-packages in CentOS/RHEL),
which is why distribution upgrades are the bane of every RHEL admin's
existence. The Leapp tooling more or less externally does the same
thing now, but that's generally not available to CentOS users.

The distro-sync behavior is the right way to handle distribution
upgrades, the "upgrade path" is the right way *within* a distribution
release.




--
真実はいつも一つ！/ 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: 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 is broken in more
> detail?
> 
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 update to that
build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading
from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated to
the 9.2 build before or not.

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 Fedoras is not maintained anymore and users need to do "dnf
distro-sync" to ignore the RPM versioning.

All that stems from tha fact that a number of commits between parallelly
supported braches is not monotonic.

> > - I sometimes need a different commit message from an RPM changelog entry.
> 
> That's not a problem, the %changelog entry is customziable, see
> https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.
>
If I understand it correctly the customization is actually dumping a changelog
into a static file. So instead of a few-line commit one would need to review
the complete changelog. No, thanks.

> > - I prefer "fedpkg local" over mock (faster, smaller, easier to debug).
> 
> That also just works.
> 
With preserving the release numbers. Last time it subsituted the release
number with a dummy value. Part of the development is comparing old and new
builds and testing an upgrade path. A dummy release number is not sufficient.

-- Petr


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

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 their packages
> > - provenpackagers MAY convert existing packages
> >   (e.g. when they want to push some fix or separately from other
> >work)
> > - people submitting pull requests against src.fp.o MAY also
> >   include a conversion in the pull request and packagers SHOULD
> >   merge it.
> > 
> I don't like it because:
> 
> - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL minor
>   releases).

Hmm, can you provide describe the workflow that is broken in more
detail?

> - I sometimes need a different commit message from an RPM changelog entry.

That's not a problem, the %changelog entry is customziable, see
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.

> - I prefer "fedpkg local" over mock (faster, smaller, easier to debug).

That also just works.

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: 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. when they want to push some fix or separately from other
>work)
> - people submitting pull requests against src.fp.o MAY also
>   include a conversion in the pull request and packagers SHOULD
>   merge it.
> 
I don't like it because:

- It breaks upgrade path in downstream distributions (e.g. fixes in RHEL minor
  releases).

- I sometimes need a different commit message from an RPM changelog entry.

- I prefer "fedpkg local" over mock (faster, smaller, easier to debug).

-- Petr



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

Re: convert everything to rpmautospec?

2024-04-08 Thread Richard W.M. Jones

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 don't have to use it, it's 
> all optional", but the plan is always to make it mandatory later. See also 
> 2FA that they are now trying to force on us, taking as an excuse an incident 
> that was demonstrably NOT stopped by 2FA.
> 
> > They start off as as things packagers will not have to use if they do
> > not want to and, over time, become default/forced (Matrix vs IRC,
> 
> To be fair, part of the blame there is to be put on Libera.Chat that 
> unilaterally turned off their Matrix bridge. (Yes, they did give Matrix some 
> time to address the demands they had, but when Matrix told them it was not 
> feasible in such a short time frame, they just first suspended, then 
> permanently blocked the Matrix bridge.) But, and here is where I blame 
> Fedora, instead of just letting the chans on Libera.Chat die and moving 
> everything to Matrix, they should have moved the IRC chans to a network with 
> a working Matrix bridge, such as OFTC (or pretty much anything other than 
> Libera.Chat – I guess even Freenode under its new owners might be an 
> option), then we could still be happily using both technologies 
> interoperably. Instead, we get told to just use Matrix and shut up, which I 
> do not consider acceptable.
> 
> > Discourse, ...).
> 
> There too, I do not see why some discussions are now being directed to 
> Discourse instead of the mailing list. And it is not even working. Most of 
> the pertinent feedback for new Changes still comes on this list, not on 
> Discourse. The developers use this list, Discourse is only for users who do 
> not know how to use a mailing list.

The massive & central problem with discourse (and it's amazing that it
still has not been fixed) is that there's no way to reliably get it to
send me an email when there's a new topic, or even when there's a new
message on an existing topic.  As a result it's completely useless and
invisible to me.

Rich.

> > Perhaps it's time to discuss imposing financial and/or legal penalties
> > when the opt-in nature of the change goes away.
> 
> Who would impose those? And from whom to whom would the money flow? I do not 
> think this can work.
> 
> Kevin Kofler
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: 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 so may break the changelog.
> 
> Yes, I think rpm changelog is for users of the package and git log
> is for the maintainers. Most of the time the entries apply to both,
> but sometimes they don't.

This was already answered to some extent, but since it seems to a
common misconception, I'll reply here again:

%autochangelog is designed to keep the separation between git log and
%changelog. Generally, only some git log entries end up with a
matching entry in the autogenerated %changelog, see
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#skipping-changelog-entries.

> I use a script to generate rpm changelog
> entries from git log as a separate commit with the release bump, but
> occasionally I need to edit the text.

That still works. Just put the whatever text in 'changelog' file, and
%autochangelog will use that. (The way it works is that it processes
git log from the top, generating %changelog entries, until it hits a
commit which touches 'changelog' file, at which points it uses the
contensts of that file as the rest of the %changelog. This mechanism
is also used when one needs to "edit" the autogenerated changelog.)

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: 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, commits related with increasing gating test coverage
> > efforts, or setting up gating.yaml itself. Another example is linting
> > setting and/or configurations. How is that handled with autochangelog?
> > Can we tell it to skip certain commits? Or should we include it all?

Yes, you can skip %changelog for some commits with '[skip changelog]'
and provide additional content in the commit message which is not part
of the changelog. See
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.

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: 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 fix for that inconsistency would be to ban rpmautospec. It just makes 
> everything more complicated.
> 
> > All my packages have been converted, so in day-to-day work, I don't
> > even think about %changelog. When working with other packages, I'll
> > forget to update the Relase and/or %changelog. Today I was rebasing
> > some pull requests in pagure, and the _only_ conflicts that I had were
> > about Release and %changelog.
> 
> Generally, it helps to keep all your branches in sync [...] if you are 
> building the same 
> versions for all releases (which is typically the one case where you bother 
> backporting specfile updates across releases at all), and to process pull 
> requests quickly, before you or rel-eng or another pull request bump the 
> specfile in Rawhide. Then you rarely have conflicts in %changelog to begin 
> with.

Hmm, so KDE has an explicit exception for the updates policy, so that
old releases can be updated and it's indeed possible to keep branches
in sync. I _like_ keeping my branches in sync, but for most packages,
this is not what is supposed to happen.

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.

> I mean, fast-forwarded to the exact same commit hash – no, it is not
> a problem if the changelog for a Fedora release includes an entry
> for a Rawhide mass rebuild made after that Fedora release branched,
> it explains why the Release number has increased and is otherwise
> harmless

I find that distateful and annoying ;]
It's also unnecessary, with rpmautospec and cherry-picking, you get
a clean changelog.

> > 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. when they want to push some fix or separately from other
> >work)
> > - people submitting pull requests against src.fp.o MAY also
> >   include a conversion in the pull request and packagers SHOULD
> >   merge it.
> 
> I am opposed to every part of this proposal. Allowing provenpackagers to 
> convert existing packages (that they do not explicitly comaintain) would be 
> particularly rude. I do NOT want any of this automagic (also the various 
> %auto* macros such as %autosetup) in my specfiles, it just makes my life 
> harder for no benefit whatsoever.

I guess we'll just have to agree to disagree. In the other part of the
thread, a proposal that was floated to allow opt-out. I hope that's
acceptable.

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: convert everything to rpmautospec?

2024-04-08 Thread Cristian Le via devel


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 `copr` to be a pre-release/testing environment?


Cristian

On 2024/04/08 10:43, Zbigniew Jędrzejewski-Szmek wrote:

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

I do not want to use it unless I absolutely have to (e.g. Rust
packages since rust2rpm sets it up that way).

-100.

No. I do not want to use this unless it is finally fixed to enable
rebuild automation. And since that will not happen anytime soon, I
have no compelling reason to use it and tremendous disadvantages
otherwise. It makes building things in COPR terrible, it makes
building things locally annoying, and I can't use it at all reasonably
in non-VCS oriented build systems.

Neal,

I appreciate the work you with other distributions, but in this case,
you're essentially saying that you'll hold Fedora hostage in order
to force some unrelated changes that have no consensus.

In particular:
- local builds work, I do them all the time, with 'fedpkg local' or
   through an srpm.
- builds in copr work.
- "non-VCS oriented build systems" — building from srpm works, so they
   probably actually work, but anyway, it's 2024, we want more version
   control, not less.
- if you want automated rebuilds, please make a proposal and open a
   new dicussion. Don't beat up on rpmautospec.

And we already have a significant fraction of packages using rpmautospec,
so you must have _some_ solution in place that works for those packages.
Even if rpmautospec doesn't fit those external workflows nicely, maybe
even you would benefit if it is used consistently, because then you
can apply the same (adjusted) workflow everywhere?

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

--
___
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: 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 it solve the problem?
> 
> In your original post, you stated "When working with other packages,
> I'll forget to update the Relase and/or %changelog." This will not go
> away if packages are allowed to opt-out.

The issue will be greatly reduced. Every package that is convered
means a little less busy work ;)

> > The opt-out with 'norpmautospec' would solve 1 and 2.
> 
> I've noticed a trend in proposed changes in the way Fedora works.
> 
> They start off as as things packagers will not have to use if they do
> not want to and, over time, become default/forced (Matrix vs IRC,
> Discourse, ...).

Well, you and Kevin see "salami tactics" (whatever that may be),
while I see normal engineering practice: some new idea is hatched,
it's implemented and used narrowly, them it's applied by default
and more widely, and possibly at the end previous methods are
deprecated.

And yes, the purpose of introducing it narrowly at first is so that
we can change course or even revert completely if it turns out to
be a bad idea. And also, so we can apply corrections. In another
part of the thread, Miro raised some concrete issues, which is useful,
because we know that there's something to fix before moving forward.

The alternative would be to have "grand plans" where we decide that
some technology will be used by default and mandatory before we deploy
it widely and get feedback. Maybe this works in a company where
management sets the course, but not such much in community project.
I think that if you think this through, you'll realize that the
"salami tactic" is quite reasonable.

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: 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 automation.
> 
> I do not want to use it unless I absolutely have to (e.g. Rust
> packages since rust2rpm sets it up that way).
> 
> -100.
> 
> No. I do not want to use this unless it is finally fixed to enable
> rebuild automation. And since that will not happen anytime soon, I
> have no compelling reason to use it and tremendous disadvantages
> otherwise. It makes building things in COPR terrible, it makes
> building things locally annoying, and I can't use it at all reasonably
> in non-VCS oriented build systems.

Neal,

I appreciate the work you with other distributions, but in this case,
you're essentially saying that you'll hold Fedora hostage in order
to force some unrelated changes that have no consensus.

In particular:
- local builds work, I do them all the time, with 'fedpkg local' or
  through an srpm.
- builds in copr work.
- "non-VCS oriented build systems" — building from srpm works, so they
  probably actually work, but anyway, it's 2024, we want more version
  control, not less.
- if you want automated rebuilds, please make a proposal and open a
  new dicussion. Don't beat up on rpmautospec.

And we already have a significant fraction of packages using rpmautospec,
so you must have _some_ solution in place that works for those packages.
Even if rpmautospec doesn't fit those external workflows nicely, maybe
even you would benefit if it is used consistently, because then you
can apply the same (adjusted) workflow everywhere?

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: convert everything to rpmautospec?