Bug#936371: dbus-python: Python2 removal in sid/bullseye
On Thu, 23 Jul 2020 at 18:01:55 +0100, peter green wrote: > dbus-python in testing build-depends on python-gi > which is no longer available in testing. This is fixed in > unstable but the fix is blocked from migrating to testing by > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965308 If jackd2 isn't fixed for a while, we'll have to choose one of these: - get jackd2 removed from testing - revert the removal of python-dbus, but drop the python-gi B-D and the python-gi dependency of the python2 autopkgtest (test coverage will be reduced, and python-dbus will be of limited practical use) - revert the removal of python-gi (revert pygobject 3.36.0-4) smcv
Bug#966361: gnome-shell: Windows preview render problem in overview
On Mon, 27 Jul 2020 at 10:16:50 -0300, Rômulo Penido wrote:
> Changing configurations on some extensions (Painel Mode in Dash to Dock, for
> example) changes the behavior
What extensions are enabled?
Does this problem persist if you disable all of the extensions you use?
If it does, please re-enable extensions one at a time to narrow down
which extension triggers it. The bug should probably be reassigned to
whichever extension (or combination of extensions) that is.
smcv
Bug#966150: openarena: undefined symbol: __atan2_finite on pak6-patch088/uix86_64.so
Control: tags -1 + confirmed On Thu, 23 Jul 2020 at 22:39:32 +0200, Jérémy Lal wrote: > "Failed loading /usr/lib/openarena/baseoa/pak6-patch088/uix86_64.so: > /usr/lib/openarena/baseoa/pak6-patch088/uix86_64.so: undefined symbol: > __atan2_finite" This seems to be a recent behaviour change, perhaps related to the recent upgrades to glibc 2.31 and gcc 10. The UI module has undefined references to symbols from libm. Previously, it was able to pick up those symbols because the executable (/usr/lib/ioquake3/ioquake3) is linked to libm, which puts libm's symbols in the global namespace that is used to satisfy undefined symbols in newly-loaded modules; but now it doesn't find that symbol. (Building these modules as native objects is not something that upstream supports very seriously, and the only reason we're doing that in Debian is that the bytecode version used by upstream needs the non-Free lcc compiler.) smcv
Bug#957285: gnome-control-center: ftbfs with GCC-10
On Fri, 17 Apr 2020 at 11:01:32 +, Matthias Klose wrote: > /usr/bin/ld: > panels/thunderbolt/libthunderbolt.a(meson-generated_.._bolt-enum-types.c.o):./obj-x86_64-linux-gnu/../panels/thunderbolt/bolt-error.h:40: > multiple definition of `BoltError'; > panels/thunderbolt/libthunderbolt.a(cc-bolt-device-dialog.c.o):./obj-x86_64-linux-gnu/../panels/thunderbolt/bolt-error.h:40: > first defined here This appears to have been fixed in upstream version 3.35.90 by commit 901ef8b0 "Thunderbolt: make BoltError enum a typedef; Fixes error when compiled with -fno-common". (I'm doing a test rebuild to confirm this.) If that's the case, the first version in Debian that is fixed would be 1:3.35.92-1. smcv
Bug#965963: ITP: wlr-randr -- Utility to manage outputs of a Wayland compositor
On Tue, 21 Jul 2020 at 14:27:43 +, Henry-Nicolas Tourneur wrote: > Description : Utility to manage outputs of a Wayland compositor > > Command line interface which allows setting the size, scale, orientation of > the > output for a screen. This is the wayland equivalent to xrandr under X11. How generically does this work? Do all major Wayland compositors (GNOME Shell, KDE KWin, Weston, the Sway/wlroots family, ...) implement the interfaces that it uses? If it only works on wlroots-based compositors, or some limitation like that, then it's still useful for users of those compositors, but the quoted description seems misleading; saying what the requirements are would help to set expectations. As far as I'm aware, some Wayland compositors (including GNOME Shell, I think) have it as a design goal that unprivileged clients *can't* make disruptive changes like switching between display modes. smcv
Bug#965345: mousetweaks: no longer used by GNOME, should be removed or transferred to a new maintainer
On Tue, 21 Jul 2020 at 19:20:30 +0900, Norbert Preining wrote:
> > - ${desktop}-control-center has options to enable mouse accessibility
> > (click-on-hover/"dwell clicks" and/or simulated secondary clicks),
> > but those options just set the value of a key in GSettings
>
> There is no code in cinnamon-control-center that references mousetweaks
> or it gconf setting.
That's a good point. In GNOME the UI for mouse a11y
features was always in gnome-control-center, but it
looks as though Cinnamon has moved it out of c-c-c and into
files/usr/share/cinnamon/cinnamon-settings/modules/cs_accessibility.py
in src:cinnamon. Look for "a11y.mouse".
So removing the Recommends from c-c-c was definitely correct, even if
you might want to add it back somewhere else (probably c-s-d).
This still looks like approximately "the same shape" as in GNOME -
UI in a settings app, controlling an implementation in a core desktop
component - which is really the only arrangement that could make sense
for features like this one.
(As a side note, this is GSettings, not gconf. GSettings is an abstraction
layer in GLib for the equivalent of GNOME 2's use of gconf. In practice
the backend for it on Unix systems is dconf, which is a more direct
replacement for gconf.)
smcv
Bug#965345: mousetweaks: no longer used by GNOME, should be removed or transferred to a new maintainer
On Tue, 21 Jul 2020 at 17:20:25 +0900, Norbert Preining wrote:
> > >* Drop mousetweaks recommends, not used anymore (Closes: #965345)
> >
> > Does this mean I was reading the cinnamon code wrong, and cinnamon
> > no longer needs mousetweaks, similar to GNOME?
>
> Where did you see that? I searched in the cinnamon-control-setting
> without success for any reference to mousetweaks.
>From what I saw in codesearch, it seems to be roughly the same as the
buster and older versions of GNOME, which makes sense since Cinnamon
is derived from an older version of GNOME:
- ${desktop}-control-center has options to enable mouse accessibility
(click-on-hover/"dwell clicks" and/or simulated secondary clicks),
but those options just set the value of a key in GSettings
- ${desktop}-settings-daemon is responsible for reading the GSettings
keys; if at least one of those two options is enabled, it starts
mousetweaks, or if both are disabled it stops mousetweaks
- mousetweaks also reads the GSettings keys to see what it should actually
do (dwell clicks, simulated secondary clicks or both)
Now that I look at it again, I don't understand how/whether the
Cinnamon implementation works. mousetweaks seems to read settings
from the org.gnome.desktop.a11y.mouse GSettings schema (part of
src:gsettings-desktop-schemas) to determine whether to enable dwell
clicks, simulated secondary clicks or both; but cinnamon-control-center
writes its settings to the org.cinnamon.desktop.a11y.mouse GSettings
schema (part of src:cinnamon-desktop) which mousetweaks isn't going to
read, unless I'm misunderstanding something. So perhaps this has never
actually worked in Cinnamon? I don't know - I don't use this feature
myself, and I use GNOME rather than Cinnamon. If it doesn't work, please
clone this into a bug report against an appropriate cinnamon component.
In testing/unstable GNOME, the options that would previously have used
mousetweaks are accessed via:
- Settings -> Universal Access -> Click Assist -> Simulated Secondary Click
- Settings -> Universal Access -> Click Assist -> Hover Click
but gnome-control-center has had a few redesigns and relayouts, so their
UI location was probably a bit different in Cinnamon and in older GNOME.
In both Cinnamon and older GNOME, the dependency was in
${desktop}-control-center for some reason; but I think it would have
been more appropriate to have it in ${desktop}-settings-daemon, since
that's where mousetweaks is actually mentioned. As I said, GNOME doesn't
need that any more because it has moved to a different implementation
that can work in Wayland, but I think Cinnamon maybe still does need
the X11-specific mousetweaks? (But then again, I can't see how it would
actually work, as described above, so maybe this is dead code that was
never tested.)
Code search:
https://codesearch.debian.net/search?q=mousetweaks=1=1
c-s-d implementation:
https://sources.debian.org/src/cinnamon-settings-daemon/4.6.4-1/plugins/mouse/csd-mouse-manager.c/?hl=1566#L1391
Equivalents in UKUI and MATE (which are #if 0):
https://sources.debian.org/src/ukui-settings-daemon/1.2.1-1/plugins/mouse/usd-mouse-manager.c/?hl=92#L1402
https://sources.debian.org/src/mate-settings-daemon/1.24.0-2/plugins/mouse/msd-mouse-manager.c/?hl=1782#L1612
cinnamon also checks for the mousetweaks package here:
https://sources.debian.org/src/cinnamon/4.6.6-1/files/usr/share/cinnamon/cinnamon-settings/modules/cs_accessibility.py/?hl=372#L372
MATE's onboard also seems to try to use mousetweaks:
https://sources.debian.org/src/onboard/1.4.1-5/Onboard/ClickSimulator.py/?hl=586#L586
If this feature is important to Cinnamon, I would recommend either talking
to GNOME upstream about taking over upstream maintenance of mousetweaks, or
absorbing the mousetweaks code into cinnamon-settings-daemon, or moving
this functionality into Cinnamon's compositor/window manager as a more
direct equivalent of what GNOME has done.
Or, if it isn't important to Cinnamon and doesn't work, I'd recommend
removing it from the UI and implementation (like UKUI and MATE have done)
to avoid misleading users.
smcv
Bug#965345: mousetweaks: no longer used by GNOME, should be removed or transferred to a new maintainer
Control: reopen -1 Reopening since this is a bug report against mousetweaks, not cinnamon, which should be closed when mousetweaks is either adopted or removed. > Changed-By: Norbert Preining > Closes: 965343 965345 > Changes: > cinnamon-control-center (4.6.1-2) unstable; urgency=medium ... >* Drop mousetweaks recommends, not used anymore (Closes: #965345) Does this mean I was reading the cinnamon code wrong, and cinnamon no longer needs mousetweaks, similar to GNOME? If that's the case, I'll ask for mousetweaks to be removed from Debian (unless someone, perhaps a GNOME or MATE maintainer, says they still need it and wants to take over maintenance). Thanks, smcv
Bug#964738: gnome-shell-extensions : On screen keyboard has missing icons for Enter, Shift, Caps-lock, alt keys
Control: reopen -1
Control: reassign -1 gnome-shell
Control: found -1 3.36.3-1
> Package: gnome-shell-extensions
Sorry, I didn't notice that this wasn't already a gnome-shell
bug. Reopening so that I can close it for the right package.
smcv
Bug#965080: Resignation + Call for votes for new Chair
On Wed, 15 Jul 2020 at 21:05:23 +0200, Margarita Manterola wrote: > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A : Philip Hands > B : Margarita Manterola > C : David Bremner > D : Niko Tyni > E : Gunnar Wolf > F : Simon McVittie > G : Sean Whitton > H : Elana Hashman > > ===END=== I vote A = B = C = D = E > F > G = H. smcv signature.asc Description: PGP signature
Bug#965358: Please update Widelands package to Build 21
Control: notfound -1 1:21-0 Control: found -1 1:20-2 On Mon, 20 Jul 2020 at 09:49:13 +0100, Fòram na Gàidhlig wrote: > We have just released a new version of Widelands Thanks for reporting this. "The version in Debian is out of date" can be considered to be a bug in the version currently in Debian testing/unstable, which will be fixed by the first upload of version 1:21 or later. I'm adjusting the metadata of this bug report accordingly. (I don't play Widelands myself, so I'm not intending to work on packaging this new version - hopefully someone else in the games team will.) smcv
Bug#956523: mousetweaks ends with segmentation fault
Control: forwarded -1 https://gitlab.gnome.org/GNOME/mousetweaks/-/issues/8
On Sun, 12 Apr 2020 at 12:50:42 +0200, Gero Treuner wrote:
> I'm using Gnome with Wayland (but stacktrace doesn't look like the
> issue is in that area anyway).
mousetweaks only supports X11, not Wayland. Please use the "GNOME on Xorg"
session type if you require the mouse accessibility features that it
provides ("hover click" and "simulated secondary click").
The crash[1] appears to be because mousetweaks assumes that the default
GDK display is X11. There is a merge request available upstream[2]
to make it exit more or less gracefully when run in a Wayland session,
instead of just crashing.
However, it will likely never *work* under Wayland, because in a Wayland
environment, ordinary client programs do not have sufficient control over
the compositor to do what mousetweaks does. In a Wayland environment,
the mouse accessibility features that mousetweaks provides have to be
implemented as part of the compositor itself, which was done in GNOME
3.34.x (for both Wayland and X11) and will be available as part of
Debian 11.
[1] https://gitlab.gnome.org/GNOME/mousetweaks/-/issues/8
[2] https://gitlab.gnome.org/GNOME/mousetweaks/-/merge_requests/3
> It looks to me that mousetweaks is founded on outdated Gnome bases and
> is not fit to serve for this purpose anymore.
As far as I know, it should still work in an X11 environment, such as
"GNOME on Xorg". It's also used by the GNOME-derived Cinnamon environment,
which I believe is purely an X11 environment and does not implement a
Wayland compositor, for their equivalent feature.
On Sun, 19 Jul 2020 at 22:05:16 +0300, Emre Uyguroglu wrote:
> See [1]https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/269
> The package should be dropped, it still ships with SID and segfaults as well
> same functionality is provided by "gnome-control-center -> universal access->
> click assist" now
In testing/unstable, you are correct to say that GNOME no longer needs
this. A future gnome-control-center upload will remove the Recommends.
It seems to still be used by Cinnamon, so I've opened a separate bug
asking whether the Cinnamon maintainers want to take over maintenance
of mousetweaks. If they do not, then yes, it should probably be dropped.
smcv
Bug#965324: python3-dbus: Missing dependency on the dbus-X11 package
Control: retitle -1 guake: missing dependency on default-dbus-session-bus|dbus-session-bus Control: reassign -1 guake 3.4.0-1 On Sun, 19 Jul 2020 at 16:49:47 +0200, Sergiy Kolesnikov wrote: > while running the Guake terminal emulator I encountered the following > exception: > > dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: > /usr/bin/dbus-launc > h terminated abnormally without any error message > > By installing the dbus-X11 package the problem was resolved and Guake ran > successfully. > > Since the exception was thrown in the dbus Python package, it looks like it > should depend on dbus-X11. python3-dbus can be used for several purposes, not all of which need a D-Bus session bus in your desktop environment. If an application requires the D-Bus session bus, it is up to that application to depend on it. There are multiple ways to get a session bus, so applications that require a D-Bus session bus and cannot work without it should usually depend on the virtual packages "default-dbus-session-bus | dbus-session-bus". For example, gnome-terminal does this correctly. dbus-session-bus is currently provided by dbus-user-session (only implemented on the Linux kernel, where it is the default) and by dbus-x11 (the default on non-Linux ports, and also available on Linux, mainly for systems that do not boot using systemd). If both implementations are installed, dbus-user-session is preferred. The error message mentions dbus-launch(1) because "X11 autolaunching", which uses dbus-launch, is the last mechanism attempted before giving up. Applications that benefit from a D-Bus session bus but do not strictly require it should use a weaker dependency on the same virtual packages, either Recommends or Suggests (I don't know which strength of dependency is most appropriate for guake). For example, xfce4-terminal uses Recommends for this. The version of guake in testing/unstable already indirectly depends on a D-Bus session bus, via GSettings, but ideally it would have this as a direct dependency too (assuming it's still a requirement). smcv
Bug#965317: gnome-shell: failed to write to XWayland
On Sun, 19 Jul 2020 at 12:58:06 +0200, EdiD wrote: > Gnome-shell crashes and (systemd) restarts DE. All running applications are > killed. Errors from log: > > gnome-shell[1119]: WL: error in client communication (pid 1119) > gnome-shell[1179]: (EE) failed to write to XWayland fd: Broken pipe I suspect this is happening because Xwayland has crashed (you can find out by looking at previous lines in the system log). If it is, please report that as a bug in Xwayland, with a backtrace: https://wiki.debian.org/HowToGetABacktrace It is unlikely to be possible to fix this without either a backtrace, or a sequence of instructions to reproduce the same crash. smcv
Bug#965216: policykit-1: Virtual Machine Manager is unauthorized after upgrade
On Fri, 17 Jul 2020 at 20:06:53 +0200, Christian Göttsche wrote: > After the upgrade to policykit-1 version 0.105-28 the Virtual Machine > Manager is unable to authorize (no password prompt pops up). This might be the upgrade issue I described in #965210. If it is, the workaround is to reboot, or to log out and back in. #965210 is very similar to the old bug #699447 in experimental, but with different versions and paths involved. > polkitd logs Log messages from your polkit agent (whatever package provides polkit-1-auth-agent, for example GNOME Shell, polkit-kde-agent-1 or lxpolkit) would help to confirm whether it's #965210. If it's #965210, you'd see something like this (quoting from #699447, the message might be a bit different in testing/unstable): Cannot spawn helper: Failed to execute child process "/usr/lib/policykit-1/polkit-agent-helper-1" (No such file or directory) If you get a message similar to that during the failure to authenticate, then this is probably a duplicate of #965210. smcv
Bug#964803: Debian Sid Alpha architecture dbus-daemon(6913): unaligned trap at 0000000000000000: 0000000082eaf0e0 28 18
alpha is not a release architecture, so expect it to have issues. On Sat, 11 Jul 2020 at 00:43:39 +0800, Антон Кочков wrote: > Preparing to unpack .../16-libpython3.8-dev_3.8.4~rc1-1_alpha.deb ... > Unpacking libpython3.8-dev:alpha (3.8.4~rc1-1) ... > [ 406.873815] dbus-daemon(6913): unaligned trap at : > 82eaf0e0 28 18 Can alpha kernels be configured to make processes crash with a core dump on unaligned access, like /proc/cpu/alignment on ARM? It is unlikely to be possible to solve this in dbus without having a backtrace for each unaligned access that indicates where the problem occurred. smcv
Bug#964723: Ordering of entries: the calibre opens everything problem
On Fri, 10 Jul 2020 at 14:57:24 +0900, Charles Plessy wrote:
> I just remembered it is more complicated: the FreeDesktop menu entries
> do not contain priority values.
As far as I'm aware, this is deliberate, for two reasons:
* The authors and maintainers of individual viewers (evince, calibre,
okular, etc.) are not well-placed to choose priorities, because
*obviously* they think theirs is the best, otherwise they wouldn't be
continuing to develop it. The best you're likely to get from priorities
is that the maintainers of things that know they *shouldn't* be the
default, like gimp opening PDFs (which it can, but that's rarely what
anyone wants), can choose an artificially low priority.
* To get well-integrated desktop environments, the default choice of viewer
ought to be desktop-specific: if a GNOME user and a KDE user share a
computer, neither user has expressed any preference about their PDF
viewer, and they both open a PDF, then the GNOME user ought to get
evince and the KDE user ought to get okular. (Obviously the user's
choice, *if they have expressed a choice*, should be prioritized higher
than this - but we need sensible defaults.)
> The informations used by the Desktop
> Environment systems to sort entries in their menus are somewhere else,
> and I have not found yet...
/usr/share/applications/${desktop}-mimeapps.list, where ${desktop} is
one of the colon-separated values in $XDG_CURRENT_DESKTOP, transformed
into lower case. For example, GNOME sets XDG_CURRENT_DESKTOP=GNOME, and
gnome-session-common provides /usr/share/applications/gnome-mimeapps.list.
I think Ubuntu's Unity used to set XDG_CURRENT_DESKTOP=Unity:GNOME (read
as "Unity, which is similar to/based on GNOME"), which means it would use
/usr/share/applications/unity-mimeapps.list, falling back to the GNOME
list for anything not found there.
Full specification:
https://specifications.freedesktop.org/mime-apps-spec/latest/
smcv
Bug#964728: gtk-doc-tools: gtkdoc-scangobj fails in mipsel / Loongson when building webkit2gtk
On Thu, 09 Jul 2020 at 17:42:35 +0200, Alberto Garcia wrote: > the mipsel build of webkit2gtk is failing because of gtkdoc-scangobj: ... > This is only happening on the mipsel builds, and I cannot reproduce > the problem in eller.debian.org. Adrian Bunk says it fails on the > Loongson buildds but succeeds on the others. gtkdoc-scangobj works by compiling a small C program that it uses to introspect GObject types. According to the build log, that program exited with status -6 (which is probably Python's representation of it being killed by signal 6, which is SIGABRT?) with no output. The Loongson 3A "is known for having an FPU bug" (see #959845) - perhaps that could be related, if webkit2gtk contains GObject types with G_TYPE_FLOAT or G_TYPE_DOUBLE values? I'm not sure what individual packages can do about this, or why we are using known-faulty CPUs on official buildds. This is likely to be "won't fix" (or rather "can't fix") for gtk-doc-tools, unless someone with a suitably faulty FPU can reproduce the bug and figure out what is going on. Workaround: instead of 8< ifneq (,$(filter nodoc,$(DEB_BUILD_OPTIONS))) EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=OFF else EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=ON endif 8< webkit2gtk could use something like 8< binaries := $(shell dh_listpackages) ifneq (,$(filter %-doc,$(binaries))) EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=OFF else EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=ON endif 8< together with 8< Package: libwebkit2gtk-4.0-doc Build-Profiles: 8< so that you don't run gtk-doc in architecture-specific builds, only in builds that include Architecture: all. That would also be faster, and you might be able to move gtk-doc-tools from Build-Depends to Build-Depends-Indep (usually you can for Meson, but not for Autotools because it's needed at dh_autoreconf time; I don't know which category CMake falls into). smcv
Bug#961756: glib-networking: CVE-2020-13645: GTlsClientConnection silently ignores unset server identity
On Thu, 28 May 2020 at 22:41:19 +0200, Salvatore Bonaccorso wrote:
> CVE-2020-13645[0]:
> | In GNOME glib-networking through 2.64.2, the implementation of
> | GTlsClientConnection skips hostname verification of the server's TLS
> | certificate if the application fails to specify the expected server
> | identity. This is in contrast to its intended documented behavior, to
> | fail the certificate verification. Applications that fail to provide
> | the server identity, including Balsa before 2.5.11 and 2.6.x before
> | 2.6.1, accept a TLS certificate if the certificate is valid for any
> | host.
A reproducer is available from
https://gitlab.gnome.org/GNOME/balsa/-/issues/34 (look for
test-tls.tar.xz).
Preconditions:
* Compile the test program from test-tls.tar.xz (attached)
* Have a test server with two names, and no valid cert for one of them.
people.debian.org works: it has a valid cert for people.debian.org,
but not for paradis.debian.org. (Check this with a browser first,
in case SNI gets added later.)
Bad result: connecting without specifying a server identity succeeds.
$ sudo apt-get install glib-networking=2.58.0-2
$ ./test_server_valid people.debian.org:443 0
** Message: 09:16:43.133: set remote server_identity: no
** Message: 09:16:43.534: g_tls_connection_handshake(): OK (no error)
$ ./test_server_valid people.debian.org:443 1
** Message: 09:16:02.406: set remote server_identity: yes
** Message: 09:16:02.779: g_tls_connection_handshake(): OK (no error)
$ ./test_server_valid paradis.debian.org:443 0
** Message: 09:18:36.097: set remote server_identity: no
** Message: 09:18:36.495: g_tls_connection_handshake(): OK (no error)
$ ./test_server_valid paradis.debian.org:443 1
** Message: 09:18:37.722: set remote server_identity: yes
** Message: 09:18:38.132: cert_accept_cb: conn=0x561d080d8150,
cert=0x7fdbcc005eb0 for 'people.debian.org', error=0x2
** Message: 09:18:38.132: g_tls_connection_handshake(): ERROR (Unacceptable TLS
certificate)
Good result: the only way to avoid G_TLS_CERTIFICATE_BAD_IDENTITY is to
specify the server's name in the form that appears in its certificate.
$ sudo dpkg -i glib-networking_2.58.0-2+deb10u1_amd64.deb
$ ./test_server_valid people.debian.org:443 0
** Message: 09:20:01.640: set remote server_identity: no
** Message: 09:20:02.045: cert_accept_cb: conn=0x55afead25150,
cert=0x7f1f3c005eb0 for 'people.debian.org', error=0x2
** Message: 09:20:02.045: g_tls_connection_handshake(): ERROR (Unacceptable TLS
certificate)
$ ./test_server_valid people.debian.org:443 1
** Message: 09:20:03.338: set remote server_identity: yes
** Message: 09:20:03.737: g_tls_connection_handshake(): OK (no error)
$ ./test_server_valid paradis.debian.org:443 0
** Message: 09:20:08.924: set remote server_identity: no
** Message: 09:20:09.332: cert_accept_cb: conn=0x5620d607a150,
cert=0x7f38500066b0 for 'people.debian.org', error=0x2
** Message: 09:20:09.332: g_tls_connection_handshake(): ERROR (Unacceptable TLS
certificate)
$ ./test_server_valid paradis.debian.org:443 1
** Message: 09:20:10.552: set remote server_identity: yes
** Message: 09:20:10.954: cert_accept_cb: conn=0x560a74e26150,
cert=0x7f88e8005eb0 for 'people.debian.org', error=0x2
** Message: 09:20:10.955: g_tls_connection_handshake(): ERROR (Unacceptable TLS
certificate)
(0x2 is G_TLS_CERTIFICATE_BAD_IDENTITY.)
smcv
/*
gcc -Wall -O -g $(pkg-config --cflags glib-2.0 gio-2.0 gcr-3) test_server_valid.c -o test_server_valid \
$(pkg-config --libs glib-2.0 gio-2.0 gcr-3)
*/
#include
#include
#include
#define GCR_API_SUBJECT_TO_CHANGE
#include
static gboolean
cert_accept_cb(GTlsConnection *conn, GTlsCertificate *peer_cert, GTlsCertificateFlags errors, gpointer user_data)
{
GByteArray *der_data;
GcrCertificate *gcr_cert;
gchar *subject;
g_object_get(peer_cert, "certificate", _data, NULL);
gcr_cert = gcr_simple_certificate_new(der_data->data, der_data->len);
g_byte_array_unref(der_data);
subject = gcr_certificate_get_subject_name(gcr_cert);
g_object_unref(gcr_cert);
g_message("%s: conn=%p, cert=%p for '%s', error=0x%x", __func__, conn, peer_cert, subject, errors);
g_free(subject);
return FALSE;
}
int main(int argc, char **argv)
{
GSocketClient *sock;
GSocketConnectable *remote_address;
GSocketConnection *plain_conn;
GIOStream *tls_conn;
gboolean set_ident;
gboolean tls_ok;
GError *error = NULL;
if (argc < 3) {
g_error("usage: %s connect 0|1 [cafile]", argv[0]);
}
set_ident = (atoi(argv[2]) != 0);
sock = g_socket_client_new();
remote_address = g_network_address_parse(argv[1], 65000, );
if (remote_address == NULL) {
g_error("g_network_address_parse(%s): %s", argv[1], error->message);
}
plain_conn = g_socket_client_connect(sock, remote_address, NULL, );
if (plain_conn == NULL) {
g_error("g_socket_client_connect(): %s", error->message);
}
g_message("set remote server_identit
Bug#964185: freetype2.pc depends on libbrotlidec.pc without a dependency on the libbrotli-dev package
On Fri, 03 Jul 2020 at 21:16:44 +0300, Michael Tokarev wrote: > On Fri, 03 Jul 2020 18:45:07 +0900 Mike Hommey > wrote: > .. > > Arguably, freetype2.pc shouldn't depend on libbrotlidec.pc except with a > > Required.private, assuming one doesn't actually need to include > > libbrotli headers or link against libbrotli library (presumably, that's > > the case). > > The thing is that libbrotli *is* in Requires.private, and pkg-config still > insists on it to exist. This is because there are three possible "weights" of dependency, and only two dependency lists in a .pc file, so the dependency lists cannot possibly be 100% correct for all three "weights". In decreasing order of "weight": 1. Public dependency: depending on A guarantees availability of B because they are inextricably linked, and you can't use A without B (for example GTK depends on GLib like this). This is Requires. pkg-config --cflags A includes B. pkg-config --libs A includes B. pkg-config --static --cflags A includes B. pkg-config --static --libs A includes B. A-dev must depend on B-dev. 2. Use of data structures: some header files from A include header files, macros, data structures from B; it is possible to use A without directly linking to B, but you can't successfully #include all the headers of A unless you have B-dev installed (for example GTK depends on Pango like this, I think). This is Requires.private. pkg-config --cflags A includes B. pkg-config --libs A does not include B. pkg-config --static --cflags A includes B. pkg-config --static --libs A includes B. A-dev must depend on B-dev, even if you don't care about static linking. 3. Implementation detail: A uses B internally, but does not mention it in its header files at all. It is possible to use A without having B-dev, *unless* you are linking statically (for example GTK depends on epoxy like this). pkg-config does not have a representation for this at the moment, although a new Requires.internal was proposed in 2018 (<https://bugs.freedesktop.org/show_bug.cgi?id=105572>). Requires.private behaved like this before 2007 (#390132), but we have had 13 years of packages depending on Requires.private's new meaning, so reverting that change would be harmful. Ideally the behaviour here would be: pkg-config --cflags A should not include B. pkg-config --libs A should not include B. pkg-config --static --cflags A should not include B. pkg-config --static --libs A should include B. A-dev does not need to depend on B-dev unless you care about static linking (so maybe weakening it to a Recommends or Suggests would be OK). Known workarounds for the nonexistence of Requires.internal are: * Don't mention B in A.pc at all. Statically linking A will not work. This is perhaps the least bad solution if A or one of its dependencies is shared-only and does not support static linking, for example Mesa or libsystemd, but it's difficult to make that decision in practice. For example, libdbus conditionally depends on libsystemd, so it cannot easily be statically linked *in Debian* - but I think the same upstream source code *can* be statically linked in Devuan or on non-Linux, where the libsystemd dependency is disabled, so it is not straightforward for the upstream developer to know whether static linking is supported when generating the .pc file. * Put B and all its recursive dependencies in Libs.private, which is not great because it requires hard-coding part of the information you got from B.pc into A.pc, meaning A.pc can be out of date if B.pc has changed (for example gaining a dependency) since A was built. * Strengthen the dependency to Requires.private. This is what usually happens in practice (as in this case), and means you need B-dev installed even though in principle shared linking shouldn't need it. smcv
Bug#963813: evince: segmentation fault in evince opening rfc8798.pdf
Control: reassign -1 libpoppler-glib8 0.71.0-6
Control: affects -1 + evince
Control: notfound -1 0.85.0-1
On Sat, 27 Jun 2020 at 21:44:46 +0200, Erik Auerswald wrote:
>I wanted to read the PDF version of the IETF RFC 8798 document using
>evince, the GNOME Document Viewer. This public standard document is
>accessible at https://www.rfc-editor.org/rfc/rfc8798.pdf .
>
>When trying to open the PDF file with evince using
>
> evince rfc8708.pdf
>
>the GNOME Document Viewer "evince" crashes with a segmentation fault.
I can reproduce this on unstable (note to poppler maintainers: the
original report was against buster). Here's a backtrace.
It looks as though a PopplerAttachment somehow has an invalid pointer
at attachment->checksum, so I'm guessing this is more likely to be a
bug in the poppler library than in evince.
This appears to have been fixed in libpoppler-glib8_0.85.0-1 in
experimental (or at least, I can't reproduce it in that version) so
perhaps there is a fix that can be backported.
Regards,
smcv
Thread 6 "EvJobScheduler" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f491e4ec700 (LWP 139528)]
0x7f4926f67c7c in g_string_free (string=0x,
free_segment=free_segment@entry=1) at ../../../glib/gstring.c:215
215 ../../../glib/gstring.c: No such file or directory.
(gdb) bt full
#0 0x7f4926f67c7c in g_string_free (string=0x,
free_segment=free_segment@entry=1) at ../../../glib/gstring.c:215
_g_boolean_var_ =
segment =
__func__ = "g_string_free"
#1 0x7f491dc22c53 in poppler_attachment_finalize(GObject*)
(obj=0x55d1dde5d460 [PopplerAttachment])
at ./glib/poppler-attachment.cc:88
attachment = 0x55d1dde5d460 [PopplerAttachment]
#2 0x7f492703509e in g_object_unref (_object=) at
../../../gobject/gobject.c:3499
weak_locations =
old_ref =
__func__ = "g_object_unref"
object = 0x55d1dde5d460 [PopplerAttachment]
__func__ = "g_object_unref"
#3 g_object_unref (_object=0x55d1dde5d460) at ../../../gobject/gobject.c:3391
object = 0x55d1dde5d460 [PopplerAttachment]
__func__ = "g_object_unref"
#4 0x7f491dc9817e in
pdf_document_attachments_get_attachments(EvDocumentAttachments*)
(document=)
at ev-poppler.cc:4222
ev_attachment =
data = 0x55d1de094960 "\nhttp://www.w3.org/2001/XInclude\; version=\"3\" category=\"std\"
consensus=\"true\" docName=\"draft-ietf-core-senml-more-units-06\"
indexInclude=\"true\" ipr"...
attachment = 0x55d1dde5d460 [PopplerAttachment]
size = 51880
error = 0x0
pdf_document =
attachments =
list = 0x55d1ddb16c20 = {0x55d1dde5d460}
retval = 0x55d1ddb17180 = {0x55d1dde3b560}
#5 0x7f4927d8b77a in ev_job_attachments_run (job=0x55d1dde5d630
[EvJobAttachments]) at ev-jobs.c:472
job_attachments = 0x55d1dde5d630 [EvJobAttachments]
#6 0x7f4927d8d7da in ev_job_thread (job=0x55d1dde5d630 [EvJobAttachments])
at ev-job-scheduler.c:184
result =
job = 0x55d1ddc582f0
#7 ev_job_thread_proxy (data=) at ev-job-scheduler.c:217
job = 0x55d1ddc582f0
#8 0x7f4926f6e52d in g_thread_proxy (data=0x55d1dde36580) at
../../../glib/gthread.c:807
thread = 0x55d1dde36580
__func__ = "g_thread_proxy"
#9 0x7f4926d97f27 in start_thread (arg=) at
pthread_create.c:479
ret =
pd =
unwind_buf =
{cancel_jmp_buf = {{jmp_buf = {139952017819392,
4879852856656241710, 140730885663534, 140730885663535, 139952017816704,
139952017819392, -4815890835605576658, -4815766494322252754}, mask_was_saved =
0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0,
canceltype = 0}}}
not_first_call = 0
#10 0x7f4926cc931f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
