Bug#1070983: supertuxkart: symbol lookup error: undefined symbol
Package: supertuxkart Version: 1.4+dfsg-4 Severity: grave Justification: renders package unusable X-Debbugs-Cc: b...@zockertown.de Dear Maintainer, Trying to start supertuxkart from console brings this as answer, after last full-upgrade supertuxkart: symbol lookup error: /lib/x86_64-linux-gnu/libshaderc.so.1: undefined symbol: _ZTVN8spvtools5utils5TimerE This is my first bugreort, hope it is ok. Tanks and have a nice day Bernd, aka bed -- System Information: Debian Release: trixie/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages supertuxkart depends on: ii libangelscript2.35.1t64 2.35.1+ds-3.1 ii libbluetooth35.71-1 ii libc62.38-10 ii libcurl3t64-gnutls 8.7.1-5 ii libfreetype6 2.13.2+dfsg-1+b4 ii libgcc-s114-20240330-1 ii libharfbuzz0b8.3.0-2+b1 ii libjpeg62-turbo 1:2.1.5-3 ii libmbedcrypto7t642.28.8-1 ii libmcpp0 2.7.2-5.1 ii libopenal1 1:1.23.1-4+b1 ii libpng16-16t64 1.6.43-5 ii libsdl2-2.0-02.30.2+dfsg-1 ii libshaderc1 2023.2-1 ii libsqlite3-0 3.45.3-1 ii libsquish0 1.15-3+b1 ii libstdc++6 14-20240330-1 ii libvorbisfile3 1.3.7-2 ii supertuxkart-data1.4+dfsg-4 ii zlib1g 1:1.3.dfsg-3.1 supertuxkart recommends no packages. supertuxkart suggests no packages. -- no debconf information
Bug#1012752: unattended-upgrades: regularly stuck in loop, eating CPU
Hi, as this is regularly leaving systems unresponsible or at least in a state where its basically making a hot air dryer out of servers, I'm raising the severity. Its not an option to have a datacenter running amok. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1069879: ITP:cashbox -- memorise cost and calculate price of articles
Package: wnpp Version: N/A; reported 2024-04-26 Severity: wishlist For my librem5 smartphone, but also for any debian based system, I have written cashbox with python3 and gtk4. I intent to package cashbox, because I think it would be good for debian to have more apps for debian/mobian based smartphones. Description: cashbox - memorise cost and calculate price of articles cashbox memorises the cost of articles and calculates the total price and change. It is intended for small clubs on a celebration, where members are not experienced in memorizing prices and doing mental arithmetic. License: GPL-3.0+ It is easy to use use on small smartphone displays or on touchscreens. See: https://salsa.debian.org/debian/cashbox I have already communicated this project to the puri.sm forum: https://forums.puri.sm/t/new-app-cashbox/23349/1 and to the matrix gnome python forum: https://matrix.to/#/!pJkHfTcdAUntpUNxJf:matrix.org/$171402440417331vHQZi:matrix.org?via=gnome.org=matrix.org=fedora.im
Bug#1068823: Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device"
On Thu, 2024-04-11 at 16:46 +, mYnDstrEAm wrote:
>
> For example, I think a good approach to this would be something like
> this (if the user is low on root partition disk space):
> 1. asking for *at least* 400MB to be available
> 2. if a parameter for stepwise is set or it detected low free disk
> space:
> 3. downloading the first 300 MB or so of packages
> 4. installing these
> 5. deleting the cached packages from /var/cache/apt/archives/
> 6. downloading the next batch up to the storage limit set at start
> 7. and so on (without exiting in-between)
>
quick and dirty and not tested:
while apt -s upgrade | grep '^Inst' | head -1 | awk '{print $2}' |
xargs apt install; do apt clean; done
Use head -10 or whatever fits for more/less packages.
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1068580: collected: FTBFS on arm{el,hf}: configure: error: "Some plugins are missing dependencies - see the summary above for details"
Hi Sebastian, https://buildd.debian.org/status/package.php?p=grpc its just not built on armel yet and the old version is most likely not installable anymore due to the time_t change. Bernd On Sun, 2024-04-07 at 14:48 +0200, Sebastian Ramacher wrote: > Source: collectd > Version: 5.12.0-17.1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in > the past) > X-Debbugs-Cc: sramac...@debian.org > > https://buildd.debian.org/status/fetch.php?pkg=collectd=armhf=5.12.0-17.1=1712493429=0 > > > Configuration: > Build: > Platform . . . . . . Linux > Compiler vendor . . . gnu > CC . . . . . . . . . arm-linux-gnueabihf-gcc > CFLAGS . . . . . . . -Wall -Werror -g -O2 -Werror=implicit- > function-declaration -ffile-prefix-map=/<>=. -fstack- > protector-strong -fstack-clash-protection -Wformat -Werror=format- > security -Wall -Wno-error=deprecated-declarations -Wno-error=address- > of-packed-member -Wno-stringop-truncation -Wno-cpp -Wno-error=format- > truncation > CXXFLAGS . . . . . . -Wall -Werror -g -O2 -ffile-prefix- > map=/<>=. -fstack-protector-strong -fstack-clash- > protection -Wformat -Werror=format-security -Wall -Wno- > error=deprecated-declarations > CPP . . . . . . . . . arm-linux-gnueabihf-gcc -E > CPPFLAGS . . . . . . -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 - > I/<>/debian/include -UCONFIGFILE - > DCONFIGFILE='"/etc/collectd/collectd.conf"' > GRPC_CPP_PLUGIN . . . /usr/bin/grpc_cpp_plugin > LD . . . . . . . . . /usr/bin/ld > LDFLAGS . . . . . . . -Wl,-z,relro -Wl,-z,now > PROTOC . . . . . . . /usr/bin/protoc > YACC . . . . . . . . bison -y > YFLAGS . . . . . . . > > Libraries: > intel mic . . . . . . no (MicAccessApi not found) > libaquaero5 . . . . . no (libaquaero5.h not found) > libatasmart . . . . . yes > libcurl . . . . . . . yes > libdbi . . . . . . . yes > libdpdk . . . . . . . no (rte_config.h not found) > libesmtp . . . . . . yes > libganglia . . . . . no (gm_protocol.h not found) > libgcrypt . . . . . . yes > libgps . . . . . . . yes > libgrpc++ . . . . . . no ( not found) > libhiredis . . . . . yes > libi2c-dev . . . . . yes > libiokit . . . . . . no > libiptc . . . . . . . yes > libjansson . . . . . yes > libjevents . . . . . no (jevents.h not found) > libjvm . . . . . . . yes > libkstat . . . . . . no (Solaris only) > libkvm . . . . . . . no > libldap . . . . . . . yes > liblua . . . . . . . yes > libmemcached . . . . yes > libmicrohttpd . . . . yes > libmnl . . . . . . . yes > libmodbus . . . . . . yes > libmongoc . . . . . . yes > libmosquitto . . . . yes > libmysql . . . . . . yes > libnetapp . . . . . . no (netapp_api.h not found) > libnetsnmp . . . . . yes > libnetsnmpagent . . . yes > libnotify . . . . . . yes > libnvidia-ml . . . . no > libopenipmi . . . . . yes > liboping . . . . . . yes > libowcapi . . . . . . yes > libpcap . . . . . . . yes > libperfstat . . . . . no (AIX only) > libperl . . . . . . . yes (version 5.38.2) > libpmwapi . . . . . . no (pmw_api.h not found) > libpq . . . . . . . . yes > libpqos . . . . . . . no (pqos.h not found) > libprotobuf . . . . . yes > libprotobuf-c . . . . yes > libpython . . . . . . yes > libqpid-proton . . . yes > librabbitmq . . . . . yes > libriemann-client . . yes > librdkafka . . . . . yes > librouteros . . . . . no (routeros_api.h not found) > librrd . . . . . . . yes > libsensors . . . . . yes > libsigrok . . . . . no (pkg-config could not find libsigrok) > libssl . . . . . . . yes > libslurm . . . . . . no (pkg-config doesn't know libslurm) > libstatgrab . . . . . no > libtokyotyrant . . . no (tcrdb.h not found) > libudev . . . . . . . yes > libupsclient . . . . yes > libvarnish . . . . . no (pkg-config doesn't know varnishapi) > libvirt . . . . . . . yes > libxenctrl . . . . . yes > libxml2 . . . . . . . yes > libxmms . . . . . . . no > libyajl . . . . . . . yes > oracle . . . . . . . no (ORACLE_HOME is not set) > protobuf-c . . . . . yes > protoc 3 . . . . . . yes > > Features: > daemon mode . . . . . yes > debug . . . . . . . . no > > Bindings: > perl . . . . . . . . yes (INSTALLDIRS=vendor INSTALL_BASE=) > > Modules: > aggregation . . . . . yes >
Bug#1063077: syslog-ng: identified for time_t transition but no ABI in shlibs
Hi Attila, On Fri, 2024-04-05 at 09:47 +0100, Attila Szalay wrote: > Based on https://wiki.debian.org/NonMaintainerUpload, the binNMU > should > be careful I think you are confusing binNMUs and NMUs. See https://wiki.debian.org/binNMU They are handled more or less automatic as soon as a rebuild is needed for a transition. You might want to read the bug report again, it basically says that no NMU will be uploaded, but you package will break if you don't apply the attached patch. And the binNMU that will most likely break it will happen. The way how the time_t change happens was discussed for a *long* time, you are a bit late with complaints. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1067376: [nore...@release.debian.org: gforth is marked for autoremoval from testing]
I had a look at building gforth 0.7.3 from within Debian sid and dpkg- buildpackage. What's happening here is that lt_dlopen() can't find the just generated files; the generated libraries are in the build directory (a subdirectory of it) and fine, they are just in a place where the loader doesn't look at. The development snapshots (which will become Gforth 1.0 soon) have a solution for that that isn't too easy to backport, and doesn't work for cross-compiling (the cross compiled libraries won't load into the host's Gforth), in which case these errors are just ignored. Therefore I recommend to ignore the error, see attached libcc-err-ignore.patch (to be applied last). Furthermore, I have some issues building Gforth 0.7.3 when the current development Gforth is already installed. That patch (gforth-ditc-for- kernel.patch) could become useful in future. When you already are at it: What I would strongly recommend to revert the removal of the documentation: It's GFDL with no invariant sections, so it is compatible with the Debian rules since 2006 (which was even before we released Gforth 0.7). Gforth without documentation isn't very useful, we recommend Gforth users not to use Debian's package for any other purpose than to compile the source code (from git; the tarball doesn't need it). But for that purpose it should stay there. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* https://net2o.de/ Description: Ignore failure on open-lib with libcc build stuff Author: Bernd Paysan Bug-Debian: https://bugs.debian.org/1067376 Last-Update: 2024-03-30 --- gforth-0.7.3+dfsg.orig/Makefile.in +++ gforth-0.7.3+dfsg/Makefile.in @@ -652,7 +652,7 @@ uninstall: FORCE build-libcc-named: $(LIBCC_BUILD_SRC) $(FORTH_GEN) $(GEN) FORCE $(RMTREE) lib/gforth/$(VERSION)/libcc-named/ - for i in $(LIBCC_BUILD_SRC); do ./gforth -e "s\" `pwd`/lib/gforth/$(VERSION)/libcc-named/\" libcc-named-dir-v 2! libcc-path clear-path libcc-named-dir libcc-path also-path :noname 2drop s\" $(libccdir)\" ; is replace-rpath" $(srcdir)/$$i -e bye; done + -for i in $(LIBCC_BUILD_SRC); do ./gforth -e "s\" `pwd`/lib/gforth/$(VERSION)/libcc-named/\" libcc-named-dir-v 2! libcc-path clear-path libcc-named-dir libcc-path also-path :noname 2drop s\" $(libccdir)\" ; is replace-rpath" $(srcdir)/$$i -e bye; done check: gforths gforth.fi $(MAKE) checkone check-nofast ENGINE="./gforth --no-dynamic" >/dev/null 2>&1 Description: Build gforth-ditc first before building the kernel, use gforth-ditc for that Author: Bernd Paysan Bug-Debian: https://bugs.debian.org/1067376 Last-Update: 2024-03-30 --- gforth-0.7.3+dfsg.orig/Makefile.in +++ gforth-0.7.3+dfsg/Makefile.in @@ -449,7 +449,7 @@ FORTH_GEN = $(FORTH_GEN0) @KERNEL@ gfor FORTH_GEN1 = $(FORTH_GEN0) @kernel_fi@ build-ec #kernel dependencies -KERN_DEPS = $(KERN_SRC) kernel/version.fs machpc.fs $(FORTH_GEN0) compat/strcomp.fs +KERN_DEPS = $(KERN_SRC) kernel/version.fs machpc.fs $(FORTH_GEN0) gforth-ditc$(EC)$(EXE) compat/strcomp.fs #distributed documentation DOCDIST = doc/gforth.info doc/gforth.info-* doc/gforth.ps \ --- gforth-0.7.3+dfsg.orig/preforth.in +++ gforth-0.7.3+dfsg/preforth.in @@ -17,7 +17,7 @@ #You should have received a copy of the GNU General Public License #along with this program. If not, see http://www.gnu.org/licenses/. -test -z "$ENGINE" && ENGINE=./gforth +test -z "$ENGINE" && ENGINE=./gforth-ditc test -f "@srcdir@/@kernel_fi@" && KERNEL="@srcdir@/@kernel_fi@" test -f "@kernel_fi@" && KERNEL="@kernel_fi@" if test -f $ENGINE -a -f $KERNEL; then signature.asc Description: This is a digitally signed message part.
Bug#1031802: Move fuse_new_31 to FUSE_3.13?
Hi Andrea, thanks for raising my attention and thanks for the detailed analysis. Would it help to move that symbol to FUSE_3.13 in the version script (for example in libfuse-3.17?)? Thanks, Bernd
Bug#1062065: ceph: NMU diff for 64-bit time_t transition
Hi Steve, I would not bother too much, actually I'm winding why ceph was not yet removed from the 32bit architectures. It's just not supported by upstream and although it builds, I would not trust it to work correctly. Bernd 31.01.2024 10:03:28 Steve Langasek : > Source: ceph > Version: 16.2.11+ds-5 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > ceph as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > 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. Therefore I have prepared a 0-day NMU for ceph > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. > > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system)
Bug#1063679: O: unionfs-fuse -- Fuse implementation of unionfs
Package: wnpp Severity: normal Dear Debian maintainers, unfortunately I don't have time anymore to maintain unionfs-fuse. There hadn't been any updates from me for the last years and I'm afraid it does not get any better. To my excuse I actually tried to upload a new version some time ago (1 or 2 years ago now), posted it to to debian mentors - no progress and I then didn't have time again either - the updated package was auto-removed from mentors.debian.net/packages/. Thanks, Bernd
Bug#1057146: collectd: drop build-dependency on libdpdk-dev on i386
On Thu, 2023-12-07 at 12:58 +, Luca Boccassi wrote: > On Thu, 7 Dec 2023 at 12:49, Luca Boccassi wrote: > > > > On Thu, 7 Dec 2023 at 12:34, Bernd Zeimetz wrote: > > > > > > On 2023-12-07 13:22, Luca Boccassi wrote: > > > > > > > That's a pre-existing issue that happens before any of my > > > > changes as > > > > you can see in the previous Salsa commit, which was made by > > > > somebody > > > > else: > > > > > > > > https://salsa.debian.org/debian/pkg-collectd/-/jobs/4917853 > > > > > > yes. It still fails to build due to that, so your upload is > > > broken. > > > Again, please either remove or fix it. > > > > Actually, it fails to build even before that, at your last commit: > > > > https://salsa.debian.org/bluca/pkg-collectd/-/commit/b8563518a02bc841fb93c778e553f09e8f6ac659 > > I've filed #1057712 for the FTBFS, cancelled the NMU and unblocked > the > transition. It's just a Recommends: anyway, so it will be solved > whenever it will be solved. > I've just uploaded collectd with the java plugin disabled on i386, libjvm has a missing symbol there and fails to link because of that. So your transition should be happy. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1057146: collectd: drop build-dependency on libdpdk-dev on i386
On 2023-12-07 13:22, Luca Boccassi wrote: That's a pre-existing issue that happens before any of my changes as you can see in the previous Salsa commit, which was made by somebody else: https://salsa.debian.org/debian/pkg-collectd/-/jobs/4917853 yes. It still fails to build due to that, so your upload is broken. Again, please either remove or fix it. Thanks, Bernd
Bug#1057146: collectd: drop build-dependency on libdpdk-dev on i386
Hi Luca, I have now uploaded the 5.12.0-14.1 NMU to DELAYED/3, let me know if there are any objections and I'll cancel it. I will push the changelog commit to Salsa if it gets through. before uploading things you should check if it actually builds at all: https://salsa.debian.org/debian/pkg-collectd/-/jobs/4999730 and it does not on i386. Please fix your upload or remove it and wait until somebody has the time to investigate. Thanks, Bernd
Bug#1056205: open-vm-tools containerInfo plugin is being installed in incorrect directory
Hi John! > VMware's internal builds and testing of upcoming versions of open-vm- > tools is based on the > debian packaging source seen at > > > https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/ That is nice to hear! Feel free to create an account on salsa and send merge requests, they will go trough the CI automatically and make your (no need to type long bug emails)_and my work easier. How important is this issue for you? Does it need to be fixed in the stable releases? I've uploaded the fixed version to unstable, all backports will follow when it hits testing. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1054666: open-vm-tools: CVE-2023-34059 CVE-2023-34058
On Mon, 2023-10-30 at 22:50 +0100, Moritz Muehlenhoff wrote: > On Mon, Oct 30, 2023 at 07:09:53PM +0100, Bernd Zeimetz wrote: > > Hi Moritz, > > > > as usual, stable/oldstable updates prepared, diffs are attached to > > this > > mail as salsa seems to have some issues right now. > > > > https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/ - > > bookworm/bullseye branches are actually there. > > > > Please let me know if/when I can upload. > > Thanks, these look fine, please upload to security-master. > Both uploaded! Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1054666: open-vm-tools: CVE-2023-34059 CVE-2023-34058
Hi Moritz,
as usual, stable/oldstable updates prepared, diffs are attached to this
mail as salsa seems to have some issues right now.
https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/ -
bookworm/bullseye branches are actually there.
Please let me know if/when I can upload.
Thanks,
Bernd
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
diff --git a/debian/changelog b/debian/changelog
index a68092c65..b550b2ff4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+open-vm-tools (2:12.2.0-1+deb12u2) bookworm-security; urgency=medium
+
+ * Closes: #1054666
+ * [81326c8] Fixing CVE-2023-34059.
+This fixes a file descriptor hijack vulnerability in the vmware-user-suid-wrapper
+command. A malicious actor with non-root privileges might have been able to hijack the
+/dev/uinput file descriptor allowing them to simulate user inputs.
+ * [95acc49] Fixing CVE-2023-34058.
+This fixes a SAML Token Signature Bypass vulnerability. A malicious actor
+that has been granted Guest Operation Privileges in a target virtual
+machine might have been able to elevate their privileges if that target
+virtual machine has been assigned a more privileged Guest Alias.
+
+ -- Bernd Zeimetz Mon, 30 Oct 2023 17:59:25 +0100
+
open-vm-tools (2:12.2.0-1+deb12u1) bookworm-security; urgency=medium
* [3812674] Fixing CVE-2023-20867, CVE-2023-20900
diff --git a/debian/patches/CVE-2023-34058.patch b/debian/patches/CVE-2023-34058.patch
new file mode 100644
index 0..79cea095c
--- /dev/null
+++ b/debian/patches/CVE-2023-34058.patch
@@ -0,0 +1,234 @@
+From 6822b5a84f8cfa60d46479d6b8f1c63eb85eac87 Mon Sep 17 00:00:00 2001
+From: John Wolfe
+Date: Wed, 18 Oct 2023 09:04:07 -0700
+Subject: [PATCH] Address CVE-2023-34058
+
+VGAuth: don't accept tokens with unrelated certs.
+
+---
+ open-vm-tools/vgauth/common/certverify.c| 145
+ open-vm-tools/vgauth/common/certverify.h| 4 +
+ open-vm-tools/vgauth/common/prefs.h | 2 +
+ open-vm-tools/vgauth/serviceImpl/saml-xmlsec1.c | 14 +++
+ 4 files changed, 165 insertions(+)
+
+Index: pkg-open-vm-tools/open-vm-tools/vgauth/common/certverify.c
+===
+--- pkg-open-vm-tools.orig/open-vm-tools/vgauth/common/certverify.c
pkg-open-vm-tools/open-vm-tools/vgauth/common/certverify.c
+@@ -914,3 +914,148 @@ done:
+
+return err;
+ }
++
++
++/*
++ * Finds a cert with a subject (if checkSubj is set) or issuer (if
++ * checkSUbj is unset), matching 'val' in the list
++ * of certs. Returns a match or NULL.
++ */
++
++static X509 *
++FindCert(GList *cList,
++ X509_NAME *val,
++ int checkSubj)
++{
++ GList *l;
++ X509 *c;
++ X509_NAME *v;
++
++ l = cList;
++ while (l != NULL) {
++ c = (X509 *) l->data;
++ if (checkSubj) {
++ v = X509_get_subject_name(c);
++ } else {
++ v = X509_get_issuer_name(c);
++ }
++ if (X509_NAME_cmp(val, v) == 0) {
++ return c;
++ }
++ l = l->next;
++ }
++ return NULL;
++}
++
++
++/*
++ **
++ * CertVerify_CheckForUnrelatedCerts -- */ /**
++ *
++ * Looks over a list of certs. If it finds that they are not all
++ * part of the same chain, returns failure.
++ *
++ * @param[in] numCerts The number of certs in the chain.
++ * @param[in] pemCerts The chain of certificates to verify.
++ *
++ * @return VGAUTH_E_OK on success, VGAUTH_E_FAIL if unrelated certs are found.
++ *
++ **
++ */
++
++VGAuthError
++CertVerify_CheckForUnrelatedCerts(int numCerts,
++ const char **pemCerts)
++{
++ VGAuthError err = VGAUTH_E_FAIL;
++ int chainLen = 0;
++ int i;
++ X509 **certs = NULL;
++ GList *rawList = NULL;
++ X509 *baseCert;
++ X509 *curCert;
++ X509_NAME *subject;
++ X509_NAME *issuer;
++
++ /* common single cert case; nothing to do */
++ if (numCerts == 1) {
++ return VGAUTH_E_OK;
++ }
++
++ /* convert all PEM to X509 objects */
++ certs = g_malloc0(numCerts * sizeof(X509 *));
++ for (i = 0; i < numCerts; i++) {
++ certs[i] = CertStringToX509(pemCerts[i]);
++ if (NULL == certs[i]) {
++ g_warning("%s: failed to convert cert to X509\n", __FUNCTION__);
++ goto done;
++ }
++ }
++
++ /* choose the cert to start the chain. shouldn't matter which */
++ baseCert = certs[0];
++
++ /* put the rest into a list */
++ for (i = 1; i < numCerts; i++) {
++ rawList = g_list_append(rawList, certs[i]);
++ }
++
++ /* now chase down to a l
Bug#1050970: open-vm-tools: CVE-2023-20900
> Hi, > > https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/compare/15b2b38edd7834b7ad93ae25831fc7ef2bf7ce28...bullseye?from_project_id=38835=false > > > > bookworm: > > https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/compare/2231c605efb0564efee229d6c535033159cc92bc...bookworm?from_project_id=38835=false > > These look good, please upload to security-master. bookworm needs to > be build with -sa sicne it's the first upload, > bullseye doesn't. Thanks! > Both uploaded (and fixed the version for the bookworm upload before uploading, seems dch still lives in bullseye...). Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1050970: open-vm-tools: CVE-2023-20900
Hi Moritz, Ack, that's perfectly fine! Thanks! Here are the current diffs: bullseye: https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/compare/15b2b38edd7834b7ad93ae25831fc7ef2bf7ce28...bullseye?from_project_id=38835=false bookworm: https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/compare/2231c605efb0564efee229d6c535033159cc92bc...bookworm?from_project_id=38835=false I'll have a look tomorrow. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1050970: open-vm-tools: CVE-2023-20900
On 2023-09-06 20:11, Bernd Zeimetz wrote: Hi security team, I'm preparing security uploads for bookworm-security and buster-security (bullseye-security of course... - we clearly have too many relases with bu) -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1050970: open-vm-tools: CVE-2023-20900
Hi security team, I'm preparing security uploads for bookworm-security and buster-security for CVE-2023-20900[0]: | VMware Tools contains a SAML token signature bypass vulnerability. A | malicious actor with man-in-the-middle (MITM) network positioning | between vCenter server and the virtual machine may be able to bypass | SAML token signature verification, to perform VMware Tools Guest | Operations. any objections against fixing CVE-2023-20867 at the same time? Its a minor issue so we did not fix it, but I think it doesn't hurt to include it in stable/oldstable uploads while we are at it. Current (untested) diff would be: https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/commit/3812674370c07c708744c0d1d497583dffa3d665 Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1050972: Ready for review
On 2023-09-06 09:22, Christian Ehrhardt wrote: The build was fine, I'm asking Bernd and/or Bryce to have another pair of eyes for a sanity check. => https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/merge_requests/23 After an approval and the tests passing it should be good for an upload to unstable. Pushed the merge button :) Please upload! -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1049967: regression: kernel WARNING at arch/x86/kernel/fpu/xstate.c:973 get_xsave_addr+0x9b/0xb0
Source: linux Version: 5.10.179-5 Severity: important X-Debbugs-Cc: b.zeim...@conova.com, m.viertha...@conova.com Hi, since updating the bullseye kernel to 5.10.179-5, we get the following kernel WARNING (and so a tainted kernel) while running under vmware ESX: [0.087938] [ cut here ] [0.087940] get of unsupported state [0.087947] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:973 get_xsave_addr+0x9b/0xb0 [0.087948] Modules linked in: [0.087952] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-24-amd64 #1 Debian 5.10.179-5 [0.087953] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 [0.087954] RIP: 0010:get_xsave_addr+0x9b/0xb0 [0.087956] Code: 48 83 c4 08 5b e9 15 80 bc 00 80 3d 8d 7c 80 01 00 75 a8 48 c7 c7 97 de cb 99 89 74 24 04 c6 05 79 7c 80 01 01 e8 f5 96 88 00 <0f> 0b 8b 74 24 04 eb 89 31 c0 e9 e6 7f bc 00 66 0f 1f 44 00 00 89 [0.087957] RSP: :9a203ec8 EFLAGS: 00010282 [0.087958] RAX: RBX: 9a46a600 RCX: 8b635fdfffa8 [0.087959] RDX: c0007fff RSI: 7fff RDI: 0247 [0.087960] RBP: 9a46a4a0 R08: R09: 9a203ce8 [0.087960] R10: 9a203ce0 R11: 8b637fec18a8 R12: 0246 [0.087961] R13: R14: R15: [0.087962] FS: () GS:8b635fe0() knlGS: [0.087962] CS: 0010 DS: ES: CR0: 80050033 [0.087963] CR2: 8b5d8d602000 CR3: 0001cbc0a001 CR4: 007300b0 [0.087977] Call Trace: [0.087982] identify_cpu+0x51f/0x540 [0.087985] identify_boot_cpu+0xc/0x94 [0.087986] arch_cpu_finalize_init+0x5/0x47 [0.087988] start_kernel+0x4ec/0x599 [0.087991] secondary_startup_64_no_verify+0xb0/0xbb [0.087993] ---[ end trace 8ac8962c4c9dda0c ]--- This sounds like the issue described in https://lore.kernel.org/lkml/2023081511-easing-exerciser-c356@gregkh/ Could you please follow up and include the fix in case its not in the next kernel pointrelease? Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1041497: vmm: fails to run with python3 >= 3.10
19.07.2023 21:36:39 Bastian Germann : >> uploading a broken 0.1 version and keeping the maintainer who actually >> orphaned the package intact is probably not the best way, I would >> suggest that you either adopt the package or at least set the QA Group >> as maintainer. > > Can you please reference the orphaning bug report? > I cannot find one and that is why the upload was a NMU and not a QA upload. Oh well sorry, seems there was no otphaning bug, I was sure there was one. Probably because I once said that I might take over the maintenance of the package. That's why I actually started to prepare it, but didn't find the time to finish it. If necessary I can look through my email archives, but if you want to maintain it, nobody will have anything against it.
Bug#1041497: vmm: fails to run with python3 >= 3.10
Package: vmm Version: 0.7.0-0.1 Severity: grave X-Debbugs-Cc: b...@debian.org Hi Bastian, uploading a broken 0.1 version and keeping the maintainer who actually orphaned the package intact is probably not the best way, I would suggest that you either adopt the package or at least set the QA Group as maintainer. # vmm ld Traceback (most recent call last): File "/usr/sbin/vmm", line 18, in sys.exit(run(sys.argv)) ^ File "/usr/lib/python3/dist-packages/VirtualMailManager/cli/main.py", line 43, in run handler = _get_handler() ^^ File "/usr/lib/python3/dist-packages/VirtualMailManager/cli/main.py", line 27, in _get_handler handler = CliHandler() File "/usr/lib/python3/dist-packages/VirtualMailManager/cli/handler.py", line 44, in __init__ super(CliHandler, self).__init__(skip_some_checks) File "/usr/lib/python3/dist-packages/VirtualMailManager/handler.py", line 87, in __init__ self._cfg = Cfg(self._cfg_fname) File "/usr/lib/python3/dist-packages/VirtualMailManager/config.py", line 292, in __init__ LazyConfig.__init__(self) File "/usr/lib/python3/dist-packages/VirtualMailManager/config.py", line 73, in __init__ 'optionname': LazyConfigOption(int, 1, self.getint), ^ File "/usr/lib/python3/dist-packages/VirtualMailManager/config.py", line 251, in __init__ if not isinstance(getter, collections.Callable): AttributeError: module 'collections' has no attribute 'Callable' collections.Callable is collections.abs.Callable since Python 3.10 Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1037485: Adsense of ovt in Debian 12 iso image
On 2023-06-14 14:31, Winnie Yue wrote: Hi, We used https://cdimage.debian.org/debian-cd/12.0.0/amd64/iso-dvd/debian-12.0.0-amd64-DVD-1.iso and https://cdimage.debian.org/debian-cd/12.0.0/i386/iso-dvd/debian-12.0.0-i386-DVD-1.iso. For previous released versions, open-vm-tools was included in this type of iso. Debian is growing, so things are gettings moved automatically. https://cdimage.debian.org/debian-cd/current/amd64/ has some list-* folders which contain the list of packages of all packages. Rebuilding or customizing CDs is also not hard, for example you could provide uptodate netinst images that include open-vm-tools* Happy to help, Bernd Best regards, Winnie Yue From: Bernd Zeimetz Date: Wednesday, June 14, 2023 at 17:50 To: Winnie Yue , 1037...@bugs.debian.org <1037...@bugs.debian.org> Cc: cont...@bugs.debian.org Subject: Re: Bug#1037485: Adsense of ovt in Debian 12 iso image !! External Email severity 1037485 wishlist thanks On 2023-06-13 13:24, Winnie Yue wrote: We noticed that there is no open-vm-tools in Debian 12.0 iso image. As you might have noticed there is more than one iso image. You didn't mention which one you are using, so I assume its the network install image or the normal CD image. They are used to install a minimal system and can't contain all packages - they are way too small for that. You could - for example - use the first blueray (bd) image or the 16BG usb stick image instead. Btw, this behaviour did not change. open-vm-tools is part of the "contrib" part of Debian as it needs a proprietary environment to work with. Software from that won't be on the netinstall image. -- Bernd ZeimetzDebian GNU/Linux Developer https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbzed.de%2F=05%7C01%7Cwyue%40vmware.com%7C63da81e1978c4afd0c6c08db6cbcd7a1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638223330573383553%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=f4ciW%2Bvm0Efbond4VmXz9BuYmabIHmFSQCmBP21cf9I%3D=0 [1] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.debian.org%2F=05%7C01%7Cwyue%40vmware.com%7C63da81e1978c4afd0c6c08db6cbcd7a1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638223330573383553%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=pSTxwSkrTzph7pUTPdUTZ%2Bmzs9V4iT0T5DdeOvv4aOc%3D=0 [2] GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F !! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender. Links: -- [1] http://bzed.de/ [2] http://www.debian.org/ -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1037485: Adsense of ovt in Debian 12 iso image
severity 1037485 wishlist thanks On 2023-06-13 13:24, Winnie Yue wrote: We noticed that there is no open-vm-tools in Debian 12.0 iso image. As you might have noticed there is more than one iso image. You didn't mention which one you are using, so I assume its the network install image or the normal CD image. They are used to install a minimal system and can't contain all packages - they are way too small for that. You could - for example - use the first blueray (bd) image or the 16BG usb stick image instead. Btw, this behaviour did not change. open-vm-tools is part of the "contrib" part of Debian as it needs a proprietary environment to work with. Software from that won't be on the netinstall image. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1034516: gpsd: Default GPSD_OPTIONS should include -n
Hi, > The lead developer of gpsd says that, "You should always use the '-n' > flag"[1]. > the lead developer of gpsd refuses to understand how systemd works and is rather unpleasant to deal with. > However, GPSD_OPTIONS in /etc/default/gpsd does not default to including it. > > Version 3.22 has a bug (fixed in 3.24 I believe) in which PPS devices are not > properly used if -n is not passed.[2] Then -n would be a workaround... In the "default" way (and that is: for most cases don't do anything except somthing via the socket talks to gpsd), which is the only sane option for distributions imho, gpsd is configured to talk to a gps device when udev will recognize one. So there is no need for -n. If there is a need for anything else - change the configuration. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1034532: O: gpsd -- Global Positioning System - daemon
Package: wnpp Severity: normal X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gpsd Hi! I intend to orphan the gpsd package. While it was fun to work on the package back at the time when ESR was the lead developer, things have changed unfortunately. If you want to take over the maintenance of the package: - expect a hostile upstream, especially when you talk about distro requirements, systemd or similar things - expect words that will fail to pass any kind of code of conduct. - expect breaking API and ABI changes with every version. - expect scons as build system, which is a major source of PAIN in every imaginable body part. - you should have some knowledge about libraries, symbols, API/ABIs, building shared/static libs and similar things, you might need to be able to debug the build/usage of all these things, althouigh lately the scons stuff worked okayish most of the time. I'm happy to help to take over the maintenance of the package, guess I have a bit of in depth knowledge as I've fixed various bugs on the upstream side, too The package description is: The gpsd service daemon can monitor one or more GPS devices connected to a host computer, making all data on the location and movements of the sensors available to be queried on TCP port 2947. . With gpsd, multiple GPS client applications can share access to devices without contention or loss of data. Also, gpsd responds to queries with a format that is substantially easier to parse than the different standards emitted by GPS devices. . This also includes common tools ubxtool and gpsctl for device configuration of the local hardware as well as a ntpshmmon to check generated refclock data. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1034089: calibre: TypeError on opening Preferences
Package: calibre
Version: 6.15.0-1
Severity: important
Dear Maintainer,
When I click on "Preferences", an error dialog is displayed, with the following
content:
calibre 6.15 embedded-python: False
Linux-6.2.10-1-siduction-amd64-x86_64-with-glibc2.36 Linux ('64bit', 'ELF')
('Linux', '6.2.10-1-siduction-amd64', '#1 SMP PREEMPT_DYNAMIC siduction 6.2-10
(2023-04-06)')
Python 3.11.2
Interface language: en_GB
Successfully initialized third party plugins: Count Pages (1, 11, 2) && Modify
ePub (1, 7, 3) && Quality Check (1, 12, 0)
Traceback (most recent call last):
File "/usr/lib/calibre/calibre/gui2/preferences/main.py", line 308, in
show_plugin
self.showing_widget = plugin.create_widget(self.scroll_area)
^^
File "/usr/lib/calibre/calibre/customize/__init__.py", line 709, in
create_widget
return widget(parent)
^^
File "/usr/lib/calibre/calibre/gui2/preferences/__init__.py", line 267, in
__init__
self.setupUi(self)
File "/usr/lib/calibre/calibre/gui2/preferences/saving_ui.py", line 46, in
setupUi
self.save_template = SaveTemplate(parent=Form)
^
TypeError: SaveTemplate.__init__() got an unexpected keyword argument 'parent'
(the Preferences dialog does not open)
-- System Information:
Debian Release: 12.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.2.10-1-siduction-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages calibre depends on:
ii ca-certificates20230311
ii calibre-bin6.15.0-1
ii fonts-liberation2 2.1.5-1
ii libjpeg-turbo-progs1:2.1.5-2
ii libjxr-tools 1.2~git20170615.f752187-5
ii libqt6webenginecore6-bin 6.4.2-final+dfsg-1
ii optipng0.7.7-2+b1
ii poppler-utils 22.12.0-2+b1
ii pyqt6-dev-tools6.4.2-1
ii python33.11.2-1
ii python3-apsw 3.40.0.0-2+b1
ii python3-bs44.11.2-2
ii python3-chm0.8.6-3+b4
ii python3-css-parser 1.0.8-1
ii python3-cssselect 1.2.0-2
ii python3-dateutil 2.8.2-2
ii python3-feedparser 6.0.10-1
ii python3-html2text 2020.1.16-2
ii python3-html5-parser 0.4.10-8+b1
ii python3-html5lib 1.1-3
ii python3-jeepney0.8.0-3
ii python3-lxml 4.9.2-1+b1
ii python3-markdown 3.4.1-2
ii python3-mechanize 1:0.4.8+pypi-5
ii python3-msgpack1.0.3-2+b1
ii python3-netifaces 0.11.0-2+b1
ii python3-pil9.4.0-1.1+b1
ii python3-pkg-resources 66.1.1-1
ii python3-py7zr 0.11.3+dfsg-5
ii python3-pycryptodome 3.11.0+dfsg1-4
ii python3-pygments 2.14.0+dfsg-1
ii python3-pyparsing 3.0.9-1
ii python3-pyqt6 6.4.2-1
ii python3-pyqt6.qtquick 6.4.2-1
ii python3-pyqt6.qtsvg6.4.2-1
ii python3-pyqt6.qtwebengine 6.4.0-1
ii python3-pyqt6.sip 13.4.1-1
ii python3-regex 0.1.20221031-1+b1
ii python3-routes 2.5.1-3
ii python3-speechd0.11.4-2
ii python3-zeroconf 0.54.0-1
ii python3.11 3.11.2-6
ii xdg-utils 1.1.3-4.1
Versions of packages calibre recommends:
ii python3-dnspython 2.3.0-1
ii python3-ipython8.5.0-4
ii qt6-wayland6.4.2-1
ii udisks22.9.4-4
Versions of packages calibre suggests:
pn python3-unrardll
-- no debconf information
Bug#1025950: RM: mod-gearman -- ROM; no usecase anymore
Package: ftp.debian.org Severity: normal Package is not necessary for current icinga installations, out of testing since two years now - time to remove it. Thanks, Bernd
Bug#1025949: RM: seamly2d -- ROM; kind-of-dead fork of valentina
Package: ftp.debian.org Severity: normal seamly2d did not progress as expected, valentina (packaged in Debian) is the way to go. Please remove it. Thanks, Bernd
Bug#1018068: Open-vm-tools 12.1.0 has been released
Source: open-vm-tools Source-Version: 2:12.1.0-1 Done: Bernd Zeimetz Hi John, I think at the time you've opened the bug report, security updates for all maintained Debian releases and backports where done already, only testing is waiting for the migration which should happen today. Cheers, Bernd On Thu, 2022-08-25 at 05:41 +, John Wolfe wrote: > Package: open-vm-tools > Version: 12.1.0 > open-vm-tools 12.1.0 was released on Aug. 23, 2022. > > This release contains several fixes including: > - fix for CVE-2022-31676 - a local privilege escalation vulnerability. > - a number of Coverity reported issues have been addressed. > - https://github.com/vmware/open-vm-tools/pull/588 > - https://github.com/vmware/open-vm-tools/pull/387 > > For complete details, see: > https://github.com/vmware/open-vm-tools/releases/tag/stable-12.1.0 > > Release Notes are available at: > https://github.com/vmware/open-vm-tools/blob/stable-12.1.0/ReleaseNotes.md > > The granular changes that have gone into the 12.1.0 release are in the > ChangeLog at > https://github.com/vmware/open-vm-tools/blob/stable-12.1.0/open-vm-tools/ChangeLog > > > > -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1018012: open-vm-tools: CVE-2022-31676: local privilege escalation
Hi security team,
I've prepared uploads for bullseye and buster, diffs are attached.
CI is also happy:
https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/pipelines
Is it okay to upload to *-security?
Thanks,
Bernd
On Wed, 2022-08-24 at 09:18 +0200, Salvatore Bonaccorso wrote:
> Source: open-vm-tools
> Version: 2:12.0.5-2
> Severity: grave
> Tags: security upstream fixed-upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team
>
>
> Hi,
>
> The following vulnerability was published for open-vm-tools.
>
> CVE-2022-31676[0]:
> > VMware Tools (12.0.0, 11.x.y and 10.x.y) contains a local privilege
> > escalation vulnerability. A malicious actor with local non-
> > administrative access to the Guest OS can escalate privileges as a
> > root user in the virtual machine.
>
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2022-31676
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31676
> [1] https://www.vmware.com/security/advisories/VMSA-2022-0024.html
> [2]
> https://github.com/vmware/open-vm-tools/commit/70a74758bfe0042c27f15ce590fb21a2bc54d745
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
> Salvatore
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
diff --git a/debian/.gitlab-ci.yml b/debian/.gitlab-ci.yml
index df6de3138..015d78d49 100644
--- a/debian/.gitlab-ci.yml
+++ b/debian/.gitlab-ci.yml
@@ -3,7 +3,7 @@ include:
- https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
variables:
- RELEASE: 'unstable'
+ RELEASE: 'bullseye'
SALSA_CI_DISABLE_APTLY: 0
SALSA_CI_DISABLE_AUTOPKGTEST: 0
SALSA_CI_DISABLE_BLHC: 0
diff --git a/debian/changelog b/debian/changelog
index e37895416..234dd7c95 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+open-vm-tools (2:11.2.5-2+deb11u1) bullseye-security; urgency=high
+
+ * [67b16ff] Properly check authorization on incoming guestOps requests.
+(Closes: #1018012 CVE-2022-31676)
+ * [747392e] gbp: build in bullseye
+ * [80c2e62] gitlab-ci: build in bullseye
+
+ -- Bernd Zeimetz Wed, 24 Aug 2022 10:28:40 +0200
+
open-vm-tools (2:11.2.5-2) unstable; urgency=medium
* [7f14954] Drop max_nic_count patch.
diff --git a/debian/gbp.conf b/debian/gbp.conf
index bf4163e8d..83ee87ce1 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,3 +1,6 @@
+[DEFAULT]
+debian-branch = bullseye
+
[buildpackage]
sign-tags = True
posttag = git push && git push --tags
diff --git a/debian/patches/1125-Properly-check-authorization-on-incoming-guestOps-re.patch b/debian/patches/1125-Properly-check-authorization-on-incoming-guestOps-re.patch
new file mode 100644
index 0..25cfbe9ac
--- /dev/null
+++ b/debian/patches/1125-Properly-check-authorization-on-incoming-guestOps-re.patch
@@ -0,0 +1,33 @@
+From 4f5cfc23dd3357bafc8b699dd5c558f000a534c3 Mon Sep 17 00:00:00 2001
+From: John Wolfe
+Date: Wed, 10 Aug 2022 06:12:02 -0700
+Subject: [PATCH] Properly check authorization on incoming guestOps requests
+
+Fix public pipe request checks. Only a SessionRequest type should
+be accepted on the public pipe.
+---
+ open-vm-tools/vgauth/serviceImpl/proto.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+Index: pkg-open-vm-tools/open-vm-tools/vgauth/serviceImpl/proto.c
+===
+--- pkg-open-vm-tools.orig/open-vm-tools/vgauth/serviceImpl/proto.c
pkg-open-vm-tools/open-vm-tools/vgauth/serviceImpl/proto.c
+@@ -1,5 +1,5 @@
+ /*
+- * Copyright (C) 2011-2016,2019 VMware, Inc. All rights reserved.
++ * Copyright (c) 2011-2016,2019-2022 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU Lesser General Public License as published
+@@ -1201,6 +1201,10 @@ Proto_SecurityCheckRequest(ServiceConnec
+VGAuthError err;
+gboolean isSecure = ServiceNetworkIsConnectionPrivateSuperUser(conn);
+
++ if (conn->isPublic && req->reqType != PROTO_REQUEST_SESSION_REQ) {
++ return VGAUTH_E_PERMISSION_DENIED;
++ }
++
+switch (req->reqType) {
+ /*
+* This comes over the public connection; alwsys let it through.
diff --git a/debian/patches/series b/debian/patches/series
index 166107320..381f418ad 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
use-debian-pam
debian/scsi-udev-ru
Bug#1016187: collectd: diff for NMU version 5.12.0-9.1
Hi, thanks for your work, but I don't think that disabling -Werror is an appropriate fix, especially as the issues are rather easy to fix. I've uploaded -10 a few seconds ago. Bernd On Sat, 2022-08-20 at 22:22 +0300, Adrian Bunk wrote: > Control: tags 1016187 + patch > > Dear maintainer, > > I've prepared an NMU for collectd (versioned as 5.12.0-9.1) and uploaded > it to DELAYED/2. Please feel free to tell me if I should cancel it. > > cu > Adrian -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1015976: Should vmm be removed?
Hi, well, I've started to work on the package, but I've not yet decided if I want to maintain it. Help would be very welcome. Bernd 25.07.2022 21:53:09 Pascal Volk : > On 7/24/22 18:05, Moritz Muehlenhoff wrote: >> Source: vmm >> Version: 0.6.2-2 >> Severity: serious >> >> Your package came up as a candidate for removal from Debian: >> - Still depends on Python 2 >> - Last upload in 2017, removed from testing since 2019 >> >> If you disagree and want to continue to maintain this package, >> please just close this bug (and fix the open issues). >> > > Hi Moritz, > > looks like Bernd Zeimetz has taken over the maintenance for vmm. :-) > https://salsa.debian.org/debian/vmm/-/commit/5f5c7ef13ed33c60fdb0d4eb140370d9593bce56 > > Bernd, that's why I've added you to CC. > > > Regards, > Pascal > -- > Ubuntu is an ancient African word meaning “I can’t install Debian.” > -- unknown
Bug#1012752: unattended-upgrades: regularly stuck in loop, eating CPU
lib/apt/lists/deb.debian.org_debian_dists_sid-backports_contrib_binary-i386_Packages.bz2", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [. and so on] 100% CPU, needs to be killed as its stuck in a loop. Thanks, Bernd -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unattended-upgrades depends on: ii debconf [debconf-2.0] 1.5.79 ii lsb-base 11.2 ii lsb-release11.2 ii python33.10.4-1+b1 ii python3-apt2.3.0+b1 ii python3-dbus 1.2.18-3+b1 ii python3-distro-info1.1 ii ucf3.0043 ii xz-utils 5.2.5-2.1 Versions of packages unattended-upgrades recommends: ii anacron 2.3-32 ii cron [cron-daemon] 3.0pl1-139 ii systemd-sysv251.2-2 Versions of packages unattended-upgrades suggests: pn bsd-mailx pn needrestart ii postfix [mail-transport-agent] 3.6.4-1+b3 ii powermgmt-base 1.36 ii python3-gi 3.42.1-1 -- debconf information: unattended-upgrades/enable_auto_updates: true
Bug#976439: wminput: Aborts with "undefined symbol: PyVarObject_CallFunction"
Hi, with this MR applied, it does not crash at least. https://salsa.debian.org/georgesk/cwiid/-/merge_requests/1 Not tested yet. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#976439: wminput: Aborts with "undefined symbol: PyVarObject_CallFunction"
Hi, I've raised to seveirity to grave as this basically renders the package useless - and breaks connecting wiimotes. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1010899: ITP: python3-pyst -- Python module for interacting with the Asterisk PBX
Package: wnpp Severity: wishlist Owner: Bernd Schumacher * Package name: python3-pyst Version : 0.8 Upstream Author : Ralf Schlatterbeck * URL : https://github.com/schlatterbeck/pyst.git * License : LGPL, PSFL Programming Lang: Python Description : Python module for interacting with the Asterisk PBX Pyst consists of a set of interfaces and libraries to allow programming of Asterisk from python. The library currently supports AGI, AMI, and the parsing of Asterisk configuration files. The library also includes debugging facilities for AGI. In debian buster an older python2 version of pyst called python-pyst is already maintained by Apollon Oikonomopoulos . Now pyst supports also python3. Apollon Oikonomopoulos told me he is a bit short on time these days, and I could feel free to file an ITP and "adopt" the package. Ralf Schlatterbeck told me, he likes to see the a debian python3-pyst pakage.
Bug#1009013: krita: registers desktop file for csv (wtf)
Package: krita Version: 1:5.0.2+dfsg-2+b1 Severity: normal Hi, krita ships /usr/share/applications/krita_csv.desktop and will be registered as tool to open csv files. But it can't handle csv files and it really doesn't make sense to open them in Krita... Please fix that. Thanks. Bernd -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-rc6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages krita depends on: ii krita-data1:5.0.2+dfsg-2 ii libc6 2.33-7 ii libexiv2-27 0.27.5-3 ii libfftw3-double3 3.3.8-2 ii libgcc-s1 12-20220319-1 ii libgif7 5.1.9-2 ii libgsl27 2.7.1+dfsg-3 ii libheif1 1.12.0-2+b3 ii libilmbase25 2.5.7-2 ii libjpeg62-turbo 1:2.1.2-1 ii libkf5completion5 5.90.0-1 ii libkf5configcore5 5.90.0-1 ii libkf5configgui5 5.90.0-1 ii libkf5coreaddons5 5.90.0-1 ii libkf5crash5 5.90.0-1 ii libkf5guiaddons5 5.90.0-2 ii libkf5i18n5 5.90.0-1 ii libkf5itemviews5 5.90.0-1 ii libkf5widgetsaddons5 5.90.0-1 ii libkf5windowsystem5 5.90.0-1 ii libkseexpr4 4.0.4.0-2 ii libkseexprui4 4.0.4.0-2 ii liblcms2-22.12~rc1-2 ii libmypaint-1.5-1 1.6.0-2 ii libopencolorio1v5 1.1.1~dfsg0-7.1+b1 ii libopenexr25 2.5.7-1 ii libopenjp2-7 2.4.0-6 ii libpng16-16 1.6.37-3 ii libpoppler-qt5-1 22.02.0-3 ii libpython3.10 3.10.4-2 ii libqt5concurrent5 5.15.2+dfsg-16 ii libqt5core5a 5.15.2+dfsg-16 ii libqt5dbus5 5.15.2+dfsg-16 ii libqt5gui55.15.2+dfsg-16 ii libqt5multimedia5 5.15.2-3 ii libqt5network55.15.2+dfsg-16 ii libqt5printsupport5 5.15.2+dfsg-16 ii libqt5qml55.15.2+dfsg-10 ii libqt5quick5 5.15.2+dfsg-10 ii libqt5quickwidgets5 5.15.2+dfsg-10 ii libqt5sql55.15.2+dfsg-16 ii libqt5sql5-sqlite 5.15.2+dfsg-16 ii libqt5svg55.15.2-4 ii libqt5widgets55.15.2+dfsg-16 ii libqt5x11extras5 5.15.2-2 ii libqt5xml55.15.2+dfsg-16 ii libquazip5-1 0.9.1-2 ii libraw20 0.20.2-2 ii libstdc++612-20220319-1 ii libtiff5 4.3.0-6 ii libwebp7 1.2.2-2+b1 ii libx11-6 2:1.7.5-1 ii zlib1g1:1.2.11.dfsg-4 Versions of packages krita recommends: pn krita-gmic ii python3-pyqt55.15.6+dfsg-1+b2 ii python3-sip 4.19.25+dfsg-3+b1 pn qml-module-qtmultimedia Versions of packages krita suggests: ii colord 1.4.6-1 ii ffmpeg 7:4.4.1-3+b2 pn krita-l10n -- no debconf information
Bug#1006744: open-vm-tools core dump on debian 10
Hi Girish, could you give 11.3.5 from buster-backports-sloppy a try please? If that doesn't fix it, 12.0 was released recently, but that will take a bit until packages are ready. You could download it from gthub and build/test it, though. Also - please note that bullseye is the current stable release. Bernd On 2022-03-08 11:18, Chilukuri, Girish - Dell Team wrote: Hi Bernd, Debian buster we are using. Thanks, Girish Internal Use - Confidential -Original Message- From: Bernd Zeimetz Sent: Tuesday, March 8, 2022 2:13 PM To: Chilukuri, Girish - Dell Team; 1006...@bugs.debian.org Cc: Singh, Harmeet - Dell Team; Paturu, Santhosh - Dell Team Subject: Re: Bug#1006744: open-vm-tools core dump on debian 10 [EXTERNAL EMAIL] Hi, did you actually install the debug packages? The backtrace doesn't look like that. Please do so. https://urldefense.com/v3/__https://wiki.debian.org/HowToGetABacktrace__;!!LpKI!0puEtOoAByFgLNggB_VMDeU15wGT9ZJdww_v-PEituwvNiosvGG9pv-_z76wY7MGw9htYJ8$ [wiki[.]debian[.]org] Which release are you using? Bullseye? Or something else? What is "your product"? Thanks, Bernd On 2022-03-08 07:37, Chilukuri, Girish - Dell Team wrote: Hi Bernd, Below is the full backtrace from all threads from the core file. gdb /usr/bin/vmtoolsd rp_core.417 GNU gdb (Debian 8.2.1-2+b3) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://urldefense.com/v3/__http://gnu.org/licenses/gpl.html__;!!LpKI!0puEtOoAByFgLNggB_VMDeU15wGT9ZJdww_v-PEituwvNiosvGG9pv-_z76wY7MGF37RWWE$ [gnu[.]org]> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://urldefense.com/v3/__http://www.gnu.org/software/gdb/bugs/__;!!LpKI!0puEtOoAByFgLNggB_VMDeU15wGT9ZJdww_v-PEituwvNiosvGG9pv-_z76wY7MGIaDgDPE$ [gnu[.]org]>. Find the GDB manual and other documentation resources online at: <https://urldefense.com/v3/__http://www.gnu.org/software/gdb/documentation/__;!!LpKI!0puEtOoAByFgLNggB_VMDeU15wGT9ZJdww_v-PEituwvNiosvGG9pv-_z76wY7MGraty7eo$ [gnu[.]org]>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/vmtoolsd...(no debugging symbols found)...done. [New LWP 417] [New LWP 1105] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/bin/vmtoolsd'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120 120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory. [Current thread is 1 (Thread 0x7f321f095780 (LWP 417))] (gdb) where #0 0x7f321f589206 in __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120 #1 0x7f321f56b475 in __GI___fputs_unlocked (str=0x7f321e2f7ac8 , fp=fp@entry=0x55d222325690) at iofputs_u.c:34 #2 0x7f321f5e4868 in __GI___vsyslog_chk (pri=, flag=1, fmt=0x7f321edc083c "%s.", ap=0x7ffd36e1eda0) at ../misc/syslog.c:205 #3 0x7f321f5e4dff in __syslog_chk (pri=, flag=, fmt=) at ../misc/syslog.c:129 #4 0x7f321edbb1db in Audit_EventV () at /lib/libvgauth.so.0 #5 0x7f321edbb2a4 in Audit_Event () at /lib/libvgauth.so.0 #6 0x7f321edb7f95 in VGAuth_AuditEvent () at /lib/libvgauth.so.0 #7 0x7f321edb6d05 in VGAuth_ValidateUsernamePassword () at /lib/libvgauth.so.0 #8 0x7f321edd1cf1 in () at /usr/lib/open-vm-tools/plugins/common/libvix.so #9 0x7f321edd22e3 in () at /usr/lib/open-vm-tools/plugins/common/libvix.so #10 0x7f321edd25d9 in () at /usr/lib/open-vm-tools/plugins/common/libvix.so #11 0x7f321edd81f6 in () at /usr/lib/open-vm-tools/plugins/common/libvix.so #12 0x7f321edcf2cb in () at /usr/lib/open-vm-tools/plugins/common/libvix.so #13 0x7f3221a5f664 in RpcChannel_Dispatch () at /lib/libvmtools.so.0 #14 0x7f3221a611de in () at /lib/libvmtools.so.0 #15 0x7f3221a61aa4 in () at /lib/libvmtools.so.0 #16 0x7f32218dfe98 in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x7f32218e0288 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #18 0x7f32218e0582 in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #19 0x55d221850bb6 in () #20 0x55d22184fcc7 in main () (gdb) thread apply all bt Thread 2 (Thread 0x7f321ed23700 (LWP 1105)): #0 0x7f321f5df819 in __GI___poll (fds=0x55d22231b050, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f32218e01f6 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f32218e031c
Bug#1006744: open-vm-tools core dump on debian 10
Hi, did you actually install the debug packages? The backtrace doesn't look like that. Please do so. https://wiki.debian.org/HowToGetABacktrace Which release are you using? Bullseye? Or something else? What is "your product"? Thanks, Bernd On 2022-03-08 07:37, Chilukuri, Girish - Dell Team wrote: Hi Bernd, Below is the full backtrace from all threads from the core file. gdb /usr/bin/vmtoolsd rp_core.417 GNU gdb (Debian 8.2.1-2+b3) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/vmtoolsd...(no debugging symbols found)...done. [New LWP 417] [New LWP 1105] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/bin/vmtoolsd'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120 120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory. [Current thread is 1 (Thread 0x7f321f095780 (LWP 417))] (gdb) where #0 0x7f321f589206 in __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120 #1 0x7f321f56b475 in __GI___fputs_unlocked (str=0x7f321e2f7ac8 , fp=fp@entry=0x55d222325690) at iofputs_u.c:34 #2 0x7f321f5e4868 in __GI___vsyslog_chk (pri=, flag=1, fmt=0x7f321edc083c "%s.", ap=0x7ffd36e1eda0) at ../misc/syslog.c:205 #3 0x7f321f5e4dff in __syslog_chk (pri=, flag=, fmt=) at ../misc/syslog.c:129 #4 0x7f321edbb1db in Audit_EventV () at /lib/libvgauth.so.0 #5 0x7f321edbb2a4 in Audit_Event () at /lib/libvgauth.so.0 #6 0x7f321edb7f95 in VGAuth_AuditEvent () at /lib/libvgauth.so.0 #7 0x7f321edb6d05 in VGAuth_ValidateUsernamePassword () at /lib/libvgauth.so.0 #8 0x7f321edd1cf1 in () at /usr/lib/open-vm-tools/plugins/common/libvix.so #9 0x7f321edd22e3 in () at /usr/lib/open-vm-tools/plugins/common/libvix.so #10 0x7f321edd25d9 in () at /usr/lib/open-vm-tools/plugins/common/libvix.so #11 0x7f321edd81f6 in () at /usr/lib/open-vm-tools/plugins/common/libvix.so #12 0x7f321edcf2cb in () at /usr/lib/open-vm-tools/plugins/common/libvix.so #13 0x7f3221a5f664 in RpcChannel_Dispatch () at /lib/libvmtools.so.0 #14 0x7f3221a611de in () at /lib/libvmtools.so.0 #15 0x7f3221a61aa4 in () at /lib/libvmtools.so.0 #16 0x7f32218dfe98 in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x7f32218e0288 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #18 0x7f32218e0582 in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #19 0x55d221850bb6 in () #20 0x55d22184fcc7 in main () (gdb) thread apply all bt Thread 2 (Thread 0x7f321ed23700 (LWP 1105)): #0 0x7f321f5df819 in __GI___poll (fds=0x55d22231b050, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f32218e01f6 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f32218e031c in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f32218e0361 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f32219084d5 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f321f6bbfa3 in start_thread (arg=) at pthread_create.c:486 #6 0x7f321f5ea4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7f321f095780 (LWP 417)): #0 0x7f321f589206 in __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120 #1 0x7f321f56b475 in __GI___fputs_unlocked (str=0x7f321e2f7ac8 , fp=fp@entry=0x55d222325690) at iofputs_u.c:34 #2 0x7f321f5e4868 in __GI___vsyslog_chk (pri=, flag=1, fmt=0x7f321edc083c "%s.", ap=0x7ffd36e1eda0) at ../misc/syslog.c:205 #3 0x7f321f5e4dff in __syslog_chk (pri=, flag=, fmt=) at ../misc/syslog.c:129 #4 0x7f321edbb1db in Audit_EventV () at /lib/libvgauth.so.0 #5 0x7f321edbb2a4 in Audit_Event () at /lib/libvgauth.so.0 #6 0x7f321edb7f95 in VGAuth_AuditEvent () at /lib/libvgauth.so.0 #7 0x7f321edb6d05 in VGAuth_ValidateUsernamePassword () at /lib/libvgauth.so.0 #8 0x7f321edd1cf1 in () at /usr/lib/open-vm-tools/plugins/common/libvix.so #9 0x7f321edd
Bug#1006744: open-vm-tools core dump on debian 10
Hi, Core file was generated and below is the segmentation fault information from core dump file: Using host libthread_db library "/usr/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/bin/vmtoolsd'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65 65 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory. is that the full backtrace? Please install the debug packages and get the backtrace from all threads from the core file. (gdb) where (gdb) thread apply all bt Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#873717: Fixed a long time ago....
Control: close -1 On 2022-02-28 09:57, Andreas Beckmann wrote: Definitively not. This was worked around in 5.7.2-2 with --disable-sigrok That actually fixes a bug called 'ftbfs'. The package will build again. Its not a workaround, this is the only solution. Trying to re-enable it on 5.12.0-9 only results in checking for libsigrok < 0.4... no and a subsequent configure failure. There is not libsigrok < 0.4 in Debian. Not even 0.4 is supported. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1005187: collectd build-depends on package that is not in testing.
On Tue, 2022-02-22 at 22:37 +, Peter Green wrote: > > To the best of my knowledge there is no mechanism to automatically remove > packages with broken build-dependencies from testing. I certainly > don't recall collectd being listed for autoremoval at the time I filed the > bug. No idea, but things work as expected, got this mail on january 9th: collectd 5.12.0-7 is marked for autoremoval from testing on 2022-02-04 It (build-)depends on packages with these RC bugs: 997189: liboping: FTBFS: oping.c:1159:25: error: format not a string literal and no format arguments [-Werror=format-security] https://bugs.debian.org/997189 > > The auto-removals system does take account of reverse build-dependencies when > deciding what extra removals to trigger, but unfortunately the same does not > apply to manual removals by the release team. > Not sure, but in the next mail the removal date changed, I'd assume as the removal from testing was used as base date for the autoremoval, not the filed bug: (mail from january 31st) collectd 5.12.0-8 is marked for autoremoval from testing on 2022-02-28 It (build-)depends on packages with these RC bugs: 1002985: ruby-redis, src:ruby-fakeredis: ruby-redis breaks ruby-fakeredis autopkgtest https://bugs.debian.org/1002985 997189: liboping: FTBFS: oping.c:1159:25: error: format not a string literal and no format arguments [-Werror=format-security] https://bugs.debian.org/997189 > In particular the following scenario can happen. > > Package a build-depends (but does not depend) on package b. > Package b is rc buggy. > The autoremovals system sends out mails notifying maintainers that if the > situation doesn't change, it will remove packages b and a > Package b gets manually removed by the release team. > The package with the rc bug is no longer in testing, so it drops off the > autoremoval system's list of issues. > Package a does not actually get autoremoved despite the earlier mail from the > autoremovals system. > > I suspect that may well be what happened here (liboping was manually > removed from testing as it was blocking the perl transition). > > > > Don't think so, at least thats how I interpret the mails I've got. > > It basically adds the extra work of tracking and closing this bug manually. > > I understand that and that is why I am selective about when I file such bugs. > If I see indications that the underlying issue is likely to be fixed on > a reasonable timescale, I generally will hold-off filing bugs on the reverse > dependencies. > > In this case I saw no such indications. The bug report was over a month > old with no maintainer response, and the package had not seen a maintainer > upload in over a year. > The maintainer is busy with real life, if I'd have known that it blocks the perl transition, I'd have fixed oping earlier. > > > > If you want to add such bugs, please link them properly to the bugs that > > caused the issue and make sure that it is closed automatically as soon as > > the > > issue is fixed. > > If the bts had a system to automatically close bugs when another package > migrates > to testing I would use it but afaict it doesn't. > > I am not going to build custom automation for such a small volume of bugs. > Ah thought that it would be automatically generated. > It certainly makes sense to link to the underlying bug though, I'll try and > remember > that next time. > That would be appreciated. > I guess I could also set "blocks", but i'm not entirely convinced it's > appropriate, > it's the maintainers call not mine as to whether to fix the issue by fixing > the > unmaintained package they build-depend on or by eliminating the > build-dependency > on it. True. But I still think that these things shouldn't need manual investigation and bugs at all, if autoremovals doesn't handle manual removals (I guess it does, but add a delay), that should be fixed. Manually filing bugs also needs time. Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#946152: iptables-dev vs libiptc-dev dependency in collectd
Hi,
sorry for the late reply!
On Fri, 2020-03-06 at 18:11 -0700, Antonio Russo wrote:
>
> Because that is not the case, the pkg-config calls to get the path to
> libip4tc{.h,.so} libip6tc{.h,.so} and libiptc.h fail. You can get around
> that with the trivial patch I've attached.
Unfortunately the attached patch is for xvfb - and not collectd.
If possible just send an MR on salsa.
Bernd
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1003579: wsl: destroys files/directories named 'temp'
Package: wsl
Version: 0.2.1-2
Severity: grave
hi,
when sourcing /usr/share/wsl/wsl-functions, files or directories named
temp are overwritten or renamed to .wslrun, depending on if it is a file
or directory. Errors are not handled at all...
cat ${MYENV} | grep -v "^#" | sort | uniq >temp
echo "# history ends #" >>temp
/bin/mv temp ${MYENV}
Made my temp folder unhappy. Even if its a file named 'temp', this
should never happen, especially as the created file is sourced later.
. ${MYENV}
Cheers,
Bernd
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#791445: marked as done (ceph: uses bundled "libjerasure" library again)
Hi, please keep in mind that there were regular incompatibilities happening between the libraries, and this might break ceph badly. You might want to add some automatic diff or similar tool, or sick to a specific version as build dependency. The dependency was added again when the diff was too big, and for good reasons. Bernd 08.01.2022 03:12:13 Debian Bug Tracking System : > Your message dated Sat, 08 Jan 2022 02:10:17 + > with message-id > and subject line Bug#791445: fixed in ceph 16.2.7+ds-2 > has caused the Debian Bug report #791445, > regarding ceph: uses bundled "libjerasure" library again > to be marked as done. > > This means that you claim that the problem has been dealt with. > If this is not the case it is now your responsibility to reopen the > Bug report if necessary, and/or fix the problem forthwith. > > (NB: If you are a system administrator and have no idea what this > message is talking about, this may indicate a serious mail system > misconfiguration somewhere. Please contact ow...@bugs.debian.org > immediately.) > > > -- > 791445: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791445 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#1002749: ceph: Do not upgrade to Pacific from an older version
Source: ceph Version: 16.2.6+ds-8 Severity: critical Hi, from https://docs.ceph.com/en/latest/releases/pacific/ V16.2.6 PACIFIC Danger DATE: 01 NOV 2021. DO NOT UPGRADE TO CEPH PACIFIC FROM AN OLDER VERSION. A recently-discovered bug (https://tracker.ceph.com/issues/53062) can cause data corruption. This bug occurs during OMAP format conversion for clusters that are updated to Pacific. New clusters are not affected by this bug. The trigger for this bug is BlueStore’s repair/quick-fix functionality. This bug can be triggered in two known ways: manually via the ceph-bluestore-tool, or automatically, by OSD if bluestore_fsck_quick_fix_on_mount is set to true. The fix for this bug is expected to be available in Ceph v16.2.7. DO NOT set bluestore_quick_fix_on_mount to true. If it is currently set to true in your configuration, immediately set it to false. DO NOT run ceph-bluestore-tool’s repair/quick-fix commands. Opening a bug to track it just in case... Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#1002312: gnu-smalltalk-browser: Smalltalk browser fails to start
Package: gnu-smalltalk-browser Version: 3.2.5-1.3+b3 Severity: grave Justification: renders package unusable X-Debbugs-Cc: be...@fams.de Dear Maintainer, * What led up to the situation? Tried to run the GNU Smalltalk Browser application. * What exactly did you do (or not do) that was effective (or ineffective)? Installed the gst-smalltalk-browser package and run 'gst-browser' from the command line. * What was the outcome of this action? Got the following error message: a Smalltalk Stream:2: Aborted a Smalltalk Stream:2: Error occurred while not in byte code interpreter!! /lib/libgst.so.7(+0x74607)[0x7f429c214607] /lib/x86_64-linux-gnu/libc.so.6(+0x3cef0)[0x7f429c017ef0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x141)[0x7f429c017e71] /lib/x86_64-linux-gnu/libc.so.6(abort+0x112)[0x7f429c001536] /lib/libgst.so.7(+0x10c04)[0x7f429c1b0c04] /lib/x86_64-linux-gnu/libsigsegv.so.2(+0x129c)[0x7f429bfd629c] /lib/x86_64-linux-gnu/libc.so.6(+0x3cef0)[0x7f429c017ef0] /lib/x86_64-linux- gnu/libgobject-2.0.so.0(g_type_check_is_value_type+0x1e)[0x7f427a1d4a7e] /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x216bae)[0x7f427a4cbbae] /lib/x86_64-linux- gnu/libgtk-x11-2.0.so.0(gtk_list_store_new+0xa8)[0x7f427a3e8cf8] Aborted Application stopped. * What outcome did you expect instead? Starting the GNU Smalltalk browser. * Other related information. This seems to be to https://stackoverflow.com/questions/52766461/gst-browser- fails-to-start though the bug is different from the ones linked from there. libgtk2.0-dev and libgtk2.0-0 are both installed, which are referenced as a solution to the problem. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnu-smalltalk-browser depends on: ii gnu-smalltalk 3.2.5-1.3+b3 ii gnu-smalltalk-common 3.2.5-1.3 ii libgtk2-gst 3.2.5-1.3+b3 gnu-smalltalk-browser recommends no packages. gnu-smalltalk-browser suggests no packages. -- no debconf information
Bug#892058: Your Debian key is expiring
On Sun, 2021-12-05 at 05:36 -0800, felix.lech...@lease-up.com wrote: > If you like this service, please leave a favorable comment here [2]. Very useful service, thanks for providing it! Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#990140: upgrade-reports: lxc-attach does not start with apparmor problem after ugrade to 10.10
Hi Paul, I just did an apt upgrade, error is history now. Thank you, the QA team, the kernel team and all the people at Debian for their hard, efficient and professional work behind the curtains now, in the past and in the future - I respect and appreciate very much. Wich you all the best, cheers Bernd Am 21.06.21 um 19:06 schrieb Paul Gevers: Hi Bernd, Thanks for your report. On 21-06-2021 18:04, Bernd Breuer wrote: after the recent upgrade to Buster 10.10 (including a kernel upgrade) the command 'lxc-attach' (out of the Linux Container (lxc) set of commands), typed in like "sudo lxc-attach " stopped working with the error message "lxc-attach: : lsm/lsm.c: lsm_process_label_set_at: 174 Operation not permitted - Failed to set AppArmor label "unconfined" The conainer itself is starting, but apparmor related config lines like "lxc.apparmor.profile = unconfined" produce the above mentioned error, also on another machine after the same packages upgrade. I expect lxc-attach to provide me a root shell in the running lxc-container like it was the case before the recent upgrade. As we didn't upgrade lxc during the point release, this *may* be caused by the updated Linux kernel. What happens if you reboot using the previous kernel? Paul
Bug#989064: curl: output of -w accidentally in microseconds
> Hi, > I am working on an NMU, but the build fails with the patch applied > (while it successfully builds before applying). > > Any hints before I find them myself are welcome. are your changes and/or the build output somewhere online? Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#990140: upgrade-reports: lxc-attach does not start with apparmor problem after ugrade to 10.10
Hi Paul, thanks for your immediate response. Your assumption is right, booting into kernel 4.19.0-16 causes lxc-attach to behave as expected, no more apparmor related errors. Cheers Bernd Am 21.06.21 um 19:06 schrieb Paul Gevers: Hi Bernd, Thanks for your report. On 21-06-2021 18:04, Bernd Breuer wrote: after the recent upgrade to Buster 10.10 (including a kernel upgrade) the command 'lxc-attach' (out of the Linux Container (lxc) set of commands), typed in like "sudo lxc-attach " stopped working with the error message "lxc-attach: : lsm/lsm.c: lsm_process_label_set_at: 174 Operation not permitted - Failed to set AppArmor label "unconfined" The conainer itself is starting, but apparmor related config lines like "lxc.apparmor.profile = unconfined" produce the above mentioned error, also on another machine after the same packages upgrade. I expect lxc-attach to provide me a root shell in the running lxc-container like it was the case before the recent upgrade. As we didn't upgrade lxc during the point release, this *may* be caused by the updated Linux kernel. What happens if you reboot using the previous kernel? Paul
Bug#990140: upgrade-reports: lxc-attach does not start with apparmor problem after ugrade to 10.10
Package: upgrade-reports Severity: normal Dear Maintainer, after the recent upgrade to Buster 10.10 (including a kernel upgrade) the command 'lxc-attach' (out of the Linux Container (lxc) set of commands), typed in like "sudo lxc-attach " stopped working with the error message "lxc-attach: : lsm/lsm.c: lsm_process_label_set_at: 174 Operation not permitted - Failed to set AppArmor label "unconfined" The conainer itself is starting, but apparmor related config lines like "lxc.apparmor.profile = unconfined" produce the above mentioned error, also on another machine after the same packages upgrade. I expect lxc-attach to provide me a root shell in the running lxc-container like it was the case before the recent upgrade. -- System Information: Debian Release: 10.10 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-17-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#989507: unblock: collectd/5.12.0-6
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package collectd
[ Reason ]
Fixing
#968950
collectd-dev: missing meta_data.h header file included by plugin.h
[ Impact ]
Building c plugins for collectd is not possible anymore.
[ Tests ]
There are header files being shipped again. No tests for that.
[ Risks ]
Plugins still fail to build. I have nothing to test that
unfortunately. Otherwise - no changes, so no risks.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock collectd/5.12.0-6
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
diff --git a/debian/changelog b/debian/changelog
index 74daf54..c6a6057 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+collectd (5.12.0-6) unstable; urgency=medium
+
+ * [b4e7861] collectd-dev: Add missing header files again.
+Thanks to Benjamin Drung (Closes: #968950)
+ * [3261aa1] Also create necessary directories
+ * [6c0c6be] Fix target location in dh_install
+
+ -- Bernd Zeimetz Tue, 01 Jun 2021 17:56:33 +0200
+
collectd (5.12.0-5) unstable; urgency=medium
* [11ee08b] Disable tokyotyrant.
diff --git a/debian/collectd-dev.install b/debian/collectd-dev.install
index a3dd678..ffd3f5f 100644
--- a/debian/collectd-dev.install
+++ b/debian/collectd-dev.install
@@ -1,4 +1,3 @@
src/liboconfig/oconfig.h usr/include/collectd/liboconfig
-src/*.h usr/include/collectd/core
-src/daemon/*.h usr/include/collectd/core/daemon
+usr/include/collectd/core
diff --git a/debian/rules b/debian/rules
index 5cf4804..ad8880f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -275,17 +275,24 @@ install-indep:
dh_testroot
dh_prep
dh_installdirs -i
- dh_install -i
+ set -e ;\
+ find src -path src/libcollectdclient -prune -o -path
src/liboconfig -prune -o -name '*.h' -print | while read i; do \
+ d=$$(echo "$${i}" | sed
's,^src,debian/tmp/usr/include/collectd/core,') ;\
+ mkdir -p $$(echo "$${i}" | sed -e
's,^src,debian/tmp/usr/include/collectd/core,' -e 's,/[^/]*$$,,') ;\
+ cp "$${i}" "$${d}" ;\
+ done
+
+ dh_install -i
+
# update include path for collectd header files
( set -e; \
cd $(CURDIR)/debian/collectd-dev/usr/include/collectd/; \
- for lib in $$(find . -type f -name '*.h'); do \
+ headers=$$(find . -type f -name '*.h'); \
+ for lib in $$headers; do \
libname=$$(basename $$lib); \
fullpath=$$(echo $$lib | sed -r -e
's,^\./,collectd/,'); \
- for dir in $$(find . -mindepth 1 -type d); do \
- sed -r -i -e
"s,(include\s+)\".*\<$$libname\",\1\"$$fullpath\"," $$dir/*.h; \
- done; \
+ sed -r -i -e
"s,(include\s+)\".*\<$$libname\",\1\"$$fullpath\"," $$headers; \
done )
install-arch: build
@@ -299,9 +306,9 @@ install-arch: build
rm -f debian/tmp/usr/lib/collectd/*.la
rm -f debian/tmp/usr/lib/libcollectdclient.la
rm -f debian/tmp/etc/collectd.conf
-
+
dh_install -a --sourcedir=$(CURDIR)/debian/tmp --fail-missing
-
+
perl ./debian/bin/gen_plugin_deps.pl
mkdir -p debian/collectd-core/usr/share/lintian/overrides/
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second set of .debs but not in first
-
-rw-r--r-- root/root /usr/include/collectd/core/utils/avltree/avltree.h
-rw-r--r-- root/root /usr/include/collectd/core/utils/cmds/cmds.h
-rw-r--r-- root/root /usr/include/collectd/core/utils/cmds/flush.h
-rw-r--r-- root/root /usr/include/collectd/core/utils/cmds/getthreshold.h
-rw-r--r-- root/root /usr/include/collectd/core/utils/cmds/getval.h
-rw-r--r-- root/root /usr/include/collectd/core/utils/cmds/listval.h
-rw-r--r-- root/root /usr/include/collectd/core/utils/cmds/parse_option.h
-rw-r--r-- root/root /usr/include/collectd/core/utils/cmds/putnotif.h
-rw-r--r-- root/root /usr/include/collectd/core/utils/cmds/putval.h
-rw-r--r-- root/root /usr/include/collectd/core/utils/common/common.h
-rw-r--r-- root/root
/usr/include/collectd/core/utils/config_cores/config_cores.h
-rw-r--r-- root/root /usr/include/collectd/core/utils/crc32/crc32.h
-rw-r--r-- root/root /usr/include/collectd/core/utils/cur
Bug#989064: curl: output of -w accidentally in microseconds
Package: curl Version: 7.74.0-1.2 Severity: serious Tags: patch upstream Hi, ymmv, but as there are probably zillions of scripts out there parsing the output of curl -w, I think switching to microseconds accidentally will break enough things to warrant a serious bug. Upstream bug is https://github.com/curl/curl/issues/6321 its fixed in 7.75.0 with the patches mentioned in the github issue. Please apply before bullseye will be relased. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#987412: gpsd ntrip mountpoint (aka stream) parsing and use error
Hi Aiden,
forwarded to upstream: https://gitlab.com/gpsd/gpsd/-/issues/136
Shouldn't take too long to fix, maybe I'll have a look into it
Bernd
On Sun, 2021-04-25 at 10:57 +, Aiden Morrison wrote:
> Hi Bernd,
>
> I can get this to manifest with
> ntrip://SNTu0:pa...@caster.dyndns.org:2101/NOT
>
> The same caster/mountpoint are working with each of the Ublox u-center
> software, the BKG Ntrip Client (https://igs.bkg.bund.de/ntrip/bnc) and the
> previously mentioned ntripclient code on github.
> BKG Ntrip Client - BNC
> BKG Ntrip Client (BNC) The BKG Ntrip Client (BNC) is an Open Source multi-
> stream client program designed for a variety of real-time GNSS
> applications.
> igs.bkg.bund.de
> Please let me know if further information is helpful.
>
> -Aiden
> From: Bernd Zeimetz
> Sent: 25 April 2021 11:52
> To: Aiden Morrison ; 987...@bugs.debian.org
> <987...@bugs.debian.org>
> Subject: Re: Bug#987412: gpsd ntrip mountpoint (aka stream) parsing and use
> error
> Hi,
>
> do you have a example url for me? Maybe a public ntrip caster with auth,
> that
> shows the bug?
>
> Thanks,
>
> Bernd
>
> On Fri, 2021-04-23 at 13:30 +, Aiden Morrison wrote:
> > Package: gpsd
> > Version: 3.22 (revision 3.22)
> > Error text: gpsd:ERROR not authorized for Ntrip stream
> > caster.address.extension/mountpoint
> >
> > Reproduction: provide an ntrip stream address per the documentation of
> > gpsd
> > at
> > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgpsd.gitlab.io%2Fgpsd%2Fgpsd.htmldata=04%7C01%7Caiden.morrison%40sintef.no%7Ced4144881c454d0f9b3708d907cfd559%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637549411485653196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=J6W2QinFv7DlRv3%2BTzKDFRPcTbgLEbJ5yYUqTznZaiI%3Dreserved=0
> > ) in the form
> > "ntrip://username:passw...@address.of.caster:port/mountpoint" and note
> > that
> > gpsd will throw the above error.
> >
> > If the configuration string is intentionally malformed to include a "/"
> > after the mountpoint name, this error is not thrown, however the
> > corrections are not sent to the attached GNSS receiver:
> >
> > cgps reports string
> > {"class":"DEVICE","path":"ntrip://user:p...@address.of.caster:port/mountp
> > oi
> > nt/","activated":0} showing the malformed mountpoint identifier
> >
> > I can connect to the same ntrip server
> > using
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnunojpg%2Fntripclientdata=04%7C01%7Caiden.morrison%40sintef.no%7Ced4144881c454d0f9b3708d907cfd559%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637549411485653196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=QjyVo3xXClMT1wKpQrYttB5LK37JIt%2FRBMR%2F44PGwNw%3Dreserved=0
> > as well as two commercial
> > software packages, so the error appears to be in how gpsd is interpreting
> > the connection string.
> >
> > If credentials would be helpful in reproducing this bug I can be
> > contacted
> > ataiden.morri...@sintef.no
> >
> >
>
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#987542: unblock: gpsd/3.22-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package gpsd
Adding missing Breaks/Replaces and fixing a bit of mess in the symbols
files.
gpsd (3.22-3) unstable; urgency=medium
* [c6838e37] Remove duplicate lines from symbol files.
Thanks to Matthias Klose (Closes: #985930)
* [5c240253] Mark String::QString(QString const&)@Base as optional.
Required for backporting.
* [2dfbaa07] Updating debian/control from debian/control.in
* [c582b2aa] gpsd-tools: add missing Breaks+Replaces
gpsd-tools needs Breaks/Replaces for gpsd-clients (<< 3.20-10)
Thanks to Andreas Beckmann (Closes: #987208)
-- Bernd Zeimetz Sun, 25 Apr 2021 12:17:57 +0200
Full diff is attached.
Thanks,
Bernd
unblock gpsd/3.22-3
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
diff --git a/debian/changelog b/debian/changelog
index dfef5f900..f0b5369f7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+gpsd (3.22-3) unstable; urgency=medium
+
+ * [c6838e37] Remove duplicate lines from symbol files.
+Thanks to Matthias Klose (Closes: #985930)
+ * [5c240253] Mark String::QString(QString const&)@Base as optional.
+Required for backporting.
+ * [2dfbaa07] Updating debian/control from debian/control.in
+ * [c582b2aa] gpsd-tools: add missing Breaks+Replaces
+gpsd-tools needs Breaks/Replaces for gpsd-clients (<< 3.20-10)
+Thanks to Andreas Beckmann (Closes: #987208)
+
+ -- Bernd Zeimetz Sun, 25 Apr 2021 12:17:57 +0200
+
gpsd (3.22-2) unstable; urgency=medium
[ Bernd Zeimetz ]
diff --git a/debian/control b/debian/control
index 30665b4e2..a38b8c82f 100644
--- a/debian/control
+++ b/debian/control
@@ -63,8 +63,8 @@ Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends},
libgps28 (= ${binary:Version}),
Suggests: gpsd
-Breaks: python-gps, gpsd (<< 3.20-9)
-Replaces: python-gps
+Breaks: python-gps, gpsd (<< 3.20-9), gpsd-clients (<< 3.20-10)
+Replaces: python-gps, gpsd-clients (<< 3.20-10)
Description: Global Positioning System - tools
The gpsd service daemon can monitor one or more GPS devices connected to
a host computer, making all data on the location and movements of the
diff --git a/debian/control.in b/debian/control.in
index cb2df897d..7ff2aa444 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -63,8 +63,8 @@ Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends},
libgpsLIBGPSSONAME (= ${binary:Version}),
Suggests: gpsd
-Breaks: python-gps, gpsd (<< 3.20-9)
-Replaces: python-gps
+Breaks: python-gps, gpsd (<< 3.20-9), gpsd-clients (<< 3.20-10)
+Replaces: python-gps, gpsd-clients (<< 3.20-10)
Description: Global Positioning System - tools
The gpsd service daemon can monitor one or more GPS devices connected to
a host computer, making all data on the location and movements of the
diff --git a/debian/libgpsLIBGPSSONAME.symbols
b/debian/libgpsLIBGPSSONAME.symbols
index 03ae8f936..3f66558b5 100644
--- a/debian/libgpsLIBGPSSONAME.symbols
+++ b/debian/libgpsLIBGPSSONAME.symbols
@@ -9,8 +9,6 @@ libgps.so.LIBGPSSONAME libgpsLIBGPSSONAME #MINVER#
(c++)"gpsmm::stream(int)@Base" 3.3
(c++)"gpsmm::waiting(int)@Base" 3.3
(c++)"gpsmm::~gpsmm()@Base" 3.3
- (c++)"gpsmm::~gpsmm()@Base" 3.3
- (c++)"gpsmm::~gpsmm()@Base" 3.3
(c++)"typeinfo for gpsmm@Base" 3.3
(c++)"typeinfo name for gpsmm@Base" 3.3
(c++)"vtable for gpsmm@Base" 3.3
diff --git a/debian/libqgpsmmLIBGPSSONAME.symbols
b/debian/libqgpsmmLIBGPSSONAME.symbols
index 84edae24e..d3d51ab01 100644
--- a/debian/libqgpsmmLIBGPSSONAME.symbols
+++ b/debian/libqgpsmmLIBGPSSONAME.symbols
@@ -36,18 +36,12 @@ libQgpsmm.so.LIBGPSSONAME libqgpsmmLIBGPSSONAME #MINVER#
(c++)"gpsmm::waiting(int)@Base" 3.3
(c++)"gpsmm::clear_fix()@Base" 3.3
(c++)"gpsmm::~gpsmm()@Base" 3.3
- (c++)"gpsmm::~gpsmm()@Base" 3.3
- (c++)"gpsmm::~gpsmm()@Base" 3.3
-#MISSING: 3.18# (c++|optional)"QDebug::~QDebug()@Base" 3.3
#MISSING: 3.18# (c++|optional)"QDebug::~QDebug()@Base" 3.3
(c++|optional)"QString::~QString()@Base" 3.3
- (c++|optional)"QString::~QString()@Base" 3.3
- (c++|optional)"QList::~QList()@Base" 3.5
(c++|optional)"QList::~QList()@Base" 3.5
(c++)"typeinfo for gpsmm@Base" 3.3
(c++)"typeinfo name for gpsmm@Base" 3.3
(c++)"vtable for gpsmm@Base" 3.3
-#MISSING: 3.18# (c++|optional)"QByteArray::~QByteArray()@Base" 3.3
#MISSING: 3.18# (c++|optional)"QByteArray::~QByteArray()@Base" 3.3
(c++)"shiftleft(unsigned char*, int, unsigned short)@Base"
Bug#987412: gpsd ntrip mountpoint (aka stream) parsing and use error
Hi,
do you have a example url for me? Maybe a public ntrip caster with auth, that
shows the bug?
Thanks,
Bernd
On Fri, 2021-04-23 at 13:30 +, Aiden Morrison wrote:
> Package: gpsd
> Version: 3.22 (revision 3.22)
> Error text: gpsd:ERROR not authorized for Ntrip stream
> caster.address.extension/mountpoint
>
> Reproduction: provide an ntrip stream address per the documentation of gpsd
> at (https://gpsd.gitlab.io/gpsd/gpsd.html) in the form
> "ntrip://username:passw...@address.of.caster:port/mountpoint" and note that
> gpsd will throw the above error.
>
> If the configuration string is intentionally malformed to include a "/"
> after the mountpoint name, this error is not thrown, however the
> corrections are not sent to the attached GNSS receiver:
>
> cgps reports string
> {"class":"DEVICE","path":"ntrip://user:p...@address.of.caster:port/mountpoi
> nt/","activated":0} showing the malformed mountpoint identifier
>
> I can connect to the same ntrip server
> using https://github.com/nunojpg/ntripclient as well as two commercial
> software packages, so the error appears to be in how gpsd is interpreting
> the connection string.
>
> If credentials would be helpful in reproducing this bug I can be contacted
> ataiden.morri...@sintef.no
>
>
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#987475: buildd.debian.org: fails to poweroff
Package: buildd.debian.org Severity: normal Dear Maintainer, I upgraded my ThinkPad T560 from Debian KDE Buster to Bullseye. Most of it works very well. Except, after a shutdown, the device does not turn off. The last messages stop on the screen and nothing happens anymore ( <= 8h). The error occurs with kernel 5.10.0-5-amd64 + 5.10.0-6-amd64. When testing with a kernel 4.19.0-14-amd64 (was still installed on the machine) everything is okay. A fresh installation with Bullseye (on another hard drive) is again flawed. The error occurs regardless of the way I shut down the machine (KDE Starter Menu or Terminal shutdown -h, systemctl poweroff, systemctl syspend). A restart works, but it takes about 2-3 minutes after the last message. I could switch back to Debian Buster if necessary, but I fear that the bug will also be included in the Bullseye stable. The following message is displayed at the end (Only the last lines): [ ok ] Reached target Shutdown [ ok ] Reached target Final Step [ ok ] Finished Power-Off [ ok ] Reached target Power-Off [49414.375090] rmi4_physical rmi-00: failed to read irqs, code=-6 [49414.640283] reboot: Power down
Bug#986173: new upstream (14.2.19)
Hi, that was discussed with the security and release team and point releases should be accepted. Please remind me to forward the mails. Bernd 31.03.2021 13:57:14 Thomas Goirand : > On 3/30/21 10:32 PM, Daniel Baumann wrote: >> Package: ceph >> Severity: important >> >> Hi, >> >> 14.2.19 just got released, announcement says: >> >> ---snip--- >> This is a hotfix release to prevent daemons from binding to loopback >> network interfaces. All nautilus users are advised to upgrade to this >> release. >> >> [...] >> >> This release fixes a regression introduced in v14.2.18 whereby in >> certain environments, OSDs will bind to 127.0.0.1. See >> https://tracker.ceph.com/issues/49938. >> ---snap--- >> >> it would be nice if this makes it to the archive soon. >> >> Regards, >> Daniel > > Hi Daniel, > > Well, this patch: > > https://github.com/ceph/ceph/commit/89321762ad4cfdd1a68cae467181bdd1a501f14d > > was made by me, because otherwise, it's impossible to run Ceph on a > bgp-to-the-host setup. So, if we're reverting this patch, I see this as > a regression, rather than an improvement. > > Also, I've posted an unblock request to the release team, and the > debdiff was 13 MB big. You know what's happening next, don't you? The > release team claims they can't review such big change, and refuses. What > do you suggest I do then? > > Do you see a way forward? > > Cheers, > > Thomas Goirand (zigo)
Bug#984426: Confirm Bug#984426
The last time I just fixed it via the rescue grub-install and did not made a bug report neither looked up the bug investigating for the reason. So this second time I looked up wtf could be the reason and found the missing uuid in the configuration - well I am not a guru, just a user ;-) Am 05.03.21 um 12:30 schrieb Colin Watson: On Fri, Mar 05, 2021 at 08:36:30AM +0100, Dr. Bernd Zimmermann wrote: I can confirm this bug. After apt-get upgrade from deb10u3 to deb10u4 and reboot, system boot hangs und grub must be reinstalled via rescue-system. Seems to be the SAME bug as a during the last failed upgrade a few months ago. May I ask: if you ran into this a few months ago (implying that the affected system was misconfigured at that time), how is it that you didn't fix the configuration at that point? (I'm genuinely curious about how people would run into the same class of failure twice on the same system, since once you've fixed grub-pc/install_devices you should be good for future upgrades.)
Bug#984426: Possible manual fix with install/configuration issue
See bug: #966575 It happens during auto-upgrade on systems with more than one disk (here raid1 /dev/md*) and due to inconsistent installation information in grub-pc: root@gkmonitor:~# debconf-show grub-pc | grep /install_devices: * grub-pc/install_devices: /dev/disk/by-id/ata-ST2000DM001-1ER164_Z4Z3JAP0 with: root@gkmonitor:~# ls -l /dev/disk/by-id/ insgesamt 0 lrwxrwxrwx 1 root root 9 Mär 5 09:37 ata-ST2000DM001-1ER164_Z4Z3JAP0 -> ../../sdb lrwxrwxrwx 1 root root 9 Mär 5 09:37 ata-ST2000DM001-1ER164_Z4Z3JBQN -> ../../sda lrwxrwxrwx 1 root root 9 Mär 5 09:37 md-name-gkmonitor:0 -> ../../md0 lrwxrwxrwx 1 root root 9 Mär 5 09:37 md-name-gkmonitor:1 -> ../../md1 So automatic upgrade will do grub-install into /dev/sdb and not /dev/sda. Booting from /dev/sda via BIOS will result in error. Fixing it with grub-install /dev/sda. dpkg-reconfigure grub-pc will give the option to select all disks, resulting in: root@gkmonitor:~# debconf-show grub-pc | grep /install_devices: * grub-pc/install_devices: /dev/disk/by-id/ata-ST2000DM001-1ER164_Z4Z3JBQN, /dev/disk/by-id/ata-ST2000DM001-1ER164_Z4Z3JAP0 On next upgrade, the grub-install script will hopefully upgrade all disk MBRs Regards, Bernd
Bug#984426: Confirm Bug#984426
Hey, I can confirm this bug. After apt-get upgrade from deb10u3 to deb10u4 and reboot, system boot hangs und grub must be reinstalled via rescue-system. Seems to be the SAME bug as a during the last failed upgrade a few months ago. Regards, Bernd
Bug#984551: valentina-tape: formular wizard crashes
Package: valentina Version: 0.7.44~dfsg-1 Severity: important Tags: upstream patch Hi, https://gitlab.com/smart-pattern/valentina/-/commit/d2c6ebba21c84bc428674fe9586b9ffa128f457d fixes a crash of the formular wizard in valentina-tape. As this seems to hapen regularily, I think it should be fixed for bullseye. cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#982949: Please allow libvirt-python 7.0.0 into bullseye
Hi Paul, On Wed, 2021-02-17 at 18:37 +0100, Paul Gevers wrote: > libvirt-python is a key package. and it should match libvirt. Having libvirt-python 6.x and libvirt 7.0 is (imho, ymmv...) much worse than an completely (from us) untested libvirt-python. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#981176: RFP: doas -- minimal replacement for sudo
On 2/5/21 11:17 PM, Geert Stappers wrote: > Qouting https://packages.debian.org/bullseye/pleaser > > please, a polite, regex-first sudo clone the good thing on open source is that is about having the choise... And I clearly prefer the openbsd doas code over something written in rust. Doas is in unstable already. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#982023: gimp-gmic: prevents gimp from loading
severity 982023 normal tags 982023 moreinfo thanks Hi, I had the same issue here, reason for that was that some library was linked against libdap25 and another one against libdap27. ==3160905== Invalid free() / delete / delete[] / realloc() ==3160905==at 0x4839EAB: operator delete(void*) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==3160905==by 0x58BBAC5: __cxa_finalize (cxa_finalize.c:83) ==3160905==by 0x15ED7FA2: ??? (in /usr/lib/x86_64-linux-gnu/libdap.so.27.0.4) ==3160905==by 0x4010342: _dl_fini (dl-fini.c:138) ==3160905==by 0x58BB4D6: __run_exit_handlers (exit.c:108) ==3160905==by 0x58BB679: exit (exit.c:139) ==3160905==by 0x58A3D10: (below main) (libc-start.c:342) ==3160905== Address 0x1674ad90 is 0 bytes inside a block of size 25 free'd ==3160905==at 0x4839EAB: operator delete(void*) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==3160905==by 0x58BBAC5: __cxa_finalize (cxa_finalize.c:83) ==3160905==by 0x1288B5A2: ??? (in /usr/lib/x86_64-linux-gnu/libdap.so.25.2.3) ==3160905==by 0x4010342: _dl_fini (dl-fini.c:138) ==3160905==by 0x58BB4D6: __run_exit_handlers (exit.c:108) ==3160905==by 0x58BB679: exit (exit.c:139) ==3160905==by 0x58A3D10: (below main) (libc-start.c:342) ==3160905== Block was alloc'd at ==3160905==at 0x4838DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==3160905==by 0x1290EC46: ??? (in /usr/lib/x86_64-linux-gnu/libdap.so.25.2.3) ==3160905==by 0x1288B1EC: ??? (in /usr/lib/x86_64-linux-gnu/libdap.so.25.2.3) ==3160905==by 0x400FFB1: call_init.part.0 (dl-init.c:72) ==3160905==by 0x40100B8: call_init (dl-init.c:30) ==3160905==by 0x40100B8: _dl_init (dl-init.c:119) ==3160905==by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so) Please either use unstable or wait until all testing migrations are done. If you still see this bug afterwards, please provide a valgrind output. It will be most likely that its not gmic code which triggers this bug. Also: gimp should not hang when a plugin crashes, and it didn't do so for me. That might be a different bug, possibly in gimp. Thanks, Bernd On 2/5/21 7:42 PM, Christoph Anton Mitterer wrote: > Package: gimp-gmic > Version: 2.9.4-1 > Severity: grave > Justification: renders package unusable > > > Hi. > > Since one of the more recent upgrades, gimp doesn't start up anymore, when > gimp-gmic is present (purging it solves the issue), but instead hangs > forever at th slapsh screen. > > > Cheers, > Chris. > > > > $ gimp --verbose > Parsing '/etc/gimp/2.0/gimprc' for configured language. > Parsing '/home/calestyo/.config/GIMP/2.10/gimprc' for configured language. > No language property found. > INIT: gimp_load_config > Parsing '/home/calestyo/.config/GIMP/2.10/unitrc' > Parsing '/etc/gimp/2.0/gimprc' > Parsing '/home/calestyo/.config/GIMP/2.10/gimprc' > Adding icon theme 'Color' (/usr/share/gimp/2.0/icons/Color) > Adding icon theme 'Legacy' (/usr/share/gimp/2.0/icons/Legacy) > Adding icon theme 'Symbolic' (/usr/share/gimp/2.0/icons/Symbolic) > Adding icon theme 'Symbolic-Inverted' > (/usr/share/gimp/2.0/icons/Symbolic-Inverted) > Adding icon theme 'Symbolic-High-Contrast' > (/usr/share/gimp/2.0/icons/Symbolic-High-Contrast) > Adding icon theme 'Symbolic-Inverted-High-Contrast' > (/usr/share/gimp/2.0/icons/Symbolic-Inverted-High-Contrast) > Loading icon theme 'Color' > Adding theme 'Dark' (/usr/share/gimp/2.0/themes/Dark) > Adding theme 'Gray' (/usr/share/gimp/2.0/themes/Gray) > Adding theme 'Light' (/usr/share/gimp/2.0/themes/Light) > Adding theme 'System' (/usr/share/gimp/2.0/themes/System) > Writing '/home/calestyo/.config/GIMP/2.10/themerc' > Trying splash '/home/calestyo/.config/GIMP/2.10/gimp-splash.png' ... failed > Trying splash '/usr/share/gimp/2.0/images/gimp-splash.png' ... OK > INIT: gimp_initialize > INIT: gimp_real_initialize > Parsing '/usr/lib/gimp/2.0/interpreters/default.interp' > Parsing '/usr/lib/gimp/2.0/environ/default.env' > INIT: gui_initialize_after_callback > INIT: gimp_restore > Parsing '/home/calestyo/.config/GIMP/2.10/parasiterc' > Loading 'brush factory' data > Loading /usr/share/gimp/2.0/brushes/Texture/Cell-01.gbr > Loading /usr/share/gimp/2.0/brushes/Texture/Cell-02.gbr > Loading /usr/share/gimp/2.0/brushes/Texture/Grass.gih > Loading /usr/share/gimp/2.0/brushes/Texture/Hatch-Pen-01.gbr > Loading /usr/share/gimp/2.0/brushes/Texture/Smoke.gbr > Loading /usr/share/gimp/2.0/brushes/Texture/Stone-Work-01.gih > Loading /usr/share/gimp/2.0/brushes/Texture/Texture-01.gbr > Loading /usr/share/gimp/2.0/brushes/Texture/Texture-02.gbr > Loading /usr/share/gimp/2.0/brushes/Texture/Texture-Hose-01.gih > Loading
Bug#934843: parsedatetime: FTBFS in stretch
Hi, On 1/30/21 12:54 AM, Santiago Vila wrote: > > I have not tested myself, but if this were my package I would try to > built it in 2019-08 (using "libfaketime" or something similar), as the > failure in the test suite seems to depend on the date on which it's > built. just done that with several of the timestamps that were marked as failed in your list - was not able reproduce that issue. I also remember that I gave it a try shortly after you've opened that bug, and it just built fine. So if you have any more clues on how to reproduce that issue, I'd be all happy to try it. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#981176: RFP: doas -- minimal replacement for sudo
Hi, I just did some last fixes and uploaded doas to unstable. Thanks for your work! but fyi: I failed a bit, I've enabled PAM, but uploaded before testing it. It will need a source only upload to migrate to testing anyway, I'll do that as soon as it is trough new. The version i ngit is working just fine. If you have some time, please add an autopkgtest. Something like: - creating a config for some user and for root - as root: doas -u someuser doas -u root whoami | grep root better ideas welcome, the CI should happily run your tests normally, but it is broken due to some ssl issues at the moment. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#981176: RFP: doas -- minimal replacement for sudo
Hi, weird, now I gave you more permissions - same I have. please try again. bernd On 2021-01-27 23:03, Scupake wrote: On Wed, Jan 27, 2021 at 10:28:25PM +0100, Bernd Zeimetz wrote: git push origin master:master or git push --all if you have more branches to push. Still having the same issue, here's the entire error: --- Enumerating objects: 56, done. Counting objects: 100% (56/56), done. Delta compression using up to 2 threads Compressing objects: 100% (48/48), done. Writing objects: 100% (56/56), 47.66 KiB | 3.97 MiB/s, done. Total 56 (delta 5), reused 0 (delta 0), pack-reused 0 remote: GitLab: remote: A default branch (e.g. master) does not yet exist for debian/doas remote: Ask a project Owner or Maintainer to create a default branch: remote: remote: https://salsa.debian.org/debian/doas/-/project_members remote: To https://salsa.debian.org/debian/doas.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'https://salsa.debian.org/debian/doas.git' --- Maybe I don't have permission to create a default branch? --- Scupake :D 4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16 -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#981176: RFP: doas -- minimal replacement for sudo
On 1/27/21 10:27 PM, Bernd Zeimetz wrote: > > > On 1/27/21 9:58 PM, Scupake wrote: >> Hello, >> >> I am getting an error when trying to git push, it's teling me that: >> "A default branch (e.g. master) does not yet exist for debian/doas >> Ask a project Owner or Maintainer to create a default branch" > > git push origin master:master or git push --all if you have more branches to push. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#981176: RFP: doas -- minimal replacement for sudo
On 1/27/21 9:58 PM, Scupake wrote: > Hello, > > I am getting an error when trying to git push, it's teling me that: > "A default branch (e.g. master) does not yet exist for debian/doas > Ask a project Owner or Maintainer to create a default branch" git push origin master:master > > --- > Scupake :D > 4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16 > -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#981176: RFP: doas -- minimal replacement for sudo
Hi, On 1/27/21 8:40 PM, Scupake wrote: > On Wed, Jan 27, 2021 at 08:20:55PM +0100, Bernd Zeimetz wrote: >> whats your salsa username? > @Scupake > I have just created my account a little bit ago. found your user :) > Also, are you going to make a repository in the debian group or should I > just make a repository? repository created, you should have got an invitation. I've configured the CI to use debian/.gitlab-ci.yml please use the salsa pipeline to test the package. please note that this requires to use git-buildpackage. let me know if you have troubles with that CI documentation is at https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/README.md thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#981176: RFP: doas -- minimal replacement for sudo
On 1/27/21 7:30 PM, Scupake wrote: > On Wed, Jan 27, 2021 at 06:48:39PM +0100, Bernd Zeimetz wrote: >> nice, I'll happily sponsor the upload. > Thanks! > >> Would you be willing to put your packaging work on salsa.debian.org? >> Maybe in the debian group? I could create a repository there if necessary. > Sure, I don't mind. whats your salsa username? -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#981176: RFP: doas -- minimal replacement for sudo
Hi, On 1/27/21 6:40 PM, Scupake wrote: > I have started working on packaging Duncaen's OpenDoas, I'll notify you > once I think it's ready for review. nice, I'll happily sponsor the upload. Would you be willing to put your packaging work on salsa.debian.org? Maybe in the debian group? I could create a repository there if necessary. Thanks for your work, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#981176: RFP: doas -- minimal replacement for sudo
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: doas Version : 6.8 Upstream Author : Duncan Overbruck znc others * URL : https://github.com/Duncaen/OpenDoas * License : bsd Programming Lang: c Description : minimal replacement for sudo OpenDoas: a portable version of OpenBSD's doas command With the regular security issues in sudo it would make sense to have an alternative tools with a much smaller codebase. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#956936: Same issue on bullseye [[Was: Re: Also impacts buster packages]]
Hi, On Tue, 26 Jan 2021 14:06:49 +0100 Bernd Schatz wrote: Now i run into this issue. sudo debsums --config | grep -v OK /etc/sudoersFAILED id uid=1004(beschat) gid=1004(beschat) Gruppen=1004(beschat),1005(libvirtd),64055(libvirt-qemu) Sorry, just after sending the mail i saw that i added the wrong group, after: sudo usermod -a -G libvirt beschat the box starts, now i ran into this: $ vagrant up Bringing machine 'default' up with 'libvirt' provider... ==> default: Checking if box 'debian/testing64' version '20210124.1' is up to date... ==> default: Starting domain. There was an error talking to Libvirt. The error message is shown below: Call to virDomainCreateWithFlags failed: can't connect to virtlogd: Socket-Erstellung zu '/r But this seems to be another issue ... -- Bernd
Bug#956936: Same issue on bullseye [[Was: Re: Also impacts buster packages]]
Hi, On Mon, 31 Aug 2020 14:51:35 -0600 Joel Johnson wrote: Version: 5.0.0-4+deb10u1 I ran into this same issue on a buster system, with additional buster-backports packages installed. After digging through it appears that during a recent update the libvirt-daemon-system package was uninstalled without me noticing. Reinstalling the package also resolved the issue for me. Because of an other problem with a vagrant box and debian buster i tried to reproduce that issue on a newly installed debian bullseye. Now i run into this issue. sudo debsums --config | grep -v OK /etc/sudoersFAILED id uid=1004(beschat) gid=1004(beschat) Gruppen=1004(beschat),1005(libvirtd),64055(libvirt-qemu) $ echo $VAGRANT_DEFAULT_PROVIDER libvirt Bringing machine 'default' up with 'libvirt' provider... Error while connecting to Libvirt: Error making a connection to libvirt URI qemu:///system?no_verify=1=/home/beschat/.ssh/id_rsa: Call to virConnectOpen failed: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage' dpkg -l | grep polkit ii gir1.2-polkit-1.0 0.105-29 amd64GObject introspection data for PolicyKit ii libpolkit-agent-1-0:amd64 0.105-29 amd64PolicyKit Authentication Agent API ii libpolkit-gobject-1-0:amd64 0.105-29 amd64PolicyKit Authorization API ii libpolkit-qt5-1-1:amd64 0.113.0-1 amd64PolicyKit-qt5-1 library sudo cat /var/lib/polkit-1/localauthority/10-vendor.d/60-libvirt.pkla [Allow group libvirt management permissions] Identity=unix-group:libvirt Action=org.libvirt.unix.manage ResultAny=yes ResultInactive=yes ResultActive=yes -- Bernd
Bug#980331: tokyotyrant: should ship with bullseye?
Hi, collectd (5.12.0-5) unstable; urgency=medium * [11ee08b] Disable tokyotyrant. See #980331 for details -- Bernd Zeimetz Tue, 26 Jan 2021 10:52:28 +0100 uploaded a few seconds ago. Bernd On 1/25/21 9:29 AM, Chris Hofstaedtler wrote: > Dear collectd Maintainers, > > * Salvatore Bonaccorso [210118 08:25]: >> On Sun, Jan 17, 2021 at 10:44:09PM +0100, Chris Hofstaedtler wrote: >>> Should bullseye really ship with such a package? > [..] >> If unmaintained, I guess this can make sense. But one would need to >> solve the collectd build-dependency, as we probably woulld not want to >> loose collectd in bullseye. > > would you consider removing the tokyotyrant build-dep, for the > reasons stated in bug #980331 (tl;dr: tokyotyrant is very old and > unmaintained, and probably shouldn't be exposed to the network?). > > Thanks, > Chris > > -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#864338: gpsd: Provide a way to initialize GPS mode on cards like Ericsson F5521gw or F3507g
Hi, please note that this is not a forum and not a user help lines, its a bug tracker. Please fix your device and permissions issues first, with the help from a debian-user mailinglist for example, and if you can send a proper report, do so. > Now I am confused that none of the previously working steps led to any output > on my device port. what is a "device port"? > In the past it wasn't possible to directly read /dev/ttyACM2 because of > permission issues. permission issues are not a problem that gpsd can fix for you. Use udev rules or whatever else is necessary. > The necessary information are posted here: > https://forum.ubuntuusers.de/topic/gpsd-mit-ericsson-f5521gw-mobile-broadband-mod/#post-6727147 > . > For now I can only report that gpsd can't read from the pipe mentioned in > this post. Which is just fine, because what you are doing there is sad sad nonsense. Learn to fix device permissions. > I turned the gps receiver on in the way I was able to remember, went outside, > but couldn't get any output of the NMEA stream when reading from > /dev/ttyACM2. I tried around with hard-resets and different ways connecting > clients, reading directly from port, but nothing turned out to work for me. Thas a LTE modem or something similar, you'll probably have to switch it into gps mode first. Nothing gpsd will do for you. So basically: 1. fix your permission issues (using a pipe is not a fix!), maybe using udev or whatever else is necessary. 2. learn how to put your modem into a working mode 3. trigger gpsd to read from you device. If you then run into bugs, run gpsd in debug mode... Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#979614: seamly2d: virtually dead fork of valentina
On 1/10/21 10:20 AM, Jonas Smedegaard wrote: > Quoting Bernd Zeimetz (2021-01-09 22:09:06) >>> Since then, he continued develop under original project name >>> Valentina, whereas Seamly2D virtually stalled with no substantial >>> code changes , only superficial changes to build infrastructure, >>> locales, and icons. >> >> well, compared to valentina it seems to have way more pull requests >> and is at least very responsive to requests. Looking on valentina it >> seems to be a one-man-show - more or less. > > Seems to me that Seamly2D is similarly a one-woman-show - difference > (disregarding sexes) being that one is good with code and the other is > good with words and people. I think its a woman and a man, at least according to the commits. There is a long list of issues with interesting ideas, more pushing towards cloud and similar features. > But I might be wrong. Or maybe code is largely "done" and only _need_ > smaller polishing. Definitely not, there are some new features like keyboard shortcuts (imho not chosen wisely, but thats my taste probably). >>> I recommend that Debian does not carry Seamly3D, and encourage >>> helping out with maintaining Valentina instead. >> >> Would have been nice to know about that after I've opened the RFP bug >> - to be hones I haven't even been able to find valentina with apt, >> maybe I've searched for the wrong words. > > For future sake, I recommend to share RFPs and ITPs to > debian-devel@l.d.o as is the default for reportbug Thats why I've used reportbug, would have expected that that happens. > That said, you got a point about keywords - and curiously, you didn't > add "sewing" to long description of Seamly2D either :-P true. we've copied the same text ;) > https://en.wikipedia.org/wiki/Valentina_(software) has a summary, with > link to a longer blog entry about it. > > Following trails from there, I found this post which seems essential: > https://web.archive.org/web/20171216140149/http://valentinaproject.forumotion.me/t23-my-vision I've searched a bit, also found https://librearts.org/2017/12/valentina-seamly2d/ which is the mentioned blog entry. > I found no similar information from Seamly2D side of the fork. If you > find any then please do share. Me neither. > Seems to me that Seamly2D has created a stronger brand with more fans, > whereas Valentina has more programmers involved (i.e. has "only one" or > "one at all", depending how you look at it). Was probably easy as the valentina-project page points to seamly now, which is rather sad. > I was hoping that the strong community of Seamly2D would lead to more > sample documents than the relatively few shipped with Valentina, but I > have so far not been able to locate any, and it seems all blog posts in > Seamly2D shares only PDFs, no *source* patterns. Therefore I also am > unaware how compatible Valentina and Seamly2D is in their document > formats, if at all. I also gave that a try: and they are not compatible anymore, although seamly still says valentina format. Which is.. stupid. It was easy to fix with 3676 sed 's,solidLine,hair,g' -i hike_and_fly_backpack.val 3678 sed 's,lineType,typeLine,g' -i hike_and_fly_backpack.val I'd have expected a new file format name and extension. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#979614: seamly2d: virtually dead fork of valentina
Hi, > Since then, he continued develop under original project name Valentina, > whereas Seamly2D virtually stalled with no substantial code changes , > only superficial changes to build infrastructure, locales, and icons. well, compared to valentina it seems to have way more pull requests and is at least very responsive to requests. Looking on valentina it seems to be a one-man-show - more or less. > I recommend that Debian does not carry Seamly3D, and encourage helping > out with maintaining Valentina instead. Would have been nice to know about that after I've opened the RFP bug - to be hones I haven't even been able to find valentina with apt, maybe I've searched for the wrong words. > If you disagree, then I just wish you the best of luck with Seamly3D. > I admit the severity is bloated - feel free to lower as you see fit. I think keeping one of them in Debian is the better option, but for now I'm not sure whats the best option. I'd be very happy to co-maintain one. Never planned to put seamly2d into bullseye, so don't worry about severities. Any idea why there is a fork at all? (feel free to reply in private...) Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#979341: transition: gpsd
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi release team, just in time gpsd upstream pushed the first release candidate of 3.22, which is due to be released within the next few days. As usual its comes with a soname bump and a small api change, so I've uploaded -rc1 to experimental, ready to upload to unstable. Only one build-rdep fails to build against it (foxtrotgps, fix in progress, #979252), as you can see here. https://salsa.debian.org/debian-gps-team/pkg-gpsd/-/pipelines/215214 Please ack the start of the transition. Thanks, Bernd Ben file: title = "gpsd"; is_affected = .depends ~ /^lib.*gps.*26$/ | .depends ~ /^lib.*gps.*28$/; is_good = .depends ~ /^lib.*gps.*28$/; is_bad = .depends ~ /^lib.*gps.*26$/; -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#979260: navit: support gps.h api 10
Package: navit
Version: 0.5.5+dfsg.1-1
Severity: important
Tags: patch
Hi,
the upcoming gpsd upload ships with a new api version.
The attached patch fixes the ftbfs.
Thanks,
Bernd
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Index: navit-0.5.5+dfsg.1/navit/vehicle/gpsd/vehicle_gpsd.c
===
--- navit-0.5.5+dfsg.1.orig/navit/vehicle/gpsd/vehicle_gpsd.c
+++ navit-0.5.5+dfsg.1/navit/vehicle/gpsd/vehicle_gpsd.c
@@ -166,7 +166,11 @@ vehicle_gpsd_callback(struct gps_data_t
data->set &= ~SATELLITE_SET;
}
if (data->set & STATUS_SET) {
+#if GPSD_API_MAJOR_VERSION >= 10
+priv->status = data->fix.status;
+#else
priv->status = data->status;
+#endif
data->set &= ~STATUS_SET;
}
if (data->set & MODE_SET) {
Bug#979254: s3dosm: support gps.h api 10
Package: s3dosm
Version: 0.2.2.1-2
Severity: important
Tags: patch
Hi,
the next gps.h comes with an api bump - the attached patch should be all
thats needed.
Thanks,
Bernd
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Index: s3d-0.2.2.1/apps/s3dosm/gps.c
===
--- s3d-0.2.2.1.orig/apps/s3dosm/gps.c
+++ s3d-0.2.2.1/apps/s3dosm/gps.c
@@ -43,7 +43,11 @@ void show_gpsdata(struct gps_data_t *dgp
printf("speed [kph]: %f\n", dgps->fix.speed / KNOTS_TO_KPH);
printf("used %d/%d satellits\n", dgps->satellites_used,
dgps->satellites_visible);
+#if GPSD_API_MAJOR_VERSION >= 10
+ switch (dgps->fix.status) {
+#else
switch (dgps->status) {
+#endif
case STATUS_NO_FIX:
printf("status: no fix\n");
break;
Bug#979252: foxtrotgps: support gps.h API 10
Package: foxtrotgps
Version: 1.2.2+bzr324-1
Severity: important
Tags: patch
Hi,
there is an API change coming with the next gpsd version (which I'd like
to get into bullseye...).
The attached patch should be all thats needed.
Thanks,
Bernd
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--- src/gps_functions.c.orig2021-01-04 18:24:55.810095970 +0100
+++ src/gps_functions.c 2021-01-04 18:24:57.738086752 +0100
@@ -762,7 +762,11 @@
{
gpsdata->fix.time = (time_t) 0;
}
+#if GPSD_API_MAJOR_VERSION >= 10
+ gpsdata->valid = (libgps_gpsdata.fix.status != STATUS_NO_FIX);
+#else
gpsdata->valid = (libgps_gpsdata.status != STATUS_NO_FIX);
+#endif
if (gpsdata->valid)
{
gpsdata->seen_valid = TRUE;
Bug#977021: bus errors on armhf running on a 64bit kernel
Dear Pierre,
Thanks for digging into it. Indeed the tests check whether unaligned
memory access works. Unfortunately, that is used in the
NativeTaggedArray for 64bit primitive types and even ranks, see e.g.
line 267 in NativeTaggedArray.
As I cannot reproduce the error myself, not even on a machine with
aarch64 architecture, can you please tell me if the tests pass when you
apply the attached patch?
Best regards,
Bernd
On 12/13/20 9:51 PM, Pierre Gruet wrote:
Dear Bernd,
I have looked again at the issue we discussed last Friday; as pointed
out in the companion bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929530#5
I see an unaligned address is passed to GetXxxArrayRegion() in the
native part of the code, when running the tests testXxxToByteToXxx, for
Xxx in {Char, Short, Ing, Long, Float, Double}: this happens when the
argument targetOfs of the test is not a multiple of the size of Xxx.
I suggest to remove all pairs (i,j) from getOfs() in NativeDataTests
where j is not zero. I think the pairs (i,0) could remain even when i is
not zero, but I would remove them as well because the only place, in the
main source, where copyXxxToByte or copyByteToXxx are used is in
NativeTaggedArray, and there it never happens that inStart and outStart
are not multiples of the size of Xxx.
Do you agree or am I missing something? If you think my suggestions are
correct, I will upload the package with a patch leaving only the pair
(0,0) in getOfs() in NativeDataTests.
Warm thanks for your help,
Pierre
On Thu, 10 Dec 2020 18:45:37 +0100 Bernd Rinn wrote:
> Dear Pierre,
>
> No, I've not yet seen this bus error. I can see two changes to my test
> setup:
>
> - JDK 11 instead of JDK 8
> - 64bit OS instead of 32 bit OS
>
> The 64bit platoform is more likely to be the change that uncovers this
> bug. Which hardware did you get the error on?
>
> All the best,
> Bernd
>
> On 12/10/20 5:45 PM, Pierre Gruet wrote:
> > Control: forwarded -1 br...@ethz.ch
> >
> >
> > Dear Bernd,
> >
> > In Debian we have received a bug report you may find below: there
seems
> > to be an unaligned memory access in (seemingly) the JNI part of
sis-base
> > version 18.09, leading to a failure on the architecture armhf
running on
> > a 64bit kernel.
> >
> > Have you already met this issue and do you see how it might be fixed?
> >
> > Thanks a lot,
> > Pierre Gruet
> >
> >
> > On Thu, 10 Dec 2020 07:15:24 +0100 Matthias Klose
wrote:
> > > Package: src:libsis-base-java
> > > Version: 18.09~pre1+git20180928.45fbd31+dfsg-2
> > > Severity: important
> > > Tags: sid bullseye
> > >
> > > building libsis-base-java (or running the jni) leads to a bus
error,
> > usually
> > > caused by unaligned memory accesses.
> > >
> > > [...]
> > > LC_ALL=C java -Djava.library.path=source/c/.libs -classpath
> > sis-base-test.jar
> > > ch.systemsx.cisd.base.AllTests
> > > Application: base
> > > Version: UNKNOWN*
> > > Java VM: OpenJDK Server VM (v11.0.9.1+1-Debian-1)
> > > CPU Architecture: arm
> > > OS: Linux (v4.15.0-126-generic)
> > > Test class: NativeDataTests
> > >
> > > Running testFloatToByteNonNativeByteOrderPartialOutputArray
> > > Running testIntToByteToInt
> > > Arguments: [0, 0]
> > > Arguments: [0, 1]
> > > #
> > > # A fatal error has been detected by the Java Runtime Environment:
> > > #
> > > # SIGBUS (0x7) at pc=0xf74b1d1c, pid=10186, tid=10187
diff --git a/source/java/ch/systemsx/cisd/base/convert/NativeData.java b/source/java/ch/systemsx/cisd/base/convert/NativeData.java
index f962af5..ec85500 100644
--- a/source/java/ch/systemsx/cisd/base/convert/NativeData.java
+++ b/source/java/ch/systemsx/cisd/base/convert/NativeData.java
@@ -15,8 +15,6 @@ package ch.systemsx.cisd.base.convert;
import java.nio.ByteBuffer;
-import ch.systemsx.cisd.base.utilities.NativeLibraryUtilities;
-
/**
* This class encapsulates native methods to deal with arrays of numbers, converting from numbers to
* bytes and bytes to numbers.
@@ -28,26 +26,10 @@ import ch.systemsx.cisd.base.utilities.NativeLibraryUtilities;
* primitive numbers (int, short, ...)
*
* Variant interfaces convert only a sub-array.
- *
- * The class has optimized methods using jni-libraries for some common platforms and a pure-java
- * implementation (called javamode if the jni-libraries are not available). If you want to
- * enforce javamode, you need to pass the property nativedata.javamode=true to
- * the JRE.
*/
public class NativeData
{
-private static
Bug#977021: bus errors on armhf running on a 64bit kernel
Dear Pierre, No, I've not yet seen this bus error. I can see two changes to my test setup: - JDK 11 instead of JDK 8 - 64bit OS instead of 32 bit OS The 64bit platoform is more likely to be the change that uncovers this bug. Which hardware did you get the error on? All the best, Bernd On 12/10/20 5:45 PM, Pierre Gruet wrote: Control: forwarded -1 br...@ethz.ch Dear Bernd, In Debian we have received a bug report you may find below: there seems to be an unaligned memory access in (seemingly) the JNI part of sis-base version 18.09, leading to a failure on the architecture armhf running on a 64bit kernel. Have you already met this issue and do you see how it might be fixed? Thanks a lot, Pierre Gruet On Thu, 10 Dec 2020 07:15:24 +0100 Matthias Klose wrote: > Package: src:libsis-base-java > Version: 18.09~pre1+git20180928.45fbd31+dfsg-2 > Severity: important > Tags: sid bullseye > > building libsis-base-java (or running the jni) leads to a bus error, usually > caused by unaligned memory accesses. > > [...] > LC_ALL=C java -Djava.library.path=source/c/.libs -classpath sis-base-test.jar > ch.systemsx.cisd.base.AllTests > Application: base > Version: UNKNOWN* > Java VM: OpenJDK Server VM (v11.0.9.1+1-Debian-1) > CPU Architecture: arm > OS: Linux (v4.15.0-126-generic) > Test class: NativeDataTests > > Running testFloatToByteNonNativeByteOrderPartialOutputArray > Running testIntToByteToInt > Arguments: [0, 0] > Arguments: [0, 1] > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGBUS (0x7) at pc=0xf74b1d1c, pid=10186, tid=10187 smime.p7s Description: S/MIME Cryptographic Signature
Bug#976890: RFP: seamly2d -- pattern making program
Package: wnpp Severity: wishlist * Package name: seamly2d Version : 0.6.0.2+20201207 (latest weekly snapshot for now -> target experimental) * URL : https://github.com/FashionFreedom/Seamly2D * License : gpl3 Programming Lang: c++ Description : pattern making program Seamly2D enables creative parametric patterns which conform to an individual's body measurements and to multiple sizing tables. It blends new technologies with traditional methods to remove Victorian-era gender, ethnic, and size biases from clothing design. Seamly2D is created to allow independent patternmakers and designers to profitably scale their small batch clothing production. I've started to prepare some packaging based on upstream's work on Vcs-Git: https://salsa.debian.org/debian/pkg-seamly2d.git Vcs-Browser: https://salsa.debian.org/debian/pkg-seamly2d But I'm not keen on maintaining it, I have enough packages to take care of. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#973070: libsis-base-java: FTBFS: Could not delete the directory targets/unit-test-wd/ch.syst
Hi Andreas,
I can confirm that this bug is in commons-io 2.8.0 while commons-io 2.6
workes fine.
The bug is in PathUtils.deleteFile(), line 360 and 361:
"""
final boolean exists = Files.exists(file,
LinkOption.NOFOLLOW_LINKS);
final long size = exists ? Files.size(file) : 0;
"""
It determines "exists" based on not following the symlink by using
LinkOption.NOFOLLOW_LINKS, but then in the next line uses
Files.size(file) to determine the size which *does* follow the symlink.
Kaboom. This will prevent PathUtils.deleteFile() to delete any dangling
symlink (which it has to in my test case).
I have attached a patch for commons-io 2.8.0 which fixes this bug.
Cheers,
Bernd
On 10/28/20 8:29 PM, Andreas Tille wrote:
Control: forwarded -1 Bernd Rinn
Hi,
I'd recommend reading the bug report log from here to get some hints
about recommended changes in the code:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973070#17
For the moment I've excluded the affected tests.
Kind regards
Andreas.
- Forwarded message from Markus Koschany -
Date: Wed, 28 Oct 2020 19:34:35 +0100
From: Markus Koschany
To: Debian Java List
Cc: 973...@bugs.debian.org
Subject: Bug#973070: Bug#973070: Help needed: Bug#973070: libsis-base-java:
FTBFS: Could not delete the directory
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests because: 1
exceptions: [java.io.IOException: Unable to delete file:
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someDanglingLink]
X-Debian-PR-Message: followup 973070
X-Debian-PR-Package: src:libsis-base-java
X-Debian-PR-Keywords: bullseye ftbfs help sid
X-Debian-PR-Source: libsis-base-java
Am 28.10.20 um 16:01 schrieb olivier sallou:
[...]
*dumb* patch would be to simply remove those tests from code...
Either this or you can keep the override for dh_auto_test-arch empty.
The test creates a broken symlink but then FileUtils.deleteDirectory
fails to delete the file, obviously because it is not a directory but
I'm not sure how it really handles symlinks within directories. See also
[1]. Probably upstream should switch to the java.nio.file API (they
still use java.io.File), test for the existence of symlinks and then try
File.delete instead of FileUtils.deleteDirectory first. Not tested, just
a guess.
Markus
[1] https://issues.apache.org/jira/browse/IO-576
___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
- End forwarded message -
--- org/apache/commons/io/file/PathUtils.java.orig 2020-01-22 15:10:16.0 +0100
+++ org/apache/commons/io/file/PathUtils.java 2020-10-28 21:32:24.874024999 +0100
@@ -358,7 +358,8 @@
}
final PathCounters pathCounts = Counters.longPathCounters();
final boolean exists = Files.exists(file, LinkOption.NOFOLLOW_LINKS);
-final long size = exists ? Files.size(file) : 0;
+final boolean existsFollowLink = Files.exists(file);
+final long size = existsFollowLink ? Files.size(file) : 0;
if (overrideReadOnly(options) && exists) {
setReadOnly(file, false, LinkOption.NOFOLLOW_LINKS);
}
smime.p7s
Description: S/MIME Cryptographic Signature
Bug#970752: Subject: open-vm-tools: ConditionVirtualization=vmware was not met
Hi, The following condition caused the failure: ConditionVirtualization=vmware was not met After commenting it out vmtoolsd started successfully. For what it's worth, the same condition fails in VMware vmplayer. please run systemd-detect-virt and show the output, then install systemd from buster-backports and run it again and see if it makes a difference. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#969926: glibc: Parsing of /etc/gshadow can return bad pointers causing segfaults in applications
Hi, This has already been reported, Florian will work on a backport, as it is not straightforward to backport it to buster due to the usage of private symbols. Thanks! As it was flagged security in the upstream bugtracker, I'm doing the same here. The bug is actually tagged as security- in the upstream bug tracker, which means it has been reviewed from the security point of view, and hasn't been considered as a security issue. oh well, I've missed that - in the middle of the night. Sorry for the noise, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#969926: glibc: Parsing of /etc/gshadow can return bad pointers causing segfaults in applications
Source: glibc Version: 2.28-10 Severity: serious Tags: security upstream patch X-Debbugs-Cc: Debian Security Team Hi, we are running into the bug https://sourceware.org/bugzilla/show_bug.cgi?id=20338 causing systemd-sysusers to segfault. Patch is available in the linked bug report. As it was flagged security in the upstream bugtracker, I'm doing the same here. A fix in buster would be appreciated. Thanks a lot, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#968052: O: pmacct -- promiscuous mode traffic accountant
Package: wnpp Severity: normal Hi! I intend to orphan the pmacct package. Unfortunately I don't have the time to maintain it properly anymore. There are various new daemons and features that should be enabled and properly supported, otherwise the package is hopefully in a still working shape. The package description is: pmacct is a tool designed to gather traffic information (bytes and number of packets) by listening on a promiscuous interface or for Netflow data, which may facilitate billing, bandwidth management, traffic analysis, or creating usage graphs. . Data can be stored in memory and queried, displayed directly, or written to a database; storage methods are quite flexible and may aggregate totals or keep them separate. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#967897: debspawn: install lintian after build
Package: debspawn Version: 0.4.0-1 Severity: important Hi, first: thanks a lot for debspawn, works very well for me! I've found one issue that might result in FTBFS after uploading packages build with debspawn b --lintian: lintian is being installed before the package was built - with the result of having all lintian dependencies in the build environment. And lintian brings lots of dependencies, mainly perl modules. So your package will build fine, even one of those packages is missing in Build-Deps. With the result that the package will FTBFS on the buildds. Please install lintian after the package was sucessfully built, before running it. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#967856: mod-gearman: keep out of testging
Source: mod-gearman Version: 1.5.5-1+b9 Severity: serious With mod gearman not being needed for icinga anymore, it might make sense to remove it. Please only close this bug if you are willing to adopt the package. (its being orpahened!) If this does not happen before the release of bullseye, I'll remove the package. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#967855: O: mod-gearman -- Worker agent for Mod-Gearman
Package: wnpp Severity: normal I intend to orphan the mod-gearman package. The package description is: The worker agent for Mod-Gearman connects to a Gearman job server, runs active Icinga/Nagios service checks, and return the results. . The worker can ask for any available check, or it can be bound to specific hostgroups or servicegroups. Unfortunately (due to a broken debian/watch file) the package is also pretty outdated. As it is not needed for current icinga versions, I also don't have any usage for it anymore and I it might make sense to remove it. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#967854: O: gimp-plugin-registry -- repository of optional extensions for GIMP
end these into a contrast enhanced image. * ez-perspective: EZ Perspective: Specialized tool for easily correcting or changing perspective. * fix-ca (3.0.2): Fix-CA Corrects chromatic aberration in photos * gimp-fx-foundry (r111): GIMP FX Foundry Probably the largest script collection available for The GIMP. * gimp-mask: GIMP-Mask: Do and undo several popular image masking (that is, censoring) methods (CP, FL, Q0, MEKO). * hdroberts-tone-adjust (May 24, 2010): Warming and Cooling Filters Warm or cool an image using one of several methods: Wratten, Roy's Warm, Brauer's Warm, Pasty Cadaveric Look * layer-effects (4/12/2012): Layer-Effects This is a series of scripts that implement various layer effects: Drop Shadow, Inner Shadow, Outer Glow, Inner Glow, Bevel and Emboss, Satin, Color Overlay, Gradient Overlay, Pattern Overlay, Stroke * lqr (0.7.1): Liquid Rescale Content-aware rescaling. Keeps the features of the image while rescaling along a single direction. * openraster (20110529-1d32622): OpenRaster load/save handler OpenRaster is an effort by the Create project[1] to offer a standardized and open interchange format for raster-based applications. This plugin allows one to load and save files in the OpenRaster format. * planet-render (1-2): Planet Render Creates a planet. Color, size and sun orientation can be set. * resynthesizer (2.0.3): Resynthesizer Gimp plugin for texture synthesis This gimp plugin takes samples of textures, and synthesizes larger textures from them. It can be used to extend textures (including making tileable textures), remove objects from textures, and make themed images. * safe-for-web (0.29.0): Save for Web Allows to experiment with various popular web format options. It shows an automatically updated preview and file size statistics. * separate+ (0.5.8): Separate+ Separate+ is a plug-in that generates color separations from an RGB image, proofs CMYK colors on the monitor and exports the CMYK TIFF file. * smart-seperate-sharpen (2.8): Smart Seperate Sharpening This script implements a new version of smart sharpening (redux) combined with separate sharpen to give better results. You can find more about Smart Sharpening at http://www.gimpguru.org/Tutorials/SmartSharpening2/ * streak (0.6): Streak-Camera simulation A streak camera images an object through a slit - thus getting a "one dimensional image". This image is propagated along the second dimension of the image plane at a constant speed. The result is a picture of the time dependency of the object. * traditional-orton: Traditional Orton: This is an effect invented by Michael Orton in the 1990s, which consists of taking two copies of an image, one blurred, and one sharp, and mixing them to produce an image with a dreamy quality. It is especially well suited to landscape and flower photography. * wavelet-denoise (0.3.1): Wavelet Denoise The wavelet denoise plugin is a tool to selectively reduce noise in individual channels of an image with optional RGB<->YCbCr conversion. It has a user interface to adjust the amount of denoising applied. The wavelet nature of the algorithm makes the processing quite fast. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
