Tails

#3 Updated by segfault 2019-04-12 12:21:09

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 Bug #15952 to add a tooltip to the keyfile chooser button, which was only released in 3.31.90. But intrigeri wrote on Bug #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 2019-04-12 12:53:00

> 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 2019-04-12 17:40:00

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.

#7 Updated by segfault 2019-06-01 23:29:41

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 2019-06-06 07:50:14

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.

#10 Updated by segfault 2019-06-06 09:54:56

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 2019-06-06 10:12:21

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 2019-06-07 09:53:35

> 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 2019-06-09 07:46:13

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 2019-06-09 16:23:23

> 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 2019-06-12 20:05:54

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 2019-06-13 12:43:53

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 2019-06-13 19:20:14

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 2019-06-14 08:39:45

> 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 2019-06-14 09:16:09

> 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 2019-06-14 09:17:48

> 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 2019-06-14 09:37:18

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.

#23 Updated by intrigeri 2019-06-15 09:34:41

@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 2019-06-16 10:04:20

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