Bug#1068945: ITP: rust-names -- generator for random names suitable for containers, projects, applications etc.
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: rust-names Version : 0.14.0 Upstream Contact: Fletcher Nichol * URL : https://crates.io/crates/names * License : MIT Programming Lang: Rust Description : generator for random names suitable for containers, projects, applications etc. A random name generator with names suitable for use in container instances, project names, application instances, etc. This is a dependency for zellij-utils, in turn a dependency that will be needed to package zellij.
Bug#1068726: ITP: rust-csv2svg -- Take a csv as input and outputs svg
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: rust-csv2svg Version : 0.2.1 Upstream Contact: dystroy * URL : https://crates.io/crates/csv2svg * License : MIT Programming Lang: Rust Description : Take a csv as input and outputs svg Build a SVG graph from a csv document. This is a dependency needed by glassbench, which comes the zellij dependency tree.
Bug#1055655: rebuild fails with node-typescript 4.9.5 in experimental
Control: close 1055655
Bug#1055655: rebuild fails with node-typescript 4.9.5 in experimental
Control: close 1055655 node-js-sdsl/4.1.4-3 Hi Paul, only now after rebuidling the package and coming to close the bug after noticing the issue is fixed did I notice your mail. Thanks for the fix. Best, Ananthu
Bug#983870: Picking up webdriver-manager packaging
Hi Joost, It seems that you are no longer intending to work on this. I, on the other hand, require webdriver manager for packaging lightnovel-crawler. So if you don't mind, can I pick this up? Best, Ananthu
Bug#1067029: closed by Thomas Lange (closing)
Dear Thomas, thanks for your your reply. My report was not about how to find donation info because I am looking for them. My intention was to improve Debian. I still recommend to add "Donations" as a term to the landing page. Doing a text search (CTRL+F) on that page for "Donation" has 0 hits. IMHO such an info should be obvious and not hidden behind a search engine or a "more" button. It is to important. But I am not the maintainer here. Of course I do accept your decision. I simply offered my point of view as a user. Kind Christian buhtz Am 17.03.2024 18:42 schrieb Debian Bug Tracking System: This is an automatic notification regarding your Bug report which was filed against the www.debian.org package: #1067029: www.debian.org: Landing page missing donation information It has been closed by Thomas Lange . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Thomas Lange by replying to this email.
Bug#1017720: nfs-common: No such file or directory
I've been looking for an explanation for a similar kind of failure. I
wonder if the core problem is the same as reported here:
https://bugzilla.opensuse.org/show_bug.cgi?id=1209457
Supposedly fixed by the patch posted to linux-nfs here (also attached
after extraction from the SuSE kernel build source RPM):
https://www.spinics.net/lists/linux-nfs/msg86343.html
And merged into the main-line kernel in 5.15.3, see the Changelog here
(specifically under commit "69e0be0efe53fb012f5db32bc328590745cf8f71"):
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.3
I would be interested to hear whether it makes any difference for the
issue reported in this Debian bug.
--KenFrom 255fc6efacf25d954a986ff058fd9899f322e7d1 Mon Sep 17 00:00:00 2001
From: Trond Myklebust
Date: Tue, 28 Sep 2021 11:15:53 -0400
Subject: [PATCH] NFS: Don't set NFS_INO_DATA_INVAL_DEFER and NFS_INO_INVALID_DATA
Git-commit: 488796ec1e39fb9194cc8175f770823d40fbf0ed
Patch-mainline: v5.16-rc1
References: stable-5.14.19
[ Upstream commit 488796ec1e39fb9194cc8175f770823d40fbf0ed ]
NFS_INO_DATA_INVAL_DEFER and NFS_INO_INVALID_DATA should be considered
mutually exclusive.
Fixes: 1c341b777501 ("NFS: Add deferred cache invalidation for close-to-open consistency violations")
Signed-off-by: Trond Myklebust
Tested-by: Benjamin Coddington
Reviewed-by: Benjamin Coddington
Signed-off-by: Sasha Levin
Acked-by: Takashi Iwai
---
fs/nfs/inode.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 6ea1bde33cb6..f9d3ad3acf11 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -210,10 +210,15 @@ void nfs_set_cache_invalid(struct inode *inode, unsigned long flags)
flags &= ~NFS_INO_INVALID_XATTR;
if (flags & NFS_INO_INVALID_DATA)
nfs_fscache_invalidate(inode);
- if (inode->i_mapping->nrpages == 0)
- flags &= ~(NFS_INO_INVALID_DATA|NFS_INO_DATA_INVAL_DEFER);
flags &= ~(NFS_INO_REVAL_PAGECACHE | NFS_INO_REVAL_FORCED);
+
nfsi->cache_validity |= flags;
+
+ if (inode->i_mapping->nrpages == 0)
+ nfsi->cache_validity &= ~(NFS_INO_INVALID_DATA |
+ NFS_INO_DATA_INVAL_DEFER);
+ else if (nfsi->cache_validity & NFS_INO_INVALID_DATA)
+ nfsi->cache_validity &= ~NFS_INO_DATA_INVAL_DEFER;
}
EXPORT_SYMBOL_GPL(nfs_set_cache_invalid);
--
2.26.2
Bug#921239:
I support this wish because of the low quality German translation of the current man page. Translating it is waste of ressources. It is also not clear where the translation comes from Upstream do not provide translations. It is obvious that the German man page was translated by a machine or a none native speaker. Kind
Bug#989775: OpenJPEG 2.5.2 fixes CVE-2021-3575
CVE-2021-3575 OpenJPEG 2.5.1 has been released https://groups.google.com/g/openjpeg/c/othStX49Yc8 and includes a fix https://github.com/uclouvain/openjpeg/pull/1509 for CVE-2021-3575. OpenJPEG 2.5.2 updates 2.5.1 with a minor bug fix. https://github.com/uclouvain/openjpeg/blob/v2.5.2/NEWS.md -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk
Bug#1064380: Aw: Re: Bug#1064380: RFS: jpeginfo/1.7.1-1 [Team] -- Prints information and tests integrity of JPEG/JFIF files
I'm not on your fucking team. And I said stop sending this fucking spam. Wannabee ninja motherfucker. On 2/28/2024 3:40 AM, xiao sheng wen (肖盛文) wrote: 在 2024/2/27 16:26, Bastian Germann 写道: The string " $Id: hash $" in "jpeginfo.h" file is almost not change in upstream. Even this string changed in upstream, it will not affect do deb package. "almost no change" is a change and dpkg-source will not create a source package for me. Do you meet this question? How to reproduce it? I don't understand it now. How are you able to create one from the released tarball? When upstream release a new version, do a tag on one commit, The "jpeginfo.h" file is not change in this tag version, is it? -- 肖盛文 xiao sheng wen https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统 Debian QA page:https://qa.debian.org/developer.php?login=atzlinux%40sina.com Debian salsa:https://salsa.debian.org/atzlinux-guest GnuPG Public Key: 0x00186602339240CB
Bug#989775: CVE-2021-3575
OpenJPEG 2.5.1 has been released https://groups.google.com/g/openjpeg/c/othStX49Yc8 and includes a fix https://github.com/uclouvain/openjpeg/pull/1509 for CVE-2021-3575. -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk
Bug#1064278: xkb-data: Spanish (Macintosh) Layout removed from the list of keyboard distributions
Package: xkb-data
Version: 2.38-2
Severity: normal
Dear Maintainer,
In trixie, upon upgrading xkb-data from 2.38-2 to 2.41-2 the Spanish
(Macintosh) Layout was removed from the list of distributions avaible
for selection, as per:
diff /usr/share/X11/xkb-2.41/symbols/es xkb-2_38/xkb/symbols/es
1c1
< // Modified for a real Spanish keyboard by Jon Tombs.
---
> // Keyboard layouts for Spain.
2a3
> // Modified for a real Spanish keyboard by Jon Tombs.
15c16
< key { [exclamdown, questiondown, dead_cedilla,
dead_ogonek ] };
---
> key { [exclamdown, questiondown, dead_cedilla,
dead_ogonek]};
44a46
> key { [ j, J, ezh, EZH ] };
48c50
< key { [ minus, underscore, dead_belowdot,
abovedot ]};
---
> key { [ minus, underscore, ellipsis, abovedot ]};
51c53
< // Spanish mapping (note R-H exchange)
---
> // Spanish Dvorak mapping (note R-H exchange)
133,138d134
< // Copied from macintosh_vndr/es
< partial alphanumeric_keys
< xkb_symbols "mac" {
< include "es"
< name[Group1]= "Spanish (Macintosh)";
< };
So i'm unable to select it.
Please add the layout back, it may have been removed due to changes
upstream.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
-- no debconf information
--
Julio C. Ortega
Bug#1064250: bbpager segfaults after a while of use
Package: bbpager
Version: 0.4.7-10
Severity: important
X-Debbugs-Cc: c.peter...@firemail.de
Dear Maintainer,
bbpager, wether started seperately or from /home/me/.fluxbox/startup segfaults
after a while of not being idle. This is true for the package from the
repository or one built from debian source.
(gdb):
#0 std::_List_iterator::operator++ (this=0x7fffdac0)
at /usr/include/c++/12/bits/stl_list.h:297
__tmp =
#1 0x55564ee6 in WMInterface::updateWindowList (this=0x555eb1c0)
at ./src/wminterface.cxx:84
it = 49
it_end = 49
pit =
pit_end = 0x2
window_vect = std::vector of length 3, capacity 3 = {25165838,
27262990, 29360132}
pwindow = 0x555b0b30
#2 0x555653fc in WMInterface::propertyNotifyEvent
(this=0x555eb1c0, event=0x7fffdbc0)
at ./src/wminterface.cxx:185
No locals.
#3 0x77e465b0 in bt::Application::run() () from /lib/x86_64-linux-
gnu/libbt.so.0
No symbol table info available.
#4 0xe9a2 in main (argc=1, argv=0x7fffe168) at
./src/main.cxx:112
bbpager = { = {}, resource =
0x555e5620, desktop_nr = 4,
wminterface = 0x555eb1c0, root_window = 963, pager_window_list =
std::__cxx11::list = {
[0] = 0x555b2950, [1] = 0x555b0b30}, desktop_window_list =
std::__cxx11::list = {
[0] = 0x555b0d40, [1] = 0x555ea1a0, [2] = 0x555ffa10,
[3] = 0x555ffc60},
wm_init = false, number_of_desktops = 4, current_desktop_nr = 2,
iargv = 0x0, iargc = 0,
row_last = 0, column_last = 0, _ewmh = 0x555b93d0,
xa_wm_delete_window = 338,
xa_wm_state = 389, current_screen_info = @0x55587340,
current_screen = 0,
frame_window = 0x555ef300, config = @0x7fffdda0}
i = 1
options = {withdrawn = false, decorated = false, shape = false, _argc =
1, _argv = 0x7fffe168,
_geometry = "", rc_filename = "", blackbox_rc_filename = "", app_name
= "/usr/bin/bbpager",
display_name = ""}
coredump:
Message: Process 140913 (bbpager) of user 1000 dumped core.
Stack trace of thread 140913:
#0 0x55f7f1d3c918
_ZNSt14_List_iteratorIP11PagerWindowEppEi (bbpager + 0x8918)
#1 0x55f7f1d44ee6 _ZN11WMInterface16updateWindowListEv
(bbpager + 0x10ee6)
#2 0x55f7f1d453fc
_ZN11WMInterface19propertyNotifyEventEPK14XPropertyEvent (bbpager + 0x113fc)
#3 0x7fabc86df5b0 _ZN2bt11Application3runEv (libbt.so.0 +
0x115b0)
#4 0x55f7f1d3e9a2 main (bbpager + 0xa9a2)
#5 0x7fabc824624a __libc_start_call_main (libc.so.6 +
0x2724a)
#6 0x7fabc8246305 __libc_start_main_impl (libc.so.6 +
0x27305)
#7 0x55f7f1d39791 _start (bbpager + 0x5791)
ELF object binary architecture: AMD x86-64
earlier strace (with the package from Debian):
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\24\0\6\0\303\3\0\0W\1\0\0!\0\0\0\0\0\0\0\1\0\0\0",
iov_len=24}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 24
poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1
7\n\1\0\0\0!\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}],
msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 36
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Die Ressource ist zur Zeit
nicht verfügbar)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Die Ressource ist zur Zeit
nicht verfügbar)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\16\0\2\0\3\0`\2", iov_len=8}, {iov_base=NULL,
iov_len=0}, {iov_base="", iov_len=0}], 3) = 8
poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\0\t8\n\3\0`\2\0\0\16\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3,
[{iov_base="\f\0\7\0\232\0\0\2\17\0\0\0\21\0\0\0\21\0\0\0\23\0\0\0\4\0\0\0\f\0\4\0"...,
iov_len=112}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 112
poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\f\09\n\232\0\0\2\0\0\0\0\23\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\f\0:\n\20\0\0\2$\0\21\0\2\0\4\0\1\0\0\0\0\0\0\0\0\0
Bug#1062827: RFP: pydevtool -- CLI dev tools powered by pydoit
I checked upstream README.md. I have no clue what this is. Can someone explain please? Am 03.02.2024 18:05 schrieb dpars...@debian.org: Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-pyt...@lists.debian.org Control: affects -1 src:scipy * Package name: pydevtool Version : 0.3.0 Upstream Contact: Eduardo Schettino * URL : https://github.com/pydoit/pydevtool * License : MIT Programming Lang: Python Description : CLI dev tools powered by pydoit Python dev tool. doit powered, integration with: - click and rich for custom CLI - linters: pycodestlye, pyflakes pydevtool is used by scipy's new dev.py developer script, which upstream now intends us to use for running scipy tests, see https://scipy.github.io/devdocs/dev/contributor/devpy_test.html Until pydevtool is available, our scipy build will have to invoke pytest directly, which means the debian test environment is discrepant from that expected by scipy developers until pydevtool becomes available. Uses doit, so should be maintained by the Debian Python Team alongside the doit package.
Bug#990343:
The problem is fixed in version 1.4.2.
Bug#1061974:
And also using "Package: backintime" do not work as expected. A message like this result in new bugs and not in closing an existing one. See this two examples: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061973 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061975 I am confused. Kind
Bug#1060305: libifd-cyberjack6: Package is out of date. 3 new hardware devices are not supported, which are already supported in upstream
Package: libifd-cyberjack6 Version: 3.99.5final.sp14-2 Severity: important Tags: a11y upstream X-Debbugs-Cc: s...@kernelport.com, siret...@tauware.de, kreuzritter2...@gmx.de The current version available in the Debain Stable's (12) repository is 3.99.5final.sp14-2 and 3.99.5final.sp14-2+b1 in unstable (SID). But the manufacturer's version is 3.99.5final.sp16. See here for the upstream deb package: https://support.reiner-sct.de/downloads/LINUX/V3.99.5_SP16/libifd- cyberjack6_3.99.5final.sp16_amd64_d12.deb And the source release: https://support.reiner-sct.de/downloads/LINUX/V3.99.5_SP16/pcsc- cyberjack-3.99.5final.SP16.tar.bz2 The changelog of this much newer version 3.99.5final.sp16 shows the following: Begin changelog: pcsc-cyberjack (3.99.5final.sp16) unstable; urgency=low * add REINER SCT cyberJack RFID standard EN -- Frank Neuber Thu, 26 Oct 2023 22:46:54 +0200 pcsc-cyberjack (3.99.5final.sp15) unstable; urgency=low * add REINER SCT cyberJack wave HUN * add REINER SCT cyberJack RFID komfort FON -- Frank Neuber Fri, 01 Oct 2021 08:11:04 + pcsc-cyberjack (3.99.5final.sp14) unstable; urgency=low * Update to the Reiner-SCT repository rev cyberJack@1454 -- Frank Neuber Mon, 02 Dec 2019 16:57:46 +0100 ### End changelog This means, that the devices: * REINER SCT cyberJack RFID standard EN * REINER SCT cyberJack wave HUN and * REINER SCT cyberJack RFID komfort FON are not supported in the current version of Debian. The device REINER SCT cyberJack RFID komfort FON device is for users with disabilities. As of now, all three devices are not supported by Debian 12 because this package is out of date. You should also read bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010675 It might be related to this bug #1010675, because the new upstream version ships as .bz2 file and in the other bug report has someone mentioned, that the old uscan filter does only search for .tar.gz files. But this is definitely not a minor bug, like the this other bug report claims, when you can't use these new three devices. The devices * REINER SCT cyberJack wave HUN and * REINER SCT cyberJack RFID komfort FON got a patch in upstream on Fri, 01 Oct 2021. Debian stable was released in June 10, 2023. So it's high time that the new version is added to Debian SID and a Debian backport version for Debian 12 or an update with the next Debian 12 point release is added. After all, this is about driver support and support for new hardware. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libifd-cyberjack6 depends on: ii libc6 2.36-9+deb12u3 ii libgcc-s1 12.2.0-14 ii libstdc++612.2.0-14 ii libusb-1.0-0 2:1.0.26-1 ii pcscd 1.9.9-2 libifd-cyberjack6 recommends no packages. Versions of packages libifd-cyberjack6 suggests: ii pcsc-tools 1.6.2-1 -- no debconf information changelog.Debian.gz Description: application/gzip
Bug#1058794: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Hi, Thank you very much for looking into this, it is much appreciated and you can go ahead with the upload. Ana On Thu, Jan 4, 2024, at 12:19 PM, Alexandre Detiste wrote: > Le jeu. 4 janv. 2024 à 07:48, Andreas Tille a écrit : >> > @Vincent: this one package "gtextfsm" is yours >> > do you green light an upload ? >> >> If you ask me the package is team maintained and a "Team upload" >> should be fine. > > Hi, I just try to follow the rules I agreed on last month. > > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#id2 > > | Team in Uploaders is a weak statement of collaboration. Help in > maintaining the package is appreciated, > | commits to the Git repository are freely welcomed, but before > uploading, please contact the Maintainer for the green light. > > There are not so many packages where "Uploader = DPT" to begin with, > so this might not well a well-known practice... > > So I'm formally asking Ana & PaN for approval to upload "lexicon" and > "dioptas". > (lexicon is a one line change, dioptas needs to package a new release) > > @Vincent: thanks. > > Greetings > > - > > Debian Python Team >dioptas (U) >gtextfsm (U) >lexicon (U) > > Ana Custura >lexicon > > Debian PaN Maintainers >dioptas
Bug#1059770: php-horde-core: Error "ReflectionMethod::__construct(): Argument #2 ($method) cannot be null"
Package: php-horde-core
Version: 2.31.18+debian0-2
Severity: important
Dear Maintainer,
When trying to create a new message with Horde IMP, an error is
displayed:
ValueError Object
(
[message:protected] => ReflectionMethod::__construct(): Argument #2
($method) cannot be null when argument #1 ($objectOrMethod) is an object
[string:Error:private] => ValueError: ReflectionMethod::__construct():
Argument #2 ($method) cannot be null when argument #1 ($objectOrMethod) is an
object in /usr/share/php/Horde/Core/Ajax/Application/Handler.php:91
Stack trace:
#0 /usr/share/php/Horde/Core/Ajax/Application/Handler.php(91):
ReflectionMethod->__construct()
#1 /usr/share/php/Horde/Core/Ajax/Application.php(271):
Horde_Core_Ajax_Application_Handler->has()
#2 /usr/share/php/Horde/Core/Ajax/Application.php(84):
Horde_Core_Ajax_Application->_getHandler()
#3 /usr/share/php/Horde/Core/Factory/Ajax.php(44):
Horde_Core_Ajax_Application->__construct()
#4 /usr/share/horde/imp/lib/Dynamic/Compose.php(239):
Horde_Core_Factory_Ajax->create()
#5 /usr/share/horde/imp/lib/Dynamic/Base.php(90): IMP_Dynamic_Compose->_init()
#6 /usr/share/horde/imp/dynamic.php(33): IMP_Dynamic_Base->__construct()
#7 {main}
[code:protected] => 0
[file:protected] => /usr/share/php/Horde/Core/Ajax/Application/Handler.php
[line:protected] => 91
[trace:Error:private] => Array
(
[0] => Array
(
[file] =>
/usr/share/php/Horde/Core/Ajax/Application/Handler.php
[line] => 91
[function] => __construct
[class] => ReflectionMethod
[type] => ->
)
[1] => Array
(
[file] => /usr/share/php/Horde/Core/Ajax/Application.php
[line] => 271
[function] => has
[class] => Horde_Core_Ajax_Application_Handler
[type] => ->
)
[2] => Array
(
[file] => /usr/share/php/Horde/Core/Ajax/Application.php
[line] => 84
[function] => _getHandler
[class] => Horde_Core_Ajax_Application
[type] => ->
)
[3] => Array
(
[file] => /usr/share/php/Horde/Core/Factory/Ajax.php
[line] => 44
[function] => __construct
[class] => Horde_Core_Ajax_Application
[type] => ->
)
[4] => Array
(
[file] => /usr/share/horde/imp/lib/Dynamic/Compose.php
[line] => 239
[function] => create
[class] => Horde_Core_Factory_Ajax
[type] => ->
)
[5] => Array
(
[file] => /usr/share/horde/imp/lib/Dynamic/Base.php
[line] => 90
[function] => _init
[class] => IMP_Dynamic_Compose
[type] => ->
)
[6] => Array
(
[file] => /usr/share/horde/imp/dynamic.php
[line] => 33
[function] => __construct
[class] => IMP_Dynamic_Base
[type] => ->
)
)
[previous:Error:private] =>
)
-- System Information:
Debian Release: 12.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-16-cloud-amd64 (SMP w/1 CPU thread; PREEMPT)
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 php-horde-core depends on:
ii libjs-excanvas 0.r4~git20090427.000-4
ii libjs-prototype 1.7.3-1
ii libjs-scriptaculous 1.9.0-3
ii php-common 2:93
ii php-horde-alarm 2.2.10-10
ii php-horde-auth 2.2.2-10
ii php-horde-autoloader2.1.2-11
ii php-horde-browser 2.0.16-5
ii php-horde-cache 2.5.5-11
ii php-horde-cli 2.3.0-6
ii php-horde-compress 2.2.4-3
ii php-horde-compress-fast 1.1.1-10
ii php-horde-controller2.0.5-5
ii php-horde-cssminify 1.0.4-6
ii php-horde-data 2.1.5-3
ii php-horde-date 2.4.1-9
ii php-horde-exception 2.0.8-10
ii php-horde-group 2.1.1-12
ii php-horde-hashtable 1.2.6-12
ii php-horde-history 2.3.6-11
ii php-horde-injector 2.0.5-12
ii php-horde-javascriptminify 1.1.5-7
ii php-horde-lock 2.1.4-7
ii php-horde-log
Bug#1059571: php-horde-tree: Declaration of Horde_Tree_Renderer_Jquerymobile must be compatible with Horde_Tree_Renderer_Base
Package: php-horde-tree Version: 2.0.5-6 Severity: important Dear Maintainer, While browsing Horde IMP with a mobile device, this error appears in the logs while trying to access IMAP folders: PHP Fatal error: Declaration of Horde_Tree_Renderer_Jquerymobile::_buildTree($node_id, $special) must be compatible with Horde_Tree_Renderer_Base::_buildTree($id) in /usr/share/php/Horde/Tree/Renderer/Jquerymobile.php on line 46 On the device, folders aren't displayed. Regards, -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-16-cloud-amd64 (SMP w/1 CPU thread; PREEMPT) 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 php-horde-tree depends on: ii php-common 2:93 ii php-horde-exception 2.0.8-10 ii php-horde-url2.2.6-9 ii php-horde-util 2.5.12-2 php-horde-tree recommends no packages. php-horde-tree suggests no packages. -- no debconf information
Bug#1055192: RFS: golang-github-apenella-go-ansible
On Sat, Dec 23, 2023 at 10:35:08PM +0530, Nilesh Patra wrote: > I finally got some time to look at this. From what I see, this is just a > library > package (and no binary) and this seems to be the final package you want to > get uploaded. > > Generally, all go library packages 'are'/'should be' present in Debian > because they are needed > for a target (binary) package which a user is interested in using. No-one > would be keen > on apt installing golang libraries and fiddling with GOPATH/GOROOT > rather than a simpler `go get -u` if they want to use them to write code. > > Hence, unless you have any target packages for which these libs are needed, I > do not see > a lot of use of getting this in. Let me know what you'd think. I *do* expect > your reponse on this. It looks that this has been a clear oversight from my side. *I do find this a very useful library* but as you mentioned, since go team convention does not include packaging libaries that are not needed by any binaries, there is probably no real value in getting this in. As such, please prune the corresponding repositories for the following: - golang-github-apenella-go-ansible - golang-github-apenella-go-common-utils - golang-github-sosedoff-ansible-vault-go > Thanks! > > Best, > Nilesh I feel sincerely sorry that an oversight from my side has ended up taking some of your busy schedule and I apologize for making you spend your time needlessly. I'll try my best to make sure such mishapas does not occur in the future, since it is not beneficial to anyone. And regardless of the outcome of this, thanks a lot for taking a look at the RFS. Best, Ananthu
Bug#1057885: mate-desktop-environment: File copy progress dialog shows wrong values on 32-bit Debian 12 MATE
Package: mate-desktop-environment Version: 1.26.0+1 Severity: normal X-Debbugs-Cc: m...@mrdictionary.net Dear Maintainer, I installed Debian 12 32-bit x86 from the netinst CD image and selected the MATE desktop environment. Within MATE (caja), when copying large files (e.g. over 100MB) between local folders or from an FTP remote host to a local drive, the file copy progress dialogue gives highly incorrect numbers. For example when copying the 200MB file PS3UPDAT.PUP (a Sony PS3 firmware update) to a USB stick, the file progress copy dialogue reported that the file was 881.6 PB in size (with a corresponding bizarre file transfer speed shown). The file seemed to copy normally however. Screenshot https://imgur.com/a/QDNjJtG To reproduce, install x86 32-bit Debian 12 from the current netinst image and copy a large file within caja after logging in. CPU: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz × 2 I've since reinstalled that system with 64-bit Debian 12 which doesn't show this bug. (The bug was also not present on 32-bit Debian 10; I was using up-to-date Debian 10 32-bit with MATE on that system up to October 2023.) Apologies: please disregard the system specs/package automatically attached as I am reporting from a different system from the one showing this bug. Regards. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mate-desktop-environment depends on: ii mate-desktop-environment-core 1.26.0+1 Versions of packages mate-desktop-environment recommends: ii atril 1.26.0-2+b1 ii desktop-base 12.0.6+nmu1~deb12u1 ii engrampa 1.26.0-1 ii eom 1.26.0-2 ii ffmpegthumbnailer 2.2.2+git20220218+dfsg-1+b1 ii libcanberra-pulse 0.30-10 ii mate-applet-brisk-menu0.6.2-2 ii mate-applets 1.26.1-1 ii mate-backgrounds 1.26.0-1 ii mate-calc 1.26.0-1 ii mate-media1.26.0-2 ii mate-notification-daemon 1.26.0-1+deb12u1 ii mate-power-manager1.26.0-2+deb12u1 ii mate-screensaver 1.26.1-1 ii mate-system-monitor 1.26.0-1 ii mate-user-guide 1.26.0-1 ii mate-utils1.26.0-1 ii pluma 1.26.0-1 Versions of packages mate-desktop-environment suggests: pn mail-reader | thunderbird pn mate-desktop-environment-extras ii network-manager-gnome1.30.0-2 pn x-www-browser | firefox -- no debconf information
Bug#1055930: ITP: yte -- YAML template engine with Python expressions
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: yte Version : 1.5.1 Upstream Author : Johannes K��ster * URL : https://github.com/yte-template-engine/yte * License : Expat Programming Lang: Python Description : YAML template engine with Python expressions Binary package names: python3-yte YTE is a template engine for YAML format that utilizes the YAML structure in combination with Python expressions for enabling to dynamically build YAML documents. . The key idea of YTE is to rely on the YAML structure to enable conditionals, loops and other arbitrary Python expressions to dynamically render YAML files. Python expressions are thereby declared by prepending them with a ? anywhere in the YAML. Any such value will be automatically evaluated by YTE, yielding plain YAML as a result. Importantly, YTE templates are still valid YAML files (for YAML, the ? expressions are just strings).
Bug#1055221: qemu-system is not compiled with pipewire audio support
> Personally I don't see value in pw support in qemu for now.
I didn't even know that qemu has introduced pipewire support in the
latest version.
I discovered it while trying to find an alternative for the audiodev
driver because of the issue I've experienced :
- pulse+vga , pulse+virgl , pulse without graphics -> audio stream
loses samples ( probably because of my low end hardware )
- the same with sdl
- alsa doesn't work for any reason
- dbus,jack not viable
- spice works perfectly but I have to use qxl driver for graphics that
suffers of a nasty bug on the host side that leads to an unrecoverable
crash of the guest graphics since a couple of months ("failed to
allocate VRAM BO"
:https://groups.google.com/g/linux.kernel/c/w7Ee-j9YonY ).
- pulse+spice the same as above
That's it.
Regards.
Bug#1055221: qemu-system is not compiled with pipewire audio support
Package: qemu-system Version: 1:8.1.2+ds-1 Severity: normal Dear Maintainer, Qemu mainline version 8.1.2 claims supporting pipewire audio as host audio driver , but debian packages is not compiled with that feature : > qemu-system-amd64 -audiodev help Available audio drivers: none alsa dbus jack oss pa sdl spice wav The changelog in the main site explains that pipewire support is enabled when the build system detects libpipewire installed on the system. Debian package should (build-)depends on libpipewire-*-dev to enable pipewire audio host support.
Bug#1055196: ITP: golang-github-apenella-go-common-utils -- Set of golang utilities
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-apenella-go-common-utils Version : 0.5.1-1 Upstream Author : Aleix Penella * URL : https://github.com/apenella/go-common-utils * License : Expat Programming Lang: Go Description : Set of golang utilities Go-common-utils repository contains a set of helpers or common functions which could be used such a library from any Golang project. . Common utils are organized in: . data: Functions to manipulate data structures. errors: An error interface implementation that could have a context and a list of wrapped errors. logger: Manages log messages (no longer maintained) networking: Functions for networking purpose. os: Functions to interactuate with the system. transformer/string: Functions to manipulate messages types: Custom types definition. This is a dependency for packaging go-ansble(#1055192).
Bug#1055195: ITP: golang-github-sosedoff-ansible-vault-go -- Go package to interact with Ansible Vault files
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-sosedoff-ansible-vault-go Version : 0.2.0-1 Upstream Author : Dan Sosedoff * URL : https://github.com/sosedoff/ansible-vault-go * License : Expat Programming Lang: Go Description : Go package to interact with Ansible Vault files Go package to read/write Ansible Vault secrets. This is a dependency for packaging go-ansible(#1055192).
Bug#1055192: ITP: golang-github-apenella-go-ansible -- Go package for executing ansible from Golang applications
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-apenella-go-ansible Version : 1.2.0-1 Upstream Author : Aleix Penella * URL : https://github.com/apenella/go-ansible * License : Expat Programming Lang: Go Description : Go package for executing ansible from Golang applications Go-ansible is a Go package that enables the execution of ansible-playbooks and ansible commands directly from Golang applications. It supports a wide range of options for each command, enabling smooth integration of Ansible functionality into projects. Debian currently does not seem to have any Ansible libaries for Golang. It would be extremely helpful to have this one in debian.
Bug#1055191: ITP: golang-github-apenella-go-ansible -- Go package for executing ansible from Golang applications
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-apenella-go-ansible Version : 1.2.0-1 Upstream Author : Aleix Penella * URL : https://github.com/apenella/go-ansible * License : Expat Programming Lang: Go Description : Go package for executing ansible from Golang applications Go-ansible is a Go package that enables the execution of ansible-playbooks and ansible commands directly from Golang applications. It supports a wide range of options for each command, enabling smooth integration of Ansible functionality into projects. Debian currently does not seem to have any Ansible libaries for Golang. It would be extremely helpful to have this one in debian.
Bug#1054136: ITP: node-prosemirror-tables -- enhances table support
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: node-prosemirror-tables Version : 1.3.4 Upstream Author : ProseMirror * URL : https://github.com/prosemirror/prosemirror-tables * License : Expat Programming Lang: JavaScript Description : enhances table support This module defines a schema extension to support tables with rowspan/colspan support, a custom selection class for cell selections in such a table, a plugin to manage such selections and enforce invariants on such tables, and a number of commands to work with tables. This package is a dependency required to package tiptap (#963902), a dependency used by gitlab. I intend to package this myself and maintain it as part of the javascript team. But as I hold no uploading rights, I will be needing a sponsor.
Bug#1053905: emacs-common-non-dfsg: not included among emacs 29 backported packages
Package: emacs-common-non-dfsg Version: 1:28.2+1-2 Severity: wishlist X-Debbugs-Cc: brandon.iriza...@gmail.com Dear Maintainer, I recently installed the Emacs 29 Bookworm backport; however, the documentation is still at version 28. I tried to install emacs-common-non-dfsg from backports, but no backport exists for it yet. This message is a simple request for the backport to be made. Thanks! - Brandon -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.31-antix.1-amd64-smp (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: runit (via /run/runit.stopit) Versions of packages emacs-common-non-dfsg depends on: ii dpkg 1.21.22 ii install-info 6.8-6+b1 emacs-common-non-dfsg recommends no packages. emacs-common-non-dfsg suggests no packages. -- no debconf information
Bug#985260:
Dear Francesco, can you please have a look at the latest upstream release of Back In Time. Upstream assumes the problem is solved. Can you confirm this? Kind Christian
Bug#1053858: ITP: node-tiptap-core -- headless rich text editor
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: node-tiptap-core Version : 2.1.12 Upstream Author : Tiptap GmbH * URL : https://tiptap.dev * License : Expat Programming Lang: JavaScript Description : headless rich text editor A headless, framework-agnostic and extendable rich text editor, based on ProseMirror. @tiptap/core is one of the dependencies used by gitlab. I am intending to maintain this as part of the javascript team. As I do not have uploading rights, I will be needing a sponspor.
Bug#1053520: RFS: golang-github-ozeidan-fuzzy-patricia/3.0.0-1
Dear Go team, I am looking for a sponsor for the package "golang-github-ozeidan-fuzzy-patricia". This package is a prerequisite for upcoming package "lazygit" (#908894). I pushed to our team's Salsa: https://salsa.debian.org/go-team/packages/golang-github-ozeidan-fuzzy-patricia Could you please review/sponsor this? Any kind of reviews and suggestions are appreciated
Bug#1053520: RFS: golang-github-ozeidan-fuzzy-patricia/3.0.0-1
Dear Go team, I am looking for a sponsor for the package "golang-github-ozeidan-fuzzy-patricia". This package is a prerequisite for upcoming package "lazygit" (#908894). I pushed to our team's Salsa: https://salsa.debian.org/go-team/packages/golang-github-ozeidan-fuzzy-patricia Could you please review/sponsor this? Any kind of reviews and suggestions are appreciated
Bug#1053520: ITP: golang-github-ozeidan-fuzzy-patricia -- A generic patricia trie (also called radix tree) implemented in Go (Golang).
Package: wnpp
Severity: wishlist
Owner: Ananthu C V
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-ozeidan-fuzzy-patricia
Version : 3.0.0
Upstream Author : Omar Zeidan
* URL : https://github.com/ozeidan/fuzzy-patricia.git
* License : Expat
Programming Lang: Go
Description : A generic patricia trie (also called radix tree)
implemented in Go (Golang).
A generic patricia trie (also called radix tree) implemented in Go (Golang).
The patricia trie as implemented in this library enables fast visiting of items
in some particular ways:
visit all items saved in the tree,
visit all items matching particular prefix (visit subtree), or
given a string, visit all items matching some prefix of that string.
[]byte type is used for keys, interface{} for values.
Trie is not thread safe. Synchronize the access yourself.
This package is in the dependency tree of Lazygit (#908894)
Bug#1037133:
Upstream responded to my questions about how this was fixed. They pointed to two PullRequests. https://github.com/owncloud/client/pull/10058 https://github.com/owncloud/client/pull/10065 My apologize. I'm not experienced enough to provide this as a patch to the current Debian version. Hope someone else can go this way. Kind Christian
Bug#1043124: zfs-dkms: module fails to build for Linux 6.5: None of the expected "bops->release()" interfaces were detected.
>(Completely unrelated, but browsing the issues it popped up that encryption is >very broken above 6.3, >and it has been somewhat broken on older kernels too; not one people lost their >data due to upgrading > beyond 6.3, so beware. "Encryption is very broken" seems too generic : it seems (to me) that the reported issue affects zfs "native" encryption , not luks with [(plain) zfs].
Bug#1051921: CVE-2023-1393 and TigerVNC
Package: tigervnc-standalone-server Version: 1.12.0+dfsg-8 RedHat have released updates to tigervnc to address CVE-2023-1393, e.g. https://access.redhat.com/errata/RHSA-2023:1592 but https://security-tracker.debian.org/tracker/CVE-2023-1393 does not mention tigervnc, and the latest version predates the CVE. I guess this relates to the binary package tigervnc-standalone-server but the fix might be needed in one or more of the other tigervnc binary packages. Upstream discussion at https://groups.google.com/g/tigervnc-users/c/5dq5O2OAoQI -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk
Bug#940319: [#940319 backintime] run test suite during build" : Request for maintainer feedback
Dear Jonathan, before investing my ressources into a solution can you please give me feedback about my proposal. Would this fit to your needs as DM and solve this bug? Kind Christian
Bug#1050203: bsd-mailx and selinux not co-operating
Package: bsd-mailx
Version: 8.1.2-0.20220412cvs-1
In follow-up to https://groups.google.com/g/linux.debian.user/c/vsYHlu728Ig
$ echo hello | mail -s test xx...@yyy.xyz <https://groups.google.com/>
2023-08-20 14:39:30 1qXieQ-000Bpa-1P 1qXieQ-000Bpa-1P no recipients
found in headers
Can't send mail: sendmail process failed with error code 1
however the same works fine when I put selinux in permissive state (no
warnings shown in audit/dmesg).
This is NOT a configuration issue but looks like selinux compatibility issue
A quick ltrace says
1qXia0-000BPb-0a Failed to create spool file
/var/spool/exim4//input//1qXia0-000BPb-0a-D: Permission denied
However there are no avc: messages for me to allow this through in my
selinux module
I even tried a custom policy
allow unconfined_t exim_spool_t:file { open read write create };
allow unconfined_t exim_spool_t:dir { open read write };
since /var/spool/exim4/input has exim_spool_dir set in it
ls -lZd
drwxr-x---. 2 Debian-exim Debian-exim system_u:object_r:exim_spool_t:s0
4096 Aug 22 00:10 /var/spool/exim4/input
I cant fine any booleans either ..
Many scripts including chkrootkit and tripwire are failing because mail
cannot send mails(becauses debian uses bsd-mailx as default)
--
Bhasker C V
Secure Mails:http://keys.gnupg.net/pks/lookup?op=get=0x4D05FEEC54E47413
Registered Linux User: #306349
Bug#1024501: Can we close this bug report?
Since it is evident that the Code of Conduct does not apply to the content of packages in this way (nor can it), and absent a clear policy permitting the removal of a package based on its content not being agreeable, can we close this bug report? Regards, -Roberto -- Roberto C. Sánchez
Bug#1043046:
Dear Armin, maybe you can save the time generating all the diagnostic output I asked for. I'm not absolute sure about this point but based on my research it is not possible to configure Back In Time (BIT) that way that it run "Every Day" and at boot. "Every Day" do result in a crontab line like "0 12 * * * cmd" (or another value for minute and hour). And as we know cron does not catch up jobs. My hypothesis is that you might have configured your Debian 11 machines explicit and without using BIT in a way that the described behavior is possible. You might have created an anacron job? The behavior you describe for Debian 12 is usual and the expected. There is nothing wrong with it. Kind Christian
Bug#1043046:
Please show the output of cat /etc/anacrontab Please also think hard about if you have configured something on your Debian 11 machines in the past? I'm not an expert in cron and anacron but in my understanding anacron do not start cron-jobs after their scheduled time (in hours in minutes). But I might be wrong. Maybe you manually configured your Debian 11 in the past that way and forgot it then? The upgrade to Debian 12 might overwrite your anacron/cron config with some default behavior? It is just an idea and I'll investigate further. It is also possible that there is a BIT bug.
Bug#1043046:
Dear Armin, thanks for reporting this. I'm member of the upstream maintainer team and not a Debian person. Please be aware that the current maintainer team is quit new to BIT and we are not yet familiar with all parts of the code and the behavior of BIT. But I'll try to assist you. I need to investigate the issue. Let me try to rephrase. You have a snapshot profile schedule "Every day". This results in a crontab line like "00 12 * * *" In Debian 11 (Bullseye, oldstable) the job was started at the first boot on each day and at a specified time (e.g. 12 o'clock). Correct? In Debian 12 (Bookworm, stable) the job do not start at boot but only at the specified time (e.g. 12 o'clock). This makes me wonder. I would assume that the Debian 12 behavior is "correct". I wonder why Debian 11 to run that job at boot when there is just a crontab line. On GNU Linux it is often that cron and anacron are somehow connected in several ways. Anacron is often involved while booting. Maybe something here changed between 11 and 12. I'll investigate that. On Debian 11 you run BIT 1.2.1-3 from the official Debian repository? Do you still have a working Debian 11 machine? Or did you updated all your machines? If you have Debian 11 and 12 available please provide the following information from both machines. If not Debian 12 only is also OK. Run "backintime --diagnostics" (only with BIT 1.3.4) in a terminal and give the output. Show roots crontab with "sudo crontab -l" (as user) or "crontab -l" (as root). Show the users crontab entries related to BIT with "crontab -l | grep backintime". How did you verify (via "journalctl" ?) if BIT was run or not? Maybe it run but decided nothing changed and there is no need for a new snapshot. Maybe you can provide the relevant syslog entries via journalctl --since "two weeks" | grep -i -e backintime -e boot Kind Christian
Bug#1042682: mongo-c-driver: FTBFS with Sphinx 7.1, docutils 0.20: make[3]: *** [src/libbson/doc/CMakeFiles/bson-html.dir/build.make:554: src/libbson/doc/html/api.html] Error 2
tags 1042682 + fixed-upstream pending thanks I have confirmed that this is fixed on the upstream master branch (commit ba5ab6de26a874d33b0abc3d2b46961a69380e7a seems like the most likely, but I did not bisect to confirm). When the upstream 1.25.0 release is made and then packaged for Debian, this fix will land in unstable. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Bug#1042428: qa.debian.org: Missing description for lintian warning tags (https://udd.debian.org/lintian/?packages=)
Dear Sebastiaan, thanks for reporting back. Am 28.07.2023 10:00 schrieb Sebastiaan Couwenberg: You can get the tag description from lintian-explain-tags: I know that. The bug report wasn't a support question but a feature request. The infos about the meaning of the tags need to be part of the linked website or somehow should linked there.
Bug#940319:
No response to my questions. I also asked on the debian python team mailing list. Without response I'll close the ticket on next iteration.
Bug#1040423: golang-yaml.v2: Build (tests) fail on 32-bit arch
Source: golang-yaml.v2
Version: 2.2.2-1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
In working on golang-yaml.v2 for an LTS update, I noticed that the build
fails on 32-bit arch (i386 and armhf, in this specific case).
https://salsa.debian.org/lts-team/packages/golang-yaml.v2/-/pipelines/548358
The specific failure is:
dh_auto_test -O--buildsystem=golang
cd obj-i686-linux-gnu && go test -vet=off -v -p 2 gopkg.in/yaml.v2
# gopkg.in/yaml.v2_test [gopkg.in/yaml.v2.test]
src/gopkg.in/yaml.v2/decode_test.go:134:33: constant -9223372036854775808
overflows int
FAILgopkg.in/yaml.v2 [build failed]
The source lines in that vicinity are:
}, {
"bin:
-0b1000",
map[string]interface{}{"bin": -9223372036854775808},
}, {
The source is the same in the latest version (on the debian/sid branch).
It seems like since the binary packages in this source package are
"Architecture: all" and that since the buildds selected to build
"Architecture: all" packages are 64-bit systems, that this failure is
not one that is encountered in practice for official Debian builds.
However, it might be good to detect when the build is running on a
32-bit system and either not run the tests, or conditionally patch the
source to exclude that particular overflow problem.
Regards,
- -Roberto
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEIYZ1DR4ae5UL01q7ldFmTdL1kUIFAmSlt6UACgkQldFmTdL1
kUK1aBAAxLomEtEKbZN0JlMA0U3BJVBdNpnD+jfyjeVfIJU//mQoWYQKv7JDWh2x
MCC+HmMZ7wgWNdzNR0/VE2BRqTamIYrgmF1gZ7QhiUIZ4UYt+TmNbyK6kb716trO
u4exL5v8r0d7yCdvHgm/GWElg5GlzXz66TEQTOswibRdluTrf6t8441lCZDTGCNE
XZq045nYHSa9NG1HgSbkTlAyzGwZnD2vgxLk27JIEoy8T3zVLP5495NmSkiuK+ig
tnBCyX65POpUa3WFy5XvyxNPjrfv1gNkBhQIRCvRDqt3f04rtNlXPfF0QghWZkC4
CQVGnNA8U1YyUwCQq+TQ/eAxRRVsgJ0Az+gkCtF5iitutnlurLL+QgcTuz6EfKKs
j9NUJzuY8gr71z2Bv+WWRcqwIVlK5+X83Tj3GwfJF8lbpiNib9vqJzo3lLqJU9TS
bw2BgkxZ9SsEZj1U/0NCca6fdHOeRHZpVDBWlB4vpKIwkzNNZVGciAQ1Z79YrFrl
xGqbXJQO2FdF+hh3gDfwlfaMsUMKaJz6hPoHIOC3NBKmCJi6R2hPF+HYmgpVb5cr
C/F9lgO8+N8V6azeU2LO+HDZjV1HQI6T9A2c5gp5NfE8ZNupzSnLC1OUdrJXY36J
t0afOewuYoBC8mGDDZ9TJMV+9DmCsyqwSK3KRANpP1EtsaKW/GQ=
=Waos
-END PGP SIGNATURE-
Bug#1035972: isc-dhcp EOL'ed
On Fri, Jun 16, 2023 at 10:12:22PM +0200, Moritz Muehlenhoff wrote: > On Fri, Jun 16, 2023 at 01:29:28PM -0400, Roberto C. Sánchez wrote: > > On Wed, May 17, 2023 at 10:50:34AM +0200, Moritz Muehlenhoff wrote: > > > > > > My take would be to mark it as unsupported after the trixie development > > > cycle > > > has started (this flags awareness, but has no impact on stable releases) > > > and then revisit the support situation before the trixie freeze (Kea > > > might be > > > a full replacment by then or maybe it turns out the patch support is > > > ensured > > > despite upstream's EOL) > > > > > Hi Moritz, > > > > Now that bookworm is out and (AFAICT) that the trixie development cycle > > has started, are able to go ahead with marking isc-dhcp as unsupported? > > Ultimately it's the maintainer(s) call, but sounds good to me. > Are you referring to the maintainer of debian-security-support, or the maintainer of isc-dhcp? Regards, -Roberto -- Roberto C. Sánchez
Bug#1040169: smplayer: Smplayer hangs when starting video
()] can't load config client.conf: No such file or directory [E][14041.464827] pw.conf | [ conf.c: 963 pw_conf_load_conf_for_context()] can't load default config client.conf: No such file or directory AO: [pulse] 44100Hz stereo 2ch float VO: [x11] 854x480 yuv420p [vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 8, serial: 29 [vo/x11/x11] Error code: 9, request code: e, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 8, serial: 2a [vo/x11/x11] Error code: 3, request code: 28, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 2b [vo/x11/x11] Error code: 3, request code: c, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 2d [vo/x11/x11] Error code: 3, request code: 12, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 2e [vo/x11/x11] Error code: 3, request code: 2, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 2f [vo/x11/x11] Error code: 3, request code: 2, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 30 [vo/x11/x11] Error code: 3, request code: 3, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 32 [vo/x11/x11] Error code: 3, request code: 8, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 33 [vo/x11/x11] Error code: 3, request code: 12, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 36 [vo/x11/x11] Error code: 3, request code: 3, minor code: 0 [vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 8, serial: 38 [vo/x11/x11] Error code: 9, request code: e, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 8, serial: 39 [vo/x11/x11] Error code: 3, request code: 28, minor code: 0 INFO_VIDEO_DSIZE=854x480 [vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 3f [vo/x11/x11] Error code: 9, request code: 82, minor code: 3 [vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter) [vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 40 vo/x11/x11] Error code: 9, request code: 82, minor code: 3 MPV_VERSION=mpv 0.35.1 INFO_VIDEO_WIDTH=854 INFO_VIDEO_HEIGHT=480 INFO_VIDEO_ASPECT=1.779167 INFO_VIDEO_FPS=29.954546 INFO_VIDEO_FORMAT=h264 INFO_VIDEO_CODEC=h264 (H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10) INFO_DEMUX_ROTATION= INFO_AUDIO_FORMAT=aac INFO_AUDIO_CODEC=aac (AAC (Advanced Audio Coding)) INFO_AUDIO_RATE=44100 INFO_AUDIO_NCH=2 INFO_LENGTH=20.664000 INFO_DEMUXER=lavf INFO_SEEKABLE=yes INFO_TITLES= INFO_CHAPTERS=0 INFO_TRACKS_COUNT=2 METADATA_TITLE= METADATA_ARTIST= METADATA_ALBUM= METADATA_GENRE= METADATA_DATE= METADATA_TRACK= METADATA_COPYRIGHT= INFO_MEDIA_TITLE=chris vs mikey.flv INFO_STREAM_PATH=/data/pics/videos/trever/chris vs mikey.flv [vo/x11] can't keep up! Waiting for XShm completion events... INFO_TRACK_0: video 1 '' '' yes INFO_TRACK_1: audio 1 '' '' yes Exiting... (Quit) = -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT) 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 smplayer depends on: ii libc6 2.36-9 ii libgcc-s1 12.2.0-14 ii libqt5core5a5.15.8+dfsg-11 ii libqt5dbus5 5.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5network5 5.15.8+dfsg-11 ii libqt5widgets5 5.15.8+dfsg-11 ii libqt5xml5 5.15.8+dfsg-11 ii libstdc++6 12.2.0-14 ii libx11-62:1.8.4-2+deb12u1 ii mplayer 2:1.5+svn38408-1 ii mpv 0.35.1-4 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages smplayer recommends: ii smplayer-l10n22.7.0~ds0-1 ii smplayer-themes 1:20.11.0-1 smplayer suggests no packages. -- no debconf information
Bug#1034867: smplayer always crashes in Debian 12
: 0x7febb40456b0, resourceid: 322, serial: 25 [vo/x11/x11] Error code: 9, request code: 37, minor code: 0 [W][83392.728217] pw.conf | [ conf.c: 939 try_load_conf()] can't load config client.conf: No such file or directory [E][83392.728272] pw.conf | [ conf.c: 963 pw_conf_load_conf_for_context()] can't load default config client.conf: No such file or directory AO: [pulse] 44100Hz mono 1ch float VO: [x11] 640x480 yuv420p [vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 8, serial: 29 [vo/x11/x11] Error code: 9, request code: e, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 8, serial: 2a [vo/x11/x11] Error code: 3, request code: 28, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 2b [vo/x11/x11] Error code: 3, request code: c, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 2d [vo/x11/x11] Error code: 3, request code: 12, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 2e [vo/x11/x11] Error code: 3, request code: 2, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 2f [vo/x11/x11] Error code: 3, request code: 2, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 30 [vo/x11/x11] Error code: 3, request code: 3, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 32 [vo/x11/x11] Error code: 3, request code: 8, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 33 [vo/x11/x11] Error code: 3, request code: 12, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 36 [vo/x11/x11] Error code: 3, request code: 3, minor code: 0 [vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 8, serial: 38 [vo/x11/x11] Error code: 9, request code: e, minor code: 0 [vo/x11/x11] X11 error: BadWindow (invalid Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 8, serial: 39 [vo/x11/x11] Error code: 3, request code: 28, minor code: 0 INFO_VIDEO_DSIZE=640x480 [vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 3f [vo/x11/x11] Error code: 9, request code: 82, minor code: 3 [vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter) [vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 40 [vo/x11/x11] Error code: 9, request code: 82, minor code: 3 MPV_VERSION=mpv 0.35.1 INFO_VIDEO_WIDTH=640 INFO_VIDEO_HEIGHT=480 INFO_VIDEO_ASPECT=1.33 INFO_VIDEO_FPS=30.00 INFO_VIDEO_FORMAT=vp8 INFO_VIDEO_CODEC=vp8 (On2 VP8) INFO_DEMUX_ROTATION= INFO_AUDIO_FORMAT=vorbis INFO_AUDIO_CODEC=vorbis (Vorbis) INFO_AUDIO_RATE=44100 INFO_AUDIO_NCH=1 INFO_LENGTH=421.60 INFO_DEMUXER=mkv INFO_SEEKABLE=yes INFO_TITLES= INFO_CHAPTERS=0 INFO_TRACKS_COUNT=2 METADATA_TITLE= METADATA_ARTIST= METADATA_ALBUM= METADATA_GENRE= METADATA_DATE= METADATA_TRACK= METADATA_COPYRIGHT= INFO_MEDIA_TITLE=trever and chris grappling part 3.webm INFO_STREAM_PATH=/data/pics/videos/trever/trever and chris grappling part 3.webm [vo/x11] can't keep up! Waiting for XShm completion events... INFO_TRACK_0: video 1 '' '' yes INFO_TRACK_1: audio 1 '' '' yes Exiting... (Quit) = End of log -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT) 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 smplayer depends on: ii libc6 2.36-9 ii libgcc-s1 12.2.0-14 ii libqt5core5a5.15.8+dfsg-11 ii libqt5dbus5 5.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5network5 5.15.8+dfsg-11 ii libqt5widgets5 5.15.8+dfsg-11 ii libqt5xml5 5.15.8+dfsg-11 ii libstdc++6 12.2.0-14 ii libx11-62:1.8.4-2+deb12u1 ii mpv 0.35.1-4 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages smplayer
Bug#1037998: Re : gost-crypto-dkms: module fails to build for Linux 6.3: error: implicit declaration of function 'crypto_tfm_ctx'
A google search of 'crypto_tfm_ctx' will show that the declaration of this function is located in 'include/crypto/algapi.h' in the linux 6.3.x series. So this is not complicated to solve : it's enough to add '#include ' into the magma_generic.c file , after the '#include ' line.
Bug#1035972: isc-dhcp EOL'ed
On Wed, May 17, 2023 at 10:50:34AM +0200, Moritz Muehlenhoff wrote: > > My take would be to mark it as unsupported after the trixie development cycle > has started (this flags awareness, but has no impact on stable releases) > and then revisit the support situation before the trixie freeze (Kea might be > a full replacment by then or maybe it turns out the patch support is ensured > despite upstream's EOL) > Hi Moritz, Now that bookworm is out and (AFAICT) that the trixie development cycle has started, are able to go ahead with marking isc-dhcp as unsupported? Regards, -Roberto -- Roberto C. Sánchez
Bug#1033829:
Hello, upstream maintainer here. I just want to inform. I don't know how Debian would handle this usually. The problem is fixed in upstream but unreleased. And this NMU tries to backport the fix. The next Debian release will come in around 2 years. Until then upstream will do a new release. Because of that and to my understanding there is no need anymore for that NMU and it can be removed from the system. Kind Christian
Bug#963849:
Dear Felix, can you please try to reproduce the problem with a newer release. Debian 12 now has 1.3.3 on board which is the latest upstream version. This version is also available via an Ubuntu PPA or directly via git clone. Feel free to ask if you need further help with installing. Kind Christian Buhtz
Bug#940319:
Hello, I try to learn here and that is why I asked. Do I get it right that the problem is that BIT do write and read from the users home folder. And that is not possible or not recommended on Debian's own build and test system. Am I right so far? To my knowledge as upstream maintainer this problem is not solved in upstream. So how do you do it on the Debian side? Does our BIT still write to Debians build system's users home folder or not? If not, how did you solved or worked around it? Thanks for your reply. Kind Christian Buhtz
Bug#1037456: RFP: Publii -- Static CMS for privacy-focused, SEO-optimized websites
Package: wnpp Severity: wishlist * Package name: Publii Version : 0.42.1 Upstream Contact: TidyCustoms * URL : https://getpublii.com * License : GPL-3.0 Programming Lang: JavaScript Description : Static CMS for privacy-focused, SEO-optimized websites. Unlike static-site generators that are often unwieldy and difficult to use, Publii provides an easy-to-understand UI much like server-based CMSs such as WordPress or Joomla!, where users can create posts and other site content, and style their site using a variety of built-in themes and options. Users can enjoy the benefits of a super-fast and secure static website, with all the convenience that a CMS provides. What makes Publii even more unique is that the app runs locally on your desktop rather than on the site's server. Available for Windows, Mac, Linux once the app has been installed you can create a site in minutes, even without internet access; since Publii is a desktop app you can create, update and modify your site offline, then upload the site changes to your server at the click of a button. Publii supports multiple upload options, including standard HTTP/HTTPS servers, Netlify, Amazon S3, GitHub Pages and Google Cloud or SFTP. -- Fernando C. Estrada
Bug#1036631: procps: [ps] segmentation fault ps:src/ps/display.c:75
Package: procps Version: 2:4.0.3-1 Severity: important Dear Maintainer, Running the command: # ps -wwlmfjAF leads to a partial listing along with a segmentation fault message: F S UID PIDPPIDPGID SID C PRI NI ADDR SZ WCHANRSS PSR STIME TTY TIME CMD 4 - root 1 0 1 1 0 - - - 42369 - 13784 - May10 ?00:26:24 /sbin/init 4 S root - - - - 0 597548028 - - - - 597547968 May10 - 00:26:24 - 1 - root 2 0 0 0 0 - - - 0 - 0 - May10 ?00:00:01 [kthreadd] Signal 11 (SEGV) caught by ps (4.0.3). 1 S root - - - - 0 60 0 - -ps:src/ps/display.c:75: please report this bug Segmentation fault Thanks for your time! C. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-8-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages procps depends on: ii init-system-helpers 1.65.2 ii libc62.36-9 ii libncursesw6 6.4-4 ii libproc2-0 2:4.0.3-1 ii libtinfo66.4-4 Versions of packages procps recommends: ii psmisc 23.6-1 procps suggests no packages. -- no debconf information
Bug#1036630: procps: unowned /usr/bin/ps on filesystem after upgrade to bookworm
Package: procps Version: 2:4.0.3-1 Severity: normal Dear Maintainer, After upgrading to bookworm there is an unowned /usr/bin/ps on the filesystem: # dpkg -S /usr/bin/ps dpkg-query: no path found matching pattern /usr/bin/ps There is also /bin/ps owned by procps: # dpkg -S /bin/ps procps: /bin/ps I wasn't able to find a /usr/bin/ps in on non-upgraded versions of Debian (only /bin/ps). Thanks for your efforts! C. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-8-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages procps depends on: ii init-system-helpers 1.65.2 ii libc62.36-9 ii libncursesw6 6.4-4 ii libproc2-0 2:4.0.3-1 ii libtinfo66.4-4 Versions of packages procps recommends: ii psmisc 23.6-1 procps suggests no packages. -- no debconf information
Bug#1033750: glib-networking libproxy fails
Package: glib-networking Version: 2.74.0-4 An issue with glib-networking causes GStreamer to abort streams. The "environment-libproxy" test from glib-networking-tests fails: "$ /usr/libexec/installed-tests/glib-networking/environment-libproxy # random seed: R02Scaabc7588fed22ec43e9b4138b1e372f 1..3 # Start of proxy tests # Start of environment tests ok 1 /proxy/environment/uri ok 2 /proxy/environment/socks # child process (/proxy/environment/ignore [2843]) exit status: 1 (error) # child process (/proxy/environment/ignore [2843]) stdout: "" # child process (/proxy/environment/ignore [2843]) stderr: "**\nGLib-Net:ERROR:../proxy/tests/common.c:192:test_proxy_ignore_common: assertion failed (proxies[0] == ignore_tests[i].proxy): (\" http://localhost:8080\; == \"direct://\")\n" ** GLib-Net:ERROR:../proxy/tests/environment.c:72:test_proxy_ignore: child process (/proxy/environment/ignore [2843]) failed unexpectedly Bail out! GLib-Net:ERROR:../proxy/tests/environment.c:72:test_proxy_ignore: child process (/proxy/environment/ignore [2843]) failed unexpectedly Aborted" Other tests complete without error. Debian GStreamer Bug Report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029618 GStreamer Bug Report: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1008 Architecture is powerpc. Running 32-bit userland on 64-bit kernel (6.0.0-6-powerpc64). Please let me know if I can provide any additional information.
Bug#1029618: GStreamer & glib-networking
I submitted a bug report to GStreamer about this issue. See https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1008. The GStreamer dev that helped out with my bug report found that the fault originates with libproxy in glib-networking. I ran the "environment-libproxy" test from glib-networking-tests and the result was: "$ /usr/libexec/installed-tests/glib-networking/environment-libproxy # random seed: R02S5b1dc0abfabd6b943121bee035468cde 1..3 # Start of proxy tests # Start of environment tests ok 1 /proxy/environment/uri ok 2 /proxy/environment/socks # child process (/proxy/environment/ignore [2067]) exit status: 1 (error) # child process (/proxy/environment/ignore [2067]) stdout: "" # child process (/proxy/environment/ignore [2067]) stderr: "**\nGLib-Net:ERROR:../proxy/tests/common.c:192:test_proxy_ignore_common: assertion failed (proxies[0] == ignore_tests[i].proxy): (\" http://localhost:8080\; == \"direct://\")\n" ** GLib-Net:ERROR:../proxy/tests/environment.c:72:test_proxy_ignore: child process (/proxy/environment/ignore [2067]) failed unexpectedly Bail out! GLib-Net:ERROR:../proxy/tests/environment.c:72:test_proxy_ignore: child process (/proxy/environment/ignore [2067]) failed unexpectedly Aborted" The rest of the glib-networking tests complete without errors. I will submit a bug report for glib-networking.
Bug#998105:
Do I see it correct that the commit was done but not yet uploaded? In result there should be a 1.3.3-5, right?
Bug#940319:
Dear Jonathan, what is the current situation about that issue? There where some new releases of Back In Time in Debian. Do you workaround that problem on your Debian side? And how? Kind Christian
Bug#859115:
Initial report based on a very old version of Back In Time. No feedback from reporter. Not able to reproduce.
Bug#1030726: marked as pending in intelrdfpmath
On Sun, Feb 12, 2023 at 09:32:55PM +0100, Stephen Kitt wrote: > > Given how late we are in the Bookworm release process, I’ve updated the > package description to mention that the library is only fully functional on > x86 architectures and ia64, but may be sufficient on others (for free42, it > is, at least on ARM), and haven’t restricted the architectures. That doesn’t > help on MIPS of course... > > Does libdfp work on MIPS? I got the impression it’s mainly supported on IBM > platforms (POWER and S/390) but perhaps that’s outdated! > After having talked with the developer who has implemented the new DFP-dependent features in libmongocrypt, it seems that portability (beyond amd64, arm64, ppc64el, and s390x) was in view for him. He did look at libdfp and concluded that it has some benefits over Intel DFP, but clearly building on MIPS family architectures is not achievable even with libdfp. As far as it being outdated, I am not certain but I think that upstream might have gone away from tagged/versioned releases and more to a model of "clone master and build from that". In that sense, it wouldn't be outdated, but the version in Debian would be about ~18 months out of date by that measure. In any event, upstream decided that rather than implement support for libdfp they would implement a switch to enable/disable building with Intel DFP (and thus the features that depend on it). That will allow for libmongocrypt to be able to build on all of the release architectures for bookworm. That new upstream release is due out today or tomorrow. The upstream CI gives sufficient coverage with testing that I am confident in all the 64-bit non-MIPS arches and I would be surprised if 32-bit ARM were an issue given the fairly robust upstream tests. In any event, thanks for leaving the architectures as they are for the moment. Regards, -Roberto -- Roberto C. Sánchez
Bug#1030726: marked as pending in intelrdfpmath
On Tue, Feb 07, 2023 at 08:44:50PM +0100, Stephen Kitt wrote: > > Yes, it seems like we’d really need a mips_macros.h implementation on MIPS. > That was my suspicion as well. > I enabled the test suite, and the result is basically that the library only > works fully on amd64, i386 (nearly, with two test failures out of ~120,000 > test cases), and ia64, which matches the architectures which the library > claims to support. On other architectures, the number of failures varies, up > to 12.5% of test cases on s390x. > > So really I should change the library to [amd64 i386 ia64]... > That's unfortunate. > Do you have a good way of validating whether the library is good enough for > libmongocrypt’s purposes on non-Intel architectures? > libmonogocrypt has a test suite, which we don't execute as part of the package build because of upstream's robust CI. However, we could definitely enable it and it would be sufficient to let us know that the library is adequate for what libmongocrypt needs. That said, upstream is quite close validating that libmongocrypt works with libdfp, so that might provide a near-term alternative if you decide that the best thing to do from a quality perspective is to restrict the architecture list of intelrdfpmath. Regards, -Roberto -- Roberto C. Sánchez
Bug#1030726: marked as pending in intelrdfpmath
And even with the build continuing on mips64el I see this: float128/dpml_ux_trig.c: In function '__dpml_bid_ux_degree_reduce__': float128/dpml_ux_trig.c:254:9: warning: implicit declaration of function 'UMULH' [-Wimplicit-f unction-declaration] 254 | UMULH((UX_FRACTION_DIGIT_TYPE) exponent, RECIP_TWELVE, k); | ^ When I build libmongocrypt against the resulting libintelrdfp-math, the libmongocrypt will then fail at link time: /usr/bin/ld: /home/roberto/mips64el/intelrdfpmath-2.0u2/debian/libintelrdfpmath-dev/usr/lib/mips64el-linux-gnuabi64/libbidgcc000.a(dpml_ux_ops_64.o): in function `__eval_pos_poly': (.text+0xe4): undefined reference to `UMULH' /usr/bin/ld: (.text+0xfc): undefined reference to `UMULH' /usr/bin/ld: (.text+0x144): undefined reference to `UMULH' /usr/bin/ld: (.text+0x160): undefined reference to `UMULH' /usr/bin/ld: (.text+0x168): undefined reference to `UMULH' /usr/bin/ld: /home/roberto/mips64el/intelrdfpmath-2.0u2/debian/libintelrdfpmath-dev/usr/lib/mips64el-linux-gnuabi64/libbidgcc000.a(dpml_ux_ops_64.o):(.text+0x17c): more undefined references to `UMULH' follow It might be better to simply declare intelrdfpmath '[!mipsel !mips64el]'. Sadly, my experience with Intel libraries (I maintained TBB in Debian for several years) is that they only put effort into the architectures that are important to them and that you can't assume that their code will work on other architectures. That could well be the case here. Regards, -Roberto -- Roberto C. Sánchez
Bug#1030726: marked as pending in intelrdfpmath
This patch is broken. I attempted a build and this is what happened:
(sid_mips64el-dchroot)roberto@eller:~/mips64el/intelrdfpmath-2.0u2$
dpkg-buildpackage
dpkg-buildpackage: info: source package intelrdfpmath
dpkg-buildpackage: info: source version 2.0u2-6
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Stephen Kitt
dpkg-buildpackage: info: host architecture mips64el
dpkg-source --before-build .
debian/rules clean
dh clean
debian/rules override_dh_auto_clean
make[1]: Entering directory '/home/roberto/mips64el/intelrdfpmath-2.0u2'
/usr/bin/make -C LIBRARY clean
make[2]: Entering directory '/home/roberto/mips64el/intelrdfpmath-2.0u2/LIBRARY'
makefile.iml_head:356: *** Unknown host architecture mips64. Stop.
make[2]: Leaving directory '/home/roberto/mips64el/intelrdfpmath-2.0u2/LIBRARY'
make[1]: *** [debian/rules:16: override_dh_auto_clean] Error 2
make[1]: Leaving directory '/home/roberto/mips64el/intelrdfpmath-2.0u2'
make: *** [debian/rules:13: clean] Error 2
dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2
I have attached an updated patch that seems to resolve this issue and
allows the build to execute on mips64el and mipsel.
Regards,
-Roberto
On Mon, Feb 06, 2023 at 08:58:44PM +, Stephen Kitt wrote:
> Control: tag -1 pending
>
> Hello,
>
> Bug #1030726 in intelrdfpmath reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
>
> https://salsa.debian.org/debian/intelrdfpmath/-/commit/758574be1ed3ce30ec26c6e5136fdb1691d5213a
>
>
> Fix MIPS support
>
> Closes: #1030726
>
>
> (this message was generated automatically)
> --
> Greetings
>
> https://bugs.debian.org/1030726
>
> --
> To unsubscribe, send mail to 1030726-unsubscr...@bugs.debian.org.
--
Roberto C. Sánchez
Description: Fix MIPS support
Author: Stephen Kitt
This removes references to files which aren't shipped, and adds
support for 64-bit MIPS.
Based on a patch by Roberto Sánchez .
Index: intelrdfpmath-2.0u2/LIBRARY/float128/architecture.h
===
--- intelrdfpmath-2.0u2.orig/LIBRARY/float128/architecture.h
+++ intelrdfpmath-2.0u2/LIBRARY/float128/architecture.h
@@ -128,14 +128,22 @@
# undef MULTIPLE_ISSUE
# undef UNSIGNED_TO_FLOAT
# define UNSIGNED_MULTIPLY 1
-# define ENDIANESS little_endian
+# if defined(_MIPSEL)
+# define ENDIANESS little_endian
+# elif defined(_MIPSEB)
+# define ENDIANESS big_endian
+# endif
# define SCALE_METHOD by_int
# define CVT_TO_HI_LO_METHOD by_flt
# define BITS_PER_CHAR8
# define BITS_PER_SHORT 16
# define BITS_PER_INT32
-# define BITS_PER_LONG 32
+# if (_MIPS_SIM == _ABIO32) || (_MIPS_SIM == _ABIN32)
+# define BITS_PER_LONG 32
+# elif _MIPS_SIM == _ABI64
+# define BITS_PER_LONG 64
+# endif
# define BITS_PER_FLOAT 32
# define BITS_PER_DOUBLE 64
@@ -144,22 +152,31 @@
# define INT_8 signed char
# define INT_16 signed short
# define INT_32 signed int
-# undef INT_64
+# define INT_64 long long
# undef INT_128
# define U_INT_8 unsigned char
# define U_INT_16 unsigned short
# define U_INT_32 unsigned int
-# undef U_INT_64
+# define U_INT_64 unsigned long long
# undef U_INT_128
-# define WORD INT_32
-# define U_WORD U_INT_32
-# define BITS_PER_WORD 32
-
-# define HALF_WORD INT_16
-# define U_HALF_WORD U_INT_16
-# define BITS_PER_HALF_WORD 16
-
+# if (_MIPS_SIM == _ABIO32) || (_MIPS_SIM == _ABIN32)
+# define WORD INT_32
+# define U_WORD U_INT_32
+# define BITS_PER_WORD 32
+
+# define HALF_WORD INT_16
+# define U_HALF_WORD U_INT_16
+# define BITS_PER_HALF_WORD 16
+# elif _MIPS_SIM == _ABI64
+# define WORD INT_64
+# define U_WORD U_INT_64
+# define BITS_PER_WORD 64
+
+# define HALF_WORD INT_32
+# define U_HALF_WORD U_INT_32
+# define BITS_PER_HALF_WORD 32
+# endif
#elif (defined(hp_pa) || defined(HP_PA) || defined(__hppa) || defined(__HPPA))
Index: intelrdfpmath-2.0u2/LIBRARY/float128/dpml_exception.h
===
--- intelrdfpmath-2.0u2.orig/LIBRARY/float128/dpml_exception.h
+++ intelrdfpmath-2.0u2/LIBRARY/float128/dpml_exception.h
@@ -325,7 +325,6 @@ typedef struct {
# define PROCESS_DENORMS 1
# define DPML_EXCEPTION_HANDLER DPML_EXCEPTION_NAME
# define EXCEPTION_ARGUMENTS( error_code ) error_code
-# define PLATFORM_SPECIFIC_HEADER_FILE "mips_exception.c"
# elif ARCHITECTURE == hp_pa
# define PROCESS_DENORMS 1
Index: intelrdfpmath-2.0u2/LIBRARY/float128/dpml_private.h
===
--- intelrdfpmath-2
Bug#1030726: marked as pending in intelrdfpmath
As a further note, even with the update patch that I supplied, there is still a later failure on 32-bit mipsel: float128/dpml_ux_cbrt.c: In function 'bid_f128_cbrt': float128/dpml_ux_cbrt.c:136:27: error: 'lsd' undeclared (first use in this function); did you mean 'msd'? 136 || (lsd >> D_EXP_WIDTH); | ^~~ | msd float128/dpml_ux_cbrt.c:136:27: note: each undeclared identifier is reported only once for each function it appears in Regards, -Roberto -- Roberto C. Sánchez
Bug#1030701: intelrdfpmath: FTBFS on alpha/hppa/mips and likely misbuilt on several architectures
On Mon, Feb 06, 2023 at 08:04:13PM +0100, Stephen Kitt wrote:
>
> I’m afraid there isn’t much I can do about that, other than ask upstream to
> add MIPS support.
>
> Given the RC severity of this bug, I’ll consider the main point of the bug to
> be the latter part:
>
> > The RC severity is based on looking at a related question:
> > How did intelrdfpmath compile on new platforms like powerpc/arm/s390x
> > that never had any explicit support in intelrdfpmath?
> >
> > intelrdfpmath (2.0u2-2) unstable; urgency=medium
> > * Assume unknown architectures are “EFI2”.
> >
> > LIBRARY/float128/architecture.h:
> > #if defined(ct) || defined(efi2)
> > # undef _M_AMD64
> > # define _M_AMD64
> > #endif
> >
> > This builds, but the (used) definition
> > # define ENDIANESS little_endian
> > isn't correct on s390x, and neither is
> > # define BITS_PER_LONG 64
> > on 32bit arm.
>
> Ah, I knew that would bite me some day...
>
> I’m updating intelrdfpmath to apply the architecture definitions used in
> libmongocrypt (see
> <https://github.com/mongodb/libmongocrypt/blob/master/cmake/IntelDFP.cmake>):
> armel/armhf are assumed to behave like i386 (I haven’t checked whether that
> makes sense), arm64/ppc64el/riscv64 are assumed to behave like amd64, and
> s390x is supported explicitly.
>
> If you want to track the unsupported architectures, please open a new bug. As
> far as I can tell, even if libmongocrypt were built in Debian using its
> embedded copy of intelrdfpmath, it would fail on the same architectures.
>
So, based on the fact that upstream treats x86 and x86_64 as having the
same data model, I came up with the attached patch. It allows the build
to succeed on both mips64el and mipsel. I am preparing to test (using
the libmongocrypt tests as a proxy) and I will report back with the
results of those tests.
Regards,
-Roberto
--
Roberto C. Sánchez
Index: intelrdfpmath-2.0u2/LIBRARY/float128/dpml_private.h
===
--- intelrdfpmath-2.0u2.orig/LIBRARY/float128/dpml_private.h
+++ intelrdfpmath-2.0u2/LIBRARY/float128/dpml_private.h
@@ -212,7 +212,12 @@ versions until we need them. ] */
#elif (ARCHITECTURE == mips)
-#include "mips_macros.h"
+/*
+ * This header doesn't exist and the attempted inclusion causes a FTBFS.
+ * Don't try to include it, but also leave this branch here so that the
+ * absence of it doesn't result in raising the error below.
+include "mips_macros.h"
+*/
#elif (ARCHITECTURE == hp_pa)
Index: intelrdfpmath-2.0u2/LIBRARY/float128/architecture.h
===
--- intelrdfpmath-2.0u2.orig/LIBRARY/float128/architecture.h
+++ intelrdfpmath-2.0u2/LIBRARY/float128/architecture.h
@@ -144,17 +144,23 @@
# define INT_8 signed char
# define INT_16 signed short
# define INT_32 signed int
-# undef INT_64
+# define INT_64 long long
# undef INT_128
# define U_INT_8 unsigned char
# define U_INT_16 unsigned short
# define U_INT_32 unsigned int
-# undef U_INT_64
+# define U_INT_64 unsigned long long
# undef U_INT_128
-# define WORD INT_32
-# define U_WORD U_INT_32
-# define BITS_PER_WORD 32
+# if 0
+# define WORD INT_32
+# define U_WORD U_INT_32
+# define BITS_PER_WORD 32
+# else
+# define WORD INT_64
+# define U_WORD U_INT_64
+# define BITS_PER_WORD 64
+# endif
# define HALF_WORD INT_16
# define U_HALF_WORD U_INT_16
Index: intelrdfpmath-2.0u2/LIBRARY/float128/dpml_exception.h
===
--- intelrdfpmath-2.0u2.orig/LIBRARY/float128/dpml_exception.h
+++ intelrdfpmath-2.0u2/LIBRARY/float128/dpml_exception.h
@@ -325,7 +325,7 @@ typedef struct {
# define PROCESS_DENORMS 1
# define DPML_EXCEPTION_HANDLER DPML_EXCEPTION_NAME
# define EXCEPTION_ARGUMENTS( error_code ) error_code
-# define PLATFORM_SPECIFIC_HEADER_FILE "mips_exception.c"
+//# define PLATFORM_SPECIFIC_HEADER_FILE "mips_exception.c"
# elif ARCHITECTURE == hp_pa
# define PROCESS_DENORMS 1
Bug#1029618: Fwd: GStreamer1.0 Aborts Streams
I can confirm this bug also affects version 1.22.0-2, which was recently released to Debian sid. Example: fienix@fienix:~$ yt-dlp -g -x https://www.youtube.com/watch?v=B7xai5u_tnk https://rr4---sn-vgqsknez.googlevideo.com/videoplayback?expire=1675118797=bfTXY7j4EoColu8PgqmQsAI=2600%3A6c44%3A93f%3A62f3%3A28ba%3A44e5%3A4324%3Aba01=o-AL-uOcbw087rHpx2iYu1Rbi-yi1AS1M_xmR1iBp29WHX=251=youtube=yes=1_=31%2C26=sn-vgqsknez%2Csn-p5qlsn6l=au%2Conr=m=4=34=1625000=H3gIhvbfx70EptYwVvP7lqj-lnYy_yk=1=1=audio%2Fwebm=yes=4902093=290.961=1584116719229328=1675096869=4=yes=24007246=ANDROID=5431432=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt=AOq0QJ8wRAIgZeHPW3YaEVgMYfZgAAUVl62449gqar8QBKg2SFV2DbsCIHft38hBSAJuw7A_wonGlZT3pyX5-BoP3ducun4JUEtE=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps=AG3C_xAwRgIhAJZth3oNdSuIvw09x3gppNh3WfqdSKtNGARUnWQYhZUTAiEA51Ad3cSgCgGue30dG30a6qDLTIAw0QMbtq0ymH2m8ac%3D fienix@fienix:~$ gst-launch-1.0 playbin uri="https://rr4---sn-vgqsknez.googlevideo.com/videoplayback?expire=1675118797=bfTXY7j4EoColu8PgqmQsAI=2600%3A6c44%3A93f%3A62f3%3A28ba%3A44e5%3A4324%3Aba01=o-AL-uOcbw087rHpx2iYu1Rbi-yi1AS1M_xmR1iBp29WHX=251=youtube=yes=1_=31%2C26=sn-vgqsknez%2Csn-p5qlsn6l=au%2Conr=m=4=34=1625000=H3gIhvbfx70EptYwVvP7lqj-lnYy_yk=1=1=audio%2Fwebm=yes=4902093=290.961=1584116719229328=1675096869=4=yes=24007246=ANDROID=5431432=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt=AOq0QJ8wRAIgZeHPW3YaEVgMYfZgAAUVl62449gqar8QBKg2SFV2DbsCIHft38hBSAJuw7A_wonGlZT3pyX5-BoP3ducun4JUEtE=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps=AG3C_xAwRgIhAJZth3oNdSuIvw09x3gppNh3WfqdSKtNGARUnWQYhZUTAiEA51Ad3cSgCgGue30dG30a6qDLTIAw0QMbtq0ymH2m8ac%3D; Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'source': gst.soup.session=context, session=(GstSoupSession)NULL; Aborted
Bug#1029618: Fwd: GStreamer1.0 Aborts Streams
Package: libgstreamer1.0-0 Version: 1.20.5-1 Architecture is powerpc. Running 32-bit userland on 64-bit kernel (5.14.0-3-powerpc64). GStreamer aborts streams and causes apps that depend on GStreamer to close unexpectedly. This behavior is present in version 1.20.2-1 and 1.20.5-1. Version 1.16.2-2 did not exhibit this behavior, it worked correctly. Example 1.20.5-1: "fienix@fienix:~$ gst-launch-1.0 playbin uri=" https://rr5---sn-vgqsrnek.googlevideo.com/videoplayback?expire=1674531421=_f3OY_voL_2b2_gPoNeT8Aw=2600%3A6c44%3A93f%3A62f3%3A28ba%3A44e5%3A4324%3Aba01=o-AGnkjnP88MjN7lD0RftW0BNjOFMp4bjMk31zRCAD3Os5=251=youtube=yes=1_=31%2C29=sn-vgqsrnek%2Csn-vgqsknez=au%2Crdu=m=5=34=1681250=H3gIhur2nEmAfkKUu7FHAHzRqW7q930=1=1=audio%2Fwebm=yes=4902093=290.961=1584116719229328=1674509574=4=yes=24007246=ANDROID=5431432=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt=AOq0QJ8wRAIgN_sDcp41RZrKDPaqz04uotyjKGqwjISalBComgFW_KYCIF3w-Sxs6Ppq7Y3_BVYSjUV5k7Ie9fChbkpqauIjMFMk=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps=AG3C_xAwRgIhAP5s4OgohwnRsEETu18mHcVxoUOXZUOeQZfyJcHWufrLAiEA4Dg8xUbIvII2wPgXdCXgpkdNB3chJBjYaOpjPoWNyV4%3D " Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'source': gst.soup.session=context, session=(GstSoupSession)NULL; Aborted" Example 1.16.2-2: "fienix@fienix:~$ gst-launch-1.0 playbin uri=" https://rr5---sn-vgqsrnek.googlevideo.com/videoplayback?expire=1674531421=_f3OY_voL_2b2_gPoNeT8Aw=2600%3A6c44%3A93f%3A62f3%3A28ba%3A44e5%3A4324%3Aba01=o-AGnkjnP88MjN7lD0RftW0BNjOFMp4bjMk31zRCAD3Os5=251=youtube=yes=1_=31%2C29=sn-vgqsrnek%2Csn-vgqsknez=au%2Crdu=m=5=34=1681250=H3gIhur2nEmAfkKUu7FHAHzRqW7q930=1=1=audio%2Fwebm=yes=4902093=290.961=1584116719229328=1674509574=4=yes=24007246=ANDROID=5431432=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt=AOq0QJ8wRAIgN_sDcp41RZrKDPaqz04uotyjKGqwjISalBComgFW_KYCIF3w-Sxs6Ppq7Y3_BVYSjUV5k7Ie9fChbkpqauIjMFMk=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps=AG3C_xAwRgIhAP5s4OgohwnRsEETu18mHcVxoUOXZUOeQZfyJcHWufrLAiEA4Dg8xUbIvII2wPgXdCXgpkdNB3chJBjYaOpjPoWNyV4%3D " Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'source': gst.soup.session=context, session=(SoupSession)NULL, force=(boolean)false; Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... ^Chandling interrupt. Interrupt: Stopping pipeline ... Execution ended after 0:00:05.168342809 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ..." Example Goodvibes (depends on GStreamer): "fienix@fienix:~$ goodvibes (goodvibes:1024): Gtk-WARNING **: 17:31:07.812: Theme parsing error: gtk-contained-dark.css:2871:228: Missing closing bracket for :not() Aborted" Example Goodvibes via gdb: "Reading symbols from goodvibes... Reading symbols from /usr/lib/debug/.build-id/4b/026b582e015d5446c3d825804d547274785898.debug... (gdb) run Starting program: /usr/bin/goodvibes [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1". [New Thread 0xf1f3f180 (LWP 3247)] [New Thread 0xf15ff180 (LWP 3248)] (goodvibes:3243): Gtk-WARNING **: 17:41:48.823: Theme parsing error: gtk-contained-dark.css:2871:228: Missing closing bracket for :not() [New Thread 0xf092f180 (LWP 3249)] [New Thread 0xefd7f180 (LWP 3250)] [Thread 0xefd7f180 (LWP 3250) exited] [New Thread 0xefd7f180 (LWP 3251)] [New Thread 0xef06f180 (LWP 3252)] [Thread 0xefd7f180 (LWP 3251) exited] [New Thread 0xefd7f180 (LWP 3253)] [New Thread 0xee61f180 (LWP 3254)] [Thread 0xef06f180 (LWP 3252) exited] [Thread 0xefd7f180 (LWP 3253) exited] [Thread 0xee61f180 (LWP 3254) exited] [New Thread 0xee61f180 (LWP 3255)] [New Thread 0xefd7f180 (LWP 3256)] [Thread 0xee61f180 (LWP 3255) exited] [New Thread 0xee61f180 (LWP 3257)] [New Thread 0xef06f180 (LWP 3258)] [Thread 0xefd7f180 (LWP 3256) exited] [Thread 0xee61f180 (LWP 3257) exited] [Thread 0xef06f180 (LWP 3258) exited] [New Thread 0xef06f180 (LWP 3259)] [New Thread 0xee61f180 (LWP 3260)] [Thread 0xef06f180 (LWP 3259) exited] [New Thread 0xef06f180 (LWP 3261)] [New Thread 0xefd7f180 (LWP 3262)] [Thread 0xee61f180 (LWP 3260) exited] [Thread 0xef06f180 (LWP 3261) exited] [Thread 0xefd7f180 (LWP 3262) exited] [New Thread 0xefd7f180 (LWP 3263)] [New Thread 0xef06f180 (LWP 3264)] [New Thread 0xee61f180 (LWP 3265)] Thread 20 "pool-goodvibes" received signal SIGABRT, Aborted. [Switching to Thread 0xee61f180 (LWP 3265)] 0xf6ac2ec0 in __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:43 43 pthread_kill.c: No such file or directory. (gdb) " Please let me know if I can provide any additional information to assist in resolving this issue.
Bug#985631:
Seems to be a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985256
Bug#985256:
Looks like a duplicate of this to me: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985631
Bug#986152: Offer of help
On Sat, Jan 21, 2023 at 09:58:13AM +0100, Romain Francoise wrote: > On Fri, Jan 20, 2023 at 11:59:44AM +, Jeremy Sowden wrote: > > The Developer's Reference, § 5.6.1, expresses the preference that when > > new binary packages are added to a source package, it should be > > uploaded to experimental, so I've updated the version and distribution > > in the change-log entry accordingly. > > But these are not *new* binary packages, so I don't think the upload > will go through NEW. In fact, I hope it won't because there's still the > freeze to consider and I'd really like the new package to be in > bookworm. Sort of. Whenever a source package produces a new binary package, whether that package exists in the archive already or not, it will land in NEW. For instance, this happens with libraries that bump SONAME and start shipping a new binary package as a result. Consider the source package foo which produces (among others) libfoo1. If the SONAME is bumped to 2 causing libfoo2 to be emitted by the foo source package instead of libfoo1, then that upload will land in NEW. The FTP masters take notice and this particular case is usually handled very quickly (since they don't have to do all the normal checks of a brand new source package), but they still have to check that the new binary package being created by the source package in question doesn't conflict with a binary package from another source package. Imagine an entirely different source package, foo2, that already produced the binary package libfoo2. Allowing an unchecked upload of foo to add the libfoo2 binary package to the archive when foo2 is already producing a libfoo2 package would be a Bad Thing(TM). This is where appropriate use of things like Breaks/Replaces/Conflicts can help streamline the process. Regards, -Roberto -- Roberto C. Sánchez
Bug#986152: Offer of help
On Fri, Jan 20, 2023 at 09:46:35PM +, Jeremy Sowden wrote: > On 2023-01-19, at 22:56:39 +0100, Romain Francoise wrote: > > On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden wrote: > > > I've pushed all the work to my repo on Salsa: > > > > > > https://salsa.debian.org/azazel/shorewall > > > > > > Do you want to review it before I push to the shorewall-team repo? > > > > It all looks pretty good to me! In fact, it's a radical improvement > > over the previous packaging with seven source packages. > > > > [...] > > > > I have not yet actually tested the packages in my lab but please feel > > free to push your changes to the team repo, and I will do the final > > testing and upload over the week-end. I can also take care of opening > > the bugs to have the previous source packages removed from unstable. > > I was wondering about this shorewall-doc bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266957 > > Once 5.2.8 is uploaded there won't be a shorewall-doc source package. > Shall I reassign it to shorewall? > > J. That's a good question. I think that the bug is actually assigned to the shorewall-doc binary package, not the shorewall-doc source package. Assuming that the shorewall source package will start to emit a shorewall-doc binary package, I think that the BTS will do the right thing and leaving the bug assigned to shorewall-doc is correct. In that case, the source package association of shorewall-doc will change, but its bugs will still belong to shorewall-doc (the binary package). If you think about it, this must be the case, as closed and archived bugs would end up being orphaned otherwise. Regards, -Roberto -- Roberto C. Sánchez
Bug#985258: closed by c.bu...@posteo.jp ()
Dear Francesco, thanks for the reply. Am 20.01.2023 12:53 schrieb Francesco Potortì: I understand that this is not an error hand has no consequences. However, for someone using the progrma, it gives the impression of inaccuracy, carelessness and possible unreliability, which is grave for a backup utility. That is a good point. Why not setting XDG_RUNTIME_DIR to something bening and get rid of the warning? For example, I see that people use /tmp/runtime-root as a fallback. Can you do me a favour please and check again with the latest version 1.3.3. (from "unstable" repo in Debian) or directly from our upstream github repo? I assume this is fixed as a side effect of this commit: https://github.com/bit-team/backintime/commit/26d079a9f30c02ac91d8f0e5cbb6d94ef2065f78 A better solution would be to get rid of the Qt stuff. I assume that some of the Qt stuff can be replaced by Python-inbuild features.
Bug#985260:
Tags: confirmed, upstream Upstream do confirm this bug. Which is related to the fact how Back In Time reacts on failing user-callback scripts. It seems that BIT doesn't exit with an error code. There is an upstream report about it: https://github.com/bit-team/backintime/issues/1053
Bug#998105:
Dear Sven, there is a new release 1.3.3 in "unstable" branch of Debian. Can you please try to reproduce the problem with that version and then report back. Thanks Christian
Bug#920050: Vote for close
#Close Close Can I send commands myself? I vote for closing this issue because it is not reproducible. Kind Christian
Bug#986152: Offer of help
On Sat, Jan 07, 2023 at 12:48:08PM +0100, Romain Francoise wrote: > On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden wrote: > > I've imported my fork of Roberto's SF repo to Salsa: > > > > https://salsa.debian.org/azazel/shorewall > > > > I haven't touched it in 18 months, so I'll give it a polish when I have > > some time, and perhaps we can use it as a starting point. > > Thanks. I created a Salsa team and repo here: > https://salsa.debian.org/shorewall-team/shorewall and added you both > as co-owners. > > I felt more comfortable using Roberto's original SF repo as a starting > point, and merging in your changes after review. I can do that in the > next few days, the freeze is coming up very soon and I would like to > have the new upstream in bookworm. If you have further changes please > push them to your repo. > > I'll also configure the CI on Salsa to have all the usual QA tools run > automatically on each push. > > Did you find a practical way to do changes across all seven source > packages at once? For a bit of historical context, the current multi-branch structure from the SF repo is quite antiquiated. It is from a time before debhelper supported multiple .orig.tar.gz components. It might make sense to consider starting with a new repo, with a more sensible branch structure (one that works more easily with tools like gbp), and that makes use of the multi-tarball capabilities so that you have have all the source packages in view at the same time. Regards, -Roberto -- Roberto C. Sánchez
Bug#986152: Offer of help
On Mon, Jan 02, 2023 at 06:08:57PM +0100, Romain Francoise wrote: > Hi, > > [Cc'ing Roberto directly to make sure he's aware of this discussion.] > Thanks for that. I'm not sure I would have seen it otherwise. > I'm also a Shorewall[6] user and while the state of the package isn't > really alarming right now, I need it to be properly maintained going > forward. > My needs have been evolving the last few years and I have much less of a need for a tool like Shorewall these days. Additionally, I have never used some of the advanced features (e.g., Multi-ISP, tc, accounting, etc.). It would be good to have others involved in maintenance who are able to contribute in that way. > We could set up a pkg-shorewall team on Salsa and co-maintain the > packages there. Jeremy, would that work for you? > I see that the group has already been created and that I was added. At the moment I am not able to jump in to aid with the transition. I hope to clear some major items from my queue in the coming weeks and until then I will do what I can. I'd like to mention that there is already a Gitlab group for upstream Shorewall work (which has been essentially dormant for some time): https://gitlab.com/shorewall It might make sense to consider if there is any overlap and if any of the Salsa work might be better house under the Shorewall Gitlab group. I'll try to jump in a bit more helpfully next week. Regards, -Roberto -- Roberto C. Sánchez
Bug#1006179: [Pkg-clamav-devel] Bug#1006179: Bug#1006179: Bug#1006179: Bug#1006179: Bug#1006179: ClamAV 1.0.0 release candidate now available
On Fri, 23 Dec 2022, Sebastian Andrzej Siewior wrote: Then we need to decide what we do about the rust bits. I'm currently unsure if we can use the in-source bits or must use packages. From https://blog.clamav.net/2022/10/ Starting with ClamAV 0.105.1, some of the ClamAV project is written in Rust and depends on Rust libraries. To make it possible for our users to build ClamAV offline, we bundle in the Rust dependencies. I think that means that some of the rust code in the clam tarball is needed and some can be replaced by system versions. I am a little uneasy about build time downloads of dependencies, but that looks like a general rust issue. Elsewhere ClamAV suggest that packages are built on the oldest system you wish to support, as that they will run on newer systems too. Personally I prefer each system version to have its own package built on that system, but I'd stick with the standard Debian way. -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk
Bug#1006179: [Pkg-clamav-devel] ClamAV 1.0.0 release candidate now available
On Thu, 22 Dec 2022, Scott Kitterman wrote: On Monday, December 12, 2022 10:45:57 PM EST Scott Kitterman wrote: On Saturday, December 10, 2022 11:14:14 AM EST Sebastian Andrzej Siewior wrote: On 2022-12-07 12:51:30 [-0500], Scott Kitterman wrote: OK. I'm back to having some time for Debian again, so let me know how I can help. I pushed something to the experimental branch. It ain't much… This updates the build dependencies and you still need download the upstream .tar.gz yourself for 1.0.0. uscan is a bit of help. The split script isn't working anymore. Looks like it needs an some rewrite. I guess we are in the land of CMake now as the configure.ac files it expects to find don't exist now. The llvm code is gone from the archive. This is the only good new. We probably need to patch clamav to take the tfm library instead the one they ship. The only change is probably that one you pointed out (with the larger bit size). I also found the 7z folder and I *think* that it can be substituted by lzma-dev. The result builds and the testsuite passes. Besides we need to split out unrar. Scott K Sebastian That doesn't sound too bad. I'll see if I can find some time to work on the split, but probably not until Wednesday or Friday. I did, eventually, look at this some. This is both easier and harder is some ways. First, the CMake build system supports not building libclamavunrar, so we don't need to monkey with the build system to get clamav built with it removed. I think split script is a do-over. Only the most trivial parts of it are still useful. My suggested path forward is to manually create a DFSG tarball (and clean up the win32 bits we don't need) by removing the relevant directories: libclamunrar win32 Then, at least in theory we can build a DFSG free package by passing ENABLE_UNRAR_DEFAULT=OFF in the configure parameters. I think we should focus on getting clamav up to 1.0.0 before the freeze and deal with the unrar bits later (should be easy enough to get a freeze exception for if we need it). If you think tha'ts reasonable, I'll manually make the tarball and update git (including the pristine-tar branch so we can work with the same tarball)? How will that affect the non-free unrar package that Ubuntu ships ? -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk
Bug#1025543: backintime: dependency on transitional policykit-1 package
Dear Simon, thanks for that report. I'm a member of the new upstream maintainer team. Do I understand it correct that this ticket is relevant only for the Debian Package Maintainer? Or can we as upstream do something about it? Kind Christian Buhtz
Bug#639537: backintime: messes with file access time when performing backups
Dear Julian, I'm a member of the new upstream maintainer team. The bug is quit old. Please try to reproduce that problem with the current upstream version. If you can reproduce it please open an Issue at upstream and link it here. It seems rsync specific but we would take care of it if it is reproducable. I suggest to close that Debian bug report because it seems not distro specific. Kind Christian Buhtz
Bug#985355: backintime-qt: runtime error - reentrant call
Dear Francesco, I'm a member of the new upstream maintainer team. I assume this is reported at upstream https://github.com/bit-team/backintime/issues/1003 and also fixed there https://github.com/bit-team/backintime/pull/1380 Please try to reproduce that problem with the current upstream version. If you can still reproduce it please open an Issue at upstream and link it here. I suggest to close that Debian bug report because it seems not distro specific. Kind Christian Buhtz
Bug#985257: backintime-qt: no user callback example installed
Hello, I'm a member of the new upstream maintainer team. It is not a bug but a feature request. It is still tracked at upstream. So suggest to close that Debian bug report because it seems not distro specific. Kind Christian Buhtz
Bug#985260: backintime-qt: cron jobs error not mailed to user
Dear Francesco, I'm a member of the new upstream maintainer team. The bug is quit old. Please try to reproduce that problem with the current upstream version. If you can reproduce it please open an Issue at upstream and link it here. I suggest to close that Debian bug report because it seems not distro specific. Kind Christian Buhtz
Bug#985256: backintime-qt: unmount at wrong time leads to core dump
Dear Francesco, I'm a member of the new upstream maintainer team. The bug is quit old. Please try to reproduce that problem with the current upstream version. If you can reproduce it please open an Issue at upstream and link it here. You still gave us the steps to reproduce. Can you please give some more information about snapshot profile you setup? I suggest to close that Debian bug report because it seems not distro specific. Kind Christian Buhtz
Bug#978735: backintime-qt: crash and failure to create SSH profile
Dear Sebastian, I'm a member of the new upstream maintainer team. The bug is quit old. Please try to reproduce that problem with the current upstream release. If you can reproduce it please open an Issue at upstream and link it here. I suggest to close that Debian bug report because it seems not distro specific. Kind Christian Buhtz
Bug#973760: backintime-common: in backintime.py function smartRemoveList missing return value
Dear Greg, I'm a member of the new upstream maintainer team. Thank you for reporting this. I opened an upstream Issue for that https://github.com/bit-team/backintime/issues/1392 I suggest to close that Debian bug report because it seems not distro specific. Kind Christian Buhtz
Bug#920050: backintime-common: restoring file within a symbolic-linked directory removes symbolic link
Dear Jacob, I'm a member of the new upstream maintainer team. Your report sounds serious but is IMHO not distro specific. The bug is quit old. Please try to reproduce that problem with the current upstream release. If you can reproduce it please open an Issue at upstream and link it here. I suggest to close that Debian bug report because it seems not distro specific. Kind Christian Buhtz
Bug#888914: backintime adds current directory to path?
Hello, I'm a member of the new upstream maintainer team. Please try to reproduce that problem with the current upstream release and report back. I suspect that the fix Fabian linked to does fix your problem. I suggest to close that Debian bug report because it seems not distro specific. Kind Christian Buhtz
Bug#866741: backintime-qt4: Freezes when pressing button "View last log"
Hello, I'm a member of the new upstream maintainer team. The bug is quit old. Please try to reproduce that problem with the current upstream release. If you can reproduce it please open an Issue at upstream and link it here. I suggest to close that Debian bug report because it seems not distro specific. Kind Christian Buhtz
Bug#859115: backintime-gnome: The 'backintime-gnome' blames Canberra, while 'backintime' blames keyring
Hello, I'm a member of the new upstream maintainer team. The bug is quit old. Please try to reproduce that problem with the current upstream release. If you can reproduce it please open an Issue at upstream and link it here. Based on your report I'm not sure if this is maybe Debian specific. Can you also please test the current BIT 1.3.2 from Debians "unstable" branch? Kind Christian Buhtz
Bug#995257: backintime-qt4: does not check if backup directory exists (or drive is mounted)
Hello, I'm a member of the new upstream maintainer team. The bug is quit old. Please try to reproduce that problem with the current upstream release. If you can reproduce it please open an Issue at upstream and link it here. I suggest to close that Debian bug report because it is not distro specific. Kind Christian Buhtz
Bug#1006179: [Pkg-clamav-devel] Bug#1006179: Bug#1006179: Bug#1006179: Bug#1006179: ClamAV 1.0.0 release candidate now available
On Tue, 13 Dec 2022, Sebastian Andrzej Siewior wrote: On 2022-12-12 22:45:57 [-0500], Scott Kitterman wrote: That doesn't sound too bad. I'll see if I can find some time to work on the split, but probably not until Wednesday or Friday. So I managed to tell cmake to use the tfm library instead of the bundled code and the testsuite fails now but I think this is due to the limit in "our" libtfm. I noticed libclammspack/libclammspack.so which appears to be the libmspack and I hope that this is a typo somewhere and we can exclude the bundled library. INSTALL.md lists a CMake option ENABLE_EXTERNAL_MSPACK so there should be no problem there. Then I had to throw up a little. It might me be nothing and I'm just stupid and don't know things but there is a lot of rust code in libclamav_rust/.cargo/vendor/ and it appears to me that they bundled a bunch of rust libraries. It *might* be enough to just install librust-jpeg-decoder-dev as dependency and then libclamav_rust/.cargo/vendor/jpeg-decoder will be ignored but I just wanted point that out. I don't have any rust skills at this time. ClamAV are moving towards Rust being a major part of the project. https://docs.clamav.net/faq/faq-rust.html Sadly, from our point of view, they use cpack (part of cmake) to build their .deb (and .rpm) packages rather than a "debian" tree. They also use an in-house tool - Mussels https://blog.clamav.net/2019/12/introducing-mussels-application.html to manage library dependencies. Not sure whther this will be an issue. CMakeLists.txt has set(LLVM_MAX_VER "13") set(LLVM_MIN_VER "8") I don't know about Debian, but Ubuntu Kinetic/22.10 has LLVM v15 by default. We can hope that 13 is not a hard limit, just that it is the latest tested version ... -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk
Bug#1024537: printing long code lines cut off
package: wiki.debian.org
Using
https://wiki.debian.org/SecureBoot#Using_your_key_to_sign_modules as
an example, when I go to print it, even in landscape format, while
regular text wraps fine, the command snippets are in scroll boxes
(great if you're on a screen and the command line is wider than the
box) which don't wrap when printed, just are cut off at the end of the
box. For example:
Or sign all modules of the current directory:
$ for i in *.ko ; do sudo --preserve-env=KBUILD_SIGN_PIN
"$KBUILD_DIR"/scripts/sign-file sha256
/var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der
"$i" ; done
I would suggest _either_ that there be a print (or export to pdf)
option which handles such lines, _or_ that the wiki editor function
limit line length so that authors would put line-continuing (" ") and
the wiki not use scroll-bar boxes for such text.
Thanks,
Doug.
===
Doug Tutty,
508 Douglass Dr.
PO Box 233
Faro YT Y0B 1K0Ph: 867-322-0984douglas.tutty@hushmail.comSecure email
form: https://hushforms.com/douglas.tutty
