Bug#911281: disorderfs: can not update only mtime

[Bernhard M. Wiedemann]

Package: disorderfs
Version: 0.5.4
Severity: normal

Dear Maintainer,

   * I found that files extracted by tar into a disorderfs did not
 have their original mtime restored by futimens / utimensat syscalls
   * Same effect for touch -m -d@123 $FILE or touch -a
 that left mtime and atime unchanged
   * Both use the special UTIME_OMIT value in a tv_nsec field
   * But using touch to update both atime and mtime works fine.

-- System Information:
openSUSE Release: 15.0
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.14 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Bug#885114: bless: Don't depend on rarian

[Jeremy Bicha]

Control: severity -1 serious
Control: tags -1 +patch

I have proposed a merge request to fix this issue.

https://salsa.debian.org/dotnet-team/bless/merge_requests/1

Thanks,
Jeremy Bicha

Bug#909135: [Pkg-samba-maint] Bug#909135: consider dropping python support from libtevent.a

[Mathieu Parent]

Hi,
Le mar. 18 sept. 2018 à 21:54, Helmut Grohne  a écrit :
[...]
> Given that you cannot load a static library into a Python interpreter
> and that static linking is discouraged in Debian, it would seem that the
> use of Python support in a static library is quite limited. How about
> removing it by passing --disable-python?

OK. But if we do this, we will probably forget when enabling python
(which is a nice to have).

What about simply removing libtevent.a?

Can you propose a merge request for this?

> The resulting simplification of Build-Depends should bring us closer to
> cross building tevent.

Regards

Mathieu Parent

Bug#911280: smartmontools: DEVICESCAN pattern doesn't match /dev/nvme*

[Carl Suster]

Package: smartmontools
Version: 6.6-1
Severity: normal

Dear Maintainer,

I see the same systemd error status reported in #862908, however unlike that
reporter my system does have an SSD disk, mounted at /dev/nvme0n1. If
I manually execute smartctl --all /dev/nvme0 I get SMART data, so it's clearly
a supported NVMe disk.

/dev/nvm* paths don't seem to be included in the pattern searched by DEVICESCAN
leading it to conclude that there are no disks. Is there any reason why the
default pattern can't be extended to include NVMe paths?

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

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

Versions of packages smartmontools depends on:
ii  debianutils  4.8.6
ii  libc62.27-6
ii  libcap-ng0   0.7.9-1
ii  libgcc1  1:8.2.0-7
ii  libselinux1  2.8-1+b1
ii  libstdc++6   8.2.0-7
ii  lsb-base 9.20170808

Versions of packages smartmontools recommends:
ii  mailutils [mailx]  1:3.4-2

Versions of packages smartmontools suggests:
pn  gsmartcontrol   
pn  smart-notifier  

-- no debconf information

Bug#911279: tweak FTCBFS: uses the wrong compiler

[Helmut Grohne]

Source: tweak
Version: 3.02-3
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

tweak fails to cross build from source, because it uses the build
architecture compiler as linker. The upstream Makefile stores the
compiler in two variables CC and LINK and dh_auto_build only supplies
the former. We could add an override_dh_auto_build to fix that, but it
seems much more natural to default LINK to $(CC). Please consider
applying the attached patch.

Helmut
--- tweak-3.02.orig/Makefile
+++ tweak-3.02/Makefile
@@ -18,7 +18,7 @@
 
 CC ?= gcc
 CFLAGS ?= -g -Wall $(XFLAGS)
-LINK ?= gcc
+LINK ?= $(CC)
 
 PREFIX=$(DESTDIR)/usr/local
 BINDIR=$(PREFIX)/bin

Bug#907298: CVE-2018-15869

[Shengjing Zhu]

Package: awscli
Followup-For: Bug #907298

The corresponding bug on Redhat is closed as

> Closing this bug as NOTABUG and asked MITRE for rejection, since the issue
> does not seem to be in AWS CLI but in Packer.

Can we downgrade this bug and keep awscli in buster?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1623095

-- 
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#911278: php7cc: PHP Fatal error: Uncaught Error: Cannot instantiate interface PhpParser\Parser

[Paul Wise]

Package: php7cc
Version: 1.2.1-1
Severity: serious

php7cc doesn't appear to work at all. I tried with a empty directory
and with an empty file as well as with some old PHP code and all three
invocations produced the same set of errors:

$ php7cc .
PHP Fatal error:  Uncaught Error: Cannot instantiate interface PhpParser\Parser 
in /usr/share/php/Sstalle/php7cc/Infrastructure/ContainerBuilder.php:165
Stack trace:
#0 /usr/share/php/Pimple/Container.php(113): 
Sstalle\php7cc\Infrastructure\ContainerBuilder->Sstalle\php7cc\Infrastructure\{closure}(Object(Pimple\Container))
#1 /usr/share/php/Sstalle/php7cc/Infrastructure/ContainerBuilder.php(195): 
Pimple\Container->offsetGet('parser')
#2 /usr/share/php/Pimple/Container.php(113): 
Sstalle\php7cc\Infrastructure\ContainerBuilder->Sstalle\php7cc\Infrastructure\{closure}(Object(Pimple\Container))
#3 /usr/share/php/Sstalle/php7cc/Infrastructure/ContainerBuilder.php(220): 
Pimple\Container->offsetGet('contextChecker')
#4 /usr/share/php/Pimple/Container.php(113): 
Sstalle\php7cc\Infrastructure\ContainerBuilder->Sstalle\php7cc\Infrastructure\{closure}(Object(Pimple\Container))
#5 /usr/share/php/Sstalle/php7cc/Infrastructure/ContainerBuilder.php(229): 
Pimple\Container->offsetGet('pathChecker')
#6 /usr/share/php/Pimple/Container.php(113): Ss in 
/usr/share/php/Sstalle/php7cc/Infrastructure/ContainerBuilder.php on line 165

$ touch foo.php
$ php7cc foo.php 
PHP Fatal error:  Uncaught Error: Cannot instantiate interface PhpParser\Parser 
in /usr/share/php/Sstalle/php7cc/Infrastructure/ContainerBuilder.php:165
Stack trace:
#0 /usr/share/php/Pimple/Container.php(113): 
Sstalle\php7cc\Infrastructure\ContainerBuilder->Sstalle\php7cc\Infrastructure\{closure}(Object(Pimple\Container))
#1 /usr/share/php/Sstalle/php7cc/Infrastructure/ContainerBuilder.php(195): 
Pimple\Container->offsetGet('parser')
#2 /usr/share/php/Pimple/Container.php(113): 
Sstalle\php7cc\Infrastructure\ContainerBuilder->Sstalle\php7cc\Infrastructure\{closure}(Object(Pimple\Container))
#3 /usr/share/php/Sstalle/php7cc/Infrastructure/ContainerBuilder.php(220): 
Pimple\Container->offsetGet('contextChecker')
#4 /usr/share/php/Pimple/Container.php(113): 
Sstalle\php7cc\Infrastructure\ContainerBuilder->Sstalle\php7cc\Infrastructure\{closure}(Object(Pimple\Container))
#5 /usr/share/php/Sstalle/php7cc/Infrastructure/ContainerBuilder.php(229): 
Pimple\Container->offsetGet('pathChecker')
#6 /usr/share/php/Pimple/Container.php(113): Ss in 
/usr/share/php/Sstalle/php7cc/Infrastructure/ContainerBuilder.php on line 165

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

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

Versions of packages php7cc depends on:
ii  php-cli   1:7.2+62
ii  php-common1:62
ii  php-parser3.1.5-1
ii  php-pimple3.0.2-2
ii  php-symfony-console   3.4.17+dfsg-1
ii  php-symfony-finder3.4.17+dfsg-1
ii  php7.2-cli [php-cli]  7.2.9-1

php7cc recommends no packages.

php7cc suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#911277: ITP: termbox -- Library for writing text-based user interfaces

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: termbox
  Version : 1.1.2+dfsg
  Upstream Author : nsf
* URL : https://github.com/nsf/termbox
* License : Expat
  Programming Lang: C, Python
  Description : Library for writing text-based user interfaces

Bug#885698: Update and document criteria for inclusion in /usr/share/common-licenses

[Paul Hardy]

Control: block 910548 by -1

Blocking my own bug report with this one, which I just noticed.

I submitted bug #910548 previously against the base-files package:
"base-files - please consider adding
/usr/share/common-licenses/Unicode-Data".

I had formatted the copyright and license information for Unicode data
files from the http://unicode.org website to put in the
debian/copyright file in a package that I created this summer.  The
copyright information is more involved than most copyright statements,
so I kept it in what I submitted with the bug report.

I thought if that license was something Debian found useful, there
would be no need for anyone else to duplicate the effort of formatting
that I had gone through once, and so I offered it.  Just the license
in isolation could be formatted like other licenses fairly quickly if
the copyright section is not wanted.  Or the whole thing can be left
out and that bug closed, as you wish.

Thanks,


Paul Hardy

Bug#911275: systemd: ignores swap options (discard) from /etc/fstab ?

[Michael Biebl]

Am 18.10.18 um 04:42 schrieb Michael Biebl:
> Am 18.10.18 um 02:23 schrieb Bob Bib:
>>
>> UUID= none    swap    sw,discard=once 
>> 0   0
> 
> Where is that discard mount option documented?

And please also test this with v239 from sid/buster


-- 
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#860551: fixed in lirc 0.10.0~rc3-1

[Pablo G Goikoetxea]

Hi folks

I arrived here because my ssh service refused to restart throwing the 
very same error code. It was caused by mistyping a line in sshd_config 
file  (PermitEmptyPasswords "nonoyes", without quotes).


Not sure this might help the bug issue, just in case...

Pablo

--

Pablo G Goicoechea
C/ Conde Don Vela 54, 2º izda
01009 Vitoria-Gasteiz
Spain
Phone:+34629443307
-

Bug#911275: systemd: ignores swap options (discard) from /etc/fstab ?

[Michael Biebl]

Am 18.10.18 um 02:23 schrieb Bob Bib:
> 
> UUID= none    swap    sw,discard=once 
> 0   0

Where is that discard mount option documented?

-- 
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#870267: graphicsmagick frequently FTBFS on ppc64el: test hang

[Aee Freedom]

On Tue, 22 Aug 2017 17:13:17 +0300 Adrian Bunk  wrote:
> Control: severity -1 serious
>
> On Thu, Aug 10, 2017 at 01:02:54PM +0200, László Böszörményi wrote:
> >...
> >  OK, GCC 7.1.0 arrived to ppc64el and GraphicsMagick no longer FTBFS
> > even on ppc64el-unicamp-01. I don't close this bugreport but lower the
> > severity to let the security fixes finally migrate to Buster
> > (testing). I'll see how future builds do on ppc64el and will act
> > accordingly.
>
> Happened again with 1.3.26-6:
> https://buildd.debian.org/status/fetch.php?pkg=graphicsmagick=ppc64el=1.3.26-6=1503263346=0
>
> > Regards,
> > Laszlo/GCS
>
> cu
> Adrian
>
> BTW: The mips64el build failure looks unrelated, likely caused by #871514.
>
> --
>
>"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
>
>
>




ส่งจากสมาร์ทโฟน Samsung Galaxy ของฉัน

Bug#870267: graphicsmagick frequently FTBFS on ppc64el: test hang

[Aee Freedom]

On Mon, 31 Jul 2017 15:31:20 +0300 Adrian Bunk  wrote:
> Source: graphicsmagick
> Version: 1.3.26-3
> Severity: serious
>
> 2 out of the 4 latest build attempts FTBFS on ppc64el:
>
> https://buildd.debian.org/status/logs.php?pkg=graphicsmagick=ppc64el
> https://buildd.debian.org/status/fetch.php?pkg=graphicsmagick=ppc64el=1.3.26-4=150145=0
>
> ...
> PASS: Magick++/tests/tests.tap 7 - colorHistogram
> PASS: Magick++/tests/tests.tap 8 - exceptions
> PASS: Magick++/tests/tests.tap 9 - montageImages
> PASS: Magick++/tests/tests.tap 10 - morphImages
> PASS: Magick++/tests/tests.tap 11 - readWriteBlob
> PASS: Magick++/tests/tests.tap 12 - readWriteImages
> E: Build killed with signal TERM after 150 minutes of inactivity
>
>
> The next test is "Magick++/demo/demos.tap 1 - analyze",
> this seems to be the hanging one?
>
>




ส่งจากสมาร์ทโฟน Samsung Galaxy ของฉัน

Bug#911276: elfutils: ftbfs on arm64 with gcc-8

[Michael Hudson-Doyle]

Source: elfutils
Version: 0.170-0.4
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

elfutils ftbfs on sid on arm64 currently. Current git passes, and git
bisect and logic point to the following upstream commit as fixing it:

commit f881459ffc95b6fad51aa055a158ee14814073aa
Author: Mark Wielaard 
Date:   Wed Apr 11 10:37:45 2018 +0200

aarch64: Add default cfi rule to restore SP from CFA address.

The CFA is set by default to the stack pointer of the previous frame.
So that is also how we can always restore the SP. This default aarch64
CFI rule is necessary on Fedora 28 with GCC8 to make the run-deleted.sh
and run-backtrace-dwarf.sh testcases work.

Signed-off-by: Mark Wielaard 

so this bug can be closed either with an upstream update (this patch is
in 0.171) or a cherry pick of the above commit.

Cheers,
mwh

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (400, 'bionic-proposed'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#909707: hyphy: autopkgtest

[Ioannis Valasakis]

I am interested in getting assigned this bug and getting to know the process of 
creating an autopkg test :) Regards ioannis

Bug#911104: mosquitto: New upstream release available

[Andreas Henriksson]

Hi Roger,

On Wed, Oct 17, 2018 at 11:36:58PM +0100, Roger Light wrote:
> Hi Andreas,
> 
> Thanks for taking the time to look at it - there are a number of
> changes in the 1.5 series of mosquitto which remove the need for the
> majority of the patches. I've got an updated package but because there
> were a few changes I wanted to give it a bit more of a test and simply
> hadn't got round to it yet. I can see you've made some useful
> additions though, I'd be pleased to take some of those changes for
> sure. I'll try and get this sorted out in the next few days.

Happy to hear back from you and looking forward to seeing your results.
Nice that you where able to find something useful and salvagable from
my packages. If there's anything I can help out with please don't
hesitate to ask!

Regards,
Andreas Henriksson

Bug#911275: systemd: ignores swap options (discard) from /etc/fstab ?

[Bob Bib]

Package: systemd
Version: 232-25+deb9u4
Severity: normal

Dear Maintainer,

Apparently, systemd ignores swap options (namely, "discard") from 
"/etc/fstab";

i.e. my SSD swap partition gets activated, but with TRIM disabled.

For reference:
// 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/mm/swapfile.c?h=v4.9.133#n2567
pr_info("Adding %uk swap on %s.  Priority:%d extents:%d across:%lluk 
%s%s%s%s%s\n",

p->pages<<(PAGE_SHIFT-10), name->name, p->prio,
nr_extents, (unsigned long long)span<<(PAGE_SHIFT-10),
(p->flags & SWP_SOLIDSTATE) ? "SS" : "",
(p->flags & SWP_DISCARDABLE) ? "D" : "",
(p->flags & SWP_AREA_DISCARD) ? "s" : "",
(p->flags & SWP_PAGE_DISCARD) ? "c" : "",
(frontswap_map) ? "FS" : "");

BTW, manually playing with discard options & swapoff/swapon has resulted
in the following (reasonable) changes
of the final word of the kernel message:
 => SSFS
discard => SSDscFS
discard=pages => SSDcFS
discard=once => SSDsFS

P.S. I don't know whether the current issue is related to that old 
openSUSE bug,

but anyway I'm leaving these links here:
https://bugzilla.novell.com/show_bug.cgi?id=897422
https://github.com/systemd/systemd/commit/47cb901e38cd7092576fc8e76cc4a14f39bf719d

-- Package-specific info:

-- 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:en (charmap=UTF-8)

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

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.0-3+deb9u2
ii  libaudit1   1:2.6.7-2
ii  libblkid1   2.29.2-1+deb9u1
ii  libc6   2.24-11+deb9u3
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-4
ii  libgcrypt20 1.7.6-2+deb9u3
ii  libgpg-error0   1.26-2
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-6
ii  libkmod223-2
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.2+b1
ii  libmount1   2.29.2-1+deb9u1
ii  libpam0g1.1.8-3.6
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.6-3+b3
ii  libsystemd0 232-25+deb9u4
ii  mount   2.29.2-1+deb9u1
ii  procps  2:3.3.12-3+deb9u1
ii  util-linux  2.29.2-1+deb9u1

Versions of packages systemd recommends:
ii  dbus1.10.26-0+deb9u1
ii  libpam-systemd  232-25+deb9u4

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

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 232-25+deb9u4

-- no debconf information

-- Some terminal output:
$ cat /etc/fstab
...
UUID= noneswapsw,discard=once  0   0
$ sudo swapoff -va
swapoff /dev/sda4
$ /sbin/swapon
$ sudo swapon -va
swapon: /dev/sda4: found signature [pagesize=4096, signature=swap]
swapon: /dev/sda4: pagesize=4096, swapsize=, devsize=
swapon /dev/sda4
$ sudo journalctl | grep -i swap
Oct 18 01:26:26 Computer1 kernel: zswap: loaded using pool lzo/zbud
Oct 18 01:26:26 Computer1 systemd[1]: Found device  Swap01.
Oct 18 01:26:26 Computer1 systemd[1]: Found device  Swap01.
Oct 18 01:26:26 Computer1 systemd[1]: Activating swap Swap Partition...
Oct 18 01:26:26 Computer1 kernel: Adding k swap on /dev/sda4. 
Priority:-1 extents:1 across:k SSFS

