subject:"F38 proposal\: Rpmautospec by Default \(System\-Wide Change proposal\)"

On Tue, Jan 3, 2023 at 5:10 PM Neal Gompa  wrote:
>
> On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer  wrote:
> >
> > On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar  wrote:
> > >
> > > V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> > > > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > > > that they don't truncate or eliminate the Git history anymore? Because 
> > > > I would
> > > > personally be very displeased if my historical attribution went away
> > > > because of broken processes like the one used to fork all the Fedora
> > > > Linux 34 packages for CentOS Stream 9.
> > > >
> > > It's not only about loosing attributions. There will be NEVRA 
> > > discrepancies in
> > > RHEL:
> > >
> > > Different number of commits will mean different release numbers. That will
> > > break package interdependencies which requires a specific release number. 
> > > E.g
> > > foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus 
> > > Fedora foo
> > > will strengthen the dependency with "Requires: bar >= 1-2". However, after
> > > importing to RHEL, bar will become bar-1-1. The dependency from foo will
> > > break.
> >
> > That's a good point.  The design works well within a single,
> > continuous development environment such as Fedora's but any usage of
> > the sources outside of that, either by importing SRPMs or by importing
> > subsets of dist-git, seems like it would struggle.  Does something
> > like OBS suffer from the same issue?  Seems it would, but I don't know
> > much about how OBS works.
> >
>
> OBS parses the spec file on import and sets the Release value auto
> increment based on the value of the Release field at import time. Then
> when you do a version bump, it resets the Release field back to 1.
>
> OBS does not (by default) let you control the Release field, though a
> project/instance admin can change these defaults. By default, OBS
> overrides the Release value and does its own increments with a commit
> counter and a build counter, formatted as such: .
>
> If you import foo-5-2 into OBS, it'll do foo-5-2.1 for the first
> build. Any triggered rebuilds will bump the build counter. When you
> bump to foo-6, then the new build will be foo-6-1.1.
>
> If you want to tweak OBS to retain the spec file Release value, you
> can configure the project or the instance entirely to use another
> scheme. For example, for the OBS project that obsctl is released
> to[1], the scheme is +obs.. That allows the
> original spec file's Release value to remain, while allowing OBS'
> generated data to be appended. You can see this in motion with a build
> of obsctl[2], where you can see that we've done the 6th rebuild of the
> 11th checkin of commit b6e1e99.
>

I should clarify here a bit, this is the 11th checkin into the OBS
SCM, not the 11th checkin of the Git commit:
https://build.opensuse.org/package/revisions/isv:Datto:Utilities:OBSCtl:Mainline/obsctl-git




-- 
真実はいつも一つ！/ 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 3, 2023 at 5:11 PM Neal Gompa  wrote:
>
> On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer  wrote:
> >
> > On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar  wrote:
> > >
> > > V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> > > > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > > > that they don't truncate or eliminate the Git history anymore? Because 
> > > > I would
> > > > personally be very displeased if my historical attribution went away
> > > > because of broken processes like the one used to fork all the Fedora
> > > > Linux 34 packages for CentOS Stream 9.
> > > >
> > > It's not only about loosing attributions. There will be NEVRA 
> > > discrepancies in
> > > RHEL:
> > >
> > > Different number of commits will mean different release numbers. That will
> > > break package interdependencies which requires a specific release number. 
> > > E.g
> > > foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus 
> > > Fedora foo
> > > will strengthen the dependency with "Requires: bar >= 1-2". However, after
> > > importing to RHEL, bar will become bar-1-1. The dependency from foo will
> > > break.
> >
> > That's a good point.  The design works well within a single,
> > continuous development environment such as Fedora's but any usage of
> > the sources outside of that, either by importing SRPMs or by importing
> > subsets of dist-git, seems like it would struggle.  Does something
> > like OBS suffer from the same issue?  Seems it would, but I don't know
> > much about how OBS works.
> >
>
> OBS parses the spec file on import and sets the Release value auto
> increment based on the value of the Release field at import time. Then
> when you do a version bump, it resets the Release field back to 1.
>
> OBS does not (by default) let you control the Release field, though a
> project/instance admin can change these defaults. By default, OBS
> overrides the Release value and does its own increments with a commit
> counter and a build counter, formatted as such: .

Thank you!

josh

>
> If you import foo-5-2 into OBS, it'll do foo-5-2.1 for the first
> build. Any triggered rebuilds will bump the build counter. When you
> bump to foo-6, then the new build will be foo-6-1.1.
>
> If you want to tweak OBS to retain the spec file Release value, you
> can configure the project or the instance entirely to use another
> scheme. For example, for the OBS project that obsctl is released
> to[1], the scheme is +obs.. That allows the
> original spec file's Release value to remain, while allowing OBS'
> generated data to be appended. You can see this in motion with a build
> of obsctl[2], where you can see that we've done the 6th rebuild of the
> 11th checkin of commit b6e1e99.
>
> [1]: https://build.opensuse.org/projects/isv:Datto:Utilities:OBSCtl/prjconf
> [2]: 
> https://build.opensuse.org/package/binaries/isv:Datto:Utilities:OBSCtl:Mainline/obsctl-git/Fedora_Rawhide
>
>
> --
> 真実はいつも一つ！/ 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
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer  wrote:
>
> On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar  wrote:
> >
> > V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> > > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > > that they don't truncate or eliminate the Git history anymore? Because I 
> > > would
> > > personally be very displeased if my historical attribution went away
> > > because of broken processes like the one used to fork all the Fedora
> > > Linux 34 packages for CentOS Stream 9.
> > >
> > It's not only about loosing attributions. There will be NEVRA discrepancies 
> > in
> > RHEL:
> >
> > Different number of commits will mean different release numbers. That will
> > break package interdependencies which requires a specific release number. 
> > E.g
> > foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora 
> > foo
> > will strengthen the dependency with "Requires: bar >= 1-2". However, after
> > importing to RHEL, bar will become bar-1-1. The dependency from foo will
> > break.
>
> That's a good point.  The design works well within a single,
> continuous development environment such as Fedora's but any usage of
> the sources outside of that, either by importing SRPMs or by importing
> subsets of dist-git, seems like it would struggle.  Does something
> like OBS suffer from the same issue?  Seems it would, but I don't know
> much about how OBS works.
>

OBS parses the spec file on import and sets the Release value auto
increment based on the value of the Release field at import time. Then
when you do a version bump, it resets the Release field back to 1.

OBS does not (by default) let you control the Release field, though a
project/instance admin can change these defaults. By default, OBS
overrides the Release value and does its own increments with a commit
counter and a build counter, formatted as such: .

If you import foo-5-2 into OBS, it'll do foo-5-2.1 for the first
build. Any triggered rebuilds will bump the build counter. When you
bump to foo-6, then the new build will be foo-6-1.1.

If you want to tweak OBS to retain the spec file Release value, you
can configure the project or the instance entirely to use another
scheme. For example, for the OBS project that obsctl is released
to[1], the scheme is +obs.. That allows the
original spec file's Release value to remain, while allowing OBS'
generated data to be appended. You can see this in motion with a build
of obsctl[2], where you can see that we've done the 6th rebuild of the
11th checkin of commit b6e1e99.

[1]: https://build.opensuse.org/projects/isv:Datto:Utilities:OBSCtl/prjconf
[2]: 
https://build.opensuse.org/package/binaries/isv:Datto:Utilities:OBSCtl:Mainline/obsctl-git/Fedora_Rawhide

-- 
真実はいつも一つ！/ 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Kalev Lember

On Tue, Jan 3, 2023 at 10:27 PM Otto Liljalaakso 
wrote:

> Kalev Lember kirjoitti 3.1.2023 klo 11.19:
> > We might need to update package maintainer documents to be clear about
> this
> > though, so that people know that they should use 'fedpkg srpm' and not
> > 'rpmbuild -bs'.
>
> In Package Maintainer Docs, we have just a single instance of rpmbuild
> usage, at Using the Koji Build System — Scratch Builds [1]. Everything
> else is fedpkg based already. I made a pull request to get rid of that
> single outlier [2].
>
> Did you have some other source of documentation in mind that would need
> more work?
>
> [1]:
>
> https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/#scratch_builds
> [2]:
> https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101


Awesome, thanks for doing that! No, I didn't have anything specific in
mind, so hopefully that was all there was to fix :)

-- 
Kalev
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Otto Liljalaakso

Kalev Lember kirjoitti 3.1.2023 klo 11.19:

On Tue, Jan 3, 2023 at 10:13 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:

On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:

- fedpkg mockbuild

But it doesn't work correctly (will always use Release: 1) if you run
"rpmbuild -bs foo-bar.spec" which is a very common scenario.

"Doctor, it hurts when I do that."

'rpmbuild -bs' is broken. Don't use it.

Yes, I would say that as well. It's just a low level tool and can never
have all the integration with git that fedpkg has.

We might need to update package maintainer documents to be clear about this
though, so that people know that they should use 'fedpkg srpm' and not
'rpmbuild -bs'.

In Package Maintainer Docs, we have just a single instance of rpmbuild
usage, at Using the Koji Build System — Scratch Builds [1]. Everything
else is fedpkg based already. I made a pull request to get rid of that
single outlier [2].

Did you have some other source of documentation in mind that would need
more work?

[1]:
https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/#scratch_builds

