On Mon, Jul 13, 2020 at 10:17:11AM +0200, Nicolas Mailhot via devel wrote: > Le dimanche 12 juillet 2020 à 13:07 -0700, Kevin Fenzi a écrit : > > On Sun, Jul 05, 2020 at 02:15:23PM +0200, Nicolas Mailhot via devel > > wrote: > > > > > > This is now done in the latest code refresh and in the test copr > > > https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/bc4e6a79355f3a2b73abeea7e5c0e1f53b09579e?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump > > > https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/ > > > > > > I fleshed out the change page a little too > > > https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping > > > > So I finally carved out a few minutes to look at this, but... > > Thank you for taking a look at it > > > > > https://copr-dist-git.fedorainfracloud.org/cgit/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/sil-charis-fonts.git > > seems to not exist? Is that some copr issue? > > I honestly do not know. The copr was created with a mass import of > srpms themselves created by rpmbuild -bs. I mainly use copr to check > the srpm I build locally in mock work in another system before feeding > them to koji, so I never used the git part of copr much. ok. No worries. > > Looking in the src.rpms I see some of the files I want to look at are > > oddly empty? > > > > ➜ ~ od -c rpmbuild/SOURCES/buildsys.conf > > 0000000 \n > > 0000016 > > > > Is that because it's the 'before' src.rpm without the version > > information injected yet? > > Yes, almost all of the srpm have not been bumped before they were fed > to copr, so they only include the minimal whitespace necessary for > rpmbuild to register them as sources (the evil "your source is less > than 13 bytes" rpmbuild assertion). > > IIRC, I scratched sources for most of them to check the new spectool > had not problem with the specs, so they won’t have any bump history in > them. > > You have an example of bumped srpm in adf-accanthis-fonts (with an > almost full buildsys.conf though this package do not use the postbuild > counter). > > > Might be nice for these files to have a small > > doc block at the top? > > The detached changelog – certainly not, that would complexify its > maintenance quite a lot. The conf file, why not, that’s fairly trivial > to add. > > Tough it is a litteral key = value file with no fancy formatting nor > even ini-like sections, and a handful of variables. Very boring KISS > stuff. Sure, but a file with 16 spaces and a newline is pretty confusing. > > Or at least the wiki page could explain each file, > > whats in it and whats the format for it. > > > > I really dislike having a second commit to say 'yes, this build was > > the last one'. Could you generate that info in advance and just > > commit it before the build? > > Well I really dislike people who commit that a build happened when it > has not yet, and who rewrite git history multiple times to "fix" when > they guess wrong:) Or worse, who do *not* rewrite git, and have a > changelog that clearly does not correspond to their build history. But then you know that exact thing was built. With this setup you look at the git hash in koji and... it's the next commit after that thats exactly this build? Thats really messy. > > The release part of autobumping will only happen if the spec needs it. > ie if the release the packager stored in the spec already makes the evr > newer than the last recorded evr no bump will happen. Changelog, not > sure, I suppose I could tie it up to release bumping so if one does not > happen the other does not happen either (that would make the code more > complex, but not too hard to add). > > However, is not possible and it won’t be possible to pre-fill > buildsys.conf because the decision to bump or not is made by comparing > the current evr to the one stored in there. So if you pre-bump the > file, the logic will decide you have already done the corresponding > build (which, if I follow you correctly will be *true*) and add another > release bump to make sure two consecutive builds in a branch have > different evrs. Right, I was suggesting _changing_ your macros for this workflow. maintainer makes changes, runs scratch builds, tests, etc. They decide everything is good for an official build. They generate the files and the macros just use those generated files, they don't bump anything or require a post build checkin. > > Basically, what you want is to reproduce a build you already did some > other way. Then just set the variable that triggers reproducible mode > and you’ll be done (that would require koji/copr cooperation however). > > If anything changed in the buildroots you build against your build may > fail the same way it fails today, and your git and changelog will be a > lie the same way they are a lie today, but I guess than is that mode > that’ll be what you want. But it's not a lie. Git isn't recording the state of the buildroot, koji does that. We now know exactly what git hash was built. With these macros we no longer do. Or I guess we sort of do, because we can input the same input again, but if the macros change any the result could change. > > There is no miracle, pre-filling means build roulette and bumping > mistakes. The proposed system is reliable because nothing except > rpmbuild itself records that a build actually happened in sources. > > The change is quite simple and robust code wise but it turns people > assumptions on their head. It is *real* autobumping and not the > approximations they are used to. > > In a real autobumper setup you do not pre-bump manually, anymore than a > real automated ansible setup you do not mess manually with the target > systems before you run your playbook. You can pre-mess manually and > pre-automation people are used to pre-mess manually but that’s a real > bad idea to continue once you switch to automated mode. While I like some of the ideas here, I don't like the proposed workflow. Will ponder on it some more. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
