Bug #12551

Set up a process to keep our fork of GNOME Shell's .desktop file and GDM's .session file up-to-date

Added by intrigeri 2017-05-16 14:58:46 . Updated 2020-04-15 06:02:10 .

Status:
Resolved
Priority:
Normal
Assignee:
anonym
Category:
Target version:
Tails_4.0
Start date:
2017-05-16
Due date:
% Done:

100%

Feature Branch:
feature/16912-move-greeter-to-main-git-repo+force-all-tests
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Welcome Screen
Deliverable for:

Description

As noticed on Bug #12364#note-33, our own config/gdm-shell-tails.desktop (in Tails Greeter’s Git repo) tends to be behind /usr/share/applications/org.gnome.Shell.desktop as shipped in Debian. This can potentially cause serious issues, so IMO we need a process to keep it more up-to-date than what we’ve done in the past. I don’t know what’s the best way to do that, but at least a ticket per Tails release based on the next version of Debian would be a good start; completing said ticket would require creating the next one. But there are probably better ways to do so, e.g. generate our own .desktop file dynamically at package build time from the upstream one.

Same for gdm-tails.session, see commit:f5e00d2d1051991e29720c422337e8855ca17cb2.

Subtasks

Related issues

Related to Tails - Bug #16288: No accessibility support in the Greeter on Buster Resolved 2019-01-05
Related to Tails - Bug #16951: Update gdm-tails.json for Bullseye Confirmed
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed
Blocked by Tails - Feature #16912: Move greeter source to main git repo Resolved

History

#1 Updated by intrigeri 2017-06-04 14:09:42

I’d like this to be done before the time we might switch to tracking Buster, hence this target version early 2018. Sounds doable? Otherwise please reassign to me.

#2 Updated by alant 2017-07-27 15:29:15

Yes, it looks doable for me before the end of the year.

#3 Updated by intrigeri 2017-10-06 04:40:59

  • Subject changed from Set up a process to keep our fork of GNOME Shell's .desktop file up-to-date to Set up a process to keep our fork of GNOME Shell's .desktop file and GDM's .session file up-to-date
  • Description updated

#4 Updated by Anonymous 2018-01-15 16:28:15

  • Target version changed from Tails_3.5 to Tails_3.6

Postponing.

#5 Updated by bertagaz 2018-03-14 11:32:04

  • Target version changed from Tails_3.6 to Tails_3.7

#6 Updated by intrigeri 2018-03-30 15:55:12

  • Status changed from Confirmed to In Progress

Applied in changeset commit:378502fe4d26d43506e8e542f75ff42ac98684cf.

#7 Updated by bertagaz 2018-05-10 11:09:00

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

#8 Updated by intrigeri 2018-06-26 16:27:37

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

#9 Updated by intrigeri 2018-09-05 16:26:47

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

#10 Updated by intrigeri 2018-10-24 17:03:29

  • Target version changed from Tails_3.10.1 to Tails_3.11

#11 Updated by CyrilBrulebois 2018-12-16 13:55:09

  • Target version changed from Tails_3.11 to Tails_3.12

#12 Updated by intrigeri 2019-01-05 14:30:31

alant wrote:
> Yes, it looks doable for me before the end of the year.

A while later: we’ve started working seriously on the port to Buster. Can you please give me a more realistic ETA? Thanks in advance!

#13 Updated by intrigeri 2019-01-05 15:09:55

  • related to Bug #16288: No accessibility support in the Greeter on Buster added

#14 Updated by sajolida 2019-01-22 18:26:15

#15 Updated by anonym 2019-01-30 11:59:16

  • Target version changed from Tails_3.12 to Tails_3.13

#16 Updated by CyrilBrulebois 2019-03-20 14:35:10

  • Target version changed from Tails_3.13 to Tails_3.14

#17 Updated by CyrilBrulebois 2019-05-23 21:23:22

  • Target version changed from Tails_3.14 to Tails_3.15

#18 Updated by intrigeri 2019-05-24 06:13:34

  • Assignee deleted (alant)
  • Target version changed from Tails_3.15 to Tails_4.0

This ticket was filed 2 years ago, Alan gave an ETA that’s now 5 months in the past and did not reply to my request for an updated ETA ⇒ let’s have FT (quite possibly me) do this as part of the 4.0 work. This being said, @alant, if you do join one of the Buster sprints, this could be a good task for you there :)

#19 Updated by intrigeri 2019-05-24 06:13:50

#20 Updated by intrigeri 2019-06-18 16:57:34

  • Status changed from In Progress to Confirmed

