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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
