Bug#938751: Bug#939506: unanimity ftbfs in unstable

[Andreas Tille]

Control: tags -1 help

Hi,

On Thu, Sep 05, 2019 at 06:39:33PM +0200, Matthias Klose wrote:
> cd /build/1st/unanimity-3.3.0+dfsg/build/src && /usr/bin/cmake -E
> cmake_link_script CMakeFiles/gcpp.dir/link.txt --verbose=1
> /build/1st/unanimity-3.3.0+dfsg/src/main/ccs.cpp: In function ‘int
> Runner(const PacBio::CLI::Results&)’:
> /build/1st/unanimity-3.3.0+dfsg/src/main/ccs.cpp:570:38: error: ‘move’ was
> not declared in this scope
>   570 | read.Sequence(), move(ipd), move(pw),
> read.LocalContextFlags(),
>   |  ^~~~

I have pushed the latest upstream version to Git[1].  The whole error message
is now:


...
cd /build/unanimity-3.4.1+git20180307.02aa264+dfsg/build/src && /usr/bin/c++   
-I/build/unanimity-3.4.1+git20180307.02aa264+dfsg/include 
-I/build/unanimity-3.4.1+git20180307.02aa264+dfsg/build/generated 
-I/build/unanimity-3.4.1+git20180307.02aa264+dfsg/src  -g -O2 
-fdebug-prefix-map=/build/unanimity-3.4.1+git20180307.02aa264+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time - 
  D_FORTIFY_SOURCE=2 -Wall -Wextra -Wno-unused-parameter 
-Wno-unused-variable -Wno-unused-local-typedefs   -fPIC -std=c++14 -o 
CMakeFiles/ccs.dir/main/ccs.cpp.o -c 
/build/unanimity-3.4.1+git20180307.02aa264+dfsg/  src/main/ccs.cpp
/build/unanimity-3.4.1+git20180307.02aa264+dfsg/src/main/ccs.cpp:63:12: error: 
‘std::setprecision’ has not been declared
   63 | using std::setprecision;
  |^~~~
/build/unanimity-3.4.1+git20180307.02aa264+dfsg/src/main/ccs.cpp: In function 
‘void WriteResultsReport(std::ostream&, const Results&)’:
/build/unanimity-3.4.1+git20180307.02aa264+dfsg/src/main/ccs.cpp:273:24: error: 
‘setprecision’ was not declared in this scope
  273 | report << fixed << setprecision(2);
  |^~~~
/build/unanimity-3.4.1+git20180307.02aa264+dfsg/src/main/ccs.cpp: In function 
‘int Runner(const PacBio::CLI::Results&)’:
/build/unanimity-3.4.1+git20180307.02aa264+dfsg/src/main/ccs.cpp:570:38: error: 
‘move’ was not declared in this scope
  570 | read.Sequence(), move(ipd), move(pw), 
read.LocalContextFlags(),
  |  ^~~~
/build/unanimity-3.4.1+git20180307.02aa264+dfsg/src/main/ccs.cpp:570:38: note: 
suggested alternatives:
In file included from /usr/include/c++/9/deque:67,
 from /usr/include/boost/detail/container_fwd.hpp:91,
 from /usr/include/boost/container_hash/extensions.hpp:22,
 from /usr/include/boost/container_hash/hash.hpp:760,
 from /usr/include/boost/type_index/stl_type_index.hpp:43,
 from /usr/include/boost/type_index.hpp:29,
 from /usr/include/boost/function/function_base.hpp:21,
 from /usr/include/boost/function/detail/prologue.hpp:17,
 from /usr/include/boost/function.hpp:30,
 from 
/usr/include/boost/algorithm/string/detail/find_iterator.hpp:18,
 from /usr/include/boost/algorithm/string/find_iterator.hpp:24,
 from /usr/include/boost/algorithm/string/iter_find.hpp:27,
 from /usr/include/boost/algorithm/string/split.hpp:16,
 from /usr/include/boost/algorithm/string.hpp:23,
 from 