#21 Updated by segfault 2019-06-21 01:39:19

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|25673681fe16bad4c03dc920c8b2e32753bd7a77.

#22 Updated by segfault 2019-06-21 01:45:13

  • Status changed from In Progress to Needs Validation
  • % Done changed from 0 to 10

I wrote a build hook in the Tails repo to copy the original file as shipped in Debian and apply our changes on top. I think doing this during the Tails build is much easier than during Greeter build. If this makes sense, I can prepare another commit in the greeter repo to stop shipping the affected files there.

#23 Updated by intrigeri 2019-06-22 10:27:20

  • Feature Branch set to bugfix/12551-keep-gdm-tails-files-up-to-date

#24 Updated by intrigeri 2019-06-22 10:40:50

  • Status changed from Needs Validation to In Progress
  • Assignee set to segfault

I like it a lot!

Code review passes except:

  • You need to escape regexp special chars, e.g. the dots in “org.gnome.Shell”
  • Please consistently use extended regexps so we don’t have to remember the subtle (or not so subtle) differences between N>1 regexp languages.

Also, what about /usr/share/gnome-shell/modes/gdm-tails.json? It’s not explicitly listed on this ticket but it has exactly the same problem: see 8d4b0d95c2ccf06df9cd2fe8b2dee9d4427c2626 in greeter.git.

Just to avoid wasting your time: the corresponding changes in greeter.git shall be based on the feature/buster branch there.

#25 Updated by segfault 2019-06-23 21:26:17

intrigeri wrote:
> I like it a lot!
>
> Code review passes except:
>
> * You need to escape regexp special chars, e.g. the dots in “org.gnome.Shell”
> * Please consistently use extended regexps so we don’t have to remember the subtle (or not so subtle) differences between N>1 regexp languages.

I pushed a commit to fix that. I hope I didn’t miss any other unescaped special chars.

> Also, what about /usr/share/gnome-shell/modes/gdm-tails.json? It’s not explicitly listed on this ticket but it has exactly the same problem: see 8d4b0d95c2ccf06df9cd2fe8b2dee9d4427c2626 in greeter.git.

It’s not clear to me which of the differences between gdm-tails.json and classic.json are on purpose and which caused by updates of classic.json. Here is the complete diff of the classic.json from buster and gdm-tails.json from the feature/buster branch of greeter.git:

<code class="diff">
diff -Naur /usr/share/gnome-shell/modes/classic.json config/gdm-tails.json 
--- /usr/share/gnome-shell/modes/classic.json   2018-11-02 09:26:47.000000000 +0000
+++ config/gdm-tails.json   2019-06-23 17:52:05.676737605 +0000
@@ -1,9 +1,16 @@
 {
-    "parentMode": "user",
-    "stylesheetName": "gnome-classic.css",
-    "enabledExtensions": ["apps-menu@gnome-shell-extensions.gcampax.github.com", "places-menu@gnome-shell-extensions.gcampax.github.com", "launch-new-instance@gnome-shell-extensions.gcampax.github.com", "window-list@gnome-shell-extensions.gcampax.github.com"],
-    "panel": { "left": ["activities", "appMenu"],
-               "center": [],
-               "right": ["a11y", "keyboard", "dateMenu", "aggregateMenu"]
-             }
+    "hasNotifications": true,
+    "isGreeter": false,
+    "isPrimary": true,
+    "unlockDialog": null,
+    "isLocked": true,
+    "hasWindows": true,
+    "components": ["polkitAgent"],
+    "panel": {
+        "left": [],
+        "center": ["dateMenu"],
+        "right": ["a11y", "keyboard", "aggregateMenu"]
+    },
+    "panelStyle": "loginScreen",
+    "stylesheetName": "gnome-classic.css"
 }

> Just to avoid wasting your time: the corresponding changes in greeter.git shall be based on the feature/buster branch there.

Ack

#26 Updated by segfault 2019-06-23 21:42:02

gdm-tails.json was created in 2016, for Tails based on Jessie I assume. Jessie had gnome-shell-extensions 3.14.2, which includes data/classic.json.in. That file wasn’t updated since then, so I suspect all the differences are on purpose.

#27 Updated by intrigeri 2019-06-24 08:01:48

FWIW it looks like our gdm-tails.json is a kind of hybrid between classic.json (meant for a regular GNOME Classic user session) and the gdm mode in js/ui/sessionMode.js (from GNOME Shell’s source tree). And in passing, our panelStyle is loginScreen while GNOME’s is login-screen — no idea if loginScreen actually does/means anything relevant.