[2]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar  wrote:
>
> V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > that they don't truncate or eliminate the Git history anymore? Because I 
> > would
> > personally be very displeased if my historical attribution went away
> > because of broken processes like the one used to fork all the Fedora
> > Linux 34 packages for CentOS Stream 9.
> >
> It's not only about loosing attributions. There will be NEVRA discrepancies in
> RHEL:
>
> Different number of commits will mean different release numbers. That will
> break package interdependencies which requires a specific release number. E.g
> foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora foo
> will strengthen the dependency with "Requires: bar >= 1-2". However, after
> importing to RHEL, bar will become bar-1-1. The dependency from foo will
> break.

That's a good point.  The design works well within a single,
continuous development environment such as Fedora's but any usage of
the sources outside of that, either by importing SRPMs or by importing
subsets of dist-git, seems like it would struggle.  Does something
like OBS suffer from the same issue?  Seems it would, but I don't know
much about how OBS works.

> Another RHEL problem will be fixes for minor RHEL version. E.g. RHEL 10.0 will
> contain foo-1-1, RHEL-10.1 updates to foo-1-2, then RHEL-10.0 backports
> the change, preferably as foo-1-1.el10_0.1. However, the generated rpmautospec
> schema won't allow it and will produce foo-1-2.el10_0. I foresee RHEL
> maintainers to revert rpmautospec to manual numbering for minor RHEL updates.

Or automation grows the ability to support that kind of versioning, if
it were to be used in RHEL.

> None of these issues are Fedora issues. But considering the ecosystems
> wholistically, the proposed rpmautospec propotion will add a friction.

Nothing is free, that's for sure :)

josh
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Mon, Jan 2, 2023 at 5:56 AM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Monday, 02 January 2023 at 09:57, Miroslav Suchý wrote:
> > Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
> > > produces bogus changelog messages and artificially
> > > inflates Release counters.
> >
> > I always wondered why people are afraid of gaps in numbering? It is
> > just a number. The number will not object if you skip some of them. :)
>
> Gaps in release numbering are just not neat. To me, they create an
> unnecessary confusion. Each bump in Release field should have a
> corresponding build in koji and it makes me wonder why if it doesn't.

Which means you go and investigate and learn why, which is a sane
thing to do if you want to know that information.

Equating Release values with builds is folly unless the build system
automatically does a build for every commit.  If it did, it could
autogenerate the Release value and probably the changelog oh wait
:)

josh

> > Or it is my origin in BASIC that I am not afraid of that? We numbered
> > the lines as a multiply of 5 or 10. :)
>
> I've written code in BASIC back in the day. This comment is irrelevant
> to the issue at hand.
>
> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Mon, Jan 2, 2023 at 4:43 AM Maxwell G via devel
 wrote:
>
> On Mon Jan 2, 2023 at 09:57 +0100, Miroslav Suchý wrote:
> > Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
> > > produces bogus changelog messages and artificially
> > > inflates Release counters.
> >
> > I always wondered why people are afraid of gaps in numbering? It is
> > just a number. The number will not object if you skip some of them. :)
>
> The release number shows how many builds of the same version have been
> made. A high release is also baseline indicator that a package/project
> is stale downstream and/or upstream. When the first build of foo v1.5.0
> is foo-1.5.0-6 because the author took the time to split up logical
> changes into separate commits, the value of that release number is lost.

The heuristics you are describing are assumptions, not facts.  They
are decent assumptions in the context of the Fedora project, but they
don't necessarily actually apply equally across the package set.

Personally, I think we should avoid tying any assumption to the
Release value and simply realize that it is the mechanism used to
present an update to a system.  Guessing what foo-1.5.0-6 vs.
foo-1.5.0-560 means based on what we think Release denotes is kind of
dangerous.

josh
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Todd Zullinger

Zbigniew Jędrzejewski-Szmek wrote:
> Yes, this is what I was talking about too. Because rpmbuild does not set
> %_sourcedir, it may fail to load some files. Even worse, it may load *wrong*
> versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/.
> Personally, I have dozens of stray files there from old rpm builds there…

I've used the following in ~/.rpmmacros for many years to
have rpmbuild keep package files together, as rpkg/fedpkg
do:

%_sourcedir %{_topdir}/%{?name:%name}
%_specdir   %{_sourcedir}
%_builddir  %{_sourcedir}
%_srcrpmdir %{_sourcedir}
%_rpmdir%{_sourcedir}

That doesn't address the deeper issues with respect to
rpmautospec compatibility, but it does make rpmbuild much
more comfortable to use, at least for me.

-- 
Todd


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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Vít Ondruch



Dne 03. 01. 23 v 16:24 Neal Gompa napsal(a):

On Tue, Jan 3, 2023 at 10:21 AM Zbigniew Jędrzejewski-Szmek
 wrote:

On Tue, Jan 03, 2023 at 03:50:10PM +0100, Vít Ondruch wrote:

Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):

On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen  wrote:


On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek  
wrote:

On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:

On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:

- fedpkg mockbuild

But it doesn't work correctly (will always use Release: 1) if you run
"rpmbuild -bs foo-bar.spec" which is a very common scenario.

"Doctor, it hurts when I do that."

'rpmbuild -bs' is broken. Don't use it.


Could you please elucidate why the command that people have used for nearly 30 
years and is the most documented on how to build rpms is broken? And how people 
should use instead when they may be dealing with an environment which doesn't 
allow fedpkg to work? [AKA I am working on a package which I want to submit for 
review so I need to build a @$@$% src RPM somehow and I am being told I can't 
use the built in command to do so]

"rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec
(because it's implemented on top of RPM instead of *in* RPM),


Oh, it does not know about more things, e.g.:

~~~

$ rpmbuild -bs ruby.spec
error: /home/vondruch/fedora-scm/own/ruby/ruby.spec: line 132: failed to
load macro file /home/vondruch/rpmbuild/SOURCES/macros.ruby
   0<  (%load)
~~~

Yes, this is what I was talking about too. Because rpmbuild does not set
%_sourcedir, it may fail to load some files. Even worse, it may load *wrong*
versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/.
Personally, I have dozens of stray files there from old rpm builds there…


So it does not handle more scenarios then just rpmautospec.
IMHO, it would be much better to recommend:

$ touch sources
$ fedpkg --release f38 srpm

Ideally, fedpkg/rpkg would allow 'sources' to not exist and DTRT automatically.
It would just make everyone's life easier.


It already does. I use it for packaging I have in Git repos on
pagure.io.




Oh really? Very nice. Have not noticed it yet. Thx for heads up.


Vít




--
真実はいつも一つ！/ 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


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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 3, 2023 at 10:21 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Jan 03, 2023 at 03:50:10PM +0100, Vít Ondruch wrote:
> >
> > Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):
> > > On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen  
> > > wrote:
> > > >
> > > >
> > > > On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek 
> > > >  wrote:
> > > > > On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel 
> > > > > wrote:
> > > > > > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > > > - fedpkg mockbuild
> > > > > > But it doesn't work correctly (will always use Release: 1) if you 
> > > > > > run
> > > > > > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
> > > > > "Doctor, it hurts when I do that."
> > > > >
> > > > > 'rpmbuild -bs' is broken. Don't use it.
> > > > >
> > > > Could you please elucidate why the command that people have used for 
> > > > nearly 30 years and is the most documented on how to build rpms is 
> > > > broken? And how people should use instead when they may be dealing with 
> > > > an environment which doesn't allow fedpkg to work? [AKA I am working on 
> > > > a package which I want to submit for review so I need to build a @$@$% 
> > > > src RPM somehow and I am being told I can't use the built in command to 
> > > > do so]
> > > "rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec
> > > (because it's implemented on top of RPM instead of *in* RPM),
> >
> >
> > Oh, it does not know about more things, e.g.:
> >
> > ~~~
> >
> > $ rpmbuild -bs ruby.spec
> > error: /home/vondruch/fedora-scm/own/ruby/ruby.spec: line 132: failed to
> > load macro file /home/vondruch/rpmbuild/SOURCES/macros.ruby
> >   0<  (%load)
> > ~~~
>
> Yes, this is what I was talking about too. Because rpmbuild does not set
> %_sourcedir, it may fail to load some files. Even worse, it may load *wrong*
> versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/.
> Personally, I have dozens of stray files there from old rpm builds there…
>
> > So it does not handle more scenarios then just rpmautospec.
>
> > IMHO, it would be much better to recommend:
> >
> > $ touch sources
> > $ fedpkg --release f38 srpm
>
> Ideally, fedpkg/rpkg would allow 'sources' to not exist and DTRT 
> automatically.
> It would just make everyone's life easier.
>

It already does. I use it for packaging I have in Git repos on
pagure.io.




--
真実はいつも一つ！/ 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Jan 03, 2023 at 03:50:10PM +0100, Vít Ondruch wrote:
> 
> Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):
> > On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen  wrote:
> > > 
> > > 
> > > On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek 
> > >  wrote:
> > > > On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel 
> > > > wrote:
> > > > > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > > - fedpkg mockbuild
> > > > > But it doesn't work correctly (will always use Release: 1) if you run
> > > > > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
> > > > "Doctor, it hurts when I do that."
> > > > 
> > > > 'rpmbuild -bs' is broken. Don't use it.
> > > > 
> > > Could you please elucidate why the command that people have used for 
> > > nearly 30 years and is the most documented on how to build rpms is 
> > > broken? And how people should use instead when they may be dealing with 
> > > an environment which doesn't allow fedpkg to work? [AKA I am working on a 
> > > package which I want to submit for review so I need to build a @$@$% src 
> > > RPM somehow and I am being told I can't use the built in command to do so]
> > "rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec
> > (because it's implemented on top of RPM instead of *in* RPM),
> 
> 
> Oh, it does not know about more things, e.g.:
> 
> ~~~
> 
> $ rpmbuild -bs ruby.spec
> error: /home/vondruch/fedora-scm/own/ruby/ruby.spec: line 132: failed to
> load macro file /home/vondruch/rpmbuild/SOURCES/macros.ruby
>   0<  (%load)
> ~~~

Yes, this is what I was talking about too. Because rpmbuild does not set
%_sourcedir, it may fail to load some files. Even worse, it may load *wrong*
versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/.
Personally, I have dozens of stray files there from old rpm builds there…

> So it does not handle more scenarios then just rpmautospec.

> IMHO, it would be much better to recommend:
> 
> $ touch sources
> $ fedpkg --release f38 srpm

Ideally, fedpkg/rpkg would allow 'sources' to not exist and DTRT automatically.
It would just make everyone's life easier.

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Vít Ondruch



Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):