/build/unanimity-3.4.1+git20180307.02aa264+dfsg/src/main/ccs.cpp:14:
/usr/include/c++/9/bits/stl_deque.h:443:5: note:   ‘std::move’
  443 | move(_Deque_iterator<_Tp, _Tp&, _Tp*> __first,
  | ^~~~
In file included from /usr/include/boost/move/algorithm.hpp:29,
 from /usr/include/boost/move/move.hpp:32,
 from /usr/include/boost/variant/detail/move.hpp:28,
 from /usr/include/boost/variant/detail/initializer.hpp:23,
 from /usr/include/boost/variant/variant.hpp:30,
 from /usr/include/boost/variant.hpp:17,
 from /usr/include/pbbam/Tag.h:10,
 from /usr/include/pbbam/TagCollection.h:13,
 from /usr/include/pbbam/BamRecordImpl.h:21,
 from /usr/include/pbbam/BamRecord.h:19,
 from /usr/include/pbbam/BamWriter.h:15,
 from 
/build/unanimity-3.4.1+git20180307.02aa264+dfsg/src/main/ccs.cpp:22:
/usr/include/boost/move/algo/move.hpp:53:6: note:   ‘boost::move’
   53 |O move(I f, I l, O result)
  |  ^~~~
In file included from /usr/include/boost/function/function_template.hpp:32,
 from /usr/include/boost/function/detail/maybe_include.hpp:15,
 from 
/usr/include/boost/function/detail/function_iterate.hpp:14,
 from 
/usr/include/boost/preprocessor/iteration/detail/iter/forward1.hpp:48,
 from /usr/include/boost/function.hpp:71,
 from 
/usr/include/boost/algorithm/string/detail/find_iterator.hpp:18,
 from /usr/include/boost/a

Bug#946997: /usr/sbin/sshd: sshd doesn't restart after dying

[Xavier Bestel]

Package: openssh-server
Version: 1:7.9p1-10+deb10u1
Severity: normal
File: /usr/sbin/sshd

Hi,

When sshd dies, it doesn't restart which makes the machine unreachable.
E.g. try "sudo killall sshd", and voilà you can't use a headless machine 
anymore.

Could this be fixed ?

Thanks,
Xav

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-10
ii  libcom-err21.44.5-1+deb10u2
ii  libgssapi-krb5-2   1.17-3
ii  libkrb5-3  1.17-3
ii  libpam-modules 1.3.1-5
ii  libpam-runtime 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux12.8-1+b1
ii  libssl1.1  1.1.1d-0+deb10u2
ii  libsystemd0241-7~deb10u2
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400
ii  openssh-client 1:7.9p1-10+deb10u1
ii  openssh-sftp-server1:7.9p1-10+deb10u1
ii  procps 2:3.3.15-2
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  241-7~deb10u2
ii  ncurses-term 6.1+20181013-2+deb10u2
ii  xauth1:1.0.10-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
pn  ssh-askpass   
pn  ufw   

-- debconf information:
  openssh-server/permit-root-login: true
  openssh-server/password-authentication: true

Bug#934467: Meson build system leads to missing library for linker (Was: Bug#934467: pbbam FTBFS with nocheck profile: cram3 missing)

[Andreas Tille]

Control: tags -1 pending

Hi,

I have a problem with latest version of pbbam[1] where upstream switched
to meson as build system.  I get:


...
...  'src/25a6634@@pbbam@sha/  vcf_VcfWriter.cpp.o' 
'src/25a6634@@pbbam@sha/pugixml_pugixml.cpp.o' -Wl,--as-needed 
-Wl,--no-undefined -shared -fPIC -Wl,--start-group 
-Wl,-soname,libpbbam.so.1.0.6 -g -O2 -fdebug-prefix-map=/build/pbbam-1.0.6+  
dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,-z,now -pthread /usr/lib/x86_64-linux-gnu/libz.so 
/usr/lib/x86_64-linux-gnu/libhts.so -lpbcopper -Wl,--end-group
/usr/bin/ld: cannot find -lpbcopper


In the pbuilder chroot everything seems to be prepared to find libpbcopper:

root:/# find /usr/lib/x86_64-linux-gnu -name "*pbcopper*"
/usr/lib/x86_64-linux-gnu/libpbcopper.so
/usr/lib/x86_64-linux-gnu/pkgconfig/pbcopper.pc
root:/# pkg-config --libs pbcopper
-lpbcopper


Am I missing something?

Kind regards

   Andreas.


[1] https://salsa.debian.org/med-team/pbbam

-- 
http://fam-tille.de

Bug#946359: pg-snakeoil: Selftest apears to be broken

[Christoph Berg]

Re: Sebastian Andrzej Siewior 2019-12-18 <20191218225837.qttuxpwrbo5ukpr3@flow>
> > $ sudo -u clamav freshclam --verbose
> 
> what happens if you strip the sudo part? One of the first thing is to
> change to the clamav user (well so is my memory and the /var/…/clamav is
> owned by clamav so…)? However after I install sudo in my chroot and try
> this it still works :/

Now it just works, both with "sudo freshclam --verbose" and "sudo -u
clamav freshclam --verbose":

$ sudo freshclam --verbose
Thu Dec 19 10:00:32 2019 -> ClamAV update process started at Thu Dec 19 
10:00:32 2019
Thu Dec 19 10:00:32 2019 -> *Current working dir is /var/lib/clamav/
Thu Dec 19 10:00:32 2019 -> *Querying current.cvd.clamav.net
Thu Dec 19 10:00:32 2019 -> *TTL: 539
Thu Dec 19 10:00:32 2019 -> *fc_dns_query_update_info: Software version from 
DNS: 0.102.1
Thu Dec 19 10:00:32 2019 -> *Current working dir is /var/lib/clamav/
Thu Dec 19 10:00:32 2019 -> *check_for_new_database_version: No local copy of 
"daily" database.
Thu Dec 19 10:00:32 2019 -> *query_remote_database_version: daily.cvd version 
from DNS: 25667
Thu Dec 19 10:00:32 2019 -> daily database available for download (remote 
version: 25667)
Thu Dec 19 10:00:32 2019 -> *Retrieving https://database.clamav.net/daily.cvd
Thu Dec 19 10:00:32 2019 -> *downloadFile: Download source:  
https://database.clamav.net/daily.cvd
Thu Dec 19 10:00:32 2019 -> *downloadFile: Download destination: 
/var/lib/clamav/tmp/clamav-a0eebaf13c63bb204c5e5a77e26f717c.tmp
*   Trying 2606:4700::6810:db54:443...
* TCP_NODELAY set
* Connected to database.clamav.net (2606:4700::6810:db54) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; 
CN=ssl392509.cloudflaressl.com
*  start date: Aug 24 00:00:00 2019 GMT
*  expire date: Mar  1 23:59:59 2020 GMT
*  subjectAltName: host "database.clamav.net" matched cert's "*.clamav.net"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; 
CN=COMODO ECC Domain Validation Secure Server CA 2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c822a6d790)
> GET /daily.cvd HTTP/2
Host: database.clamav.net
user-agent: ClamAV/0.102.1 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
accept: */*
connection: close

* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 200 
< date: Thu, 19 Dec 2019 09:00:33 GMT
< content-type: application/octet-stream
< content-length: 55429776
< set-cookie: __cfduid=d808352f8029efc872822e310079600b81576746033; 
expires=Sat, 18-Jan-20 09:00:33 GMT; path=/; domain=.clamav.net; HttpOnly; 
SameSite=Lax
< last-modified: Wed, 18 Dec 2019 09:53:00 GMT
< etag: "5df9f6fc-34dca90"
< expires: Thu, 19 Dec 2019 13:00:33 GMT
< cache-control: public, max-age=14400
< cf-cache-status: HIT
< age: 3383
< accept-ranges: bytes
< strict-transport-security: max-age=15552000
< x-content-type-options: nosniff
< expect-ct: max-age=604800, 
report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct";
< server: cloudflare
< cf-ray: 54782fd3fa8ed45b-HAM
< 
Time: 3.5s, ETA; 0.0s [===>] 
52.86MiB/52.86MiB
* Connection #0 to host database.clamav.net left intact
Thu Dec 19 10:00:36 2019 -> *updatedb: Running g_cb_download_complete 
callback...
Thu Dec 19 10:00:36 2019 -> *download_complete_callback: Download complete for 
database : 
/var/lib/clamav/tmp/clamav-a0eebaf13c63bb204c5e5a77e26f717c.tmp-daily.cvd
Thu Dec 19 10:00:36 2019 -> *download_complete_callback:   
fc_context->bTestDatabases   : 1
Thu Dec 19 10:00:36 2019 -> *download_complete_callback:   
fc_context->bBytecodeEnabled : 1
Thu Dec 19 10:00:36 2019 -> Testing database: 
'/var/lib/clamav/tmp/clamav-a0eebaf13c63bb204c5e5a77e26f717c.tmp-daily.cvd' ...
Thu Dec 19 10:00:36 2019 -> *Loading signatures from 
/var/lib/clamav/tmp/clamav-a0eebaf13c63bb204c5e5a77e26f717c.tmp-daily.cvd
Thu Dec 19 10:00:40 2019 -> *Properly loaded 2061162 signatures from 
/var/lib/clamav/tmp/clamav-a0eebaf13c63bb204c5e5a77e26f717c.tmp-daily.cvd
Thu Dec 19 10:00:41 2019 -> Database test passed.
Thu Dec 19 10:00:41 2019 -> daily.cvd updated (version: 25667, sigs: 2061162, 
f-level: 63, builder: raynman)
Thu Dec 19 10:00:41 2019 -> *fc_update_database: daily.cvd updated.
Thu Dec 19 10:00:41 2019 -> *Current working dir is /var/lib/clamav/
Thu Dec 19 10:00:41 2019 -> *check_for_new_database_version: No local copy of 
"main" database.
Thu Dec 19 10:00:41 2019 -> *query_remote_database_version: main.cvd version 
from DNS: 59
Thu Dec 19 10:00:41 2019 -> main database 

Bug#939837: Bug#946987: r-cran-dqrng: Relationship to libpcg-cpp-dev and r-cran-sitmo

[Andreas Tille]

On Thu, Dec 19, 2019 at 08:39:36AM +0100, Ralf Stubner wrote:
> 
> A strong depends on sitmo would be fine as well. However, right now
> there is only
> a build-dependency on sitmo. Maybe the Depends was not generated because
> r-cran-sitmo seems to be missing from the archives?

Arrrghhh, yes, this is definitely the point.  I'll care for this.  Somehow
it sliped through.  Just uploaded to new.

Thanks a lot for that hint, Andreas.
 

-- 
http://fam-tille.de

Bug#880368: YAML::XS::Load expects utf8 octets, not perl's encoding; use slurp_raw

[Andrej Shadura]

On 15/12/2019 19:30, Dominique Dumont wrote:
> On Fri, 13 Dec 2019 14:23:46 +0100 Andrej Shadura 
>  wrote:
>> As a temporary workaround, I patched the locally used version to use
>> YAML::XS, but as I see you won?t accept this patch upstream. Is there a
>> solution that would satisfy both conditions of how having security
>> issues and supporting proper YAML? 
> 
> YAML::XS security issues has been fixed upstream. Now 
> Config::Model::Backend::Yaml uses YAML:XS
> 
> That said, YAML input and output is used in several places in libconfig-model-
> dpkg-perl. I fail to see your use case which involves debian/copyright in 
> YAML 
> format.
> 
> Could you provide more details on your use case?

In Apertis, we use scan-copyrights to verify the licenses for updates
coming from Debian are under licenses we know we want, and that there
are no new files with unclear terms. For that, we ship a YAML file under
debian/apertis/ in the format of fill-copyright-blanks and a
gitignore-formatted whitelist file. We also tell scan-copyrights to scan
all files, not just whitelisted extensions. For this to work, we read
our own config files, the config files in the normal scan-copyrights
location, and parse debian/copyright to determine the license of
debian/, and then merge them so that scan-copyrights uses the merged
configuration.

However, I was unable to make pyyaml to generate the YAML format
YAML::Tiny is always able to read, and apparently ruamel (judging by the
code) has the same issue.

-- 
Cheers,
  Andrej

Bug#946957: postgresql-common: pg_upgradecluster woe: postgres fails to restart after upgrade

[Christoph Berg]

Re: Julian Gilbey 2019-12-18 <20191218140411.ga8...@d-and-j.net>
> Running 'invoke-rc.d postgresql start' does not help: it still does
> not bring up the postgresql server.

Hi,

did you invoke pg_upgradecluster as 'postgres' user? In that case,
systemd doesn't get notified that a new cluster exists until
"systemctl daemon-reload" is run manually.

> The /lib/systemd/system/postgresql@.service files are identical on
> both machines.  And 'systemctl enable postgresql@.service' doesn't do
> anything, though 'systemctl enable postgresql@12-main.service' changes
> the status to enabled.  But even with that, 'invoke-rc.d postgresql
> start' doesn't start it.

What's in /etc/postgresql/12/main/start.conf ? It should be 'auto' to
be included in postgresql.service start.

start.conf is legacy from the old sysvinit days. It is now read by
/lib/systemd/system-generators/postgresql-generator.

Christoph

Bug#880368: YAML::XS::Load expects utf8 octets, not perl's encoding; use slurp_raw

[Dominique Dumont]

On Thursday, 19 December 2019 10:06:28 CET you wrote:
> However, I was unable to make pyyaml to generate the YAML format
> YAML::Tiny is always able to read, and apparently ruamel (judging by the
> code) has the same issue.

ok, I understand which instance of YAML::Tiny is causing trouble.

Since the security issue related to YAML::XS has been fixed (provided 
$YAML::XS::LoadBlessed is set to 0, which is not a problem for cme), I see no 
issue to switch libconfig-model-dpkg-perl to YAML::XS instead of YAML::Tiny.

Dear debian-perl team colleagues, do you foresee any problem with this change 
?

All the best

Dod

Bug#946998: python-django-split-settings: autopkgtest failure: No module named 'django_split_settings'

[Paul Gevers]

Source: python-django-split-settings
Version: 0.3.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

Your new package python-django-split-settings is using autopkgtest,
great. However, the test fails. I copied some of the output at the
bottom of this report. You're using autodep8 to trigger the test, but it
seems your package naming and Python module name isn't aligned for
autodep8. autodep8 recently acquired a new feature that enables you to
tell autode8 what the real module name is that should be tested [1].

Currently this regression is blocking the migration to testing [2], as
well as the fact that you'll need to upload a source-only package, as we
don't allow binaries built by maintainers to migrate to testing, but we
can't schedule binNMU's for arch all.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1]
https://manpages.debian.org/unstable/autodep8/autodep8.1.en.html#PYTHON_PACKAGES
[2] https://qa.debian.org/excuses.php?package=python-django-split-settings

https://ci.debian.net/data/autopkgtest/testing/arm64/p/python-django-split-settings/3473596/log.gz

autopkgtest [00:27:44]: test autodep8-python3: set -e ; for py in
$(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
with $py:" ; $py -c "import django_split_settings;
print(django_split_settings)" ; done
autopkgtest [00:27:44]: test autodep8-python3: [---
Testing with python3.7:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'django_split_settings'
autopkgtest [00:27:44]: test autodep8-python3: ---]



signature.asc
Description: OpenPGP digital signature

Bug#940985: dnsmasq: diff for NMU version 2.80-1.1

[Paul Gevers]

Control: tags 940985 + pending

Dear maintainer,

I've prepared an NMU for dnsmasq (versioned as 2.80-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u dnsmasq-2.80/debian/changelog dnsmasq-2.80/debian/changelog
--- dnsmasq-2.80/debian/changelog
+++ dnsmasq-2.80/debian/changelog
@@ -1,3 +1,12 @@
+dnsmasq (2.80-1.1) unstable; urgency=medium
+
+  [ Andreas Metzler ]
+  * Non-maintainer upload.
+  * Apply ab73a746a0d6fcac2e682c5548eeb87fb9c9c82e from upstream GIT to fix
+build error against nettle 3.5. Closes: #940985
+
+ -- Paul Gevers   Wed, 18 Dec 2019 21:23:49 +0100
+
 dnsmasq (2.80-1) unstable; urgency=low

* New upstream. (closes: #837602) (closes: #794640) (closes: #794636)
only in patch2:
unchanged:
--- dnsmasq-2.80.orig/src/crypto.c
+++ dnsmasq-2.80/src/crypto.c
@@ -275,6 +275,10 @@
   static struct ecc_point *key_256 = NULL, *key_384 = NULL;
   static mpz_t x, y;
   static struct dsa_signature *sig_struct;
+#if NETTLE_VERSION_MAJOR == 3 && NETTLE_VERSION_MINOR < 4
+#define nettle_get_secp_256r1() (&nettle_secp_256r1)
+#define nettle_get_secp_384r1() (&nettle_secp_384r1)
+#endif

   if (!sig_struct)
 {
@@ -294,7 +298,7 @@
  if (!(key_256 = whine_malloc(sizeof(struct ecc_point
return 0;

- nettle_ecc_point_init(key_256, &nettle_secp_256r1);
+ nettle_ecc_point_init(key_256, nettle_get_secp_256r1());
}

   key = key_256;
@@ -307,7 +311,7 @@
  if (!(key_384 = whine_malloc(sizeof(struct ecc_point
return 0;

- nettle_ecc_point_init(key_384, &nettle_secp_384r1);
+ nettle_ecc_point_init(key_384, nettle_get_secp_384r1());
}

   key = key_384;



signature.asc
Description: OpenPGP digital signature

Bug#946999: nm.debian.org: Adjust display on am overview

[Joerg Jaspert]

Package: nm.debian.org
Severity: normal

Dear Maintainer,

on a process of DD non-uploading -> DD uploading we don't need the
SC/DMUP and key check (previously done), so fine, the site doesn't list
it. But its confusing in the display as nothing indicates that it was
previously done.

So some subtle hint in the line like it blinking green/red, or maybe a
little dd_nu->dd_u hint, would be nice to have.

Thanks.

--
bye, Joerg

Bug#943943: getfem++ ftbfs

[Konstantinos Poulios]

the latest ftbfs on all architectures seems more like a python2to3
transition issue

/usr/bin/env: ‘python’: No such file or directory

Bug#946422: silx: autopkgtest regression: pocl error

[PICCA Frederic-Emmanuel]

With the silx.io import I have this

(sid_amd64-dchroot)picca@barriere:~$ 
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py 
pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close resident 
module'.
note: missing symbols in the kernel binary might be reported as 'file not 
found' errors.

without, I have this

(sid_amd64-dchroot)picca@barriere:~$ 
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
.Maximum valid workgroup size 2048 on device 
FThe gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
.The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
.The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
../home/picca/silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build/silx/opencl/test/test_linalg.py:69:
 FutureWarning: Using a non-tuple sequence for multidimensional indexing is 
deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this 
will be interpreted as an array index, `arr[np.array(seq)]`, which will result 
either in an error or a different result.
  gradient[slice_all] = np.diff(img, axis=d)
4096
...7 warnings generated.
/usr/lib/python3/dist-packages/pyopencl/__init__.py:235: CompilerWarning: 
Non-empty compiler output encountered. Set the environment variable 
PYOPENCL_COMPILER_OUTPUT=1 to see more.
  "to see more.", CompilerWarning)
..7 warnings generated.
..
==
FAIL: test_medfilt (silx.opencl.test.test_medfilt.TestMedianFilter)
--
Traceback (most recent call last):
  File 
"/home/picca/silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build/silx/opencl/test/test_medfilt.py",
 line 115, in test_medfilt
self.assertEqual(r.error, 0, 'Results are correct')
AssertionError: 3.4028235e+38 != 0 : Results are correct

--
Ran 217 tests in 175.525s

FAILED (failures=1, skipped=48)


I will run it with the PYOPENCL_COMPILEr_OUTPUT=1 to check that compiler warning


(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1 
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
.Maximum valid workgroup size 2048 on device 
FThe gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
.The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
.The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU. 
For more performances, it is advised to install gpyfft.
../home/picca/silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build/silx/opencl/test/test_linalg.py:69:
 FutureWarning: Using a non-tuple sequence for multidimensional indexing is 
deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this 
will be 

Bug#934467: Meson build system leads to missing library for linker (Was: Bug#934467: pbbam FTBFS with nocheck profile: cram3 missing)

[Phil Wyett]

On Thu, 2019-12-19 at 09:54 +0100, Andreas Tille wrote:
> Control: tags -1 pending
> 
> Hi,
> 
> I have a problem with latest version of pbbam[1] where upstream
> switched
> to meson as build system.  I get:
> 
> 
> ...
> ...  'src/25a6634@@pbbam@sha/  vcf_VcfWriter.cpp.o'
> 'src/25a6634@@pbbam@sha/pugixml_pugixml.cpp.o' -Wl,--as-needed -Wl,
> --no-undefined -shared -fPIC -Wl,--start-group -Wl,-
> soname,libpbbam.so.1.0.6 -g -O2 -fdebug-prefix-map=/build/pbbam-
> 1.0.6+  dfsg=. -fstack-protector-strong -Wformat -Werror=format-
> security -Wl,-z,relro -Wl,-z,now -pthread /usr/lib/x86_64-linux-
> gnu/libz.so /usr/lib/x86_64-linux-gnu/libhts.so -lpbcopper -Wl,--end-
> group
> /usr/bin/ld: cannot find -lpbcopper
> 
> 
> In the pbuilder chroot everything seems to be prepared to find
> libpbcopper:
> 
> root:/# find /usr/lib/x86_64-linux-gnu -name "*pbcopper*"
> /usr/lib/x86_64-linux-gnu/libpbcopper.so
> /usr/lib/x86_64-linux-gnu/pkgconfig/pbcopper.pc
> root:/# pkg-config --libs pbcopper
> -lpbcopper
> 
> 
> Am I missing something?
> 
> Kind regards
> 
>Andreas.
> 
> 
> [1] https://salsa.debian.org/med-team/pbbam
> 

Hi,

Basic build clean in a sid pbuilder created using:

sudo pbuilder create --debootstrapopts --variant=buildd

The only failure(s) I see are the post build tests:

# Ran 8 tests, 0 skipped, 6 failed.
make[1]: *** [debian/rules:22: override_dh_auto_test] Error 1
make[1]: Leaving directory '/build/pbbam-1.0.6+dfsg'
make: *** [debian/rules:13: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2
I: copying local configuration
E: Failed autobuilding of package

Regards

Phil

-- 

*** Playing the game for the games sake. ***

Twitter: @kathenasorg

IRC: kathenas



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

Bug#945931: haskell-crypto: Removal notice: broken and unmaintained

[Ilias Tsitsimpis]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: haskell-crypto -- ROM; broken and unmaintained
Control: severity -1 normal

Hi,

Please remove haskell-crypto from Debian. It is unmaintained and doesn't
work with the latest version of GHC.

Thanks,

-- 
Ilias

Bug#933928: Bug#936977: macsyfinder: Python2 removal in sid/bullseye

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/gem-pasteur/macsyfinder/issues/29

Upstream confirmed that a Python3 version is in progress.

-- 
http://fam-tille.de

Bug#947000: xfce4-weather-plugin: moonset time not shown on no-moonrise days

[Sergio Gelato]

Package: xfce4-weather-plugin
Version: 0.10.0-1
Tags: patch

A logic error causes the time the Moon sets not to be displayed if the Moon
doesn't also rise on the same day. Patch tested on 0.8.11, applies cleanly
to tip of upstream master branch.
Treat moon_never_rises and moon_never_sets independently of each other.

Unlike the Sun perhaps, the Moon may set but not rise on certain days.
Prior to this patch, the moonset time would be suppressed on no-moonrise days.
Index: xfce4-weather-plugin-0.8.11/panel-plugin/weather-summary.c
===
--- xfce4-weather-plugin-0.8.11.orig/panel-plugin/weather-summary.c	2019-03-24 13:08:29.0 +0100
+++ xfce4-weather-plugin-0.8.11/panel-plugin/weather-summary.c	2019-12-19 09:26:57.061048252 +0100
@@ -466,16 +466,17 @@
 value =
 g_strdup(_("\tMoonrise:\tThe moon never rises today.\n"));
 APPEND_TEXT_ITEM_REAL(value);
-} else if (data->current_astro->moon_never_sets) {
-value =
-g_strdup(_("\tMoonset:\tThe moon never sets today.\n"));
-APPEND_TEXT_ITEM_REAL(value);
 } else {
 moonrise = format_date(data->current_astro->moonrise, NULL, FALSE);
 value = g_strdup_printf(_("\tMoonrise:\t%s\n"), moonrise);
 g_free(moonrise);
 APPEND_TEXT_ITEM_REAL(value);
-
+}
+if (data->current_astro->moon_never_sets) {
+value =
+g_strdup(_("\tMoonset:\tThe moon never sets today.\n"));
+APPEND_TEXT_ITEM_REAL(value);
+} else {
 moonset = format_date(data->current_astro->moonset, NULL, FALSE);
 value = g_strdup_printf(_("\tMoonset:\t%s\n"), moonset);
 g_free(moonset);

Bug#947001: Tests segfaults (since the r-base-core update?)

[Sebastien Bacher]

Package: r-bioc-iranges
Version: 2.20.1-1

The autopkgtest started failing on a segfault
https://ci.debian.net/packages/r/r-bioc-iranges/unstable/amd64/

It seems to have started with the r-base update
-r-base-core 3.6.1-7
+r-base-core 3.6.1.20191206-1

Bug#925561: xfce4-weather-plugin uses deprecated API version

[Sergio Gelato]

control: fixed -1 0.10.0-1

My eyes had glazed over last night, I hadn't noticed that 0.10.0 was already
in sid. That supports the sunrise/2.0 API which this bug is about. Marking
as fixed.

> Alternatively, it may be enough to just replace /locationforecastlts/1.3
> with /locationforecast/1.9 in panel-plugin/weather.c and in README; will
> test this next.

Aside: I've tested this successfully. Not sure it's worth a bug report yet,
as the old API is deprecated but still supported.

Bug#872410: AHCI module not loaded when using preseed

[Jörg Schulz]

Still having this problem with buster and newer hardware "Intel NUC8".

Sometimes the ahci module gets loaded without any modification
of the installer (/bin/hw-detect).

When using the old hack
> d-i preseed/early_command string
>   sed -i '/^update-dev >.dev.null$/i udevadm control --reload'
>   /bin/hw-detect
the ahci module seems to be loaded reliably.


Jörg

Bug#947002: wxmaxima version 19.07.0 onwards cannot display properly exponents

[Stelios Loukadakis]

Package: wxmaxima
Version: 19.12.1-1
Severity: important

Dear Maintainer,

Since version 19.07.0 onwards wxmaxima cannot display the exponents returned
from Maxima. This issue does not apply when running maxima through a terminal
or emacs. For example a simple ilt(1/(s+1),s,t) simply displays "e" in the
wxmaxima session and nothing else. I've tried version 18.12.0-1 and was working
correctly giving e^-t for the answer. I've also tried building the latest
version from the git master branch but the same behaviour persists. Please
advice what additional information I could supply to assist with debugging this
issue. Thank you very match

wxmaxima bug_report() info

wxMaxima version: 19.12.1
using wxWidgets version: wxWidgets 3.0.4
Maxima version: 5.42.1
Maxima build date: 2019-07-22 04:02:52
Host type: x86_64-pc-linux-gnu
System type: BSD BSD NIL
Lisp implementation type: GNU Common Lisp (GCL)
Lisp implementation version: GCL 2.6.12
wxMaxima's idea of the directory layout is:
User configuration dir: /home/stelios/.maxima/
Help dir: /usr/share/doc/wxmaxima



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

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

Versions of packages wxmaxima depends on:
ii  libc6 2.29-3
ii  libgcc1   1:9.2.1-21
ii  libstdc++69.2.1-21
ii  libwxbase3.0-0v5  3.0.4+dfsg-15
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-15
ii  maxima5.42.1-1+b1

Versions of packages wxmaxima recommends:
ii  maxima-doc  5.42.1-1

Versions of packages wxmaxima suggests:
ii  fonts-jsmath 0.090709+0-3
ii  ibus-gtk31.5.21-3
ii  texlive-latex-extra  2019.20191208-1

-- no debconf information

Bug#947003: network-manager: Incorrect update of /etc/resolv.conf, bad search field

[Guillaume Clercin]

Package: network-manager
Version: 1.22.0-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 After upgrading network-manager from 1.20.8-1 to 1.22.0-1.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 DNS works if I fix /etc/resolv.conf until network-manager restart.

   * What was the outcome of this action?
 The file "/etc/resolv.conf" was incorrectly updated. Dot in search
 field are removed. Example: intellique.com => intelliquecom.

   * What outcome did you expect instead?
 As version 1.20.8-1, network-manager update correctly
 /etc/resolv.conf


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

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

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.16-2
ii  init-system-helpers1.57
ii  libaudit1  1:2.8.5-2+b1
ii  libbluetooth3  5.50-1+b1
ii  libc6  2.29-6
ii  libcurl3-gnutls7.67.0-2
ii  libglib2.0-0   2.62.3-2
ii  libgnutls303.6.11.1-2
ii  libjansson42.12-1
ii  libmm-glib01.10.4-0.1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.21-4
ii  libnm0 1.22.0-1
ii  libpam-systemd 244-3
ii  libpolkit-agent-1-00.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libpsl50.20.2-2
ii  libreadline8   8.0-3
ii  libselinux13.0-1
ii  libsystemd0244-3
ii  libteamdctl0   1.29-1
ii  libudev1   244-3
ii  libuuid1   2.34-0.1
ii  policykit-10.105-26
ii  udev   244-3
ii  wpasupplicant  2:2.9-3+b1

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1+b1
ii  iptables 1.8.4-1
ii  modemmanager 1.10.4-0.1
ii  ppp  2.4.7-2+4.1+b1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2
pn  libteam-utils

-- no debconf information

Bug#946422: silx: autopkgtest regression: pocl error

[PICCA Frederic-Emmanuel]

I decided to concentrate myself on one opencl test (addition)
So I deactivated all other test by commenting the test in 
silx/opencl/__init__.py

If I do not import silxs.io, this test works

(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1 
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
.Maximum valid workgroup size 2048 on device 

--
Ran 1 test in 0.030s

OK


If I add silxs.io, it fails

(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1 
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close resident 
module'.
note: missing symbols in the kernel binary might be reported as 'file not 
found' errors.
Aborted


so this test is ok in order to investigate this issue.

Bug#946829: Patch works!

[Marco Gaiarin]

I can confirm that patch works as expected.

Patch does not apply cleanly on my SA (3.4.2-1~deb9u2) but only for
cosmetic differences, attached a patch that wok on SA 3.4.2-1~deb9u2.


Thanks!

-- 
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
  Associazione ``La Nostra Famiglia''  http://www.lanostrafamiglia.it/
  Polo FVG   -   Via della Bontà, 7 - 33078   -   San Vito al Tagliamento (PN)
  marco.gaiarin(at)lanostrafamiglia.it   t +39-0434-842711   f +39-0434-842797

Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
  http://www.lanostrafamiglia.it/index.php/it/sostienici/5x1000
(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)
--- Greylisting.pm.orig	2019-12-19 11:27:35.535866138 +0100
+++ Greylisting.pm	2019-12-19 11:30:59.132703809 +0100
@@ -21,6 +21,7 @@
 
 use strict;
 use Mail::SpamAssassin::Plugin;
+use Mail::SpamAssassin::Util qw(untaint_var);
 use NetAddr::IP;
 use File::Path qw(mkpath);
 our @ISA = qw(Mail::SpamAssassin::Plugin);
@@ -71,9 +72,25 @@
 }
 Mail::SpamAssassin::Plugin::dbg("GREYLISTING: called function");
 
-$optionhash  =~ s/;/,/g;
+#$optionhash  =~ s/;/,/g;
 # This is safe, right? (users shouldn't be able to set it in their config)
-%option=eval $optionhash;
+#%option=eval $optionhash;
+
+# ... no, evaling random strings is not safe!!!
+# Ditch eval and parse hash string manually to maintain backwards compatibility
+$optionhash =~ s/^\s*\(\s*//;
+$optionhash =~ s/\s*\)\s*$//;
+foreach my $opt (split(/\s*;\s*/, $optionhash)) {
+   my @vals = split(/\s*=>\s*/, $opt, 2);
+   next unless defined $vals[1];
+   # Sanitize away quotes and any unneeded characters, then untaint
+   foreach (@vals) {
+   s/[^\w\/-]//gs;
+   $_ = untaint_var($_);
+   }
+   $option{$vals[0]} = $vals[1];
+}
+
 $self->{'rangreylisting'}=1;
 
 foreach my $reqoption (qw ( method greylistsecs dontgreylistthreshold

Bug#947004: Tests segfaults (since the r-base-core update?)

[Sebastien Bacher]

Package: r-bioc-s4vectors
Version: 0.24.1-1

The autopkgtest started failing on a segfault
https://ci.debian.net/packages/r/r-bioc-s4vectors/unstable/amd64/

It seems to have started with the r-base update
-r-base-core 3.6.1-7
+r-base-core 3.6.1.20191206-1

Bug#947005: nethack: buffer overflow when parsing config files

[Reiner Herrmann]

Source: nethack
Version: 3.6.0-1
Severity: grave
Tags: security
X-Debbugs-Cc: t...@security.debian.org

Hi,

a new version of NetHack has been released that fixes a privilege
escalation issue introduced in 3.6.0 [0] [1]:

> A buffer overflow issue exists when reading very long lines from a
> NetHack configuration file (usually named .nethackrc).
> 
> This vulnerability affects systems that have NetHack installed suid/sgid
> and shared systems that allow users to upload their own configuration
> files.
> 
> All users are urged to upgrade to NetHack 3.6.4 as soon as possible. 

As the Debian packages ship setgid binaries, I think they are affected by it.

At least these two commits look related:
 https://github.com/NetHack/NetHack/commit/f4a840a
 https://github.com/NetHack/NetHack/commit/f001de7

Regards,
  Reiner

[0] https://nethack.org/security/index.html
[1] https://nethack.org/v364/release.html


signature.asc
Description: PGP signature

Bug#946422: silx: autopkgtest regression: pocl error

[PICCA Frederic-Emmanuel]

looking in picca@sixs7:~/Debian/silx/silx/silx/opencl/test/test_addition.py

def setUp(self):
if ocl is None:
return
self.shape = 4096
self.data = numpy.random.random(self.shape).astype(numpy.float32)
self.d_array_img = pyopencl.array.to_device(self.queue, self.data)
self.d_array_5 = pyopencl.array.zeros_like(self.d_array_img) - 5
self.program = pyopencl.Program(self.ctx, 
get_opencl_code("addition")).build()

I found that commenting this line 

# self.d_array_5 = pyopencl.array.zeros_like(self.d_array_img) - 5

remove the pocl issue.


I remove everythings from the unit test.

@unittest.skipUnless(ocl, "pyopencl is missing")
def test_add(self):
self.assetTrue(True)


that means, only ther setUp and the tearDown are done.

with the line uncomment

(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1 
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close resident 
module'.
note: missing symbols in the kernel binary might be reported as 'file not 
found' errors.
Aborted

with the line commented

(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1 
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
.Maximum valid workgroup size 0 on device 

--
Ran 1 test in 0.013s

OK
Test suite succeeded


If now I do not import silx.io before there is no issue with or without the 
commented line

(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1 
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
.Maximum valid workgroup size 0 on device 

--
Ran 1 test in 0.021s

OK
Test suite succeeded



So what is going on when executing this line ???


self.d_array_5 = pyopencl.array.zeros_like(self.d_array_img) - 5

Bug#943515: linux-image-5.2.0-3-amd64: Cannot resume from suspend

[Julien Rabier]

Source: linux
Followup-For: Bug #943515

Hi,

I'm experiencing the same issue, only with Debian-provided kernels since
version 5.2. It's affecting all versions packaged since.
My workaround is to compile the kernel from upstream, which works as expected
without any issue.

My laptop is a Thinkpad X260. If I disable the security chip or set it to
Discrete TPM, the issue disappears.
So, to me, it seems like something in Debian packaging related to TPM is
causing this issue.


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

Kernel: Linux 5.4.4 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#946997: /usr/sbin/sshd: sshd doesn't restart after dying

[Colin Watson]

On Thu, Dec 19, 2019 at 09:38:11AM +0100, Xavier Bestel wrote:
> When sshd dies, it doesn't restart which makes the machine unreachable.
> E.g. try "sudo killall sshd", and voilà you can't use a headless machine 
> anymore.
> 
> Could this be fixed ?

I see from the information that reportbug attached that you're using
systemd.

As far as I can tell, systemd doesn't have a way to express this in the
particular example you gave.  killall will kill processes using SIGTERM
by default, and systemd considers that to be a deliberate administrative
action, i.e. "you meant to do that", so Restart=on-failure won't apply.
This seems correct to me.  However, if you kill sshd in an unclean way,
for example by sending SIGKILL, then systemd *will* restart it.

systemd.service(5) says:

If set to on-failure, the service will be restarted when the process
exits with a non-zero exit code, is terminated by a signal
(including on core dump, but excluding the aforementioned four
signals [SIGHUP, SIGINT, SIGTERM or SIGPIPE]), when an operation
(such as service reload) times out, and when the configured watchdog
timeout is triggered.

It feels like you filed a reduced bug report based on something more
complex happened in real life.  If so, could you share the more complex
version?

-- 
Colin Watson   [cjwat...@debian.org]

Bug#947006: libvirt: autopkgtest always fails and now started to time out regularly

[Paul Gevers]

Source: libvirt
Version: 5.6.0-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: timeout flaky

Dear maintainers,

Your package has an autopkgtest, great. However, I noticed that it
always fails, which nowadays is considered RC. However, on top of that,
with version 5.6.0-3 your package started to time out regularly on
ci.debian.net (after 2:50 h).

I wonder if the smoke-lxc test is suitable to test *inside* an lxc as
your using virsh. I am not enough into this, but it smells a bit like
you want an "isolation-machine" restriction for that test.

Can you please investigate the situation? Don't hesitate to ask for help
from the Debian CI team (in X-Debbugs-CC) if you need help solving this
issue.

To avoid wasting lots of time on the ci.debian.net infrastructure, I
have blacklisted your package. If needed, please ping me to try any
uploads you make that should fix the issue if you are unsure and don't
want to close this bug until verified.

Paul

https://ci.debian.net/data/autopkgtest/unstable/amd64/libv/libvirt/3677408/log.gz

autopkgtest [18:02:42]: test smoke-lxc: [---
+ virt-host-validate lxc
   LXC: Checking for Linux >= 2.6.26
 : PASS
   LXC: Checking for namespace ipc
 : PASS
   LXC: Checking for namespace mnt
 : PASS
   LXC: Checking for namespace pid
 : PASS
   LXC: Checking for namespace uts
 : PASS
   LXC: Checking for namespace net
 : PASS
   LXC: Checking for namespace user
 : PASS
   LXC: Checking for cgroup 'cpu' controller support
 : PASS
   LXC: Checking for cgroup 'cpuacct' controller support
 : PASS
   LXC: Checking for cgroup 'cpuset' controller support
 : PASS
   LXC: Checking for cgroup 'memory' controller support
 : PASS
   LXC: Checking for cgroup 'devices' controller support
 : PASS
   LXC: Checking for cgroup 'freezer' controller support
 : PASS
   LXC: Checking for cgroup 'blkio' controller support
 : PASS
   LXC: Checking if device /sys/fs/fuse/connections exists
 : PASS
+ virsh capabilities
autopkgtest [20:49:22]: ERROR: timed out on command "su -s /bin/bash
root -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.g55a6fi0/downtmp/build.mXC/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.g55a6fi0/downtmp/smoke-lxc-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.g55a6fi0/downtmp/smoke-lxc-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.g55a6fi0/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.g55a6fi0/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=2; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; export
AUTOPKGTEST_NORMAL_USER=debci; export ADT_NORMAL_USER=debci; chmod +x
/tmp/autopkgtest-lxc.g55a6fi0/downtmp/build.mXC/src/debian/tests/smoke-lxc;
touch /tmp/autopkgtest-lxc.g55a6fi0/downtmp/smoke-lxc-stdout
/tmp/autopkgtest-lxc.g55a6fi0/downtmp/smoke-lxc-stderr;
/tmp/autopkgtest-lxc.g55a6fi0/downtmp/build.mXC/src/debian/tests/smoke-lxc
2> >(tee -a /tmp/autopkgtest-lxc.g55a6fi0/downtmp/smoke-lxc-stderr >&2)
> >(tee -a /tmp/autopkgtest-lxc.g55a6fi0/downtmp/smoke-lxc-stdout);"
(kind: test)
autopkgtest [20:49:22]: test smoke-lxc: ---]



signature.asc
Description: OpenPGP digital signature

Bug#946988: coinor-dylp_1.10.4-1_source.changes REJECTED

[Sudip Mukherjee]

I have updated the changelog and Vcs and uploaded to mentors.
Here is the new changelog:

Changes since the last upload:

   * QA upload
   * Mark maintainer to QA.
   * Update to upstream 1.10.4
   * Remove Uploaders entry.
   * Update compat level to 12
   * Update Standards-Version to 4.4.1
   * Drop coinor-libdylp1-dbg package.
   * Enadle DOT in configuration and drop the patch.
   * Fix build-depends (Closes: #934251)
   * Update copyright
   * Remove build dependency on cdbs.
   * Rename package to coinor-libdylp1.
   * Add source to salsa and update Vcs links

In my previous comment I have given my reasoning to rename the package,
but if you feel it should stay as coinor-libdylp0, I will be very happy
to modify it.

--
Regards
Sudip

Bug#947007: buildah bud causes errors with Dockerfile

[Ryutaroh Matsumoto]

Package: buildah
Version: 1.10.1-5
Severity: normal

Dear Maintainer,

buildah bud does not work on a Dockerfile starting with
FROM alpine:3.10

I tried to create an image by
https://github.com/y-yu/new-year-letter/blob/master/docker/Dockerfile

The reason of buildah bud giving errors are three-fold:

(1) Lack of /etc/containers/registries.conf
I copied /usr/share/doc/buildah/examples/registries.conf in the
buildah Debian package.

(2) Lack of /etc/containers/policy.json
I copied policy.json from the golang-github-containers-image-dev 
Debian package.


(3) Lack of runc or crun
I manually installed crun and executed buildah --runtime /usr/bin/cron
The runc or crun package should be suggested/recommended by the
buildah Debian package.

Best regards, Ryutaroh Matsumoto


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

Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP.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 buildah depends on:
ii  libc6   2.29-3
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libglib2.0-02.62.3-2
ii  libgpgme11  1.13.1-1
ii  libostree-1-1   2019.6-1
ii  libseccomp2 2.4.2-2
ii  libselinux1 3.0-1
ii  uidmap  1:4.7-2

Versions of packages buildah recommends:
ii  fuse-overlayfs  0.7.2-1

buildah suggests no packages.

-- no debconf information

Bug#947007: buildah bud causes errors with Dockerfile

[Dmitry Smirnov]

Yes, thanks. Most of those issues are already fixed in the repository
and pending upload.


On Thursday, 19 December 2019 11:06:05 PM AEDT Ryutaroh Matsumoto wrote:
> The reason of buildah bud giving errors are three-fold:
> 
> (1) Lack of /etc/containers/registries.conf
> I copied /usr/share/doc/buildah/examples/registries.conf in the
> buildah Debian package.

That's how it is expected to be used.

Not everybody need Docker registries and having them by default
may not be a good idea...

Also this configuration file is shared with Podman which adds
to complexity...


> (2) Lack of /etc/containers/policy.json
> I copied policy.json from the golang-github-containers-image-dev
> Debian package.

https://salsa.debian.org/go-team/packages/golang-github-containers-buildah/commit/911ac680


> (3) Lack of runc or crun
> I manually installed crun and executed buildah --runtime /usr/bin/cron
> The runc or crun package should be suggested/recommended by the
> buildah Debian package.

https://salsa.debian.org/go-team/packages/golang-github-containers-buildah/commit/9b802644

Certainly fixes for 2 and 3 will be uploaded soon.
Not sure about 1 as I'm still thinking about how to resolve it elegantly
and what would be reasonable default.

-- 
Cheers,
 Dmitry Smirnov.

---

Freedom is the freedom to say that two plus two make four. If that is
granted, all else follows.
-- George Orwell


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

Bug#947008: sendxmpp: Formatting codes leak into the man page

[Alberto Luaces]

Package: sendxmpp
Version: 1.24-2
Severity: minor
Tags: patch upstream a11y

Some formatting characters in the POD are not interpreted in the
configuration section, so the user is mislead into thinking that each
value has to be prepended by "I<".

I have made a pull request in salsa, and a similar fix is also present
in upstream:

https://github.com/lhost/sendxmpp/commit/9186b8c49e54cf59ace4e5ddf52aa10b1a386fa5

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

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

Versions of packages sendxmpp depends on:
ii  libnet-xmpp-perl  1.05-1
ii  perl  5.30.0-9

sendxmpp recommends no packages.

sendxmpp suggests no packages.

-- no debconf information

Bug#947009: libssh-4 v9 breaks tmate when you have a ssh config that uses a custom port

[Alejandro Enrique Brito Monedero]

Package: libssh-4
Version: 0.9.3-2
Severity: important
Tags: upstream

Dear Maintainer,

   * What led up to the situation?
I have a custom ssh_config [1] that defines a not default ssh port.
When using tmate. Tmate cannot connect to ssh.tmate.io because libssh
version 9 I think doesn't parse correctly the ssh_config, it tries to use
the non default port instead of the port defined for *.io. In [2] I explain
how to reproduce the problem.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Comment the ssh port option in ~/.ssh/config
 Downgrade libssh to last stable version

   * What was the outcome of this action?
  Tmate worked

   * What outcome did you expect instead?
  That tmate using libssh-4 V9 worked



-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libssh-4 depends on:
ii  libc6 2.28-10
ii  libgssapi-krb5-2  1.17-3
ii  libssl1.1 1.1.1d-0+deb10u2
ii  zlib1g1:1.2.11.dfsg-1

libssh-4 recommends no packages.

libssh-4 suggests no packages.

-- no debconf information

[1] example ~/.ssh/config

Host *.io
Port 22

Host ssh.tmate.io
Port 22

Host *
Port 

[2] How to reproduce using docker so you don't pollute your machine.

# docker run --rm -ti debian:buster-slim bash # this will get you in a
container
# cd
# cat - >> /etc/apt/sources.list << END
> deb-src http://deb.debian.org/debian buster main
> deb-src http://security.debian.org/debian-security buster/updates main
> deb-src http://deb.debian.org/debian buster-updates main
> END
# apt-get update
# apt-get install -y git wget
# apt-get build-dep -y tmate
# mkdir ~/.ssh
# cat - > ~/.ssh/config << END
> Host ssh.tmate.io
>Port 22
>
> Host *
>Port 
> END
# git clone https://github.com/tmate-io/tmate.git
# cd tmate/
# git checkout 2.4.0
# ./autogen.sh
# ./configure --enable-debug
# make
# ./tmate -F # This works
To connect to the session locally, run: tmate -S /tmp/tmate-0/oSLG0w attach
Connecting to ssh.tmate.io...
web session read only: https://tmate.io/t/ro-8B3p4kSE5Qz7U58Dmze4Meg5Q
ssh session read only: ssh ro-8b3p4kse5qz7u58dmze4me...@lon1.tmate.io
web session: https://tmate.io/t/fzT2NfyY673DQ4PvsdMwLpSdE
ssh session: ssh fzt2nfyy673dq4pvsdmwlp...@lon1.tmate.io
# ldd ./tmate | grep libssh
   libssh.so.4 => /usr/lib/x86_64-linux-gnu/libssh.so.4 (0x7f8779e0)
# dpkg -l | grep libssh-4
ii  libssh-4:amd64   0.8.7-1 amd64
   tiny C SSH library (OpenSSL flavor)
# apt-get purge -y libssh-4
# wget "
http://ftp.us.debian.org/debian/pool/main/libs/libssh/libssh-4_0.9.3-2_amd64.deb
"
# dpkg -i libssh-4_0.9.3-2_amd64.deb
# ./tmate -F # this doesn't work
./tmate -F
To connect to the session locally, run: tmate -S /tmp/tmate-0/OpKj7B attach
Connecting to ssh.tmate.io...
Error connecting: Connection refused
Reconnecting...
Connecting to ssh.tmate.io...
Error connecting: Connection refused
Reconnecting...

-- 

Cheers

Alejandro Brito Monedero
Responsable: ALEA SOLUCIONES, S.L.; Dirección: Av de la Albufera, 321, 5ª
planta, 28031, Madrid; Teléfono: +34 91 187 9000; E-Mail:
r...@alea-soluciones.com

En ALEA SOLUCIONES, S.L. tratamos su dirección de correo electrónico, así
como el resto de la información y datos personales que nos facilite, con la
finalidad de llevar a cabo la gestión y el archivo de las comunicaciones y
sus adjuntos por motivos de seguridad, la inclusión de los datos en la
agenda de contactos y el envío de comunicaciones profesiones por vía
electrónica. Los datos proporcionados se conservarán mientras se mantenga
la relación comercial. Los datos no se cederán a terceros salvo en los
casos en que exista una obligación legal. Usted tiene derecho a obtener
confirmación sobre si en ALEA SOLUCIONES, S.L. estamos tratando sus datos
personales por tanto tiene derecho a acceder a sus datos personales,
rectificar los datos inexactos o solicitar su supresión cuando los datos ya
no sean necesarios. Asimismo, podrá oponerse al tratamiento de sus datos,
solicitar la limitación al tratamiento y la portabilidad de sus datos.  Si
considera que sus datos personales no han sido tratados conforme a la
normativa, puede contactar con r...@alea-soluciones.com. Igualmente podrá
presentar una reclamación ante la Agencia Española de Protección de Datos,
especialmente cuando no haya obtenido la satisfacción en el ejercicio de
sus derechos, a través de la sede electrónica en www.aepd.es.

-- o --

Controller: ALEA SOLUCIONES, S.L.; Address: Av de la Albufera, 321, 5th
Floor, 28031, Madrid; telephone: +34 91 187 9000; e-mail:
r.

Bug#880368: YAML::XS::Load expects utf8 octets, not perl's encoding; use slurp_raw

[gregor herrmann]

On Thu, 19 Dec 2019 10:18:12 +0100, Dominique Dumont wrote:

> Since the security issue related to YAML::XS has been fixed (provided 
> $YAML::XS::LoadBlessed is set to 0, which is not a problem for cme), I see no 
> issue to switch libconfig-model-dpkg-perl to YAML::XS instead of YAML::Tiny.
> 
> Dear debian-perl team colleagues, do you foresee any problem with this change 
> ?

No, sounds good.
(And we're using YAML::XS in other places as well, so at least for us
it's not even a new dependency.)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Red Hot Chili Peppers: Road Trippin'


signature.asc
Description: Digital Signature

Bug#946422: silx: autopkgtest regression: pocl error

[Andreas Beckmann]

On 19/12/2019 11.59, PICCA Frederic-Emmanuel wrote:
> I found that commenting this line 
> 
> # self.d_array_5 = pyopencl.array.zeros_like(self.d_array_img) - 5
> 
> remove the pocl issue.

I think that's a red herring. Without that line I get python errors because 
d_array_5 is missing.

That's the backtrace I get in gdb for the original failure:

(gdb) bt
#0  0x77e41081 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x77e2c535 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x7fffe67c46d1 in pocl_check_kernel_dlhandle_cache 
(cmd=cmd@entry=0x13e1bb0, initial_refcount=initial_refcount@entry=1) at 
./lib/CL/devices/common.c:1097
#3  0x7fffe67ca327 in pocl_pthread_prepare_kernel (cmd=0x13e1bb0, 
data=0x1335df0) at ./lib/CL/devices/pthread/pthread_scheduler.c:413
#4  pocl_pthread_exec_command (td=0x133cb80, cmd=0x13e1bb0) at 
./lib/CL/devices/pthread/pthread_scheduler.c:450
#5  pocl_pthread_driver_thread (p=) at 
./lib/CL/devices/pthread/pthread_scheduler.c:496
#6  0x77deefb7 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#7  0x77f012df in clone () from /lib/x86_64-linux-gnu/libc.so.6

we are failing in pocl_check_kernel_dlhandle_cache() here:

if (ci->dlhandle == NULL || ci->wg == NULL || dl_error != NULL)
  { 
POCL_ABORT (
"pocl error: lt_dlopen(\"%s\") or lt_dlsym() failed with '%s'.\n"
"note: missing symbols in the kernel binary might be"
" reported as 'file not found' errors.\n",
module_fn, dl_error);
  }

(gdb) print *ci
$11 = {hash = "p\374|\271.\364b0\217\036\361?\271\327~\372", local_wgs = {32, 
1, 1}, wg = 0x0, dlhandle = 0x7fff890010f0, next = 0x0, prev = 0x0, ref_count = 
1}
(gdb) print dl_error
$15 = 0x753433e0 "can't close resident module"

I'm suspecting openmpi (that gets loaded by the io import) somehow messes up 
some state,
causing the lt_*() failures.

Andreas

Bug#946984: yade: Ships python3.8 scripts, without any python3 or python3.8 deps

[Dimitri John Ledkov]

tag 946984 pending
thanks

On Thu, 19 Dec 2019 07:33:52 +0100 Anton Gladky  wrote:
> Hi,
>
> it is already done and will be uploaded tonight.

Great! Thanks.

> The problem is that it should go through NEW-queue.
>

Indeed it will must do that =/ I guess we can live without yade in
testing for a little while

Bug#946422: silx: autopkgtest regression: pocl error

[Graham Inggs]

On Thu, 19 Dec 2019 at 15:17, Andreas Beckmann  wrote:
> I'm suspecting openmpi (that gets loaded by the io import) somehow messes up 
> some state,
> causing the lt_*() failures.

I wonder if this is related to #946986 ?

Bug#947010: O: python-h2 -- Pure-Python HTTP/2 State-Machine based protocol implementation in python

[Sebastien Delafond]

Package: wnpp
Severity: normal

I intend to orphan the python-h2 package.

The package description is:
 This module contains a pure-Python HTTP/2 of a HTTP/2 protocol
 stack. It’s written from the ground up to be embeddable in whatever
 program you choose to use, ensuring that you can speak HTTP/2
 regardless of your programming paradigm.
 This module contains a pure-Python HTTP/2 of a HTTP/2 protocol
 stack. It’s written from the ground up to be embeddable in whatever
 program you choose to use, ensuring that you can speak HTTP/2
 regardless of your programming paradigm.

Bug#947012: mmdebstrap: Extended attributes are lost in tarball

[Benjamin Drung]

Package: mmdebstrap
Version: 0.5.1-3
Severity: normal
Tags: patch upstream

Hi,

When specifying a tarball as output format, the extended attributes are
lost. This leads to programs like ping fail to run as normal user.

```
mmdebstrap --include=iputils-ping buster buster.tar
mkdir root
sudo tar --xattrs --xattrs-include='*' -C root -xf buster.tar
getcap root/bin/ping
```

Therefore the attached patch will preserve the extended attributes when
generating the tarball. Then getcap will show:

```
root/bin/ping = cap_net_raw+ep
```

-- 
Benjamin Drung

System Developer and Debian & Ubuntu Developer
Platform Engineering Compute (IONOS Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet
>From 0e38f515d96a927d84262dc38df19f41920468d8 Mon Sep 17 00:00:00 2001
From: Benjamin Drung 
Date: Tue, 10 Dec 2019 15:00:12 +0100
Subject: [PATCH] Preserve extended attributes in tarball

When specifying a tarball as output format, the extended attributes are
lost. This leads to programs like ping fail to run as normal user.

```
mmdebstrap --include=iputils-ping buster buster.tar
mkdir root
sudo tar --xattrs --xattrs-include='*' -C root -xf buster.tar
getcap root/bin/ping
```

Therefore preserve the extended attributes when generating the tarball.
Then getcap will show:

```
root/bin/ping = cap_net_raw+ep
```

Signed-off-by: Benjamin Drung 
---
 mmdebstrap | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mmdebstrap b/mmdebstrap
index b9b7af5..9996f16 100755
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -2836,7 +2836,7 @@ sub main() {
 }
 
 my $exitstatus = 0;
-my @taropts = ('--sort=name', "--mtime=\@$mtime", '--clamp-mtime', 
'--numeric-owner', '--one-file-system', '-c', '--exclude=./dev');
+my @taropts = ('--sort=name', "--mtime=\@$mtime", '--clamp-mtime', 
'--numeric-owner', '--one-file-system', '--xattrs', '-c', '--exclude=./dev');
 
 # disable signals so that we can fork and change behaviour of the signal
 # handler in the parent and child without getting interrupted
-- 
2.20.1

Bug#947011: O: python-hpack -- Pure-Python HTTP/2 header encoding (HPACK)

[Sebastien Delafond]

Package: wnpp
Severity: normal

I intend to orphan the python-hpack package.

The package description is:
 This module contains a pure-Python HTTP/2 header encoding (HPACK) logic
 for use in Python programs that implement HTTP/2. It also contains a
 compatibility layer that automatically enables the use of nghttp2 if
 it’s available.
 This module contains a pure-Python HTTP/2 header encoding (HPACK) logic
 for use in Python programs that implement HTTP/2. It also contains a
 compatibility layer that automatically enables the use of nghttp2 if
 it’s available.

Bug#947013: O: python-hyperframe -- Pure-Python HTTP/2 framing code

[Sebastien Delafond]

Package: wnpp
Severity: normal

I intend to orphan the python-hyperframe package.

The package description is:
 This module contains a pure-Python codebase that is capable of
 decoding a binary stream into HTTP/2 frames.
 This module contains a pure-Python codebase that is capable of
 decoding a binary stream into HTTP/2 frames.
 This module contains a pure-Python codebase that is capable of
 decoding a binary stream into HTTP/2 frames.

Bug#947014: O: python-h11 -- Pure-Python, bring-your-own-I/O implementation of HTTP/1.1 (Python 3)

[Sebastien Delafond]

Package: wnpp
Severity: normal

I intend to orphan the python-h11 package.

The package description is:
 HTTP/1.1 library written from scratch in Python, heavily inspired by
 hyper-h2.
 .
 It's a "bring-your-own-I/O" library; h11 contains no IO code
 whatsoever. This means you can hook h11 up to your favorite network
 API, and that could be anything you want: synchronous, threaded,
 asynchronous, or your own implementation of RFC 6214 – h11 won’t
 judge you.
 .
 This is the Python 3 package.

Bug#947016: O: python-kaitaistruct -- Kaitai Struct declarative parser generator for binary data

[Sebastien Delafond]

Package: wnpp
Severity: normal

I intend to orphan the python-kaitaistruct package.

The package description is:
 This library implements Kaitai Struct API for Python.
 .
 Kaitai Struct is a declarative language used for describe various
 binary data structures, laid out in files or in memory: i.e. binary
 file formats, network stream packet formats, etc.
 .
 It is similar to Python's construct and Construct3, but it is
 language-agnostic. The format description is done in YAML-based .ksy
 format, which then can be compiled into a wide range of target
 languages.

Bug#947015: O: python-kaptan -- Python configuration manager in various formats

[Sebastien Delafond]

Package: wnpp
Severity: normal

I intend to orphan the python-kaptan package.

The package description is:
 Configuration manager that allows users to transparently access
 configuration data stored in various formats (INI, JSON, YAML, dict,
 file).

Bug#947018: O: python-jsbeautifier -- JavaScript unobfuscator and beautifier (python2)

[Sebastien Delafond]

Package: wnpp
Severity: normal

I intend to orphan the python-jsbeautifier package.

The package description is:
 Beautify, unpack or deobfuscate JavaScript, leveraging popular online
 obfuscators.
 .
 This is the Python 2 version of the package.
 Beautify, unpack or deobfuscate JavaScript, leveraging popular online
 obfuscators.
 .
 This is the Python 2 version of the package.

Bug#947017: RFP: org-drill -- emacs self-learning mode with spaced repetition

[Thomas Koch]

Package: wnpp
X-Debbugs-Cc: tho...@koch.ro, debian-emac...@lists.debian.org, Phillip Lord 


org-drill was bundled as contrib in org-mode but needed an update and a new 
maintainer.
It has now a new maintainer
https://lists.gnu.org/archive/html/emacs-orgmode/2019-06/msg00191.html
is on melpa
https://melpa.org/#/org-drill
and has been removed from org-mode.
https://code.orgmode.org/bzg/org-mode/commit/2c8e8b4a186473729b983318c2befc1732127165

(BTW, once this is done: https://melpa.org/#/org-drill-table )

* Package name: org-drill
  Version : 2.7
  Upstream Author : Paul Sexton , Phillip Lord 

* URL : https://gitlab.com/phillord/org-drill
* License : GPL-3+
  Programming Lang: elisp
  Description : emacs self-learning mode with spaced repetition

Org-Drill is an extension for Emacs' org-mode. Org-Drill uses a spaced
repetition algorithm to conduct interactive “drill sessions”, using org files
as sources of facts to be memorised. The material to be remembered is
presented in random order. The self-rated recall of each item is used to
schedule the item for later revision.

Bug#947019: O: python-pyperclip -- Cross-platform clipboard module for Python

[Sebastien Delafond]

Package: wnpp
Severity: normal

I intend to orphan the python-pyperclip package.

The package description is:
 This module is a cross-platform Python module for copy and paste clipboard
 functions.
 .
 It currently only handles plaintext.
 This module is a cross-platform Python module for copy and paste clipboard
 functions. Currently only handles plaintext.

Bug#947020: O: python-typing -- Backport of the standard 3.5 library typing module

[Sebastien Delafond]

Package: wnpp
Severity: normal

I intend to orphan the python-typing package.

The package description is:
 Typing defines a standard notation for Python function and variable
 type annotations. The notation can be used for documenting code in a
 concise, standard format, and it has been designed to also be used by
 static and runtime type checkers, static analyzers, IDEs and other
 tools.
 Typing defines a standard notation for Python function and variable
 type annotations. The notation can be used for documenting code in a
 concise, standard format, and it has been designed to also be used by
 static and runtime type checkers, static analyzers, IDEs and other
 tools.

Bug#947021: linux-image-4.19.0-6-amd64: root can lift kernel lockdown

[Niklas Sombert]

Package: src:linux
Version: 4.19.67-2+deb10u2
Severity: normal

Dear Maintainer,

echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even though it 
shouldn't.

Kernel lockdown is meant to create a barrier between root and the kernel that 
can only be broken with physical access to the system.
But a bug in 
debian/patches/features/all/lockdown/0002-Add-a-SysRq-option-to-lift-kernel-lockdown.patch
 allows root to easily circumvent this security measure:

vagrant@buster:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 
root=UUID=b9ffc3d1-86b2-4a2c-a8be-f2b2f4aa4cb5 ro net.ifnames=0 quiet lockdown
vagrant@buster:~$ sudo dmesg | grep locked
[0.00] Kernel is locked down from command line; see 
https://wiki.debian.org/SecureBoot
vagrant@buster:~$ sudo sysctl kernel.sysrq=1
kernel.sysrq = 1
vagrant@buster:~$ sudo sh -c "echo x > /proc/sysrq-trigger"
vagrant@buster:~$ sudo dmesg | tail
[3.050592] vboxvideo :00:02.0: fb0: vboxdrmfb frame buffer device
[3.068268] [drm] Initialized vboxvideo 1.0.0 20130823 for :00:02.0 on 
minor 0
[3.183323] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[3.223529] Adding 1045500k swap on /dev/sda5.  Priority:-2 extents:1 
across:1045500k FS
[5.200670] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: 
RX
[5.201533] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   42.660726] sysrq: SysRq : 
[   42.660728] This sysrq operation is disabled from userspace.
[   42.660797] Disabling Secure Boot restrictions
[   42.660830] Lifting lockdown

I already reported this bug to Ubuntu at 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851380
but it also affects Debian. (There's a bit more context and a patch in that bug 
report.)

Looking at the patch on salsa I think that this bug doesn't just exist in 
Buster, but that's the version I used to test it.

Best regards,
Niklas Sombert

-- Package-specific info:
** Version:
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 
root=UUID=b9ffc3d1-86b2-4a2c-a8be-f2b2f4aa4cb5 ro net.ifnames=0 quiet lockdown

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[1.080252] Loading compiled-in X.509 certificates
[1.123039] Loaded X.509 cert 'Debian Secure Boot CA: 
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[1.123062] Loaded X.509 cert 'Debian Secure Boot Signer: 00a7468def'
[1.123095] zswap: loaded using pool lzo/zbud
[1.123659] AppArmor: AppArmor sha1 policy hashing enabled
[1.124095] rtc_cmos rtc_cmos: setting system clock to 2019-12-19 14:23:08 
UTC (1576765388)
[1.124123] Lockdown: Hibernation is restricted; see 
https://wiki.debian.org/SecureBoot
[1.125951] Freeing unused kernel image memory: 1584K
[1.148274] Write protecting the kernel read-only data: 16384k
[1.150291] Freeing unused kernel image memory: 2028K
[1.150967] Freeing unused kernel image memory: 772K
[1.165327] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[1.165329] x86/mm: Checking user space page tables
[1.173508] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[1.173511] Run /init as init process
[1.274579] piix4_smbus :00:07.0: SMBus Host Controller at 0x4100, 
revision 0
[1.280038] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[1.280040] e1000: Copyright (c) 1999-2006 Intel Corporation.
[1.288044] SCSI subsystem initialized
[1.297356] FDC 0 is an 82078.
[1.306225] cryptd: max_cpu_qlen set to 1000
[1.317316] libata version 3.00 loaded.
[1.323785] ahci :00:0d.0: version 3.0
[1.324687] ahci :00:0d.0: SSS flag set, parallel bus scan disabled
[1.324882] ahci :00:0d.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 
impl SATA mode
[1.324884] ahci :00:0d.0: flags: 64bit ncq stag only ccc 
[1.325243] scsi host0: ahci
[1.325387] ata1: SATA max UDMA/133 abar m8192@0xf0804000 port 0xf0804100 
irq 21
[1.336127] AVX2 version of gcm_enc/dec engaged.
[1.336128] AES CTR mode by8 optimization enabled
[1.553903] input: ImExPS/2 Generic Explorer Mouse as 
/devices/platform/i8042/serio1/input/input2
[1.647971] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[1.648249] ata1.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133
[1.648253] ata1.00: 41533440 sectors, multi 128: LBA48 NCQ (depth 32)
[1.649141] ata1.00: configured for UDMA/133
[1.652372] scsi 0:0:0:0: Direct-Access ATA  VBOX HARDDISK1.0  
PQ: 0 ANSI: 5
[1.661577] sd 0:0:0:0: [sda] 41533440 512-byte logical blocks: (21.3 
GB/19.8 GiB)
[1.661585] sd 0:0:0:0: [sda] Write Protect is off
[1.661587] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[1.661596] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[1.662

Bug#946913: should flatpak -> xdg-desktop-portal be downgraded to Recommends?

[Simon McVittie]

Control: clone -1 -2
Control: retitle -2 should flatpak -> xdg-desktop-portal be downgraded to 
Recommends?
Control: reassign -2 flatpak
Control: severity -2 wishlist

On Wed, 18 Dec 2019 at 17:57:25 +0100, Martin F Krafft wrote:
> I only use Flatpak for us.zoom.Zoom, which works just fine
> without the process. So it's actually more a Recommends than a Depends.

Strictly speaking yes. I think this is close to the borderline between
Depends and Recommends; breaking this off into a separate bug while I
think about which side of the line it ought to be on.

The reason I originally added a hard dependency from flatpak on x-d-p is
that the documents portal, which used to be part of flatpak, was moved
into x-d-p - so not depending on x-d-p would have been a functional
regression. Before that, the dependency chain was:
flatpak Recommends x-d-p-gtk | x-d-p-backend, x-d-p-gtk Depends x-d-p.

Flatpak *can* do useful things without x-d-p, but it will break most apps'
expectations - it provides an "API" to apps, and x-d-p is part of that
"API". As time goes on and Flatpak apps (hopefully) get better-sandboxed,
x-d-p will become increasingly necessary.

Zoom is (probably) unaffected by absence of x-d-p because all of the
permissions it requires happen to be things that are currently done
"statically" by Flatpak, rather than going through a portal. However,
perhaps relatedly, its permissions are worryingly broad for proprietary
software: it has full access to the home directory, devices and
PulseAudio.

Ideally it would either use xdg-desktop-portal to mediate access to files,
or use --persist to have its own fake home directory, or both; and ideally
it would use x-d-p's webcam portal instead of devices=all, but that won't
work until Pipewire is widespread (and would also require code changes
in Zoom, which leaves you at the mercy of proprietary software updates).

The other category of applications I can immediately think of that might
be OK without x-d-p is simple, self-contained games that confine all their
filesystem accesses to one directory and don't open files interactively
(for example OpenArena, but not anything that has a File->Open...-style
interface for loading levels or mods or whatever).

smcv

Bug#785356: call me

[Tonita McCalment]

I am Tonita, I need your help.

Bug#940491: python3-meep-Script blocks apt-get installation operations in upgraded experimental debian

[Claus Fütterer]

Package: python3-meep
Version: 1.12.0-2
Followup-For: Bug #940491

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
installation of meep and python3-meep

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I installed the named packages with synaptic and later with apt
   * What was the outcome of this action?

synaptic:
E: python3-meep: »installiertes python3-meep-Skript des Paketes post-
installation«-Unterprozess gab den Fehlerwert 1 zurück
English: installed python3-meep-script of package post-installation sup-process
returned error 1

now I cannot install or remove any software but get instead this error message

Further:

root@kugel:~# apt-get upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr
benötigt:
  freecad-runtime libfuse3-3 python3-pyside2.qtsvg python3-pyside2.qtuitools
python3-pyside2.qtxml python3-pyside2uic
Verwenden Sie »apt autoremove«, um sie zu entfernen.
Die folgenden Pakete sind zurückgehalten worden: (English: The following
packages are hold back)
  freecad gnome-dictionary libequinox-osgi-java libllvm9 libllvm9:i386 phonon-
backend-gstreamer-common python-sip quota sshfs
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 9 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n]
python3-meep (1.12.0-2) wird eingerichtet ...
dpkg-query: Paket »python-meep« ist nicht installiert  (English: ...is not
installed)
Verwenden Sie dpkg --contents (= dpkg-deb --contents) zum Auflisten von
Archivinhalten.
Traceback (most recent call last):
  File "/usr/bin/pycompile", line 289, in 
main()
  File "/usr/bin/pycompile", line 262, in main
options.force, options.optimize, e_patterns)
  File "/usr/bin/pycompile", line 154, in compile
for fn, versions_to_compile in filter_files(files, e_patterns, versions):
  File "/usr/bin/pycompile", line 109, in filter_files
for fn in files:
  File "/usr/share/python/debpython/files.py", line 77, in filter_out_ext
for fn in files:
  File "/usr/share/python/debpython/namespace.py", line 77, in
add_namespace_files
for fn in files:
  File "/usr/share/python/debpython/files.py", line 69, in filter_public
for fn in files:
  File "/usr/share/python/debpython/files.py", line 53, in from_package
raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of python-meep
dpkg: Fehler beim Bearbeiten des Paketes python3-meep (--configure):
 »installiertes python3-meep-Skript des Paketes post-installation«-Unterprozess
gab den Fehlerwert 1 zurück
Trigger für libc-bin (2.29-6) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
 python3-meep
E: Sub-process /usr/bin/dpkg returned an error code (1)


   * What outcome did you expect instead?
no errors when installing or removing

*** End of the template - remove these template lines ***



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

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

Versions of packages python3-meep depends on:
ii  libatlas3-base [liblapack.so.3]3.10.3-9
ii  libblas3 [libblas.so.3]3.9.0-1
ii  libc6  2.29-6
ii  libctl74.4.0-3
ii  libfftw3-double3   3.3.8-2
ii  libgcc11:9.2.1-21
ii  liblapack3 [liblapack.so.3]3.9.0-1
pn  libmeep17  
ii  libopenblas0-pthread [liblapack.so.3]  0.3.7+ds-7
ii  libstdc++6 9.2.1-21
ii  python33.7.5-3
ii  python3-numpy  1:1.17.4-4

python3-meep recommends no packages.

python3-meep suggests no packages.

-- no debconf information

Bug#945773: Fwd: Bug#946965: RFS: sendmail/8.15.2-16 [QA] -- powerful, efficient, and scalable Mail Transport Agent (metapackage)

[David Bürgin]

I have created a QA upload with this patch and one for #945797, and
have sent a request for sponsorship to debian-mentors. If anyone here
wants to sponsor, I’d be very glad.

Cheers,
David


 Forwarded Message 
Subject: Bug#946965: RFS: sendmail/8.15.2-16 [QA] -- powerful, efficient, and 
scalable Mail Transport Agent (metapackage)
Resent-Date: Wed, 18 Dec 2019 15:51:01 +
Resent-From: David Bürgin 
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Mentors 
Date: Wed, 18 Dec 2019 16:47:29 +0100
From: David Bürgin 
Reply-To: David Bürgin , 946...@bugs.debian.org
To: sub...@bugs.debian.org

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a QA upload for package "sendmail"

 * Package name: sendmail
   Version : 8.15.2-16
   Upstream Author : Sendmail, Inc.
 * URL : http://www.sendmail.org
 * License : other-Sendmail
 * Vcs : https://salsa.debian.org/debian/sendmail
   Section : mail

It builds those binary packages:

  sendmail-bin - powerful, efficient, and scalable Mail Transport Agent
  rmail - MTA->UUCP remote mail handler
  sensible-mda - Mail Delivery Agent wrapper
  libmilter1.0.1 - Sendmail Mail Filter API (Milter)
  libmilter-dev - Sendmail Mail Filter API (Milter) (development files)
  sendmail-doc - powerful, efficient, and scalable Mail Transport Agent 
(documentation)
  sendmail - powerful, efficient, and scalable Mail Transport Agent 
(metapackage)
  sendmail-base - powerful, efficient, and scalable Mail Transport Agent (arch 
independent files)
  sendmail-cf - powerful, efficient, and scalable Mail Transport Agent (config 
macros)

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

  https://mentors.debian.net/package/sendmail

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sendmail/sendmail_8.15.2-16.dsc

Changes since the last upload:

   * QA upload.
   * libmilter-dev: Add patch that changes the log level of the log message on
 socket close to DEBUG.  (Closes: #945773)
   * libmilter-dev: Add milter.pc metadata file to enable pkg-config support.
 (Closes: #945797)

Regarding #945797, please ignore my previous messages over at the BTS. I
have now learnt Debian packaging basics and have studied the sendmail
build, so I’m now in a better position to propose a patch. I think the
solution here for including a new milter.pc file is quite
straightforward.

Unfortunately there is a bit of noise, because I had to execute the
target refresh-debian-configure in debian/rules to have milter.pc.in
processed properly and included in the build. But the two changes
themselves are small.

Thank you!

Bug#947023: harden-doc: Please ship single page plain text version

[Roberto C. Sanchez]

Package: harden-doc
Version: 3.19
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It would be very nice if the single page plain text version of "Securing
Debian Manual" was shipped alongside the current HTML version.

Regards,

- -Roberto

- -- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEIYZ1DR4ae5UL01q7ldFmTdL1kUIFAl37lc0ACgkQldFmTdL1
kUKt9hAAhGabNJLW3WEovX2TglTB1MzocQOT5EbkPpht3z9elDIbSB/bVfy7STlm
kMZTYFahsxa1MOu6CJdPgd420Gov8IBRAUSqix+tHzhakmx8iivRI70l7eXugz5B
Cvztd8DByxdw551S2GLE1ObZzifofvyWbZEO6pwHnDza4JObahy3P+IeORwqEt0L
Z4+exo+GrtL9JZ/QPKo8cgYnGEQoFcrjGrY/LqjYEdCuXNvpgIkHSJwd0I5J88i7
dVYsP87ibjC9z1efO7avALX44kqDgI0o093Y6UY5SXS5aMEX84AWGlLDkX9pSED9
P0iraB1DO/o+xRWywN8N6RIwZfHf7TtuxePADGRM8b/KoZxvRPtCvotz5Ies/W8R
0mlqNEfJ39NI/jn/t3rsl7BDhnMFYjxyZXVrFAamLaFhbvI0KOTG0yw4wNGnHTcR
4opMz6gAa72D+j8AXk6hQg2L5S4RHN46KVP3K2fvcbLN8Y/Nf+/bNmscP0dQAAxu
CVxIwUOJV6JLpPUgPqRliRhPO3Qxb5aP3sBV84FmHCGtKVHhTdnCvyerCTEdXN1q
wQrDAfqAL0aoddoiEn4ZaIg8y65TudqL92S+fR5aHhEWyERMJyCighJOSElga07O
/cDu/fTjtuBrjtJq6AFOdqVcxUme7BlUfQWO7iVtV0fuAOGNINw=
=9svh
-END PGP SIGNATURE-

-- 
Roberto C. Sánchez

Bug#935141: Forwarded the bug.

[Gunter Königsmann]

Tried to forward this bug to the wxWidgets guys as the bug lies in wxWidgets 
and I cannot completely avoid opening modal dialogs.
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#944426: [Pkg-pascal-devel] Bug#944426: Bug#944426: Still not able to update

[Abou Al Montacir]

Hi Johann

As far as I can see everything is OK.
You were updating from 2.0.6-2 to 2.0.6-3 and this was tested here as you can
see below.

What I can assume is that even your 2.0.6-2 installation was broken and thus the
diversion was not done.
However this does not explain that your diversions file is OK.

Unfortunately, you did force the installation, but if you can reproduce the
issue (an other machine, or reinstall -2 then -3) then I'll be happy to
reproduce and fix.

# aptitude upgrade Resolving dependencies...The following
packages will be upgraded:  lazarus lazarus-2.0 lazarus-doc-2.0 lazarus-ide
lazarus-ide-2.0 lazarus-ide-gtk2-2.0 lazarus-src-2.0 lcl-2.0   lcl-gtk2-2.0 lcl-
nogui-2.0 lcl-units-2.0 lcl-utils-2.0 12 packages upgraded, 0 newly installed, 0
to remove and 2 not upgraded.Need to get 0 B/83.8 MB of archives. After
unpacking 115 kB will be freed.Do you want to continue? [Y/n/?] ...Reading
changelogs... Donegelogs... 7%Preconfiguring packages ...(Reading database ...
545578 files and directories currently installed.)Preparing to unpack .../00-
lazarus-2.0_2.0.6+dfsg-3_all.deb ...Unpacking lazarus-2.0 (2.0.6+dfsg-3) over
(2.0.6+dfsg-2) ...Preparing to unpack .../01-lazarus-ide-2.0_2.0.6+dfsg-
3_amd64.deb ...Unpacking lazarus-ide-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2)
...Preparing to unpack .../02-lazarus-ide-gtk2-2.0_2.0.6+dfsg-3_amd64.deb
...Unpacking lazarus-ide-gtk2-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2)
...Preparing to unpack .../03-lazarus-ide_2.0.6+dfsg-3_all.deb ...Unpacking
lazarus-ide (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../04-
lazarus-src-2.0_2.0.6+dfsg-3_all.deb ...Unpacking lazarus-src-2.0 
(2.0.6+dfsg-3) 
over (2.0.6+dfsg-2) ...Preparing to unpack .../05-lcl-nogui-2.0_2.0.6+dfsg-
3_amd64.deb ...Unpacking lcl-nogui-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2)
...Preparing to unpack .../06-lcl-units-2.0_2.0.6+dfsg-3_amd64.deb ...Unpacking
lcl-units-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../07-
lcl-gtk2-2.0_2.0.6+dfsg-3_amd64.deb ...Unpacking lcl-gtk2-2.0 (2.0.6+dfsg-3)
over (2.0.6+dfsg-2) ...Preparing to unpack .../08-lcl-utils-2.0_2.0.6+dfsg-
3_amd64.deb ...Unpacking lcl-utils-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2)
...Preparing to unpack .../09-lcl-2.0_2.0.6+dfsg-3_amd64.deb ...Unpacking lcl-
2.0:amd64 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../10-
lazarus_2.0.6+dfsg-3_all.deb ...Unpacking lazarus (2.0.6+dfsg-3) over
(2.0.6+dfsg-2) ...Preparing to unpack .../11-lazarus-doc-2.0_2.0.6+dfsg-
3_all.deb ...Unpacking lazarus-doc-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2)
...Setting up lazarus-doc-2.0 (2.0.6+dfsg-3) ...Setting up lazarus-src-2.0
(2.0.6+dfsg-3) ...Setting up lazarus-ide-2.0 (2.0.6+dfsg-3) ...update-
alternatives: using /usr/lib/lazarus/2.0.6/startlazarus to provide
/usr/bin/lazarus-ide (lazarus-ide) in auto modeSetting up lcl-utils-2.0
(2.0.6+dfsg-3) ...update-alternatives: using /usr/lib/lazarus/2.0.6 to provide
/usr/lib/lazarus/default (lazarus) in auto modeSetting up lcl-nogui-2.0
(2.0.6+dfsg-3) ...Setting up lazarus-ide-gtk2-2.0 (2.0.6+dfsg-3) ...update-
alternatives: using /usr/lib/lazarus/2.0.6/lazarus-gtk2 to provide
/usr/lib/lazarus/2.0.6/lazarus (lazarus-2.0.6) in auto modeSetting up lazarus-
ide (2.0.6+dfsg-3) ...Setting up lcl-gtk2-2.0 (2.0.6+dfsg-3) ...Setting up lcl-
units-2.0 (2.0.6+dfsg-3) ...Setting up lcl-2.0:amd64 (2.0.6+dfsg-3) ...Setting
up lazarus-2.0 (2.0.6+dfsg-3) ...Setting up lazarus (2.0.6+dfsg-3) ...Processing
triggers for mime-support (3.62) ...Processing triggers for hicolor-icon-theme
(0.17-2) ...Processing triggers for gnome-menus (3.31.4-3) ...Processing
triggers for man-db (2.8.5-2) ...Processing triggers for desktop-file-utils
(0.23-4) ... Current status: 2 (-12)
upgradable.-- 
Cheers,
Abou Al Montacir


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

Bug#946422: silx: autopkgtest regression: pocl error

[Andreas Beckmann]

On 19/12/2019 14.33, Graham Inggs wrote:
> On Thu, 19 Dec 2019 at 15:17, Andreas Beckmann  wrote:
>> I'm suspecting openmpi (that gets loaded by the io import) somehow messes up 
>> some state,
>> causing the lt_*() failures.
> 
> I wonder if this is related to #946986 ?

Downgrading to python3-h5py from buster makes the problem go away. But
it also removes mpi from the loop.

Selecting previously unselected package libhdf5-103:amd64.
(Reading database ... 32183 files and directories currently installed.)
Preparing to unpack .../libhdf5-103_1.10.4+repack-10_amd64.deb ...
Unpacking libhdf5-103:amd64 (1.10.4+repack-10) ...
(Reading database ... 32197 files and directories currently installed.)
Removing python3-mpi4py (3.0.3-1) ...
Removing mpi-default-bin (1.13) ...
Removing openmpi-bin (4.0.2-4+b1) ...
Removing libhdf5-openmpi-103:amd64 (1.10.4+repack-10) ...
Removing libopenmpi3:amd64 (4.0.2-4+b1) ...
Removing libpmix2:amd64 (3.1.4-1+b1) ...
Removing libevent-2.1-7:amd64 (2.1.11-stable-1) ...
Removing libevent-pthreads-2.1-7:amd64 (2.1.11-stable-1) ...
Removing libevent-core-2.1-7:amd64 (2.1.11-stable-1) ...
Removing libfabric1 (1.6.2-3+b1) ...
Removing librdmacm1:amd64 (26.0-2) ...
Removing libibverbs1:amd64 (26.0-2) ...
Removing libnl-route-3-200:amd64 (3.4.0-1+b1) ...
Removing libnl-3-200:amd64 (3.4.0-1+b1) ...
Removing libpsm2-2 (11.2.86-1) ...
Removing libnuma1:amd64 (2.0.12-1+b1) ...
Removing libpsm-infinipath1 (3.3+20.604758e7-6+b1) ...
update-alternatives: warning: alternative
/usr/lib/libpsm1/libpsm_infinipath.so.1.16 (part of link group
libpsm_infinipath.so.1) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/libpsm_infinipath.so.1
is dangling; it will be updated with best choice
Removing openmpi-common (4.0.2-4) ...
Setting up libhdf5-103:amd64 (1.10.4+repack-10) ...
Setting up python3-h5py (2.8.0-3) ...
Processing triggers for libc-bin (2.29-6) ...

I can reproduce the original problem if I take some OpenCL hello world
program (e.g. https://gist.github.com/ddemidov/2925717 with s/GPU/CPU/)
and insert MPI_Init(&argc, &argv; - no python needed

Andreas

Bug#947025: O: python-wsproto -- WebSockets state-machine based protocol implementation (Python3)

[Sebastien Delafond]

Package: wnpp
Severity: normal

I intend to orphan the python-wsproto package.

The package description is:
 Pure-Python implementation of a WebSocket protocol stack. It's
 written from the ground up to be embeddable in whatever program you
 choose to use, ensuring that you can communicate via WebSockets, as
 defined in RFC6455, regardless of your programming paradigm.
 .
 This is the Python3 package.

Bug#947024: ipxe-qemu: grub2 tests fail after upgrade to 1.0.0+git-20190125.36a4c85-2

[Colin Watson]

On Thu, Dec 19, 2019 at 04:15:55PM +, Colin Watson wrote:
> With ipxe-qemu 1.0.0+git-20190125.36a4c85-1, it runs for a few seconds
> then exits 0.  With 1.0.0+git-20190125.36a4c85-2, it hangs apparently
> forever (grub2's test suite kills it after a minute, but I've left it
> running for rather longer than that and it doesn't seem to make a
> difference).  Any hints welcome.

I rebuilt ipxe-qemu 1.0.0+git-20190125.36a4c85-1 against current
unstable and it works fine, so I think that rules out changes in ipxe's
build-dependencies.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#946998: [Python-modules-team] Bug#946998: python-django-split-settings: autopkgtest failure: No module named 'django_split_settings'

[Emmanuel Arias]

Hello everybody

I've just push to salsa the fix.

I will need sponsor  for upload, please :)


Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El jue., 19 de dic. de 2019 a la(s) 06:21, Paul Gevers
(elb...@debian.org) escribió:
>
> Source: python-django-split-settings
> Version: 0.3.0-1
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: regression
>
> Dear maintainers,
>
> Your new package python-django-split-settings is using autopkgtest,
> great. However, the test fails. I copied some of the output at the
> bottom of this report. You're using autodep8 to trigger the test, but it
> seems your package naming and Python module name isn't aligned for
> autodep8. autodep8 recently acquired a new feature that enables you to
> tell autode8 what the real module name is that should be tested [1].
>
> Currently this regression is blocking the migration to testing [2], as
> well as the fact that you'll need to upload a source-only package, as we
> don't allow binaries built by maintainers to migrate to testing, but we
> can't schedule binNMU's for arch all.
>
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> [1]
> https://manpages.debian.org/unstable/autodep8/autodep8.1.en.html#PYTHON_PACKAGES
> [2] https://qa.debian.org/excuses.php?package=python-django-split-settings
>
> https://ci.debian.net/data/autopkgtest/testing/arm64/p/python-django-split-settings/3473596/log.gz
>
> autopkgtest [00:27:44]: test autodep8-python3: set -e ; for py in
> $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
> with $py:" ; $py -c "import django_split_settings;
> print(django_split_settings)" ; done
> autopkgtest [00:27:44]: test autodep8-python3: [---
> Testing with python3.7:
> Traceback (most recent call last):
>   File "", line 1, in 
> ModuleNotFoundError: No module named 'django_split_settings'
> autopkgtest [00:27:44]: test autodep8-python3: ---]
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#946422: Fw: pocl and silx

[Jerome Kieffer]

Thanks Fred for the time spent on this. It looks like it is a very deep problem 
!

Concerning the code:
This medfilt code never properly worked on POCL CPU-thread version
while it works as expected on CUDA (POCL+CUDA) or other drivers. 
There is a huge amount of shared memory involved which may be the root of the 
problem (?)

But about the interference I mainly see specfile (the C-library) which is our 
"first" guess inside "silx.io".
This legacy code is far from our current standards ...

Other point, pyopencl.array.zeros_like() is calling the opencl enfillBuffer 
function which caused me also issues 
in (POCL+CUDA). Creating a work-around on the silx side is an option as it has 
been done many times.

I opened a bug on our side:
https://github.com/silx-kit/silx/issues/2848

Cheers

Begin forwarded message:

Date: Thu, 19 Dec 2019 10:08:49 +
From: PICCA Frederic-Emmanuel 
To: "kief...@esrf.fr" 
Subject: pocl and silx


Salut Jerome, on est en train d'essayer de demerder le problème avec pocl.

On a mis les info la

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946422


est-ce que cela te dis quelque choses.

C'est vrai que si l'on import silxs.io avant silxs.opencl  dans le petit 
snipset de test, ca change fondamentalement la done...

Amicalement

Fred

-- 
Jérôme Kieffer
tel +33 476 882 445

Bug#947028: bind9: Set EDNS UDP buffer size to avoid fragmentation

[Karl O. Pinc]

Package: bind9
Version: 1:9.10.3.dfsg.P4-12.3+deb9u5
Severity: normal

Hello,

Please deliver a default configuration which prevents fragmentation
of UDP EDNS datagrams.

DNS Flag Day 2020 is focusing "on the operational and security
problems in DNS caused by Internet Protocol packet fragmentation."

https://dnsflagday.net/

They recommend:

options {
  edns-udp-size 1232;
  max-udp-size 1232;
};

FYI, it seems the DNS Flag Day people involve some big players.  They
are interested in removing work-arounds from their own systems which
provide interoperability with other people's poorly configured or
poorly operating DNS servers.

Regards,
Karl


-- System Information:
Debian Release: 9.11
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-11-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bind9 depends on:
ii  adduser3.115
ii  bind9utils 1:9.10.3.dfsg.P4-12.3+deb9u5
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  libbind9-140   1:9.10.3.dfsg.P4-12.3+deb9u5
ii  libc6  2.24-11+deb9u4
ii  libcap21:2.25-1
ii  libcomerr2 1.43.4-2+deb9u1
ii  libdns162  1:9.10.3.dfsg.P4-12.3+deb9u5
ii  libgeoip1  1.6.9-4
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libirs141  1:9.10.3.dfsg.P4-12.3+deb9u5
ii  libisc160  1:9.10.3.dfsg.P4-12.3+deb9u5
ii  libisccc1401:9.10.3.dfsg.P4-12.3+deb9u5
ii  libisccfg140   1:9.10.3.dfsg.P4-12.3+deb9u5
ii  libk5crypto3   1.15-1+deb9u1
ii  libkrb5-3  1.15-1+deb9u1
ii  liblwres1411:9.10.3.dfsg.P4-12.3+deb9u5
ii  libssl1.0.21.0.2t-1~deb9u1
ii  libxml22.9.4+dfsg1-2.2+deb9u2
ii  lsb-base   9.20161125
ii  net-tools  1.60+git20161116.90da8a0-1
ii  netbase5.4

bind9 recommends no packages.

Versions of packages bind9 suggests:
ii  bind9-doc   1:9.10.3.dfsg.P4-12.3+deb9u5
ii  dnsutils1:9.10.3.dfsg.P4-12.3+deb9u5
pn  resolvconf  
pn  ufw 

-- debconf information excluded

Bug#947029: unbound: Set EDNS UDP buffer size to avoid fragmentation

[Karl O. Pinc]

Source: unbound
Version: Set EDNS UDP buffer size to avoid fragmentation
Severity: normal

Hello,

Please deliver a default configuration which prevents fragmentation
of UDP EDNS datagrams.

DNS Flag Day 2020 is focusing "on the operational and security
problems in DNS caused by Internet Protocol packet fragmentation."

https://dnsflagday.net/

They recommend:

server:
  edns-buffer-size: 1232

FYI, it seems the DNS Flag Day people involve some big players.  They
are interested in removing work-arounds from their own systems which
provide interoperability with other people's poorly configured or
poorly operating DNS servers.

Regards,
Karl

-- System Information:
Debian Release: 9.11
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-11-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#936802: kmer: Python2 removal in sid/bullseye

[Andreas Tille]

Control: tags -1 help

Hi,

I tried to convert kmer to Python3 in Git[1].  Unfortunately I'm stumbling
upon an issue in the test suite:

...
python3 /usr/bin/../lib/atac/bin/AtacDriver.py 
/tmp/atac-test.doxZJ4/results/work/LeprvsTuber.matches.extended

Traceback (most recent call last):
  File "/usr/bin/../lib/atac/bin/AtacDriver.py", line 18, in 
import MyFile
  File "/usr/lib/atac/lib/MyFile.py", line 6, in 
class myfile(file):
NameError: name 'file' is not defined
PYTHONPATH=/usr/bin/../lib/atac/lib
Chainer failed.


Any idea what's wrong here?

Kind regards

Andreas.


[1] https://salsa.debian.org/med-team/kmer

-- 
http://fam-tille.de

Bug#947024: ipxe-qemu: grub2 tests fail after upgrade to 1.0.0+git-20190125.36a4c85-2

[Colin Watson]

On Thu, Dec 19, 2019 at 04:32:32PM +, Colin Watson wrote:
> On Thu, Dec 19, 2019 at 04:15:55PM +, Colin Watson wrote:
> > With ipxe-qemu 1.0.0+git-20190125.36a4c85-1, it runs for a few seconds
> > then exits 0.  With 1.0.0+git-20190125.36a4c85-2, it hangs apparently
> > forever (grub2's test suite kills it after a minute, but I've left it
> > running for rather longer than that and it doesn't seem to make a
> > difference).  Any hints welcome.
> 
> I rebuilt ipxe-qemu 1.0.0+git-20190125.36a4c85-1 against current
> unstable and it works fine, so I think that rules out changes in ipxe's
> build-dependencies.

OK, I bisected this to this commit:

  
https://salsa.debian.org/waldi/ipxe/commit/56212b3037321d709184c5aed48b91b0a1bbd06e

Happy to try further tests if you have any suggestions.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#947030: nsd: Set EDNS UDP buffer size to avoid fragmentation

[Karl O. Pinc]

Package: nsd
Severity: normal

Hello,

Please deliver a default configuration which prevents fragmentation
of UDP EDNS datagrams.

DNS Flag Day 2020 is focusing "on the operational and security
problems in DNS caused by Internet Protocol packet fragmentation."

https://dnsflagday.net/

They recommend:

server:
  ipv4-edns-size: 1232
  ipv6-edns-size: 1232

FYI, it seems the DNS Flag Day people involve some big players.  They
are interested in removing work-arounds from their own systems which
provide interoperability with other people's poorly configured or
poorly operating DNS servers.

See also Bug#947028.

Regards,
Karl


-- System Information:
Debian Release: 9.11
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-11-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nsd depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u4
ii  libevent-2.0-5   2.0.21-stable-3
ii  libssl1.11.1.0l-1~deb9u1
ii  lsb-base 9.20161125
ii  openssl  1.1.0l-1~deb9u1

nsd recommends no packages.

nsd suggests no packages.

Bug#947028: Related bugs

[Karl O. Pinc]

See also: Bug#947029 (unbound), Bug#947030 (nsd)

I'm sure there are other DNS related packages in Debian
that could benefit but I have not contacted them.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#947030: Related bugs

[Karl O. Pinc]

See also: Bug#947029 (unbound)

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#947029: Related bugs

[Karl O. Pinc]

See also: Bug#947028 (bind9), Bug#947030 (nsd)

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#895450: slapd: segfault in back_mdb

[wferi]

Control: tag -1 - moreinfo

On Wed, 11 Apr 2018 10:08:25 -0700 Ryan Tandy  wrote:

> On Wed, Apr 11, 2018 at 06:41:08PM +0200, Ferenc Wágner wrote:
>
>> slapd[4515]: segfault at 4c ip 7f71abdbfc9b sp 7f716f184780 error 4 
>> in back_mdb-2.4.so.2.10.7[7f71abdb+39000]
>
> Not familiar to me, nor to upstream based on the information provided. 
> Feel free to remove the 'moreinfo' tag if it happens again and you're 
> able to capture a core or stacktrace.

Hi Ryan,

One and a half year later, and I've got a core dump!  Stretch system,
slapd 2.4.44+dfsg-5+deb9u3, segmentation fault at the same point, but
with a different value:

Dec 19 10:31:40 birch slapd[19274]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE 
- NEW_COOKIE
Dec 19 10:31:40 birch slapd[19274]: do_syncrep2: rid=001 NEW_COOKIE: 
rid=001,csn=20191219093138.816310Z#00#000#00
Dec 19 10:31:40 birch slapd[19274]: slap_queue_csn: queueing 0x7ff460102d90 
20191219093138.816310Z#00#000#00
Dec 19 10:31:40 birch slapd[19274]: slap_graduate_commit_csn: removing 
0x7ff460102d90 20191219093138.816310Z#00#000#00
Dec 19 10:31:59 birch slapd[19274]: do_syncrep2: rid=001 
cookie=rid=001,csn=20191219093159.802851Z#00#000#00
Dec 19 10:31:59 birch slapd[19274]: syncrepl_message_to_entry: rid=001 DN: 
uid=jeszenszkya,ou=users,o=niifi,o=niif,c=hu, UUID: 
6eb0ba40-14b1-1039-9559-11af45fdb739
Dec 19 10:31:59 birch slapd[19274]: syncrepl_entry: rid=001 
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
Dec 19 10:31:59 birch slapd[19274]: syncrepl_entry: rid=001 be_search (0)
Dec 19 10:31:59 birch slapd[19274]: syncrepl_entry: rid=001 
uid=jeszenszkya,ou=users,o=niifi,o=niif,c=hu
Dec 19 10:31:59 birch slapd[19274]: slap_queue_csn: queueing 0x7ff46c11d760 
20191219093159.802851Z#00#000#00
Dec 19 10:31:59 birch kernel: [3068983.104734] slapd[19276]: segfault at 
80b9542009 ip 7ff4b7304c9b sp 7ff47a6c9700 error 4 in 
back_mdb-2.4.so.2.10.7[7ff4b72f5000+39000]

Some random info that looked useful at first sight:

(gdb) bt
#0  mdb_modify_internal (op=op@entry=0x7ff47a6ca760, 
tid=tid@entry=0x5652a1c04f50, 
modlist=0x7ff46c11d8d0, e=e@entry=0x7ff47a6c9850, 
text=text@entry=0x7ff47a6ca020, 
textbuf=textbuf@entry=0x7ff47a6c98d0 "\024", textlen=256)
at ../../../../../servers/slapd/back-mdb/modify.c:99
#1  0x7ff4b7307f8e in mdb_modrdn (op=0x7ff47a6ca760, rs=0x7ff47a6ca000)
at ../../../../../servers/slapd/back-mdb/modrdn.c:509
#2  0x5652a06cb040 in overlay_op_walk (op=op@entry=0x7ff47a6ca760, 
rs=0x7ff47a6ca000, 
which=op_modrdn, oi=0x5652a1a2a850, on=)
at ../../../../servers/slapd/backover.c:677
#3  0x5652a06cb19d in over_op_func (op=0x7ff47a6ca760, rs=, 
which=)
at ../../../../servers/slapd/backover.c:730
#4  0x5652a06c29df in syncrepl_entry (syncCSN=0x7ff46c115400, 
syncUUID=0x7ff47a6ca070, 
syncstate=, modlist=0x7ff47a6c9d30, entry=0x5652a19a8f38, 
op=0x7ff47a6ca760, 
si=0x5652a1a39600) at ../../../../servers/slapd/syncrepl.c:3273
#5  do_syncrep2 (op=op@entry=0x7ff47a6ca760, si=si@entry=0x5652a1a39600)
at ../../../../servers/slapd/syncrepl.c:1040
#6  0x5652a06c4134 in do_syncrepl (ctx=ctx@entry=0x7ff47a6cac10, 
arg=arg@entry=0x5652a1a21e90)
at ../../../../servers/slapd/syncrepl.c:1564
#7  0x5652a065deed in connection_read_thread (ctx=0x7ff47a6cac10, argv=0xb)
at ../../../../servers/slapd/connection.c:1296
#8  0x7ff4bbe3efda in ?? () from 
/usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#9  0x7ff4ba3a74a4 in start_thread (arg=0x7ff47a6cb700) at 
pthread_create.c:456
#10 0x7ff4ba0e9d0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