> gdm-tails.json was created in 2016, for Tails based on Jessie I assume. Jessie had gnome-shell-extensions 3.14.2, which includes data/classic.json.in. That file wasn’t updated since then, so I suspect all the differences are on purpose.

Yep.

I’m not sure how we should handle this file. Forking the gdm mode at build time would make some sense: the only part we’ve ever had to update since 2016 is the “panel” bits, and we’re using exactly the same config there as the gdm mode. But I don’t know if/how we can access this config at Tails build time without downloading the GNOME Shell source package. I’m not sure it’s worth the effort.

I propose we:

  • add a comment in this file to sum up what we’ve reverse-engineered here, so it’s easier to find out where the 2 upstream components our file is derived from live
  • create a ticket with target version = Tails_5.0 that will be about:
    • sync’ing this file with Bullseye’s
    • creating a similar ticket for 6.0
    • rationale: we need to bother only when we switch to a new Debian release

What do you think?

#28 Updated by segfault 2019-07-11 21:29:51

intrigeri wrote:
> FWIW it looks like our gdm-tails.json is a kind of hybrid between classic.json (meant for a regular GNOME Classic user session) and the gdm mode in js/ui/sessionMode.js (from GNOME Shell’s source tree). And in passing, our panelStyle is loginScreen while GNOME’s is login-screen — no idea if loginScreen actually does/means anything relevant.

Good catch. I don’t think that setting the style to loginScreen has any effect. login-screen is defined in gnome-shell’s CSS, loginScreen is not. We could either change that line to actually use the login-screen style or delete it to keep using the default panel style.

> > gdm-tails.json was created in 2016, for Tails based on Jessie I assume. Jessie had gnome-shell-extensions 3.14.2, which includes data/classic.json.in. That file wasn’t updated since then, so I suspect all the differences are on purpose.
>
> Yep.
>
> I’m not sure how we should handle this file. Forking the gdm mode at build time would make some sense: the only part we’ve ever had to update since 2016 is the “panel” bits, and we’re using exactly the same config there as the gdm mode. But I don’t know if/how we can access this config at Tails build time without downloading the GNOME Shell source package. I’m not sure it’s worth the effort.
>
> I propose we:
>
> * add a comment in this file to sum up what we’ve reverse-engineered here, so it’s easier to find out where the 2 upstream components our file is derived from live
> * create a ticket with target version = Tails_5.0 that will be about:
> sync’ing this file with Bullseye’s
> creating a similar ticket for 6.0
> rationale: we need to bother only when we switch to a new Debian release

Sounds good, but unfortunately JSON doesn’t support comments. We could add the information to the Tails 5.0 ticket instead.

#29 Updated by intrigeri 2019-08-04 08:52:35

Just to be clear: are you waiting for further input from me?

#30 Updated by segfault 2019-08-04 09:00:12

intrigeri wrote:
> Just to be clear: are you waiting for further input from me?

Yes, whether you’re fine with adding the comment to the Tails 5.0 ticket instead of the JSON file.

#31 Updated by intrigeri 2019-08-04 09:04:46

> Yes, whether you’re fine with adding the comment to the Tails 5.0 ticket instead of the JSON file.

Sure, go for it :)

#32 Updated by segfault 2019-08-08 12:55:43

  • related to Bug #16951: Update gdm-tails.json for Bullseye added

#33 Updated by segfault 2019-08-08 14:00:31

  • Feature Branch changed from bugfix/12551-keep-gdm-tails-files-up-to-date to bugfix/12551-keep-gdm-tails-files-up-to-date,greeter:bugfix/12551-keep-gdm-tails-files-up-to-date

intrigeri wrote:
> * create a ticket with target version = Tails_5.0 that will be about:
> sync’ing this file with Bullseye’s
> creating a similar ticket for 6.0
> rationale: we need to bother only when we switch to a new Debian release

Done, see Bug #16951.

segfault wrote:
> If this makes sense, I can prepare another commit in the greeter repo to stop shipping the affected files there.

I did that, but I didn’t test it yet. intrigeri, on Feature #11529 you said that I shouldn’t upload releases with official looking versions for testing. But I think I have to upload a release here for testing. Can I use a version like 1.0.9+1.bugfix.12551.1 for that? Or is there another way?

#34 Updated by intrigeri 2019-08-08 14:35:11

> you said that I shouldn’t upload releases with official looking versions for testing. But I think I have to upload a release here for testing. Can I use a version like 1.0.9+1.bugfix.12551.1 for that? Or is there another way?

This would work. Note that 1.0.9 is not the latest one.

Alternatively, basing your branch on top of Feature #16912 might be easier.

