Project

General

Profile

Bug #16819

Bug #16281: Update the test suite for Buster

Failing scenario: Recovering in offline mode after Additional Software previously failed to upgrade and then succeed to upgrade when online

Added by hefee 3 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Test suite
Target version:
Start date:
Due date:
% Done:

100%

Feature Branch:
test/16819-buggy-asp-step
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Additional Software Packages

Description

The Scenario "Recovering in offline mode after Additional Software previously failed to upgrade and then succeed to upgrade when online" is failing everytime.

The video shows at 101:10 "Additional software installed successfully" notification instead of "The upgrade of your additional software failed" notification. This indicates that the code is broken, that should be tested.

Associated revisions

Revision 580e9d83 (diff)
Added by intrigeri 3 months ago

Test suite: don't rely on mtimes from Debian packages we download, to indicate which one has the biggest version (refs: #16819).

These mtimes are copied from the HTTP server where APT downloads packages from.

In "Scenario: Recovering in offline mode after Additional Software previously
failed to upgrade and then succeed to upgrade when online", after we've done "I
prepare the Additional Software upgrade process to fail", the APT cache on
Buster has:

rw-r--r- 1 root root 20296 Apr 1 2018 cowsay_3.03+dfsg2-1_all.deb
rw-r--r- 1 root root 20856 Feb 5 01:06 cowsay_3.03+dfsg2-6_all.deb

… and we want the dpkg hook installed by this step to delete the one with the
largest version number, i.e. cowsay_3.03+dfsg2-6.

But the previous code, based on "ls -tr1 | head -n 1" would delete the file with
the oldest mtime (cowsay_3.03+dfsg2-1) when run on Buster, instead of
cowsay_3.03+dfsg2-6, so the upgrade we wanted to make fail succeeds,
and in turn this step fails:

I see the "The upgrade of your additional software failed" notification after at most 300 seconds

FWIW, I think the previous code happened to work on Stretch merely because the
mtime of cowsay_3.03+dfsg2-1_all.deb in our custom APT repo was newer than the
one of Stretch's 3.03+dfsg2-3, since we had uploaded it at a later time.
But if a 3.03+dfsg2-3+deb9u1 was ever released, if my hypothesis is correct,
this test would start failing on Stretch in the exact same way.

Let's not rely on such mtimes and instead, use ls' ability to sort
by version number, to pick the biggest one.

Revision a22222cc
Added by intrigeri 3 months ago

Merge branch 'test/16819-buggy-asp-step' into feature/buster

Closes: #16819

History

#1 Updated by intrigeri 3 months ago

  • Assignee set to intrigeri

It's a really corner-corner case, so what I see as a blocker for 4.0~beta1 is "make sure current buggy behavior is not dangerous". I'll do that. Then we can fix the bug in beta2 or something.

#2 Updated by intrigeri 3 months ago

  • Affected tool set to Additional Software Packages

#3 Updated by intrigeri 3 months ago

  • Category set to Test suite
  • Status changed from Confirmed to In Progress

This scenario manages to upgrade cowsay to 3.03+dfsg2-6 despite "I prepare the Additional Software upgrade process to fail". That's because that step is buggy: ls -tr1 /var/cache/apt/archives/cowsay*.deb | head -n 1 prints /var/cache/apt/archives/cowsay_3.03+dfsg2-1_all.deb, i.e. the oldest (in terms of mtime) cowsay binary package in the APT cache, instead of "the newest cowsay package from the APT cache", which would be cowsay_3.03+dfsg2-6_all.deb.

At this point of the scenario, said APT cache has:

-rw-r--r-- 1 root root 20296 Apr  1  2018 cowsay_3.03+dfsg2-1_all.deb
-rw-r--r-- 1 root root 20856 Feb  5 01:06 cowsay_3.03+dfsg2-6_all.deb

This code happens to work on Stretch because the mtime of cowsay_3.03+dfsg2-1_all.deb in our custom APT repo is newer than the one of Stretch's 3.03+dfsg2-3.

#4 Updated by intrigeri 3 months ago

  • Parent task set to #16281
  • Feature Branch set to test/16819-buggy-asp-step

#5 Updated by intrigeri 3 months ago

  • Status changed from In Progress to Needs Validation
  • Assignee deleted (intrigeri)

This scenario passes for me locally on this branch.

#6 Updated by hefee 3 months ago

  • Assignee set to hefee

#7 Updated by hefee 3 months ago

  • Status changed from Needs Validation to In Progress
  • Assignee changed from hefee to intrigeri

Seems fine.

#8 Updated by intrigeri 3 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF