Bug#956187: firejail-profiles: Updated profile for Microsoft Teams for Linux

[Patrik Flykt]

On Sun, 2020-04-12 at 16:33 +0200, Reiner Herrmann wrote:
> Control: tags -1 + fixed-upstream
> 
> Hi Patrik,
> 
> thanks for the patch.
> A little different profile for teams is already available in the
> upstream repository [1].
> It will be included in the next release/upload.

That sounds like an excellent plan.

Thanks,

Patrik

Bug#956187: firejail-profiles: Updated profile for Microsoft Teams for Linux

[Patrik Flykt]

Package: firejail-profiles
Version: 0.9.62-3
Severity: important
Tags: patch

Dear Maintainer,

Microsoft Teams for Linux has been updated with a packagad desktop
version of their program which can be downloaded when visiting
https://teams.microsoft.com. The new Teams Debian package comes with
a renamed application 'teams' and uses a few more standard command
line tools. To support the new version, I created a new
'teams.profile' to match the name of the binary and allows access
to the new helper programs that package is using.

I don't know if the current teams-for-linux will still work, if not
that one could be retired and all of the profile information updated
to a profile using the name of the new binary.

The new teams.profile is:
---
include teams-for-linux.profile

whitelist ${HOME}/.config/teams
whitelist ${HOME}/.config/Microsoft/Microsoft Teams

private-bin teams,readlink,dirname,mkdir,nohup
---

Please test,

Patrik



