Feature #15522

Iteration 1: Create custom Debian package for udisks

Added by segfault 2018-04-11 10:18:55 . Updated 2018-08-09 10:38:00 .

Status:
Resolved
Priority:
High
Assignee:
Category:
Target version:
Start date:
2018-04-11
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:
299

Description

I backported our udisks patches to the udisks version in Stretch (see Feature #15253).

Packaging repository: https://gitlab.com/segfault3/tails-packaging-udisks

Upstream-based repository: https://github.com/segfault3/udisks-debian
Branch: 2.1.8-support-tcrypt


Subtasks


Related issues

Blocked by Tails - Feature #15253: Iteration 1: Backport support for unlocking VeraCrypt partitions to udisks in Stretch Resolved 2018-01-25

History

#1 Updated by segfault 2018-04-11 12:48:47

  • Deliverable for set to 299

#2 Updated by segfault 2018-04-15 12:14:48

  • Description updated
  • Assignee changed from segfault to anonym
  • % Done changed from 0 to 30
  • QA Check set to Ready for QA

I added our patches using gbp pq and was able to build packages using gbp buildpackage. The build command fails with an error because I don’t have the correct signing key, but the packages are still created in the parent directory.

#3 Updated by segfault 2018-04-15 12:21:17

  • Description updated

#4 Updated by intrigeri 2018-04-15 13:00:27

  • blocked by Feature #15253: Iteration 1: Backport support for unlocking VeraCrypt partitions to udisks in Stretch added

#5 Updated by intrigeri 2018-04-15 13:00:47

  • Status changed from Confirmed to In Progress

#6 Updated by Anonymous 2018-04-16 14:50:38

segfault wrote:
> I added our patches using gbp pq and was able to build packages using gbp buildpackage. The build command fails with an error because I don’t have the correct signing key, but the packages are still created in the parent directory.

Cool. Before launching the build you might want to do

dch -i

This will create a new version of the package - and that’s what we want.
(dch -i increments debian/changelog.)
Here, you can add a note about what you did and use your own name and signing key.
And you should use a new version number in there. For example, the current version is : 2.7.6-2 (corresponding to the branch or tag you used as a base for your own build) and then your version should probably be 2.7.6-2tails1
-> this ensures that any version with the number 2.7.6-3 from Debian would be considered newer than this one and it encodes the version you are building upon.

#7 Updated by segfault 2018-04-16 18:08:58

u wrote:
> segfault wrote:
> > I added our patches using gbp pq and was able to build packages using gbp buildpackage. The build command fails with an error because I don’t have the correct signing key, but the packages are still created in the parent directory.
>
> Cool. Before launching the build you might want to do
>
> […]
>
> This will create a new version of the package - and that’s what we want.
> (dch -i increments debian/changelog.)
> Here, you can add a note about what you did and use your own name and signing key.
> And you should use a new version number in there. For example, the current version is : 2.7.6-2 (corresponding to the branch or tag you used as a base for your own build) and then your version should probably be 2.7.6-2tails1
> -> this ensures that any version with the number 2.7.6-3 from Debian would be considered newer than this one and it encodes the version you are building upon.

That’s helpful, thanks!

#8 Updated by intrigeri 2018-05-07 14:06:05

  • Target version changed from Tails_3.7 to Tails_3.8

#9 Updated by intrigeri 2018-05-21 14:07:19

  • Assignee changed from anonym to segfault

I think you should not block on anonym for this. If you need help / uploads, ask me (or possibly u if she’s fine with that).

#10 Updated by intrigeri 2018-06-03 11:39:43

  • QA Check changed from Ready for QA to Dev Needed

I did a first review on Feature #14481.

#11 Updated by intrigeri 2018-06-03 17:53:29

My review will appear on Feature #15521 soon and a tiny bit of dev will be needed.

#12 Updated by intrigeri 2018-06-04 19:35:26

  • Target version changed from Tails_3.8 to Tails_3.9

This can (and should) wait post-3.8.

#13 Updated by intrigeri 2018-07-07 09:48:11

  • % Done changed from 30 to 50

I think the only remaining thing here is to update the package for https://gitlab.com/segfault3/tails-packaging-udisks/commit/6a3f6424b0b636a0238eca99a4697bcf535d7a3c. Maybe we should do this for the beta? (I’m reluctant to add new blockers at this point but it would feel silly to ship something that UX testing has identified as buggy, when we already have a bugfix ready :)

Once this is done, let’s close this ticket as resolved and if Feature #14480 or Feature #15589 bring more needed changes, we’ll track this on the parent ticket (Feature #15521).

#14 Updated by intrigeri 2018-07-09 09:38:23

  • blocks Feature #14481: Release Beta for VeraCrypt support in Tails added

#15 Updated by intrigeri 2018-07-09 09:42:04

intrigeri wrote:
> I think the only remaining thing here is to update the package for https://gitlab.com/segfault3/tails-packaging-udisks/commit/6a3f6424b0b636a0238eca99a4697bcf535d7a3c. Maybe we should do this for the beta? (I’m reluctant to add new blockers at this point but it would feel silly to ship something that UX testing has identified as buggy, when we already have a bugfix ready :)

segfault already did his part of the work. If I have time to upload the new package in time for the beta, I will. Otherwise, no big deal. Please reassign to me once the source package is available.

#16 Updated by intrigeri 2018-07-09 09:42:11

  • blocked by deleted (Feature #14481: Release Beta for VeraCrypt support in Tails)

#17 Updated by segfault 2018-07-09 10:43:37

  • Description updated
  • Assignee changed from segfault to intrigeri
  • QA Check changed from Dev Needed to Ready for QA

intrigeri wrote:
> Please reassign to me once the source package is available.

It’s already available. I updated the links in the description.

#18 Updated by intrigeri 2018-07-10 09:24:33

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

Uploaded, thanks!

#19 Updated by segfault 2018-07-10 13:03:44

  • Status changed from Resolved to In Progress
  • Assignee set to intrigeri
  • QA Check changed from Pass to Ready for QA

I think we also have to upload gnome-disk-utiliy 3.22.1-1.0tails2, because the current version still has the strict dependency on udisks 2.1.8-1tails1, which is now not available anymore.

#20 Updated by intrigeri 2018-07-10 13:20:02

segfault wrote:
> I think we also have to upload gnome-disk-utiliy 3.22.1-1.0tails2, because the current version still has the strict dependency on udisks 2.1.8-1tails1

3.22.1-1.0tails1 in our archive Build-Depends: libudisks2-dev (>= 2.1.8-1.0tails1) and Depends: libudisks2-0 (>= 2.1.1). I think I’ve had to fix the build-dep during the 1st round (my bad for not having bumped the version, see: it’s already causing confusion and wasted time). And the dependency for the binary package is not hard-coded in debian/control, instead it’s computed at build time (${shlibs:Depends}) and for some reason (outdated .symbols file?) dh_shlibdeps, or whatever handles this, did not notice there’s a runtime dependency on newer symbols that udisks2 2.1.1 has not. Which means it’s technically possible to install a broken combination of packages. Anyway, let’s not bother: if the ISO builds we’re fine, and once all this makes it into new upstream releases, the Debian maintainers will have to sort out the new symbols and versioned deps anyway. I’ll keep this on my plate to check that the ISO does build fine and then I’ll let you verify that GNOME Disks works as expected.

#21 Updated by intrigeri 2018-07-10 13:21:36

intrigeri wrote:
> 3.22.1-1.0tails1 in our archive Build-Depends: libudisks2-dev (>= 2.1.8-1.0tails1) and Depends: libudisks2-0 (>= 2.1.1). I think I’ve had to fix the build-dep during the 1st round

And indeed, debdiff gnome-disk-utility_3.22.1-1.0tails1.dsc gnome-disk-utility_3.22.1-1.0tails2.dsc (the 1st one being the one I’ve uploaded a while ago and the latter one being yours that I just downloaded) only shows changes in debian/changelog.

#22 Updated by segfault 2018-07-10 13:29:38

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

intrigeri wrote:
> intrigeri wrote:
> > 3.22.1-1.0tails1 in our archive Build-Depends: libudisks2-dev (>= 2.1.8-1.0tails1) and Depends: libudisks2-0 (>= 2.1.1). I think I’ve had to fix the build-dep during the 1st round
>
> And indeed, debdiff gnome-disk-utility_3.22.1-1.0tails1.dsc gnome-disk-utility_3.22.1-1.0tails2.dsc (the 1st one being the one I’ve uploaded a while ago and the latter one being yours that I just downloaded) only shows changes in debian/changelog.

Ah, ok, then I’m rebasing my gnome-disk-utiltiy 3.22.1-1.0tails1 on the one you uploaded.

#23 Updated by intrigeri 2018-08-09 10:38:00

  • Priority changed from Normal to High

(To raise priority of the parent ticket, that blocks merging feature/14481-TCRYPT-support-beta into devel.)