On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen  wrote:



On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek  
wrote:

On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:

On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:

- fedpkg mockbuild

But it doesn't work correctly (will always use Release: 1) if you run
"rpmbuild -bs foo-bar.spec" which is a very common scenario.

"Doctor, it hurts when I do that."

'rpmbuild -bs' is broken. Don't use it.


Could you please elucidate why the command that people have used for nearly 30 
years and is the most documented on how to build rpms is broken? And how people 
should use instead when they may be dealing with an environment which doesn't 
allow fedpkg to work? [AKA I am working on a package which I want to submit for 
review so I need to build a @$@$% src RPM somehow and I am being told I can't 
use the built in command to do so]

"rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec
(because it's implemented on top of RPM instead of *in* RPM),



Oh, it does not know about more things, e.g.:

~~~

$ rpmbuild -bs ruby.spec
error: /home/vondruch/fedora-scm/own/ruby/ruby.spec: line 132: failed to 
load macro file /home/vondruch/rpmbuild/SOURCES/macros.ruby

  0<  (%load)
~~~

So it does not handle more scenarios then just rpmautospec.



  but it
will still produce a valid SRPM file, just with default fallback
values for both %autorelease (i.e. 1%{?dist}) and %autochangelog (i.e.
empty). I even still recommend "rpmbuild -bs" to "new packagers" for
building an SRPM outside a dist-git repository (for example, for
submitting it for package review).



IMHO, it would be much better to recommend:


~~~

$ touch sources

$ fedpkg --release f38 srpm

~~~


instead.



Vít



But for building an SRPM in a
dist-git repo, "fedpkg srpm" is absolutely the better choice.

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


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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Richard Hughes

On Tue, 3 Jan 2023 at 13:46, Florian Weimer  wrote:
> > BuildError: Error running GIT command "git clone -n
> > https://src.fedoraproject.org/rpms/fwupd.git
> > /var/lib/mock/f38-build-4075-4953952/root/chroot_tmpdir/scmroot/fwupd",
> > see checkout.log for details
> | fatal: the remote end hung up unexpectedly
> So maybe an unrelated issue?  I mean, at this point the system won't
> even know that the package uses rpmautospec.

You're correct indeed, thanks. It seems to be a spurious error. The
package is building happily now.

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Stephen Smoogen

On Tue, 3 Jan 2023 at 08:14, Stephen Smoogen  wrote:

>
>
> On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
>> > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
>> > > - fedpkg mockbuild
>> >
>> > But it doesn't work correctly (will always use Release: 1) if you run
>> > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
>>
>> "Doctor, it hurts when I do that."
>>
>> 'rpmbuild -bs' is broken. Don't use it.
>>
>>
> Could you please elucidate why the command that people have used for
> nearly 30 years and is the most documented on how to build rpms is broken?
> And how people should use instead when they may be dealing with an
> environment which doesn't allow fedpkg to work? [AKA I am working on a
> package which I want to submit for review so I need to build a @$@$% src
> RPM somehow and I am being told I can't use the built in command to do so]
>
>
>
OK I have started off the year with a cranky email. My apologies for that
as I should have gone back to read the context which this was being said
in. [I am usually all for removing extra stuff from an email to make it
short and sweet, and then go read what I might have missed.. however in
this case I didn't and just barked like a mad dog.]


> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle.
> -- Ian MacClaren
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Florian Weimer

* Richard Hughes:

> On Fri, 30 Dec 2022 at 19:02, Ben Cotton  wrote:
>> Version: 1.2.3
>> Release: %autorelease
>> %autochangelog
>
> I tied this on a package this morning and got:
>
> BuildError: Error running GIT command "git clone -n
> https://src.fedoraproject.org/rpms/fwupd.git
> /var/lib/mock/f38-build-4075-4953952/root/chroot_tmpdir/scmroot/fwupd",
> see checkout.log for details

That log says:

| $ git clone -n https://src.fedoraproject.org/rpms/fwupd.git 
/var/lib/mock/f38-build-4075-4953952/root/chroot_tmpdir/scmroot/fwupd
| Cloning into 
'/var/lib/mock/f38-build-4075-4953952/root/chroot_tmpdir/scmroot/fwupd'...
| error: RPC failed; curl 16 Error in the HTTP2 framing layer
| fatal: the remote end hung up unexpectedly

So maybe an unrelated issue?  I mean, at this point the system won't
even know that the package uses rpmautospec.

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Florian Weimer

* Stephen Smoogen:

> On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek  
> wrote:
>
>  On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
>  > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
>  > > - fedpkg mockbuild
>  > 
>  > But it doesn't work correctly (will always use Release: 1) if you run
>  > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
>
>  "Doctor, it hurts when I do that."
>
>  'rpmbuild -bs' is broken. Don't use it.
>
> Could you please elucidate why the command that people have used for
> nearly 30 years and is the most documented on how to build rpms is
> broken?

It's never been a reliable way to create a source RPM from a dist-git
checkout.  For example, it does not ensure that all the necessary
dependencies are installed, or that all the RPM macros are set up
correctly.

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 3, 2023 at 8:24 AM Dan Horák  wrote:
>
> On Tue, 3 Jan 2023 08:14:04 -0500
> Stephen Smoogen  wrote:
>
> > On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek 
> > wrote:
> >
> > > On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
> > > > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > - fedpkg mockbuild
> > > >
> > > > But it doesn't work correctly (will always use Release: 1) if you run
> > > > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
> > >
> > > "Doctor, it hurts when I do that."
> > >
> > > 'rpmbuild -bs' is broken. Don't use it.
> > >
> > >
> > Could you please elucidate why the command that people have used for nearly
> > 30 years and is the most documented on how to build rpms is broken? And how
> > people should use instead when they may be dealing with an environment
> > which doesn't allow fedpkg to work? [AKA I am working on a package which I
> > want to submit for review so I need to build a @$@$% src RPM somehow and I
> > am being told I can't use the built in command to do so]
>
> I wonder whether we should start recommending "rpkg" instead of plain
> "rpmbuild" for the initial/non-dist-git work on rpms ... I am finding it
> quite useful/powerful.
>

As I understand it, rpkg is not maintained, so that would be a poor choice.




--
真実はいつも一つ！/ 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Dan Horák

On Tue, 3 Jan 2023 08:14:04 -0500
Stephen Smoogen  wrote:

> On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek 
> wrote:
> 
> > On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
> > > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > > - fedpkg mockbuild
> > >
> > > But it doesn't work correctly (will always use Release: 1) if you run
> > > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
> >
> > "Doctor, it hurts when I do that."
> >
> > 'rpmbuild -bs' is broken. Don't use it.
> >
> >
> Could you please elucidate why the command that people have used for nearly
> 30 years and is the most documented on how to build rpms is broken? And how
> people should use instead when they may be dealing with an environment
> which doesn't allow fedpkg to work? [AKA I am working on a package which I
> want to submit for review so I need to build a @$@$% src RPM somehow and I
> am being told I can't use the built in command to do so]

I wonder whether we should start recommending "rpkg" instead of plain
"rpmbuild" for the initial/non-dist-git work on rpms ... I am finding it
quite useful/powerful.


Dan
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Fabio Valentini

On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen  wrote:
>
>
>
> On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek  
> wrote:
>>
>> On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
>> > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
>> > > - fedpkg mockbuild
>> >
>> > But it doesn't work correctly (will always use Release: 1) if you run
>> > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
>>
>> "Doctor, it hurts when I do that."
>>
>> 'rpmbuild -bs' is broken. Don't use it.
>>
>
> Could you please elucidate why the command that people have used for nearly 
> 30 years and is the most documented on how to build rpms is broken? And how 
> people should use instead when they may be dealing with an environment which 
> doesn't allow fedpkg to work? [AKA I am working on a package which I want to 
> submit for review so I need to build a @$@$% src RPM somehow and I am being 
> told I can't use the built in command to do so]

"rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec
(because it's implemented on top of RPM instead of *in* RPM), but it
will still produce a valid SRPM file, just with default fallback
values for both %autorelease (i.e. 1%{?dist}) and %autochangelog (i.e.
empty). I even still recommend "rpmbuild -bs" to "new packagers" for
building an SRPM outside a dist-git repository (for example, for
submitting it for package review). But for building an SRPM in a
dist-git repo, "fedpkg srpm" is absolutely the better choice.

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Stephen Smoogen

On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
> > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > - fedpkg mockbuild
> >
> > But it doesn't work correctly (will always use Release: 1) if you run
> > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
>
> "Doctor, it hurts when I do that."
>
> 'rpmbuild -bs' is broken. Don't use it.
>
>
Could you please elucidate why the command that people have used for nearly
30 years and is the most documented on how to build rpms is broken? And how
people should use instead when they may be dealing with an environment
which doesn't allow fedpkg to work? [AKA I am working on a package which I
want to submit for review so I need to build a @$@$% src RPM somehow and I
am being told I can't use the built in command to do so]


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Richard Hughes

On Fri, 30 Dec 2022 at 19:02, Ben Cotton  wrote:
> Version: 1.2.3
> Release: %autorelease
> %autochangelog

I tied this on a package this morning and got:

BuildError: Error running GIT command "git clone -n
https://src.fedoraproject.org/rpms/fwupd.git
/var/lib/mock/f38-build-4075-4953952/root/chroot_tmpdir/scmroot/fwupd",
see checkout.log for details

The page is here if that helps:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95738071 -- this
is from a "git push && fedpkg build" from the main branch. Any ideas?

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Kalev Lember

On Tue, Jan 3, 2023 at 10:13 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
> > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > - fedpkg mockbuild
> >
> > But it doesn't work correctly (will always use Release: 1) if you run
> > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
>
> "Doctor, it hurts when I do that."
>
> 'rpmbuild -bs' is broken. Don't use it.
>

Yes, I would say that as well. It's just a low level tool and can never
have all the integration with git that fedpkg has.

We might need to update package maintainer documents to be clear about this
though, so that people know that they should use 'fedpkg srpm' and not
'rpmbuild -bs'.

-- 
Kalev
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
> On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > - fedpkg mockbuild
> 
> But it doesn't work correctly (will always use Release: 1) if you run
> "rpmbuild -bs foo-bar.spec" which is a very common scenario.

"Doctor, it hurts when I do that."

'rpmbuild -bs' is broken. Don't use it.

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Vitaly Zaitsev via devel


On 03/01/2023 09:30, Petr Pisar wrote:

Different number of commits will mean different release numbers. That will
break package interdependencies which requires a specific release number. E.g
foo requires bar.


Good point. Hard-coded release numbers are a serious problem even in Fedora.

We have a serious issue with mesa vs. mesa-freeworld synchronization, 
because Fedora's mesa package has a strict EVR dependency requirement. 
RPM Fusion maintainers can't even bump Release, otherwise the package 
can't be installed due to conflict[1].


[1]: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6426

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Vitaly Zaitsev via devel


On 01/01/2023 15:10, Florian Weimer wrote:

COPR seems to work in some cases, specifically with the dist-git build
(but not just building from dist-git).


Run "rpmbuild -bs foo-bar.spec", upload it to COPR and it will use 
Release: 1.


I also need to figure out if it works with building from SCM without 
uploading rendered SRPM.


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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Vitaly Zaitsev via devel


On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:

- fedpkg mockbuild


But it doesn't work correctly (will always use Release: 1) if you run 
"rpmbuild -bs foo-bar.spec" which is a very common scenario.


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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Petr Pisar

V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> Have we made sure that when Red Hat forks Fedora packages for RHEL
> that they don't truncate or eliminate the Git history anymore? Because I would
> personally be very displeased if my historical attribution went away
> because of broken processes like the one used to fork all the Fedora
> Linux 34 packages for CentOS Stream 9.
> 
It's not only about loosing attributions. There will be NEVRA discrepancies in
RHEL:

Different number of commits will mean different release numbers. That will
break package interdependencies which requires a specific release number. E.g
foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora foo
will strengthen the dependency with "Requires: bar >= 1-2". However, after
importing to RHEL, bar will become bar-1-1. The dependency from foo will
break.

Another RHEL problem will be fixes for minor RHEL version. E.g. RHEL 10.0 will
contain foo-1-1, RHEL-10.1 updates to foo-1-2, then RHEL-10.0 backports
the change, preferably as foo-1-1.el10_0.1. However, the generated rpmautospec
schema won't allow it and will produce foo-1-2.el10_0. I foresee RHEL
maintainers to revert rpmautospec to manual numbering for minor RHEL updates.

None of these issues are Fedora issues. But considering the ecosystems
wholistically, the proposed rpmautospec propotion will add a friction.

-- 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Miroslav Suchý


Dne 02. 01. 23 v 22:39 Otto Liljalaakso napsal(a):
Also, 'mock --buildsrpm' will not convert them. Perhaps Vitaly meant mock should support such usage? 


Mock cannot add such support, because Mock rarely operate on top of dist-git (or even git). So there is no way how to 
retrieve git log.


Miroslav
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Otto Liljalaakso


Zbigniew Jędrzejewski-Szmek kirjoitti 2.1.2023 klo 22.44:

On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:

* Vitaly Zaitsev via devel:


On 30/12/2022 20:01, Ben Cotton wrote:

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


-1 until these known issues[1] are fixed, especially with changelogs
  and using rpmautospec in COPR or mock.

[1]:
https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-constraints


The page doesnt discuss COPR/mock?

COPR seems to work in some cases, specifically with the dist-git build
(but not just building from dist-git).

A quick check suggests that rpmautospec does the right thing and
produces a portable source RPM that doesn't depend on rpmautospec
anymore.  As a result, the compatibility impact won't be too severe, I
hope.


Also mock builds seem fine. I tested this now on F37 with a few different 
scenarios:
- fedpkg mockbuild
- git commit --allow-empty -m Rebuild && fedpkg mockbuild
- fedpkg srpm && mock *.src.rpm
seem to generate the expected versions numbers and changelogs.


All these examples work because 'fedpkg srpm' does the rpmautospec 
conversion, and all the used fedpkg commands imply 'fedpkg srpm'.


If you generate an srpm which still contains %autorelease and 
%autochangelog with 'rpmbuild -bs', mock will not convert them by 
itself. Also, 'mock --buildsrpm' will not convert them. Perhaps Vitaly 
meant mock should support such usage?


But I wonder, if that is really necessary? In many cases like local test 
builds, the default values for uncoverted %autorelease and 
%autochangelog are just fine, and if the real values are needed, 'fedpkg 
srpm' can be called before invoking mock.

___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Miroslav Suchý


Dne 02. 01. 23 v 22:01 Richard Shaw napsal(a):


Also mock builds seem fine. I tested this now on F37 with a few different 
scenarios:
- fedpkg mockbuild
- git commit --allow-empty -m Rebuild && fedpkg mockbuild
- fedpkg srpm && mock *.src.rpm
seem to generate the expected versions numbers and changelogs.


This is my problem with the proposal. Our tools haven't been fully integrated. For a typical update I do not need to 
run git directly, but for this workflow I do.


For a typical bump all I need is:

rpmdev-bumpspec -c "Change here"
fedpkg commit -c -p
fedpkg build

Our tools need to handle this automagically. I shouldn't have to know I need to add 
"--allow-empty". It should just work.


https://pagure.io/rpkg/pull-request/644

You are welcome.

Miroslav
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Zbigniew Jędrzejewski-Szmek

On Mon, Jan 02, 2023 at 03:01:16PM -0600, Richard Shaw wrote:
> On Mon, Jan 2, 2023 at 2:44 PM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> 
> > On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:
> > > * Vitaly Zaitsev via devel:
> > >
> > > > On 30/12/2022 20:01, Ben Cotton wrote:
> > > >> This document represents a proposed Change. As part of the Changes
> > > >> process, proposals are publicly announced in order to receive
> > > >> community feedback. This proposal will only be implemented if approved
> > > >> by the Fedora Engineering Steering Committee.
> > > >
> > > > -1 until these known issues[1] are fixed, especially with changelogs
> > > >  and using rpmautospec in COPR or mock.
> > > >
> > > > [1]:
> > > >
> > https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-constraints
> > >
> > > The page doesnt discuss COPR/mock?
> > >
> > > COPR seems to work in some cases, specifically with the dist-git build
> > > (but not just building from dist-git).
> > >
> > > A quick check suggests that rpmautospec does the right thing and
> > > produces a portable source RPM that doesn't depend on rpmautospec
> > > anymore.  As a result, the compatibility impact won't be too severe, I
> > > hope.
> >
> > Also mock builds seem fine. I tested this now on F37 with a few different
> > scenarios:
> > - fedpkg mockbuild
> > - git commit --allow-empty -m Rebuild && fedpkg mockbuild
> > - fedpkg srpm && mock *.src.rpm
> > seem to generate the expected versions numbers and changelogs.
> >
> 
> This is my problem with the proposal. Our tools haven't been fully
> integrated. For a typical update I do not need to run git directly, but for
> this workflow I do.
> 
> For a typical bump all I need is:
> 
> rpmdev-bumpspec -c "Change here"
> fedpkg commit -c -p
> fedpkg build
> 
> Our tools need to handle this automagically. I shouldn't have to know I
> need to add "--allow-empty". It should just work.

Yes, it'd be nice if 'fedpkg' handled this natively more nicely.
There is nothing to do for rpmdev-bumpspec in this case. The first two
steps should/could be replaced by one command:

  fedpkg commit -m 'Change here' -p

I filed https://pagure.io/fedpkg/issue/494 asking for this.
I'll add this to the Scope section of the proposal so we don't lose
track.

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Zbigniew Jędrzejewski-Szmek

On Sun, Jan 01, 2023 at 12:06:51PM -0500, Neal Gompa wrote:
> On Sat, Dec 31, 2022 at 11:44 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Sat, Dec 31, 2022 at 11:23:35AM -0500, Neal Gompa wrote:
> > > On Sat, Dec 31, 2022 at 11:17 AM Miro Hrončok  wrote:
> > > >
> > > > On 31. 12. 22 15:07, Josh Boyer wrote:
> > > > > On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa  wrote:
> > > > >>
> > > > >> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
> > > > >>  wrote:
> > > > >>>
> > > > >>> On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
> > > >  On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton  
> > > >  wrote:
> > > > > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
> > > >  Have we made sure that when Red Hat forks Fedora packages for RHEL
> > > >  that they don't truncate or eliminate the Git history anymore? 
> > > >  Because I would
> > > >  personally be very displeased if my historical attribution went 
> > > >  away
> > > >  because of broken processes like the one used to fork all the 
> > > >  Fedora
> > > >  Linux 34 packages for CentOS Stream 9.
> > > > >>>
> > > > >>> I can't speak for the RH folks who do the forking… It'd be great if
> > > > >>> somebody who knows how that's done could answer.
> > > > >>>
> > > > >>> Fedora is already using rpmautospec widely enough that (if it was to
> > > > >>> be problem at all), it must already be a problem.
> > > > >>>
> > > > >>> At the level of specific solutions, obviously the obvious answer is 
> > > > >>> to
> > > > >>> keep the git history. It's in general a great of source of 
> > > > >>> information
> > > > >>> and discarding that is just an error. But if somebody were really 
> > > > >>> to do that,
> > > > >>> it's fairly trivial to undo the conversion and get a static 
> > > > >>> changelog
> > > > >>> again by inserting the output of 'rpmautospec changelog' in the 
> > > > >>> %changelog
> > > > >>> section.
> > > > >>>
> > > > >>
> > > > >> As they are the most prominent downstream we have, I would like this
> > > > >> resolved before changing Fedora's defaults.
> > > > >>
> > > > >> At the time we branched from Fedora Linux 34, there were very few
> > > > >> packages using rpmautospec and I don't think any that were kept used
> > > > >> rpmautospec. Now it is very obvious it would be a problem, so I would
> > > > >> like that fixed first. CentOS and RHEL infrastructure needs to 
> > > > >> account
> > > > >> for it properly and not gut the Git history.
> > > > >
> > > > > We can look into it, but at the moment this is unlikely to change on
> > > > > the CentOS Stream/RHEL side.
> > > >
> > > > Are the packages imported on SRPM level with the changelogs rendered?
> > > >
> > >
> > > They are not. It's done using distrobaker[1], which syncs Git content
> > > and lookaside data.
> > >
> > > Example commit:
> > > https://gitlab.com/redhat/centos-stream/rpms/pipewire/-/commit/67142e715ecacbf1c94c4d6f8000ef113c1e7c92
> > >
> > > [1]: https://github.com/fedora-eln/distrobaker
> >
> > I don't think that changes in Fedora should be held hostage by some 
> > downstream
> > utils. We know that the problem is solvable and in fact not hard at all. We
> > certainly can notify RHEL maintainers about this, which I did right now [1],
> > but actual implementation is something that we have no control of from the
> > Fedora side.
> >
> > [1] https://github.com/fedora-eln/distrobaker/issues/12
> >
> 
> I think it's absolutely reasonable to consider the effects of people
> forking the packages in a way where attribution is lost. Losing
> attribution and correct package history is just not acceptable to me.
> 
> In many respects, this is *extremely* personal to me, because all I
> *have* is that attribution. I don't make any money on my work in
> Fedora. Nobody pays me to do it. The absolute *least* anyone can do is
> respect my copyright and preserve the attribution and history.
> 
> I am insulted that you think that's an issue that can be hand-waved
> away. This is a hill I will die on.
>
> Fix it. And that means fundamentally changing how distrobaker works.
> Either preserve the whole Git history or always eliminate rpmautospec
> and expand the changelog when importing into RHEL. The current
> situation is simply not acceptable.

I fully support what you are saying. I do a lot of work in Fedora on my
free time too, and I would very much like for it to be attributed properly.
I also agree with the solutions you propose: I wrote the very same suggestions
in the issue I linked above. (I also think that the problem already exists,
*right now*, because rpmautospec is being used fairly widely, and if 
attributions
are stripped, this is not nice to those maintainers and also deprives downstream
users of useful information.)
I just don't think that we should ask Fedora contributors to make plans or
promises for a downstream distro. You are sending your complaints not to the
people who can fix

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Richard Shaw

On Mon, Jan 2, 2023 at 2:44 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:
> > * Vitaly Zaitsev via devel:
> >
> > > On 30/12/2022 20:01, Ben Cotton wrote:
> > >> This document represents a proposed Change. As part of the Changes
> > >> process, proposals are publicly announced in order to receive
> > >> community feedback. This proposal will only be implemented if approved
> > >> by the Fedora Engineering Steering Committee.
> > >
> > > -1 until these known issues[1] are fixed, especially with changelogs
> > >  and using rpmautospec in COPR or mock.
> > >
> > > [1]:
> > >
> https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-constraints
> >
> > The page doesnt discuss COPR/mock?
> >
> > COPR seems to work in some cases, specifically with the dist-git build
> > (but not just building from dist-git).
> >
> > A quick check suggests that rpmautospec does the right thing and
> > produces a portable source RPM that doesn't depend on rpmautospec
> > anymore.  As a result, the compatibility impact won't be too severe, I
> > hope.
>
> Also mock builds seem fine. I tested this now on F37 with a few different
> scenarios:
> - fedpkg mockbuild
> - git commit --allow-empty -m Rebuild && fedpkg mockbuild
> - fedpkg srpm && mock *.src.rpm
> seem to generate the expected versions numbers and changelogs.
>

This is my problem with the proposal. Our tools haven't been fully
integrated. For a typical update I do not need to run git directly, but for
this workflow I do.

For a typical bump all I need is:

rpmdev-bumpspec -c "Change here"
fedpkg commit -c -p
fedpkg build

Our tools need to handle this automagically. I shouldn't have to know I
need to add "--allow-empty". It should just work.

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Zbigniew Jędrzejewski-Szmek

On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:
> * Vitaly Zaitsev via devel:
> 
> > On 30/12/2022 20:01, Ben Cotton wrote:
> >> This document represents a proposed Change. As part of the Changes
> >> process, proposals are publicly announced in order to receive
> >> community feedback. This proposal will only be implemented if approved
> >> by the Fedora Engineering Steering Committee.
> >
> > -1 until these known issues[1] are fixed, especially with changelogs
> >  and using rpmautospec in COPR or mock.
> >
> > [1]:
> > https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-constraints
> 
> The page doesnt discuss COPR/mock?
> 
> COPR seems to work in some cases, specifically with the dist-git build
> (but not just building from dist-git).
> 
> A quick check suggests that rpmautospec does the right thing and
> produces a portable source RPM that doesn't depend on rpmautospec
> anymore.  As a result, the compatibility impact won't be too severe, I
> hope.

Also mock builds seem fine. I tested this now on F37 with a few different 
scenarios:
- fedpkg mockbuild
- git commit --allow-empty -m Rebuild && fedpkg mockbuild
- fedpkg srpm && mock *.src.rpm
seem to generate the expected versions numbers and changelogs.

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Kevin Kofler via devel

Dominik 'Rathann' Mierzejewski wrote:
> Personally, I use the kernel's recommended commit to the oldest
> supported branch and merge upwards workflow and I've learned not to be
> afraid of merge commits. If any branch needs some specific fixes,
> I just apply them there and only there, without using spec conditionals.
> This keeps the specfiles clean and readable, even if they differ
> between branches. Obviously, this can't be (easily) automated and
> doesn't scale to hundreds or thousands of packages, but it works well
> for leaf packages.
> 
> rpmautospec doesn't work with the above workflow as it breaks on those
> merge commits, produces bogus changelog messages and artificially
> inflates Release counters.

This (the failure to handle merge commits) is a serious limitation because 
this is one of the workflows where an autochangelog would be most useful, in 
order to avoid the merge conflicts on the changelog.

If you work the way I do, avoiding merge commits in favor of fast forwards 
and specfile conditionals, then rpmautospec can in principle generate the 
autochangelog, but in that case, I do not really need it because my manual 
changelog fast-forwards just fine along with the rest of the commit.

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Dominik 'Rathann' Mierzejewski

On Monday, 02 January 2023 at 09:57, Miroslav Suchý wrote:
> Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
> > produces bogus changelog messages and artificially
> > inflates Release counters.
> 
> I always wondered why people are afraid of gaps in numbering? It is
> just a number. The number will not object if you skip some of them. :)

Gaps in release numbering are just not neat. To me, they create an
unnecessary confusion. Each bump in Release field should have a
corresponding build in koji and it makes me wonder why if it doesn't.

> Or it is my origin in BASIC that I am not afraid of that? We numbered
> the lines as a multiply of 5 or 10. :)

I've written code in BASIC back in the day. This comment is irrelevant
to the issue at hand.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Jiri Konecny

Similar situation happens if you have spec file in upstream. The problem 
is that mass rebuilds are
adding entries to dowstream spec file only, so you have to manually 
merge the upstream and
downstream or ideally do a backport upstream before realese. This is 
nice and easy solution for

the issue.

Even though, we solved that by using Packit for releasing.

Jirka

Dne 01. 01. 23 v 20:51 Fabio Valentini napsal(a):

On Sat, Dec 31, 2022 at 9:38 PM Stephen Smoogen  wrote:

My main questions are what is this supposed to fix long term?

I have guessed that it has to do with automation, the shrinking number of active 
packagers in operating systems, and the exploding number of packages in requested 
languages (Rust, Go, jq, etc). However, that is just a guess and it doesn't really say 
"HOW" this gets to dealing with this long term. It also isn't clear what the 
underlying remaining active packagers want to be part of.

Speaking for myself: Using rpmautospec has massively reduced the
maintenance burden for the Rust stack, and also for other packages
that I maintain.

Due to the way optional dependencies / features are mapped to RPM
subpackages (this works like with "extra" dependencies in Python
packages, so this is not unique to Rust), you really should regenerate
the entire spec file with rust2rpm for every new version (and every
time when touching a patch that modifies features / optional
dependencies in Rust crate metadata).

Previously, this meant arduously copying the old changelog contents
somewhere, regenerating the spec file with rust2rpm, copying the old
changelog back, set the Release count to "0", run "rpmdev-bumpspec"
for the latest change, and commit the changes (usually with a useless
duplicate of the changelog entry as commit message).

With rpmautospec, all steps except "regenerate the spec file with
rust2rpm" and "git commit -c 'changelog contents'" are eliminated,
which makes updating packages *much* easier, faster, and less
error-prone.

Additionally, not having Release counter and changelog in the .spec
file means that you can usually freely cherry-pick or merge bug-fix
commits across different dist-git branches. This wasn't possible
without rpmautospec due to merge conflicts caused by different Release
counter or changelog contents.

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

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Maxwell G via devel

On Mon Jan 2, 2023 at 09:57 +0100, Miroslav Suchý wrote:
> Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
> > produces bogus changelog messages and artificially
> > inflates Release counters.
>
> I always wondered why people are afraid of gaps in numbering? It is
> just a number. The number will not object if you skip some of them. :)

