Bug #17556

whisperback: double check packaging

Added by CyrilBrulebois 2020-03-26 00:30:19 . Updated 2020-03-26 20:01:30 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Checking my 1.8.2 whisperback upload, I’ve compared it to the existing 1.8.1.

Changes and comments (lines reordered for clarity):

kibi@armor:~/work/clients/tails$ debdiff whisperback_1.8.*dsc
 .gitignore                  |    2 --

I've used -i/-I for the upload from git.

 debian/changelog            |    6 ++++++

New changelog entry.

 data/whisperback.desktop.in |    2 +-
 doc/whisperback.t2t         |    2 +-
 setup.py                    |    2 +-
 whisperBack/gui.py          |    2 +-

Version number update.

 po/fr.po                    |    4 ++--
 po/hu.po                    |   72 ++++++++++++++++++++++++++++++++++++++++++------------------------------

Actual changes.

 8 files changed, 54 insertions(+), 38 deletions(-)

which seems rather good and expected.

But I’m a little concerned with this change on the binary side, having built the package on Stretch:

Postinst files: lines which differ (wdiff format)
-------------------------------------------------
[-if which pypy3compile >/dev/null 2>&1; then-]
[-  pypy3compile -p whisperback  || true-]
[-fi-]

Could those missing lines do any harm?

Would it be appropriate to bump the requirements (like building on Buster, and/or updated/versioned Build-Depends)?


Subtasks


History

#1 Updated by intrigeri 2020-03-26 08:32:20

Hi,

to clarify:

  • I know you’re running Stretch.
  • Did you build using pbuilder/sbuild in a Buster chroot, or? If not, we should indeed document the requirement to build in a chroot for whatever Debian release Tails is currently based on.

#2 Updated by CyrilBrulebois 2020-03-26 09:29:12

No, I did not use any chroots.

Personal backstory: I had just tried to deal with tails-installer (refs: Bug #17553), which was pretty emphatic about trying to accomodate a wide range of Debian distributions. And since I don’t recall seeing any requirements regarding buiding in a chroot or in any particular environment, I didn’t do that.

HACKING also kind of focuses on manual things, rather than suggesting a “use cowbuilder/sbuild/whatever as usual” approach.

#3 Updated by CyrilBrulebois 2020-03-26 09:37:34

Rebuilding the package in Buster, I’m also remembering that: The lack of a need to catch up with Buster was also reinforced by the dependency on debhelper (>= 7.0.50~), which is deprecated in Buster…

#4 Updated by intrigeri 2020-03-26 09:45:38

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|bfedb3a69035687608a7b99a8e9514ea31d7f945.

#5 Updated by intrigeri 2020-03-26 09:46:20

  • Status changed from In Progress to Needs Validation
  • Assignee set to CyrilBrulebois

Understood.

Please review commit:bfedb3a69035687608a7b99a8e9514ea31d7f945 :)

#6 Updated by intrigeri 2020-03-26 09:49:27

> Rebuilding the package in Buster, I’m also remembering that: The lack of a need to catch up with Buster was also reinforced by the dependency on debhelper (>= 7.0.50~), which is deprecated in Buster…

Right.

FTR I’ve not put much effort into updating the packaging lately because it’ll go away soonish (Feature #16936, one of the last 2 steps of Feature #7036, on which segfault and I made great progress in the last 6 months or so).

#7 Updated by CyrilBrulebois 2020-03-26 09:50:41

Leaving that bug open, so that we have a chance of updating the packaging and/or documentation.

In the meanwhile, I’ve removed the previously-uploaded package from the testing distribution by using a manual reprepro remove testing whisperback command, and re-uploaded a package rebuilt in a buster chroot, which should fix the immediate issue (releasing 4.5~rc1).

Except I don’t see the whisperback package getting added back into the testing distribution, so I suspect re-using a package version isn’t OK.

I guess I’ll have to prepare a no-change 1.8.3 version instead.

Poking @anonym for confirmation on that topic (in addition to Bug #17557).

#8 Updated by intrigeri 2020-03-26 10:01:33

> so I suspect re-using a package version isn’t OK.

Indeed, it’s not OK.

> I guess I’ll have to prepare a no-change 1.8.3 version instead.

I think so.

#9 Updated by CyrilBrulebois 2020-03-26 10:29:09

  • Assignee deleted (CyrilBrulebois)

The whisperback package is back in the testing repository (1.8.3).

#10 Updated by CyrilBrulebois 2020-03-26 20:01:30

  • Status changed from Needs Validation to Resolved

Thanks intrigeri, reviewed when merging master@ into testing, looking good.