On Wed, 2020-12-30 at 14:41 -0800, Michel Alexandre Salim wrote: > Howdy, > > On Sat, 2020-12-26 at 20:39 +0000, Sérgio Basto wrote: > > Hi, > > For me the most time consuming is monkey updates packages like kde > > apps > > , which every month or two we have a new release ( kde app 20.04.1 > > 20.04.2 20.08.0 , 20.12.00 etc ) > > > > I did some scripts to automate my builds , we got some software > > like > > https://github.com/fedora-infra/the-new-hotness/ > > but the more I do, I always some variables that are different from > > project to project , we need to know the version number, we may > > need > > to > > download more than one source, we may need drop patches that we > > know > > that are already upstreamed, not all the package are build in same > > branches so we need to know what branches we want update , we may > > have > > to add buildroot-overrides, we need add build to bodhi and fill > > some > > information , we need close bugs create made by hotness or other > > users > > etc > > > > Examples of my scripts are usually in packages sources like > > > > https://src.fedoraproject.org/rpms/virtualbox-guest-additions/blob/master/f/update_vbox.sh > > > > > > or (in attachment) scripts in very quick-and-dirty style > > > > So, combine tools like rpmdevtools , the-new-hotness , bodhi-client > > etc > > we improve building automation . > > > My use case is similar: I comaintain a list of packages that Facebook > open-sources that need to be rebuilt in step (since sadly ABI > stability > is not currently promised). > > I've cleaned-up my scripts: > https://pagure.io/michel-slm/bulk-rebuild > > and blogged about them: > https://michel-slm.name/posts/2020-12-30-fedora-bulk-rebuild/ > > They mostly wrap around rpmdev-bumpspec, fedpkg, and bodhi right now. > > Curious to see how much can be factored out and shared among > different > packagers that perform similar tasks. e.g. I see the GNOME packagers > doing bulk updates too. > > One observation (also in the post): > > The CLIs for fedpkg and koji is currently meant for human, not > machine, > consumptions. Invoking them from Bash scripts and trying to use the > output (e.g. getting the name of that side tag) involves some brittle > parsing. I plan to rewrite this in Python anyway, but it might be > useful to add an output formatter to some commands where it makes > sense > (e.g. request-side-tag or chain-build). I was looking at your scripts and I saw a reference to bodhi-cli, yesterday I found out that fedpkg also has this option. fedpkg update --help usage: fedpkg update [-h] [--type {bugfix,security,enhancement,newpackage}] [--request {testing,stable}] [--bugs BUGS [BUGS ...]] [--notes NOTES] [--disable-autokarma] [--stable-karma KARMA] [ --unstable-karma KARMA] [--not-close-bugs] [--suggest-reboot] [--no- require-bugs] [--no-require-testcases] This will create a bodhi update request for the current package n-v-r. There are two ways to specify update details. Without any argument from command line, either update type or notes is omitted, a template editor will be shown and let you edit the detail information interactively. Alternatively, you could specify argument from command line to create an update directly, for example: fedpkg update --type bugfix --notes 'Rebuilt' --bugs 1000 1002 When all lines in template editor are commented out or deleted, the creation process is aborted. If the template keeps unchanged, fedpkg continues on creating update. That gives user a chance to confirm the auto-generated notes from change log if option --notes is omitted. optional arguments: -h, --help show this help message and exit --type {bugfix,security,enhancement,newpackage} Update type. Template editor will be shown if type is omitted. --request {testing,stable} Requested repository. --bugs BUGS [BUGS ...] Bug numbers. If omitted, bug numbers will be extracted from change logs. --notes NOTES Update description. Multiple lines of notes could be specified. If omitted, template editor will be shown. --disable-autokarma Karma automatism is enabled by default. Use this option to disable that. --stable-karma KARMA Stable karma. Default is 3. --unstable-karma KARMA Unstable karma. Default is -3. --not-close-bugs By default, update will be created by enabling to close bugs automatically. If this is what you do not want, use this option to disable the default behavior. --suggest-reboot Suggest user to reboot after update. Default is False. --no-require-bugs Disables the requirement that all of the bugs in your update have been confirmed by testers. Default is True. --no-require-testcases Disables the requirement that this update passes all test cases before reaching stable. Default is True. Best regards, -- Sérgio M. B. _______________________________________________ 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
