Bug#976296: blender: Segmentation fault when importing background image
Hi, Am 2020-12-03 00:47, schrieb will: ii libavcodec58 10:4.3.1-dmo3 ii libavdevice58 10:4.3.1-dmo3 ii libavformat58 10:4.3.1-dmo3 ii libavutil56 10:4.3.1-dmo3 ii libswscale5 10:4.3.1-dmo3 it's incredible that people still install these package. Please replace them with their Debian pendants and try again. Thanks! - Fabian
Bug#976285: please enable redis plugin
Control: retitle -1 please enable Zabbix Agent 2 Am Donnerstag, den 03.12.2020, 13:10 +1100 schrieb Dmitry Smirnov: > On Thursday, 3 December 2020 6:44:45 AM AEDT Felix Zielcke wrote: > > it looks like Zabbix is compiled without the redis plugin. > > No, it looks like there is no special support for Redis in zabbix- > agent. > > You probably need (Golang-based) Zabbix Agent 2, which is not > provided > by Debian package (yet). > Thanks for your fast reply. So what's missing to enable Agent 2? > > From /usr/share/doc/zabbix-frontend- > > php/templates/db/redis/README.md.gz > > Test availability: `zabbix_get -s redis-master -k redis.ping` > > > > # `zabbix_get -s redis-master -k redis.ping` > > zabbix_get [2264555]: Get value error: cannot resolve [redis- > > master] > > That error indicates that your network have no "redis-master" host > (or that there is no DNS record for it). > > > > And the template indeed doestn't work. > > That's hardly a surprise if "redis master" don't resolve... Whoops. So I didn't read the docs fully. But now I get a different error: zabbix_get [2294402]: Check access restrictions in Zabbix agent configuration Well this isn't a support channel, so I'll try to find it out myself, what's now wrong. Thanks again for your answer.
Bug#976274: libqt5gui5: Please build Qt5 with configure option -xcb-native-painting
Hi Lisandro, On Mittwoch, 2. Dezember 2020 23:57:00 CET Lisandro Damián Nicanor Pérez Meyer wrote: > Hi Andre! > > El mié., 2 dic. 2020 13:03, Andre Woebbeking escribió: > > > Package: libqt5gui5 > > Version: 5.15.1+dfsg-4 > > Severity: wishlist > > X-Debbugs-Cc: woebbek...@web.de > > > > Dear Maintainer, > > > > with X2Go Qt5 apps are much slower than X or GTK apps. But there is a > > workaround: > > setting the environment variable QT_XCB_NATIVE_PAINTING. > > > > This worked until testing updated to Qt 5.15 because upstream disabled the > > automatic > > configuration of this feature in commit > > 7f948d9effad983477977c3274231401f260c531. > > > > So please build Qt5 with -xcb-native-painting to make X2Go users happy > > again :-) > > > > And what would the drawbacks be? the compile time and the library size would increase a bit. To get any behaviour change you've to set QT_XCB_NATIVE_PAINTING.
Bug#975752: view from aptitude
The following packages have unmet dependencies: android-libadb : Depends: android-libbase (= 1:8.1.0+r23-8) but 1:10.0.0+r36-1~stage1.1 is to be installed The following actions will resolve these dependencies: Keep the following packages at their current version: 1) android-libbase [1:8.1.0+r23-8 (now)] 2) android-libcutils [1:8.1.0+r23-8 (now)] 3) android-liblog [1:8.1.0+r23-8 (now)] Accept this solution? [Y/n/q/?] n The following actions will resolve these dependencies: Remove the following packages: 1) adb [1:8.1.0+r23-8 (now, unstable)] 2) android-libadb [1:8.1.0+r23-8 (now, unstable)] Accept this solution? [Y/n/q/?] n *** No more solutions available ***
Bug#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault
Control: tag 970878 + patch
Hi Jonas (2020.10.23_03:07:27_-0700)
FWIW I found the offending upstream commit and reverting it seems to do
the trick. I prefer fixing problems to reverting changes, but the bug
wasn't obvious to me, and the commit doesn't seem critical.
The commit is "txtwrite - better processing of text in type 3 fonts"
http://www.ghostscript.com/cgi-bin/findgit.cgi?278f9a53ed507f9109380ee4210fb860b35b1811
Uploaded that revert to Ubuntu, and things seem OK there. The doc-rfc
autopkgtests pass.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
From 0f6cd8fbb1e2dc99ff19e4e796cac62f046d1bb5 Mon Sep 17 00:00:00 2001
From: Stefano Rivera
Date: Mon, 30 Nov 2020 18:48:24 -0800
Subject: [PATCH] Revert "txtwrite - better processing of text in type 3 fonts"
This reverts commit 278f9a53ed507f9109380ee4210fb860b35b1811.
---
devices/vector/gdevtxtw.c | 75 +--
1 file changed, 8 insertions(+), 67 deletions(-)
diff --git a/devices/vector/gdevtxtw.c b/devices/vector/gdevtxtw.c
index d46a935e6..9958dc140 100644
--- a/devices/vector/gdevtxtw.c
+++ b/devices/vector/gdevtxtw.c
@@ -142,9 +142,6 @@ static dev_proc_dev_spec_op(txtwrite_dev_spec_op);
/* Define the text enumerator. */
typedef struct textw_text_enum_s {
gs_text_enum_common;
-gs_text_enum_t *pte_fallback;
-double d1_width;
-bool d1_width_set;
bool charproc_accum;
bool cdevproc_callout;
double cdevproc_result[10];
@@ -1541,9 +1538,6 @@ get_missing_width(gs_font *font, int wmode, const gs_matrix *scale_c,
FONT_INFO_MISSING_WIDTH, );
if (code < 0)
return code;
-if (!(finfo.members & FONT_INFO_MISSING_WIDTH))
-return_error(gs_error_undefined);
-
if (wmode) {
gs_distance_transform(0.0, -finfo.MissingWidth, scale_c, >real_width.xy);
pwidths->Width.xy.x = 0;
@@ -1618,7 +1612,7 @@ txt_glyph_widths(gs_font *font, int wmode, gs_glyph glyph,
&& (code == gs_error_undefined || !(info.members & (GLYPH_INFO_WIDTH0 << wmode {
code = get_missing_width(font, wmode, _c, pwidths);
if (code < 0)
-return code;
+v.y = 0;
else
v.y = pwidths->Width.v.y;
if (wmode && (ofont->FontType == ft_CID_encrypted ||
@@ -1988,32 +1982,26 @@ txtwrite_process_plain_text(gs_text_enum_t *pte)
txt_glyph_widths_t widths;
gs_point wanted; /* user space */
-for (i=pte->index;itext.size;i++) {
+for (i=0;itext.size;i++) {
gs_point dpt = {0,0};
if (operation & (TEXT_FROM_STRING | TEXT_FROM_BYTES)) {
-ch = pte->text.data.bytes[pte->index];
+ch = pte->text.data.bytes[pte->index++];
} else if (operation & (TEXT_FROM_CHARS | TEXT_FROM_SINGLE_CHAR)) {
-ch = pte->text.data.chars[pte->index];
+ch = pte->text.data.chars[pte->index++];
} else if (operation & (TEXT_FROM_GLYPHS | TEXT_FROM_SINGLE_GLYPH)) {
if (operation & TEXT_FROM_GLYPHS) {
gdata = pte->text.data.glyphs + (pte->index++ * sizeof (gs_glyph));
} else {
gdata = >text.data.d_glyph;
+pte->index++;
}
}
glyph = (gdata == NULL ? pte->orig_font->procs.encode_char(pte->orig_font, ch, GLYPH_SPACE_NAME)
: *gdata);
code = txt_glyph_widths(font, font->WMode, glyph, (gs_font *)font, , NULL);
-if (code < 0) {
-if (penum->d1_width_set) {
-widths.Width.w = widths.Width.xy.x = widths.real_width.w = widths.real_width.xy.x = penum->d1_width;
-penum->d1_width = 0;
-penum->d1_width_set = 0;
-}
-else
-return code;
-}
+if (code < 0)
+return code;
penum->cdevproc_callout = false;
code = txt_update_text_state(penum->text_state, (textw_text_enum_t *)pte, pte->orig_font, >FontMatrix);
@@ -2058,10 +2046,6 @@ txtwrite_process_plain_text(gs_text_enum_t *pte)
memset(>Advs[penum->TextBufferIndex + 1], 0x00, (code - 1) * sizeof(float));
}
penum->TextBufferIndex += code;
-/*gs_moveto_aux(penum->pgs, gx_current_path(penum->pgs),
- fixed2float(penum->origin.x) + wanted.x + dpt.x,
- fixed2float(penum->origin.y) + wanted.y + dpt.y);*/
-pte->index++;
}
return 0;
}
@@ -2096,7 +2080,7 @@ txt_add_sorted_fragment(gx_device_txtwrite_t *tdev, textw_text_enum_t *penum)
/* Already have text at this y-position */
text_list_entry_t *X_List = Y_List->x_ordered_list;
-while (X_List->next && X_List->start.x <= penum->text_state->start.x)
+while (X_List->next && X_List->start.x < penum->text_state->start.x)
X_List = X_List->next;
if
Bug#976294: gitlab: fails to install: Could not find gem 'faraday (~> 0.12)'
Control: fixed -1 13.4.6-1 On 2020, ഡിസംബർ 3 4:26:15 AM IST, Carlos Pasqualini wrote: >Package: gitlab >Version: 13.3.9-1 >Severity: important > >Dear Maintainer, > >I am unable to install latest gitlab from unstable. Is there any >workaround to get this working? > > * What led up to the situation? > The server was working on buster, and updated to testing (another > service on same server) broke gitlab. > Trying to upgrade to a new (working) version. > > * What exactly did you do (or not do) that was effective (or > ineffective)? > > Try to install latest gitlab from unstable: > ># LANG=C apt -t unstable install gitlab >Reading package lists... Done >Building dependency tree >Reading state information... Done >gitlab is already the newest version (13.3.9-1). >The following package was automatically installed and is no longer required: > libgumbo1 >Use 'apt autoremove' to remove it. >0 upgraded, 0 newly installed, 0 to remove and 104 not upgraded. >1 not fully installed or removed. >After this operation, 0 B of additional disk space will be used. >Do you want to continue? [Y/n] >Setting up gitlab (13.3.9-1) ... >fatal: not a git repository (or any of the parent directories): .git >fatal: not a git repository (or any of the parent directories): .git >Could not find gem 'faraday (~> 0.12)' in any of the gem sources listed in >your Gemfile. You need to install gitlab 13.4.6 from experimental. It will be uploaded to unstable soon. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#976191: texlive-latex-base: Fails to build formats for LaTeX
> > @Norbert: could fix this in upstream? l3packages has moved from collection-latexrecommended to collection-latex in svn 57048. Thus, a new checkout with the respective filemove;texlive-latex-recommended;texlive-latex-base;2020.20201203 needs to be added to tpm2deb.cfg, and rebuilt. It might be worth at some point (before the freeze), to also push the cross TeX Live dependencies: latest-version;texlive-bin;2020.20200327 texlive-base-version;2020.20200417 latest-version;texlive-base;2020.20200417 latest-version;texlive-extra;2020.20200417 latest-version;texlive-lang;2020.20200417 and move all of them forward to the latest version to ensure that there is no squeeze in the installed packages. Best Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#976306: gtk-doc-tools: broken symlink: /usr/share/man/man1/gtkdoc-scangobj.1.gz
Package: gtk-doc-tools Version: 1.33.1-1 Severity: minor User: debian...@lists.debian.org Usertags: adequate broken-symlink There is now a broken symlink in the gtk-doc-tools package. $ adequate gtk-doc-tools gtk-doc-tools: broken-symlink /usr/share/man/man1/gtkdoc- scangobj.1.gz -> gtkdoc-scanobj.1.gz It looks like what happened is that the Debian-specific manual pages were removed but a symlink to one of them was forgotten to be removed. gtk-doc (1.33.1-1) unstable; urgency=medium ... * Remove Debian-specific man pages. Most of them don't actually describe the commands' options, and those that do are sufficiently outdated/incomplete that they are more misleading than useful at this point. More information about the missing symlink: $ chase /usr/share/man/man1/gtkdoc-scangobj.1.gz chase: /usr/share/man/man1/gtkdoc-scanobj.1.gz: No such file or directory $ ls -l /usr/share/man/man1/gtkdoc-scanobj.1.gz ls: cannot access '/usr/share/man/man1/gtkdoc-scanobj.1.gz': No such file or directory $ apt-file search gtkdoc-scanobj ; echo $? 1 $ apt-file search gtkdoc-scangobj ; echo $? gtk-doc-tools: /usr/bin/gtkdoc-scangobj gtk-doc-tools: /usr/share/man/man1/gtkdoc-scangobj.1.gz 0 -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gtk-doc-tools depends on: ii docbook-to-man1:2.0.0-45 ii docbook-xml 4.5-9 ii docbook-xsl 1.79.2+dfsg-1 ii pkg-config0.29.2-1 ii python3 3.9.0-3 ii python3-lxml 4.6.1-1 ii python3-pygments 2.7.1+dfsg-1 ii xsltproc 1.1.34-4 gtk-doc-tools recommends no packages. Versions of packages gtk-doc-tools suggests: pn dblatex -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#976157: thunderbird: Thunderbird refuses to decrypt inline PGP message
Hello Jeff, Am 02.12.20 um 18:11 schrieb Jeff: > No. They are all plain text. then I even more don't understand why people still using inline PGP... Self-made problems. >> Without further information what the message is build of you have >> problems with we can't do any useful error detection. >> I expect you will have the same problems if you use an upstream version >> of Thunderbird from Mozilla. If yes your bug report should go into >> Bugzilla so MZLNA have a chance to fix the underlying issue (if possible). > > Enigmail had no problem with these messages, and if Thunderbird cannot > recognise them, then I cannot read them any more (including all the > historical ones sitting my my mailbox.) Yes, as said, I can't do anything if we can't readjust that behaviour. I expect that the outcome is the same if you are using a prebuild version from upstream. I'm also quite sure this all isn't a Debian specific issue. Means, the report need to get addressed upstream. So, please check if the same issue is happen if you are using from MZLNA. > https://download-origin.cdn.mozilla.net/pub/thunderbird/releases/78.5.1/linux-x86_64/ If the issue is also happen here please raise a report in the Bugzilla issue tracker from Mozilla. > https://bugzilla.mozilla.org/home Afterwards we can connect this Debian report with the upstream report and will get informed once the status in Bugzilla is changing. -- Regards Carsten
Bug#976260: RFS: opentype-sanitizer/8.1.0-1 [ITP] -- tools to validate and sanitize OTF/TTF/WOFF/WOFF2 font files
On Wed, Dec 2, 2020 at 11:45 AM Romain Porte wrote: > dget -x > https://mentors.debian.net/debian/pool/main/o/opentype-sanitizer/opentype-sanitizer_8.1.0-1.dsc The package (and upstream) is missing copyright and license information for all of the test fonts. Some of them contain no license information, so it isn't clear that they are legal for Debian (and upstream) to redistribute. There are no source files for any of them, which could be a violation of DFSG item 2. Some of them are SIL OFL licensed, with reserved font names, which means that modifying them is a license violation unless you also rename them. Personally I would remove the test fonts from the Debian source package. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#832958: "the -bit_depth N option is longer functional."
Package: pngcrush Version: 1.8.13-0.1 Followup-For: Bug #832958 X-Debbugs-Cc: calumlikesapple...@gmail.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Update: it no longer gives that warning, and now simply refuses to recognize the option. Can the manpage please be edited to reflect that? - -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN 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 pngcrush depends on: ii libc62.31-4 ii libpng16-16 1.6.37-3 ii zlib1g 1:1.2.11.dfsg-2 pngcrush recommends no packages. pngcrush suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAl/IZ8UdHGNhbHVtbGlr ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzIVqQ/+MlfNdrOZzxwhhtyL CDZA24EB44ZhHTcHgMJ4GuIpZYnc5mduBQSxrE4FVnJu7lYcQmZNam74HTUk7ivc t0CAwNFV2js5LwnZ48aEuyRoSQW3M/2rE6wyoXdo7BVNo5nEFenJjdkokK47mrhp sOJc1q99usSzaWr+zzN0a6TwBok4Xzp5nHM5f7W7zve6EqZAnhyMc3Is0wGG7998 wMpf0NC/p/Ck/aO/84EhnSRrBkWRLu9GiIEA4AxXYl9DAK1pbm5n4GHBNoGhTT4j PFqksTSmMPpTCqG3cSzG/ry6bbtMeQtwEO3CBhTUEA5P+cDhdjv8N2ucERe2DgE1 VN/nfsyGvMH0efI6MJjG9PVN7s/QB//9QuJgEbdReDzAuPfqjmUiqqLpL0RuyhqR KjSGfuFNjhPf9xogz6gPw+seOjuiE+RlSmFMNDfLsimOcrvMtz2/9vavo9MrWfEM r+01R242m2RxMlkLyVWIBifu2qiiRhYI23LGu8BdSUbgZwgPNXGa243gZ8VjMb6V SjjwmwHzDwOMUKx67MVh9GObS4NEmUHv8pM/KlsNWhxBz7+TZhkC7otWVH0d+syi OaFg5bT1Th7azv/Yu6JS3quBO2MKRjAo+dJKA1jDZ+UzZnAiriQvGRdA0U7izxxm NW/mPNqEaJaCcUOWktqDhrQo+s8= =C873 -END PGP SIGNATURE-
Bug#976303: kodi: FTBFS during separate binary-indep build
Dear colleagues, On Thu, 03 Dec 2020 03:34:52 +0100 Andreas Beckmann wrote: > Probably some files are being accessed that are not created in this mode: I have already fixed it and a bunch of another issues but I have not uploaded the fix yet to Salsa. Today I am going to build the latest trunk for my staging repo and push beta1 to unstable after that closing this bug. -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#971570: [Pkg-julia-devel] Bug#971570: Bug#971570: julia: libgit2 1.0 transition
severity 971570 normal retitle 971570 check whether binNMU transition to libgit2 1.0 is successful thanks Ajusting severity according to what I wrote. I keep the bug open to remind us that we should check that the binNMU facility actually worked. Nothing else should be necessary. Norbert On Wed, 02 Dec 2020, Norbert Preining wrote: > Hi Ximin, > > On Tue, 01 Dec 2020, Ximin Luo wrote: > > Control: severity -1 serious > > I am very doubtful what you are doing here. > > Have you tested julia with libgit2 1.0? Are there build errors? > > I don't see any, the package builds fine with libgit2-dev 1.0.1+dfsg.1-1 > from experimental, I just did a test build. > > That means, the transition would require a simple binary rebuild, > without any action on our side. > > I tend to close this bug as incorrect. > > Best > > Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#976305: atop: FTBFS twice in a row
Source: atop Version: 2.5.0-1+exp1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, atop FTBFS twice in a row because 'make clean' does not remove the generated 'atopsar': fakeroot debian/rules clean dh clean debian/rules override_dh_auto_clean make[1]: Entering directory '/build/atop-2.5.0' dh_auto_clean make -j3 clean make[2]: Entering directory '/build/atop-2.5.0' rm -f *.o atop atopacctd atopconvert make[2]: Leaving directory '/build/atop-2.5.0' rm -f debian/atop.service debian/atopacct.service debian/atop.init debian/atopacct.init rm -f atop make[1]: Leaving directory '/build/atop-2.5.0' dh_clean dpkg-source -b . dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building atop using existing ./atop_2.5.0.orig.tar.gz dpkg-source: info: using patch list from debian/patches/series dpkg-source: error: cannot represent change to atopsar: dpkg-source: error: new version is symlink to atop dpkg-source: error: old version is nonexistent dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 127 Andreas atop_2.5.0-1+exp1_twice.log.gz Description: application/gzip
Bug#976304: RFA: gzip -- GNU compression utilities
Package: wnpp Severity: normal I took over the Debian gzip package on 2 December 1995, which means that as of today, I've taken care of it for 25 years! The package is in good shape, though a number of bugs have accumulated over the years that I have neither the time nor motivation remaining to address... so, like some other packages I've maintained for a long time, I've decided to offer the gzip package for adoption. Because this is a 'required' package, and has a special variant needed for at least one Debian installation method, I would like to suggest that anyone considering taking over the package have a look at the current sources and open bug reports first, then reach out to me for a conversation before making a commitment to take over the package. Bdale
Bug#976303: kodi: FTBFS during separate binary-indep build
Source: kodi Version: 2:19.0~alpha3+dfsg1-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, kodi/experimental FTBFS during a separate binary-indep build, i.e. dpkg-buildpackage -A https://buildd.debian.org/status/fetch.php?pkg=kodi=all=2%3A19.0%7Ealpha3%2Bdfsg1-1=1605638298=0 Probably some files are being accessed that are not created in this mode: debian/rules override_dh_gencontrol make[1]: Entering directory '/<>' debian/dh-addon/dh_kodiaddon_depends No such file or directory at debian/dh-addon/dh_kodiaddon_depends line 66. make[1]: *** [debian/rules:190: override_dh_gencontrol] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:95: binary-indep] Error 2 Andreas
Bug#976302: astra-toolbox: FTBFS twice in a row
Source: astra-toolbox Version: 1.8.3-3 Severity: serious Tags: ftbfs Justification: fails to build from source Hi, astra-toolbox FTBFS twice in a row. After the first (and successful) build, the package source gets cleaned but leaves some artifacts lying around which breaks the subsequent dpkg-source call. The override_dh_auto_clean target seems to miss some actions to undo the effects of the autogen.sh call in the override_dh_auto_configure target. fakeroot debian/rules clean dh clean --sourcedirectory=build/linux debian/rules override_dh_auto_clean make[1]: Entering directory '/build/astra-toolbox-1.8.3' dh_auto_clean --builddirectory build-python dh_auto_clean --builddirectory build-octave make[1]: Leaving directory '/build/astra-toolbox-1.8.3' dh_autoreconf_clean -O--sourcedirectory=build/linux dh_clean -O--sourcedirectory=build/linux dpkg-source -b . dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building astra-toolbox using existing ./astra-toolbox_1.8.3.orig.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: error: cannot represent change to build/linux/install-sh: dpkg-source: error: new version is symlink to /usr/share/libtool/build-aux/install-sh dpkg-source: error: old version is nonexistent dpkg-source: error: cannot represent change to build/linux/config.sub: dpkg-source: error: new version is symlink to /usr/share/libtool/build-aux/config.sub dpkg-source: error: old version is nonexistent dpkg-source: error: cannot represent change to build/linux/config.guess: dpkg-source: error: new version is symlink to /usr/share/libtool/build-aux/config.guess dpkg-source: error: old version is nonexistent dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 127 Andreas astra-toolbox_1.8.3-3_twice.log.gz Description: application/gzip
Bug#976285: please enable redis plugin
On Thursday, 3 December 2020 6:44:45 AM AEDT Felix Zielcke wrote: > it looks like Zabbix is compiled without the redis plugin. No, it looks like there is no special support for Redis in zabbix-agent. You probably need (Golang-based) Zabbix Agent 2, which is not provided by Debian package (yet). > From /usr/share/doc/zabbix-frontend-php/templates/db/redis/README.md.gz > Test availability: `zabbix_get -s redis-master -k redis.ping` > > # `zabbix_get -s redis-master -k redis.ping` > zabbix_get [2264555]: Get value error: cannot resolve [redis-master] That error indicates that your network have no "redis-master" host (or that there is no DNS record for it). > And the template indeed doestn't work. That's hardly a surprise if "redis master" don't resolve... -- All the best, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- If liberty means anything at all, it means the right to tell people what they do not want to hear. -- George Orwell signature.asc Description: This is a digitally signed message part.
Bug#975994: zimlib breaks python-libzim autopkgtest: segfaults
Hi, On 11/30/20 11:25 AM, Paul Gevers wrote: That versioned Depends relation should be enough for CI. But what about users that do a partial upgrade? (Yes, I know, officially not supported in Debian, but in practice it works pretty well). Good point. I'll do that as well. -- Kunal
Bug#976301: Fix invalid `changelog` format example
Package: debian-policy
Control: tag -1 + patch
Hello,
I am seeking seconds for the following patch:
diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index edae8c1..1265c5e 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -126,7 +126,7 @@ That format is a series of entries like this:
[blank line(s), included in output of dpkg-parsechangelog]
* even more change details
[optional blank line(s), stripped]
[]{+[space]--+} maintainer name [two [-spaces]
date-]{+spaces]date+}
``package`` and ``version`` are the source package name and version
number.
Bug#976135: Breaks tt-rss
tag 976135 + patch
thanks
On Mon, 30 Nov 2020 09:45:48 +0100 Andrey Rahmatullin
wrote:
[...]
>
> PHP Fatal error: Uncaught Error: Call to a member function evaluate() on
> null in /usr/share/php/php-php-gettext/gettext.php:325
This is a silly error I made in a patch to fix the security issue with
plurals evaluation. I never caught the error as I didn't test
non-English locales. A patch is now available for merge.
https://salsa.debian.org/php-team/pear/php-gettext/-/merge_requests/2
As a workaround to the issue, either use English language until this
issue is fixed or modify the file
/usr/share/php/php-php-gettext/gettext.php line 300
from
if ($this->pluralheader !== NULL) {
to
if ($this->pluralheader === NULL) {
Thanks,
--
Sunil
Bug#976300: volk: FTBFS during separate binary-indep build
Source: volk Version: 2.4.0-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, volk/experimental FTBFS during a separate binary-indep build, i.e. dpkg-buildpackage -A https://buildd.debian.org/status/fetch.php?pkg=volk=all=2.4.0-2=1606779232=0 CMake Error at cmake_install.cmake:54 (file): file INSTALL cannot find "/<>/obj-x86_64-linux-gnu/include/volk/volk.h": No such file or directory. Also the unittests fail in this mode since volk_test_all has not been built. Andreas
Bug#975727: util-linux: [util-linux] 2.36.1-1 breaks davfs mount
Package: util-linux Version: 2.36.1-2 Followup-For: Bug #975727 X-Debbugs-Cc: hyil...@gmail.com Just pulled to util-linux 2.36.1-2 from unstable into testing and rebooted just to be sure, but am still seeing the same error davfs2 1.6.0-1. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, 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 util-linux depends on: ii libaudit1 1:2.8.5-3.1 ii libblkid1 2.36.1-1 ii libc6 2.31-4 ii libcap-ng0 0.7.9-2.2 ii libcrypt1 1:4.4.17-1 ii libmount1 2.36.1-1 ii libpam0g 1.3.1-5 ii libselinux13.1-2+b1 ii libsmartcols1 2.36.1-1 ii libsystemd0246.6-4 ii libtinfo6 6.2+20200918-1 ii libudev1 246.6-4 ii libuuid1 2.36.1-1 ii login 1:4.8.1-1 ii zlib1g 1:1.2.11.dfsg-2 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.1-2 ii kbd 2.3.0-3 pn util-linux-locales -- no debconf information
Bug#976299: xalan: FTBFS during separate binary-indep build
Source: xalan Version: 1.12-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, xalan FTBFS during a separate binary-indep build, i.e. dpkg-buildpackage -A, because it tries to run unittests whose binaries have not been built. This will be a problem for a source-only upload since the buildds will build the 'amd64' and the 'all' binary packages in separate runs. dh_auto_test -i cd obj-x86_64-linux-gnu && make -j3 test ARGS\+=-j3 make[1]: Entering directory '/build/xalan-1.12/obj-x86_64-linux-gnu' Running tests... /usr/bin/ctest --force-new-ctest-process -j3 Test project /build/xalan-1.12/obj-x86_64-linux-gnu Start 1: CompileStylesheet Could not find executable /build/xalan-1.12/obj-x86_64-linux-gnu/samples/CompileStylesheet Looked in the following places: /build/xalan-1.12/obj-x86_64-linux-gnu/samples/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/Release/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/Release/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/Debug/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/Debug/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/MinSizeRel/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/MinSizeRel/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/RelWithDebInfo/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/RelWithDebInfo/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/Deployment/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/Deployment/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/Development/CompileStylesheet /build/xalan-1.12/obj-x86_64-linux-gnu/samples/Development/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/Release/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/Release/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/Debug/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/Debug/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/MinSizeRel/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/MinSizeRel/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/RelWithDebInfo/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/RelWithDebInfo/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/Deployment/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/Deployment/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/Development/CompileStylesheet build/xalan-1.12/obj-x86_64-linux-gnu/samples/Development/CompileStylesheet Unable to find executable: /build/xalan-1.12/obj-x86_64-linux-gnu/samples/CompileStylesheet 1/21 Test #1: CompileStylesheet ***Not Run 0.00 sec [...] Andreas xalan_1.12-1_indep.log.gz Description: application/gzip
Bug#972134: chromium: please, consider moving the package to team-maintainance to properly maintain it
Hi, Is there any dependency that needs to be packaged for the package to be updated? I remember seeing on the tracker that there are packages in python2 that according to a Debian Developer told me that it is not being allowed to enter the official repositories. The number of CVEs continues to rise. I would be happy to help.
Bug#928439: Bestätige dein Abonnement von Simple Thoughts
Hallo. Du hast dich gerade dazu entschlossen, Benachrichtigungen von diesem Blog zu erhalten. Wenn du jetzt den Bestätigungslink klickst, wirst du bei jedem neuen Beitrag eine Benachrichtigung per E-Mail erhalten. Um diese Funktion zu aktivieren, klicke auf „Folgen bestätigen“. Solltest du diese E-Mail fälschlicherweise erhalten haben, kannst du diese Nachricht einfach ignorieren. Blog: Simple Thoughts URL: http://simplethoughts.de Abonnement bestätigen: https://subscribe.wordpress.com/?key=40a94e718bff6a2f9ce5c403ce94fe39=928439%40bugs.debian.org=de=3270e919f9bb03d4db2814dfe99c8abd Wenn du diese E-Mails nicht mehr erhalten möchtest: https://subscribe.wordpress.com/?key=40a94e718bff6a2f9ce5c403ce94fe39=928439%40bugs.debian.org=de Wenn du alle Blogs und Beiträge, denen du im Web folgst, an einem einzelnen Ort sehen möchtest, registriere dich für ein WordPress.com-Konto. (http://wordpress.com/signup/?ref=lof)
Bug#976298: Internal microphone not detected on Thinkpad T14 Gen 1
Package: linux-image-5.9.0-0.bpo.2-amd64-unsigned Version: 5.9.6-1~bpo10+1 No driver is found for Renoir audio processor in buster-backports 5.9 kernel : $ lshw -c multimedia *-usb description: Vidéo produit: Integrated Camera fabriquant: Chicony Electronics Co.,Ltd. identifiant matériel: 2 information bus: usb@2:2 version: 58.18 numéro de série: 0001 fonctionnalités: usb-2.01 configuration: driver=uvcvideo maxpower=500mA speed=480Mbit/s *-multimedia:0 description: Audio device produit: Advanced Micro Devices, Inc. [AMD/ATI] fabriquant: Advanced Micro Devices, Inc. [AMD/ATI] identifiant matériel: 0.1 information bus: pci@:07:00.1 version: 00 bits: 32 bits horloge: 33MHz fonctionnalités: pm pciexpress msi bus_master cap_list configuration: driver=snd_hda_intel latency=0 ressources: irq:100 mémoire:fd3c8000-fd3cbfff *-multimedia:1 NON-RÉCLAMÉ description: Multimedia controller produit: Advanced Micro Devices, Inc. [AMD] fabriquant: Advanced Micro Devices, Inc. [AMD] identifiant matériel: 0.5 information bus: pci@:07:00.5 version: 01 bits: 32 bits horloge: 33MHz fonctionnalités: pm pciexpress msi cap_list configuration: latency=0 ressources: mémoire:fd38-fd3b *-multimedia:2 description: Audio device produit: Advanced Micro Devices, Inc. [AMD] fabriquant: Advanced Micro Devices, Inc. [AMD] identifiant matériel: 0.6 information bus: pci@:07:00.6 version: 00 bits: 32 bits horloge: 33MHz fonctionnalités: pm pciexpress msi bus_master cap_list configuration: driver=snd_hda_intel latency=0 ressources: irq:101 mémoire:fd3c-fd3c7fff $ lspci -k -s 07:00.5 07:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor (rev 01) Subsystem: Lenovo Raven/Raven2/FireFlight/Renoir Audio Processor But on a custom 5.9.11 kernel with||"AMD Audio Coprocessor - Renoir support"| and "AMD Renoir support for DMIC" enabled : $ lshw -c multimedia *-multimedia:0 description: Audio device produit: Advanced Micro Devices, Inc. [AMD/ATI] fabriquant: Advanced Micro Devices, Inc. [AMD/ATI] identifiant matériel: 0.1 information bus: pci@:07:00.1 version: 00 bits: 32 bits horloge: 33MHz fonctionnalités: bus_master cap_list configuration: driver=snd_hda_intel latency=0 ressources: irq:120 mémoire:fd3c8000-fd3cbfff *-multimedia:1 description: Multimedia controller produit: Advanced Micro Devices, Inc. [AMD] fabriquant: Advanced Micro Devices, Inc. [AMD] identifiant matériel: 0.5 information bus: pci@:07:00.5 version: 01 bits: 32 bits horloge: 33MHz fonctionnalités: bus_master cap_list configuration: driver=snd_rn_pci_acp3x latency=0 ressources: irq:102 mémoire:fd38-fd3b *-multimedia:2 description: Audio device produit: Advanced Micro Devices, Inc. [AMD] fabriquant: Advanced Micro Devices, Inc. [AMD] identifiant matériel: 0.6 information bus: pci@:07:00.6 version: 00 bits: 32 bits horloge: 33MHz fonctionnalités: bus_master cap_list configuration: driver=snd_hda_intel latency=0 ressources: irq:121 mémoire:fd3c-fd3c7fff $ lspci -k -s 07:00.5 07:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor (rev 01) Subsystem: Lenovo Raven/Raven2/FireFlight/Renoir Audio Processor Kernel driver in use: snd_rn_pci_acp3x Kernel modules: snd_rn_pci_acp3x Once the Renoir audio processor enabled, the internal microphone is visible and functionnal. ||I suggest to enable "AMD Audio Coprocessor - Renoir support" and |||"AMD Renoir support for DMIC"| in upcoming kernels|||.| Miscellaneous informations : |$ lsb_release -d Description:Debian GNU/Linux 10 (buster) # dmidecode -s system-manufacturer; dmidecode -s system-product-name; dmidecode -s system-version LENOVO 20UDCTO1WW ThinkPad T14 Gen 1
Bug#976255: Fwd: Re: Minimun hardware requirements innaccurate as documented
Hi all, I just wanted to make sure you all got this, as i just read the other emails. I hope i didnt miss anyone. You can go ahead and close it. And amending what I said below, thanks for adding the note about the livecd installer requirements. You guys are very fast and very responsive. Thanks again for all the great work you do. Jim Original message From: Jim Date: 12/2/20 3:10 PM (GMT-08:00) To: Samuel Thibault Subject: Re: Minimun hardware requirements innaccurate as documented Ok thanks. I guess i missed that the 512M didnt apply to the installer on the livecd. I figured since it said 512m for gui and 256m non gui that the live cd fell under gui. Perhaps that should be noted somewhere if it isnt on the page link i referenced? You can go ahead and close it though, as it isnt a bug i guess-:) Thank you and your team for all the hard work you do. It's a terrific product. Jim
Bug#975322: broken mlterm 3.9 definitions
On Wed, Dec 02, 2020 at 09:27:49PM +0100, Yuri D'Elia wrote: > On Sat, Nov 21 2020, Sven Joachim wrote: > >> If the mlterm package changed that ut-default setting, then providing your > >> own termcap settings may have reset the behavior to match the compiled-in > >> NON-ut default. > > > > That seems to have hit the mark. Indeed, if ":ut" is added to Yuri's > > termcap example, mlterm works correctly again. > > > > Yuri, would you like to bring this to the attention of the mlterm > > developers? > > So I think there's another problem here. The reason I had to change > ~/.mlterm/termcap was to fix the behavior of F[1-4] keys by making > mlterm send a different sequence. > > mlterm sends ^[OP for F1, but all mlterm terminfo definitions seem to > expect \[[11~ I noticed that earlier, but was busy. Revisiting the topic: a) just considering Debian, I could have overlooked F1-F4, because mlterm hardcodes shift/control modifiers for those keys to do special (and apparently undocumented) operations. b) the developer used to provide a termcap and terminfo, but removed that a while back: commit 00cbfd76d180bbf9025324a863cd124ec027a7f7 Author: arakiken Date: Sat Nov 21 23:51:43 2015 +0900 * README.ja, man/mlterm.1: Updated. * doc/term: Removed. * ml_vt100_parser.c: Conversion from Unicode to ISCII is disabled if use_ctl = false. (the termcap/terminfo were in doc/term) c) of course those were incomplete or in error (which is what I test for). d) not only are those keys hard-coded, but a look at the source tells me that they may depend upon the system on which mlterm was built. https://github.com/arakiken/mlterm/blob/f2bb9eba4e6918ad2df5149a3e1f02c8b130a87a/uitoolkit/fb/ui_display.c#L932 (look for "XK_F3", for instance) However, that's in the "fb" GUI. I don't see anything relevant in uitoolkit/xlib or in the input-method code. e) at one point, the terminfo was (more) correct. That changed a while back: commit 19bfa85d50d05862126f59a9c7d4f0275e2c1faa Author: arakiken Date: Tue Sep 4 07:20:10 2012 +0900 * MLTerm.java: Application-cursor-keys sequences for Home and End keys are ^[OH and ^[OF instead of ^[[H and ^[[F. * x_screen.c, x_termcap.c, etc/termcap: - code cleanup - ML_F1(k1), ML_F2(k2), ML_F3(k3), ML_F4(k4) are added. - Application-cursor-keys sequences for XK_Home and XK_End are ^[OH and ^[OF instead of ^[[H and ^[[F. - Following key sequences are changed. XK_BackSpace: \x7f -> \x08 XK_Home: \x1bOH -> \x1b[H XK_End:\x1bOF -> \x1b[F XK_F1: \x1b[11~ -> \x1bOP XK_F2: \x1b[12~ -> \x1bOQ XK_F3: \x1b[13~ -> \x1bOR XK_F4: \x1b[14~ -> \x1bOS * x_screen.c: PAGE_DOWN shortcut is checked even if it is not backscroll mode. * ml_edit.c, ml_edit_util.c, ml_line.c: ml_line_t::is_continued_to_next flag is reset ml_edit_clear_line_to_right(), ml_edit_clear_below(), ml_edit_clear_above(), ml_edit_fill_all() and ml_edit_clear_lines() by using the new function ml_line_clear_with() instead of ml_line_fill(). I had that (or a test-report) in my notes in March 2014, but on closing out those notes, overlooked the F1-F4 change. > ls mlterm* | xargs -l infocmp | grep kf1= > kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~, > kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~, > kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~, > kcuu1=\EOA, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, > kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~, > > Either all these definitions are broken, or I need some enlightenment? > If I remove my customization, bce works as it should, but F[1-4] are > broken. > > Sure I can also add :ut to my ~/.mlterm/termcap, then mlterm sends what > the terminfo says, but it doesn't look like I'm fixing the right thing > here. yes. It would be nice if mlterm's developer documented things, so that it's not necessary to read the source code and experiment for a while to develop a terminal description. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#976295: ocl-icd-libopencl1: add docs for AMD proprietary OpenCL library, since mesa's doesn't work
Ximin Luo: > [..] > > 4. Finally run clinfo(1) with the right LD_LIBRARY_PATH to check that it > worked. >You should get something like: > > >$ LD_LIBRARY_PATH=/opt/amdgpu-pro/lib/x86_64-linux-gnu/ clinfo -l >Platform #0: AMD Accelerated Parallel Processing > `-- Device #0: Ellesmere >Platform #1: Clover > `-- Device #0: Radeon RX 580 Series (POLARIS10, DRM 3.39.0, > 5.9.0-4-amd64, LLVM 11.0.0) > > >Clover being what is output by mesa-opencl-icd, unfortunately it doesn't > work >e.g. leela-zero runs into errors with it. > > 5. To avoid needing LD_LIBRARY_PATH, edit /etc/OpenCL/vendors/amdocl*.icd to >instead contain the full path to the particular library. > Actually, at least for the latest versions of these packages, I noticed that LD_LIBRARY_PATH is no longer necessary, they install config files into /etc/ld.so.conf.d/ that automatically adds them to the path. This is more reliable in the long run that the full-path solution, because the full-paths include version numbers that might change after an update. Also, you probably want to remind the user in step (3) to delete that sources.list.d entry afterwards, otherwise any local user that can write to the path, can inject extra packages into the apt cache. Ximin -- GPG: ed25519/56034877E1F87C35 https://github.com/infinity0/pubkeys.git
Bug#976297: RFP: ripgrep-all -- search in PDFs, E-Books, and archives
Package: wnpp Severity: wishlist * Package name: ripgrep-all Version : 0.9.6 (2020-05-19) Upstream Author : phiresky * URL : https://github.com/phiresky/ripgrep-all * License : AGPL-3 Programming Lang: Rust Description : search in PDFs, E-Books, and archives rga is a line-oriented search tool that allows you to look for a regex in a multitude of file types. rga wraps the awesome ripgrep and enables it to search in pdf, docx, sqlite, jpg, movie subtitles (mkv, mp4), etc. See also: https://phiresky.github.io/blog/2019/rga--ripgrep-for-zip-targz-docx-odt-epub-jpg/
Bug#976296: blender: Segmentation fault when importing background image
Package: blender Version: 2.83.5+dfsg-4+b1 Severity: normal X-Debbugs-Cc: wiiliamchung...@gmail.com Dear Maintainer, Starting with a default general setup, selecting an image from the context menu crashes blender with a segmentation fault: /tmp/blender.crash.txt: http://paste.debian.net/1175346/ -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-3-amd64 (SMP w/24 CPU threads) Kernel taint flags: 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 blender depends on: ii blender-data 2.83.5+dfsg-4 ii fonts-dejavu 2.37-2 ii libavcodec58 10:4.3.1-dmo3 ii libavdevice58 10:4.3.1-dmo3 ii libavformat58 10:4.3.1-dmo3 ii libavutil56 10:4.3.1-dmo3 ii libboost-locale1.71.0 1.71.0-7+b1 ii libc6 2.31-4 ii libfftw3-double3 3.3.8-2 ii libfreetype6 2.10.2+dfsg-4 ii libgcc-s1 10.2.0-18 ii libgl11.3.2-1 ii libglew2.12.1.0-4+b1 ii libgomp1 10.2.0-18 ii libilmbase25 2.5.3-2 ii libjack-jackd2-0 [libjack-0.125] 1.9.16~dfsg-1 ii libjemalloc2 5.2.1-1 ii libjpeg62-turbo 1:2.0.5-1.1 ii libopenal11:1.19.1-2 ii libopencolorio1v5 1.1.1~dfsg0-6+b3 ii libopenexr25 2.5.3-2 ii libopenimageio2.2 2.2.7.0+dfsg-2+b2 ii libopenjp2-7 2.3.1-1 ii libopenvdb7.1 7.1.0-2+b2 ii libosdcpu3.4.33.4.3-3 ii libosdgpu3.4.33.4.3-3 ii libpcre3 2:8.39-13 ii libpng16-16 1.6.37-3 ii libpython3.9 3.9.0-5 ii libsdl2-2.0-0 2.0.12+dfsg1-4 ii libsndfile1 1.0.28-8 ii libspnav0 0.2.3-1+b2 ii libstdc++610.2.0-18 ii libswscale5 10:4.3.1-dmo3 ii libtbb2 2020.3-1 ii libtiff5 4.1.0+git191117-2 ii libx11-6 2:1.6.12-1 ii libxfixes31:5.0.3-2 ii libxi62:1.7.10-1 ii libxml2 2.9.10+dfsg-6.2 ii libxrender1 1:0.9.10-1 ii libxxf86vm1 1:1.1.4-1+b2 ii zlib1g1:1.2.11.dfsg-2 blender recommends no packages. blender suggests no packages. -- no debconf information
Bug#971890: RFS: tensorwatch/0.9.0-1 [ITP] -- Debug, monitor and visualize for Python Machine Learning
On Fri, Oct 09, 2020 at 08:09:10AM +0200, Gürkan Myczko wrote: > * Package name: tensorwatch >Version : 0.9.0-1 > tensorwatch (0.9.0-1) unstable; urgency=medium > . >* Initial release. (Closes: #931009) autopkgtest [00:34:21]: test autodep8-python3: [--- Testing with python3.8: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/tensorwatch/__init__.py", line 26, in from .embeddings.tsne_utils import get_tsne_components File "/usr/lib/python3/dist-packages/tensorwatch/embeddings/tsne_utils.py", line 4, in from sklearn.manifold import TSNE ModuleNotFoundError: No module named 'sklearn' autopkgtest [00:34:22]: test autodep8-python3: ---] 喵! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A white dwarf seeks a red giant for a binary relationship. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#976295: ocl-icd-libopencl1: add docs for AMD proprietary OpenCL library, since mesa's doesn't work
Package: ocl-icd-libopencl1 Version: 2.2.13-1 Severity: important Dear Maintainer, Currently Debian does not have a working OpenCL library for a lot of AMD graphics drivers - mesa-opencl-icd does not work or often breaks; and ROCm is not yet packaged in Debian. The AMDGPU PRO OpenCL drivers work with the open source AMDGPU driver that is already part of Linux, but the official installation instructions are a bit convoluted. Here are simpler ones, please include them in the docs of this package: 1. Look for the latest linux drivers on the AMD website. For example at the time of writing this is: https://www.amd.com/en/support/kb/release-notes/rn-amdgpu-unified-linux-20-45 2. Download the ones for Ubuntu, e.g.: https://drivers.amd.com/drivers/linux/amdgpu-pro-20.45-1164792-ubuntu-20.04.tar.xz 3. Unpack the tarball. This contains a ./amdgpu-pro-install script, however it will attempt to install the proprietary driver AMDGPU-PRO which is not necessary for us. (And it likely won't work, due to wanting a too-old version of linux than is in Debian Unstable.) Instead, we can install the unpacked Debian packages directly. You will need to install either: - opencl-orca-amdgpu-pro-icd, for older GPUs, or - opencl-rocr-amdgpu-pro, for newer ones. They can be installed both simultaneously in case you aren't sure which one works, or you need to switch GPUs constantly. Since you also need to install their dependencies, it's easiest to do this by adding: deb [ trusted=yes ] file:/path/where/you/extracted/ ./ to /etc/apt/sources.list.d/amdgpu-pro-local.list then running `apt-get update`. Then run `apt-get install opencl-orca-amdgpu-pro-icd opencl-rocr-amdgpu-pro`. 4. Finally run clinfo(1) with the right LD_LIBRARY_PATH to check that it worked. You should get something like: $ LD_LIBRARY_PATH=/opt/amdgpu-pro/lib/x86_64-linux-gnu/ clinfo -l Platform #0: AMD Accelerated Parallel Processing `-- Device #0: Ellesmere Platform #1: Clover `-- Device #0: Radeon RX 580 Series (POLARIS10, DRM 3.39.0, 5.9.0-4-amd64, LLVM 11.0.0) Clover being what is output by mesa-opencl-icd, unfortunately it doesn't work e.g. leela-zero runs into errors with it. 5. To avoid needing LD_LIBRARY_PATH, edit /etc/OpenCL/vendors/amdocl*.icd to instead contain the full path to the particular library. Best, Ximin -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ocl-icd-libopencl1 depends on: ii libc6 2.31-4 ocl-icd-libopencl1 recommends no packages. Versions of packages ocl-icd-libopencl1 suggests: ii mesa-opencl-icd [opencl-icd] 20.2.3-1 -- no debconf information
Bug#976072: closed by Debian FTP Masters (reply to David Steele ) (Bug#976072: fixed in topydo 0.13-4)
Control: reopen -1 Control: fouund -1 0.13-4 Hi David Debian Bug Tracking System wrote: >* Accommodate autopkgtests with the old todo.txt-base (Closes: #976111, > #976072). #976072 had nothing todo with autopkgtests. And the issue is still there in 0.13-4: Preparing to unpack .../archives/topydo_0.13-4_all.deb ... Unpacking topydo (0.13-4) over (0.13-2) ... Setting up topydo (0.13-4) ... update-alternatives: warning: forcing reinstallation of alternative /usr/bin/topydo because link group todo.txt is broken update-alternatives: warning: not removing /usr/bin/todo.txt-helper since it's not a symlink update-alternatives: error: alternative todo can't be master: it is a slave of todo.txt dpkg: error processing package topydo (--configure): installed topydo package post-installation script subprocess returned error exit status 2 Processing triggers for man-db (2.9.3-2) ... Errors were encountered while processing: topydo Hence reopening. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#976294: gitlab: fails to install: Could not find gem 'faraday (~> 0.12)'
Package: gitlab Version: 13.3.9-1 Severity: important Dear Maintainer, I am unable to install latest gitlab from unstable. Is there any workaround to get this working? * What led up to the situation? The server was working on buster, and updated to testing (another service on same server) broke gitlab. Trying to upgrade to a new (working) version. * What exactly did you do (or not do) that was effective (or ineffective)? Try to install latest gitlab from unstable: # LANG=C apt -t unstable install gitlab Reading package lists... Done Building dependency tree Reading state information... Done gitlab is already the newest version (13.3.9-1). The following package was automatically installed and is no longer required: libgumbo1 Use 'apt autoremove' to remove it. 0 upgraded, 0 newly installed, 0 to remove and 104 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Setting up gitlab (13.3.9-1) ... fatal: not a git repository (or any of the parent directories): .git fatal: not a git repository (or any of the parent directories): .git Could not find gem 'faraday (~> 0.12)' in any of the gem sources listed in your Gemfile. dpkg: error processing package gitlab (--configure): installed gitlab package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: gitlab E: Sub-process /usr/bin/dpkg returned an error code (1) All ruby-faraday has been installed from unstable too: LANG=C apt search ^ruby-faraday Sorting... Done Full Text Search... Done ruby-faraday/unstable,now 1.1.0-3 all [installed,automatic] HTTP/REST API client library ruby-faraday-cookie-jar/unstable,testing,stable,oldstable,unstable,unstable,unstable,now 0.0.6-1 all [installed,automatic] Manages client-side cookie jar for Faraday HTTP client ruby-faraday-middleware/unstable,now 1.0.0-2 all [installed,automatic] various middleware for Faraday HTTP/REST library ruby-faraday-middleware-aws-sigv4/unstable,testing,now 0.3.0-2 all [installed,automatic] Faraday middleware for AWS Signature Version 4 using aws-sigv4 ruby-faraday-middleware-multi-json/unstable,testing,stable,oldstable,unstable,unstable,unstable,now 0.0.6-2 all [installed,automatic] response JSON parser using MultiJson and FaradayMiddleware -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gitlab depends on: ii asciidoctor 2.0.10-2 ii bc 1.07.1-2+b2 ii bundler 2.1.4-2 ii bzip21.0.8-4 ii dbconfig-pgsql 2.0.17 ii debconf [debconf-2.0]1.5.74 ii gitlab-common13.4.6+dfsg1-2 ii gitlab-workhorse 8.46.0+debian-1 ii libjs-bootstrap4 [node-bootstrap]4.5.2+dfsg1-1 ii libjs-codemirror [node-codemirror] 5.58.2+~cs0.23.101-1 ii libjs-popper.js [node-popper.js] 1.16.1+ds-2 ii libjs-uglify 2.8.29-6 ii libruby2.7 [ruby-json] 2.7.2-3 ii lsb-base 11.1.0 ii nginx1.18.0-6 ii nginx-extras [nginx] 1.18.0-6+b1 ii node-autosize4.0.2~dfsg1-4 ii node-axios 0.21.0+dfsg-1 ii node-babel-loader8.2.2-1 ii node-babel7 7.12.9+~cs150.130.99-1 ii node-brace-expansion 2.0.0-1 ii node-cache-loader4.1.0-6 ii node-chart.js2.9.4+dfsg+~cs2.10.1-1 ii node-clipboard 2.0.6+ds+~cs7.6.4-1 ii node-compression-webpack-plugin 3.0.1-3 ii node-core-js 3.8.0-1 ii node-css-loader 3.2.1+~cs14.0.5-2 ii node-d3 5.16.0-1 ii node-d3-scale2.2.2-2 ii node-d3-selection1.4.0-5 ii node-dateformat 3.0.0-2 ii node-exports-loader 1.1.1-2 ii
Bug#976274: libqt5gui5: Please build Qt5 with configure option -xcb-native-painting
Hi Andre! El mié., 2 dic. 2020 13:03, Andre Woebbeking escribió: > Package: libqt5gui5 > Version: 5.15.1+dfsg-4 > Severity: wishlist > X-Debbugs-Cc: woebbek...@web.de > > Dear Maintainer, > > with X2Go Qt5 apps are much slower than X or GTK apps. But there is a > workaround: > setting the environment variable QT_XCB_NATIVE_PAINTING. > > This worked until testing updated to Qt 5.15 because upstream disabled the > automatic > configuration of this feature in commit > 7f948d9effad983477977c3274231401f260c531. > > So please build Qt5 with -xcb-native-painting to make X2Go users happy > again :-) > And what would the drawbacks be? >
Bug#954286: RFP: prometheus-redis-exporter -- Prometheus exporter for Redis metrics
Hi, * Guillem Jover [Thu Mar 19, 2020 at 07:01:25PM +0100]: > On Thu, 2020-03-19 at 18:30:17 +0100, Guillem Jover wrote: > > Package: wnpp > > Severity: wishlist > > Tags: patch > > * Package name: prometheus-redis-exporter > > Version : 1.4.0 > Version : 1.5.2 Version : 1.13.1 > > Upstream Author : Oliver > > * URL : https://github.com/oliver006/redis_exporter > > * License : MIT > > Programming Lang: Go > > Description : Prometheus exporter for Redis metrics > > Prometheus exporter for Redis metrics. Supports Redis 2.x, 3.x, 4.x, and > > 5.x. > > Attached a tested and working packaging (based on the one from the > > prometheus-node-exporter, where Tina agreed to the relicensing to > > match upstream), where only the Uploaders, and ITP bug need to be > > filled, and the packaging imported into git. > Attached an update for the latest upstream which removed the need for > the embedded vendoring. And with few minor packaging improvements. Another update, based on the packaging work by Guillem, and adjusted for the lastest upstream release 1.13.1 (which Build-Depends on a more recent golang-github-gomodule-redigo-dev version, which I uploaded to unstable and is available now). regards -mika- prometheus-redis-exporter_1.13.1-1.debian.tar.xz Description: Binary data signature.asc Description: Digital signature
Bug#962184: [Help] Re: jellyfish FTBFS on 32bit
Hi Andreas, On Thu, 3 Dec 2020 at 03:04, Andreas Tille wrote: > Control: tags -1 help > > Hi, > > I guess this bug is relatively easy to fix by some explicit typing - but > I'm lacking the C++ knowledge to find out where. > Attaching a patch for this, it goes past this. However, the build-time tests fail on 32-bit arches - on exploring the test files, it looks like (with some confidence at least) that its due to large valued numbers in test files, which is (probably) beyond what a 32-bit arch can digest. Maybe it is sensible to disable tests (both build-time and autopkgtest) for that 32-bit arch, but I leave that up to you to check and decide :-) Kind regards Nilesh --- a/include/jellyfish/rectangular_binary_matrix.hpp +++ b/include/jellyfish/rectangular_binary_matrix.hpp @@ -118,7 +118,7 @@ uint64_t *p = _columns; while(*p == 0 && p < _columns + _c) ++p; - return (p - _columns) == _c; + return static_cast(p - _columns) == _c; } // Randomize the content of the matrix --- a/include/jellyfish/mer_dna.hpp +++ b/include/jellyfish/mer_dna.hpp @@ -693,7 +693,7 @@ char buffer[mer.k() + 1]; is.read(buffer, mer.k()); - if(is.gcount() != mer.k()) + if(static_cast(is.gcount()) != mer.k()) goto error; buffer[mer.k()] = '\0'; if(!mer.from_chars(buffer)) --- a/unit_tests/test_mer_dna.cc +++ b/unit_tests/test_mer_dna.cc @@ -466,7 +466,7 @@ // Get bits by right-shifting typename TypeParam::Type cm(m); -for(unsigned int j = 1; j < start; j += 2) +for(unsigned long int j = 1; start>=0 && j < static_cast(start); j += 2) cm.shift_right(0); // Shift by 2 bits typename TypeParam::Type::base_type y = cm.word(0); if(start & 0x1)
Bug#975582: mypaint: MyPaint does not start
Hi maintainer, I understand MyPaint requires version 3.9, which is still unavailable in testing. I believe that dependency should be describe in the package definition however. Currently, the package only depends on python3:any, but not on python3 (>= 3.9) as I believe it should.
Bug#976284: linux-image-5.9.0-4-amd64: kernel oops when handling small 32GB usb drives
Package: src:linux Version: 5.9.11-1 Severity: normal Dear Maintainer, I checked dmesg after mounting a couple of new usb sticks and found a few oops apparently associated with task sync. I will attach the dmesg (gzipped) if reportbug does not do that automatially. -- Package-specific info: ** Version: Linux version 5.9.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-19) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.9.11-1 (2020-11-27) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-4-amd64 root=UUID=5b8060f7-f126-4534-a051-db5d205bd315 ro elevator=deadline ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Notebook product_name: W54_55SU1,SUW product_version: Not Applicable chassis_vendor: Notebook chassis_version: N/A bios_vendor: American Megatrends Inc. bios_version: 4.6.5 board_vendor: Notebook board_name: W54_55SU1,SUW board_version: Not Applicable ** Loaded modules: nls_ascii nls_cp437 vfat fat essiv authenc dm_crypt dm_mod uas usb_storage snd_hrtimer snd_seq snd_seq_device cmac algif_hash algif_skcipher af_alg bnep uinput binfmt_misc btusb btrtl btbcm btintel bluetooth uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common jitterentropy_rng videodev drbg mc ansi_cprng ecdh_generic ecc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel pktcdvd kvm irqbypass crc32_pclmul snd_hda_codec_realtek iwlmvm ghash_clmulni_intel snd_hda_codec_generic aesni_intel ledtrig_audio snd_hda_codec_hdmi libaes cpufreq_ondemand snd_hda_intel crypto_simd snd_intel_dspcfg mac80211 cryptd glue_helper libarc4 rtsx_pci_sdmmc snd_hda_codec xhci_pci iTCO_wdt intel_pmc_bxt rapl mmc_core iTCO_vendor_support iwlwifi xhci_hcd snd_hda_core r8169 ehci_pci watchdog at24 ehci_hcd intel_cstate snd_hwdep realtek snd_pcm mdio_devres sr_mod cfg80211 intel_uncore mei_me cdrom snd_timer i2c_i801 usbcore rtsx_pci libphy sg mei snd rfkill pcspkr soundcore lpc_ich joydev usb_common i2c_smbus wmi battery button ac nfsd msr parport_pc ppdev lp parport auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic i915 i2c_algo_bit drm_kms_helper ahci libahci cec libata crct10dif_pclmul drm crct10dif_common scsi_mod psmouse crc32c_intel evdev serio_raw video ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller [8086:0c04] (rev 06) Subsystem: CLEVO/KAPOK Computer Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller [1558:5455] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel modules: ie31200_edac 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer 4th Gen Core Processor Integrated Graphics Controller [1558:5455] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) Subsystem: CLEVO/KAPOK Computer Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [1558:5455] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) (prog-if 30 [XHCI]) Subsystem: CLEVO/KAPOK Computer 8 Series/C220 Series Chipset Family USB xHCI [1558:5455] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04) Subsystem: CLEVO/KAPOK Computer 8 Series/C220 Series Chipset Family MEI Controller [1558:5455] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
Bug#976293: fontmatrix: segfault on selecting shaping
Package: fontmatrix Version: 0.9.99-2 Severity: normal Hi! When viewing a font that includes shaping variants (fonts-elstob in this case), if you select something from the "shaping" menu (it's grayed otherwise), I get the following splat: hread 1 "fontmatrix" received signal SIGSEGV, Segmentation fault. FMShaperFactory::doShape (this=this@entry=0x563e1d00, aString=...) at ./src/fmbaseshaper.cpp:129 129 ./src/fmbaseshaper.cpp: No such file or directory. (gdb) bt #0 FMShaperFactory::doShape(QString const&) (this=this@entry=0x563e1d00, aString=...) at ./src/fmbaseshaper.cpp:129 #1 0x55704690 in FontItem::glyphs(QString, double, QString) (this=this@entry=0x55f150f0, spec=..., fsize=fsize@entry=14, script=...) at ./src/fontitem.cpp:3746 #2 0x5576c98b in SampleWidget::slotView() (this=0x5641dfc0) at ./src/samplewidget.cpp:422 #3 0x76dab7d0 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x76dab7d0 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x77933171 in QComboBox::currentIndexChanged(int) () Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-rc6-00014-gc4c7126c671f (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages fontmatrix depends on: ii libc62.31-5 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.2+dfsg-4 ii libgcc-s110.2.0-19 ii libjs-jquery 3.5.1+dfsg+~3.5.4-2 ii libqt5core5a 5.15.1+dfsg-4 ii libqt5gui5 5.15.1+dfsg-4 ii libqt5printsupport5 5.15.1+dfsg-4 ii libqt5sql5 5.15.1+dfsg-4 ii libqt5webkit55.212.0~alpha4-7 ii libqt5widgets5 5.15.1+dfsg-4 ii libqt5xml5 5.15.1+dfsg-4 ii libstdc++6 10.2.0-19 fontmatrix recommends no packages. fontmatrix suggests no packages. -- no debconf information
Bug#954678: node-xterm: FTBFS: src/renderer/ColorManager.test.ts(12,18): error TS2694: Namespace '"/usr/share/nodejs/@types/jsdom/ts3.1/index"' has no exported member 'JSDOM'.
Hi Xavier (2020.10.12_02:18:06_-0700) > node-xterm is incompatible with current tsc. It requires ^3.5.3. FWIW, the new upstream 4.9.0 supports typescript 4 https://github.com/xtermjs/xterm.js/releases/tag/4.9.0 But it also comes with new dependencies, and packaging work. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#975331: Installation guide: No instructions for verifying image integrity after download
Control: tags -1 + pending Holger Wansing wrote: > Holger Wansing wrote: > > xloem <0xl...@gmail.com> wrote: > > > It is important to provide a reasonable way to verify the integrity of > > > installation media. > > > > I have prepared a patch, to add a small chapter on this topic to the guide > > (and correct a misleading phrase in chapter 4.2). > > I have overworked the patch a bit, mainly to include "BD images" link only > for > archs which have Bluray images. > Attached. > > Any objections/comments? I have pushed that to git now (with some small modifications). Tagging this bug as pending Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#976283: nmu: tpm2-abrmd tpm2-pkcs11
On 2020-12-03 02:06:25 +0800, Ying-Chun Liu (PaulLiu) wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: binnmu > Severity: normal > > Hello, > > libtpm2-tss bump the soname and renames the package for > transition from buster -> bullseye. Make the package tpm2-abrmd > and tpm2-pkcs11 needs to build against the latest libtpm2-tss. > Please see #974837 > > nmu tpm2-abrmd:2.3.3-1 . ANY . -m 'Rebuild against the new libtpm2-tss, see > #974837.' > nmu tpm2-pkcs11:1.2.0-1 . ANY . -m 'Rebuild against the new libtpm2-tss, > see #974837.' tpm2-pkcs11 needs an upload fixing #975741. Cheers > > Thanks.| > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#957107: crashmail: diff for NMU version 1.7-1.1
Control: tags 957107 + patch
Control: tags 957107 + pending
--
Dear maintainer,
I've prepared an NMU for crashmail (versioned as 1.7-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.
--
Regards
Sudip
diff -Nru crashmail-1.7/debian/changelog crashmail-1.7/debian/changelog
--- crashmail-1.7/debian/changelog 2018-07-19 00:14:23.0 +0100
+++ crashmail-1.7/debian/changelog 2020-12-02 21:49:50.0 +
@@ -1,3 +1,10 @@
+crashmail (1.7-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ftbfs with GCC-10. (Closes: #957107)
+
+ -- Sudip Mukherjee Wed, 02 Dec 2020 21:49:50
+
+
crashmail (1.7-1) unstable; urgency=medium
* New upstream release.
diff -Nru crashmail-1.7/debian/patches/fix_gcc-10.patch
crashmail-1.7/debian/patches/fix_gcc-10.patch
--- crashmail-1.7/debian/patches/fix_gcc-10.patch 1970-01-01
01:00:00.0 +0100
+++ crashmail-1.7/debian/patches/fix_gcc-10.patch 2020-12-02
21:49:20.0 +
@@ -0,0 +1,30 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Sudip Mukherjee
+Bug-Debian: https://bugs.debian.org/957107
+Forwarded: no
+
+---
+
+--- crashmail-1.7.orig/src/crashmail/handle.c
crashmail-1.7/src/crashmail/handle.c
+@@ -94,7 +94,7 @@ bool AddTossNode(struct Area *area,struc
+return(TRUE);
+ }
+
+-time_t lastt;
++static time_t lastt;
+
+ void MakeDirectory(char *dest,uint32_t destsize,char *defdir,char *areaname)
+ {
+--- crashmail-1.7.orig/src/crashmail/pkt.c
crashmail-1.7/src/crashmail/pkt.c
+@@ -551,7 +551,7 @@ struct Pkt *FindPkt(struct Node4D *node,
+return(NULL);
+ }
+
+-time_t lastt;
++static time_t lastt;
+ uint32_t serial;
+
+ struct Pkt *CreatePkt(struct Node4D *dest,struct ConfigNode *node,struct
Node4D *orig,uint16_t type)
diff -Nru crashmail-1.7/debian/patches/series
crashmail-1.7/debian/patches/series
--- crashmail-1.7/debian/patches/series 2018-07-19 00:14:23.0 +0100
+++ crashmail-1.7/debian/patches/series 2020-12-02 21:41:45.0 +
@@ -1,3 +1,4 @@
01-ExamplePrefs.patch
02-Makefile.patch
03-MitigateErroneousFailure.patch
+fix_gcc-10.patch
Bug#976187: runit-systemd => runit-run transition fails to enable unit
On 12/2/20 5:15 AM, Jamie Heilman wrote: > debconf: delaying package configuration, since apt-utils is not installed > (Reading database ... 25354 files and directories currently installed.) > Removing runit-systemd (2.1.2-36) ... > Selecting previously unselected package runit-run. > (Reading database ... 25348 files and directories currently installed.) > Preparing to unpack .../runit-run_2.1.2-38_all.deb ... > Unpacking runit-run (2.1.2-38) ... > Setting up runit-run (2.1.2-38) ... > (Reading database ... 25355 files and directories currently installed.) > Purging configuration files for runit-systemd (2.1.2-36) ... > > systemctl status shows disabled. This happens regardless of if > /etc/service is a symlink to /etc/runit/runsvdir/current or not (I > updated one of my systems just to see). > > I suspect you couldn't repro it becuase you didn't purge > runit-systemd, you probably only removed it, which clearly has > different logic in runit-systemd's postrm script: Yes you are right, this is the issue: I see from you output that you have a hook or some setting that automatically purge packages after removal. Am I correct? The default setting in apt is that packages are not purged after removal; your sequence is particularly unfortunate here because runit-run and runit-systemd share the same conffiles, so you end up with runit-run in a weird state like installed, configured but purged at the same time, de facto overriding the "enable by default" setting of runit-run. This bug exists but only under a particular configuration of apt; changing the name of the service so that the purge of runit-systemd does not affect runit-run could be a fix, but then some other user may popup and complain that i broke their setup with an unnecessary change.. I think I will leave this bug open for a while (for reference to other users that may run into the same issue) but unfixed, as I don't have an idea for a fix that does not have the potential to break other people's stuff. I'm still open to suggestions and further discussion Lorenzo
Bug#976278: src: Backport Google Compute Virtual Ethernet driver into Debian10
Package: src:linux Severity: wishlist Dear Maintainer, Google would like to have its cloud networking driver, the Google Compute Engine Virtual Ethernet driver (GVE) backported into Debian 10 which is running on the kernel version 4.19. This driver has been accepted into the upstream Linux kernel since version 5.2: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/ethernet/google?h=v5.4.46). I filed this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964812 to get the driver configured in future Debian releases. We have used this driver with the 4.19 kernel internally so I believe it works quite well and shouldn't be significantly difficult to backport to 4.19. Please let me know how we can go about getting this backport into Debian 10. Thanks David -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-cloud-amd64 (SMP w/16 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#973865: RFS: dhcpdump/1.8-3 [ITA] -- Capture dhcp-packets and show for easier checking and debugging
Hi Peter,
On 12/2/20 10:16 AM, Peter Ji wrote:
You have a number of easy to fix lintian tags. I'd recommend to fix them.>
Thanks for your review, Lintian tags have been fixed in the latest upload.
That's great news! The first time around, I only looked at
mentors.debian.net QA information. Now is time for a bit more in-depth
review. Don't hesitate to ask questions, I'll happy to answer them :)
Note: Read through the entire mail, I have a couple of useful links in
the end.
- debian/changelog:
It's looking a bit thin. Each and every changes from one version to
another must be documented in this file. For instance you've added the
VCS fields, the Homepage, the Require-Root-Rules in debian/control. That
must be documented along side with every modification you've made.
Don't hesitate to run a spell checker on the changelog once done. You
have a syntax error with the comma.
- debian/control:
You can bump the policy to 4.5.1, it was released a couple of days
ago. To see if you have any additional modification see the checklist [1]
The Homepage field is an URL to upstream sources [2], not the
packaging one.
You shouldn't need Require-Root-Rule to build that software. I suppose
it's required because you explicitly set the owner/group when installing
the program. Drop that and the R-R-R.
Once again the spell checking indicates a syntax error. Your "for" is
preceded by a dot.
- debian/copyright:
The Source, like the Homepage field of debian/control also refers to
the upstream source.
You are missing a block for the debian/* files. You should list every
authors present in debian/changelog, including yourself.
You are missing an entry for strsep.c, which license and copyright
holder differs from other sources (man licensecheck).
- debian/NMU-Disclaimer:
NMU is quite well defined in the developer reference [3]. Unless you
plan on following those outdated guidelines, you can safely drop this file.
- debian/patches:
Your patch name and description doesn't match the content of the
patch. You are patching different files for different reason and a
separate patch file is needed for each one of them.
Don't update upstream CHANGES with Debian changelog information. Both
will be installed under /usr/share/doc/ and content should be
respectively separated.
Don't patch the Makefile with anything related to the Debian
packaging. That should be done in debian/rules.
You have a trailing whitespace line 108 of the patch file and the
"for" have that previous dot as well.
Creating a README.Debian with sole content the description of the
package is useless. Please remove it. (also the file should have been
wrap to 80 colons).
- debian/rules:
You switched to using dh, which is very good, but you are not using
any of the dh helper files. Please have a look at the Debian New
Maintainer Guide [4] to help you move all the content of that file to
debian/{install,manpage,clean,...}. As a thumb rule, if you have any
target not starting by 'execute_{before,after}_dh_' or 'override_dh',
you are not finished with the dh conversion.
- debian/watch:
The watch file should monitor upstream release [2], not the packaging
one.
---
I know the list looks long but believe me, it's actually quite feasible
:) You can have a look at dhcping packaging [5]. It's a very similar
package, from the same upstream, that I converted a couple of weeks ago.
Do you know about Debian's Gitlab [6]? While hosting the packaging
source anywhere public is actually quite alright, having it on salsa
does bring out a couple advantages:
- you can create the repository under the debian/ namespace. This will
ease collaborative maintenance by any Debian Developer. (Note that you
will need to ask the repository creation on debian-ment...@lists.debian.org)
- you have access to a nice CI [7] pipeline doing all sort of QA stuff
on you package.
- it's open-source! As opposed to github :)
[1]:
https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-5-1
[2]: http://www.mavetju.org/unix/general.php
[3]: https://www.debian.org/doc/manuals/developers-reference/
[4]: https://www.debian.org/doc/manuals/maint-guide/
[5]: https://salsa.debian.org/debian/dhcping
[6]: https://salsa.debian.org
[7]: https://salsa.debian.org/salsa-ci-team/pipeline
--
Baptiste Beauplat - lyknode
OpenPGP_signature
Description: OpenPGP digital signature
Bug#975707: adb devices fails with munmap_chunk() invalid pointer
Package: adb Version: 1:8.1.0+r23-8 Followup-For: Bug #975707 > Thanks for the tips! I think the updates are in unstable, just not testing. Some are in unstable, but not all the of them -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages adb depends on: ii android-libadb 1:8.1.0+r23-8 ii android-libbase 1:8.1.0+r23-8 ii libc62.31-4 ii libgcc-s110.2.0-19 ii libstdc++6 10.2.0-19 Versions of packages adb recommends: ii android-sdk-platform-tools-common 27.0.0+12 adb suggests no packages. -- no debconf information
Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles
On Sun, 29 Nov 2020 16:25:00 +0100 Mourad De Clerck wrote: > I suspect this is upstream bug #1672139: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1672139 That upstream bug appears to be about addon overlays not being rendered properly: they appear to be enabled, and just not rendering properly. That isn't what this Debian bug is about. This bug report is about Firefox addons installed systemwide (such as via webext-* packages) not being enabled when Firefox starts, and requiring a disable/re-enable to get them enabled. The most easily observed side effect of this is starting Firefox, having the uBlock Origin icon missing entirely, and seeing ads not blocked; after toggling uBlock Origin off and back on, ads go back to being blocked.
Bug#962184: [Help] Re: jellyfish FTBFS on 32bit
Control: tags -1 help Hi, I guess this bug is relatively easy to fix by some explicit typing - but I'm lacking the C++ knowledge to find out where. Kind regards Andreas. -- http://fam-tille.de
Bug#976292: design-desktop-web: drop chromium as Depends
Package: design-desktop-web Version: 3.0.20 Severity: serious Justification: chromium removal Hi Jonas, With my Release Team member hat on, please drop chromium from the list of Depends of design-desktop-web. The reason I'm asking is that we want to remove chromium from bullseye because it's currently in a bad shape and your package Depends on it, so either has to go too or should drop the Depends. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#921257:
Hi, Is it possible to update the version of khal that is being built here? One of the failures in the latest build log was fixed in 0.10.2 and I'm not sure about the other, and there's currently no version in testing. Thanks!
Bug#976291: rails: please drop Build-Depends on qunit-selenium
Source: rails Version: 2:6.0.3.4+dfsg-1 Severity: serious Justification: removal of chromium Dear rails maintainers, I love tests. As one of the maintainers of the ci.debian.net infrastructure, I really do. However, with my Release Team member hat on, I'm asking you to stop Build-Depending on qunit-selenium which you need to run your build time tests. The reason I'm asking is that we want to remove chromium from bullseye because it's currently in a bad shape and qunit-selenium Depends on it, so has to go too. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#976240: hplip: Upgrede to 3.20.9+dfsg0-4 broke laserjet mfp network printing/scanning
On Wednesday, December 2, 2020 11:16:44 AM PST Brian Potkin wrote: > tags 976240 - moreinfo > Thanks > > > > On Wed 02 Dec 2020 at 10:39:49 -0800, Andrew Nady wrote: > > > On Wednesday, December 2, 2020 7:42:26 AM PST Brian Potkin wrote: > > > > > > Please give what you get for > > > > > > avahi-browse -rt _ipp._tcp | grep -B 2 address > > > > > > Regards, > > > > > > Brian. > > > > > Hi Brian, > > Thanks for looking into this issue. > > > > This is the output from the "avahi-browse -rt _ipp._tcp | grep -B 2 > > address" command: > > > > > > =dmz IPv6 HP LaserJet Pro M148fdw (E27AD3) Internet > > Printer local > > hostname = [hp-m148.local] > > address = [192.168.89.196] > > Looks fine. I suppose > > hp-setup -i -a -x hp-m148.local > > doesn't get you anything different from previously? > > I've indictated that I cannot reproduce your issue on unstable. But, > AFAICT, there hasn't been any significant change in Debian's HPLIP > between testing and unstable. Perhaps wait for testing HPLIP and CUPS > to get updated from unstable and test again? > > Regards, > > Brian. > I've decided to reset the printer networking portion and start fresh. After the printer was reset I was able to connect again. The avahi-browse -rt _ipp._tcp | grep -B 2 address command from before and after: After the reset : =dmz IPv6 HP LaserJet Pro M148fdw (E27AD3) Internet Printer local hostname = [NPIE27AD3.local] address = [192.168.89.196] -- =dmz IPv4 HP LaserJet Pro M148fdw (E27AD3) Internet Printer local hostname = [NPIE27AD3.local] address = [192.168.89.196] Before the reset: =dmz IPv6 HP LaserJet Pro M148fdw (E27AD3) Internet Printer local hostname = [hp-m148.local] address = [192.168.89.196] -- =dmz IPv4 HP LaserJet Pro M148fdw (E27AD3) Internet Printer local hostname = [hp-m148.local] address = [192.168.89.196] So it works fine now, thanks for your help. Andrew. signature.asc Description: This is a digitally signed message part.
Bug#976290: RM: python-gmusicapi -- ROM; Google Play Music service has shut down
Package: ftp.debian.org Severity: normal Hi, As the maintainer of the python-gmusicapi package, I request that it is removed from Debian as soon as the mopidy-gmusic package is removed (see bug #976287). The package no longer has any use case as the Google Play Music service has been shut down. For what it's worth, the package has never been part of a stable release. Thanks, -- Stein Magnus Jodal jo...@debian.org
Bug#976289: libkolabxml: please mark some symbols as optional
Source: libkolabxml Version: 1.2.0-1 Tags: patch Severity: important Hello, when built with -O3, some symbols are disappearing on s390x. Is it possible to mark them as optional? --- libkolabxml-1.2.0/debian/libkolabxml1v5.symbols 2020-12-01 22:09:37.0 +0100 +++ libkolabxml-1.2.0/debian/libkolabxml1v5.symbols 2020-12-02 22:00:26.0 +0100 @@ -4685,8 +4685,8 @@ _ZN5Kolab14RecurrenceRuleaSERKS0_@Base 1.1.0 _ZN5Kolab16ContactReferenceD1Ev@Base 1.1.0 _ZN5Kolab16ContactReferenceD2Ev@Base 1.1.0 - (arch=!kfreebsd-amd64 !kfreebsd-i386 !mips !powerpcspe)_ZN5Kolab16PrivateIncidenceC1Ev@Base 1.1.6 - (arch=!kfreebsd-amd64 !kfreebsd-i386 !mips !powerpcspe)_ZN5Kolab16PrivateIncidenceC2Ev@Base 1.1.6 + (optional=templinst|arch=!kfreebsd-amd64 !kfreebsd-i386 !mips !powerpcspe)_ZN5Kolab16PrivateIncidenceC1Ev@Base 1.1.6 + (optional=templinst|arch=!kfreebsd-amd64 !kfreebsd-i386 !mips !powerpcspe)_ZN5Kolab16PrivateIncidenceC2Ev@Base 1.1.6 _ZN5Kolab16PrivateIncidenceD1Ev@Base 1.1.0 _ZN5Kolab16PrivateIncidenceD2Ev@Base 1.1.0 _ZN5Kolab16getSerializedUIDB5cxx11Ev@Base 1.1.0 @@ -4757,8 +4757,8 @@ _ZN5Kolab4Todo6setDueERKNS_9cDateTimeE@Base 1.1.0 _ZN5Kolab4Todo6setUidERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.1.0 _ZN5Kolab4Todo6setUrlERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.1.0 - (arch=!kfreebsd-amd64 !kfreebsd-i386 !mips !powerpcspe)_ZN5Kolab4Todo7PrivateC1Ev@Base 1.1.6 - (arch=!kfreebsd-amd64 !kfreebsd-i386 !mips !powerpcspe)_ZN5Kolab4Todo7PrivateC2Ev@Base 1.1.6 + (optional=templinst|arch=!kfreebsd-amd64 !kfreebsd-i386 !mips !powerpcspe)_ZN5Kolab4Todo7PrivateC1Ev@Base 1.1.6 + (optional=templinst|arch=!kfreebsd-amd64 !kfreebsd-i386 !mips !powerpcspe)_ZN5Kolab4Todo7PrivateC2Ev@Base 1.1.6 _ZN5Kolab4Todo8setStartERKNS_9cDateTimeE@Base 1.1.0 _ZN5Kolab4Todo9setAlarmsERKSt6vectorINS_5AlarmESaIS2_EE@Base 1.1.0 _ZN5Kolab4Todo9setStatusENS_6StatusE@Base 1.1.0 The patch is provided by Matthias Klose Gianfranco
Bug#974003: src:plink2: fails to migrate to testing for too long: FTBFS on ppc64el
Hi, On Sun, 8 Nov 2020 22:21:36 +0100 Paul Gevers wrote: > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release Team. The removal bug has been filed some time ago. We'll just have to wait until ftp-masters process that bug. Pinging this bug to avoid autoremoval for now. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#972588: src:netgen: fails to migrate to testing for too long: FTBFS, unresolved RC bug and maintainer built arch:all binaries
Hi On Tue, 20 Oct 2020 22:07:09 +0200 Paul Gevers wrote: > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release Team. This package is waiting for python3-defaults, which should migrate in a couple of days. Pinging this bug to prevent autoremoval now as there is not much that can be done to this package to improve the situation. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#976288: src:srt: fails to migrate to testing for too long: unresolved RC bug
Source: srt Version: 1.4.1-5 Severity: serious Control: close -1 1.4.2-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 971754 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:srt in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=srt OpenPGP_signature Description: OpenPGP digital signature
Bug#975322: broken mlterm 3.9 definitions
On Sat, Nov 21 2020, Sven Joachim wrote: >> If the mlterm package changed that ut-default setting, then providing your >> own termcap settings may have reset the behavior to match the compiled-in >> NON-ut default. > > That seems to have hit the mark. Indeed, if ":ut" is added to Yuri's > termcap example, mlterm works correctly again. > > Yuri, would you like to bring this to the attention of the mlterm > developers? So I think there's another problem here. The reason I had to change ~/.mlterm/termcap was to fix the behavior of F[1-4] keys by making mlterm send a different sequence. mlterm sends ^[OP for F1, but all mlterm terminfo definitions seem to expect \[[11~ ls mlterm* | xargs -l infocmp | grep kf1= kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~, kcuu1=\EOA, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~, Either all these definitions are broken, or I need some enlightenment? If I remove my customization, bce works as it should, but F[1-4] are broken. Sure I can also add :ut to my ~/.mlterm/termcap, then mlterm sends what the terminfo says, but it doesn't look like I'm fixing the right thing here.
Bug#976287: RM: mopidy-gmusic -- ROM; Google Play Music service has been shut down
Package: ftp.debian.org Severity: normal Hi! As the maintainer of the mopidy-gmusic package, I request that it is removed from Debian. The package no longer has any use case as the Google Play Music service has been shut down. For what it's worth, the package has never been part of a stable release. Thanks, -- Stein Magnus Jodal jo...@debian.org
Bug#976286: dlt-viewer: new version available
Source: dlt-viewer Version: 2.19.0+dfsg-1 Severity: normal Hello, thanks to the new watch file you integrated, now there is shown the new version 2.20.3 on ddpo page. Is it possible to have it packaged? I tried to package it and it was a smooth process (one patch dropped, one refreshed, the desktop file name changed in dlt-daemon.install file to src/org.genivi.DLTViewer.desktop) Please let me know if you can update it, and please also consider moving it under a team maintenance and add myself to uploaders. I contribute upstream since long time, and I'm a user of the package. I also added myself to dlt-daemon and python-dlt packages, because I did all the packaging work in the last 2 years or so... G.
Bug#976187: runit-systemd => runit-run transition fails to enable unit
Lorenzo wrote: > Yes you are right, this is the issue: I see from you output > that you have a hook or some setting that automatically purge > packages after removal. Am I correct? No, purging packages is a normal part of using Debian. It's not a special hook, it's just a completely normal administrator activity. > The default setting in apt is that packages are not purged after > removal; That's not exactly accurate. There are a lot ways to manage packages, apt is one, I happen to use aptitude most of the time, but this isn't a setting we're talking about, it's an entirely normal action. Purging packages is how you keep your system free from unused conf files. > your sequence is particularly unfortunate here because runit-run and > runit-systemd share the same conffiles, so you end up with runit-run > in a weird state like installed, configured but purged at the same > time, de facto overriding the "enable by default" setting of > runit-run. > > This bug exists but only under a particular configuration of apt; > changing the name of the service so that the purge of runit-systemd > does not affect runit-run could be a fix, but then some other user > may popup and complain that i broke their setup with an unnecessary > change.. No, it's not a particular configuration of apt. It's how package management on Debian works. If you're going to maintain packages, you have to understand these mechanics intimately or you'll wind up causing no end of problems for users. > I think I will leave this bug open for a while (for reference to > other users that may run into the same issue) but unfixed, as I > don't have an idea for a fix that does not have the potential to > break other people's stuff. > > I'm still open to suggestions and further discussion You probably should get help from the maintainer community, and they can explain the best approach to refactoring these packages so the migration is smooth. As it stands, when you introduced runit-run you created this problem for every user of runit-systemd. The only way to avoid the problem is to avoid having the runit-systemd.postrm script from runit-systemd <= 2.1.2-36 run after runit-run is installed. You could introduce a new version of a more-or-less empty transition runit-systemd package that runit-run depends on, to ensure a version of the runit-systemd.postrm script that doesn't disable the unit exists prior to purge, it's just ugly becuase sysvinit users would be forced into installing a package with "systemd" in the name (even though it shouldn't depend on systemd) which is going to cause confusion. The maintainer community will hopefully have better advice that results in a cleaner transition. -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#976285: please enable redis plugin
Package: zabbix-agent Version: 1:5.0.5+dfsg-1~bpo10+1 Severity: wishlist Hello, it looks like Zabbix is compiled without the redis plugin. >From /usr/share/doc/zabbix-frontend-php/templates/db/redis/README.md.gz Test availability: `zabbix_get -s redis-master -k redis.ping` # `zabbix_get -s redis-master -k redis.ping` zabbix_get [2264555]: Get value error: cannot resolve [redis-master] And the template indeed doestn't work. Would be nice to have redis support enabled. -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (510, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates'), (498, 'testing'), (497, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zabbix-agent depends on: ii adduser 3.118 ii init-system-helpers 1.56+nmu1 ii libc62.28-10 ii libcurl3-gnutls 7.64.0-4+deb10u1 ii libgnutls30 3.6.7-4+deb10u5 ii libldap-2.4-22.4.56+dfsg-1~bpo10+1 ii libpcre3 2:8.42-1+0~20190203125152.5+buster~1.gbp79d75d ii lsb-base 10.2019051400 ii pciutils 1:3.5.2-1 ii ucf 3.0038+nmu1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages zabbix-agent recommends: ii usbutils 1:010-3 Versions of packages zabbix-agent suggests: ii logrotate 3.14.0-4 -- no debconf information
Bug#929530: libsis-base-java: unaligned access on armhf
Control: tags -1 help Hi, I wonder whether some Java expert might be able to clarify the situation in bug #929530. Any help would be appreciated Andreas. -- http://fam-tille.de
Bug#976275: Please add a libncursesw6-udeb package
On 2020-12-02 17:48 +0100, Jordi Mallach wrote: > Source: ncurses > Version: 6.2+20201114-1 > Severity: normal > Tags: d-i > > Hi, > > I've posted a MR in Salsa to add a libncursesw6-udeb package, in order > to make it possible to build nano-udeb against it. > > https://salsa.debian.org/debian/ncurses/-/merge_requests/3 Sorry for not following up on this MR sooner, have done that now. > The next version of nano will remove Slang support, so this will now be > necessary in order to be able to include new versions in bullseye. > > Thanks for considering, Have you asked debian-boot and the d-i maintainer already? >From the ncurses side there is the problem that the current version needs to go into testing first. It has been blocked for 12 days, first by #975455 and now by the udeb freeze. :-( Uploading to experimental would be possible, but at this point it only makes sense if the libncursesw6-udeb package actually ends up in bullseye eventually. Cheers, Sven
Bug#976272: ITP: libnewuoa-cpp -- C++ implementation of the NEWUOA algorithm
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" * Package name: libnewuoa-cpp Version : 0.1.0 Upstream Author : Roman Siromakha * URL : https://github.com/elsid/newuoa-cpp * License : MIT Programming Lang: C++ Description : C++ implementation of the NEWUOA algorithm This library contains the C++ implementation of the NEWUOA derivative free optmization algorithm originally published by Michael J. D. Powell.
Bug#976240: hplip: Upgrede to 3.20.9+dfsg0-4 broke laserjet mfp network printing/scanning
tags 976240 - moreinfo Thanks On Wed 02 Dec 2020 at 10:39:49 -0800, Andrew Nady wrote: > On Wednesday, December 2, 2020 7:42:26 AM PST Brian Potkin wrote: > > > > Please give what you get for > > > > avahi-browse -rt _ipp._tcp | grep -B 2 address > > > > Regards, > > > > Brian. > > > Hi Brian, > Thanks for looking into this issue. > > This is the output from the "avahi-browse -rt _ipp._tcp | grep -B 2 address" > command: > > > =dmz IPv6 HP LaserJet Pro M148fdw (E27AD3) Internet Printer >local > hostname = [hp-m148.local] > address = [192.168.89.196] > -- > =dmz IPv4 HP LaserJet Pro M148fdw (E27AD3) Internet Printer >local > hostname = [hp-m148.local] > address = [192.168.89.196] Looks fine. I suppose hp-setup -i -a -x hp-m148.local doesn't get you anything different from previously? I've indictated that I cannot reproduce your issue on unstable. But, AFAICT, there hasn't been any significant change in Debian's HPLIP between testing and unstable. Perhaps wait for testing HPLIP and CUPS to get updated from unstable and test again? Regards, Brian.
Bug#930751: wpasupplicant: Please enable support for 802.11s (mesh)
On 02/12/2020 22:00, José Miguel Gonçalves wrote: wpasupplicant, not hostapd Yep, my fault, wpasupplicant-mesh of course! -- sergio.
Bug#930751: wpasupplicant: Please enable support for 802.11s (mesh)
On 15/11/2020 16:55, Andrej Shadura wrote: I’ve got reports it completely broke connectivity on certain drivers. Could you provide a separate package then (hostapd-mesh for example)? -- sergio.
Bug#930751: wpasupplicant: Please enable support for 802.11s (mesh)
On 02/12/20 18:50, sergio wrote: On 15/11/2020 16:55, Andrej Shadura wrote: I’ve got reports it completely broke connectivity on certain drivers. Could you provide a separate package then (hostapd-mesh for example)? A separate package could be a solution to anyone that needs encrypted Mesh functionality in Debian. Nevertheless the binary package that implements mesh networking is wpasupplicant, not hostapd, so it should be named something like wpasupplicant-mesh. BR, José Gonçalves
Bug#976240: hplip: Upgrede to 3.20.9+dfsg0-4 broke laserjet mfp network printing/scanning
On Wednesday, December 2, 2020 7:42:26 AM PST Brian Potkin wrote: > notfound 976240 3.20.9+dfsg0-4+b1 > tags 976240 moreinfo > thanks > > > On Tue 01 Dec 2020 at 17:14:29 -0800, andrew wrote: > > > Package: hplip > > Version: 3.20.9+dfsg0-4 > > Severity: important > > > > Dear Maintainer, > > > > The hplip package was update in testing from 3.20.5+dfsg0-3+b1 to > > 3.20.9+dfsg0-4 > > After which I'm no longer able to install my network HP LaserJet MFP > > M148 printer. > > Installing the printer using hp-setup -i fails with the following: > > > > hp-setup -i -a -x 192.168.89.196 > > Thank you for your report, Andrew. > > I executed this command on an unstable installation. The queue was set > up successfully. > > > HP Linux Imaging and Printing System (ver. 3.20.9) > > Printer/Fax Setup Utility ver. 9.0 > > > > Copyright (c) 2001-18 HP Development Company, LP > > This software comes with ABSOLUTELY NO WARRANTY. > > This is free software, and you are welcome to distribute it > > under certain conditions. See COPYING file for more details. > > > > > > > > | SELECT CONNECTION (I/O) TYPE | > > > > > > Num Connection Description > > Type > > -- > > -- > > 0*usb Universal Serial Bus (USB) > > 1 net Network/Ethernet/Wireless (direct connection or > > JetDirect) > > I did not get this dialog. The setup proceeded automatically without > interuption. > > > Enter number 0...1 for connection type (q=quit, enter=usb*) ? 1 > > > > Using connection type: net > > > > error: No device selected/specified or that supports this functionality. > > > > I can print to the printer using the KDE cups connection: > > implicitclass://HP_LaserJet_Pro_M148fdw_E27AD3_/ > > I imagine this queue would have been set up by cups-browsed. Adding > another queue with HPLIP seems superfluous. > > Please give what you get for > > avahi-browse -rt _ipp._tcp | grep -B 2 address > > Regards, > > Brian. > Hi Brian, Thanks for looking into this issue. This is the output from the "avahi-browse -rt _ipp._tcp | grep -B 2 address" command: =dmz IPv6 HP LaserJet Pro M148fdw (E27AD3) Internet Printer local hostname = [hp-m148.local] address = [192.168.89.196] -- =dmz IPv4 HP LaserJet Pro M148fdw (E27AD3) Internet Printer local hostname = [hp-m148.local] address = [192.168.89.196] Andrew. signature.asc Description: This is a digitally signed message part.
Bug#976283: nmu: tpm2-abrmd tpm2-pkcs11
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: normal Hello, libtpm2-tss bump the soname and renames the package for transition from buster -> bullseye. Make the package tpm2-abrmd and tpm2-pkcs11 needs to build against the latest libtpm2-tss. Please see #974837 nmu tpm2-abrmd:2.3.3-1 . ANY . -m 'Rebuild against the new libtpm2-tss, see #974837.' nmu tpm2-pkcs11:1.2.0-1 . ANY . -m 'Rebuild against the new libtpm2-tss, see #974837.' Thanks.|
Bug#976282: RM: ruby-azure-core -- ROM; obsolete, replaced by ruby-azure-storage-{common,blob}
Package: ftp.debian.org
Severity: normal
Control: block -1 by 976281
ruby-azure-core is replaced by ruby-azure-storage-{common,blob} and its
only reverse dependency is ruby-azure-storage, which has a removal
request already (#976281).
It is affected by rc bug #976279 (blocking ruby-faraday 1.0
transition). So please remove this package to facilitate ruby-faraday
1.0 transition.
Bug#976281: RM: ruby-azure-storage -- ROM; obsolete, replaced by ruby-azure-storage-{common,blob}
Package: ftp.debian.org
Severity: normal
ruby-azure-storage is replaced by ruby-azure-storage-{common,blob} and
it has no reverse dependencies.
It is affected by rc bug #976280 (blocking ruby-faraday 1.0
transition). So please remove this package to facilitate ruby-faraday
1.0 transition.
Bug#976280: ruby-azure-storage: ftbfs with ruby-faraday 1.0
Package: ruby-azure-storage Version: 0.15.0~preview-2 Severity: serious Autopkgtest fails with error (rebuild should see the same failure) /usr/lib/ruby/2.7.0/rubygems/dependency.rb:313:in `to_specs': Could not find 'faraday' (~> 0.9) - did find: [faraday-1.1.0] (Gem::MissingSpecVersionError) Full log https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-azure-storage/8564803/log.gz Though this is a leaf package and replaced by ruby-azure-storage-common and ruby-azure-storage-blob. We should remove this package from the archive.
Bug#976279: ruby-azure-core: ftbfs with ruby-faraday 1.0
Package: ruby-azure-core Version: 0.1.15-1 Severity: serious Autopkgtest failed with this error (rebuild should see the same error) /usr/lib/ruby/2.7.0/rubygems/dependency.rb:313:in `to_specs': Could not find 'faraday' (~> 0.9) - did find: [faraday-1.1.0] (Gem::MissingSpecVersionError) Full log https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-azure-core/8564802/log.gz Though this package is replaced by ruby-azure-storage-common and ruby-azure-storage-blob. So this should be removed.
Bug#934025: affects to debian 10
This bug affects me too, if I can provide some data tell me debian 10
Bug#920282: Set severity to minor
Control: severity -1 minor
Bug#976157: thunderbird: Thunderbird refuses to decrypt inline PGP message
Hi Carsten, On 01/12/2020 20:43, Carsten Schoenert wrote: yes, of course. But remember my sentence above your answer. If the sender is using inline PGP with an HTML message the behavior is undefined, in the end Thunderbird can't decrypt the message and there is nothing we can do about this. No. They are all plain text. Without further information what the message is build of you have problems with we can't do any useful error detection. I expect you will have the same problems if you use an upstream version of Thunderbird from Mozilla. If yes your bug report should go into Bugzilla so MZLNA have a chance to fix the underlying issue (if possible). Enigmail had no problem with these messages, and if Thunderbird cannot recognise them, then I cannot read them any more (including all the historical ones sitting my my mailbox.) Regards Jeff OpenPGP_signature Description: OpenPGP digital signature
Bug#976277: iputils-tracepath: destination address of ipv6 probes is cut off after the first 64 bits
Package: iputils-tracepath Version: 3:20180629-2+deb10u1 Severity: important File: /usr/bin/tracepath Tags: ipv6 The iputils-tracepath version currently packaged contains a bug, which results in ipv6 destination addresses being cut off after the first 64 bits. Because tracepath is trying to reach a different address than given by the user, tracepath is almost always unable to reach the destination host. For example, if the user tries to 'tracepath 2001:db8::1234', the probes are actually sent to '2001:db8::'. The bug was introduced in version 20180629 and has already been fixed upstream [1], which is included in version 20190324. However, this bug is still present in the iputils package from debian stable. This fix should probably be backported into debian stable because tracepath shows "!H" (destination address unreachable) for almost every ipv6 address (except for those with a suffix containing only 0-bits). [1] https://github.com/iputils/iputils/pull/136
Bug#976276: libmarpa-r2-perl: New version (8.0) available
Package: libmarpa-r2-perl Version: 2.086000~dfsg-6+b3 Severity: normal Dear Maintainer, A new version is available. A simple cpan2deb produced a working package on my (Buster) system so there do not seem to be any obvious upgrade difficulties. Thanks! - Dean -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (900, 'stable-updates'), (900, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-11-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libmarpa-r2-perl depends on: ii libc6 2.28-10 ii libhtml-parser-perl 3.72-3+b3 ii perl5.28.1-6+deb10u1 ii perl-base [perlapi-5.28.0] 5.28.1-6+deb10u1 libmarpa-r2-perl recommends no packages. libmarpa-r2-perl suggests no packages. -- no debconf information
Bug#976275: Please add a libncursesw6-udeb package
Source: ncurses Version: 6.2+20201114-1 Severity: normal Tags: d-i Hi, I've posted a MR in Salsa to add a libncursesw6-udeb package, in order to make it possible to build nano-udeb against it. https://salsa.debian.org/debian/ncurses/-/merge_requests/3 The next version of nano will remove Slang support, so this will now be necessary in order to be able to include new versions in bullseye. Thanks for considering, Jordi -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), LANGUAGE=ca_ES:ca Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye
On Fri, Nov 20, 2020 at 08:40:22AM +, Holger Levsen wrote: > > Thanks for the upload. > :) note however that "#975016: OpenJDK 15 support state for Bullseye" is still > open... ping, has there been any progress on this? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ If secure encryption is outlawed, only criminals will have it. signature.asc Description: PGP signature
Bug#976270: [Pkg-puppet-devel] Bug#976270: ruby-puppet-forge: autopkgtest/ftbfs with ruby-faraday-middleware 1.x
On 2020, ഡിസംബർ 2 9:33:04 PM IST, Utkarsh Gupta wrote: >Hi Praveen, > >On Wed, Dec 2, 2020 at 8:06 PM Pirate Praveen wrote: >> I can see there is already a patch for relaxing faraday. >> https://salsa.debian.org/puppet-team/ruby-puppet-forge/-/blob/master/debian/patches/002_loosen_deps.patch >> This will need to be extended to cover ruby-faraday-middleware as well. > >I've updated the patch and even updated the version from 2.3.2 to >2.3.4. But the test failures are legit. The codebase is not prepared >for faraday v1.x. I'll raise the issue upstream but you probably need >to consider adding Breaks. I think adding Breaks won't be sufficient for testing migration. I will try adding it anyway. It may reduce the migration delay when there is a fixed version. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#976270: [Pkg-puppet-devel] Bug#976270: ruby-puppet-forge: autopkgtest/ftbfs with ruby-faraday-middleware 1.x
Hi Praveen, On Wed, Dec 2, 2020 at 8:06 PM Pirate Praveen wrote: > I can see there is already a patch for relaxing faraday. > https://salsa.debian.org/puppet-team/ruby-puppet-forge/-/blob/master/debian/patches/002_loosen_deps.patch > This will need to be extended to cover ruby-faraday-middleware as well. I've updated the patch and even updated the version from 2.3.2 to 2.3.4. But the test failures are legit. The codebase is not prepared for faraday v1.x. I'll raise the issue upstream but you probably need to consider adding Breaks. - u
Bug#976274: libqt5gui5: Please build Qt5 with configure option -xcb-native-painting
Package: libqt5gui5 Version: 5.15.1+dfsg-4 Severity: wishlist X-Debbugs-Cc: woebbek...@web.de Dear Maintainer, with X2Go Qt5 apps are much slower than X or GTK apps. But there is a workaround: setting the environment variable QT_XCB_NATIVE_PAINTING. This worked until testing updated to Qt 5.15 because upstream disabled the automatic configuration of this feature in commit 7f948d9effad983477977c3274231401f260c531. So please build Qt5 with -xcb-native-painting to make X2Go users happy again :-) Cheers, André -- System Information: Debian Release: testing APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-2-amd64 (SMP w/8 CPU threads) 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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libqt5gui5 depends on: ii fontconfig2.13.1-4.2 ii libc6 2.31-4 ii libdrm2 2.4.103-1 ii libegl1 1.3.2-1 ii libfontconfig12.13.1-4.2 ii libfreetype6 2.10.2+dfsg-4 ii libgbm1 20.2.3-1 ii libgcc-s1 10.2.0-19 ii libgl11.3.2-1 ii libglib2.0-0 2.66.3-1 ii libharfbuzz0b 2.6.7-1 ii libice6 2:1.0.10-1 ii libinput101.16.4-1 ii libjpeg62-turbo 1:2.0.5-1.1 ii libmd4c0 0.4.6-1 ii libmtdev1 1.1.6-1 ii libpng16-16 1.6.37-3 ii libqt5core5a [qtbase-abi-5-15-1] 5.15.1+dfsg-4 ii libqt5dbus5 5.15.1+dfsg-4 ii libqt5network55.15.1+dfsg-4 ii libsm62:1.2.3-1 ii libstdc++610.2.0-19 ii libudev1 246.6-4 ii libx11-6 2:1.6.12-1 ii libx11-xcb1 2:1.6.12-1 ii libxcb-glx0 1.14-2 ii libxcb-icccm4 0.4.1-1.1 ii libxcb-image0 0.4.0-1+b2 ii libxcb-keysyms1 0.4.0-1+b2 ii libxcb-randr0 1.14-2 ii libxcb-render-util0 0.3.9-1+b1 ii libxcb-render01.14-2 ii libxcb-shape0 1.14-2 ii libxcb-shm0 1.14-2 ii libxcb-sync1 1.14-2 ii libxcb-xfixes01.14-2 ii libxcb-xinerama0 1.14-2 ii libxcb-xinput01.14-2 ii libxcb-xkb1 1.14-2 ii libxcb1 1.14-2 ii libxkbcommon-x11-01.0.3-2 ii libxkbcommon0 1.0.3-2 ii zlib1g1:1.2.11.dfsg-2 Versions of packages libqt5gui5 recommends: ii libqt5svg5 5.15.1-2 pn qt5-gtk-platformtheme Versions of packages libqt5gui5 suggests: ii qt5-image-formats-plugins 5.15.1-2 pn qtwayland5 -- no debconf information
Bug#976273: RFS: motor/3.5.1-1 -- ncurses based ide
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "motor": * Package name: motor Version : 3.5.1-1 Upstream Author : * URL : https://github.com/rofl0r/motor * License : GPL-2.0+ * Vcs : [fill in URL of packaging vcs] Section : devel It builds those binary packages: motor - ncurses based ide To access further information about this package, please visit the following URL: https://mentors.debian.net/package/motor/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/motor/motor_3.5.1-1.dsc Changes since the last upload: motor (3.5.1-1) unstable; urgency=medium . * Initial release (Closes: #976263) Regards, -- Witherking25
Bug#976240: hplip: Upgrede to 3.20.9+dfsg0-4 broke laserjet mfp network printing/scanning
notfound 976240 3.20.9+dfsg0-4+b1 tags 976240 moreinfo thanks On Tue 01 Dec 2020 at 17:14:29 -0800, andrew wrote: > Package: hplip > Version: 3.20.9+dfsg0-4 > Severity: important > > Dear Maintainer, > > The hplip package was update in testing from 3.20.5+dfsg0-3+b1 to > 3.20.9+dfsg0-4 > After which I'm no longer able to install my network HP LaserJet MFP > M148 printer. > Installing the printer using hp-setup -i fails with the following: > > hp-setup -i -a -x 192.168.89.196 Thank you for your report, Andrew. I executed this command on an unstable installation. The queue was set up successfully. > HP Linux Imaging and Printing System (ver. 3.20.9) > Printer/Fax Setup Utility ver. 9.0 > > Copyright (c) 2001-18 HP Development Company, LP > This software comes with ABSOLUTELY NO WARRANTY. > This is free software, and you are welcome to distribute it > under certain conditions. See COPYING file for more details. > > > > | SELECT CONNECTION (I/O) TYPE | > > > Num Connection Description > Type > -- > -- > 0*usb Universal Serial Bus (USB) > 1 net Network/Ethernet/Wireless (direct connection or > JetDirect) I did not get this dialog. The setup proceeded automatically without interuption. > Enter number 0...1 for connection type (q=quit, enter=usb*) ? 1 > > Using connection type: net > > error: No device selected/specified or that supports this functionality. > > I can print to the printer using the KDE cups connection: > implicitclass://HP_LaserJet_Pro_M148fdw_E27AD3_/ I imagine this queue would have been set up by cups-browsed. Adding another queue with HPLIP seems superfluous. Please give what you get for avahi-browse -rt _ipp._tcp | grep -B 2 address Regards, Brian.
Bug#975049: sogo: webmail not working after update of libxmlsec1-openssl
please consider giving the bug important severity as the webinterface is not accessable at all (unless modifying the URL manually after logging in). on the sogo mailinglist another user confirmed the bug: https://www.mail-archive.com/users%40sogo.nu/msg30232.html i found a workaround for the issue on a bug report of the sogo ubuntu package (4.1.1) on arm: https://bugs.launchpad.net/ubuntu/+source/sogo/+bug/1860906 putting "LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libssl.so.1.1" into /etc/default/sogo helps.
Bug#976271: q2cli: please improve autopkgtest
Source: q2cli Version: 2020.11.0-1 Severity: wishlist Tags: newcomer Dear Fellow Maintainers, While working on q2cli, I noticed the autopkgtest was only calling the binary with --help option. While this test is great to have already, and already allows to catch various issues, it is not sufficient to benefit from the sides of full fledged autopkgtests, so I marked it superficial for the moment. Still, it would be a nice addition for the package to have some full fledged autopkgtest available; I thus opened this wishlist item to keep a record of it. Kind Regards, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/3, please excuse my verbosity. PS: For newcomers: this package is maintained under the umbrella of the Debian Med Team , so feel free to send us an email and have a peek at the following location for a template on how we usually wrap up autopkgtests: https://salsa.debian.org/med-team/community/package_template/-/tree/master/debian/tests signature.asc Description: PGP signature
Bug#976270: ruby-puppet-forge: autopkgtest/ftbfs with ruby-faraday-middleware 1.x
Package: ruby-puppet-forge Version: 2.3.2-1 Severity: serious autopkgtest is failing with ruby-faraday-middleware 1.0. /usr/lib/ruby/2.7.0/rubygems/dependency.rb:313:in `to_specs': Could not find 'faraday_middleware' (< 0.14.0, >= 0.9.0) - did find: [faraday_middleware-1.0.0] (Gem::MissingSpecVersionError) Full log https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-puppet-forge/8564808/log.gz I can see there is already a patch for relaxing faraday. https://salsa.debian.org/puppet-team/ruby-puppet-forge/-/blob/master/debian/patches/002_loosen_deps.patch This will need to be extended to cover ruby-faraday-middleware as well.
Bug#975707: adb devices fails with munmap_chunk() invalid pointer
Thanks for the tips! I think the updates are in unstable, just not testing.
Bug#976254: Something for our Advent calendar (Was: Bug#976254: rnahybrid: Does not build from source "multiple definition of")
Hi, That is a common problem with legacy code being compiled with gcc-10, since it defaults to "-fno-common". It can be solved for legacy packages by passing "CFLAGS=-fcommon" to the `configure` (e.g `./configure CFLAGS=-fcommon`), then `make` will succeed. More information from https://gcc.gnu.org/gcc-10/porting_to.html: > Default to -fno-common > A common mistake in C is omitting extern when declaring a global variable in a header file. If the header is included by several files it results in multiple definitions of the same variable. In previous GCC versions this error is ignored. GCC 10 defaults to -fno-common, which means a linker > error will now be reported. To fix this, use extern in header files when declaring global variables, and ensure each global is defined in exactly one C file. If tentative definitions of particular variables need to be placed in a common block, __attribute__((__common__)) can be used to force > that behavior even in code compiled without -fcommon. As a workaround, legacy C code where all tentative definitions should be placed into a common block can be compiled with -fcommon. Regards, Hamid Nassiby On Wed, Dec 2, 2020 at 12:51 PM Andreas Tille wrote: > Control: tags -1 help > > Hi, > > no idea why this was not catched in the usual gcc-10 rebuilds. Any > volunteer? > > Kind regards > > Andreas. > > On Wed, Dec 02, 2020 at 12:08:32AM +0100, Andreas Tille wrote: > > Source: rnahybrid > > Severity: serious > > Tags: ftbfs > > Justification: FTBFS > > > > Hi, > > > > I tried to rebuild the package but the build ends in: > > > > ... > > gcc -g -O2 -fdebug-prefix-map=/build/rnahybrid-2.1.2=. > -fstack-protector-strong -Wformat -Werror=format-security -g -O2 > -fdebug-prefix-map=/build/rnahybrid-2.1.2=. -fstack-protector-strong > -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -Wl,-z,relro > -Wl,-z,now -o RNAeffective rnaeffective.o hybrid_core.o numerical.o > energy.o input.o fasta.o random.o mt19937-1.o plot.o -lg2 -lm > > /usr/bin/ld: /usr/bin/ld: /usr/bin/ld: > hybrid_core.o:./src/hybrid_core.h:13: multiple definition of `x'; > rnahybrid.o:./src/hybrid_core.h:13: first defined here > > hybrid_core.o:./src/hybrid_core.h:/usr/bin/ld: hybrid_core.o13: multiple > definition of `x'; :./src/hybrid_core.h:15: multiple definition of `y'; > rnahybrid.o:./src/hybrid_core.h:15: first defined herehybrid_core.o > > /usr/bin/ld: hybrid_core.o:./src/hybrid_core.h:28: multiple definition > of `r1'; rnahybrid.o:./src/hybrid_core.h:28: first defined here > > /usr/bin/ld: hybrid_core.o:./src/hybrid_core.h:28: multiple definition > of `r2'; rnahybrid.o:./src/hybrid_core.h:28: first defined here > > /usr/bin/ld: hybrid_core.o:./src/hybrid_core.h:28: multiple definition > of `r3'; rnahybrid.o:./src/hybrid_core.h:28: first defined here > > /usr/bin/ld: > hybrid_core.o:./src/hybrid_core.h:13:./src/hybrid_core.h:28: multiple > definition of `r4'; rnahybrid.o:./src/hybrid_core.h:28: first defined here > > /usr/bin/ld: hybrid_core.o: multiple definition of `x'; > :./src/hybrid_core.h:30: multiple definition of `a1'; > rnahybrid.o:./src/hybrid_core.h:30: first defined here > > /usr/bin/ld: hybrid_core.o:./src/hybrid_core.h:30: multiple definition > of `a2'; rnahybrid.o:./src/hybrid_core.h:30: first defined > herernaeffective.o:./src/hybrid_core.h:13: first defined here > > /usr/bin/ld: hybrid_core.o > > /usr/bin/ld: hybrid_core.o:./src/hybrid_core.h:30: multiple definition > of `a3'; rnahybrid.o:./src/hybrid_core.h:30: first defined here > > /usr/bin/ld: hybrid_core.o:./src/hybrid_core.h:30: multiple definition > of `a4'; rnahybrid.o:./src/hybrid_core.h:30: first defined here > > /usr/bin/ld: hybrid_core.o:./src/hybrid_core.h:30: multiple definition > of `a5'; rnahybrid.o:./src/hybrid_core.h:30: first defined here > > /usr/bin/ld: hybrid_core.o:./src/hybrid_core.h:30: multiple definition > of `a6'; rnahybrid.o:./src/hybrid_core.h:30: first defined here > > /usr/bin/ld:./src/hybrid_core.h:15: multiple definition of `y'; > rnaeffective.o:./src/hybrid_core.h:15: first defined here > > /usr/bin/ld: hybrid_core.o: hybrid_core.o:./src/hybrid_core.h:23: > multiple definition of `helix_start'; rnahybrid.o:./src/hybrid_core.h:23: > first defined here > > /usr/bin/ld: hybrid_core.o:./src/hybrid_core.h:23: multiple definition > of `helix_end'; rnahybrid.o:./src/hybrid_core.h:23: first defined here > > /usr/bin/ld: hybrid_core.o:./src/energy.h:50: multiple definition of > `canPair'; rnahybrid.o:./src/energy.h:50: first defined here > > /usr/bin/ld:./src/hybrid_core.h:28: multiple definition of `r1'; > rnaeffective.o:./src/hybrid_core.h:28: first defined here > > /usr/bin/ld: hybrid_core.o:./src/hybrid_core.h:28: multiple definition > of `r2'; rnaeffective.o:./src/hybrid_core.h:28: first defined here > > /usr/bin/ld: hybrid_core.o:./src/hybrid_core.h:28: multiple definition > of `r3'; rnaeffective.o:./src/hybrid_core.h:28: first defined here > > /usr/bin/ld:
Bug#976269: [20201202] mirror.intergrid.com.au: sync-frequency, ftpsync-version
Package: mirrors Severity: normal X-Debbugs-Cc: Javed Ali Hi, I was checking some things in the Debian mirror universe and noticed a problem with your mirror: Looking at https://mirror-master.debian.org/status/mirror-info/mirror.intergrid.com.au.html it seems you only sync about once a day. The Debian archive updates 4 times a day, and we expect mirrors listed in our mirror list to follow that cadence. A couple other things to note: o The tracefile at http://mirror.intergrid.com.au/debian/project/trace/mirror.intergrid.com.au is missing some required information. We expect at least the Maintainer and Upstream-mirror values to be filled in, and your tracefile is missing one or both of them. o The tracefile http://mirror.intergrid.com.au/debian/project/trace/mirror.intergrid.com.au suggests that the ftpsync version you are using is old. Please upgrade. Using a modern ftpsync ensures updates are done in the correct order so apt clients don't get confused. In particular, it processes translations, contents, and more files that have been added to the archive in recent years in the correct stage. It also should produce trace files that contain more information that is useful for us and helps downstream mirrors sync better. http://mirror.intergrid.com.au/debian/project/ftpsync/ftpsync-current.tar.gz Thanks, Julien
Bug#976267: Acknowledgement (ams: AMS segmentaton fault)
In Non/New-Session-manager (NSM) it launches, but it does that with twice instances https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976268
Bug#976191: texlive-latex-base: Fails to build formats for LaTeX
> @Norbert: could fix this in upstream? I'll discuss with Karl. Thanks Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#976268: ams: Non/new-session-manager lauches two instances of AMS
Package: ams Version: 2.1.2-2 Severity: normal X-Debbugs-Cc: rosea.grammost...@gmail.com Dear Maintainer, I tried to build the AMS package from SID (2.1.2-2) on Testing dget -ux dpkg-buildpackage -rfakeroot -b -uc -us When adding AMS to Non/New-session-manager it oddly launches two instances of AMS. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-3-rt-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ams depends on: ii cmt 5:1.17-1kxstudio1 ii libasound21.2.3.2-1+b1 ii libc6 2.31-4 ii libclalsadrv2 2.0.0-3+b1 ii libfftw3-double3 3.3.8-2 ii libgcc-s1 10.2.0-16 ii libjack-jackd2-0 [libjack-0.125] 1.9.16~dfsg-1 ii liblo70.31-1 ii libqt5core5a 5.15.1+dfsg-2 ii libqt5gui55.15.1+dfsg-2 ii libqt5opengl5 5.15.1+dfsg-2 ii libqt5widgets55.15.1+dfsg-2 ii libstdc++610.2.0-16 ii mcp-plugins 0.4.0-6 ii swh-plugins 0.4.17-2 Versions of packages ams recommends: ii amb-plugins 5:0.8.1-7kxstudio2 ii rev-plugins 0.7.1-3+b1 ii vco-plugins 0.3.0-5+b1 ams suggests no packages. -- no debconf information