Oct 18 01:26:26 Computer1 systemd[1]: Activated swap Swap Partition.
Oct 18 01:26:26 Computer1 systemd[1]: Activated swap 
/dev/disk/by-uuid/.

Oct 18 01:26:26 Computer1 systemd[1]: Reached target Swap.
Oct 18 01:27:14 Computer1 sudo[1049]:  user1 : TTY=tty1 ; 
PWD=/home/user1 ; USER=root ; COMMAND=/sbin/swapoff -va
Oct 18 01:27:27 Computer1 sudo[1057]:  user1 : TTY=tty1 ; 
PWD=/home/user1 ; USER=root ; COMMAND=/sbin/swapon -va
Oct 18 01:27:33 Computer1 kernel: Adding k swap on /dev/sda4. 
Priority:-1 extents:1 across:k SSDsFS


--
Best wishes,
Bob

Bug#911205: Move shared library binaries from libhidapi-dev to libhidapi0 ?

[Scott Talbert]

On Wed, 17 Oct 2018, Witold Baryluk wrote:


Package: libhidapi-dev
Severity: normal

I just found that libhidapi-dev is per arch, and delivers shared libraries.

Isn't this normally done with a package without -dev suffix? With -dev one
only having header files, pkgconfig stuff, some documentation maybe,
and sometimes static library binaries?


libhidapi-dev doesn't contain any shared libraries.

talbert@debian-unstable:~$ dpkg --listfiles libhidapi-dev
/.
/usr
/usr/include
/usr/include/hidapi
/usr/include/hidapi/hidapi.h
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libhidapi-hidraw.a
/usr/lib/x86_64-linux-gnu/libhidapi-libusb.a
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/hidapi-hidraw.pc
/usr/lib/x86_64-linux-gnu/pkgconfig/hidapi-libusb.pc
/usr/share
/usr/share/doc
/usr/share/doc/libhidapi-dev
/usr/share/doc/libhidapi-dev/AUTHORS.txt
/usr/share/doc/libhidapi-dev/README.txt.gz
/usr/share/doc/libhidapi-dev/changelog.Debian.gz
/usr/share/doc/libhidapi-dev/copyright
/usr/lib/x86_64-linux-gnu/libhidapi-hidraw.so
/usr/lib/x86_64-linux-gnu/libhidapi-libusb.so

libhidapi-hidraw.so and libhidapi-libusb.so are just symbolic links.

If you want the shared libraries you need libhidapi-libusb0 or 
libhidapi-hidraw0 packages (there are two backends on Linux, so user

applications have to choose one).

talbert@debian-unstable:~$ dpkg --listfiles libhidapi-libusb0
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libhidapi-libusb.so.0.0.0
/usr/share
/usr/share/doc
/usr/share/doc/libhidapi-libusb0
/usr/share/doc/libhidapi-libusb0/changelog.Debian.gz
/usr/share/doc/libhidapi-libusb0/copyright
/usr/lib/x86_64-linux-gnu/libhidapi-libusb.so.0

Bug#911264: posh-0.13.1 'unset -f' broken

[or...@fredslev.dk]

Thank you for the quick fix, this seems to resolve the immediate
blocking issue. However it seems 'unset -f' still has problems.

I updated my example case slightly and found while 'unset -f' won't
block later commands if the function is not set, it will still do so
when the function is previously set.

I have attached the updated example which will fail with.

  9: echo: can't find function definition file

Note that there is also a nasty memory link if the function name
references the command inside the function.

  echo () echo foo; }

  echo

The attached example uses 'printf' instead to avoid this.


posh_unset2.sh
Description: application/shellscript

Bug#911274: vim-nox: custom command completion should append space if -nargs=1 or -nargs=+

[Daniel Shahaf]

Package: vim-nox
Version: 2:8.1.0320-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

The following:

% vim -Nu NONE
:command -nargs=1 Foo :
:Fo

results in:

:Foo

I suggest to have it result in:

:Foo 

with an extra space, since «:Foo» is invalid syntax (pressing 
at that point results in an E471 error).

Cheers,

Daniel

Bug#769494: [Pkg-sysvinit-devel] Bug#769494: Bug#769494: Please mount cgroup automatically

[Axel Beckert]

Thorsten Glaser wrote:
> > I notice that on my laptop I have some binfmt_misc filesystem mounted.
> > I'm pretty sure I don't use anything that uses binfmt_misc.  I also
> > have something called pstore.  IDK what that is.  It's emty so I guess
> > I'm not using it.
> 
> I’m a bit concerned about all these.
> 
> They increase the attack surface, they need resources
> (especially on older or embedded-ish architectures),
> and they clutter the visual output of, if not df(1),
> then at least mount(8), to a point where one requires
> manual postprocessing to make it legible.
> 
> Yes, it seems harmless, but… idk, a system isn’t
> perfect when there’s nothing left to add but nothing
> needs to be removed any more.
> 
> Stuff like that could perhaps be mounted from fstab,
> populated by d-i. I remember /tmp, /dev/pts et al.
> having been in fstab once too, nowadays they’re
> automatically mounted, though I’m not concerned
> about these.

Seconded.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#911271: [Pkg-privacy-maintainers] Bug#911271: foolscap: (Build) Depends on non existing python-txtorcon

[Antoine Beaupré]

On 2018-10-18 00:16:15, Sebastian Andrzej Siewior wrote:
> Package: foolscap
> Version: 0.13.1-1
> Severity: serious
>
> txtorcon does not build the Python2 variant (python-txtorcon) since its
> last upload, only the python3 one (python3-txtorcon) remains.
>
> As of now the package can't be built due to missing packages.

Seems to me foolscap should be ported to python rather than to force
txtorcon to support a (soon to be) obsolete version of python. :)

A.

-- 
Si Dieu est, l'homme est esclave ; 
or l'homme peut, doit être libre, donc Dieu n'existe pas.
Et si Dieu existait, il faudrait s'en débarrasser!
- Michel Bakounine

Bug#911273: d-i does not display NVMe model strings

[dann frazier]

Package: parted
Version: 3.2-22
Severity: normal
Tags: patch, d-i

parted currently exposes the same generic model name for all NVMe devices:

  # parted /dev/nvme0n1 -s print | grep Model
  Model: NVMe Device (nvme)

That can make it difficult to distinguish devices in your system,
especially at install-time.

This is fixed upstream in the following commit, which applies to Debian's
package with only minor offset adjustments:

  279bd554 Read NVMe model names from sysfs

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

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

Versions of packages parted depends on:
ii  libc6 2.27-6
ii  libparted23.2-22
ii  libreadline7  7.0-5
ii  libtinfo6 6.1+20180714-1

parted recommends no packages.

Versions of packages parted suggests:
pn  parted-doc  

-- no debconf information
>From 279bd5540a59e3bdc4e3702ff062f87fd842c0e9 Mon Sep 17 00:00:00 2001
From: dann frazier 
Date: Fri, 7 Sep 2018 13:31:15 -0600
Subject: [PATCH] Read NVMe model names from sysfs

parted currently shows the same generic model name for all NVMe devices:

  # parted /dev/nvme0n1 -s print | grep Model
  Model: NVMe Device (nvme)

If the model information is available in sysfs, display that instead:

  # parted /dev/nvme0n1 -s print | grep Model
  Model: THNSN5512GPU7 NVMe TOSHIBA 512GB (nvme)

Signed-off-by: Brian C. Lane 
---
 libparted/arch/linux.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/libparted/arch/linux.c b/libparted/arch/linux.c
index 02d7a52c..7d83dfbb 100644
--- a/libparted/arch/linux.c
+++ b/libparted/arch/linux.c
@@ -1405,6 +1405,22 @@ init_sdmmc (PedDevice* dev)
 return init_generic(dev, id);
 }
 
