Bug#970580: licenseutils: Memory access error

[handsome_feng]

Tags: patch


Hi,

I found this error is caused by the gpl url redirected from
https://www.gnu.org/licenses/gpl-1.0 to
https://www.gnu.org/licenses/old-licenses/gpl-1.0,


so I added the CURLOPT_FOLLOWLOCATION to tell libcurl to follow redirection.


Regards,

handsome_feng

--- a/src/url-downloader.c
+++ b/src/url-downloader.c
@@ -82,6 +82,7 @@ download (struct lu_state_t *state, char
   curl_easy_setopt (state->curl, CURLOPT_HTTPGET, 1);
   curl_easy_setopt (state->curl, CURLOPT_URL, url);
   curl_easy_setopt (state->curl, CURLOPT_WRITEDATA, fileptr);
+  curl_easy_setopt (state->curl, CURLOPT_FOLLOWLOCATION, 1L);
   curl_easy_perform(state->curl);
   fflush (fileptr);
   fsync (fileno (fileptr));


OpenPGP_0x9BB850C013111F0C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#977175: ITP: node-ist -- Mini assertion library

[Abraham Raji]

Package: wnpp
Severity: wishlist
Owner: Abraham Raji 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name    : node-ist
  Version : 1.0.0
  Upstream Author : 2016 by Marijn Haverbeke 
* URL : https://github.com/marijnh/ist#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Mini assertion library
This is a tiny assertion library (in the same space as require("assert"))
that is only a handful of lines, and exports a simple API.
.
Node.js is an event-based server-side JavaScript engine.

This is package is a development dependency for multiple prosemirror 
modules. I will package and maintain this package myself with help
from the Debian JS team.

Abraham Raji
-- 
Mea navis aëricumbens anguillis abundat.

Bug#977184: FTBFS with glade 3.38.1-1

[Laurent Bigonville]

Source: libgtkdatabox
Version: 1:0.9.3.1-1
Severity: important

Hello,

libgtkdatabox FTBFS with glade 3.38.1 that is currently in debian experimental 
with the following errors:

/usr/include/glib-2.0/glib/gmacros.h:1032:49: error: 
‘glib_autoptr_clear_GtkBox’ undeclared (first use in this function); did you 
mean ‘glib_autoptr_clear_GProxy’?
 1032 | #define _GLIB_AUTOPTR_CLEAR_FUNC_NAME(TypeName) 
glib_autoptr_clear_##TypeName
  | ^~~
/usr/include/glib-2.0/glib/gmacros.h:1049:18: note: in definition of macro 
‘_GLIB_DEFINE_AUTOPTR_CLEANUP_FUNCS’
 1049 | { if (_ptr) (cleanup) ((ParentName *) _ptr); }  
\
  |  ^~~
/usr/include/glib-2.0/glib/gmacros.h:1060:65: note: in expansion of macro 
‘_GLIB_AUTOPTR_CLEAR_FUNC_NAME’
 1060 |   _GLIB_DEFINE_AUTOPTR_CLEANUP_FUNCS(ModuleObjName, ParentName, 
_GLIB_AUTOPTR_CLEAR_FUNC_NAME(ParentName))
  | 
^
/usr/include/glib-2.0/gobject/gtype.h:1496:3: note: in expansion of macro 
‘_GLIB_DEFINE_AUTOPTR_CHAINUP’
 1496 |   _GLIB_DEFINE_AUTOPTR_CHAINUP (ModuleObjName, ParentName)  
 \
  |   ^~~~
/usr/include/libgladeui-2.0/gladeui/glade-editor-property.h:37:1: note: in 
expansion of macro ‘G_DECLARE_DERIVABLE_TYPE’
   37 | G_DECLARE_DERIVABLE_TYPE (GladeEditorProperty, glade_editor_property, 
GLADE, EDITOR_PROPERTY, GtkBox)
  | ^~~~
/usr/include/glib-2.0/glib/gmacros.h:1032:49: note: each undeclared identifier 
is reported only once for each function it appears in
 1032 | #define _GLIB_AUTOPTR_CLEAR_FUNC_NAME(TypeName) 
glib_autoptr_clear_##TypeName
  | ^~~
[...]

Could you please have a look at this? This is blocking us to update
glade in unstable

Kind regards,
Laurent Bigonville

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#769626: groff-base: suggest mailcap entries for .ms and .me files

[Kevin Ryde]

I wrote:
>
> I see "groffer" does many things.

I tried the mailcap lines below.  Intended to be "works everywhere"
level, so don't try to divine user preferences or do anything fragile
with character sets or predict $PAGER capability.  The user can copy to
~/.mailcap and adapt (that being entirely normal to select mail type
viewing preferences ...).

The X form gets a warning from grog for me, but I think is either its
fault or the way groffer runs it.


# groffer looks in the input for needed preprocessors (eg. tbl).
# --mode=X uses gxditview which is included in the groff package.
# groffer has other mode options to easily run other graphics viewers.
# -TX100 anticipates a 100dpi screen.  Can -TX75 if desired.
application/x-troff-ms; groffer --mode=X -TX100 -ms; test=test -n "$DISPLAY"; 
description=Troff ms
application/x-troff-me; groffer --mode=X -TX100 -me; test=test -n "$DISPLAY"; 
description=Troff me
#
# -Tascii output for maximum portability.
# -P -c is option -c to grotty for no SGR escapes (but still backspacing).
# col -b collapses backspacing to plain text.
# Both SGR and backspacing are undesirable for output to a file or an
# unknown viewer (such as a mail reader).
application/x-troff-ms; groffer --mode=text -Tascii -P -c -ms '%s' | col -b; 
copiousoutput; description=Troff ms; priority=2
application/x-troff-me; groffer --mode=text -Tascii -P -c -me '%s' | col -b; 
copiousoutput; description=Troff me; priority=2

Bug#977158: gnome-sofware: gnome software updates the kernel without my consent. My wifi driver needs to be recompiled.

[Andrei POPESCU]

Control: reassign -1 gnome-software

On Vi, 11 dec 20, 22:15:38, Al.ABBES wrote:
> Package: gnome-sofware
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> my wifi driver does not work after each update.  gnome softawre updates 
> the kernel without asking. It is not polite? It is a security issue.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
> I did not find why my wifi driver did not work suddenly.
>* What outcome did you expect instead?
> Gnome-software should not be working by default, and should not have access 
> to essential softwares.
> *** End of the template - remove these template lines ***
> 
> 
> -- 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-12-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_CH.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Fixing typo in package name.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#977185: nheko: switch to Boost 1.74

[Sebastian Ramacher]

Source: nheko
Version: 0.7.2-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

nheko currently hardcodes its boost build dependencies with an explicit
version. Since the default boost version is now 1.74 and we are trying
to remove boost 1.71 before the release of bullseye, please switch to
1.74 or to the unversioned boost packages.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#901379: gitlab: postinst script should not call psql if database is not managed by dbconfig-common

[Pirate Praveen]

On Fri, 11 Dec 2020 23:53:27 +0100  wrote:
> Hello,
>
> I encounter the same problem (psql directly used in postinst script) 
during

> every package upgrade.
>
> The main problem (in my case) is the misdetection of an 
uninitialized database

> (see "db_relations" in /usr/lib/gitlab/scripts/rake-tasks.sh).
> The script checks via "psql" (locally), whether the database is 
already
> populated. Since the database is empty, the initial database setup 
is started
> (this time using rake for interacting with the configured external 
database).

> This initialization fails, since the real database is not empty.
> Thus postinst fails.
>
> My current workaround is to run the following loop in a separate 
shell:

>
>  while sleep 1; do sed -i 's/db_relations"/db_relationsXXX"/' \
>/usr/lib/gitlab/scripts/rake-tasks.sh; done
>
> This overrides the test for an empty database.
> Another approach could be to simply populate the local (unused) 
database.

>
> The proper solution would be to use the *configured* database 
connection
> instead of running "psql" directly. Maybe this could be done via 
rake?

>
> If you could give me any hints in this direction, then I could 
propose a patch
> for fixing the database accesses in the postinst other related 
scripts.


We can read dbc_dbserver value from /etc/dbconfig-common/gitlab.conf 
and use psql -h $dbc_dbserver to check remotely.

Bug#977187: FTBFS with glade 3.38

[Laurent Bigonville]

Source: libhandy
Version: 0.0.13-2
Severity: important

Hello,

libhandy currently FTBFS with glade 3.38 that is currently in
experimenal. This is preventing us to update it in unstable

The errors are:

FAILED: glade/libglade-handy.so.p/glade-hdy-header-group.c.o
cc -Iglade/libglade-handy.so.p -Iglade -I../glade -I. -I.. -Isrc -I../src 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gtk-3.0 
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
-I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 
-I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 
-I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 
-I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/libgladeui-2.0 -I/<>/obj-x86_64-linux-gnu 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
-std=gnu11 -DHAVE_CONFIG_H -DHANDY_COMPILATION -Wcast-align -Wdate-time 
-Wdeclaration-after-statement -Werror=format-security -Werror=format=2 
-Wendif-labels -Werror=incompatible-pointer-types -Werror=missing-declarations 
-Werror=overflow -Werror=return-type -Werror=shift-count-overflow 
-Werror=shift-overflow=2 -Werror=implicit-fallthrough=3 -Wformat-nonliteral 
-Wformat-security -Winit-self -Wmaybe-uninitialized 
-Wmissing-field-initializers -Wmissing-include-dirs -Wmissing-noreturn 
-Wnested-externs -Wno-missing-field-initializers -Wno-sign-compare 
-Wno-strict-aliasing -Wno-unused-parameter -Wold-style-definition 
-Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default 
-Wswitch-enum -Wtype-limits -Wundef -Wunused-function -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD -MQ 
glade/libglade-handy.so.p/glade-hdy-header-group.c.o -MF 
glade/libglade-handy.so.p/glade-hdy-header-group.c.o.d -o 
glade/libglade-handy.so.p/glade-hdy-header-group.c.o -c 
../glade/glade-hdy-header-group.c
../glade/glade-hdy-header-group.c: In function 
‘glade_hdy_header_group_read_widgets’:
../glade/glade-hdy-header-group.c:46:46: error: ‘GPC_OBJECT_DELIMITER’ 
undeclared (first use in this function)
   46 |   g_strdup_printf ("%s%s%s", string, GPC_OBJECT_DELIMITER,
  |  ^~~~
../glade/glade-hdy-header-group.c:46:46: note: each undeclared identifier is 
reported only once for each function it appears in
../glade/glade-hdy-header-group.c: In function 
‘glade_hdy_header_group_read_widget’:
../glade/glade-hdy-header-group.c:77:3: warning: implicit declaration of 
function ‘GWA_GET_CLASS’; did you mean ‘G_TASK_GET_CLASS’? 
[-Wimplicit-function-declaration]
   77 |   GWA_GET_CLASS (G_TYPE_OBJECT)->read_widget (adaptor, widget, node);
  |   ^
  |   G_TASK_GET_CLASS
../glade/glade-hdy-header-group.c:77:3: warning: nested extern declaration of 
‘GWA_GET_CLASS’ [-Wnested-externs]
../glade/glade-hdy-header-group.c:77:32: error: invalid type argument of ‘->’ 
(have ‘int’)
   77 |   GWA_GET_CLASS (G_TYPE_OBJECT)->read_widget (adaptor, widget, node);
  |^~
../glade/glade-hdy-header-group.c: In function 
‘glade_hdy_header_group_write_widget’:
../glade/glade-hdy-header-group.c:123:32: error: invalid type argument of ‘->’ 
(have ‘int’)
  123 |   GWA_GET_CLASS (G_TYPE_OBJECT)->write_widget (adaptor, widget, 
context, node);
  |^~
../glade/glade-hdy-header-group.c: In function 
‘glade_hdy_header_group_set_property’:
../glade/glade-hdy-header-group.c:157:34: error: invalid type argument of ‘->’ 
(have ‘int’)
  157 | GWA_GET_CLASS (G_TYPE_OBJECT)->set_property (adaptor, object,
  |  ^~

Could you have a look please?

Kind regards,
Laurent Bigonville


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#976880: transition: dtkcore

[Arun Kumar Pariyar]

Package: release.debian.org
Followup-For: Bug #976880

Dear Release Team,

Following packages need to have a sourceful upload:

dtkcore
dtkgui
dtkwidget
dtkwm
dde-qt-dbus-factory
dde-qt5integration
dde-calendar
deepin-deb-installer
deepin-menu
deepin-movie-reborn
deepin-music
deepin-screen-recorder
deepin-voice-recorder
deepin-calculator
deepin-image-viewer

And the following packages need binNMU:

deepin-shortcut-viewer
deepin-picker
deepin-notifications
deepin-screenshot

--
Arun Kumar Pariyar



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977188: cthumb: no more upstream homepage, suggestion to use archive.org

[Davide Prina]

Package: cthumb
Version: 4.2-3.1
Severity: normal

I have see that the homepage
http://cthumb.sourceforge.net/
is not present anymore

I found that the upstream has asked the deletion of this project
https://sourceforge.net/p/forge/site-support/15113/
so this project has no more upstream homepage

I think that it is better to set the homepage at:
https://web.archive.org/web/20161009151909/http://cthumb.sourceforge.net/

Ciao
Davide

Bug#977189: geeqie: No image is rendered, only white rectangle visible

[Roberto Lumbreras]

Package: geeqie
Version: 1:1.6-2
Severity: important

Geeqie just renders all images as white boxes.
It seems this is a common and old problem with Wayland, leaving geeqie
unusable.
I'm running stock Debian Gnome, which apparently means Wayland.
Upgrading to qeeqie/unstable didn't help.

Regards,
Roberto

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'),
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages geeqie depends on:
ii  geeqie-common1:1.6-2
ii  libc62.31-5
ii  libcairo21.16.0-4
ii  libchamplain-0.12-0  0.12.20-1
ii  libchamplain-gtk-0.12-0  0.12.20-1
ii  libclutter-1.0-0 1.26.4+dfsg-2
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libcogl201.22.8-2
ii  libdjvulibre21   3.5.28-1
ii  libexiv2-27  0.27.3-3
ii  libffmpegthumbnailer4v5  2.1.1-0.2+b1
ii  libgcc-s110.2.0-19
ii  libgdk-pixbuf-2.0-0  2.40.0+dfsg-8
ii  libglib2.0-0 2.66.3-2
ii  libgtk-3-0   3.24.23-3
ii  libheif1 1.9.1-1
ii  libjpeg62-turbo  1:2.0.5-1.1
ii  liblcms2-2   2.9-4+b1
ii  liblirc-client0  0.10.1-6.2+b1
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libopenjp2-7 2.3.1-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpoppler-glib8 20.09.0-3
ii  libstdc++6   10.2.0-19
ii  libtiff5 4.1.0+git191117-2
ii  libwebp6 0.6.1-2+b1
ii  libx11-6 2:1.6.12-1
ii  sensible-utils   0.0.12+nmu1

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.3.3op1-2
ii  exiftran 2.10-4
ii  exiv20.27.3-3
ii  imagemagick  8:6.9.11.24+dfsg-1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.24+dfsg-1+b2
ii  librsvg2-common  2.50.2+dfsg-1
ii  ufraw-batch  0.22-4
ii  zenity   3.32.0-6

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.10.22-2
ii  libjpeg-turbo-progs [libjpeg-progs]  1:2.0.5-1.1
pn  ufraw
pn  xpaint   

-- no debconf information

Bug#975430: Raising the bug's severity

[Anton Gladky]

severity 975430 serious
severity 975588 serious
severity 975593 serious
severity 975660 serious
severity 975665 serious
severity 975666 serious
severity 975667 serious
severity 975672 serious
severity 975863 serious
thanks

boost1.74 is already default in unstable. Thus raising the bug's severity.

Cheers

Anton

Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD

[Sébastien Delafond]

On 11/12 18:59, Sylvain Beucler wrote:
> I did more tests during the past few hours (checking that
> XERCES_DISABLE_DTD does address the memory leak and using a couple
> reverse dependencies) and just uploaded the buster update to security
> master.

I've just rejected this upload, so you can reuse deb10u1 once the test
suite is fixed on 32bit architectures.

Cheers,

-- 
Seb

Bug#977190: awstats: CVE-2020-35176

[Salvatore Bonaccorso]

Source: awstats
Version: 7.8-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/eldy/awstats/issues/195
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for awstats, which is a
followup to CVE-2020-29600 (incomplete fix for it, and previously
CVE-2017-1000501, cf. #891469).

CVE-2020-35176[0]:
| In AWStats through 7.8, cgi-bin/awstats.pl?config= accepts a partial
| absolute pathname (omitting the initial /etc), even though it was
| intended to only read a file in the /etc/awstats/awstats.conf format.
| NOTE: this issue exists because of an incomplete fix for
| CVE-2017-1000501 and CVE-2020-29600.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-35176
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35176
[1] https://github.com/eldy/awstats/issues/195

Regards,
Salvatore

Bug#977191: cvsps: Wrong homepage + new version

[Davide Prina]

Package: cvsps
Version: 2.1-8
Severity: normal

I have see that the project homepage do not respond anymore:
http://www.cobite.com/cvsps/

I think that the homepage is:
http://cvsps.sourceforge.net/

I think that there is a new version 2.2b1 on sourceforge

Ciao
Davide

Bug#976922: systemd-bootchart: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2

[Lucas Nussbaum]

On 11/12/20 at 15:08 +0100, Michael Biebl wrote:
> Am 11.12.20 um 09:09 schrieb Lucas Nussbaum:
> > On 10/12/20 at 22:12 +0100, Michael Biebl wrote:
> > > Am 10.12.20 um 22:10 schrieb John Paul Adrian Glaubitz:
> > > > Hi Michael!
> > > > 
> > > > On 12/10/20 8:42 PM, Michael Biebl wrote:
> > > > > 
> > > > > Testsuite summary for systemd-bootchart 233
> > > > > 
> > > > > # TOTAL: 1
> > > > > # PASS:  1
> > > > > # SKIP:  0
> > > > > # XFAIL: 0
> > > > > # FAIL:  0
> > > > > # XPASS: 0
> > > > > # ERROR: 0
> > > > > 
> > > > 
> > > > Did the test machine you used actually have that many cores?
> > > 
> > > No idea
> > 
> > I tried building with SMT off (so the machine only has 20 visible
> > cores). I could reproduce the failure. (I disabled SMT at runtime using
> > ppc64_cpu --smt=off)
> > 
> > It also fails when running 'make check VERBOSE=1' (so it's not caused by
> > parallelism).
> > 
> > It crashes with:
> > (gdb) r -o /tmp/tmp.k64Np1I2cr -n 10 -r -p
> > Starting program: /root/systemd-bootchart-233/systemd-bootchart -o 
> > /tmp/tmp.k64Np1I2cr -n 10 -r -p
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library 
> > "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00014d04 in svg_ps_bars (interval=, 
> > graph_start=2775.3698308829998, ps_first=0x1000505d0, n_cpus=1,
> >  n_samples=10, head=0x100050770, of=0x1000503f0) at src/svg.c:1187
> > 1187i = ps->sample->next->sampledata->counter;
> > (gdb) bt
> > #0  0x00014d04 in svg_ps_bars (interval=, 
> > graph_start=2775.3698308829998, ps_first=0x1000505d0,
> >  n_cpus=1, n_samples=10, head=0x100050770, of=0x1000503f0) at 
> > src/svg.c:1187
> 
> This looks a lot like
> 
> https://github.com/systemd/systemd-bootchart/pull/37
> specifically
> https://github.com/systemd/systemd-bootchart/pull/37/commits/65320230f5fcb02e81df5131a4dc03092558c263
> 
> Could you give this PR a try?

Hi,

This branch fixes the crash.

Lucas

Bug#977192: libappimage: CVE-2020-25265

[Salvatore Bonaccorso]

Source: libappimage
Version: 0.1.9+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/AppImage/libappimage/pull/146
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libappimage.

CVE-2020-25265[0]:
| AppImage libappimage before 1.0.3 allows attackers to trigger an
| overwrite of a system-installed .desktop file by providing a .desktop
| file that contains Name= with path components.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-25265
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25265
[1] https://github.com/AppImage/libappimage/pull/146
[2] https://github.com/refi64/CVE-2020-25265-25266

Regards,
Salvatore

Bug#977192: libappimage: CVE-2020-25265

[Salvatore Bonaccorso]

On Sat, Dec 12, 2020 at 10:32:06AM +0100, Salvatore Bonaccorso wrote:
> Source: libappimage
> Version: 0.1.9+dfsg-1
> Severity: important
> Tags: security upstream
> Forwarded: https://github.com/AppImage/libappimage/pull/146
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for libappimage.
> 
> CVE-2020-25265[0]:
> | AppImage libappimage before 1.0.3 allows attackers to trigger an
> | overwrite of a system-installed .desktop file by providing a .desktop
> | file that contains Name= with path components.

I'm not entirely sure if the issue is present as well in 0.1.9. The
code is different but 0.2.0 merged the desktop_integration part into
libappimage, before the rename/merge of the sources files.

I have one comment: There seem to be no users of libappimage within
Debian (anymore), and has low popcon, and said security issue. 

Should possibly libappimage be removed for bullseye? It would be
possible:

$ dak rm --suite=sid -n -R libappimage
Will remove the following packages from sid:

libappimage | 0.1.9+dfsg-1 | source
libappimage-dev | 0.1.9+dfsg-1+b1 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
libappimage0 | 0.1.9+dfsg-1+b1 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x

Maintainer: Scarlett Moore 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

Or is there something I miss right now?

Otherwise it probably should be updated straight to 1.0.3 for bullseye
in time.


Regards,
Salvatore

Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/

[Lucas Nussbaum]

On 11/12/20 at 22:43 +0100, Andreas Henriksson wrote:
> Hello Lucas Nussbaum,
> 
> On Sat, Dec 05, 2020 at 02:23:54PM +0100, Lucas Nussbaum wrote:
> > Source: golang-github-shirou-gopsutil
> > Version: 2.19.11-3
> > Severity: serious
> > Justification: FTBFS on arm64
> > Tags: bullseye sid ftbfs
> > Usertags: ftbfs-20201205 ftbfs-bullseye
> > 
> > Hi,
> > 
> > During a rebuild of all packages in sid, your package failed to build
> > on arm64 (I don't know if it also fails on amd64).
> [...]
> > > === RUN   TestCpuInfo
> > > cpu_test.go:90: could not get CPU Info: 
> > > {"cpu":0,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"0","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > > cpu_test.go:90: could not get CPU Info: 
> > > {"cpu":1,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"1","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > > cpu_test.go:90: could not get CPU Info: 
> > > {"cpu":2,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"2","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > > cpu_test.go:90: could not get CPU Info: 
> > > {"cpu":3,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"3","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > > --- FAIL: TestCpuInfo (0.00s)
> [...]
> > > FAIL
> > > FAIL  github.com/shirou/gopsutil/cpu  0.047s
> [...]
> > > FAIL
> > > dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 
> > > github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu 
> > > github.com/shirou/gopsutil/disk github.com/shirou/gopsutil/docker 
> > > github.com/shirou/gopsutil/host 
> > > github.com/shirou/gopsutil/internal/common 
> > > github.com/shirou/gopsutil/load github.com/shirou/gopsutil/mem 
> > > github.com/shirou/gopsutil/net github.com/shirou/gopsutil/process 
> > > returned exit code 1
> > 
> > The full build log is available from:
> >
> > http://qa-logs.debian.net/2020/12/05/golang-github-shirou-gopsutil_2.19.11-3_unstable.log
> [...]
> 
> With the above log I will, without ever looking deeper at the problem,
> claim that gopsutil parsing of /proc/cpuinfo does not work on your
> architecture of choice.
> 
> I've briefly dug into this package in the past[1] and unless my memory
> serves me wrong my conclusion was that gopsutil's assumptions about
> /proc is not intended to be portable between architectures at all.
> On the other hand /proc looking wildly different between architectures
> on linux is kind of a problem that each architecture that is not the
> most popular one is setting themselves up for problems with. Not even
> using the same syntax in /proc/cpuinfo (or even using same keywords
> as used on mainstream archs, but give them a different meaning!).
> 
> I would personally expect that porters steps up if they want a
> particular piece of software ported to their arch, but I doubt that will
> happen. I also very much doubt anyone else will port to a wide range of
> architectures, or even a single one - plus maintain it.
> 
> I can thus suggest one "solution":
> Disable the testsuite on !amd64 and just let it build without actually
> ever having a chance of working except possibly by chance.
> (We all did this for so many years while kfreebsd was still a testing
> migration blocker, so it's not like my suggestion is a new idea.)

Hi Andreas,

Is the above problem going to be a problem at runtime as well?
If so, I wonder if you should make this package "Architecture: amd64"
instead of "Architecture: all".

If the problem is only at build time (but the package works fine, when
installed, on all architectures), it might be better to leave it as is,
and just document in a bug that it can only be build on amd64. For
example:
retitle 976509 golang-github-shirou-gopsutil: FTBFS when building
arch:all on arch != amd64
severity 976509 minor

Lucas

Bug#976935: inkscape: FTBFS on ppc64el: make[3]: *** No rule to make target 'po/zh_TW.gmo', needed by 'share/templates/default_templates.timestamp'. Stop.

[Lucas Nussbaum]

On 11/12/20 at 16:42 +0100, Mattia Rizzolo wrote:
> Control: tag -1 unreproducible
> 
> On Wed, Dec 09, 2020 at 09:36:42AM +0100, Lucas Nussbaum wrote:
> > During a rebuild of all packages in sid, your package failed to build
> > on ppc64el. At the same time, it did not fail on amd64.
> > 
> > I'm marking this bug as severity:serious since your package currently has
> > ppc64el binary packages in unstable (so this is a regression).
> 
> That's surprising.
> 
> > > make[3]: Entering directory '/<>/obj-powerpc64le-linux-gnu'
> > > make[3]: *** No rule to make target 'po/zh_TW.gmo', needed by 
> > > 'share/templates/default_templates.timestamp'.  Stop.
> > > make[3]: Leaving directory '/<>/obj-powerpc64le-linux-gnu'
> > > make[2]: *** [CMakeFiles/Makefile2:6529: 
> > > share/templates/CMakeFiles/default_templates.dir/all] Error 2
> 
> TBH, such a failure reeks of parallelism-induced inconsistency in the
> makefile.  which is surprising since this package uses cmake…
> 
> > The full build log is available from:
> >http://qa-logs.debian.net/2020/12/09/inkscape_1.0.1-2_unstable.log
> > 
> > If you fail to reproduce this, please provide a build log and diff it with 
> > me
> > so that we can identify if something relevant changed in the meantime.
> 
> Indeed I tried on plummer.d.o and I couldn't reproduce this.
> Attached is my build log, but I couldn't really spot anything due to the
> re-ordered log lines.
> Anyway, that .gmo is correctly produced.
> 
> Do you have any hint as to what might have caused such failure on your
> hand?

Hi,

I tried again under the same conditions (just to make sure it wasn't
transient) and could reproduce the failure.

I also tried after disabling SMT (so the machine has only 20 visible
CPUs) and it succeeded.

Still with SMT disabled, I tried with forcing
DEB_BUILD_OPTIONS=parallel=200, and it failed. Can you reproduce it like
that?

Lucas

Bug#959875: RFS: redmine-plugin-apijs/6.5.0-1 [ITP] -- Redmine plugin to display, gallery from attachments

[Fabrice Creuzot]

I uploaded a new package release (6.5.0-1).

Bug#977178: [debian-mysql] Bug#977178: mariadb-plugin-rocksdb: Server crashes in rocksdb on startup on pmull on some ARM CPUs

[Michal Povinsky]

> Can you please help out and try to produce a repeatable test case to
> trigger this bug?

I managed to reproduce the issue in a KVM virtual machine running on a
Raspberry Pi 4.
The detail I was missing was having to restart the server twice after
creating a rocksdb table.
I believe it should be possible to reproduce the issue on an emulated
VM, but I couldn't find a way to configure CPU features in QEMU as
required.

-- Check that crc32 is supported, but pmull isn't.
root@armtest:~# grep Features /proc/cpuinfo
Features: fp asimd evtstrm crc32 cpuid

root@armtest:~# apt-get install mariadb-plugin-rocksdb
root@armtest:~# mysql <<< "CREATE DATABASE a; USE a; CREATE TABLE a
(id INT PRIMARY KEY) ENGINE=ROCKSDB; INSERT INTO a VALUES (1);"
root@armtest:~# mysql <<< "SELECT * FROM a.a;"
-- This returns correct results

root@armtest:~# systemctl restart mysql
root@armtest:~# mysql <<< "SELECT * FROM a.a;"
-- Restart mysql once, everything still works

root@armtest:~# systemctl restart mysql
Job for mariadb.service failed because a fatal signal was delivered to
the control process.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
-- But the second restart fails!

Bug#936604: FYI: Python 3 migration of distributuion

[Moritz Muehlenhoff]

On Sat, Dec 12, 2020 at 03:21:06PM +0900, Osamu Aoki wrote:
> Hi,
> 
> It's a fork with a new upstream with some issues.  (Not supported by
> the old upstream)
> 
> Anyway, I switched out from getmail to other MUA.
> 
> No one seems to take over this package maintenance.
> 
> So please remove this package.

Ack, will file an RM bug.

> I am not going to package the new getmail6.

getmail6 _is_ packaged already :-)

https://packages.qa.debian.org/g/getmail6.html

Cheers,
Moritz

Bug#975672: xylib: FTBFS against boost_1.74

[Marcin Wojdyr]

This was fixed in the latest release upstream:
https://github.com/wojdyr/xylib/releases
but unfortunately I'm no longer able to maintain the Debian package.
The only package that depends on xylib is fityk. Perhaps fityk
maintainers could help.

Best wishes,
Marcin

Bug#977193: julia REPL crashes on simple function

[Zoltan Barta]

Package: julia
Version: 1.5.3+dfsg-2+b2
Severity: important
X-Debbugs-Cc: zbar...@gmail.com

Dear Maintainer,

   * What led up to the situation?

When I am running these in the REPL there is no problem.

julia> include("good.jl")
probak (generic function with 2 methods)

julia> c,f = probak()
([[1, 2, 3]], [1.0954451150103321])

On the other hand, running these crashes julia:

julia> include("bad.jl")
probak (generic function with 2 methods)

julia> c,f = probak()

The only difference between good.jl and bad.jl is this line (both attached):
randn() < 0.0 && return [4,5,6], 1.233
vs
randn() < 0.0 && return [4,5,6]

Runing at the command line, (e.g. julia bad.jl) runs without problems.

Many thanks for your effort,
Zoltan

>>> Content of bad.jl:

function proba(;α = 0.1)
randn() < 0.0 && return [4,5,6]
return [1,2,3], 1.2^α
end

function probak(α = 0.5)
kont1 = Array{Array{Int,1},1}()
kont2 = Array{Float64, 1}()
k1, k2 = proba(α = α)
push!(kont1, k1)
push!(kont2, k2)
return kont1, kont2
end

<<<

>>> Content of good.jl

function proba(;α = 0.1)
randn() < 0.0 && return [4,5,6], 1.233
return [1,2,3], 1.2^α
end

function probak(α = 0.5)
kont1 = Array{Array{Int,1},1}()
kont2 = Array{Float64, 1}()
k1, k2 = proba(α = α)
push!(kont1, k1)
push!(kont2, k2)
return kont1, kont2
end

<<<

   * What exactly did you do (or not do) that was effective (or ineffective)?

julia> include("bad.jl")
probak (generic function with 2 methods)

julia> c,f = probak()

   * What was the outcome of this action?

Illegal inttoptr
  %23 = ptrtoint %jl_value_t addrspace(10)* %20 to i64, !dbg !19
Illegal inttoptr
  %24 = inttoptr i64 %23 to i64 addrspace(13)*, !dbg !19

signal (6): Aborted
in expression starting at REPL[2]:1
gsignal at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
abort at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
unknown function (ip: 0x7f315d7872f0)
_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE at 
/usr/bin/../lib/x86_64-linux-gnu/libLLVM-10.so.1 (unknown line)
_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE at 
/usr/bin/../lib/x86_64-linux-gnu/libLLVM-10.so.1 (unknown line)
_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE at 
/usr/bin/../lib/x86_64-linux-gnu/libLLVM-10.so.1 (unknown line)
unknown function (ip: 0x7f315d87a537)
unknown function (ip: 0x7f315d87d004)
unknown function (ip: 0x7f315d87dcce)
unknown function (ip: 0x7f315d87f12a)
unknown function (ip: 0x7f315d87fefd)
unknown function (ip: 0x7f315d880ec8)
unknown function (ip: 0x7f315d8100cb)
jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/libjulia.so.1 (unknown 
line)
unknown function (ip: 0x7f315d824854)
unknown function (ip: 0x7f315d8244f5)
unknown function (ip: 0x7f315d825087)
unknown function (ip: 0x7f315d825b1e)
unknown function (ip: 0x7f315d83e028)
unknown function (ip: 0x7f315d83e5e8)
jl_toplevel_eval_in at /usr/bin/../lib/x86_64-linux-gnu/libjulia.so.1 (unknown 
line)
eval at ./boot.jl:331
eval_user_input at 
/build/julia-pTK15f/julia-1.5.3+dfsg/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:134
repl_backend_loop at 
/build/julia-pTK15f/julia-1.5.3+dfsg/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:195
start_repl_backend at 
/build/julia-pTK15f/julia-1.5.3+dfsg/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:180
#run_repl#37 at 
/build/julia-pTK15f/julia-1.5.3+dfsg/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:292
run_repl at 
/build/julia-pTK15f/julia-1.5.3+dfsg/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:288
#807 at ./client.jl:399
jfptr_YY.807_56835.clone_1 at /usr/lib/x86_64-linux-gnu/julia/sys.so (unknown 
line)
unknown function (ip: 0x7f315d81ba8f)
jl_f__apply_latest at /usr/bin/../lib/x86_64-linux-gnu/libjulia.so.1 (unknown 
line)
#invokelatest#1 at ./essentials.jl:710 [inlined]
invokelatest at ./essentials.jl:709 [inlined]
run_main_repl at ./client.jl:383
exec_options at ./client.jl:313
_start at ./client.jl:506
jfptr__start_42866.clone_1 at /usr/lib/x86_64-linux-gnu/julia/sys.so (unknown 
line)
unknown function (ip: 0x5592d19e1755)
unknown function (ip: 0x5592d19e1332)
__libc_start_main at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
unknown function (ip: 0x5592d19e13d9)
Allocations: 771272 (Pool: 771185; Big: 87); GC: 1
Aborted

   * What outcome did you expect instead?

julia> include("good.jl")
probak (generic function with 2 methods)

julia> c,f = probak()
([[1, 2, 3]], [1.0954451150103321])


Julia versioninfo() output:
   _
   _   _ _(_)_ |  Documentation: https://docs.julialang.org
  (_) | (_) (_)|
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.3
 _/ |\__'_|_|_|\__'_|  |  Debian ⛬  julia/1.5.3+dfsg-2+b2
|__/   |

julia> using InteractiveUtils

julia> versioninfo()
Julia Version 1.5.3
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Core(TM) i7-

Bug#960788: [External] Re: Intel SOF audio firmware packaging

[Vincent Bernat]

 ❦ 11 décembre 2020 20:36 -05, Mark Pearson:

>> They seem to say future releases will be tagged. So, I think you should
>> use in gbp.conf:
>> 
>> upstream-tag = v%(version%~%-)s
>> pristine-tar = False
>> 
>> No need for upstream-branch since you won't use "gbp import-orig" as the
>> origin lives directly in git repository.
>> 
> Got it - I've made these changes and pushed them to the repository

You need to use "~rc" instead of "-rc", otherwise, users won't be able
to upgrade to "1.6" when they have "1.6-rc3" installed.

#v+
diff --git a/debian/changelog b/debian/changelog
index 1b404ac5e2e6..a5a29a905188 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-firmware-sof (1.6-rc3-1) UNRELEASED; urgency=medium
+firmware-sof (1.6~rc3-1) UNRELEASED; urgency=medium

   * Initial release. (Closes: #960788)

diff --git a/debian/gbp.conf b/debian/gbp.conf
index 12bd6acf629c..ac06bdd3b375 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,5 +1,5 @@
 [DEFAULT]
 debian-branch = debian/latest
-upstream-tag = v%(version%-%-)s
+upstream-tag = v%(version%~%-)s
 pristine-tar = False

#v-

> What do I need to do going forward to look after this? Is there anything
> in particular that is needed as new sof firmware is released? Just
> wanting to check what expectations are going forward and if there is
> anything I should be looking out for etc.

We wait until monday and then we can upload. When a new firmware is
released, you upgrade your repository on Salsa, ping me, I'll review and
upload. At some point, you may want to become a DM (Debian Maintainer)
to do upload of known packages yourself.

>> Also, did you test the package on real hardware or do you need me to
>> test it? I can test it, I just need to spend 10 minutes doing it.
> Tested on my X1Carbon7 and it works well. I have a bunch of other
> platforms I can try it on too if that helps but it will have to be next
> week.

No need, I'll test it on mine during the week-end.
-- 
It is often the case that the man who can't tell a lie thinks he is the best
judge of one.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"

Bug#976405: texlive-latex-base: pdflatex command fails while building doxygen

[Paolo Greppi]

Hi Hilmar,

Il 09/12/20 23:44, Hilmar Preuße ha scritto:

Control: reassign -1 src:doxygen
...
As explained this issue is probably not related to changed in TL base, hence 
I'm reassigning to src:doxygen .

For the other build failures, w/ docbook based documents I've opened Bug#976887 
w/ criticality serious to make sure the new TL packages do not migrate to 
testing until the issue is sorted out.

Hilmar


well done !

Paolo

Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/

[Andreas Henriksson]

On Sat, Dec 12, 2020 at 10:32:15AM +0100, Lucas Nussbaum wrote:
> Hi Andreas,
> 
> Is the above problem going to be a problem at runtime as well?

It depends on which part of /proc you use and how it deviates on
your architecture, but yes... eventually you'll hit something that
errors out in parsing or worse returns an answer that's just wildly
wrong/unexpected.

> If so, I wonder if you should make this package "Architecture: amd64"
> instead of "Architecture: all".
[...]

In theory, the right question is probably what anyone is willing to
support. Debian usually takes the naive approach of assuming porters
will fix up any issues once they're found, but that's not really how
things turn out in practise.

(Also if we limit the archs, what is the correct subset? The ones where
the testsuite succeeds? The ones where it actually works? The ones which
someone is actually promising to support?)

The practical problem is that if the arch field is changed
what happens to the entire reverse dependency tree that has
accumulated? Getting one thing removed from the archive is hard
and painful enough

Regards,
Andreas Henriksson

Bug#977093: s3ql FTBFS with pytest 6

[Nikolaus Rath]

On Dec 10 2020, Christian Kastner  wrote:
> Source: s3ql
> Version: 3.3.2+dfsg-2
> Severity: important
> User: pyt...@packages.debian.org
> Usertags: pytest-v6
>
> Hi,
>
> s3ql FTBFS with pytest 6 in experimental because it uses a
> removed feature "catch_log_handler", see:
>
> https://docs.pytest.org/en/stable/changelog.html#id60

This is fixed upstream, just needs a new Debian release.


Best,
-Nikolaus
-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#977086: python-dugong FTBFS with pytest 6

[Nikolaus Rath]

On Dec 10 2020, Christian Kastner  wrote:
> Source: python-dugong
> Version: xx
> Severity: important
> User: pyt...@packages.debian.org
> Usertags: pytest-v6
>
> Hi,
>
> python-dugong FTBFS with pytest 6 in experimental because it uses a
> removed feature "catch_log_handler", see:
>
> https://docs.pytest.org/en/stable/changelog.html#id60

This is fixed upstream, just needs a new Debian release.


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#977104: s3ql: Missing dependency on python3-systemd

[Nikolaus Rath]

On Dec 10 2020, Leandro Lisboa Penz  wrote:
> Package: s3ql
> Version: 3.3.2+dfsg-2+b2
> Severity: important
>
> Dear Maintainer,
>
> The package is missing a dependency on python3-systemd:
>
> $ mount.s3ql --systemd --log none --fg s3://... "$HOME/..."
> <6>Using 10 upload threads.
> <6>Autodetected 1048514 file descriptors available for cache entries
> <6>Using cached metadata.
> <6>Setting cache size to 3152 MB
> <6>Mounting s3://... at ...
> <6>Unmounting file system...
> <3>Uncaught top-level exception:
> Traceback (most recent call last):
>   File "/usr/bin/mount.s3ql", line 33, in 
> sys.exit(load_entry_point('s3ql==3.3.2', 'console_scripts', 
> 'mount.s3ql')())
>   File "/usr/lib/s3ql/s3ql/mount.py", line 205, in main
> import systemd.daemon
> ModuleNotFoundError: No module named 'systemd'

This module is not actually needed. I suspect the reason this breaks is
that in Python 3.9 missing modules raise ModuleNotFoundError (rather
than ImportError as before). Should be a pretty simple
patch. Alternatively, we could of course also just depend systemd.



Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#977195: libboost-all-dev is missing a dependency on libboost-nowide-dev

[Matthias Klose]

Package: src:boost-defaults
Version: 1.74.0.2
Severity: serious

libboost-all-dev is missing a dependency on the newly introduced
libboost-nowide-dev.

please also bump debhelper and standards versions with a new upload.

Bug#901931: Hi dear

[Willian Reese]

How are you

Bug#977177: mm-common: reproducible builds: Generated tarball includes user, group and file mode

[Simon McVittie]

On Fri, 11 Dec 2020 at 20:45:09 -0800, Vagrant Cascadian wrote:
> If anyone has a better handle on python's tarfile mode handling code, it
> might be worth taking a closer look. I'm not entirely sure how the file
> modes work in this code (they don't appear to use modes similar to those
> used by umask, chmod or python's file functions)

It looks like they're encoded in the same way as st_mode in a struct
stat_buf: the low bits are Unix permissions (which start making sense
if you print them in octal) and the high bits are file type. See the
documentation for the stat Python module, and in particular stat.S_IMODE
and stat.S_IFMT.

I think the correct normalization would be something like this (untested!):

if tarinfo.isdir() or (tarinfo.mode & 0o111) != 0:
tarinfo.mode = stat.S_IFMT(tarinfo.mode) | 0o755
else:
tarinfo.mode = stat.S_IFMT(tarinfo.mode) | 0o644

(that's the same as chmod a+rX,og-w).

smcv

Bug#977187: FTBFS with glade 3.38

[Laurent Bigonville]

tag 977187 + patch
thanks

Hello,

The attached patch fix the compilation with glade 3.38. It still 
compiling fine with the previous version


The patch is inspired from an upstream one, see 
https://gitlab.gnome.org/GNOME/libhandy/-/issues/335


Can you apply it? Otherwise I'll do NMU in the following days as I 
really would like to have the last version of glade in unstable


Kind regards,

Laurent Bigonville

--- a/src/handy.h
+++ b/src/handy.h
@@ -24,6 +24,16 @@ G_BEGIN_DECLS
 #errorlibhandy is unstable API. You must define HANDY_USE_UNSTABLE_API before including handy.h
 #endif
 
+#ifdef HANDY_COMPILATION
+#ifndef GWA_GET_CLASS
+#define GWA_GET_CLASS GLADE_WIDGET_ADAPTOR_GET_ADAPTOR_CLASS
+#endif
+
+#ifndef GPC_OBJECT_DELIMITER
+#define GPC_OBJECT_DELIMITER GLADE_PROPERTY_DEF_OBJECT_DELIMITER
+#endif
+#endif
+
 #include "hdy-version.h"
 #include "hdy-action-row.h"
 #include "hdy-animation.h"

Bug#977196: RFS: 4pane/7.0-1 -- four-pane detailed-list file manager

[david]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "4pane"

 * Package name: 4pane
   Version : 7.0-1
   Upstream Author : David Hart 
 * URL : https://www.4Pane.co.uk
 * License : GPL-3
 * Vcs : https://github.com/dghart/4pane-debian-dir/tree/master/
   Section : x11

It builds those binary packages:

  4pane - four-pane detailed-list file manager

To access further information about this package, please visit the following
URL:

  https://mentors.debian.net/package/4pane

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/4/4pane/4pane_7.0-1.dsc

There is also a git repo:
 https://github.com/dghart/4pane-debian-dir

The upload is mostly for a new upstream release, but it also updates to
the latest standards etc.

This is a request for a review and upload of the update. The amended package
builds and works, and is lintian-clean.

Changes since the last upload:

   * New upstream release:
 - Fixes lintian acute-accent-in-manual-page tag.
   * debian/control:
 - Bump standards to 4.5.1 and 13
 - Fix lintian 'cute-field debian/control@source Vcs-browser vs Vcs-Browser'
   * debian/copyright:
 - Remove a duplicate entry.
   * debian/upstream/metadata:
 - Add missing fields.
   * debian/source:
 - remove override which is no longer necessary.

Regards,

David Hart

Bug#975593: python-mapnik: FTBFS against boost_1.74

[Sebastiaan Couwenberg]

Control: reassign -1 src:mapnik
Control: found -1 mapnik/3.0.23+ds-2
Control: tags -1 pending

This turns out to be an issue in mapnik, Fedora has a patch for
boost1.73 which fixes the python-mapnik FTBFS.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#977197: ITP: node-route-recognizer -- library that matches paths against registered routes

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name : node-route-recognizer
 Version : 0.3.4
 Upstream Author : Yehuda Katz
* URL : https://github.com/tildeio/route-recognizer
* License : Expat
 Programming Lang: JavaScript
 Description : library that matches paths against registered routes

route-recognizer is a lightweight JavaScript library (under 2k!) that
can be used as the recognizer for a more comprehensive router system
(such as router.js).
.
In keeping with the Unix philosophy, it is a modular library that does 
one

thing and does it well.
.
Node.js is an event-based server-side JavaScript engine.

This module is a dependency of miragejs module which is in turn a 
dependency of gitlab.

Bug#977194: installation-reports: Installation stalls on network devices search when wifi key plugged in

[Geert Stappers]

Control: tag -1 moreinfo

Hello Mathieu,


On Sat, Dec 12, 2020 at 12:02:31PM +0100, Mathieu Van Nieuwenhuyse wrote:
> Package: installation-reports

Thanks for the report


> Severity: normal
> Tags: d-i
> X-Debbugs-Cc: mathieu.van.nieuwenhu...@gmail.com
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> I launched the installation (via usb key) with both a wifi stick plugged in
> (TP-link Archer T2U) and an ethernet connexion
> the search for network devices stalled : no error message, nothing to do.
> 
> I restarted the installation without the wifi stick.
> 
> Everything worked fine then.

Acknowledge.


There are now two options:

A: Closing this bugreport
B: Keep this bugreport open for "fix bug"


Option A is a clear path.

What do you expect from option B?



Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#977193: [Pkg-julia-devel] Bug#977193: julia REPL crashes on simple function

[Norbert Preining]

Hi Zoltan,

thanks for your report. Interesting.

> signal (6): Aborted

I get the same indeed.

Then I tried:
- upstream original 1.5.2
worked, got answer, no error
- upstream original 1.5.3
got error
julia> c,f = probak()
ERROR: MethodError: Cannot `convert` an object of type Int64 to an 
object of type Array{Int64,1}
Closest candidates are:
  convert(::Type{T}, ::AbstractArray) where T<:Array at array.jl:554
  convert(::Type{T}, ::T) where T<:AbstractArray at abstractarray.jl:14
  convert(::Type{T}, ::LinearAlgebra.Factorization) where 
T<:AbstractArray at 
/buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/LinearAlgebra/src/factorization.jl:55
  ...
Stacktrace:
 [1] push!(::Array{Array{Int64,1},1}, ::Int64) at ./array.jl:934
 [2] probak at /home/norbert/Development/Julia/bugs/977193/bad.jl:10 
[inlined]
 [3] probak() at /home/norbert/Development/Julia/bugs/977193/bad.jl:7
 [4] top-level scope at REPL[2]:1

Both official Julia packages are compiled with LLVM9, while the one in
Debian with LLVM10.


> in expression starting at REPL[2]:1
> gsignal at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
> abort at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
> unknown function (ip: 0x7f315d7872f0)
> _ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE at 
> /usr/bin/../lib/x86_64-linux-gnu/libLLVM-10.so.1 (unknown line)
> _ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE at 
> /usr/bin/../lib/x86_64-linux-gnu/libLLVM-10.so.1 (unknown line)
> _ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE at 
> /usr/bin/../lib/x86_64-linux-gnu/libLLVM-10.so.1 (unknown line)

I will build Debian julia 1.5.3 packages and see how they fare!

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#977198: cups service should start after nslcd service

[Wolfgang Schweer]

Package: cups
Version: 2.3.3op1-3
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: debian-edu

Dear Maintainer,

while working on Debian Edu 11 Bullseye, I noticed the cups service 
failing randomly after rebooting the system:

● cups.service - CUPS Scheduler
 Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: 
enabled)
 Active: failed (Result: exit-code) since Sat 2020-12-12 10:25:50 CET; 3min 
46s ago
TriggeredBy: ● cups.path
 ● cups.socket
   Docs: man:cupsd(8)
Process: 1201 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE)
   Main PID: 1201 (code=exited, status=1/FAILURE)

Dez 12 10:25:50 tjener.intern systemd[1]: Failed to start CUPS Scheduler.
Dez 12 10:25:50 tjener.intern systemd[1]: cups.service: Scheduled restart job, 
restart counter is at 5.
Dez 12 10:25:50 tjener.intern systemd[1]: Stopped CUPS Scheduler.
Dez 12 10:25:50 tjener.intern systemd[1]: cups.service: Start request repeated 
too quickly.
Dez 12 10:25:50 tjener.intern systemd[1]: cups.service: Failed with result 
'exit-code'.
Dez 12 10:25:50 tjener.intern systemd[1]: Failed to start CUPS Scheduler.

Debian Edu uses an LDAP group printer-admins in cups-files.conf like so:

SystemGroup lpadmin printer-admins

Please note that Debian Edu uses nslcd.

After adding the nslcd.service (in addition to sssd.service and 
ypbind.service) to the cups.service unit file, things work like 
expected, this is the proposed change:

diff --git a/scheduler/cups.service.in b/scheduler/cups.service.in
index 9e70b2973..a3fa0e83f 100644
--- a/scheduler/cups.service.in
+++ b/scheduler/cups.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=CUPS Scheduler
 Documentation=man:cupsd(8)
-After=network.target sssd.service ypbind.service
+After=network.target sssd.service ypbind.service nslcd.service
 Requires=cups.socket
 
 [Service]

Please check if the change could be accepted.

Wolfgang


signature.asc
Description: PGP signature

Bug#977199: lists.debian.org: Please create a new list: debian-localgroups

[Elena ``of Valhalla'']

Package: lists.debian.org
Severity: wishlist

Dear Maintainer,

please create a new mailing list for the local groups team.

name: debian-localgroups
rationale: 
the recently started local groups team needs a place where members
of the local groups can ask for support and the team can provide
guidance and material support.
short description:
Local Groups Team
long description:
Support for the organization of local events and other local group
activities.
category: Miscellaneous Debian
subscription policy: open
post policy: open
web archive: yes

Thanks

Bug#977200: ITP: node-miragejs -- client-side server to build, test and demo JavaScript apps

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name : node-miragejs
 Version : 0.1.41
 Upstream Author : Sam Selikoff
* URL : https://github.com/miragejs/miragejs
* License : Expat
 Programming Lang: JavaScript
 Description : client-side server to build, test and demo JavaScript 
apps


Mirage JS is an API mocking library that lets one build, test and 
share a
complete working JavaScript application without having to rely on any 
backend

services.
.
Node.js is an event-based server-side JavaScript engine.

This module is a dependency of gitlab.

Bug#977201: transition: glade

[Laurent Bigonville]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

I would like to upload glade 3.38 in unstable, but this requires a
transiton (libgladeui-2-6 -> libgladeui-2-13)

I tried to rebuild all the rdeps and they all build fine except libhandy
and libgtkdatabox

For libhandy I opened #977187 (with a patch).

For libgtkdatabox I opened #977184 but I'm not really sure that can be
fixed easily (at all?) as it seems there is a mismatch between gtk2 and
gtk3 in the source. IMVHO, the only option is to remove the glade
plugin. AFAICS, there is not rdeps in the archive, I've also a patch for
that.

Kind regards,
Laurent Bigonville


Ben file:

title = "glade";
is_affected = .depends ~ "libgladeui-2-6" | .depends ~ "libgladeui-2-13";
is_good = .depends ~ "libgladeui-2-13";
is_bad = .depends ~ "libgladeui-2-6";


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#777185: cli-common-dev: please make the debhelper script additions reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Friendly ping on this?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#885326: flask-peewee: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Gentle ping on this?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#891073: clblas: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Friendly ping on this?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#940013: apophenia: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Friendly ping on this?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#929208: xorg-gtest: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Friendly ping on this?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#977187: FTBFS with glade 3.38

[Guido Günther]

Hi Laurent,
On Sat, Dec 12, 2020 at 10:03:32AM +0100, Laurent Bigonville wrote:
> Source: libhandy
> Version: 0.0.13-2
> Severity: important
> 
> Hello,
> 
> libhandy currently FTBFS with glade 3.38 that is currently in
> experimenal. This is preventing us to update it in unstable
> 
> The errors are:
> 
> FAILED: glade/libglade-handy.so.p/glade-hdy-header-group.c.o
> cc -Iglade/libglade-handy.so.p -Iglade -I../glade -I. -I.. -Isrc -I../src 
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
> -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gtk-3.0 
> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
> -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
> -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 
> -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 
> -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 
> -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 
> -I/usr/include/libgladeui-2.0 -I/<>/obj-x86_64-linux-gnu 
> -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
> -std=gnu11 -DHAVE_CONFIG_H -DHANDY_COMPILATION -Wcast-align -Wdate-time 
> -Wdeclaration-after-statement -Werror=format-security -Werror=format=2 
> -Wendif-labels -Werror=incompatible-pointer-types 
> -Werror=missing-declarations -Werror=overflow -Werror=return-type 
> -Werror=shift-count-overflow -Werror=shift-overflow=2 
> -Werror=implicit-fallthrough=3 -Wformat-nonliteral -Wformat-security 
> -Winit-self -Wmaybe-uninitialized -Wmissing-field-initializers 
> -Wmissing-include-dirs -Wmissing-noreturn -Wnested-externs 
> -Wno-missing-field-initializers -Wno-sign-compare -Wno-strict-aliasing 
> -Wno-unused-parameter -Wold-style-definition -Wpointer-arith 
> -Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum 
> -Wtype-limits -Wundef -Wunused-function -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD 
> -MQ glade/libglade-handy.so.p/glade-hdy-header-group.c.o -MF 
> glade/libglade-handy.so.p/glade-hdy-header-group.c.o.d -o 
> glade/libglade-handy.so.p/glade-hdy-header-group.c.o -c 
> ../glade/glade-hdy-header-group.c
> ../glade/glade-hdy-header-group.c: In function 
> ‘glade_hdy_header_group_read_widgets’:
> ../glade/glade-hdy-header-group.c:46:46: error: ‘GPC_OBJECT_DELIMITER’ 
> undeclared (first use in this function)
>46 |   g_strdup_printf ("%s%s%s", string, GPC_OBJECT_DELIMITER,
>   |  ^~~~
> ../glade/glade-hdy-header-group.c:46:46: note: each undeclared identifier is 
> reported only once for each function it appears in
> ../glade/glade-hdy-header-group.c: In function 
> ‘glade_hdy_header_group_read_widget’:
> ../glade/glade-hdy-header-group.c:77:3: warning: implicit declaration of 
> function ‘GWA_GET_CLASS’; did you mean ‘G_TASK_GET_CLASS’? 
> [-Wimplicit-function-declaration]
>77 |   GWA_GET_CLASS (G_TYPE_OBJECT)->read_widget (adaptor, widget, node);
>   |   ^
>   |   G_TASK_GET_CLASS
> ../glade/glade-hdy-header-group.c:77:3: warning: nested extern declaration of 
> ‘GWA_GET_CLASS’ [-Wnested-externs]
> ../glade/glade-hdy-header-group.c:77:32: error: invalid type argument of ‘->’ 
> (have ‘int’)
>77 |   GWA_GET_CLASS (G_TYPE_OBJECT)->read_widget (adaptor, widget, node);
>   |^~
> ../glade/glade-hdy-header-group.c: In function 
> ‘glade_hdy_header_group_write_widget’:
> ../glade/glade-hdy-header-group.c:123:32: error: invalid type argument of 
> ‘->’ (have ‘int’)
>   123 |   GWA_GET_CLASS (G_TYPE_OBJECT)->write_widget (adaptor, widget, 
> context, node);
>   |^~
> ../glade/glade-hdy-header-group.c: In function 
> ‘glade_hdy_header_group_set_property’:
> ../glade/glade-hdy-header-group.c:157:34: error: invalid type argument of 
> ‘->’ (have ‘int’)
>   157 | GWA_GET_CLASS (G_TYPE_OBJECT)->set_property (adaptor, object,
>   |  ^~
> 
> Could you have a look please?

sure. I've disabled glade support since this is troublesome with
libhandy-1's glade support anyway.
Cheers,
 -- Guido

Bug#966590: git-remote-bzr(1) manual page: broken link

[Jelmer Vernooij]

On Fri, Jul 31, 2020 at 02:25:55PM +0800, Paul Wise wrote:
> Package: brz
> Version: 3.1.0-5
> Severity: minor
> File: /usr/share/man/man1/git-remote-bzr.1.gz
> 
> There is a broken link in the manual page, looks like dropping "-git"
> from the URL should fix the link.
> 
> $ zgrep http /usr/share/man/man1/git-remote-bzr.1.gz 
> Please report bugs at \fUhttps://launchpad.net/brz-git/+filebug\fR
> 
> $ wget https://launchpad.net/brz-git/+filebug
> --2020-07-31 14:23:13--  https://launchpad.net/brz-git/+filebug
> Resolving launchpad.net (launchpad.net)... 91.189.89.223, 91.189.89.222, 
> 2001:67c:1560:8003::8003, ...
> Connecting to launchpad.net (launchpad.net)|91.189.89.223|:443... connected

I've fixed this upstream. It should make it into 3.1.1-1.

Bug#977184: FTBFS with glade 3.38.1-1

[Laurent Bigonville]

The problem seems to be coming from a mix of GTK 2 and GTK 3 headers.

Looking at the build logs of the current version, I see that the call to 
gcc already has "-I/usr/include/gtk-2.0" (coming from libgtkdatabox 
itself) and -I/usr/include/gtk-3.0" (coming via the pkg-config file of 
glade).


As libgtkdatabox is GTK2 and glade GTK3 there are data structure that 
are different (has this even worked in the past?)


I'll push a NMU to the delayed/10 queue with some other changes.

Kind regards,

Laurent Bigonville

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Shengjing Zhu]

Package: im-config
Severity: normal
X-Debbugs-Cc: z...@debian.org

According to https://github.com/fcitx/fcitx5/pull/161#issuecomment-735234080
Upstream wants people to use "fcitx" in *_IM_MODULE environment.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages im-config depends on:
ii  gettext-base  0.19.8.1-10

Versions of packages im-config recommends:
ii  whiptail0.52.21-4+b3
ii  x11-common  1:7.7+21

im-config suggests no packages.

Bug#977202: libgtkdatabox: diff for NMU version 1:0.9.3.1-1.1

[Laurent Bigonville]

Package: libgtkdatabox
Version: 1:0.9.3.1-1
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for libgtkdatabox (versioned as 1:0.9.3.1-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru libgtkdatabox-0.9.3.1/debian/changelog 
libgtkdatabox-0.9.3.1/debian/changelog
--- libgtkdatabox-0.9.3.1/debian/changelog  2019-01-13 12:50:01.0 
+0100
+++ libgtkdatabox-0.9.3.1/debian/changelog  2020-12-12 14:19:46.0 
+0100
@@ -1,3 +1,18 @@
+libgtkdatabox (1:0.9.3.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop libgtkdatabox0-libglade package and stop using ancient libglade2
+(Closes: #653827, #967875)
+  * Drop libgtkdatabox0-glade package, there is a mix between GTK+2.0 and
+GTK+3.0 headers when compiled with the newer version of glade. This fix a
+FTBFS with glade 3.38 (Closes: #977184)
+  * Remove Ramakrishnan Muthukrishnan from the Uploaders list, thanks to him
+for his past work on the package (Closes: #859284)
+  * debian/patches/cross.patch: Fix cross-compilation, thanks Helmut Grohne
+for the patch (Closes: #894046)
+
+ -- Laurent Bigonville   Sat, 12 Dec 2020 14:19:46 +0100
+
 libgtkdatabox (1:0.9.3.1-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru libgtkdatabox-0.9.3.1/debian/control 
libgtkdatabox-0.9.3.1/debian/control
--- libgtkdatabox-0.9.3.1/debian/control2019-01-13 12:50:01.0 
+0100
+++ libgtkdatabox-0.9.3.1/debian/control2020-12-12 14:19:46.0 
+0100
@@ -1,7 +1,6 @@
 Source: libgtkdatabox
 Maintainer: Debian Science Maintainers 

-Uploaders: Ramakrishnan Muthukrishnan ,
-   Andreas Tille ,
+Uploaders: Andreas Tille ,
Daniele E. Domenichelli 
 Section: science
 Priority: optional
@@ -10,9 +9,7 @@
libgtk2.0-dev,
libcairo2-dev,
libpango1.0-dev,
-   gtk-doc-tools,
-   libglade2-dev,
-   libgladeui-dev
+   gtk-doc-tools
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/science-team/libgtkdatabox
 Vcs-Git: https://salsa.debian.org/science-team/libgtkdatabox.git
@@ -67,56 +64,6 @@
  coordinates, thus allowing you to easily create powerful applications for
  data analysis.
 
-Package: libgtkdatabox0-glade
-Architecture: any
-Depends: ${shlibs:Depends},
- ${misc:Depends}
-Conflicts: libgtkdatabox-0.9.2-0-glade,
-   libgtkdatabox-0.9.3-0-glade
-Replaces: libgtkdatabox-0.9.2-0-glade,
-  libgtkdatabox-0.9.3-0-glade
-Description: Gtk+ library to display large amounts of numerical data (glade 
API)
- One or more data sets of thousands of data points (X and Y coordinate) may be
- displayed and updated in split seconds. The widget is therefore used in many
- scientific and private projects that need to show quickly changing data live.
- GtkDatabox offers the ability to zoom into and out of the data and to navigate
- through your data by scrolling.
- .
- In addition to rulers and a simple coordinate cross, GtkDatabox now also 
allows
- you to add one (or even more) configurable grids like on an oscilloscope.
- .
- Data may be presented as dots, lines connecting the data, or vertical bars.
- The widget allows you to easily transform pixel coordinates into data
- coordinates, thus allowing you to easily create powerful applications for
- data analysis.
- .
- Modules for GUI development with Glade3
-
-Package: libgtkdatabox0-libglade
-Architecture: any
-Depends: ${shlibs:Depends},
- ${misc:Depends}
-Conflicts: libgtkdatabox-0.9.2-0-libglade,
-   libgtkdatabox-0.9.3-0-libglade
-Replaces: libgtkdatabox-0.9.2-0-libglade,
-  libgtkdatabox-0.9.3-0-libglade
-Description: Gtk+ library to display large amounts of numerical data (glade 
lib)
- One or more data sets of thousands of data points (X and Y coordinate) may be
- displayed and updated in split seconds. The widget is therefore used in many
- scientific and private projects that need to show quickly changing data live.
- GtkDatabox offers the ability to zoom into and out of the data and to navigate
- through your data by scrolling.
- .
- In addition to rulers and a simple coordinate cross, GtkDatabox now also 
allows
- you to add one (or even more) configurable grids like on an oscilloscope.
- .
- Data may be presented as dots, lines connecting the data, or vertical bars.
- The widget allows you to easily transform pixel coordinates into data
- coordinates, thus allowing you to easily create powerful applications for
- data analysis.
- .
- Libraries for run-time GUI loading with libglade
-
 Package: libgtkdatabox-doc
 Architecture: all
 Section: doc
diff -Nru libgtkdatabox-0.9.3.1/debian/patches/01_libglage_example.patch 
libgtkdatabox-0.9.3.1/debian/patches/01_libglage_example.patch
--- libgtkdatabox-0.9.3.1/debian/patches/01_libglage_example.patch  
2019-01-13 12:50:01.0 +0100
+++ 

Bug#973459: uim: FAIL: test-composer.scm

[Sebastian Ramacher]

Control: severity -1 serious

On 2020-11-19 11:25:39 +0900, d...@debian.org wrote:
> Control: severity -1 important
> 
> > Indeed, after the second retry uim built fine.
> > 
> > Removing the block, but not closing because a race condition may be a
> > valid bug.
> 
> I lower the severity once because it is not always an build error.

And it failed already twice for the Qt 5.15.2 transition, so I'm raising
the severity. Please investigate and fix this issue.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#977185: nheko: switch to Boost 1.74

[Matthias Klose]

please consider using the unversioned build dependency, like any other package
is doing it.

Bug#977204: cwiid: Wrong homepage

[Davide Prina]

Source: cwiid
Version: 0.6.91-2
Severity: normal

I have see that the project homepage do not respond anymore:
http://abstrakraft.org/cwiid/

I think that the homepage is now:
https://github.com/abstrakraft/cwiid

Ciao
Davide

Bug#977205: imagemagick: CVE-2020-29599

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.11.24+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for imagemagick.

A very extensive blogpost[1] explains the issue, and note that the
provided POC though does only work so far in ImageMagick7 the issue is
present as well in legacy ImageMagick 6, affected versions should be
around 6.9.8-1 onwards.

The required fixes for ImageMagick6 are referenced in the
security-tracker.

As a side node: For buster the issue is mitigated as the recent DSA
included the 200-disable-ghostscript-formats.patch patch and disables
ghostscript handled formats. As a hardening measure against those
issue it might be ideal to ship the disabling as well in bullseye.

CVE-2020-29599[0]:
| ImageMagick before 6.9.11-40 and 7.x before 7.0.10-40 mishandles the
| -authenticate option, which allows setting a password for password-
| protected PDF files. The user-controlled password was not properly
| escaped/sanitized and it was therefore possible to inject additional
| shell commands via coders/pdf.c.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-29599
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29599
[1] 
https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html

Regards,
Salvatore

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-rc6-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#977206: cylc: Wrong homepage

[Davide Prina]

Source: cylc
Version: 8.0~a2-1
Severity: normal

I have see that the project homepage do not respond anymore:
https://cylc.github.io/cylc

I think that the homepage is now:
https://cylc.github.io/
https://github.com/cylc

Ciao
Davide

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Gunnar Hjalmarsson]

On 2020-12-12 14:48, Shengjing Zhu wrote:

According to https://github.com/fcitx/fcitx5/pull/161#issuecomment-735234080
Upstream wants people to use "fcitx" in *_IM_MODULE environment.


This was commit by Boyuan Yang a while ago:

https://salsa.debian.org/input-method-team/im-config/-/commit/0dc20c88

and reverted a few weeks later:

https://salsa.debian.org/input-method-team/im-config/-/commit/2515d3db

Are you sure this time? :)

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#922677: Please update this package for Bullseye

[Diederik de Haas]

It would be really great if this package would receive an update before the 
Bullseye freeze/release.

Upstream moved to https://github.com/nhorman/rng-tools/ as both Sjoerd and bug 
#970388 mentioned.
Release 6.10 (https://github.com/nhorman/rng-tools/releases/tag/v6.10) would 
already be a great improvement, but if you'd use a recent snapshot (ceb30b2ea 
or later), that would also fix bug #847962. 
I already tried to entice upstream maintainer to release a new version in 
https://github.com/nhorman/rng-tools/issues/105#issuecomment-732994509 but 
coming from the maintainer of Debian's package of it may likely carries more 
weight.

Cheers,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Bug#944968: popularity-contest: Program accesses internal dpkg database

[Bill Allombert]

On Thu, Nov 28, 2019 at 08:55:00PM +, Niels Thykier wrote:
> On Tue, 19 Nov 2019 11:27:56 +0100 Bill Allombert 
> 
> While it would take a bit of restructuring / refactoring, I think it
> would be possible to use a single dpkg-query for everything and still be
> able to process the data in a "streaming" fashion.
> 
> As an example, using the following:
> 
>   dpkg-query --show \
> --showformat='${status} ${package}\n${db-fsys:Files}\n\n'

Hello Guillem,

I am trying to implement this to see how well this perform.
Unfortunately it seems it does not provide a stable interface across release,
but maybe I am doing something wrong.

dpkg-query --show --showformat='${status} 
${package}\n${db-fsys:Files}\n\n'|head -n1

On buster:
deinstall ok config-files 0ad

On sid:
(Lecture de la base de données... 134812 fichiers et répertoires déjà
installés.)

Cheers,
Bill.

Bug#977123: Aw: Re: Bug#977123: ldapadd: simple authentication works without setting of -x

[Werner . Heuser]

Hi Quanah,

thank you for your support. I have double checked again:
- I use a static configuration with slapd.conf
- slapd was startet from the command line
- with no ACLs
- no $HOME/.ldaprc
- default Debian /etc/ldap/ldap.conf
- no aliases for ldap-clients

ldapwhoami, ldapsearch _require_ -x for simple binds without SASL
ldapadd, and also ldapdelete work _without_ -x (and of course with -x)
when I try to connect to a slapd running on the same machine.

Best regards,

Werner

> Gesendet: Freitag, 11. Dezember 2020 um 18:02 Uhr
> Von: "Quanah Gibson-Mount" 
> An: werner.heu...@web.de, 977...@bugs.debian.org
> Betreff: Re: Bug#977123: ldapadd: simple authentication works without setting 
> of -x
>
>
>
> --On Friday, December 11, 2020 8:20 AM +0100 David Damago
>  wrote:
>
> > Package: ldap-utils
> > Version: 2.4.47+dfsg-3+deb10u4
> > Severity: minor
> > Tags: upstream
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Hello,
> >
> > ldapadd used without -x and without SASL of course performs
> > a simple bind and add entries to the OpenLDAP server. Other
> > LDAP clients, e.g. ldapsearch, ldapwhoami, .. still
> > require -x for simple authentication.
> >
> > Thank you,
>
> Hi Werner,
>
> I do not see such behavior when using ldapadd against a publicly available
> ldap server:
>
> root@d10build:/var/log# ldapadd -H ldap://ldap.stanford.edu
> ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
> additional info: SASL(-4): no mechanism available: No worthy mechs
> found
>
>
> Instead, without -x, ldapadd immediately moves on to trying a SASL bind.
>
> Are you sure there isn't something providing defaults to the ldap client,
> such as an ~/.ldaprc file or modified /etc/ldap/ldap.conf?
>
> Regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
>

Bug#932197: Bug#937144: Request to join the Neurodebian group

[Yaroslav Halchenko]

On Thu, 30 Apr 2020, Moritz Mühlenhoff wrote:

> > Thanks for the hint.  While this could possibly speet up the upload of
> > nipype I for myself are fine with waiting for the new Build-Depends.
> > Anybody who wants to speed up things is kindly invited to add this patch
> > and upload.

> What's the status here? python-etelemetry is now in the archive and testing.

FWIW: I just uploaded rdflib 5.0.0 (recent nipype needs that
version if any) and pushed initial changes to nipype's packaging git for
1.6.0 . Will try to find more time over weekend to finalize packaging
update (if no other new depends etc) -- needed for heudiconv package
(currently present  nipype version incorrectly handles some DWIs, FYI
for those who care ;)).

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#976811: transition: php8.0

[Holger Levsen]

On Sat, Dec 12, 2020 at 08:05:19AM +0100, Ondřej Surý wrote:
> And let me restate that it’s not my intent to make anyone’s life hell and
> I am willing to help with any package (as usual). I am just trying to do
> the most sane thing to do security and maintainer wise.
 
oh sure, I never expected anything else, on the contrary. many thanks for
very nicely caring about php! (and other packages too! :)



signature.asc
Description: PGP signature

Bug#977147: texlive-base: "texdoc asymptote" pulls up an ancient version of the documentation

[Sanjoy Mahajan]

On 2020-12-12 09:05, Norbert Preining  wrote:

>> "texdoc asymptote" starts up a viewer with documentation for asymptote
>> 1.79 and in (I think) Chinese.  Meanwhile, I'm using asymptote 2.68.

> Indeed, the asymptote doc is not linked into the texmf tree and thus not
> found by texdoc. I faintly remember it was in former times, strange.

It used to work.  I had always run "texdoc asymptote" and got the
current documentation, at least until asymptote 2.44.  I'm not sure when
the problem showed up, however, as I'd pinned asymptote to that version
until a week ago (due to a backwards-incompatible change in asymptote's
behavior that would have messed up my next textbook's figures).

> I will fix it.
>
> basically
>   mkdir -p /usr/share/texmf/doc/support/asymptote/
>   ln -s ../../../../doc/asymptote/asymptote.pdf 
> /usr/share/texmf/doc/support/asymptote/asymptote.pdf
>   mktexlsr /usr/share/texmf/
> should (it did here) make
>   texdoc asymptote
> bring up the correct doc.

That works here too.  Thank you.

-Sanjoy

Bug#976922: systemd-bootchart: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2

[Michael Biebl]

Am 12.12.20 um 10:12 schrieb Lucas Nussbaum:

On 11/12/20 at 15:08 +0100, Michael Biebl wrote:



https://github.com/systemd/systemd-bootchart/pull/37
specifically
https://github.com/systemd/systemd-bootchart/pull/37/commits/65320230f5fcb02e81df5131a4dc03092558c263

Could you give this PR a try?


Hi,

This branch fixes the crash.


Thanks a lot, Lucas.

Regards,
Michael

Bug#977147: texlive-base: "texdoc asymptote" pulls up an ancient version of the documentation

[Norbert Preining]

Hi Sanjoy,

> It used to work.  I had always run "texdoc asymptote" and got the

Yes, that was my memory, too, but obviously it isn't anymore.

I have prepared an upload alreayd, but somehow broken connections
buggered up the files on ftp-master, will need a day or two to clear up.

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#977207: nmu: avldrums.lv2_0.4.1-1

[Dennis Braun]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: d_br...@kabelmail.de

nmu avldrums.lv2_0.4.1-1 . ANY . bullseye . -m "Upload to bullseye"

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash

Bug#977208: exim4 install failed

[Jörg Frings-Fürst]

Package: exim4
Version: 4.94-9
Severity: grave

Hello,

on a fresh bullseye/sid installation I get:

[qoute]
# apt update && apt install exim4
Hit:1 https://wire-app.wire.com/linux/debian stable InRelease
Hit:2 https://linux.teamviewer.com/deb stable InRelease
Hit:3 https://repo.skype.com/deb stable InRelease
Hit:4 https://josm.openstreetmap.de/apt alldist InRelease
Hit:5 http://security.debian.org/debian-security bullseye-security InRelease
Hit:6 http://mirror.1und1.de/debian unstable InRelease
Hit:7 http://deb.debian.org/debian bullseye InRelease
Hit:8 http://dl.google.com/linux/chrome/deb stable InRelease
Hit:10 https://download.jitsi.org stable/ InRelease
Hit:9 https://packagecloud.io/AtomEditor/atom/any any InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 exim4 : Depends: exim4-daemon-light (>= 4.94-9) but it is not installable or
  exim4-daemon-heavy (>= 4.94-9) but it is not installable or
  exim4-daemon-custom (>= 4.94-9) but it is not installable
E: Unable to correct problems, you have held broken packages.
[/quote]

But all packages have the right version:


[quote]
# apt policy exim4*
exim4-daemon-light:
  Installed: (none)
  Candidate: 4.94-9+b1
  Version table:
 4.94-9+b1 500
    500 http://deb.debian.org/debian bullseye/main amd64 Packages
    300 http://mirror.1und1.de/debian unstable/main amd64 Packages
exim4-daemon-heavy:
  Installed: (none)
  Candidate: 4.94-9+b1
  Version table:
 4.94-9+b1 500
    500 http://deb.debian.org/debian bullseye/main amd64 Packages
    300 http://mirror.1und1.de/debian unstable/main amd64 Packages
exim4-daemon-custom:
  Installed: (none)
  Candidate: (none)
  Version table:

exim4:
  Installed: (none)
  Candidate: 4.94-9
  Version table:
 4.94-9 500
    500 http://deb.debian.org/debian bullseye/main amd64 Packages
    300 http://mirror.1und1.de/debian unstable/main amd64 Packages
[/quote]

If you need some more infos ask me.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0] 
1.5.74
ii  exim4-base
4.94-9+b1
pn  exim4-daemon-light | exim4-daemon-heavy | exim4-daemon-custom 


exim4 recommends no packages.

exim4 suggests no packages.




signature.asc
Description: This is a digitally signed message part

Bug#977208: exim4 install failed

[Andreas Metzler]

On 2020-12-12 Jörg Frings-Fürst  wrote:
> Package: exim4
> Version: 4.94-9
> Severity: grave

> Hello,

> on a fresh bullseye/sid installation I get:

> [qoute]
> # apt update && apt install exim4
> Hit:1 https://wire-app.wire.com/linux/debian stable InRelease
[...]

Please, try apt dist-upgrade first.

cu Andreas

Bug#977209: transition: proftpd-dfsg

[Hilmar Preusse]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

This transition was already started by the recent proftpd upload, but is not
caught caught automatically since it is a virtual package name that has
changed.

Ben file:

title = "proftpd-dfsg";
is_affected = .depends ~ /proftpd-abi-/;
is_good = .depends ~ /proftpd-abi-1.3.7a+dfsg/;
is_bad = .depends ~ /proftpd-abi-1.3.7a/;

Thanks!

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 5.9.0-4-686-pae (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#894399: gzip.1: Some typographic corrections and cleaning of the manual

[Guinness]

Control: tag -1 -patch

-- 
Guinness


signature.asc
Description: PGP signature

Bug#977139: geeqie: fails immediatly after start

[Andreas Ronnquist]

On Fri, 11 Dec 2020 19:34:09 +0300
Ilya Ovchinnikov  wrote:

>On 11.12.2020 19:17, Andreas Ronnquist wrote:
>> On Fri, 11 Dec 2020 17:50:07 +0300
>> Ilya Ovchinnikov  wrote:
>>   
>>> Package: geeqie
>>> Version: 1:1.6-2
>>> Severity: grave
>>> Justification: renders package unusable

 8< 

>
>> I am guessing you are running X? (You can quickly find out by the
>> command
>> 
>> echo $XDG_SESSION_TYPE
>> in the terminal.)  
>
>x11
>

>[Detaching after vfork from child process 990936]
>[Thread 0x7fffceffd700 (LWP 990929) exited]
>^C
>Thread 1 "geeqie" received signal SIGINT, Interrupt.
>0x7617a39f in poll () from /lib/x86_64-linux-gnu/libc.so.6
>(gdb) bt
>#0  0x7617a39f in poll () at /lib/x86_64-linux-gnu/libc.so.6
>#1  0x77230e1e in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
>#2  0x7723117b in g_main_loop_run () at
>/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3  0x77a407a5 in
>gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #4
>0x555c9916 in  () #5  0x760add0a in __libc_start_main
>() at /lib/x86_64-linux-gnu/libc.so.6 #6  0x555ca54a in  ()
>(gdb)

Are you really sure that it is crashing? I have discovered that I can
reproduce your problem - I see the geeqie window flashing and
disappearing, and then press Ctrl+C in gdb to get the same backtrace.
What is happening is that geeqie is simply moved to another workspace
(probably the last workspace it was present on), and doesn't crash at
all. (I thought that it crashed, just like you). When you see this
behaviour, please check so geeqie isn't running on any workspace (which
I suspect it still does).

It sure fooled me! :)

/Andreas
gus...@debian.org

Bug#343575: zdiff should ideally inspect file contents to see if decompression is necessary

[Guinness]

Control: tags -1 -patch
stop


Need to rework the patch.

-- 
Guinness


signature.asc
Description: PGP signature

Bug#630111: /bin/zdiff: zdiff doesn't gunzip without .gz extension

[Guinness]

Control: tags -1 -patch
stop
-

Need to rework the patch.

-- 
Guinness


signature.asc
Description: PGP signature

Bug#960788: [External] Re: Intel SOF audio firmware packaging

[Mark Pearson]

On 12/12/2020 05:48, Vincent Bernat wrote:
>  ❦ 11 décembre 2020 20:36 -05, Mark Pearson:
> 
> You need to use "~rc" instead of "-rc", otherwise, users won't be able
> to upgrade to "1.6" when they have "1.6-rc3" installed.
> 
Ooops - my bad. I started wearing glasses this year...but don't always
put them on :)
I've corrected that. Thank you!

> 
>> What do I need to do going forward to look after this? Is there anything
>> in particular that is needed as new sof firmware is released? Just
>> wanting to check what expectations are going forward and if there is
>> anything I should be looking out for etc.
> 
> We wait until monday and then we can upload. When a new firmware is
> released, you upgrade your repository on Salsa, ping me, I'll review and
> upload. At some point, you may want to become a DM (Debian Maintainer)
> to do upload of known packages yourself.
> 
Great. Thanks again for your help.
Longer term I'd love to work towards becoming a DM - I think I still
have a lot of learning to do though :)

>>> Also, did you test the package on real hardware or do you need me to
>>> test it? I can test it, I just need to spend 10 minutes doing it.
>> Tested on my X1Carbon7 and it works well. I have a bunch of other
>> platforms I can try it on too if that helps but it will have to be next
>> week.
> 
> No need, I'll test it on mine during the week-end.
> 
Sound good - let me know if any issues.

As a note - I did find that for some reason the speaker is muted by
default and needed to go into alsamixer to unmute it (someone in the bug
saw the same effect and I've seen that previously on the P1G3 with
Debian). I don't believe that has anything to do with the SOF firmware
but is more likely an issue in ALSA/pulseaudio. I'll dig into that
separately.

Mark

Bug#977139: geeqie: fails immediatly after start

[Ilya Ovchinnikov]

On 12.12.2020 18:36, Andreas Ronnquist wrote:

On Fri, 11 Dec 2020 19:34:09 +0300
Ilya Ovchinnikov  wrote:


On 11.12.2020 19:17, Andreas Ronnquist wrote:

On Fri, 11 Dec 2020 17:50:07 +0300
Ilya Ovchinnikov  wrote:
   

Package: geeqie
Version: 1:1.6-2
Severity: grave
Justification: renders package unusable


 8< 




I am guessing you are running X? (You can quickly find out by the
command

echo $XDG_SESSION_TYPE
in the terminal.)


x11




[Detaching after vfork from child process 990936]
[Thread 0x7fffceffd700 (LWP 990929) exited]
^C
Thread 1 "geeqie" received signal SIGINT, Interrupt.
0x7617a39f in poll () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x7617a39f in poll () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x77230e1e in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7723117b in g_main_loop_run () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3  0x77a407a5 in
gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #4
0x555c9916 in  () #5  0x760add0a in __libc_start_main
() at /lib/x86_64-linux-gnu/libc.so.6 #6  0x555ca54a in  ()
(gdb)


Are you really sure that it is crashing? I have discovered that I can
reproduce your problem - I see the geeqie window flashing and
disappearing, and then press Ctrl+C in gdb to get the same backtrace.
What is happening is that geeqie is simply moved to another workspace
(probably the last workspace it was present on), and doesn't crash at
all. (I thought that it crashed, just like you). When you see this
behaviour, please check so geeqie isn't running on any workspace (which
I suspect it still does).

It sure fooled me! :)


Yes, it does exactly that! :)
Thank you and sorry for such foolish bug report!

Previous versions started in the current workplace and this remember the previous one. It 
can be changed in Edit/Preferences/Windows/Remember window positon -- probably it is 
better to keep it off as default?


With best regards,
Ilya Ovchinnikov



/Andreas
gus...@debian.org

Bug#977107: proftpd-basic: Cannot login after upgrade from jessie to stretch then to buster

[Francesco P. Lovergine]

tags 977107 = confirmed upstream
severity 977107 normal

thanks

Ok, I managed to replicate the issue by using the default configuration
and your snippet on buster. It works only by removing the 
AuthAliasOnly/AuthUsingAlias directives.


Also, I did a fast trial with the latest jessie version (several security 
patch had been applied during its support time) with the same results.


Same results with testing and moving AuthAliasOnly in global, too.


  AnonRequirePassword on
  RequireValidShell   off

   AuthAliasOnly   on   <- here the problem
   AuthUsingAlias  on   <- here the problem, even 
by using x for UserPassword

   Userwww-data
  UserAlias   x www-data
  Group   www-data
  Umask   003
  GroupOwner  www-data
  MaxClients  2
  AccessGrantMsg  "Acceso Permitido a %u - Toda su actividad esta siendo 
monitoreada."
  HideNoAccesson
  UserPasswordwww-data w4/CBsf6D7jf2



--
Francesco P. Lovergine

Bug#977210: redshift: AppArmor profile breaks under Wayland

[nicoo]

Package: redshift
Version: 1.12-3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi myself!

The AppArmor profile for redshift is broken under Wayland.
Since Wayland support just got added in this version, this is not a problem
for existing users of the package, but I should fix this ASAP.

The log message is pretty straightforward:

> kernel: audit: type=1400 audit(1607788832.946:72): apparmor="DENIED" 
> operation="mknod" profile="/usr/bin/redshift" 
> name="/run/user/1000/redshift-shared-DbzWVS" pid=1511436 comm="redshift" 
> requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

abstractions/wayland authorises manipulating /run/user/*/${name}-shared-*,
when the file is owned by the user, and ${name} belongs to a whitelist
(mesa, mutter, sdl, wayland-cursor, weston, or xwayland).

I do not know whether the rule in the abstraction should be made more flexible,
if redshift implements the wayland parts wrong (this is implemented from a patch
that upstream hasn't merged yet), or something else, so I am just going to add
this specific path pattern in redshift's AppArmor profile.


Best,

  nicoo


- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages redshift depends on:
ii  init-system-helpers  1.59
ii  libc62.31-5
ii  libdrm2  2.4.103-2
ii  libglib2.0-0 2.66.3-2
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libx11-6 2:1.6.12-1
ii  libxcb-randr01.14-2
ii  libxcb1  1.14-2
ii  libxxf86vm1  1:1.1.4-1+b2

Versions of packages redshift recommends:
ii  geoclue-2.0  2.5.6-1

redshift suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl/U6vMRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MvFbQ//ZYK3m0Qk40ATjCAjZKX8I3c6HCcrAzym
x5IOy0GfvAtrYh1VpWuuHC6fEu+FrDJYZSVGth+HSBrrmJaF90RuRbr3+SXM2Zwk
EBqwccfDnE7GSvgARQ8k5MRZs1+iGFTuriY1H3UuJT4QnWtX9tpuAR+NYLlDSgZP
yTBk0PIvVAMXlWDoO3Zo/UFjq0qHfRw5UNzRUs9nBiM+iLvF5l8nnkAWK/jXsLNI
NldGXGN3A8V0biveJgbCR0S+QSfTr1dHd/eDc8KimL1ZitFP9NZ4Qd5kjRG3JSbj
ltEGgXUS/IJa7fJe3urwLrahfGN5kGVBqpMjGIzQDEWsTvuRTWY58/a63AUswu+w
EEfI6/jXzooCjnS2butv1YcFpqhaze4fbN/35enoxBFDHwPOLE0FrijwdDhjXzCP
Tv86jb6RZCJcwnlVRxhXEbuOyd7PKNHknyGTdV9GcEPXtPam4DdJGffuKqUPidlM
L9neBqhkhk7IdD7JJb+yDcyrgBMbOz9ai/gplTmOTuoasVAsRYXokBZlsy2QVwF8
SGmOQuFTNXZ+L2fmmmAasF/O54qsxznXAFqBItjQiX1V/rgZeFUrFBVJGmm/9DMW
trbHrsLFUrc5H6kIcmvunG/j63pvYVV/g+0RnfZu2e4Tx8h6h9khFWnOplCJXvox
UHcmK9eSthI=
=XkJv
-END PGP SIGNATURE-

Bug#977211: d52: Wrong homepage

[Davide Prina]

Source: d52
Version: 3.4.1-1.1
Severity: normal

I have see that the project homepage do not respond anymore:
http://home.pacbell.net/theposts

I think that the homepage is now:
http://www.brouhaha.com/~eric/software/d52/
https://github.com/jblang/d52

Ciao
Davide

Bug#977139: geeqie: fails immediatly after start

[Andreas Ronnquist]

On Fri, 11 Dec 2020 19:34:09 +0300 Ilya Ovchinnikov  wrote:
> On 11.12.2020 19:17, Andreas Ronnquist wrote:
> > On Fri, 11 Dec 2020 17:50:07 +0300
> > Ilya Ovchinnikov  wrote:
> > 
> >> Package: geeqie
> >> Version: 1:1.6-2
> >> Severity: grave
> >> Justification: renders package unusable
> >>
> >> Dear Maintainer,
> >>
> >> Since last upgrade geeqie fails to start:
> >>
> >> % geeqie
> >>
> >> (geeqie:987585): Gtk-CRITICAL **: 17:45:52.857:
> >> gtk_box_gadget_distribute: assertion 'size >= 0' failed in
> >> GtkScrollbar
> >>

As in the upstream bug report - for a work-around please try to change
the preferences in Edit/Preferences/Windows and de-select "Remember
window positions".

/Andreas
gus...@debian.org

Bug#977046: Aw: Re: Bug#977046: parted: support pattern matching, e.g. parted -s /dev/sd[b-c] "print"

[Werner . Heuser]

Hi Colin,

thank you for your fast and friendly answer. Yes, indeed
my suggestion is only small and it's easy to use
a loop instead, of course.

The idea came to me, when I used parted to
prepare some disks for RAID as well
as for LVM2. Both tools (e.g. mdadm, pvcreate) can
handle a list of devices out of the box. So I just
wondered why  parted (and sfdisk) don't.

Best regards,

Werner

> Gesendet: Freitag, 11. Dezember 2020 um 10:53 Uhr
> Von: "Colin Watson" 
> An: werner.heu...@web.de, 977...@bugs.debian.org
> Betreff: Re: Bug#977046: parted: support pattern matching, e.g. parted -s 
> /dev/sd[b-c] "print"
>
> On Thu, Dec 10, 2020 at 04:51:39PM +0100, Werner Heuser wrote:
> > please consider to support pattern matching, e.g.
> > parted -s /dev/sd[b-c] "print"
>
> The problem with anything like this would be that the shell would expand
> the pattern, so parted itself would see the argument list as:
>
>   parted -s /dev/sdb /dev/sdc print
>
> The only ways I can think of to solve this would be:
>
>  * use a different pattern syntax that doesn't collide with shell
>metacharacters (unlikely to be a good idea)
>  * require users to quote the pattern to protect it from shell expansion
>(clumsy)
>  * allow -s to take multiple device arguments until they stop looking
>like valid devices
>
> But I think this is special-purpose enough that it's unlikely to be
> worth the effort to implement in parted, when you could just use a shell
> loop instead (granted, it's longer, but it composes nicely and the
> meaning is unambiguous):
>
>   for dev in /dev/sd[b-c]; do parted -s "$dev" print; done
>
> You're welcome to file your request directly upstream yourself, but
> since I'm not convinced that it should be implemented given the
> disadvantages, I don't currently plan to forward it.
>
> Thanks,
>
> --
> Colin Watson (he/him)  [cjwat...@debian.org]
>

Bug#977212: darnwdl: Wrong homepage

[Davide Prina]

Package: darnwdl
Version: 0.5-2
Severity: normal

I have see that the project homepage do not respond anymore:
http://www.openfoundry.org/of/projects/753

I think that the homepage is now:
https://github.com/grandpaul/darnwdl

Ciao
Davide

Bug#977213: davix: Wrong homepage

[Davide Prina]

Source: davix
Version: 0.7.6-2
Severity: normal

I have see that the project homepage do not respond anymore:
http://dmc.web.cern.ch/projects/davix/home

I think that the homepage is now:
http://lcginfo.cern.ch/pkg/Davix/

Ciao
Davide

Bug#977214: debian-installer: Please allow underscore in username of first account

[John Lines]

Package: debian-installer
Severity: wishlist
X-Debbugs-Cc: j...@paladyn.org

Dear Maintainer,

If a system has a number of users then more that one will have the same first
name. After the initial install it is possible to add users with names such
as john_lines, but this is not permitted for the first user, make them an
anomoly.

Please use the NAME_REGEX="^[a-z][-a-z0-9_]*\$" pattern as per adduser

Thank you

John


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/1 CPU thread)
Kernel taint flags: TAINT_SOFTLOCKUP
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

Bug#977215: dawgdic: Wrong homepage

[Davide Prina]

Source: dawgdic
Version: 0.4.5-3
Severity: normal

I have see that the project homepage point to the google archived 
repository:

https://code.google.com/archive/p/dawgdic

I think that the homepage is now:
https://github.com/stil/dawgdic

Ciao
Davide

Bug#977216: ITP: pacrunner -- Proxy configuration daemon

[Laurent Bigonville]

Package: wnpp
Severity: wishlist
Owner: !

* Package name: pacrunner
  Version : 0.18
  Upstream Author : Marcel Holtmann 
* URL : https://git.kernel.org/pub/scm/network/connman/pacrunner.git
* License : GPL, LGPL
  Programming Lang: C
  Description : Proxy configuration daemon

PacRunner is a simple standalone daemon which communicates via D-Bus. It
is designed to receive its proxy configuration from a trusted source
such as ConnMan or NetworkManager, then simply exposes a method on D-Bus
for applications to ask the what proxy? question.

Bug#977218: db2twitter: Wrong homepage + new version

[Davide Prina]

Package: db2twitter
Version: 0.6-1
Severity: normal

I have see that the project homepage do not respond anymore:
https://github.com/chaica/db2twitter

I think that the homepage is:
https://gitlab.com/chaica/db2twitter
https://pypi.org/project/db2twitter/

I think that there is a new version 0.10

Ciao
Davide

Bug#977217: New upstream release available, fixes stuck test on UEFI systems

[Benjamin Valentin]

Package: memtest86+
Version: 5.01-3.1

The version of memtest86+ shipped by Debian gets stuck on many UEFI
systems (see other bug reports, google search).

The latest upstream release (5.31b) fixes that.

I was suspecting bad RAM when memtest86+ would get stuck shortly after
start, however normally the system runs just fine.

A brief internet search led to results suggesting that this is a bug in
memtest86+ 5.01 that has been fixed upstream.

I tried the latest .iso image provided by http://www.memtest.org and
there the test ran with no errors or freezes.

It would be great if you could update the package so that it no longer
reports false positives on lots of systems!

Best,
Benjamin

Bug#976907: golang-github-boltdb-bolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short github.com/boltdb/bolt github.co

[Andreas Henriksson]

Hello all,

1 down, 1 to go info below.

On Wed, Dec 09, 2020 at 10:03:31AM +0100, Lucas Nussbaum wrote:
> Source: golang-github-boltdb-bolt
> Version: 1.3.1-7
> Severity: serious
> Justification: FTBFS on ppc64el
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on ppc64el. At the same time, it did not fail on amd64.
[...]
> > === RUN   TestBucket_Stats
> > bucket_test.go:1172: unexpected BranchPageN: 0
> > --- FAIL: TestBucket_Stats (6.41s)

^--- I've not looked into this one yet.

[...]
> > === RUN   TestTx_Commit_ErrTxNotWritable
> > panic: test timed out after 10m0s
[...]

^-- this one is solved by adding `tx.Rollback()` last in
TestTx_Commit_ErrTxNotWritable function (in tx_test.go:65).
In other words, this is a test-suite bug (not a bug in the actual
product code).

The reasoning goes that tx.Commit() is expected to
return error bolt.ErrTxNotWritable, which it does -- but this
means it's holding a reader lock on db.mmaplock.
After the test function finishes the deferred function
db.MustClose() runs and calls into things that tries
to take a read-write lock of db.mmaplock which times out.
The added tx.Rollback() on a read-only tx basically only
removes the transaction and releases the db.mmaplock.

I have no idea why this would not also trigger on any other arch.

Regards,
Andreas Henriksson

Bug#977219: anytun: FTBFS with boost 1.74

[Sebastian Ramacher]

Source: anytun
Version: 0.3.7-1.2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

anytun FTBFS with boost 1.74:

| g++ -g -Wall -Werror -Wno-error=unused-variable -O2 -DLOG_SYSLOG -DLOG_FILE 
-DLOG_STDOUT -DUSE_GCRYPT syncServer.cpp -c -o syncServer.o
| In file included from /usr/include/boost/bind.hpp:30,
|  from syncServer.h:49,
|  from syncServer.cpp:46:
| /usr/include/boost/bind.hpp:36:1: note: ‘#pragma message: The practice of 
declaring the Bind placeholders (_1, _2, ...) in the global namespace is 
deprecated. Please use  + using namespace 
boost::placeholders, or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the 
current behavior.’
|36 | BOOST_PRAGMA_MESSAGE(
|   | ^~~~
| In file included from /usr/include/boost/asio/executor.hpp:342,
|  from /usr/include/boost/asio.hpp:86,
|  from syncServer.h:56,
|  from syncServer.cpp:46:
| /usr/include/boost/asio/impl/executor.hpp: In instantiation of ‘void 
boost::asio::executor::impl< ,  
>::on_work_started() [with Executor = 
boost::asio::execution::any_executor,
 boost::asio::execution::detail::blocking::never_t<0>, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 > >; Allocator = std::allocator]’:
| /usr/include/boost/asio/impl/executor.hpp:77:8:   required from here
| /usr/include/boost/asio/impl/executor.hpp:79:15: error: ‘class 
boost::asio::execution::any_executor,
 boost::asio::execution::detail::blocking::never_t<0>, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 > >’ has no member named ‘on_work_started’
|79 | executor_.on_work_started();
|   | ~~^~~
| /usr/include/boost/asio/impl/executor.hpp: In instantiation of ‘void 
boost::asio::executor::impl< ,  
>::on_work_finished() [with Executor = 
boost::asio::execution::any_executor,
 boost::asio::execution::detail::blocking::never_t<0>, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 > >; Allocator = std::allocator]’:
| /usr/include/boost/asio/impl/executor.hpp:82:8:   required from here
| /usr/include/boost/asio/impl/executor.hpp:84:15: error: ‘class 
boost::asio::execution::any_executor,
 boost::asio::execution::detail::blocking::never_t<0>, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 > >’ has no member named ‘on_work_finished’
|84 | executor_.on_work_finished();
|   | ~~^~~~
| /usr/include/boost/asio/impl/executor.hpp: In instantiation of ‘void 
boost::asio::executor::impl< ,  
>::dispatch(boost::asio::executor::function&&) [with Executor = 
boost::asio::execution::any_executor,
 boost::asio::execution::detail::blocking::never_t<0>, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 > >; Allocator = std::allocator; boost::asio::executor::function = 
boost::asio::detail::executor_function]’:
| /usr/include/boost/asio/impl/executor.hpp:92:8:   required from here
| /usr/include/boost/asio/impl/executor.hpp:94:15: error: ‘class 
boost::asio::execution::any_executor,
 boost::asio::execution::detail::blocking::never_t<0>, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 > >’ has no member named ‘dispatch’
|94 | executor_.dispatch(BOOST_ASIO_MOVE_CAST(function)(f), allocator_);
|   | ~~^~~~
| /usr/include/boost/asio/impl/executor.hpp: In instantiation of ‘void 
boost::asio::executor::impl< ,  
>::post(boost::asio::executor::function&&) [with Executor = 
boost::asio::execution::any_executor,
 boost::asio::execution::detail::blocking::never_t<0>, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 >, 
boost::asio::execution::prefer_only
 > >; Allocator = std::allocator; boost::asio::executor::function = 
boost::asio::detail::executor_function]’:
| /usr/include/boost/asio/impl/executor.hpp:97:8:   required from here
| /usr/include/boost/asio/impl/executor.hpp:99:15: error: ‘class 
boost::asio::execu

Bug#743789:

[Elvis Edorh]

Pozdrav,
molim vas prihvatite moje isprike. Ne želim zadirati u vašu privatnost,
napisao sam vam raniji e-mail, ali bez odgovora. U prvom sam vam e-mailu
spomenuo svog pokojnog klijenta koji je umro 30. prosinca 2013, od njegove
smrti primio sam nekoliko pisama iz banke kod koje je dao depozit prije
njegove smrti, banka je tražila da mu pružim najbližeg rođaka ili nekoga od
njegove rodbine koji mogu zatražiti njegova sredstva ili će ih banka
zaplijeniti, jer nisam uspio pronaći nijednog od njegov rođak, stoga sam
vas kontaktirao zbog ove tvrdnje, jer imate isto prezime s njim. Nakon
vašeg odgovora dat ću vam detalje i postupke transakcije
Čekam vaš odgovor

Elvis Edorh

Bug#976907: golang-github-boltdb-bolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short github.com/boltdb/bolt github.co

[Andreas Henriksson]

Hello again,

On Sat, Dec 12, 2020 at 05:59:37PM +0100, Andreas Henriksson wrote:
> Hello all,
> 
> 1 down, 1 to go info below.
> 
> On Wed, Dec 09, 2020 at 10:03:31AM +0100, Lucas Nussbaum wrote:
> [...]
> > > === RUN   TestBucket_Stats
> > > bucket_test.go:1172: unexpected BranchPageN: 0
> > > --- FAIL: TestBucket_Stats (6.41s)
[...]

Now also quickly looked into this one. It seems the test-suite
makes assumptions related to calculations that involve
os.Getpagesize() (which gives 4096 on amd64 and 65536 on ppc64el,
which is 16 times larger).
Changing the 500 number to 8000 (16 times larger) in
TestBucket_Stats(...) (in bucket_test.go:1143) gives the expected
BranchPageN == 1 (however after that it then says 
"unexpected LeafPageN: 6" with this modification).

Anyway, this makes me loose interest in pursuing this further.
In my opinion it's pretty clear that these are test-suite only
issues and not issues in the actual product.

Unless someone else wants to pursue fixing up the test-suite for ppc64le
needs, my offer to "fix" this will be to simply disable it on !amd64
architectures (unless we agree on simply downgrading this issue to non-RC).

Regards,
Andreas Henriksson

Bug#976907: golang-github-boltdb-bolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short github.com/boltdb/bolt github.co

[Andreas Henriksson]

Hello again,

So after wasting my time here I finally realized that apparently
boltdb is archived upstream. It will not receive any fixes.

Apparently golang-github-coreos-bbolt is a maintained feature-extended
fork. We should likely encurage moving to that and get boltdb removed
from debian.

The timeout waiting for db.mmaplock that occurred in boltdb is
apparently already fixed in bbolt, see:
https://github.com/etcd-io/bbolt/commit/e06ec0a754bc30c2e17ad871962e71635bf94d45

The pagesize issue seems to plague them both still though.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976926
for the bug report against bbolt.

Regards,
Andreas Henriksson

Bug#977158: gnome-sofware: gnome software updates the kernel without my consent. My wifi driver needs to be recompiled.

[Andrei POPESCU]

On Sb, 12 dec 20, 11:27:01, Alexandre Abbes wrote:
> Thank you for correcting the typo.
> 
> Should I write a new bug report with the good typo, or is it OK with your
> fix?

It's ok, nothing else to do, except maybe prompt replies to requests for 
information from the Maintainer (if applicable) :)

However,,, (see below)

> > > * What led up to the situation?
> > > my wifi driver does not work after each update.  gnome softawre updates
> > > the kernel without asking. It is not polite? It is a security issue.

The kernel should be updated regularly, primarily for security.

> > > * What exactly did you do (or not do) that was effective (or
> > >   ineffective)?
> > > * What was the outcome of this action?
> > > I did not find why my wifi driver did not work suddenly.
> > > * What outcome did you expect instead?
> > > Gnome-software should not be working by default, and should not have 
> > > access to essential softwares.
> > > *** End of the template - remove these template lines ***

In Debian stable the kernel upgrades automatically in two cases:

1. Security update *without* ABI change

   The Linux image package (e.g. something like 
   linux-image-4.19.0-13-amd64) has a new version. Such a change should 
   have no impact on external drivers unless they are buggy.

   In this case the package version can be 'pinned', assuming this is 
   respected by Gnome Software.

2. Security update *with* ABI change

   In case the update is more intrusive the ABI changes. In this case 
   the package linux-image-4.19.0-13-amd64 will be superseded by the 
   package linux-image-4.19.0-14-amd64.
   
   Because this a new package it will be installed only if you also have 
   linux-image-amd64 installed, whose only purpose is to "pull" the 
   latest Linux image package for your release.

   If this is what you are seeing then it is usually enough to just 
   remove linux-image-amd64, while keeping the Linux image package 
   installed.

Please note the above applies to Debian stable using APT. As far as I 
know gnome-software is just a frontend to APT, though I don't know if it 
is 100% compatible.

You might want to contact one of Debian's support channels for advice 
and update your report accordingly.

https://www.debian.org/support

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#977174: Other options

[Jelmer Vernooij]

Another option might be to have vcswatch provide a feed of recently
changed repositories that the janitor (and other jobs) can regularly
scrape.

The advantage of this is that there is no need to provide a mechanism
for new webhooks to be registered. Downside is that polling needs to
happen, and notifications would be less real-time.

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc

Bug#977220: bsdmainutils: Issues in man pages

[Helge Kreutzmann]

Package: bsdmainutils
Severity: minor

Dear bsdmainutils maintainer,
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including bsdmainutils) as
well for a large variety of target languages.

During their work translators notice different possible issues in the
original (english) man pages. Sometimes this is a straightforward
typo, sometimes a hard to read sentence, sometimes this is a
convention not held up and sometimes we simply do not understand the
original.

We use several distributions as sources and update regularly (at
least every 2 month). This means we are fairly recent (some
distributions like archlinux also update frequently) but might miss
the latest upstream version once in a while, so the error might be
already fixed. We apologize and ask you to close the issue immediately
if this should be the case, but given the huge volume of projects and
the very limited number of volunteers we are not able to double check
each and every issue.

Secondly we translators see the manpages in the neutral po format,
i.e. converted and harmonized, but not the original source (be it man,
groff, xml or other). So we cannot provide a true patch (where
possible), but only an approximation which you need to convert into
your source format.

Finally the issues I'm reporting have accumulated over time and are
not always discovered by me, so sometimes my description of the
problem my be a bit limited - do not hesitate to ask so we can clarify
them.

I'm now reporting the errors for your project. If future reports
should use another channel, please let me know.

Man page: ncal.1
Issue: Formatting is broken (6 lines in rendered manpage)

"E<.Nm> E<.Op Fl 31jy> E<.Op Fl A Ar number> E<.Op Fl B Ar number> E<.Op Fl d "
"Ar -mm> E<.Oo> E<.Op Ar month> E<.Ar year> E<.Oc> E<.Nm> E<.Op Fl 31j> "
"E<.Op Fl A Ar number> E<.Op Fl B Ar number> E<.Op Fl d Ar -mm> E<.Fl m "
"Ar month> E<.Op Ar year> E<.Nm ncal> E<.Op Fl C> E<.Op Fl 31jy> E<.Op Fl A "
"Ar number> E<.Op Fl B Ar number> E<.Op Fl d Ar -mm> E<.Oo> E<.Op Ar "
"month> E<.Ar year> E<.Oc> E<.Nm ncal> E<.Op Fl C> E<.Op Fl 31j> E<.Op Fl A "
"Ar number> E<.Op Fl B Ar number> E<.Op Fl d Ar -mm> E<.Fl m Ar month> E<."
"Op Ar year> E<.Nm ncal> E<.Op Fl 31bhjJpwySM> E<.Op Fl A Ar number> E<.Op Fl "
"B Ar number> E<.Op Fl H Ar -mm-dd> E<.Op Fl d Ar -mm> E<.Op Fl s Ar "
"country_code> E<.Oo> E<.Op Ar month> E<.Ar year> E<.Oc> E<.Nm ncal> E<.Op Fl "
"31bhJeoSM> E<.Op Fl A Ar number> E<.Op Fl B Ar number> E<.Op Fl d Ar -"
"mm> E<.Op Ar year>"

--
Man page: ncal.1
Issue: Final full stop missing

"A E<.Nm> command appeared in E<.At v5>.  The E<.Nm ncal> command appeared in "
"E<.Fx 2.2.6>.  The output of the E<.Nm cal> command is supposed to be bit "
"for bit compatible to the original Unix E<.Nm cal> command, because its "
"output is processed by other programs like CGI scripts, that should not be "
"broken. Therefore it will always output 8 lines, even if only 7 contain "
"data. This extra blank line also appears with the original E<.Nm cal> "
"command, at least on Solaris 8"

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#976926: golang-github-coreos-bbolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short go.etcd.io/bbolt returned exit

[Andreas Henriksson]

Hello!

On Wed, Dec 09, 2020 at 10:03:39AM +0100, Lucas Nussbaum wrote:
> Source: golang-github-coreos-bbolt
> Version: 1.3.5-1
> Severity: serious
> Justification: FTBFS on ppc64el
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on ppc64el. At the same time, it did not fail on amd64.
[...]
> > === RUN   TestBucket_Stats
> > bucket_test.go:1222: unexpected BranchPageN: 0
> > --- FAIL: TestBucket_Stats (9.56s)
[...]

Apparently bbolt is a fork of boltdb, so please see my comments
on the equivalent bug report againt boltdb:
https://bugs.debian.org/976907


Relevant part:
 It seems the test-suite makes assumptions related to calculations that
 involve os.Getpagesize() (which gives 4096 on amd64 and 65536 on
 ppc64el, which is 16 times larger).
 Changing the 500 number to 8000 (16 times larger) in
 TestBucket_Stats(...) (in bucket_test.go:1143) gives the expected
 BranchPageN == 1  (however after that it then says 
 "unexpected LeafPageN: 6" with this modification).

 In my opinion it's pretty clear that these are test-suite only
 issues and not issues in the actual product.


I would thus personally just disable the test-suite on !amd64 if no
porter is interested in fixing the testsuite (unless we agree this
issue simply can be downgraded to non-RC).

Regards,
Andreas Henriksson

Bug#880556: parse upstream metadata files like package.json or .gemspec files

[Andrej Shadura]

Hi,

On Fri, 13 Dec 2019 16:11:23 +0100 Andrej Shadura
 wrote:
> Please find attached proof of concept scanner for Rust Cargo.toml files.
> I’m not fluent in Perl, and I wasn’t sure where exactly to put this
> piece of code, but this is something you probably can polish up a bit.

Almost exactly a year later I decided it’s be great to write a
Cargo.toml parser for scan-copyrights, I fought with Perl for an hour or
so and then checked the BTS… Damn it, I already *have* written one a
year ago :D

Have you had a chance to have a look at it? :)

-- 
Cheers,
  Andrej