The release number shows how many builds of the same version have been
made. A high release is also baseline indicator that a package/project
is stale downstream and/or upstream. When the first build of foo v1.5.0
is foo-1.5.0-6 because the author took the time to split up logical
changes into separate commits, the value of that release number is lost.

--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Miroslav Suchý


Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):

produces bogus changelog messages and artificially
inflates Release counters.


I always wondered why people are afraid of gaps in numbering? It is just a number. The number will not object if you 
skip some of them. :)


Or it is my origin in BASIC that I am not afraid of that? We numbered the lines 
as a multiply of 5 or 10. :)

Miroslav
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-02 Thread Dominik 'Rathann' Mierzejewski

On Sunday, 01 January 2022 at 20:51, Fabio Valentini wrote:
[...]
> Additionally, not having Release counter and changelog in the .spec
> file means that you can usually freely cherry-pick or merge bug-fix
> commits across different dist-git branches. This wasn't possible
> without rpmautospec due to merge conflicts caused by different Release
> counter or changelog contents.

Personally, I use the kernel's recommended commit to the oldest
supported branch and merge upwards workflow and I've learned not to be
afraid of merge commits. If any branch needs some specific fixes,
I just apply them there and only there, without using spec conditionals.
This keeps the specfiles clean and readable, even if they differ
between branches. Obviously, this can't be (easily) automated and
doesn't scale to hundreds or thousands of packages, but it works well
for leaf packages.

