Le vendredi 10 juillet 2020 à 14:59 +0200, Nicolas Mailhot a écrit :
> Le vendredi 10 juillet 2020 à 13:22 +0200, Pavel Raiskup a écrit :
> > On Wednesday, July 8, 2020 6:25:57 PM CEST Nicolas Mailhot via
> > devel
> > wrote:
> > > Le 2020-07-08 17:19, Pavel Raiskup a écrit :
> > >
> > > > Small
Le vendredi 10 juillet 2020 à 13:22 +0200, Pavel Raiskup a écrit :
> On Wednesday, July 8, 2020 6:25:57 PM CEST Nicolas Mailhot via devel
> wrote:
> > Le 2020-07-08 17:19, Pavel Raiskup a écrit :
> >
> > > Small experiment (few-liner) for copr with "%bid, build system
> > > tag":
> > >
On Wednesday, July 8, 2020 6:25:57 PM CEST Nicolas Mailhot via devel wrote:
> Le 2020-07-08 17:19, Pavel Raiskup a écrit :
>
> > Small experiment (few-liner) for copr with "%bid, build system tag":
> > https://pagure.io/copr/copr/pull-request/1436
>
> Well, that ties the system to corp, not koji
Le 2020-07-08 17:19, Pavel Raiskup a écrit :
Small experiment (few-liner) for copr with "%bid, build system tag":
https://pagure.io/copr/copr/pull-request/1436
Well, that ties the system to corp, not koji, and like the other
proposal, that makes releases that do not import from one system to
On Wednesday, July 8, 2020 4:16:34 PM CEST Pavel Raiskup wrote:
> On Monday, July 6, 2020 10:19:31 AM CEST Adam Saleh wrote:
> > Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
> > problem few months ago.
> > It is a koji plugin as well as CLI tool that makes bumping the
On Monday, July 6, 2020 10:19:31 AM CEST Adam Saleh wrote:
> Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
> problem few months ago.
> It is a koji plugin as well as CLI tool that makes bumping the release
> field and generating changelog problem of Koji,
> instead of
Adam Saleh wrote:
> Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
> problem few months ago.
> It is a koji plugin as well as CLI tool that makes bumping the release
> field and generating changelog problem of Koji,
> instead of package-maintainer. Currently it sits
On 7/6/20 8:27 AM, Björn Persson wrote:
> Florian Weimer wrote:
>> * Björn Persson:
>>
>>> The macro could be defined like this for example:
>>>
>>>%buildtag .%(date +%%s)
>>
>> Using time for synchronization is always a bit iffy.
>
> Well, if somebody manages to build a package twice within
Florian Weimer wrote:
> * Björn Persson:
>
> > The macro could be defined like this for example:
> >
> > %buildtag .%(date +%%s)
>
> Using time for synchronization is always a bit iffy.
Well, if somebody manages to build a package twice within a second,
using two different versions of a
Le lundi 06 juillet 2020 à 13:06 +0200, Nicolas Mailhot a écrit :
>
> Because the build state exists in koji only, there is no need to
> commit back to git.
BTW I’m fairly certain I could have managed to implement the thing
without adding source files to the SRPM, removing the need for mock
Le lundi 06 juillet 2020 à 10:19 +0200, Adam Saleh a écrit :
> Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve
> this problem few months ago.
> It is a koji plugin as well as CLI tool that makes bumping the
> release field and generating changelog problem of Koji,
> instead of
Le dimanche 05 juillet 2020 à 23:36 +0200, Dan Čermák a écrit :
> Nicolas Mailhot via devel writes:
>
> > Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit :
> > > Nicolas Mailhot via devel wrote:
> > > > So if you want to push Fedora release logic to its ultimate
> > > >
Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
problem few months ago.
It is a koji plugin as well as CLI tool that makes bumping the release
field and generating changelog problem of Koji,
instead of package-maintainer. Currently it sits deployed in staging koji,
so you
* Björn Persson:
> The macro could be defined like this for example:
>
> %buildtag .%(date +%%s)
Using time for synchronization is always a bit iffy.
> It would be used in each spec like this:
>
> Release: 1%{?dist}%{?buildtag}
We could put the Koji task ID directly into the %dist tag. We
Nicolas Mailhot via devel wrote:
> Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit :
> > It seems that several problems would just disappear if a rebuild
> > would generate a unique package ID without a Git commit.
>
> That’s exacly what the change does.
No it's not. Your
Nicolas Mailhot via devel writes:
> Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit :
>> Nicolas Mailhot via devel wrote:
>> > So if you want to push Fedora release logic to its ultimate
>> > conclusion,
>> > the thing that should be in charge of committing the new
>> >
Le dimanche 05 juillet 2020 à 18:41 +0200, Nicolas Mailhot a écrit :
>
> While timestamping would remove the need to pass the last build info
> to the next one it would also break all the workflows where several
> rebuilds are done in parallel for separate needs, and the latest
> rebuild is not
Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit :
> Nicolas Mailhot via devel wrote:
> > So if you want to push Fedora release logic to its ultimate
> > conclusion,
> > the thing that should be in charge of committing the new
> > release/changelog build state to package history in
Nicolas Mailhot via devel wrote:
> So if you want to push Fedora release logic to its ultimate conclusion,
> the thing that should be in charge of committing the new
> release/changelog build state to package history in git is bodhi, not
> koji.
Why do build events need to be recorded in the Git
19 matches
Mail list logo
