Bug #16947: Investigate build-manifest discrepancy for Tails 4.0~beta1

Bug #16947

Investigate build-manifest discrepancy for Tails 4.0~beta1

Added by anonym 2019-08-07 20:18:40 . Updated 2019-08-10 18:12:58 .

Status:

Resolved

Priority:

High

Assignee:

Category:

Build system

Target version:

Tails_3.16

Start date:

Due date:

% Done:

Feature Branch:

Type of work:

Research

Blueprint:

Starter:

Affected tool:

Deliverable for:

Description

So I just successfully built Tails 4.0~beta1 but got this .build-manifest diff (“almost-final” vs final):

--- tails-amd64-testing-4.0~beta1-20190807T1254Z-8be2a69358.build-manifest      2019-08-07 15:18:56.392828125 +0200
+++ tails-amd64-4.0~beta1.build-manifest   2019-08-07 21:09:15.846847112 +0200
@@ -3,7 +3,7 @@
   debian:
     reference: '2019080601'
   debian-security:
-    reference: '2019080702'
+    reference: '2019080703'
   torproject:
     reference: '2019080601'
 packages:
@@ -4488,9 +4488,6 @@
     package: poedit
     version: 2.2.1-2
   - arch: amd64
-    package: policykit-1-gnome
-    version: 0.105-7
-  - arch: amd64
     package: policykit-1
     version: 0.105-25
   - arch: all

So I guess my last minute fixes to config/chroot_local-hooks/98-remove_unwanted_packages, which happened after building the “almost-final” images, caused this, somehow (?).

I’m thinking this diff isn’t problematic. First of all, we don’t install policykit-1-gnome in stretch, which gives some confidence in that it isn’t needed in buster. Second, since the .build-manifest I used to generate 4.0~beta1’s tagged snapshot contains an extra package, there’s no real problem, just an unused package in the snapshot wasting some irrelevant amount of disk space. Correct? If so, I don’t think there’s any problem, and the 4.0~beta1 attempt as of commit:4e4e18975355e691114fc40ceb9aae5c506952bb can be what we actually release.

Subtasks

Related issues

Blocks Tails - Feature #16209: Core work: Foundations Team

Confirmed

History

#1 Updated by anonym 2019-08-07 20:20:59

Assignee set to intrigeri
Priority changed from Normal to High

Assigning high prio for an ASAP answer; I’ll tell manual testers to hold off testing (or risk having to redo it unpaid :)) until I have a confirmation (but I’ll make them optimistically download the images so that’s done).

CyrilBrulebois, intrigeri, what do you think of my explanation?

#2 Updated by CyrilBrulebois 2019-08-07 22:50:59

So I’ve just built from the latest git locally (commit:4e4e18975355e691114fc40ceb9aae5c506952bb), and I’m confirming the diff against the artifacts you shared with me for the previous build.

I’m not convinced the situation is fine.

We have this package installed:

tails-amd64-4.0~beta1.packages:network-manager-gnome    1.8.20-1.1

which, according to a quick look in a buster chroot has a hard dependency (Depends) on policykit-1-gnome | polkit-1-auth-agent.

We had the former package in your almost-final build, but it’s no longer in the final build.

The latter package is neither in the almost-final build, nor in the final build.

It seems to me we could be shipping a broken package?

Except… checking from within a running ISO, it seems that there’s no issue for APT, because polkit-1-auth-agent is provided by our own gnome-shell package (as would do the pristine gnome-shell package, from Debian buster).

So it might not be a practical issue, but I’m slightly concerned… Your tails-amd64-testing-4.0~beta1-20190807T1254Z-8be2a69358.build-manifest had the package, and https://tagged.snapshots.deb.tails.boum.org/4.0-beta1/debian/dists/buster/main/binary-amd64/Packages has Package: policykit-1-gnome\nVersion: 0.105-7 so I don’t really understand why apt doesn’t resolve to the same set of packages…

Could/will that bite us (harder) in the future?

For this specific beta release, it doesn’t look to me like it should be a blocker, though.

#3 Updated by anonym 2019-08-08 08:00:11

CyrilBrulebois wrote:
> It seems to me we could be shipping a broken package?

FWIW, I quickly tested GNOME’s network-manager integration, and wired, wireless and mobile broadband all seem to work fine.

> Except… checking from within a running ISO, it seems that there’s no issue for APT, because polkit-1-auth-agent is provided by our own gnome-shell package (as would do the pristine gnome-shell package, from Debian buster).

I don’t get it. If gnome-shell provides polkit-1-auth-agent it means it offer equivalent functionality, right?

I think the situation is that policykit-gnome is deprecated in favor of the built-in policykit auth agent that gnome-shell now provides. In fact, I just found that Gnome archived policykit-gnome (note the “Archive” in the URL) which they do for “[p]rojects that were part of the GNOME group but were archived due to inactivity or deprecation” (source.

> Could/will that bite us (harder) in the future?

We definitely should investigate/evaluate this as well! I’ll make sure to open a new ticket if we close this one (or re-purpose this one),

> For this specific beta release, it doesn’t look to me like it should be a blocker, though.

My tests and the facts we have seem to support this. So I’ll tell testers to start testing.

#4 Updated by intrigeri 2019-08-08 08:12:52

Status changed from Confirmed to Needs Validation
Assignee changed from intrigeri to anonym

> which, according to a quick look in a buster chroot has a hard dependency (Depends) on policykit-1-gnome | polkit-1-auth-agent.

> We had the former package in your almost-final build, but it’s no longer in the final build.

As you folks suspected, we don’t need polkit-1-gnome when using GNOME Shell, as documented in the description of the polkit-1-gnome package.

So the problem here is: we should never install policykit-1-gnome. It’s good that it’s not in the final build. But we should ensure we never ship it, even in the {non,almost}-final builds.

> The latter package is neither in the almost-final build, nor in the final build.

Indeed, it’s a virtual package :)

