Bug#949315: cups-filters: driverless generates wrong InputSlots

[Brian Potkin]

tags 949315 upstream
forwarded 949315 https://github.com/OpenPrinting/cups-filters/issues/201
thanks



On Sun 19 Jan 2020 at 20:10:17 +0100, Martin Mares wrote:

> Package: cups-filters
> Version: 1.21.6-5
> Severity: important
> 
> When I use "driverless" to generate a PPD for my Xerox B215 printer,
> I get definition of InputSlot which does not work.
> 
> In particular, the printer reports that it supports media source "tray-1".
> This is translated to "Tray-1" by driverless, so the PPD contains:
> 
>   *InputSlot Tray-1/Tray 1: ""
> 
> When I submit a print job, CUPS's IPP backend translates this to IPP
> media source "tray--1", which is later rejected by the printer (the printer
> replies by a malformed IPP message, but that's another story).
> 
> The problem lies in the mismatch between name mangling rules in
> cups-filters-1.21.6/cupsfilters/ppdgenerator.c (the pwg_ppdize_name function)
> and
> cups-2.2.10/cups/ppd-cache.c (the pwg_unppdize_name function). It is hard
> to tell which one is wrong as the name mangling rules seem arbitrary. However,
> at least one of them needs fixing.
> 
> I checked cups-filters 1.26.2 and CUPS 2.3.1 and the name mangling functions
> stay the same, so the problem is probably still present.

Thank you for your report, Martin. I have forwarded it upstream, so
please monitor its progress there. I will be unable to add anything
useful to any conversation.

Regards,

Brian.

Bug#950792: /usr/lib/libreoffice/program/soffice: Opening OpenOffice make Xorg crash

[Nicola]

Package: libreoffice-core
Version: 1:6.3.4-2
Severity: important
File: /usr/lib/libreoffice/program/soffice

Dear Maintainer,

launching libreoffice make Xorg crash.
Xorg log, /var/log/Xorg.0.log :
[  7245.804] (EE)
[  7245.804] (EE) Backtrace:
[  7245.805] (EE) 0: /usr/lib/xorg/Xorg (?+0x0) [0x55df838a3d60]
[  7245.806] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (?+0x0)
[0x7f8cbca0550f]
[  7245.806] (EE) 2: /usr/lib/xorg/Xorg (?+0x0) [0x55df8375ada0]
[  7245.806] (EE) 3: /usr/lib/xorg/Xorg (?+0x0) [0x55df83741fa0]
[  7245.806] (EE) 4: /usr/lib/xorg/Xorg (?+0x0) [0x55df83746630]
[  7245.806] (EE) 5: /usr/lib/xorg/Xorg (?+0x0) [0x55df8374a580]
[  7245.806] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f8cbc856ad0]
[  7245.806] (EE) 7: /usr/lib/xorg/Xorg (?+0x0) [0x55df83734720]
[  7245.806] (EE)
[  7245.806] (EE) Segmentation fault at address 0x0
[  7245.806] (EE)
Fatal server error:
[  7245.806] (EE) Caught signal 11 (Segmentation fault). Server aborting
[  7245.806] (EE)
[  7245.806] (EE)
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
[  7245.806] (EE) Please also check the log file at "/var/log/Xorg.0.log" for
additional information.
[  7245.806] (EE)
[  7245.807] (II) AIGLX: Suspending AIGLX clients for VT switch
[  7245.878] (EE) Server terminated with error (1). Closing log file.

>From /var/log/kern.log :

Feb  6 15:56:04 Lenovo kernel: [ 7246.351689] nouveau :01:00.0: bus: MMIO
read of  FAULT at 619444 [ IBUS ]