(gdb) p *modlist
$9 = {sml_mod = {sm_desc = 0x5652a198dc00, sm_values = 0x7ff46c11d910, 
sm_nvalues = 0x7ff46c11d960, 
sm_numvals = 1, sm_op = 1, sm_flags = 0, sm_type = {bv_len = 0, bv_val = 
0x0}}, 
  sml_next = 0x7ff46c11d7f0}
(gdb) p *modlist->sml_next
$10 = {sml_mod = {sm_desc = 0x5652a198dc00, sm_values = 0x7ff46c11d830, 
sm_nvalues = 0x7ff46c11d880, 
sm_numvals = 1, sm_op = 4096, sm_flags = 0, sm_type = {bv_len = 0, bv_val = 
0x0}}, 
  sml_next = 0x80b9541fed}
(gdb) p mod
$12 = (Modification *) 0x80b9541fed
(gdb) p &mod->sm_op
$13 = (short *) 0x80b9542009

The end of the console output:

$ /usr/sbin/slapd -h ldapi:/// -F /etc/ldap/slapd.d -d Stats,Stats2
[...]
5dfb4079 conn=1001 op=4783 SRCH base="o=niifi,o=niif,c=hu" scope=2 deref=0 
filter="(&(objectClass=posixAccount)(uid=jsj))"
5dfb4079 conn=1001 op=4783 SRCH attr=uidNumber cn gecos uid objectClass 
homeDirectory gidNumber loginShell
5dfb4079 conn=1001 op=4783 SEARCH RESULT tag=101 err=0 nentries=0 text=
Segmentation fault