-- System Information:
Debian Release: bullseye/sid
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'testing'), (500, 'oldstable-updates'), 
(500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.5.15 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firejail-profiles depends on:
ii  firejail  0.9.62-3

firejail-profiles recommends no packages.

firejail-profiles suggests no packages.

-- no debconf information

Bug#930084: shotwell: Replace Picasaweb with Google Photos publishing

[Patrik Flykt]

Package: shotwell
Version: 0.30.4
Severity: important
Tags: upstream

Dear Maintainer,

Please update shotwell to 0.30.4 or apply fix in commit
de38dccbe2783f468107879ce23a4f0f7177a2aa, which is about replacing Picasaweb
support with Google Photos publishing. Picasaweb API support has ended as of
April 2019, thus photo publishing to Google Photos has ceased to work some time
ago.

My version of shotwell is off by 0.0.3 versions, I compiled shotwell from
sources to verify that the Google Photos bug is actually fixed.

Thanks,

Patrik



-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'stable'), (500, 'stable-updates'), (500, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.0.19 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_SOFTLOCKUP
Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages shotwell depends on:
ii  dbus-x11 1.12.14-1
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  dconf-tools  0.26.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libexif120.6.21-5.1
ii  libgcr-base-3-1  3.28.1-1
ii  libgcr-ui-3-13.28.1-1
ii  libgdata22   0.17.9-3
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgee-0.8-2 0.20.1-2
ii  libgexiv2-2  0.10.9-1
ii  libglib2.0-0 2.58.3-2
ii  libgphoto2-6 2.5.22-3
ii  libgphoto2-port122.5.22-3
ii  libgstreamer-plugins-base1.0-0   1.14.4-2
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.5-1
ii  libgudev-1.0-0   232-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libraw19 0.19.2-2
ii  librsvg2-common  2.44.10-2.1
ii  libsoup2.4-1 2.64.2-2
ii  libsqlite3-0 3.27.2-2
ii  libwebkit2gtk-4.0-37 2.24.2-1
ii  libxml2  2.9.4+dfsg1-7+b3

Versions of packages shotwell recommends:
ii  desktop-file-utils  0.23-4

shotwell suggests no packages.

-- no debconf information

Bug#921454: firejail-profiles: Zoom does not find its login information when run with firejail

[Patrik Flykt]

Package: firejail-profiles
Version: 0.9.58-1
Severity: important
Tags: patch

Dear Maintainer,

Starting a recent version of Zoom videoconferencing binary
(https://www.zoom.us) with '/usr/bin/firejail /usr/bin/zoom %u' causes Zoom not
to remember any of its login information.

The fix was to locally modify the Zoom firejail file /etc/firejail/zoom.local
by adding the following lines:
noblacklist ${HOME}/.zoom
whitelist ${HOME}/.config/zoomus.conf

The 'noblacklist' addition looks for some reason a bit redundant, but I could
not make Zoom work without it either. The whole modification looks to me as the
config file for Zoom has moved around since earlier releases.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'stable'), (500, 'stable-updates'), (500, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.20.6 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firejail-profiles depends on:
ii  firejail  0.9.58-1

firejail-profiles recommends no packages.

firejail-profiles suggests no packages.

-- no debconf information

Bug#885920: [firefox] Firefox window doesn't show under wayland

[Patrik Flykt]

> That explains it. Verified that Firefox works on GNOME/X11, enforcing
> GDK_BACKEND=x11 doesn't help either with wayland. Seems I need to
 > wait for newer Firefox versions and use X11 meanwhile.

With current Debian testing, there is no longer a problem. So some
(combination of) user space components contributed to the issues seen,
and Firefox works just fine now. Actually things started to work fine
some time ago, but I forgot about this bug report.

Bug#885920: [firefox] Firefox window doesn't show under wayland

[Patrik Flykt]

I think I see the very same issue that affects also firefox 58.0.1-1.

To make matters more complex, Firefox starts with GNOME/wayland on an
laptop with an integrated Intel graphics chip just fine, but fails to
show a window on an desktop with AMD graphics card (Oland, Radeon R7
240/340) just as described in this bug. Poking with gdb on the second
process/thread on the desktop where the firefox window is not shown
gives the following output:

$ gdb -p 3414
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 3414
[New LWP 3429]
[New LWP 3430]
[New LWP 3431]
[New LWP 3432]
[New LWP 3433]
[New LWP 3434]
[New LWP 3435]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
38  ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory.
(gdb) where
#0  0x7f551369ce19 in syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7f54fec7ebca in xshmfence_await () at 
/usr/lib/x86_64-linux-gnu/libxshmfence.so.1
#2  0x7f54ff6e522b in dri3_fence_await (buffer=0x7f54f619d4c0, 
draw=0x7f54fe103e98, c=)
at ../../../src/loader/loader_dri3_helper.c:187
#3  0x7f54ff6e522b in dri3_get_buffer (format=format@entry=4098, 
buffer_type=buffer_type@entry=
loader_dri3_buffer_front, draw=draw@entry=0x7f54fe103e98, 
driDrawable=)
at ../../../src/loader/loader_dri3_helper.c:1463
#4  0x7f54ff6e5f3d in loader_dri3_get_buffers (driDrawable=, 
format=4098, stamp=0x7f551308b800, loaderPrivate=0x7f54fe103e98, buffer_mask=2, 
buffers=0x7ffe3932ccb0) at ../../../src/loader/loader_dri3_helper.c:1578
#5  0x7f54fd61e976 in dri_image_drawable_get_buffers 
(statts_count=, statts=, images=, 
drawable=) at 
../../../../../src/gallium/state_trackers/dri/dri2.c:466
#6  0x7f54fd61e976 in dri2_allocate_textures (ctx=0x7f54fe11ce20, 
drawable=0x7f551308b800, statts=
0x7f54fe144c60, statts_count=1) at 
../../../../../src/gallium/state_trackers/dri/dri2.c:590
#7  0x7f54fd619e5c in dri_st_framebuffer_validate (stctx=, 
stfbi=, statts=
0x7f54fe144c60, count=1, out=0x7ffe3932ce50) at 
../../../../../src/gallium/state_trackers/dri/dri_drawable.c:85
#8  0x7f54fd4c03c9 in st_framebuffer_validate (stfb=0x7f54fe144800, 
st=st@entry=0x7f54f61c)
at ../../../src/mesa/state_tracker/st_manager.c:197
#9  0x7f54fd4c18a0 in st_api_make_current (stapi=, 
stctxi=0x7f54f61c, stdrawi=0x7f551308b800, streadi=0x7f551308b800) at 
../../../src/mesa/state_tracker/st_manager.c:995
#10 0x7f54fd6198f6 in dri_make_current (cPriv=, 
driDrawPriv=0x7f54f61ae840, driReadPriv=0x7f54f61ae840)
at ../../../../../src/gallium/state_trackers/dri/dri_context.c:280
#11 0x7f54fd618786 in driBindContext (pcp=, pdp=, prp=)
at ../../../../../../src/mesa/drivers/dri/common/dri_util.c:564
#12 0x7f54ff6df346 in dri3_bind_context (context=0x7f54fe103b40, 
old=, draw=35651586, read=35651586)
at ../../../src/glx/dri3_glx.c:199
#13 0x7f54ff6b21d9 in MakeContextCurrent (dpy=0x7f55130ca000, 
draw=35651586, read=35651586, gc_user=0x7f54fe103b40)
at ../../../src/glx/glxcurrent.c:228
#14 0x7f54ffbc21dd in  () at /usr/lib/x86_64-linux-gnu/libGLX.so.0
#15 0x7f54ffbc2bd5 in  () at /usr/lib/x86_64-linux-gnu/libGLX.so.0
#16 0x7f54ffbc41d6 in  () at /usr/lib/x86_64-linux-gnu/libGLX.so.0
#17 0x7f550752715c in  () at /usr/lib/firefox/libxul.so
#18 0x7f5507527377 in  () at /usr/lib/firefox/libxul.so
#19 0x7f550751ccee in  () at /usr/lib/firefox/libxul.so
#20 0x7f550752233f in  () at /usr/lib/firefox/libxul.so
#21 0x7f5507522b32 in  () at /usr/lib/firefox/libxul.so
#22 0x564ce39fb72c in  ()
#23 0x564ce39fae99 in  ()
#24 0x7f55135cdf2a in __libc_start_main (main=
0x564ce39fae30, argc=1, argv=0x7ffe3932eb28, init=, 
fini=, rtld_fini=, stack_end=0x7ffe3932eb18) at 
../csu/libc-start.c:310
#25 0x564ce39fb1aa in _start ()

