Le 2020-03-03 15:14, clime a écrit :
On Tue, 3 Mar 2020 at 09:22, Nicolas Mailhot
wrote:
Le 2020-03-02 14:45, clime a écrit :
> On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
> wrote:
>>
>> Le 2020-03-01 02:31, clime a écrit :
>> > On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via
On Tue, 3 Mar 2020 at 09:38, Nicolas Mailhot
wrote:
>
> Le 2020-03-03 07:03, clime a écrit :
>
> > Actually, that wouldn't work because prefix needs to be static, not
> > dependent on rpm macros
>
> For myself, I would oppose any rpm release process that would not take
> core rpm mecanisms like
On Tue, 3 Mar 2020 at 09:22, Nicolas Mailhot
wrote:
>
> Le 2020-03-02 14:45, clime a écrit :
> > On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
> > wrote:
> >>
> >> Le 2020-03-01 02:31, clime a écrit :
> >> > On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel
> >> > wrote:
> >> >>
Le 2020-03-03 07:03, clime a écrit :
Actually, that wouldn't work because prefix needs to be static, not
dependent on rpm macros
For myself, I would oppose any rpm release process that would not take
core rpm mecanisms like macros into account.
Recording builds in changelogs without
Le 2020-03-02 14:45, clime a écrit :
On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
wrote:
Le 2020-03-01 02:31, clime a écrit :
> On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel
> wrote:
>>
>> Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :
>> Putting %{dynrel}
On Tue, 3 Mar 2020 at 00:28, clime wrote:
>
> Ad. Zbyszek:
>
> > What about doing --.?
> > This means that upgrade path not affected by the number of commits or
> > builds in the older release.
>
> I was thinking how to properly implement this into rpkg-util and then
> finally, it clicked for me.
Ad. Zbyszek:
> What about doing --.?
> This means that upgrade path not affected by the number of commits or
> builds in the older release.
I was thinking how to properly implement this into rpkg-util and then
finally, it clicked for me.
First, I added the prefix parameter for git_release macro
On Mon, Mar 2, 2020 at 8:46 AM clime wrote:
>
> On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
> wrote:
> >
> > If you don’t keep things decentralized you’ll be in a word of pain when
> > the scm or buildsys needs to be changed for another implementation (not
> > to mention, that’s not a
On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
wrote:
>
> Le 2020-03-01 02:31, clime a écrit :
> > On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel
> > wrote:
> >>
> >> Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :
>
> >> Putting %{dynrel} reconciliation in the rpmbuild
On Mon, 2 Mar 2020 at 11:44, Nils Philippsen wrote:
>
> On Fri, 2020-02-28 at 15:45 +0100, clime wrote:
> > I thought the main reason not to combine update in the changelog file
> > with
> > code commits is to avoid conflicts when cherry picking as you
> > described.
> >
> > I.e. i do minor
Le 2020-03-01 02:31, clime a écrit :
On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel
wrote:
Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :
Putting %{dynrel} reconciliation in the rpmbuild -bs stage using
detached file state means that fedpkg local (or checking out git
On Fri, 2020-02-28 at 15:45 +0100, clime wrote:
> I thought the main reason not to combine update in the changelog file
> with
> code commits is to avoid conflicts when cherry picking as you
> described.
>
> I.e. i do minor update specifically in f32 and generate changelog
> file
> in the same
On Sat, Feb 29, 2020 at 10:40:51PM +0100, Nicolas Mailhot via devel wrote:
> Le samedi 29 février 2020 à 20:57 +0100, clime a écrit :
> > If I, as a user, see e.g. python3-alembic-1.1.0-13 in f31 and then I
> > will see python3-alembic-1.1.0-13 in f32 (this time with .fc32
> > disttag), I am going
On Sat, 29 Feb 2020 at 22:42, Nicolas Mailhot via devel
wrote:
>
> Le samedi 29 février 2020 à 20:57 +0100, clime a écrit :
> > On Sat, 29 Feb 2020 at 16:24, Nicolas Mailhot via devel
> > wrote:
> > > Le samedi 29 février 2020 à 15:12 +0100, clime a écrit :
> > > > On Sat, 29 Feb 2020 at 14:47,
On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel
wrote:
>
> Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :
> >
> > What about fedpkg local and fedpkg verrel then?
>
> Putting %{dynrel} reconciliation in the rpmbuild -bs stage using
> detached file state means that fedpkg local
Le samedi 29 février 2020 à 20:57 +0100, clime a écrit :
> On Sat, 29 Feb 2020 at 16:24, Nicolas Mailhot via devel
> wrote:
> > Le samedi 29 février 2020 à 15:12 +0100, clime a écrit :
> > > On Sat, 29 Feb 2020 at 14:47, Nicolas Mailhot via devel
> > > wrote:
> > > > Le samedi 29 février 2020 à
Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :
>
> What about fedpkg local and fedpkg verrel then?
Putting %{dynrel} reconciliation in the rpmbuild -bs stage using
detached file state means that fedpkg local (or checking out git state
and building in mock or copr or OBS or via plain
On Sat, 29 Feb 2020 at 16:24, Nicolas Mailhot via devel
wrote:
>
> Le samedi 29 février 2020 à 15:12 +0100, clime a écrit :
> > On Sat, 29 Feb 2020 at 14:47, Nicolas Mailhot via devel
> > wrote:
> > > Le samedi 29 février 2020 à 14:28 +0100, clime a écrit :
> > > > Does ENVR without %{dist}
On Sat, 29 Feb 2020 at 16:12, Nicolas Mailhot via devel
wrote:
>
> Le samedi 29 février 2020 à 13:49 +0100, clime a écrit :
> > On Sat, 29 Feb 2020 at 10:15, Nicolas Mailhot via devel
> > wrote:
> > > Hi,
> > >
> > > Anyway, here is what I would personnaly consider a robust,
> > > inclusive,
> >
On 2/27/20 12:08 AM, Dan Čermák wrote:
For the changelog: yes please, generate it from the commit log! They are
more or less the same for all my packages and I'm getting tired of copy
pasting the same text into %changelog and git commit.
Do you know about fedpkg commit --clog ?
--
Orion
Le samedi 29 février 2020 à 16:11 +0100, Nicolas Mailhot a écrit :
>
> Build-time state changes need to be commited back, of course
> (otherwise the produced srpm needs to be re-imported manually)
Probably, only on *successful* production build however. We don’t need
to record failed or scratch
Le samedi 29 février 2020 à 15:12 +0100, clime a écrit :
> On Sat, 29 Feb 2020 at 14:47, Nicolas Mailhot via devel
> wrote:
> > Le samedi 29 février 2020 à 14:28 +0100, clime a écrit :
> > > Does ENVR without %{dist} means something with respect to the
> > > content
> > > from
> > > which the
Le samedi 29 février 2020 à 13:49 +0100, clime a écrit :
> On Sat, 29 Feb 2020 at 10:15, Nicolas Mailhot via devel
> wrote:
> > Hi,
> >
> > Anyway, here is what I would personnaly consider a robust,
> > inclusive,
> > and future-proof design:
>
> I will need to ask some questions to really
On Sat, 29 Feb 2020 at 14:47, Nicolas Mailhot via devel
wrote:
>
> Le samedi 29 février 2020 à 14:28 +0100, clime a écrit :
> >
> > Does ENVR without %{dist} means something with respect to the content
> > from
> > which the package was built or with respect to features that it
> > offers for the
Le samedi 29 février 2020 à 14:28 +0100, clime a écrit :
>
> Does ENVR without %{dist} means something with respect to the content
> from
> which the package was built or with respect to features that it
> offers for the given distribution version?
You need to evaluate evr with a neutral dist
On Thu, 27 Feb 2020 at 18:07, Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Tue, Feb 25, 2020 at 05:42:11PM +0100, Miro Hrončok wrote:
> > On 25. 02. 20 9:50, Pierre-Yves Chibon wrote:
> > >Upgrade path may be problematic if you update Fn to a version in less
> > >commit
> > >than the update for
On Sat, 29 Feb 2020 at 10:15, Nicolas Mailhot via devel
wrote:
>
> Hi,
>
> Anyway, here is what I would personnaly consider a robust, inclusive,
> and future-proof design:
I will need to ask some questions to really understand it.
>
> — a %{use_dynstate} rpm variable enables dynamic
Hi,
Anyway, here is what I would personnaly consider a robust, inclusive,
and future-proof design:
— a %{use_dynstate} rpm variable enables dynamic changelog/release
behaviour
— probably initialy set to false distro-wide, to let volunteers test
the thing by setting it to true iin their specs,
On Fri, 28 Feb 2020 at 15:07, Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Fri, Feb 28, 2020 at 12:31:23PM +0100, Vít Ondruch wrote:
> >
> > Dne 27. 02. 20 v 16:11 Zbigniew Jędrzejewski-Szmek napsal(a):
> > > Hi,
> > >
> > > On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> > >>
Dne 28. 02. 20 v 15:06 Zbigniew Jędrzejewski-Szmek napsal(a):
> On Fri, Feb 28, 2020 at 12:31:23PM +0100, Vít Ondruch wrote:
>> Dne 27. 02. 20 v 16:11 Zbigniew Jędrzejewski-Szmek napsal(a):
>>> Hi,
>>>
>>> On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
For the changelog,
On Fri, Feb 28, 2020 at 12:31:23PM +0100, Vít Ondruch wrote:
>
> Dne 27. 02. 20 v 16:11 Zbigniew Jędrzejewski-Szmek napsal(a):
> > Hi,
> >
> > On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> >> For the changelog, we believe we have a potential good solution:
> >> - The
Dne 27. 02. 20 v 16:11 Zbigniew Jędrzejewski-Szmek napsal(a):
> Hi,
>
> On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
>> For the changelog, we believe we have a potential good solution:
>> - The changelog will be automatically generated using an external `changelog`
>>
On Thu, 27 Feb 2020 at 16:13, Zbigniew Jędrzejewski-Szmek
wrote:
>
> Hi,
>
> On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> > For the changelog, we believe we have a potential good solution:
> > - The changelog will be automatically generated using an external
> >
Le jeudi 27 février 2020 à 17:38 +0100, clime a écrit :
> On Thu, 27 Feb 2020 at 16:26, Nicolas Mailhot via devel
> wrote:
> > Le 2020-02-27 12:59, clime a écrit :
> > Hi,
> >
> > > can you, please, show an example of such package? I was searching
> > > through some
> > > golang packages because
On Thu, 27 Feb 2020 at 17:29, Nils Philippsen wrote:
>
> On Thu, 2020-02-27 at 15:10 +0100, clime wrote:
> > Another thing to consider is whether we want a transparent build
> > system where all the description of what will happen when a spec file
> > is sent to it is included in the specfile
On Tue, Feb 25, 2020 at 05:42:11PM +0100, Miro Hrončok wrote:
> On 25. 02. 20 9:50, Pierre-Yves Chibon wrote:
> >Upgrade path may be problematic if you update Fn to a version in less commit
> >than the update for Fn-1 (ie: you update F32 to 1.0 in 1 commit and update
> >F31
> >to 1.0 in 2
On Thu, 27 Feb 2020 at 16:26, Nicolas Mailhot via devel
wrote:
>
> Le 2020-02-27 12:59, clime a écrit :
> Hi,
>
> >
> > can you, please, show an example of such package? I was searching
> > through some
> > golang packages because I was curious how it works but couldn't find
> > an example
>
> A
On Wed, 2020-02-26 at 23:07 -0500, Neal Gompa wrote:
> On Wed, Feb 26, 2020 at 8:05 PM Robert-André Mauchin <
> zebo...@gmail.com> wrote:
> > On Monday, 24 February 2020 17:48:36 CET Pierre-Yves Chibon wrote:
> > > However, for the release field, we are struggling a little bit
> > > more, two
> >
On Thu, 2020-02-27 at 15:10 +0100, clime wrote:
> Another thing to consider is whether we want a transparent build
> system where all the description of what will happen when a spec file
> is sent to it is included in the specfile itself or whether we want
But we don't have that today: think of
Le 2020-02-27 12:59, clime a écrit :
Hi,
can you, please, show an example of such package? I was searching
through some
golang packages because I was curious how it works but couldn't find
an example
A Go example:
https://src.fedoraproject.org/rpms/golang-x-build
A non-Go example:
Hi,
On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> For the changelog, we believe we have a potential good solution:
> - The changelog will be automatically generated using an external `changelog`
> file as well as the commit history
...
> If you wanted to edit the
On Thu, 27 Feb 2020 at 13:23, clime wrote:
>
> On Thu, 27 Feb 2020 at 12:42, David Kaufmann wrote:
> >
> > On Thu, Feb 27, 2020 at 12:21:48PM +0100, clime wrote:
> > > On Thu, 27 Feb 2020 at 10:00, David Kaufmann wrote:
> > >> Another idea would be generating a changelog-entry from git history
On Thu, 27 Feb 2020 at 12:42, David Kaufmann wrote:
>
> On Thu, Feb 27, 2020 at 12:21:48PM +0100, clime wrote:
> > On Thu, 27 Feb 2020 at 10:00, David Kaufmann wrote:
> >> Another idea would be generating a changelog-entry from git history when
> >> creating an update in bodhi, and there is no
On Thu, 27 Feb 2020 at 10:47, Nicolas Mailhot via devel
wrote:
>
> Le 2020-02-27 09:52, Miro Hrončok a écrit :
> > On 27. 02. 20 9:20, Pierre-Yves Chibon wrote:
> >>> How would that work with "complex" releases? For example release
> >>> containing
> >>> prerelease info like 0.1.beta.2 or
On Thu, Feb 27, 2020 at 12:21:48PM +0100, clime wrote:
> On Thu, 27 Feb 2020 at 10:00, David Kaufmann wrote:
>> Another idea would be generating a changelog-entry from git history when
>> creating an update in bodhi, and there is no pre-existing
>> changelog-entry for the current version.
>
>
On Thu, 27 Feb 2020 at 10:00, David Kaufmann wrote:
>
> On Thu, Feb 27, 2020 at 08:08:49AM +0100, Dan Čermák wrote:
> > For the changelog: yes please, generate it from the commit log! They are
> > more or less the same for all my packages and I'm getting tired of copy
> > pasting the same text
On 27. 02. 20 11:57, clime wrote:
If i understand correctly, this would rely on the locally undefined
%{baserelease} macro, which is later provided auto-magically by the
build system. Should this macro be populated also locally if not
defined?
Yes, by fedpkg. Now should the specs be buildable
On Thu, 27 Feb 2020 at 09:53, Miro Hrončok wrote:
>
> On 27. 02. 20 9:20, Pierre-Yves Chibon wrote:
> >> How would that work with "complex" releases? For example release containing
> >> prerelease info like 0.1.beta.2 or 0.1.20120225gitd6c789a? Many Go package
> >> have no version, so depend
Le 2020-02-27 09:52, Miro Hrončok a écrit :
On 27. 02. 20 9:20, Pierre-Yves Chibon wrote:
How would that work with "complex" releases? For example release
containing
prerelease info like 0.1.beta.2 or 0.1.20120225gitd6c789a? Many Go
package
have no version, so depend heavily on the Release tag
Le 2020-02-27 08:35, Nicolas Mailhot via devel a écrit :
Le mercredi 26 février 2020 à 23:07 -0500, Neal Gompa a écrit :
You don't use Release for upstream versioning, even for snapshots.
For
your examples:
* 0-0.1.beta.2 -> 0~beta.2-1
* 0-0.1.20120225gitd6c789a -> 0~git20120225.d6c789a-
On Thu, Feb 27, 2020 at 08:08:49AM +0100, Dan Čermák wrote:
> For the changelog: yes please, generate it from the commit log! They are
> more or less the same for all my packages and I'm getting tired of copy
> pasting the same text into %changelog and git commit.
Another idea would be generating
On 27. 02. 20 9:20, Pierre-Yves Chibon wrote:
How would that work with "complex" releases? For example release containing
prerelease info like 0.1.beta.2 or 0.1.20120225gitd6c789a? Many Go package
have no version, so depend heavily on the Release tag to signal what is the
snapshot date and git
On Thu, Feb 27, 2020 at 02:04:41AM +0100, Robert-André Mauchin wrote:
> On Monday, 24 February 2020 17:48:36 CET Pierre-Yves Chibon wrote:
> > However, for the release field, we are struggling a little bit more, two
> > options are more appealing to us:
> >
> > A) The release field is
Le mercredi 26 février 2020 à 23:07 -0500, Neal Gompa a écrit :
>
> You don't use Release for upstream versioning, even for snapshots.
> For
> your examples:
>
> * 0-0.1.beta.2 -> 0~beta.2-1
> * 0-0.1.20120225gitd6c789a -> 0~git20120225.d6c789a-
Sorry but no
You are attempting to redefine the
Hi list,
Stephen John Smoogen writes:
> On Mon, 24 Feb 2020 at 11:50, Pierre-Yves Chibon
> wrote:
>
>> Good Morning Everyone,
>>
>> This topic has already been discussed a few times over the past month, but
>> Adam
>> Saleh, Nils Philippsen and myself have had the opportunity to invest some
>>
On Wed, Feb 26, 2020 at 8:05 PM Robert-André Mauchin wrote:
>
> On Monday, 24 February 2020 17:48:36 CET Pierre-Yves Chibon wrote:
> > However, for the release field, we are struggling a little bit more, two
> > options are more appealing to us:
> >
> > A) The release field is automatically
On Monday, 24 February 2020 17:48:36 CET Pierre-Yves Chibon wrote:
> However, for the release field, we are struggling a little bit more, two
> options are more appealing to us:
>
> A) The release field is automatically generated using two elements:
> - the number of commits at this version
>
On Mon, Feb 24, 2020 at 06:13:21PM +0100, Miro Hrončok wrote:
> On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
> >However, for the release field, we are struggling a little bit more, two
> >options
> >are more appealing to us:
>
> Can we please have a "git is the only source of truth" version of
On Wed, 2020-02-26 at 11:29 +0100, Nicolas Mailhot via devel wrote:
> Le 2020-02-26 11:14, Nils Philippsen a écrit :
>
> > Well, if we officially were to break with the upgrade path
> > constraints,
> > we'd have to document this. While we're at it, we should then
> > document
> > that Rawhide
On Mon, 24 Feb 2020 at 11:50, Pierre-Yves Chibon
wrote:
> Good Morning Everyone,
>
> This topic has already been discussed a few times over the past month, but
> Adam
> Saleh, Nils Philippsen and myself have had the opportunity to invest some
> time
> on it with the hope of making the packager's
Dne 26. 02. 20 v 12:16 clime napsal(a):
> Few more notes:
> - having just: Release: means every commit bumps
> release and hence every commit should likely generate a new record
> into changelog => changelog basically becomes dumped `git log` (in
> rpm-compatible format) - i.e. there is no
Dne 25. 02. 20 v 15:03 Pierre-Yves Chibon napsal(a):
> On Tue, Feb 25, 2020 at 12:59:39PM +0100, Vít Ondruch wrote:
>
> [About the release field]
>
>> I am not really sure about this. How do you envision this is going to be
>> implemented? Is there going to be "release" file, similarly to
>>
Few more notes:
- having just: Release: means every commit bumps
release and hence every commit should likely generate a new record
into changelog => changelog basically becomes dumped `git log` (in
rpm-compatible format) - i.e. there is no capability to group multiple
changes into one changelog
Le 2020-02-26 11:14, Nils Philippsen a écrit :
Well, if we officially were to break with the upgrade path constraints,
we'd have to document this. While we're at it, we should then document
that Rawhide users should use "dnf distro-sync".
That won’t work because (for example) rawhide is
On Mon, 2020-02-24 at 18:13 +0100, Miro Hrončok wrote:
> On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
> > However, for the release field, we are struggling a little bit
> > more, two options
> > are more appealing to us:
>
> Can we please have a "git is the only source of truth" version of
>
On Tue, 2020-02-25 at 17:45 +0100, Miro Hrončok wrote:
> On 25. 02. 20 15:27, Fabio Valentini wrote:
> > Side note: I've been meaning to propose dropping Epoch because of
> > this
> > "we don't care about upgrade path anymore", but I've not gotten
> > around
> > to do that yet
We still need Epoch
On Tue, Feb 25, 2020, at 2:53 PM, Matthew Miller wrote:
> On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> > So these are the results of our current investigations, we are very much
> > eager
> > to get your feedback on them and even more eager if you have ideas on how to
>
On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> So these are the results of our current investigations, we are very much eager
> to get your feedback on them and even more eager if you have ideas on how to
> approach/solve some of the challenges mentioned here.
This all
On 25. 02. 20 15:27, Fabio Valentini wrote:
Side note: I've been meaning to propose dropping Epoch because of this
"we don't care about upgrade path anymore", but I've not gotten around
to do that yet
Unfortunately, that breaks rawhide users.
--
Miro Hrončok
--
Phone: +420777974800
IRC:
On 25. 02. 20 9:50, Pierre-Yves Chibon wrote:
Upgrade path may be problematic if you update Fn to a version in less commit
than the update for Fn-1 (ie: you update F32 to 1.0 in 1 commit and update F31
to 1.0 in 2 commits, suddenly you have F32 with 1.0-1 and F31 with 1.0-2).
I don't consider
On Tue, Feb 25, 2020 at 3:12 PM Pierre-Yves Chibon wrote:
>
> On Tue, Feb 25, 2020 at 02:55:37PM +0100, Fabio Valentini wrote:
> > On Tue, Feb 25, 2020 at 2:47 PM Remi Collet
> > wrote:
> > >
> > > Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
> > >
> > > > - You can easily opt-in by
On Tue, Feb 25, 2020 at 02:55:37PM +0100, Fabio Valentini wrote:
> On Tue, Feb 25, 2020 at 2:47 PM Remi Collet wrote:
> >
> > Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
> >
> > > - You can easily opt-in by using the macros
> >
> > Please keep opt-in as a mandatory need for such a
On Tue, Feb 25, 2020 at 12:59:39PM +0100, Vít Ondruch wrote:
>
> Dne 24. 02. 20 v 17:48 Pierre-Yves Chibon napsal(a):
> > Good Morning Everyone,
> >
> > This topic has already been discussed a few times over the past month, but
> > Adam
> > Saleh, Nils Philippsen and myself have had the
On Tue, Feb 25, 2020 at 2:47 PM Remi Collet wrote:
>
> Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
>
> > - You can easily opt-in by using the macros
>
> Please keep opt-in as a mandatory need for such a change.
>
>
> To be clear, I will be (perhaps the only) one to not use it.
>
>
> For
Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
> - You can easily opt-in by using the macros
Please keep opt-in as a mandatory need for such a change.
To be clear, I will be (perhaps the only) one to not use it.
For now spec file are self-contained, which is nice.
I don't like the
Dne 25. 02. 20 v 9:55 Pierre-Yves Chibon napsal(a):
> On Mon, Feb 24, 2020 at 10:05:31PM +0100, Miroslav Suchý wrote:
>> Dne 24. 02. 20 v 18:13 Miro Hrončok napsal(a):
>>> Can we please have a "git is the only source of truth" version of this?
>>> I.e. "Compute the release field from the number
Dne 24. 02. 20 v 17:48 Pierre-Yves Chibon napsal(a):
> Good Morning Everyone,
>
> This topic has already been discussed a few times over the past month, but
> Adam
> Saleh, Nils Philippsen and myself have had the opportunity to invest some time
> on it with the hope of making the packager's life
On Tue, 25 Feb 2020 at 12:47, clime wrote:
>
> Hey pingou!
>
> On Tue, 25 Feb 2020 at 10:26, Pierre-Yves Chibon wrote:
> >
> > On Tue, Feb 25, 2020 at 12:18:24AM +0100, clime wrote:
> > > Hello!
> > >
> > > What is the point of including number of builds into release? I think
> > > the Miro's
Hey pingou!
On Tue, 25 Feb 2020 at 10:26, Pierre-Yves Chibon wrote:
>
> On Tue, Feb 25, 2020 at 12:18:24AM +0100, clime wrote:
> > Hello!
> >
> > What is the point of including number of builds into release? I think
> > the Miro's approach solves it.
> > Or is there any other problem except
Le 2020-02-25 10:24, Pierre-Yves Chibon a écrit :
If you make the build system provide the ${dirty_appendix} and drop the
${pivot}
(because we want to generate the release, so there is no input
specified), you
get very close to what we described.
BTW, regardless of how things up, we have
On Tue, Feb 25, 2020 at 12:18:24AM +0100, clime wrote:
> Hello!
>
> What is the point of including number of builds into release? I think
> the Miro's approach solves it.
> Or is there any other problem except soname bumps?
It makes it easier to do rebuilds which means it makes it easier and
On Tue, Feb 25, 2020 at 09:06:35AM +0100, Petr Pisar wrote:
> On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> > - commits containing "magic keyword" (#changelog_exclude,
> > #changelog_include?) will be ignored or included as the case may be
>
> Could we please use
On Mon, Feb 24, 2020 at 10:05:31PM +0100, Miroslav Suchý wrote:
> Dne 24. 02. 20 v 18:13 Miro Hrončok napsal(a):
> > Can we please have a "git is the only source of truth" version of this?
> > I.e. "Compute the release field from the number
> > of commits since the last version change" in the
On Mon, Feb 24, 2020 at 07:30:15PM +0100, Nicolas Mailhot via devel wrote:
> Le lundi 24 février 2020 à 18:13 +0100, Miro Hrončok a écrit :
> > On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
> > > However, for the release field, we are struggling a little bit
> > > more, two options
> > > are more
On Mon, Feb 24, 2020 at 06:13:21PM +0100, Miro Hrončok wrote:
> On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
> > However, for the release field, we are struggling a little bit more, two
> > options
> > are more appealing to us:
>
> Can we please have a "git is the only source of truth" version
On Tue, 25 Feb 2020 at 09:31, clime wrote:
>
> Hello Adam!
>
> On Tue, 25 Feb 2020 at 08:58, Adam Saleh wrote:
> >
> > Nice, I have been trying to fight through the 'git context already missing'
> > with pure lua rpm macros,
> > and so far was hitting walls left and right :-)
> >
> > Will look
Hello Adam!
On Tue, 25 Feb 2020 at 08:58, Adam Saleh wrote:
>
> Nice, I have been trying to fight through the 'git context already missing'
> with pure lua rpm macros,
> and so far was hitting walls left and right :-)
>
> Will look at https://pagure.io/rpkg-util, might have more questions :-)
On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> - commits containing "magic keyword" (#changelog_exclude,
> #changelog_include?) will be ignored or included as the case may be
Could we please use the usual git commit keyword syntax? I.e. the e-mail
header format
Nice, I have been trying to fight through the 'git context already missing'
with pure lua rpm macros,
and so far was hitting walls left and right :-)
Will look at https://pagure.io/rpkg-util, might have more questions :-)
Adam
On Tue, Feb 25, 2020 at 12:20 AM clime wrote:
> Hello!
>
> On Mon,
Hello!
On Mon, 24 Feb 2020 at 17:50, Pierre-Yves Chibon wrote:
>
> Good Morning Everyone,
>
> This topic has already been discussed a few times over the past month, but
> Adam
> Saleh, Nils Philippsen and myself have had the opportunity to invest some time
> on it with the hope of making the
Dne 24. 02. 20 v 18:13 Miro Hrončok napsal(a):
> Can we please have a "git is the only source of truth" version of this? I.e.
> "Compute the release field from the number
> of commits since the last version change" in the document. It seem to only
> have one con (breaks if two builds are
>
On 24. 02. 20 19:30, Nicolas Mailhot via devel wrote:
Le lundi 24 février 2020 à 18:13 +0100, Miro Hrončok a écrit :
On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
However, for the release field, we are struggling a little bit
more, two options
are more appealing to us:
Can we please have a
Le lundi 24 février 2020 à 18:13 +0100, Miro Hrončok a écrit :
> On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
> > However, for the release field, we are struggling a little bit
> > more, two options
> > are more appealing to us:
>
> Can we please have a "git is the only source of truth" version
On Mon, Feb 24, 2020, 18:38 Miro Hrončok wrote:
> On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
> > However, for the release field, we are struggling a little bit more, two
> options
> > are more appealing to us:
>
> Can we please have a "git is the only source of truth" version of this?
> I.e.
On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
However, for the release field, we are struggling a little bit more, two options
are more appealing to us:
Can we please have a "git is the only source of truth" version of this? I.e.
"Compute the release field from the number of commits since
Good Morning Everyone,
This topic has already been discussed a few times over the past month, but Adam
Saleh, Nils Philippsen and myself have had the opportunity to invest some time
on it with the hope of making the packager's life simpler as well as making it
easier to build automation around
96 matches
Mail list logo
