Hey Miro! On Fri, 2020-04-10 at 11:01 +0200, Miro Hrončok wrote: > 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 [snipped errors from broken Python 3rd party packages] > So there are 2 reasonable things I think that can be done apart from > rewriting rpmautospec into Rust ;) It's a little late for April Fools. :) [snipped the "special case buildSRPMFromSCM for side tag builds" approach] > ## 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. I think rpmautospec separates concerns between what has to be done in the build root vs. what can be done outside pretty good already. ;) Let me back up a little: The reason rpmautospec does anything in the build root at all is because the code that computes the "next release" value has to know for which Fedora version (or more precisely, the %dist tag) the build in question is intended: if at all possible, the EVR about to be built should fit within that of the latest builds in the same or older Fedora versions on the one hand, and newer Fedora versions on the other. Unfortunately (for rpmautospec), Koji doesn't really care about the Fedora or EPEL version it's building for, all it seems to know is tags and how they're derived from each other. The dist tag is only set in the build root, by /usr/lib/rpm/macros.d/macros.dist from the fedora- release-common package. Fortunately, rpmautospec already does very little in the build root: The plugin queries Koji outside (this is where the one 3rd party Python package dep comes from) and stores the information gathered (latest build EVRs for each dist tag) as git tags. The code run in the build root computes the next release using the tags (dep on git-core), and with that generates the changelog (which needs info about the current and historic build EVRs). So, to make this more robust against problems like you described, we should decouple what's run in the build root from a specific minor version of Python and the rpm Python package (and remove the superfluous Koji dependency). This shouldn't be much work, the biggest piece is probably to make it get by without using the rpm Python package (for comparing EVRs and to expand macros), but a tiny ctypes wrapper around rpmlib should solve this for us. To me, that's good enough. Porting the pieces that have to run inside the build root to e.g. shell really wouldn't make them more robust, but just change one dependency which may not break for another. Also, even if the worst came to the worst, say a severily broken Python or git-core package has snuck its way into the build roots, and all people with the power to untag these went on vacation, then any packager can easily unblock their build by temporarily reverting to a manually set release and changelog, the plugin will just go out of the way in this case. Nils -- Nils Philippsen "Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 _______________________________________________ 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
