Tails

#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!

#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.

#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.

#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.

#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.

#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

#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?

#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).

#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.

#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 ;)

#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 :)

#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.

#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.

#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.

#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

#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.

#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.

#75 Updated by intrigeri 2018-07-11 12:18:18

Uploaded to our rsync server. URL will be http://dl.amnesia.boum.org/tails/alpha/tails-amd64-feature_14481-TCRYPT-support-beta-3.9-20180711T0737Z-628b2ff44a+devel@df85233d79.iso once the mirrors have picked it up.