+static int
+init_nvme (PedDevice* dev)
+{
+int ret;
+char *model = read_device_sysfs_file (dev, "model");
+
+if (!model)
+ret = init_generic (dev, _("NVMe Device"));
+else {
+ret = init_generic (dev, model);
+free (model);
+}
+
+return ret;
+}
+
 static PedDevice*
 linux_new (const char* path)
 {
@@ -1489,7 +1505,7 @@ linux_new (const char* path)
 break;
 
 case PED_DEVICE_NVME:
-if (!init_generic (dev, _("NVMe Device")))
+if (!init_nvme (dev))
 goto error_free_arch_specific;
 break;
 
-- 
2.19.1

Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

[Sebastian Andrzej Siewior]

On 2018-10-17 21:21:29 [+0200], Kurt Roeckx wrote:
> > - src:foolscap #898800: foolscap: FTBFS against openssl 1.1.1
> 
> I'm not sure if this is actually still a problem, there have been
> fixes on the python and openssl side for this. reproducible builds
> shows it as having problems trying to install the build
> dependencies for months.

added #911271 to the pile. Not sure if foolscape is usable in testing
due to #905253 (it depends on python-txtorcon).

> > - src:python-boto #909545: SSL CERTIFICATE_VERIFY_FAILED when using gs 
> > (Google Cloud Storage) backend
> 
> Patch is available.

does it make sense to NMU it?

> Kurt

Sebastian

Bug#769494: [Pkg-sysvinit-devel] Bug#769494: Please mount cgroup automatically

[Ian Jackson]

Thorsten Glaser writes ("Bug#769494: [Pkg-sysvinit-devel] Bug#769494: Please 
mount cgroup automatically"):
> On Wed, 17 Oct 2018, Ian Jackson wrote:
> > I notice that on my laptop I have some binfmt_misc filesystem mounted.
> > I'm pretty sure I don't use anything that uses binfmt_misc.  I also
> > have something called pstore.  IDK what that is.  It's emty so I guess
> > I'm not using it.
> 
> I’m a bit concerned about all these.
> 
> They increase the attack surface, they need resources
> (especially on older or embedded-ish architectures),
> and they clutter the visual output of, if not df(1),
> then at least mount(8), to a point where one requires
> manual postprocessing to make it legible.

Well, these are reasonable points.  Certainly I don't care enough to
strongly advocate getting rid of the cgroupfs-mount package and you
seem to care enough to advocate keeping it.

If you think we should adopt a similar approach for other kernel
filesystems then I guess you might want to go to d-policy about that.

Regards,
Ian.

Bug#911104: mosquitto: New upstream release available

[Roger Light]

Hi Andreas,

Thanks for taking the time to look at it - there are a number of
changes in the 1.5 series of mosquitto which remove the need for the
majority of the patches. I've got an updated package but because there
were a few changes I wanted to give it a bit more of a test and simply
hadn't got round to it yet. I can see you've made some useful
additions though, I'd be pleased to take some of those changes for
sure. I'll try and get this sorted out in the next few days.

Regards,

Roger
On Mon, 15 Oct 2018 at 19:33, Andreas Henriksson  wrote:
>
> Package: mosquitto
> Version: 1.4.15-2
> Severity: wishlist
>
> Dear Maintainer,
>
> As you're most likely well aware of there's a new upstream release
> available. It would be nice to have it in Debian.
>
> For your convenience I've already prepared an updated package
> that is available at https://people.debian.org/~ah/mosquitto/
> (which has still to be properly tested and inspected).
>
> In case you don't have time for updating the package I would happily
> help out with an non-maintainer upload (NMU). Your review would ofcourse
> be much appreciated though, if you have time to look over the changes.
> Please get back to me as soon as possible on how you'd like to see it
> handled.
>
> Regards,
> Andreas Henriksson
>
> PS. the Vcs-Git repository is out of date or I'd have based the changes
> on that and provided a git tree.

Bug#911272: RM: python-txtorcon -- NBS; decruft

[Sebastian Andrzej Siewior]

Package: ftp.debian.org
Severity: normal

Hi,

The source package txtorcon no longer builds the binary package
python-txtorcon. The binary package is still in archive and was not
auto-decrufted. Removing the package breakds two other packages:

|bigeasy@coccia:~$ dak rm -Rnb python-txtorcon
|Will remove the following packages from unstable:
|
|python-txtorcon |   18.0.2-1 | all
|
|Maintainer: Debian Privacy Tools Maintainers 

|
|--- Reason ---
|
|--
|
|Checking reverse dependencies...
|# Broken Depends:
|ooniprobe/contrib: ooniprobe
|
|# Broken Build-Depends:
|foolscap: python-txtorcon
|ooniprobe/contrib: python-txtorcon (>= 0.14.2)
|
|Dependency problem found.

Both packages have a RC bug open:
- #909866 ooniprobe: (Build-) Depends on vanished package python-txtorcon
- #911271 foolscap: (Build) Depends on non existing python-txtorcon

python-txtorcon itself can't be installed in unstable anymore (#905253)
so I doubt it makes sense to wait until the two packages get fixed.
It seems that BTS things that #905253 is still open because the package
is in archive and piuparts tests with the old binary and fails. I think
this is the reason why the package can't migrate to testing. I don't
understand however why the package does not pop up in the cruft report.

Sebastian

Bug#777625: xwayland: Unpredictable segmentation fault

[Lionel Landwerlin]

A few fixes have landed that look like the abort you're hitting :

https://gitlab.freedesktop.org/xorg/xserver/commit/8dd7173eeba08f1ecfb414915625c609ad4b3297
https://gitlab.freedesktop.org/xorg/xserver/commit/cffac815b957fd1296d61cc5c20ba3709a77ee4e
https://gitlab.freedesktop.org/xorg/xserver/commit/1b0db2c74258d20e3f99bd69c2914fd445abe920

All available in 1.20.2.

Bug#881891: xwayland: FatalError() when new monitor is added (not always reproced)

[Lionel Landwerlin]

This commit might fix this :

https://gitlab.freedesktop.org/xorg/xserver/commit/8dd7173eeba08f1ecfb414915625c609ad4b3297

Available in 1.20.2.

Bug#911271: foolscap: (Build) Depends on non existing python-txtorcon

[Sebastian Andrzej Siewior]

Package: foolscap
Version: 0.13.1-1
Severity: serious

txtorcon does not build the Python2 variant (python-txtorcon) since its
last upload, only the python3 one (python3-txtorcon) remains.

As of now the package can't be built due to missing packages.

Sebastian

Bug#769494: [Pkg-sysvinit-devel] Bug#769494: Please mount cgroup automatically

[Thorsten Glaser]

On Wed, 17 Oct 2018, Ian Jackson wrote:

> I notice that on my laptop I have some binfmt_misc filesystem mounted.
> I'm pretty sure I don't use anything that uses binfmt_misc.  I also
> have something called pstore.  IDK what that is.  It's emty so I guess
> I'm not using it.

I’m a bit concerned about all these.

They increase the attack surface, they need resources
(especially on older or embedded-ish architectures),
and they clutter the visual output of, if not df(1),
then at least mount(8), to a point where one requires
manual postprocessing to make it legible.

Yes, it seems harmless, but… idk, a system isn’t
perfect when there’s nothing left to add but nothing
needs to be removed any more.

Stuff like that could perhaps be mounted from fstab,
populated by d-i. I remember /tmp, /dev/pts et al.
having been in fstab once too, nowadays they’re
automatically mounted, though I’m not concerned
about these.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#769494: [Pkg-sysvinit-devel] Bug#769494: Please mount cgroup automatically

[Ian Jackson]

Thorsten Glaser writes ("Bug#769494: [Pkg-sysvinit-devel] Bug#769494: Please 
mount cgroup automatically"):
> On Wed, 17 Oct 2018, Daniel Abrecht wrote:
> > I don't think mounting cgroup is sysvinits job. Mounting cgroups can be 
> > done using /etc/fstab and/or using the cgroupfs-mount package. I don't 
> > mind it being always added though.
> 
> Why? I mean, what for? I run dozens of systems without it.

Always mounting it would simplify things somewhat, overall.  There
would be a very small additional complexity on systems that didn't
need it, but a quite large benefit in not having to maintain a
separate mount-it package and so on.  In general this is how we handle
these kernel filesystems, usually (but not invariably - see the
special xen fs).

This is all assuming that there aren't any significant downsides to
mounting it.

I notice that on my laptop I have some binfmt_misc filesystem mounted.
I'm pretty sure I don't use anything that uses binfmt_misc.  I also
have something called pstore.  IDK what that is.  It's emty so I guess
I'm not using it.

This all seems harmless enough.  Am I wrong about cgroup ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

[Russ Allbery]

Ansgar Burchardt  writes:

> So shipping a daemon without init scripts is better than shipping one
> with only a systemd unit? 

I don't believe such a daemon package (with no init script) should be
included in Debian at *all*, as a matter of not meeting the quality bar.

> Shipping a sysvinit script is only a "should" in Policy, unless you ship
> something for any other init system.

I think that's just that it's very difficult to write a Policy rule
explaining when something should have an init script and when something
should not.

> We already have several packages only shipping systemd units, including
> with socket activation (I did not check if any services cannot be
> configured to not listen on their own, but I wouldn't be surprised).
> Those with socket activation include: chasquid, cockpit-ws, erlang-base,
> hddemux, ibacm, rkt, snapd, sssd-kcm, tang, tinysshd.

I'm not surprised, but (and I have not investigated in detail) I suspect
at least some of these are bugs.  I think they should be RC bugs in cases
where there's no significant porting required, just no init script, but
I'm not on the release team and don't get to make that call.  I do think
they violate a Policy must.

> (Also, see DBus-activated services, inetd-style socket activation,
> .timer units with their associated .service; there is no need for a
> sysvinit script in these cases, but Policy requires it.)

I think you're reading Policy far too literally here; the intent is only
to cover unit files that are equivalent to init scripts, and none of those
things are.  I certainly support fixing that to make it clearer.

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

Bug#890594: Job started

[Xavier]

Hello,

I started to implement this. See
https://salsa.debian.org/debian/devscripts/merge_requests/70

Command already ready:
 - search_team
 - search_user
 - create_repo

Each command is a simple perl file in Devscripts::Salsa namespace.
(inspired from pkg-perl-tools, thanks to Perl-Team !)

---
https://bugs.debian.org/890594 : devscripts: Implement a salsa-configure
script to configure salsa.debian.org project repositories

Bug#904558: What should happen when maintscripts fail to restart a service

[Simon McVittie]

On Tue, 09 Oct 2018 at 20:35:33 +0200, Wouter Verhelst wrote:
> According to "man invoke-rc.d", policy-rc.d can exit with exit state 106
> and provide a number of actions on stdout. These are then actions that
> invoke-rc.d must try in order "until one of them succeeds". As such, a
> policy-rc.d implementation written like so:
> 
> #!/bin/sh
> 
> if [ "$1" = ssh ] # logic error fixed as per subsequent mail
> then
>   exit 0
> fi
> echo "$2 stop"
> exit 106
> 
> would result in the system attempting whatever init script action was
> being asked for, followed by a "stop" action (except in the case of the
> "ssh" service, which must not fail before we close a shell, ever). This
> assumes that a "stop" action when the daemon fails to start will be
> successful

If I'm reading invoke-rc.d correctly, this is implemented (in a cross-init
way), but probably doesn't interact well with the logic that avoids
(re)starting services that are disabled, because that doesn't consider
"restart stop" to match "restart".

Obviously, if I'm right about that limitation, then that's a bug, and
bugs can be fixed. However, it makes me concerned that the exit status
106 thing is not well-understood or well-tested, even by invoke-rc.d
maintainers.

Packages that have systemd units with no corresponding LSB init
script (not necessarily services - timer, socket, path and (auto)mount
units are also units) use deb-systemd-invoke instead of
invoke-rc.d. deb-systemd-invoke doesn't implement the full generality
of the policy-rc.d interface, but only 0, 101 and 104 (in particular
not 106). That would be a reasonable feature request, particularly if
we want to encourage this route, but it isn't currently implemented.

While discussing this on IRC we wondered whether maintainer scripts
that restart services should be normally be using an interface that is
analogous to "systemctl try-restart", namely: check whether the service
is running, then restart it if it was. (This can't work for maintainer
scripts that stop the service in prerm and start it in postinst, but
that is no longer the default behaviour in recent debhelper compat
levels.) However, both dh_installinit and dh_installsystemd currently
use plain "restart", so if the service is not running (possibly because
it's already broken), it will usually be started.

> With that background, IMHO the proper reply to this question before the
> committee is that yes, postinst scripts should fail when an init script
> fails, but we should also better document the policy-rc.d interface to
> point out that the above is possible and can be done where it makes
> sense.

This would solve Marga's use case with a very large fleet of machines
maintained by a small number of sysadmins: they can install a policy-rc.d
on all those machines that does the right thing.

However, it leaves the default as "fail hard", which I'm not convinced
is the most appropriate thing for systems that lack an experienced
sysadmin (which are the systems where defaults matter most, because an
inexperienced user is the least able to make an informed decision about
where they should deviate from defaults).

policy-rc.d also has some practical integration issues. It normally relies
on putting an unpackaged file in /usr/sbin (unless you have installed
policyrcd-script-zg2), and it's common for tools like debootstrap and
debian-installer to create and delete policy-rc.d to suppress service
startup while carrying out bootstrap operations. One Debian derivative
that I'm involved in (SteamOS) is *meant* to have a policy-rc.d, but we
recently discovered that it has always been deleted at the end of the
debian-installer run, and so doesn't exist in practice.

smcv

Bug#769494: [Pkg-sysvinit-devel] Bug#769494: Please mount cgroup automatically

[Thorsten Glaser]

On Wed, 17 Oct 2018, Daniel Abrecht wrote:

> I don't think mounting cgroup is sysvinits job. Mounting cgroups can be 
> done using /etc/fstab and/or using the cgroupfs-mount package. I don't 
> mind it being always added though.

Why? I mean, what for? I run dozens of systems without it.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#911020: installation-guide: Comments on section D.3

[Holger Wansing]

Hi,

Brian Potkin  wrote:
> This is for D.3.4.4. Configure Networking.
> 
> 8<==8<===
> 
> ###
> # /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
> # See the interfaces(5) manpage for information on what options are
> # available and look at the files in /usr/share/doc/ifupdown/examples/.
> ###
> 
> # The loopback interface isn't really required any longer,
> # but can be used if needed.
> #
> # auto lo
> # iface lo inet loopback
> 
> # To use dhcp:
> #
> # auto eth0
> # iface eth0 inet dhcp
> 
> # An example static IP setup: (network, broadcast and gateway are optional)
> #
> # auto eth0
> # iface eth0 inet static
> # address 192.168.0.42
> # netmask 255.255.255.0
> # gateway 192.168.0.1
> 
> Enter your nameserver(s) and search directives in /etc/resolv.conf:
> 
> # editor /etc/resolv.conf
> 
> A simple example /etc/resolv.conf:
> 
> search example.com
> nameserver 10.1.1.36
> nameserver 192.168.9.100
> 
> ==8<==8<
> 
> I hope this is reasonably helpful and sufficient for you to make a
> decision.

Thanks Brian!

I created a clean patch for this (attached) and will commit it shortly.


Holger




-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/en/appendix/chroot-install.xml b/en/appendix/chroot-install.xml
index fa3beba5d..6dd075af2 100644
--- a/en/appendix/chroot-install.xml
+++ b/en/appendix/chroot-install.xml
@@ -407,17 +407,18 @@ Here are some simple examples from
 # available.
 ##
 
-# We always want the loopback interface.
+# The loopback interface isn't really required any longer, but can be used
+# if needed.
 #
-auto lo
-iface lo inet loopback
+# auto lo
+# iface lo inet loopback
 
 # To use dhcp:
 #
 # auto eth0
 # iface eth0 inet dhcp
 
-# An example static IP setup: (broadcast and gateway are optional)
+# An example static IP setup: (network, broadcast and gateway are optional)
 #
 # auto eth0
 # iface eth0 inet static
@@ -438,7 +439,7 @@ Enter your nameserver(s) and search directives in
 A simple example /etc/resolv.conf:
 
 
-search hqdom.local
+search example.com
 nameserver 10.1.1.36
 nameserver 192.168.9.100
 

Bug#769494: Please mount cgroup automatically

[Ian Jackson]

Daniel Abrecht writes ("Bug#769494: Please mount cgroup automatically"):
> I don't think mounting cgroup is sysvinits job. Mounting cgroups can be 
> done using /etc/fstab and/or using the cgroupfs-mount package. I don't 
> mind it being always added though.

Thanks for your message.

I confess I am very ignorant but I don't understand why it would be a
bad idea for this to be mounted on all systems.

If the existence of cgroupfs-mount is just there to do this, because
sysvinit doesn't, it seems like a lot of trouble.  Maybe it would be
better to have sysvinit do it, always, and then we could get rid of
cgroupfs-mount and packages that wanted this facility wouldn't need to
write anything in their control file.

OTOH the current situation sounds tolerable.

I have CC'd `cgroupfs-mo...@packages.debian.org' which is the
maintainers of that package, so that they can have an opinion.  (I'm
afraid this mail will come across as a bit ignorant because I'm not
really in a position to do any proper research like reading the rest
of this bug or the cgroupfs-mount package description.)

> This is my first mail to the debian bug tracker, I hope I was able to 
> help and to give some new helpful perspectives on this matter.

Thank you for your contribution to Debian.  I thought your message was
very helpful, even if I don't know that I 100% agree with your
conclusion :-).

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#911270: infnoise: Fails to upgrade (systemd, no device plugged in)

[Axel Beckert]

Package: infnoise
Version: 0.3.0+dfsg-1
Severity: serious

Hi Stephen,

I also have infnoise installed on my laptop with systemd as init system
where I first tried the TRNG stick. There upgrading from 0.2.6+dfsg-1
failed as follows:

Preparing to unpack .../151-infnoise_0.3.0+dfsg-1_amd64.deb ...
Unpacking infnoise (0.3.0+dfsg-1) over (0.2.6+dfsg-1) ...
[…]
Setting up infnoise (0.3.0+dfsg-1) ...
A dependency job for infnoise.service failed. See 'journalctl -xe' for details.
invoke-rc.d: initscript infnoise, action "restart" failed.
● infnoise.service - Wayward Geek InfNoise TRNG driver
   Loaded: loaded (/lib/systemd/system/infnoise.service; enabled; vendor 
preset: enabled)
   Active: inactive (dead)
 Docs: man:infnoise.service(8)

Oct 08 19:27:51 c-cactus2 systemd[1]: Dependency failed for Wayward Geek 
InfNoise TRNG driver.
Oct 08 19:27:51 c-cactus2 systemd[1]: infnoise.service: Job 
infnoise.service/start failed with result 'dependency'.
Oct 17 22:03:08 c-cactus2 systemd[1]: infnoise.service: Bound to unit 
dev-infnoise.device, but unit isn't active.
Oct 17 22:03:08 c-cactus2 systemd[1]: Dependency failed for Wayward Geek 
InfNoise TRNG driver.
Oct 17 22:03:08 c-cactus2 systemd[1]: infnoise.service: Job 
infnoise.service/start failed with result 'dependency'.
Oct 17 22:06:01 c-cactus2 systemd[1]: infnoise.service: Bound to unit 
dev-infnoise.device, but unit isn't active.
Oct 17 22:06:01 c-cactus2 systemd[1]: Dependency failed for Wayward Geek 
InfNoise TRNG driver.
Oct 17 22:06:01 c-cactus2 systemd[1]: infnoise.service: Job 
infnoise.service/start failed with result 'dependency'.
dpkg: error processing package infnoise (--configure):
 installed infnoise package post-installation script subprocess returned error 
exit status 1

'journalctl -xe' says:
Oct 17 22:10:04 c-cactus2 systemd[1]: Unnecessary job for dev-infnoise.device 
was removed.
-- Subject: Unit dev-infnoise.device has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit dev-infnoise.device has failed.
--
-- The result is RESULT.
Oct 17 22:10:04 c-cactus2 systemd[1]: infnoise.service: Bound to unit 
dev-infnoise.device, but unit isn't active.
Oct 17 22:10:04 c-cactus2 systemd[1]: Dependency failed for Wayward Geek 
InfNoise TRNG driver.
-- Subject: Unit infnoise.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit infnoise.service has failed.
--
-- The result is RESULT.
Oct 17 22:10:04 c-cactus2 systemd[1]: infnoise.service: Job 
infnoise.service/start failed with result 'dependency'.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages infnoise depends on:
ii  libc6 2.27-6
ii  libftdi1  0.20-4

infnoise recommends no packages.

infnoise suggests no packages.

-- no debconf information

Bug#911220: stretch-pu: package jhead/1:3.00-4

[Ludovic Rousseau]

Le 17/10/2018 à 11:15, Salvatore Bonaccorso a écrit :

Hi

[Disclaimer: not a SRM but looking at the proposed update]

On Wed, Oct 17, 2018 at 10:28:15AM +0200, Ludovic Rousseau wrote:

+jhead (1:3.00-4.1) stable; urgency=high


Please use 1:3.00-4+deb9u1 as version. Using the codename instead of
'stable' would be prefered, but both work.

Thanks a lot for preparing the update!


New patch version with the package version fixed.

Bye

--
 Dr. Ludovic Rousseau
diff -Nru jhead-3.00/debian/changelog jhead-3.00/debian/changelog
--- jhead-3.00/debian/changelog 2017-03-20 20:26:16.0 +0100
+++ jhead-3.00/debian/changelog 2018-10-16 10:38:19.0 +0200
@@ -1,3 +1,11 @@
+jhead (1:3.00-4+deb9u1) stretch; urgency=high
+
+  * d/p/32_crash_in_gpsinfo: Fix CVE-2018-17088
+  * d/p/33_fix_908176: Fix CVE-2018-16554
+  * d/p/34_buffer_overflow: Fix heap buffer overflow
+
+ -- Ludovic Rousseau   Tue, 16 Oct 2018 10:38:19 +0200
+
 jhead (1:3.00-4) unstable; urgency=medium
 
   * Fix "CVE-2016-3822" Apply patch from Google (Closes: #858213)
diff -Nru jhead-3.00/debian/patches/32_crash_in_gpsinfo 
jhead-3.00/debian/patches/32_crash_in_gpsinfo
--- jhead-3.00/debian/patches/32_crash_in_gpsinfo   1970-01-01 
01:00:00.0 +0100
+++ jhead-3.00/debian/patches/32_crash_in_gpsinfo   2018-10-16 
10:33:06.0 +0200
@@ -0,0 +1,26 @@
+From: Ludovic Rousseau 
+Date: Wed Sep  5 15:32:00 CEST 2018
+Subject: Fix heap buffer overflow
+
+Bug-Debian: http://bugs.debian.org/907925
+Description: Fix CVE-2018-17088
+
+--- a/gpsinfo.c
 b/gpsinfo.c
+@@ -4,6 +4,7 @@
+ // Matthias Wandel,  Dec 1999 - Dec 2002 
+ //--
+ #include "jhead.h"
++#include 
+ 
+ #define MAX_GPS_TAG 0x1e
+ 
+@@ -101,7 +102,7 @@
+ unsigned OffsetVal;
+ OffsetVal = Get32u(DirEntry+8);
+ // If its bigger than 4 bytes, the dir entry contains an offset.
+-if (OffsetVal+ByteCount > ExifLength){
++if (OffsetVal > UINT32_MAX - ByteCount || OffsetVal+ByteCount > 
ExifLength){
+ // Bogus pointer offset and / or bytecount value
+ ErrNonfatal("Illegal value pointer for Exif gps tag %04x", 
Tag,0);
+ continue;
diff -Nru jhead-3.00/debian/patches/33_fix_908176 
jhead-3.00/debian/patches/33_fix_908176
--- jhead-3.00/debian/patches/33_fix_908176 1970-01-01 01:00:00.0 
+0100
+++ jhead-3.00/debian/patches/33_fix_908176 2018-10-16 10:35:19.0 
+0200
@@ -0,0 +1,19 @@
+From: Ludovic Rousseau 
+Date: Sat Sep  8 16:19:07 CEST 2018
+Subject: fix heap buffer overflow
+
+Bug-Debian: https://bugs.debian.org/908176
+Description: Fix CVE-2018-16554
+
+--- a/gpsinfo.c
 b/gpsinfo.c
+@@ -162,7 +162,8 @@
+ break;
+ 
+ case TAG_GPS_ALT:
+-sprintf(ImageInfo.GpsAlt + 1, "%.2fm", 
++snprintf(ImageInfo.GpsAlt + 1, sizeof(ImageInfo.GpsAlt) -1,
++"%.2fm",
+ ConvertAnyFormat(ValuePtr, Format));
+ break;
+ }
diff -Nru jhead-3.00/debian/patches/34_buffer_overflow 
jhead-3.00/debian/patches/34_buffer_overflow
--- jhead-3.00/debian/patches/34_buffer_overflow1970-01-01 
01:00:00.0 +0100
+++ jhead-3.00/debian/patches/34_buffer_overflow2018-10-16 
10:36:45.0 +0200
@@ -0,0 +1,15 @@
+From: Ludovic Rousseau 
+Date: Sat Sep  8 16:02:23 CEST 2018
+Subject: Fix heap buffer overflow
+
+--- a/jhead.c
 b/jhead.c
+@@ -670,7 +670,7 @@
+ NameExtra[0] = 0;
+ }
+ 
+-sprintf(NewName, "%s%s.jpg", NewBaseName, NameExtra);
++snprintf(NewName, sizeof(NewName), "%s%s.jpg", NewBaseName, 
NameExtra);
+ 
+ if (!strcmp(FileName, NewName)) break; // Skip if its already this 
name.
+ 
diff -Nru jhead-3.00/debian/patches/series jhead-3.00/debian/patches/series
--- jhead-3.00/debian/patches/series2017-03-20 20:26:16.0 +0100
+++ jhead-3.00/debian/patches/series2018-10-16 10:37:07.0 +0200
@@ -5,3 +5,6 @@
 25_makefile
 27_documentation
 31_CVE-2016-3822
+32_crash_in_gpsinfo
+33_fix_908176
+34_buffer_overflow

Bug#911269: All Qt packages on Debian Sid have broken dependencies.

[scozatigheratten]

Package: libqt5core5a
Version: 5.11.2+dfsg-3
Severity: serious

Dear Qt maintainers,

All Qt packages that depend on the virtual package `qtbase-abi-5-11-0` will not 
install because the virtual package is no longer provided by
libqt5core5a since 5.11.1 was upgraded to 5.11.2.
Other virtual packages are broken as well.
This is a serious issue and renders any package that depends on Qt 
uninstallable on Sid, including KDE.

Thanks for the attention.

Bug#911268: iceweasel doesn't print web pages, only header and footer lines.

[enno]

Package: iceweasel
Version: 60.2.2esr-1~deb9u1
Severity: normal

Dear Maintainer,

Visited some website, tried to print to file (pdf), resulted in pages only
containing header and footer lines.

Whereas chrome had no problem at all to print those pages to a pdf file.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.17.0-1-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_AT@euro, LC_CTYPE=de_AT@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iceweasel depends on:
ii  firefox-esr  60.2.2esr-1~deb9u1

iceweasel recommends no packages.

iceweasel suggests no packages.

-- no debconf information

Bug#911267: Upstream on github.com disappeared

[Micha Lenk]

Source: sleepenh
Version: 1.6-1
Severity: minor
Tags: upstream

Dear sleepenh maintainer,

since I sponsored the last upload of the sleepenh package, the package appears
on my packages overview page on qa.debian.org. This table recently started to
indicate that there is an issue with the Git repository the packaging is
tracked in. And indeed, the entire project which used to live on
https://github.com/nsc-deb/sleepenh-debian seems to be gone.

As a backup I've just mirrored the last Git clone I still had on my workstation
to Debian's Git server on https://salsa.debian.org/debian/sleepenh. If you want
to use that repository, please create a guest account on
https://signup.salsa.debian.org/ and let me know with a GPG signed message
which account name should be granted access to that repository.

Best regards,
Micha

Bug#911266: mosquitto: CVE-2017-7653

[Salvatore Bonaccorso]

Source: mosquitto
Version: 1.4.10-1
Severity: grave
Tags: patch security upstream
Forwarded: https://bugs.eclipse.org/bugs/show_bug.cgi?id=532113

Hi,

The following vulnerability was published for mosquitto. Planned to be
fixed in a DSA, and needs to be fixed for buster as reason for the RC
severity filling.

CVE-2017-7653[0]:
| The Eclipse Mosquitto broker up to version 1.4.15 does not reject
| strings that are not valid UTF-8. A malicious client could cause other
| clients that do reject invalid UTF-8 strings to disconnect themselves
| from the broker by sending a topic string which is not valid UTF-8,
| and so cause a denial of service for the clients.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-7653
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7653
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=532113
[2] 
https://github.com/eclipse/mosquitto/commit/729a09310a7a56fbe5933b70b4588049da1a42b4

Regards,
Salvatore

Bug#911265: mosquitto: CVE-2017-7654

[Salvatore Bonaccorso]

Source: mosquitto
Version: 1.4.10-1
Severity: grave
Tags: patch security upstream
Forwarded: https://bugs.eclipse.org/bugs/show_bug.cgi?id=533493

Hi,

The following vulnerability was published for mosquitto.

Filling with RC severity as it will be fixed in a DSA, and needs to be
fixed before buster release in unstable/testing as well.

CVE-2017-7654[0]:
| In Eclipse Mosquitto 1.4.15 and earlier, a Memory Leak vulnerability
| was found within the Mosquitto Broker. Unauthenticated clients can
| send crafted CONNECT packets which could cause a denial of service in
| the Mosquitto Broker.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-7654
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7654
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=533493
[2] 
https://github.com/eclipse/mosquitto/commit/51ec5601c2ec523bf2973fdc1eca77335eafb8de

Regards,
Salvatore

Bug#911064: python-vcr: SyntaxError in /usr/lib/python2.7/dist-packages/vcr/cassette_yf.py

[Pierre-Elliott Bécue]

Le lundi 15 octobre 2018 à 12:06:15+0200, Jérémy Lal a écrit :
> Package: python-vcr
> Version: 2.0.1-1
> Severity: important
> 
> When upgrading to python-vcr 2.0.1, i get:
> 
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Paramétrage de python-vcr (2.0.1-1) ...
>   File "/usr/lib/python2.7/dist-packages/vcr/cassette_yf.py", line 7
> yield from coroutine
>  ^
> SyntaxError: invalid syntax

What makes me sad is that I took the time to test it via autopkgtest, but it
seems the dh compilation thingy happens only upon normal install.

This patch I made is broken. I'm working on a good one.

Sorry and 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.

Bug#910911: command-not-found is affected, too

[Axel Beckert]

Hi,

JFTR: command-not-found is affected by this issue, too:

$ acn foo
Unable to open binary database /var/cache/command-not-found//contrib.db: 
Malformed database file header
Sorry, command-not-found has crashed! Please file a bug report for 
the command-not-found package, see http://www.debian.org/Bugs/Reporting
for further information
Please include the following information with the report:

command-not-found version: 0.2.26
$ file /var/cache/command-not-found/*.db
/var/cache/command-not-found/contrib.db:  GNU dbm 1.x or ndbm database, little 
endian, old
/var/cache/command-not-found/main.db: GNU dbm 1.x or ndbm database, little 
endian, old
/var/cache/command-not-found/non-free.db: GNU dbm 1.x or ndbm database, little 
endian, old
$ for i in /var/cache/command-not-found/*.db ; do gdbm_dump $i; done
gdbm_dump: gdbm_open failed: Malformed database file header
gdbm_dump: gdbm_open failed: Malformed database file header
gdbm_dump: gdbm_open failed: Malformed database file header
$

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#769494: Please mount cgroup automatically

[Daniel Abrecht]

Hello,

I don't think mounting cgroup is sysvinits job. Mounting cgroups can be 
done using /etc/fstab and/or using the cgroupfs-mount package. I don't 
mind it being always added though.


Also, I think this issue has already been solved. liblxc1, which is a 
dependency of lxc, has a dependency for "cgroupfs-mount or systemd", 
which means on non-systemd systems, when installing lxc or anything else 
which uses liblxc1, cgroupfs-mount will get installed, which will 
automatically mount the cgroups.


I don't use lxc anymore, but I used to have it working in jessie without 
systemd back when I was still using it.


I am using libvirt-lxc (which has been merged into libvirt-daemon) 
without systemd or lxc, though. I haven't seen a similar dependency on 
libvirt-daemon yet. libvirt-daemon can be used for other things than lxc 
containers, in which case cgroups don't seam to be required. I recommend 
adding a recommends to the libvirt-daemon package for "cgroupfs-mount or 
systemd" to account for all use cases.


To summarize, I'm for closing this bug and just adding a "cgroupfs-mount 
or systemd" dependency or recommends to packages which need or benefit 
from it respectively, similar to how it is done with liblxc1. For this, 
a new bug could be opened for each affected packet.


This is my first mail to the debian bug tracker, I hope I was able to 
help and to give some new helpful perspectives on this matter.


Regards,
Daniel Abrecht

Bug#911247: geeqie: Moving symlink to image crashes geeqie

[Andreas Ronnquist]

On Wed, 17 Oct 2018 17:27:23 +0200 =?utf-8?q?Wojciech_Mu=C5=82a?=
 wrote:
> How to reproduce:
> 
> 1. Providing there's file.jpg, create symbolic link in the same
> directory 
> ln -s file.jpg link.jpg
> 
> 2. Open geeqie and navigate to link.jpg (geeqie displays image
> correctly). 3. Right click on the link.jpg, select "copy file" and
> copy the file to **another device**.
> 4. Geeqie crashes. When run from a console, it prints error messages,
>I noted two different: "corrupted double-linked list" and something
>about double free (sorry, lost the exact copy).
> 
> In my case links are located on an external disc, and I'm trying to
> copy them to my home directory, which is mounted on a local hard
> drive. When I copy links within the same device, everything works!
> 
> 

Thanks for your report! This has been fixed in the git repo upstream,
and I will include this soon in a fix in Debian too. (I will
most probably package a new git snapshot).

However, please notice that upstream has solved the problem by reverting
other fixes to make copying symlinks to images in geeqie also symlink
at the copy target, and instead dereferencing the symlink target. This
means that the result target when copying a symlink to an image will be
a copy of the image the symlink targets, and not a new symlink with the
same target as the source.

(Upstream bug report at:
https://github.com/BestImageViewer/geeqie/issues/640 )

best
/Andreas
gus...@debian.org
andr...@ronnquist.net

Bug#907015: [Pkg-openssl-devel] Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

[Kurt Roeckx]

On Wed, Oct 17, 2018 at 09:22:35PM +0300, Niko Tyni wrote:
> 
> As a status update, I count just six packages left in testing that are
> marked as blockers for this bug. (I could be wrong of course; double
> checking welcome.)

I think you missed one.

> - src:foolscap #898800: foolscap: FTBFS against openssl 1.1.1

I'm not sure if this is actually still a problem, there have been
fixes on the python and openssl side for this. reproducible builds
shows it as having problems trying to install the build
dependencies for months.

> - src:kdeconnect #907339: qtbase-opensource-src breaks kdeconnect autopkgtest 
> possibly due to new openssl
> - src:kimap #907427: (kimap) openssl 1.1.1 breaks ssl tests

There is also purpose, they all seem to be related to
qtbase-opensource-src.

> - src:ruby-eventmachine #900160: ruby-eventmachine: FTBFS against openssl 
> 1.1.1

I'm not sure why the patch didn't fix it

> - src:python-boto #909545: SSL CERTIFICATE_VERIFY_FAILED when using gs 
> (Google Cloud Storage) backend

Patch is available.

> - src:m2crypto #897658: m2crypto: FTBFS against openssl 1.1.1

Only test suite problems that don't show any real issues.

> Is it still useful to block openssl 1.1.1 testing migration with this bug?

Things like python are also blocked on it. I have no problem
lowering the severity of this issue, to make it migrate.


Kurt

Bug#907139: vlc: VLC starts without GUI (Videos opens with sound only) after upgrade to VLC version 3

[Sebastian Ramacher]

Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-56140

On 2018-10-17 20:44:57, Sebastian Ramacher wrote:
> Control: reassign -1 libqt5widgets5 5.7.1+dfsg-3
> 
> Hi Reinhold,
> 
> sorry for the delay in getting back to you.
> 
> On 2018-08-24 11:10:43, Reinhold Schink wrote:
> > Package: src:vlc
> > Version: 3.0.3-1-0+deb9u1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > 
> > The Upgrade procedure replace the formerly installed vlc version (2.7), but 
> > the
> > new version is starting without gui. If a video file is launched, it starts
> > only with sound.
> > I tried to uninstall the not working vlc installtion with all related 
> > modules
> > and requirement and cleaning the related configurations. A new installation 
> > of
> > vlc has the same result.
> > 
> > There are a lot of messages in the log.
> > 
> > QPainter::end: Painter not active, aborted
> > [55ac5e716850] main interface debug: using interface module "qt"
> > [55ac5e6c61d0] main playlist: playlist is empty
> > [55ac5e6c61d0] main playlist debug: nothing to play
> > QWidget::setMinimumSize: (/FirstRun) Negative sizes (-492131588,-492131668) 
> > are
> > not possible
> 
> This line is already suspicious. But if you don't see a GUI at all, this call
> isn't triggered by vlc. Maybe it's coming somewhere from within Qt or some
> theme. I don't know.
> 
> Qt maintainers, is there any way to hunt the broken call location down?
> 
> Cheers
> 
> > QXcbConnection: XCB error: 2 (BadValue), sequence: 423, resource id: 0, 
> > major
> > code: 1 (CreateWindow), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 424, resource id: 
> > 48234501,
> > major code: 2 (ChangeWindowAttributes), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 425, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 426, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 427, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 429, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 430, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 431, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 434, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 438, resource id: 
> > 48234501,
> > major code: 2 (ChangeWindowAttributes), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 439, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 442, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 443, resource id: 
> > 48234501,
> > major code: 20 (GetProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 447, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 448, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 451, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 452, resource id: 
> > 48234501,
> > major code: 18 (ChangeProperty), minor code: 0
> > QXcbConnection: XCB error: 2 (BadValue), sequence: 454, resource id: 0, 
> > major
> > code: 1 (CreateWindow), minor code: 0
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 455, resource id: 
> > 48234505,
> > major code: 2 (ChangeWindowAttributes), minor code: 0

This seems to be https://bugreports.qt.io/browse/QTBUG-56140. Any changes the
fixes can be backported?

Cheers

> > 
> > 
> > Kind,
> > Regards Reinhold
> > 
> > 
> > 
> > -- System Information:
> > Debian Release: 9.5
> >   APT prefers stable-updates
> >   APT policy: (500, 'stable-updates'), (500, 'stable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> > LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > 
> > Versions of packages vlc depends on:
> > ii  dpkg 1.18.25
> > ii  vlc-bin  3.0.3-1-0+deb9u1
> > ii  vlc-l10n 3.0.3-1-0+deb9u1
> > ii  vlc-plugin-base  3.0.3-1-0+deb9u1
> > ii  

Bug#911263: tcpflow: CVE-2018-18409

[Salvatore Bonaccorso]

Source: tcpflow
Version: 1.5.0+repack1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/simsong/tcpflow/issues/195

Hi,

The following vulnerability was published for tcpflow.

CVE-2018-18409[0]:
| A stack-based buffer over-read exists in setbit() at iptree.h of
| TCPFLOW 1.5.0, due to received incorrect values causing incorrect
| computation, leading to denial of service during an address_histogram
| call or a get_histogram call.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-18409
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18409
[1] https://github.com/simsong/tcpflow/issues/195

Regards,
Salvatore

Bug#911262: fastboot: no fastboot version 8 in experimental

[Jan Volec]

Package: fastboot
Severity: important

Dear Maintainer,

It seems that fastboot packae not got updated in the experimental repository,
unlike the rest of android's framework (in particular, adb). Would it be
possible to add a package with fastboot 8.1.0 to the repository?


Best wishes,

Jan


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

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

Versions of packages fastboot depends on: 
ii  android-libadb 1:8.1.0+r23-1~stage1.2
ii  android-libbase1:8.1.0+r23-1~stage1.2
ii  android-libcutils  1:8.1.0+r23-1~stage1.2
ii  android-libext4-utils  8.1.0+r23-1
ii  android-libf2fs-utils  8.1.0+r23-1
ii  android-libsparse  1:8.1.0+r23-1~stage1.2
ii  android-libziparchive  1:8.1.0+r23-1~stage1.2
ii  libc6  2.27-6
ii  libgcc11:8.2.0-7
ii  libstdc++6 8.2.0-7

fastboot recommends no packages.

fastboot suggests no packages.

Bug#907139: vlc: VLC starts without GUI (Videos opens with sound only) after upgrade to VLC version 3

[Sebastian Ramacher]

Control: reassign -1 libqt5widgets5 5.7.1+dfsg-3

Hi Reinhold,

sorry for the delay in getting back to you.

On 2018-08-24 11:10:43, Reinhold Schink wrote:
> Package: src:vlc
> Version: 3.0.3-1-0+deb9u1
> Severity: important
> 
> Dear Maintainer,
> 
> 
> The Upgrade procedure replace the formerly installed vlc version (2.7), but 
> the
> new version is starting without gui. If a video file is launched, it starts
> only with sound.
> I tried to uninstall the not working vlc installtion with all related modules
> and requirement and cleaning the related configurations. A new installation of
> vlc has the same result.
> 
> There are a lot of messages in the log.
> 
> QPainter::end: Painter not active, aborted
> [55ac5e716850] main interface debug: using interface module "qt"
> [55ac5e6c61d0] main playlist: playlist is empty
> [55ac5e6c61d0] main playlist debug: nothing to play
> QWidget::setMinimumSize: (/FirstRun) Negative sizes (-492131588,-492131668) 
> are
> not possible

This line is already suspicious. But if you don't see a GUI at all, this call
isn't triggered by vlc. Maybe it's coming somewhere from within Qt or some
theme. I don't know.

Qt maintainers, is there any way to hunt the broken call location down?

Cheers

> QXcbConnection: XCB error: 2 (BadValue), sequence: 423, resource id: 0, major
> code: 1 (CreateWindow), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 424, resource id: 
> 48234501,
> major code: 2 (ChangeWindowAttributes), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 425, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 426, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 427, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 429, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 430, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 431, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 434, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 438, resource id: 
> 48234501,
> major code: 2 (ChangeWindowAttributes), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 439, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 442, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 443, resource id: 
> 48234501,
> major code: 20 (GetProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 447, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 448, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 451, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 452, resource id: 
> 48234501,
> major code: 18 (ChangeProperty), minor code: 0
> QXcbConnection: XCB error: 2 (BadValue), sequence: 454, resource id: 0, major
> code: 1 (CreateWindow), minor code: 0
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 455, resource id: 
> 48234505,
> major code: 2 (ChangeWindowAttributes), minor code: 0
> 
> 
> 
> Kind,
> Regards Reinhold
> 
> 
> 
> -- System Information:
> Debian Release: 9.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages vlc depends on:
> ii  dpkg 1.18.25
> ii  vlc-bin  3.0.3-1-0+deb9u1
> ii  vlc-l10n 3.0.3-1-0+deb9u1
> ii  vlc-plugin-base  3.0.3-1-0+deb9u1
> ii  vlc-plugin-qt3.0.3-1-0+deb9u1
> ii  vlc-plugin-video-output  3.0.3-1-0+deb9u1
> 
> Versions of packages vlc recommends:
> ii  vlc-plugin-notify  3.0.3-1-0+deb9u1
> ii  vlc-plugin-samba   3.0.3-1-0+deb9u1
> ii  vlc-plugin-skins2  3.0.3-1-0+deb9u1
> ii  vlc-plugin-video-splitter  3.0.3-1-0+deb9u1
> ii  vlc-plugin-visualization   3.0.3-1-0+deb9u1
> 
> vlc suggests no packages.
> 
> Versions of packages libvlc-bin depends on:
> ii  libc62.24-11+deb9u3
> ii  

Bug#911261: libcereal: autopkgtest regression

[Paul Gevers]

Source: libcereal
Version: 1.2.2-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of libcereal the autopkgtest of libcereal fails in
testing when that autopkgtest is run with the binary packages of
libcereal from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
libcereal  from testing1.2.2-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

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

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=libcereal

https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libcereal/1163185/log.gz

autopkgtest [16:20:21]: test run-tests: [---
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Boost version: 1.62.0
-- Found the following Boost libraries:
--   serialization
CMake Error at CMakeLists.txt:67 (add_subdirectory):
  add_subdirectory given source "doc" which is not an existing directory.


-- Configuring incomplete, errors occurred!
See also
"/tmp/autopkgtest-lxc.vmh2qgu5/downtmp/autopkgtest_tmp/CMakeFiles/CMakeOutput.log".
make: *** No targets specified and no makefile found.  Stop.
autopkgtest [16:20:24]: test run-tests: ---]



signature.asc
Description: OpenPGP digital signature

Bug#911184: wicd-daemon: Please make log file location configurable

[Axel Beckert]

Control: tag -1 - moreinfo + upstream

Hi Dmitry,

Dmitry Bogatov wrote:
> > Can you check if these options already help for your needs?
> 
> Not exactly. There are two kind of data, that is stored in
> /var/log/wicd/wicd.log:
> 
>  * stdout/stderr from subprocessed, that wicd executes
>  * messages from wicd proper like 'Autoconnecting...'
> 
> If I specify --no-{stdout,stderr}, first group of messages will indeed
> go to standard streams of wicd, but messages from wicd proper will go
> to /var/log/wicd/wicd.log nevertheless.

Ah, I see. Thanks for the explanation!

Will see what I can do.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#911260: libkf5xmlgui5: Uninstallable since upload of qtbase-opensource-src 5.11.2+dfsg

[Andreas Tille]

Package: libkf5xmlgui5
Severity: grave
Justification: renders package unusable

Hi,


$ sudo apt install libkf5xmlgui5
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libkf5xmlgui5 : Depends: qtbase-abi-5-11-0 but it is not installable
E: Unable to correct problems, you have held broken packages.


The reason is pretty obvious since the version of libqt5core5a
in unstable now provides a higher ABI version

$ apt-cache show libqt5core5a | grep -e Provides -e Version
Version: 5.11.2+dfsg-3
Provides: qtbase-abi-5-11-2
Version: 5.11.1+dfsg-9
Provides: qtbase-abi-5-11-0


Kind regards

   Andreas.

-- System Information:
Debian Release: buster/sid 
  APT prefers unstable 
  APT policy: (500, 'unstable') 
Architecture: amd64 (x86_64) 
 
Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores) 
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968) 
Shell: /bin/sh linked to /bin/dash 
Init: unable to detect 
 
Versions of packages libkf5xmlgui5 depends on: 
ii  libc6  2.27-6 
pn  libkf5attica5   
pn  libkf5configcore5   
pn  libkf5configgui5
pn  libkf5configwidgets5
pn  libkf5coreaddons5   
pn  libkf5globalaccel-bin   
pn  libkf5globalaccel5  
pn  libkf5i18n5 
pn  libkf5iconthemes5   
pn  libkf5itemviews5
pn  libkf5textwidgets5  
pn  libkf5widgetsaddons5
pn  libkf5windowsystem5 
pn  libkf5xmlgui-data   
pn  libqt5core5a
pn  libqt5dbus5 
pn  libqt5gui5  
pn  libqt5network5  
pn  libqt5printsupport5 
pn  libqt5widgets5  
pn  libqt5xml5  
ii  libstdc++6 8.2.0-7 
pn  qtbase-abi-5-11-0   
 
Versions of packages libkf5xmlgui5 recommends: 
pn  libkf5xmlgui-bin   
 
libkf5xmlgui5 suggests no packages.

Bug#911206: wip

[Fernando Toledo]

i have a WIP at https://github.com/ftoledo/pkg-multiblend

Bug#911148: kildclient: mouseover timestamp balloon disappears instantly

[Eduardo M KALINOWSKI]

Yeah, I can reproduce the bug (sort of -- here I never see the  
tooltip, only a mouse pointer flickering).


Might be this Gtk bug: https://gitlab.gnome.org/GNOME/gtk/issues/1371  
. I'll try the workaround later to see if it works.

--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

[Niko Tyni]

On Thu, Aug 23, 2018 at 09:07:31AM +0200, Paul Gevers wrote:
> Source: openssl
> Version: 1.1.1~~pre9-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: breaks
> Control: affects -1 src:ganeti src:libnet-ssleay-perl src:ruby-openssl
> Control: affects -1 src:m2crypto src:python2.7 src:python3.6
> Control: affects -1 src:python3.7 src:stunnel4 isync
> Control: block -1 by 900161 906981 906955

> We file this bug to:
> 1) allow reverse dependencies some time (we let you judge how long is
> reasonable for the serious severity) to adapt to the new situation
> 2) enable the openssl package to collect information which packages it
> breaks and which version of those package fix the issue. With that
> information the openssl package can add versioned Breaks

As a status update, I count just six packages left in testing that are
marked as blockers for this bug. (I could be wrong of course; double
checking welcome.)

- src:foolscap #898800: foolscap: FTBFS against openssl 1.1.1
- src:kdeconnect #907339: qtbase-opensource-src breaks kdeconnect autopkgtest 
possibly due to new openssl
- src:m2crypto #897658: m2crypto: FTBFS against openssl 1.1.1
- src:python-boto #909545: SSL CERTIFICATE_VERIFY_FAILED when using gs (Google 
Cloud Storage) backend
- src:kimap #907427: (kimap) openssl 1.1.1 breaks ssl tests
- src:ruby-eventmachine #900160: ruby-eventmachine: FTBFS against openssl 1.1.1

Is it still useful to block openssl 1.1.1 testing migration with this bug?

My personal concern is that the openssl testing/unstable situation has
been the only blocker for a Perl 5.28 transition for quite some time now,
and the buster transition deadline (2019-01-12) is less than three
months away.
-- 
Niko Tyni   nt...@debian.org

Bug#911259: ruby-httpclient: Please use the system ca-certificates instead of bundling one

[Vincent Tondellier]

Package: ruby-httpclient
Version: 2.8.3-1
Severity: normal

Dear Maintainer,

ruby-httpclient bundles a copy of the root certificate authorities:

$ dpkg -L ruby-httpclient | grep pem
/usr/lib/ruby/vendor_ruby/httpclient/cacert.pem
/usr/lib/ruby/vendor_ruby/httpclient/cacert1024.pem
...

Thus, the local CAs configured by the local system administrator (by adding
a .crt file in /usr/local/share/ca-certificates/) are ignored, the 
explicitly

untrusted CAs are still valid, etc ...

Test (with ca-cacert installed):
$ ruby -rhttpclient -e 'p HTTPClient.get("https://www.cacert.org;)'
...
/usr/lib/ruby/vendor_ruby/httpclient/ssl_socket.rb:103:in `connect': 
SSL_connect returned=1 errno=0 state=error: certificate verify failed 
(unable to get local issuer certificate) (OpenSSL::SSL::SSLError)


Expected:
$ curl https://www.cacert.org


Please find attached a debdiff to use the system CA bundle instead.
Some comments:
- the file "cacert1024.pem" is not used by the code: removed
- the ca-certificates package is already pulled by rubygems-integration,
 but a direct dependency may be better


Thanks.

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 ruby-httpclient depends on:
ii  ruby1:2.5.1
ii  ruby-http-cookie1.0.2-1
ii  ruby2.1 [ruby-interpreter]  2.1.5-4
ii  ruby2.2 [ruby-interpreter]  2.2.4-1

ruby-httpclient recommends no packages.

ruby-httpclient suggests no packages.

-- no debconf information
diff -Nru ruby-httpclient-2.8.3/debian/changelog ruby-httpclient-2.8.3/debian/changelog
--- ruby-httpclient-2.8.3/debian/changelog	2017-07-31 16:40:48.0 +0200
+++ ruby-httpclient-2.8.3/debian/changelog	2018-10-17 19:30:30.0 +0200
@@ -1,3 +1,9 @@
+ruby-httpclient (2.8.3-2) UNRELEASED; urgency=medium
+
+  * Unbundle the root CA list, use the one from ca-certificates
+
+ -- Vincent Tondellier   Wed, 17 Oct 2018 19:30:30 +0200
+
 ruby-httpclient (2.8.3-1) unstable; urgency=medium
 
   * Team upload
diff -Nru ruby-httpclient-2.8.3/debian/ruby-httpclient.links ruby-httpclient-2.8.3/debian/ruby-httpclient.links
--- ruby-httpclient-2.8.3/debian/ruby-httpclient.links	1970-01-01 01:00:00.0 +0100
+++ ruby-httpclient-2.8.3/debian/ruby-httpclient.links	2018-10-17 13:32:19.0 +0200
@@ -0,0 +1 @@
+usr/lib/ssl/certs/ca-certificates.crt  usr/lib/ruby/vendor_ruby/httpclient/cacert.pem
diff -Nru ruby-httpclient-2.8.3/debian/rules ruby-httpclient-2.8.3/debian/rules
--- ruby-httpclient-2.8.3/debian/rules	2017-07-31 16:40:48.0 +0200
+++ ruby-httpclient-2.8.3/debian/rules	2018-10-17 13:32:13.0 +0200
@@ -6,3 +6,8 @@
 
 %:
 	dh $@ --buildsystem=ruby --with ruby
+
+override_dh_auto_install:
+	dh_auto_install
+	rm -f debian/ruby-httpclient/usr/lib/ruby/vendor_ruby/httpclient/cacert1024.pem
+	rm -f debian/ruby-httpclient/usr/lib/ruby/vendor_ruby/httpclient/cacert.pem

Bug#911020: installation-guide: Comments on section D.3

[Brian Potkin]

On Tue 16 Oct 2018 at 23:00:17 +0200, Holger Wansing wrote:

> Hi,
> 
> Brian Potkin  wrote:
> > Please have a look at
> > 
> >   https://lists.debian.org/debian-user/2018/10/msg00438.html
> > 
> > and its followup
> > 
> >   https://lists.debian.org/debian-user/2018/10/msg00448.html
> > 
> > Could changes to advice for /e/n/i and /etc/hosts be considered?
> 
> Getting some sort of a patch for this would speed up the process ...

This is for D.3.4.4. Configure Networking.

8<==8<===

###
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
# See the interfaces(5) manpage for information on what options are
# available and look at the files in /usr/share/doc/ifupdown/examples/.
###

# The loopback interface isn't really required any longer,
# but can be used if needed.
#
# auto lo
# iface lo inet loopback

# To use dhcp:
#
# auto eth0
# iface eth0 inet dhcp

# An example static IP setup: (network, broadcast and gateway are optional)
#
# auto eth0
# iface eth0 inet static
# address 192.168.0.42
# netmask 255.255.255.0
# gateway 192.168.0.1

Enter your nameserver(s) and search directives in /etc/resolv.conf:

# editor /etc/resolv.conf

A simple example /etc/resolv.conf:

search example.com
nameserver 10.1.1.36
nameserver 192.168.9.100

==8<==8<

I hope this is reasonably helpful and sufficient for you to make a
decision.

Regards,

Brian.

Bug#911258: libopenhmd-dev: missing dependency on libhidapi-dev, required by pkg-config metadata

[Simon McVittie]

Package: libopenhmd-dev
Version: 0.2.0-2
Severity: serious
Tags: patch
Justification: Policy 3.5

libopenhmd-dev contains openhmd.pc, which Requires hidapi-libusb.
hidapi-libusb.pc is provided by libhidapi-dev, which is a
build-dependency for libopenhmd but is not included in libopenhmd's
dependencies.

The pkg-config file also contains an incorrect includedir and libdir,
because it assumes that the .pc file is installed 2 directories below
${prefix} (typically ${prefix}/lib/pkgconfig), but this is not true in
Debian. I attach proposed patches to fix this. Note that they include a
non-upstreamed patch for the pkg-config metadata.

This class of bug is easy to detect with an autopkgtest that builds
and runs a simple program (also included in the attached patches).

Regards,
smcv
>From f89ce3e8b599cf7783fb5db23d95d15315c1186e Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Wed, 17 Oct 2018 17:14:57 +0100
Subject: [PATCH 1/3] d/tests/build: Add a simple compile/link/execute test

---
 debian/changelog |  6 ++
 debian/tests/build   | 23 +++
 debian/tests/control |  3 +++
 3 files changed, 32 insertions(+)
 create mode 100755 debian/tests/build
 create mode 100644 debian/tests/control

diff --git a/debian/changelog b/debian/changelog
index fdf402e..6d71daa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+libopenhmd (0.2.0-3.1) UNRELEASED; urgency=medium
+
+  * d/tests/build: Add a simple compile/link/execute test
+
+ -- Simon McVittie   Wed, 17 Oct 2018 17:14:22 +0100
+
 libopenhmd (0.2.0-3) unstable; urgency=medium
 
   * Fix filename in debian/watch
diff --git a/debian/tests/build b/debian/tests/build
new file mode 100755
index 000..9bb6c12
--- /dev/null
+++ b/debian/tests/build
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+set -e
+exec 2>&1
+set -u
+set -x
+
+cd "$AUTOPKGTEST_TMP"
+cat > example.c <<'EOF'
+/* A very much simplified version of examples/simple/simple.c */
+#include 
+
+int main(void)
+{
+ohmd_context *ctx = ohmd_ctx_create();
+ohmd_ctx_destroy(ctx);
+return 0;
+}
+EOF
+
+gcc -o example example.c $(pkg-config --cflags --libs openhmd)
+test -x ./example
+./example
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..9140881
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,3 @@
+Tests: build
+Restrictions: superficial
+Depends: build-essential, libopenhmd-dev, pkg-config
-- 
2.19.1

>From 66b6c5645d4edadbb2d80121e78a2ef4e901b357 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Wed, 17 Oct 2018 17:44:39 +0100
Subject: [PATCH 2/3] Make libopenhmd-dev depend on libhidapi-dev so the
 pkg-config metadata will work

---
 debian/changelog | 2 ++
 debian/control   | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 6d71daa..b7423fd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,8 @@
 libopenhmd (0.2.0-3.1) UNRELEASED; urgency=medium
 
   * d/tests/build: Add a simple compile/link/execute test
+  * Make libopenhmd-dev depend on libhidapi-dev so the pkg-config
+metadata will work
 
  -- Simon McVittie   Wed, 17 Oct 2018 17:14:22 +0100
 
diff --git a/debian/control b/debian/control
index 00f2ef4..38d4813 100644
--- a/debian/control
+++ b/debian/control
@@ -27,7 +27,8 @@ Description: API and drivers for immersive technology (shared library)
 Package: libopenhmd-dev
 Architecture: any
 Section: libdevel
-Depends: libopenhmd0 (= ${binary:Version}),
+Depends: libhidapi-dev,
+ libopenhmd0 (= ${binary:Version}),
  ${misc:Depends}
 Description: API and drivers for immersive technology (development files)
  OpenHMD aims to provide a Free and Open Source API and drivers for
-- 
2.19.1

>From 3bdd4fd30d4dda02dd101a6954379ad45d3d5832 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Wed, 17 Oct 2018 17:53:03 +0100
Subject: [PATCH 3/3] Further fixes to the pkg-config metadata

---
 debian/changelog  |  3 +
 ...code-the-hidapi-dependency-in-the-pk.patch | 70 +++
 ...titute-the-correct-libdir-includedir.patch | 27 +++
 debian/patches/series |  2 +
 4 files changed, 102 insertions(+)
 create mode 100644 debian/patches/Autoconf-do-not-hard-code-the-hidapi-dependency-in-the-pk.patch
 create mode 100644 debian/patches/pkg-config-Substitute-the-correct-libdir-includedir.patch
 create mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index b7423fd..dec15aa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,9 @@ libopenhmd (0.2.0-3.1) UNRELEASED; urgency=medium
   * d/tests/build: Add a simple compile/link/execute test
   * Make libopenhmd-dev depend on libhidapi-dev so the pkg-config
 metadata will work
+  * d/p/Autoconf-do-not-hard-code-the-hidapi-dependency-in-the-pk.patch,
+d/p/pkg-config-Substitute-the-correct-libdir-includedir.patch:
+Further fixes to the pkg-config metadata
 
  -- Simon 

Bug#911257: libixp FTCBFS: multiple reasons

[Helmut Grohne]

Source: libixp
Version: 0.6~20121202+hg148-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

libixp fails to cross build from source. It mostly works, but in the end
it uses the build architecture compiler as linker. Since it wants the C
compiler as linker, seeding the variable LD from CC makes it much easier
to replace the compiler. It also hard codes the build architecture
pkg-config. The attached patch fixes both and makes libixp cross
buildable. Please consider applying it.

Helmut
--- libixp-0.6~20121202+hg148.orig/config.mk
+++ libixp-0.6~20121202+hg148/config.mk
@@ -23,7 +23,7 @@
 
 # Compiler, Linker. Linker should usually *not* be ld.
 CC = cc
-LD = cc
+LD = $(CC)
 # Archiver
 AR = ar crs
 #AR = sh -c 'ar cr "$$@" && ranlib "$$@"'
--- libixp-0.6~20121202+hg148.orig/mk/hdr.mk
+++ libixp-0.6~20121202+hg148/mk/hdr.mk
@@ -19,15 +19,16 @@
 TEXT =
 
 FILTER = cat
+PKG_CONFIG ?= pkg-config
 
 EXCFLAGS = $(INCLUDES) -D_XOPEN_SOURCE=600
 
-COMPILE_FLAGS = $(EXCFLAGS) -c $(CFLAGS) $$(pkg-config --cflags $(PACKAGES))
+COMPILE_FLAGS = $(EXCFLAGS) -c $(CFLAGS) $$($(PKG_CONFIG) --cflags $(PACKAGES))
 COMPILE= $(SHELL) $(ROOT)/util/compile "$(CC)" "$(COMPILE_FLAGS)"
 COMPILEPIC = $(SHELL) $(ROOT)/util/compile "$(CC)" "$(COMPILE_FLAGS) $(SOCFLAGS)"
 
-LINK   = $(SHELL) $(ROOT)/util/link "$(LD)" "$$(pkg-config --libs $(PACKAGES)) $(LDFLAGS) $(LIBS)"
-LINKSO = $(SHELL) $(ROOT)/util/link "$(LD)" "$$(pkg-config --libs $(PACKAGES)) $(SOLDFLAGS) $(LIBS) $(SHARED)"
+LINK   = $(SHELL) $(ROOT)/util/link "$(LD)" "$$($(PKG_CONFIG) --libs $(PACKAGES)) $(LDFLAGS) $(LIBS)"
+LINKSO = $(SHELL) $(ROOT)/util/link "$(LD)" "$$($(PKG_CONFIG) --libs $(PACKAGES)) $(SOLDFLAGS) $(LIBS) $(SHARED)"
 
 CLEANNAME=$(SHELL) $(ROOT)/util/cleanname
 

Bug#911256: libopenhmd: Vcs metadata outdated

[Simon McVittie]

Source: libopenhmd
Version: 0.2.0-3
Severity: minor

libopenhmd's Vcs-* metadata is no longer valid since the shutdown of
alioth.debian.org. A code-drop is available in
.

Since it was in the collab-maint group, I've assumed it's OK to
import it into the equivalent Debian group on salsa.debian.org:
. Please update the Vcs-*
metadata to point there, or to any other location of your choice.

Thanks,
smcv

Bug#911255: bandwidthd FTCBFS: multiple reasons

[Helmut Grohne]

Source: bandwidthd
Version: 2.0.1+cvs20090917-11
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

bandwidthd fails to cross build from source, for multiple reasons. It
doesn't pass --host to ./configure. dh_auto_configure can take care of
that. It uses AC_CHECK_FILE to check for directories on the build
machine, while AC_CHECK_FILE is only to be used for host files. Finally
it strips during make install with the wrong strip. The attached patch
fixes all of that. Please consider applying it.

Helmut
diff --minimal -Nru bandwidthd-2.0.1+cvs20090917/debian/changelog 
bandwidthd-2.0.1+cvs20090917/debian/changelog
--- bandwidthd-2.0.1+cvs20090917/debian/changelog   2017-09-15 
10:41:04.0 +0200
+++ bandwidthd-2.0.1+cvs20090917/debian/changelog   2018-10-17 
19:50:30.0 +0200
@@ -1,3 +1,13 @@
+bandwidthd (2.0.1+cvs20090917-11.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_configure pass --host to ./configure.
++ cross.patch: Don't use AC_CHECK_FILE for build machine files.
++ Don't strip during make install.
+
+ -- Helmut Grohne   Wed, 17 Oct 2018 19:50:30 +0200
+
 bandwidthd (2.0.1+cvs20090917-11) unstable; urgency=medium
 
   * Orphan package.
diff --minimal -Nru bandwidthd-2.0.1+cvs20090917/debian/patches/cross.patch 
bandwidthd-2.0.1+cvs20090917/debian/patches/cross.patch
--- bandwidthd-2.0.1+cvs20090917/debian/patches/cross.patch 1970-01-01 
01:00:00.0 +0100
+++ bandwidthd-2.0.1+cvs20090917/debian/patches/cross.patch 2018-10-17 
19:50:30.0 +0200
@@ -0,0 +1,19 @@
+--- bandwidthd-2.0.1+cvs20090917.orig/configure.in
 bandwidthd-2.0.1+cvs20090917/configure.in
+@@ -30,12 +30,12 @@
+ CPPFLAGS="$CPPFLAGS -I/usr/local/include"
+ 
+ #Check for Darwin sw directory
+-AC_CHECK_FILE(/sw/lib, LDFLAGS="$LDFLAGS -L/sw/lib")
+-AC_CHECK_FILE(/sw/include, CPPFLAGS="$CPPFLAGS -I/sw/include")
++test -d /sw/lib && LDFLAGS="$LDFLAGS -L/sw/lib"
++test -d /sw/include && CPPFLAGS="$CPPFLAGS -I/sw/include"
+ 
+ #Check for NetBSD usr/pkg directory
+-AC_CHECK_FILE(/usr/pkg/lib, LDFLAGS="$LDFLAGS -L/usr/pkg/lib")
+-AC_CHECK_FILE(/usr/pkg/include, CPPFLAGS="$CPPFLAGS -I/usr/pkg/include")
++test -d /usr/pkg/lib LDFLAGS="$LDFLAGS -L/usr/pkg/lib"
++test -d /usr/pkg/include CPPFLAGS="$CPPFLAGS -I/usr/pkg/include"
+ 
+ # Required for solaris
+ AC_CHECK_LIB(socket, connect)
diff --minimal -Nru bandwidthd-2.0.1+cvs20090917/debian/patches/series 
bandwidthd-2.0.1+cvs20090917/debian/patches/series
--- bandwidthd-2.0.1+cvs20090917/debian/patches/series  2015-07-06 
07:47:40.0 +0200
+++ bandwidthd-2.0.1+cvs20090917/debian/patches/series  2018-10-17 
19:50:30.0 +0200
@@ -12,3 +12,4 @@
 fix-gcc-5-ftbfs.patch
 convert_short_php_syntax_to_long.patch
 replace_depricated_HTTP_GET_VARS_by_GET.patch
+cross.patch
diff --minimal -Nru bandwidthd-2.0.1+cvs20090917/debian/rules 
bandwidthd-2.0.1+cvs20090917/debian/rules
--- bandwidthd-2.0.1+cvs20090917/debian/rules   2013-06-14 00:41:25.0 
+0200
+++ bandwidthd-2.0.1+cvs20090917/debian/rules   2018-10-17 19:50:30.0 
+0200
@@ -6,7 +6,7 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-configureoptions = --prefix=/usr --bindir=/usr/sbin/ 
--sysconfdir=/etc/bandwidthd/ --localstatedir=/var/lib/
+configureoptions = --bindir=/usr/sbin/ --sysconfdir=/etc/bandwidthd/ 
--localstatedir=/var/lib/
 
 p_bwdstatic = bandwidthd
 p_bwdpgsql = bandwidthd-pgsql
@@ -26,9 +26,6 @@
 else
CFLAGS += -O2
 endif
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   INSTALL_PROGRAM += -s
-endif
 
 configure:
 
@@ -41,7 +38,7 @@
cp -f /usr/share/misc/config.sub config.sub
dh_autoreconf
chmod +x configure
-   ./configure $(configureoptions) --disable-pgsql
+   INSTALL='install --strip-program=true' dh_auto_configure -- 
$(configureoptions) --disable-pgsql
touch $@

 configure-bwdpgsql: configure-bwdpgsql-stamp
@@ -52,7 +49,7 @@
[ ! -f /usr/share/misc/config.guess ] || cp -f 
/usr/share/misc/config.guess config.guess
[ ! -f /usr/share/misc/config.sub ] || cp -f /usr/share/misc/config.sub 
config.sub
chmod +x configure
-   ./configure $(configureoptions) --enable-pgsql
+   INSTALL='install --strip-program=true' dh_auto_configure -- 
$(configureoptions) --enable-pgsql
touch $@
 
 

Bug#894359: Now we have antlr 4.6 - any chance to get 4.7 soon (Was: beast-mcmc2: Cannot find symbol CharStreams.fromString(newick))

[Andreas Tille]

Hi Andrius,

On Wed, Oct 17, 2018 at 01:57:29PM +0300, Andrius Merkys wrote:
> On 10/16/18 5:03 PM, Andreas Tille wrote:
> > Very good.  Let me know if I could be of any help (which basically would
> > boil down to testing and if needed sponsoring).
> 
> Many thanks! I will turn to you once I get the updated package build.

Fine.
 
> > Interesting.  You might like to join the Debian Med sprint in March 2019
> > which will happen in Vilnius[1] (no better details yet).
> 
> Thanks, I will be there.

Meanwile the Wiki page is setup and you (and for sure everybody else
reading this list) can add your name to the list of participants:

   https://wiki.debian.org/Sprints/2019/DebianMed2019

Looking forward to meed you in Vilnius

  Andreas.

-- 
http://fam-tille.de

Bug#885678: gmysqlcc: Depends on unmaintained gtksourceview2

[René Mayorga]

On Tue, Oct 16, 2018 at 12:44:52PM -0400, Jeremy Bicha wrote:
> On Mon, Jan 8, 2018 at 11:07 AM René Mayorga  wrote:
> > On Thu, Dec 28, 2017 at 10:14:04PM -0500, Jeremy Bicha wrote:
> > > Please port your package to GTK3 and gtksourceview3 and related
> > > maintained libraries. Otherwise, please consider requesting that your
> > > package be removed from Debian to help us complete this goal.
> >
> > This is quite an old package, upstream is dead for more than 5 years at
> > least. I don't think there is any plan to port this package to use GTK3.
> >
> > Besides this, this package is not longer so usable as it was before, now
> > mysql-workbench fulfill all the needs for the users, thought.
> >
> > So I'll request this package to be removed.
> 
> Do you still intend to file the removal bug? I can file it for you if you 
> want.

Please go ahead, I've been quite busy and haven't time to do this simple
task :(

Cheers

--
René


signature.asc
Description: Digital signature

Bug#911254: libclanlib-dev: move .pc files to a multiarch location

[Helmut Grohne]

Package: libclanlib-dev
Version: 1.0~svn3827-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:trophy

trophy fails to cross build from source, because it cannot find
clanApp-1.0.pc. During cross compilation, pkg-config does not search
/usr/lib/pkgconfig. Please move the .pc files to
/usr/lib//pkgconfig. The attached patch implements that using
dh_auto_configure, which passes a multiarch --libdir since compat level
9. Please consider applying it.

Helmut
diff --minimal -Nru clanlib-1.0~svn3827/debian/changelog 
clanlib-1.0~svn3827/debian/changelog
--- clanlib-1.0~svn3827/debian/changelog2017-07-26 01:21:28.0 
+0200
+++ clanlib-1.0~svn3827/debian/changelog2018-10-17 19:36:24.0 
+0200
@@ -1,3 +1,11 @@
+clanlib (1.0~svn3827-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Let dh_auto_configure pass a multiarch --libdir to ./configure.
+(Closes: #-1)
+
+ -- Helmut Grohne   Wed, 17 Oct 2018 19:36:24 +0200
+
 clanlib (1.0~svn3827-7) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru clanlib-1.0~svn3827/debian/libclanapp-1.0v5.install 
clanlib-1.0~svn3827/debian/libclanapp-1.0v5.install
--- clanlib-1.0~svn3827/debian/libclanapp-1.0v5.install 2017-07-26 
01:21:28.0 +0200
+++ clanlib-1.0~svn3827/debian/libclanapp-1.0v5.install 2018-10-17 
19:36:24.0 +0200
@@ -1,11 +1,11 @@
-usr/lib/libclanApp*.so.*
-usr/lib/libclanCore*.so.*
-usr/lib/libclanDisplay*.so.*
-usr/lib/libclanGL*.so.*
-usr/lib/libclanGUI*.so.*
-usr/lib/libclanGUIStyleSilver*.so.*
-usr/lib/libclanMikMod*.so.*
-usr/lib/libclanNetwork*.so.*
-usr/lib/libclanSignals*.so.*
-usr/lib/libclanSound*.so.*
-usr/lib/libclanVorbis*.so.*
+usr/lib/*/libclanApp*.so.*
+usr/lib/*/libclanCore*.so.*
+usr/lib/*/libclanDisplay*.so.*
+usr/lib/*/libclanGL*.so.*
+usr/lib/*/libclanGUI*.so.*
+usr/lib/*/libclanGUIStyleSilver*.so.*
+usr/lib/*/libclanMikMod*.so.*
+usr/lib/*/libclanNetwork*.so.*
+usr/lib/*/libclanSignals*.so.*
+usr/lib/*/libclanSound*.so.*
+usr/lib/*/libclanVorbis*.so.*
diff --minimal -Nru clanlib-1.0~svn3827/debian/libclanlib-dev.install 
clanlib-1.0~svn3827/debian/libclanlib-dev.install
--- clanlib-1.0~svn3827/debian/libclanlib-dev.install   2017-07-26 
01:21:28.0 +0200
+++ clanlib-1.0~svn3827/debian/libclanlib-dev.install   2018-10-17 
19:36:24.0 +0200
@@ -1,4 +1,4 @@
 usr/include
-usr/lib/libclan*.so
-usr/lib/libclan*.a
-usr/lib/pkgconfig
+usr/lib/*/libclan*.so
+usr/lib/*/libclan*.a
+usr/lib/*/pkgconfig
diff --minimal -Nru clanlib-1.0~svn3827/debian/libclansdl-1.0v5.install 
clanlib-1.0~svn3827/debian/libclansdl-1.0v5.install
--- clanlib-1.0~svn3827/debian/libclansdl-1.0v5.install 2017-07-26 
01:21:28.0 +0200
+++ clanlib-1.0~svn3827/debian/libclansdl-1.0v5.install 2018-10-17 
19:36:24.0 +0200
@@ -1 +1 @@
-usr/lib/libclanSDL*.so.*
+usr/lib/*/libclanSDL*.so.*
diff --minimal -Nru clanlib-1.0~svn3827/debian/rules 
clanlib-1.0~svn3827/debian/rules
--- clanlib-1.0~svn3827/debian/rules2017-07-26 01:21:28.0 +0200
+++ clanlib-1.0~svn3827/debian/rules2018-10-17 19:36:24.0 +0200
@@ -27,14 +27,13 @@
--enable-clansound --enable-lua --enable-network --enable-dyn \
--enable-vidmode --disable-smalljpeg --disable-debug  \
--enable-asm386=$(use_asm386) \
-   --x-includes=/usr/include/X11 \
-   --prefix=/usr --mandir=/usr/share/man
+   --x-includes=/usr/include/X11
 
 %:
dh $@
 
 override_dh_auto_configure:
-   CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" CPPFLAGS="$(shell 
dpkg-buildflags --get CPPFLAGS)" LDFLAGS="$(shell dpkg-buildflags --get 
LDFLAGS)" ./configure $(CONFIG_FLAGS)
+   CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" CPPFLAGS="$(shell 
dpkg-buildflags --get CPPFLAGS)" LDFLAGS="$(shell dpkg-buildflags --get 
LDFLAGS)" dh_auto_configure -- $(CONFIG_FLAGS)
 
 override_dh_auto_clean:
dh_auto_clean

Bug#911253: RM: gmysqlcc -- RoM; RoQA; depends on unmaintained gtksourceview2

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: gmysq...@packages.debian.org
Affects: src:gmysqlcc

gmysqlcc's last release was a decade ago. It depends on gtksourceview2
which the Debian GNOME team is trying to remove from Debian.

The maintainer approved this removal request in https://bugs.debian.org/885678

Thanks,
Jeremy Bicha

Bug#695157: sed: --in-place (or -i) changes permissions on a file with ACLs applied

[Sven Joachim]

On 2012-12-04 13:57 -0500, Daniel Kahn Gillmor wrote:

> Package: sed
> Version: 4.2.1-10
> Severity: normal
>
> It appears that sed -i tampers with the permissions on a file that has
> ACLs in place.  Below is an example of it granting group read access
> to a given file (and revoking read access to another user):
>
> 0 dkg@pip:/srv/dkg$ getfacl test
> # file: test
> # owner: dkg
> # group: adm
> user::rw-
> user:wt215:r--
> group::---
> mask::r--
> other::---
>
> 0 dkg@pip:/srv/dkg$ sed -i 's/foo/bar/' test
> 0 dkg@pip:/srv/dkg$ getfacl test
> # file: test
> # owner: dkg
> # group: adm
> user::rw-
> group::r--
> other::---
>
> 0 dkg@pip:/srv/dkg$ 
>
> This is potentially a security concern, if sed causes data to be
> exposed to users or groups that should not have read access to it.
>
> Consider, for example, a configuration file owned by user X that
> contains a secret authentication token.  If X has granted read access
> to another user, and refused it for everyone else, and X then modifies
> the config file with sed -i, it could leak the authentication token.

Support for preserving ACLs has been in sed since version 4.2, but the
Debian package lacks it.  I presume adding libacl1-dev to Build-Depends
should be sufficient to fix that, but have not tested it.

>From the latest build log on amd64[1]:

,
| checking sys/acl.h usability... no
| checking sys/acl.h presence... no
| checking for sys/acl.h... no
| configure: WARNING: libacl development library was not found or not usable.
| configure: WARNING: GNU sed will be built without ACL support.
`

Cheers,
   Sven


1. 
https://buildd.debian.org/status/fetch.php?pkg=sed=amd64=4.5-1=1530726731=0

Bug#894519: xpra 2.4 depends on python-gtkglext1

[Jeremy Bicha]

python-gtkglext1 is back in Testing (Buster) now.

Thanks,
Jeremy Bicha

Bug#911252: directvnc FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

Source: directvnc
Version: 0.7.7-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

directvnc fails to cross build from source, because it uses the build
architecture pkg-config via AC_PATH_PROG. The attached patch replaces
that with PKG_PROG_PKG_CONFIG and makes it cross buildable. Please
consider applying it.

Helmut
--- directvnc-0.7.7.orig/configure.in
+++ directvnc-0.7.7/configure.in
@@ -57,7 +57,7 @@
 #
 # Find pkg-config needed for DFB
 #
-AC_PATH_PROG(PKG_CONFIG, pkg-config)
+PKG_PROG_PKG_CONFIG
 if test -z "${PKG_CONFIG}"; then
   AC_MSG_ERROR([*** pkg-config not found. See http://pkgconfig.sourceforge.net])
 fi

Bug#911251: shhmsg FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: shhmsg
Version: 1.4.2-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

shhmsg fails to cross build from source, because it does not pass cross
tools to make. Using dh_auto_build is sufficient to fix that. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru shhmsg-1.4.2/debian/changelog shhmsg-1.4.2/debian/changelog
--- shhmsg-1.4.2/debian/changelog   2015-08-01 12:58:57.0 +0200
+++ shhmsg-1.4.2/debian/changelog   2018-10-17 19:22:07.0 +0200
@@ -1,3 +1,10 @@
+shhmsg (1.4.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 17 Oct 2018 19:22:07 +0200
+
 shhmsg (1.4.2-1) unstable; urgency=medium
 
   * New package maintainer (Closes: #554255).
diff --minimal -Nru shhmsg-1.4.2/debian/rules shhmsg-1.4.2/debian/rules
--- shhmsg-1.4.2/debian/rules   2015-08-01 13:47:33.0 +0200
+++ shhmsg-1.4.2/debian/rules   2018-10-17 19:22:05.0 +0200
@@ -13,9 +13,9 @@
 
 build-stamp:
dh_testdir
-   CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" $(MAKE)
+   CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" 
dh_auto_build
$(MAKE) clean
-   SHARED=1 CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" 
$(MAKE)
+   SHARED=1 CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" 
dh_auto_build
touch build-stamp
 
 clean:

Bug#911250: morse FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: morse
Version: 2.5-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

morse fails to cross build from source, because it does not pass any
cross tools to make. The easiest way of fixing that is using
dh_auto_build. The morse.d directory still hard codes the build
architecture pkg-config. After making it substitutable, morse cross
builds successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru morse-2.5/debian/changelog morse-2.5/debian/changelog
--- morse-2.5/debian/changelog  2015-06-10 21:40:20.0 +0200
+++ morse-2.5/debian/changelog  2018-10-17 19:16:30.0 +0200
@@ -1,3 +1,12 @@
+morse (2.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build supply cross tools to make.
++ cross.patch: Make pkg-config substitutable.
+
+ -- Helmut Grohne   Wed, 17 Oct 2018 19:16:30 +0200
+
 morse (2.5-1) unstable; urgency=low
 
   * New upstream release.
diff --minimal -Nru morse-2.5/debian/patches/cross.patch 
morse-2.5/debian/patches/cross.patch
--- morse-2.5/debian/patches/cross.patch1970-01-01 01:00:00.0 
+0100
+++ morse-2.5/debian/patches/cross.patch2018-10-17 19:16:30.0 
+0200
@@ -0,0 +1,25 @@
+--- morse-2.5.orig/morse.d/Makefile
 morse-2.5/morse.d/Makefile
+@@ -3,16 +3,18 @@
+ BEEPERS = beepLinux.c beepOSS.c beepX11.c beepALSA.c
+ SOURCES = alarm.c morse.c alarm.h beep.h $(BEEPERS)
+ 
++PKG_CONFIG ?= pkg-config
++
+ # The flags necessary to link with the X11 libraries.
+ X11LIBS = -L/usr/X11R6/lib -lX11
+ 
+ # The flags necessary to link with PulseAudio and support pthread
+-PA_CFLAGS = -pthread $(shell pkg-config --cflags libpulse-simple)
+-PA_LIBS = $(shell pkg-config --libs libpulse-simple) -pthread
++PA_CFLAGS = -pthread $(shell $(PKG_CONFIG) --cflags libpulse-simple)
++PA_LIBS = $(shell $(PKG_CONFIG) --libs libpulse-simple) -pthread
+ 
+ # The flags necessary to link with ALSA
+-ALSA_CFLAGS = $(shell pkg-config --cflags alsa)
+-ALSA_LIBS = $(shell pkg-config --libs alsa)
++ALSA_CFLAGS = $(shell $(PKG_CONFIG) --cflags alsa)
++ALSA_LIBS = $(shell $(PKG_CONFIG) --libs alsa)
+ 
+ # Any additional flags your favorite C compiler requires to work.
+ CFLAGS  = -O3 -I/usr/X11R6/include $($(device)_EXTRA_CFLAGS)
diff --minimal -Nru morse-2.5/debian/patches/series 
morse-2.5/debian/patches/series
--- morse-2.5/debian/patches/series 2015-06-10 21:38:46.0 +0200
+++ morse-2.5/debian/patches/series 2018-10-17 19:16:30.0 +0200
@@ -4,3 +4,4 @@
 04fix-pa_simple_write-with-mono-output.patch
 05fix_ftbfs.patch
 06fix_-X_handling.patch
+cross.patch
diff --minimal -Nru morse-2.5/debian/rules morse-2.5/debian/rules
--- morse-2.5/debian/rules  2015-06-10 21:38:46.0 +0200
+++ morse-2.5/debian/rules  2018-10-17 19:16:27.0 +0200
@@ -37,15 +37,15 @@
dh_testdir
 
# Add here commands to compile the package.
-   cd qso.d && $(MAKE)
-   cd morse.d && $(MAKE) DEVICE=X11
-   cd morse.d && $(MAKE) DEVICE=PA
-   cd morse.d && $(MAKE) DEVICE=OSS
+   dh_auto_build --sourcedirectory=qso.d
+   dh_auto_build --sourcedirectory=morse.d -- DEVICE=X11
+   dh_auto_build --sourcedirectory=morse.d -- DEVICE=PA
+   dh_auto_build --sourcedirectory=morse.d -- DEVICE=OSS
if dpkg-architecture -ilinux-any ; then \
-   cd morse.d && $(MAKE) DEVICE=Linux ; \
+   dh_auto_build --sourcedirectory=morse.d -- DEVICE=Linux ; \
fi
if dpkg-architecture -ilinux-any ; then \
-   cd morse.d && $(MAKE) DEVICE=ALSA ; \
+   dh_auto_build --sourcedirectory=morse.d -- DEVICE=ALSA ; \
fi
#docbook-to-man debian/morse.sgml > morse.1
xmlto man morse.xml

Bug#911249: between FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: between
Version: 6+dfsg1-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

between fails to cross build from source, because it builds for the
wrong architecture. No cross tools are passed to make. dh_auto_build
fixes that in theory. However, between uses the uncommon variable GXX,
so we need to rename the compiler. That's sufficient to make between
cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru between-6+dfsg1/debian/changelog 
between-6+dfsg1/debian/changelog
--- between-6+dfsg1/debian/changelog2013-05-10 15:02:07.0 +0200
+++ between-6+dfsg1/debian/changelog2018-10-17 16:26:11.0 +0200
@@ -1,3 +1,12 @@
+between (6+dfsg1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Pass the C++ compiler as GXX.
+
+ -- Helmut Grohne   Wed, 17 Oct 2018 16:26:11 +0200
+
 between (6+dfsg1-3) unstable; urgency=low
 
   * Bump the debhelper compat to 9 and enable extra hardening
diff --minimal -Nru between-6+dfsg1/debian/rules between-6+dfsg1/debian/rules
--- between-6+dfsg1/debian/rules2013-05-09 09:23:18.0 +0200
+++ between-6+dfsg1/debian/rules2018-10-17 16:26:11.0 +0200
@@ -20,7 +20,7 @@
sed -i -e 's/^OPTIMIZE_FLAG = .*/OPTIMIZE_FLAG = /' 
game7/gameSource/Makefile
sed -i -e 's/^COMPILE_FLAGS = /COMPILE_FLAGS = $$(CFLAGS) $$(CPPFLAGS) 
/' game7/gameSource/Makefile
sed -i -e 's/^LINK_FLAGS = /LINK_FLAGS = $$(LDFLAGS) /' 
game7/gameSource/Makefile
-   $(MAKE) -C game7/gameSource LDFLAGS="$(LDFLAGS)" CPPFLAGS="$(CPPFLAGS)" 
CFLAGS="$(CFLAGS) -DETCDIR=\\\"/etc/between\\\" 
-DDATADIR=\\\"/usr/share/games/between/\\\""
+   dh_auto_build --sourcedirectory=game7/gameSource -- 'GXX=$$(CXX)' 
LDFLAGS="$(LDFLAGS)" CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS) 
-DETCDIR=\\\"/etc/between\\\" -DDATADIR=\\\"/usr/share/games/between/\\\""
 
 override_dh_auto_clean:
[ ! -f game7/gameSource/Makefile ] || $(MAKE) -C game7/gameSource clean

Bug#911169: console-setup: can vidcontrol and kbdcontrol depends be removed for non-kfreebsd archs?

[Holger Wansing]

Hi,

Ben Hutchings  wrote:
> On Tue, 2018-10-16 at 19:43 +0200, Holger Wansing wrote:
> > Package: console-setup
> > Severity: wishlist
> > 
> > 
> > Holger Wansing  wrote:
> > > Holger Wansing  wrote:
> > > > I noticed that the latest upload of console-setup fails to
> > > > migrate to testing.
> > > > It claims being "uninstallable on amd64", while
> > > > https://buildd.debian.org/status/fetch.php?pkg=console-setup=all=1.185=1534275854=0
> > > > says that the build was successful.
> > > > 
> > > > How can I find out what is wrong here?
> > > 
> > > Hmm, at the 15. day it migrated to testing now, while I cannot see that 
> > > something has changed.
> > 
> > console-setup needs several attempts everytime, 'til it migrates.
> > 
> > The point is, that autopkgtest claims about unmet dependencies for all
> > archs (packages vidcontrol and kbdcontrol being unavailable).
> > However, these packages are only existing for kfreebsd.
> > 
> > Why does console-setup depend on it on all archs?
> > Can the control file be changed for console-setup-freebsd as below?
> 
> No.  dpkg-gencontrol handles architecture qualification in Depends
> (etc.) at build time, for architecture-dependent binary packages.  You
> must not use them in architecture-independent binary packages.

Ok. Anything else that can be done about this?
Maybe change

- Architecture: all
+ Architecture: kfreebsd-amd64 kfreebsd-i386

for console-setup-freebsd?

Holger


> >   Package: console-setup-freebsd
> >   Section: utils
> >   Priority: optional
> >   Architecture: all
> >   Multi-Arch: foreign
> > - Depends: vidcontrol, kbdcontrol, keyboard-configuration (= 
> > ${source:Version}), ${misc:Depends}, init-system-helpers (>= 1.29~) | 
> > initscripts
> > + Depends: vidcontrol [kfreebsd-any], kbdcontrol [kfreebsd-any], 
> > keyboard-configuration (= ${source:Version}), ${misc:Depends}, 
> > init-system-helpers (>= 1.29~) | initscripts
> >   Suggests: console-setup
> >   Conflicts: console-setup-linux
> >   Breaks: console-setup (<< 1.71)
> >   Replaces: console-setup (<< 1.71)
> >   Description: FreeBSD specific part of console-setup
> >This package includes raw, uuencoded fonts and various screen maps.
> > 
> > 
> > console-setup-freebsd is not needed on archs other than kfreebsd, I suspect?
> > Or am I missing something?
> > 
> > 
> > Holger
> > 
> > 
> > 
> -- 
> Ben Hutchings
> Man invented language to satisfy his deep need to complain.
>   - Lily Tomlin
> 
> 


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#897926: status?

[Andrew Brown]

Hi all,

Just checking on the status of this bug/feature, since it's been about 5
months.

I don't know a ton about the processes here, so anything I can do to help,
let me know.

-- 
*Andrew Brown* | *Senior Web Developer*
*Kennedy Communications*
D: 608-443-0976 | abr...@kennedyc.com
9 Odana Ct Suite 200 | Madison, WI 53719

Like KennedyC on Facebook! 

Bug#910567: ITA: sn -- Small NNTP server for leaf sites

[Robert J. Clay]

On Mon, Oct 15, 2018 at 6:46 PM Hilko Bengen  wrote:
>
> * Robert J. Clay:
>
> >> For some reason Gitlab thinks that "upstream" should be the
> >> "default" branch, i.e. the branch that is checked out after a git clone.
> >
> >That's a salsa (gitlab) setting for the repository.  I've changed
> > that to 'master'.
>
> Ah, I found that setting, too. Thanks.

   You're quite welcome.

>
> I have also added upload privileges for your GPG key
> (24483AE0874D86966DCDECF4198CAB6F43B7EA9A), so you should be able to
> take over the package.

   Many thanks!  I'll be working on getting that done.



-- 
Robert J. Clay
rjc...@gmail.com

Bug#911179: Seems to be fixed

[Jussi Pakkanen]

Hi

This seems to be fixed now, at least I could do pbuilder package builds today.

Bug#903656: publicsuffix 20180523.2326-0+deb9u1 flagged for acceptance

[Daniel Kahn Gillmor]

On Tue 2018-10-09 19:15:09 +, Adam D Barratt wrote:
> The upload referenced by this bug report has been flagged for acceptance into 
> the proposed-updates queue for Debian stretch.
>
> Thanks for your contribution!
>
> Upload details
> ==
>
> Package: publicsuffix
> Version: 20180523.2326-0+deb9u1

thanks!  since this process started, there has been more updates to the
publicsuffix list.  I've opened #911244 to track that request.

Regards,

--dkg

Bug#910684: munin: autopkgtest regression

[Holger Levsen]

On Wed, Oct 17, 2018 at 06:25:13PM +0200, Ivo De Decker wrote:
> > > Changing the test to show the difference between both lists of plugins 
> > > would
> > > probably be nice.
> > How could this be done? I'd like to include this in the 2.0.42-2 upload.
> I'm not sure. Maybe Paul has suggestions on logging detailed output when
> test fail.

I'd also take improved/increased logging output in any case, whether
failure or success...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#826994: [Pkg-zfsonlinux-devel] Bug#826994: Devuan Compatibility

[Chris Zubrzycki]

On Wed, 17 Oct 2018 17:03:34 +0200 Petter Reinholdtsen  wrote:
> 
> [Chris Dos]
> > If this patch gets applied,
> 
> I believe the point Aron is trying to get through to those of you who
> care about init.d scripts, is that you should work with the upstream
> project to get the scripts included there, to avoid having the Debian
> packages deviate from upstream any more.
> 
> In other words, you are barking up the wrong tree.  Try the upstream
> tree, it might work better.

I think you may be confused here. The scripts have been upstream for years. In 
fact for many years they were the *only* upstream init scripts. 
https://github.com/zfsonlinux/zfs/tree/master/etc/init.d has them, last 
modified 2 years - 3 months ago. That is upstream. They were successfully 
shipped in the upstream debian packages until debian finally accepted a native 
package. We have been trying to get the sysv scripts added back in since then. 
The patch from Chris Dos does not add any init scripts, it only has them 
installed to the debian package and changes the location of 2 binaries to where 
debian put them. His patch only adds 30 lines to the debian build scripts 
almost all in debian/rules. How exactly do we bark this up upstream's tree?


-chris zubrzycki
- --
PGP ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070


Unix  _IS_  user friendly... It's just selective about who its friends are.

Bug#910684: munin: autopkgtest regression

[Ivo De Decker]

Hi Holger,

On 10/17/18 12:24 PM, Holger Levsen wrote:


Changing the test to show the difference between both lists of plugins would
probably be nice.


How could this be done? I'd like to include this in the 2.0.42-2 upload.


I'm not sure. Maybe Paul has suggestions on logging detailed output when 
test fail.


Cheers,

Ivo

Bug#911184: wicd-daemon: Please make log file location configurable

[Dmitry Bogatov]

[2018-10-17 02:30] Axel Beckert 
> Hi Dmitry,

Hi, Axel

> > please make log file location configurable at run time.
> > 
> > In most cases, daemons have option to specify log file location, and
> > providing /dev/stdout fulfils my needs. Wicd, on other hand have path
> > to log file hardcoded in setup.py.
> 
> There is indeed a directory path (not file path!) in setup.py, but the
> hardcoded file name is actually in wicd/wicd-daemon.py.
> 
> Then again, wicd/logfile.py seems to have already support for logging
> to stdout or stderr.
> 
> And as I read the code from wicd/wicd-daemon.py lines 1803 to 1827 and
> lines 1882 to 1905, starting the daemon with the option --no-stdout
> (sic!) should do what you want. Alternatively try --no-stderr
> 
> Can you check if these options already help for your needs?

Not exactly. There are two kind of data, that is stored in
/var/log/wicd/wicd.log:

 * stdout/stderr from subprocessed, that wicd executes
 * messages from wicd proper like 'Autoconnecting...'

If I specify --no-{stdout,stderr}, first group of messages will indeed
go to standard streams of wicd, but messages from wicd proper will go
to /var/log/wicd/wicd.log nevertheless.


pgp6NYrqvc1pl.pgp
Description: PGP signature

Bug#899317: mercurial-git: Breaks with python-dulwich 19.1

[Blake C. Rawlings]

For reference, the recently-released version 0.8.12 of hg-git seems to fix this.

Upstream release: https://bitbucket.org/durin42/hg-git/commits/tag/0.8.12

Upstream mailing-list discussion: 
https://groups.google.com/forum/#!topic/hg-git/LLyCmSzf9Fw

Thanks,

Blake

Bug#909306: qt3d5-dev: Qt53DExtrasConfig.cmake missing

[Philipp Marek]

We do not ship the Qt 3D Extras module because it is considered 
unstable

by upstream. Quoting from [1]:

  This module is under development and is subject to change.

...

We will ship it again once upstream declares it stable.

Thank you for the answer!

But as this is only useful for developers, why not just include it
anyway? Not having it is worse than having a possibly changing
version; when compiling other projects I need one, and if a newer
QT version becomes incompatible to the other software there's still
no more problem than if it is included.

The _important_ part is IMO to keep the local binaries and their
dev files consistent; that could be accomplished by shipping the
required dev files.


If there's some incompatible change, it's good when I notice via
a compile error; I can just use archive.debian.org to go back
anyway.
Much better than having to _manually_ keep the library and dev
environment in sync (and failing to do so half of the time!)


Please re-include it; by running testing/unstable we developers
implicitly acknowledge incompatible changes already.


Regards,

Phil

Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

[Ian Jackson]

Russ Allbery writes ("Bug#911165: debian-policy: drop requirement to ship 
sysvinit init script with same name"):
> This is not the sort of thing that we should be dropping on an ad hoc
> basis given the project decision to support multiple init systems, since
> if we give up this principle it will be *extremely* hard to re-establish
> it.
> 
> That doesn't mean that we can't decide to drop formal sysvinit support.
> It does mean that we should do this properly, as a project-wide decision,
> which is way, WAY beyond the scope of Policy and is *absolutely not*
> something that we're going to be able to decide here on this mailing list
> or in this bug report.

Needless to say I agree with all of this.

Obviously when there are situations where providing an init script is
actually wrong (because under sysvinit or other systems the daemon is
started some other way), the init script should not be provided.

In the existing text, this could be done as follows:

  | However, any package integrating with other init systems must also
  | be backwards-compatible with sysvinit

+ |  , usually

  |   by providing a SysV-style init
  | script with the same name as and equivalent functionality to any
  | init-specific job

As for the Russ's point about exact equivalence, that would be dealt
with by something like this:

  | script with the same name as and

+ |  roughly

  |  equivalent functionality to any
  | init-specific job

Ian.

Bug#911248: globus-gass-copy-progs: copy fails with some SSL errors

[Christoph Anton Mitterer]

Package: globus-gass-copy-progs
Version: 10.3-1
Severity: important


Hi.

The following might be some issue with current libssl versions?
$ globus-url-copy -dbg -vb 
gsiftp://lcg-lrz-dc09.grid.lrz.de/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasdatadisk/rucio/data15_13TeV/8f/66/DRAW_RPVLL.10929329._031512.pool.root.1
 foo 
Source: 
gsiftp://lcg-lrz-dc09.grid.lrz.de/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasdatadisk/rucio/data15_13TeV/8f/66/
Dest:   file:///home/calestyo/
  DRAW_RPVLL.10929329._031512.pool.root.1  ->  foo
debug: starting to get 
gsiftp://lcg-lrz-dc09.grid.lrz.de/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasdatadisk/rucio/data15_13TeV/8f/66/DRAW_RPVLL.10929329._031512.pool.root.1
debug: connecting to 
gsiftp://lcg-lrz-dc09.grid.lrz.de/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasdatadisk/rucio/data15_13TeV/8f/66/DRAW_RPVLL.10929329._031512.pool.root.1

debug: response from 
gsiftp://lcg-lrz-dc09.grid.lrz.de/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasdatadisk/rucio/data15_13TeV/8f/66/DRAW_RPVLL.10929329._031512.pool.root.1:
220 GSI FTP door ready

debug: authenticating with 
gsiftp://lcg-lrz-dc09.grid.lrz.de/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasdatadisk/rucio/data15_13TeV/8f/66/DRAW_RPVLL.10929329._031512.pool.root.1
debug: fault on connection to 
gsiftp://lcg-lrz-dc09.grid.lrz.de/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasdatadisk/rucio/data15_13TeV/8f/66/DRAW_RPVLL.10929329._031512.pool.root.1:
 globus_ftp_control: gss_init_sec_context failed
debug: data callback, error globus_ftp_control: gss_init_sec_context failed, 
buffer 0x7f01aea93010, length 0, offset=0, eof=true
debug: operation complete

error: globus_ftp_control: gss_init_sec_context failed
GSS failure: 
GSS Major Status: General failure
GSS Minor Status Error Chain:
globus_gsi_gssapi: Error with gss context
globus_gsi_gssapi: Error with gss credential handle
globus_gsi_gssapi: Error with openssl: Couldn't set the certificate to be used 
for the SSL context
OpenSSL Error: ../ssl/ssl_rsa.c:310: in library: SSL routines, function 
SSL_CTX_use_certificate: ee key too small


Both, client and server certs are current ones as issued within the grid.

Any ideas?

Thanks,
Chris.



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

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

Versions of packages globus-gass-copy-progs depends on:
ii  libc6 2.27-6
ii  libglobus-common0 18.0-1
ii  libglobus-ftp-client2 9.1-1
ii  libglobus-gass-copy2  10.3-1
ii  libglobus-gass-transfer2  9.0-1
ii  libglobus-gsi-sysconfig1  9.1-1
ii  libglobus-gssapi-error2   6.0-1
ii  libglobus-gssapi-gsi4 14.7-1
ii  libglobus-io3 12.1-1
ii  libltdl7  2.4.6-6
ii  libssl1.1 1.1.1-1

globus-gass-copy-progs recommends no packages.

globus-gass-copy-progs suggests no packages.

-- no debconf information

Bug#911246: RFA: fpart -- sort file trees and pack them into bags

[Carl Chenet]

Package: wnpp
Severity: normal

I request an adopter for the fpart package (I'm not using it any more).

The upstream is very responsive and would like an updated version of this 
package.

The package description is:
 Fpart is a tool that helps you sort file trees and pack them into bags (called
 "partitions"). It is developed in C and available under the BSD license.
 .
 It splits a list of directories and file trees into a certain number of
 partitions, trying to produce partitions with the same size and number of
 files.
 It can also produce partitions with a given number of files or a limited size.
 Once generated, partitions are either printed as file lists to stdout
 (default) or to files. Those lists can then be used by third party programs.
 .
 Fpart also includes a live mode, which allows it to crawl very large
 filesystems and produce partitions in live. Hooks are available to act on
 those partitions  (e.g. immediatly start a transfer using rsync(1)) without
 having to wait for the filesystem traversal job to be finished. Used this way,
 fpart can be seen as a powerful data migration tool.

Bug#911247: geeqie: Moving symlink to image crashes geeqie

[Wojciech Muła]

Package: geeqie
Version: 1:1.4+git20180925-1
Severity: important

Dear Maintainer,

How to reproduce:

1. Providing there's file.jpg, create symbolic link in the same directory

ln -s file.jpg link.jpg

2. Open geeqie and navigate to link.jpg (geeqie displays image correctly).
3. Right click on the link.jpg, select "copy file" and copy the file
   to **another device**.
4. Geeqie crashes. When run from a console, it prints error messages,
   I noted two different: "corrupted double-linked list" and something
   about double free (sorry, lost the exact copy).

In my case links are located on an external disc, and I'm trying to copy
them to my home directory, which is mounted on a local hard drive.
When I copy links within the same device, everything works!


best regards
Wojciech Muła

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
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)

Versions of packages geeqie depends on:
ii  geeqie-common1:1.4+git20180925-1
ii  libatk1.0-0  2.26.1-3
ii  libc62.27-2
ii  libcairo21.15.8-3
ii  libexiv2-14  0.25-3.1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-1
ii  libgcc1  1:8-20180425-1
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.3-2
ii  libgtk2.0-0  2.24.32-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-1
ii  liblirc-client0  0.10.0-2+b1
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpangoft2-1.0-01.40.14-1
ii  libstdc++6   8-20180425-1
ii  libtiff5 4.0.9-3
ii  sensible-utils   0.0.11

Versions of packages geeqie recommends:
pn  cups-bsd | lpr   
ii  exiftran 2.10-2+b3
ii  exiv20.25-3.1
ii  imagemagick  8:6.9.7.4+dfsg-16
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-16
ii  librsvg2-common  2.40.20-2
ii  ufraw-batch  0.22-2
pn  zenity   

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.8.20-1.1
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.2-2+b1
pn  ufraw
pn  xpaint   

-- no debconf information

Bug#911245: ITP: libvma -- libvma is a LD_PRELOAD-able library that boosts performance

[Talat Batheesh]

Package: wnpp
Severity: wishlist
Owner: Talat Batheesh 

* Package name: libvma
  Version : 8.7.1
  Upstream Author : Liran Oz 
* URL : https://github.com/Mellanox/libvma
* License : GPLv2 and BSD
  Programming Lang: C, C++
  Description : libvma is a LD_PRELOAD-able library that boosts performance

libvma is a LD_PRELOAD-able library that boosts performance of TCP and UDP 
traffic.
It allows application written over standard socket API to handle fast path data
traffic from user space over Ethernet and/or Infiniband with full network stack
bypass and get better throughput, latency and packets/sec rate.

No application binary change is required for that.
libvma is supported by RDMA capable devices that support "verbs" 
IBV_QPT_RAW_PACKET QP for Ethernet and/or IBV_QPT_UD QP for IPoIB.

Bug#911233: ossim FTCBFS: multiple reasons

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Helmut,

On 10/17/18 3:04 PM, Helmut Grohne wrote:
> In any case, the combination of upstream.patch and rules.patch make
> ossim cross buildable. Please do something useful with them.

Thanks for the patches, they've been applied in git and a new upload to
unstable will follow shortly.

I've also forwarded this issue upstream, in the hope that they will fix
the various CMake issues so that we can drop the workaround in the rules
file.

Kind Regards,

Bas

Bug#911195: dxvk packaging progress

[Alexandre Viau]

Hello!

If you are interested in my progress, the packaging can be found here:
 - https://salsa.debian.org/aviau/dxvk

The package works but it still uses the embedded libraries.

The embedded libraries are built for Windows (I think?) so we would have
to rebuild them as part of the build process or modify their
corresponding packages to also ship these libs.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#911215: kmail: Cannot disable HTML-switcher in Messagewindow any more

[Hans-J. Ullrich]

Package: kmail
Version: 4:18.08.1-1
Followup-For: Bug #911215

Dear Maintainer,

I believe, this issue is caused by the long text in the html-switcher. In 
German (I am using a German environment) there is "HTML Nacxhricht" and "Keine 
HTML Nachricht" which is a long text and makes the bar very long.

An idea is either to shorten the text (i.e. "HTML" and "Kein HTML") or even 
completely left. If you decide to remove the text, its status might be shown 
with decent coulours (red and green?). Also a button IMO might be a good 
alternative.

I do not know, but I believe, there are more people than me, which are alo 
usimg a netbook with its low resolution and get into the same issue.

Thank you for reading this an your great work!

Best regards

Hans
 


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.18.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 kmail depends on:
ii  akonadi-server   4:18.08.1-1
ii  kdepim-runtime   4:18.08.1-1
ii  kio  5.49.0-1
ii  libc62.27-6
ii  libgcc1  1:8.2.0-7
ii  libgpgmepp6  1.11.1-2
ii  libkf5akonadiagentbase5  4:18.08.1-1
ii  libkf5akonadicontact54:18.08.1-1
ii  libkf5akonadicore5abi2   4:18.08.1-1
ii  libkf5akonadimime5   4:18.08.1-2
ii  libkf5akonadisearch-bin  4:18.08.1-1
ii  libkf5akonadisearch-plugins  4:18.08.1-1
ii  libkf5akonadisearchdebug54:18.08.1-1
ii  libkf5akonadisearchpim5  4:18.08.1-1
ii  libkf5akonadiwidgets5abi14:18.08.1-1
pn  libkf5bookmarks5 
ii  libkf5calendarcore5abi2  4:18.08.1-1
ii  libkf5calendarutils5 4:18.08.1-1
pn  libkf5codecs5
pn  libkf5completion5
pn  libkf5configcore5
ii  libkf5configgui5 5.49.0-1
ii  libkf5configwidgets5 5.49.0-1
ii  libkf5contacts5  4:18.08.1-1
ii  libkf5coreaddons55.49.0-1
ii  libkf5crash5 5.49.0-1
ii  libkf5dbusaddons55.49.0-1
ii  libkf5followupreminder5  4:18.08.1-1
ii  libkf5grantleetheme-plugins  18.08.1-1
ii  libkf5gravatar5abi2  4:18.08.1-1
ii  libkf5guiaddons5 5.49.0-1
ii  libkf5i18n5  5.49.0-1
ii  libkf5iconthemes55.49.0-1
ii  libkf5identitymanagement518.08.1-1
ii  libkf5itemmodels55.49.0-1
ii  libkf5itemviews5 5.49.0-1
ii  libkf5jobwidgets55.49.0-1
ii  libkf5kcmutils5  5.49.0-1
ii  libkf5kiocore5   5.49.0-1
ii  libkf5kiofilewidgets55.49.0-1
ii  libkf5kiowidgets55.49.0-1
ii  libkf5kontactinterface5  18.08.1-1
ii  libkf5ksieveui5  4:18.08.1-1
ii  libkf5libkdepim-plugins  4:18.08.1-1
ii  libkf5libkdepim5 4:18.08.1-1
ii  libkf5libkdepimakonadi5  4:18.08.1-1
ii  libkf5libkleo5   4:18.08.1-1
ii  libkf5mailcommon5abi24:18.08.1-1
ii  libkf5mailtransport5 18.08.1-2
ii  libkf5mailtransportakonadi5  18.08.1-2
ii  libkf5messagecomposer5abi1   4:18.08.1-1
ii  libkf5messagecore5abi1   4:18.08.1-1
ii  libkf5messagelist5abi1   4:18.08.1-1
ii  libkf5messageviewer5abi1 4:18.08.1-1
ii  libkf5mime5abi1  18.08.1-1
ii  libkf5mimetreeparser5abi14:18.08.1-1
ii  libkf5notifications5 5.49.0-1
ii  libkf5notifyconfig5  5.49.0-1
ii  libkf5parts5 5.49.0-1
ii  libkf5pimcommon5abi2 4:18.08.1-1
ii  libkf5pimcommonakonadi5abi1  4:18.08.1-1
ii  libkf5pimtextedit5abi2   18.08.1-1
ii  libkf5sendlater5 4:18.08.1-1
ii  libkf5service-bin5.49.0-1
ii  libkf5service5   5.49.0-1
ii  libkf5sonnetui5  5.49.0-1
ii  libkf5templateparser54:18.08.1-1
ii  libkf5textwidgets5   5.49.0-1
ii  libkf5tnef5  4:18.08.1-1
ii  libkf5wallet-bin 5.49.0-1
ii  libkf5wallet55.49.0-1
ii  libkf5webengineviewer5abi1   4:18.08.1-1
ii  libkf5widgetsaddons5 5.49.0-1
ii  libkf5windowsystem5  5.49.0-1
ii  libkf5xmlgui55.49.0-1
ii  libqgpgme7   1.11.1-2
ii  libqt5core5a 5.11.1+dfsg-9
ii  libqt5dbus5  5.11.1+dfsg-9
ii  libqt5gui5   5.11.1+dfsg-9
ii  libqt5network5   5.11.1+dfsg-9
ii  libqt5widgets5   5.11.1+dfsg-9
ii  libqt5xml5   5.11.1+dfsg-9
ii  libstdc++6   8.2.0-7

Versions of packages kmail recommends:
ii  accountwizard   4:18.08.1-1
ii  gnupg   2.2.10-3
ii  kdepim-addons   18.08.1-1
ii  kdepim-themeeditors 

Bug#911244: stretch-pu: package publicsuffix/20181003.1334-0+deb9u1

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 publicsuffix

Please consider an update to publicsuffix in debian stretch.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the version currently in stretch-proposed-updates is
attached.

This proposed release is also available at the
"publicsuffix_debian/20181003.1334-0+deb9u1" tag on the "debian/stretch" branch 
at
the git repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to stretch.



publicsuffix_20180523.2326-0+deb9u1_20181003.1334-0+deb9u1.debdiff.gz
Description: application/gzip

Bug#911240: festvox-ca-ona-hts: Weird 'copyright' sound at the beginning of synthesised speech

[Sergio Oller]

Dear Francis,

Festival does not support UTF-8. You should send the text to festival with
ISO-8859-15 encoding.

The accented character ò is represented by two bytes in UTF-8. Festival
interprets those two bytes as two ISO-8859-15 characters, one of them being
the copyright symbol.

That's why you are hearing "copyright".

You can probably use iconv to do the character encoding conversion.

Best
Sergio

El dc., 17 d’oct. 2018, 16:51, Francis Tyers  va
escriure:

> Package: festvox-ca-ona-hts
> Version: 1.3-2
> Severity: important
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> I installed festvox-ca-ona-hts
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> I ran:
>
> $ echo "això és una prova" | festival --tts --language catalan
>
>
>* What was the outcome of this action?
>
> It said "A ix copyright és una prova"
>
>* What outcome did you expect instead?
>
> It should say "això és una prova"
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8),
> LANGUAGE=ca_AD.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages festvox-ca-ona-hts depends on:
> ii  festival 1:2.5.0-2
> ii  festival-ca  3.0.6-1
>
> festvox-ca-ona-hts recommends no packages.
>
> festvox-ca-ona-hts suggests no packages.
>
> -- no debconf information
>

Bug#911243: ITP: sockperf -- Network benchmarking utility for testing latency and throughput

[Talat Batheesh]

Package: wnpp
Severity: wishlist
Owner: Talat Batheesh 

* Package name: sockperf
  Version : 3.5.0
  Upstream Author : Liran Oz 
* URL : https://github.com/Mellanox/sockperf
* License : BSD
  Programming Lang: C, C++
  Description : Network benchmarking utility for testing latency and 
throughput

sockperf is a network benchmarking utility over socket API that was 
designed for testing performance (latency and throughput) of 
high-performance systems (it is also good for testing performance of 
regular networking systems as well). It covers most of the socket API 
calls and options.
Specifically, in addition to the standard throughput tests, sockperf, 
does the following:

Measure latency of each discrete packet at sub-nanosecond  
resolution (using TSC register that counts CPU ticks with very  low 
overhead).

* Does the above for both ping-pong mode and for latency under  load 
mode. This means that we measure latency of single packets  even under 
load of millions Packets Per Second (without waiting  for reply of 
packet before sending subsequent packet on time)

* Enable spike analysis by providing histogram, with various  
percentiles of the packets' latencies (for example: median, min,  max, 
99% percentile, and more), (this is in addition to average  and 
standard deviation). Also, sockperf provides full log with  all 
packet's tx/rx times that can be further analyzed with  external 
tools, such as MS-Excel or matplotlib - All this  without affecting 
the benchmark itself.

* Support MANY optional settings for good coverage of socket API  and 
network configurations, while still keeping very low  overhead in the 
fast path to allow cleanest results.

Bug#826994: [Pkg-zfsonlinux-devel] Bug#826994: Devuan Compatibility

[Petter Reinholdtsen]

[Chris Dos]
> If this patch gets applied,

I believe the point Aron is trying to get through to those of you who
care about init.d scripts, is that you should work with the upstream
project to get the scripts included there, to avoid having the Debian
packages deviate from upstream any more.

In other words, you are barking up the wrong tree.  Try the upstream
tree, it might work better.

-- 
Happy hacking
Petter Reinholdtsen