Re: Auto-update for sid? Auto-backport?
Hi Guido,
2017-11-24 12:48 GMT+01:00 Guido Günther <agx@sigxcpu.org>:
> Hi,
> On Fri, Nov 17, 2017 at 04:31:43PM +0100, Guido Günther wrote:
>> Hi,
>> On Wed, Nov 15, 2017 at 04:43:17PM +0100, Steffen Möller wrote:
>> > Hello,
>> >
>> > my QA page or our blend's task page (like
>> > https://blends.debian.org/med/tasks/bio-ngs) regularly informs me about
>> > updates that should be performed to packages I alone maintain or (more
>> > likely) with the help of my blend. The updates are often (but now
>> > always, admittedly) easy to do.
>> >
>> > I would really like to see updates performed in some automated fashion.
>> > Maybe into a different section of Debian like sid-auto? The problem with
>> > that obviously is the missing scrutiny by the human maintainer, so it
>> > cannot go straight into sid. Or can it? Maybe with an auto-created bug
>> > report against the package so it does not auto-migrate into testing?
>>
>> What I have started to do is having jobs that run once a day uscan,
>> rebase patches, build in pbuilder, run autopkgtests via pbuilder's
>> autopkgtest hook[1] (to be put into a Jenkins instance).
>>
>> That's about 99% of the busy work since I know in advance which packages
>> will need work (because patches no longer apply, tests fail or lintian
>> reports errors) while others can be uploaded right away after more
>> manual testing (if they don't have excessive test suites). Would that
>> help already? if so we could look into making this more usable to
>> others.
>
> I've cleaned stuff up a bit and moved some of the (smaller) jobs to a
> public instance:
>
> http://autoff.sigxcpu.org
>
> and dumped the ansible to setup jenkins and the jobs here:
>
> http://github.com/agx/debautoff
> http://github.com/agx/debautoff-projects
>
> (Autopkgtests are currently disabled to not make the vm explode). If
> this make sense for others as well it needs to be moved to a bigger
> instance (maybe integrated with jenkins.debian.net)?
Thanks! I believe at some point such service will need much bigger machines. :-)
I was thinking about automating the repetitive tasks, too for some time
but could not find time to implement fully what I wanted to share as an
initial release.
I just uploaded a prototype/skeleton of the idea here:
https://anonscm.debian.org/cgit/collab-maint/debian-dad.git
Instead of starting with the service concept I went with the distributed
usage model to let everyone play with the tool easily even with
private packages.
The idea was starting from a known source package name and helping
the maintainer as much as possible in an automated manner and providing
the changes in a git repository nicely separated commit by commit.
The set of packages which can be updated easily includes the ones
without any packaging repository and the the update is not limited to
updating to latest upstream and testing the result. There are many minor
changes which can be easily applied like fixing smaller problems
already reported by Lintian and as an example I already implemented
updating symbols files.
Please take a look and if you like the concept I'll go ahead with an ITP
and welcome contributions.
I don't plan sticking to one particular packaging repository format, for
example I plan adding support for tracking upstream branches
commit-by-commit with gbp but Subversion repository support will most
likely exist only via git-svn.
Cheers,
Balint
>
> Cheers,
> -- Guido
>
>>
>> > A similar situation I see with backports. Most commonly all that is
>> > needed is a recompilation. Would an automation of that process be
>> > acceptable? Would it be acceptable for packages that offer some means of
>> > automated testing and are in backports already?
>> >
>> > Many thanks for your opinions
>> >
>> > Steffen
>> >
>>
>> [1]: /usr/share/doc/git-buildpackage/examples/gbp-try-ff
>>
--
I fixed #875980 in git before sending this email to debian-devel.
http://balintreczey.hu/blog/my-debian-devel-pledge
Actually I fixed it using 'dad update' and tested the results manually. :-)
Reply to: