Hi,
I need to bootstrap package which has bootstrap support written according to the [1]. I am able to bootstrap it locally (rpmbuild, mock, ...) with the "--with bootstrap" or "-D '_with_bootstrap 1'". Is there support for it in koji? E.g. something like: koji build SIDE-TAG PACKAGE --bootstrap? Or do I have to manually do: 1. patch: - %bcond_with bootstrap + %bcond_without bootstrap 2. koji build SIDE-TAG SCM 3. update&build the circular dep 4. unpatch: - %bcond_without bootstrap + %bcond_with bootstrap 5. release bump 6. koji build SIDE-TAG SCM
Or is there some better way?
thanks & regards
Jaroslav
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
On Tue, Jan 24, 2023 at 1:39 PM Jaroslav Skarvada jskarvad@redhat.com wrote:
Hi,
I need to bootstrap package which has bootstrap support written according to the [1]. I am able to bootstrap it locally (rpmbuild, mock, ...) with the "--with bootstrap" or "-D '_with_bootstrap 1'". Is there support for it in koji? E.g. something like: koji build SIDE-TAG PACKAGE --bootstrap? Or do I have to manually do:
- patch:
- %bcond_with bootstrap
- %bcond_without bootstrap
- koji build SIDE-TAG SCM
- update&build the circular dep
- unpatch:
- %bcond_without bootstrap
- %bcond_with bootstrap
- release bump
- koji build SIDE-TAG SCM
Or is there some better way?
thanks & regards
Jaroslav
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
You might be able to set macros in your build tags to switch back and forth between bootstrap mode. I don't recall exactly how this is done from the koji CLI though...
On Tue, Jan 24, 2023 at 7:42 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jan 24, 2023 at 1:39 PM Jaroslav Skarvada jskarvad@redhat.com wrote:
Hi,
I need to bootstrap package which has bootstrap support written according to the [1]. I am able to bootstrap it locally (rpmbuild, mock, ...) with the "--with bootstrap" or "-D '_with_bootstrap 1'". Is there support for it in koji? E.g. something like: koji build SIDE-TAG PACKAGE --bootstrap? Or do I have to manually do:
- patch:
- %bcond_with bootstrap
- %bcond_without bootstrap
- koji build SIDE-TAG SCM
- update&build the circular dep
- unpatch:
- %bcond_without bootstrap
- %bcond_with bootstrap
- release bump
- koji build SIDE-TAG SCM
Or is there some better way?
thanks & regards
Jaroslav
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
You might be able to set macros in your build tags to switch back and forth between bootstrap mode. I don't recall exactly how this is done from the koji CLI though...
I initially thought about: release bump $ koji edit-tag SIDETAG -x %_with_bootstrap=1 build handle circular dep $ koji edit-tag SIDETAG -r %_with_bootstrap build
But I haven't tried it yet because I didn't want to break anything :) Is this the correct way to do it?
On Tue, Jan 24, 2023 at 07:54:29PM +0100, Jaroslav Skarvada wrote:
I initially thought about: release bump $ koji edit-tag SIDETAG -x %_with_bootstrap=1 build handle circular dep $ koji edit-tag SIDETAG -r %_with_bootstrap build
But I haven't tried it yet because I didn't want to break anything :) Is this the correct way to do it?
That should work, (as long as you bump the release for the second build as koji will not let you rebuild the same n-v-r) but I am not sure anyone has tried it.
The "old" way to do it, is as you assumed, to just modify the spec to enable the bootstrap path, build and then change back.
The sidetag way would save you a commit, so that seems better to me, but up to you.
kevin
On Tue, Jan 24, 2023 at 3:00 PM Kevin Fenzi kevin@scrye.com wrote:
On Tue, Jan 24, 2023 at 07:54:29PM +0100, Jaroslav Skarvada wrote:
I initially thought about: release bump $ koji edit-tag SIDETAG -x %_with_bootstrap=1 build handle circular dep $ koji edit-tag SIDETAG -r %_with_bootstrap build
But I haven't tried it yet because I didn't want to break anything :) Is this the correct way to do it?
That should work, (as long as you bump the release for the second build as koji will not let you rebuild the same n-v-r) but I am not sure anyone has tried it.
The NVR will automatically change when you flip between modes, since it changes the DistTag.
On Tue, Jan 24, 2023 at 9:37 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jan 24, 2023 at 3:00 PM Kevin Fenzi kevin@scrye.com wrote:
On Tue, Jan 24, 2023 at 07:54:29PM +0100, Jaroslav Skarvada wrote:
I initially thought about: release bump $ koji edit-tag SIDETAG -x %_with_bootstrap=1 build handle circular dep $ koji edit-tag SIDETAG -r %_with_bootstrap build
But I haven't tried it yet because I didn't want to break anything :) Is this the correct way to do it?
That should work, (as long as you bump the release for the second build as koji will not let you rebuild the same n-v-r) but I am not sure anyone has tried it.
The NVR will automatically change when you flip between modes, since it changes the DistTag.
Thanks for the info, we will try it. It would be great to have it documented somewhere in the guidelines
thanks & regards
Jaroslav
Jaroslav Skarvada wrote:
Thanks for the info, we will try it. It would be great to have it documented somewhere in the guidelines
Yes it would. This looks like a good place: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
"koji edit-tag --help" calls it "Set tag extra option". I would not have guessed that an "extra option" would transform into an RPM macro, nor that a "_with_" prefix would need to be added.
Björn Persson
On Tue, Jan 24, 2023 at 03:36:41PM -0500, Neal Gompa wrote:
On Tue, Jan 24, 2023 at 3:00 PM Kevin Fenzi kevin@scrye.com wrote:
On Tue, Jan 24, 2023 at 07:54:29PM +0100, Jaroslav Skarvada wrote:
I initially thought about: release bump $ koji edit-tag SIDETAG -x %_with_bootstrap=1 build handle circular dep $ koji edit-tag SIDETAG -r %_with_bootstrap build
But I haven't tried it yet because I didn't want to break anything :) Is this the correct way to do it?
That should work, (as long as you bump the release for the second build as koji will not let you rebuild the same n-v-r) but I am not sure anyone has tried it.
The NVR will automatically change when you flip between modes, since it changes the DistTag.
Ah indeed.
So you should only need 1 initial commit.
kevin
Unfortunately we have tried to use 'koji edit-tag SIDETAG -x %_with_bootstrap=1' command but it always ended with 'koji: ActionNotAllowed: tag permission required (logged in as USER)' even when creator of the sidetag used the command.
On Tue, Jan 24, 2023 at 10:45 PM Kevin Fenzi kevin@scrye.com wrote:
On Tue, Jan 24, 2023 at 03:36:41PM -0500, Neal Gompa wrote:
On Tue, Jan 24, 2023 at 3:00 PM Kevin Fenzi kevin@scrye.com wrote:
On Tue, Jan 24, 2023 at 07:54:29PM +0100, Jaroslav Skarvada wrote:
I initially thought about: release bump $ koji edit-tag SIDETAG -x %_with_bootstrap=1 build handle circular dep $ koji edit-tag SIDETAG -r %_with_bootstrap build
But I haven't tried it yet because I didn't want to break anything :) Is this the correct way to do it?
That should work, (as long as you bump the release for the second build as koji will not let you rebuild the same n-v-r) but I am not sure anyone has tried it.
The NVR will automatically change when you flip between modes, since it changes the DistTag.
Ah indeed.
So you should only need 1 initial commit.
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Reading the thread, I was afraid this will be the end result. Nevertheless, given this would be used just for side-tags, is there a chance to exclude side tags from the policy? Who would handle such request?
Although being able to modify one macro means also possibility to edit all macros. Not sure this is desired. However one can achieve almost everything by changing .spec file, so that should not be blocker IMHO.
Vít
Dne 25. 01. 23 v 9:18 Richard Lescak napsal(a):
Unfortunately we have tried to use 'koji edit-tag SIDETAG -x %_with_bootstrap=1' command but it always ended with 'koji: ActionNotAllowed: tag permission required (logged in as USER)' even when creator of the sidetag used the command.
On Tue, Jan 24, 2023 at 10:45 PM Kevin Fenzi kevin@scrye.com wrote:
On Tue, Jan 24, 2023 at 03:36:41PM -0500, Neal Gompa wrote: > On Tue, Jan 24, 2023 at 3:00 PM Kevin Fenzi <kevin@scrye.com> wrote: > > > > On Tue, Jan 24, 2023 at 07:54:29PM +0100, Jaroslav Skarvada wrote: > > > > > > I initially thought about: > > > release bump > > > $ koji edit-tag SIDETAG -x %_with_bootstrap=1 > > > build > > > handle circular dep > > > $ koji edit-tag SIDETAG -r %_with_bootstrap > > > build > > > > > > But I haven't tried it yet because I didn't want to break anything :) > > > Is this the correct way to do it? > > > > That should work, (as long as you bump the release for the second build > > as koji will not let you rebuild the same n-v-r) > > but I am not sure anyone has tried it. > > > > The NVR will automatically change when you flip between modes, since > it changes the DistTag. Ah indeed. So you should only need 1 initial commit. kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
--
Richard Lescak
Associate Software Engineer
Red Hat Czech - Brno TPB-C https://www.redhat.com/
devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-leave@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
On 25. 01. 23 11:50, Vít Ondruch wrote:
Reading the thread, I was afraid this will be the end result. Nevertheless, given this would be used just for side-tags, is there a chance to exclude side tags from the policy? Who would handle such request?
Although being able to modify one macro means also possibility to edit all macros. Not sure this is desired. However one can achieve almost everything by changing .spec file, so that should not be blocker IMHO.
I think the "commit the bootstrap conditional directly to bootstrap something" approach is much more transparent than "fiddling with macros in Koji to save myself one tiny commit" anyway.
-------
To answer the original question, it can be done like this:
1. commit all commits and push them all 2. fedpkg request-side-tag 3. koji chain-build --nowait f38-build-side-66666 'git+https://src.fedoraproject.org/rpms/python3.12.git#fe95b37f25338c94bcfa2fb653...' : ..instert mid deps here... : 'git+https://src.fedoraproject.org/rpms/python3.12.git#1bc45ffecb2b268fb56fbdc61c...'
On Wed, Jan 25, 2023 at 12:13 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 01. 23 11:50, Vít Ondruch wrote:
Reading the thread, I was afraid this will be the end result. Nevertheless, given this would be used just for side-tags, is there a chance to exclude side tags from the policy? Who would handle such request?
Although being able to modify one macro means also possibility to edit all macros. Not sure this is desired. However one can achieve almost everything by changing .spec file, so that should not be blocker IMHO.
Or add an option that will mark/unmark the sidetag for bootstrapping, i.e. option that will add only this specific bootstrap macro to the sidetag and nothing more.
I think the "commit the bootstrap conditional directly to bootstrap something" approach is much more transparent than "fiddling with macros in Koji to save myself one tiny commit" anyway.
It's one commit per package. If you rebuild more packages there may be more things that need bootstrapping.
To answer the original question, it can be done like this:
- commit all commits and push them all
- fedpkg request-side-tag
- koji chain-build --nowait f38-build-side-66666
'git+https://src.fedoraproject.org/rpms/python3.12.git#fe95b37f25338c94bcfa2fb653...' : ..instert mid deps here... : 'git+https://src.fedoraproject.org/rpms/python3.12.git#1bc45ffecb2b268fb56fbdc61c...'
If there already are the boostrap conditionals in the specs the logic progress is to have some support in the infra. Just manually reverting the condition in the spec is, let's say not the optimal solution. Just my two cents.
Dne 25. 01. 23 v 15:45 Jaroslav Skarvada napsal(a):
On Wed, Jan 25, 2023 at 12:13 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 01. 23 11:50, Vít Ondruch wrote:
Reading the thread, I was afraid this will be the end result. Nevertheless, given this would be used just for side-tags, is there a chance to exclude side tags from the policy? Who would handle such request?
Although being able to modify one macro means also possibility to edit all macros. Not sure this is desired. However one can achieve almost everything by changing .spec file, so that should not be blocker IMHO.
Or add an option that will mark/unmark the sidetag for bootstrapping, i.e. option that will add only this specific bootstrap macro to the sidetag and nothing more.
I think the "commit the bootstrap conditional directly to bootstrap something" approach is much more transparent than "fiddling with macros in Koji to save myself one tiny commit" anyway.
It's one commit per package. If you rebuild more packages there may be more things that need bootstrapping.
Right. I was the one proposing bootstrap macro and I did it with Ruby on Rails rebuild in mind. That was ~8 packages at that time (but the full dependency chain is probably more than 100 packages). So it would be really handy if I could do:
1. Commit everything.
2. Build with bootstrap everything.
3. Build without bootstrap everything.
I still think it would be of great benefit for mass rebuilds, where one needs to work with large sets of packages without intimate knowledge of each package.
Vít
To answer the original question, it can be done like this:
- commit all commits and push them all
- fedpkg request-side-tag
- koji chain-build --nowait f38-build-side-66666
'git+https://src.fedoraproject.org/rpms/python3.12.git#fe95b37f25338c94bcfa2fb653...' : ..instert mid deps here... : 'git+https://src.fedoraproject.org/rpms/python3.12.git#1bc45ffecb2b268fb56fbdc61c...'
If there already are the boostrap conditionals in the specs the logic progress is to have some support in the infra. Just manually reverting the condition in the spec is, let's say not the optimal solution. Just my two cents. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Wed, Jan 25, 2023 at 03:45:35PM +0100, Jaroslav Skarvada wrote:
On Wed, Jan 25, 2023 at 12:13 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 01. 23 11:50, Vít Ondruch wrote:
Reading the thread, I was afraid this will be the end result. Nevertheless, given this would be used just for side-tags, is there a chance to exclude side tags from the policy? Who would handle such request?
I thought we had already done this, but it seems not.
I am not 100% koji has the needed policy for this, so I'd say file the issue first as a koji issue and once we can allow/disallow this via policy we can allow it for sidetags... but see below.
Although being able to modify one macro means also possibility to edit all macros. Not sure this is desired. However one can achieve almost everything by changing .spec file, so that should not be blocker IMHO.
Or add an option that will mark/unmark the sidetag for bootstrapping, i.e. option that will add only this specific bootstrap macro to the sidetag and nothing more.
Yeah, that would be better than allowing all tag options to be set.
I think the "commit the bootstrap conditional directly to bootstrap something" approach is much more transparent than "fiddling with macros in Koji to save myself one tiny commit" anyway.
It's one commit per package. If you rebuild more packages there may be more things that need bootstrapping.
Also: commits to reverse the horrible with/without syntax are error prone. If we can avoid doing them, we can probibly avoid some mistakes.
To answer the original question, it can be done like this:
- commit all commits and push them all
- fedpkg request-side-tag
- koji chain-build --nowait f38-build-side-66666
'git+https://src.fedoraproject.org/rpms/python3.12.git#fe95b37f25338c94bcfa2fb653...' : ..instert mid deps here... : 'git+https://src.fedoraproject.org/rpms/python3.12.git#1bc45ffecb2b268fb56fbdc61c...'
If there already are the boostrap conditionals in the specs the logic progress is to have some support in the infra. Just manually reverting the condition in the spec is, let's say not the optimal solution. Just my two cents.
I personally agree.
I think ideally koji would allow us to allow/deny changing taginfo to side tags, and even better allow/deny changing just bootstrap=1.
kevin
Dne 25. 01. 23 v 19:34 Kevin Fenzi napsal(a):
On Wed, Jan 25, 2023 at 03:45:35PM +0100, Jaroslav Skarvada wrote:
On Wed, Jan 25, 2023 at 12:13 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 01. 23 11:50, Vít Ondruch wrote:
Reading the thread, I was afraid this will be the end result. Nevertheless, given this would be used just for side-tags, is there a chance to exclude side tags from the policy? Who would handle such request?
I thought we had already done this, but it seems not.
I am not 100% koji has the needed policy for this, so I'd say file the issue first as a koji issue and once we can allow/disallow this via policy we can allow it for sidetags... but see below.
Although being able to modify one macro means also possibility to edit all macros. Not sure this is desired. However one can achieve almost everything by changing .spec file, so that should not be blocker IMHO.
Or add an option that will mark/unmark the sidetag for bootstrapping, i.e. option that will add only this specific bootstrap macro to the sidetag and nothing more.
Yeah, that would be better than allowing all tag options to be set.
I think the "commit the bootstrap conditional directly to bootstrap something" approach is much more transparent than "fiddling with macros in Koji to save myself one tiny commit" anyway.
It's one commit per package. If you rebuild more packages there may be more things that need bootstrapping.
Also: commits to reverse the horrible with/without syntax are error prone. If we can avoid doing them, we can probibly avoid some mistakes.
To answer the original question, it can be done like this:
- commit all commits and push them all
- fedpkg request-side-tag
- koji chain-build --nowait f38-build-side-66666
'git+https://src.fedoraproject.org/rpms/python3.12.git#fe95b37f25338c94bcfa2fb653...' : ..instert mid deps here... : 'git+https://src.fedoraproject.org/rpms/python3.12.git#1bc45ffecb2b268fb56fbdc61c...'
If there already are the boostrap conditionals in the specs the logic progress is to have some support in the infra. Just manually reverting the condition in the spec is, let's say not the optimal solution. Just my two cents.
I personally agree.
I think ideally koji would allow us to allow/deny changing taginfo to side tags, and even better allow/deny changing just bootstrap=1.
I have opened this Koji ticket:
https://pagure.io/koji/issue/3669
Lets see what happens.
Vít
Dne 26. 01. 23 v 9:43 Vít Ondruch napsal(a):
Dne 25. 01. 23 v 19:34 Kevin Fenzi napsal(a):
On Wed, Jan 25, 2023 at 03:45:35PM +0100, Jaroslav Skarvada wrote:
On Wed, Jan 25, 2023 at 12:13 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 01. 23 11:50, Vít Ondruch wrote:
Reading the thread, I was afraid this will be the end result. Nevertheless, given this would be used just for side-tags, is there a chance to exclude side tags from the policy? Who would handle such request?
I thought we had already done this, but it seems not.
I am not 100% koji has the needed policy for this, so I'd say file the issue first as a koji issue and once we can allow/disallow this via policy we can allow it for sidetags... but see below.
Although being able to modify one macro means also possibility to edit all macros. Not sure this is desired. However one can achieve almost everything by changing .spec file, so that should not be blocker IMHO.
Or add an option that will mark/unmark the sidetag for bootstrapping, i.e. option that will add only this specific bootstrap macro to the sidetag and nothing more.
Yeah, that would be better than allowing all tag options to be set.
I think the "commit the bootstrap conditional directly to bootstrap something" approach is much more transparent than "fiddling with macros in Koji to save myself one tiny commit" anyway.
It's one commit per package. If you rebuild more packages there may be more things that need bootstrapping.
Also: commits to reverse the horrible with/without syntax are error prone. If we can avoid doing them, we can probibly avoid some mistakes.
To answer the original question, it can be done like this:
- commit all commits and push them all
- fedpkg request-side-tag
- koji chain-build --nowait f38-build-side-66666
'git+https://src.fedoraproject.org/rpms/python3.12.git#fe95b37f25338c94bcfa2fb653...'
: ..instert mid deps here... : 'git+https://src.fedoraproject.org/rpms/python3.12.git#1bc45ffecb2b268fb56fbdc61c...'
If there already are the boostrap conditionals in the specs the logic progress is to have some support in the infra. Just manually reverting the condition in the spec is, let's say not the optimal solution. Just my two cents.
I personally agree.
I think ideally koji would allow us to allow/deny changing taginfo to side tags, and even better allow/deny changing just bootstrap=1.
I have opened this Koji ticket:
https://pagure.io/koji/issue/3669
Lets see what happens.
It seems that Koji supports this, but it need some configuration change. I have opened followup ticket here:
https://pagure.io/releng/issue/11254
Vít
On Tue, Jan 31, 2023 at 02:23:48PM +0100, Vít Ondruch wrote:
It seems that Koji supports this, but it need some configuration change. I have opened followup ticket here:
Yeah, my first thought about this was that it might be too broad, but it was pointed out that maintainers can already override macros in specs anyhow.
Might run it by FESCo just to make sure everyone is ok with enabling...
kevin
On 1/31/23 11:06, Kevin Fenzi wrote:
On Tue, Jan 31, 2023 at 02:23:48PM +0100, Vít Ondruch wrote:
It seems that Koji supports this, but it need some configuration change. I have opened followup ticket here:
Yeah, my first thought about this was that it might be too broad, but it was pointed out that maintainers can already override macros in specs anyhow.
Might run it by FESCo just to make sure everyone is ok with enabling...
kevin
I would think the main concern is the audit trail. Defining a macro in a spec file is checked into git and there is a record. Is there a record (and relatively easily accessed) for the macros set in a side tage?
On Tue, Jan 31, 2023 at 07:06:25PM -0700, Orion Poplawski wrote:
On 1/31/23 11:06, Kevin Fenzi wrote:
On Tue, Jan 31, 2023 at 02:23:48PM +0100, Vít Ondruch wrote:
It seems that Koji supports this, but it need some configuration change. I have opened followup ticket here:
Yeah, my first thought about this was that it might be too broad, but it was pointed out that maintainers can already override macros in specs anyhow.
Might run it by FESCo just to make sure everyone is ok with enabling...
kevin
I would think the main concern is the audit trail. Defining a macro in a spec file is checked into git and there is a record. Is there a record (and relatively easily accessed) for the macros set in a side tage?
Yeah, koji list-history will show it... but that may not be an obvious place to look. For bootstrap purposes you still need 1 commit saying you did the bootstrap, so perhaps thats enough...
kevin
Getting back to this thread, because the good news is that things have improved and there is now easier way to bootstrap packages in Koji using side-tags:
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guid...
and `%_with_bootstrap` macro.
https://docs.fedoraproject.org/en-US/fesco/Policy_for_buildroot_macros/
Enjoy.
Vít
Dne 24. 01. 23 v 19:38 Jaroslav Skarvada napsal(a):
Hi,
I need to bootstrap package which has bootstrap support written according to the [1]. I am able to bootstrap it locally (rpmbuild, mock, ...) with the "--with bootstrap" or "-D '_with_bootstrap 1'". Is there support for it in koji? E.g. something like: koji build SIDE-TAG PACKAGE --bootstrap? Or do I have to manually do:
- patch:
- %bcond_with bootstrap
- %bcond_without bootstrap
- koji build SIDE-TAG SCM
- update&build the circular dep
- unpatch:
- %bcond_without bootstrap
- %bcond_with bootstrap
- release bump
- koji build SIDE-TAG SCM
Or is there some better way?
thanks & regards
Jaroslav
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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