I'm ready to extract more info from the core dump or provide the
configuration if needed.  In short, it's a partial replica (constrained
by ACLs) from a wheezy slapd (2.4.40-4~bpo70+2).
-- 
Thanks,
Feri

Bug#947031: Fails to build with python3.8

[Sebastien Bacher]

Package: python-libarchive-c
Version: 2.8-0.4
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

The package failes to build with python 3.8, the attached patch fixes
the issue
diff -Nru python-libarchive-c-2.8/debian/changelog python-libarchive-c-2.8/debian/changelog
--- python-libarchive-c-2.8/debian/changelog	2019-10-08 02:24:30.0 +0200
+++ python-libarchive-c-2.8/debian/changelog	2019-12-19 18:25:00.0 +0100
@@ -1,3 +1,10 @@
+python-libarchive-c (2.8-0.5) UNRELEASED; urgency=medium
+
+  * debian/patches/git_python38_compat.patch:
+- backport an upstream commit to fix build with python 3.8
+
+ -- Sebastien Bacher   Thu, 19 Dec 2019 18:23:18 +0100
+
 python-libarchive-c (2.8-0.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-libarchive-c-2.8/debian/patches/git_python38_compat.patch python-libarchive-c-2.8/debian/patches/git_python38_compat.patch
--- python-libarchive-c-2.8/debian/patches/git_python38_compat.patch	1970-01-01 01:00:00.0 +0100
+++ python-libarchive-c-2.8/debian/patches/git_python38_compat.patch	2019-12-19 18:24:08.0 +0100
@@ -0,0 +1,49 @@
+From 7480fcdc8c6585d3f8ac67fe9a4dff0ebb0e479e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Miro=20Hron=C4=8Dok?= 
+Date: Thu, 2 May 2019 15:39:00 +0200
+Subject: [PATCH] Python 3.8: tarfile.filemode is gone, use stat.filemode if
+ available
+
+>   mode = tarfile.filemode(entry.mode)[1:]
+E   AttributeError: module 'tarfile' has no attribute 'filemode'
+---
+ tests/__init__.py | 6 +-
+ tox.ini   | 2 +-
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/tests/__init__.py b/tests/__init__.py
+index 7e922aa..bfca007 100644
+--- a/tests/__init__.py
 b/tests/__init__.py
+@@ -6,6 +6,10 @@
+ from os.path import abspath, dirname, join
+ from stat import S_ISREG
+ import tarfile
++try:
++from stat import filemode
++except ImportError:  # Python 2
++filemode = tarfile.filemode
+ 
+ from libarchive import file_reader
+ 
+@@ -83,7 +87,7 @@ def get_tarinfos(location):
+ path += '/'
+ # libarchive introduces prefixes such as h prefix for
+ # hardlinks: tarfile does not, so we ignore the first char
+-mode = tarfile.filemode(entry.mode)[1:]
++mode = filemode(entry.mode)[1:]
+ yield {
+ 'path': path,
+ 'mtime': entry.mtime,
+diff --git a/tox.ini b/tox.ini
+index 8973837..1f6b04f 100644
+--- a/tox.ini
 b/tox.ini
+@@ -1,5 +1,5 @@
+ [tox]
+-envlist=py27,py34,py35,py36
++envlist=py27,py34,py35,py36,py37,py38
+ skipsdist=True
+ 
+ [testenv]
+
diff -Nru python-libarchive-c-2.8/debian/patches/series python-libarchive-c-2.8/debian/patches/series
--- python-libarchive-c-2.8/debian/patches/series	2019-01-08 12:28:40.0 +0100
+++ python-libarchive-c-2.8/debian/patches/series	2019-12-19 18:24:17.0 +0100
@@ -1 +1,2 @@
 retrieve-version-from-debian-changelog.diff
+git_python38_compat.patch

Bug#947000: Acknowledgement (xfce4-weather-plugin: moonset time not shown on no-moonrise days)

[Sergio Gelato]

Here is the corresponding patch for sunrise and sunset, for the sake of
high-latitude users close to the middle of their time zone. Definitely
more of a corner case than the moonrise/moonset one.
The Sun may set today even though it last rose months ago.

For high-latitude locations, approximately once a year.
Index: xfce4-weather-plugin-0.8.11/panel-plugin/weather-summary.c
===
--- xfce4-weather-plugin-0.8.11.orig/panel-plugin/weather-summary.c	2019-12-19 09:26:57.061048252 +0100
+++ xfce4-weather-plugin-0.8.11/panel-plugin/weather-summary.c	2019-12-19 18:15:46.932435519 +0100
@@ -439,15 +439,16 @@
 if (data->current_astro->sun_never_rises) {
 value = g_strdup(_("\tSunrise:\t\tThe sun never rises today.\n"));
 APPEND_TEXT_ITEM_REAL(value);
-} else if (data->current_astro->sun_never_sets) {
-value = g_strdup(_("\tSunset:\t\tThe sun never sets today.\n"));
-APPEND_TEXT_ITEM_REAL(value);
 } else {
 sunrise = format_date(data->current_astro->sunrise, NULL, FALSE);
 value = g_strdup_printf(_("\tSunrise:\t\t%s\n"), sunrise);
 g_free(sunrise);
 APPEND_TEXT_ITEM_REAL(value);
-
+}
+if (data->current_astro->sun_never_sets) {
+value = g_strdup(_("\tSunset:\t\tThe sun never sets today.\n"));
+APPEND_TEXT_ITEM_REAL(value);
+} else {
 sunset = format_date(data->current_astro->sunset, NULL, FALSE);
 value = g_strdup_printf(_("\tSunset:\t\t%s\n\n"), sunset);
 g_free(sunset);

Bug#897137: live-build: man -k and apropos don't work in live system

[Raphael Hertzog]

Control: tag -1 - patch

On Sat, 28 Apr 2018, Robert Munyer wrote:
> The cause is the command "rm -rf /var/cache/man/*" in
> "/usr/share/live/build/hooks/normal/0190-remove-temporary-files.hook.chroot".
> 
> You can prevent the problem by doing the following before "lb config":

While this fixes this feature, it bloats the image for a feature that is
seldom used.

I'm not sure that I want to apply your patch.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#947033: RM: seed-webkit2 -- ROM; no users, unmaintained, inactive upstream

[Andrej Shadura]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Please remove seed-webkit2 from unstable on all architectures.

Seed has not been maintained upstream for about three years, has little
or no users in Debian, not used or developed actively in the downstream
distribution (Apertis) and there are no plans to in the foreseeable
future to work on it there.

The Debian GNOME team also doesn’t seem to have any plans for seed, and
in fact the previous version of seed (based on WebKit 1) has also been
removed because it had no users [1].

In case anyone needs seed again, it’s always possible to bring it back,
if necessary.

[1]: https://bugs.debian.org/773616

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl37ulIUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdKqeQf+OPi/8yoF2u7CK+4uCFPgjD5PDdMZ
vvfP3A0BqR428kydosHu9SMiVD5gkVsGKRLJdj3k+6u6IFl/wOTAfVP36P0gd5qN
gKFkqCzqi+efas+704n3IAhBX1cF48p2sVEoZNIu6C+YJjmU6A+8JdD8gXpC/U6H
wh2KtIt4ef+TvMW9JKYkq4VFmaO1nDniL1Ja4pnO3iWrYCAC/t/mlo59weOCYa58
6wF9BRkR0hDuC6totVPDp6d7Bawgre19RDQLQUGZ0AWZ+CGsbn5q3R2bk8IUkOQa
mb3EuYVeH5fGkUUlk2VgaI0cysov1ONb5ZtAW4ogWg5h7AMNHSPArk4o5w==
=je90
-END PGP SIGNATURE-

Bug#947035: ITP: vscpd -- A daemon for VSCP and friends m2m/IoT framework.

[Ake Hedman]

Package: wnpp
Severity: wishlist
Owner: Ake Hedman 

* Package name    : vscpd
  Version : 14.0.0
  Upstream Author : Ake Hedman 
* URL : https://www.vscp.org
* License : MIT
  Programming Lang: C, C++
  Description : A daemon for VSCP and friends m2m/IoT framework.

VSCP (Very Simple Control Protocol) was released in it's first version
in the autumn of 2000. It will therefore be twenty years next year. An
electronic paper once dubbed it as the IoT framework that was available
before IoT itself was around.

VSCP is a framework with software, drivers and firmware that makes it
possible to abstract the interaction with resource limited IoT devices.
The upcoming release 14.0.0 is a major rewrite from the previous release
and with some new goals for upper level functionality.

VSCP has been and will always be free and not owned by anyone.

I have maintained VSCP since the start and plan to continue to do so.
Part of that is packaging which really is needed and which I put a major
effort into lately to get done in a proper way.

This is the first package (the daemon) of a series of planed packages
(drivers/libs etc).

Need a sponsor of course. Will ask for that on IoT maintainers
debian-iot-maintain...@lists.alioth.debian.org which appears to be the
relevant place to ask.

Bug#947034: Fails to build with python3.8

[Sebastien Bacher]

Package: python-passlib
Version: 1.7.1-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

The package fails to build with python 3.8, the attached patch fixes the
issue
diff -Nru python-passlib-1.7.1/debian/changelog python-passlib-1.7.1/debian/changelog
--- python-passlib-1.7.1/debian/changelog	2017-01-31 17:48:36.0 +0100
+++ python-passlib-1.7.1/debian/changelog	2019-12-19 18:46:11.0 +0100
@@ -1,3 +1,10 @@
+python-passlib (1.7.1-2) UNRELEASED; urgency=medium
+
+  * debian/patches/hg_python38_build.patch:
+- backport some python 3.8 fixes from the upstream vcs
+
+ -- Sebastien Bacher   Thu, 19 Dec 2019 18:43:51 +0100
+
 python-passlib (1.7.1-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru python-passlib-1.7.1/debian/patches/hg_python38_build.patch python-passlib-1.7.1/debian/patches/hg_python38_build.patch
--- python-passlib-1.7.1/debian/patches/hg_python38_build.patch	1970-01-01 01:00:00.0 +0100
+++ python-passlib-1.7.1/debian/patches/hg_python38_build.patch	2019-12-19 18:45:41.0 +0100
@@ -0,0 +1,71 @@
+# Description: python3.8 compat fixes
+# https://bitbucket.org/ecollins/passlib/commits/844b76a82d5b
+#
+Index: python-passlib-1.7.1/passlib/utils/__init__.py
+===
+--- python-passlib-1.7.1.orig/passlib/utils/__init__.py
 python-passlib-1.7.1/passlib/utils/__init__.py
+@@ -6,7 +6,12 @@ from passlib.utils.compat import JYTHON
+ # core
+ from binascii import b2a_base64, a2b_base64, Error as _BinAsciiError
+ from base64 import b64encode, b64decode
+-import collections
++try:
++from collections.abc import Sequence
++from collections.abc import Iterable
++except ImportError:
++from collections import Sequence
++from collections import Iterable
+ from codecs import lookup as _lookup_codec
+ from functools import update_wrapper
+ import itertools
+@@ -30,6 +35,7 @@ else:
+ import time
+ if stringprep:
+ import unicodedata
++import timeit
+ import types
+ from warnings import warn
+ # site
+@@ -275,14 +281,14 @@ def batch(source, size):
+ """
+ if size < 1:
+ raise ValueError("size must be positive integer")
+-if isinstance(source, collections.Sequence):
++if isinstance(source, Sequence):
+ end = len(source)
+ i = 0
+ while i < end:
+ n = i + size
+ yield source[i:n]
+ i = n
+-elif isinstance(source, collections.Iterable):
++elif isinstance(source, Iterable):
+ itr = iter(source)
+ while True:
+ chunk_itr = itertools.islice(itr, size)
+@@ -839,14 +845,7 @@ def test_crypt(secret, hash):
+ assert secret and hash
+ return safe_crypt(secret, hash) == hash
+ 
+-# pick best timer function to expose as "tick" - lifted from timeit module.
+-if sys.platform == "win32":
+-# On Windows, the best timer is time.clock()
+-from time import clock as timer
+-else:
+-# On most other platforms the best timer is time.time()
+-from time import time as timer
+-
++timer = timeit.default_timer
+ # legacy alias, will be removed in passlib 2.0
+ tick = timer
+ 
+@@ -903,7 +902,7 @@ def genseed(value=None):
+ 
+ # the current time, to whatever precision os uses
+ time.time(),
+-time.clock(),
++tick(),
+ 
+ # if urandom available, might as well mix some bytes in.
+ os.urandom(32).decode("latin-1") if has_urandom else 0,
diff -Nru python-passlib-1.7.1/debian/patches/series python-passlib-1.7.1/debian/patches/series
--- python-passlib-1.7.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ python-passlib-1.7.1/debian/patches/series	2019-12-19 18:42:17.0 +0100
@@ -0,0 +1 @@
+hg_python38_build.patch

Bug#943234: Fwd: Processed: py2removal RC severity updates - 2019-12-19 17:37:03.473537+00:00

[Andrej Shadura]

Control: severity -1 normal

Sandro, can you please stop this?

Let me quote my previous message, which I understand you missed:

> Python 2 dependency in SparkleShare is not part of the core
> functionality, thus this bug is only severity normal.
>
> I plan to update it but it is not an RC bug.
>
> Thanks for not raising it again. I will fix it when I have time,
> juggling the severity will not me spend more time on it or work faster.

On Thu, 19 Dec 2019 at 18:39, Debian Bug Tracking System
 wrote:
>
> Processing commands for cont...@bugs.debian.org:
>
> > # Part of the effort for the removal of python from bullseye
> > #  * https://wiki.debian.org/Python/2Removal
> > #  * http://sandrotosi.me/debian/py2removal/index.html
> > # See https://lists.debian.org/debian-devel-announce/2019/11/msg0.html
> > # for more details on this severity bump
> > # sparkleshare is an application, has low popcon (99 < 300), and has 0 
> > external rdeps or not in testing
> > severity 943234 serious
> Bug #943234 [src:sparkleshare] sparkleshare: Python2 removal in sid/bullseye
> Severity set to 'serious' from 'normal'
> >
> End of message, stopping processing here.
>
> Please contact me if you need assistance.
> --
> 943234: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943234
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>


--
Cheers,
  Andrej


-- 
Cheers,
  Andrej

Bug#880368: YAML::XS::Load expects utf8 octets, not perl's encoding; use slurp_raw

[Alex Muntada]

Hi Dominique,

> Dear debian-perl team colleagues, do you foresee any problem
> with this change?

None that I'm aware of... +1 to YAML::XS

Cheers!
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer 🍥 log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#895450: slapd: segfault in back_mdb

[Ryan Tandy]

On Thu, Dec 19, 2019 at 06:12:05PM +0100, wf...@niif.hu wrote:

One and a half year later, and I've got a core dump!


Yay!

I guess the problem here is the "sml_next" value. I have not reproduced 
the crash yet, but for a start I am looking at "m2" on syncrepl.c:3236.


With your coredump, could you dig a little further into the two 
"sml_mod" structures and show their sm_desc/sm_values/sm_nvalues?


(For the "sm_op" values, 1 is LDAP_MOD_DELETE and 4096 is 
SLAP_MOD_SOFTADD.)


Also, if the frame is still valid, the contents of "dni" in 
syncrepl_entry (frame #4) would be useful too.


Thanks!

Bug#934119: [Pkg-privacy-maintainers] Bug#934119: torbrowser-launcher: Erroneously manages /etc/apparmor.d/local/torbrowser.* as conffiles

[Roger Shimizu]

Dear Intrigeri,

Thanks for your report, and sorry I just had time to look at this issue.

On Wed, Aug 7, 2019 at 5:21 PM  wrote:
>
> Package: torbrowser-launcher
> Version: 0.3.2-1
> Severity: normal
>
> With this version, /etc/apparmor.d/local/torbrowser.Browser.firefox
> and /etc/apparmor.d/local/torbrowser.Tor.tor are managed as conffiles
> again, while they should not: they're supposed to be created/deleted
> as needed by bits of maintainer scripts generated by dh_apparmor.

So you mean we should revert 9fdce2a576782bb0790416bcf739b31ceb869c6b?

> A problematic consequence is that if I have local tweaks in those
> files (which is their actual intended purpose), I'm asked on upgrade
> to resolve the conflict between my configuration and the empty one
> shipped by the package.
>
> I believe we've had the same bug in the past, that got fixed in
> d0deb2f923edbaf3c2801c46d74b7925c5605593. I'm not sure what
> exact rm_conffile call would be suitable here (depends on which
> upgrade paths we shall support).

d0deb2f923edbaf3c2801c46d74b7925c5605593 was just add entries of
rm_conffile line.
I'm not sure why we should remove rm_conffile here.
Please provide more info if possible. Thank you!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#934948: Dropping dependencies to avoid extra binary package when same source package targets more than one environment

[Pirate Praveen]

[copying debian-ruby]

On Wed, 18 Dec 2019 22:55:16 + Simon McVittie  wrote:

The technical committee has been asked to consider what level of binary
package granularity is appropriate for the src:ruby-task-list package,
and for similar packages that provide library code for more than one
language in the same upstream source release. This is advice under
§6.1(5) of the Debian constitution, and is not intended to overrule
any developers' decisions.


Thanks for the detailed response. I wonder if this could be documented 
in debian-policy or developers reference or some other suitable place.


> 3. For the specific case of src:ruby-task-list, which provides both a 
Ruby

>   library and a JavaScript library, we suggest:
>
> * shipping both Ruby and JavaScript libraries in a single binary package
> * removing the dependency on the Ruby interpreter, unless there is a
>  reason why it is required
> * asking the maintainers of the Ruby libraries that ruby-task-list
>  recursively depends on (such as ruby-rack) to remove *their* 
dependencies

>  on the Ruby interpreter, unless there is a reason why it is required

Just confirming, this would mean ruby-rack (371 kB), ruby-activesupport 
(2,082 kB), ruby-html-pipeline (90.1 kB) getting installed even when 
only javascript library is required for an application. Since this will 
not be pulling an interpreter so waste of space and bandwidth is ignored 
in this case as it is not opening an attack vector (unlike the case when 
unrelated interpreter is installed). At least 7 MB packages (combined 
size of those mentioned recursive dependencies) will be installed when 
some one just wants to install a 8KB library.


And ruby-activesupport will pull  ruby-concurrent (886 kB), ruby-i18n 
(38.5 kB), ruby-minitest (150 kB), ruby-tzinfo (202 kB). So I will need 
to ask maintainers of each of these packages (all of them under ruby 
team) also to remove their dependency on ruby.


ruby-tzinfo will pull ruby-thread-safe (26.4 kB) and tzdata 
(ruby-thread-safe will pull ruby-atomic (56.3 kB)).


ruby-html-pipeline will pull ruby-nokogiri (446 kB), ruby-pkg-config 
(8,464 B) and ruby-nokogiri has non-ruby dependencies too libxml2 (687 
kB), libxslt1.1 (237 kB) and recursively more, at least 32.4 MB of 
libicu63 (which can be ignored as nodejs also depend on it).


I think we will need to update gem2deb to not add a dependency on ruby 
if it is a library only package (ie, no executables).

Bug#936802: kmer: Python2 removal in sid/bullseye

[Scott Talbert]

On Thu, 19 Dec 2019, Andreas Tille wrote:


Traceback (most recent call last):
 File "/usr/bin/../lib/atac/bin/AtacDriver.py", line 18, in 
   import MyFile
 File "/usr/lib/atac/lib/MyFile.py", line 6, in 
   class myfile(file):
NameError: name 'file' is not defined
PYTHONPATH=/usr/bin/../lib/atac/lib
Chainer failed.


The 'file' class doesn't exist anymore in Python 3.  You'll have to 
rewrite myfile to not use it.


Scott

Bug#947036: filter out obviously incorrect upstream metadata fields

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.47
Severity: normal

When finding upstream metadata in upstream data sources, lintian-brush should 
filter out obviously incorrect or unuseful values.

For example, the value "BUG-REPORT-ADDRESS" for Bug-Submit, or any field set to 
"unknown".

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-3
ii  python3-breezy   3.0.2-1
ii  python3-debian   0.1.36
ii  python3-distro-info  0.22
ii  python3-dulwich  0.19.14-2
ii  python3-levenshtein  0.12.0-5
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  libdebhelper-perl  12.7.2
ii  lintian2.41.0
ii  python3-asyncpg0.20.0-1
ii  python3-pyinotify  0.9.6-1.2

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  210

-- no debconf information

Bug#947024: ipxe-qemu: grub2 tests fail after upgrade to 1.0.0+git-20190125.36a4c85-2

[Bastian Blank]

Control: tags -1 pending

Hi Colin

On Thu, Dec 19, 2019 at 05:14:11PM +, Colin Watson wrote:
> OK, I bisected this to this commit:
>   
> https://salsa.debian.org/waldi/ipxe/commit/56212b3037321d709184c5aed48b91b0a1bbd06e
> Happy to try further tests if you have any suggestions.

I feared it would be something like that.  And after re-reading the
change, the cause is found:

qemu loads rom files, which are supposed to include roms for all
environments, currently efi-x86_64 and pcbios.  By accident they now
only contain efi-x86_64.  So booting with OVMF works, but seabios does
not.

Regards,
Bastian

-- 
Dammit Jim, I'm an actor, not a doctor.

Bug#913867: Bug remains, but mitigated for Lintian

[Felix Lechner]

Control: retitle -1 file: Please disable WE32K executables like 3B20
Control: affects -1 - src:lintian

Hi Norbert,

> Please exempt .tfm files from this check, it is incorrect.

The problem in Lintian was not so much that .tfm files were looked at
but that their format, which file (1) misidentified, was associated
with Windows executables. This line in data/cruft/warn-file-type
should read "COM", not "COFF":

source-contains-prebuilt-windows-binary ~~
\b(?:PE(?:32|64)|(?:MS-DOS|COFF)\s executable)\b

I made the change in this commit:


https://salsa.debian.org/lintian/lintian/commit/c7c223d7bb23b82ea0d9a55a11a11318ce539a58

That mitigates the impact on Lintian for the time being. I removed the
bug's 'affects' setting.

The change also means that Lintian may not warn against some COFF
files in sources, although it does not look to be a common issue from
the list of tags on lintian.d.o [2]. Also, none of the omissions will
relate to Microsoft Windows, because the regex still catches PE
executables, which the only COFF format in use there (mostly NT) [3].
Hopefully the magic information will be adjusted before Lintian is
asked to again reject all COFF executables.

> I think the bug might actually be in file(1)

I agree. A solution could be to disable WE32K executables similar to
the way 3B20 executables were commented out. Both formats relate to
the Bellmac 32, an obsolete mainframe architecture discontinued in the
mid-1980s [1]. Both formats are described in magic/Magdir/att3b. I
retitled the bug to reflect that suggestion.

For the record, I attached one of the 274 offending font metrics. (It
is only 500 bytes.) This is how file(1) gets it wrong:

$ file -kr csitt8.tfm
csitt8.tfm: WE32000 COFF executable (TV) not stripped
- TeX font metric data (TeX cs typewriter text)
   - data

It may also possible to promote the TeX file format similar to this
entry found online [4]:

#--
# Localstuff:  file(1) magic for locally observed files
#
# $Id: Localstuff,v 1.3 1995/01/21 21:09:00 christos Exp $
# Add any locally observed files here.  Remember:
# text if readable, executable if runnable binary, data if unreadable.

# XXX promoted from tex so that *.tfm is not mis-identified as mc68k file.
# There is no way to detect TeX Font Metric (*.tfm) files without
# breaking them apart and reading the data.  The following patterns
# match most *.tfm files generated by METAFONT or afm2tfm.
2 string \000\021 TeX font metric data
>33 string >\0 (%s)
2 string \000\022 TeX font metric data
>33 string >\0 (%s)

Thank you for helping to make Lintian better.

Kind regards,
Felix Lechner

[1] https://en.wikipedia.org/wiki/Bellmac_32
[2] https://lintian.debian.org/tags/source-contains-prebuilt-windows-binary.html
[3] https://en.wikipedia.org/wiki/COFF
[4] https://www.garykessler.net/library/magic.html


csitt8.tfm.xz
Description: application/xz

Bug#913867: Bug remains, but mitigated for Lintian

[Christoph Biedl]

Control: tags 913867 pending

Felix Lechner wrote...

> Control: retitle -1 file: Please disable WE32K executables like 3B20

Executive summary: Aye

> > I think the bug might actually be in file(1)
>
> I agree. A solution could be to disable WE32K executables similar to
> the way 3B20 executables were commented out. Both formats relate to
> the Bellmac 32, an obsolete mainframe architecture discontinued in the
> mid-1980s [1]. Both formats are described in magic/Magdir/att3b. I
> retitled the bug to reflect that suggestion.

The bad part is the pattern is very weak, just 16 bits of a file are
considered enough to terminate the detection process - in general I try
to find at least 33 identifying bits. This can be improved by
re-ordering the rules, I'll bring this upstream. But for the moment
disabling such an error-prone pattern is the way to go.

Afterwards:

file-testsuite-data.git/debian-bugs/913867/csitt12.tfm: TeX font metric data 
(TeX cs typewriter text)
file-testsuite-data.git/debian-bugs/913867/csitt8.tfm:  TeX font metric data 
(TeX cs typewriter text)

Version 1:5.38-1 will hit experimental very soon (hours - I'm still in
the middle of regression tests).

> It may also possible to promote the TeX file format similar to this
> entry found online [4]:
>
> #--
> # Localstuff:  file(1) magic for locally observed files
> #
> # $Id: Localstuff,v 1.3 1995/01/21 21:09:00 christos Exp $
> # Add any locally observed files here.  Remember:
> # text if readable, executable if runnable binary, data if unreadable.
>
> # XXX promoted from tex so that *.tfm is not mis-identified as mc68k file.
> # There is no way to detect TeX Font Metric (*.tfm) files without
> # breaking them apart and reading the data.  The following patterns
> # match most *.tfm files generated by METAFONT or afm2tfm.
> 2 string \000\021 TeX font metric data
> >33 string >\0 (%s)
> 2 string \000\022 TeX font metric data
> >33 string >\0 (%s)
>
> Thank you for helping to make Lintian better.

Excuse my blindness, do you want this sniplet become part of
file/libmagic? If yes, it should see some improvement first (just 17
identifying bits, see above).

Cheers,

Christoph


signature.asc
Description: PGP signature

Bug#938525: spectacle: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:53:18AM +, Matthias Klose wrote:
> Package: src:spectacle
> Version: 0.25-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

Hi Philippe,
Spectacle seems dead upstream, let's remove it from the archive?

Cheers,
Moritz

Bug#874843: [cdcat] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Mon, Aug 26, 2019 at 09:30:48AM +0200, Eduard Bloch wrote:
> reassign 874843 wnpp
> retitle 874843 RFA: cdcat - maintain disk media contents catalog
> thanks
> 
> Hallo Moritz,
> * Moritz Mühlenhoff [Thu, Aug 22 2019, 11:16:12PM]:
> > On Sat, Sep 09, 2017 at 09:03:03PM +0200, Lisandro Damián Nicanor Pérez 
> > Meyer wrote:
> > > Source: cdcat
> > >
> > > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > > as [announced] in:
> > >
> > > [announced] 
> > > 
> > >
> > > Therefore, please take the time and:
> > > - contact your upstream (if existing) and ask about the state of a Qt5
> > > port of your application
> > > - if there are no activities regarding porting, investigate whether there 
> > > are
> > > suitable alternatives for your users
> > > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > > archives, consider removing the Qt4 version
> >
> > Eduard,
> > cdcat is dead upstream, are you planning to port it to Qt5 yourself or 
> > should
> > it be removed from the archive?
> 
> IMHO, unless some wants to contribute here, it can go for good.
> 
> TBH it was not just porting to Qt5 but also architectural issues in later
> versions which I refused to package the way they were designed
> (depending on build-time config and weird 3rd party libs). And I don't
> have time nor much interest to continue here.
> 
> Thanks for pushing, I am making this request RFA for now and it can
> become RoM by the time you are RoMing qt4.

We're now wrapping up the remaining rev deps of Qt4 and noone adopted it
since then so I just filed a removal bug.

Cheers,
Moritz

Bug#947037: RM: cdcat -- RoQA; Depends on qt4, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove cdcat, it's dead upstream and depends on Qt4.

Cheers,
Moritz

Bug#946359: pg-snakeoil: Selftest apears to be broken

[Sebastian Andrzej Siewior]

On 2019-12-19 10:04:48 [+0100], Christoph Berg wrote:
> Re: Sebastian Andrzej Siewior 2019-12-18 
> <20191218225837.qttuxpwrbo5ukpr3@flow>
> > > $ sudo -u clamav freshclam --verbose
> > 
> > what happens if you strip the sudo part? One of the first thing is to
> > change to the clamav user (well so is my memory and the /var/…/clamav is
> > owned by clamav so…)? However after I install sudo in my chroot and try
> > this it still works :/
> 
> Now it just works, both with "sudo freshclam --verbose" and "sudo -u
> clamav freshclam --verbose":

I meant without sudo but here you go.

> Thu Dec 19 10:00:36 2019 -> *updatedb: Running g_cb_download_complete 
> callback...

and now out of the sudden it is no longer outdated.

> > > Time: 2.4s, ETA; 0.0s [===>] 
> > > 52.81MiB/52.81MiB   
> > > * Connection #0 to host database.clamav.net left intact
> > > Wed Dec 18 11:56:13 2019 -> ^Mirror https://database.clamav.net is not 
> > > synchronized.
> > 
> > So I don't have this. And for that to happen you need an out-dated
> > database. And somehow you have that and the ci host. Reproducible.
> 
> Maybe there was one bad server in the mirror list...

right. And the same server is used ci.debian.net. For days.
The database server sits behind cloudflare's CDN [0]. Which means
something would bad with the CDN. But then it appears to work with the
old freshclam while new one throws the problem. So it might be a problem
somewhere else.

[0] https://blog.clamav.net/2018/09/want-to-improve-your-clamav-experience.html

> > If the `sudo' part makes no difference, can you stash me your chroot or
> > the other way around? There must be something that is different.
> 
> One bit that could have been relevant is that I'm running on schroot
> with tmpfs on an overlay fs.

But that part is transparent. I would expect a transparent proxy,
dns-preload library or an odd package which somehow influeces
curl/freshclam.

> Christoph

Sebastian

Bug#936802: kmer: Python2 removal in sid/bullseye

[Andreas Tille]

Hi Scott,

thanks a lot for your hint.

On Thu, Dec 19, 2019 at 01:34:08PM -0500, Scott Talbert wrote:
> 
> The 'file' class doesn't exist anymore in Python 3.  You'll have to rewrite
> myfile to not use it.

OK, I simply went with

...
@@ -608,6 +608,11 @@ Last-Update: Thu, 19 Dec 2019 10:43:09 +0100
  
  # from __future__ import generators  # Necessary before Python 2.3
  
+-class myfile(file):
++class myfile():
+ "A temporary anonymous file"
+ def __init__(self):
+ filename = tempfile.mktemp()
 @@ -27,8 +27,8 @@ class ListLikeFileIter:
  self._fileIter = iter(self._fileptr.readline,"")
  def __del__(self):
...


This brings me to the next error where a Module written in C is not
found:



python3 /usr/bin/../lib/atac/bin/AtacDriver.py 
/tmp/atac-test.XqdEPl/results/work/LeprvsTuber.matches.extended

Traceback (most recent call last):
  File "/usr/bin/../lib/atac/bin/AtacDriver.py", line 26, in 
import localAlignerInterface
ModuleNotFoundError: No module named 'localAlignerInterface'
PYTHONPATH=/usr/bin/../lib/atac/lib
Chainer failed.



The file /usr/lib/atac/lib/localAlignerInterfacemodule.so exists
but it seems the Python3 script can't load it.


Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#947005: nethack: buffer overflow when parsing config files

[Salvatore Bonaccorso]

Control: retitle -1 nethack: CVE-2019-19905: buffer overflow when parsing 
config files

On Thu, Dec 19, 2019 at 11:57:42AM +0100, Reiner Herrmann wrote:
> Source: nethack
> Version: 3.6.0-1
> Severity: grave
> Tags: security
> X-Debbugs-Cc: t...@security.debian.org
> 
> Hi,
> 
> a new version of NetHack has been released that fixes a privilege
> escalation issue introduced in 3.6.0 [0] [1]:
> 
> > A buffer overflow issue exists when reading very long lines from a
> > NetHack configuration file (usually named .nethackrc).
> > 
> > This vulnerability affects systems that have NetHack installed suid/sgid
> > and shared systems that allow users to upload their own configuration
> > files.
> > 
> > All users are urged to upgrade to NetHack 3.6.4 as soon as possible. 
> 
> As the Debian packages ship setgid binaries, I think they are affected by it.
> 
> At least these two commits look related:
>  https://github.com/NetHack/NetHack/commit/f4a840a
>  https://github.com/NetHack/NetHack/commit/f001de7

This issue has been assigned CVE-2019-19905 by MITRE.

Regards,
Salvatore

Bug#947038: buster-pu: package libburn/1.5.0-1

[Steve McIntyre]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi folks,

We'd like to add a stable update for libburn to fix an important bug
in cdrskin. 1.5.0-1 (currently in Buster) currently can't burn
multi-track audio CDs correctly and instead just spoils/wastes
media. This was reported by Thomas upstream and I've verified this
behaviour myself. See #946679, where he's given much more detail about
the problem.

There's a simple fix, here's the debdiff.

Thomas has done the packaging work, and I'm helping him with
sponsorship.

diff -Nru libburn-1.5.0/debian/changelog libburn-1.5.0/debian/changelog
--- libburn-1.5.0/debian/changelog  2018-10-05 20:21:10.0 +0100
+++ libburn-1.5.0/debian/changelog  2019-11-27 15:17:00.0 +
@@ -1,3 +1,14 @@
+libburn (1.5.0-1+deb10u1) buster; urgency=low
+  * Patch taken from upstream development
++ cdrskin multi-track burning was slow and stalled after track 1.
+  Regression introduced in version 1.5.0 by commit 84fad99, 2018.02.05,
+  which should fix a bug with O_DIRECT track reading.
+  Debian never enabled O_DIRECT, so 84fad99 was never desirable.
+  The patch reverts the upstream commit to bring the fifo code of cdrskin
+  back to the state in Debian 9 and Debian 8.
+
+ -- Thomas Schmitt   Wed, 27 Nov 2019 16:17:00 +0100
+
 libburn (1.5.0-1) unstable; urgency=low
 
   [ Thomas Schmitt ]
diff -Nru libburn-1.5.0/debian/patches/01-fix-cdrskin-multi-track.patch 
libburn-1.5.0/debian/patches/01-fix-cdrskin-multi-track.patch
--- libburn-1.5.0/debian/patches/01-fix-cdrskin-multi-track.patch   
1970-01-01 01:00:00.0 +0100
+++ libburn-1.5.0/debian/patches/01-fix-cdrskin-multi-track.patch   
2019-11-27 15:17:00.0 +
@@ -0,0 +1,18 @@
+Description: Bug fix: cdrskin multi-track burning was slow and stalled
+ after track 1.
+ Regression introduced in version 1.5.0 by commit 84fad99, 2018.02.05,
+ which should fix a bug with O_DIRECT track reading.
+ This patch reverts the upstream commit to bring the fifo code of cdrskin back
+ to the state of cdrskin-1.4.6 in Debian 9 and cdrskin-1.3.2 in Debian 8.
+Author: Thomas Schmitt 
+
+--- a/cdrskin/cdrfifo.c
 b/cdrskin/cdrfifo.c
+@@ -28,7 +28,6 @@
+ #ifndef Cdrfifo_standalonE
+ /* for burn_os_alloc_buffer() */
+ #include "../libburn/libburn.h"
+-#define Libburn_has_open_trac_srC 1
+ #endif
+
+ #include "cdrfifo.h"
diff -Nru libburn-1.5.0/debian/patches/series 
libburn-1.5.0/debian/patches/series
--- libburn-1.5.0/debian/patches/series 2018-10-05 20:21:10.0 +0100
+++ libburn-1.5.0/debian/patches/series 2019-11-27 15:17:00.0 +
@@ -0,0 +1,2 @@
+01-fix-cdrskin-multi-track.patch
+



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

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

Bug#937900: python-lxc: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:41:57AM +, Matthias Klose wrote:
> Package: src:python-lxc
> Version: 0.1-3
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

Hi Evgeni,
there are no remaining rdeps for python-lxc and Python 3 support is
available via the separate python3-lxc source package, let's remove?

Cheers,
Moritz

Bug#947039: libapache2-mod-auth-pgsql: AuthType Basic configured without corresponding module

[Bernd Zeimetz]

Package: libapache2-mod-auth-pgsql
Version: 2.0.3-6.1
Severity: serious

As far as I can see one of the issues from #666814 has reincarnated the 
package since Stretch. I could not get the auth module to work at all due to


AH01796: AuthType Basic configured without corresponding module

Due to the low popcon and auth_dbd being available, I'd assume nobody 
noticed this at all.



--
Bernd Zeimetz
Senior Systems Engineer
Debian Developer, Palo Alto ACE, RHCE, RHCS-PaaS

conova communications GmbH
Zentrale Salzburg
Karolingerstraße 36a
5020 Salzburg, Austria

T +43 662/22 00-313
M +43 676/830 50 313
b.zeim...@conova.com
www.conova.com

Gesetzliche Pflichtangaben:
www.conova.com/impressum
www.conova.com/datenschutz


smime.p7s
Description: S/MIME cryptographic signature

Bug#947040: kopano-core: PIDFILE in /etc/init.d/kopano-* does not match /etc/kopano/*.cfg

[Albert]

Package: kopano-core
Version: 8.7.0-3
Severity: normal

Dear Maintainer,

First of all thanks for the wonderfull job of bringing kopano to the debian
repositories! It is a lot easier to install/maintain thanks to your work.

When configuring kopano, I needed to restart the server to activate the new
configuration. I did a:

  systemctl restart kopano-server

I noticed the following messages in /var/log/syslog:

Dec 19 11:04:42 defiant systemd[1]: Stopping LSB: Kopano Collaboration
Platform's Storage Server...
Dec 19 11:04:42 defiant kopano-server[4728]: Stopping Kopano server: kopano-
serverNo /usr/sbin/kopano-server found running; none killed.
Dec 19 11:04:42 defiant kopano-server[4728]:  failed!
Dec 19 11:04:42 defiant systemd[1]: kopano-server.service: Succeeded.
Dec 19 11:04:42 defiant systemd[1]: Stopped LSB: Kopano Collaboration
Platform's Storage Server.
Dec 19 11:04:42 defiant systemd[1]: kopano-server.service: Found left-over
process 1506 (kopano-server) in control group while starting unit. Ignoring.
Dec 19 11:04:42 defiant systemd[1]: This usually indicates unclean termination
of a previous run, or service implementation deficiencies.
Dec 19 11:04:42 defiant systemd[1]: Starting LSB: Kopano Collaboration
Platform's Storage Server...
Dec 19 11:04:43 defiant kopano-server[4744]: Starting kopano-server version
8.7.0 (pid 4744 uid 0)
Dec 19 11:04:43 defiant kopano-server[4744]: Unable to bind to port 236:
Address already in use. This is usually caused by another process (most likely
another server) already using this port. This program will terminate now.

In the end the 'old' kopano-server kept running, while the 'one' terminated due
to 'unable to bind port 236'.


Searching for the source of this problem, I found that the PIDFILE directives
in /etc/init.d/kopano-* are not consistent with the ones used in
/etc/init.d/kopano-*.

My problem was locally solved by changing /etc/init.d/kopano-* and running
'systemctl daemon-reload'.

In my opinion others can benefit if this change is integrated in the kopano-
package.

Thanks for all your work.
If you need more info, please contact me.

Albert



-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kopano-core depends on:
ii  kopano-backup   8.7.0-3
ii  kopano-dagent   8.7.0-3
ii  kopano-gateway  8.7.0-3
ii  kopano-ical 8.7.0-3
ii  kopano-monitor  8.7.0-3
ii  kopano-search   8.7.0-3
ii  kopano-server   8.7.0-3
ii  kopano-spamd8.7.0-3
ii  kopano-spooler  8.7.0-3
ii  kopano-utils8.7.0-3

kopano-core recommends no packages.

Versions of packages kopano-core suggests:
pn  kopano-webapp  

-- no debconf information

Bug#947041: RFS: coinutils/2.11.3+repack1-1 [QA]-- Coin-or collection of utility classes (binaries and libraries)

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "coinutils"

* Package name : coinutils
Version : 2.11.3+repack1-1
Upstream Author :
* URL : https://projects.coin-or.org/CoinUtils
* License : EPL-1
* Vcs : https://salsa.debian.org/science-team/coinutils
Section : science

It builds those binary packages:

coinor-libcoinutils3v5 - Coin-or collection of utility classes (binaries 
and libraries)
coinor-libcoinutils-dev - Coin-or collection of utility classes 
(developer files)
coinor-libcoinutils-doc - Coin-or collection of utility classes 
(documentation)


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


https://mentors.debian.net/package/coinutils

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

dget -x 
https://mentors.debian.net/debian/pool/main/c/coinutils/coinutils_2.11.3+repack1-1.dsc


Changes since the last upload:

* QA upload
[ Debian Janitor ]
* Drop use of autotools-dev debhelper.
* Update standards version to 4.4.1, no changes needed.
* Set upstream metadata fields: Bug-Submit.
* Fix day-of-week for changelog entries 2.9.4-1.
.
[ Håvard Flaget Aasen ]
* New upstream version 2.11.3+repack1
* Remove autotools-dev as build-dependency
* Remove debian/compat, use debhelper-compat instead
* Update debian/watch.
- Add 'repack' in dversionmangle
- Use secure URI
* Update copyright.
- Exclude MSVisualStudio
* Shorten paths in debian/*.install files.
* Remove unused lintian-overrides
* In debian/rules
- Remove README file in wrong folder

Regards,
Håvard

Bug#947042: node-express isn't compatible with node-path-to-regexp ≥ 6

[Xavier Guimard]

Package: node-express
Version: 4.17.1-1
Severity: important
Tags: upstream
Forwarded: https://github.com/expressjs/express/issues/4136

Hi,

node-express is not compatible with recent node-path-to-regex. This
affects node-superagent tests and renders part of express unusable.

The fix is simple but then test fail:

 8< 
diff --git a/lib/router/layer.js b/lib/router/layer.js
index 4dc8e86..cc96d56 100644
--- a/lib/router/layer.js
+++ b/lib/router/layer.js
@@ -13,7 +13,7 @@
  * @private
  */

-var pathRegexp = require('path-to-regexp');
+const { pathToRegexp } = require('path-to-regexp');
 var debug = require('debug')('express:router:layer');

 /**
@@ -42,7 +42,7 @@ function Layer(path, options, fn) {
   this.name = fn.name || '';
   this.params = undefined;
   this.path = undefined;
-  this.regexp = pathRegexp(path, this.keys = [], opts);
+  this.regexp = pathToRegexp(path, this.keys = [], opts);

   // set fast path flags
   this.regexp.fast_star = path === '*'
 >8