Tails

#2 Updated by Anonymous 2018-04-11 13:43:35

@segfault: I assume you will want to get this patch upstream? If yes, may you please create a ticket for that or link one that you created already?

If we have to build this package for every Tails release, we will also need a release process documentation, similar to this one: http://tails.boum.org/contribute/release_process/tails-installer

#3 Updated by segfault 2018-04-11 16:13:08

u wrote:
> @segfault: I assume you will want to get this patch upstream?
The changes in Disks will be upstreamed (to Disks, see Feature #15221), but the Debian package will not be upstreamed (to Debian) - we only need it to ship our changes in Tails before the end of the contract. They will land in Debian Buster anyway, so we don’t need to take the effort of upstreaming the Stretch packages.

> If we have to build this package for every Tails release, we will also need a release process documentation, similar to this one: http://tails.boum.org/contribute/release_process/tails-installer

Right. I don’t expect that we will have to change the package, but we should include a step in the release process to check whether there are security updates we should merge. I now created Feature #15524 for that.

#4 Updated by Anonymous 2018-04-12 12:21:51

segfault wrote:
> I backported our Disks patches to the Disks version in Stretch (Feature #15515).
> Now we have to create a Debian package out of this, which we can ship in the beta release (planned for June 1) and Tails 3.9.
>
> The code lives in https://github.com/segfault3/gnome-disk-utility branch 3.22.1-support-tcrypt.
>
> The dependencies are listed here: https://packages.debian.org/stretch/gnome-disk-utility.

So basically : you patched gnome-disk-utility?
i.e. we can take that package from Debian, add your patch, build and upload?
If you confirm, this is much easier (read: faster!) than what I thought.

#5 Updated by Anonymous 2018-04-12 12:30:03

You might want to learn how to create patches for Debian packages :)

To start with:

debcheckout gnome-disk-utility
cd gnome-disk-utility

Now use quilt: https://wiki.debian.org/UsingQuilt

quilt push -a
quilt new bla.diff
quilt add file_to_patch
quilt edit file_to_patch
quilt refresh
quilt pop -a

This should create bla.diff in debian/patches/ and update debian/patches/series

You can also create that patch manually from your code and put it into debian/patches/mypatch.diff and then add it to debian/patches/series.

Actually.. I think intrigeri uses http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html to handle patches. But i never tried this -> although I think it is particularly intended for the kind of case we’re facing here :)

From here we can build the package using

gbp buildpackage

.. assuming you’ve already created a build environment with pbuilder or cowbuilder for example.

Depending on the codebase and language, building can take quite some time though.

Do you want to give it a try or should I +/- anonym do it?

Also, I guess we might want to use a Git repository that other people than you can write to? Could you ask sysadmins to set this up?

#6 Updated by segfault 2018-04-15 11:54:26

Yay, I succeeded in building custom packages for both udisks2 and gnome-disk-utility! Thanks for your help!

u wrote:
> You might want to learn how to create patches for Debian packages :)
>
> To start with:
>
> debcheckout gnome-disk-utility
> cd gnome-disk-utility

Wow, debcheckout is awesome, I wish I knew about that earlier (I always used apt source to get the sources, but getting the git repository is much better).

> Now use quilt: https://wiki.debian.org/UsingQuilt
>
> […]
>
> This should create bla.diff in debian/patches/ and update debian/patches/series
>
>
> You can also create that patch manually from your code and put it into debian/patches/mypatch.diff and then add it to debian/patches/series.
>
> Actually.. I think intrigeri uses http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html to handle patches. But i never tried this -> although I think it is particularly intended for the kind of case we’re facing here :)

I tried both quilt and gbp now and found that gbp does indeed do exactly what I needed.

> From here we can build the package using
> […]
> .. assuming you’ve already created a build environment with pbuilder or cowbuilder for example.

I did not use pbuilder or cowbuilder, but found that gbp buildpackage still does build a package - at least up to the point where it fails with

