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"
. . . . . yes > snmp_agent . . . . . yes > statsd . . . . . . . yes > swap . . . . . . . . yes > synproxy . . . . . . yes > sysevent. . . . . . . yes > syslog . . . . . . . yes > table . . . . . . . . yes > tail_csv . . . . . . yes > tail . . . . . . . . yes > tape . . . . . . . . no (disabled on command line) > target_notification . yes > target_replace . . . yes > target_scale . . . . yes > target_set . . . . . yes > target_v5upgrade . . yes > tcpconns . . . . . . yes > teamspeak2 . . . . . yes > ted . . . . . . . . . yes > thermal . . . . . . . yes > threshold . . . . . . yes > tokyotyrant . . . . . no (disabled on command line) > turbostat . . . . . . no (disabled on command line) > ubi . . . . . . . . . yes > unixsock . . . . . . yes > uptime . . . . . . . yes > users . . . . . . . . yes > uuid . . . . . . . . yes > varnish . . . . . . . no (disabled on command line) > virt . . . . . . . . yes > vmem . . . . . . . . yes > vserver . . . . . . . yes > wireless . . . . . . yes > write_graphite . . . yes > write_http . . . . . yes > write_influxdb_udp. . yes > write_kafka . . . . . yes > write_log . . . . . . yes > write_mongodb . . . . yes > write_prometheus. . . yes > write_redis . . . . . yes > write_riemann . . . . yes > write_sensu . . . . . yes > write_stackdriver . . yes > write_syslog . . . . yes > write_tsdb . . . . . yes > xencpu . . . . . . . yes > xmms . . . . . . . . no (disabled on command line) > zfs_arc . . . . . . . yes > zone . . . . . . . . no (disabled on command line) > zookeeper . . . . . . yes > > configure: error: "Some plugins are missing dependencies - see the > summary above for details" > > Cheers -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
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#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#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#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
Package: unattended-upgrades Version: 2.8 Severity: important hi, unattended upgrades is regularly eating 100% CPU here, seems to be stuck in a loop while trying to find non-existing file (yes, they can't exist as puppet dropped some bad sources.list lines into my config, but that shouldn't break u-a). [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_binary-all_Packages.lzma", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_binary-all_Packages.gz", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_binary-all_Packages.lz4", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_binary-all_Packages.zst", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_binary-all_Packages.uncompressed", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_i18n_Translation-en", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_i18n_Translation-en.xz", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_i18n_Translation-en.bz2", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_i18n_Translation-en.lzma", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_i18n_Translation-en.gz", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_i18n_Translation-en.lz4", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_i18n_Translation-en.zst", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_main_i18n_Translation-en.uncompressed", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_contrib_binary-amd64_Packages", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_contrib_binary-amd64_Packages.xz", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_contrib_binary-amd64_Packages.bz2", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_contrib_binary-amd64_Packages.lzma", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_contrib_binary-amd64_Packages.gz", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_contrib_binary-amd64_Packages.lz4", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_contrib_binary-amd64_Packages.zst", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_contrib_binary-amd64_Packages.uncompressed", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_contrib_binary-i386_Packages", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_sid-backports_contrib_binary-i386_Packages.xz", 0x7ffdc3ac3ca0, 0) = -1 ENOENT (No such file or directory) [pid 1391788] newfstatat(AT_FDCWD, "/var/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,
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#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
22e3 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 --Type for more, q to quit, c to continue without paging--c #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) Thanks, Girish Internal Use - Confidential -Original Message- From: Bernd Zeimetz Sent: Monday, March 7, 2022 9:53 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, 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#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#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#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#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#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#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
ig/GIMP/2.10/tool-options/gimp-bucket-fill-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-gradient-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-pencil-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-paintbrush-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-eraser-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-airbrush-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-ink-tool' > Parsing > '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-mypaint-brush-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-clone-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-heal-tool' > Parsing > '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-perspective-clone-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-convolve-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-smudge-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-dodge-burn-tool' > Parsing > '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-brightness-contrast-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-threshold-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-levels-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-curves-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-offset-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-gegl-tool' > Parsing '/home/calestyo/.config/GIMP/2.10/tool-options/gimp-operation-tool' > INIT: gimp_real_restore > Parsing '/home/calestyo/.config/GIMP/2.10/pluginrc' > Querying plug-in: '/usr/lib/gimp/2.0/plug-ins/gmic_gimp' > malloc_consolidate(): invalid chunk size > ^Cgimp: terminated: Interrupt > > > > > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) > Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
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#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#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#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
Bug#967852: gimp-plugin-registry: keep out of testing
Package: gimp-plugin-registry Version: 9.20180625+nmu1 Severity: serious Hi, this package should be kept out of testing until it is adopted by somebody who is willing to fix all the plugins to work with current gimp versions, checks if there are new/active upstreams, updates the package and packaging and so on... If this does not happen before the release of bullseye, I'll ask for removal of 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#964031: src:viking: New version 1.8 available; offer to help maintain viking
Hi, thanks a lot! Bernd On 2020-07-02 22:13, Paul Gevers wrote: Hi Bernd, On 30-06-2020 22:52, Bernd Zeimetz wrote: so you should have access - please just do whatever is necessary if you have the time. Done. Paul -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#964051: RM: python-cjson -- ROM; python3 support missing, upstream MIA since a long time
Package: ftp.debian.org Severity: normal 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#964031: src:viking: New version 1.8 available; offer to help maintain viking
Hi Paul, > I'm a user of viking and today I learned viking is no longer in bullseye > due to build dependency issues. However, a new upstream version is > available and bug #947541 points at a patch (that seems to be applied on > top of 1.8 by the looks of the date). > > Is there anything blocking updating viking such that it can be part of > bullseye again? If it's merrily time, I am willing to help maintain viking. basically: missing time is blocking it. Packaging is in the Debian group on Salsa: https://salsa.debian.org/debian/viking so you should have access - please just do whatever is necessary if you have the time. 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#937645: python-cjson: Python2 removal in sid/bullseye
On 6/30/20 10:41 PM, Moritz Mühlenhoff wrote: > There's no movement on https://github.com/AGProjects/python-cjson/issues/6 > and at this point there are no reverse dependencies left, let's remove it? yes, good plan - I've filed a ROM removal bug. 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#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking
On 6/28/20 10:58 PM, Lucas Nussbaum wrote: > Well, I think that it would a good thing for Debian to enforce some > consistency on Debian images for clouds and software that require > VM images, at least about where to find information about such images, > and where to report problems. > > And I don't think that pointing to github for our tooling, and for bug > reporting, is really an acceptable solution for something that is > officially endorsed by Debian. Official *Docker* images come from https://github.com/docker-library/official-images It might be possible to pull git repositories from the outside of git hub in there, though, but I doubt it is. At least you'll have to use github pull requests. Of course you are free to run your own registry even under a debian.org domain and provide official Debian images for docker there, but as long as you want to have them in the docker hub, I think the current practice is just fine. And: its an image from DOCKER, maintained by Debian developers - its not an image from DEBIAN. It says 'Docker official images', not 'Debian official images'. To be honest, I fail to understand why this needs discussion at all. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#961481: ceph: Protocol incompatibility between armhf and amd64
Hi Ard, On 6/18/20 1:28 PM, Ard van Breemen wrote: >> The biggest issue in maintaining ceph is to make it build on 32 bit >> architectures. This seems not to be supported at all by upstream anymore. > > First of all, I don't know what your goal is to support 32 bit. Debian supports it, so it should be supported if possible. > I do have a goal: I have loads of armhf machines and only so many amd64 > machines that do not even have enough memory to properly support ceph > and being able to do something (as the MON uses 1GB of memory alone). > I have multiple sites with this situation, and for the foreseeable > future, we will still be building infrastructure on armhf. Getting a > decent AMD64 setup in any location is additional and probably > unnecessary costs. You'll either need to migrate to amd64 (or arm/whatever64) or pay somebody to fix ceph at upstream. > I think the stance of the ceph community in this is: as long as nobody > sends in patches they are not going to care. And they can't support it > themselves because they have a totally different target (clouds). Its the same: they support what they get paid for or what is needed. People rarely use 32bit these days. Even on cheap arm devices 64bit is the way to go. > I am willing to host the armhf releases and maybe the i386 releases on > my server, that way there will be 32 bit releases but not official ones. Doesn't matter, hosting is not the issue here. > But I do want your involvement. You can want that, but you won't get it. Send patches or people who will do the work. I'll happily accept patches, or even better, but reports with links to patches at upstream. > I've been trying to compile it for a time, using sources from ceph and > from proxmox, until I realised ceph nautilus is in backports. And it > worked. > So at least I want your guidance on how you build these... For now I've > used an armhf machine, and I needed to limit the number of threads to 1 > due to c++ compiler needing more than 1GB of RAM to compile a single > source. Upstream has a detailed readme, or you can use the basic way to build a debian package using dpkg-buildpackage, or similar tools. > Not only do I want to make support complete so I can use hardware, I > also think it's just bad programming not to use explicit sizes. And I am > also on the verge of investing in amd64 clusters, I don't want it to > depend on code that's depending on a lot of features. > Anyway: I don't know how you build and test on non amd64 systems, do you > also use armhf, or do you use a cross compile environment? You can just build it, if you are using the Debian source. Otherwise you'll need a lot of patches to make it build, and even more to fix those various 32bit related bugs. 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#960065: updated MP
Hi, Abandoned https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/merge_requests/6 and added https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/merge_requests/7 I'll merge and upload as soon as open-vm-tools passed the NEW queue. 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#962637: node-left-pad -- String left-pad
Hi, > This is the infamous left-pad package used to left-pad strings. > The project is archived and this tool is now deprecated. The recommendation > is to use String.prototype.padStart() instead. However, due to the > ubiquity of this package in other node projects it is useful to have this > packaged. Please don't package already deprecated things in Debian - if you reallz need it for compat reasons, make it a wrapper around String.prototype.padStart(). 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#961680: please provide a collection3 package
Hi, > The collectd-core package includes the collection3 viewer for the collectd > statistics that are gathered in the RRDs in the examples subdir. It would > be great if the Debian packaging built this as a separately installable > package so that it updates along with collectd. hmm, I'd assume that you have the collectd-core package on your webserver - so why no run collection3 from the examples directory? I don't think that adding a package for a tool that is - imho - pretty much deprecated these days is not worth the work and disk space. 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#961481: ceph: Protocol incompatibility between armhf and amd64
Hi,
sorry for not replying inline, but I thought I'd just share my general
opinion on this.
The biggest issue in maintaining ceph is to make it build on 32 bit
architectures. This seems not to be supported at all by upstream anymore.
Between 14.2.7 and 14.2.9 I had a longer look into the issue and started
to fix some issues, for example the parsing of config options does
pretty broken things if the default for the option does not fit into a
32bit integer. Fixing this properly brought me to various other places
where size_t is being used in the code, but actually an (at least)
uint64_t is being required.
Fedora already removed ceph for all 32bit architectures with a "not
supported by upstream anymore", but I was not able to find an official
statement from ceph upstream.
Also unfortunately I did not yet find the time to collect my findings
and send them to the ceph devel mailinglist, but I'd assume that they
just don't want to support 32bit anymore, otherwise they'd test it properly.
As the work to fix this is properly seems to be a rather long task, I
definitely won't do this. But I also don't want to upload maybe-working
binaries to Debian anymore. So unless somebody fixes and tests ceph for
32bit (or does this for Debian, also fine for me - running the
regression test suite is possible with enough resources and some
hardware), I will remove all 32bit architectures with the next upload.
I guess those are not the news you wanted to hear, but so fard thats the
situation.
Bernd
On 5/27/20 10:54 AM, Ard van Breemen wrote:
> Hi,
>
> On Tue, May 26, 2020 at 06:35:20PM +0200, Val Lorentz wrote:
>> Thanks for the tip.
>>
>> I just tried downgrading an OSD (armhf) and a monitor (amd64) to
>> 14.2.7-1~bpo10+1 using http://snapshot.debian.org/ ; but they are still
>> unable to communicate ("failed decoding of frame header:
>> buffer::bad_alloc").
>>
>> So this might be a different issue, although related.
>
> Well, 14.2.7-~bpo something did work on my armhf osd cluster,
> with 2 mons running on armhf, and one on proxmox pve 6 running
> ceph 14.2.8 .
> What Already did not work was OSD's on AMD64 working together
> with a 2xarmhf and 1xamd64 mon setup.
> I had a lot of problems getting it to work at all, but I thought
> it was just my lack of knowledge at that time. 99% of the
> problems is with setting up the correct secrets, or in other
> words, the handling of the "keyrings". Even between amd64 and
> amd64 this has been buggy if I look at the release notes.
> Specifically 14.2.6 to 14.2.7 I think.
> I assume bugs are in authentication, because as long as I did not
> reboot the amd64 it works.
> The daemons authenticate using the secrets, and the secret gives
> an authentication ticket.
>
> Anyway: the most simple test is to install a system, rsync
> /etc/ceph and type in ceph status. It either works (on 32 bits,
> fix the timeout in the python script, because if you don't it
> won't work at all) or it doesn't return at all.
>
> I will test if it's also the case with armhf ceph cli client to a
> amd64 cluster. I only have one working amd64 cluster though, and
> it has 2 fake OSD's, because amd64 clusters are too expensive to
> experiment with.
> I have to do some networking hacks though to connect the systems.
>
> Anyway: the kernel has no problem talking to either OSD types, so
> the kernel's protocol handling is implemented correctly, and
> cephx works between an rbd amd64 or armhf kernel client and armhf
> userspace.
> The rbd amd64 userspace utility however does not work at all. As
> far as I can see it can't get past authentication, but without
> any logs I am a bit riddled.
>
> By the way: the mgr dashboard modules is about 99% correct. The
> disk space is obviously calculated incorrectly.
>
> Regards,
> Ard
>
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#961201: ceph-common does not include /usr/bin/ceph-crush-location (but it should)
severity 961201 minor thanks > Starting ceph's osd via /etc/init.d/ceph fails, because the init script > refers to ceph-crush-location, does not find it and exits 2. The init script from the package does not call this command. Actually the command was removed from ceph in 2018. > Note: the manpage for this binary is included, the binary itself is > missing. I'll remove it. > This is tested on Devuan Beowulf, but any ceph operation also on systemd > based distros that require ceph-crush-location will fail. Doesn't exist, can't be required. I'd assume you've configured something that is not supported anymore. 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#960065: add the sdmp plugin
Hi Oliver, > This should be in an optional separate package. Attached is a patch for > the Debian scripts that would create this package. This has been used in > our internal testing. Note that there is an additional runtime > dependency on net-tools for netstat. please note that netstat is deprecated since at least 2011. Adding a new package requires to pass the NEW queue again, so I'll have to review the copyright file... will take a bit. 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#959149: kea-dhcp4-server: unable to open '/var/lib/lib/kea/kea-leases4.csv'
Package: kea-dhcp4-server Version: 1.7.5-1 Severity: serious Hi, after the upgrade kea fails to start with Apr 29 23:47:12 xxx kea-dhcp4[1606]: 2020-04-29 23:47:12.790 ERROR [kea-dhcp4.dhcp4/1606] DHCP4_CONFIG_LOAD_FAIL configuration error using file: /etc/kea/kea-dhcp4.conf, reason: Unable to open database: unable to open '/var/lib/lib/kea/kea-leases4.csv' Please note the extra 'lib/' in the path to the database. A symlink as workaround helped... 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#948375: buster-pu: package ceph/12.2.12+dfsg-1
Hi Julien, > That's kind of unreadable. We like to have the proposed diff directly > in the p-u bug, along with a description of the changes, what they fix, > what the risks are. how does a 48k lines diff as text help you? Its a mix of fixes for about 70 bugs (and 12.2.13 was released already, so >>100 bugs). Of course, you can read the diff, but you wouldn't be able to review it properly. > Pointers to more information elsewhere are not bad, > but they don't replace information that should be in the bug. In this > case the upstream changelog doesn't really provide much context on which > if any of the fixed issues are serious enough for us to want the update > in stable. https://docs.ceph.com/docs/master/releases/luminous/#v12-2-11-luminous has all the info. Including links to th ebugs and the discussion. Including various CVEs. It is a stable point release, like it is done for firefox and others. it is very well tested by upstream and I will definitely not start to pick single commit - I don't have the infrastructure to run the regression tests and that is done by upstream in a proper way. And I hope you also don't want to risk to ship something that slowly degrades stored data. >> - I've basically imported the changes the Ubuntu people have done in >> Ubuntu together with 12.2.12. So I assume this should work well, I did >> not yet test it properly as I want to wait for a reply from you. I'll >> prepare a backport of 14.2.x as soon as it migrates to testing anyway. >> > A reply from us tends to not be forthcoming before the proposed changes > have been tested, so there's a bit of a chicken and egg issue. But I'm not wasting an enourmous amount of time if there is a chance that you say no anyway. >> - The issue with ceph is that upstream doesn't do QA for 32bit and our >> selection of unusual architectures. I don't know if it builds on all >> buildds without trying... >> > There should be porterboxes available for all our release architectures. I'll remove 32bit for bullseye, its way too broken to fix it properly anyway, and not supported by upstream anymore. It is really sad that Debian was not able to ship ceph in a proper state until now, the former maintainers had similar discussions with the release team and its even completely broken on arm64 in stable. Really sad about this, 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#956860: Aw: Re: Bug#956860: ceph 14.x packages lost init script
On 2020-04-16 12:06, to...@gmx.de wrote: Hi Bernd, thanks for your quick response. Â that won't happen, ceph startup is a big mix of systemd template units and targets these days. So why then are ceph upstream builds of 14.2.9 for ubuntu bionic and xenial still able to provide an init script? Please see https://download.ceph.com/debian-nautilus/pool/main/c/ceph/ceph-base_14.2.9-1bionic_arm64.deb for reference. Because somebody might be paid to test and maintain it. Feel free to use Ubuntu. 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#956860: ceph 14.x packages lost init script
hi, On 2020-04-16 01:56, Tobias Prousa wrote: ceph-base (or ceph) binary packages were supplying /etc/init.d/ceph, but beginning with 14.x versions neither of ceph binary packages seems to provide /etc/init.d/ceph any longer. Could you please consider to keep packaging a working init script file? that won't happen, ceph startup is a big mix of systemd template units and targets these days. 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#953346: open-vm-tools: consider raise process priority of vmtoolsd
Hi, After discussing this issue with upstream we came to the conclusion that reverting this is the best option as it is possible to start programs trough vmtoolsd and they would also run with a nice level of -20. Upstream will fix this issue in a sane way. I've reopened the bug. Sorry, Bernd On 3/9/20 7:13 AM, Aron Xu wrote: > On Mon, Mar 9, 2020 at 2:23 AM Bernd Zeimetz wrote: >> >> Hi Aron, >> >> which nice level do you suggest? -10? >> > > I'd suggest -20, since vmtoolsd does not consume a lot resources > itself while the highest priority would give it better chance to deal > with watchdog stuff. > > Regards, > Aron > -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#953760: check-service autopkgtest fails while parsing systemctl output
Hi, just uploaded. Sorry for the delay! Bernd On 3/28/20 8:36 AM, Michael Biebl wrote: > Hi Bernd > > On Fri, 13 Mar 2020 03:03:25 +0100 Michael Biebl wrote: >> >> the autopkgtest shipped by gpsd fails with the latest systemd v245 >> version: >> > > As autopkgtest results are used nowadays to gate testing migration, this > issue now blocks systemd from entering testing. Do you have any plans to > upload gpsd with a fix in the near future? > > Michael > -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F signature.asc Description: OpenPGP digital signature
Bug#948375: buster-pu: package ceph/12.2.12+dfsg-1
Hi release team! any news on this? There are various bugs in ceph in buster and there was 12.2.13 released in the meantime... Bernd On 1/7/20 11:37 PM, Bernd Zeimetz wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > > > Hi release-team! > > I have a bit complicated idea for a buster-pu: ceph. > Buster shipped with 12.2.11 and last April upstream released 12.2.12 as > bugfix release. As usual with ceph, the diff is *huge*, but it is a > bugfix-only release. So here are a few facts: > > - upstream changes: https://ceph.io/releases/v12-2-12-luminous-released/ > > - proposed diff: > > https://salsa.debian.org/ceph-team/ceph/compare/luminous%2Funstable...debian%2Fbuster > > - I've basically imported the changes the Ubuntu people have done in > Ubuntu together with 12.2.12. So I assume this should work well, I did > not yet test it properly as I want to wait for a reply from you. I'll > prepare a backport of 14.2.x as soon as it migrates to testing anyway. > > - The issue with ceph is that upstream doesn't do QA for 32bit and our > selection of unusual architectures. I don't know if it builds on all > buildds without trying... > > - 12.2.X is already EOL at ceph upstream I just took over the > maintenance of ceph, so... everything is late. Things should be better > for bullseye. > > - The packaging is not yet as close to the upstream packaging as I'd > like to have it. Upstream's packaging is very well tested and > supported, we should stick to that as far as possible. > > For bullseye we'll have the same question: Big updates from upstream as > their pointrelease. Target will probably be 15.2.X (Octopus), which is > not yet released, but I hope it will be before bullseye will go into > freeze. > > > So... whats your opinion on that? > > > 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#935156: ceph: Multiple mon deployment failure on arm64: ms_verfity_authorizer bad authorizer and crc check failure
Hi, > And ceph v12.2.13 has already cherry-picked this patch. > So please maintainer bump ceph luminous to v12.2.13+ to fix this issue. > And make ceph can work on arm64 buster. Thank you. I'd love to, but I did not yet get a reply from the release team on that :( Will poke them again. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
