Project

General

Profile

Bug #16634

Build patched VeraCrypt packages for buster

Added by segfault 5 months ago. Updated 2 months ago.

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

100%

Feature Branch:
bugfix/16634-build-patched-veracrypt
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

In buster we need custom packages for:

  • gnome-shell: Patches released in 3.33.2, buster has 3.30.2
  • gtk: Not all patches merged yet, will not make it into Buster
  • gjs: depends on gtk
  • gvfs: The latest of our patches was released in 1.39.1, Buster has 1.38.1

We don't need custom packages anymore for:

  • glib: VeraCrypt patch was released in 2.57.2, Buster has 2.58.3
  • udisks2: last VeraCrypt patch released in 2.8.1, which is the version in Buster
  • gnome-disk-utility: VeraCrypt patch was released in 3.29.2 , Buster has 3.30.2. We submitted another commit in the context of #15952 to add a tooltip to the keyfile chooser button, which was only released in 3.31.90. But intrigeri wrote on #15952 that we don't need to backport this patch (except if the tests turn out to be fragile, which I assume they are not, because intrigeri didn't reopen the ticket)
  • gobject-introspection: This was only required because we rebuilt glib. I thought it would also depend on gtk, but that does not seem to be the case.

Related issues

Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed 03/22/2019

Associated revisions

Revision 461c1397 (diff)
Added by segfault 5 months ago

