On 24. 06. 22 9:30, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 23 June 2022 at 15:01, Miro Hrončok wrote:
On 23. 06. 22 14:24, Aleksandra Fedorova wrote:
2) A packager rebuilds packages from Fedora dist-git in a Copr repo, what will
be the value of the build tag? How will the Copr
On Thursday, 23 June 2022 at 15:01, Miro Hrončok wrote:
> On 23. 06. 22 14:24, Aleksandra Fedorova wrote:
> > > 2) A packager rebuilds packages from Fedora dist-git in a Copr repo, what
> > > will
> > > be the value of the build tag? How will the Copr build sort over the
> > > official
> > >
On 23. 06. 22 14:24, Aleksandra Fedorova wrote:
3) If every Fedora packager can rebuild anything without a commit, what do we
do prevent accidental builds?
I think each rebuild should be treated as a new package, thus it would
require a new bodhi update, testing, and signing. Which means it
Dne 23. 06. 22 v 14:24 Aleksandra Fedorova napsal(a):
1) An user rebuilds a package from Fedora dist-git in local mock, what will be
the value of the build tag? How will the local build sort over the official
Fedora builds?
Afaik currently, if you do a local build, you need to bump an NVR to
On 23. 06. 22 14:24, Aleksandra Fedorova wrote:
2) A packager rebuilds packages from Fedora dist-git in a Copr repo, what will
be the value of the build tag? How will the Copr build sort over the official
Fedora builds? (This is essentially the same question but the answer might
differ.)
On Thu, Jun 23, 2022 at 8:25 AM Aleksandra Fedorova wrote:
>
> Hi, Miro,
>
> On Thu, Jun 23, 2022 at 12:15 PM Miro Hrončok wrote:
> >
> > On 18. 06. 22 13:05, Aleksandra Fedorova wrote:
> > > Hi, all,
> > >
> > > I'd like to discuss how we can add Build tag in the RPM.
> > >
> > > As one of the
Hi, Miro,
On Thu, Jun 23, 2022 at 12:15 PM Miro Hrončok wrote:
>
> On 18. 06. 22 13:05, Aleksandra Fedorova wrote:
> > Hi, all,
> >
> > I'd like to discuss how we can add Build tag in the RPM.
> >
> > As one of the key points is to turn it into a common standard for rpm
> > packages across the
On 18. 06. 22 13:05, Aleksandra Fedorova wrote:
Hi, all,
I'd like to discuss how we can add Build tag in the RPM.
As one of the key points is to turn it into a common standard for rpm
packages across the ecosystem, the conversation is currently opened
upstream [1] and in RHEL Engineering. And
On Thu, Jun 23, 2022 at 09:28:47AM +0200, Kamil Dudka wrote:
> On Wednesday, June 22, 2022 7:45:09 PM CEST Kevin Fenzi wrote:
> > On Wed, Jun 22, 2022 at 11:09:13AM -, Michael J Gruber wrote:
> > > > I also think that every package change (including rebuild) must be
> > > > tracked in
On Wednesday, June 22, 2022 7:45:09 PM CEST Kevin Fenzi wrote:
> On Wed, Jun 22, 2022 at 11:09:13AM -, Michael J Gruber wrote:
> > > I also think that every package change (including rebuild) must be
> > > tracked in changelog.
> >
> > I think that convolution is at the very heart of the
On Wed, Jun 22, 2022 at 11:09:13AM -, Michael J Gruber wrote:
> >
> > I also think that every package change (including rebuild) must be
> > tracked in changelog.
>
> I think that convolution is at the very heart of the problem:
>
> As it is, dist-git tracks "packaging sources", i.e. spec
On Wed, Jun 22, 2022 at 01:10:57PM +0200, Petr Pisar wrote:
> I have probably shocking news for you: Pull requests do not live in a parallel
This seems like it's getting a little heated and going towards
personally-directed rhetoric. Can we please not do that? Thank you.
--
Matthew Miller
V Wed, Jun 22, 2022 at 12:23:21PM +0200, Fabio Valentini napsal(a):
> On Wed, Jun 22, 2022 at 11:08 AM Hunor Csomortáni wrote:
> >
> > On Mon, Jun 20, 2022 at 1:46 PM Vitaly Zaitsev via devel
> > wrote:
> > >
> > > On 20/06/2022 10:47, Petr Pisar wrote:
> > > > I think Aleksandra wants to
>
> I also think that every package change (including rebuild) must be
> tracked in changelog.
I think that convolution is at the very heart of the problem:
As it is, dist-git tracks "packaging sources", i.e. spec and source hashes or
files, and this determines the content of the src.rpm and
On 22/06/2022 11:07, Hunor Csomortáni wrote:
I actually think it's a good idea.
Scratch builds always sounded like a strange idea, mainly b/c it's
forcing us to decide if the output of a build is going to be released
*before* the build is triggered, when it's impossible to tell whether
that
On Wed, Jun 22, 2022 at 11:08 AM Hunor Csomortáni wrote:
>
> On Mon, Jun 20, 2022 at 1:46 PM Vitaly Zaitsev via devel
> wrote:
> >
> > On 20/06/2022 10:47, Petr Pisar wrote:
> > > I think Aleksandra wants to (non-scratch) build all pull requestes before
> > > merging.
> >
> > Official
On Mon, Jun 20, 2022 at 1:46 PM Vitaly Zaitsev via devel
wrote:
>
> On 20/06/2022 10:47, Petr Pisar wrote:
> > I think Aleksandra wants to (non-scratch) build all pull requestes before
> > merging.
>
> Official non-scratch builds for non-merged pull requests? Looks very
> dangerous.
I actually
V Tue, Jun 21, 2022 at 03:50:31PM -0400, Matthew Miller napsal(a):
> On Mon, Jun 20, 2022 at 09:47:27PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > > Official non-scratch builds for non-merged pull requests? Looks very
> > > dangerous.
> >
> > Yeah. I think we should think about scratch and
On 21/06/2022 22:05, David Cantrell wrote:
5) Also go all in on automating (or removing) the spec file changelog. I
don't understand what the "build reason" is for above, but isn't every
changelog entry in a spec file technically the build reason?
I also think that every package change
On Sat, Jun 18, 2022 at 01:05:31PM +0200, Aleksandra Fedorova wrote:
> Hi, all,
>
> I'd like to discuss how we can add Build tag in the RPM.
>
> As one of the key points is to turn it into a common standard for rpm
> packages across the ecosystem, the conversation is currently opened
> upstream
On Mon, Jun 20, 2022 at 09:47:27PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > Official non-scratch builds for non-merged pull requests? Looks very
> > dangerous.
>
> Yeah. I think we should think about scratch and non-scratch builds
> separately. For scratch builds, e.g. in a pull request,
V Tue, Jun 21, 2022 at 11:58:02AM +0200, Pierre-Yves Chibon napsal(a):
> On Tue, Jun 21, 2022 at 12:27:57AM +0200, Fabio Valentini wrote:
> > There's currently a 100% foolproof way to parse NEVRs into their
> > components, because there are *always* two "-" separators (when
> > counting from the
On Tue, Jun 21, 2022 at 12:27:57AM +0200, Fabio Valentini wrote:
> On Tue, Jun 21, 2022 at 12:15 AM Neal Gompa wrote:
> >
> > On Mon, Jun 20, 2022 at 3:48 PM Zbigniew Jędrzejewski-Szmek
> > wrote:
> > >
> > > On Sat, Jun 18, 2022 at 01:05:31PM +0200, Aleksandra Fedorova wrote:
> > > > The most
On Mon, Jun 20, 2022 at 6:28 PM Fabio Valentini wrote:
>
> On Tue, Jun 21, 2022 at 12:15 AM Neal Gompa wrote:
> >
> > On Mon, Jun 20, 2022 at 3:48 PM Zbigniew Jędrzejewski-Szmek
> > wrote:
> > >
> > > On Sat, Jun 18, 2022 at 01:05:31PM +0200, Aleksandra Fedorova wrote:
> > > > The most visible
On Tue, Jun 21, 2022 at 12:15 AM Neal Gompa wrote:
>
> On Mon, Jun 20, 2022 at 3:48 PM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Sat, Jun 18, 2022 at 01:05:31PM +0200, Aleksandra Fedorova wrote:
> > > The most visible impact of the proposal would be the filename change:
> > >
> > >
On Mon, Jun 20, 2022 at 3:48 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Sat, Jun 18, 2022 at 01:05:31PM +0200, Aleksandra Fedorova wrote:
> > We'd like to introduce Build Number/Tag/Id in the rpm metadata.
>
> I agree with Vitaly: %rpmautospec+%rpmautorelease seem to cover
> most of this
On Sat, Jun 18, 2022 at 01:05:31PM +0200, Aleksandra Fedorova wrote:
> We'd like to introduce Build Number/Tag/Id in the rpm metadata.
I agree with Vitaly: %rpmautospec+%rpmautorelease seem to cover
most of this functionality in a reasonable way. Maybe there are other
motivations / use-cases that
On 20/06/2022 10:47, Petr Pisar wrote:
I think Aleksandra wants to (non-scratch) build all pull requestes before
merging.
Official non-scratch builds for non-merged pull requests? Looks very
dangerous.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
V Sat, Jun 18, 2022 at 01:57:30PM +0200, Vitaly Zaitsev via devel napsal(a):
> On 18/06/2022 13:43, Aleksandra Fedorova wrote:
> > And, for example, rpmautospec will not help in the case we need to
> > update a build on pull request update: When you work with
> > pull-requests you don’t
On 18/06/2022 14:05, Ralf Corsépius wrote:
It is just useless featuritis and doesn't make any sense at all, breaks
lots of tools/scripts, breaks 3rd party packaging conventions, and many
more ...
If an optional RPM BuildTag is introduced, it won't break anything. If
you don't need it, you
Am 18.06.22 um 13:05 schrieb Aleksandra Fedorova:
Hi, all,
I'd like to discuss how we can add Build tag in the RPM.
As one of the key points is to turn it into a common standard for rpm
packages across the ecosystem, the conversation is currently opened
upstream [1] and in RHEL Engineering.
On 18/06/2022 13:43, Aleksandra Fedorova wrote:
And, for example, rpmautospec will not help in the case we need to
update a build on pull request update: When you work with
pull-requests you don’t necessarily add commits, you rework the
history of a branch from which you run a PR. Sometimes even
Hi,
On Sat, Jun 18, 2022 at 1:24 PM Vitaly Zaitsev via devel
wrote:
>
> On 18/06/2022 13:05, Aleksandra Fedorova wrote:
> > * Provide a possibility to change build environment and rebuild rpm
> > packages without changing their content: neither sources nor spec
> > files.
>
> I have a better
On 18/06/2022 13:05, Aleksandra Fedorova wrote:
* Provide a possibility to change build environment and rebuild rpm
packages without changing their content: neither sources nor spec
files.
I have a better solution - let's move all packages to %autorelease +
%autochangelog.
Release:
Hi, all,
I'd like to discuss how we can add Build tag in the RPM.
As one of the key points is to turn it into a common standard for rpm
packages across the ecosystem, the conversation is currently opened
upstream [1] and in RHEL Engineering. And I'd like to get Fedora
community on board.
This
35 matches
Mail list logo
