Bug#1064170: mediastreamer2: NMU diff for 64-bit time_t transition
X-Debbugs-CC: Steve Langasek , Sebastian Ramacher Can I get confirmation that this will get uploaded before the autoremoval from testing on April 15th? Message #17 has the fixed NMU patch. Regards.
Bug#1064170: mediastreamer2: NMU diff for 64-bit time_t transition
X-Debbugs-CC: Steve Langasek
On Sat, Feb 17, 2024 at 04:27:04PM -0800, Steve Langasek wrote:
> Unfortunately, this has not been uploaded because mediastreamer2 appears to
> have a preexisting FTBFS in unstable due to missing cmake commands.
The NMU patch missed the library package name mentioned in
debian/rules. Attached is a fixed revision of the patch (last hunk).
Regards.
diff -Nru mediastreamer2-5.2.0+dfsg/debian/changelog
mediastreamer2-5.2.0+dfsg/debian/changelog
--- mediastreamer2-5.2.0+dfsg/debian/changelog 2024-01-30 14:30:19.0
+
+++ mediastreamer2-5.2.0+dfsg/debian/changelog 2024-02-18 00:13:01.0
+
@@ -1,3 +1,10 @@
+mediastreamer2 (1:5.2.0+dfsg-3.2) experimental; urgency=medium
+
+ * Non-maintainer upload.
+ * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek Sun, 18 Feb 2024 00:13:01 +
+
mediastreamer2 (1:5.2.0+dfsg-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru mediastreamer2-5.2.0+dfsg/debian/control
mediastreamer2-5.2.0+dfsg/debian/control
--- mediastreamer2-5.2.0+dfsg/debian/control2024-01-30 14:30:14.0
+
+++ mediastreamer2-5.2.0+dfsg/debian/control2024-02-18 00:13:01.0
+
@@ -58,7 +58,10 @@
Vcs-Browser:
https://salsa.debian.org/pkg-voip-team/linphone-stack/mediastreamer2
Description: Multimedia streaming engine for telephony
-Package: libmediastreamer13
+Package: libmediastreamer13t64
+Provides: ${t64:Provides}
+Replaces: libmediastreamer13
+Breaks: libmediastreamer13 (<< ${source:Version})
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends},
@@ -86,7 +89,7 @@
Section: libdevel
Architecture: any
Multi-Arch: same
-Depends: libmediastreamer13 (= ${binary:Version}),
+Depends: libmediastreamer13t64 (= ${binary:Version}),
${misc:Depends},
# the .pc file mentions these 2, so a Depends: is needed
# also the headers reference files from these 2
diff -Nru mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13.install
mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13.install
--- mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13.install 2024-01-30
14:20:36.0 +
+++ mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13.install 1970-01-01
00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/*/libmediastreamer.so.*
diff -Nru mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13.shlibs
mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13.shlibs
--- mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13.shlibs 2024-01-30
14:20:36.0 +
+++ mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13.shlibs 1970-01-01
00:00:00.0 +
@@ -1 +0,0 @@
-libmediastreamer 13 libmediastreamer13 (>= 1:5.2.0-1), libmediastreamer13 (<<
1:5.3.0-1)
diff -Nru mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13t64.install
mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13t64.install
--- mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13t64.install
1970-01-01 00:00:00.0 +
+++ mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13t64.install
2024-01-30 14:20:36.0 +
@@ -0,0 +1 @@
+usr/lib/*/libmediastreamer.so.*
diff -Nru
mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13t64.lintian-overrides
mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13t64.lintian-overrides
--- mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13t64.lintian-overrides
1970-01-01 00:00:00.0 +
+++ mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13t64.lintian-overrides
2024-02-18 00:13:01.0 +
@@ -0,0 +1 @@
+libmediastreamer13t64: package-name-doesnt-match-sonames libmediastreamer13
diff -Nru mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13t64.shlibs
mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13t64.shlibs
--- mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13t64.shlibs
1970-01-01 00:00:00.0 +
+++ mediastreamer2-5.2.0+dfsg/debian/libmediastreamer13t64.shlibs
2024-02-18 00:13:01.0 +
@@ -0,0 +1 @@
+libmediastreamer 13 libmediastreamer13t64 (>= 1:5.2.0-1),
libmediastreamer13t64 (<< 1:5.3.0-1)
diff -Nru mediastreamer2-5.2.0+dfsg/debian/rules
mediastreamer2-5.2.0+dfsg/debian/rules
--- mediastreamer2-5.2.0+dfsg/debian/rules 2024-01-30 14:30:19.0
+
+++ mediastreamer2-5.2.0+dfsg/debian/rules 2024-02-18 00:13:01.0
+
@@ -24,7 +24,7 @@ indeptargets := $(filter ms2-html-doc,$(cmaketargets))
archtargets := $(filter-out ms2-html-doc,$(cmaketargets))
endif
-libpkgname := libmediastreamer13
+libpkgname := libmediastreamer13t64
features += -DENABLE_TOOLS=$(call
when-building-package,libmediastreamer-tools,YES,NO)
features += -DENABLE_UNIT_TESTS=no
Bug#1063106: bctoolbox: NMU diff for 64-bit time_t transition
X-Debbugs-CC: Steve Langasek On Fri, Feb 16, 2024 at 01:55:51PM -0800, Steve Langasek wrote: > > I presume the need for "close together in time" is to prevent > > interoperability issues from cropping up in unstable between shared > > library versions on different sides of the time_t transition. How > > timely would our staged versions need to be uploaded to unstable to > > obviate the need for the NMUs? I ask because it is very difficult to > > say with a useful degree of certainty when these staged versions will > > actually reach testing. Experience has shown that linphone stack > > transitions are prone to being afflicted by (sometimes multi-month) > > delays due to being blocked by other transitions, and I see no open > > bugreport for linphone on the release.debian.org pseudopackage, so > > Berni (who will do these uploads) apparently has not yet applied for a > > new transition slot. > > Based on the above I think you should let us go ahead with the NMUs to > unstable and not worry about it, clobbering them later at your convenience. I agree. Regards.
Bug#1063106: bctoolbox: NMU diff for 64-bit time_t transition
X-Debbugs-CC: Steve Langasek The packages bctoolbox, belle-sip and linphone have been marked as affected by the 64-bit time_t transition. However, all these packages currently have new versions staged in experimental because their library packages had soname bumps unrelated to the 64-bit time_t transition (which you already noticed for belle-sip). As long as these staged versions actually make it into testing before the Trixie freeze there should be no need for these NMU diffs, correct? > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. I presume the need for "close together in time" is to prevent interoperability issues from cropping up in unstable between shared library versions on different sides of the time_t transition. How timely would our staged versions need to be uploaded to unstable to obviate the need for the NMUs? I ask because it is very difficult to say with a useful degree of certainty when these staged versions will actually reach testing. Experience has shown that linphone stack transitions are prone to being afflicted by (sometimes multi-month) delays due to being blocked by other transitions, and I see no open bugreport for linphone on the release.debian.org pseudopackage, so Berni (who will do these uploads) apparently has not yet applied for a new transition slot. Regards.
Bug#1054380: mediastreamer2: diff for NMU version 1:5.2.0+dfsg-3.1 (also: linphone/5.2.0-4.2)
X-Debbugs-CC: Boyuan Yang On Tue, Jan 30, 2024 at 09:38:05AM -0500, Boyuan Yang wrote: > Control: tags 1054380 + patch > Control: tags 1054380 + pending > > Dear maintainer, > > I've prepared an NMU for mediastreamer2 (versioned as 1:5.2.0+dfsg-3.1) and > uploaded it to DELAYED/10. Please feel free to tell me if I > should delay it longer. It's okay (also for the accompanying linphone NMU). However, since equivalent changes are already present in the newer versions currently waiting in experimental I will not acknowledge these NMUs in their changelogs unless I'm explicitly asked to. Regards. (Resending because I forgot to CC: in the first message)
Bug#1054380: mediastreamer2: diff for NMU version 1:5.2.0+dfsg-3.1 (also: linphone/5.2.0-4.2)
On Tue, Jan 30, 2024 at 09:38:05AM -0500, Boyuan Yang wrote: > Control: tags 1054380 + patch > Control: tags 1054380 + pending > > Dear maintainer, > > I've prepared an NMU for mediastreamer2 (versioned as 1:5.2.0+dfsg-3.1) and > uploaded it to DELAYED/10. Please feel free to tell me if I > should delay it longer. It's okay (also for the accompanying linphone NMU). However, since equivalent changes are already present in the newer versions currently waiting in experimental I will not acknowledge these NMUs in their changelogs unless I'm explicitly asked to. Regards.
Bug#1060289: linphone: why are there ringtones in mkv encapsulated opus and the only thing it is able to use are wav files?
X-Debbugs-CC: "Mr. T" Control: close -1 I'm closing this since the linphone-desktop in Bookworm has Matroska support and can play MKV ringtones just fine. Regards.
Bug#1058849: linphone: diff for NMU version 5.2.0-4.1
X-Debbugs-CC: Boyuan Yang On Sun, Dec 17, 2023 at 11:50:11AM -0500, Boyuan Yang wrote: > I've prepared an NMU for linphone (versioned as 5.2.0-4.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer or cancel it. No, it's okay.
Bug#1052747: ortp: FTBFS: b64.h:293: error: unable to resolve link to 'b64::b64_encode2' for \link command (warning treated as error, aborting now)
Control: close -1 1:5.2.98-1 X-Debbugs-Cc: lu...@debian.org I'm closing this as this was fixed with 1:5.2.98-1 in experimental. Reopen at will. Regards.
Bug#1050607: xcb: bookworm xcb won't paste from selected cut buffer
X-Debbugs-CC: Phil Chadwick Control: tag -1 moreinfo I cannot reproduce this with 2.4-7 under xorg: xcb behaves as expected. You state that you use the "standard bookworm Gnome desktop" which should be using Wayland. Are you under Wayland? Because if so then I suspect the behaviour you observed might be due to Xwayland probably not implementing Cut Buffers correctly (or at all) -- which would be unsurprising as they have been a rather obscure/obsolete feature of X for quite some time. In that case it would be prudent to look for an alternative clipboard because I have my doubts that the Xwayland people would add this feature if one were to ask them to. If you want to debug this further you should paste the output of xprop -root | grep CUT_BUFFER For me its: CUT_BUFFER0(UTF8_STRING) = "foo" CUT_BUFFER1(UTF8_STRING) = "bar" CUT_BUFFER2(STRING) = CUT_BUFFER3(STRING) = CUT_BUFFER4(STRING) = CUT_BUFFER5(STRING) = CUT_BUFFER6(STRING) = CUT_BUFFER7(STRING) = Regards.
Bug#1040320: libmediastreamer13: undeclared file conflict with libmediastreamer12
Control: tag -1 confirmed X-Debbugs-Cc: Helmut Grohne On Tue, Jul 04, 2023 at 03:17:41PM +0200, Helmut Grohne wrote: > In reality, the file needs to be moved to an soname-dependent path > or to a package that is not soname-dependent in order to not violate > Debian policy. Thanks for catching this early. I guess moving libmsqogl.so to mediastreamer2-plugin-msqogl will be the best course of action as it will spare headless linphone setups the installation of various Qt libraries. Regards.
Bug#979982: emacsen-common: emacs -batch is noisy
X-Debbugs-CC: Michael Hoffman Control: tag -1 +patch This bug still persists, and the attached patch should fix it while still printing informative messages in interactive mode. I might raise the severity to "serious" at some point since the stray output renders GNU Emacs unsuitable as a script interpreter, thus breaking it. Regards. --- a/debian-startup.el +++ b/debian-startup.el @@ -113,7 +113,7 @@ (mapc (lambda (file) (condition-case err - (load file nil) + (load file nil noninteractive) (error (message "Error while loading %s: %s" file (error-message-string err) base-names)
Bug#1037942: linphone-desktop: Call notification windows in the middle of the screen
X-Debbugs-CC: Samuel Wolf Control: reassign -1 src:qtwayland-opensource-src On Fri, Jun 16, 2023 at 11:18:00AM +0200, Samuel Wolf wrote: > I tried the same setup with X11 (disable wayland) and it works as expected. > So this is another "wayland" issue and maybe not a linphone problem? Looks like it. > Do you see any chance for a workaround in wayland? Running linphone under XWayland could be worth a try. If that doesn't work either I guess we'll probably just have to wait till the Wayland-related bug in Qt has been ironed out. Anyway, I'll reassign this to src:qtwayland-opensource-src in the hope that this will increase its chance of getting resolved eventually. Regards.
Bug#1037942: linphone-desktop: Call notification windows in the middle of the screen
X-Debbugs-CC: Samuel Wolf On Wed, Jun 14, 2023 at 05:15:52PM +0200, Samuel Wolf wrote: > Package: linphone-desktop > Version: 4.4.10-3 > Severity: minor > X-Debbugs-Cc: samuelwol...@googlemail.com > > Dear Maintainer, > > since Debian 12 my call notification windows is not anymore in the right down > corner of my two screens. > There are two white windows (size of call window) and two call notification > windows in the middle of the screen. > Is this a known issue? No, this is something new. I suspect Qt 5.15.8 might have changed something in its multi-monitor support which may have broken something somewhere, probably in linphone-app/src/components/notifier/Notifier.cpp:Notifier::createNotification(). It would help a lot if: - you could confirm that the behaviour is still as expected if you disable one of your monitors, - you could give the exact dimensions of your monitors and the exact coordinates and dimensions of the notification windows and the white rectangles, - you could paste any stdout/stderr or logfile output that contains the string "Primary screen" if it appears anywhere, - you could maybe prepare screenshot(s) that are not too large (e.g. maybe convert to 256 colour PNG, remove any Desktop wallpaper etc.) and post them here. It would be important to know if the notification windows are actually in the very center or slightly offset somehow in case the bug is related to subpixel support. As for how soon this bug will be fixed: I can't tell. Everyone in Qt-land will probably start the migration to Qt 6 in the near future if they haven't already, and thus probably deprioritize polish-related issues like this. Since I use a single-monitor setup I won't notice if this bug still persists, so consider posting here after a new version has been uploaded whether or not it still manifests. Regards.
Bug#1037524: libortp: still missing -lbctoolbox (was: Bug#994437: fixed in ortp 1:5.0.37-1)
Control: tags -1 confirmed X-Debbugs-CC: Frank Heckenbach On Tue, Jun 13, 2023 at 08:25:28PM +0200, Frank Heckenbach wrote: > Package: libortp-dev > Version: 1:5.1.64-2 > Severity: normal > > It's actually not fixed! > > You added a "Requires.private" in the .pc, but that doesn't help. > "Requires" is required (sic!) because a program that links to ortp > apparently must also link to bctoolbox. Dude, did you not see that the string "bctbx_set_log_level_mask" does not occur anywhere in your program? And that as a consequence the error message does not really make any sense? Because if you did see it then you could have said something. It was not immediately obvious to me that ortp_set_log_level_mask() in the distant past was provided by libortp.so, but then replaced with bctbx_set_log_level_mask() from libbctoolbox.so and the name change papered over with a macro (instead of a wrapper function which would have preserved the old linkage relationship). Anyway, I'll fix it when preparing 1:5.2.x which I'll try to get to in the coming weeks. Regards.
Bug#1036082: linphone: Unable to enable H.264 video codec required for Zoom SIP connections
X-Debbugs-CC: Petter Reinholdtsen On Wed, May 17, 2023 at 08:05:44PM +0200, Petter Reinholdtsen wrote: > [Petter Reinholdtsen] writes: > > Nope. It do not seem to be available in Bullseye. I'll try with a > > Bookworm machine and see if there is greater success there. > > I tested on Bookworm, and while it is different, I did not manage to > call the SIP endpoint of Zoom. > > With the mediastreamer2-plugin-openh264 package installed, the H.264 > option show up as enabled, and disabling and enabling it do not ask for > anything to be downloaded. This is great. > > The problem is that I try to connect it to my local Asterisk server, > which appear to not work. I get a proxy account with the correct > settings, but linphone do not seem to reach the server. If you're behind NAT-ing router like most people then you usually need some kind of SIP proxy that connects to your ISP's SIP gateway to make it work. So, if Linphone is not working with your Asterisk server you need to fix that first somehow. > > Are you able to connect to Zoom yourself? > > Would be interesting to know the answer to this question. Well, I don't really use Zoom, mainly for privacy reasons, so you're a bit on your own here. > It behave a lot better. I guess this issue can be seen as solved with > linphone version 5.1.65-4. Still have not found a way to make Linphone > useful, but at least the download popup seem to be gone. > > I am happy to debug some more, and am available on #debian-voip if > someone want direct contact. Okay, I will close the bug report then. Regards.
Bug#1036082: linphone: Unable to enable H.264 video codec required for Zoom SIP connections
X-Debbugs-CC: Petter Reinholdtsen On Mon, May 15, 2023 at 08:06:49AM +0200, Petter Reinholdtsen wrote: > Any calls to the SIP endpoint for the Zoom video chat service fail. I > discovered https://github.com/bemoody/linphone-deb > with a > recipe for how to get it working, but the "Enable H.264 video compression" > step fail. When I try to enable the video codec, a popup message ask if > it is OK to download the codec, but even if I accept the download and > press the strange empty 'confirm' popup afterwards, the H.264 video > codec option stay disabled. > > And without H.264 video codec available, the call is rejected. I > verified this using Jami, which I normally can use to connect to the > SIP endpoint of Zoom, but it will fail when I disable H.264. Do you have the package mediastreamer2-plugin-openh264 installed? It is necessary to use H.264 and will also pull in the required package containing the H.264 codec. If you do have both installed and it still does not work you have to provide more info (e.g. linphone logs etc.). Regards.
Bug#1034836: {Spam?} Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
X-Debbugs-CC: Pásztor János On Wed, May 03, 2023 at 11:20:07PM +0200, Pásztor János wrote: > I have checked #902943 and the fine print from > /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz > Based on that I have made an attempt to replace the UUIDs with > `traditional` disk device paths. > > [...] > > However this fails spectacularly, as during the boot process the > ordering is not stable, sometimes it is sdb1 or sda1 instead of sdc1 > :/ If your device order is not stable during boot you need to use PARTUUID instead of UUID. You might argue that you should be able to use UUID because it worked before Bookworm if you overwrote the crypttab. However, it might be that your LUKS containers were created with an old version of cryptsetup that did not wipe the start of the partition properly. libblkid has had "behavioural changes" in the past under such circumstances wrt. to block device probing and making decisions [1]. It might be that whatever component is used to create /dev/disk/by-* symlinks in the initramfs has changed behaviour, too. According to your initramfs.debug log it's systemd-udevd. + /scripts/init-top/udev Starting systemd-udevd version 252.6-1 You'd have to try to get access to its log output. You should also take copies of the first 1 MiB of your partitions that hold the LUKS containers so libblkid (or whatever the culprit) can be debugged with before you overwrite anything. You'll have to provide copies of some sort if you want someone else to debug this for you -- no idea how to sanitize/dekey them. "cryptsetup luksErase" might render the LUKS header unrecognizable. You'll have to try it out. If you feel like it you can investigate further with: LIBBLKID_DEBUG=all blkid -p lsblk -o NAME,SIZE,TYPE,UUID,PARTUUID The next-heavier cannons would be ltrace/strace and gdb. > But with this I am back at the original issue. > > During this I have spotted an interesting thing. Even tough I put > `traditional` disk device paths into /etc/crypttab, the generated > initramfs has the UUID version of it, even after multiple > regeneration! > > Going even forward, I have seen this in the source code of > `/usr/share/initramfs-tools/hooks/cryptroot`: > https://salsa.debian.org/cryptsetup-team/cryptsetup/-/blob/debian/latest/debian/initramfs/hooks/cryptroot#L43 > That contradicts with your previous statement of no UUID shall be present in > crypttab Oops, I was looking at a wrong version of the file. Regards. 1: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/428435
Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Control: reassign -1 cryptsetup-initramfs
X-Debbugs-CC: Pásztor János
I having doubts that your issue is due to a bug because of this:
> ...
> root@asgard ~ # more /etc/initramfs-tools/hooks/crypttab-fix.sh
> #!/bin/sh
> cp /etc/crypttab "${DESTDIR}/cryptroot/crypttab"
> exit 0
> ...
Why did you add this? Did you notice that during update-initramfs
runs no cryptroot/crypttab file was placed into the initramfs? If yes
then you should have investigated why not because it was indicative
that something in your setup was broken enough for
/usr/share/initramfs-tools/hooks/cryptroot to properly generate its
part of the initramfs. FYI: That script does not simply copy
/etc/crypttab, but parses it and generates a sanitized version because
it relies on /scripts/local-block/lvm2 which does not work with UUIDs
(see #902943). Sure enough your crypttab contains UUID= entries:
> -- /etc/crypttab
> 1Tnvme UUID=1cb8215e-4bb9-479b-ad06-36ae1b3fc957 none luks,discard
> 4Tsolid UUID=2c3dd479-7f24-4aa9-8850-ee5e970e7d32 none luks
Adding some kind of warning in a comment to the generated
cryptroot/crypttab to not manually edit or overwrite it sure would
have been helpful. Or if that's not possible at least a brief README
file in the same directory. One could even lint for this during
initramfs generation and emit a warning, e.g. with:
grep -e '\(etc\|cryptroot\)/crypttab' /etc/initramfs-tools/hooks/*
Regards.
Bug#1033868: linphone-desktop: cannot use any account, without agreeing to terms
X-Debbugs-CC: Martin , Jonas Smedegaard
On Mon, Apr 03, 2023 at 07:29:44AM +, Martin wrote:
> IMHO, agree to terms only makes sense, if using their linphone SIP
> service, but not when using any other SIP account. I really hope (but
> did not yet check), that linphone does not interchange any data with
> Belledonne, if I don't use their linphone SIP service, right?
>
> Suggested solution: The buttons "Use SIP account" and "Fetch remote
> configuration" must not be greyed out, even if user does not agree to
> the terms. The other two buttons ("Create a linphone account" and "Use a
> linphone account") should remain as they arey.
I had already patched this out of the 5.0 version of linphone-desktop
that unfortunately didn't make it into Bookworm in time. I'll look
into backporting that patch.
> Also, the two documents might not be available, e.g. because using
> linphone-desktop in an internal setup without web access or in a country
> where outside web access is blocked. Maybe the documents could be copied
> and linked to /usr/share/doc/linphone-desktop/?
That thought occurred to me, too, but IIRC I opted against it because
I couldn't figure out if those documents are actually redistributable.
Also, they might be subject to change, and users could unknowingly
agree to terms/conditions that were not yet in the outdated version of
the agreement.
Regards.
Bug#1033740: linphone crashed when receiving a phone call
X-Debbugs-Cc: Marco d'Itri
On Sat, Apr 01, 2023 at 11:53:32PM +0200, Marco d'Itri wrote:
> On Apr 01, Dennis Filder wrote:
>
> > I cannot reproduce this here. BTW: That stack backtrace is missing
> > the actual error message which I need.
> I do not understand which message that would be: I reported the complete
> output of "where".
> If it is linphone output then I do not have it anymore: I only have the
> core dump.
>
> > The offending line in mediastreamer2 would be this:
> >
> > s->dev = ms_strdup(card_data->pa_id_sink);
> >
> > In GDB, could you try running these commands after triggering the bug
> > and paste the output?
> >
> > print s
> > print *card_data
> (gdb) print s
> $1 = (Stream *) 0x0
> (gdb) print *card_data
> $2 = {pa_id_sink = 0x558b0c991820 "alsa_output.pci-_33_00.1.pro-output-3",
> pa_id_source = 0x0}
> (gdb)
Okay, in your case s is NULL, so this is a null pointer dereference,
but that can only happen when pulse_write_init() returns early due to
not being able to connect to a pulseaudio server.
> > The output of "pactl list" could also help shed some light on the
> > cause. It could be that you have a somewhat unusual pulseaudio setup.
> Actually I switched to pipewire and wireplumber.
> Also, I cannot promise that the current configuration that I am showing
> here is identical to the one at the time of the crash.
> Card #218
> ...
> Card #219
> ...
> Card #220
That this involves pipewire makes this issue rather difficult since
I'm not really familiar with it yet. And it also means I can't really
try to reproduce it in a chroot and would have to do it on bare metal.
These unusually high card IDs strike me as very odd. Do they change
over the duration of a session? I somewhat suspect pipewire keeps
reconstructing its pulseaudio facility on-the-fly, and that might be
too slow for what pulse_write_init() is expecting. But I'm just
guessing here.
It would help a lot if you launched something that talks to pulseaudio
continuously (e.g. pavucontrol) before launching linphone. This would
ensure that the pulseaudio backend is already up and stays up. Can
you still reproduce the crash then? And can you play the selected
ringtone under Menu -> Preferences -> Audio?
Regards
Bug#1031771: linphone-desktop: Update check recommends AppImage
X-Debbugs-CC: Daniel Kahn Gillmor On Wed, Mar 29, 2023 at 08:47:45AM +0900, Daniel Kahn Gillmor wrote: > Thanks for this fix! I notice that the text says: > > >>> To enable it restart the program with the variable > >>> LINPHONE_DO_APPIMAGE_DOWNLOAD set to "y" in the environment. > > but the actual check is just whether the variable is set, not whether it > is set to "y". > > This means that: > > LINPHONE_DO_APPIMAGE_DOWNLOAD=n linphone > > will actually enable the check. Maybe make sure it checks for "y" as > well? > > I've offered > https://salsa.debian.org/pkg-voip-team/linphone-stack/linphone/-/merge_requests/3 > that tries to do that (but haven't really tested it, sorry!) While I agree in principle that the wording is a tick inaccurate, this is a very small issue -- too small to merit its own upload IMO. If any other issue in the linphone source package pops up during the freeze I will fix this one, too. If not it will have to wait until after Bookworm is released. Regards.
Bug#1033740: linphone crashed when receiving a phone call
X-Debbugs-Cc: Marco d'Itri I cannot reproduce this here. BTW: That stack backtrace is missing the actual error message which I need. The offending line in mediastreamer2 would be this: s->dev = ms_strdup(card_data->pa_id_sink); In GDB, could you try running these commands after triggering the bug and paste the output? print s print *card_data The output of "pactl list" could also help shed some light on the cause. It could be that you have a somewhat unusual pulseaudio setup. Regards.
Bug#1031771: linphone-desktop: Update check recommends AppImage
I just updated the master branch in Salsa for this and #1032051. Regards.
Bug#1031771: linphone-desktop: Update check recommends AppImage
Control: reassign -1 linphone 5.1.65-3 X-Debbugs-CC: Bastian Germann On Wed, Feb 22, 2023 at 02:15:09PM +0100, Bastian Germann wrote: > The update check in the "burger menu" should be disabled because it > downloads the AppImage version of linphone-desktop. Patching an envvar-overridable early return and warning message into linphone/coreapi/update_check.c:linphone_core_check_for_update() seems to me like the easiest way to address this. It would also function as a stop-gap for any new mechanisms that try to trigger an update check. I'll try to have a branch prepared in salsa by Sunday. Regards.
Bug#983597: Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()
This may have gotten fixed by the fix for QTBUG-107850[1] (commit
7487332)[2]. QTBUG-84858 gets a tacit mention there, but is not among
the list of duplicates that got closed through this (even though it
probably should be).
I hastily backported this to 5.15.8 (see attachment), but have not yet
checked if it actually compiles (the test might use functions/macros
missing from 5.15) or works. I can't look into this more currently
since I'm somewhat busy. Hopefully I can try it out this weekend.
Regards.
1: https://bugreports.qt.io/browse/QTBUG-107850
2:
https://invent.kde.org/qt/qt/qtdeclarative/-/commit/74873324bdf3399753f9fcaf7461c0e00df628b1
Description: backport commit 7487332 to hopefully fix #983597
Edited from the original for 6.5.0 FF: https://invent.kde.org/qt/qt/qtdeclarative/-/commit/74873324bdf3399753f9fcaf7461c0e00df628b1
--- a/src/quick/items/qquickitem.cpp
+++ b/src/quick/items/qquickitem.cpp
@@ -2326,6 +2326,7 @@
QQuickItem::~QQuickItem()
{
Q_D(QQuickItem);
+d->inDestructor = true;
if (d->windowRefCount > 1)
d->windowRefCount = 1; // Make sure window is set to null in next call to derefWindow().
@@ -2689,9 +2690,8 @@
const bool wasVisible = isVisible();
op->removeChild(this);
-if (wasVisible) {
+if (wasVisible && !op->inDestructor)
emit oldParentItem->visibleChildrenChanged();
-}
} else if (d->window) {
QQuickWindowPrivate::get(d->window)->parentlessItems.remove(this);
}
@@ -2768,8 +2768,9 @@
d->itemChange(ItemParentHasChanged, d->parentItem);
-emit parentChanged(d->parentItem);
-if (isVisible() && d->parentItem)
+if (!d->inDestructor)
+emit parentChanged(d->parentItem);
+if (isVisible() && d->parentItem && !QQuickItemPrivate::get(d->parentItem)->inDestructor)
emit d->parentItem->visibleChildrenChanged();
}
@@ -2965,7 +2966,8 @@
itemChange(QQuickItem::ItemChildRemovedChange, child);
-emit q->childrenChanged();
+if (!inDestructor)
+emit q->childrenChanged();
}
void QQuickItemPrivate::refWindow(QQuickWindow *c)
@@ -3194,6 +3196,7 @@
, touchEnabled(false)
#endif
, hasCursorHandler(false)
+, inDestructor(false)
, dirtyAttributes(0)
, nextDirtyItem(nullptr)
, prevDirtyItem(nullptr)
@@ -6106,9 +6109,11 @@
QAccessible::updateAccessibility();
}
#endif
-emit q->visibleChanged();
-if (childVisibilityChanged)
-emit q->visibleChildrenChanged();
+if (!inDestructor) {
+emit q->visibleChanged();
+if (childVisibilityChanged)
+emit q->visibleChildrenChanged();
+}
return true;// effective visibility DID change
}
--- a/src/quick/items/qquickitem_p.h
+++ b/src/quick/items/qquickitem_p.h
@@ -472,6 +472,7 @@
bool replayingPressEvent:1;
bool touchEnabled:1;
bool hasCursorHandler:1;
+quint32 inDestructor:1; // has entered ~QQuickItem
enum DirtyType {
TransformOrigin = 0x0001,
--- a/tests/auto/quick/qquickitem2/tst_qquickitem.cpp
+++ b/tests/auto/quick/qquickitem2/tst_qquickitem.cpp
@@ -130,6 +130,7 @@
void isAncestorOf();
void grab();
+void signalsOnDestruction();
private:
QQmlEngine engine;
@@ -3520,6 +3521,52 @@
QVERIFY(!sub2.isAncestorOf());
}
+/*
+Items that are getting destroyed should not emit property change notifications.
+*/
+void tst_QQuickItem::signalsOnDestruction()
+{
+QQuickWindow window;
+window.show();
+
+// visual children, but not QObject children
+std::unique_ptr parent(new QQuickItem(window.contentItem()));
+std::unique_ptr child(new QQuickItem);
+std::unique_ptr grandChild(new QQuickItem);
+
+QSignalSpy childrenSpy(parent.get(), ::childrenChanged);
+QSignalSpy visibleChildrenSpy(parent.get(), ::visibleChildrenChanged);
+QSignalSpy childParentSpy(child.get(), ::parentChanged);
+QSignalSpy childChildrenSpy(child.get(), ::childrenChanged);
+QSignalSpy childVisibleChildrenSpy(child.get(), ::visibleChanged);
+QSignalSpy grandChildParentSpy(grandChild.get(), ::parentChanged);
+
+child->setParentItem(parent.get());
+QCOMPARE(childrenSpy.count(), 1);
+QCOMPARE(visibleChildrenSpy.count(), 1);
+QCOMPARE(childParentSpy.count(), 1);
+QCOMPARE(childChildrenSpy.count(), 0);
+QCOMPARE(childVisibleChildrenSpy.count(), 0);
+
+grandChild->setParentItem(child.get());
+QCOMPARE(childrenSpy.count(), 1);
+QCOMPARE(visibleChildrenSpy.count(), 1);
+QCOMPARE(childParentSpy.count(), 1);
+QCOMPARE(childChildrenSpy.count(), 1);
+QCOMPARE(childVisibleChildrenSpy.count(), 0);
+QCOMPARE(grandChildParentSpy.count(), 1);
+
+parent.reset();
+
+QVERIFY(!child->parentItem());
+QVERIFY(grandChild->parentItem());
+QCOMPARE(childrenSpy.count(), 1);
+QCOMPARE(visibleChildrenSpy.count(), 1);
+QCOMPARE(childParentSpy.count(), 2);
+
Bug#1029253: linphone: FTBFS: ValueError: invalid mode: 'rU'
Control: tags -1 confirmed pending Fixed in salsa, git tag: debian/5.1.65-3
Bug#1026042: trx: License is incompatible with that of up-coming ortp 5.2.0
Source: trx Version: 0.5-4 Severity: important With the recently released version 5.2 ortp has been relicensed to GNU AGPL-3+. Since your package is GPL-2 it is my understanding that it may not link in ortp 5.2 until it is relicensed to either GPL-3 or AGPL-3. Please consult with the upstream developer whether they are open to relicensing. If they aren't you face the decision of whether to maintain a fork of an older license-compatible version of ortp, remove trx from Debian or work around this in some other way. Ask on debian-legal if you have questions about the details of license compatibility and how to best handle this. I may raise the severity to serious at some point as this may actually be an RC bug. Regards. P.S.: I'm not subscribed to this bug, so CC me in every message I should see.
Bug#1021686: zxing-cpp: FTBFS: error: static assertion failed: Cannot format an argument.
Control: tags -1 fixed-upstream Upstream commit 3872abbb33ebb8d6c891baff33778aae04f0c546 fixes this for me[0]. Please upload a zxing-cpp 1.4.0 soon -- I need it in mediastreamer2 5.2 for linphone-desktop 5.0, and I'd rather not have to port back to 1.2 as the API has changed quite a bit since. Regards. (I'm not subscribed to this bug, so CC me in replies I should see.) 0: https://github.com/zxing-cpp/zxing-cpp/commit/3872abbb33ebb8d6c891baff33778aae04f0c546
Bug#1024719: linphone-desktop: New version 5.0 available upstream
X-Debbugs-Cc: Karl Schmidt On Wed, Nov 23, 2022 at 12:21:51PM -0600, Karl Schmidt wrote: > Worth jumping forward to this release.. > [...] > This is version 5.0.0-beta At5.12.12 The transition process to get linphone-desktop 4.4.10 into testing has been initiated already, and since 5.0 is still in beta I see no point in trying to stop it. I'll start work on 5.0 some time after its official release. Regards.
Bug#1021125: soci: ABI break in soci::session causes crashes in Linphone
Control: severity -1 important I'm downgrading this for now since the relinked reverse-dependencies have migrated to testing making this less urgent. But this still needs addressing for bookworm so no one upgrading from bullseye will think they can do a partial upgrade. Regards.
Bug#986324: soci: libsoci-dev needs Depends: on libboost1.74-dev
Control: close -1 I'm closing this since it's become irrelevant. It might have been from accidentally using an outdated soci from my private repo. BTW: If #1021125 is still open by 2022-11-07 we'll probably NMU it (it's just a soversion bump/library package rename). Regards. (Reply is late as I wasn't CC'ed)
Bug#983597: Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()
Control: tag -1 + patch
The attached patch fixed the crashes of Linphone for me.
Regards.
Description: Don't update visibility etc. recursively in setParentItem() when
called within a dtor
Debian bugs: 996910 983597
Last-Update: 2022-10-10
--- a/src/quick/items/qquickitem.cpp
+++ b/src/quick/items/qquickitem.cpp
@@ -2330,13 +2330,13 @@
if (d->windowRefCount > 1)
d->windowRefCount = 1; // Make sure window is set to null in next call
to derefWindow().
if (d->parentItem)
-setParentItem(nullptr);
+_setParentItem(nullptr, true);
else if (d->window)
d->derefWindow();
// XXX todo - optimize
while (!d->childItems.isEmpty())
-d->childItems.constFirst()->setParentItem(nullptr);
+d->childItems.constFirst()->_setParentItem(nullptr, true);
if (!d->changeListeners.isEmpty()) {
const auto listeners = d->changeListeners; // NOTE: intentional copy
(QTBUG-54732)
@@ -2643,6 +2643,11 @@
void QQuickItem::setParentItem(QQuickItem *parentItem)
{
+_setParentItem(parentItem, false);
+}
+
+void QQuickItem::_setParentItem(QQuickItem *parentItem, bool in_dtor)
+{
Q_D(QQuickItem);
if (parentItem == d->parentItem)
return;
@@ -2729,8 +2734,14 @@
else if (d->window && !alreadyAddedChild)
QQuickWindowPrivate::get(d->window)->parentlessItems.insert(this);
-d->setEffectiveVisibleRecur(d->calcEffectiveVisible());
-d->setEffectiveEnableRecur(nullptr, d->calcEffectiveEnable());
+// Updating recursively is superfluous if the object is being
+// destroyed anyway, and also unsafe as doing it would involve
+// virtual functions like accessibleRole() among maybe others
+// (QTBUG 84858).
+if (!in_dtor) {
+ d->setEffectiveVisibleRecur(d->calcEffectiveVisible());
+ d->setEffectiveEnableRecur(nullptr, d->calcEffectiveEnable());
+}
if (d->parentItem) {
if (!scopeFocusedItem) {
--- a/src/quick/items/qquickitem.h
+++ b/src/quick/items/qquickitem.h
@@ -458,6 +458,8 @@
Q_PRIVATE_SLOT(d_func(), void _q_resourceObjectDeleted(QObject *))
Q_PRIVATE_SLOT(d_func(), quint64 _q_createJSWrapper(QV4::ExecutionEngine
*))
+__attribute__((visibility("hidden"))) void _setParentItem(QQuickItem
*parent, bool in_dtor);
+
friend class QQuickEventPoint;
friend class QQuickWindow;
friend class QQuickWindowPrivate;
Bug#1021576: can't have both LIME and LIME X3DH enabled at the same time
Control: close -1 X-Debbugs-Cc: ael On Thu, Oct 13, 2022 at 07:35:25PM +0100, ael wrote: > It does seem to leave some error handling attention if it dumps core > on a simple configuration error. I guess that is for upstream. It's not actually a coredump, but a fatal error message that is implemented awkwardly. There currently does not seem to be any way to gracefully loop through such error messages from liblinphone to linphone-desktop. I'll try to bring it up with the developers, and also the dearth of documentation. > PS. I assume you will close the bug report, or should I do so? I'll close it. Regards.
Bug#1021576: can't have both LIME and LIME X3DH enabled at the same time
X-Debbugs-Cc: ael On Thu, Oct 13, 2022 at 12:42:52PM +0100, ael wrote: > Another gdb log after installing liblinphone*10-dbgsym*. > > one line that may be relevant is > > #5 0x77b37798 in bctbx_fatal(char const*, ...) > (fmt=fmt@entry=0x77bc1670 "You can't have both LIME and LIME X3DH > enabled at the same time !\nConflicting settings are [sip] lime and [lime] > lime_server_url") > at /usr/include/bctoolbox/logging.h:245 > > This is another quick and dirty interim report for now... Well, there's your answer right there: Your ~/.config/linphone/linphonerc still contains a lime= entry in the [sip] section from earlier releases. Somehow it must have been set to 1 which conflicts with the newer LIME X3DH support that has its own section. Just delete that line from the [sip] section and you should be good to go. It is unfortunate that the error message is only written to the log, not to stderr where it would be helpful. I just wonder why it didn't manifest before (assuming you didn't make any changes to your configuration recently). Have you used the AppImage version recently? If so it may have touched your configuration. Regards.
Bug#1021576: Small update
X-Debbugs-Cc: ael On Wed, Oct 12, 2022 at 11:12:07AM +0100, ael wrote: > A quick note in haste. > > Seems that I had ulimit still slightly too small. > > Trying to get a backtrace on a full core > ($ ls -ltrh core > -rw--- 1 ael ael 229M Oct 12 11:06 core > ) > > gives: > (gdb) bt > #0 0x7f623be8957c in ?? () > Backtrace stopped: Cannot access memory at address 0x7fff724b0460 Is there a reason you're not running linphone under GDB directly? Nowadays there usually no need to mess with coredumps anymore. Just run: gdb linphone then type: start continue bt Regards.
Bug#1021576: linphone-desktop: Core dumped: Program terminated with signal SIGABRT, Aborted.
On Wed, Oct 12, 2022 at 12:31:58PM +0200, Bernhard Schmidt wrote: > Am 11.10.22 um 18:19 schrieb Dennis Filder: > > > The change in 5.0.37-6 was tiny and I doubt it broke something. But > > maybe you're running into #1021125: liblinphone10:amd64 5.0.37-6 is > > already linked against soci/4.0.3-1, but liblime0 5.0.37+dfsg-4 is > > still linked against soci/4.0.1-5 and there was an ABI break. You'd > > have to downgrade to 5.0.37-5 and soci 4.0.1-5 and wait until either > > that bug gets fixed or lime will be rebuilt and reuploaded. > > Shall we just do a new upload of liblime0 then? That would be nice. > liblime and linphone are the only reverse dependencies in the archive, and > linphone has already been rebuilt against the new version/ABI. I doubt one > can fix the soci ABI bump without breaking linphone again, so we could just > go forward and rebuild lime. While it would make addressing #1021125 less urgent, that bug still needs to be fixed eventually for Bookworm. Otherwise people might falsely assume they can stay on soci 4.0.1 while upgrading liblinphone10 and liblime0 to 5.0.37 (or their 5.1 successors). Having it fixed before the linphone-stack 5.1/4.4 uploads would save work. Regards
Bug#1021576: linphone-desktop: Core dumped: Program terminated with signal SIGABRT, Aborted.
Control: tags -1 + moreinfo X-Debbugs-Cc: ael On Mon, Oct 10, 2022 at 07:16:18PM +0100, ael wrote: > Package: linphone-desktop > Version: 4.3.2-2+b1 > Severity: normal > > After updating to linphone-common:all 5.0.37-6 and liblinphone10:amd64 > 5.0.37-6 > as part of routine testing updates, I find that /usr/bin/linphone from > linphone-desktop aborts and dumps core as of today. > > Reportbug highlighted linphone-desktop_4.3.2-2+b1_amd64.deb > in unstable. Trying to install that failed on a depedency on > libqt5qml5_5.15.6+dfsg-2_amd64.deb > > Trying to install those broke again on a dependency on > qtdeclarative-abi-5-15-6 > which does not appear to exist. The qtbase-abi-5-15-6 transition is still on-going[0], so any 5-15-6 packages should not be installed yet. You must downgrade any you have installed back to 5-15-4. > So linphone is broken on testing. > > $gdb -c core > does help much probably because I have set ulimit too small, and right > now I can't remember where ulimit gets set. > > But it ends with > Core was generated by `linphone'. > Program terminated with signal SIGABRT, Aborted. Did you maybe forget to attach some files before sending this message? I ask because your bug report is very light on details. You only say that 5.0.37-6 crashes with SIGABRT, but not what version you used before and where it crashes. You don't provide any stderr output or logs either. And if you have gdb installed and your APT preferences are on testing-debug you are clearly skilled enough to install -dbgsym packages and provide a stack backtrace. I currently have no information I can work with. The change in 5.0.37-6 was tiny and I doubt it broke something. But maybe you're running into #1021125: liblinphone10:amd64 5.0.37-6 is already linked against soci/4.0.3-1, but liblime0 5.0.37+dfsg-4 is still linked against soci/4.0.1-5 and there was an ABI break. You'd have to downgrade to 5.0.37-5 and soci 4.0.1-5 and wait until either that bug gets fixed or lime will be rebuilt and reuploaded. Regards. 0: https://release.debian.org/transitions/html/qtbase-abi-5-15-6.html
Bug#1021043: linphone-desktop: linphone crashes and is unusable
Control: reassign -1 linphone 5.0.37-5 Control: retitle -1 linphone: std::logic_error in src/account/account.cpp:LinphonePrivate::Account::notifyPublishStateChanged() X-Debbugs-Cc: Daniel Kahn Gillmor On Sat, Oct 01, 2022 at 03:15:10PM -0400, Daniel Kahn Gillmor wrote: > However, after restoring my configuration, and trying to place a single > call (to myself, which of course i didn't expect to work) the app > crashed again. > > now, even with libsoci* from bullseye, it is crashing again at startup, > with this stderr log and backtrace: > > ... > #9 0x77868d34 in > LinphonePrivate::Account::notifyPublishStateChanged(_LinphonePublishState) () > at /lib/x86_64-linux-gnu/liblinphone.so.10 > ... Yeah, this is a different issue. Upstream commit a6ca93ec62b66dfcc0fe41783beeab4a471c95dc looks like it fixed this. I'll look into preparing an update. That should then also take care of the soci breakage. Regards.
Bug#1021043: linphone-desktop: linphone crashes and is unusable
Control: tags -1 + confirmed X-Debbugs-Cc: Daniel Kahn Gillmor On Fri, Sep 30, 2022 at 06:56:04PM -0400, Daniel Kahn Gillmor wrote: > I've used linphone for years. Recently (i think with the upgrade to > 4.3.2-2) it no longer works for me, crashing with a range of errors. It would help a lot to know the exact time when those crashes started. Can you try narrowing it down, e.g. by looking at the ctime of files/directories you created in reaction to the crashes? I also saw one segfault that was not handled by __GI_abort() -- maybe you had one, too, so it might show up as a message in /var/log/message* somewhere. Also, do you have the impression that the crashes suddenly became more frequent somehow? If so: When? What is the output of?: stat /usr/share/doc/linphone-desktop/changelog.Debian.gz > Working with my longstanding configuration, i see the following on stderr: > > [...] > > Please let me know if you'd like me to supply any additional debugging > information. I could reproduce all of those messages and stack traces with varying frequencies except the first one. Can you try if downgrading libsoci-core4.0 and libsoci-sqlite3-4.0 to 4.0.1-5 from bullseye stops the crashes or at least makes them less frequent for you? I have not been able to reproduce any crashes with those versions, neither with a fresh profile nor with my own. soci had an upgrade to 4.0.3-1 which entered unstable on 2022-09-25 and testing on 2022-09-27. If you are certain that you observed crashes before those dates the cause might lie elsewhere, or there might be multiple issues at play. My current suspicion is that soci 4.0.3-1 had an ABI break from upstream commit 1b1b5621f5abc40bd76a54a779455e8b9c0892ff (adding the private backendRef_ member changed the layouts of the classes soci::connection_parameters and soci::session and liblinphone.so.10 instantiates the latter). Regards.
Bug#1012900: fixed in bctoolbox 5.0.37-2
X-Debbugs-CC: Paul Gevers On Sat, Aug 13, 2022 at 11:07:12PM +0200, Paul Gevers wrote: > Can we have this fix in unstable too please? bctoolbox is a key package. > Please fix RC bugs in unstable/bookworm too. I'll look into it, but need some clarification: If I make a new version 4.4.13-4 for unstable, it will then contain the very changes that led to the creation of 5.0.37-2 for experimental (thus rendering it redundant), and the latter will also not have 4.4.13-4 as a predecessor in its changelog. In a nutshell, shouldn't any new upload to unstable automatically nuke any newer version already in experimental as otherwise it becomes impossible for the experimental package to migrate to unstable without introducing changelog inconsistencies in the form of missing entries? I presume to handle this correctly that I'd have to do something like rebase all 5.0.37-* releases onto 4.4.13-4, then create 5.0.37-3 with no changes except its changelog rewritten to explain which changes were backported to unstable and which releases were obviated as a result. Is there an established way to express this? Regards, Dennis
Bug#1014832: libdecaf: Source-only upload is needed
X-Debbugs-CC: Boyuan Yang On Tue, Jul 12, 2022 at 04:43:07PM -0400, Boyuan Yang wrote: > According to https://tracker.debian.org/pkg/libdecaf , you package needs > another source-only upload to be able to migrate to Debian Testing. Please > consider making another upload. Will that actually fix it? Or will it just break again on the affected platforms due to still-missing cmake, cmake-data and/or libssl1.1? Regards, Dennis.
Bug#989959: closed by Debian FTP Masters (reply to Michael Tokarev ) (Bug#989959: fixed in unbound 1.15.0-2)
I wasn't CC'ed, thus the late reply. > But now I've a question: how the initial problem happened? > > Okay, it smells like it is, and it definitely it should not be > copied from /usr/share/dns/root.key.. What can I say? My /var partition became full (too many .deb files IIRC) and unbound.service wouldn't start because of an unusable trust anchor file (which was empty). How exactly that happened I have no idea. It may have been from unbound trying to replace root.key with its own changes and failing, but looking at the code (validator/autotrust.c:autr_write_file()) that should have left the old version in place upon failure. So maybe it was from package-helper trying to copy over the existing file for some other reason. Maybe due to the missing StateDirectory=/var/lib/unbound directive /var was not yet mounted when [ ! -e "$ROOT_TRUST_ANCHOR_FILE" ] ran fooling the script into thinking it should update that "missing" file, but became mounted before /usr/bin/install was invoked which then failed due to missing disk space leaving behind an empty file. The "-" in "ExecStartPre=-/usr/lib/unbound/package-helper root_trust_anchor_update" then resulted in this error being ignored which would have made it impossible for me to learn what exactly went wrong. Again, I have no way of reconstructing whether it happened like this, I'm just guessing here. As far as I see it a problem also was that (in the old version) after the reboot the package-helper script only tried to overwrite /var/lib/unbound/root.key when it was older than /usr/share/dns/root.key or missing, but not when it was empty or corrupted. Having package-helper automatically detect and try to auto-repair that would be a nice convenience to have as then simply restarting the unit would fix the problem. > The script (/usr/lib/unbound/package-helper) use install(1) to > update the file and to chown it (this also smells unsafe from the > security PoV). And install unlinks the destination file first, > creates destination file, writes contents to it, and closes it. It > looks like we should not use install(1) here, or maybe install it to > .tmp and mv it atomically, - and from _there_, the problem will just > go away. > ... > Am I right this is just the initial key and unbound updates this key > automatically by its own? I think so, but I'm not sure. My knowledge of both unbound and the details of DNSSEC is rather spotty. > > P.S.: I also noticed that unbound.service under [Service] defines no > > StateDirectory=/var/lib/unbound to ensure that it is mounted on start. > > The chroot setup procedure has its own load of issues. I see. Maybe adding just After=var.mount var-lib.mount var-lib-unbound.mount would still be worth considering. It would cause unbound.service to wait only if these mount units exist. And since /var/lib/unbound gets installed as part of the package this should not cause any problems even if unbound is run in chroot-mode. Regards.
Bug#1008840: linphone: Recording does not work due to lack of mkv support
X-Debbugs-CC: Rainer Dorsch On Sat, Apr 02, 2022 at 10:24:49PM +0200, Rainer Dorsch wrote: > Thanks for the analysis. Do you think it would be sufficient to replace the > .mkv > with .wav in ./linphone-app/src/components/call/CallModel.cpp > > [...] > > and rebuild the Debian package? You'll have to find out by trying. From my cursory reading Mediastreamer2 determines the backend from the extension, so the chances are somewhat high that it will work. But I cannot say if something else in linphone-desktop won't break, e.g. when trying to append to an existing recording. Regards.
Bug#1008840: linphone: Recording does not work due to lack of mkv support
X-Debbugs-CC: Rainer Dorsch Oops, forgot something: On Sat, Apr 02, 2022 at 08:27:19PM +0200, Rainer Dorsch wrote: > Do you think 4.3.2 builds also on bullseye or does it have dependencies, which > are not in bullseye? It should work and a backport is planned. Regards.
Bug#1008840: linphone: Recording does not work due to lack of mkv support
X-Debbugs-CC: Rainer Dorsch
On Sat, Apr 02, 2022 at 08:27:19PM +0200, Rainer Dorsch wrote:
> HmmI just configured the path for in Settings->User Interface. Can you
> tell
> where I can configure the file name?
I just looked at the code and the ".mkv" suffix is hard-coded in the
Qt version, so currently there is no way to record in WAV despite
Mediastreamer2 supporting it. The command line version ("linphonec")
still supports it with the "record" command. I'll add this to the
list of things to bring up once I get around to discussing bugs with
the upstream developers.
A work-around can be to record straight from the Pulseaudio monitor of
an on-going call (oggenc is part of vorbis-tools):
pacmd list-sink-inputs # the index for Linphone was 58
parec --monitor-stream=58 | oggenc -o /tmp/linphone.ogg --raw -
The volume may need to be cranked up quite high. Working with
Pulseaudio like this can also get somewhat finicky.
Regards
Bug#1008840: linphone: Recording does not work due to lack of mkv support
X-Debbugs-CC: Rainer Dorsch On Sat, Apr 02, 2022 at 04:23:34PM +0200, Rainer Dorsch wrote: > as a side note, even though reportbug reports that there is a newer > version of linphone (4.4.21-2) for stable, I cannot install it. apt > does not find it, rmadison has even two entries: > > rd@h370:~$ apt-cache policy linphone > linphone: > Installiert: 4.2.5-3 > Installationskandidat: 4.2.5-3 > Versionstabelle: > *** 4.2.5-3 500 > 500 http://ftp-stud.hs-esslingen.de/debian bullseye/main amd64 > Packages > 500 http://ftp-stud.hs-esslingen.de/debian bullseye/main i386 Packages > 100 http://deb.debian.org/debian sid/main amd64 Packages > 100 http://deb.debian.org/debian sid/main i386 Packages > 105 http://deb.debian.org/debian bookworm/main amd64 Packages > 105 http://deb.debian.org/debian bookworm/main i386 Packages > 100 /var/lib/dpkg/status > rd@h370:~$ rmadison linphone > linphone | 3.6.1-2.4 | oldoldoldstable | source > linphone | 3.6.1-2.4+b1 | oldoldoldstable | amd64, armel, armhf, i386 > linphone | 3.6.1-3 | oldoldstable| source, amd64, arm64, armel, > armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > linphone | 3.12.0-3 | oldstable | source, amd64, arm64, armel, > armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > linphone | 4.2.5-3 | stable | all > linphone | 4.2.5-3 | testing | all > linphone | 4.2.5-3 | unstable| all > linphone | 4.4.21-2 | stable | source > linphone | 4.4.21-2 | testing | source > linphone | 4.4.21-2 | unstable| source > linphone | 4.4.21-2 | unstable-debug | source This is most likely due to a package renaming. Can you try running?: rmadison -S linphone The CLI version is now in "linphone-cli" and the Qt version (which was formerly in "linphone") is now in "linphone-desktop". "linphone" from now on only exists as a source package name. But the 4.2.5-3 "linphone" transitional package should still show up under bullseye. The versioning is confusing because the desktop app and the core libraries (of which the CLI version is a component) are not versioned according to the same scheme. > which suggests that linphone was built w/o mkv support. > > Can you confirm that? Yes. Version 4.3.2 of linphone-desktop and its dependencies have been packaged already in Salsa, are waiting for an upload and are planned to ship with Matroska support. > Previously the recording were in wav format. Is it possible to > switch back to wav, if mkv is troublesome? You can try to record in WAV by supplying a file name that ends in ".wav". If that does not work then I don't know what can be done besides waiting. Regards.
Bug#1008841: imagemagick: compare falsely deems two identical images different
Source: imagemagick
Version: 8:6.9.11.60+dfsg-1.3
Architecture: amd64
Running
compare-im6.q16hdri wizard: wizard: null:
yields an exit status of 1 ("Images are dissimilar"), but it should be
0 ("Images are similar"). Running
compare-im6.q16hdri -metric ncc wizard: wizard: null:
prints "0.97", but it should be "1". Since NCC is the default
metric this renders the compare command broken. For comparison:
compare-im6.q16hdri -metric AE wizard: wizard: null:
This correctly prints "0" as you would expect for the AE metric.
The delta image produced is also useless for finding differences since
it merely produces a fainter version of the original image, e.g. by
running
compare-im6.q16hdri wizard: wizard: /tmp/delta.png
No idea what's going wrong here.
The bug is present in both the q16 and the q16hdri flavors of the
package, thus I file it against the source package.
Bug#983985: bctoolbox: ftbfs with GCC-11
X-Debbugs-CC: Andrea Pappacoda On Thu, Jan 27, 2022 at 04:21:29PM +0100, Andrea Pappacoda wrote: > I got here because bctoolbox depends on MbedTLS, and I'm working on its > transition. As the release team told me that I can proceed with the upload > to unstable, would it be an issue for you if I push the update? MbedTLS 2.28 > should be API compatible with 2.16 and shouldn't cause issues (the current > version of bctoolbox builds fine with it), but I'd like to be sure that I > don't break stuff (again). As I can't test the version you're working on, > could you please test if your updated bctoolbox builds fine with the mbedtls > package in experimental? No, it's alright, proceed ahead. Because the version number was different I didn't realize you are doing essentially a BinNMU. bctoolbox 5.0.37 builds perfectly with mbedtls 2.28.0-0.1 here, I will test with 2.28.0-0.2 ASAP. Regards.
Bug#983985: bctoolbox: ftbfs with GCC-11
X-Debbugs-CC: Andrea Pappacoda , Bastian Germann On Tue, Jan 25, 2022 at 07:07:44PM +0100, Bastian Germann wrote: > Do you mean the NMU that was uploaded at > https://mentors.debian.net/package/bctoolbox? > That was not uploaded by me. No, I actually meant the mediastreamer2 NMU last November, but thanks for putting this on my radar. @Andrea: I'm currently in the process of packaging the current AppImage's version of linphone-desktop and all its dependencies, but that will still take a couple of days (at least) before it's finished and then some time till it gets uploaded. It will however take care of #983985. If you want to participate in the on-going maintenance of linphone you can always contact us. Regards.
Bug#983985: bctoolbox: ftbfs with GCC-11
X-Debbugs-CC: Bastian Germann On Mon, Jan 24, 2022 at 08:18:02PM +0100, Bastian Germann wrote: > Upstream has that fixed with > https://gitlab.linphone.org/BC/public/bctoolbox/-/commit/9ac0e412c45bf28d02829e9d912342359714f638 Thanks for the effort (and the NMU). I'm currently in the process of preparing linphone 5.0.37 and dependencies which will take care of this. Regards.
Bug#1004354: git-buildpackage: exception: AttributeError: 'bytes' object has no attribute 'encode'
Source: git-buildpackage
Version: 0.9.22
Severity: normal
I tried to import an orig tarball while on the "upstream" branch and
was met with this:
$ git status
On branch upstream
Your branch is up to date with 'origin/upstream'.
nothing to commit, working tree clean
$ gbp import-orig ../origtarballs/*_?.?.??.orig.tar.xz
git-buildpackage: exception:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/gbp/scripts/import_orig.py", line 111,
in detect_name_and_version
cp = ChangeLog(filename='debian/changelog')
File "/usr/lib/python3/dist-packages/gbp/deb/changelog.py", line 84, in
__init__
raise NoChangeLogError("Changelog %s not found" % (filename, ))
gbp.deb.changelog.NoChangeLogError: Changelog debian/changelog not found
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/gbp", line 149, in
sys.exit(supercommand())
File "/usr/bin/gbp", line 145, in supercommand
return module.main(args)
File "/usr/lib/python3/dist-packages/gbp/scripts/import_orig.py", line 470,
in main
(name, version) = detect_name_and_version(repo, sources[0], options)
File "/usr/lib/python3/dist-packages/gbp/scripts/import_orig.py", line 118,
in detect_name_and_version
cp = parse_changelog_repo(repo, options.debian_branch, 'debian/changelog')
File "/usr/lib/python3/dist-packages/gbp/deb/__init__.py", line 100, in
parse_changelog_repo
return ChangeLog(repo.show(sha))
File "/usr/lib/python3/dist-packages/gbp/deb/changelog.py", line 90, in
__init__
self._parse()
File "/usr/lib/python3/dist-packages/gbp/deb/changelog.py", line 106, in
_parse
output = self._run_parsechangelog()
File "/usr/lib/python3/dist-packages/gbp/deb/changelog.py", line 98, in
_run_parsechangelog
(stdout, stderr) = cmd.communicate(self._contents.encode('utf-8'))
AttributeError: 'bytes' object has no attribute 'encode'
Regards.
Bug#1003075: gnutls28: HTML API reference documentation is not generated
Source: gnutls28 Version: 3.7.2-4 Tags: patch Building the HTML api-reference docs seems to have been broken for quite a while due to XML shenanigans. The first of the attached patches makes it work again, but fixing makeinfo to emit DocBook that is actually valid XML would be better. The second patch polishes d/rules a bit. The patches apply cleanly to 3.7.2-4, but I only ran the build with 3.7.1-5. Regards. --- a/doc/reference/gnutls-docs.sgml +++ b/doc/reference/gnutls-docs.sgml @@ -2,7 +2,7 @@ https://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd; [ - https://www.w3.org/2003/XInclude'"> + http://www.w3.org/2003/XInclude'"> ]> --- a/lib/cert-cred.c +++ b/lib/cert-cred.c @@ -905,7 +905,7 @@ * chain is incomplete due a missing intermediate certificate. The callback * may provide the missing certificate for use during verification. * - * The callback's function prototype is defined in as: + * The callback's function prototype is defined in gnutls/x509.h as: * * int (*callback)(gnutls_x509_trust_list_t list, * const gnutls_x509_crt_t cert, --- a/debian/rules +++ b/debian/rules @@ -46,7 +46,7 @@ $(AMCONFBUILDINDEP) override_dh_autoreconf: - rm -v `grep -rl gettext-0.20 m4/` + -rm -v `grep -rl gettext-0.20 m4/` if ! dh_listpackages | grep -q gnutls-doc ; \ then env GTKDOCIZE="echo DISABLED running gtkdocize" \ dh_autoreconf --verbose $(BDIR) ; \ @@ -78,7 +78,7 @@ # restore gnutls.pdf if [ -e doc/gnutls.pdf.debbackup ] && [ ! -e doc/gnutls.pdf ] ; \ then mv -v doc/gnutls.pdf.debbackup doc/gnutls.pdf ; fi - rm -fv \ + -rm -fv \ `grep -El 'has been AutoGen-ed |has been AutoGen-ed *$$' doc/manpages/*.?` override_dh_auto_build: @@ -93,9 +93,9 @@ override_dh_auto_install: dh_auto_install $(BDIR) --verbose ifneq ($(filter --disable-doc,$(AMCONFBUILDINDEP)),) - $(MAKE) -C b4deb/doc/manpages DESTDIR=`pwd`/debian/tmp install + $(MAKE) -C b4deb/doc/manpages DESTDIR=$(CURDIR)/debian/tmp install else - $(MAKE) -C b4deb/doc/ DESTDIR=`pwd`/debian/tmp install-html + $(MAKE) -C b4deb/doc/ DESTDIR=$(CURDIR)/debian/tmp install-html # we symlink these rm -vf debian/tmp/usr/share/info/*.png endif @@ -126,7 +126,7 @@ # Fails with "dwz: Section overlap detected" override_dh_dwz: - dh_dwz -O--builddirectory=b4deb -Xextra.go -Xgnutls.go + dh_dwz $(BDIR) -Xextra.go -Xgnutls.go %: - dh $@ --builddirectory=b4deb + dh $@ $(BDIR)
Bug#996910: linphone: Segmentation fault when registering a sip account
X-Debbugs-CC: Tiago Bortoletto Vaz On Tue, Dec 28, 2021 at 09:45:04AM -0500, Tiago Bortoletto Vaz wrote: > gdb log attached. I hope that can be useful :\ That stacktrace looks very similar to the ones from #983597 which already has 3 entries in the Qt bugtracker[0] one of which has an Orca-less reproducer. Thus I'm inclined to mark this as a duplicate. Unfortunately, tracking this down would probably require unoptimized debug builds of most of the involved libraries, so that's something the Qt devs have to solve. Regards. 0: https://bugreports.qt.io/browse/QTBUG-84858
Bug#1001858: sudo.prerm will not allow replacement with sudo-ldap if no root password
On Fri, Dec 17, 2021 at 11:28:35PM +0100, Marc Haber wrote: > If you run the Debian installer with default settings, you get a system > without root password. I guess the majority of desktop installations run > that way. The majority of desktop installations never uninstall sudo, either. Anyway, performing sudo surgery without a root password set is asking for trouble. Anyone with half a brain would set one temporarily. > As far as I know, you generally cannot control the environment in all > autopkgtest instances. That's their problem, and it is also very easy to solve. A package installs to /usr/share/autopkgtest/adjusts/.env a list of environment variable names (and maybe also the set of permitted values), and then the autopkgtest author expresses an explicit Depends: on the package and specifies the assignment of the environment variable in Extra-Environment:. Then autopkgtest should place that into the environment and it will work. Till they offer such a mechanism no one should spend time on working around this. Regards. P.S.: I just saw your message about the LDAP-related autopkgtests for sudo, and I'll look into that in the next days, but I wonder what a good tesing goal should be. The most critical part is switching between sudo and sudo-ldap and back. Stuff like PAM has to be tested to work out of the box, too. And hooking sudo to a pseudo-terminal (e.g. through socat or ptywrap) would be more realistic as well. I also first have to get a better understanding of how autopkgtests work, i.e. how exactly they are invoked on QA servers and if later tests can rely on side-effects by earlier tests.
Bug#1001858: sudo.prerm will not allow replacement with sudo-ldap if no root password
On Fri, Dec 17, 2021 at 09:49:01PM +0100, Marc Haber wrote: > sudo.prerm will error out unconditionally if there is no root password > set. This breaks the replacement of sudo with sudo-ldap in autopkgtest > environments and makes ugly workarounds necessary. How would we make > this better? I don't see the issue here. That was put in there for a very good reason: to not bork the system if something goes wrong during the replacement. A system without a root password set is a very unorthodox use case. Running autopkgtest with --env=SUDO_FORCE_REMOVE=yes should make this work. Of course, it would be nicer if the format for d/tests/control offered something like Extra-Environment: to specify (a file with definitions of) additional environment variables for a set of tests. Since there is apparently no good way either to safely determine with authority if you're running under an autopkgtest I think this is not sudo's problem to solve, but that of autopkgtest. Regards.
Bug#1001862: mbedtls: Enable MBEDTLS_SSL_DTLS_SRTP
Source: mbedtls Severity: wishlist mbedtls 2.28 came out today and is the new LTS release. Of its new features I need support for DTLS SRTP (option MBEDTLS_SSL_DTLS_SRTP) for Linphone, so please ensure to enable it. Thanks in advance. P.S.: libmbedtls-doc contains Doxygen .map files, so please adjust override_dh_installdocs to exclude them, too.
Bug#990244: tests/streams: Failing test on pipe stdout file descriptor
control: forwarded -1 https://sourceforge.net/p/clisp/bugs/747/ X-Debbugs-CC: Ariel D'Alessandro On Thu, Dec 09, 2021 at 11:20:52PM -0300, Ariel D'Alessandro wrote: > Did a quick check by running the lisp tests using ptywrap and the error > is no longer happening. Of course, now the pty is used instead of the > (root owned) pipe, so permissions are fine to re-open the file. > > So, moving forward. This is the failing test simplified: > > (streamp (setq s (make-stream :error))) T > (let ((*reopen-open-file* nil)) ; stdout can be a file, it will be detected! > (with-open-file (copy s :direction :output) (streamp copy))) T > > My question here would be: is this test expected to always succeed? You'd have to ask the original author of the test that. In a perfect world every test would be accompanied by a detailed description of what exactly it tests for, what conditions it expects and what constitutes a pass or failure. > AFAIU, we can't assume to have the permissions to re-open the file > related to the file descriptor, which is what the code is explicitly > trying to do. In a test suite you usually can since it is probably not supposed to be run by a privileged user in such a way that it fails. Build servers and CI pipelines, which are almost always involved in exposing such bugs, really ought to put in more effort to make their environment more similar to the one the developer develops and tests the code in instead of silently expecting everyone else to put in the additional effort to placate them. Fooling a build/test suite into thinking it is hooked to a terminal with a tool like ptywrap is really not that big of an ask and it should be a default feature in all such products. Alternatively the privileged invoker could just as easily call chown(2) on the pipe after opening it and solve the issue this way. > Please correct me if I'm wrong as I'm not used to clisp syntax, just > going through the source code :-) > > From what I see, it responsibility of the clisp test code to check if it > has the permissions to re-open the file. Otherwise, it's not guaranteed > to succeed. For example, having this fd pointing to a (root owned) pipe > is a valid situation and should be properly handled by this test. That's debatable. Yes, it could be argued that the test should do a better job at disarming itself by testing if it can reopen the file with e.g. access(2). OTOH it could also be argued that it is the invoker's burden to ensure conditions that allow the test to succeed. Writing test suites is annoying enough as is. No need to make it more annoying by also expecting accommodation for build servers and CI pipelines if they themselves could do the accommodation much more easily. Regards.
Bug#996910: linphone: Segmentation fault when registering a sip account
X-Debbugs-CC: Tiago Bortoletto Vaz On Wed, Oct 20, 2021 at 04:49:33PM -0400, Tiago Bortoletto Vaz wrote: > Hi, thanks for the quick answer, > > On Wed, Oct 20, 2021 at 06:48:43PM +0200, Dennis Filder wrote: > [...] > > > When you try to register the account, what steps to you go through? I > > presume in the main window you're clicking in this order: Home -> > > Assistant -> Use a SIP Account. If so, does Linphone still crash if > > you omit the "sip:" prefix in the input field "SIP Domain"? That > > field must be a resolvable hostname, domain name or an IP address, and > > unfortunately the input validation in that dialog is not as good as it > > should be. > > Yes, it crashes when I use a domain name without "sip:" prefix. What domain name are you using? Also are you doing this from the same dialog as before? Because from the log output I would guess you are using the settings menu instead of the account registering dialog. Whether a crash happens from within the settings menu that would also be important to know. Also, are you running Orca by any chance? > > If the above advice does not resolve the issue, please give detailed > > steps on what you click and what information you enter in each field. > > Also exit Linphone and then start a new Linphone instance from a > > terminal like this: > > > > catchsegv linphone 2>&1 | tee /tmp/linphone-segfault.txt > > > > Then post that file here after it has crashed. > > Sure, attached. > > Let me know if there is anything else I can do to help. That was not as illuminating as I had hoped. If you can, download the debug symbols package for linphone-desktop (or wherever the segfault happens) from http://debug.mirrors.debian.org/debian-debug/pool/main/l/linphone-desktop/ and run it under gdb to get a stack trace. Regards.
Bug#996910: linphone: Segmentation fault when registering a sip account
X-Debbugs-CC: Tiago Bortoletto Vaz
On Wed, Oct 20, 2021 at 12:06:05PM -0400, Tiago Bortoletto Vaz wrote:
> Package: linphone
> Version: 4.2.5-3
> Severity: important
> X-Debbugs-Cc: ti...@debian.org
>
> Dear Maintainer,
>
> I'm getting a segmentation fault every time I try to registar a regular UDP
> account from my SIP provider:
>
> [...]
> : Implicitly defined onFoo properties in Connections are deprecated. Use this
> syntax instead: function onFoo() { ... }
> [11:59:09:441][0x55a449eb92b0][Info]app/App.cpp:225: "Creating subwindow:
> `qrc:/ui/views/App/Settings/SettingsWindow.qml`."
> [11:59:09:506][0x55a449eb92b0][Info]app/App.cpp:232: "Subwindow status: `1`."
> [11:59:09:682][0x55a449eb92b0][Warning]qrc:/ui/views/App/Settings/SettingsAdvanced.qml:91:
> qrc:/ui/views/App/Settings/SettingsAdvanced.qml:91:7: QML Connections:
> Implicitly defined onFoo properties in Connections are deprecated. Use this
> syntax instead: function onFoo() { ... }
> [11:59:09:911][0x55a449eb92b0][Warning]qrc:/ui/views/App/Settings/SettingsVideo.qml:149:
> qrc:/ui/views/App/Settings/SettingsVideo.qml:149:7: QML Connections:
> Implicitly defined onFoo properties in Connections are deprecated. Use this
> syntax instead: function onFoo() { ... }
> [11:59:09:911][0x55a449eb92b0][Warning]qrc:/ui/views/App/Settings/SettingsVideo.qml:142:
> qrc:/ui/views/App/Settings/SettingsVideo.qml:142:7: QML Connections:
> Implicitly defined onFoo properties in Connections are deprecated. Use this
> syntax instead: function onFoo() { ... }
> [11:59:10:027][0x55a449eb92b0][Warning]app/App.cpp:802: System tray not found
> on this system.
> [11:59:10:062][0x55a449eb92b0][Warning]qrc:/ui/views/App/Main/Assistant/AssistantHome.qml:132:
> qrc:/ui/views/App/Main/Assistant/AssistantHome.qml:132:5: QML Connections:
> Implicitly defined onFoo properties in Connections are deprecated. Use this
> syntax instead: function onFoo() { ... }
> [11:59:10:236][0x55a449eb92b0][Info]components/core/event-count-notifier/AbstractEventCountNotifier.cpp:71:
> "Notify event count: 0."
> [11:59:20:311][0x55a449eb92b0][Info]components/assistant/AssistantModel.cpp:416:
> "Set config on assistant:
> `/usr/share/linphone/assistant/use-other-sip-account.rc`."
> Segmentation fault
When you try to register the account, what steps to you go through? I
presume in the main window you're clicking in this order: Home ->
Assistant -> Use a SIP Account. If so, does Linphone still crash if
you omit the "sip:" prefix in the input field "SIP Domain"? That
field must be a resolvable hostname, domain name or an IP address, and
unfortunately the input validation in that dialog is not as good as it
should be.
If the above advice does not resolve the issue, please give detailed
steps on what you click and what information you enter in each field.
Also exit Linphone and then start a new Linphone instance from a
terminal like this:
catchsegv linphone 2>&1 | tee /tmp/linphone-segfault.txt
Then post that file here after it has crashed.
Regards.
Bug#996880: unconditionally unpauses media playback after call
X-Debbugs-CC: Timo Weingärtner On Wed, Oct 20, 2021 at 09:19:14AM +0200, Timo Weingärtner wrote: > Package: linphone-desktop > Version: 4.2.5-3 > Severity: normal > > steps to reproduce: > * have any positive number of paused youtube videos opened in firefox > * maybe wait hours or days after pausing the last one > * call someone using linphone > * end the call > * be surprised that one of the videos resumes playback > > suggested solution: > * remember whether there was media playback running when the call starts > * only resume playback if it was running before the call I have very strong doubts that linphone-desktop (or rather libmediastreamer2) is the culprit here. A pulseaudio client disconnecting should leave other clients untouched, and clients usually have no way of affecting other clients anyway. This leaves pulseaudio itself and Firefox as suspects. Linphone creates its pulseaudio streams with the property media.role="phone" which pulseaudio internally gives higher priority so that when you get a phone call while watching a movie, the movie stream gets automatically corked for the duration of the call and then uncorked. The event-handling code in Firefox probably does not deal with that correctly leading to the unpausing. This would also make sense because the decision to pause/resume playback happens entirely in the code of a pulseaudio client. The pulseaudio backend code in Firefox currently is under: 91.2.0esr-1/third_party/rust/cubeb-pulse/src/backend/ Upstream at: github.com/mozilla/cubeb-pulse-rs/ What version of Firefox are you running? It would also help a ton if you could state if this bug happens with the Firefox nightly builds from mozilla.org, too. If you want this to ever get even close to being fixed you'll have to find a way to reproduce the issue quicker somehow (restarting pulseaudio, disconnecting and reconnecting network/Internet connection etc.). After that you should start Firefox like this: MOZ_LOG="cubeb:4" firefox --new-instance 2>&1 | tee /tmp/ff-cubeb.log then reproduce the issue and post that log file here. That will hopefully generate enough clues to figure out what is happening. I'll reassign the bug to firefox-esr unless I hear convincing arguments for why the cause is to be sought elsewhere. Regards.
Bug#994437: libortp: missing -lbctoolbox
X-Debbugs-CC: Frank Heckenbach Control: tags -1 confirmed I've put it on the TODO list, so it will be fixed in time. Regards.
Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye
X-Debbugs-CC: Pieter Hollander > auto br0 > iface br0 inet static > address 10.10.10.1 > netmask 255.255.255.0 > bridge_ports none > bridge_stp off > bridge_fd 0 > > iface br0 inet6 static > address 2001:db8::2 > netmask 64 These stanzas are missing the "bridge_hw" entry which can be a MAC address or the name of the interface whose MAC to take. Thus your bridge ends up being connected to nothing. The NEWS.Debian file has details on why this was introduced (the kernel changed behaviour). You aren't the only one who ran into this. Regards.
Bug#981349: kde/plasma does not start under wayland (solved)
X-Debbugs-CC: Antonio
This happened to me, too. I can't tell what the cause in your case
might have been, but in my case it was because I set DISPLAY to ":0"
via ~/.pam_environment which made kwin_wayland believe it is running
within an X server, so it chose the X11 backend without testing if it
could actually connect to the X server first. Since with SDDM (which
I use, too) the sddm-greeter's X server runs as user sddm, the
logged-in user's .Xauthority file will not match (because it is not
updated when entering a Wayland session) and the connection will fail
with an authentication error.
A remedy would be to actually try to open an X display in
kwin/main_wayland.cpp:automaticBackendSelection() and choose a
different plugin if it fails. The code could look as simple as this:
#include
...
static QString automaticBackendSelection(SpawnMode spawnMode)
{
...
if (qEnvironmentVariableIsSet("DISPLAY")) {
if (qEnvironmentVariableIsSet("KWIN_WAYLAND_SKIP_X11CHECK"))
return s_x11Plugin;
Display *d = XOpenDisplay(NULL);
if (d) {
XCloseDisplay(d);
return s_x11Plugin;
}
}
...
}
Since kwin_wayland already links against libX11.so.6 there would be no
new dependencies.
N.B.: There is another very insidious problem here with how
startplasma-wayland chooses default values. If startplasma-wayland is
called without arguments it unconditionally runs:
kwin_wayland --xwayland
--exit-with-session=/path/to/startplasma-waylandsession
But if a user modifies the Exec= line in
/usr/share/wayland-sessions/plasmawayland.desktop to e.g.
/usr/bin/startplasma-wayland --drm
then it runs only this:
kwin_wayland --drm
The user has no way of knowing (beyond studying the source code) that
he must also specify those other options, too, as otherwise the Plasma
session will not be set up correctly due to a missing X server. The
lack of a manpage does not help exactly either.
Regards.
Bug#993036: plasma-workspace: Provide locked sessions
Package: plasma-workspace Version: 5.21.5-3 Severity: wishlist Tags: patch The attached patch creates additional session definitions for X and Wayland that launch Plasma in a locked state. Using them with auto-login makes for a great combination. I had been looking for something like this for years. The patch applies against 5.21.5-3, but I have only tested it with 5.20.5-6. Locked auto-login under X works nicely and it's what I'll be using. Locked auto-login under Wayland works, too, but is a rather rocky experience IMO. I also recommend using throwaway user accounts for testing (to not mess up your saved session) and running top/htop on a separate VT during the familiarization phase and keeping an eye on CPU usage. Notable observations from my testing: * kwin_wayland pegs the CPU to ~385% until you unlock the session (with DRM backend on nouveau). I guess disabling some effects could reduce that, but I haven't looked into that. * Consequently mouse movement is choppy, and you have to put the pointer directly over the password field for it to retain focus. * The window dimensions of the kscreenlocker_greet window change once Plasma launches the Task Manager leaving a black bar at the position where the Task Manager would be. * Also upon logout sometimes stray processes (korgac, kactivitymanager, kded5) stay around which consume ~200 % CPU till killed. I can't reliably reproduce this yet, though, so it might be nothing. Regards, Dennis Filder --- a/debian/rules +++ b/debian/rules @@ -11,6 +11,18 @@ include /usr/share/pkg-kde-tools/qt-kde-team/2/library-packages.mk override_dh_auto_configure: dh_auto_configure -Skf5 -- -DBUILD_TESTING=OFF +override_dh_auto_install: + dh_auto_install --buildsystem=kf5 -i -O--buildsystem=kf5 + rm -f debian/tmp/usr/share/xsessions/plasmalocked.desktop debian/tmp/usr/share/wayland-sessions/plasmawaylandlocked.desktop + cp -a debian/tmp/usr/share/xsessions/plasma.desktop debian/tmp/usr/share/xsessions/plasmalocked.desktop + cp -a debian/tmp/usr/share/wayland-sessions/plasmawayland.desktop debian/tmp/usr/share/wayland-sessions/plasmawaylandlocked.desktop + sed -f debian/genlockedplasma.sed -i debian/tmp/usr/share/xsessions/plasmalocked.desktop + sed -f debian/genlockedplasma.sed -i debian/tmp/usr/share/wayland-sessions/plasmawaylandlocked.desktop +# Test if the above actually took effect and error out if it didn't + grep -q -e DESKTOP_LOCKED=true debian/tmp/usr/share/xsessions/plasmalocked.desktop + grep -q -e --lockscreen debian/tmp/usr/share/wayland-sessions/plasmawaylandlocked.desktop + grep -q -e '^Name=.*(Wayland)$$' debian/tmp/usr/share/wayland-sessions/plasmawaylandlocked.desktop + override_dh_auto_test: # Disable auto tests at build time : --- a/debian/plasma-workspace.install +++ b/debian/plasma-workspace.install @@ -66,3 +66,4 @@ usr/share/kservicetypes5/ usr/share/metainfo/ usr/share/solid/actions/test-predicate-openinwindow.desktop usr/share/xsessions/plasma.desktop +usr/share/xsessions/plasmalocked.desktop --- a/debian/plasma-workspace-wayland.install +++ b/debian/plasma-workspace-wayland.install @@ -1,3 +1,4 @@ usr/bin/startplasma-wayland usr/lib/*/libexec/startplasma-waylandsession usr/share/wayland-sessions/plasmawayland.desktop +usr/share/wayland-sessions/plasmawaylandlocked.desktop --- /dev/null +++ b/debian/genlockedplasma.sed @@ -0,0 +1,26 @@ +# -*- mode: conf; -*- + +# https://github.com/sddm/sddm/issues/306 has some discussion + +s@^Exec=\(/usr/.*/startplasma-x11.*\)$@Exec=/usr/bin/env DESKTOP_LOCKED=true \1@ +# The Plasma devs in their infinite wisdom made startplasma-wayland +# ignore DESKTOP_LOCKED. Also because their approach to command line +# defaults is a bit unorthodox, we have to specify the command line +# in full like so carefully preserving arch-specific paths. +s@^Exec=/usr/\(.*/libexec\)/\(plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland.*\)$@Exec=/usr/\1/\2 --lockscreen --xwayland --exit-with-session /usr/\1/startplasma-waylandsession@ + +# sddm in src/common/Session.cpp:Session::setTo() foolishly expects +# the string "(Wayland)" at the very end of Name= (instead of e.g. +# inspecting Type=), so we must preserve it until they fix the code. +# +# Consider using U+1F510 CLOSED LOCK WITH KEY () or U+1F512 LOCK +# () once Qt supports it. +#s@^Name=\(Plasma\)\(.*\)$@Name=\1 \2@ +#s@^Name=\(Plasma\)\(.*\)$@Name=Locked \1\2@ +#s@^Name=\(Plasma\)\(.*\)$@Name=\1 „-o\2@ +#s@^Name=\(Plasma\)\(.*\)$@Name=\1 o––⃩\2@ +#s@^Name=\(Plasma\)\(.*\)$@Name=\1 o¬\2@ +#s@^Name=\(Plasma\)\(.*\)$@Name=\1 ◯—▄\2@ +s@^Name=\(Plasma\)\(.*\)$@Name=\1 [locked]\2@ + +s@^Comment=\(.*\)$@Comment=\1 (locked)@
Bug#804561: GCC can't compile a program using RDSEED intrinsics
Control: tag - bullseye bookworm This can be closed as the bug no longer manifests. The first version of gcc-9 with the fix[0] that reached testing was 9.1.0-10 on 2019-07-26. In 8.* it has never been fixed. Regards, Dennis Filder. 0: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6c0d746f66cd349be052ca207e2397570f8aa314
Bug#971393: [FYI] New mbedtls LTS version upcoming in 2021 (likely 2.28)
X-Debbugs-CC: ant...@friki.cat, gs-debian@gluelogic.com In [0,1] it was announced that 2021 will see a new LTS release (2.28) for mbedtls: Dave Rodgman <...> wrote on Thu Jul 29 13:05:10 UTC 2021: > We expect to release an LTS later this year. It’s likely to be 2.27, > and very likely will be supported for the usual LTS period of 3 > years. > > So if you are considering updating to a new LTS, you could use 2.26 > for prototyping in the short term until the LTS becomes > available. The upcoming LTS will be API-compatible with 2.26. Gilles Peskine <...> wrote on Thu Jul 29 13:24:58 UTC 2021: > Off-by-one error! The current 2.x release is 2.27.0. Most > development work is happening on 3.x but there will be at least one > more 2.x release: 2.28.0. The last 2.x release will become an LTS. Regards, Dennis Filder. 0: https://lists.trustedfirmware.org/pipermail/mbed-tls/2021-July/000422.html 1: https://lists.trustedfirmware.org/pipermail/mbed-tls/2021-July/000423.html
Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface
X-Debbugs-CC: Roman Fiedler On Sat, Aug 14, 2021 at 08:18:00PM +, Roman Fiedler wrote: > > iface virtbr0 inet static > > address 192.168.1.1 > > netmask 255.255.255.0 > > bridge_hw 86:aa:aa:aa:aa:aa > > Weird, using the configuration from above will result in: > > $ ifup virtbr0 > Cannot find device "virtbr0" > ifup: failed to bring up virtbr0 It is because the "bridge_ports" directive is missing. From the manpage bridge-utils-interfaces(5): bridge_ports interface specification this option must exist for the scripts to setup the bridge. Either specify "bridge_ports none" or "bridge_ports enp2s0 enp2s1" (or whatever your physical interfaces are named). > I also reactivated "systemd-udevd": > > $ systemctl start systemd-udevd-kernel.socket > $ systemctl start systemd-udevd-control.socket > $ systemctl start systemd-udevd.service > > And then tried to use the link, but I am not sure, if it is active > without rebooting as "reload" does not seem to be the right command > for it. > > # systemctl reload /lib/systemd/network/80-bridgeutils.link > Failed to reload lib-systemd-network-80\x2dbridgeutils.link.mount: Unit > lib-systemd-network-80\x2dbridgeutils.link.mount not found. Running "systemctl daemon-reload" would have been the correct thing to do here. > Without rebooting (which at the moment would be annoying for > the test machine), the "hw_address" does still not work: > > iface virtbr0 inet static > address 192.168.1.1 > netmask 255.255.255.0 > pre-up brctl addbr virtbr0 > post-down brctl delbr virtbr0 > bridge_hw 86:aa:aa:aa:aa:aa > > but now the MAC seems truely random each time the bridge is created: This is because with systemd-udevd stopped (or told to not touch bridge devices through 80-bridgeutils.link) the MAC address the kernel assigns upon device creation (which is randomly generated every time) remains untouched. systemd-udevd would also assign a random MAC address, but generates the same one every time (it's random only compared to the burnt-in MAC address). Regards.
Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface
X-Debbugs-CC: Roman Fiedler , Michael Tokarev
As stated in the documentation, bridge-utils recently added support
for the "bridge_hw" directive which allows you define a MAC address
for a bridge interface. Changing your stanza to just this should
already work:
iface virtbr0 inet static
address 192.168.1.1
netmask 255.255.255.0
bridge_hw 86:aa:aa:aa:aa:aa
If you also use systemd, then systemd-udevd may cause trouble because
in its default configuration it will assign a randomly generated MAC
address to the bridge device which might cause a race.
I haven't tried this, but putting this udev rule into
/etc/udev/rules.d/95-bridge.rules should prevent systemd-udevd from
touching any bridge interfaces at all:
ACTION=="add", SUBSYSTEM=="net", DEVTYPE=="bridge", ENV{TAGS}-="systemd"
Alternatively placing the file 80-bridge-utils.link from #991416
(message #17)[0] into /lib/systemd/network/ should work as well.
Regards,
Dennis Filder
0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991416#17
Bug#989845: pulseaudio: Needless Depends: on libasound2-plugins should be turned back into Recommends:
On Thu, Jul 29, 2021 at 09:10:58AM -0400, Felipe Sateler wrote: > Well, without libasound2-plugins plain alsa apps cannot output to > pulseaudio. That's the reason we want it. OTOH, this may fit the > definition of "all but unusual installations". Using only packages depending on libpulse0 with pulseaudio is an entirely valid use case (e.g. just using Firefox and a softphone on a thin client). These users shouldn't have to live with a 200 MB burden. > Happy to review a salsa MRs, especially if they also address 963582. Let's not needlessly couple these issues: Fixing this bug by reverting the Depends is trivial, but fixing #963582 is not esp. if the Apparmor profile has to be modularized, too, and because it will probably require splitting off the X-related modules into a separate package. I have done some exploratory work, but it is still just at the proof-of-concept stage. I will prepare a MR for that once I have something that's a bit more presentable. Regards, Dennis.
Bug#991588: systemd: Buster to Bullseye: boot stalls at network loading on normal boot
X-Debbugs-CC: Martin-Éric Racine
A couple of observations:
* You have tpm2-abrmd installed, and its systemd unit is the only one
defining a Requires=systemd-udev-settle.service. 2.1.0-1 under
Buster didn't do that yet, so this could be the breaking change. As
its manpage states systemd-udev-settle.service as a unit is
conceptually problematic because udev events are never really
settled; the unit is also deprecated, so tpm2-abrmd should correct
its systemd/udev definitions.
* Another potential issue is this line:
post-up systemctl restart micro-httpd.socket
The call to systemctl might be blocking.
* Both ifupdown-pre.service and systemd-udev-settle.service run
"udevadm settle" in ExecStart=
* These dependencies are defined:
systemd-udev-trigger.service: Before=systemd-udev-settle.service
ifupdown-pre.service: After=systemd-udev-trigger.service
systemd-udev-settle.service: After=systemd-udev-trigger.service
sysinit.target: After=systemd-udev-settle.service
micro-httpd.socket: {After,Requires}=sysinit.target
I wonder if that micro-httpd.socket definition amounts to a circular
dependency resulting in a deadlock.
I recommend uncommenting the post-up line from /etc/network/interfaces
just to see if this solves the problem. Alternatively try disabling
tpm2-abrmd.service temporarily.
Regards,
Dennis.
Bug#991416: bridge-utils: broken IPv4 connection after upgrading to Debian Bullseye, setting old MAC with bridge_hw fixes the issue
Control: tags -1 patch X-Debbugs-CC: Matthias Bosc , Martin-Éric Racine @Matthias: This was documented in NEWS.Debian: Linux kernel has changed bridge MAC address selection. In older Linux kernels the MAC of the bridge was the lower mac of the devices attached to it, this is no longer the case now at Bullseye. The kernel now makes up a completely new MAC address. This means that if you rely on your bridge's MAC address for something like DHCP leases or similar stuff you'll loose this feature. The only way to go back to your old MAC address is to assign it to the bridge explicitly using bridge_hw followed by the wanted MAC address on your bridge definition. The attached systemd unit and patch (against 1.7-1) try to recreate the old behaviour, but probably need more testing by people with realistic setups. The problem of also considering fleeting MAC addresses (e.g. from virtual and removable devices) could be solved by: udevadm info -q property /sys/class/net/$IFACE|sed -n '/^ID_BUS=/s@^ID_BUS=@@p' For virtual devices the output will be "", for removable devices usually "usb" and for fix devices usually "pci" or something else. You can then filter MAC addresses based on that. @Martin-Éric: Why did you lower the severity? @Santiago: Feel free to remove the patch tag if you have doubts about its quality. Regards, Dennis --- /usr/lib/bridge-utils/ifupdown.sh-orig +++ /usr/lib/bridge-utils/ifupdown.sh @@ -13,6 +13,12 @@ . /lib/bridge-utils/bridge-utils.sh +# hardware address assignment types (from linux/include/uapi/linux/netdevice.h) +NET_ADDR_PERM=0 +NET_ADDR_RANDOM=1 +NET_ADDR_STOLEN=2 +NET_ADDR_SET=3 + case "$IF_BRIDGE_PORTS" in "") exit 0 @@ -117,6 +123,37 @@ # We finish setting up the bridge if [ "$MODE" = "start" ] ; then + # If bridge_hw is not set then mimic the old "lowest MAC wins" + # selection algorithm. Doing this after attaching the ports lets us + # conveniently grep for "master $IFACE". To mimic the v3.15 + # behaviour closely we only set the MAC address if the assignment + # type of $IFACE is still NET_ADDR_RANDOM (on systemd systems this + # needs /lib/systemd/network/80-bridge-utils.link). + if [ -z "$IF_BRIDGE_HW" -a -e "/sys/class/net/$IFACE/addr_assign_type" ] + then +IF_BRIDGE_HW="$(ip -oneline link show |grep -F " master $IFACE "|sed 's@^.*link/ether @@'|cut -d' ' -f1|sort|head -n1)" +if [ -n "$IF_BRIDGE_HW" -a "$(cat /sys/class/net/$IFACE/addr_assign_type)" -eq "$NET_ADDR_RANDOM" ] +then + ip link set dev "$IFACE" address "$IF_BRIDGE_HW" + printf "\nWarning: The old lowest-MAC-wins compatibility mode is deprecated and will be removed in future releases of bridge-utils." >&2 + printf "\nSee /usr/share/doc/bridge-utils/NEWS.Debian.gz for details." >&2 + SENDMAIL="$(command -v sendmail)" + if [ -n "$SENDMAIL" -a -x "$SENDMAIL" ] + then + printf "Subject: bridge-utils: deprecation warning\n\nWarning: The old lowest-MAC-wins compatibility mode is deprecated and will be removed in future releases of bridge-utils.\nSee /usr/share/doc/bridge-utils/NEWS.Debian.gz for details.\n.\n" | "$SENDMAIL" -bm root + fi +elif [ -n "$IF_BRIDGE_HW" -a "$(cat /sys/class/net/$IFACE/addr_assign_type)" -eq "$NET_ADDR_SET" ] +then + # issue a diagnostic warning if someone set the MAC already, but + # it's not the lowest address of its ports + IF_BRIDGE_HW_CUR="$(ip link show dev $IFACE|grep 'link/ether'|cut -d/ -f2-|cut -d' ' -f2)" + if [ "$IF_BRIDGE_HW" != "$IF_BRIDGE_HW_CUR" ] + then + printf "\nWarning: userspace-assigned MAC address for bridge %s is %s, but should be %s." "$IFACE" "$IF_BRIDGE_HW_CUR" "$IF_BRIDGE_HW" >&2 + fi +fi + fi + if [ "$IF_BRIDGE_AGEING" ] then brctl setageing $IFACE $IF_BRIDGE_AGEING # /lib/systemd/network/80-bridgeutils.link (bridge-utils) # # By default systemd-udevd overwrites the kernel's randomly assigned # MAC address with its own randomly generated one. This file prevents # that and thus allows observers to tell if someone has set the MAC # address on a bridge device already. The lowest-MAC-wins # compatibility code in /usr/lib/bridge-utils/ifupdown.sh relies on # this. [Match] OriginalName=* Driver=bridge [Link] MACAddressPolicy=none
Bug#991320: flameshot crashing on startup
Control: tag -1 patch upstream
X-Debbugs-CC: allan grossman
On Wed, Jul 21, 2021 at 04:47:17PM -0500, allan wrote:
> [General]
> disabledTrayIcon=true
Okay, I can reproduce the crash now with that setting. The update
check silently assumes that tray and its associated member variables
have been initialized.
The attached patch at least prevents flameshot from crashing. A
proper fix would ensure that any enabled feature that depends on
disabled features automatically gets disabled, too.
Regards.
Description: Fix nullptr dereference
It occurs when the user has disabledTrayIcon=true, but also
checkForUpdates=true (explicitly or the default).
Last-Update: 2021-07-22
Author: Dennis Filder
--- a/src/core/controller.cpp
+++ b/src/core/controller.cpp
@@ -192,7 +192,8 @@
m_appLatestUrl = json["html_url"].toString();
QString newVersion =
tr("New version %1 is available").arg(m_appLatestVersion);
-m_appUpdates->setText(newVersion);
+if (m_appUpdates != nullptr)
+m_appUpdates->setText(newVersion);
if (m_showCheckAppUpdateStatus) {
sendTrayNotification(newVersion, "Flameshot");
QDesktopServices::openUrl(QUrl(m_appLatestUrl));
Bug#991320: flameshot crashing on startup
X-Debbugs-CC: allan grossman On Wed, Jul 21, 2021 at 02:20:37PM -0500, allan wrote: > this doesn't look real helpful - looks like I may need to install some > source code but not sure which code other than flameshot - No, it shows exactly what I was looking for: > (gdb) backtrace 5 > #0 QAction::setText (this=0x0, text=...) > at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:116 The this pointer is null, i.e. m_appUpdates is still uninitialized when the call to setText() happens. That is something the upstream devs can't easily argue away. But the question is: Why is it null/uninitialized? Either because Openbox lacks a feature Qt needs for making system trays (and flameshot doesn't properly check for that failing), or because your Internet connection is too fast leading to the wrong race condition outcome. Was flameshot working normally with Openbox in the past? You could also try if lowering your connection speed (latency, throughput) resolves the issue. Maybe going to a coffee shop or some other place with slow Internet is the easiest way. Otherwise you'll have to fiddle with netem[0,1] or the firewall and find ways to throttle speed that way (I can't help you with that). Also: I saw that AppImages[2] are provided, but apparently not for version 0.10.0[3]. It would have been valuable to know if the error occurs with that, too. Maybe you can try the Snap image (I have no experience with using that). If running that via shell is for some reason not possible segfaults should show up in the output of dmesg. Regards. 0: https://stackoverflow.com/questions/24729545/how-to-tc-filter-with-netem 1: https://wiki.linuxfoundation.org/networking/netem 2: https://flameshot.org/guide/installation/installation-linux/#appimage 3: https://github.com/flameshot-org/flameshot/releases/tag/v0.10.0
Bug#991320: flameshot crashing on startup
X-Debbugs-CC: allan grossman Okay, download the debug symbols from: http://debug.mirrors.debian.org/debian-debug/pool/main/f/flameshot/flameshot-dbgsym_0.9.0+ds1-1_amd64.deb http://debug.mirrors.debian.org/debian-debug/pool/main/q/qtbase-opensource-src/libqt5widgets5-dbgsym_5.15.2+dfsg-9_amd64.deb Put them in /tmp and make them world-readable, then install as root (e.g. apt install /tmp/flameshot-dbgsym_0.9.0+ds1-1_amd64.deb /tmp/libqt5widgets5-dbgsym_5.15.2+dfsg-9_amd64.deb). Then run "gdb flameshot" again and type: start break Controller::handleReplyCheckUpdates(QNetworkReply*) continue break QAction::setText(QString const&) continue backtrace 5 The output should look like this. #0 QAction::setText (this=0x558b52b0, text=...) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:116 #1 0x555b2267 in Controller::handleReplyCheckUpdates (this=0x55642160 , reply=0x7fffcbe0) at ./src/core/controller.cpp:195 #2 0x76d755a6 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #3 0x77dd5ad2 in QNetworkAccessManager::finished(QNetworkReply*) () from /lib/x86_64-linux-gnu/libQt5Network.so.5 #4 0x77dd6e17 in ?? () from /lib/x86_64-linux-gnu/libQt5Network.so.5
Bug#991320: flameshot crashing on startup
X-Debbugs-CC: allan grossman On Wed, Jul 21, 2021 at 12:51:16PM -0500, allan wrote: > couldn't get past "start" - Okay, omit "start" and "continue" and just type the "backtrace 5" command.
Bug#991320: flameshot crashing on startup
X-Debbugs-CC: allan grossman After looking at the code I'm fairly certain the segfault happens in Controller::handleReplyCheckUpdates() in src/core/controller.cpp which gets passed to the connect() call. The culprit is probably line 195: m_appUpdates->setText(newVersion); Since I cannot reproduce it I can't look at it in a debugger. Allan, if you want you can try running this in gdb like so: gdb flameshot and then in gdb start continue backtrace 5 and give us the output. I speculate for people with very fast Internet connections the call to setText() happens before m_appUpdates gets initialized, maybe because the compiler reorders statements. A fix could consist of one of these changes: * Return immediately from src/core/controller.cpp:Controller::getLatestAvailableVersion() to disable update checks altogether. * Initialize res with false instead of true in src/utils/confighandler.cpp:ConfigHandler::checkForUpdates() to turn off update checks by default. Regards.
Bug#991320: flameshot crashing on startup
X-Debbugs-CC: allan grossman On Tue, Jul 20, 2021 at 02:54:26PM -0500, allan wrote: > Setting checkForUpdates=false resolved the issue. Thanks, Dennis :) Okay, that is good to know. I personally feel like that option should be set to false by default in Debian (don't the pop-ups annoy the hell out of people?). Of course the segfault as a problem remains, but that is upstream's issue. Also I suspect I know why I couldn't reproduce this: I sit behind a proxy, so maybe Qt's networking code behaves differently then. There is a lot going on in the strace log, but the crash happened after the hostname for api.github.com was resolved. Regards.
Bug#991320: flameshot crashing on startup
X-Debbugs-CC: allan grossman On Tue, Jul 20, 2021 at 02:16:16PM -0500, allan wrote: > apt log shows qt libraries updated three days ago - these wouldn't > have made it to Bullseye yet. > > Start-Date: 2021-07-17 08:52:52 > Requested-By: wizard (1000) > Install: libqt5quickwidgets5:amd64 (5.15.2+dfsg-6, automatic), > qml-module-qtquick-window2:amd64 (5.15.2+dfsg-6, automatic), sox:amd64 > (14.4.2+git20190427-2, automatic), qml-module-qt-labs-settings:amd64 > (5.15.2+dfsg-6, automatic), qml-module-qtmultimedia:amd64 (5.15.2-3, > automatic), libqt5multimediaquick5:amd64 (5.15.2-3, automatic), > libsox3:amd64 (14.4.2+git20190427-2, automatic), mystiq:amd64 > (20.03.23-2), qml-module-qt-labs-folderlistmodel:amd64 (5.15.2+dfsg-6, > automatic), libsox-fmt-alsa:amd64 (14.4.2+git20190427-2, automatic), > libqt5multimediawidgets5:amd64 (5.15.2-3, automatic), > qml-module-qtquick-privatewidgets:amd64 (5.15.2-2, automatic), > libsox-fmt-base:amd64 (14.4.2+git20190427-2, automatic), > qml-module-qtquick2:amd64 (5.15.2+dfsg-6, automatic), > qml-module-qtquick-dialogs:amd64 (5.15.2-2, automatic), > libqt5qmlworkerscript5:amd64 (5.15.2+dfsg-6, automatic), > qml-module-qtqml:amd64 (5.15.2+dfsg-6, automatic) > End-Date: 2021-07-17 08:52:58 All those libraries are on my system already. I think this late in the freeze some libraries get fast-tracked into testing on request. > Backtrace: > /lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN7QAction7setTextERK7QString+0x5)[0x7fd8dbd48005] > flameshot(+0x5e267)[0x55efcb2b6267] > /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6] > /lib/x86_64-linux-gnu/libQt5Network.so.5(_ZN21QNetworkAccessManager8finishedEP13QNetworkReply+0x42)[0x7fd8dc2b6ad2] > /lib/x86_64-linux-gnu/libQt5Network.so.5(+0x44e17)[0x7fd8dc2b7e17] > /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6] > /lib/x86_64-linux-gnu/libQt5Network.so.5(+0xa08b8)[0x7fd8dc3138b8] > /lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0x291)[0x7fd8db249ff1] > ... The only reason for flameshot to touch the network (which it presumably does here) is to check for updates. Try setting "checkForUpdates" to "false" in ~/.config/flameshot/flameshot.ini -- maybe this will preclude the codepath in question from being taken. Let us know if this fixes it for you -- if not, then I don't really see what more could be done here. Maybe running strace -s2048 -f -e 'trace=%net' -o /tmp/flameshot.strace flameshot will reveal what network facility it tries to contact before it crashes. Regards, Dennis.
Bug#991320: flameshot crashing on startup
X-Debbugs-CC: allan grossman On Tue, Jul 20, 2021 at 01:16:39PM -0500, allan wrote: > This has only been broken for a couple of days - there's a strong > possibility that whatever broke it hasn't made it to Bullseye yet. > This appears to be an upstream bug because a Manjaro user running same > version of flameshot and Qt is experiencing same behavior and as > mentioned, it broke a couple of days ago. When exactly did it break and what packages did you install that could have made it break? /var/log/apt/history.log should have the answer. Again: Does running flameshot with GDK_BACKEND=x11 fix it for you -- yes or no? Do you run wayland or xorg? Also, you say it crashes. How does it crash? Segfault? What is the exact message? What is the output if you run it like this?: catchsegv flameshot You have to give us something to work with.
Bug#991320: flameshot crashing on startup
X-Debbugs-CC: allan grossman I can't reproduce this under current Bullseye KDE/xorg -- flameshot behaves absolutley normally. It could be a Wayland issue, and flameshot's Wayland support is apparently still experimental. Let us know if running flameshot like so fixes this for you: GDK_BACKEND=x11 flameshot Regards, Dennis Filder
Bug#983369: linphone-desktop: chat msgs and (missed) incoming calls dates are wrong
Control: tag -1 confirmed X-Debbugs-CC: David Pirotte On linphone-users others posted similar reports. I can reproduce this by setting my timezone from +0200 to -0400. I'll try to look into it after the freeze ends. Regards.
Bug#991060: Processed: mlpost FTBFS with imagemagick with the #987504 change
On Sat, Jul 17, 2021 at 10:42:03AM +0200, Stéphane Glondu wrote: > Package builds are not allowed to fiddle with $HOME like that, by > policy: what if the builder already has its own imagemagick policy? But > I think your idea can be used: create a temporary home directory (e.g. > in debian or /tmp), and set $HOME to that. mlpost expresses "debhelper-compat (= 13)" in d/control. From the manpage: HOME, XDG_* In compat 13 and later, these environment variables are reset before invoking the upstream build system via the dh_auto_* helpers. The variables HOME (all dh_auto_* helpers) and XDG_RUNTIME_DIR (dh_auto_test only) will be set to a writable directory. All remaining variables and XDG_RUNTIME_DIR (except for during dh_auto_test) will be cleared. The HOME directory will be created as an empty directory but it will be reused between calls to dh_auto_*. Any content will persist until explicitly deleted or dh_clean. So there should be no problems. In my patches for other packages affected by this and not yet on 13 I used XDG_CONFIG_HOME and created/removed a tempdir under debian/tmp by hand. But relying on dh_clean is more consistent. Regards, Dennis.
Bug#991061: ns3 FTBFS with imagemagick with the #987504 change
On Fri, Jul 16, 2021 at 09:02:44PM +0200, Martin Quinson wrote: > I'm sorry to ask, but I fear I need additional information, please. > It seems to me that this patch merely circumvent the change in > ImageMagik to allow the handling of eps file during the construction > of the package. Am I right, or is it only disabling the dangerous > parts of the converter while retrieving the parts we need? > > Sorry to ask, I'm very bad with ImageMagik. > > Even if it's re-enabling the conversion of eps files for the package > building, I guess that this is a good emergency solution to not delay > the release too much, provided that we trust the eps files that come > with ns-3. Thanks for the proposal. You have to trust the EPS files in your package like everything else anyway. AIUI the restriction in /etc/ImageMagick-6/policy.xml exists as a stop-gap to keep people from accidentally running ImageMagick on untrusted input (e.g. shoddily-written CGI scripts that don't sanitize input correctly). Seccomp filters would be a better approach, but since ImageMagick has to also work under Windows that's unlikely to ever happen. If ImageMagick were too dangerous to use even on trusted input then shipping it at all wouldn't make any sense. > But I would prefer not to live with such a complex and even somewhat > dangerous patch in my package, so I'm curious about other solutions > that would allow to convert eps to png without ImageMagik. Maybe using > gimp and Script-Fu? pdftoppm from poppler-utils is another option. Ubuntu's version of sctk has a patch for that: https://patches.ubuntu.com/s/sctk/sctk_2.4.10-20151007-1312Z+dfsg2-3ubuntu1.patch (But I don't believe for a single second that that parser is any safer than what comes in ImageMagick.) Regards
Bug#991060: mlpost FTBFS with imagemagick with the #987504 change
Control: tag -1 patch The attached patch should fix this. Regards, Dennis Filder Description: Override ImageMagick policy Derive an appropriate policy from the too strict default one. Author: Dennis Filder Last-Update: 2021-07-16 Bug-Debian: https://bugs.debian.org/991060 --- a/ocamlbuild.Makefile +++ b/ocamlbuild.Makefile @@ -44,6 +44,7 @@ EXTDLL = .so DLL := backend/dllmlpost_ft$(EXTDLL) backend/libmlpost_ft.a +POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')"/policy.xml ifeq "$(OCAMLBEST)" "opt" all: @@ -195,7 +196,10 @@ .PHONY: doc doc: rm -f doc + test -d $(HOME)/.magick || mkdir -p $(HOME)/.magick + sed -e '//s@"none"@"read|write"@' $(POLFILE) > $(HOME)/.magick/policy.xml $(OCAMLBUILD) doc/index.html + rm -Rf $(HOME)/.magick ln -s _build/doc doc # clean
Bug#991057: gri FTBFS with imagemagick with the #987504 change
Control: tag -1 patch The attached patch fixed this for me. Regards. --- debian/rules-orig +++ debian/rules @@ -21,6 +21,8 @@ ARCH := $(shell dpkg --print-architecture | perl -pe chop) +POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml" + build: build-indep build-arch # Build architecture-dependent files here (no need to be root). @@ -69,7 +71,10 @@ # Build architecture-independent files here (no need to be root). build-indep: debian/gri_merge.1 Makefile - cd doc; make refcard.ps cmdrefcard.ps gri.pdf html + mkdir -p debian/tmp/ImageMagick + sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml + cd doc; make XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" refcard.ps cmdrefcard.ps gri.pdf html + rm -Rf debian/tmp/ImageMagick # Install (as root) architecture-independent files here. binary-indep: build-indep
Bug#991053: ftgl FTBFS with imagemagick with the #987504 change
Control: tag -1 patch The attached patch makes generating the EPS files work. Regards --- debian/rules-orig +++ debian/rules @@ -9,11 +9,16 @@ ^(\./\.git/.*|\./debian/.*|\./\.pc/.*|\./test/font_pack/(El_Abogado_Loco\.ttf|timR12-ISO8859-1\.pcf\.gz)|\./docs/images/.*\.png|\./docs/FTGL_1_3\.gif)$ +POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml" + %: dh $@ override_dh_auto_build: - dh_auto_build -- GLUT_LIBS="$(GLUT_LIBS)" + mkdir -p debian/tmp/ImageMagick + sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml + dh_auto_build -- GLUT_LIBS="$(GLUT_LIBS)" XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" + rm -Rf debian/tmp/ImageMagick override_dh_makeshlibs: dh_makeshlibs -p libftgl2 -V "libftgl2 (>= $(SHLIBVER))"
Bug#991068: xnee FTBFS with imagemagick with the #987504 change
Control: tag -1 patch
The attached patch allowed me to build xnee.
Regards.
Description: Override overly strict ImageMagick default security policy (#987504)
This derives a more permissive policy from the system default policy.
.
XDG_CONFIG_HOME is only set for invocations of convert instead of
globally to minimize inadvertent side-effects.
Author: Dennis Filder
Last-Update: 2021-07-16
Bug-Debian: https://bugs.debian.org/991068
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -15,6 +15,8 @@
# $(MANUALS)
+POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml"
+
if BUILDDOC
DOC_DEP=$(GEN_IMAGES_TO_INSTALL) $(MANUALS)
doc_DATA = $(MANUALS) $(GEN_IMAGES_TO_INSTALL)
@@ -93,18 +95,24 @@
%.png: %.eps
@echo "creating PNG"
- $(CONVERT) -density 144x144 $< $@
+ mkdir -p debian/tmp/ImageMagick
+ sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml
+ XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" $(CONVERT) -density 144x144 $< $@
( mv $@ `echo $@ | sed 's,\.png,_big\.png,g'` )
- $(CONVERT) -density 32x32 $< $@
+ XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" $(CONVERT) -density 32x32 $< $@
( mv $@ `echo $@ | sed 's,\.png,_small\.png,g'` )
- $(CONVERT) -density 60x60 $< $@
+ XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" $(CONVERT) -density 60x60 $< $@
+ rm -Rf debian/tmp/ImageMagick
%.jpg: %.eps
echo "creating JPG"
- $(CONVERT) -density 144x144 $< $@
+ mkdir -p debian/tmp/ImageMagick
+ sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml
+ XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" $(CONVERT) -density 144x144 $< $@
( mv $@ `echo $@ | sed 's,\.jpg,_big\.jpg,g'` )
- $(CONVERT) -density 32x32 $< $@
+ XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" $(CONVERT) -density 32x32 $< $@
( mv $@ `echo $@ | sed 's,\.jpg,_small\.jpg,g'` )
- $(CONVERT) -density 60x60 $< $@
+ XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" $(CONVERT) -density 60x60 $< $@
+ rm -Rf debian/tmp/ImageMagick
${IMG_EPS}: ${IMG_DIA}
Bug#991066: vlfeat FTBFS with imagemagick with the #987504 change
Control: tag -1 patch
The attached patch should fix this by overriding the policy.
Regards,
Dennis Filder
--- rules-orig
+++ rules
@@ -10,12 +10,16 @@
# grab the API version from the library SONAME
API_VERSION = $(shell objdump -p bin/*/libvl.so | perl -ne 'if(/^\s+SONAME\s+libvl.so./p) {print $${^POSTMATCH}; exit;}')
+POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml"
+
%:
dh $@
override_dh_auto_build:
- make PYTHON=python3 MKOCTFILE=`which mkoctfile` VERB=1 CFLAGS+=-g all doc
-
+ mkdir -p debian/tmp/ImageMagick
+ sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml
+ make XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" PYTHON=python3 MKOCTFILE=`which mkoctfile` VERB=1 CFLAGS+=-g all doc
+ rm -Rf debian/tmp/ImageMagick
override_dh_auto_install: $(addprefix install/,data $(wildcard toolbox/*))
cp bin/*/libvl.so libvl.so.$(VERSION)
Bug#991064: therion FTBFS with imagemagick with the #987504 change
Control: tag -1 patch The attached patch seems to allow the "Converting images" step to succeed. I ran this only once though. Regards. --- debian/rules-orig +++ debian/rules @@ -2,6 +2,9 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow future=+lfs export DH_VERBOSE=1 + +POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml" + %: dh $@ @@ -11,7 +14,10 @@ # We need therion itself to build the samples $(MAKE) therion # create HTML documentation for samples - faketime "$(dpkg-parsechangelog -S Date)" $(MAKE) samples + mkdir -p debian/tmp/ImageMagick + sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml + faketime "$(dpkg-parsechangelog -S Date)" $(MAKE) XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" samples + rm -Rf debian/tmp/ImageMagick endif $(MAKE) thbook
Bug#991061: ns3 FTBFS with imagemagick with the #987504 change
Control: tag -1 patch With this patch the build finished for me. Regards, Dennis Filder Description: Override overly strict ImageMagick security policy (#987504) This patch derives a more permissive ImageMagick security policy from the system default. Author: Dennis Filder Last-Update: 2021-07-16 Bug-Debian: https://bugs.debian.org/991061 --- a/ns-3.31/doc/models/Makefile +++ b/ns-3.31/doc/models/Makefile @@ -496,6 +496,8 @@ RESCALE = ../../utils/rescale-pdf.sh +POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml" + %.eps : %.dia @echo dia $(notdir $<) @$(DIA) -t eps $< -e $@ >/dev/null @@ -506,7 +508,9 @@ %.png : %.eps @echo convert $(notdir $<) - @$(CONVERT) $< $@ >/dev/null + test -d ../../../debian/tmp/ImageMagick || mkdir -p ../../../debian/tmp/ImageMagick + test -f ../../../debian/tmp/ImageMagick/policy.xml || sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > ../../../debian/tmp/ImageMagick/policy.xml + XDG_CONFIG_HOME="$(shell pwd)/../../../debian/tmp" $(CONVERT) $< $@ >/dev/null %.pdf : %.eps @echo epstopdf $(notdir $<) @@ -556,6 +560,7 @@ clean: -rm -rf $(BUILDDIR)/* -rm -rf $(SOURCETEMP) + -rm -Rf ../../../debian/tmp/ImageMagick frag: pickle @if test ! -d $(BUILDDIR)/frag; then mkdir $(BUILDDIR)/frag; fi
Bug#991067: x4d-icons FTBFS with imagemagick with the #987504 change
Control: tag -1 patch
The attached patch should fix this by loading a more permissive policy.
Regards,
Dennis Filder.
Description: Override overly strict ImageMagick coder policy (#987504)
This creates a more permissive version of
/etc/ImageMagick-6/policy.xml and ensures it gets loaded after the
one from /etc.
.
It is done by means of a patch to make use of the debhelper-provided
$HOME visible by dh_auto_*.
.
The relevant code is at:
https://sources.debian.org/src/imagemagick/8:6.9.11.60+dfsg-1.3/magick/configure.c/#L860
Author: Dennis Filder
Last-Updated: 2021-07-15
--- a/generate.sh
+++ b/generate.sh
@@ -33,6 +33,29 @@
generate XML '1.0' xml10
generate XML '1.1' xml11
+# this relies on debhelper providing a $HOME directory for us to write
+# to
+polfile="/etc/$(convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')"/policy.xml
+if [ ! -f "$polfile" ]; then
+echo "Error: generate.sh: Policy file not found: $polfile" >&2;
+exit 1
+fi
+if [ -e "$HOME"/.magick ]; then
+rm -Rf "$HOME"/.magick
+fi;
+if [ -e "$HOME"/.magick ]; then
+echo "Error: generate.sh: Failed to remove $HOME/.magick -- remove manually and try again." >&2;
+exit 1
+fi
+mkdir "$HOME"/.magick
+if [ ! -d "$HOME"/.magick ]; then
+echo "Error: generate.sh: Failed to create $HOME/.magick -- investigate, fix manually, then try again." >&2;
+exit 1;
+fi
+
+sed -e '//s@"none"@"read|write"@' "$polfile" \
+> "$HOME"/.magick/policy.xml
+
/bin/ls Icons/*.svg | sed 's/-v\.svg//' | xargs -I{} convert -background none {}-v.svg {}.png
/bin/ls Icons/*.svg | sed 's/-v\.svg//' | xargs -I{} convert -background none {}-v.svg {}.gif
/bin/ls Icons/*.svg | sed 's/-v\.svg//' | xargs -I{} convert -background none {}-v.svg {}-v.eps
Bug#783889: sudo-ldap, libsss-sudo: need to coordinate modifications to /etc/nsswitch.conf
To summarize from discussions on sudo@packages.d.o and elsewhere
(e.g. #990855):
* Sudo has IMO no business of putting an entry into /etc/nsswitch.conf
since NSS is a mechanism for order-invariant entity resolution
whereas sudo uses its plugins for combined entity resolution and
policy rule evaluation which is not order-invariant. Also, despite
the manpage for nsswitch.conf wrongly claiming the opposite, as far
as I can tell sudo never uses NSS facilities for its plugins, but
instead implements its own in plugins/sudoers/sudo_nss.{c,h} the
purpose of which doesn't really make sense to me.
* Changes to that entry are not preservable across removals/purges
which violates DPM (as stated).
* Sudo's approach to plugins is unlike anything I've seen. The APIs
move very fast, and there exist several plugin types which make it
somewhat difficult to reason about how to best distribute that
gracefully across several packages. For example, sudoers_ldap.so
does not just include LDAP-related functions, but also duplicates
everything from sudoers.so. This architecture stems probably from
the days before the plugin API was introduced and you had to build
several versions of sudo with different features linked in. Also,
the function pointers are exported in structs which makes rather
hard to tell what each plugin is for which is not helped by the fact
that the type of the plugin is only encoded as an int in the struct.
The goal(s) for bookworm could be:
* Copy the entry from /etc/nsswitch.conf to
e.g. /etc/sudo/plugins.conf and patch sudo to use that and simply
ignore/warn about the other thereafter. The points below could be
left for trixie, but this one is a must since any error here has the
potential to break libc's NSS for everyone. No longer having to
worry about that will make life much easier.
The sssd maintainers will have to cooperate on this.
* To keep plugins from interfering with each other's config
files/entries, try to split the packages sudo and sudo-ldap into
sudo, sudo-common and sudo-plugin-ldap. sudo-common must ship the
update-sudo-plugins script that regenerates /etc/sudo/plugins.conf
from whatever implements change-preserving configuration of the
plugins (note: plugin order matters, so that has to be preserved,
too; sudo also implements a subset of the nsswitch.conf
short-circuting behaviour which also needs to be covered; some
plugins are in mutual conflict, e.g. the SSSD and LDAP plugins; no
idea how to best express/default that (maybe some preference
score)).
Oddities in the architecture of the plugin APIs might make this very
difficult or even impossible.
Also, to actually load a plugin, it has to be configured explicitly
in /etc/sudo.conf which the user has to do by hand.
/etc/sudo/plugins.conf only configures which facilities will
actually be used and in what order. (This point somewhat calls into
question the sensibility of trying to preserve changes for
/etc/sudo/plugins.conf: If the user after installing/removing a
plugin has to touch /etc/sudo.conf unconditionally anyway, why can't
we expect him to also touch /etc/sudo/plugins.conf?)
* Plugin packages then have to call update-sudo-plugins upon
installation/removal. During their first installation they should
infer their configuration state from what's in
/etc/sudo/plugins.conf already. sudo-common probably needs to
provide another helper script for that.
* A problem is that under sudo-ldap the LDAP plugin was always loaded
because it had the same name as the non-LDAP plugin in the sudo
package. Setups which don't load it explicitly in /etc/sudo.conf
(i.e. essentially all of them) could thus break during the migration
since the LDAP plugin will be named sudoers_ldap.so afterwards.
IIRC the only non-interactive way to prevent that is to patch sudo
to first try loading sudoers_ldap.so before sudoers.so if it is
installed and issue a warning about this fallback behaviour being
deprecated.
Additional matters:
* The Python plugin should probably allow referencing the exact Python
version from the beginning, e.g. sudo-plugin-python3.9. But since
it's considered a beta feature this is not urgent.
Bug#990855: sudo: enable python plugin support
On Tue, Jul 13, 2021 at 05:09:25PM +0200, Marc Haber wrote:
> On Tue, Jul 13, 2021 at 09:10:32AM +0200, Michael Prokop wrote:
> > So maybe it makes sense to provide a sudo-python package, similar to
> > what's available with sudo-ldap already?
>
> I THINK that we were planning to get rid of sudo-ldap anyway
> post-release (see #783889), but I don't remember the state of
> discussion.
It fizzled out. To recap:
* One problem is that sudo puts an entry into /etc/nsswitch.conf that
has no business of being there in the first place since NSS is a
mechanism for order-invariant entity resolving whereas sudo uses its
plugins for combined entity resolution and policy rule evaluation
which is not order-invariant. Also, despite the manpage for
nsswitch.conf wrongly claiming the opposite, as far as I can tell
sudo never uses NSS facilities for its plugins, but instead
implements its own in plugins/sudoers/sudo_nss.{c,h} which doesn't
make sense to me.
* Changes to that entry are not preservable across removals/purges
which violates DPM.
* sudo-ldap should be transformed into a package that only ships the
plugin.
* Sudo's approach to plugins is unlike anything I've seen.
The goal(s) for bookworm should/could be:
* Copy the entry from /etc/nsswitch.conf to
e.g. /etc/sudo/plugins.conf and patch sudo to use that and simply
ignore/warn about the other thereafter. The points below could be
left for trixie, but this one is a must since any error here has the
potential to break libc's NSS for everyone. No longer having to
worry about that will make life much easier.
* Try to split the packages sudo and sudo-ldap into sudo, sudo-common
and sudo-plugin-ldap. sudo-common must ship the update-sudo-plugins
script that regenerates /etc/sudo/plugins.conf from whatever
implements change-preserving configuration of the plugins (note:
plugin order matters, so that has to be preserved, too; sudo also
implements a subset of the nsswitch.conf short-circuting behaviour
which also needs to be covered; some plugins are in mutual conflict,
e.g. the SSSD and LDAP plugins; no idea how to best express/default
that (maybe some preference score)).
Oddities in the architecture of the plugin APIs might make this very
difficult or even impossible.
Also, to load a plugin, it has to be configured explicitly in
/etc/sudo.conf which the user has to do by hand.
/etc/sudo/plugins.conf only configures which facilities will
actually be used and in what order.
* Plugin packages then have to call update-sudo-plugins upon
installation/removal. During their first installation they should
infer their configuration state from what's in
/etc/sudo/plugins.conf already. sudo-common probably needs to
provide another helper script for that.
* A problem is that under sudo-ldap the LDAP plugin was always loaded
because it had the same name as the non-LDAP plugin in the sudo
package. Setups which don't have it explicitly enabled in
/etc/sudo.conf (i.e. essentially all of them) could thus break
during the migration since the LDAP plugin will be named to
sudoers_ldap.so afterwards. IIRC the only way to prevent that is to
patch sudo to first try loading sudoers_ldap.so before sudoers.so if
it is installed and issue a warning about this fallback behaviour
being deprecated.
Additional matters:
* The Python plugin should probably allow referencing the exact Python
version from the beginning, e.g. sudo-plugin-python3.9. But since
it's considered a beta feature this is not urgent.
Regards.
Bug#981815: Please explain
On Thu, Jul 01, 2021 at 07:59:51AM +0200, Marc Haber wrote: > I cringe at the necessity of using strace to obtain vital debugging > information. Would it be worth to make an upstream withlist request for > debugging output of this string so that stracing sudo unnecessary? It is > quite hard to strace an suid binary. Intuiting how shells evaluate their syntax and turn the result into parameters for execve calls is fundamental Unix knowledge, and the system must expect a user to grok that. Also, it's not even difficult, except for the odd beginner's mistake. Maybe the manpage could emphasize a tick more that no shell expansion is done on sudoers rules (despite some wildcard expansion which may lead to confusion). But other than that I don't think anything should be done here. People just have to either read the error messages, study the docs harder/closer or suggest how they could be improved/say what confuses them. Regards, Dennis.
Bug#981815: Please explain
X-Debbugs-CC: serfyo...@yandex.ru
On Wed, Jun 30, 2021 at 05:27:45PM +0300, Сергей Фёдоров wrote:
> Sorry for the late response - I just went to the mail and did not
> expect a letter from you.
>
> I wanted to use sudo to delete the list of root owner files whose
> names are placed in the file.
Your first example is probably wrong because using '<' in sudoers
files is a syntax error, and the shell would interpret it anyway, so
sudo would never see it.
In your second and third examples the same rule applies. Also, your
executed command differs from that in sudoers ('-0t' vs. '-t'), so
sudo asks for a password.
Remember: sudo is not a shell, and it does no processing of shell meta
characters. To work with a defined sudoers entry, the beginning of
the command (after evaluation of meta characters by the shell) must
match /exactly/ what is specified in sudoers (absolute paths,
parameter order etc.). Additional parameters can be added, but what
is specified in sudoers must not be omitted nor rearranged.
I find the easiest way to inspect what the ultimately executed command
will look like after meta character evaluation is by processing the
output of strace, e.g. like so:
printf '/dev/null\n/dev/zero\n' > /tmp/files
strace -o '|grep execve' -e trace=execve \
-s 4096 -f sh -c "/usr/bin/xargs \
-a /tmp/files -n 1 -d '\n' /usr/bin/stat"
Notice that strace does some escaping of special characters like '\n'
in its output itself, so you have to be mindful of that.
Regards,
Dennis.
Bug#990244: tests/streams: Failing test on pipe stdout file descriptor
Control: tags -1 moreinfo X-Debbugs-CC: Ariel D'Alessandro It could be that OBS opens the pipe as a privileged process, forks, then drops privileges afterwards such that the child process is precluded from reopening the inode that backs the file descriptor clisp operates on. You'd somehow have to find a way to invoke "stat -L /proc//fd/" on the failing file quickly enough to find out if this is the case. Inserting sleeps into the test could buy you more time. Alternatively (and assuming you use ocs) tools like socat/ptywrap could maybe be used via $OSC_SU_WRAPPER to hook the child process onto a pty (which should also be created after dropping the privileges). Or you could try to run the build as root (osc build --userootforbuild) and see if the error persists. Regards, Dennis
Bug#990076: acngfs: incomplete files; download retries in a loop
Package: apt-cacher-ng Version: 3.7.2-1 Severity: normal I'm having a real hard time getting acngfs to work reliably, and it starts straining my good will quite a bit. The impression that I'm getting is that it finishes system calls before the underlying download has finished which manifests as hashes being calculated incorrectly in aptitude/apt-get/apt which makes acngfs useless. Other behaviour I'm observing: apt-cacher-ng constantly terminates not-yet-finished downloads only to retry them anew quickly after which results in a lot of wasted bandwidth and incomplete files under /var/cache/apt-cacher-ng/debrep which I then have to delete manually because for some reason apt-cacher-ng does not detect the corruption itself. I have observed the behaviour only when accessing files through acngfs. Downloading a file with wget using apt-cacher-ng as the proxy works fine. I run acngfs like this: /usr/lib/apt-cacher-ng/acngfs http://deb.debian.org/debian \ /var/local/acngfs_debian proxy=127.0.0.1:3142 \ cachedir=/var/cache/apt-cacher-ng/debrep \ -o allow_root,auto_unmount,intr,intr_signal=10 -f -d I took squid out of the picture, so I don't think it has anything to do with this. That's all I have. I wish I could offer more details, but the software is nigh undebuggable and its architecture completely incomprehensible to me. -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: default Versions of packages apt-cacher-ng depends on: ii adduser 3.118 ii debconf [debconf-2.0]1.5.75 ii dpkg 1.20.9 ii libbz2-1.0 1.0.8-4 ii libc62.31-12 ii libevent-2.1-7 2.1.12-stable-1 ii libevent-pthreads-2.1-7 2.1.12-stable-1 ii libgcc-s110.2.1-6 ii liblzma5 5.2.5-2 ii libssl1.11.1.1k-1 ii libstdc++6 10.2.1-6 ii libsystemd0 247.3-5 ii libwrap0 7.6.q-31 ii lsb-base 11.1.0 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages apt-cacher-ng recommends: ii ca-certificates 20210119 Versions of packages apt-cacher-ng suggests: pn avahi-daemon ii doc-base 0.11.1 ii libfuse2 2.9.9-5 -- Configuration Files: /etc/apt-cacher-ng/acng.conf changed [not included] /etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: '/etc/apt-cacher-ng/security.conf' -- debconf information excluded
Bug#977696: pulseaudio: Pulseaudio 13.0.5 fails on Bullseye (permissions, cookie)
Control: tags -1 moreinfo X-Debbugs-CC: Andrew Savchenko , Dennis Filder >From the log you posted I can see that you try to run pactl as root, correct? You can't do that because pulseaudio refuses to start as root on grounds of security. In general pulseaudio was designed to by default accept connections from the user who started it. If you wish to connect to an already running pulseaudio process from the login session of a different user, that second user needs read access to a pulseaudio socket (either the default one under /run/user//pulse/native or a new one created by loading the module module-native-protocol-unix with appropriate parameters, see [0]) and all intermediate directories plus the path to its location. It will also need a copy of the cookie file. Usually the invocation will look similar to this (this assumes pulseaudio is already running as a non-root user): PULSE_SERVER=unix:/run/user/$(ps --no-headers -C pulseaudio un|column -t|cut -d' ' -f1)/pulse/native \ PULSE_COOKIE=$(getent passwd $(ps --no-headers -C pulseaudio un|column -t|cut -d' ' -f1)|cut -d: -f 6)/.config/pulse/cookie \ pactl info For a deeper understanding you will have to study the documentation. Unless you provide more information/reasons for why this should be considered a bug I will close this bugreport one week from now. Regards, Dennis. 0: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-native-protocol-unixtcp
Bug#989959: unbound: Corrupt/empty trust anchor file is not healed upon start
Package: unbound Version: 1.13.1-1 Severity: normal Tags: patch I ran out of space on /var and unbound still tried to update the root trust anchor file which ended up empty. Then later after reboot the package-helper failed to detect and recover from that, and unbound.service failed to start. With the attached patch (which adds a rudimentary sanity check) and freshly freed disk space unbound started normally. However, a better solution might be to test more carefully for sufficient disk space when making changes to the file or using 2 oversized files in rotation and never truncating them. Regards, Dennis P.S.: I also noticed that unbound.service under [Service] defines no StateDirectory=/var/lib/unbound to ensure that it is mounted on start. Description: Update the root trust anchor file if it fails a simple sanity check This uses sed instead of grep -v to print all non-comment lines as the latter adds a newline to its output, and we want to interpret the absence of a newline as indicator of corruption. . The regex could be written more specific, e.g. mention "DNSKEY" etc. Author: Dennis Filder --- package-helper-orig +++ package-helper @@ -78,11 +78,14 @@ if $ROOT_TRUST_ANCHOR_UPDATE; then if [ -n "$ROOT_TRUST_ANCHOR_FILE" ]; then if [ -r "$DNS_ROOT_KEY_FILE" ]; then -if [ ! -e "$ROOT_TRUST_ANCHOR_FILE" -o "$DNS_ROOT_KEY_FILE" -nt "$ROOT_TRUST_ANCHOR_FILE" ]; then +if [ ! -e "$ROOT_TRUST_ANCHOR_FILE" -o "$DNS_ROOT_KEY_FILE" -nt "$ROOT_TRUST_ANCHOR_FILE" \ + -o "$(sed -n '/^[[:space:]]*[^;]/p' < "$ROOT_TRUST_ANCHOR_FILE" | tr -cd '\n' |wc -c)" -eq 0 ]; then if [ ! -e "$ROOT_TRUST_ANCHOR_FILE" ]; then echo "$ROOT_TRUST_ANCHOR_FILE does not exist, copying from $DNS_ROOT_KEY_FILE" elif [ "$DNS_ROOT_KEY_FILE" -nt "$ROOT_TRUST_ANCHOR_FILE" ]; then echo "Overwriting older file $ROOT_TRUST_ANCHOR_FILE with newer file $DNS_ROOT_KEY_FILE" +elif [ "$(sed -n '/^[[:space:]]*[^;]/p' < "$ROOT_TRUST_ANCHOR_FILE" | tr -cd '\n' |wc -c)" -eq 0 ]; then +echo "Overwriting corrupt/incomplete file $ROOT_TRUST_ANCHOR_FILE with file $DNS_ROOT_KEY_FILE" fi install -m 0644 -o unbound -g unbound "$DNS_ROOT_KEY_FILE" "$ROOT_TRUST_ANCHOR_FILE" fi