rpmautospec doesn't work with the above workflow as it breaks on those
merge commits, produces bogus changelog messages and artificially
inflates Release counters.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-01 Thread Kevin Kofler via devel

Fabio Valentini wrote:
> Speaking for myself: Using rpmautospec has massively reduced the
> maintenance burden for the Rust stack, and also for other packages
> that I maintain.
> 
> Due to the way optional dependencies / features are mapped to RPM
> subpackages (this works like with "extra" dependencies in Python
> packages, so this is not unique to Rust), you really should regenerate
> the entire spec file with rust2rpm for every new version (and every
> time when touching a patch that modifies features / optional
> dependencies in Rust crate metadata).
> 
> Previously, this meant arduously copying the old changelog contents
> somewhere, regenerating the spec file with rust2rpm, copying the old
> changelog back, set the Release count to "0", run "rpmdev-bumpspec"
> for the latest change, and commit the changes (usually with a useless
> duplicate of the changelog entry as commit message).
> 
> With rpmautospec, all steps except "regenerate the spec file with
> rust2rpm" and "git commit -c 'changelog contents'" are eliminated,
> which makes updating packages *much* easier, faster, and less
> error-prone.

So it looks like in this case, it helps. That does not mean it needs to be 
the default for packages which are not autogenerated though.

