Bug#907446: cdrom: Cd-Rom does not start on Geode embeded x86 computer

[Jacek Jaworski]

Package: cdrom
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

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

We use two x86 Geode embeded x86 computers:
1. Kontron MOPSlcdLX - PC/104 with AMD Geode™ LX800
2. PC104 TF-PFM-540I-B10
Both didn't boot with Liteon external Usb Dvd-Rw drive.

   * What led up to the situation?
Afer I burn boot Debian image on Cd-Rw disk and when I try to boot from 
Usb Dvd-Rw.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I try to install Debian on Geode based embeded x86 computer.
   * What was the outcome of this action?
Debian install system failed to boot.
   * What outcome did you expect instead?
I want to install Debian without hacks on desired flash-card connected 
to Geode.

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


-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i586)

Kernel: Linux 4.9.0-8-686 (SMP w/1 CPU core)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#907399: cups-browsed: munmap_chunk(): invalid pointer

[Didier 'OdyX' Raboud]

Control: reassign -1 cups-browsed 1.21.0-1
Control: severity -1 important

Hi François,

Your reports seems to point to cups-browsed (from src:cups-filters); hereby 
reassigning.

Till: any clue why this could have happened?

Cheers,
OdyX

Le lundi, 27 août 2018, 16.56:21 h CEST Francois Marier a écrit :
> Once a day, I get a message like this in my logs:
> 
> Aug 27 00:00:02 hostname cups-browsed[6122]: munmap_chunk(): invalid pointer
> Aug 27 00:00:02 hostname systemd[1]: cups-browsed.service: Main process
>  exited, code=dumped, status=6/ABRT
> Aug 27 00:00:02 hostname systemd[1]: cups-browsed.service: Failed with
>  result 'core-dump'.
> 
> Not sure what's crashing since I don't print very often from this machine.


-- 
OdyX

Bug#907445: cdrom: Debian installer on CF card asks for Cd-Rom with packages on Geode

[Jacek Jaworski]

Package: cdrom
Severity: normal

Dear Maintainer,

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

We have 2 computers based on Geode processor:
1. Kontron MOPSlcdLX - PC/104 with AMD Geode™ LX800
2. PC104 TF-PFM-540I-B10
   * What led up to the situation?
We failed to boot from Dvd-Rw Usb connected drive. Then we prepare boot 
CF card and try to install on the other CF card.
Then (supprisingly) Debian installer asks for Cd-Rom in order to 
continue installation. It is unable to install unles you
type /dev/sdb (in our case - we boot from second drive and try to 
install on the first drive).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I try to install Debian from prepared CF installation card.
   * What was the outcome of this action?
The installer asks for Cd-Rom in order to install packages and to 
continue installation process.

   * What outcome did you expect instead?
I suppose installer to be aware device from what it was booted (and 
packages this device provide).

It should ask only in one case: if proprietary packages are needed.

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


-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i586)

Kernel: Linux 4.9.0-8-686 (SMP w/1 CPU core)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#907444: libvirt-daemon: systemd runs (sort-of) in container even when disable

[Peter.Chubb]

Package: libvirt-daemon
Version: 4.6.0-2
Severity: normal

