On 10. 04. 20 1:50, Miro Hrončok wrote:
On 09. 04. 20 23:57, Miro Hrončok wrote:
On 09. 04. 20 20:45, Pierre-Yves Chibon wrote:
I actually cannot comment on this, it may be worth opening a koji ticket to ask
if this is the case or not and if it is if they can think of a way to deal with
this.
I plan to test this in staging and follow up on that, but possibly after Easter.
I was curious:
https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=90028113
CallbackError: Error running postSCMCheckout callback from
_koji_plugin__rpmautospec_builder:
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/koji/plugin.py", line 195, in
run_callbacks
func(cbtype, *cb_args, **cb_kwargs)
File "/usr/lib/koji-builder-plugins/rpmautospec_builder.py", line 91, in
process_distgit_cb
raise koji.BuildError("Installing `rpmautospec` into the build root failed.")
koji.BuildError: Installing `rpmautospec` into the build root failed.
Error:
Problem: package python3-rpmautospec-0.1.3-1.fc33.noarch requires
python3-koji, but none of the providers can be installed
- package rpmautospec-0.1.3-1.fc33.noarch requires python3-rpmautospec =
0.1.3-1.fc33, but none of the providers can be installed
- package python3-koji-1.20.0-1.fc32.noarch requires python3-six, but none of
the providers can be installed
- conflicting requests
- nothing provides this_is_broken_on_purpose needed by
python3-six-1.12.0-8.fc33.noarch
So there are 2 reasonable things I think that can be done apart from rewriting
rpmautospec into Rust ;)
## Koji side tag buildSRPMFromSCM self inavailability solution
Based on my testing, it is clear that builds from the on demand side tags
(created with `fedpkg request-side-tag`) use the builds from its own side tag
both in the actual buildArch tasks and in the buildSRPMFromSCM task.
OTOH I know we can have side tags that don't use their own builds in neither
task, for example the side tags we use for mass rebuilds behave this way.
So the actual question is: Can we have side tags that do both of the following
things at the same time?
- use their own builds in the buildArch tasks
- don't see/use their own builds in the buildSRPMFromSCM tasks
(CCed Kevin, Mohan and Tomáš for this before I go file tickets.)
Pros:
1. I'd say that rpmautospec can't be the first thing ever that would need this
kind fo treatment. We need to be able to bootstrap things that are used in
buildSRPMFromSCM tasks, right?
2. No significant changes needed in rpmautospec.
Cons:
1. If Koji doesn't support this use case yet, it might require significant
changes there.
2. If packages start using rpmautospec at scale, side tag must be always used to
bootstrap anything in the dependency chain. While I'd very much like to see this
happening regardless of rpmautospec, the truth is, that people do "simple chain
builds" directly in rawhide all the time (e.g. gcc + annobin,
python-cryptogtaphy-vectors + python-cryptogtaphy).
In the case of rpmautospec this means that if somebody bumps python3-urllib3 in
rawhide first to go to bump python3-requests immediately after that, if the old
requests don't install with the new urllib3 AND requests use %autorel, things
will blow up, builds will need to be untagged and tagged to a new side tag just
to untangle this.
## Move (most of) rpmautospec outside of the mock chroot
Another solution I can think of is that the koji-builder-plugin-rpmautospec
package does all the nice things like figure out what to inject into the spec
file and prepares everything for needed for rpmautospec *outside of the mock
chroot*.
rpmautospec than in fact would only be responsible of actually putting the
information into the specfile without using all the 3rd party Python libraries.
It would be a simple script (see fedpkg-minimal that exists for this very
reason) -- keeping it in written in Python remain an option (as long as it only
uses stdlib and doesn't live in site-packages), but making it Bash (like
fedpkg-minimal) would be even less fragile.
However, what are the reasons to determine the spec content from within the
buildroot? Does it heavily depend on values of macros like %fedora or %dist?
What parts of the procedure are safe to do from a different system and what
needs to be done from within?
Pros:
1. Much more robust solution, smaller package footprint in buildSRPMFromSCM
means smaller "bungle surface" (like "attack surface" but without the ill will).
Cons:
2. Significant (design) changes in rpmautospec needed.
3. I don't know the exact reasons rpmautospec runs from within the chroot.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
