Project

General

Profile

Feature #15226

Feature #14468: Add VeraCrypt support to Tails

Feature #15223: Iteration 2: Support unlocking VeraCrypt file containers in GNOME

Iteration 2: Upstream support for file containers in GtkPlacesSidebar

Added by segfault over 1 year ago. Updated 18 days ago.

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

100%

QA Check:
Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:


Subtasks

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


Related issues

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

History

#1 Updated by segfault over 1 year ago

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

#2 Updated by segfault over 1 year ago

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

#3 Updated by intrigeri about 1 year ago

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

#4 Updated by intrigeri 11 months ago

  • Description updated (diff)
  • Status changed from Confirmed to In Progress

#5 Updated by intrigeri 10 months ago

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 10 months ago

  • Description updated (diff)

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 10 months ago

Great!

#8 Updated by intrigeri 10 months ago

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 10 months ago

  • 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 10 months ago

  • 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 10 months ago

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 #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 10 months ago

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

Too bad :/

#13 Updated by intrigeri 9 months ago

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

#14 Updated by segfault 7 months ago

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

#15 Updated by CyrilBrulebois 5 months ago

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

#16 Updated by anonym 4 months ago

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

#17 Updated by CyrilBrulebois 2 months ago

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

#18 Updated by intrigeri about 2 months ago

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 about 1 month ago

  • Description updated (diff)
  • 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:

  1. submit a MR that backports the code to GTK 3 and get it merged

Did that and it was already merged.

  1. 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 #16634, so I think we can mark this ticket as resolved.

#20 Updated by intrigeri about 1 month ago

\o/

#21 Updated by intrigeri 20 days ago

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

#22 Updated by anonym 19 days ago

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

#23 Updated by intrigeri 18 days ago

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

Also available in: Atom PDF