> Additionally, not having Release counter and changelog in the .spec
> file means that you can usually freely cherry-pick or merge bug-fix
> commits across different dist-git branches. This wasn't possible
> without rpmautospec due to merge conflicts caused by different Release
> counter or changelog contents.

If I have a package that I upgrade in stable releases, I keep Release in 
sync, and the changelog only really reflects Rawhide. I just fast-forward 
Rawhide to the release branch, and the Release tag and the changelog go 
along with it. If that includes some "Rebuild for Fnn mass rebuild" entries 
that do not really apply to the release branch, so be it. At least it 
explains why the Release number is as high as it is.

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-01 Thread Kevin Fenzi

On Sat, Dec 31, 2022 at 03:37:34PM -0500, Stephen Smoogen wrote:
> On Sat, 31 Dec 2022 at 13:40, Kevin Kofler via devel <
> > https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#changelog-entries-generated-from-commit-messages
> >
> > All in all a very complicated and error-prone process just to save some
> > extremely lazy packagers a 5-second copy I really do not see why
> > that
> > should be the default and recommended process.
> >
> > The rules how to format the commit message are error-prone, and if you get
> > them wrong, you usually only notice when it is too late to fix it (because
> > force-pushes are not allowed). Yes, you can manually run "rpmautospec
> > generate-changelog", but that is actually no less effort than just taking
> > care of the changelog manually to begin with.
> >
> 
> My main questions are what is this supposed to fix long term?

My understanding is that the main thing rpmautospec is supposed to
address is to decouple changelog and release values from specific
changes. This for example makes pull requests much easier. 

Without it, pull requests either have to specifically tie a change to a
release/changelog entry or leave that to the maintainer. 
With it, PR's can be applied in any order or after some other unrelated
changes without a bunch of back and forth to adjust the
release/changelog to match unrelated changes. 

I think moving more things to it makes a lot of sense as long as we are
moving to a more pull request flow. I can't speak for others, but I have
indeed noticed a increase in PR's on packages I maintain over the last
few years.

kevin

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-01 Thread Fabio Valentini

On Sat, Dec 31, 2022 at 9:38 PM Stephen Smoogen  wrote:
>
> My main questions are what is this supposed to fix long term?
>
> I have guessed that it has to do with automation, the shrinking number of 
> active packagers in operating systems, and the exploding number of packages 
> in requested languages (Rust, Go, jq, etc). However, that is just a guess and 
> it doesn't really say "HOW" this gets to dealing with this long term. It also 
> isn't clear what the underlying remaining active packagers want to be part of.

Speaking for myself: Using rpmautospec has massively reduced the
maintenance burden for the Rust stack, and also for other packages
that I maintain.

Due to the way optional dependencies / features are mapped to RPM
subpackages (this works like with "extra" dependencies in Python
packages, so this is not unique to Rust), you really should regenerate
the entire spec file with rust2rpm for every new version (and every
time when touching a patch that modifies features / optional
dependencies in Rust crate metadata).

Previously, this meant arduously copying the old changelog contents
somewhere, regenerating the spec file with rust2rpm, copying the old
changelog back, set the Release count to "0", run "rpmdev-bumpspec"
for the latest change, and commit the changes (usually with a useless
duplicate of the changelog entry as commit message).

With rpmautospec, all steps except "regenerate the spec file with
rust2rpm" and "git commit -c 'changelog contents'" are eliminated,
which makes updating packages *much* easier, faster, and less
error-prone.

Additionally, not having Release counter and changelog in the .spec
file means that you can usually freely cherry-pick or merge bug-fix
commits across different dist-git branches. This wasn't possible
without rpmautospec due to merge conflicts caused by different Release
counter or changelog contents.

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-01 Thread Neal Gompa

