[Re-sending as the autopkgtest list on Alioth has ceased to exist. Sorry
for the dup.]
Hi Niels,
On 15-04-18 12:50, Niels Thykier wrote:
> Ok, a few remarks:
>
>
> AutopkgtestPolicy.__init__:
>> self.pending_tests_file = os.path.join(self.options.state_dir, 'pending.json')
>> self.results_cache_file = os.path.join(self.options.state_dir, 'results.cache')
>
> The basenames ("pending.json" and "results.cache") are rather generic
> and state_dir is reused between all policies. I think we should
> namespace these files somehow (E.g. either put them in a subdir or name
> them "autopkgtests-<original-name>").
I am not at all attached to the names. They come straight from the
Ubuntu code, so I see no problem changing them.
> AutopkgtestPolicy.apply_policy_impl:
>> # Keep track if this source package has tests of its own for the
>> # bounty system, but only if at least one arch has something else than
>> # running or alwaysfail
>> if testsrc == source_name and r - {'RUNNING', 'RUNNING-ALWAYSFAIL', 'ALWAYSFAIL'}:
>> src_has_own_test = True
>
> How difficult would it be to make the bouncy only apply if the tests are
> successful on all architectures (i.e. no "ALWAYSFAIL")? If it is a
> trivial matter, then I would prefer to only give bonus to packages that
> are a good example on all architectures.
I'll think about it. I don't know by heart. I expect this to be no
problem. Please be aware though that currently ci.debian.net only runs
amd64. I don't know the details of what would be needed to add other
architectures, but I expect that to be: hardware. ci.debian.net
currently runs on Amazon EC2 instances, I think there is no other
hardware available there. We had some arm flavor in the past, but I
believe that couldn't keep up or the setup was buggy, or something. In
principle this is no issue, and there have been hardware offers. They
just haven't materialized.
> AutopkgtestPolicy.tests_for_source:
>> # Hardcode linux-meta → linux, lxc, glibc, systemd triggers until we get a more flexible
>> # implementation: https://bugs.debian.org/779559
>> if src.startswith('linux-meta'):
>> for pkg in ['lxc', 'lxd', 'glibc', src.replace('linux-meta', 'linux'), 'systemd', 'snapd']:
>> if pkg not in reported_pkgs:
>> # does this have any image on this arch?
>> for pkg_id in srcinfo.binaries:
>> if pkg_id.architecture == arch and '-image' in pkg_id.package_name:
>> try:
>> tests.append((pkg, self.britney.sources['unstable'][pkg].version))
>> except KeyError:
>> try:
>> tests.append((pkg, sources_info[pkg].version))
>> except KeyError:
>> # package not in that series? *shrug*, then not
>> pass
>> break
>
> Is this piece still relevant? AFAICT, #779559 is fixed in stable. (I
> admit having a feeling of deja vu about this - apologies if I asked
> about this case earlier and simply forgot the answer).
Coincidentally, I investigated last night and removed the code already
locally. Debian doesn't even have a linux-meta package, that is
something Ubuntu specific. In my opinion, the Ubuntu linux-meta package
should just start do the right thing now.
> Beyond that: I also committed some changes for some nits things I
> discovered while reviewing the code.
Ack. And thanks for those. I am not fluent yet in Python to catch any of
these issues.
>> Secondly, assuming we can come to deployment of the new britney policy,
>> I started a gobby document³ to draft an announcement to d-d-a.
[...]
> My "quick" fix would be removing the emphasis and inject a bit longer
> explanation:
> """
> There is one important note to make here on how to go about regressions
> in test cases from reverse dependencies. We recommend communication
> between the maintainers of the involved packages as one party has
> insight in what changed and the other party insight in what is being
> tested. More information is available in the britney documentation
> [britney].
> """
Ack, will take over.
> On another note: Would you be open for getting hint permissions for
> dealing with autopkgtest policy issues (at least in the initial phase of
> the deployment)?
I recon you already know the answer: yes.
I have an additional note. There is one commit to debci pending review
and deployment that I like to get landed before going live with the
official britney checking autopkgtest: the retrigger link currently only
works with a POST http request with a special debci key; the commit will
add a functional GET request option and optionally works with Debian SSO
certificates. Apart from that, my experience over the last week is very
positive. Just for reference, I started collecting relevant bugs in the
bts with the ci-team@tracker.debian.org user¹ in the bts (bunk and
ginggs added a couple using the right usertags as well).
Paul
¹
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=ci-team@tracker.debian.org
Attachment:
signature.asc
Description: OpenPGP digital signature