Dear Maintainer,

 I replaced systemd with sysvinit-core inside a libvirt-lxc container
 containing a stretch rootfs.
 I expected not to see any systemd messages in the in-container logs.
 But I see (even though anacron isn't installed in the container):

Aug 28 15:05:14 stage systemd[1]: Started Run anacron jobs.
Aug 28 15:05:14 stage systemd[30916]: anacron.service: Failed at step 
EXEC spawning /usr/sbin/anacron: No such file or directory
Aug 28 15:05:14 stage systemd[1]: anacron.service: Main process exited, 
code=exited, status=203/EXEC
Aug 28 15:05:14 stage systemd[1]: anacron.service: Unit entered failed 
state.
Aug 28 15:05:14 stage systemd[1]: anacron.timer: Adding 1min 49.830702s 
random time.
Aug 28 15:05:14 stage systemd[1]: anacron.service: Failed with result 
'exit-code'.


Inside the container:
# dpkg -l | grep systemd
ii  libsystemd0:amd64232-25+deb9u4amd64 
   systemd utility library
# dpkg -l | grep sysv
ii  sysv-rc  2.88dsf-59.9 all   
   System-V-like runlevel change mechanism
ii  sysvinit-core2.88dsf-59.9 amd64 
   System-V-like init utilities
ii  sysvinit-utils   2.88dsf-59.9 amd64 
   System-V-like utilities
# dpkg -l anacron
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
un  anacron  (no description available)


The other thing that seems to be happening is cron jobs all run twice.
If I stop the in-container cron daemon, they run once but partially in
the wrong namespace (for example, they cannot see the ethernet adapter
but can see the filesystem)

My guess is that somehow either the host systemd-timer or libvirt-daemon
is reading the in-container /etc/crontab and executing the commands there,

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

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

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.13-8
ii  libaudit1   1:2.8.3-1+b1
ii  libavahi-client30.7-4
ii  libavahi-common30.7-4
ii  libblkid1   2.32.1-0.1
ii  libc6   2.27-5
ii  libcap-ng0  0.7.9-1
ii  libcurl3-gnutls 7.61.0-1
ii  libdbus-1-3 1.12.10-1
ii  libdevmapper1.02.1  2:1.02.145-4.1
ii  libfuse22.9.8-2
ii  libgcc1 1:8.2.0-4
ii  libgnutls30 3.5.19-1
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma12.0.11-2.2
ii  libparted2  3.2-21+b1
ii  libpcap0.8  1.8.1-6
ii  libpciaccess0   0.14-1
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3.1
ii  libselinux1 2.8-1+b1
ii  libssh2-1   1.8.0-2
ii  libudev1239-7
ii  libvirt04.6.0-2
ii  libxen-4.8  4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9
ii  libxenstore3.0  4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9
ii  libxml2 2.9.4+dfsg1-7+b1
ii  libyajl22.1.0-2+b3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b1
ii  netcat-openbsd  1.190-2
ii  qemu-kvm1:2.12+dfsg-3

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-sheepdog  
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   4.6.0-2
ii  numad   0.5+20150602-5

-- no debconf information

-- 
Dr Peter Chubb Tel: +61 2 9490 5852  http://ts.data61.csiro.au/
Trustworthy Systems Group Data61, CSIRO (formerly NICTA)

Bug#907292: Can't find package list on server

[David Lawyer]

On Sun, Aug 26, 2018 at 01:16:19PM +1000, Stuart Prescott wrote:
> Control: tags -1 + moreinfo unreproducible
> 
> > Running debootstrap fails because it tries to fetch the package list
> > shown in /var/lib/apt/lists named binary-i386_Packages.  But there is no
> > such file on the server.  Instead there are files: binary-i386_Packages.gz
> > and binary-i386_Packages.xz but it doesn't look for them.  I've run strace
> > on it.  Here's the command I gave and results:
> > 
> > debootstrap --variant=minbase --verbose stretch /minboot
> > http://debian.usu.edu/debian
> 
> Running this same command works just fine here. 
> 
> If 'unxz' from xz-utils is found, then the .xz version is used; bunzip2 will 
> similarly be tried (but isn't on the mirror) and then gunzip is searched for 
> and the .gz file is used.
> 
> From debootstrap.log:
> 
> Resolving debian.usu.edu (debian.usu.edu)... 129.123.104.15
> Connecting to debian.usu.edu (debian.usu.edu)|129.123.104.15|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 7098644 (6.8M) [application/octet-stream]
> Saving to: '«tmpdir»/mini/var/lib/apt/lists/partial/
> debian.usu.edu_debian_dists_stretch_main_binary-amd64_Packages.xz'
> 
> And stracing: 
> 
> execve("/usr/bin/wget", ["wget", "-O", "/home/stuart/tmp/mini/var/lib/apt/
> lists/partial/debian.usu.edu_debian_dists_stretch_main_binary-
> i386_Packages.xz", 
> "http://debian.usu.edu/debian/dists/stretch/main/binary-i386/by-hash/SHA256/
> d07f5e29da93524d0956a1bc00581413e5560156c3350bc22560ee633fb29b3a"]
> 
> Removing xz-utils, strace shows:
> 
> execve("/usr/bin/wget", ["wget", "-O", "«tmpdir»/mini/var/lib/apt/lists/
> partial/debian.usu.edu_debian_dists_stretch_main_binary-amd64_Packages.gz", 
> "http://debian.usu.edu/debian/dists/stretch/main/binary-amd64/by-hash/
> SHA256/9e7870c3c3b5b0a7f8322c323a3fa641193b1eee792ee7e2eedb6eeebf9969f3"]
> 
> (tested against both i386 and amd64)
> 
> > debootstrap needs to find one of the compressed files. download it, and
> > unconpress it.  But it doesn't.
> 
> That is what is supposed to happen (and does for me). Is it possible that you 
> somehow do not have unxz and gunzip available in PATH? 
> 
strace shows them found.  I'll have to look into it more.  wget is never
executed.
> I see that you've created this bug report without using reportbug and from 
> what looks like a non-Debian system -- is the version against which you have 
> reported this bug incorrect? Is there additional information you can provide?

I use Debian but for over 20 years have never done a clean install.  The
last try at updating corrupted my system and some packages will not
configure.  That's why I'm now trying to reinstall linux from scratch.
Running aptitude to try to fetch reportbug (or anything else) just
displays many screenfulls of configuration errors and doesn't fetch
anything.  I got debootstrap via downloading using the Firefox browser and
installed with dpkg.  I downloaded twice and got identical dbootstrap's
(108).  The new drive that I'm trying to bootstrap is in the bay that
contained a failed cd drive so it wouldn't be too easy to boot from cd if
I had one (actually DVDs).  My PC is 12 years old and doesn't boot from a
flash drive.  I'm connecting via free dial-up provided by Southern
California Freenet (I think it's the last FreeNet left in the USA).  Slow
but I'm willing to wait days for upgrading.

> 
> Cheers
> Stuart
> 
> -- 
> Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
> Debian Developer   http://www.debian.org/ stu...@debian.org
> GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
David Lawyer

Bug#907443: libdancer-perl: Make autopkgtests proxy-safe

[Steve Langasek]

Package: libdancer-perl
Version: 1.3400+dfsg-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear maintainers,

The libdancer-perl autopkgtests fail on Ubuntu's infrastructure because they
try to access the configured proxy instead of talking directly to the local
test server:

[...]
t/02_request/20_body.t .. 
1..2
# Selected 127.0.0.11:37639
not ok 1 - req is success

#   Failed test 'req is success'
#   at t/02_request/20_body.t line 30.
not ok 2 - raw_data is OK

#   Failed test 'raw_data is OK'
#   at t/02_request/20_body.t line 31.
#  got: 'http://www.w3.org/TR/html4/strict.dtd;>
# 
# 
# ERROR: The requested URL could not be retrieved
# 

Bug#783307: ITP: fzf -- General-purpose command-line fuzzy finder

[Mo Zhou]

Hi Tom,

Have you found any sponsor for the fzf package?
And are you still interested in maintaining it?

> https://github.com/tomfitzhenry/pkg-fzf

Best,

Bug#907441: asylum FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: asylum
Version: 0.3.2-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

asylum fails to cross build from source, because it uses the build
architecture compiler. Usually, using dh_auto_build fixes this in
similar cases, but here doing so causes more warnings. asylum's Makefile
uses CC to store the C++ compiler and when dh_auto_build passes a C
cross compiler via CC, things go badly wrong. I suggest renaming the
variable to the standard variable CXX and doing that fixes the cross
build. Please consider applying the attached patch.

Helmut
diff --minimal -Nru asylum-0.3.2/debian/changelog asylum-0.3.2/debian/changelog
--- asylum-0.3.2/debian/changelog   2018-05-17 13:34:38.0 +0200
+++ asylum-0.3.2/debian/changelog   2018-08-27 21:40:59.0 +0200
@@ -1,3 +1,12 @@
+asylum (0.3.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ cross.patch/Makefile: Use CXX for the C++ compiler.
+
+ -- Helmut Grohne   Mon, 27 Aug 2018 21:40:59 +0200
+
 asylum (0.3.2-3) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru asylum-0.3.2/debian/patches/cross.patch 
asylum-0.3.2/debian/patches/cross.patch
--- asylum-0.3.2/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ asylum-0.3.2/debian/patches/cross.patch 2018-08-27 21:40:59.0 
+0200
@@ -0,0 +1,20 @@
+--- asylum-0.3.2.orig/Makefile
 asylum-0.3.2/Makefile
+@@ -2,7 +2,7 @@
+ #HOST=mingw
+ #HOST=haiku
+ 
+-CC=g++
++CXX=g++
+ RM=rm
+ CFLAGS= -O3
+ COPTS=  $(CFLAGS) -funsigned-char \
+@@ -95,7 +95,7 @@
+ build: asylum$(EXE)
+ 
+ asylum$(EXE): $(SRCS) $(OS_SOURCE) asylum.h Makefile
+-  $(CC) $(COPTS) $(LDFLAGS) -o asylum$(EXE) $(SRCS) $(OS_SOURCE) $(LIBS)
++  $(CXX) $(COPTS) $(LDFLAGS) -o asylum$(EXE) $(SRCS) $(OS_SOURCE) $(LIBS)
+ 
+ clean:
+   $(RM) asylum$(EXE)
diff --minimal -Nru asylum-0.3.2/debian/patches/series 
asylum-0.3.2/debian/patches/series
--- asylum-0.3.2/debian/patches/series  2018-05-17 13:34:38.0 +0200
+++ asylum-0.3.2/debian/patches/series  2018-08-27 21:40:59.0 +0200
@@ -3,3 +3,4 @@
 0003-loadconfig-fix-scanf-buffer-overflow.patch
 0004-swi_blitz_hammerop-missing-fclose.patch
 0005-dropprivs-add-error-checking.patch
+cross.patch
diff --minimal -Nru asylum-0.3.2/debian/rules asylum-0.3.2/debian/rules
--- asylum-0.3.2/debian/rules   2018-05-17 13:34:38.0 +0200
+++ asylum-0.3.2/debian/rules   2018-08-27 21:40:56.0 +0200
@@ -7,7 +7,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) CFLAGS="$(CFLAGS)"
+   dh_auto_build -- CFLAGS="$(CFLAGS)"
 
 override_dh_auto_install-arch:
$(MAKE) install-binary \

Bug#907313: Lack of guidelines on purging conffiles in stateless packages

[Russ Allbery]

Guillem Jover  writes:

> I think the distinguishing factor here is whether a pathname is a
> configuration file or a configuration fragments directory. So, I'd
> say:

>  * configuration file → /etc/foo/foo.conf → remove on purge, even if
>the package did not ship a file there, because this is "virtually"
>owned by the program/package (and I can see in the future these
>being marked as ghost conffiles in the dpkg metadata manifest, for
>example).
>  * configuration fragment directory → /etc/foo/foo.d/* → do not remove
>on purge, unless the package ships or creates these itself. This
>preserves local admin changes, and changes from 3rd party packages.

This makes sense to me, and your first case would apply if the package has
a specific number of configuration files that can be shadowed in /etc.

My subjective impression (and I might be wrong here) is that it's more
common for packages that support this style of configuration to also
support fragment directories, for all the reasons that fragment
directories are a good idea anyway.  So I think this policy would lead to
normally not removing most administrator configuration.  Does that sound
right?

-- 
Russ Allbery (r...@debian.org)   

Bug#907440: libvirt-daemon: libvirtd spams host logs with `cant open .../memory.memsw.usage_in_bytes'

[Peter.Chubb]

Package: libvirt-daemon
Version: 4.6.0-2
Severity: minor

Dear Maintainer,
I'm running lots of containerised systems using libvirt-lxc.  The systems run 
on a machine with more than 300Gb RAM, and no swap.  So I haven't enabled swap
accounting on the host kernel.

Every few seconds, I see a pair of messages like this in the logs for each
container on the system:
   Aug 28 12:00:21 hostname libvirtd[39700]: 2018-08-28 02:00:21.467+: 
39707: error : virFileReadAll:1434 : Failed to open file 
'/sys/fs/cgroup/memory/machine/lxc-41320-containername.libvirt-lxc/memory.memsw.usage_in_bytes':
 No such file or directory
   Aug 28 12:00:21 hostname libvirtd[39700]: 2018-08-28 02:00:21.467+: 
39707: error : virCgroupGetValueStr:819 : Unable to read from 
'/sys/fs/cgroup/memory/machine/lxc-41320-containername.libvirt-lxc/memory.memsw.usage_in_bytes':
 No such file or directory

I expect a single warning message when each container is started, then nothing.
The swap accounting files aren't magically going to appear without a reboot.

Peter C

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

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

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.13-8
ii  libaudit1   1:2.8.3-1+b1
ii  libavahi-client30.7-4
ii  libavahi-common30.7-4
ii  libblkid1   2.32.1-0.1
ii  libc6   2.27-5
ii  libcap-ng0  0.7.9-1
ii  libcurl3-gnutls 7.61.0-1
ii  libdbus-1-3 1.12.10-1
ii  libdevmapper1.02.1  2:1.02.145-4.1
ii  libfuse22.9.8-2
ii  libgcc1 1:8.2.0-4
ii  libgnutls30 3.5.19-1
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma12.0.11-2.2
ii  libparted2  3.2-21+b1
ii  libpcap0.8  1.8.1-6
ii  libpciaccess0   0.14-1
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3.1
ii  libselinux1 2.8-1+b1
ii  libssh2-1   1.8.0-2
ii  libudev1239-7
ii  libvirt04.6.0-2
ii  libxen-4.8  4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9
ii  libxenstore3.0  4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9
ii  libxml2 2.9.4+dfsg1-7+b1
ii  libyajl22.1.0-2+b3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b1
ii  netcat-openbsd  1.190-2
ii  qemu-kvm1:2.12+dfsg-3

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-sheepdog  
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   4.6.0-2
ii  numad   0.5+20150602-5

-- no debconf information

-- 
Dr Peter Chubb Tel: +61 2 9490 5852  http://ts.data61.csiro.au/
Trustworthy Systems Group Data61, CSIRO (formerly NICTA)

Bug#906284: CC0 is short

[Julien Puydt]

Hi,

On 27/08/2018 19:09, Chris Lamb wrote:


Thanks for that. Do you happen to have some "bad" ones handy too?


I don't have anything handy, but I remembered : when I packaged 
minetest-mod-unified-inventory and found it used CC0, I used 
codesearch.debian.net, to find other packages where CC0 was used.


So perhaps it's possible to use codesearch.d.n to find bad examples too, 
by looking at a known-wrong expression in path:debian/copyright? I 
naively searched "only some of the key features" and "not a license and 
has no legal value" found only the source of the lintian check in which 
I already took the words anyway.


Does that check actually detect anything?

jpuydt on irc.debian.org

Bug#907313: Lack of guidelines on purging conffiles in stateless packages

[Guillem Jover]

On Sun, 2018-08-26 at 12:17:23 -0700, Russ Allbery wrote:
> Gioele Barabucci  writes:
> > For instance, apache (the application) is configured by some stub conf
> > in `/etc/apache` that loads *.conf files from directories such as
> > `/etc/apache2/sites-enabled/`. The real files are usually in
> > `/etc/apache2/sites-available/`.
> 
> > The purge process for the apache (the package) removes the configuration
> > files it has installed and the symlinks it has created but leaves the
> > configuration files written by the sysadmin alone.
> 
> Yeah, this is a very interesting example.  If the administrator puts a
> bunch of local configuration in /etc/apache2/sites-available and related
> directories, those are pretty clearly intended to be configuration files
> of Apache, but should we delete everything in those directories on purge?
> I can imagine someone being *quite* surprised by that.
> 
> Another thing that makes this less obvious is that this mechanism is
> frequently used for cross-package cooperation.  In a sense, everything
> under /etc/apache2 is a configuration file for Apache, but a bunch of
> other packages do install files into that hierarchy (including things that
> don't strongly depend on Apache), so running rm -rf in postrm purge isn't
> necessarily correct.

I think the distinguishing factor here is whether a pathname is a
configuration file or a configuration fragments directory. So, I'd
say:

 * configuration file → /etc/foo/foo.conf → remove on purge, even if
   the package did not ship a file there, because this is "virtually"
   owned by the program/package (and I can see in the future these
   being marked as ghost conffiles in the dpkg metadata manifest, for
   example).
 * configuration fragment directory → /etc/foo/foo.d/* → do not remove
   on purge, unless the package ships or creates these itself. This
   preserves local admin changes, and changes from 3rd party packages.

Thanks,
Guillem

Bug#836266: [Pkg-privacy-maintainers] Bug#836266: Bug#836266: Bug#836266: Bug#836266: dirmngr: Please disable "use-tor" by default.

[Antoine Beaupré]

>  4. This actually parses the packet as well and this is where things get
> a little more complicated: what's an acceptable response from a
> keyserver?  This is another thing that's delegated to GnuPG right
> now, but it would be interesting to formalize this and (self-?)
> authenticate the key material. Or can we delegate *just* that bit to
> GnuPG?

I guess this whole re-implementation feasibility question can be
summarized as such:

Is `gpg --import` safe to run against untrusted data? If not, how
does it differ from `gpg --recv-keys`?

A.

-- 
They say that time changes things, but you actually have to change
them yourself.   - Andy Warhol

Bug#907401: RFS: dbab/1.3.2-2 [new version update]

[Tong Sun]

On Mon, Aug 27, 2018 at 1:49 PM Tong Sun wrote:
>
> On Monday, August 27, 2018, Andrey Rahmatullin  wrote:
>>
>> On Mon, Aug 27, 2018 at 11:30:55AM -0400, Tong Sun wrote:
>> > I updated my dbab to a newer version -- to accommodate for the bug
>> > #903065, which requested to update Build-Depends: ruby-ronn -> ronn.
>> You should close that bug in the changelog entry then, see
>> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-bugfix
>
>
> Oh, yeah, forgot about that.
>
> Will close it in the changelog entry.

Done. https://mentors.debian.net/package/dbab will be updated shortly.

  * Fix build because ronn split out of ruby-ronn (closes: #903065)
  * Update Standards-Version to 4.2.1, compat level to 11

Bug#907439: plasma-desktop: plasma panel freezes when handling usb memory stick

[Jiri Kanicky]

Package: plasma-desktop
Version: 4:5.13.4-1
Severity: important

Dear Maintainer,

It seems that plasma panel freezes when any kind of storage becomes unavailble. 
Please can you remove all storage components from the panel and make it rock 
stable. This is the most annoying bug from the whole KDE. I expect things to 
break, but panel should keep working.

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

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

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.13.4-1
ii  kactivitymanagerd5.13.4-1
ii  kde-cli-tools4:5.13.4-1
ii  kded55.49.0-1
ii  kio  5.49.0-1
ii  kpackagetool55.49.0-1
ii  libappstreamqt2  0.12.2-2
ii  libc62.27-5
ii  libcanberra0 0.30-6
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8.2.0-4
ii  libkf5activities55.49.0-1
ii  libkf5activitiesstats1   5.49.0-1
ii  libkf5archive5   5.49.0-1
ii  libkf5auth5  5.49.0-1
ii  libkf5baloo5 5.49.0-1
ii  libkf5codecs55.49.0-1
ii  libkf5completion55.49.0-1
ii  libkf5configcore55.49.0-1
ii  libkf5configgui5 5.49.0-1
ii  libkf5configwidgets5 5.49.0-1
ii  libkf5coreaddons55.49.0-1
ii  libkf5dbusaddons55.49.0-1
ii  libkf5declarative5   5.49.0-1
ii  libkf5emoticons-bin  5.49.0-1
ii  libkf5emoticons5 5.49.0-1
ii  libkf5globalaccel-bin5.49.0-1
ii  libkf5globalaccel5   5.49.0-1
ii  libkf5guiaddons5 5.49.0-1
ii  libkf5i18n5  5.49.0-1
ii  libkf5iconthemes55.49.0-1
ii  libkf5itemmodels55.49.0-1
ii  libkf5itemviews5 5.49.0-1
ii  libkf5jobwidgets55.49.0-1
ii  libkf5kcmutils5  5.49.0-1
ii  libkf5kdelibs4support5   5.49.0-1
ii  libkf5kiocore5   5.49.0-1
ii  libkf5kiofilewidgets55.49.0-1
ii  libkf5kiowidgets55.49.0-1
ii  libkf5newstuff5  5.49.0-1
ii  libkf5notifications5 5.49.0-1
ii  libkf5notifyconfig5  5.49.0-1
ii  libkf5package5   5.49.0-1
ii  libkf5parts5 5.49.0-1
ii  libkf5people55.49.0-1
ii  libkf5peoplewidgets5 5.49.0-1
ii  libkf5plasma55.49.0-1
ii  libkf5plasmaquick5   5.49.0-1
ii  libkf5quickaddons5   5.49.0-1
ii  libkf5runner55.49.0-1
ii  libkf5service-bin5.49.0-1
ii  libkf5service5   5.49.0-1
ii  libkf5solid5 5.49.0-1
ii  libkf5sonnetui5  5.49.0-1
ii  libkf5wallet-bin 5.49.0-1
ii  libkf5wallet55.49.0-1
ii  libkf5widgetsaddons5 5.49.0-1
ii  libkf5windowsystem5  5.49.0-1
ii  libkf5xmlgui55.49.0-1
ii  libkfontinst54:5.13.4-1
ii  libkfontinstui5  4:5.13.4-1
ii  libkworkspace5-5 4:5.13.4-1
ii  libphonon4qt5-4  4:4.10.1-1
ii  libpulse-mainloop-glib0  11.1-5
ii  libpulse011.1-5
ii  libqt5concurrent55.11.1+dfsg-6
ii  libqt5core5a 5.11.1+dfsg-6
ii  libqt5dbus5  5.11.1+dfsg-6
ii  libqt5gui5   5.11.1+dfsg-6
ii  libqt5network5   5.11.1+dfsg-6
ii  libqt5printsupport5  5.11.1+dfsg-6
ii  libqt5qml5   5.11.1-4
ii  libqt5quick5 5.11.1-4
ii  libqt5quickwidgets5  5.11.1-4
ii  libqt5sql5   5.11.1+dfsg-6
ii  libqt5svg5 

Bug#836266: [Pkg-privacy-maintainers] Bug#836266: Bug#836266: Bug#836266: Bug#836266: dirmngr: Please disable "use-tor" by default.

[Antoine Beaupré]

On 2017-01-10 18:28:59, Daniel Kahn Gillmor wrote:
> On Tue 2017-01-10 14:15:43 -0500, Antoine Beaupre wrote:
>> As things stand now, I see no choice but to stop using parcimonie, which
>> means:
>>
>>  1. i will not update my keyring in a timely manner anymore, or;
>>  2. i will reveal my keyring social graph to the keyserver and
>> possible attackers
>>
>> That seems like the opposite of what parcimonie is trying to
>> accomplish.
>
> fwiw, the ideal long-term fix here is that the logic of parcimonie gets
> folded into dirmngr itself, and just works automatically if tor is
> available.
>
> i've got sketches for how this would work if anyone has the time to work
> on it.
>
> Please see https://bugs.gnupg.org/gnupg/issue1827 for more details.

We're now a year and a half later and I've upgraded my box to Debian
Buster. Remembering this issue (and that I had no mechanism for key
refresh still!) I figured I would give it a shot again. So I installed
parcimonie and let it run for a while. It seems to do its thing but it's
hard to tell as I'm not sure if there are logs anywhere.

That said, `use-tor` is still as problematic as it was back in
stretch. As a random example, I tried to search for a key on a
keyserver, and gpg just failed to get anything. The diagnostics are, as
usual, fairly limited, but the error Phil Morrell got is pretty typical:

   Failed to fetch key 6ACBAD6A729326258CF725C6E7519C8D747F00DC: gpg: 
keyserver receive failed: No data

Since it's not the first time I have had this problem, I have full debug
enabled in dirmngr (hello metadata leakage!). This translate into this
error:

2018-08-27 21:20:17 dirmngr[9652.6] erreur d'accès à « 
https://193.164.133.100:443/pks/lookup?op=index=mr=milan%40debian%2Eorg
 » : état HTTP 502
2018-08-27 21:20:17 dirmngr[9652.6] command 'KS_SEARCH' failed: Pas de données
2018-08-27 21:20:17 dirmngr[9652.6] DBG: chan_6 -> ERR 167772218 Pas de données 


What's dumb here is that dirmngr doesn't fallback to other
servers. Repeated attempts to search keys will fail with the same
incomprehensible and useless error message. ("HTTP status 502" would
actually be more useful for debugging, for example, along with which
host is responsible - but GnuPG only blesses us only with "no data".) So
the bug in dirmngr here at least is that it doesn't rotate to the next
available server in the pool when failing with tor.

The workaround, as Morrell explained, is to restart dirmngr which
magically picks another host and moves on.

I know this is not Parcimonie's fault. It's gnupg's fault or, more
precisely, dirmngr's, but it seems difficult to change things over
there: this would require rewriting dirmngr's network routines or
reimplementing parcimonie within dirmngr itself.

After spending years fighting with GnuPG at various levels, neither
looks very attractive or accessible to me as a developer right now.

Instead, I've started thinking about what a parcimonie rewrite would
look like, one that would *not* depend on dirmngr (or, in fact, any
specific OpenPGP implementation). If you permit, I would like to use
this space to brainstorm such a design, which can be broken up into the
following step:

 1. build a random list of keys to fetch, idempotently
 2. talk with Tor
 3. fetch keys from a keyserver
 4. validate the keys (!)
 5. reinject in the data store

In details, it would look something like this:

 1. The first step is to enumerate keys. This requires talking to the
keystore: it can be done with gpg --export but that means a lot of
data. Parsing the `--list-keys --with-colons` output might be
mandated here, as much as it hurts me to even think about this. This
would load a list of fingerprints to refresh. This list should be
sorted internally, and then copied and shuffled so we have a list of
keys to iterate over reliably. This process can be repeated after a
timeout: new keys would be added, sorted, to the sorted list and
then added in a random location in the shuffled list.

 2. Fetching Tor is not that complicated, and is the cornerstone of this
program. Talking to it is simply like talking with a SOCKS5 proxy,
something which Python requests supports since 2.10, if my memory
serves me right (jessie-backports and above).

 3. Then parcimonie also needs to talk to keyservers: right now it lets
gnupg do the talking, but this is actually fairly easy as well, as
HKP was implemented on top of a few HTTP verbs. I have implemented
such a client in the PGPy library in a few lines of code:


https://github.com/SecurityInnovation/PGPy/blob/d5e46733df34f14f83bda5ed2bc0bcc13bd971e3/pgpy/types.py#L267

 4. This actually parses the packet as well and this is where things get
a little more complicated: what's an acceptable response from a
keyserver?  This is another thing that's delegated to GnuPG right
now, but it would be interesting to formalize this and (self-?)
authenticate the key material. Or 

Bug#907380: tex-common: setting up of tex-common fails

[Norbert Preining]

Hi,

> root@fulvio:/home/fc# update-updmap 
> Regenerating '/var/lib/texmf/updmap.cfg-DEBIAN'... done.
> Regenerating '/var/lib/texmf/updmap.cfg-TEXLIVEDIST'... done.
> update-updmap has updated the following file(s):
>   /var/lib/texmf/updmap.cfg-DEBIAN
>   /var/lib/texmf/updmap.cfg-TEXLIVEDIST
> If you want to activate the changes in the above file(s),
> you should run updmap-sys or updmap.

That looks absolutely fine.

> the log says bin/mkdir is missing, but line 235 recites:
> mkdir -p "$destdir"

Which "log" ? update-updmap doesn't write anything else then what is
shown above. What kind of log are you talking about.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#907419: Debian tlmgr usermode updates

[Norbert Preining]

tags 907419 + pending
tags 907415 + pending
thanks

>   $ tlmgr --usermode list
>   (running on Debian, switching to user mode!)
>   ...
> 
> Please silence this message when the --usermode option was explicitly
> enabled.

Done.

> Please make the messages more helpful, for example:
> 
>   $ tlmgr update
>   (running on Debian, switching to user mode!)
>   /home/jwilk/texmf does not exist; run "tlmgr init-usertree" first.

What it does now is:

$ tlmgr update
(running on Debian, switching to user mode!)
Cannot determine type of tlpdb from /home/norbert/texmf!
tlmgr: running in usermode, did you call `tlmgr init-usertree'?
$

>   $ tlmgr init-usertree
>   Successfully initialized TLPDB in /home/jwilk/texmf/.

$ tlmgr init-usertree
$ 

The warning about "running on Debian" does not appear when
--user-mode
is given.

Hope that helps

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#907048: fonts-noto-cjk: Consider increasing noto cjk font priority on Chinese systems

[Boyuan Yang]

On Tue, 28 Aug 2018 08:09:09 +0800 ChangZhuo Chen =?utf-8?B?KOmZs+aYjOWArCk=?= 
 wrote:
> On Thu, Aug 23, 2018 at 08:56:02AM -0400, Boyuan Yang wrote:
> > Package: fonts-noto-cjk
> > Severity: normal
> > X-Debbugs-CC: chinese-develop...@lists.alioth.debian.org czc...@debian.org
> > Tags: patch l10n
> > 
> > Dear Fonts Team, Chinese developers and czchen,
> > 
> > As previously discussed on the Chinese list, we want to make Noto CJK 
fonts 
> > the "default" one on all Chinese environments, or at least on those 
Chinese 
> > locales that are supported by Noto CJK fonts [1].As a result, I'm 
proposing to 
> > tweak its fontconfig config files to achieve that.
> > 
> > This would also workaround some weird results on fontconfig's font 
selecting, 
> > e.g., on installing fonts-arphic-gkai00mp (which is rather legacy these 
days), 
> > fontconfig on zh_CN systems would receive a (weirdly) high priority for 
all 
> > sans, sans-serif, serif and monospace fonts.
> 
> Hi,
> 
> Thanks for the patch. Could you help to send PR to salsa [salsa] so that
> it is easier for us to merge and release it.
> 
> 
> [salsa] https://salsa.debian.org/fonts-team/fonts-noto-cjk

Merge Request submitted:

https://salsa.debian.org/fonts-team/fonts-noto-cjk/merge_requests/1

--
Regards,
Boyuan Yang


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

Bug#907352: please make texinfo generation reproducible

[Nicholas D Steeves]

Hi Dmitry!

On Mon, Aug 27, 2018 at 10:42:20AM +0300, Dmitry Shachnev wrote:
> Control: forwarded -1 https://github.com/sphinx-doc/sphinx/pull/5359
> 
> Hi Nicholas!
> 
> On Sun, Aug 26, 2018 at 04:32:51PM -0400, Nicholas D Steeves wrote:
> > Here is an example of the unreproducibility on DebCI:
> >   
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/elpy.html
> 
> I have created an upstream pull request that should fix this issue:
> https://github.com/sphinx-doc/sphinx/pull/5359
> 
> Any testing/feedback is appreciated.

Wow, thank you for working on this :-) Yes, if you'd like I can set up
a local copy of src:python-sphinx, import your patch, test it, and
forward the patch to this bug (or create a PR).

If I haven't done this in 48h, please ping me.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#907438: ruby-toml-rb: Bad 'require' in first line of gem

[David Caldwell]

Package: ruby-toml-rb
Version: 1.0.0-1
Severity: important

Dear Maintainer,

$ apt install ruby-toml-rb
$ ruby -r toml-rb -e ''
Traceback (most recent call last):
3: from 
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
2: from 
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
1: from /usr/lib/ruby/vendor_ruby/toml-rb.rb:1:in `'
/usr/lib/ruby/vendor_ruby/toml-rb.rb:1:in `require_relative': cannot load 
such file -- /usr/lib/ruby/init (LoadError)
$ head -1 /usr/lib/ruby/vendor_ruby/toml-rb.rb
require_relative '../init'
$ ls /usr/lib/ruby/init*
ls: cannot access '/usr/lib/ruby/init*': No such file or directory

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 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 ruby-toml-rb depends on:
ii  ruby  1:2.5.1
ii  ruby-citrus   3.0.2-1
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.484-2
ii  ruby2.0 [ruby-interpreter]2.0.0.484+really457-3
ii  ruby2.1 [ruby-interpreter]2.1.5-4
ii  ruby2.2 [ruby-interpreter]2.2.4-1

ruby-toml-rb recommends no packages.

ruby-toml-rb suggests no packages.

-- no debconf information

Bug#907352: please make texinfo generation reproducible

[Nicholas D Steeves]

On Mon, Aug 27, 2018 at 07:43:57AM +0100, Chris Lamb wrote:
> severity 907352 wishlist
> thanks
> 
> > I've set the severity of this bug to important, because I believe
> > this bug affects all packages that generate info pages using Sphinx.
> 
> Whilst this might affect all packages I don't believe the underlying
> issue warrants that original severity and/or should be worked on before
> other issues.

That's fair, although I would have though normal was more appropriate.

> (Is there a line-item in the issues.yml Reproducible Builds notes.git
> repo?)

At this time reproducible-builds/reproducible-notes/issues.yml does
not contain a hint.  That is why I had to resort to asking for help
after the diffoscope baffled me :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#907415: tlmgr: unhelpful "Cannot determine type of tlpdb from /home/.../texmf!"

[Norbert Preining]

Hi Jakub,

thanks for this and the other bug report concerning user mode.

>   $ tlmgr update
>   (running on Debian, switching to user mode!)
>   Cannot determine type of tlpdb from /home/jwilk/texmf!
>   cannot setup TLPDB in /home/jwilk/texmf at /usr/bin/tlmgr line 6513.
> 
> The error messages gave me no clue what is wrong.

Yes. It is already a big concession that 
- I implemented user mode in tlmgr (I'm also upstream)
- included tlmgr in Debian
because in fact tlmgr should *NOT* be in Debian ;-)

>   $ tlmgr update
>   (running on Debian, switching to user mode!)

the first message is automatically shipped out every time on Debian
to make it clear that anything related to tlmgr in Debian is in 
user mode.

I do not intend to disable this.

>   /home/jwilk/texmf does not exist; run "tlmgr init-usertree" first.

Maybe ...

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#880099: mariadb-server-10.1: logrotate script does not work - permission denied

[Norbert Preining]

Hi Faustin,

> thank you for your report.

thanks for coming back, but that is nearly a year ago and in the
meantime I have done something else to fix it - don't ask me what
(reinstalling? creating users? sorry, no idea anymore).

I guess you can close this bug.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#907315: git: "git bundle verify" segfaults when out of repo

[Bernhard Übelacker]

Hello Samuel Hym,
I just tried to reproduce the segfault.


(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fc3d443e2f1 in __GI_abort () at abort.c:79
#2  0x55b095852436 in BUG_vfl (file=, line=, 
fmt=0x55b0958a9250 "attempting to get main_ref_store outside of repository", 
params=params@entry=0x7ffc469b4980) at usage.c:230
#3  0x55b095852bbf in BUG_fl (file=file@entry=0x55b0958a9536 "refs.c", 
line=line@entry=1687, fmt=fmt@entry=0x55b0958a9250 "attempting to get 
main_ref_store outside of repository") at usage.c:238
#4  0x55b0957f0a14 in get_main_ref_store (r=0x55b095b39fc0 ) at 
refs.c:1687
#5  0x55b09580e329 in handle_revision_pseudo_opt (argc=1, flags=, argv=0x7ffc469b4b98, revs=0x7ffc469b4bb0, submodule=0x0) at 
revision.c:2191
#6  setup_revisions (argc=, argc@entry=2, 
argv=argv@entry=0x7ffc469b4b90, revs=revs@entry=0x7ffc469b4bb0, 
opt=opt@entry=0x0) at revision.c:2341
#7  0x55b09576b5ac in verify_bundle (header=header@entry=0x7ffc469b54b0, 
verbose=verbose@entry=1) at bundle.c:157
#8  0x55b0956d6335 in cmd_bundle (argc=1, argv=0x7ffc469b58a0, 
prefix=) at builtin/bundle.c:43
#9  0x55b0956c7825 in run_builtin (argv=, argc=, p=) at git.c:417
#10 handle_builtin (argc=, argv=) at git.c:632
#11 0x55b0956c87c5 in run_argv (argv=0x7ffc469b5630, argcp=0x7ffc469b563c) 
at git.c:684
#12 cmd_main (argc=, argv=) at git.c:761
#13 0x55b0956c74ef in main (argc=4, argv=0x7ffc469b5888) at common-main.c:45

(gdb) list get_main_ref_store
1680
1681struct ref_store *get_main_ref_store(struct repository *r)
1682{
1683if (r->refs)
1684return r->refs;
1685
1686if (!r->gitdir)
1687BUG("attempting to get main_ref_store outside of 
repository");
1688
1689r->refs = ref_store_init(r->gitdir, REF_STORE_ALL_CAPS);
1690return r->refs;
1691}


I think a call to "BUG" is probably too much.
Probably a call to "die" could be more appropriate.
E.g. like "git diff" printing "Not a git repository".
Attached patch does just replace the "BUG" by "die".


Kind regards,
Bernhard
From a6cdb806c3540bf96b7dc8e876b4dcbe8d735eea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Tue, 28 Aug 2018 02:49:53 +0200
Subject: [PATCH] Replace bug by die to avoid segfault or writing a core dump.

Bug-Debian: https://bugs.debian.org/907315
---
 refs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/refs.c b/refs.c
index 0eb379f..512139a 100644
--- a/refs.c
+++ b/refs.c
@@ -1684,7 +1684,7 @@ struct ref_store *get_main_ref_store(struct repository *r)
 		return r->refs;
 
 	if (!r->gitdir)
-		BUG("attempting to get main_ref_store outside of repository");
+		die(_("attempting to get main_ref_store outside of repository"));
 
 	r->refs = ref_store_init(r->gitdir, REF_STORE_ALL_CAPS);
 	return r->refs;
-- 
2.18.0



apt update
apt install git git-dbgsym systemd-coredump gdb devscripts dpkg-dev mc
apt build-dep git


mkdir git/orig -p
cdgit/orig
apt source git
cd ../..


mkdir git-test1/git-test -p
cdgit-test1/git-test
git init
echo test > test
git add .
git config user.email "y...@example.com"
git config user.name "Your Name"
git commit -m "Initial commit."
cd ../..


mkdir git-test2
cdgit-test2
git clone /home/benutzer/git-test1/git-test
cd git-test/
echo test2 > test2
git add .
git config user.email "y...@example.com"
git config user.name "Your Name"
git commit -m "Commit 2."
git bundle create /home/benutzer/repo.bundle master
cd ../..


cdgit-test1/git-test

LANG=C git bundle verify /home/benutzer/repo.bundle
The bundle contains this ref:
4c1173045ccb4e3625cf333cbcbc5486c9dda8ce refs/heads/master
The bundle records a complete history.
/home/benutzer/repo.bundle is okay

cd ../..


LANG=C git bundle verify /home/benutzer/repo.bundle
BUG: refs.c:1687: attempting to get main_ref_store outside of repository
Abgebrochen (Speicherabzug geschrieben)


# rm git-test1/ git-test2/ repo.bundle  -rf




# coredumpctl gdb
   PID: 4420 (git)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 6 (ABRT)
 Timestamp: Tue 2018-08-28 02:24:52 CEST (7s ago)
  Command Line: git bundle verify /home/benutzer/repo.bundle
Executable: /usr/bin/git
 Control Group: /user.slice/user-1000.slice/session-3.scope
  Unit: session-3.scope
 Slice: user-1000.slice
   Session: 3
 Owner UID: 1000 (benutzer)
   Boot ID: 6368545921ab4b9f816f147460ff8390
Machine ID: 32f43b50ac8c4b21941bc0b02f8e7811
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.git.1000.6368545921ab4b9f816f147460ff8390.4420.153541589200.lz4
   Message: Process 4420 (git) of user 1000 dumped core.

Stack trace of thread 4420:
#0  0x7fc3d443cf3b __GI_raise (libc.so.6)
#1  0x7fc3d443e2f1 __GI_abort (libc.so.6)
   

Bug#907437: debbugs creates wrong 'Resent-CC' field

[Martin Castillo]

Package: debbugs

Hi,

I'm subscribed to the guix-patc...@lists.gnu.org mailing list and
saw that debbugs seems to add a 'Resent-CC:' field to the messages that
it bounces.

According to  the
second 'c' should be lowercase: Resent-Cc:

I checked the debbugs git repo and it seems to be created in
scripts/process:814.


$ git log -p -L /Resent-CC/,+1:scripts/process
says this has been since the first commit.

Greetings,
Martin Castillo

Bug#907048: fonts-noto-cjk: Consider increasing noto cjk font priority on Chinese systems

[陳昌倬]

On Thu, Aug 23, 2018 at 08:56:02AM -0400, Boyuan Yang wrote:
> Package: fonts-noto-cjk
> Severity: normal
> X-Debbugs-CC: chinese-develop...@lists.alioth.debian.org czc...@debian.org
> Tags: patch l10n
> 
> Dear Fonts Team, Chinese developers and czchen,
> 
> As previously discussed on the Chinese list, we want to make Noto CJK fonts 
> the "default" one on all Chinese environments, or at least on those Chinese 
> locales that are supported by Noto CJK fonts [1].As a result, I'm proposing 
> to 
> tweak its fontconfig config files to achieve that.
> 
> This would also workaround some weird results on fontconfig's font selecting, 
> e.g., on installing fonts-arphic-gkai00mp (which is rather legacy these 
> days), 
> fontconfig on zh_CN systems would receive a (weirdly) high priority for all 
> sans, sans-serif, serif and monospace fonts.

Hi,

Thanks for the patch. Could you help to send PR to salsa [salsa] so that
it is easier for us to merge and release it.


[salsa] https://salsa.debian.org/fonts-team/fonts-noto-cjk


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debconf,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#907254: closed by Adam Borowski (Re: Bug#907254: RFS: dvbcut/0.7.3-1)

[Bernhard Übelacker]

Hello Adam Borowski,
thank you very much for sponsoring.

Kind regards,
Bernhard

Bug#907399: cups-browsed: munmap_chunk(): invalid pointer

[Bernhard Übelacker]

Hello Francois Marier,
you could try to get more information from that crash
by installing the package systemd-coredump.

When the next crash happened you might call following:

  $ coredumpctl gdb

Probably with the following debug symbol package installed [1]:

  cups-browsed-dbgsym

Kind regards,
Bernhard

[1] https://wiki.debian.org/AutomaticDebugPackages

Bug#897812: mongodb: ftbfs with GCC-8

[Reiner Herrmann]

Control: forwarded -1 https://github.com/mongodb/mongo/commit/168c8d6

Upstream decided to ignore the warnings for now.


signature.asc
Description: PGP signature

Bug#907436: aptitude: Crashes with SIGABRT and "terminate called after throwing an instance of 'std::logic_error'"

[Axel Beckert]

Package: aptitude
Version: 0.8.11-1
Severity: important

Hi Manuel,

I managed to reproducibly crash aptitude from experimental when
selecting to view (at least one) specific package from the main package
list view by pressing enter when the package is selected. The package
comes from a third party repository.

It outputs "terminate called after throwing an instance of
'std::logic_error'" and then says "Ouch!  Got SIGABRT, dying.." and
dumped core.

I can reproduce this in a clean pbuilder chroot:

Minimal sources.list to reproduce the crash:

deb http://debian.ethz.ch/debian sid main
deb https://jenkins.grml.org/debian zsh main

Minimal useful sources.list to be able to install aptitude from
experimental:

deb http://debian.ethz.ch/debian sid main
deb http://debian.ethz.ch/debian experimental main
deb https://jenkins.grml.org/debian zsh main

Using the later sources.list, I had to do the following in an otherwise
clean chroot:

# apt install ca-certificates wget
# wget https://jenkins.grml.org/debian/C525F56752D4A654.asc
# apt-key add C525F56752D4A654.asc
# apt update
# apt install aptitude=0.8.11-1

Then call aptitude without paramters, type "/^zsh-dbgsym$" to
find the zsh-dbgsym package in the package list and press :
KABOOM!

This only happens with aptitude 0.8.11-1. Downgrading to 0.8.10-9 again
helps to make the issue go away.

Here's the according backtrace:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `aptitude'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f40b52d5800 (LWP 5918))]
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7f40b5a752f1 in __GI_abort () at abort.c:79
#2  0x7f40b5e37943 in __gnu_cxx::__verbose_terminate_handler () at 
../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x7f40b5e3d896 in __cxxabiv1::__terminate(void (*)()) () at 
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x7f40b5e3d8d1 in std::terminate () at 
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x7f40b5e3db04 in __cxxabiv1::__cxa_throw 
(obj=obj@entry=0x55cd321342d0, tinfo=0x7f40b5f21958 , 
dest=0x7f40b5e524e0 ) at 
../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:95
#6  0x7f40b5e39793 in std::__throw_logic_error (__s=0x55cd2f268e78 
"basic_string::_M_construct null not valid")
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x55cd2efc66da in std::__cxx11::basic_string, std::allocator >::_M_construct (
this=this@entry=0x7ffe6c9b57c0, __beg=__beg@entry=0x0, __end=) at /usr/include/c++/8/bits/char_traits.h:350
#8  0x55cd2f1163af in std::__cxx11::basic_string, std::allocator >::_M_construct_aux (
__end=, __beg=0x0, this=0x7ffe6c9b57c0) at 
/usr/include/c++/8/bits/basic_string.h:252
#9  std::__cxx11::basic_string, 
std::allocator >::_M_construct (__end=, 
__beg=0x0, 
this=0x7ffe6c9b57c0) at /usr/include/c++/8/bits/basic_string.h:255
#10 std::__cxx11::basic_string, 
std::allocator >::basic_string > (__a=..., 
__s=, 
this=0x7ffe6c9b57c0) at /usr/include/c++/8/bits/basic_string.h:516
#11 get_label[abi:cxx11](pkgCache::VerIterator const&, pkgRecords const*) 
(ver=..., records=) at ../../../../src/generic/apt/apt.cc:1423
#12 0x55cd2f01eec9 in 
pkg_grouppolicy_info::setup_package_info(pkgCache::PkgIterator const&, 
pkgCache::VerIterator const&, pkg_item_with_subtree*, sigc::signal2*) ()
at ../../src/pkg_info_screen.cc:152
#13 0x55cd2f01ff8b in pkg_info_screen::setup_new_root(pkgCache::PkgIterator 
const&, pkgCache::VerIterator const&) () at ../../src/apt_info_tree.h:60
#14 0x55cd2f02025b in 
pkg_info_screen::pkg_info_screen(pkgCache::PkgIterator const&, 
pkgCache::VerIterator const&) () at ../../src/pkg_info_screen.cc:206
#15 0x55cd2f07ad7e in pkg_info_screen::create (ver=..., pkg=...) at 
../../src/pkg_info_screen.h:61
#16 make_info_screen(pkgCache::PkgIterator const&, pkgCache::VerIterator 
const&) () at ../../src/ui.cc:1026
#17 0x55cd2f07ae6d in show_info_screen(pkgCache::PkgIterator const&, 
pkgCache::VerIterator const&) () at ../../src/ui.cc:1035
#18 0x55cd2f037c52 in pkg_ver_item::show_information 
(this=this@entry=0x55cd3187e7f0) at /usr/include/apt-pkg/cacheiterators.h:189
#19 0x55cd2f038778 in pkg_ver_item::dispatch_key(cwidget::config::key 
const&, cwidget::widgets::tree*) () at ../../src/pkg_ver_item.cc:692
#20 0x7f40b657a406 in 
cwidget::widgets::tree::handle_key(cwidget::config::key const&) () at 
treeitem.h:233
#21 0x55cd2f017b6e in menu_tree::handle_key(cwidget::config::key const&) () 
at ../../src/menu_tree.cc:430
#22 0x7f40b657f78d in 
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () at 
widget.h:217
#23 0x7f40b6567b9e in 

Bug#907416: since latest upgrade krunner does not find applications, and systemtray does not start

[Bernhard Übelacker]

Hello David Erwan,
this sounds like it could be a duplicate of bug #907301 [1].

Is your systray still visible?
If not you can check if this is really your
problem by starting this in a terminal:

QT_LOGGING_RULES="*plasma*=true" plasmawindowed org.kde.plasma.systemtray

And you receive output containing this:

... this plugin is compiled against incompatible Plasma version 340224 This 
build is compatible ...


As a workaround you might try to rebuild plasma-workspace
locally and install the resulting plasma-workspace_*.deb
(Like reported in [2] should that package be enough.)

Another user reported that he could work around the issue
by installing two packages from unstable [3].

Kind regards,
Bernhard


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907301
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907301#60
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907301#75

Bug#907301: Fwd: Bug#907301: plasma-desktop: no system tray whith task bar and no context menu of desktop

[Bernhard Übelacker]

Hello,
forwarding this email, as the bug mail dropped
out of the recipients list.

This user just installed said packages from unstable
and that this worked for him.

Kind regards,
Bernhard


 Weitergeleitete Nachricht 
Betreff:Bug#907301: plasma-desktop: no system tray whith task bar and 
no context menu of desktop
Datum:  Sun, 26 Aug 2018 18:54:10 -0300

Hi, thanks for the info.

After update my buster debian KDE on august saturday 25, myt system-tray
applet dont work anymore.

This work for me:

Download debian packages for SID from https://packages.debian.org

libkf5runner5_5.49.0-1_amd64.deb
libkf5plasma5_5.49.0-1_amd64.deb

Afther this,

sudo dpkg -i libkf5runner5_5.49.0-1_amd64.deb
sudo dpkg -i libkf5plasma5_5.49.0-1_amd64.deb

Now I have my system-tray applet working fine.

atte.

Bug#907324: meson FTBFS on armhf - cannot find -lquadmath

[Jeremy Bicha]

Ubuntu has a patch related to this issue:

https://launchpad.net/ubuntu/+source/meson/0.47.1-1ubuntu2

Ubuntu runs autopkgtests on all of its release architectures.

Thanks,
Jeremy Bicha

Bug#907026: cups-filters: filter failed on Ricoh MP 3554 SP after upgrading to 1.21.0-1

[Ben Caradoc-Davies]

Confirmed fixed in 1.21.1-1. Thanks!

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#907266: RM: sra-sdk [i386] -- ROM; Does not build fir i386 any more - please remove old version of arch i386

[Bernhard Übelacker]

Hello Andreas,

>> But even if this implementation is copied then later a file atomic64.h
>> is missing, that exists for x86_64 but not i386.
> 
> Am I understand correctly that this might be a good reason to make
> ncbi-vdb amd64 only?

Probably it was too late yesterday, because today I cannot get this
atomic64.h failure again (instead error: unknown type name ‘HttpProxy’).


Nevertheless, dropping 32 bit platforms might be reasonable because
upstream is not caring about them anymore, like mentioned in 2016 in the
issue "Please remove explicit -m32/-m64 switch" reported by you to upstream:

... We do have workaround code in all known places, but we no
longer test our code under 32-bits and ...


In the meantime bug [2] got opened in Debian against ncbi-vdb that
is exactly this issue about uint64_msbit found by Ubuntu with
the same proposed change.


Kind regards,
Bernhard


[1] 
https://github.com/ncbi/ncbi-vdb/commit/ec24d0c332cdb738a2f4516ad8bf53dd55743457
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907358

Bug#907435: ITP: antimony -- Computer-aided design CAD tool

[Tiago Bortoletto Vaz]

Package: wnpp
Severity: wishlist
Owner: Tiago Bortoletto Vaz 

* Package name: antimony
  Version : 0.9.3
  Upstream Author : Matthew Keeter and other contributors
* URL : http://www.mattkeeter.com/projects/antimony/3/
* License : MIT
  Programming Lang: C++
  Description : Computer-aided design CAD tool

Antimony is a computer-aided design (CAD) tool from a parallel universe in
which CAD software evolved from Lisp machines rather than drafting tables.

Antimony is built on three mostly-orthogonal axes:
  - A framework for tracking information flow through directed acyclic graphs
  - A geometry engine for doing CSG
  - A standard library of shapes and transforms

Bug#906284: Too many false positives?

[Julien Puydt]

Hi,

in my previous mail, I asked if that test was worth anything.

It's possible to know what packages trigger the test:
https://lintian.debian.org/tags/incomplete-creative-commons-license.html

I had a look from the start of the list (took the 20 first), and found 
only 4 where I would say it's a real positive:


https://sources.debian.org/src/3depict/0.0.19-1/debian/copyright/ (lines 
9-20)


https://sources.debian.org/src/astromenace-data/1.3.2+repack-3/debian/copyright/ 
(lines 34-43)


https://sources.debian.org/src/audacity/2.2.2-1/debian/copyright/
(lines 2146-2149).

https://sources.debian.org/src/bibletime/2.11.1-1/debian/copyright/ 
(lines 45-59)


I have a bad opinion on a test with so many false positives : that means 
people will learn to ignore it and even the few problems it catches will 
get overlooked!


Perhaps just looking at the size of the license text (say < 20 lines) 
would work better? I don't know perl at all, so I can't help write it, 
but I would be quite surprised if that wasn't easy to do for someone 
with a minimal knowledge of the language and the codebase.


I hope it helps,

jpuydt on irc.debian.org

Bug#907434: libemail-stuffer-perl: Combines text-body and html-body if attach_file is added. Both 'body's appear as text

[William Mussatto]

Package: libemail-stuffer-perl
Version: 0.014-1
Severity: normal

Dear Maintainer,

If an email is sent without the $email->attach_file... line both a text body 
and a separate html body part are created
If one or more $email->attach_file line is included both the text body and html 
body appear together without the html wrapper.
The attached file is correctly created with the correct mime type. 
If either the $email->text_body OR $email->html_body are present the email is 
created correctly. 

use Email::Stuffer;
use File::MimeInfo;
...
my $email = Email::Stuffer->new() or die 'Failed to create email 
object';
$email->to($targetEmail);
$email->from($senderEmail);
$email->subject($subject);
$email->header(Sender=>'www-d...@csz.com');
$email->text_body($pWork);
$email->html_body($hWork);
$mime_Type = mimetype(""work/base.css");
$email->attach_file("work/base.css",$mime_Type);
$email->send;
... 

Note: version in buster' has too many dependencies for package versions not in 
stretch.

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

Kernel: Linux 4.9.0-8-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/bash
Init: sysvinit (via /sbin/init)

Versions of packages libemail-stuffer-perl depends on:
ii  libemail-mime-perl1.937-1
ii  libemail-sender-perl  1.300030-2
ii  libparams-util-perl   1.07-3+b1
ii  perl  5.24.1-3+deb9u4

libemail-stuffer-perl recommends no packages.

libemail-stuffer-perl suggests no packages.

-- no debconf information

Bug#907433: ruby-ffaker: FTBFS (TestLoremFR fails)

[Santiago Vila]

Package: src:ruby-ffaker
Version: 2.8.1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
LC_ALL=C.UTF-8 dh build-indep --buildsystem=ruby --with ruby
   dh_update_autotools_config -i -O--buildsystem=ruby
   dh_autoreconf -i -O--buildsystem=ruby
   dh_auto_configure -i -O--buildsystem=ruby
dh_ruby --configure
   dh_auto_build -i -O--buildsystem=ruby
dh_ruby --build
   dh_ruby --build
   dh_auto_test -i -O--buildsystem=ruby
dh_ruby --test
   create-stamp debian/debhelper-build-stamp
 fakeroot debian/rules binary-indep
LC_ALL=C.UTF-8 dh binary-indep --buildsystem=ruby --with ruby

[ ... ]

===
Failure: test_phrase(TestLoremFR):
   was expected to be =~
  <"À maintes prémâchées lui.">.
/<>/test/test_lorem_fr.rb:24:in `test_phrase'
 21:   end
 22: 
 23:   def test_phrase
  => 24: assert_match(/\A[ -.àâéèêîôùûa-z]+\z/i, 
FFaker::LoremFR.phrase)
 25:   end
 26: 
 27:   def test_paragraphsLoremFR
===

[ ... ]

Finished in 0.705650289 seconds.
---
1550 tests, 12557 assertions, 1 failures, 0 errors, 0 pendings, 0 omissions, 0 
notifications
99.9355% passed
---
2196.56 tests/s, 17794.93 assertions/s
rake aborted!
Command failed with status (1): [ruby -w -I"test"  
"/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/test_address.rb" 
"test/test_address_au.rb" "test/test_address_br.rb" "test/test_address_ca.rb" 
"test/test_address_ch.rb" "test/test_address_ch_de.rb" 
"test/test_address_ch_fr.rb" "test/test_address_ch_it.rb" 
"test/test_address_da.rb" "test/test_address_de.rb" "test/test_address_fi.rb" 
"test/test_address_fr.rb" "test/test_address_gr.rb" "test/test_address_id.rb" 
"test/test_address_in.rb" "test/test_address_ja.rb" "test/test_address_kr.rb" 
"test/test_address_mx.rb" "test/test_address_nl.rb" "test/test_address_pl.rb" 
"test/test_address_ru.rb" "test/test_address_se.rb" "test/test_address_sn.rb" 
"test/test_address_ua.rb" "test/test_address_uk.rb" "test/test_address_us.rb" 
"test/test_airline.rb" "test/test_animal.rb" "test/test_array_utils.rb" 
"test/test_avatar.rb" "test/test_aws.rb" "test/test_bacon_ipsum.rb" 
"test/test_book.rb" "test/test_boolean.rb" "test/test_cheesy_lingo.rb" "
 test/test_color.rb" "test/test_color_ua.rb" "test/test_company.rb" 
"test/test_company_cn.rb" "test/test_company_it.rb" "test/test_company_se.rb" 
"test/test_conference.rb" "test/test_course_mathematiques.rb" 
"test/test_course_philosophie.rb" "test/test_currency.rb" 
"test/test_dizzle_ipsum.rb" "test/test_education.rb" "test/test_faker.rb" 
"test/test_filesystem.rb" "test/test_food.rb" "test/test_gender.rb" 
"test/test_gender_br.rb" "test/test_gender_cn.rb" "test/test_gender_id.rb" 
"test/test_gender_kr.rb" "test/test_geolocation.rb" "test/test_guid.rb" 
"test/test_healthcare_ipsum.rb" "test/test_hipster_ipsum.rb" 
"test/test_html_ipsum.rb" "test/test_identification.rb" 
"test/test_identification_br.rb" "test/test_identification_co.rb" 
"test/test_identification_es.rb" "test/test_identification_es_cl.rb" 
"test/test_identification_es_mx.rb" "test/test_identification_kr.rb" 
"test/test_internet.rb" "test/test_internet_se.rb" "test/test_job.rb" 
"test/test_job_br.rb" "test/test_job_cn.rb" "test/te
 st_job_fr.rb" "test/test_job_ja.rb" "test/test_job_kr.rb" 
"test/test_job_vn.rb" "test/test_locale.rb" "test/test_lorem.rb" 
"test/test_lorem_ar.rb" "test/test_lorem_cn.rb" "test/test_lorem_fr.rb" 
"test/test_lorem_ja.rb" "test/test_lorem_kr.rb" "test/test_lorem_ru.rb" 
"test/test_lorem_ua.rb" "test/test_module_utils.rb" "test/test_movie.rb" 
"test/test_music.rb" "test/test_name.rb" "test/test_name_ar.rb" 
"test/test_name_br.rb" "test/test_name_cn.rb" "test/test_name_cs.rb" 
"test/test_name_da.rb" "test/test_name_de.rb" "test/test_name_fr.rb" 
"test/test_name_ga.rb" "test/test_name_gr.rb" "test/test_name_id.rb" 
"test/test_name_it.rb" "test/test_name_ja.rb" "test/test_name_kh.rb" 
"test/test_name_kr.rb" "test/test_name_mx.rb" "test/test_name_nb.rb" 
"test/test_name_nl.rb" "test/test_name_ph.rb" "test/test_name_pl.rb" 
"test/test_name_ru.rb" "test/test_name_se.rb" "test/test_name_sn.rb" 
"test/test_name_th.rb" "test/test_name_th_en.rb" "test/test_name_ua.rb" 
"test/test_name_vn.rb" "test/test_nato
 _alphabet.rb" "test/test_phone_number.rb" "test/test_phone_number_au.rb" 
"test/test_phone_number_br.rb" "test/test_phone_number_cu.rb" 
"test/test_phone_number_da.rb" "test/test_phone_number_de.rb" 
"test/test_phone_number_fr.rb" "test/test_phone_number_id.rb" 
"test/test_phone_number_kr.rb" 

Bug#907432: golang-github-cloudflare-redoctober: FTBFS (too many arguments in call to activation.Listeners)

[Santiago Vila]

Package: src:golang-github-cloudflare-redoctober
Version: 0.0~git20161017.0.78e9720-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang --with systemd
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install 
-gcflags=\"-trimpath=/<>/golang-github-cloudflare-redoctober-0.0\~git20161017.0.78e9720/obj-x86_64-linux-gnu/src\"
 
-asmflags=\"-trimpath=/<>/golang-github-cloudflare-redoctober-0.0\~git20161017.0.78e9720/obj-x86_64-linux-gnu/src\"
 -v -p 1 github.com/cloudflare/redoctober 
github.com/cloudflare/redoctober/client github.com/cloudflare/redoctober/cmd/ro 
github.com/cloudflare/redoctober/cmd/ro/gopass 
github.com/cloudflare/redoctober/config github.com/cloudflare/redoctober/core 
github.com/cloudflare/redoctober/cryptor github.com/cloudflare/redoctober/ecdh 
github.com/cloudflare/redoctober/hipchat 
github.com/cloudflare/redoctober/keycache github.com/cloudflare/redoctober/msp 
github.com/cloudflare/redoctober/order github.com/cloudflare/redoctober/padding 
github.com/cloudflare/redoctober/passvault 
github.com/cloudflare/redoctober/persist 
github.com/cloudflare/redoctober/symcrypt
github.com/cloudflare/redoctober/config
github.com/cloudflare/redoctober/padding
github.com/cloudflare/redoctober/symcrypt
github.com/cloudflare/redoctober/ecdh
golang.org/x/crypto/pbkdf2
golang.org/x/crypto/scrypt
github.com/cloudflare/redoctober/passvault
github.com/cloudflare/redoctober/keycache
github.com/cloudflare/redoctober/msp
github.com/cloudflare/redoctober/persist
github.com/cloudflare/redoctober/cryptor
github.com/cloudflare/redoctober/hipchat
github.com/cloudflare/redoctober/order
github.com/cloudflare/redoctober/core
github.com/coreos/go-systemd/activation
github.com/beorn7/perks/quantile
github.com/golang/protobuf/proto
github.com/prometheus/client_model/go
github.com/matttproud/golang_protobuf_extensions/pbutil
github.com/prometheus/common/internal/bitbucket.org/ww/goautoneg
github.com/prometheus/common/model
github.com/prometheus/common/expfmt
github.com/prometheus/procfs/internal/util
github.com/prometheus/procfs/nfs
github.com/prometheus/procfs/xfs
github.com/prometheus/procfs
github.com/prometheus/client_golang/prometheus
github.com/cloudflare/redoctober
# github.com/cloudflare/redoctober
src/github.com/cloudflare/redoctober/redoctober.go:141:41: too many arguments 
in call to activation.Listeners
have (bool)
want ()
github.com/cloudflare/redoctober/client
github.com/cloudflare/redoctober/cmd/ro/gopass
github.com/cloudflare/redoctober/cmd/ro
dh_auto_build: cd obj-x86_64-linux-gnu && go install 
-gcflags=\"-trimpath=/<>/golang-github-cloudflare-redoctober-0.0\~git20161017.0.78e9720/obj-x86_64-linux-gnu/src\"
 
-asmflags=\"-trimpath=/<>/golang-github-cloudflare-redoctober-0.0\~git20161017.0.78e9720/obj-x86_64-linux-gnu/src\"
 -v -p 1 github.com/cloudflare/redoctober 
github.com/cloudflare/redoctober/client github.com/cloudflare/redoctober/cmd/ro 
github.com/cloudflare/redoctober/cmd/ro/gopass 
github.com/cloudflare/redoctober/config github.com/cloudflare/redoctober/core 
github.com/cloudflare/redoctober/cryptor github.com/cloudflare/redoctober/ecdh 
github.com/cloudflare/redoctober/hipchat 
github.com/cloudflare/redoctober/keycache github.com/cloudflare/redoctober/msp 
github.com/cloudflare/redoctober/order github.com/cloudflare/redoctober/padding 
github.com/cloudflare/redoctober/passvault 
github.com/cloudflare/redoctober/persist 
github.com/cloudflare/redoctober/symcrypt returned exit code 2
make: *** [debian/rules:4: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but there are also build failures here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-cloudflare-redoctober.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#891218: mariadb-server-10.1: logrotate sometimes fails with "Lost connection to MySQL server"

[Faustin Lammler]

Hi Ralf,
thank you for your report.

This seems to be a connexion problem and can be caused by the database
being under heavy load. Then the connexion times out and rotation of
logs can't be achieved. May that be possible?

Regards,

Faustin

Bug#907431: cppo's testsuite fails on arm{el,hf} and ppc64el

[Nicolas Braud-Santoni]

Package: cppo
Version: 1.6.4-1
Severity: serious
Tags: upstream
Justification: fails to build from source

The testsuite of cppo fails on arm{el,hf} and ppc64el in the same location:

  
https://buildd.debian.org/status/fetch.php?pkg=cppo=ppc64el=1.6.4-1=1533482737=0
  
https://buildd.debian.org/status/fetch.php?pkg=cppo=armhf=1.6.4-1=1533483827=0
  
https://buildd.debian.org/status/fetch.php?pkg=cppo=armel=1.6.4-1=1533484809=0

> dh_auto_test -a
>   make -j4 test
> make[1]: Entering directory '/<>'
> cppo alias test/runtest (exit 1)
> (cd _build/default/test && ../../install/default/bin/cppo test.cppo) > 
> /dev/null
> Error: File "test.cppo", line 98, characters 0-20
> Error: math error
> make[1]: *** [Makefile:5: test] Error 1
> make[1]: Leaving directory '/<>'
> dh_auto_test: make -j4 test returned exit code 2
> make: *** [debian/rules:18: build-arch] Error 2


This seems likely to be an upstream bug, so I am forwarding the bug there.


Best,

  nicoo

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

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

Versions of packages cppo depends on:
ii  libc6   2.27-5
ii  ocaml-base-nox [ocaml-base-nox-4.05.0]  4.05.0-10+b1

cppo recommends no packages.

cppo suggests no packages.

Bug#880099: mariadb-server-10.1: logrotate script does not work - permission denied

[Faustin Lammler]

Hi Norbert,
thank you for your report.

I need the following please:
- content of ''/etc/cron.daily/logrotate';
- content of '/etc/logrotate.d/mysql-server';
- content of '/etc/mysql/debian.cnf' (WARNING: remove eventually the
  passwords!);
- result of:
$ sudo /usr/sbin/logrotate -v /etc/logrotate.conf

It seems that mysqladmin is unable to connect to the database. May I ask
you to verify this point? Does the user 'debian-sys-maint' still exists?

Regards,

-- 
Faustin Lammler

Bug#821093: torbrowser should be usable as sensible-browser

[Sandro Knauß]

Hey,

you can use torbrowser-launcher as sensible-browser, if you start torbrowser 
every time with --allow-remote. See [15185] that is the upstream bug.

so first console:
~/.local/share/torbrowser/tbb/x86_64/tor-browser_{LANG}/Browser/start-tor-
browser  --allow-remote https://check.torproject.org/
second console open a new tab:
~/.local/share/torbrowser/tbb/x86_64/tor-browser_{LANG}/Browser/start-tor-
browser --allow-remote https://check.torproject.org/

even --new-window, --new-tab and --detach works like you expected them.

hefee

[15185] https://trac.torproject.org/projects/tor/ticket/15185

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

Bug#884765: ITP: drupal-init-tools -- helper commands to create and install new Drupal projects

[Antonio Ospite]

On Fri, 22 Dec 2017 15:18:12 -0600
Gunnar Wolf  wrote:

> Antonio Ospite dijo [Tue, Dec 19, 2017 at 11:45:52AM +0100]:
> > (...)
> > I am the upstream author of drupal-init-tool and I plan on maintaining
> > the Debian package myself, but I am not a Debian Developer or a Debian
> > Maintainer.
> > 
> > I do have a sponsor who is kind enough to upload some other packages of
> > mine, but if someone is interested in web stuff and want to sponsor me
> > for this one, my usual sponsor and I would surely appreciate it. :)
> 
> FWIW, as the maintainer of Drupal7 (FWIW, I requested for it to be
> removed from unstable yesterday), I am interested in having it. I'm
> currently away from home and with low network availability, but am
> willing to look at the packaging sponsor your uploads if needed (but
> expect end-of-the-year-time delays)

Ping.

I released upstream version 0.1.2 and updated the debian packaging in
the debian/master branch to 0.1.2-1:

https://git.ao2.it/drupal-init-tools.git/
https://git.ao2.it/drupal-init-tools.git/shortlog/refs/heads/debian/master

drupal-init-tools now works better with modern MySQL/MariaDB versions,
and with Drush 9.

The old tutorial is still valid:
https://ao2.it/en/blog/2017/08/02/drupal-init-tools-quick-and-easy-drupal-8-setup

The package description can be improved, now it assumes that the user
knows drupal 8 and how it is supposed to work, but I'd like to know if
the package has any chances to be sponsored before putting more time
into it.

Thanks,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#907430: Archiving with archiving tool "Ark" does not work in LXQt

[scrap]

Package: ark
Version: 4:16.08.3-2



Dear Debian-team,

hereby you receive a bug report for archiving tool "Ark".

When using Ark with LXQt in Debian Stretch it will throw an error when
trying to create any kind of archive (see screenshot in attachement).

It seems that this version of Ark is not compatible with other desktop
environments than KDE? Probably Ark requires "klauncher" to work
successfully.

However, unarchiving seems to be possible, but not archiving.

I am using Debian GNU/Linux 9, kernel 4.9.0.8 with desktop environment LXQt.

Thanks a lot for your great efforts!

With best regards!
David



Package: ark
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 1833
Maintainer: Debian/Kubuntu Qt/KDE Maintainers

Architecture: amd64
Version: 4:16.08.3-2
Depends: kio, libarchive13 (>= 3.2.1), libc6 (>= 2.14), libkf5archive5
(>= 4.96.0), libkf5completion5 (>= 4.97.0), libkf5configcore5 (>=
4.98.0), libkf5configgui5 (>= 4.97.0), libkf5configwidgets5 (>= 4.96.0),
libkf5coreaddons5 (>= 5.16.0), libkf5crash5 (>= 5.15.0),
libkf5dbusaddons5 (>= 4.97.0), libkf5i18n5 (>= 4.97.0),
libkf5iconthemes5 (>= 4.96.0), libkf5jobwidgets5 (>= 4.96.0),
libkf5kiocore5 (>= 4.96.0), libkf5kiofilewidgets5 (>= 4.96.0),
libkf5kiowidgets5 (>= 5.5.0+git20150101.0309+15.04), libkf5parts5 (>=
4.96.0), libkf5pty5 (>= 4.96.0), libkf5service-bin, libkf5service5 (>=
4.99.0), libkf5widgetsaddons5 (>= 5.16.0), libkf5xmlgui5 (>= 4.98.0),
libqt5core5a (>= 5.7.0), libqt5dbus5 (>= 5.4.0~), libqt5gui5 (>= 5.7.0),
libqt5widgets5 (>= 5.4.0~), libstdc++6 (>= 4.1.1)
Recommends: bzip2, p7zip-full, unar, unzip, zip
Conffiles:
 /etc/xdg/ark.categories b6761379f1dc67c4353e5b1e960cc34b
Description: archive utility
 Ark manages various archive formats, including tar, gzip, bzip2, rar
and zip,
 as well as CD-ROM images.  Ark can be used to browse, extract, create, and
 modify archives.
 .
 This package is part of the KDE SC utilities module.
Homepage: http://www.kde.org/

Bug#900374: knot: running as a non-privileged user has problems, needs overhaul.

[Daniel Kahn Gillmor]

On Tue 2018-05-29 15:08:42 -0400, Daniel Kahn Gillmor wrote:
> for systems using systemd, the [Service] section of knot.service should
> probably contain:
>
> User=knot
> AmbientCapabilities=CAP_NET_BIND_SERVICE

note that upstream now has its own very nice systemd .service file.  we
should adopt that in debian!

   --dkg

Bug#794410: Installer hangs during 'select and install software'

[Jean-Louis Deniest]

Hi,

This problem has been solved by updating the bios. Then installation of 
9.5.0 went without problems.




On 23/07/18 21:15, Jean-Louis Deniest wrote:

Thanks Cyril.

Here is it.
usb key : debian 9, DVD version

I made screenshots of vt4 during :
- error when searching mirrors - no mirrors were accepted, even usa - 
debian. I selected then 'continue with no mirror' (see screenshot 1 & 
2). It has happened a few times. > screenshots 1 and 2

- just before the hanging, at the phase of installing discover.

Then, I runned another time the install, and made a few screenshots of 
/var/log/syslog, until it hangs.


All screenshots here : https://cloud.owncube.com/s/FyPgZMi9bzQEPoj

Hope it helps...


On 22/07/18 20:02, Cyril Brulebois wrote:

Hi Jean-Louis,

Jean-Louis Deniest  (2018-07-21):

Hello, I have the same issue.

Installing debian 9 stretch, both cd 
(debian-9.5.0-amd64-xfce-CD-1.iso) and

the dvd versions.

Hangs at 12% : at the phase of installing "discover (amd64)"

I tried about 10 times.

Laptop is Packard Bell ENLG71BM-C05U

I used the additional drivers (from 
http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/stretch/20180714/),

and I put these .deb packages on another usb key : the effect is that I
don't have the step where they search for firmware for
rtlwifi/rtl8723befw.bin and rtl_nic/rtl8168g-2.fw

I don't have options to disable APCI in the bios.

I managed to install Opensuse on this computer, and there was 
Windows 10

working properly.

Any suggestion is welcome...

Can you please switch to vt4 and tell us what the last lines look like?
Bonus points if you can extract the whole /var/log/syslog file (e.g. by
using netcat to another machine); a photograph would probably work too.

Thanks already.


Cheers,

Bug#907345: After upgrading from 5.10.1+dfsg-6 to 5.10.1+dfsg-7 akonadi imap stops working - possibly OpenSSL 1.1.1

[Sandro Knauß]

Hey,

> I think this bug-report can be closed.

you can do this by your own if you send a mail at 907345-d...@bugs.debian.org.

> The problems disappears if openssl is also upgraded to version 1.1.1~~pre9-1
> (from 1.1.0h-4). So this problem only exists with openssl < 1.1.1~~pre9-1.

Wait - this is all very strange you say you have Qt 5.10.1+dfsg-6 installed 
and OpenSSL 1.1.1~~pre9-1. Qt is 5.11 in testing/unstable and for sure it is 
built aganist OpenSSL 1.1.0. 

Futher more qtbase-opensource-src is delayed because of issues with OpenSSL 
1.1.1:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907015

well but untangle this, may be not worth doing it - if it works for you now. 
So we have at least one datapoint, that OpenSSL may improve situations for 
users :D

hefee


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

Bug#904777: transition: libraw

[Matteo F. Vescovi]

Hi!

On 2018-07-28 at 10:13 (+0200), Emilio Pozuelo Monfort wrote:

[...]

> Go ahead and please file bug against those three packages and make them block
> this one.

Am I supposed to be allowed to go ahead with this transition now that
Qt's has completed?

TIA for the feedback.


-- 
Matteo F. Vescovi


signature.asc
Description: PGP signature

Bug#907057: neverball: Constant fsync calls seriously degrade performance

[Markus Koschany]

clone 907057 -1
retitle -1 libphysfs: constant fsync calls seriously degrade performance
reassign -1 src:libphysfs
affects -1 neverball
thanks

Am 27.08.2018 um 03:36 schrieb Uoti Urpala:
> On Sun, 2018-08-26 at 17:59 +0200, Markus Koschany wrote:
>> On Thu, 23 Aug 2018 17:56:01 +0300 Uoti Urpala 
>> wrote:
>>> Neverball automatically saves a replay of the latest run on disk while
>>> playing. In the Debian package, the binary constantly calls fsync() on
>>> this file, which very seriously degrades performance. If the issue is
>>> not obvious when trying to reproduce, try on a machine with as slow a
>>> spinning disk as possible.
>>>
>>> This is likely a libphysfs issue. Neverball code contains no direct
>>> fsync() calls. Neverball upstream has changed the default filesystem
>>> backend to be stdio instead of libphysfs, and current upstream code
>>> (with no physfs) does not display the problem.
> 
>> Why did you report this bug against neverball instead of libphysfs when
>> all the issues you describe are related to libphysfs?
> 
> Neverball is broken so at least a bug blocked by a physfs bug would be
> appropriate in any case, and I assume that the easiest way to fix the
> problem would be to change the Neverball package to stop using
> libphysfs.

I cannot confirm that Neverball is broken. I don't see any performance
issues on my system which is a X230 Lenovo Laptop, not quite a gaming
laptop but capable to play the game. However I cannot test whether there
is a performance degradation on slower non-SSD hard disks. So this may
or may not an issue for older hard disks.

Not using libphysfs would be a workaround and not a fix. Hence I am
going to clone and reassign this bug report to libphysfs. Upstream have
not been released a new version for years. Perhaps I will try a recent
Git snapshot in the future but this surely must be fixed upstream.
Please ask the upstream developers of Neverball to investigate this
issue and release a new version. This is not actionable by Debian itself.

Markus






signature.asc
Description: OpenPGP digital signature

Bug#907421: nm.debian.org: crash on keyserver timeout

[Pierre-Elliott Bécue]

Le lundi 27 août 2018 à 21:24:59+0200, Mattia Rizzolo a écrit :
> [nm/keyring crashes on 504]

Hey,

Here is a rough skeleton of patch.

Don't use it as its, it's not tested yet.

I'd just like to hear if the idea seems fine with you. It's supposed to rely
on django.contrib.messages that seems implemented in
deblayout/templates/debian-base.html.

Cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.
diff --git a/keyring/models.py b/keyring/models.py
index e1ceced..f450fff 100644
--- a/keyring/models.py
+++ b/keyring/models.py
@@ -63,6 +63,8 @@ class KeyManager(models.Manager):
 res = requests.get(url)
 try:
 res.raise_for_status()
+except requests.HTTPError as e:
+raise
 except Exception as e:
 raise RuntimeError("GET {} failed: {}".format(url, e))
 keytext = []
diff --git a/process/views.py b/process/views.py
index e27e9ee..f608e2f 100644
--- a/process/views.py
+++ b/process/views.py
@@ -7,6 +7,7 @@ from django.db import transaction
 from django import forms, http
 from django.core.exceptions import PermissionDenied
 from django.conf import settings
+from django.contrib import messages as django_messages
 from django.urls import reverse, reverse_lazy
 from collections import OrderedDict
 from rest_framework import viewsets
@@ -414,10 +415,20 @@ class UpdateKeycheck(RequirementMixin, View):
 key = Key.objects.get_or_download(self.person.fpr)
 except RuntimeError as e:
 key = None
+
+ret_dest = self.requirement.get_absolute_url()
 if key is not None:
-key.update_key()
+try:
+key.update_key()
+except requests.HTTPError as e:
+django_messages.add_message(
+request,
+messages.ERROR,
+_("The server met an arror: {}".format(e)),
+)
+return redirect(ret_dest)
 key.update_check_sigs()
-return redirect(self.requirement.get_absolute_url())
+return redirect(ret_dest)
 
 
 class DownloadStatements(VisitProcessMixin, View):


signature.asc
Description: PGP signature

Bug#888813: ITP: micro -- a modern and intuitive terminal-based text editor

[Jongmin Kim]

Control: block 13 by 904613 904665 904689 904695 904701

-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#907428: nm.debian.org: replace the 403 of intent for retirement/removal processes

[Mattia Rizzolo]

Package: nm.debian.org

I just hit a removed DD that felt offended by the 403 that the
"Declaration of intent" of his removal process gave him.

That 403 comes from the following commits:

a8b8b7b80cf337d99c54294b4c6005aedf41f4502017-08-28
Emergency measure to make declarations of intent for
emeritus/removed processes not visible to non-dds
b39ff0c13bffce00b91472743f412a090e2d07172017-09-24
Implemented view_intent permission


Indeed, we could display a nicer page explaining that the intent of a
retirement or removal process is not public.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#907409: casync: FTBFS with glibc 2.28, header mismatch wih new renameat2()

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/casync/issues/166

Hi Steve

On 8/27/18 19:00, Steve Langasek wrote:
> Package: casync
> Version: 2+20180321-2
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu cosmic ubuntu-patch
> 
> Dear maintainers,
> 
> casync fails to build from source against glibc 2.28, as seen in the Ubuntu
> autopkgtest:
> 
> [...]
> cc -Isrc/src@@shared@sta -Isrc -I../src -fdiagnostics-color=always -pipe 
> -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wextra -Werror=undef -Werror=format=2 
> -Wformat-security -Wformat-nonliteral -Wlogical-op -Wmissing-include-dirs 
> -Werror=old-style-definition -Werror=pointer-arith -Winit-self 
> -Wdeclaration-after-statement -Wfloat-equal -Wsuggest-attribute=noreturn 
> -Werror=missing-prototypes -Werror=implicit-function-declaration 
> -Werror=missing-declarations -Werror=return-type 
> -Werror=incompatible-pointer-types -Werror=shadow -Werror=int-conversion 
> -Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn -Wendif-labels 
> -Wstrict-aliasing=2 -Wwrite-strings -Wno-unused-parameter 
> -Wno-missing-field-initializers -Wno-unused-result -Werror=overflow 
> -Werror=sign-compare -Wdate-time -Wnested-externs -fno-common 
> -fdiagnostics-show-option -fno-strict-aliasing -fvisibility=hidden 
> -fstack-protector -fstack-protector-strong -fPIE --param=ssp-buffer-size=4 
> -include config.h -g -O2 
> -fdebug-prefix-map=/tmp/autopkgtest.iBt8c8/build.W5z/src=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -fPIC  -MD -MQ 'src/src@@shared@sta/cacache.c.o' -MF 
> 'src/src@@shared@sta/cacache.c.o.d' -o 'src/src@@shared@sta/cacache.c.o' -c 
> ../src/cacache.c
> In file included from ../src/canametable.h:9,
>  from ../src/calocation.h:12,
>  from ../src/cacache.h:7,
>  from ../src/cacache.c:9:
> ../src/util.h:532:19: error: static declaration of ‘renameat2’ follows 
> non-static declaration
>  static inline int renameat2(int oldfd, const char *oldname, int newfd, const 
> char *newname, unsigned flags) {

Looks like there is already an upstream bug report for it. So marking
accordingly.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#907427: openssl 1.1.1 breaks ssl tests

[Sandro Knauß]

Source: qtbase-opensource-src, kimap
Version: kimap/18.07.90-1
Control: block 907015 by -1

When I built my KDE PIM packages locally I built against openssl 1.1.0h-4 and I 
had no issues running the KIMAP tests.
With openssl 1.1.1~~pre9-1 (experimental) the tests breaks. See [1] for more 
examples.

You may want to merge with #907340 or #907340, as those are also failings tests 
because of openssl 1.1.1.

hefee

[1] https://buildd.debian.org/status/package.php?p=kimap=experimental

[...]
QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) "Error 
loading local certificate, error:140AB18F:SSL 
routines:SSL_CTX_use_certificate:ee key too small"
QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
QAbstractSocket::SocketError(21)
QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) "Unable 
to init SSL Context: "
QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
QAbstractSocket::SocketError(20)
QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) "The 
remote host closed the connection"
QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
QAbstractSocket::RemoteHostClosedError
QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
org.kde.pim.kimap: Connection to server lost  0
FAIL!  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
'login->exec()' returned FALSE. ()
   Loc: [/<>/autotests/loginjobtest.cpp(250)]
[...]

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

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

Versions of packages libqt5network5 depends on:
ii  libc6 2.27-5
ii  libqt5core5a [qtbase-abi-5-11-0]  5.11.1+dfsg-7
ii  libqt5dbus5   5.11.1+dfsg-7
ii  libssl1.1 1.1.1~~pre9-1
ii  libstdc++68.2.0-4
ii  zlib1g1:1.2.11.dfsg-1

libqt5network5 recommends no packages.

libqt5network5 suggests no packages.

-- no debconf information

Bug#907392: firebird3.0-utils: tables with varchar attributes with big size cannot be backed up with gbak on armel

[Damyan Ivanov]

Control: severity -1 important
Control: tags -1 upstream confirmed
Control: subject -1 firebird3.0-utils: [armel] varchar(32765) cannot be backed 
up or restored with gbak

-=| Pablo Sánchez[gmail], 27.08.2018 10:06:49 -0300 |=-
> Package: firebird3.0-utils
> Version: 3.0.3.32900.ds4-4
> Severity: grave
> Justification: renders package unusable (kind of)

Severity descriptions:

 * grave
   makes the package in question unusable or mostly so, or causes data 
   loss, or introduces a security hole allowing access to the accounts 
   of users who use the package.
 * important
   a bug which has a major effect on the usability of a package, 
   without rendering it completely unusable to everyone.

I don't think that gbak problems on armel fall in the first category.

> 1- create database, and insert on column (using raspbian)
> 
> SQL> create database '/srv/data/debian-test.fdb'
> CON> user 'SYSDBA'
> CON> password 'masterkey'
> CON> page_size 8192
> CON> default character set iso8859_1;
> SQL> commit ;
> SQL> exit ;
> 
> 2- create a table with a big size varchar and insert data into it .
> CREATE TABLE TEST
> (
>   ID INTEGER,
>   VC VARCHAR(32765)
> );
> 
> INSERT INTO TABLE1 (ID, TEXT) VALUES ('1', 'abcdef123456');
> 
> 3- backup database
> 
> root@raspberrypi:/srv/data# gbak -b -v  -user SYSDBA -password masterkey
> /srv/data/debian-test.fdb /srv/data/debian-test.fbk
> gbak:readied database /srv/data/debian-test.fdb for backup
> gbak:creating file /srv/data/debian-test.fbk
> gbak:starting transaction
> ...
> gbak:writing packages
> gbak:writing data for table TABLE1
> gbak: ERROR:message length error (encountered -32758, expected 32778)
> gbak: ERROR:gds_$receive failed
> gbak:Exiting before completion due to errors
> 
> Note that if I create db on amd64 and restore on raspberrypi, I get the
> same error .
> But if create db on amd64 and restore on amd64 there is no error and data
> is there.
> I use buster now, but on v2.5 on stretch had the same problem. After
> posting on
> firebrid-support , I was suggested to post here.

For reference, this is the thread: 
https://groups.yahoo.com/neo/groups/firebird-support/conversations/topics/132945

I can reproduce the issue on abel.debian.org (armel/buster).

No idea yet what could be the cause.


-- dam

Bug#907332: ghostscript has a new code execution issue, even when used with -dSAFER

[Salvatore Bonaccorso]

Hi,

On Mon, Aug 27, 2018 at 08:34:25PM +0200, Jonas Smedegaard wrote:
> Quoting Salvatore Bonaccorso (2018-08-26 21:55:14)
> > Hi,
> > 
> > On Sun, Aug 26, 2018 at 06:08:58PM +0100, Nicolas Braud-Santoni wrote:
> > > Tavis Ormandy disclosed a new ghoscript security issue, leading directly 
> > > to code
> > > execution:  http://openwall.com/lists/oss-security/2018/08/21/2
> > 
> > There are actually several issues, see the whole thread. For now since
> > you filled this bug will track all those with this bug entry. Proper
> > evaluation though is still pending (and Moritz is taking care of
> > strech, adding this note to dsa-needed file ("needs some research on
> > issues found by Tavis").
> > 
> > See
> > 
> > https://www.kb.cert.org/vuls/id/332928
> > 
> > the current set of fixes:
> > 
> > http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=b575e1ec
> > http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8e9ce501
> > http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=241d9111
> > http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=c432131c
> > http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=e01e77a3
> > http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=0edd3d6c
> > http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a054156d
> > http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=0d390118
> > http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=c3476dde
> > http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=b326a716
> > http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=78911a01
> > http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=5516c614
> 
> Also http://git.ghostscript.com/?p=ghostpdl.git;h=0b6cd19

A first set of CVEs has now been assigned already:

CVE-2018-15908, CVE-2018-15909 and CVE-2018-15910.

Regards,
Salvatore

Bug#907380: tex-common: setting up of tex-common fails

[fulvio ciriaco]

Dear Norbert,

On Mon, 27 Aug 2018 10:07:54 +0200,
Norbert Preining wrote:
> 
> tag 907380 + unreproducible moreinfo
> severity 907380 minor
> thanks
> 
> > /usr/sbin/update-updmap: line 235: bin/mkdir: No such file or directory
> 
> This line contains a call to
>   mkdir -p ...
> if mkdir is not available, then you have probably messed up your PATH
> setting or have a destroyed system, because
>   /bin/mkdir
> is provided by coreutils.
>
Messed or destroyed? I don't think so:

0% which mkdir
/bin/mkdir

root@fulvio:/home/fc# update-updmap 
Regenerating '/var/lib/texmf/updmap.cfg-DEBIAN'... done.
Regenerating '/var/lib/texmf/updmap.cfg-TEXLIVEDIST'... done.
update-updmap has updated the following file(s):
/var/lib/texmf/updmap.cfg-DEBIAN
/var/lib/texmf/updmap.cfg-TEXLIVEDIST
If you want to activate the changes in the above file(s),
you should run updmap-sys or updmap.

the log says bin/mkdir is missing, but line 235 recites:
mkdir -p "$destdir"

Last but not least, the problem exists on two different computers of
mine, independently installed, though there is a large overlap of
installed software. The problem is very recent but hundreds of
packages have been upgraded without problem.

regards
Fulvio

> I see that you have AppArmor enabled, maybe this interferes.
> 
> 
> 
> Norbert
> 
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. +JAIST +TeX Live +Debian Developer
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#898075: jack: segfaults at start

[François Mazen]

Hello,

apparently the character string generated in jack_cursesmodule that is
passed to ncurses is invalid. I can't figure why this happen but I
suspect an issue in the python binding in jack_cursesmodule.

Hopefully you can bypass jack_cursesmodule to use the built-in ncurses
python binding. 
It fixes the issue, and a patch is attached to this message.

I think it's a viable solution because according to the documentation
in the cursesmodule folder [1], the jack_cursesmodule is an old binding
of ncurses: version 1.5b1 from before the release of python 2.0 [2]
(see the version number at the beginning of jack_cursesmodule.c [3]).
So, using the official binding from python is a much more reliable
solution.

In addition, I can provide a non-maintainer upload for this package and
eventually maintain the package.

Best Regards,
François

[1] 
https://sources.debian.org/src/jack/3.1.1+cvs20050801-29.2/cursesmodule/README.cursesmodule/
[2] https://invisible-island.net/ncurses/ncurses-python.html
[3] 
https://sources.debian.org/src/jack/3.1.1+cvs20050801-29.2/cursesmodule/jack_cursesmodule.c/


Author: Francois Mazen 
Description: remove jack_cursesmodule, an obsolete curses binding
Bug-Debian: https://bugs.debian.org/898075

--- a/setup.py
+++ b/setup.py
@@ -13,11 +13,6 @@
 url = "http://www.home.unix-ag.org/arne/jack/;,
 
 # Description of the modules and packages in the distribution
-ext_modules = [ Extension('jack_cursesmodule',
-['cursesmodule/jack_cursesmodule.c'], libraries=["ncursesw"],
-include_dirs=["/usr/include/ncursesw"],
-extra_compile_args=["-Wno-strict-prototypes"]) ],
-
 py_modules = [ 'jack_CDTime', 'jack_TOC', 'jack_TOCentry', 'jack_argv',
 'jack_checkopts', 'jack_children', 'jack_config', 'jack_constants',
 'jack_display', 'jack_encstuff', 'jack_freedb', 'jack_functions',

Bug#907423: lintian should give an error when both foo-dbg and foo-dbgsym are built

[Chris Lamb]

Hi Adrian,

> lintian should give an error when both foo-dbg and foo-dbgsym are
> built

Could you provide another draft description? Thank you in advance.


Regards,

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

Bug#886358: chromium: Enable Hangouts screensharing extension

[Philipp Hahn]

unarchive 886358
reopen 886358
thanks

Sorry for re-opeing this bug, but it cost me some time to find that
Debian disables the shreen sharing extention in its build of chromium.

> This is the intended default configuration.  For those that would like
> it enabled in their version, the suggested patch is correct.

Can you at least clarify *why* that feature is disabled? Neither my web
search nor looking in the Debian source package found any hint:
* Does it make the package non-free/contrib
* Is it an security issue?
* or is there some other technical reason to disable it in Debian?

After re-compiling chromium with that extension enabled I was finally
able to use the screen sharing extension with my colleges.


Also (a different issue): NEW still contains this text:
> chromium-browser (55.0.2883.75-4) unstable; urgency=medium
> 
>   * External extensions are now disabled by default.  Chromium will only load
> extensions that are explicitly specified with the --load-extension command
> line option passed into CHROMIUM_FLAGS.  See the chromium-lwn4chrome
> package for an example of how to do this.
>   * You can also use the --enable-remote-extensions command line argument to
> chromium, which will bypass this restriction.

But:
> cat /etc/chromium.d/extensions 
> # remote extensions on by default
> export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-remote-extensions"

So this looks out-of-date. Please correct me if I'm wrong.

Thanks.
Philipp
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
h...@univention.de

http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Bug#891104: wapiti: python-beautifulsoup is replaced with python-bs4

[Raphael Hertzog]

On Mon, 27 Aug 2018, Stefano Rivera wrote:
> Looks like upstream did this work already.
> https://sourceforge.net/p/wapiti/code/324/
> 
> It's fixed in recent upstream releases (e.g. 3.0.1).

Thanks for the notice. Gianfranco, since you are the most familiar with
this package, would you be willing to update it to the latest upstream
release?

We have 2.3.0 right now (no update since 2016).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#907425: lintian: Strange lintian.debian.org entry for matlab-gdf

[Chris Lamb]

Package: lintian
Version: 2.5.98
Severity: normal

Hi,

https://lintian.debian.org/full/t...@neuro.debian.net.html#_0.1.2-2 has
a very strange entry which appears to confuse the package name and
version:

  https://i.imgur.com/OesRxKX.png

Not sure of the cause but I note that matlab-gdf is "Section: contrib/
science".


Regards,

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

Bug#907424: gemma: autopkgtest regression: cp: cannot stat '/usr/share/doc/gemma-doc/example/*'

[Paul Gevers]

Source: gemma
Version: 0.97+dfsg-4
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers, Andreas,

With the upload of 0.97+dfsg-4 the autopkgtest of your package started
to fail in testing. I copied the output below.

Currently this regression is contributing to the delay of the migration
to testing [1]. Could you please investigate the situation and fix it?
If needed, please change the bug's severity as appropriate.

Reading the changelog you bumped the debhelper compat level, but that
changes the location of the examples.

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

Paul

[1] https://qa.debian.org/excuses.php?package=gemma

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gemma/886648/log.gz

autopkgtest [04:52:20]: test run-sample-analysis: [---
cp: cannot stat '/usr/share/doc/gemma-doc/example/*': No such file or
directory
autopkgtest [04:52:21]: test run-sample-analysis: ---]



signature.asc
Description: OpenPGP digital signature

Bug#896238: gphoto2-cffi: diff for NMU version 0.3~a1-1.1

[Adrian Bunk]

Control: tags 896238 + patch
Control: tags 896238 + pending

Dear maintainer,

I've prepared an NMU for gphoto2-cffi (versioned as 0.3~a1-1.1) and 
uploaded it to DELAYED/2. Please feel free to tell me if I should
cancel it.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -Nru gphoto2-cffi-0.3~a1/debian/changelog gphoto2-cffi-0.3~a1/debian/changelog
--- gphoto2-cffi-0.3~a1/debian/changelog	2016-04-04 22:28:11.0 +0300
+++ gphoto2-cffi-0.3~a1/debian/changelog	2018-08-27 22:41:25.0 +0300
@@ -1,3 +1,10 @@
+gphoto2-cffi (0.3~a1-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Add upstream fix to unbreak python3-gphoto2cffi. (Closes: #896238)
+
+ -- Adrian Bunk   Mon, 27 Aug 2018 22:41:25 +0300
+
 gphoto2-cffi (0.3~a1-1) unstable; urgency=low
 
   * Updated upstream version merging changes
diff -Nru gphoto2-cffi-0.3~a1/debian/patches/0001-Make-enum-descriptors-strs-not-bytestrings-7.patch gphoto2-cffi-0.3~a1/debian/patches/0001-Make-enum-descriptors-strs-not-bytestrings-7.patch
--- gphoto2-cffi-0.3~a1/debian/patches/0001-Make-enum-descriptors-strs-not-bytestrings-7.patch	1970-01-01 02:00:00.0 +0200
+++ gphoto2-cffi-0.3~a1/debian/patches/0001-Make-enum-descriptors-strs-not-bytestrings-7.patch	2018-08-27 22:34:41.0 +0300
@@ -0,0 +1,43 @@
+From 88ed97764365fea5f72a6f2c9aba0323b7fd93a8 Mon Sep 17 00:00:00 2001
+From: Johannes Baiter 
+Date: Thu, 7 Jul 2016 16:14:37 +0200
+Subject: Make enum descriptors strs, not bytestrings (#7)
+
+---
+ gphoto2cffi/backend.py | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/gphoto2cffi/backend.py b/gphoto2cffi/backend.py
+index c49db11..21edc4b 100644
+--- a/gphoto2cffi/backend.py
 b/gphoto2cffi/backend.py
+@@ -48,7 +48,7 @@ LOG_LEVELS = {
+ _lib.GP_LOG_DEBUG:   logging.DEBUG}
+ 
+ 
+-FILE_OPS = IntEnum(b'FileOperations', {
++FILE_OPS = IntEnum('FileOperations', {
+ 'remove': _lib.GP_FILE_OPERATION_DELETE,
+ 'extract_preview': _lib.GP_FILE_OPERATION_PREVIEW,
+ 'extract_raw': _lib.GP_FILE_OPERATION_RAW,
+@@ -56,7 +56,7 @@ FILE_OPS = IntEnum(b'FileOperations', {
+ 'extract_exif': _lib.GP_FILE_OPERATION_EXIF})
+ 
+ 
+-CAM_OPS = IntEnum(b'CameraOperations', {
++CAM_OPS = IntEnum('CameraOperations', {
+ 'capture_image': _lib.GP_OPERATION_CAPTURE_IMAGE,
+ 'capture_video': _lib.GP_OPERATION_CAPTURE_VIDEO,
+ 'capture_audio': _lib.GP_OPERATION_CAPTURE_AUDIO,
+@@ -65,7 +65,7 @@ CAM_OPS = IntEnum(b'CameraOperations', {
+ 'trigger_capture': _lib.GP_OPERATION_TRIGGER_CAPTURE})
+ 
+ 
+-DIR_OPS = IntEnum(b'DirectoryOperations', {
++DIR_OPS = IntEnum('DirectoryOperations', {
+ 'remove': _lib.GP_FOLDER_OPERATION_REMOVE_DIR,
+ 'create': _lib.GP_FOLDER_OPERATION_MAKE_DIR,
+ 'delete_all': _lib.GP_FOLDER_OPERATION_DELETE_ALL,
+-- 
+2.11.0
+
diff -Nru gphoto2-cffi-0.3~a1/debian/patches/series gphoto2-cffi-0.3~a1/debian/patches/series
--- gphoto2-cffi-0.3~a1/debian/patches/series	2016-04-04 22:24:03.0 +0300
+++ gphoto2-cffi-0.3~a1/debian/patches/series	2018-08-27 22:41:25.0 +0300
@@ -0,0 +1 @@
+0001-Make-enum-descriptors-strs-not-bytestrings-7.patch

Bug#906139: debian-policy: versioned depends on libjs-sphinxdoc unsatisfiable on stretch

[Raphael Hertzog]

Hi,

On Mon, 27 Aug 2018, Sean Whitton wrote:
> On Mon 27 Aug 2018 at 12:58PM +0200, Raphael Hertzog wrote:
> > Or you could have read dh_linktree's manual page and see that you can
> > use "replace" instead of "deduplicate" to get a weak dependency.
> 
> I did read this -- unfortunately, though, it would not help make
> debian-policy installable on stretch, which was the original bug
> reporter's problem.

Ok, sorry for having commented too hastily.

(But this is the kind of thing which makes me believe that we go
too far in the avoid duplicating code, so much energy spent for
almost no gain)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#905418: openmpi: elpa builds hang on multiple architectures

[Graham Inggs]

Hi Alastair

Elpa seems to be another package with builds timing out.
Confirmed on reproducible builders for i386 [1] and armhf [2].

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/history/i386/elpa.html
[2] https://tests.reproducible-builds.org/debian/history/armhf/elpa.html

Bug#907338: tracker.debian.org: confusion between keyword and keywordall

[Raphael Hertzog]

Hi,

On Tue, 28 Aug 2018, shirish शिरीष wrote:
> The point being I didn't know for what packages I have I have
> what subscriptions.
> 
> For e.g. I like dpkg, apt and some packages and like to know
> what bugs have been caught there etc. but not necessarily all others.

You may want to use the web interface. It will show all that quite
nicely. The email interface is good to make some changes but really
not made to review all your subscriptions.

See https://tracker.debian.org/accounts/subscriptions/

> What would have been a lot better if possible to have a list of all
> the packages with subscriptions on it.  I dunno if it's on the roadmap,
> if not will file a wishlist bug for it.

Well, "which" gives you your list of subscriptions and then you can
use "keyword " on all of them in a loop if you really want
to stick to the email interface.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#824649: ostree: document how to prepare and update a .deb-based system root

[Simon McVittie]

On Mon, 27 Aug 2018 at 20:21:11 +0200, Felix Krull wrote:
> Has there been any progress on this?

The bug is tagged "help" because the maintainer does not know how to
test this. If you can help to document how, please do, but the bug is not
going to progress without someone's help.

> I have one question about the description: The ostree-boot.control file states
> that "the root filesystem must be one that dracut can mount without a root=
> command-line argument". Unless I'm misunderstanding it, this doesn't seem to 
> be
> correct (any more)? In my tests, I've happily booted VMs from MBR disks with
> LVM2 root partitions.

I think that was true at some point. If it is no longer true I'm happy
to remove that statement; you almost certainly know better than I do!

smcv

Bug#907423: lintian should give an error when both foo-dbg and foo-dbgsym are built

[Adrian Bunk]

Package: lintian
Version: 2.5.98
Severity: normal

#907362 and #907422 are examples of this problem.

Note that it is not always the -dbg that is wrong,
e.g. #907422 is a python case where the -dbgsym
are likely bogus.

Bug#907421: nm.debian.org: crash on keyserver timeout

[Mattia Rizzolo]

Package: nm.debian.org
Severity: important

crash report:

Internal Server Error: /process/522/update_keycheck

RuntimeError at /process/522/update_keycheck
GET 
http://pool.sks-keyservers.net:11371/pks/lookup?options=mr=get=on=0x61BA4809444BE8B0DAFD9BD6170661BF3FFDB248
 failed: 504 Server Error: Gateway Time-out for url: 
http://pool.sks-keyservers.net:11371/pks/lookup?options=mr=get=on=0x61BA4809444BE8B0DAFD9BD6170661BF3FFDB248

Request Method: POST
Request URL: https://nm.debian.org/process/522/update_keycheck
Django Version: 1.10.7
Python Version: 3.5.3
Server time: Mon, 27 Aug 2018 06:17:22 +

Traceback:

File "/srv/nm.debian.org/nm2/keyring/models.py" in download
  65. res.raise_for_status()

File "/usr/lib/python3/dist-packages/requests/models.py" in raise_for_status
  893. raise HTTPError(http_error_msg, response=self)


  During handling of the above exception (504 Server Error: Gateway 
Time-out for url: 
http://pool.sks-keyservers.net:11371/pks/lookup?options=mr=get=on=0x61BA4809444BE8B0DAFD9BD6170661BF3FFDB248),
 another exception occurred:



File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in inner
  42. response = get_response(request)

File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_legacy_get_response
  249. response = self._get_response(request)

File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_get_response
  187. response = self.process_exception_by_middleware(e, 
request)

File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_get_response
  185. response = wrapped_callback(request, *callback_args, 
**callback_kwargs)

File "/usr/lib/python3/dist-packages/django/views/generic/base.py" in view
  68. return self.dispatch(request, *args, **kwargs)

File "/srv/nm.debian.org/nm2/backend/mixins.py" in dispatch
  72. return super(VisitorMixin, self).dispatch(request, *args, 
**kwargs)

File "/usr/lib/python3/dist-packages/django/views/generic/base.py" in dispatch
  88. return handler(request, *args, **kwargs)

File "/srv/nm.debian.org/nm2/process/views.py" in post
  418. key.update_key()

File "/srv/nm.debian.org/nm2/keyring/models.py" in update_key
  122. self.key = Key.objects.download(fpr=self.fpr)

File "/srv/nm.debian.org/nm2/keyring/models.py" in download
  67. raise RuntimeError("GET {} failed: {}".format(url, e))

Exception Type: RuntimeError at /process/522/update_keycheck
Exception Value: GET 
http://pool.sks-keyservers.net:11371/pks/lookup?options=mr=get=on=0x61BA4809444BE8B0DAFD9BD6170661BF3FFDB248
 failed: 504 Server Error: Gateway Time-out for url: 
http://pool.sks-keyservers.net:11371/pks/lookup?options=mr=get=on=0x61BA4809444BE8B0DAFD9BD6170661BF3FFDB248


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#907422: python-yaml-dbg is empty

[Adrian Bunk]

Package: python-yaml-dbg
Version: 3.12-1
Severity: serious
Tags: buster sid

$ dpkg -L python-yaml-dbg
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/python-yaml-dbg
$


It seems bogus that python{,3}-yaml-dbgsym are built
in addition to python{,3}-yaml-dbg.

Bug#907420: rt4-standalone is empty

[Adrian Bunk]

Package: rt4-standalone
Version: 4.4.1-3
Severity: serious

$ dpkg -L rt4-standalone
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/rt4-standalone
/usr/share/doc/rt4-standalone/NEWS.Debian.gz
/usr/share/doc/rt4-standalone/changelog.Debian.gz
/usr/share/doc/rt4-standalone/copyright
$

Bug#907419: tlmgr: "running on Debian, switching to user mode" even with --usermode

[Jakub Wilk]

Package: texlive-base
Version: 2018.20180824-1
Severity: minor

tlmgr warns me that it's "switching to user mode" even when it was me 
who requested the user mode:


  $ tlmgr --usermode list
  (running on Debian, switching to user mode!)
  ...

Please silence this message when the --usermode option was explicitly 
enabled.



-- System Information:
Architecture: i386

Versions of packages texlive-base depends on:
ii  debconf   1.5.69
ii  tex-common6.09
ii  libpaper-utils1.1.24+nmu5
ii  sensible-utils0.0.12
ii  texlive-binaries  2018.20180824.48463-1
ii  ucf   3.0038
ii  xdg-utils 1.1.3-1

--
Jakub Wilk

Bug#907338: tracker.debian.org: confusion between keyword and keywordall

[shirish शिरीष]

Reply in-line :-

On 27/08/2018, Raphael Hertzog  wrote:
> Hi,
>

Hi,

> On Sun, 26 Aug 2018, shirish शिरीष wrote:
>> According to
>> https://qa.pages.debian.net/distro-tracker/usage/mailbot.html
>> one can interact with the tracker via email, while some parts work,
>> some parts don't .
>>
>> I tried using keywordall but for some reason that didn't work. Is this
>> to be used by a team or by a user, it's not clear :(
>
> In fact the command "keywordall" doesn't exist at all. This is a left-over
> from the documentation of the former implementation of the package
> tracker. I dropped it from the doc.
>

Thank you.

>> 2. keyword [email id] - This one worked as well and sent me a list of
>> all the keywords I'm accepting, unfortunately it tole me I'm accepting
>> all the keywords.
>
> Why "unfortunately"?
>

The point being I didn't know for what packages I have I have
what subscriptions.

For e.g. I like dpkg, apt and some packages and like to know
what bugs have been caught there etc. but not necessarily all others.

What would have been a lot better if possible to have a list of all
the packages with subscriptions on it.  I dunno if it's on the roadmap,
if not will file a wishlist bug for it.

>> Now I tried various methods to just have 'summary' for all the
>> packages I'm subscribed to.
>
> You won't get much with just this keyword.
>
>> The one which worked was -
>>
>> keyword [myemailid] = summary
>
> That's the correct way, yes.
>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: https://www.freexian.com/services/debian-lts.html
> Learn to master Debian: https://debian-handbook.info/get/
>

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#906633: Re%3A vala-panel FTBFS%3A CMake Error at util%2FCMakeLists.txt%3A40 %28set_target_properties%29

[Mike Gabriel]

Control: close -1
Control: fixed -1 0.4.61+repack1-1

Hi Adrian,

On Sun, 19 Aug 2018 02:44:35 +0300 Adrian Bunk  wrote:
> Source: vala-panel
> Version: 0.3.75-2
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=vala-panel
> 
> ...
> CMake Error at util/CMakeLists.txt:40 (set_target_properties):
>   set_target_properties called with incorrect number of arguments.
> 
> 
> CMake Error at util/gtk/CMakeLists.txt:31 (set_target_properties):
>   set_target_properties called with incorrect number of arguments.
> 
> 
> XMLLINT not set and xmllint not found in path; skipping xml preprocessing.
> CMake Error at ui/applets-new/CMakeLists.txt:14 (set_target_properties):
>   set_target_properties called with incorrect number of arguments.
> 
> 
> CMake Error at ui/c-lib/CMakeLists.txt:22 (set_target_properties):
>   set_target_properties called with incorrect number of arguments.
> 
> 
> XMLLINT not set and xmllint not found in path; skipping xml preprocessing.
> CMake Error at ui/CMakeLists.txt:69 (set_target_properties):
>   set_target_properties called with incorrect number of arguments.
> 
> 

This main FTBFS issue has been solved by upload of vala-panel 0.4.61+repack1-1.

Mike
-- 
Sent from my Fairphone (powered by SailfishOS)

Bug#907418: ruby-globalid: autopkgtest regression: RailtieTest#test_GlobalID.app_can_be_set_with_config.global_id.app

[Paul Gevers]

Source: ruby-globalid
Version: 0.3.6-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

Somewhere between 2018-08-18 and 2018-08-25 the autopkgtest of your
package started to fail in testing. I copied the output below.

Unfortunately, this wasn't caught by the migration software, which means
it is probably caused by an indirect (test) dependency, or if you use
autodep8, a direct test dependency. The package hasn't been tested in
unstable for a while (known debci bug), so that can't tell us more.

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

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-globalid/878913/log.gz

RailtieTest#test_GlobalID.app_can_be_set_with_config.global_id.app_= =
RailtieTest#test_SignedGlobalID.verifier_defaults_to_nil_when_secret_token_is_not_present
= Minitest::Runnable#marshal_dump is deprecated. You might be violating
internals. From
/usr/lib/ruby/vendor_ruby/active_support/testing/isolation.rb:46:in `dump'
Minitest::Runnable#marshal_dump is deprecated. You might be violating
internals. From
/usr/lib/ruby/vendor_ruby/active_support/testing/isolation.rb:46:in `dump'
# terminated with exception (report_on_exception is true):
/usr/lib/ruby/vendor_ruby/minitest.rb:961:in `run_one_method':
RailtieTest#run _must_ return a Result (RuntimeError)
from /usr/lib/ruby/vendor_ruby/minitest/parallel.rb:33:in `block (2
levels) in start'
/usr/lib/ruby/vendor_ruby/minitest.rb:961:in `run_one_method':
RailtieTest#run _must_ return a Result (RuntimeError)
from /usr/lib/ruby/vendor_ruby/minitest/parallel.rb:33:in `block (2
levels) in start'
rake aborted!
Command failed with status (1): [ruby -w -I"test"
"/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb"
"test/cases/global_id_test.rb"
"test/cases/global_identification_test.rb"
"test/cases/global_locator_test.rb" "test/cases/railtie_test.rb"
"test/cases/signed_global_id_test.rb" "test/cases/uri_gid_test.rb" -v]

Tasks: TOP => default



signature.asc
Description: OpenPGP digital signature

Bug#907417: libmems: Wrong library Provides for libraries with different ABI

[Steve Langasek]

Package: libmems
Version: 1.6.0+4725-7
Severity: grave
Tags: patch
Justification: renders package unusable
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Andreas,

The latest libmems package builds a libmems1 binary package which declares
'Provides: libmems-1.6-1v5'.  This is completely wrong.  The libmems1
package ships libMems.so.1, and the libmems-1.6-1v5 package shipped
libMems-1.6.so.1.  Declaring Provides: in this way breaks all
reverse-dependencies that were built against previous SONAME (i.e.,
progressivemauve 1.2.0+4713-2 in stable).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libmems-1.6.0+4725/debian/control libmems-1.6.0+4725/debian/control
--- libmems-1.6.0+4725/debian/control   2018-07-26 23:11:01.0 -0700
+++ libmems-1.6.0+4725/debian/control   2018-08-27 11:54:14.0 -0700
@@ -43,12 +43,6 @@
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
-Conflicts: libmems-1.6-1,
-   libmems-1.6-1v5
-Provides: libmems-1.6-1,
-  libmems-1.6-1v5
-Replaces: libmems-1.6-1,
-  libmems-1.6-1v5
 Description: library to support DNA string matching and comparative genomics
  libMems is a freely available software development library to support DNA
  string matching and comparative genomics. Among other things, libMems

Bug#907416: since latest upgrade krunner does not find applications, and systemtray does not start

[Erwan David]

Package: plasma-desktop
Version: 4:5.13.4-1
Severity: normal

Since latest upgrade on 2 different installations, systemtray does not
appear (and connot be started) and krunner finds only the latest
documents, but not the applications nor is it able anymore to execute
a command line.


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

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 plasma-desktop depends on:
ii  breeze   4:5.13.4-1
ii  kactivitymanagerd5.13.4-1
ii  kde-cli-tools4:5.13.4-1
ii  kded55.47.0-1
ii  kio  5.47.0-1
ii  kpackagetool55.47.0-1
ii  libappstreamqt2  0.12.2-2
ii  libc62.27-5
ii  libcanberra0 0.30-6
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8.2.0-4
ii  libkf5activities55.47.0-1
ii  libkf5activitiesstats1   5.49.0-1
ii  libkf5archive5   5.47.0-1
ii  libkf5auth5  5.47.0-1
ii  libkf5baloo5 5.47.0-1
ii  libkf5codecs55.47.0-1
ii  libkf5completion55.47.0-1
ii  libkf5configcore55.47.0-1
ii  libkf5configgui5 5.47.0-1
ii  libkf5configwidgets5 5.47.0-1
ii  libkf5coreaddons55.47.0-1
ii  libkf5dbusaddons55.47.0-1
ii  libkf5declarative5   5.47.0-1
ii  libkf5emoticons-bin  5.47.0-1
ii  libkf5emoticons5 5.47.0-1
ii  libkf5globalaccel-bin5.47.0-1
ii  libkf5globalaccel5   5.47.0-1
ii  libkf5guiaddons5 5.47.0-1
ii  libkf5i18n5  5.47.0-1
ii  libkf5iconthemes55.47.0-1
ii  libkf5itemmodels55.47.0-1
ii  libkf5itemviews5 5.47.0-1
ii  libkf5jobwidgets55.47.0-1
ii  libkf5kcmutils5  5.47.0-1
ii  libkf5kdelibs4support5   5.47.0-1
ii  libkf5kiocore5   5.47.0-1
ii  libkf5kiofilewidgets55.47.0-1
ii  libkf5kiowidgets55.47.0-1
ii  libkf5newstuff5  5.47.0-1
ii  libkf5notifications5 5.47.0-1
ii  libkf5notifyconfig5  5.47.0-1
ii  libkf5package5   5.47.0-1
ii  libkf5parts5 5.47.0-1
ii  libkf5people55.47.0-1
ii  libkf5peoplewidgets5 5.47.0-1
ii  libkf5plasma55.47.0-1
ii  libkf5plasmaquick5   5.47.0-1
ii  libkf5quickaddons5   5.47.0-1
ii  libkf5runner55.47.0-1
ii  libkf5service-bin5.47.0-1
ii  libkf5service5   5.47.0-1
ii  libkf5solid5 5.47.0-1
ii  libkf5sonnetui5  5.47.0-1
ii  libkf5wallet-bin 5.47.0-1
ii  libkf5wallet55.47.0-1
ii  libkf5widgetsaddons5 5.47.0-1
ii  libkf5windowsystem5  5.47.0-1
ii  libkf5xmlgui55.47.0-1+b1
ii  libkfontinst54:5.13.4-1
ii  libkfontinstui5  4:5.13.4-1
ii  libkworkspace5-5 4:5.13.4-1
ii  libphonon4qt5-4  4:4.10.1-1
ii  libpulse-mainloop-glib0  12.0-1
ii  libpulse012.0-1
ii  libqt5concurrent55.11.1+dfsg-6
ii  libqt5core5a 5.11.1+dfsg-6
ii  libqt5dbus5  5.11.1+dfsg-6
ii  libqt5gui5   5.11.1+dfsg-6
ii  libqt5network5   5.11.1+dfsg-6
ii  libqt5printsupport5  5.11.1+dfsg-6
ii  libqt5qml5   5.11.1-4
ii  libqt5quick5 5.11.1-4
ii  libqt5quickwidgets5  5.11.1-4
ii  libqt5sql5   5.11.1+dfsg-6
ii  libqt5svg5   5.11.1-2
ii  libqt5widgets5  

Bug#907415: tlmgr: unhelpful "Cannot determine type of tlpdb from /home/.../texmf!"

[Jakub Wilk]

Package: texlive-base
Version: 2018.20180824-1
Severity: minor

Trying to learn how to use tlmgr was a bit unpleasant experience.
I first tried this:

  $ tlmgr update
  (running on Debian, switching to user mode!)
  Cannot determine type of tlpdb from /home/jwilk/texmf!
  cannot setup TLPDB in /home/jwilk/texmf at /usr/bin/tlmgr line 6513.

The error messages gave me no clue what is wrong.
OK, I found in the man page that I'm supposed to run init-usertree 
beforehand:


  $ tlmgr init-usertree
  (running on Debian, switching to user mode!)
  Cannot determine type of tlpdb from /home/jwilk/texmf!

This looks like it failed too, but it did in fact succeed.

Please make the messages more helpful, for example:

  $ tlmgr update
  (running on Debian, switching to user mode!)
  /home/jwilk/texmf does not exist; run "tlmgr init-usertree" first.

  $ tlmgr init-usertree
  Successfully initialized TLPDB in /home/jwilk/texmf/.


-- System Information:
Architecture: i386

Versions of packages texlive-base depends on:
ii  debconf   1.5.69
ii  tex-common6.09
ii  libpaper-utils1.1.24+nmu5
ii  sensible-utils0.0.12
ii  texlive-binaries  2018.20180824.48463-1
ii  ucf   3.0038
ii  xdg-utils 1.1.3-1

--
Jakub Wilk

Bug#870701: Bug 870701: Also in python-pip

[PieterB (piet...@gmail.com)]

I can confirm that this also happens in python-pip and python3-pip.
I found one work around that seems to work and that is to add a timeout,
e.g.

pip3 --default-timeout=1000 install requests

I also found reports that this is ipv6 related. Better to just upgrade to
v18+ as is
recommended in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901393

Bug#907332: ghostscript has a new code execution issue, even when used with -dSAFER

[Jonas Smedegaard]

Quoting Salvatore Bonaccorso (2018-08-26 21:55:14)
> Hi,
> 
> On Sun, Aug 26, 2018 at 06:08:58PM +0100, Nicolas Braud-Santoni wrote:
> > Tavis Ormandy disclosed a new ghoscript security issue, leading directly to 
> > code
> > execution:  http://openwall.com/lists/oss-security/2018/08/21/2
> 
> There are actually several issues, see the whole thread. For now since
> you filled this bug will track all those with this bug entry. Proper
> evaluation though is still pending (and Moritz is taking care of
> strech, adding this note to dsa-needed file ("needs some research on
> issues found by Tavis").
> 
> See
> 
> https://www.kb.cert.org/vuls/id/332928
> 
> the current set of fixes:
> 
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=b575e1ec
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8e9ce501
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=241d9111
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=c432131c
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=e01e77a3
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=0edd3d6c
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a054156d
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=0d390118
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=c3476dde
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=b326a716
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=78911a01
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=5516c614

Also http://git.ghostscript.com/?p=ghostpdl.git;h=0b6cd19


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#907414: twitter-bootstrap3: CVE-2018-14040 CVE-2018-14041 CVE-2018-14042

[Antoine Beaupre]

Package: twitter-bootstrap3
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for twitter-bootstrap3.

CVE-2018-14040[0]:
| In Bootstrap before 4.1.2, XSS is possible in the collapse data-parent
| attribute.

CVE-2018-14041[1]:
| In Bootstrap before 4.1.2, XSS is possible in the data-target property
| of scrollspy.

CVE-2018-14042[2]:
| In Bootstrap before 4.1.2, XSS is possible in the data-container
| property of tooltip.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-14040
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14040
[1] https://security-tracker.debian.org/tracker/CVE-2018-14041
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14041
[2] https://security-tracker.debian.org/tracker/CVE-2018-14042
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14042

Please adjust the affected versions in the BTS as needed.

-- 


signature.asc
Description: PGP signature

Bug#907411: pcsx2 FTBFS with gcc 8

[Juhani Numminen]

On Mon, 27 Aug 2018 20:55:56 +0300 Adrian Bunk  wrote:
> Source: pcsx2
> Version: 1.4.0+dfsg-2
> Severity: serious
> Tags: ftbfs
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/pcsx2.html
> 
> ...
> In file included from /usr/lib/gcc/i686-linux-gnu/8/include/x86intrin.h:74,
>  from 
> /build/1st/pcsx2-1.4.0+dfsg/common/src/x86emitter/cpudetect.cpp:19:
> /usr/lib/gcc/i686-linux-gnu/8/include/xsaveintrin.h:60:1: error: ambiguating 
> new declaration of 'long long int _xgetbv(unsigned int)'
>  _xgetbv (unsigned int __A)
>  ^~~
> In file included from 
> /build/1st/pcsx2-1.4.0+dfsg/common/include/Pcsx2Defs.h:31,
>  from 
> /build/1st/pcsx2-1.4.0+dfsg/common/src/x86emitter/PrecompiledHeader.h:23,
>  from 
> /build/1st/pcsx2-1.4.0+dfsg/common/src/x86emitter/cpudetect.cpp:16:
> /build/1st/pcsx2-1.4.0+dfsg/common/include/intrin_x86.h:107:69: note: old 
> declaration 'long long unsigned int _xgetbv(unsigned int)'
>  static __inline__ __attribute__((always_inline)) unsigned long long 
> _xgetbv(unsigned int index)

This might be relevant:

"common: Use GCC's _xgetbv definition from GCC 8.2 onwards
The _xgetbv bug was fixed, so avoid using our own definition (again)."
https://github.com/PCSX2/pcsx2/commit/e8ed18febaa046a3383a4b960517372a5bc554d1


Regards,
Juhani

Bug#906284: CC0 is short

[Chris Lamb]

Hi Julian,

> I hope I have found the right place to apply it

I appear to have confused you, apologies. I am prepared to make this
change myself, I am only looking for example license texts that should
and should not trigger this.

> > Apply to apply this, but before I do can you supply some "known good"
^

This should have read "Happy to apply this."

Regards,

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

Bug#824649:

[Felix Krull]

Has there been any progress on this? I've been working on my own builder
script (https://gitlab.com/fkrull/debian-ostree-compose; I wasn't actually
aware of the one mentioned above, but mine has turned out quite similar
overall).

The booting part of ostree-boot has worked quite well, but I've been having
some difficulties getting the deployment part to work: i.e. create an
OSTree deployment from a regular Debian system and boot that. Once that's
worked out, I should be able to provide some step-by-step instructions.

I have one question about the description: The ostree-boot.control file
states that "the root filesystem must be one that dracut can mount without
a root= command-line argument". Unless I'm misunderstanding it, this
doesn't seem to be correct (any more)? In my tests, I've happily booted VMs
from MBR disks with LVM2 root partitions.

-Felix

Bug#907402: intel-microcode: Missing microcodes

[Henrique de Moraes Holschuh]

retitle 907402 intel-microcode: sig 0x206c2 (2nd Gen i7, Xeon 5600) update 
missing
thanks

> Then I checked the contents of the package and I noticed that the
> microcode file (intel-ucode/06-2c-02) for my CPU (Xeon E5620) is
> missing.  This microcode is present in the archive
> (microcode-20180807.tgz) downloaded from Intel's site and can be
> loaded manually.
> 
> Is this intentional and should we expect a new package with additional
> microcodes included?

Yes, it is intentional.

The text for Intel SA-00030 makes it clear that some platforms are not
to have that specific microcode updated without the corresponding BIOS
update, as the microcode requires an up-to-date SINIT ACM (Intel
TXT/vPRO firmware component).

When you update just the microcode in such a machine, according to my
reading of the text in the Intel SA-00030 advisory, it will disable
Intel TXT until you somehow manage to update the BIOS.  Worse, that
change cannot be undone by just removing the microcode update: it
supposedly modifies the contents of the platform TPM, which is a
persistent change that cannot be undone.

If the BIOS is using Intel TXT to implement secure boot, that may brick
the machine since it will disable Intel TXT, etc.   If the BIOS is not
in secure mode, it should not cause issues -- but this is *not* certain.

References:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00030.html

Intel SA-00030 excerpt:

  Recommendations: 

[...] If your BIOS includes an SINIT ACM, which is more common for
Intel® TXT server platforms, a BIOS update that includes the updated
SINIT ACM should be installed; please contact your platform OEM.
Intel is also providing microcode updates, which will revoke
vulnerable SINIT ACMs by causing GETSEC[SENTER] to fail.  The BIOS
update that contains the new microcode patch should be installed on
all affected systems. Note that prior to installing the microcode
update, an updated SINIT ACM must be installed to launch your Intel
TXT enabled software.  Contact your solutions provider or Intel®TXT
software vendor if your Intel®TXT environment fails to launch and to
determine how to update your software with the new SINIT ACM. Intel
highly recommends that these updates be applied to mitigate this
issue.

Evidently, just about everyone else is distributing this microcode
update (0x206c2) since Intel did finally include it in a public
distribution (after an hiatus of *years* refusing to distribute any of
the dozens of microcode updates 0x206c2 had in the meantime, and those
were *security* fixes that they distributed for several other processors
including 1st gen i7 and Xeon 5500).

The fact is that Debian has had that blacklisting in place for a while
now, and Intel for a long time acted as if that microcode update was
something not to be trifled with.  There is no way we can simply remove
it without being reasonably sure it is safe to do so.

If you are *not* using Intel TXT in your 2nd gen Core i7 or Xeon 5600
(as in: it is not present at all, or it is very much *disabled* in the
BIOS *and* all secure- is also disabled in the BIOS) as far as
I know it should be reasonably safe to manually add the 0x206c2 update
to "/usr/share/misc/intel-microcode-206c2.bin".  The intel-microcode
package will detect, and use it (issue "update-initramfs -u" to refresh
the microcode in the initramfs).  If you do this, please ensure that
data file is owned by root, and can only be written to by root.

-- 
  Henrique Holschuh

Bug#907171: prometheus FTBFS:

[Martín Ferrari]

On 27/08/18 17:08, Adrian Bunk wrote:

> How often did you try?
> 
> I would say the probability to hit is somewhere around 50%:
> https://tests.reproducible-builds.org/debian/history/prometheus.html

I just tried 20 builds, while using desktop applications that put some
extra strain on tHE CPU, and none failed..


-- 
Martín Ferrari (Tincho)

Bug#776240: pmount: Bash-completion hangs until interrupted

[Toby Speight]

Package: pmount
Version: 0.9.23-3+b2
Severity: normal
Tags: patch
File: /etc/bash_completion.d/pmount

When I used tab-completion on a pmount command, it would hang
indefinitely.  The problem was here:

/
| grep $mdir /proc/mounts
\

Because $mdir isn't set in _pmount(), grep sees only one argument
"/proc/mounts", which it interprets as the search regexp, and so it
waits for input on stdin.

A simple fix would be to copy the initialisation of $mdir from
_pumount(), but I got carried away: I was frustrated by being unable to
complete using the links in /dev/disk/by-*/.

So I include a pair of completions, to go into the more modern location
of /usr/share/bash-completion/completions:

_pmount() {
# shellcheck disable=SC2034
local cur prev words cword
_init_completion || return

   case "$prev" in
   -@(t|-type))
  COMPREPLY=($(grep "^[[:space:]]$cur" /proc/filesystems) $(find "/lib/modules/$(uname -r)/kernel/fs" -name "*.ko" -print0 | xargs -r -0 /sbin/modinfo | sed -ne 's/^alias: *fs-//p' | grep "^$cur"))
  return 0
  ;;

  -@(c|-charset))
  local encodings=(/sys/module/nls_* $(find "/lib/modules/$(uname -r)/kernel/fs/nls" -name '*.ko' -print0 | xargs -r -0 /sbin/modinfo | sed -ne 's/^\(name\|alias\): *//p'))
  COMPREPLY=($(compgen -W "${encodings[*]##*nls_}" -- "$cur"))
  return 0
  ;;
  -@(u|d|f|-umask|-dmask|-fmask))
  case "$cur" in
  '') COMPREPLY=( {0..7} ) ;;
  [0-7]|[0-7][0-7]) COMPREPLY=( $cur{0..7} ) ;;
  [0-7][0-7][0-7]) COMPREPLY=( $cur ) ;;
  *) return 1 ;;
  esac
  return 0
  ;;

  -@(p|-passphrase))
  _filedir
  return 0
  ;;

   esac

   if [[ "$cur" == -* ]]; then
