Feature #15226

Iteration 2: Upstream support for file containers in GtkPlacesSidebar

Added by segfault 2018-01-22 19:21:22 . Updated 2019-05-06 18:15:37 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2018-01-25
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:
299


Subtasks

Feature #15245: Iteration 2: Let upstream know we intend to intend to support file containers in GtkPlacesSidebar Resolved

0


Related issues

Related to Tails - Feature #15225: Iteration 2: Show unlocked VeraCrypt file containers in GtkPlacesSidebar Resolved 2018-01-22
Related to Tails - Feature #14467: Upstream VeraCrypt support in GNOME Files Resolved 2017-08-28

History

#1 Updated by segfault 2018-01-25 13:03:10

  • related to Feature #15225: Iteration 2: Show unlocked VeraCrypt file containers in GtkPlacesSidebar added

#2 Updated by segfault 2018-01-25 16:03:23

  • Subject changed from Upstream support for file containers in GtkPlacesSidebar to Iteration 2: Upstream support for file containers in GtkPlacesSidebar

#3 Updated by intrigeri 2018-04-14 07:54:39

  • related to Feature #14467: Upstream VeraCrypt support in GNOME Files added

#4 Updated by intrigeri 2018-06-29 09:00:56

  • Description updated
  • Status changed from Confirmed to In Progress

#5 Updated by intrigeri 2018-07-22 01:08:38

It’s been two weeks since https://gitlab.gnome.org/GNOME/gtk/merge_requests/200#note_261361 so I’m worried we won’t have an answer from Matthias Clasen early enough => please try another way to get in touch with the broader GTK+ developers community about this e.g. via their mailing lists.

#6 Updated by segfault 2018-08-05 19:05:08

  • Description updated

Today I got an explanation to why https://gitlab.gnome.org/GNOME/gtk/merge_requests/200 was rejected. I created new merge requests for GVfs and GTK (see description).

#7 Updated by intrigeri 2018-08-07 09:53:23

Great!

#8 Updated by intrigeri 2018-08-09 10:25:24

I’d like to avoid shipping in Tails a patchset that’s quite different from what we’ve submitted upstream, so please give yourself a ticket about replacing our obsolete patches with the new ones once they’re merged upstream.

#9 Updated by segfault 2018-08-09 12:45:36

  • Assignee changed from segfault to intrigeri
  • QA Check set to Info Needed

intrigeri wrote:
> I’d like to avoid shipping in Tails a patchset that’s quite different from what we’ve submitted upstream, so please give yourself a ticket about replacing our obsolete patches with the new ones once they’re merged upstream.

Not sure why you are raising this here, it seems unrelated to me. But anyway:

For GTK I will have to build a new package anyway. But if I also replace our patches in GLib, then we will have to rebuild pretty much everything else too, which is why I didn’t do it yet, and didn’t plan to, unless there were important changes, which there were not. Do you think it’s worth it?

#10 Updated by intrigeri 2018-08-09 13:11:09

  • Assignee changed from intrigeri to segfault
  • QA Check changed from Info Needed to Dev Needed

> Not sure why you are raising this here, it seems unrelated to me.

Right, it’s kinda unrelated (although the upstreaming process is what made our current patches obsolete). I did this because my other option was to reopen the relevant sibling ticket to comment there and I suspected you would not like it much. But indeed, if this requires more discussion we should do that in order to avoid hijacking this ticket :)

> For GTK I will have to build a new package anyway. But if I also replace our patches in GLib, then we will have to rebuild pretty much everything else too, which is why I didn’t do it yet, and didn’t plan to, unless there were important changes, which there were not. Do you think it’s worth it?

I don’t think it’s worth doing now but I do think it’s worth doing once the new patch series has been accepted upstream.

#11 Updated by segfault 2018-08-09 14:44:30

intrigeri wrote:
> > For GTK I will have to build a new package anyway. But if I also replace our patches in GLib, then we will have to rebuild pretty much everything else too, which is why I didn’t do it yet, and didn’t plan to, unless there were important changes, which there were not. Do you think it’s worth it?
>
> I don’t think it’s worth doing now but I do think it’s worth doing once the new patch series has been accepted upstream.

Actually, the patch for Bug #15667 uses the renamed function names introduced in the GLib patch I didn’t want to include in our packages. I don’t think I should alter that patch for our package, so I guess I do have to rebuild all the packages now (except for udisks and gnome-disk-utility, which don’t require our glib patches).

#12 Updated by intrigeri 2018-08-09 14:58:26

> […] so I guess I do have to rebuild all the packages now

Too bad :/

#13 Updated by intrigeri 2018-09-05 16:26:58

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

#14 Updated by segfault 2018-10-23 22:39:35

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

#15 Updated by CyrilBrulebois 2018-12-16 13:57:26

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

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

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

#17 Updated by CyrilBrulebois 2019-03-20 14:34:06

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

#18 Updated by intrigeri 2019-04-06 06:15:01

The two MRs in this ticket’s description were merged \o/

I assume next steps are:

  1. submit a MR that backports the code to GTK 3 and get it merged
  2. update our packages as discussed above (possibly only for Buster?)

#19 Updated by segfault 2019-04-12 13:53:23

  • Description updated
  • Status changed from In Progress to Resolved
  • Assignee deleted (segfault)
  • QA Check deleted (Dev Needed)

intrigeri wrote:
> The two MRs in this ticket’s description were merged \o/
>
> I assume next steps are:
>
> # submit a MR that backports the code to GTK 3 and get it merged

Did that and it was already merged.

> # update our packages as discussed above (possibly only for Buster?)

We only need to backport this for Buster, the packages for Stretch already include a patch which adds lists file containers in the GtkPlacesSidebar. I’m doing the backporting for Buster as part of Bug #16634, so I think we can mark this ticket as resolved.

#20 Updated by intrigeri 2019-04-12 14:02:54

\o/

#21 Updated by intrigeri 2019-05-05 08:23:53

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

#22 Updated by anonym 2019-05-06 15:03:13

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

#23 Updated by intrigeri 2019-05-06 18:15:37

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