-- Package-specific info:
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----=
un  libreoffice-gtk2   (no description available)
un  libreoffice-gtk3   (no description available)
un  libreoffice-kde5   (no description available)

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (950, 'testing'), (400, 'unstable'), (300, 'experimental'), (10,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice-core depends on:
it  fontconfig  2.13.1-2+b1
iu  fonts-opensymbol2:102.11+LibO6.4.0-1
ii  libboost-locale1.67.0   1.67.0-17
ii  libc6   2.29-9
ii  libcairo2   1.16.0-4
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
ii  libcmis-0.5-5v5 0.5.2-1
iu  libcups22.3.1-4
ii  libcurl3-gnutls 7.67.0-2
ii  libdbus-1-3 1.12.16-2
ii  libdconf1   0.34.0-2
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.4-1
ii  libexpat1   2.2.9-1
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-2+b1
ii  libfreetype62.10.1-2
iu  libgcc-s1 [libgcc1] 10-20200204-1
ii  libgcc1 1:9.2.1-25
iu  libglib2.0-02.62.4-1+b1
iu  libgpgmepp6 1.13.1-6
ii  libgraphite2-3  1.3.13-11
iu  libgstreamer-plugins-base1.0-0  1.16.2-dmo3
ii  libgstreamer1.0-0   1.16.2-2
ii  libharfbuzz-icu02.6.4-1
ii  libharfbuzz0b   2.6.4-1
ii  libhunspell-1.7-0   1.7.0-2+b1
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.9-2
ii  libicu6363.2-2
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  liblcms2-2  2.9-3+b1
ii  libldap-2.4-2   2.4.48+dfsg-1+b2
ii  libmythes-1.2-0 2:1.2.4-3+b1
ii  libneon27-gnutls0.30.2-3
ii  libnspr42:4.24-1
iu  libnss3 2:3.49.1-1
ii  libnumbertext-1.0-0 1.0.5-3
ii  liborcus-0.15-0 0.15.3-3
ii  libpng16-16 1.6.37-1
ii  libpoppler820.71.0-6
ii  librdf0 1.0.17-1.1+b1
it  libreoffice-common  1:6.3.4-2
ii  librevenge-0.0-00.0.4-6+b1
ii  libsm6  2:1.2.3-1
ii  libstdc++6  9.2.1-25
ii  libx11-62:1.6.8-1
ii  libxext62:1.3.3-1+b2
ii  libxinerama1 

Bug#542951: kipi-plugins: Separate plugins with extra dependencies

[Agustin Martin]

On Sat, Aug 22, 2009 at 02:39:43PM +0200, Eduardo Ramírez wrote:
> Package: kipi-plugins
> Version: 0.5.0-1
> Severity: wishlist
> 
> Currently installing kipi-plugins also installs libavahi-client3, 
> libavahi-common-data, libavahi-common3, libsane and libksane0; even though I 
> don't have a scaner o user avahi. 
> 
> Me suggestion is separate the plugins that depend on sane into a 
> kipi-plugins-sane package.

digikam 6.4.0 is already uploaded to Debian sid, and kipi stuff is no
longer shipped with it, so I guess we can safely close this bug report.
Do you agree?

Thanks for the feedback.

Regards,

-- 
Agustin

Bug#884949: digikam crashes on red eye removal

[Agustin Martin]

On Thu, Dec 21, 2017 at 09:50:18PM +0100, Torsten Crass wrote:
> Package: digikam
> Version: 4:5.3.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> the digikam version currenlty included in Stretch (4:5.3.0-1) consistently
> crashes when trying to apply red eye reduction to an image. This behaviour
> is known upstream and is fixed in version 5.4 according to
> https://mail.kde.org/pipermail/digikam-devel/2016-November/090029.html
> 
> Would it be possible to upgrade Stretch's digikam to 5.4.* -- or even
> backport 4:5.6.0* from testing/unstable?

Hi, Torsten,

I am triaging some digikam old bug reports. Since current versions in Debian
are 5.9.0 (stable) and 6.4.0 (sid) this problem should be fixed, or at least
I did not find it in a quick test with 5.9.0. Is this still a problem for
you or can this bug report be closed?

Thanks for the feedback,

Regards,

-- 
Agustin

Bug#950790: libqt5qml5: Do a double build with SSE2 enabled on i386

[Dmitry Shachnev]

On Thu, Feb 06, 2020 at 11:08:41AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Lars pointed out [1] that QtQml (and so I guess this lib, will need to double
> check) would really benefit from a i386 build with SSE2 enabled.
>
> [1] 
> 

Already discussed on IRC, but for the record:

Actually Qt QML has a runtime requirement for SSE2, so I am not sure the
non-SSE2 build makes sense:

https://sources.debian.org/src/qtdeclarative-opensource-src/5.12.5-5/src/qml/qml/v8/qv8engine.cpp/#L143

I think we should just switch the default build to SSE2 by passing
CONFIG+=sse2 to qmake when DEB_HOST_ARCH_CPU = i386.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#950791: neomutt: missing debian/copyright entries for autosetup/*

[Jonathan Dowland]

Source: neomutt
Version: 20180716+dfsg.1-1
Severity: serious
Justification: Policy 12.5

The file autosetup/autosetup leads with the following comment:

# Copyright (c) 2006-2011 WorkWare Systems http://www.workware.net.au/
# All rights reserved

This is a bit concerning, but the concern is alleviated by the contents of
autosetup/LICENSE, which looks DFSG-acceptable (but I haven't looked very
closely to be sure)

However, debian/copyright does not have a stanza for autosetup/* leaving '*'
as the applicable stanza, stating GPL-2+ which is not correct.

-- Package-specific info:
NeoMutt 20180716
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 4.19.0-6-amd64 (x86_64)
ncurses: ncurses 6.1.20181013 (compiled with 6.1.20180714)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-25' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Debian 7.3.0-25) 


Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/lib 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/neomutt-oDMtzm/neomutt-20180716+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.3  -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
 +attach_headers_color +compose_to_sender +compress +cond_date +debug 
 +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
 +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
 +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
 +skip_quoted +smtp +status_color +timeout +tls_sni +trash 


Compile options:
 +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens +getaddrinfo 
 +gnutls +gpgme +gss +hcache -homespool +idn -locales_hack +lua +meta 
 +mixmaster +nls +notmuch -openssl +pgp +sasl +smime +start_color 
 +sun_attachment +typeahead 
MAILPATH="/var/mail"

MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
   https://github.com/neomutt/neomutt/issues
or send an email to: 


-- System Information:
Debian Release: 10.2
 APT prefers stable
 APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages neomutt is related to:
ii  neomutt  20180716+dfsg.1-1

-- no debconf information

--
  Jonathan Dowland
   https://jmtd.net

Bug#950272: buster-pu: package mariadb-10.3 10.3.22-0+deb10u1

[Paul Gevers]

Hi Otto,

On 06-02-2020 14:10, Otto Kekäläinen wrote:
>> tail: cannot open '/home/debci/.kodi/temp/kodi.log' for reading: No such 
>> file or directory
>> tail: no files remaining
> 
> This is the only output in the test log, otherwise it is installing
> packages and everything else seemed to go fine.
> 
> Test source says it just starts the app, but now it does not seem to
> output anything:
> https://salsa.debian.org/multimedia-team/kodi/blob/master/debian/tests/gui

Yes, and I am worried about that. If the MariaDB upgrade causes kodi to
not run, that's a bad regression, don't you think?

kodi has a pretty good history in Ubuntu on ppc64el, so I don't expect
it to be flaky at first sight.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#950790: libqt5qml5: Do a double build with SSE2 enabled on i386

[Lisandro Damián Nicanor Pérez Meyer]

Package: libqt5qml5
Version: 5.12.5-5
Severity: normal

Lars pointed out [1] that QtQml (and so I guess this lib, will need to double
check) would really benefit from a i386 build with SSE2 enabled.

[1]


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'buildd-unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, armhf

Kernel: Linux 5.4.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libqt5qml5 depends on:
ii  libc6 2.29-10
ii  libgcc-s1 [libgcc1]   10-20200104-1
ii  libgcc1   1:9.2.1-25
ii  libqt5core5a [qtbase-abi-5-12-5]  5.12.5+dfsg-8
ii  libqt5network55.12.5+dfsg-8
ii  libstdc++69.2.1-25

Versions of packages libqt5qml5 recommends:
ii  libgl11.3.0-7
ii  libglx-mesa0  19.3.3-1

Versions of packages libqt5qml5 suggests:
ii  qt5-qmltooling-plugins  5.12.5-5

-- no debconf information

Bug#950789: lightning: Lost all nextcloud caldav token

[Bardot Jerome]

Package: lightning
Version: 1:68.4.2-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I update from 60 to 68


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

I just do a regular apt update && apt upgrade and after that close and restart
thunderbird

   * What was the outcome of this action?

At start it ask me for all my one usage auth token for all my calendar near
than 10-15.

   * What outcome did you expect instead?

Just keep information like it does between two standard restart


Thx for all your good jobs.



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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lightning depends on:
ii  thunderbird  1:68.4.2-1

lightning recommends no packages.

Versions of packages lightning suggests:
ii  fonts-lyx  2.3.3-3

-- debconf-show failed

Bug#842610: digikam lost track of photos when renaming an album

[Vincent Danjean]

  Hi,

Le 06/02/2020 à 13:35, Agustin Martin a écrit :
> Triaging old bug reports. Is this still a problem with current digikam
> (6.4.0 in sid)? I tried some simple renamings with 6.4.0 and seems to work.

  I think that this particular bug can be closed. However, from times to
times, the digikam database become corrupted. But I do not know what
triggers this (renames or other things). I see the corruption when I
remark some images on disk but not displayed in Digikam.
  I keep on my disk these notes to help me to fix the database:

use digikamdb;

Cleanup Comments :
SELECT * FROM ImageComments i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
DELETE i FROM ImageComments i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
Cleanup Copyright :
SELECT * FROM ImageCopyright i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
DELETE i FROM ImageCopyright i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
Cleanup Information :
SELECT * FROM ImageInformation i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
DELETE i FROM ImageInformation i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
Cleanup Metadata :
SELECT * FROM ImageMetadata i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
DELETE i FROM ImageMetadata i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
Cleanup Tags :
SELECT * FROM ImageTags i LEFT OUTER JOIN Images ON Images.id=i.imageid WHERE 
Images.name IS NULL;
DELETE i FROM ImageTags i LEFT OUTER JOIN Images ON Images.id=i.imageid WHERE 
Images.name IS NULL;


Images without information :
select CONCAT(relativePath, '/', name) from Images LEFT OUTER JOIN 
ImageInformation on Images.id=ImageInformation.imageid LEFT OUTER JOIN Albums 
on Images.album=Albums.id where ImageInformation.imageid is NULL INTO OUTFILE 
'/var/lib/mysql-files/digikam.log' ;

RESTART:
sudo cat /var/lib/mysql-files/digikam.log | while read file ; do 
f="$HOME/photos/albums/$file"; if [ -f "$f"  ] ; then touch "$f" ; else echo 
"Missing $f" ; fi ; done
sudo cat /var/lib/mysql-files/digikam.log  | sed -e 's,/[^/]*$,,' | sort -u
 In digikam, reload metadata from files in these albums

Check that all info is loaded with
select CONCAT(relativePath, '/', name) from Images LEFT OUTER JOIN 
ImageInformation on Images.id=ImageInformation.imageid LEFT OUTER JOIN Albums 
on Images.album=Albums.id where ImageInformation.creationDate is NULL AND 
status != 3 ;

GOTO RESTART


And, to force film thumbnails regeneration in an album:
delete from UniqueHashes where thumbId in (select thumbId from FilePaths where 
path like "%17_Irlande/%.avi" );
describe Thumbnails ;
delete from Thumbnails where id in (select thumbId as id from FilePaths where 
path like "%17_Irlande/%.avi" );
delete from FilePaths where path like "%17_Irlande/%.avi" ;



That said, I just checked now. No rows have been reported at all
(and I do not run these commands since a long time), so the bugs
can have been fixed.

  Regards,
Vincent


> Regards,
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#950775: RFP: boringtun -- userspace WireGuard implementation in Rust

[Marco d'Itri]

On Feb 06, Dmitry Smirnov  wrote:

> URL: https://github.com/cloudflare/boringtun
> Description: userspace WireGuard implementation in Rust
What is the purpose of having this packaged in Debian? It is at most 
a proof of concept, with hardly any improvements since it has been 
released.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#950669: cups-browsed: segfault at 0 ip 00000000f79ffb5b sp 00000000fffd3828 error 4 in libc-2.29.so

[Bernhard Übelacker]

Hello Thorsten,
getting the source of such an address is possible, even with ASLR,
if the library versions are known and dbgsyms are available,
like in attached file.

It looks like a null pointer is given to strncasecmp_l.

But you are right, this information might still not be very useful,
because the location is in libc - if it would be in cups-browsed it
would be more useful.

Kind regards,
Bernhard


# From submitter:
cups-browsed[20400]: segfault at 0 ip f79ffb5b sp fffd3828 
error 4 in libc-2.29.so[f78d2000+145000]
Code: 66 0f 6f 25 37 7c 03 00 66 0f 6f 2d 3f 7c 03 00 66 0f 6f 35 47 7c 03 00 
83 f9 30 0f 87 8e 00 00 00 83 f8 30 0f 87 85 00 00 00  0f 6f 0f f3 0f 6f 16 
66 0f 6f f9 66 44 0f 6f c5 66 44 0f 6f ca



/*
 * Page fault error code bits:
 *
 *   bit 0 ==0: no page found   1: protection fault
 *   bit 1 ==0: read access 1: write access
 *   bit 2 ==0: kernel-mode access  1: user-mode access
 *   bit 3 ==   1: use of reserved bit detected
 *   bit 4 ==   1: fault was an instruction fetch
 *   bit 5 ==   1: protection keys block access
 */
enum x86_pf_error_code {

PF_PROT =   1 << 0,
PF_WRITE=   1 << 1,
PF_USER =   1 << 2,
PF_RSVD =   1 << 3,
PF_INSTR=   1 << 4,
PF_PK   =   1 << 5,
};

arch/x86/mm/fault.c:
printk("%s%s[%d]: segfault at %lx ip %px sp %px error %lx",


"error 4" == 0x4 == 0b100

bit 0 == 0: no page found
bit 1 == 0: read access
bit 2 == 1: user-mode access
bit 3 == 0: 
bit 4 == 0: 
bit 5 == 0: 



##


# Unstable amd64 qemu VM with x32 userland 2020-02-06

apt update
apt dist-upgrade

apt install systemd-coredump gdb cups-browsed cups-browsed-dbgsym



dpkg -l | grep -i libc6
dpkg -l | grep 2.29-10

wget 
https://snapshot.debian.org/archive/debian-ports/20200111T150052Z/pool-x32/main/g/glibc/libc6_2.29-9_x32.deb
wget 
https://snapshot.debian.org/archive/debian-ports/20200111T150052Z/pool-x32/main/g/glibc/libc6-dbg_2.29-9_x32.deb
wget 
https://snapshot.debian.org/archive/debian-ports/20200111T150052Z/pool-x32/main/g/glibc/libc-bin_2.29-9_x32.deb
wget 
https://snapshot.debian.org/archive/debian/20200111T032041Z/pool/main/g/glibc/libc-l10n_2.29-9_all.deb
wget 
https://snapshot.debian.org/archive/debian/20200111T032041Z/pool/main/g/glibc/locales_2.29-9_all.deb
dpkg -i "*_2.29-9_*"



gdb -q
file /sbin/cups-browsed
b main
run
generate-core /tmp/core
kill
y
q


gdb -q | grep "libc\."
file /sbin/cups-browsed
core /tmp/core
set width 0
set pagination off
info share
q

#   0xf7920320  0xf7a634db  Yes /lib/x86_64-linux-gnux32/libc.so.6





echo -n "find /b ..., ..., 0x" && \
{
echo "66 0f 6f 25 37 7c 03 00 66 0f 6f 2d 3f 7c 03 00 66 0f 6f 35 47 7c 03 
00 83 f9 30 0f 87 8e 00 00 00 83 f8 30 0f 87 85 00 00 00  0f 6f 0f f3 0f 6f 
16 66 0f 6f f9 66 44 0f 6f c5 66 44 0f 6f ca"
} | sed 's/[<>]//g' | sed 's/ /, 0x/g'

#   find /b ..., ..., 0x66, 0x0f, 0x6f, 0x25, 0x37, 0x7c, 0x03, 0x00, 0x66, 
0x0f, 0x6f, 0x2d, 0x3f, 0x7c, 0x03, 0x00, 0x66, 0x0f, 0x6f, 0x35, 0x47, 0x7c, 
0x03, 0x00, 0x83, 0xf9, 0x30, 0x0f, 0x87, 0x8e, 0x00, 0x00, 0x00, 0x83, 0xf8, 
0x30, 0x0f, 0x87, 0x85, 0x00, 0x00, 0x00, 0xf3, 0x0f, 0x6f, 0x0f, 0xf3, 0x0f, 
0x6f, 0x16, 0x66, 0x0f, 0x6f, 0xf9, 0x66, 0x44, 0x0f, 0x6f, 0xc5, 0x66, 0x44, 
0x0f, 0x6f, 0xca




gdb -q
file /sbin/cups-browsed
core /tmp/core
set width 0
set pagination off
find /b 0xf7920320, 0xf7a634db, 0x66, 0x0f, 0x6f, 0x25, 0x37, 0x7c, 0x03, 0x00, 
0x66, 0x0f, 0x6f, 0x2d, 0x3f, 0x7c, 0x03, 0x00, 0x66, 0x0f, 0x6f, 0x35, 0x47, 
0x7c, 0x03, 0x00, 0x83, 0xf9, 0x30, 0x0f, 0x87, 0x8e, 0x00, 0x00, 0x00, 0x83, 
0xf8, 0x30, 0x0f, 0x87, 0x85, 0x00, 0x00, 0x00, 0xf3, 0x0f, 0x6f, 0x0f, 0xf3, 
0x0f, 0x6f, 0x16, 0x66, 0x0f, 0x6f, 0xf9, 0x66, 0x44, 0x0f, 0x6f, 0xc5, 0x66, 
0x44, 0x0f, 0x6f, 0xca
disassemble /r 0xf7a4db31, 0xf7a4db31 + 62
b * (0xf7a4db31 + 42)
info b


benutzer@debian:~$ gdb -q
(gdb) file /sbin/cups-browsed
Reading symbols from /sbin/cups-browsed...
Reading symbols from 
/usr/lib/debug/.build-id/30/1088ae63113870879be52401bc26cac176081b.debug...
(gdb) core /tmp/core
[New LWP 4218]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnux32/libthread_db.so.1".
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
...
(gdb) set width 0
(gdb) set pagination off
(gdb) find /b 0xf7920320, 0xf7a634db, 0x66, 0x0f, 0x6f, 0x25, 0x37, 0x7c, 0x03, 
0x00, 0x66, 0x0f, 0x6f, 0x2d, 0x3f, 0x7c, 0x03, 0x00, 0x66, 0x0f, 0x6f, 0x35, 
0x47, 0x7c, 0x03, 0x00, 0x83, 0xf9, 0x30, 0x0f, 0x87, 0x8e, 0x00, 0x00, 0x00, 
0x83, 0xf8, 0x30, 0x0f, 0x87, 0x85, 0x00, 0x00, 0x00, 0xf3, 0x0f, 0x6f, 0x0f, 
0xf3, 0x0f, 0x6f, 0x16, 0x66, 0x0f, 0x6f, 0xf9, 0x66, 0x44, 0x0f, 0x6f, 0xc5, 
0x66, 0x44, 

Bug#950272: buster-pu: package mariadb-10.3 10.3.22-0+deb10u1

[Otto Kekäläinen]

> tail: cannot open '/home/debci/.kodi/temp/kodi.log' for reading: No such file 
> or directory
> tail: no files remaining

This is the only output in the test log, otherwise it is installing
packages and everything else seemed to go fine.

Test source says it just starts the app, but now it does not seem to
output anything:
https://salsa.debian.org/multimedia-team/kodi/blob/master/debian/tests/gui

Bug#950272: buster-pu: package mariadb-10.3 10.3.22-0+deb10u1

[Paul Gevers]

Hi Otto, kodi maintainers,

On 02-02-2020 11:56, Otto Kekäläinen wrote:
> Ok, I will amend the changelog and re-upload today 1:10.3.22-0... to
> buster updates.

The autopkgtest of kodi fails on ppc64el (twice) with the p-u version of
MariaDB, while it passes with the old MariaDB version. I'll retrigger it
for the third time, but maybe you want to have a look already.

Paul

[stable result]
https://ci.debian.net/user/britney/jobs?package=kodi=mariadb-10.3%5B%5D=stable%5B%5D=arm64%5B%5D=ppc64el

[failing log]
https://ci.debian.net/data/autopkgtest/stable/ppc64el/k/kodi/4212994/log.gz

autopkgtest [20:24:43]: test gui: [---
tail: cannot open '/home/debci/.kodi/temp/kodi.log' for reading: No such
file or directory
tail: no files remaining
autopkgtest [20:24:49]: test gui: ---]



signature.asc
Description: OpenPGP digital signature

Bug#842610: digikam lost track of photos when renaming an album

[Agustin Martin]

On Sun, Oct 30, 2016 at 08:38:03PM +0100, Vincent Danjean wrote:
> Package: digikam
> Version: 4:5.2.0-2
> Severity: normal
> 
>   Hi,
> 
>   First, note that my digikam version is 4:5.2.0-2.1 instead of
> 4:5.2.0-2 because I recompile it locally with -DENABLE_MEDIAPLAYER=on
> (see #834131).
> 
>   I'm using digikam with a mysql database (since a long time).
> Today, I noticed a bug when renaming albums. It seems that this
> renaming is not taken into account in all internal data
> structure.
>   Here is what happen for example:
> 1) I renamed an album from Bricolage2 to Bricolage
>   Everything seems working. I still see the 3 photos in
>   this album.
> 2) I renamed the 3 photos in this album (using 'F2' and
>   automatic rules for mass renaming). The result is
>   strange:
>   * digikam still shows the thumbnails with the old name
>   * on disk, the pictures have really be renames (with their
> *.xmp files too)
>   * when trying to see the photo in big size, I get a blank
> page
>   * In log log below, you can see that after the rename
> from IMG_* to date_time_IMG_* of photo filenames,
> digikam print:
> digikam.database: Starting scan!
> digikam.database: Folder does not exist or is not readable:  
> "/home/vdanjean/photos/albums/Activités/Bricolage2"
> This is not normal that a reference to Bricolage2 still exists
> at this time. Then, access to photos (with the old name) fail:
> digikam.dimg: File  
> "/home/vdanjean/photos/albums/Activités/Bricolage/IMG_20130731_134231.jpg"  
> does not exist
> digikam.metaengine: Cannot load metadata from file   (Error # 9 :  
> /home/vdanjean/photos/albums/Activités/Bricolage/IMG_20130731_134231.jpg : 
> Impossible d'ouvrir la source de données : Aucun fichier ou dossier de ce 
> type (errno = 2)
> ...
> 
>   If I quit digikam and restart it, it cleans up the mess itself,

Hi, Vincent

Triaging old bug reports. Is this still a problem with current digikam
(6.4.0 in sid)? I tried some simple renamings with 6.4.0 and seems to work.

Regards,

-- 
Agustin

Bug#546403: kipi-plugins: includes Adobe DNG SDK, with problematic license

[Simon Frei]

DNG support is still present in digiKam, COPYING-ADOBE is now found in
core/libs/dngwriter.

reassign 546403 digikam
thanks

Bug#799778: digikam: Not able to import pictures from CANON EOS350D after upgrading from 3.5

[Agustin Martin]

On Sun, Dec 20, 2015 at 10:57:05PM -0600, Steve M. Robbins wrote:
> On Tue, 22 Sep 2015 15:34:20 +0200 Etienne BRETTEVILLE 
>  wrote:
> 
> > After upgrading from LinuxMintDebianEdition LMDE 1 (based on debian 7) to 
> LMDE2
> > based on debian Jessie, digikam has been updated to 4.4.0 instead of 3.5.x.
> > 
> > Since then I'm no longer able to import my pictures from my CanonEOS350D 
> using
> > the importation tool from digikam.
> > 
> > You can see the error message in the screenshot here:
> > https://framapic.org/AiUtTFceoQN0/lexIQ4R7
> > 
> > What about introducing the latest revsion of digikam, 4.13.0?!
> 
> I just uploaded 4.14 today.  If you are in a position to try that out, I'd be 
> very glad to know if it fixes this issue.

Hi,

This was a while ago, currently in Debian we have 6.4.0 in sid and 5.9.0
in stable. Is this still a problem for you?

Also note that we do not have control on local changes that may have been
included in Mint.

Regards,

-- 
Agustin

Bug#930534: Bug#930521: release.debian.org: provide machine-readable information about the freeze period for each release

[Paul Gevers]

Hi,

On 06-02-2020 12:25, Paul Wise wrote:
> On Thu, 2020-02-06 at 12:02 +0100, Paul Gevers wrote:
> 
>> We already have a maintained agenda for the team [1]. Would it make
>> sense to use that somehow?
> 
> That doesn't appear to have enough info right now, it contains only the
> unblock deadline and not the other freeze data.

That is mostly because they have not been settled 100% yet.

>> I fear that having an additional place (next to the freeze_policy
>> document [2]) to store this is likely to get out of sync.
> 
> Perhaps make either the .ics or jmw's proposed YAML[1] the canonical
> location for the dates and them build freeze_policy.html from it?

I am not so much into internals of md, but our freeze_policy page is
currently written in markdown and contains the dates in human readable
strings in several places. I don't have the energy to work on the right
logic that just for this purpose.

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930521#17

Aha, I missed that one.

Maybe we should just add this to our wiki list of stuff to do during the
release period.

Let me try to come back to this bug when we have communicated the dates
and provide a prototype so we can see if it works.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#546403: kipi-plugins: includes Adobe DNG SDK, with problematic license

[Agustin Martin]

On Sun, Sep 13, 2009 at 08:51:06AM +0300, Lars Wirzenius wrote:
> Package: kipi-plugins
> Version: 0.6.0-1
> Severity: severe
> Justification: presumed non-free license for included library
> 
> kipi-plugins contains a copy of the Adobe DNG SDK, which the ftpmasters
> (specifically, Joerg Jaspert) has deemed to have a problematic license,
> preventing it from being packaged in main. kipi-plugins includes a copy
> of the license in COPYING-ADOBE.

Hi,

As of 4:6.4.0+dfsg-1 kipi stuff is no longer shipped and its support seems
removed upstream. So, I guess this is no longer an issue.

Regards,

-- 
Agustin

Bug#927145: digikam: Digikam should depend on libhdf5-100

[Agustin Martin]

On Mon, Apr 15, 2019 at 04:48:38PM +0200, valette wrote:
> Package: digikam
> Version: 4:5.9.0-1+b1
> Severity: important
> 
> digikam 
> digikam: error while loading shared libraries: libhdf5_serial_hl.so.100: 
> cannot open shared object file: No such file or directory

Hi,

Steve has already uploaded digikam 6.4.0 to sid and I am looking at some of
the pending bug reports. Is this still an issue for you?

For 6.4.0 I cannot reproduce the problem and also do not see anything hdf
related in "ldd -v /usr/bin/digikam" output.

Regards,

-- 
Agustin

Bug#950788: /usr/share/man/man5/sysctl.d.5.gz: sysctl.d.5 man page has confusing directory order

[Michael Biebl]

Hi Craig

Am 06.02.20 um 12:31 schrieb Craig Small:
> Package: systemd
> Version: 244-3
> Severity: minor
> File: /usr/share/man/man5/sysctl.d.5.gz
> 
> The sysctl.d.5 man page says this:
> 
>   Configuration files are read from directories in /etc/, /run/, 
> /usr/local/lib/, and /lib/, in order of precedence. Each configuration file 
> in these configuration directories shall be named in the
>   style of filename.conf. Files in /etc/ override files with the same 
> name in /run/, /usr/local/lib/, and /lib/. Files in /run/ override files with 
> the same name under /usr/.
> 
> OK, so we have 4 directories.
> Anything in /etc overrides anything in the other 3.
> 
> But files in /run? They override.. /usr?
> Is this supposed to mean /usr/local/lib?
> Does that mean /run does NOT override files in /lib ?
> 
> I think the man page used to say /usr/local/lib and /usr/lib and it was
> (badly) saying both directories under /usr
> 
> Maybe.. I'm not really sure what way to interpret this.

I suppose this is a result of
https://salsa.debian.org/systemd-team/systemd/blob/debian/master/debian/rules#L200
doing some incorrect replacements.

Replace /lib with /usr/lib and it will make more sense, I guess.

I guess we have to fine-tune the sed expression.





signature.asc
Description: OpenPGP digital signature

Bug#918478: Digikam imageeditor blank screen patch, backported from Digikam 6.0

[Agustin Martin]

On Sat, Nov 09, 2019 at 05:36:07PM -0500, Timothy E. Harris wrote:
> Because this bug affected me, I backported the patch from Digikam 6.0 to the
> buster digikam version

Hi,

Thanks for the patch. Steve has just uploaded digikam 6.4.0, which should
include the fix, to sid. I have minimally tested it and this problem seems
gone here.

¿Is it also fixed for you?

Regards,

-- 
Agustin

Bug#943692: reopened for stable

[Matus UHLAR - fantomas]

Dear Maintainer,

I have reopened this bug as long as it is not fxed in debian stable.

Please, push the provided patch to squid-4.6 in buster.

Hopefully, next security update (fixing CVE-2020-8517, CVE-2020-8450,
CVE-2020-8449 and CVE-2020-8449)  will be done soon so we sould have fixed
version in debian.

The current version 4.6-1+deb10u1 crashes too often (multiple times a day)
on some systems.

Thank you

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."

Bug#950788: /usr/share/man/man5/sysctl.d.5.gz: sysctl.d.5 man page has confusing directory order

[Craig Small]

Package: systemd
Version: 244-3
Severity: minor
File: /usr/share/man/man5/sysctl.d.5.gz

The sysctl.d.5 man page says this:

  Configuration files are read from directories in /etc/, /run/, 
/usr/local/lib/, and /lib/, in order of precedence. Each configuration file in 
these configuration directories shall be named in the
  style of filename.conf. Files in /etc/ override files with the same name 
in /run/, /usr/local/lib/, and /lib/. Files in /run/ override files with the 
same name under /usr/.

OK, so we have 4 directories.
Anything in /etc overrides anything in the other 3.

But files in /run? They override.. /usr?
Is this supposed to mean /usr/local/lib?
Does that mean /run does NOT override files in /lib ?

I think the man page used to say /usr/local/lib and /usr/lib and it was
(badly) saying both directories under /usr

Maybe.. I'm not really sure what way to interpret this.

 - Craig

-- Package-specific info:

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

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-5
ii  libapparmor1 2.13.3-7
ii  libaudit11:2.8.5-2+b1
ii  libblkid12.34-0.1
ii  libc62.29-6
ii  libcap2  1:2.27-1
ii  libcryptsetup12  2:2.2.2-1
ii  libgcrypt20  1.8.5-3
ii  libgnutls30  3.6.11.1-2
ii  libgpg-error01.36-7
ii  libidn2-02.2.0-2
ii  libip4tc21.8.4-1
ii  libkmod2 26-3
ii  liblz4-1 1.9.2-2
ii  liblzma5 5.2.4-1+b1
ii  libmount12.34-0.1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.4.2-2
ii  libselinux1  3.0-1
ii  libsystemd0  244-3
ii  mount2.34-0.1
ii  util-linux   2.34-0.1

Versions of packages systemd recommends:
ii  dbus  1.12.16-2

Versions of packages systemd suggests:
ii  policykit-10.105-26
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.135
ii  udev 244-3

-- Configuration Files:
/etc/systemd/logind.conf changed [not included]

-- no debconf information

Bug#950780: Can't open DBIP database

[jean-christophe manciot]

An upstream request has been filed at netfilter-devel mailing list
.

On Thu, Feb 6, 2020 at 12:01 PM jean-christophe manciot <
actionmysti...@gmail.com> wrote:

> Thanks, I'll take care of it.
>
> On Thu, Feb 6, 2020 at 11:38 AM Dmitry Smirnov  wrote:
>
>> On Thursday, 6 February 2020 9:06:44 PM AEDT jean-christophe manciot
>> wrote:
>> > I have realized by digging within xt_geoip_build that the expected geoip
>> > provider has been changed from Maxmind to db-ip.
>> > This means that running xt_geoip_build with csv downloaded from Maxmind
>> can
>> > no longer work.
>> >
>> > I am aware that Maxmind recently introduced "Significant Changes to
>> > Accessing and Using GeoLite2 Databases" and introduced a new end-user
>> > license agreement.
>> >
>> > However, is there a way to continue to use Maxmind geoip db with latest
>> > debian xtables-addons for *people who detain the required license key*
>> in
>> > order to download GeoLite2 databases?
>>
>> I see, thanks. May I post this information to the bug report?
>>
>> Perhaps that would be a question to upstream...
>>
>> --
>> Cheers,
>>  Dmitry Smirnov.
>>
>> ---
>>
>> The surest way to corrupt a youth is to instruct him to hold in higher
>> esteem those who think alike than those who think differently.
>> -- Friedrich Nietzsche
>>
>
>
> --
> Jean-Christophe
>


-- 
Jean-Christophe

Bug#950787: python3-netaddr: strategy/__init__.py:189: SyntaxWarning: "is not" with a literal. Did you mean "!="?

[Paul Wise]

Package: python3-netaddr
Version: 0.7.19-3
Severity: normal
Usertags: warnings
File: /usr/lib/python3/dist-packages/netaddr/strategy/__init__.py

When I upgrade python3-netaddr to the latest version, I get this
warning, which I think is new in Python 3.8:

Preparing to unpack .../python3-netaddr_0.7.19-3_all.deb ...
Unpacking python3-netaddr (0.7.19-3) over (0.7.19-1) ...
Setting up python3-netaddr (0.7.19-3) ...
/usr/lib/python3/dist-packages/netaddr/strategy/__init__.py:189: SyntaxWarning: 
"is not" with a literal. Did you mean "!="?
  if word_sep is not '':

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-netaddr depends on:
ii  ieee-data  20180805.1
ii  python33.7.5-3

python3-netaddr recommends no packages.

Versions of packages python3-netaddr suggests:
ii  ipython3 5.8.0-2
pn  python-netaddr-docs  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#950626: dcut silently fails

[Mark Brown]

reopen 950626
kthxbye

On Thu, Feb 06, 2020 at 01:47:34PM +1100, Ben Finney wrote:
> On 05-Feb-2020, Mark Brown wrote:

> > If dcut is generating commands which produce no response from the
> > server that seems like a really bad bug in dcut.

> The server does not process commands immediately, so there is no way
> for a client (like ‘dcut’) to know whether they succeed or fail.

"succeed or fail" is not the same as "produce no response".  It
should be possible for dcut to tell if the commands are likely to
be silently discarded and avoid that.

> I hope that clears up the behaviour you're seeing. This is not a bug
> in ‘dcut(1)’, so I'm closing this report.

No, I perfectly understand that the commands are processed in a
laggy fashion.  Like I say that doesn't mean that dcut should be
generating command files which can produce just no reponse at
all, I'd expect dcut to have a good idea before it uploads files
if that will happen and take steps to avoid it.


signature.asc
Description: PGP signature

Bug#915797: /etc/sysctl.d/protect-links.conf should be in /usr/lib/sysctl.d/

[Craig Small]

Actuallty looking at the code this time, yep it (procps sysctl) does do
that and reads them in order of precedence of the directories.
I think procps may have the order different though as /run is before /etc.
The sysctl.d man page is actually confusing so it's hard to say.

 - Craig


On Thu, 6 Feb 2020 at 22:17, Craig Small  wrote:

> On Fri, 7 Dec 2018 at 07:42, Josh Triplett  wrote:
>
>> Package: procps
>> Version: 2:3.3.15-2
>> Severity: normal
>> File: /etc/sysctl.d/protect-links.conf
>>
>> protect-links.conf is supplied by Debian, and should be in
>> /usr/lib/sysctl.d/ ; the sysadmin can still override it by creating
>> /etc/sysctl.d/protect-links.conf .
>>
> That's not actually how the procps version of sysctl works. It reads all
> of the directories. So looks like we have a bigger problem here as the
> systemd version does something different to the procps version.
>
>  - Craig
>

Bug#950786: debian folder disappears on v2.3.0

[jean-christophe manciot]

Package: cryptsetup
Version: v2.3.0
Sources: https://salsa.debian.org/cryptsetup-team/cryptsetup

git-cryptsetup (master)# git log -1
commit 6b1ce46de9943388d2ea0973696b67a7d4ccb694 (HEAD -> master,
origin/master, origin/HEAD)
Author: Guilhem Moulin 
Date:   Tue Feb 4 15:02:02 2020 +0100

Update d/libcryptsetup12.symbols

git-cryptsetup (master)# ls debian
askpass.c  cryptsetup.cryptdisks-early.init
cryptsetup.install
...

git-cryptsetup (master)# git checkout v2.3.0
Note: switching to 'v2.3.0'.
...
HEAD is now at d3d1e30c Prepare version 2.3.0.

git-cryptsetup ((v2.3.0))# ls debian
ls: cannot access 'debian': No such file or directory

This issue prevents us from building cryptsetup with debian tools,
such as debuild.
There was no such issue with previous tags.
-- 
Jean-Christophe

Bug#930534: Bug#930521: release.debian.org: provide machine-readable information about the freeze period for each release

[Paul Wise]

On Thu, 2020-02-06 at 12:02 +0100, Paul Gevers wrote:

> We already have a maintained agenda for the team [1]. Would it make
> sense to use that somehow?

That doesn't appear to have enough info right now, it contains only the
unblock deadline and not the other freeze data.

> I fear that having an additional place (next to the freeze_policy
> document [2]) to store this is likely to get out of sync.

Perhaps make either the .ics or jmw's proposed YAML[1] the canonical
location for the dates and them build freeze_policy.html from it?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930521#17

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#915797: /etc/sysctl.d/protect-links.conf should be in /usr/lib/sysctl.d/

[Craig Small]

On Fri, 7 Dec 2018 at 07:42, Josh Triplett  wrote:

> Package: procps
> Version: 2:3.3.15-2
> Severity: normal
> File: /etc/sysctl.d/protect-links.conf
>
> protect-links.conf is supplied by Debian, and should be in
> /usr/lib/sysctl.d/ ; the sysadmin can still override it by creating
> /etc/sysctl.d/protect-links.conf .
>
That's not actually how the procps version of sysctl works. It reads all of
the directories. So looks like we have a bigger problem here as the systemd
version does something different to the procps version.

 - Craig

Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

[Sudip Mukherjee]

On Thu, Feb 6, 2020 at 8:39 AM Michael Biebl  wrote:
>
> Am 06.02.20 um 09:22 schrieb Adam D. Barratt:
> > On 2020-02-06 08:12, Paul Gevers wrote:
> >> Hi,
> >>
> >> On 06-02-2020 00:07, Adam D. Barratt wrote:
> >>> On Wed, 2020-02-05 at 22:42 +, Sudip Mukherjee wrote:
>  On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas
>   wrote:
> > Because this changes the versioning scheme from kernel releases
> > (libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf
> > version numbers (0.0.6-1), the epoch needs to be incremented to 1 I
> > believe.
> 
>  I had this doubt but 5.4.13-1 is the linux source version, and
>  libbpf0 has the version of 0.0.5. And since there is no separate
>  source for libbpf so will this not be  considered as a new package
>  rather than a version change?
> >>>

>
> One other alternative could be, to ask your upstream to change the
> versioning scheme and instead of using 0.0.6, switch to 6.0.0 as first
> version number (which would be higher then 5.x)
> Other distros might have similar problems.

I think other distros already had the package split and are now using
the source from github. Atleast Fedora and Gentoo have done already.
Looks like Fedora solved the problem using epoch as can be seen in the
comment at https://src.fedoraproject.org/rpms/libbpf/blob/f30/f/libbpf.spec#_15


-- 
Regards
Sudip

Bug#930534: Bug#930521: release.debian.org: provide machine-readable information about the freeze period for each release

[Paul Gevers]

Hi Paul,

On Sat, 15 Jun 2019 01:17:51 +0800 Paul Wise  wrote:
> In order to implement the request below (hide some suggestions from
> tracker.d.o during the freeze (and possibly other things)), we need a
> machine-readable information source about the current stage of the
> freeze and what that means for new upstream releases. I suggest that
> this come in the form of a YAML/JSON file in the testing directory
> containing start dates for each stage of the freeze and an end date
> once that is known. Each stage could be accompanied by some sort of
> metadata about the freeze policy, so that the tracker could also give
> advice on what to upload and what not to upload.
> 
> https://release.debian.org/testing/freeze.yaml

We already have a maintained agenda for the team [1]. Would it make
sense to use that somehow? I fear that having an additional place (next
to the freeze_policy document [2]) to store this is likely to get out of
sync.

Paul

[1] http://release.debian.org/release-calendar.ics
[2] https://release.debian.org/bullseye/freeze_policy.html



signature.asc
Description: OpenPGP digital signature

Bug#950470: breezy still fails with one autopkg test on the binary-indep buid

[Mattia Rizzolo]

On Sun, Feb 02, 2020 at 10:37:41AM +0100, Matthias Klose wrote:
> Package: src:breezy
> Version: 3.0.2-3
> Severity: serious
> Tags: sid bullseye
> 
> see
> https://buildd.debian.org/status/fetch.php?pkg=breezy=all=3.0.2-3=1580478666=0
> 
> ==
> ERROR:
> breezy.tests.per_branch.test_stacking.TestStackingConnections.test_open_stacked_relative(RemoteBranchFormat-v2)
> --
> Traceback (most recent call last):
> testtools.testresult.real._StringException: lost connection during test
> 'breezy.tests.per_branch.test_stacking.TestStackingConnections.test_open_stacked_relative(RemoteBranchFormat-v2)'
> --
> Ran 24171 tests in 6121.269s
> 
> FAILED (errors=1, known_failure_count=52)
> 3101 tests skipped

Note that this is flaky.
I retried the build and it seems to have passed.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#950342: RM: volatility/2.6.1-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Sandro,

On 31-01-2020 16:02, Sandro Tosi wrote:
> Please remove volatility from testing;  volatility is the last reverse
> dependency of python-openpyxl, which can then be dropped.
> 
> I've already filed an RC bug against src:volatility to keep it out of testing.

But it still has a reverse dependency. I think that package should get
time drop the dependency first, don't you think (it seems to me that
it's a meta-package that could easily do that)?

Paul

elbrus@respighi:~$ dak rm --no-action -R --suite testing volatility
Will remove the following packages from testing:

volatility |2.6.1-1 | source, all
volatility-tools |2.6.1-1 | all

Maintainer: Debian Security Tools 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
forensics-all: forensics-all

Dependency problem found.



signature.asc
Description: OpenPGP digital signature

Bug#950363: licensecheck reports dubious (may be misleading) information for image files

[Jonas Smedegaard]

control: severity -1 wishlist
control: retitle -1 licensecheck: detect additional (i.e. non-SPDX) qualities

Quoting Dominique Dumont (2020-02-06 10:17:26)
> On Friday, 31 January 2020 20:28:50 CET Jonas Smedegaard wrote:
> > Concretely I do think that you have spotted an issue with an image 
> > containing non-free code, and I recommend that you report or fix it.
> 
> Thanks for the advice. This worked quite well:
> https://github.com/libuv/libuv/issues/2670
> https://github.com/libuv/libuv/pull/2672
> 
> I'm prettysure the stripped images will be merged for libuv1 release.
> 
> Thanks for pushing me to do this :-)

I am very happy that it worked out well.  Their response is similar to 
what I generally experience: Positive surprise and (maybe after a bit of 
confusion) full agreement that it should be fixed.

(I must admit I am commonly a bit scared of filing bugreports - which 
makes me wonder not if but when and how I myself is scary to approach)


> > Just yesterday I wrote down in the TODO file for licensecheck (but 
> > not yet added that edit to git) that it would be nice if a set of 
> > "qualities" was expressed, besides the concrete task of finding 
> > copyright and licnesing statements.  It was inspired by the 
> > currently the only "side note" tracked - "(with wrong address)" - 
> > and presented only in default output (it really should be added as a 
> > Comment when generating DEP-5 output), but fits well with this 
> > example too.
> 
> ok, I'm wondering if you plan to include this information in "machine" 
> output. That may break the processing done by cme.

There are two machine-readable outputs currently, enabled by either of 
options "--machine" or "--deb-machine" - I assume you are talking about 
the latter.

Yes, I plan to include most possible in machine-readable output, but 
will (for the "--deb-machine" format) keep within the boundaries of 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ - so 
what you should worry about should only be if you are making too strict 
assumptions on that format.  In particular, beware that it is plain 
wrong to only expect explicitly defined fields (as per § 4: "Extra 
fields can be added to any paragraph").

On a related note, beware that the FIXMEs added to output is deliberate: 
Licensecheck does not claim to know better than human reasoning what is 
accurate, and therefore flag all its findings as needing human 
confirmation.  If you wrap Licensecheck and hide/strip those FIXMEs then 
_you_ take responsibility for the output being perceived as requiring 
less/no human validation.  Now that I write this, it occurs to me that 
it probably makes sense to expand those FIXMEs to add some explanatory 
text.


> > Here is the full list I wrote down:
> > 
> >  * Quality flagging
> >+ ambiguous: license ref pointing to multiple license fulltexts
> >  (e.g. "MIT" or "GNU" or "GPL"
> >+ unlicensed: copyright holder(s) but no licensing
> >+ ungranted: license fullref requiring explicit grant,
> >  but no corresponding license grant
> >+ incomplete: fractions of license fullref, but no complete fullref
> >+ alien: license label but no license name
> >+ unowned: license but no copyright holder
> >+ uncertain: license ref and more unknown text
> >  in same sentence/paragraph/section
> >+ buried: license or copyright not at top of file
> >+ unstructured: license/copyright not at ideal place of data structure
> >  (e.g. in commend field of EXIF data, or in content o of PDF/HTML)
> >+ unaligned: license/copyright out of sync between layers of structure
> >  (e.g. ICC data and EXIF data of PNG, or content and metadata of
> > PDF/HTML) + imperfect: license ref not following format documented in
> > license fulltext + conflict: incompatible licenses
> >  (e.g. GPL-3+ and GPL-2-only, or OpenSSL and GPL)
> > 
> > The example you present here would ideally (continue to report HP as
> > copyright holder - and more reliably so, but that's a separate issue -
> > and) be flagged as "unlicensed", "buried" and "unaligned".
> > 
> > Does that make sense?  
> 
> yes, but I'm not sure how I could exploit this information with cme.

I imagine that qualities are of different importance for different uses 
of licensecheck.  An author might be interested in correcting errors, 
and a larger organization of authors (e.g. KDE) might want to ensure 
coherence both in writing style and in licensing "regime" (in lack of a 
better word: which political field they want to stay within - e.g. 
"GNU-compatible copyleft" or "Apache semi-copyleft without 
GPL-contamination"), whereas a distributor like Debian is less 
interested about style (we cannot change it anyway) except for details 
directly harmful for our work (e.g. wrong contact information as has 
happened with FSF changing postal address).


> May be a mechanism similer to "and/or" in license: a license statement 
> with "and/or" is allowed but 

Bug#950785: ITP: r-bioc-rwikipathways -- rWikiPathways - R client library for the WikiPathways API

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-rwikipathways -- rWikiPathways - R client library for the 
WikiPathways API
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-rwikipathways
  Version : 1.6.1
  Upstream Author : Copyright: (FIXME: year)-2019 Egon Willighagen,
* URL : https://bioconductor.org/packages/rWikiPathways/
* License : MIT
  Programming Lang: GNU R
  Description : rWikiPathways - R client library for the WikiPathways API
 Use this package to interface with the WikiPathways API.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-rwikipathways

Bug#946491: unattended-upgrades: 100% of at least one CPU core consumed until killed daily via debian

[Joel Cross]

If I can give a bit more information on this bug, since it affects me too...

Every day, at around the same time, I notice my computer heating up, because 
the unattended-upgrades process is running. This happens even though I have 
masked the service in systemd. Attempting to kill the process does not work 
unless I do `kill -9`, even then it immediately respawns unless I also stop the 
process in systemd. This is on a fairly clean bullseye install.

Bug#950784: RM: mgltools-gle -- ROM; Unmaintained, no Python2 port

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

I hereby request removal of this package since it is unmaintained
and has no Python2 port (see #937024).

Kind regards
 Andreas.

Bug#947238: Not giving any clue on how to reproduce

[Thomas Goirand]

Hi,

I've seen that this bug was the cause for keepalived to be removed from
Testing. However, this bug was opened against keepalived in Stable. I've
been using this version in production for nearly a year, and never
experienced the same thing, everything just runs smoothly for me. So
without giving any clue on how to reproduce the issue, I don't think
this bug is relevant. I'm therefore reducing severity to "important".

Cheers,

Thomas Goirand (zigo)

Bug#950783: ITP: python-cdsapi -- Python interface for the ECMWF CDS API

[Gard Spreemann]

Package: wnpp
Severity: wishlist
Owner: Gard Spreemann 

* Package name: python-cdsapi
  Version : 0.2.5
  Upstream Author : ECMWF
* URL : https://pypi.org/project/cdsapi
* License : Apache-2.0
  Programming Lang: Python
  Description : Python interface for the ECMWF CDS API

Python library for the API of the European Centre for Medium-Range
Weather Forecasts' (ECMWF) Climate Data Store (CDS).

More information about the CDS can be found on
https://cds.climate.copernicus.eu


I plan to maintain the package myself.

Bug#943173: Not in testing yet?

[Dmitry Shachnev]

Hi Florian!

On Thu, Feb 06, 2020 at 10:36:22AM +0100, Florian Bruhin wrote:
> Hey,
>
> It looks like 5.14.0-2 with the fix isn't in testing yet? See
> https://tracker.debian.org/pkg/pyqt5webengine
> https://qa.debian.org/excuses.php?package=pyqt5webengine
>
> I don't really understand why - can someone elaborate on what's going on?

That is because the Python 3 version of calibre failed to build on two
architectures (arm64, mipsel), so calibre in testing still uses Python 2,
so some packages which dropped Python 2 support (like pyqt5webengine)
cannot migrate to testing.

I think on February 16th calibre will be auto-removed from testing, and
after that all those packages will be able to migrate. In the worst case,
they will be removed for a short time but then will migrate anyway (but now
that we have some activity on this bug, I don't think that will be the case
for pyqt5webengine).

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#950255: RM: rust-pcap -- ROM; no longer in use

[Paul Gevers]

Control: reassign -1 ftp.debian.org

Hi kpcyrd,

On 30-01-2020 17:24, Paul Gevers wrote:
> I assume you actually want the removal from unstable? Than the bug
> should be reassigned to ftp.debian.org.

I went ahead and reassigned. Please reassign back if you really only
want it removed from testing, but then please explain why.

Paul

Bug#950721: ITP: bepasty -- binary pastebin / file upload service

[Johannes Schauer]

Hi,

On Wed, 05 Feb 2020 12:05:17 +0100 Elena ``of Valhalla''  
wrote:
> bepasty is like a pastebin for all kind of files (text, image, audio, video,
>  documents, ..., binary).
> 
> AFAIK there is no other pastebin server inside debian, and this looks
> simple enough to be reasonably mainteinable as a package.

"pastebin for text, image, audio, video" sound very much like either a
"single-file time-limited file sharing" service or "file sharing (dropbox)".
Maybe you could add bepasty into the right section of this overview:

https://wiki.debian.org/FreedomBox/LeavingTheCloud

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#950782: Please support 7z archives by adding python3-lz4 to Suggests

[Marcus Frings]

Package: recollcmd
Version: 1.26.3-1
Severity: wishlist

Dear maintainer,

Recoll supports indexing 7z archives. If python3-lz4 is not installed,
recoll gives errors such as

:2:utils/netcon.cpp:699::NetconData::send: send(16): errno 32: Broken pipe
:2:utils/execmd.cpp:874::ExecCmd::send: send failed
:2:internfile/mh_execm.cpp:209::MHExecMultiple: send error
:2:internfile/internfile.cpp:797::FileInterner::internfile: next_document error 
[not-disclosed-here.7z] application/x-7z-compressed

when it finds a 7z file. Thus, I recommend adding python3-lz4 to the
"Suggests" section.

Best regards,
Marcus
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages recollcmd depends on:
ii  libc62.29-10
ii  libchm1  2:0.40a-5+b1
ii  libgcc-s1 [libgcc1]  10-20200204-1
ii  libgcc1  1:10-20200204-1
ii  libstdc++6   10-20200204-1
ii  libx11-6 2:1.6.8-1
ii  libxapian30  1.4.12-1
ii  libxml2  2.9.4+dfsg1-8
ii  libxslt1.1   1.1.32-2.2
ii  zlib1g   1:1.2.11.dfsg-1.2

Versions of packages recollcmd recommends:
ii  aspell  0.60.8-1
ii  python3 3.7.5-3
ii  python3-recoll  1.26.3-1
ii  xdg-utils   1.1.3-1
ii  xsltproc1.1.32-2.2

Versions of packages recollcmd suggests:
ii  antiword0.37-15
ii  djvulibre-bin   3.5.27.1-14
ii  ghostscript 9.50~dfsg-5
pn  groff   
ii  libimage-exiftool-perl  11.85-1
pn  libinotifytools0
pn  libwpd-tools
ii  poppler-utils   0.71.0-6
ii  pstotext1.9-6+b2
ii  python3-chardet 3.0.4-4
pn  python3-chm 
pn  python3-icalendar   
ii  python3-lxml4.4.2-1
pn  python3-mido
pn  python3-mutagen 
pn  python3-rarfile 
ii  python3-six 1.14.0-2
ii  unrtf   0.21.10-clean-1
ii  untex   1:1.2-6+b1
pn  wv  

-- no debconf information

Bug#950780: Can't open DBIP database

[Dmitry Smirnov]

On Thursday, 6 February 2020 8:29:44 PM AEDT jean-christophe manciot wrote:
> # /usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip -S .
> Can't open DBIP database
> 
> This issue also happens with 3.8-1, but not with previous versions.

Could it be related to the following upstream changelog entry?


v3.8 (2020-02-03)
=
- xt_geoip_build now expects the DBIP format as input,
  Maxmind is thrown out.


Unfortunately I don't understand the issue...

-- 
Cheers,
 Dmitry Smirnov.

---

No person, no idea, and no religion deserves to be illegal to insult,
not even the Church of Emacs.
-- Richard Stallman


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

Bug#950781: ITP: r-bioc-biocstyle -- standard styles for vignettes and other Bioconductor documents

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-biocstyle -- standard styles for vignettes and other 
Bioconductor documents
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-biocstyle
  Version : 2.14.4
  Upstream Author : Andrzej Oleś, Martin Morgan, Wolfgang Huber
* URL : https://bioconductor.org/packages/BiocStyle/
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : standard styles for vignettes and other Bioconductor 
documents
 Provides standard formatting styles for Bioconductor PDF
 and HTML documents. Package vignettes illustrate use and
 functionality.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-biocstyle

Bug#950608: gmp 6.2.0 crashes postgresql-pgmp

[Christoph Berg]

Re: Steven Robbins 2020-02-06 <4839510.uz11uGdL23@riemann>
> > the new gmp version makes postgresql-pgmp crash on arm64:
> > 
> > https://ci.debian.net/data/autopkgtest/testing/arm64/p/postgresql-pgmp/
> 4173638/log.gz
> > (linked from https://packages.qa.debian.org/g/gmp.html)
> 
> ...etc.  Thanks, that's useful to know.  I don't know the postgresql-pgmp 
> code 
> at all.  Can you help me understand what the linked web pages are telling us?

Hi Steve,

the postgresql-pgmp author found a fix so this isn't an issue anymore:

https://github.com/dvarrazzo/pgmp/issues/18
https://github.com/dvarrazzo/pgmp/commit/04274c40b63d3dff758bee47c8525112d64d1ab2

I don't know the gmp internals, but I guess this fix might be
applicable to other gmp users as well if they have problems.

Christoph

Bug#950591: O: aboot

[John Paul Adrian Glaubitz]

Control: retitle -1 ITA: aboot
Control: owner -1 !

Changing to ITA and setting myself as owner.

My pull request to switch to docbook-utils for aboot has been
merged [1] upstream in the meantime.

Thanks,
Adrian

> [1] 
> https://github.com/mattst88/aboot/commit/45004d6e3e26f385469c150989d51159cd33c802

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#943173: Not in testing yet?

[Florian Bruhin]

Hey,

It looks like 5.14.0-2 with the fix isn't in testing yet? See
https://tracker.debian.org/pkg/pyqt5webengine
https://qa.debian.org/excuses.php?package=pyqt5webengine

I don't really understand why - can someone elaborate on what's going on?

It looks like dependent packages (like qutebrowser, which I'm the upstream of)
are getting mails like this:

Date: Thu, 06 Feb 2020 04:39:10 +
From: Debian testing autoremoval watch 
To: qutebrow...@packages.debian.org
Subject: qutebrowser is marked for autoremoval from testing

qutebrowser 1.9.0-1 is marked for autoremoval from testing on 2020-02-16

It (build-)depends on packages with these RC bugs:
943173: pyqt5webengine: Python2 removal in sid/bullseye

Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature

Bug#950780: Can't open DBIP database

[jean-christophe manciot]

Package: xtables-addons
Version: 3.8-2

# ls *.csv
GeoLite2-Country-Blocks-IPv4.csv   GeoLite2-Country-Locations-en.csv
 GeoLite2-Country-Locations-ja.csv GeoLite2-Country-Locations-zh-CN.csv
GeoLite2-Country-Blocks-IPv6.csv   GeoLite2-Country-Locations-es.csv
 GeoLite2-Country-Locations-pt-BR.csv
GeoLite2-Country-Locations-de.csv  GeoLite2-Country-Locations-fr.csv
 GeoLite2-Country-Locations-ru.csv

# /usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip -S .
Can't open DBIP database

This issue also happens with 3.8-1, but not with previous versions.
-- 
Jean-Christophe

Bug#950363: licensecheck reports dubious (may be misleading) information for image files

[Dominique Dumont]

Hi Jonas

On Friday, 31 January 2020 20:28:50 CET Jonas Smedegaard wrote:
> I agree with your analysis but not your conclusion: I will argue that
> the image _does_ have copyright information - just not at its ideal
> place.

Hmmf, you're right. I assumed wrongly that the ICC info was kind of a pointer, 
not mapping data between colors.

> Concretely I do think that you have spotted an issue with an image
> containing non-free code, and I recommend that you report or fix it.

Thanks for the advice. This worked quite well:
https://github.com/libuv/libuv/issues/2670
https://github.com/libuv/libuv/pull/2672

I'm prettysure the stripped images will be merged for libuv1 release.

Thanks for pushing me to do this :-)

> Just yesterday I wrote down in the TODO file for licensecheck (but not
> yet added that edit to git) that it would be nice if a set of
> "qualities" was expressed, besides the concrete task of finding
> copyright and licnesing statements.  It was inspired by the currently
> the only "side note" tracked - "(with wrong address)" - and presented
> only in default output (it really should be added as a Comment when
> generating DEP-5 output), but fits well with this example too.

ok, I'm wondering if you plan to include this information in "machine" output. 
That may break the processing done by cme.

> Here is the full list I wrote down:
> 
>  * Quality flagging
>+ ambiguous: license ref pointing to multiple license fulltexts
>  (e.g. "MIT" or "GNU" or "GPL"
>+ unlicensed: copyright holder(s) but no licensing
>+ ungranted: license fullref requiring explicit grant,
>  but no corresponding license grant
>+ incomplete: fractions of license fullref, but no complete fullref
>+ alien: license label but no license name
>+ unowned: license but no copyright holder
>+ uncertain: license ref and more unknown text
>  in same sentence/paragraph/section
>+ buried: license or copyright not at top of file
>+ unstructured: license/copyright not at ideal place of data structure
>  (e.g. in commend field of EXIF data, or in content o of PDF/HTML)
>+ unaligned: license/copyright out of sync between layers of structure
>  (e.g. ICC data and EXIF data of PNG, or content and metadata of
> PDF/HTML) + imperfect: license ref not following format documented in
> license fulltext + conflict: incompatible licenses
>  (e.g. GPL-3+ and GPL-2-only, or OpenSSL and GPL)
> 
> The example you present here would ideally (continue to report HP as
> copyright holder - and more reliably so, but that's a separate issue -
> and) be flagged as "unlicensed", "buried" and "unaligned".
> 
> Does that make sense?  

yes, but I'm not sure how I could exploit this information with cme.

May be a mechanism similer to "and/or" in license: a license statement with 
"and/or" is allowed but triggers a warning inviting cme user to investigate 
manually the problematic file and override the information extracted by 
licensecheck.

> Would you agree to turn this bugreport into a
> wishlist reminder for making that side-note spiffy-ness happen?

Sure.

All the best

Bug#950779: Incorrect dependency on "libxcb-xfixes0-dev."

[Yuri D'Elia]

Package: libxcb-xinput-dev
Version: 1.13.1-4
Severity: important

The new version cannot be installed as it depends on
"libxcb-xfixes0-dev." (typo with a trailing dot).

Bug#950778: Debian GDB patch

[Hector Oron]

Package: gdb
Version: 8.3-1
Severity: normal
tags: patch


Hello Christian,

Missatge de Christian Biesinger  del dia dj., 6
de febr. 2020 a les 2:11:

> I noticed that in
> https://salsa.debian.org/gdb-team/gdb/blob/debian/unstable/debian/patches/load-versioned-libcc1.patch,
> you only changed gcc-c-interface.h. Doesn't gcc-cp-interface.h need a
> similar change?
>
> Also, I submitted a couple of pull requests at
> https://salsa.debian.org/gdb-team/gdb/merge_requests, it would be
> great if you could find some time to take a look at them.

Thanks for your comments and contribution! I do not have my Debian
credentials with me right now, I'll have a look as soon as time
allows, probably this evening.

PS./ Adding this as a bug in the Debian BTS to keep track

Regards

-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

[Michael Biebl]

Am 06.02.20 um 09:22 schrieb Adam D. Barratt:
> On 2020-02-06 08:12, Paul Gevers wrote:
>> Hi,
>>
>> On 06-02-2020 00:07, Adam D. Barratt wrote:
>>> On Wed, 2020-02-05 at 22:42 +, Sudip Mukherjee wrote:
 On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas
  wrote:
> Because this changes the versioning scheme from kernel releases
> (libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf
> version numbers (0.0.6-1), the epoch needs to be incremented to 1 I
> believe.

 I had this doubt but 5.4.13-1 is the linux source version, and
 libbpf0 has the version of 0.0.5. And since there is no separate
 source for libbpf so will this not be  considered as a new package
 rather than a version change?
>>>
>>> No. There is currently a libbpf0 binary package. After the source
>>> package split, there will still be a libbpf0 binary package. The
>>> version of that binary package cannot go backwards.
>>>
>>> (The source package will indeed be NEW, but that's not the issue under
>>> discussion here.)
>>
>> But, if I am correct, the source could be using a version without epoch
>> and only use the epoch in the binary package (which can be dropped if
>> libbpf0 is ever replaced by libbpf1).
> 
> Yes. It's a little more work on the packaging side, but entirely
> possible to do it that way.

There is also libbpf-dev, which could not drop the epoch on a soname
bump. Would be kinda odd if going forward libbpfx would not have an
epoch and libbpf-dev does.

One other alternative could be, to ask your upstream to change the
versioning scheme and instead of using 0.0.6, switch to 6.0.0 as first
version number (which would be higher then 5.x)
Other distros might have similar problems.

Michael




signature.asc
Description: OpenPGP digital signature

Bug#881098: unbuffered pee

[Dima Kogan]

I looked at the sources just now, and it does this:

for (i = 1; i < argc; i++) {
pipes[i - 1] = popen(argv[i], "w");
...
setbuf(pipes[i - 1], NULL);
}

I.e. each pipe is already unbuffered. Matthew, can you confirm that you
are indeed seeing buffered output?

Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

[Adam D. Barratt]

On 2020-02-06 08:12, Paul Gevers wrote:

Hi,

On 06-02-2020 00:07, Adam D. Barratt wrote:

On Wed, 2020-02-05 at 22:42 +, Sudip Mukherjee wrote:

On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas
 wrote:

Because this changes the versioning scheme from kernel releases
(libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf
version numbers (0.0.6-1), the epoch needs to be incremented to 1 I
believe.


I had this doubt but 5.4.13-1 is the linux source version, and
libbpf0 has the version of 0.0.5. And since there is no separate
source for libbpf so will this not be  considered as a new package
rather than a version change?


No. There is currently a libbpf0 binary package. After the source
package split, there will still be a libbpf0 binary package. The
version of that binary package cannot go backwards.

(The source package will indeed be NEW, but that's not the issue under
discussion here.)


But, if I am correct, the source could be using a version without epoch
and only use the epoch in the binary package (which can be dropped if
libbpf0 is ever replaced by libbpf1).


Yes. It's a little more work on the packaging side, but entirely 
possible to do it that way.


Regards,

Adam

Bug#950753: nmu: csound_1:6.13.0~dfsg-3 and other stk reverse dependencies

[Paul Gevers]

Hi Sebastian,

On 05-02-2020 20:35, Sebastian Ramacher wrote:
> libstk bumped its SOAME. So please schedule rebuilds for its reverse
> dependencies:
> 
> nmu csound_1:6.13.0~dfsg-3 . ANY . unstable . -m "Rebuild against 
> libstk-4.6.1"
> dw csound_1:6.13.0~dfsg-3 . ANY . -m "libstk0-dev (>= 4.6.1)"
> nmu lmms_1.2.1+dfsg1-4 . ANY . unstable . -m "Rebuild against libstk-4.6.1"
> dw lmms_1.2.1+dfsg1-4 . ANY . -m "libstk0-dev (>= 4.6.1)"
> nmu pd-flext_0.6.0+git20161101.1.01318a94-4 . ANY . unstable . -m "Rebuild 
> against libstk-4.6.1"
> dw pd-flext_0.6.0+git20161101.1.01318a94-4 . ANY . -m "libstk0-dev (>= 4.6.1)"
> nmu supercollider-sc3-plugins_3.9.1~repack-3 . ANY . unstable . -m "Rebuild 
> against libstk-4.6.1"
> dw supercollider-sc3-plugins_3.9.1~repack-3 . ANY . -m "libstk0-dev (>= 
> 4.6.1)"

Your transition has a collision with python3.8-defaults which is
currently being discussed, so it's hurting the process. Please, next
time, request a transition slot before uploading to unstable.

Paul

Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

[Paul Gevers]

Hi,

On 06-02-2020 00:07, Adam D. Barratt wrote:
> On Wed, 2020-02-05 at 22:42 +, Sudip Mukherjee wrote:
>> On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas
>>  wrote:
>>> Because this changes the versioning scheme from kernel releases
>>> (libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf
>>> version numbers (0.0.6-1), the epoch needs to be incremented to 1 I
>>> believe.
>>
>> I had this doubt but 5.4.13-1 is the linux source version, and
>> libbpf0 has the version of 0.0.5. And since there is no separate
>> source for libbpf so will this not be  considered as a new package
>> rather than a version change?
> 
> No. There is currently a libbpf0 binary package. After the source
> package split, there will still be a libbpf0 binary package. The
> version of that binary package cannot go backwards.
> 
> (The source package will indeed be NEW, but that's not the issue under
> discussion here.)

But, if I am correct, the source could be using a version without epoch
and only use the epoch in the binary package (which can be dropped if
libbpf0 is ever replaced by libbpf1).

Paul