On 07. 04. 24 17:47, Miro Hrončok wrote:
Note that it produces incorrect results if the Release value is not numerical
(or if it is a greater number than count of the commits since last bump). It
will happily convert release 0.1 to 3, 29.20130501hg26242d0aa7b8 to 30 or even
release 500 to 10.
I think missing easy to use documentation is the most missing part of
current rpmautospec package. Manual page does not exist, readme is in
wrong package.
I have proposed to be able to include extra section just for changelog.
I do not remember which exactly way was merged instead, there
Before any such ideas continue, I think rpmautospec should have more
decent documentation. Unfortunately it does not have even manual page
for rpmautospec command, core of its functionality. I find that missing.
While I think rpmautospec is great idea, I do not think it is ready
universally.
On Thu, Apr 11, 2024 at 09:18:09AM +0200, Ondrej Mosnáček wrote:
> On Wed, 10 Apr 2024 at 16:30, Pierre-Yves Chibon wrote:
> [...]
> > Let's look at it in another way: would you say that the people who leaved
> > in the
> > 14th century were liars for saying that the earth is flat?
> > No, they
On Thu, Apr 11, 2024 at 12:39 PM Leon Fauster via devel
wrote:
>
> Am 08.04.24 um 08:01 schrieb Miro Hrončok:
> > On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote:
> >>
> >> Not all commits correspond with a new release downstream, and not all
> >> commit messages are relevant to the end user
Am 08.04.24 um 08:01 schrieb Miro Hrončok:
On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote:
Not all commits correspond with a new release downstream, and not all
commit messages are relevant to the end user to be part of the change
log. For example, commits related with increasing
On Wed, 10 Apr 2024 at 16:30, Pierre-Yves Chibon wrote:
[...]
> Let's look at it in another way: would you say that the people who leaved in
> the
> 14th century were liars for saying that the earth is flat?
> No, they just didn't know.
Off-topic and not really affecting the validity of your
On Mon, Apr 08, 2024 at 02:55:36PM +0200, Emmanuel Seyman wrote:
> * Zbigniew Jędrzejewski-Szmek [08/04/2024 09:02] :
> >
> > Well, you and Kevin see "salami tactics" (whatever that may be),
>
> FTR, I have no idea what "salami tactics" is.
>
> > while I see normal engineering practice: some new
On Tue, Apr 09, 2024 at 05:02:00PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Apr 09, 2024 at 03:38:07PM +0200, Gerd Hoffmann wrote:
> > > In particular:
> > > - local builds work, I do them all the time, with 'fedpkg local' or
> > > through an srpm.
> >
> > Using rpmbuild directly
Remi Collet venit, vidit, dixit 2024-04-09 10:23:57:
> Le 08/04/2024 à 18:43, Michael J Gruber a écrit :
>
> > How absurd!
>
> That is rude, and ONLY your PoV.
>
>
> To summarize, there is no agreement on a unique
> workflow, and having one to become the only allowed
> seems to me as a
Dne 09. 04. 24 v 19:06 Zbigniew Jędrzejewski-Szmek napsal(a):
On Tue, Apr 09, 2024 at 12:57:33PM -0400, Neal Gompa wrote:
On Tue, Apr 9, 2024 at 12:56 PM Zbigniew Jędrzejewski-Szmek
wrote:
On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote:
Dne 08. 04. 24 v 10:43 Zbigniew
-1
I have some packages using the %autorelease packages and I do not like
that workflow at all.
For me the git commit history is intended for maintainers, while the
%changelog is intended for users. With the separation, then it is very
explicit, when mixing them, then I need to figure out if
On Tue, Apr 09, 2024 at 05:39:11PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Apr 08, 2024 at 01:12:38PM -0500, Michel Lind wrote:
> > On Mon, Apr 08, 2024 at 07:21:40AM -0400, Neal Gompa wrote:
> > > On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar wrote:
> > > > It's bascially the same
On Mon, Apr 08, 2024 at 01:12:38PM -0500, Michel Lind wrote:
> On Mon, Apr 08, 2024 at 07:21:40AM -0400, Neal Gompa wrote:
> > On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar wrote:
> > > It's bascially the same problem as Fedora has when users upgrade from
> > > Fredora
> > > 40 to 41. Fedora "fixed"
On Mon, Apr 08, 2024 at 04:11:14PM +0200, Petr Pisar wrote:
> V Mon, Apr 08, 2024 at 11:37:48AM +, Zbigniew Jędrzejewski-Szmek
> napsal(a):
> > OK, so you mean that the approach with '.' at the end of Release
> > doesn't work. Yes, that case is not supported very well.
> >
> > There is no
On Tue, Apr 09, 2024 at 12:57:33PM -0400, Neal Gompa wrote:
> On Tue, Apr 9, 2024 at 12:56 PM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote:
> > >
> > > Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a):
> > > > And we already
On Tue, Apr 9, 2024 at 6:58 PM Neal Gompa wrote:
>
> On Tue, Apr 9, 2024 at 12:56 PM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote:
> > >
> > > Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a):
> > > > And we already have a
On Tue, Apr 09, 2024 at 03:38:07PM +0200, Gerd Hoffmann wrote:
> > In particular:
> > - local builds work, I do them all the time, with 'fedpkg local' or
> > through an srpm.
>
> Using rpmbuild directly needs some adaption though:
>
> (1) Use 'rpmautospec calculate-release' to figure what the
On Tue, Apr 9, 2024 at 12:56 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote:
> >
> > Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a):
> > > And we already have a significant fraction of packages using rpmautospec,
> >
> >
> >
On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote:
>
> Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a):
> > And we already have a significant fraction of packages using rpmautospec,
>
>
> Actually, could you quantify the "significant fraction"?
7399 / 23912 = 31%.
On Tue, Apr 09, 2024 at 10:04:11AM +0200, Remi Collet wrote:
> Le 07/04/2024 à 17:15, Zbigniew Jędrzejewski-Szmek a écrit :
> > Thus, the proposal:
> > - new packages MUST use rpmautospec
> > - packagers SHOULD convert their packages
> > - provenpackagers MAY convert existing packages
> >(e.g.
On Tue, Apr 09, 2024 at 02:20:37PM +0200, Petr Pisar wrote:
> > - should we extend this further and say, if we no longer assume NEVRAs
> > are monotonically increasing in a new release, we should allow
> > packagers to use this opportunity to drop epochs in Rawhide? (likely
> > with proper
> In particular:
> - local builds work, I do them all the time, with 'fedpkg local' or
> through an srpm.
Using rpmbuild directly needs some adaption though:
(1) Use 'rpmautospec calculate-release' to figure what the release
number is.
(2) Pass that to rpmbuild using --define
V Mon, Apr 08, 2024 at 01:12:38PM -0500, Michel Lind napsal(a):
> - should we update the packaging docs? Does this need to be a new Change
> Proposal or does this just need to go through the Fedora packaging
> committee? (Those involved in the Change like zbyszek can probably
> advise here)
Le 08/04/2024 à 18:43, Michael J Gruber a écrit :
How absurd!
That is rude, and ONLY your PoV.
To summarize, there is no agreement on a unique
workflow, and having one to become the only allowed
seems to me as a terrible idea.
Remi
--
___
devel
Le 07/04/2024 à 17:15, Zbigniew Jędrzejewski-Szmek a écrit :
Thus, the proposal:
- new packages MUST use rpmautospec
- packagers SHOULD convert their packages
- provenpackagers MAY convert existing packages
(e.g. when they want to push some fix or separately from other
work)
- people
Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a):
And we already have a significant fraction of packages using rpmautospec,
Actually, could you quantify the "significant fraction"?
Thx
Vít
OpenPGP_signature.asc
Description: OpenPGP digital signature
--
On Mon, Apr 8, 2024 at 5:22 PM Leon Fauster via devel
wrote:
>
> Am 08.04.24 um 22:22 schrieb Michel Lind:
> > On Mon, Apr 08, 2024 at 08:47:20PM +0200, Leon Fauster via devel wrote:
> >> Am 08.04.24 um 20:12 schrieb Michel Lind:
> >>> (this might require coordination with RH's Leapp
Am 08.04.24 um 22:22 schrieb Michel Lind:
On Mon, Apr 08, 2024 at 08:47:20PM +0200, Leon Fauster via devel wrote:
Am 08.04.24 um 20:12 schrieb Michel Lind:
(this might require coordination with RH's Leapp developers and
AlmaLinux's ELevate developers, to make sure those support
On Mon, Apr 08, 2024 at 08:47:20PM +0200, Leon Fauster via devel wrote:
> Am 08.04.24 um 20:12 schrieb Michel Lind:
> >(this might require coordination with RH's Leapp developers and
> >AlmaLinux's ELevate developers, to make sure those support upgrading
> >to lower NEVRAs too)
>
>
Zbigniew Jędrzejewski-Szmek wrote:
> And sorry, but saying to "process pull requests quickly" is just naive.
> Busy packages often have many different pull requests concurrently, and
> some of them need discussion and fixes and work in other places before
> they can be merged.
Generally, there
Am 08.04.24 um 20:12 schrieb Michel Lind:
(this might require coordination with RH's Leapp developers and
AlmaLinux's ELevate developers, to make sure those support upgrading
to lower NEVRAs too)
Would have a major EL release have a lower package NEVRA?
Mmmh, how many fedora releases
On Mon, Apr 08, 2024 at 07:21:40AM -0400, Neal Gompa wrote:
> On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar wrote:
> > It's bascially the same problem as Fedora has when users upgrade from
> > Fredora
> > 40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade
> > path
> > between
Am 08.04.24 um 14:55 schrieb Emmanuel Seyman:
Well, you and Kevin see "salami tactics" (whatever that may be),
FTR, I have no idea what "salami tactics" is.
Since apperently multiple people don't know the term:
https://en.wikipedia.org/wiki/Salami_slicing_tactics
Regards
Kilian
--
Zbigniew Jędrzejewski-Szmek venit, vidit, dixit 2024-04-07 17:15:16:
> Hi everyone,
>
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
>
> All my packages have been
Thank you Zbigniew and Miro for the link.
On 4/8/24 02:18, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, Apr 07, 2024 at 09:08:49PM -0700, Carlos Rodriguez-Fernandez wrote:
On 4/7/24 21:07, Carlos Rodriguez-Fernandez wrote:
Not all commits correspond with a new release downstream, and not all
On Mon, Apr 8, 2024 at 2:26 PM Tom Hughes via devel
wrote:
>
> On 08/04/2024 14:47, Fabio Valentini wrote:
>
> > It is already supposed to be default / preferred since this Fedora 38
> > Change:
> > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
>
> I find that quite interesting
On 08/04/2024 14:47, Fabio Valentini wrote:
It is already supposed to be default / preferred since this Fedora 38 Change:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
I find that quite interesting because while I may have read it at
the time I had certainly long since
Dne 08. 04. 24 v 2:55 odp. Emmanuel Seyman napsal(a):
FTR, I have no idea what "salami tactics" is.
https://en.wikipedia.org/wiki/Salami_slicing_tactics
Something that would be unacceptable to be done in one step is possible when
you do that in tiny steps.
You cannot eat whole salami, but
On 08/04/2024 10:28, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Apr 08, 2024 at 09:08:19AM +0200, Miroslav Lichvar wrote:
On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote:
-1 for existing packages certainly - none of my git commit logs
are written with the expectation that
V Mon, Apr 08, 2024 at 11:37:48AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> OK, so you mean that the approach with '.' at the end of Release
> doesn't work. Yes, that case is not supported very well.
>
> There is no great solution here, but there are a few options. Which
> one makes the
On Mon, 8 Apr 2024 at 15:47, Fabio Valentini wrote:
> On Mon, Apr 8, 2024 at 3:28 PM Iñaki Ucar wrote:
> >
> > So someone wanted to use rpmautospec and was willing to do the work,
> putting things together as an opt-in feature. Perfect.
> >
> > Now, I don't see any problem if some time later
V Mon, Apr 08, 2024 at 11:37:48AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Apr 08, 2024 at 01:11:22PM +0200, Petr Pisar wrote:
> > RHEL do updates into older minor distribution versions. E.g. you might want
> > to
> > build for RHEL 9.2 and RHEL 9.3. Users staying on 9.2 should
On Mon, Apr 8, 2024 at 3:28 PM Iñaki Ucar wrote:
>
> So someone wanted to use rpmautospec and was willing to do the work, putting
> things together as an opt-in feature. Perfect.
>
> Now, I don't see any problem if some time later someone revisits the topic
> and proposes to go further. I don't
-1 as well, for all the reasons already mentioned.
On Mon, Apr 8, 2024 at 8:28 AM Iñaki Ucar wrote:
> So someone wanted to use rpmautospec and was willing to do the work,
> putting things together as an opt-in feature. Perfect.
>
> Now, I don't see any problem if some time later someone
So someone wanted to use rpmautospec and was willing to do the work,
putting things together as an opt-in feature. Perfect.
Now, I don't see any problem if some time later someone revisits the topic
and proposes to go further. I don't see anything unfriendly here.
Everything was set or decided at
* Zbigniew Jędrzejewski-Szmek [08/04/2024 09:02] :
>
> Well, you and Kevin see "salami tactics" (whatever that may be),
FTR, I have no idea what "salami tactics" is.
> while I see normal engineering practice: some new idea is hatched,
> it's implemented and used narrowly, them it's applied by
On neděle 7. dubna 2024 17:15:16 CEST Zbigniew Jędrzejewski-Szmek wrote:
> Hi everyone,
>
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
>
> All my packages have been
On 08/04/2024 11.31, Richard W.M. Jones wrote:
On Mon, Apr 08, 2024 at 12:22:35AM +0200, Kevin Kofler via devel wrote:
Emmanuel Seyman wrote:
I've noticed a trend in proposed changes in the way Fedora works.
I am fed up of this salami tactic as well. When we complain about the new
stuff, we
On Mon, Apr 08, 2024 at 01:11:22PM +0200, Petr Pisar wrote:
> V Mon, Apr 08, 2024 at 10:49:42AM +, Zbigniew Jędrzejewski-Szmek
> napsal(a):
> > On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote:
> > > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL
> > >
On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar wrote:
>
> V Mon, Apr 08, 2024 at 10:49:42AM +, Zbigniew Jędrzejewski-Szmek
> napsal(a):
> > On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote:
> > > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL
> > > minor
> > >
V Mon, Apr 08, 2024 at 10:49:42AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote:
> > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL
> > minor
> > releases).
>
> Hmm, can you provide describe the workflow
On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote:
> V Sun, Apr 07, 2024 at 03:15:16PM +, Zbigniew Jędrzejewski-Szmek
> napsal(a):
> > I think it's time to switch to rpmautospec completely.
> > Thus, the proposal:
> > - new packages MUST use rpmautospec
> > - packagers SHOULD convert
V Sun, Apr 07, 2024 at 03:15:16PM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> I think it's time to switch to rpmautospec completely.
> Thus, the proposal:
> - new packages MUST use rpmautospec
> - packagers SHOULD convert their packages
> - provenpackagers MAY convert existing packages
>
On Mon, Apr 08, 2024 at 12:22:35AM +0200, Kevin Kofler via devel wrote:
> Emmanuel Seyman wrote:
> > I've noticed a trend in proposed changes in the way Fedora works.
>
> I am fed up of this salami tactic as well. When we complain about the new
> stuff, we invariably get told "don't worry, you
On Mon, Apr 08, 2024 at 09:08:19AM +0200, Miroslav Lichvar wrote:
> On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote:
> > -1 for existing packages certainly - none of my git commit logs
> > are written with the expectation that they will double as package
> > changelogs so
On Sun, Apr 07, 2024 at 09:08:49PM -0700, Carlos Rodriguez-Fernandez wrote:
> On 4/7/24 21:07, Carlos Rodriguez-Fernandez wrote:
> > Not all commits correspond with a new release downstream, and not all
> > commit messages are relevant to the end user to be part of the change
> > log. For example,
On Mon, Apr 08, 2024 at 12:38:47AM +0200, Kevin Kofler via devel wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > I'm revisting the topic of rpmautospec because I was doing some work
> > on various packages, and it's annoying that some packages are using
> > rpmautospec and others are not.
>
> The
Zbyszek
While I am in favor of autospec, I agree with the comment that it
doesn't work well outside of koji.
- builds in copr work.
The builds themselves work, but in my experience they do not increase
the `release`, nor do they handle `autochangelog`. Are there ways around
it if we want
On Sun, Apr 07, 2024 at 06:44:57PM +0200, Emmanuel Seyman wrote:
> * Zbigniew Jędrzejewski-Szmek [07/04/2024 15:56] :
> >
> > On Sun, Apr 07, 2024 at 05:47:57PM +0200, Emmanuel Seyman wrote:
> > >
> > > This doesn't solve the problem you have so that's a no-go as well.
> >
> > In what way
On Sun, Apr 07, 2024 at 12:58:04PM -0400, Neal Gompa wrote:
> No. I do not want to use rpmautospec as it currently exists. It does
> not help me. It does not achieve anything for me. It breaks my
> packages for building outside of Fedora Koji. It doesn't even make
> things better for supporting
On Sun, Apr 07, 2024 at 05:55:08PM +0100, Sérgio Basto wrote:
> I also still see some issues in %autorelease , why fix a typo is a new
> release ?
Either the fix is important and you rebuild and then you _must_ have a
new release, because koji requires a unique NEVRA. Or the fix can wait,
so you
> Hi everyone,
>
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
>
> All my packages have been converted, so in day-to-day work, I don't
> even think about %changelog.
On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote:
> -1 for existing packages certainly - none of my git commit logs
> are written with the expectation that they will double as package
> changelogs so doing so may break the changelog.
Yes, I think rpm changelog is for users of
On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote:
Not all commits correspond with a new release downstream, and not all commit
messages are relevant to the end user to be part of the change log. For
example, commits related with increasing gating test coverage efforts, or
setting up
Am 07.04.24 um 17:15 schrieb Zbigniew Jędrzejewski-Szmek:
Hi everyone,
I'm revisting the topic of rpmautospec because I was doing some work
on various packages, and it's annoying that some packages are using
rpmautospec and others are not.
All my packages have been converted, so in
Not all commits correspond with a new release downstream, and not all
commit messages are relevant to the end user to be part of the change
log. For example, commits related with increasing gating test coverage
efforts, or setting up gating.yaml itself. Another example is linting
setting
Zbigniew Jędrzejewski-Szmek wrote:
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
The fix for that inconsistency would be to ban rpmautospec. It just makes
everything
Emmanuel Seyman wrote:
> I've noticed a trend in proposed changes in the way Fedora works.
I am fed up of this salami tactic as well. When we complain about the new
stuff, we invariably get told "don't worry, you don't have to use it, it's
all optional", but the plan is always to make it
On Sun Apr 7, 2024 at 15:15 +, Zbigniew Jędrzejewski-Szmek wrote:
> I think it's time to switch to rpmautospec completely.
> Thus, the proposal:
> - new packages MUST use rpmautospec
> - packagers SHOULD convert their packages
> - provenpackagers MAY convert existing packages
> (e.g. when
On Sun, Apr 7, 2024 at 9:22 PM Leon Fauster via devel
wrote:
>
> Am 07.04.24 um 17:15 schrieb Zbigniew Jędrzejewski-Szmek:
> > Hi everyone,
> >
> > I'm revisting the topic of rpmautospec because I was doing some work
> > on various packages, and it's annoying that some packages are using
> >
Am 07.04.24 um 17:15 schrieb Zbigniew Jędrzejewski-Szmek:
Hi everyone,
I'm revisting the topic of rpmautospec because I was doing some work
on various packages, and it's annoying that some packages are using
rpmautospec and others are not.
All my packages have been converted, so in day-to-day
On Sun, Apr 7, 2024 at 5:48 PM Tom Hughes via devel
wrote:
>
> On 07/04/2024 16:15, Zbigniew Jędrzejewski-Szmek wrote:
>
> > I think it's time to switch to rpmautospec completely.
> > Thus, the proposal:
> > - new packages MUST use rpmautospec
> > - packagers SHOULD convert their packages
> > -
On Sun, Apr 7, 2024 at 11:16 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> Hi everyone,
>
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
>
> All my packages have been
On Sun, 2024-04-07 at 15:15 +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi everyone,
>
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
>
> All my packages have been
* Zbigniew Jędrzejewski-Szmek [07/04/2024 15:56] :
>
> On Sun, Apr 07, 2024 at 05:47:57PM +0200, Emmanuel Seyman wrote:
> >
> > This doesn't solve the problem you have so that's a no-go as well.
>
> In what way doesn't it solve the problem?
In your original post, you stated "When working with
On Sun, Apr 07, 2024 at 05:47:57PM +0200, Miro Hrončok wrote:
> On 07. 04. 24 17:15, Zbigniew Jędrzejewski-Szmek wrote:
> > Hi everyone,
> >
> > I'm revisting the topic of rpmautospec because I was doing some work
> > on various packages, and it's annoying that some packages are using
> >
On Sun, Apr 07, 2024 at 05:47:57PM +0200, Emmanuel Seyman wrote:
> * Zbigniew Jędrzejewski-Szmek [07/04/2024 15:35] :
> >
> > OK, so if there was an opt-out, [...]
>
> This doesn't solve the problem you have so that's a no-go as well.
In what way doesn't it solve the problem?
The problem was
On 07/04/2024 16:15, Zbigniew Jędrzejewski-Szmek wrote:
I think it's time to switch to rpmautospec completely.
Thus, the proposal:
- new packages MUST use rpmautospec
- packagers SHOULD convert their packages
- provenpackagers MAY convert existing packages
(e.g. when they want to push some
On 07. 04. 24 17:15, Zbigniew Jędrzejewski-Szmek wrote:
Hi everyone,
I'm revisting the topic of rpmautospec because I was doing some work
on various packages, and it's annoying that some packages are using
rpmautospec and others are not.
All my packages have been converted, so in day-to-day
* Zbigniew Jędrzejewski-Szmek [07/04/2024 15:35] :
>
> OK, so if there was an opt-out, [...]
This doesn't solve the problem you have so that's a no-go as well.
Emmanuel
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
On Sun, Apr 07, 2024 at 03:30:01PM +, Gary Buhrmaster wrote:
> On Sun, Apr 7, 2024 at 3:23 PM Miroslav Suchý wrote:
> >
> > Dne 07. 04. 24 v 5:15 odp. Zbigniew Jędrzejewski-Szmek napsal(a):
> >
> > I think it's time to switch to rpmautospec completely.
> >
> > -1 from me.
> >
> > While I
On Sun, Apr 7, 2024 at 3:23 PM Miroslav Suchý wrote:
>
> Dne 07. 04. 24 v 5:15 odp. Zbigniew Jędrzejewski-Szmek napsal(a):
>
> I think it's time to switch to rpmautospec completely.
>
> -1 from me.
>
> While I enjoy simplicity of rpmautospec in some of my packages.
>
> I have bunch of packages
Dne 07. 04. 24 v 5:15 odp. Zbigniew Jędrzejewski-Szmek napsal(a):
I think it's time to switch to rpmautospec completely.
-1 from me.
While I enjoy simplicity of rpmautospec in some of my packages.
I have bunch of packages where the spec is present also in upstream and the package is build
Hi everyone,
I'm revisting the topic of rpmautospec because I was doing some work
on various packages, and it's annoying that some packages are using
rpmautospec and others are not.
All my packages have been converted, so in day-to-day work, I don't
even think about %changelog. When working with
85 matches
Mail list logo
