Opened 11 months ago

Last modified 2 months ago

#31729 new defect

Warning about missing GTK wayland related packages in configure script

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-rbm, ff68-esr, tbb-9.0, tbb-9.0-issues, gitlab-tb-tor-browser-build
Cc: boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When running the ESR 68 build on Linux one can see the following warnings

 0:10.19 WARNING: Package gtk+-wayland-3.0 was not found in the pkg-config search path.
 0:10.19 WARNING: Perhaps you should add the directory containing `gtk+-wayland-3.0.pc'
 0:10.19 WARNING: to the PKG_CONFIG_PATH environment variable
 0:10.19 WARNING: No package 'gtk+-wayland-3.0' found
 0:10.19 WARNING: Package xkbcommon was not found in the pkg-config search path.
 0:10.19 WARNING: Perhaps you should add the directory containing `xkbcommon.pc'
 0:10.19 WARNING: to the PKG_CONFIG_PATH environment variable
 0:10.19 WARNING: No package 'xkbcommon' found

Child Tickets

Change History (10)

comment:1 Changed 11 months ago by gk

I think Mozilla fixed that for their wheezy setup with patches. We might be able to copy that approach, not sure.

comment:3 Changed 11 months ago by boklm

So it seems Mozilla is building using backported Gtk+ 3.10 packages for wheezy:
https://bugzilla.mozilla.org/show_bug.cgi?id=1504906

And the resulting build is still compatible with Gtk+ 3.4:
https://phabricator.services.mozilla.com/D11141

We could do the same, either by building backported packages, or building it without packages. Unfortunately this requires backporting quite a few dependencies too:

        - deb7-atk
        - deb7-glib
        - deb7-gdk-pixbuf
        - deb7-harfbuzz
        - deb7-libxkbcommon
        - deb7-make
        - deb7-pango
        - deb7-pcre3
        - deb7-wayland

comment:4 Changed 11 months ago by gk

Hrm, that seems like a ton of work. What do you think? Should we squeeze that into 9.0? Or could that wait for, say, 9.5? Does not fixing that actually break things for users in the sense that Tor Browser becomes unusable or is it just a poorer experience?

comment:5 in reply to:  4 Changed 11 months ago by boklm

Replying to gk:

Hrm, that seems like a ton of work. What do you think? Should we squeeze that into 9.0? Or could that wait for, say, 9.5? Does not fixing that actually break things for users in the sense that Tor Browser becomes unusable or is it just a poorer experience?

Maybe that doing all of the packages rebuilding in a single projects/wheezy-backports/, using the same source packages as mozilla, won't be so much work. But maybe there are more complications to do that, so I'm not sure.

I tried running the alpha on a Debian 9 with Gnome on Wayland, and it started correctly (with the workaround for #31646). It seems it is using Xwayland automatically.

So it doesn't look like it makes Tor Browser unusable, so that probably could wait for a version 9.5.

comment:6 Changed 11 months ago by gk

Keywords: tbb-9.0 added
Parent ID: #30321

Okay, then let's keep this on our 9.0 radar but with lower prio.

comment:7 Changed 10 months ago by gk

Keywords: tbb-9.0-issues added

9.0 issues.

comment:8 Changed 2 months ago by sysrqb

Keywords: tbb-9.5-issues added; tbb-9.0-issues removed

Batch move remaining tbb-9.0-issues -> 9.5-issues

comment:9 Changed 2 months ago by sysrqb

Keywords: tbb-9.0-issues added; tbb-9.5-issues removed

comment:10 Changed 2 months ago by gk

Keywords: gitlab-tb-tor-browser-build added

Add magic gitlab keyword.

Note: See TracTickets for help on using tickets.