> Your tails-amd64-testing-4.0~beta1-20190807T1254Z-8be2a69358.build-manifest had the package, and https://tagged.snapshots.deb.tails.boum.org/4.0-beta1/debian/dists/buster/main/binary-amd64/Packages has Package: policykit-1-gnome\nVersion: 0.105-7 so I don’t really understand why apt doesn’t resolve to the same set of packages…

Uh, that’s weird.

> Could/will that bite us (harder) in the future?

I would say no, as long as we ensure we never ship policykit-1-gnome. I’ve added this to ~~Bug #16949~~. So I would say case closed here (personally I’m comfortable with not investigating why the problem happens right now: the mere existence of this ticket shows that we have good safeguards against any such trouble; OTOH I bet anonym would have happily done without this burden, so if someone wants to investigate a bit further, in the hope they identify & fix the root cause, be my guest :)

> For this specific beta release, it doesn’t look to me like it should be a blocker, though.

Full ACK: the diff provided by anonym confirms that the final image has the correct content in this respect, so there’s no reason to block on this.

#5 Updated by anonym 2019-08-08 09:08:31

blocks Feature #16209: Core work: Foundations Team added

#6 Updated by anonym 2019-08-08 09:15:19

Status changed from Needs Validation to Resolved
Assignee deleted (~~anonym~~)

intrigeri wrote:
> > which, according to a quick look in a buster chroot has a hard dependency (Depends) on policykit-1-gnome | polkit-1-auth-agent.
>
> > We had the former package in your almost-final build, but it’s no longer in the final build.
>
> As you folks suspected, we don’t need polkit-1-gnome when using GNOME Shell, as documented in the description of the polkit-1-gnome package.

Haha! The first thing I did when I saw the discrepancy was apt-cache show policykit-1-gnome, but for some reason the extended description is not shown on my system. It indeed makes the situation very clear:

This implementation was originally designed for GNOME 2, but most GNOME-based desktop environments, including GNOME 3, GNOME Flashback, and MATE, have their own built-in PolicyKit agents and no longer use this one. The remaining users of this implementation are Cinnamon, XFCE and Unity.

> So the problem here is: we should never install policykit-1-gnome. It’s good that it’s not in the final build. But we should ensure we never ship it, even in the {non,almost}-final builds.

I opened ~~Bug #16950~~ for this and some related stuff.

> > Could/will that bite us (harder) in the future?
>
> I would say no, as long as we ensure we never ship policykit-1-gnome. I’ve added this to ~~Bug #16949~~. So I would say case closed here (personally I’m comfortable with not investigating why the problem happens right now: the mere existence of this ticket shows that we have good safeguards against any such trouble; OTOH I bet anonym would have happily done without this burden, so if someone wants to investigate a bit further, in the hope they identify & fix the root cause, be my guest :)

Sure, a fix would be nice, but I defer to your wisdom in the subject. :)

> > For this specific beta release, it doesn’t look to me like it should be a blocker, though.
>
> Full ACK: the diff provided by anonym confirms that the final image has the correct content in this respect, so there’s no reason to block on this.

Closing!

#7 Updated by intrigeri 2019-08-08 11:45:14

> I opened ~~Bug #16950~~ for this and some related stuff.

Please de-duplicate it wrt. ~~Bug #16949~~.

#8 Updated by intrigeri 2019-08-10 08:24:00

@CyrilBrulebois, commit:782ed3b2a2a45b441740813b32d7afa767d632aa fixes this problem in a nicer way than “just deinstall policykit-1-gnome if it got installed for some reason we don’t understand”. I still don’t fully understand why APT would not install that package when building with partial, tagged snapshots, but I can live with it, since I think I now understood why APT would install it (which is the problem) when building with (a clone of) a full Debian archive: without diving into the APT source code, I suspect there are a few passes of dependency resolution, and what I’m doing in that commit ensures that during some early pass, the dependency is already satisfied by gnome-shell, while without this commit, without gnome-shell in the set of to-be-installed packages yet, APT adds the first package that satisfies the dependency (policykit-1-gnome) to the set of to-be-installed packages, and does not clean this up later after it has added gnome-shell to the list. I’ll submit that commit as part of a branch which will batch a few Buster-related tickets together.

#9 Updated by CyrilBrulebois 2019-08-10 18:12:59

Thanks @intrigeri; I had been thinking about this “in the background” and was suspecting this might not be fixable at all since APT’s dependency resolution isn’t something we can really control.

Your patch for this specific instance seems very reasonable and reassuring: that’s one problem we shouldn’t see again, hence more peace of mind for the RM du jour. I suppose we could extend this to other packages if that happens again in the future, in case we know (or figure out) which part of an alternative we would like to prefer…

Thanks!

#10 Updated by Anonymous 2019-10-21 12:30:55

related to ~~Feature #10037~~: Help Weblate maintainers to add the package to Debian added

#11 Updated by Anonymous 2019-10-21 12:31:01

related to deleted (~~~~Feature #10037~~: Help Weblate maintainers to add the package to Debian~~)