On Sat, Dec 31, 2022 at 11:44 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Sat, Dec 31, 2022 at 11:23:35AM -0500, Neal Gompa wrote:
> > On Sat, Dec 31, 2022 at 11:17 AM Miro Hrončok  wrote:
> > >
> > > On 31. 12. 22 15:07, Josh Boyer wrote:
> > > > On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa  wrote:
> > > >>
> > > >> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
> > > >>  wrote:
> > > >>>
> > > >>> On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
> > >  On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton  
> > >  wrote:
> > > > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
> > >  Have we made sure that when Red Hat forks Fedora packages for RHEL
> > >  that they don't truncate or eliminate the Git history anymore? 
> > >  Because I would
> > >  personally be very displeased if my historical attribution went away
> > >  because of broken processes like the one used to fork all the Fedora
> > >  Linux 34 packages for CentOS Stream 9.
> > > >>>
> > > >>> I can't speak for the RH folks who do the forking… It'd be great if
> > > >>> somebody who knows how that's done could answer.
> > > >>>
> > > >>> Fedora is already using rpmautospec widely enough that (if it was to
> > > >>> be problem at all), it must already be a problem.
> > > >>>
> > > >>> At the level of specific solutions, obviously the obvious answer is to
> > > >>> keep the git history. It's in general a great of source of information
> > > >>> and discarding that is just an error. But if somebody were really to 
> > > >>> do that,
> > > >>> it's fairly trivial to undo the conversion and get a static changelog
> > > >>> again by inserting the output of 'rpmautospec changelog' in the 
> > > >>> %changelog
> > > >>> section.
> > > >>>
> > > >>
> > > >> As they are the most prominent downstream we have, I would like this
> > > >> resolved before changing Fedora's defaults.
> > > >>
> > > >> At the time we branched from Fedora Linux 34, there were very few
> > > >> packages using rpmautospec and I don't think any that were kept used
> > > >> rpmautospec. Now it is very obvious it would be a problem, so I would
> > > >> like that fixed first. CentOS and RHEL infrastructure needs to account
> > > >> for it properly and not gut the Git history.
> > > >
> > > > We can look into it, but at the moment this is unlikely to change on
> > > > the CentOS Stream/RHEL side.
> > >
> > > Are the packages imported on SRPM level with the changelogs rendered?
> > >
> >
> > They are not. It's done using distrobaker[1], which syncs Git content
> > and lookaside data.
> >
> > Example commit:
> > https://gitlab.com/redhat/centos-stream/rpms/pipewire/-/commit/67142e715ecacbf1c94c4d6f8000ef113c1e7c92
> >
> > [1]: https://github.com/fedora-eln/distrobaker
>
> I don't think that changes in Fedora should be held hostage by some downstream
> utils. We know that the problem is solvable and in fact not hard at all. We
> certainly can notify RHEL maintainers about this, which I did right now [1],
> but actual implementation is something that we have no control of from the
> Fedora side.
>
> [1] https://github.com/fedora-eln/distrobaker/issues/12
>

I think it's absolutely reasonable to consider the effects of people
forking the packages in a way where attribution is lost. Losing
attribution and correct package history is just not acceptable to me.

In many respects, this is *extremely* personal to me, because all I
*have* is that attribution. I don't make any money on my work in
Fedora. Nobody pays me to do it. The absolute *least* anyone can do is
respect my copyright and preserve the attribution and history.

I am insulted that you think that's an issue that can be hand-waved
away. This is a hill I will die on.

Fix it. And that means fundamentally changing how distrobaker works.
Either preserve the whole Git history or always eliminate rpmautospec
and expand the changelog when importing into RHEL. The current
situation is simply not acceptable.









--
真実はいつも一つ！/ 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-01 Thread Florian Weimer

* Vitaly Zaitsev via devel:

> On 30/12/2022 20:01, Ben Cotton wrote:
>> This document represents a proposed Change. As part of the Changes
>> process, proposals are publicly announced in order to receive
>> community feedback. This proposal will only be implemented if approved
>> by the Fedora Engineering Steering Committee.
>
> -1 until these known issues[1] are fixed, especially with changelogs
>  and using rpmautospec in COPR or mock.
>
> [1]:
> https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-constraints

The page doesnt discuss COPR/mock?

COPR seems to work in some cases, specifically with the dist-git build
(but not just building from dist-git).

A quick check suggests that rpmautospec does the right thing and
produces a portable source RPM that doesn't depend on rpmautospec
anymore.  As a result, the compatibility impact won't be too severe, I
hope.

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2022-12-31 Thread Stephen Smoogen

On Sat, 31 Dec 2022 at 13:40, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Zbigniew Jędrzejewski-Szmek wrote:
> > tl;dr: you want to fix changelog entries. That's supported by saving the
> > generated changelog to 'changelog' file and doing whatever edits you want
> > there.
> >
> > With that approach, you can do arbitrary formatting and fixups. The
> > advantage compared to status quo (non-autochangelog) is that you only
> need
> > to do it if the autogenerated changelog is deficient for whatever
> reasons.
> > In the default case you can use autochangelog, and fall back to the
> manual
> > version when necessary.
> [snip]
> > Rpmautospec allows you to have a part or parts of a commit message that
> > end up in the changelog, and parts that do not, see
> >
> https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#changelog-entries-generated-from-commit-messages
>
> All in all a very complicated and error-prone process just to save some
> extremely lazy packagers a 5-second copy I really do not see why
> that
> should be the default and recommended process.
>
> The rules how to format the commit message are error-prone, and if you get
> them wrong, you usually only notice when it is too late to fix it (because
> force-pushes are not allowed). Yes, you can manually run "rpmautospec
> generate-changelog", but that is actually no less effort than just taking
> care of the changelog manually to begin with.
>

My main questions are what is this supposed to fix long term?

I have guessed that it has to do with automation, the shrinking number of
active packagers in operating systems, and the exploding number of packages
in requested languages (Rust, Go, jq, etc). However, that is just a guess
and it doesn't really say "HOW" this gets to dealing with this long term.
It also isn't clear what the underlying remaining active packagers want to
be part of.



-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2022-12-31 Thread Kevin Kofler via devel

Zbigniew Jędrzejewski-Szmek wrote:
> tl;dr: you want to fix changelog entries. That's supported by saving the
> generated changelog to 'changelog' file and doing whatever edits you want
> there.
> 
> With that approach, you can do arbitrary formatting and fixups. The
> advantage compared to status quo (non-autochangelog) is that you only need
> to do it if the autogenerated changelog is deficient for whatever reasons.
> In the default case you can use autochangelog, and fall back to the manual
> version when necessary.
[snip]
> Rpmautospec allows you to have a part or parts of a commit message that
> end up in the changelog, and parts that do not, see
> https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#changelog-entries-generated-from-commit-messages

All in all a very complicated and error-prone process just to save some 
extremely lazy packagers a 5-second copy I really do not see why that 
should be the default and recommended process.

The rules how to format the commit message are error-prone, and if you get 
them wrong, you usually only notice when it is too late to fix it (because 
force-pushes are not allowed). Yes, you can manually run "rpmautospec 
generate-changelog", but that is actually no less effort than just taking 
care of the changelog manually to begin with.

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Sat, Dec 31, 2022 at 11:23:35AM -0500, Neal Gompa wrote:
> On Sat, Dec 31, 2022 at 11:17 AM Miro Hrončok  wrote:
> >
> > On 31. 12. 22 15:07, Josh Boyer wrote:
> > > On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa  wrote:
> > >>
> > >> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
> > >>  wrote:
> > >>>
> > >>> On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
> >  On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton  wrote:
> > > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
> >  Have we made sure that when Red Hat forks Fedora packages for RHEL
> >  that they don't truncate or eliminate the Git history anymore? Because 
> >  I would
> >  personally be very displeased if my historical attribution went away
> >  because of broken processes like the one used to fork all the Fedora
> >  Linux 34 packages for CentOS Stream 9.
> > >>>
> > >>> I can't speak for the RH folks who do the forking… It'd be great if
> > >>> somebody who knows how that's done could answer.
> > >>>
> > >>> Fedora is already using rpmautospec widely enough that (if it was to
> > >>> be problem at all), it must already be a problem.
> > >>>
> > >>> At the level of specific solutions, obviously the obvious answer is to
> > >>> keep the git history. It's in general a great of source of information
> > >>> and discarding that is just an error. But if somebody were really to do 
> > >>> that,
> > >>> it's fairly trivial to undo the conversion and get a static changelog
> > >>> again by inserting the output of 'rpmautospec changelog' in the 
> > >>> %changelog
> > >>> section.
> > >>>
> > >>
> > >> As they are the most prominent downstream we have, I would like this
> > >> resolved before changing Fedora's defaults.
> > >>
> > >> At the time we branched from Fedora Linux 34, there were very few
> > >> packages using rpmautospec and I don't think any that were kept used
> > >> rpmautospec. Now it is very obvious it would be a problem, so I would
> > >> like that fixed first. CentOS and RHEL infrastructure needs to account
> > >> for it properly and not gut the Git history.
> > >
> > > We can look into it, but at the moment this is unlikely to change on
> > > the CentOS Stream/RHEL side.
> >
> > Are the packages imported on SRPM level with the changelogs rendered?
> >
> 
> They are not. It's done using distrobaker[1], which syncs Git content
> and lookaside data.
> 
> Example commit:
> https://gitlab.com/redhat/centos-stream/rpms/pipewire/-/commit/67142e715ecacbf1c94c4d6f8000ef113c1e7c92
> 
> [1]: https://github.com/fedora-eln/distrobaker

I don't think that changes in Fedora should be held hostage by some downstream
utils. We know that the problem is solvable and in fact not hard at all. We
certainly can notify RHEL maintainers about this, which I did right now [1],
but actual implementation is something that we have no control of from the
Fedora side.

[1] https://github.com/fedora-eln/distrobaker/issues/12

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Sat, Dec 31, 2022 at 01:09:54AM +0100, Kevin Kofler via devel wrote:
> > Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
> > the default approach.
> > Packaging Guidelines and other documentation are adjusted to describe
> > this approach first.
> > Various tools that provide spec file templates are adjusted.
> 
> -1 to this proposal.
> 
> As I had already written when this was first introduced,

