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. > 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. > 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. 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. 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. 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. Regards, -- Nicolas Mailhot _______________________________________________ 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
