[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automatically building packages affected by submitted patches

From: Christopher Baines
Subject: Re: Automatically building packages affected by submitted patches
Date: Wed, 06 Mar 2019 19:39:48 +0000
User-agent: mu4e 1.0; emacs 26.1

Ludovic Courtès <address@hidden> writes:

> Christopher Baines <address@hidden> skribis:
>> For a specific example, here [5] is series 700 (a Patchwork id). There
>> are a number of intermediate steps, but this is the specification in
>> Cuirass [6].
>> 5:
>> 6:
> Amazing!  Looks like you’re really close to reaching your initial goal!

Thanks :)

>> In terms of features I'd like to work towards next, the main thing on my
>> mind is doing something useful with the data from building these
>> packages. With the goal of displaying a check in Patchwork about the
>> build status of the affected packages, I need to compare what's been
>> build by my Cuirass instance, with what has
>> built. To do this, my current plan is to have the Guix Data Service
>> monitor a number of Cuirass instances somehow, extract information from
>> them and store it. You'd then be able to get a comparison for the build
>> status using the results gathered from the two Cuirass instances from
>> the Guix Data Service.
> I’m also not sure why you need to compare things.  Looking at
> <> and
> <>, it looks like Cuirass is
> already building the subset of packages that depend on the modified
> package(s):
> "subset":["address@hidden","address@hidden","address@hidden","address@hidden"]
> (Though what is “r-dnacopy” doing here?)

The query in the Guix data service to determine what's changed between
two revisions can't handle with two packages having the same name. It's
been fixed now, but there were two definitions of the r-dnacopy package.

> So I would think that you only need to check the status of these 4 jobs,
> no?  What would you need to ask

Yeah, knowing what the after effect of the patches are is pretty useful,
but I think that being able to compare the before and after state would
give an even more complete picture.

Consider if a patch affects 10 packages, and with that patch, 6 of the
ten affected packages fail to build. If previously all 10 of those
packages build successfully, then maybe this patch is a bit of a step
backwards. However, if previously all 10 of these packages failed to
build, then this patch is a definite improvement.

So, I think it would be useful to gather the information from about what packages have built and failed to build so that
this can be used to reveal more about the effect of patches.

> Going forward, I agree with Ricardo that we could start running all this
> on, whenever you think is the right time.  I guess we could
> start with the Guix Data Service, which is already useful in itself.

Great, I'm not sure it's quite ready yet, but I think setting up the
Guix Data Service as more of a proper thing would be a good step



Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]