Now signing changes and any dsc files...
 signfile dsc gnome-disk-utility_3.22.1-1.dsc Michael Biebl <biebl@debian.org>
gpg: skipped "Michael Biebl <biebl@debian.org>": No secret key
gpg: /tmp/debsign.xptmR9ZM/gnome-disk-utility_3.22.1-1.dsc: clear-sign failed: No secret key

I spent quite some time trying to fix this, without success. But then I noticed that there were already .deb files created in the parent directory, which I was able to successfully install in Tails. And it all seems to work now, I could successfully unlock VeraCrypt volumes in Disks on Tails! :)

> Also, I guess we might want to use a Git repository that other people than you can write to? Could you ask sysadmins to set this up?

I’m not sure if this is required anymore now.

#10 Updated by Anonymous 2018-04-16 14:55:39

segfault wrote:
> Yay, I succeeded in building custom packages for both udisks2 and gnome-disk-utility! Thanks for your help!

You’re welcome.

> u wrote:
> > You might want to learn how to create patches for Debian packages :)
> >
> > To start with:
> >
> > debcheckout gnome-disk-utility
> > cd gnome-disk-utility
>
> Wow, debcheckout is awesome, I wish I knew about that earlier (I always used apt source to get the sources, but getting the git repository is much better).

Indeed :) There are too many secret things in Debian :)

> > Now use quilt: https://wiki.debian.org/UsingQuilt
> >
> > […]
> >
> > This should create bla.diff in debian/patches/ and update debian/patches/series
> >
> >
> > You can also create that patch manually from your code and put it into debian/patches/mypatch.diff and then add it to debian/patches/series.
> >
> > Actually.. I think intrigeri uses http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html to handle patches. But i never tried this -> although I think it is particularly intended for the kind of case we’re facing here :)
>
> I tried both quilt and gbp now and found that gbp does indeed do exactly what I needed.

Cool, that’s what I suspected.

> > From here we can build the package using
> > […]
> > .. assuming you’ve already created a build environment with pbuilder or cowbuilder for example.
>
> I did not use pbuilder or cowbuilder, but found that gbp buildpackage still does build a package - at least up to the point where it fails with

I don’t know what gbp does by default - but I use it with pbuilder in order to build packages in a clean sid or stretch chroot - whatever I build the package for.

> […]
>
> I spent quite some time trying to fix this, without success. But then I noticed that there were already .deb files created in the parent directory, which I was able to successfully install in Tails. And it all seems to work now, I could successfully unlock VeraCrypt volumes in Disks on Tails! :)

See my other comment about incrementing the version number and using your own email address to be able to sign the package. Still, as I don’t think you have the right to upload this yourself, one of us will do the signing I guess.

> > Also, I guess we might want to use a Git repository that other people than you can write to? Could you ask sysadmins to set this up?
>
> I’m not sure if this is required anymore now.

Well, if you want us to be able to “sponsor” and upload your package to the Tails repository - I guess it’s required. Unless you have access to that which I doubt for some reason.

#14 Updated by intrigeri 2018-06-03 17:55:20

See my upcoming review on Feature #15521 for required changes. Other than that: libudisks2-dev (= 2.1.8-1tails1) feels needlessly strict and will force us to rebuild + upload this package every time we update src:udisks2. Assuming ABI is compatible, I suspect libudisks2-dev (>= 2.1.8-1tails1) would be enough to ensure we have the required API available.

#15 Updated by intrigeri 2018-06-03 18:21:33

Also, that version is wrong in the source package you’ve uploaded so the package FTFBS. I’ve replaced it with 2.1.8-1.0tails1 and did the s/=/>=/ while I was at it.

#18 Updated by segfault 2018-07-08 11:21:26

intrigeri wrote:
> Please correct me if I’m wrong, but I think we’re done here.
>
> If Feature #14480 or Feature #15589 bring more needed changes, we’ll track this on the parent ticket (Feature #15521).

ack