Enable the bugfix-16634-build-patched-veracrypt APT overlay (refs: #16634).

Revision 8ee56bfd (diff)
Added by intrigeri 2 months ago

Test suite: update fuzzy images for Buster (refs: #16634).

Revision fb169ca1
Added by intrigeri 2 months ago

Merge branch 'bugfix/16634-build-patched-veracrypt' into feature/buster (Closes: #16634)

History

#1 Updated by segfault 5 months ago

  • Feature Branch set to bugfix/16634-build-patched-veracrypt

#2 Updated by segfault 5 months ago

#3 Updated by segfault 5 months ago

In buster we need custom packages for:

  • gnome-shell: Patches not merged yet, will not make it into Buster
  • gtk: Not all patches merged yet, will not make it into Buster
  • gjs: depends on gtk

We don't need custom packages anymore for:

  • glib: VeraCrypt patch was released in 2.57.2, Buster has 2.58.3
  • gvfs: The latest of our patches was released in 1.38.1, which is the version currently in Buster
  • udisks2: last VeraCrypt patch released in 2.8.1, which is the version in Buster
  • gnome-disk-utility: VeraCrypt patch was released in 3.29.2 , Buster has 3.30.2. We submitted another commit in the context of #15952 to add a tooltip to the keyfile chooser button, which was only released in 3.31.90. But intrigeri wrote on #15952 that we don't need to backport this patch (except if the tests turn out to be fragile, which I assume they are not, because intrigeri didn't reopen the ticket)
  • gobject-introspection: This was only required because we rebuilt glib. I thought it would also depend on gtk, but that does not seem to be the case.

#4 Updated by intrigeri 5 months ago

In buster we need custom packages for: […]
We don't need custom packages anymore for: […]

Great! Having to maintain only 3 custom packages during the 4.x cycle seems quite tractable.

#5 Updated by segfault 5 months ago

I built the packages for gtk and gjs today. I want to wait a bit to see if there is more progress on the gnome-shell MR before I backport that. And once I did that I will test the three packages together (gnome-shell depends on gjs and gtk) and then upload them.

#6 Updated by segfault 5 months ago

  • Status changed from Confirmed to In Progress

#7 Updated by segfault 3 months ago

Our gnome-shell patches were merged. I will backport the patches to the version in Buster and build and release them. I hope that I won't have to do that often before the Tails 4.0 release, I'm a bit worried about that because there have already been 3 migrations of gnome-shell to Buster since the full freeze (see https://tracker.debian.org/pkg/gnome-shell).

#8 Updated by segfault 3 months ago

I tested the packages by installing them in a feature/buster VM. The gnome-shell unlock dialog doesn't open. Still have to figure out why.

#9 Updated by segfault 3 months ago

  • Description updated (diff)

Above I wrote that we wouldn't have to patch gvfs anymore, but I was wrong, our latest patch was only released in 1.39.1 and Buster has 1.38.1. Updated the description accordingly.

#10 Updated by segfault 3 months ago

I'm not sure why, but with the patched gvfs installed, the gnome-shell dialog opens. I fixed another issue with the gnome-shell patches and now everything seems to work. Releasing the packages now.

#11 Updated by segfault 3 months ago

I released and uploaded gnome-shell 3.30.2-9.0tails1 and pushed a new branch tails/buster to the existing gnome-shell repository on git.tails.boum.org.

@intrigeri: do you prefer it if I continue using my personal packaging repositories on gitlab.com for the other packages or can I create repositories for them on git.tails.boum.org as well?

#12 Updated by intrigeri 3 months ago

intrigeri: do you prefer it if I continue using my personal packaging repositories on gitlab.com for the other packages or can I create repositories for them on git.tails.boum.org as well?

Now that it's clear that we'll have to maintain these patched packages for 2 more years (Tails 4.x), it would be much better to have the packaging live in some place where all Tails commiters have access, instead of just one person. git.tails.b.o is OK (that's where most of our code currently lives) but given our plans to migrate to GitLab, I'd rather create these new repos directly under https://salsa.debian.org/tails-team/ (optimistically assuming we'll settle on Salsa is our GitLab instance of choice) instead of adding more and more repos to the list of those we'll want to migrate later. Happy to do whichever you prefer, just tell me :)

#13 Updated by segfault 3 months ago

intrigeri wrote:

I'd rather create these new repos directly under https://salsa.debian.org/tails-team/ (optimistically assuming we'll settle on Salsa is our GitLab instance of choice) instead of adding more and more repos to the list of those we'll want to migrate later. Happy to do whichever you prefer, just tell me :)

Agreed, let's use GitLab. Thanks!

#14 Updated by intrigeri 3 months ago

Agreed, let's use GitLab. Thanks!

If you are not allowed to created the repos yourself, please give me a list of package names and I'll create them.

#15 Updated by segfault 2 months ago

intrigeri wrote:

If you are not allowed to created the repos yourself, please give me a list of package names and I'll create them.

That's gtk, gvfs, and gjs. I created a repo for gtk but I'm not allowed to push to it, it's rejected because there is no master branch and I'm not allowed to create one. Also, I would prefer to fork the existing Debian packaging repos via Gitlab, but I'm not allowed to fork them into the tails-team namespace.

#16 Updated by segfault 2 months ago

Rebuilt and released gvfs because debian/1.38.1-5 was released (previous build was based on debian/1.38.1-3).

I now forked the Debian packaging repos for gtk3, gjs, and gvfs into my own namespace (segfault-guest) and pushed the tags there. @intrigeri: You should be able to just fork my repos into the tails-team namespace.

#17 Updated by segfault 2 months ago

Uploading the gtk3 .changes file fails with "Cannot put file 'libgtk-3-0-udeb_3.24.5-1.0tails1_amd64.udeb' of 'gtk+3.0_3.24.5-1.0tails1_amd64.changes' into component 'main', as it is not listed in UDebComponents of 'bugfix-16634-build-patched-veracrypt'". intrigeri, I assume that you worked around this issue when you uploaded the old gtk3 package, which also included a udeb. I don't see a UDebComponents field anywhere in @conf/distributions, so I guess that's not the workaround you chose.

#18 Updated by intrigeri 2 months ago

Uploading the gtk3 .changes file fails with "Cannot put file 'libgtk-3-0-udeb_3.24.5-1.0tails1_amd64.udeb' of 'gtk+3.0_3.24.5-1.0tails1_amd64.changes' into component 'main', as it is not listed in UDebComponents of 'bugfix-16634-build-patched-veracrypt'". intrigeri, I assume that you worked around this issue when you uploaded the old gtk3 package, which also included a udeb. I don't see a UDebComponents field anywhere in conf/distributions, so I guess that's not the workaround you chose.

Indeed, you need to remove the udebs from the .changes file before uploading.

#19 Updated by intrigeri 2 months ago

I created a repo for gtk but I'm not allowed to push to it, it's rejected because there is no master branch and I'm not allowed to create one.

OK, deleted this repo (and the empty gjs one).

Also, I would prefer to fork the existing Debian packaging repos via Gitlab

Same.

#20 Updated by intrigeri 2 months ago

I now forked the Debian packaging repos for gtk3, gjs, and gvfs into my own namespace (segfault-guest) and pushed the tags there. intrigeri: You should be able to just fork my repos into the tails-team namespace.

I'd rather fork the GNOME team's repos so the forks graph is cleaner (and then you can probably drop your own forks). I'll do that and push your tags/code to our fork.

#21 Updated by intrigeri 2 months ago

intrigeri wrote:

I'd rather fork the GNOME team's repos so the forks graph is cleaner (and then you can probably drop your own forks). I'll do that and push your tags/code to our fork.

Done! You should have push access (at least to existing branches) on these new repos.

#22 Updated by segfault 2 months ago

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

intrigeri wrote:

Done! You should have push access (at least to existing branches) on these new repos.

Thanks! I deleted my personal repos.

I uploaded all packages now. FTR, to upload GTK I had to delete the udeb entries and resign the .changes file.

I built the feature branch and the VeraCrypt feature seems to work.

#23 Updated by intrigeri 2 months ago

@segfault, can you please merge current feature/buster into the topic branch, so that Jenkins can build it? (Currently it fails when it tries to merge devel into your branch, and that merge conflict was resolved in feature/buster already.)

#24 Updated by segfault 2 months ago

intrigeri wrote:

@segfault, can you please merge current feature/buster into the topic branch, so that Jenkins can build it? (Currently it fails when it tries to merge devel into your branch, and that merge conflict was resolved in feature/buster already.)

Done

#25 Updated by intrigeri 2 months ago

  • Assignee set to intrigeri

#26 Updated by intrigeri 2 months ago

  • Status changed from Needs Validation to In Progress

I see a scenario failing (https://jenkins.tails.boum.org/view/Tails_ISO/job/test_Tails_ISO_bugfix-16634-build-patched-veracrypt/1/cucumberTestReport/using-veracrypt-encrypted-volumes/use-unlock-veracrypt-volumes-to-unlock-a-hidden-veracrypt-file-container/). The screenshot looks like everything is working well. The image Sikuli fails to find is fuzzy in other scenarios (that pass) anyway so I'll update it and we'll see.

#27 Updated by intrigeri 2 months ago

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

Also available in: Atom PDF