#35 Updated by segfault 2019-08-08 15:13:54

intrigeri wrote:
> > you said that I shouldn’t upload releases with official looking versions for testing. But I think I have to upload a release here for testing. Can I use a version like 1.0.9+1.bugfix.12551.1 for that? Or is there another way?
>
> This would work. Note that 1.0.9 is not the latest one.
>
> Alternatively, basing your branch on top of Feature #16912 might be easier.

Of course, that would be a lot easier. But I wasn’t sure whether Feature #16912 would make it into 4.0.

#36 Updated by intrigeri 2019-08-11 09:28:51

segfault wrote:
> Of course, that would be a lot easier. But I wasn’t sure whether Feature #16912 would make it into 4.0.

I’m now very confident it’ll make it, so feel free to rebase your work on top of Feature #16912 :)

#37 Updated by segfault 2019-08-14 13:13:09

  • Status changed from In Progress to Needs Validation
  • Assignee deleted (segfault)

intrigeri wrote:
> segfault wrote:
> > Of course, that would be a lot easier. But I wasn’t sure whether Feature #16912 would make it into 4.0.
>
> I’m now very confident it’ll make it, so feel free to rebase your work on top of Feature #16912 :)

Done.

#38 Updated by intrigeri 2019-08-15 06:42:37

  • Assignee set to intrigeri

#39 Updated by intrigeri 2019-08-15 06:42:56

  • blocked by Feature #16912: Move greeter source to main git repo added

#40 Updated by intrigeri 2019-08-15 07:20:21

  • Feature Branch changed from bugfix/12551-keep-gdm-tails-files-up-to-date,greeter:bugfix/12551-keep-gdm-tails-files-up-to-date to bugfix/12551-keep-gdm-tails-files-up-to-date

#41 Updated by intrigeri 2019-08-15 12:00:37

  • Status changed from Needs Validation to In Progress

Applied in changeset commit:tails|8caeebb4af9204eb21e1aeb5ab0ca10725637d6f.

#42 Updated by intrigeri 2019-08-15 12:02:02

  • Status changed from In Progress to Needs Validation
  • Assignee changed from intrigeri to segfault

I’ve pushed a bunch of small improvements (mostly maintainability & robustness, some that might be called nitpicking, but it’s all in the general spirit of “let’s avoid pointing too many loaded guns to our foots and hope nobody ever presses the trigger” :)

Please review these code changes and then reassign to me (I’ve not looked at test suite results yet).

#43 Updated by segfault 2019-08-15 18:05:53

  • Status changed from Needs Validation to In Progress
  • Assignee changed from segfault to intrigeri

intrigeri wrote:
> I’ve pushed a bunch of small improvements (mostly maintainability & robustness, some that might be called nitpicking, but it’s all in the general spirit of “let’s avoid pointing too many loaded guns to our foots and hope nobody ever presses the trigger” :)
>
> Please review these code changes and then reassign to me (I’ve not looked at test suite results yet).

LGTM. e0d2cefabbce2b3d4027d8ceefb27a59c2f0ef93 could cause the script to fail if org.gnome.Shell would ever be the last element in the list (without a trailing ;). But I see that that’s better than an incorrect replacement.

#44 Updated by intrigeri 2019-08-15 18:20:51

  • Status changed from In Progress to Needs Validation

> LGTM.

Thanks!

> e0d2cefabbce2b3d4027d8ceefb27a59c2f0ef93 could cause the script to fail if org.gnome.Shell would ever be the last element in the list (without a trailing ;). But I see that that’s better than an incorrect replacement.

Agreed on both counts.

#45 Updated by intrigeri 2019-08-16 11:30:36

Test suite works just as well as current devel and Feature #16912 so I’m going to merge this into the branch for Feature #16912 and delete this one \o/

#46 Updated by intrigeri 2019-08-16 11:31:56

  • Assignee changed from intrigeri to anonym
  • Feature Branch changed from bugfix/12551-keep-gdm-tails-files-up-to-date to feature/16912-move-greeter-to-main-git-repo+force-all-tests

@anonym, this passed the review so you can skip these bits when reviewing Feature #16912.

#47 Updated by intrigeri 2019-08-23 15:34:00

  • Status changed from Needs Validation to Fix committed
  • % Done changed from 10 to 100

Applied in changeset commit:tails|98b015374d0d8218f9a891a8a901b3f66ac303d7.

#48 Updated by intrigeri 2019-08-23 15:37:32

  • Status changed from Fix committed to Resolved

#49 Updated by intrigeri 2020-04-15 06:02:10

  • Affected tool changed from Greeter to Welcome Screen