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

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

>  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

> 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.


Nicolas Mailhot
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to