Hope this helps a bit.

Bug#805167: "Regression: rpcbind doesn't start at boottime on systemd controlled machines."

[Patrik Flykt]

> Can I add that the problem also exists on my machine, with nfs-common and 
> autofs as the 
> dependent services?
> 
> My home directories are automounted from an NFS server, but lately I have to 
> manually 
> restart rpcbind and nfs-common before my NFS client finally connects. Reading 
> the 
> output of systemctl status nfs-common shows that nfs-common fails to 
> correctly start 
> because rpcbind isn't running, and just restarting nfs-common does nothing 
> for rpcbind.

On my machine I discovered this in the logs:
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found ordering cycle on 
nfs-common.service/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
rpcbind.target/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
rpcbind.service/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
rpcbind.socket/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
sysinit.target/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
nfs-common.service/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Breaking ordering cycle 
by deleting job rpcbind.target/start
Jan 26 14:40:14 xx systemd[1]: rpcbind.target: Job rpcbind.target/start 
deleted to break ordering cycle starting with nfs-comm

Since DefaultDependencies is not disabled, rpcbind.socket ends up
depending on sysinit.target. From the above one can see a cycle forming,
which is (correctly) solved by throwing out one of the offending units.

DefaultDependencies should be set to 'no' for early boot, as is the case
for the provided rpcbind.service file. Also rpcbind.socket needs to be
updated with these, i.e. by modifying the following lines in its unit
section:

[Unit]
DefaultDependencies=no
Conflicts=shutdown.target
Before=shutdown.target
After=systemd-tmpfiles-setup.service

The easiest way of applying the modification is to add the above lines
to a .conf file in the /etc/systemd/system/rpcbind.socket.d/ directory.

This solved my problem of unmounted krb5p secured NFS /home and other
directories on bootup.

HTH.

Bug#690536: wpasupplicant does not enable AP mode at compile time

[Patrik Flykt]

Package: wpasupplicant
Version: 1.0-3

wpa_supplicant doesn't enable Access Point mode compile-time
configuration option anymore. The debian/changelog file says AP mode was
enabled in version 0.7.3-1, but doesn't mention the feature being
intentionally disabled after that.

Access point mode is needed by ConnMan to enable tethering over WiFi. It
is also needed by any other network management software, e.g.
NetworkManager, which intends to support tethering over WiFi. Thus it
would be nice to have it enabled by default.

Here is a patch to re-enable AP mode:


diff -ru a/debian/config/wpasupplicant/kfreebsd 
b/debian/config/wpasupplicant/kfreebsd
--- wpa-1.0_old/debian/config/wpasupplicant/kfreebsd2012-10-08 
19:32:27.0 +0300
+++ wpa-1.0_new/debian/config/wpasupplicant/kfreebsd2012-10-15 
12:51:21.735613929 +0300
@@ -469,3 +469,6 @@
 
 # XXX: Debian #650834
 CONFIG_BGSCAN_SIMPLE=y
+
+# Enable access point mode
+CONFIG_AP=Y
diff -ru a/debian/config/wpasupplicant/linux b/debian/config/wpasupplicant/linux
--- wpa-1.0_old/debian/config/wpasupplicant/linux   2012-10-08 
19:32:27.0 +0300
+++ wpa-1.0_new/debian/config/wpasupplicant/linux   2012-10-15 
12:50:44.977185881 +0300
@@ -468,3 +468,6 @@
 
 # XXX: Debian #650834
 CONFIG_BGSCAN_SIMPLE=y
+
+# Enable access point mode
+CONFIG_AP=Y


With the above configuration change, AP mode support is restored. I
don't know whether the same configuration switch is to be applied for
the udebs or not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org