Feature #14481

Release Beta for VeraCrypt support in Tails

Added by segfault 2017-08-28 15:53:30 . Updated 2018-07-11 17:09:17 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Target version:
Start date:
2017-12-10
Due date:
% Done:

100%

Feature Branch:
feature/14481-TCRYPT-support-beta
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:
299

Description


Subtasks


Related issues

Related to Tails - Feature #15521: Iteration 1: Create Debian packages to ship our VeraCrypt patches in Tails 3.9 Resolved 2018-04-11

History

#1 Updated by intrigeri 2017-08-28 16:48:19

  • Assignee set to segfault
  • Target version set to Tails_3.9
  • Deliverable for changed from 304 to 299

#2 Updated by sajolida 2017-09-06 16:28:44

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

After our last discussion I wrote the beta for around June 1 which is before 3.7 and not 3.8.

#3 Updated by sajolida 2017-09-06 16:41:21

  • Due date set to 2017-06-01
  • Start date deleted (2017-08-28)

#4 Updated by sajolida 2017-09-06 16:41:32

  • Due date changed from 2017-06-01 to 2018-06-01

#5 Updated by intrigeri 2017-09-29 17:29:43

  • blocks Feature #14477: User testing and community feedback for VeraCrypt support added

#6 Updated by intrigeri 2017-09-29 17:30:40

  • blocked by deleted (Feature #14477: User testing and community feedback for VeraCrypt support)

#7 Updated by intrigeri 2017-09-29 17:30:47

#8 Updated by segfault 2018-05-24 15:39:28

  • blocked by Bug #15618: Build fails if `config/chroot_local-packages` contains packages added

#9 Updated by intrigeri 2018-05-24 16:46:18

> Blocked by Bug Bug #15618: Build fails if `config/chroot_local-packages` contains packages added

Once your packages are ready and reviewed (possibly by myself) I’m happy to upload them to your branch’s APT overlay suite so I don’t think this relationship reflects the real state of things. In any case we won’t merge a branch that has packages in there so the beta would not be built from such a branch.

Now, I understand that Bug #15618 makes it harder for you to test your packages in the context of Tails. The best you can do is probably to dpkg -i them in a running Tails. Sorry about that!

#10 Updated by segfault 2018-05-24 16:52:03

  • blocks deleted (Bug #15618: Build fails if `config/chroot_local-packages` contains packages)

#11 Updated by segfault 2018-05-24 16:57:24

> Once your packages are ready and reviewed (possibly by myself) I’m happy to upload them to your branch’s APT overlay suite so I don’t think this relationship reflects the real state of things. In any case we won’t merge a branch that has packages in there so the beta would not be built from such a branch.

Ok. Btw, I can’t find the git repository containing the source of the Tails custom packages, for example glib (2.50.3-2.0tails1). I need this to include the Tails custom patches in my packages.

#12 Updated by intrigeri 2018-05-25 06:24:59

> I can’t find the git repository containing the source of the Tails custom packages, for example glib (2.50.3-2.0tails1). I need this to include the Tails custom patches in my packages.

In some cases, when the debdiff between the official Debian package and ours is tiny and self-contained, and we don’t expect to have to update it often, we don’t push such changes to Git and only upload the source + binary package to our custom APT repo. IIRC src:glib2.0 falls into this category. You can get it from our custom APT repo (apt-get source glib2.0 from a running Tails) and then import it into your Vcs-Git with gbp import-dsc in order to merge it with your own changes.

#13 Updated by segfault 2018-06-01 12:20:08

  • Assignee changed from segfault to intrigeri
  • Feature Branch set to segfault:feature/14481-TCRYPT-support-beta

I successfully built the Debian packages and tested them in Tails 3.7. The packages can be found here: https://gitlab.com/segfault3/tails-tcrypt-packages

I based the packages on the source packages which I downloaded via apt source in Tails 3.7. I then imported and applied my patches via quilt and built with pbuilder. For some packages I had to copy and install previously built packages in the pbuilder chroot environment (the ones in parentheses in the following list).

I built the packages in the following order:

  1. udisks, gtk, glib
  2. gnome-disk-utility (requires udisks)
  3. gvfs (requires udisks and glib)
  4. gobject-introspection (requires glib)
  5. gjs (requires gi and glib)
  6. gnome-shell (requires gjs and glib)

I noticed that some of the original packages in Tails have a +bN attached to the version string. I couldn’t figure out what that means - it is not included in the source package’s debian/changelog. But as a result, some packages are considered to be downgraded when the *tailsN version is installed. I’m not sure if that could cause any problems, but I guess it should be fine if the apt pinning is correct (see the feature branch).

I added a patch to gnome-shell to hide the PIM in the unlock dialog because of Bug #15630.

#14 Updated by intrigeri 2018-06-03 08:20:31

  • Assignee changed from intrigeri to segfault

> I noticed that some of the original packages in Tails have a +bN attached to the version string. I couldn’t figure out what that means - it is not included in the source package’s debian/changelog.

That’s called a binNMU in Debian i.e. a rebuild of the binary package without source changes. As long as uploads that change the source have a greater version than binNMUs (see below) that’s not a problem.

> But as a result, some packages are considered to be downgraded when the *tailsN version is installed.

This would not happen if your custom packages were using the .0tailsN suffix. I see you’ve done this correctly for gnome-shell but not for (most of?) the other packages.

> I’m not sure if that could cause any problems, but I guess it should be fine if the apt pinning is correct (see the feature branch).

Please drop this pinning once the version problem is fixed :)

In some cases you’ve pushed the modified source package you’ve built (e.g. https://gitlab.com/segfault3/tails-packaging-glib/blob/master/glib2.0_2.50.3-2.0tails1.dsc) but in some other cases you’ve pushed what looks like the original Debian one (e.g. https://gitlab.com/segfault3/tails-packaging-gnome-disk-utility/blob/master/gnome-disk-utility_3.22.1-1.dsc). What I need is the former, not the latter: to review this I want to run debdiff between the Debian’s .dsc file and yours. And in another case (https://gitlab.com/segfault3/tails-packaging-gnome-shell/blob/master/gnome-shell_3.22.3-3.0tails1.dsc) I’m not quite sure what you’ve uploaded since that’s the version we already have in Tails.

Other than these preliminary problems, I’ve had a very quick look at the packaging anyway in order to lower the number of round-trips we’ll go through:

Other than that, looks good!

#15 Updated by intrigeri 2018-06-03 08:32:56

  • Status changed from Confirmed to In Progress
  • QA Check set to Dev Needed

Wrt. commit c707d4f128821f402fc398085f3c227bb05575fc on the topic branch: I’m not convinced we should do this in the beta. It’s unclear yet what we’ll do in the final release so I’m not sure which case we should have the user testing test. I recommend discussing this with sajolida.

Wrt. “Associate .tc/.hc file extension with gnome-disk-image-mounter”: it would be nice if your commit referenced the corresponding ticket (Feature #15051).

#16 Updated by sajolida 2018-06-03 11:08:44

  • related to Feature #15628: Consider re-enabling automounting to improve VeraCrypt UX added

#17 Updated by sajolida 2018-06-03 11:10:08

Regarding c707d4f128821f402fc398085f3c227bb05575fc (and Feature #15628), I’ll test the behavior of the ISO image without both options and report on the difference in behavior before commenting on Feature #15628 because right now the different is not clear to me.

#18 Updated by intrigeri 2018-06-03 13:05:30

  • Priority changed from Normal to Elevated

#19 Updated by segfault 2018-06-03 14:44:21

intrigeri wrote:
> > I noticed that some of the original packages in Tails have a +bN attached to the version string. I couldn’t figure out what that means - it is not included in the source package’s debian/changelog.
>
> That’s called a binNMU in Debian i.e. a rebuild of the binary package without source changes. As long as uploads that change the source have a greater version than binNMUs (see below) that’s not a problem.
>
> > But as a result, some packages are considered to be downgraded when the *tailsN version is installed.
>
> This would not happen if your custom packages were using the .0tailsN suffix. I see you’ve done this correctly for gnome-shell but not for (most of?) the other packages.

Ah, I thought the suffix was only tailsN. I only accidentally did this correctly for the packages which already had this suffix, so I only had to increase the N. I’m fixing this now.

> > I’m not sure if that could cause any problems, but I guess it should be fine if the apt pinning is correct (see the feature branch).
>
> Please drop this pinning once the version problem is fixed :)

Ok.

> In some cases you’ve pushed the modified source package you’ve built (e.g. https://gitlab.com/segfault3/tails-packaging-glib/blob/master/glib2.0_2.50.3-2.0tails1.dsc) but in some other cases you’ve pushed what looks like the original Debian one (e.g. https://gitlab.com/segfault3/tails-packaging-gnome-disk-utility/blob/master/gnome-disk-utility_3.22.1-1.dsc).

In the separate packaging repositories I always included the packages I downloaded via apt source in Tails 3.7. You find all the modified packages in the https://gitlab.com/segfault3/tails-tcrypt-packages repository.

> Other than these preliminary problems, I’ve had a very quick look at the packaging anyway in order to lower the number of round-trips we’ll go through:
>
> * https://gitlab.com/segfault3/tails-packaging-gnome-disk-utility/tree/master/gnome-disk-utility-3.22.1/debian/patches has two patches but only one is applied by debian/patches/series. Clean up?

Done.

> * Please set the target distribution (in debian/changelog) to feature-14481-TCRYPT-support-beta so when I upload the resulting packages, they land in the right dist in our custom APT repo.
> * The changelog entry for https://gitlab.com/segfault3/tails-packaging-gobject-introspection/blob/master/gobject-introspection-1.50.0/debian/changelog is slightly misleading: please clarify that what this upload changes is “Require glib with TCRYPT support”.
> * More generally, a number of debian/changelog entries are a bit too terse: please document in more details what patches are added and what changes are done in the packaging.

Ok, I will fix the changelog entries now.

#20 Updated by segfault 2018-06-03 15:05:47

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

> Please drop this pinning once the version problem is fixed :)

Done (I removed the commit from the git history).

> Wrt. “Associate .tc/.hc file extension with gnome-disk-image-mounter”: it would be nice if your commit referenced the corresponding ticket (Feature #15051).

Done.

> Ok, I will fix the changelog entries now.

Done.

#21 Updated by intrigeri 2018-06-03 16:28:45

Wow, you’ve been fast, thank you so much!

#22 Updated by segfault 2018-06-03 16:31:34

I just finished building the updated packages and pushed them to https://gitlab.com/segfault3/tails-tcrypt-packages.

#23 Updated by intrigeri 2018-06-03 16:39:42

  • Assignee changed from intrigeri to segfault
  • % Done changed from 100 to 50
  • QA Check changed from Ready for QA to Dev Needed

segfault wrote:
> I just finished building the updated packages and pushed them to https://gitlab.com/segfault3/tails-tcrypt-packages.

Ah. I was just writing a comment saying I don’t see the updated source packages there. And I still don’t. Maybe your push failed?

(In the future, please assign tickets to QA for me only once everything I need to review is ready. This will avoid some round-trips and context switches :)

#24 Updated by intrigeri 2018-06-03 16:41:21

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

intrigeri wrote:
> segfault wrote:
> > I just finished building the updated packages and pushed them to https://gitlab.com/segfault3/tails-tcrypt-packages.
>
> Ah. I was just writing a comment saying I don’t see the updated source packages there. And I still don’t. Maybe your push failed?

Now (after yet another page reload) I can see them. Let’s assume your push was completed and blame GitLab web interface caching or something :)

#25 Updated by segfault 2018-06-03 16:43:01

intrigeri wrote:
> segfault wrote:
> > I just finished building the updated packages and pushed them to https://gitlab.com/segfault3/tails-tcrypt-packages.
>
> Ah. I was just writing a comment saying I don’t see the updated source packages there. And I still don’t. Maybe your push failed?

The push only finished a minute ago (seems like I was using a very slow circuit, it took 9 minutes).

> (In the future, please assign tickets to QA for me only once everything I need to review is ready. This will avoid some round-trips and context switches :)

Yeah, sorry, I only realized that I still need to rebuild the packages after I assigned it to you.

#26 Updated by intrigeri 2018-06-03 16:46:04

I won’t block on this for a beta that’ll explicitly be experimental but next time, please sign your .dsc files with debsign: it feels slightly uncomfortable to pull C code — that I can’t sensibly review — from the Internet without any end-to-end authentication+integrity.

#27 Updated by segfault 2018-06-03 16:52:28

I signed the files now

#28 Updated by intrigeri 2018-06-03 16:54:45

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

I think you forgot to update the version numbers for versioned dependencies in debian/control (at least for gnome-shell).

#29 Updated by segfault 2018-06-03 16:57:53

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

intrigeri wrote:
> I think you forgot to update the version numbers for versioned dependencies in debian/control (at least for gnome-shell).

I did bump the version in debian/control.in. I didn’t touch debian/control, which is autogenerated during build, and I didn’t mean to commit the current version, which indeed has the wrong version number. But that shouldn’t matter, because control.in is correct.

#30 Updated by intrigeri 2018-06-03 17:20:40

segfault wrote:
> intrigeri wrote:
> > I think you forgot to update the version numbers for versioned dependencies in debian/control (at least for gnome-shell).
>
> I did bump the version in debian/control.in. I didn’t touch debian/control, which is autogenerated during build, and I didn’t mean to commit the current version, which indeed has the wrong version number. But that shouldn’t matter, because control.in is correct.

OK. I got confused because https://gitlab.com/segfault3/tails-packaging-gnome-shell/blob/master/gnome-shell-3.22.3/debian/control definitely has Tails some version numbers (so somehow it’s been updated at some point and committed to Git) but they’re wrong. Anyway, indeed it should not matter so this is back on my plate!

#31 Updated by segfault 2018-06-03 17:23:55

> I got confused because https://gitlab.com/segfault3/tails-packaging-gnome-shell/blob/master/gnome-shell-3.22.3/debian/control definitely has Tails some version numbers (so somehow it’s been updated at some point and committed to Git) but they’re wrong.

Yes, I guess I inadvertently committed it with a git add -u when I updated the changelog.

#32 Updated by intrigeri 2018-06-03 17:28:11

Ooops, sorry I gave you wrong info: the target dist must be feature-14481-tcrypt-support-beta. I’ll patch the .changes files accordingly before uploading but please fix that if you need to update this packaging before the beta is out.

Also, from now on please don’t modify the packaging without bumping the version: assume that some of these packages may have already been uploaded.

#33 Updated by intrigeri 2018-06-03 17:39:16

I’m reviewing these packages now! I’ll post here about anything I consider to be a blocker for the beta (hopefully nothing); anything else will go on Feature #15521 & relevant subtasks.

#34 Updated by intrigeri 2018-06-03 18:00:46

Review posted there. I did not spot any blocker for the beta so I’ll now proceed with building and uploading the packages.

#35 Updated by segfault 2018-06-03 18:12:20

intrigeri wrote:
> Also, from now on please don’t modify the packaging without bumping the version: assume that some of these packages may have already been uploaded.

Can I still fix the changelog without bumping the version?

#36 Updated by intrigeri 2018-06-03 18:22:15

  • related to Feature #15521: Iteration 1: Create Debian packages to ship our VeraCrypt patches in Tails 3.9 added

#37 Updated by intrigeri 2018-06-03 18:25:16

> intrigeri wrote:
>> Also, from now on please don’t modify the packaging without bumping the version: assume that some of these packages may have already been uploaded.

> Can I still fix the changelog without bumping the version?

You can fix already released changelog entries (e.g. the ones you’ve added yourself or the older ones you’ve modified by mistake) but then you need to add a new changelog entry that documents the changes. What’s released is released and cannot be fixed without a time machine :)

#38 Updated by intrigeri 2018-06-03 18:31:41

intrigeri wrote:
> You can fix already released changelog entries (e.g. the ones you’ve added yourself or the older ones you’ve modified by mistake) but then you need to add a new changelog entry that documents the changes. What’s released is released and cannot be fixed without a time machine :)

And in any case, hold on until I’m done with building & uploading this first batch, or be ready to rebase your new work on top of what I’ve uploaded (in at least one case I had to fix the packaging that was FTBFS’ing).

#39 Updated by intrigeri 2018-06-03 19:40:02

  • % Done changed from 50 to 60
  • Feature Branch changed from segfault:feature/14481-TCRYPT-support-beta to feature/14481-TCRYPT-support-beta

Uploaded all the packages and enabled the overlay APT suite on the topic branch! The first build started after this was done was build 2 (https://nightly.tails.boum.org/build_Tails_ISO_feature-14481-tcrypt-support-beta/builds/). Ignore build 1, that was automatically started too early by Jenkins. I’ll keep an eye on it and will reassign to you, for the next steps of the beta release, once that build is finished.

#40 Updated by intrigeri 2018-06-03 20:34:46

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

Build 2 succeeded. Please check, test and if happy, give me the URL of the ISO you want to call beta, and I’ll copy it to the mirrors.

#41 Updated by segfault 2018-06-03 22:07:44

  • % Done changed from 60 to 50

Thanks. I took a quick look and already found issues which I will fix tomorrow. I’m so sorry and mad at myself to cause us both more work :(

#42 Updated by segfault 2018-06-04 14:07:50

I pushed a fix to my gvfs repo. Next step is to wait for sajolida’s input on Feature #15218 and Feature #15628.

#43 Updated by segfault 2018-06-04 23:28:48

  • Assignee changed from segfault to intrigeri

sajolida ACKed my modified unlock dialog message (Feature #15218), so I included it in gvfs and built a new package. I also fixed, in the feature branch, that the file extension association didn’t work. I don’t know yet what we should do about Feature #15628, but in any case it would be good if you would upload the new gvfs package and pull my branch, so that we have an ISO with those issues fixed.

#44 Updated by intrigeri 2018-06-05 08:46:21

> sajolida ACKed my modified unlock dialog message (Feature #15218), so I included it in my gvfs repo.

Great! I’ll look at it right now.

> I also fixed that the file extension association didn’t work, in the feature branch.

OK. Commented on the implementation details (Feature #15051#note-5) but that does not block the beta.

> pull my branch

Sure, will do. In the future, please make sure your branch also includes the changes I have pushed myself to prepare the beta (see ticket metadata changes in Feature #14481#note-39): in this specific case, your branch probably builds but any ISO built from it won’t include your set of TCRYPT-enablement packages, which makes me doubt you’ve tested it ;)

#45 Updated by intrigeri 2018-06-05 08:57:51

  • Assignee changed from intrigeri to segfault

intrigeri wrote:
> > sajolida ACKed my modified unlock dialog message (Feature #15218), so I included it in my gvfs repo.
>
> Great! I’ll look at it right now.

debdiff gvfs_1.30.4-1.0tails1.dsc gvfs_1.30.4-1.0tails2.dsc shows that you’ve reintroduced buggy version numbers that I had fixed in my upload e.g.

<code class="diff">
-               libudisks2-dev (>= 2.1.8-1.0tails1) [linux-any],
+               libudisks2-dev (>= 2.1.8-1tails1) [linux-any],

Please create a 1.30.4-1.0tails3 source package which fixes that and look at the debdiff vs. 1.30.4-1.0tails1 before the next round of review.

Meanwhile I’ve merged your branch and pushed so the next ISO built by Jenkins should fix the file association problem.

#46 Updated by segfault 2018-06-05 14:33:21

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

intrigeri wrote:
> Please create a 1.30.4-1.0tails3 source package which fixes that and look at the debdiff vs. 1.30.4-1.0tails1 before the next round of review.

Done. debdiff seems very useful, I didn’t know about it yet. But it requires the *orig.tar.xz files, maybe I should put those in the tails-tcrypt-packages repo too.

#47 Updated by intrigeri 2018-06-05 14:49:29

> But it requires the *orig.tar.xz files, maybe I should put those in the tails-tcrypt-packages repo too.

No need, they’re in Debian (and in our custom APT repo) already.

#48 Updated by intrigeri 2018-06-05 15:03:20

Apparently you rewrote history of commits I had already merged into my branch. Let’s please instead merge from each other’s branches and not rewrite history in situations like this when I might have to work on the branch too. Anyway, the diff between our branches is empty currently so I’ll just ignore yours for now => no immediate problem to solve but please fix that before you commit new stuff there :)

#49 Updated by intrigeri 2018-06-05 15:08:26

  • Assignee changed from intrigeri to segfault
  • QA Check deleted (Ready for QA)

gvfs 1.30.4-1.0tails3 uploaded and accepted, triggered a new build in Jenkins (ID: 6).

#50 Updated by segfault 2018-06-07 22:16:19

intrigeri wrote:
> Apparently you rewrote history of commits I had already merged into my branch. Let’s please instead merge from each other’s branches and not rewrite history in situations like this when I might have to work on the branch too. Anyway, the diff between our branches is empty currently so I’ll just ignore yours for now => no immediate problem to solve but please fix that before you commit new stuff there :)

Don’t know what happened, I thought I merged your branch, but apparently I screwed up. I fixed it now.

#51 Updated by intrigeri 2018-06-11 13:16:09

If we have no working prototype of VeraCrypt Mounter by June 25, then segfault will release what we have now as the beta.

#52 Updated by intrigeri 2018-06-11 13:16:28

  • related to deleted (Feature #15628: Consider re-enabling automounting to improve VeraCrypt UX)

#53 Updated by intrigeri 2018-06-11 13:16:38

  • blocked by Feature #15628: Consider re-enabling automounting to improve VeraCrypt UX added

#54 Updated by intrigeri 2018-06-26 16:27:58

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

#55 Updated by segfault 2018-07-01 11:34:02

  • Assignee changed from segfault to intrigeri
  • QA Check set to Ready for QA

I pushed new versions of the GVfs and GNOME Shell packages to https://gitlab.com/segfault3/tails-tcrypt-packages.

#56 Updated by segfault 2018-07-01 11:34:34

The new commits on the feature branch are also ready for review.

#57 Updated by segfault 2018-07-01 13:24:11

segfault wrote:
> The new commits on the feature branch are also ready for review.

Scratch that, I found bugs in VeraCrypt Mounter, so please only review the packages for now.

#58 Updated by segfault 2018-07-03 13:00:56

The feature branch is now ready for review. I extensively refactored VeraCrypt Mounter in commit 6a82abc45a840c77607a1233430329d86908fe9e, so you should probably not review the code commit by commit, but only the most recent version of the code.

#59 Updated by intrigeri 2018-07-04 09:05:09

segfault wrote:
> I pushed new versions of the GVfs and GNOME Shell packages to https://gitlab.com/segfault3/tails-tcrypt-packages.

Reviewed & fixed the only blocker (see Feature #15521 for next steps), built and upoaded both packages. Will now look at your tails.git branch.

#60 Updated by intrigeri 2018-07-04 09:43:55

I’ve commented on some plumbing matters on Feature #15043 but I won’t treat them as blockers: I don’t think VeraCrypt Mount should block the beta any further.

Merged your branch into the one that’s in the “Feature Branch” field here, pushed. Jenkins picked it up and is building. Next steps:

  1. I’ll have a look at the test suite results to make sure this does not break non-VeraCrypt things.
  2. Please test an ISO built from f30f88fb107150889de3741dc43b25e392eb6ae5 manually and tell me if it’s good enough to be the beta in your opinion.
  3. I want to reach a conclusion on Feature #15628 during our meeting on Friday before we release the beta: the decision we made 3 weeks ago needs to be revisited. Then if the conclusion is “enable auto-mount”, let’s re-add the commit that does it and ignore the automated test suite that’ll be broken in many ways.
  4. Once we’re all happy I’ll copy the ISO to our rsync server so it goes on the mirrors.
  5. Then you can proceed with the communication part of Feature #14477.

#61 Updated by intrigeri 2018-07-05 07:10:03

  • Assignee changed from intrigeri to segfault

intrigeri wrote:
> Next steps:
>
> # I’ll have a look at the test suite results to make sure this does not break non-VeraCrypt things.

Done, looks OK. Next step is yours:

> # Please test an ISO built from f30f88fb107150889de3741dc43b25e392eb6ae5 manually and tell me if it’s good enough to be the beta in your opinion.
> # I want to reach a conclusion on Feature #15628 during our meeting on Friday before we release the beta: the decision we made 3 weeks ago needs to be revisited. Then if the conclusion is “enable auto-mount”, let’s re-add the commit that does it and ignore the automated test suite that’ll be broken in many ways.
> # Once we’re all happy I’ll copy the ISO to our rsync server so it goes on the mirrors.
> # Then you can proceed with the communication part of Feature #14477.

#62 Updated by segfault 2018-07-05 17:34:21

intrigeri wrote:
> Done, looks OK. Next step is yours:
>
> > # Please test an ISO built from f30f88fb107150889de3741dc43b25e392eb6ae5 manually and tell me if it’s good enough to be the beta in your opinion.

Done. I found one issue: The .hc/.tc file associations don’t work. I fixed this in 81b5bf5d994f28b0bd463ce9053fd1a3d3216be7.

But I also noticed that if we decide on Feature #15628 that we don’t want to enable auto-mounting, we should change the association to VeraCrypt Mounter instead of gnome-disk-image-mounter (and extend VeraCrypt Mounter to handle being called with file paths as argument), because without auto-mounting it only attaches the file to a loop device, but doesn’t open an unlock dialog.

#63 Updated by segfault 2018-07-05 17:56:14

I just amended 81b5bf5d994f28b0bd463ce9053fd1a3d3216be7 to use a better fitting XDG directory and include a link to the MIME-info specification. The new commit is a6294205b649b3fd2be9ab7f03ab1870bc1eb179.

#64 Updated by segfault 2018-07-06 08:49:08

  • QA Check changed from Ready for QA to Dev Needed

I just found another issue: Unlocking hidden volumes doesn’t work anymore. I don’t yet know why, will have to debug this.

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

  • blocked by Feature #15522: Iteration 1: Create custom Debian package for udisks added

#66 Updated by intrigeri 2018-07-09 09:42:12

  • blocks deleted (Feature #15522: Iteration 1: Create custom Debian package for udisks)

#67 Updated by intrigeri 2018-07-09 09:46:14

Updated plan:

  1. fix the new problem he discovered
  2. merge the doc branch
  3. manually test an ISO built from the topic branch
  4. find someone to copy the ISO to our rsync server so it goes on the mirrors
  5. proceed with the communication part of Feature #14477

#68 Updated by segfault 2018-07-09 20:15:44

  • blocks deleted (Feature #15628: Consider re-enabling automounting to improve VeraCrypt UX)

#69 Updated by intrigeri 2018-07-10 08:11:25

segfault wrote:
> But I also noticed that if we decide on Feature #15628 that we don’t want to enable auto-mounting, we should change the association to VeraCrypt Mounter instead of gnome-disk-image-mounter (and extend VeraCrypt Mounter to handle being called with file paths as argument), because without auto-mounting it only attaches the file to a loop device, but doesn’t open an unlock dialog.

If this is something you think should block the beta, please insert fixing it between steps 1 and 2 of the plan. Otherwise, please ensure it’s tracked on another ticket.

#70 Updated by segfault 2018-07-10 11:02:46

intrigeri wrote:
> segfault wrote:
> > […]
> If this is something you think should block the beta, please insert fixing it between steps 1 and 2 of the plan. Otherwise, please ensure it’s tracked on another ticket.

IIRC, we discussed this during our meeting on Friday and decided that it should not block the beta, so I didn’t work in yet.

#71 Updated by intrigeri 2018-07-10 11:31:39

> intrigeri wrote:
>> > […]
>> If this is something you think should block the beta, please insert fixing it between steps 1 and 2 of the plan. Otherwise, please ensure it’s tracked on another ticket.

> IIRC, we discussed this during our meeting on Friday and decided that it should not block the beta, so I didn’t work in yet.

OK. I’ve updated the description of Feature #15051 then.

#72 Updated by segfault 2018-07-10 21:13:41

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

> manually test an ISO built from the topic branch

I did that and couldn’t find any new issues. So I think we can release 66a75f42af as the beta.

#73 Updated by intrigeri 2018-07-10 22:23:33

> I did that and couldn’t find any new issues. So I think we can release 66a75f42af as the beta.

Woohoo!!! I’ll do the rsync bits tomorrow and then will throw the ball back into your court for the communication part :)

#74 Updated by intrigeri 2018-07-11 07:32:50

Merged current devel into the topic branch, pushed. In ~4h I should have build and test results. Unless there’s a major surprise I’ll then copy the ISO to our rsync server.

#76 Updated by intrigeri 2018-07-11 17:09:17

  • 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

All mirrors should now have it. See you on Feature #14477! (call for testing, blog post, twitter and all that)