Rpmautospec is not the same now as it was two years ago. Your reseverations
are mostly solved. See below.

> autogenerating the changelog from git history is a bad idea, especially in 
> Fedora dist-git 
> where published git history cannot ever be rewritten, so it is impossible to 
> fix typos in the changelog, hide fixup commits if they did not use the 
> proper fixup markup (or even avoid them altogether by amending the 
> previously pushed commit), etc., which all requires to at least be able to 
> edit commit messages

tl;dr: you want to fix changelog entries. That's supported by saving the
generated changelog to 'changelog' file and doing whatever edits you want there.

With that approach, you can do arbitrary formatting and fixups. The advantage
compared to status quo (non-autochangelog) is that you only need to do it if the
autogenerated changelog is deficient for whatever reasons. In the default case
you can use autochangelog, and fall back to the manual version when necessary.

> In addition, it assumes that the commits in git use the correct format for 
> %autochangelog.
[snip long description of some very specific workflow]

Rpmautospec allows you to have a part or parts of a commit message that end up
in the changelog, and parts that do not, see
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#changelog-entries-generated-from-commit-messages

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2022-12-31 Thread Neal Gompa

On Sat, Dec 31, 2022 at 11:17 AM Miro Hrončok  wrote:
>
> On 31. 12. 22 15:07, Josh Boyer wrote:
> > On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa  wrote:
> >>
> >> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
> >>  wrote:
> >>>
> >>> On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
>  On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton  wrote:
> > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
>  Have we made sure that when Red Hat forks Fedora packages for RHEL
>  that they don't truncate or eliminate the Git history anymore? Because I 
>  would
>  personally be very displeased if my historical attribution went away
>  because of broken processes like the one used to fork all the Fedora
>  Linux 34 packages for CentOS Stream 9.
> >>>
> >>> I can't speak for the RH folks who do the forking… It'd be great if
> >>> somebody who knows how that's done could answer.
> >>>
> >>> Fedora is already using rpmautospec widely enough that (if it was to
> >>> be problem at all), it must already be a problem.
> >>>
> >>> At the level of specific solutions, obviously the obvious answer is to
> >>> keep the git history. It's in general a great of source of information
> >>> and discarding that is just an error. But if somebody were really to do 
> >>> that,
> >>> it's fairly trivial to undo the conversion and get a static changelog
> >>> again by inserting the output of 'rpmautospec changelog' in the %changelog
> >>> section.
> >>>
> >>
> >> As they are the most prominent downstream we have, I would like this
> >> resolved before changing Fedora's defaults.
> >>
> >> At the time we branched from Fedora Linux 34, there were very few
> >> packages using rpmautospec and I don't think any that were kept used
> >> rpmautospec. Now it is very obvious it would be a problem, so I would
> >> like that fixed first. CentOS and RHEL infrastructure needs to account
> >> for it properly and not gut the Git history.
> >
> > We can look into it, but at the moment this is unlikely to change on
> > the CentOS Stream/RHEL side.
>
> Are the packages imported on SRPM level with the changelogs rendered?
>

They are not. It's done using distrobaker[1], which syncs Git content
and lookaside data.

Example commit:
https://gitlab.com/redhat/centos-stream/rpms/pipewire/-/commit/67142e715ecacbf1c94c4d6f8000ef113c1e7c92

[1]: https://github.com/fedora-eln/distrobaker




--
真実はいつも一つ！/ 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2022-12-31 Thread Miro Hrončok


On 31. 12. 22 15:07, Josh Boyer wrote:

On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa  wrote:


On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
 wrote:


On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:

On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton  wrote:

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

Have we made sure that when Red Hat forks Fedora packages for RHEL
that they don't truncate or eliminate the Git history anymore? Because I would
personally be very displeased if my historical attribution went away
because of broken processes like the one used to fork all the Fedora
Linux 34 packages for CentOS Stream 9.


I can't speak for the RH folks who do the forking… It'd be great if
somebody who knows how that's done could answer.

Fedora is already using rpmautospec widely enough that (if it was to
be problem at all), it must already be a problem.

At the level of specific solutions, obviously the obvious answer is to
keep the git history. It's in general a great of source of information
and discarding that is just an error. But if somebody were really to do that,
it's fairly trivial to undo the conversion and get a static changelog
again by inserting the output of 'rpmautospec changelog' in the %changelog
section.



As they are the most prominent downstream we have, I would like this
resolved before changing Fedora's defaults.

At the time we branched from Fedora Linux 34, there were very few
packages using rpmautospec and I don't think any that were kept used
rpmautospec. Now it is very obvious it would be a problem, so I would
like that fixed first. CentOS and RHEL infrastructure needs to account
for it properly and not gut the Git history.


We can look into it, but at the moment this is unlikely to change on
the CentOS Stream/RHEL side.


Are the packages imported on SRPM level with the changelogs rendered?

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2022-12-31 Thread Neal Gompa

On Sat, Dec 31, 2022 at 9:07 AM Josh Boyer  wrote:
>
> On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa  wrote:
> >
> > On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
> > > > On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton  wrote:
> > > > > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
> > > > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > > > that they don't truncate or eliminate the Git history anymore? Because 
> > > > I would
> > > > personally be very displeased if my historical attribution went away
> > > > because of broken processes like the one used to fork all the Fedora
> > > > Linux 34 packages for CentOS Stream 9.
> > >
> > > I can't speak for the RH folks who do the forking… It'd be great if
> > > somebody who knows how that's done could answer.
> > >
> > > Fedora is already using rpmautospec widely enough that (if it was to
> > > be problem at all), it must already be a problem.
> > >
> > > At the level of specific solutions, obviously the obvious answer is to
> > > keep the git history. It's in general a great of source of information
> > > and discarding that is just an error. But if somebody were really to do 
> > > that,
> > > it's fairly trivial to undo the conversion and get a static changelog
> > > again by inserting the output of 'rpmautospec changelog' in the %changelog
> > > section.
> > >
> >
> > As they are the most prominent downstream we have, I would like this
> > resolved before changing Fedora's defaults.
> >
> > At the time we branched from Fedora Linux 34, there were very few
> > packages using rpmautospec and I don't think any that were kept used
> > rpmautospec. Now it is very obvious it would be a problem, so I would
> > like that fixed first. CentOS and RHEL infrastructure needs to account
> > for it properly and not gut the Git history.
>
> We can look into it, but at the moment this is unlikely to change on
> the CentOS Stream/RHEL side.
>

Then we should not change the defaults and not recommend rpmautospec,
especially for packages that Red Hat forks for CentOS/RHEL.



-- 
真実はいつも一つ！/ 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2022-12-31 Thread Josh Boyer

On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa  wrote:
>
> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
> > > On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton  wrote:
> > > > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
> > > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > > that they don't truncate or eliminate the Git history anymore? Because I 
> > > would
> > > personally be very displeased if my historical attribution went away
> > > because of broken processes like the one used to fork all the Fedora
> > > Linux 34 packages for CentOS Stream 9.
> >
> > I can't speak for the RH folks who do the forking… It'd be great if
> > somebody who knows how that's done could answer.
> >
> > Fedora is already using rpmautospec widely enough that (if it was to
> > be problem at all), it must already be a problem.
> >
> > At the level of specific solutions, obviously the obvious answer is to
> > keep the git history. It's in general a great of source of information
> > and discarding that is just an error. But if somebody were really to do 
> > that,
> > it's fairly trivial to undo the conversion and get a static changelog
> > again by inserting the output of 'rpmautospec changelog' in the %changelog
> > section.
> >
>
> As they are the most prominent downstream we have, I would like this
> resolved before changing Fedora's defaults.
>
> At the time we branched from Fedora Linux 34, there were very few
> packages using rpmautospec and I don't think any that were kept used
> rpmautospec. Now it is very obvious it would be a problem, so I would
> like that fixed first. CentOS and RHEL infrastructure needs to account
> for it properly and not gut the Git history.

We can look into it, but at the moment this is unlikely to change on
the CentOS Stream/RHEL side.

josh
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2022-12-31 Thread Mattia Verga via devel

Il 30/12/22 20:01, Ben Cotton ha scritto:
> https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
>
I'm lazy, so I usually just 'git merge rawhide' in other branches...
what's the support status of rpmautospec for EPEL? Last time I tried, it
wasn't working in EPEL8.

Mattia

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2022-12-31 Thread Vitaly Zaitsev via devel


On 30/12/2022 22:49, Zbigniew Jędrzejewski-Szmek wrote:

That's OK, the idea is to make this opt-in.


It is already opt-in. Some packages switched to rpmautospec when it was 
introduced.


I've done this too for some of my packages and due to known issues 
reverted back to classic behavior due to the bogus auto-generated 
%changelog.


If anyone wants to debug, feel free to check out the aircrack-ng package.

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Fri, Dec 30, 2022 at 07:56:05PM -0500, Neal Gompa wrote:
> On Fri, Dec 30, 2022 at 4:50 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Fri, Dec 30, 2022 at 08:46:46PM -, Leigh Scott wrote:
> > > -1 for this change.
> > > I will ignore it if it's accepted.
> >
> > That's OK, the idea is to make this opt-in.
> > Without any specific concerns, that's all I can say.
> >
> 
> This Change seems to be about flipping the defaults to make people
> opt-out. If it's opt-in, this Change is null, since that's the status quo.

I guess we can split the difference: it's opt-in for existing packages,
and opt-out for new 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)