# transform "--help" output into completion list
   COMPREPLY=($(compgen -W "$(pmount --help | sed -e '/^..-/!d' -e 's/:.*//' -e 's/<[^>]*>//g' -e 'y/,/ /')" -- "$cur"))
   else
   local i allowed removable devices search
   local IFS=$'\n'
   allowed=($(grep -v '^[[:space:]]*#' /etc/pmount.allow))
   removable=($(for i in /sys/block/*
do
grep -Fxq 1 "$i/removable" || continue
# Replace with its partitions, if it has any - N.B. final /. is crucial, as
# subsystem entries are symlinks!
find "$i"/*/subsystem/. -maxdepth 0 -samefile "$i"/subsystem/. -print0 \
| awk -F/ -v RS='\0' -v i="${i##*/}" '{print"/dev/"$(NF-2)} END{if(!NR)print"/dev/"i}'
# # alternative non-awk version:
# j=$(find "$i"/*/subsystem/. -maxdepth 0 -samefile "$i"/subsystem/. -exec dirname '{}' \;)
# sed -e 's,.*/,/dev/,' <<<"${j:-$i}"
done))
   # Select only actual block devices that aren't already mounted
   # N.B. expansion of $allowed is unquoted, as wildcards are permitted
   devices=($(for i in ${allowed[*]} "${removable[@]}"; do test -b "$i" && echo "$i"; done | grep -vxF "$(cut -d' ' /proc/mounts -f1)"))
   test "${#devices[@]}" -gt 0 || return 0
   for i in "${devices[@]}"
   do search+=(-o -samefile "$i")
   done
   # alternative names - symlinks in /dev/disk/*/
   devices+=($(find -L /dev/disk -false "${search[@]}"))
   # all found names for mountable block devices, with and without initial /dev/
   COMPREPLY=($(compgen -W "$(printf '%q\n' "${devices[@]}" "${devices[@]#/dev/}")" -- "$cur"))
   fi
} &&
complete -F _pmount pmount
_pumount() {
# shellcheck disable=SC2034
local cur prev words cword
_init_completion || return

if [[ "$cur" == -* ]]; then
# transform "--help" output into completion list
   COMPREPLY=($(compgen -W "$(pumount --help | sed -e '/^..-/!d' -e 's/:.*//' -e 's/<[^>]*>//g' -e 'y/,/ /')" -- "$cur"))
   else
   local i mdir devices mounts search symlinks
   mdir=$(readlink -f /media)
   # shellcheck disable=SC2013
   for i in $(cut -d' ' -f1,2 /proc/mounts | grep -F " $mdir/")
   do
   # expand backslash escapes
   i=$(printf '%b' "$i")
   if test -b "$i"
   then
   search+=(-o -samefile "$i")
   devices+=("$i" "${i#/dev/}")
   elif test -d "$i"
   then
   mounts+=("$i" "${i#$mdir/}")
   fi
   done

   # alternative names - symlinks in /dev/disk/*/ and device or mountpoint basenames
   local IFS=$'\n'
   symlinks=($(find -L /dev/disk -false "${search[@]}"))
   COMPREPLY=($(compgen -W "$(printf '%q\n' "${mounts[@]}" "${devices[@]}" "${symlinks[@]}" "${symlinks[@]#/dev/}")" -- "$cur"))
   fi
} &&
complete -F _pumount pumount

I think these are a better match for what pmount and pumount accept as
arguments.  I've tested them with a variety of removable media (with
various partition layouts and some with multiple LUNs) and have been
using this 

Bug#905431: libreoffice-common: LibreOffice fails to print text unless "PDF as standard print job format" is chosen

[Rene Engelhard]

Hi,

On Sat, Aug 04, 2018 at 09:41:04PM +0100, Andrew Rule wrote:
>Just checked, and it appears that print option "PDF as standard print job
>format" is a standard setting, so I imagine you have to go into settings
>to turn it off.

Indeed.

That said there is also http://bugs.debian.org/906726, which was also
filed as https://bugs.documentfoundation.org/show_bug.cgi?id=119357.
Which is fixed in 6.1.1 rc1 (and that one is in unstable).

Does it work with 6.1.1 rc1?

Regards,

Rene

Bug#907413: gnuplot-qt: has a number broken symlinks

[Nicholas D Steeves]

Package: gnuplot-qt
Version: 5.0.5+dfsg1-6+deb9u1
Severity: normal

Dear Gnuplot maintainer,

Today, while searching for a nice packaging example of how to use the
Debian alternatives system (in a package) I noticed that gnuplot-qt
had three broken symlinks in /etc/alternatives.  I believe this
stretch system began as a squeeze installation, or was possibly
installed early in wheezy's freeze.

The first two broken symlinks appear to be lint resulting from a
transition:

  /etc/alternatives/gnuplot5:
  broken symbolic link to /usr/bin/gnuplot5-qt
  /etc/alternatives/gnuplot5.1.gz:
  broken symbolic link to [presumably /usr/share/man/man1/gnuplot5-qt.1.gz]

and this one is also broken:

  /usr/share/man/man1/gnuplot5.1.gz:
  broken symbolic link to /etc/alternatives/gnuplot5.1.gz

however, "man gnuplot" works as expected because:

  /usr/share/man/man1/gnuplot.1.gz:
  symbolic link to /etc/alternatives/gnuplot.1.gz
  /etc/alternatives/gnuplot.1.gz:
  symbolic link to /usr/share/man/man1/gnuplot-qt.1.gz


Maybe it's fixed in sid?

Regards,
Nicholas

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

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

Versions of packages gnuplot-qt depends on:
ii  gnuplot-data 5.0.5+dfsg1-6+deb9u1
ii  libc62.24-11+deb9u3
ii  libcairo21.14.8-1
ii  libedit2 3.1-20160903-3
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgd3   2.2.4-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libqt5core5a 5.7.1+dfsg-3+b1
ii  libqt5gui5   5.7.1+dfsg-3+b1
ii  libqt5network5   5.7.1+dfsg-3+b1
ii  libqt5printsupport5  5.7.1+dfsg-3+b1
ii  libqt5svg5   5.7.1~20161021-2+b2
ii  libqt5widgets5   5.7.1+dfsg-3+b1
ii  libstdc++6   6.3.0-18+deb9u1
ii  libwxbase3.0-0v5 3.0.2+dfsg-4
ii  libwxgtk3.0-0v5  3.0.2+dfsg-4
ii  libx11-6 2:1.6.4-3

gnuplot-qt recommends no packages.

Versions of packages gnuplot-qt suggests:
pn  gnuplot-doc  

-- no debconf information

Bug#906726: libreoffice printing bug

[Rene Engelhard]

Hi,

On Mon, Aug 20, 2018 at 09:47:04AM +0100, Mark van Rossum wrote:
> I reported the bug at:
> https://bugs.documentfoundation.org/show_bug.cgi?id=119357

That one says:

--- snip ---
Commit Notification 2018-08-23 12:54:59 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4a58fd0e81b0375c71f6182233f0ec9390942cd1

tdf#119357 add the glyph, if the lookup failed

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 25 Commit Notification 2018-08-23 14:40:40 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d49069887443c9eeac9c52441ad1a183d12c384=libreoffice-6-1

tdf#119357 add the glyph, if the lookup failed

It will be available in 6.1.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 26 dxt.tfg 2018-08-23 16:27:27 UTC
I can confirm that the daily build of 6.1.1 dev fixed this issue (tested
on Mx Linux 17.1 and Linux Mint 18.3), and an another issue seen in
6.0.6 version that accented characters are printed as square characters.
Comment 27 Xisco Faulí 2018-08-27 15:13:10 UTC
(In reply to dxt.tfg from comment #26)
> I can confirm that the daily build of 6.1.1 dev fixed this issue
> (tested on
> Mx Linux 17.1 and Linux Mint 18.3), and an another issue seen in 6.0.6
> version that accented characters are printed as square characters.


Thanks for checking it in LibreOffice 6.1.1.
Setting to VERIFIED FIXED
--- snip ---

said commit is in 1:6.1.1~rc1-1 - so is in unstable. Can you confirm
it works?

Regards,

Rene

Bug#907303: apparmor: libreoffice stops start with last update

[Kamil Jońca]

Vincas Dargis  writes:

> On Sun, 26 Aug 2018 10:58:50 +0200 Kamil Jonca  wrote:
>> After last upgrade of apparmor, soffice command end with error, and in log 
>> we can see:
>>
>> 
>>  audit: type=1400 audit(1535272402.067:422): apparmor="ALLOWED"
>> operation="exec" info="profile transition not found" error=-13
>> profile="libreoffice-oopslash"
>> name="/usr/lib/libreoffice/program/soffice.bin" pid=16727
>> comm="osl_executeProc" requested_mask="x" denied_mask="x" fsuid=1000
>> ouid=0 target="/usr/lib/libreoffice/program/soffice.bin"
>> 
>>
>> workaround is:
>> #aa-disable /etc/apparmor.d/usr.lib.libreoffice.program.oosplash
>
> Hi,
>
> I cannot reproduce that on my machine. Purged libreoffice-common (that
> contains AppArmor profiles) and reinstalled whole libreoffice, but it
> works for me. When ...soffice.bin is in complain *and* in enforce
> mode.
>
> Could it be that you had `usr.lib.libreoffice.program.soffice.bin` profile 
> disabled? Check with:
> ```
> ls /etc/apparmor.d/disable/
> ``
>
>
>

Hm. After reinstalling libreoffice-common and

alfa:~%sudo aa-enforce /etc/apparmor.d/usr.lib.libreoffice.program.oosplash

it start to work.
So it looks like bug can be closed as invalid. Sorry for the noise :(

KJ
-- 
http://wolnelektury.pl/wesprzyj/teraz/
I respect the institution of marriage.  I have always thought that every
woman should marry -- and no man.
-- Benjamin Disraeli, "Lothair"

Bug#907412: ITP: pslibrary -- library of ultrasoft and PAW pseudopotentials

[Andrius Merkys]

Package: wnpp
Severity: wishlist

* Package name: pslibrary
  Version : 1.0.0
  Upstream Author : Andrea Dal Corso
* URL : https://dalcorso.github.io/pslibrary/
* License : GPL-2+
  Description : library of ultrasoft and PAW pseudopotentials

PSlibrary is a library of scalar relativistic and fully relativistic PAW data
sets and ultrasoft pseudopotentials for many elements in Unified
Pseudopotential Format (UPF).

PSlibrary paper [1] is widely cited (with ~60 citations during year 2018) [2]. 
The package consists of pseudopotentials built using Quantum ESPRESSO from
upstream-supplied inputs, resulting in ~3 GB of pseudopotential files (~700 MB
when compressed).

I plan to maintain the package inside the Debichem team.

[1] http://authors.elsevier.com/sd/article/S0927025614005187
[2] 
https://scholar.google.lt/scholar?as_ylo=2018=en_sdt=2005=0,5=8672732540737765863=

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#907411: pcsx2 FTBFS with gcc 8

[Adrian Bunk]

Source: pcsx2
Version: 1.4.0+dfsg-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/pcsx2.html

...
In file included from /usr/lib/gcc/i686-linux-gnu/8/include/x86intrin.h:74,
 from 
/build/1st/pcsx2-1.4.0+dfsg/common/src/x86emitter/cpudetect.cpp:19:
/usr/lib/gcc/i686-linux-gnu/8/include/xsaveintrin.h:60:1: error: ambiguating 
new declaration of 'long long int _xgetbv(unsigned int)'
 _xgetbv (unsigned int __A)
 ^~~
In file included from /build/1st/pcsx2-1.4.0+dfsg/common/include/Pcsx2Defs.h:31,
 from 
/build/1st/pcsx2-1.4.0+dfsg/common/src/x86emitter/PrecompiledHeader.h:23,
 from 
/build/1st/pcsx2-1.4.0+dfsg/common/src/x86emitter/cpudetect.cpp:16:
/build/1st/pcsx2-1.4.0+dfsg/common/include/intrin_x86.h:107:69: note: old 
declaration 'long long unsigned int _xgetbv(unsigned int)'
 static __inline__ __attribute__((always_inline)) unsigned long long 
_xgetbv(unsigned int index)
 ^~~

Bug#906718: [pkg-bacula-devel] Bug#906718: bacula-director-pgsql: Portnumber is not put into /etc/bacula/bacula-dir.conf when setting up bacula-director

[Sven Hartge]

On 8/20/18 9:18 AM, Dieter Scheinkönig wrote:

> While setting up bacula-director, although TCP-+SSL was chosesn and 
> Portnumber was provided, the installation script forgets to put "DB Port" 
> into the catalouge service

I see where the problem is and am testing a fix right now.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#849770: exim4: bogus reject response on overlong lines

[Rúben Leote Mendes]

It seems you are missing the size check in the DATA ACL and so the 
messages are refused in the transport that, as you report, gives a very 
unhelpful error.


The "acl/40_exim4-config_check_data" that ships with stretch should 
refuse the messages with "maximum allowed line length is 998 octets, got 
$max_received_linelength", which is much more helpful:


acl_check_data:

  # Deny if the message contains an overlong line.  Per the standards
  # we should never receive one such via SMTP.
  #
  .ifndef IGNORE_SMTP_LINE_LENGTH_LIMIT
  deny    message    = maximum allowed line length is 998 octets, \
   got $max_received_linelength
  condition  = ${if > {$max_received_linelength}{998}}
  .endif

I had to disable the check because it was blocking many legitimate 
messages, so it should probably not be the default.


Rúben

Bug#907401: RFS: dbab/1.3.2-2 [new version update]

[Tong Sun]

On Monday, August 27, 2018, Andrey Rahmatullin  wrote:

> On Mon, Aug 27, 2018 at 11:30:55AM -0400, Tong Sun wrote:
> > I updated my dbab to a newer version -- to accommodate for the bug
> > #903065, which requested to update Build-Depends: ruby-ronn -> ronn.
> You should close that bug in the changelog entry then, see
> https://www.debian.org/doc/manuals/developers-reference/
> ch05.en.html#upload-bugfix
>

Oh, yeah, forgot about that.

Will close it in the changelog entry.

Thx