Bug#931568:

2019-09-15 Thread Spielwarenkontor
Ok, could temp solve it bydowngrade fetchmail to stretch version.

vi /etc/apt/sources.list
#add 
deb http://ftp.de.debian.org/debian/ stretch main non-free contrib
deb-src http://ftp.de.debian.org/debian/ stretch main non-free contrib

apt-get update
apt-get install fetchmail/stretch




Bug#925518: Bug#932817: Sponsored Post Collaboration - planet.ubuntu.com

2019-09-15 Thread Thomas Dettbarn


 
 
  
   Yeah.. i am looking for a sponsor for my awesome package that us gathering dust at mentors.devian.net...  
  
  
   
  
  
   ;)
  
  
   
  
  
   https://mentors.debian.net/package/dmagnetic
   
  
  
   
  
  
   Who else?
  
  
   Jason Turner  hat am 15. September 2019 um 15:35 geschrieben: 
   
   
   
Hello,
Jason here from Source Global Media  - We are a reputed Digital Marketing Agency working with variety of clients from UK, USA,  France, Greece, Finland, Germany and Spain
We are interested in developing partnerships with companies / webmaster such as yourself to check if you can publish sponsored content for our clients on your website i.e. - planet.ubuntu.com
If you can publish sponsored content on  planet.ubuntu.com  , please email us information with prices.
Looking forward to start the business with you.
Best regards,


 
  
   

  
 

   
  
 

   
   
  
  
    
   
 




Bug#918375: Info received (dockerd segfaults can be repeated)

2019-09-15 Thread Hans Freitag
I migrated one of my problematic servers over to buster + docker-ce it
looks very promising:

My mastodon service is running for over 2  hours including its
healthchecks enabled. It never made that much.


So to sum things up: there is something differnt with  the docker.io
package's swarm mode

that causing dockerd to segfault.


regards

 Hans



pEpkey.asc
Description: application/pgp-keys


Bug#937677: python-css-parser: Python2 removal in sid/bullseye

2019-09-15 Thread Nicholas D Steeves
Control: affects 936270 + src:python-css-parser
Control: user debian-pyt...@lists.debian.org , usertags -1 py2keep
Justification: popcon of 4249

Hi Mattias,

On Fri, Aug 30, 2019 at 07:38:00AM +, Matthias Klose wrote:
> Package: src:python-css-parser
> Version: 1.0.4-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
>

Would you please not use maintonly?  I didn't receive an email for
this bug, even though I'm subscribed to the team mailing list listed
as the maintainer, and I believe being purposefully cut out of the
loop like this will provoke drama with other maintainers.  There have
already been a few such threads (eg: didn't receive a notification
until my package was removed from unstable).  Best to avoid having
people feel like they're being manipulated and/or covertly bullied, I
think.  We're supposed to be the "good guys" after all ;-)

> - If the package has still many users (popcon >= 300), or is needed to
>   build another package which cannot be removed, document that by
>   adding the "py2keep" user tag (not replacing the py2remove tag),
>   using the debian-pyt...@lists.debian.org user.  Also any
>   dependencies on an unversioned python package (python, python-dev)
>   must not be used, same with the python shebang.  These have to be
>   replaced by python2/python2.7 dependencies and shebang.
> 
>   This is the least preferred option.
>

This package was packaged as a dep for Calibre.  I will hope for
Calibre's upstream success in the 2to3 migration.  BTW, it sounds like
Python 3 is planned for installtion to /usr/bin/python.  Is that the
case?


Cheers,
Nicholas


signature.asc
Description: PGP signature


Bug#936630: gnumed-client: py3 available upstream

2019-09-15 Thread Karsten Hilbert
Package: gnumed-client
Version: 1.7.7+dfsg-1
Followup-For: Bug #936630

Upstream (me) has py3 support available but it needs to be
polished and released.

Karsten

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 
'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 5.2.0-2-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages gnumed-client depends on:
ii  aspell   0.60.7~20110707-6
ii  file 1:5.35-4
ii  gnumed-common1.7.7+dfsg-1
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  ispell   3.4.00-6+b1
ii  python   2.7.16-1
ii  python-egenix-mxdatetime 3.2.9-1
ii  python-enchant   2.0.0-1
ii  python-gnuplot   1.8-6
ii  python-hl7   0.3.4-3
ii  python-httplib2  0.11.3-2
ii  python-pip   18.1-5
ii  python-wxgtk3.0  3.0.2.0+dfsg-8
ii  python3-hl7 [python-hl7] 0.3.4-3
ii  texlive-latex-base   2018.20190227-2

Versions of packages gnumed-client recommends:
ii  aeskulap0.2.2-beta2+git20180219.8787e95-2
ii  amide   1.0.5-12+b1
ii  audiofile-tools 0.3.6-5
ii  chktex  1.7.6-2+b1
ii  dcmtk   3.6.4-2.1
ii  elinks [www-browser]0.13~20190125-3
ii  extract 1:1.8-2
ii  firefox [www-browser]   69.0-1
ii  freediams   0.9.4-2
ii  ginkgocadx  3.8.8-1
ii  gnumed-doc  1.7.7+dfsg-1
ii  gtklp   1.3.1-0.1+b1
ii  konqueror [www-browser] 4:18.12.0-1
ii  lacheck 1.26-17
ii  libimage-exiftool-perl  11.16-1
ii  libreoffice-writer  1:6.1.5-3+deb10u4
ii  ntp 1:4.2.8p12+dfsg-4
pn  pdftk   
ii  poppler-utils   0.71.0-5
ii  printer-driver-cups-pdf [cups-pdf]  3.0.1-5
ii  python-faulthandler 3.0-1
ii  python-pyqrcode 1.2.1-2
ii  python-vobject  0.9.6.1-0.1
ii  qpdf8.4.0-2
ii  texlive-latex-extra 2018.20190227-2
ii  texlive-latex-recommended   2018.20190227-2
ii  w3m [www-browser]   0.5.3-37
ii  wgerman-medical 20160103-3
ii  xdg-utils   1.1.3-1
ii  xmedcon 0.16.1+dfsg-1
ii  xsane   0.999-6+b1

Versions of packages gnumed-client suggests:
pn  autokey-qt | autokey-gtk
ii  edfbrowser  1.67+dfsg-1
ii  entangle2.0-1
pn  gimp | kolourpaint4 
ii  gnumed-server   22.5-1
ii  incron  0.5.12-1
pn  konsolekalendar 
pn  korganizer  
ii  libchipcard-tools   5.1.0beta-3
ii  nvram-wakeup1.1-4+b1
ii  pgadmin31.22.2-5
pn  python-uno  
ii  qrisk2  0.1.20150729-4
pn  shutdown-at-night   
pn  wakeonlan | etherwake | gwakeonlan  

-- no debconf information



Bug#940331: org_kde_powerdevil crashed with SIGSEGV in __GI_raise()

2019-09-15 Thread giovanni . alberotanza
Package: powerdevil
Version: 4:5.14.5-1


=

ProblemType: Crash
Architecture: amd64
CrashCounter: 1
CurrentDesktop: KDE
Date: Sun Sep 15 22:46:38 2019
Dependencies:
 adduser 3.118
 adwaita-icon-theme 3.30.1-1
 apt 1.8.2
 apt-utils 1.8.2
 aspell 0.60.7~20110707-6
 aspell-en 2018.04.16-0-1
 at-spi2-core 2.32.1-1~bpo10+1 [origin: Debian Backports]
 ca-certificates 20190110
 coreutils 8.30-3
 cpp 4:8.3.0-1
 cpp-8 8.3.0-6
 dbus 1.12.16-1
 dconf-gsettings-backend 0.30.1-2
 dconf-service 0.30.1-2
 debconf 1.5.71
 debconf-i18n 1.5.71
 debian-archive-keyring 2019.1
 dictionaries-common 1.28.1
 dirmngr 2.2.17-3~bpo10+2 [origin: Debian Backports]
 dmsetup 2:1.02.155-3
 dpkg 1.19.7
 emacsen-common 3.0.4
 fdisk 2.33.1-0.1
 fontconfig 2.13.1-2
 fontconfig-config 2.13.1-2
 fonts-dejavu-core 2.37-1
 gcc-8-base 8.3.0-6
 glib-networking 2.58.0-2
 glib-networking-common 2.58.0-2
 glib-networking-services 2.58.0-2
 gnupg 2.2.17-3~bpo10+2 [origin: Debian Backports]
 gnupg-l10n 2.2.17-3~bpo10+2 [origin: Debian Backports]
 gnupg-utils 2.2.17-3~bpo10+2 [origin: Debian Backports]
 gpg 2.2.17-3~bpo10+2 [origin: Debian Backports]
 gpg-agent 2.2.17-3~bpo10+2 [origin: Debian Backports]
 gpg-wks-client 2.2.17-3~bpo10+2 [origin: Debian Backports]
 gpg-wks-server 2.2.17-3~bpo10+2 [origin: Debian Backports]
 gpgconf 2.2.17-3~bpo10+2 [origin: Debian Backports]
 gpgsm 2.2.17-3~bpo10+2 [origin: Debian Backports]
 gpgv 2.2.17-3~bpo10+2 [origin: Debian Backports]
 gsettings-desktop-schemas 3.28.1-1
 gtk-update-icon-cache 3.24.5-1
 hicolor-icon-theme 0.17-2
 hunspell-en-us 1:2018.04.16-1
 init-system-helpers 1.56+nmu1
 kactivities-bin 5.54.0-1
 kactivitymanagerd 5.14.5-1
 kio 5.54.1-1
 krb5-locales 1.17-3
 kwayland-data 4:5.54.0-1
 kwayland-integration 5.14.5-1
 liba52-0.7.4 0.7.4-19
 libaa1 1.4p5-46
 libaacs0 0.9.0-2
 libacl1 2.2.53-4
 libaom0 1.0.0-3
 libapparmor1 2.13.2-10
 libapt-inst2.0 1.8.2
 libapt-pkg5.0 1.8.2
 libarchive13 3.3.3-4
 libargon2-1 0~20171227-0.2
 libaribb24-0 1.0.3-2
 libasound2 1.1.8-1
 libasound2-data 1.1.8-1
 libaspell15 0.60.7~20110707-6
 libass9 1:0.14.0-2
 libassuan0 2.5.2-1
 libasyncns0 0.8-6
 libatk-bridge2.0-0 2.32.0-2~bpo10+1 [origin: Debian Backports]
 libatk1.0-0 2.32.0-2~bpo10+1 [origin: Debian Backports]
 libatk1.0-data 2.32.0-2~bpo10+1 [origin: Debian Backports]
 libatspi2.0-0 2.32.1-1~bpo10+1 [origin: Debian Backports]
 libattr1 1:2.4.48-4
 libaudit-common 1:2.8.4-3
 libaudit1 1:2.8.4-3
 libauthen-sasl-perl 2.1600-1
 libavahi-client3 0.7-4+b1
 libavahi-common-data 0.7-4+b1
 libavahi-common3 0.7-4+b1
 libavc1394-0 0.5.4-5
 libavcodec58 7:4.1.4-1~deb10u1
 libavformat58 7:4.1.4-1~deb10u1
 libavutil56 7:4.1.4-1~deb10u1
 libbasicusageenvironment1 2018.11.26-1.1
 libbdplus0 0.1.2-3
 libblkid1 2.33.1-0.1
 libbluray2 1:1.1.0-1
 libbsd0 0.9.1-2
 libbz2-1.0 1.0.6-9.2~deb10u1
 libc6 2.28-10
 libcaca0 0.99.beta19-2.1
 libcairo-gobject2 1.16.0-4
 libcairo2 1.16.0-4
 libcap-ng0 0.7.9-2
 libcap2 1:2.25-2
 libcddb2 1.3.2-6
 libchromaprint1 1.4.3-3
 libcodec2-0.8.1 0.8.1-2
 libcolord2 1.4.3-4
 libcom-err2 1.45.3-3~bpo10+1 [origin: Debian Backports]
 libcroco3 0.6.12-3
 libcryptsetup12 2:2.1.0-5+deb10u2
 libcrystalhd3 1:0.0~git20110715.fdd2f19-13
 libcups2 2.2.10-6+deb10u1
 libdata-dump-perl 1.23-1
 libdatrie1 0.2.12-2
 libdb5.3 5.3.28+dfsg1-0.5
 libdbus-1-3 1.12.16-1
 libdbusmenu-qt5-2 0.9.3+16.04.20160218-1
 libdc1394-22 2.2.5-1
 libdca0 0.0.6-1
 libdconf1 0.30.1-2
 libdevmapper1.02.1 2:1.02.155-3
 libdouble-conversion1 3.1.0-3
 libdrm-amdgpu1 2.4.97-1
 libdrm-common 2.4.97-1
 libdrm-intel1 2.4.97-1
 libdrm-nouveau2 2.4.97-1
 libdrm-radeon1 2.4.97-1
 libdrm2 2.4.97-1
 libdvbpsi10 1.3.2-1
 libdvdnav4 6.0.0-1
 libdvdread4 6.0.1-1
 libebml4v5 1.3.6-2
 libedit2 3.1-20181209-1
 libegl-mesa0 18.3.6-2
 libegl1 1.1.0-1
 libelf1 0.176-1.1
 libencode-locale-perl 1.05-1
 libepoxy0 1.5.3-0.1
 libevdev2 1.6.0+dfsg-1
 libexpat1 2.2.6-2
 libfaad2 2.8.8-3
 libfdisk1 2.33.1-0.1
 libffi6 3.2.1-9
 libfile-basedir-perl 0.08-1
 libfile-desktopentry-perl 0.22-1
 libfile-listing-perl 6.04-1
 libfile-mimeinfo-perl 0.29-1
 libflac8 1.3.2-3
 libfont-afm-perl 1.20-2
 libfontconfig1 2.13.1-2
 libfontenc1 1:1.1.3-1+b2
 libfreetype6 2.9.1-3
 libfribidi0 1.0.5-3.1
 libgbm1 18.3.6-2
 libgcc1 1:8.3.0-6
 libgcrypt20 1.8.4-5
 libgdbm-compat4 1.18.1-4
 libgdbm6 1.18.1-4
 libgdk-pixbuf2.0-0 2.38.1+dfsg-1
 libgdk-pixbuf2.0-bin 2.38.1+dfsg-1
 libgdk-pixbuf2.0-common 2.38.1+dfsg-1
 libgl1 1.1.0-1
 libgl1-mesa-dri 18.3.6-2
 libglapi-mesa 18.3.6-2
 libgles2 1.1.0-1
 libglib2.0-0 2.58.3-2+deb10u1
 libglib2.0-data 2.58.3-2+deb10u1
 libglvnd0 1.1.0-1
 libglx-mesa0 18.3.6-2
 libglx0 1.1.0-1
 libgme0 0.6.2-1
 libgmp10 2:6.1.2+dfsg-4
 libgnutls30 3.6.7-4
 libgomp1 8.3.0-6
 libgpg-error-l10n 1.35-1
 libgpg-error0 1.35-1
 libgpgme11 1.12.0-6
 libgpgmepp6 1.12.0-6
 libgpm2 1.20.7-5
 libgraphite2-3 1.3.13-7
 libgroupsock8 2018.11.26-1.1
 libgsm1 1.0.18-2
 libgssapi-krb5-2 1.17-3
 libgtk-3-0 3.24.5-1
 libgtk-3-bin 3.24.5-1
 libgtk-3-common 

Bug#940019: cups: No more options for remote shared printers

2019-09-15 Thread Vincent Danjean
Le 15/09/2019 à 19:47, Brian Potkin a écrit :
> On Sat 14 Sep 2019 at 21:05:24 +0200, Vincent Danjean wrote:
>> I'm under the impression that my server does not give all available
>> options of the server PPD, so it would explain why the generated
>> ppd is so poor.
> 
> The attributes file has
> 
>   > sides-supported (keyword) = one-sided
> 
> There isn't any two-sided printing on offer from the Brother PPD on the
> server. In other words, CUPS (and cups-browsed) cannot generate a PPD
> with two-sided printing in it because it cannot see such an option in
> the Brother PPD. The question is - why cannot this option be seen?
> 
> (media-source-supported and media-type-supported are also absent from
> your attributes file).
> 
> Please look at the Paper Feed section of the Brother PPD. You will see
> the keyword "BRInputSlot". This is non-standard and unknown to the Adobe
> PPD specification. The correct keyword is "InputSlot". CUPS will see and
> act on InputSlot but not on BRInputSlot. If you remove all the BRs in
> this section, cups-browsed (remember, it is based on the PPD generator
> of CUPS) will produce a PPD with InputSlot available. The same is true
> of the Duplex and Media Type sections of the Brother PPD.
> 
> So there you have it. The issue was on the server after all and not due
> to the Debian printing system. This is definitely a valid reason to
> close the report. 

I know for a long time that brother is not using standard name for
standard options, so I've to look at the "Advanced" tab in cups
dialogs to change options that should be available in the main tabs.
I even started to change the PPD to make it using "ggod names" where
possible (and adapt the cups-wrapper-driver to hide this change to
the binary driver) but never finished this work (lack of time).

  However, the PPD also offered specific options that are probably
not standardized (hence the existence of the "Advanced" tab in cups
dialogs). All of them disappear with the current cups system. The
current cups/cups-browsed in unstable are totally unusable for me
on my laptop. I have to bypass them totally (CUPS_SERVER, ...) to
be able to send data with options I want (staples for canon, ...).

> If you envisage upstream CUPS dealing with and catering for this rogue,
> non-free PPD, you need to read
> 
> https://lists.cups.org/pipermail/cups-devel/2016-January/016729.html

I fully understand (and support) that cups must not try to interpret
non-standard options as a replacement for standard options (and keep
them in the "Advanced" tab).
  I totally disagree that the current cups (seems to) makes all
non-standard options to disappear.

  Regards,
Vincent



Bug#940328: O: keepassx -- Cross Platform Password Manager

2019-09-15 Thread Giovani Augusto Ferreira
Package: wnpp
Severity: normal

Hi,

I intend to orphan the keepassx package.

After trying to contact Diego Sarzi privately and considering that Shengjing
Zhu tried it too via #874950, I am orphaning keepassx again.

I sponsored Diego on an upload for keepassx during DebConf19 and I thought he
would be able to keep it updated.

Keepassx is a great software with high popcorn and it needs due attention.

Regards,

Giovani



Bug#940330: libsnappy-dev: objects in libsnappy-shared.a need to be compiled with -fPIC on hppa

2019-09-15 Thread John David Anglin
Package: libsnappy-dev
Version: 1.1.7-1
Severity: normal

Dear Maintainer,

The apitrace package fails to build on hppa with the following error:

[ 99%] Linking CXX shared library egltrace.so
cd /<>/obj-hppa-linux-gnu/wrappers && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/egltrace.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden 
-std=gnu++11 -Wall -Wno-sign-compare -fno-strict-aliasing -fno-rtti 
-fno-exceptions -fmessage-length=0 -fno-omit-frame-pointer  
-Wl,--version-script=/<>/wrappers/egltrace.version  -static-libgcc 
-static-libstdc++ -Wl,-Bsymbolic -Wl,-Bsymbolic-functions -Wl,-z,defs -shared 
-Wl,-soname,egltrace.so -o egltrace.so CMakeFiles/egltrace.dir/egltrace.cpp.o 
CMakeFiles/egltrace.dir/dlsym.cpp.o libgltrace_common.a 
../dispatch/libglproc_egl.a -lpthread -ldl ../helpers/libglhelpers.a libtrace.a 
../lib/trace/libcommon.a ../lib/highlight/libhighlight.a ../lib/os/libos.a 
-lbacktrace ../thirdparty/brotli/libbrotli_dec.a 
../thirdparty/brotli/libbrotli_common.a ../lib/guids/libguids.a 
../thirdparty/crc32c/libcrc32c.a -Wl,-Bstatic -lsnappy-shared 
../dispatch/libglproc.a -Wl,-Bdynamic -ldl 
/usr/bin/ld: 
/usr/lib/gcc/hppa-linux-gnu/9/../../../hppa-linux-gnu/libsnappy-shared.a(snappy.cc.o):
 relocation R_PARISC_DPREL21L can not be used when making a shared object; 
recompile with -fPIC
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.32.51.20190909 internal error, 
aborting at ../../bfd/elf32-hppa.c:3954 in elf32_hppa_relocate_section

/usr/bin/ld: Please report this bug.

collect2: error: ld returned 1 exit status

See the following log for full build:
https://buildd.debian.org/status/fetch.php?pkg=apitrace=hppa=8.0%2Brepack-1=1568579337=0

See the following for latest snappy build:
https://buildd.debian.org/status/fetch.php?pkg=snappy=hppa=1.1.7-1%2Bb1=1568571052=0

Regards,
Dave Anglin

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Versions of packages libsnappy-dev depends on:
ii  libsnappy1v5  1.1.7-1

libsnappy-dev recommends no packages.

libsnappy-dev suggests no packages.

-- no debconf information



Bug#935928: RFS: assaultcube-data/1.2.0.2.1-4 -- data files and documentation for AssaultCube

2019-09-15 Thread Tobias Frost
Control: tags -1 moreinfo

Hi Carlos,

(After your last mail I'm not sure if you are still working in the
package, if not please let us know to get the metadata right)

Nethertheless, as assaultcube-data is now in a limbo state, and needs an
upload so that the package can be actually be used, a review:

d/changelog:
 - debian revisions -3 was never uploaded, it cannot be marked as
   uploaded to sid. So you have now two options
   - join the entries for -3 and -4 and release them as -3
   - mark the entries for -3 as UNRELEASED.
  (The first option is preferred.)
 - the changelog entry for -4… There is no change on the "Suggests"
   part?

Regarding #935669… I don't thnk your update of the breaks/replaces stancas
will fix this. First, the bug is because the (non-free) package has been
uploaded source only, second, the breaks/replace's purpose is a
different one:
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-in-other-packages
It was likely introduced because of that, but the version is so old that
it could be removed now. (As said, #935669 is a different issue)
To ensure that assaultcube is also updated, a simple Breaks:
assaultcube ( << 1.2.0.2) should do it, but the games packages I've checked
do not bother with that, so probably it can be left as it; It just needs
to be properly uploaded or marked as builddable on the buildds.

d/watch does not point to upsteam but to your own gitlab clone.
Please don't do that. You are NOT upstream and repacking is not a valid
reason to fork a project. (FTR, upstream is here:
https://github.com/assaultcube/AC)
This remark is also true for e.g. d/copyright and d/source/metadata)

-- 
tobi



signature.asc
Description: PGP signature


Bug#940311: merge with lockdown / security-misc?

2019-09-15 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2019-09-15 at 12:48 +, Patrick Schleizer wrote:
> Package: hardening-runtime
> Severity: wishlist
> X-Debbugs-CC: whonix-de...@whonix.org
> 
> We now have (at least) three very similar packages.
> 
> * https://packages.debian.org/buster/lockdown
> * https://packages.debian.org/buster/hardening-runtime
> * https://github.com/Whonix/security-misc
> 
Hi,

I'm not sure what security-misc exactly is but we try some coordination with
lockdown when I first filed an ITP (see #919226) but it didn't really go
anywhere.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1+cXMACgkQ3rYcyPpX
RFttNggAh7R+0+mnu9lEJH8IzqXpSxB30gnueRPrjVbxDyiThIoLVd/44hyJAi4f
8IK9sKPfIomu4pXb6FK1Smp92dEpnG7Fg+AhkPHxxkAtSFS4kop2AFh/lmS0f5yz
1g+DVMpr0HvToShKAL8H8CQjAbUxjPI4A9DbE/cUnvm0rUfXq2t8i5VyfQDK9JmS
7+Sxt9aUMUxp1eBUw9WNh/pA8/K5gJGvRHCW1bYPIqS54ITQIrDE1ZFkNHSQUq9p
x9pKHAsnAFjGGONqqe+KusgI6v/UfhDfM+fl5LHItYHhEE/Ui466GUB4tt5q3rn6
evcAFCIYDNAf6nd/NcC2aoOD71fFBg==
=PPny
-END PGP SIGNATURE-



Bug#874907: [hydrogen] Future Qt4 removal from Buster

2019-09-15 Thread Lisandro Damián Nicanor Pérez Meyer
Hi!

El dom., 15 sep. 2019 09:49, Jonas Smedegaard  escribió:

> Quoting Lisandro Damián Nicanor Pérez Meyer (2019-09-12 23:54:32)
> > On Thu, 12 Sep 2019 at 17:37, Lisandro Damián Nicanor Pérez Meyer
> >  wrote:
> > >
> > > On Mon, 30 Jul 2018 19:01:50 +0200 Reiner Herrmann 
> wrote:
> > > > Control: tags -1 + fixed-upstream
> > > >
> > > > The current upstream beta release supports Qt5.
> > > > https://github.com/hydrogen-music/hydrogen/releases/tag/1.0.0-beta1
> > >
> > > I'll see if I can tackle it during the weekend.
> >
> > Uuups, it uses cdbs. I'll prepare the NMU switching to dh. If this is
> > not wanted please say so as soon as possible :-)
>
> Thanks for the offer, but please don't if not familiar with CDBS.
>
> I want to migrate to short-form dh but want to to it cautiously.



Perfect! Please do not hesitate in asking for help if needed.


Bug#940329: (no subject)

2019-09-15 Thread Andreas Noteng
Package: wnpp
Severity: wishlist
Owner: Andreas Noteng 

* Package name: scantailor-advanced
  Version : 1.0.17~2019.08.16-1
  Upstream Author : 4lex4 <4le...@zoho.com> 
* URL : https://github.com/4lex4/scantailor-advanced/
* License : GPL3+
  Programming Lang: C++
  Description : Interactive post-processing tool for scanned pages

Scan Tailor is an interactive post-processing tool for scanned pages. It
performs operations such as page splitting, deskewing, adding/removing
borders, and others. You give it raw scans, and you get pages ready to be
printed or assembled into a PDF or DJVU file. Scanning, optical character
recognition, and assembling multi-page documents are out of scope of this
project.

The current scantailor package in Debain is removed from stable and
testing due to it blocking QT4-removal (#875176). The project is not
dead upstream, but development is going slow. Scantailor Advanced is a
fork that uses QT5, and also includes some extended features.



Bug#940330: Acknowledgement (libsnappy-dev: objects in libsnappy-shared.a need to be compiled with -fPIC on hppa)

2019-09-15 Thread John David Anglin
The symbolic link in the build isn't correct on hppa:

make[1]: Entering directory '/<>'
dh_install
ln -s /usr/lib/hppa-linux-gnu/libsnappy.a \

/<>/debian/libsnappy-dev/usr/lib/hppa-linux-gnu/libsnappy-shared.a

The objects in libsnappy.a aren't compiled with -fPIC.

Dave
-- 

John David Anglin  dave.ang...@bell.net



Bug#940437: RFA: golang-github-vitrun-qart

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello!

I'd like to find new maintainers for some of my packages because I have
had less time for Debian. I'd like to focus the small amount of time
that I have for Debian on other things.

For now, I intend to do my best to keep maintaining this package.
However, I will probably retitle this bug with the 'O:' prefix at some
point, indicating that I have orphaned it.

Feel free to upload a new version of the package and remove me from the
uploaders in debian/control.

Feel free to contact me with any questions. Also note that I always
willing to sponsor uploads!

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#940440: RFA: golang-github-zenazn-goji

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello!

I'd like to find new maintainers for some of my packages because I have
had less time for Debian. I'd like to focus the small amount of time
that I have for Debian on other things.

For now, I intend to do my best to keep maintaining this package.
However, I will probably retitle this bug with the 'O:' prefix at some
point, indicating that I have orphaned it.

Feel free to upload a new version of the package and remove me from the
uploaders in debian/control.

Feel free to contact me with any questions. Also note that I always
willing to sponsor uploads!

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#940439: RFA: golang-github-xlab-treeprint

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello!

I'd like to find new maintainers for some of my packages because I have
had less time for Debian. I'd like to focus the small amount of time
that I have for Debian on other things.

For now, I intend to do my best to keep maintaining this package.
However, I will probably retitle this bug with the 'O:' prefix at some
point, indicating that I have orphaned it.

Feel free to upload a new version of the package and remove me from the
uploaders in debian/control.

Feel free to contact me with any questions. Also note that I always
willing to sponsor uploads!

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#940438: RFA: golang-github-vjeantet-grok

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello!

I'd like to find new maintainers for some of my packages because I have
had less time for Debian. I'd like to focus the small amount of time
that I have for Debian on other things.

For now, I intend to do my best to keep maintaining this package.
However, I will probably retitle this bug with the 'O:' prefix at some
point, indicating that I have orphaned it.

Feel free to upload a new version of the package and remove me from the
uploaders in debian/control.

Feel free to contact me with any questions. Also note that I always
willing to sponsor uploads!

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#940443: RFA: golang-gopkg-errgo.v1

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello!

I'd like to find new maintainers for some of my packages because I have
had less time for Debian. I'd like to focus the small amount of time
that I have for Debian on other things.

For now, I intend to do my best to keep maintaining this package.
However, I will probably retitle this bug with the 'O:' prefix at some
point, indicating that I have orphaned it.

Feel free to upload a new version of the package and remove me from the
uploaders in debian/control.

Feel free to contact me with any questions. Also note that I always
willing to sponsor uploads!

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#939896: Two-finger touchpad scroll is broken in wxgtk3.0-gtk3 on wayland

2019-09-15 Thread Olly Betts
On Sat, Sep 14, 2019 at 06:47:10PM +0200, Gunter Königsmann wrote:
> 
> > With GTK3 you can probably work around this by forcing X11, e.g.:
> >
> > env GDK_BACKEND=x11 /usr/bin/app
> 
> For many applications that might be a valuable hint. But it causes
> hideous flicker, due to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934386.

If you insist on conflating all your bugs into one big bug ball that
just makes it more difficult to investigate, so it's less likely anyone
can help you solve any of them.

Ignoring other issues for now, does my suggestion actually address
*THIS* bug?  In other words, if run as above, does two-finger touchpad
scrolling work?

You haven't clearly said if it does or not, just that it doesn't solve
your flicker problem (which I wouldn't expect it to).  I can't easily
test touchpad scrolling as I don't have a touchpad.

Cheers,
Olly



Bug#940445: RFA: golang-gopkg-httprequest.v1

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello!

I'd like to find new maintainers for some of my packages because I have
had less time for Debian. I'd like to focus the small amount of time
that I have for Debian on other things.

For now, I intend to do my best to keep maintaining this package.
However, I will probably retitle this bug with the 'O:' prefix at some
point, indicating that I have orphaned it.

Feel free to upload a new version of the package and remove me from the
uploaders in debian/control.

Feel free to contact me with any questions. Also note that I always
willing to sponsor uploads!

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#940295: libeclipse-compare-java: circular dependency hell

2019-09-15 Thread Jochen Sprickerhof

Hi Bill,

thanks for the report. This was added in:

https://salsa.debian.org/java-team/eclipse-platform-text/commit/13e5456276b4159db659c1e603e085adbaa8fe66

I guess due to:

https://salsa.debian.org/java-team/eclipse-platform-text/blob/master/org.eclipse.ui.genericeditor/META-INF/MANIFEST.MF#L18

@Emmanuel: would it make sense to model the 'resolution:=optional' as
Recommends? Would that help?

Cheers Jochen


signature.asc
Description: PGP signature


Bug#939787: RFS: assaultcube/1.2.0.2.1-3 [ITA] -- realistic first-person-shooter

2019-09-15 Thread Tobias Frost
On Thu, Sep 12, 2019 at 09:12:30PM -0300, Carlos Donizete Froes wrote:
> Hi Tobias,
> 
> > This changelog entry does not really make sense / completly unclear.
> > Please be more concise. For the breaks+replace:
> > the changelog entry should answer the question "Why" not "what", it is
> > completly unclear what you want to archieve.
> 
> I forgot to complement when I was testing and correcting the package.
> 
> The reason for adding Breaks+Replaces is that in the previous package it was:
> 
> Breaks: assaultcube-data (<< 1.1.0.4+repack1)
> Replaces: assaultcube-data (<< 1.1.0.4+repack1)

(See #935928 why I think is likely not what you wanted)

> As the latest version of the package was "1.1.0.4+repack1-2.1",the 
> assaultcube-data "1.2.0.2.1-2" package was not found in my tests.
> 
> > the mentioned bug is the ITA, you should have closed that with the
> > previous upload. It is wrong to close it now, you need to close it with
> > interacting with the BTS.
> 
> I understand, this is my first package I want to adopt.

Understood, but you still need to interact with the BTS to close that bug…
Hint: You need to manually close the bug and set the fixed version
manually. See bts(1) and the BTS documentation.

> Thanks!
> 
> -- 
> ⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
> ⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
> ⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
> ⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780



Bug#931568: [Pkg-openssl-devel] Bug#931568:

2019-09-15 Thread Kurt Roeckx
On Sun, Sep 15, 2019 at 06:23:42PM +0200, Spielwarenkontor wrote:
> 
> Same here in Debian stable - just upgraded from stable stretch to the
> new stable buster and broke production fetchmail system.
> 
> client
> Sep 15 18:14:01 boark fetchmail[4250]: OpenSSL berichtete:
> error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small

This is clearly a different issue than the original bug report.
The problem here is that you're trying to connect to an insecure
server. See /usr/share/doc/libssl1.1/NEWS.Debian.gz for more
information.


Kurt



Bug#940300: RM: minetest-mod-torches -- RoM; obsolete and abandoned upstream

2019-09-15 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Julien,

On 15-09-2019 13:16, Julien Puydt wrote:
> I'm the package maintainer (within the Debian Games Team), and I'm
> proposing to drop it off Debian testing (and unstable, with another bug
> report).

Did you already file that bug? Than we can close this bug as testing
follows unstable automatically. If you haven't filed the bug, we can
reassign it to ftp.debian.org.

Paul



Bug#939549: sdaps: diff for NMU version 1.9.7-0.2

2019-09-15 Thread Boyuan Yang
Package: sdaps
Version: 1.9.7-0.1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for sdaps (versioned as 1.9.7-0.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru sdaps-1.9.7/debian/changelog sdaps-1.9.7/debian/changelog
--- sdaps-1.9.7/debian/changelog2019-09-03 11:00:23.0 -0400
+++ sdaps-1.9.7/debian/changelog2019-09-15 14:04:29.0 -0400
@@ -1,3 +1,14 @@
+sdaps (1.9.7-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Replace old build-dependency
+texlive-generic-recommended with texlive-plain-generic.
+(Closes: #940119)
+  * debian/patches: Add patch 0001 to make the build
+reproducible. (Patch already merged upstream) (Closes: #939549)
+
+ -- Boyuan Yang   Sun, 15 Sep 2019 14:04:29 -0400
+
 sdaps (1.9.7-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru sdaps-1.9.7/debian/control sdaps-1.9.7/debian/control
--- sdaps-1.9.7/debian/control  2019-08-20 14:31:23.0 -0400
+++ sdaps-1.9.7/debian/control  2019-09-15 14:00:36.0 -0400
@@ -25,7 +25,7 @@
  python3-setuptools,
  python3-zbar,
  texlive,
- texlive-generic-recommended,
+ texlive-plain-generic,
  texlive-latex-extra,
  texlive-latex-recommended,
  texlive-science,
@@ -54,7 +54,7 @@
  python3-pil,
  python3-reportlab,
  texlive,
- texlive-generic-recommended,
+ texlive-plain-generic,
  texlive-latex-extra,
  texlive-latex-recommended,
  texlive-science,
diff -Nru sdaps-1.9.7/debian/patches/0001-Make-the-build-reproducible.patch
sdaps-1.9.7/debian/patches/0001-Make-the-build-reproducible.patch
--- sdaps-1.9.7/debian/patches/0001-Make-the-build-reproducible.patch   1969-
12-31 19:00:00.0 -0500
+++ sdaps-1.9.7/debian/patches/0001-Make-the-build-reproducible.patch   2019-
09-15 14:04:22.0 -0400
@@ -0,0 +1,35 @@
+From: Chris Lamb 
+Date: Fri, 6 Sep 2019 09:28:51 +0100
+Subject: Make the build reproducible
+
+Whilst working on the Reproducible Builds effort [0] we noticed
+that sdaps could not be built reproducibly.
+
+This is because its "setup.py" iterated over the keys of a dictionary
+(to generate translations), an operation which, in Python, is
+nondeterministic.
+
+This was originally filed in Debian as #939549 [1].
+
+ [0] https://reproducible-builds.org/
+ [1] https://bugs.debian.org/939549
+
+Applied-Upstream: https://github.com/sdaps/sdaps/pull/182
+Signed-off-by: Chris Lamb 
+---
+ setup.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/setup.py b/setup.py
+index 018f632..9562ef4 100755
+--- a/setup.py
 b/setup.py
+@@ -132,7 +132,7 @@ class sdaps_build_i18n(build_i18n.build_i18n):
+ f.write('%\n\n')
+ f.write('\\ProvidesDictionary{translator-sdaps-
dictionary}{%s}\n\n' % name)
+ 
+-for key in keys:
++for key in sorted(keys):
+ if lang is not None:
+ k = "%s[%s]" % (key, lang)
+ else:
diff -Nru sdaps-1.9.7/debian/patches/series sdaps-1.9.7/debian/patches/series
--- sdaps-1.9.7/debian/patches/series   1969-12-31 19:00:00.0 -0500
+++ sdaps-1.9.7/debian/patches/series   2019-09-15 14:03:33.0 -0400
@@ -0,0 +1 @@
+0001-Make-the-build-reproducible.patch


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


Bug#932883: RFS: dmagnetic/0.16-1 [put in ITP, ITA, RC, NMU if applicable]

2019-09-15 Thread Adam Borowski
On Wed, Jul 24, 2019 at 08:30:49AM +0200, Thomas Dettbarn wrote:
>  * Package name: dmagnetic
>Version : 0.16-1
>Upstream Author : Thomas Dettbarn 
>  * URL : http://www.dettus.net/dMagnetic
>  * License : BSD-2clause
>Section : games

>   It builds those binary packages:
> dmagnetic - A Magnetic Scrolls Interpreter

Hi!
First, the big question: is there are freely licensed data for this
interpreter?  If not, the package will have to go into contrib rather than
main: it's a section for free stuff that requires non-free to function.

The package lacks build-depends on debhelper 12: you use compat 12 yet have
"Build-Depends: debhelper (>=9)".  Also, nowadays there's a better way to
express that: "Build-Depends: debhelper-compat (=12)".

The package installs LICENSE.txt (redundant with copyright) and README.txt
(redundant with the long desc of the package).

After having downloaded game data, I get no graphics.  The command
"graphics" switches between text only and text + a line with lightgray
background + a lot of empty space.  I've tried two games: "pawn" and
"guild", passing -gfx and -mag each time.

The .menu file is obsolete, most desktop environments don't support it
anymore, and those which do are hardly maintained.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.



Bug#940442: RFA: golang-go.uber-zap

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello!

I'd like to find new maintainers for some of my packages because I have
had less time for Debian. I'd like to focus the small amount of time
that I have for Debian on other things.

For now, I intend to do my best to keep maintaining this package.
However, I will probably retitle this bug with the 'O:' prefix at some
point, indicating that I have orphaned it.

Feel free to upload a new version of the package and remove me from the
uploaders in debian/control.

Feel free to contact me with any questions. Also note that I always
willing to sponsor uploads!

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#940283: Done

2019-09-15 Thread Thomas Goirand
Hi,

So, I've uploaded python-fixtures with Python 2 support removed.

Now, it looks like python-fastimport is part of a dependency chain for
BZR. Since, as I wrote, BZR is probably going to be removed from Debian,
I'm not sure if we should fix python-fastimport or just get it removed
from Debian as well (I'd vote for the later).

So, now we still have the problem to fix with python-daemon, which has,
as reverse dependency:

- bcfg2 doesn't seem to have Python 3 support upstream, neither the
Debian package.
- mini-buildd in Experimental has been converted to Python 3, while the
version in Sid is still Python 2.
- nss-pam-ldapd isn't Python 3 ready upstream. Note that the debian
maintainer the same person as upstream.
- There's been zero upstream work on this repository:
https://github.com/Yubico/python-pyhsm
so the package has no change to be Python 3 ready anytime soon.
- lavapdu-daemon should be upgraded to latest upstream release to have
Python 3 support.
- I haven't been able to tell for lava-coordinator.

I suppose we could raise the severity to serious for the Python 2
removal bug of these packages, and get the work done for python-daemon,
which is otherwise useful (in Python 3).

Your thoughts?

Cheers,

Thomas Goirand (zigo)



Bug#931568:

2019-09-15 Thread Spielwarenkontor

Same here in Debian stable - just upgraded from stable stretch to the
new stable buster and broke production fetchmail system.

client
Sep 15 18:14:01 boark fetchmail[4250]: OpenSSL berichtete:
error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small

server
Sep 15 18:18:01 example.com dovecot: imap-login: Disconnected (no auth
attempts in 0 secs): user=<>, rip=10.0.0.1, lip=192.168.1.1., TLS
handshaking: SSL_accept() failed: error:14094410:SSL
routines:SSL3_READ_BYTES:sslv3 alert handshake failure: SSL alert
number 40

Please escalate this bug. 


Bug#940190: gegl: FTBFS on mips64el and mipsel while it did built before

2019-09-15 Thread Bernhard Übelacker
Hello,
I have created a new upstream issue:
https://gitlab.gnome.org/GNOME/gegl/issues/206

Kind regards,
Bernhard



Bug#940323: mark opam-doc Multi-Arch: foreign

2019-09-15 Thread Helmut Grohne
Package: opam-doc
Version: 2.0.5-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:eliom src:fieldslib src:js-build-tools src:ocaml-atd 
src:ocaml-qtest src:ocaml-rope src:ppx-core src:ppx-driver src:ppx-optcomp 
src:ppx-sexp-conv src:ppx-type-conv src:react src:reactivedata src:sexplib310 
src:variantslib

The affected packages fail to satisfy their cross Build-Depends, because
their transitive dependency on opam-doc is unsatisfiable. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch foreign or annotated :native. In this case, the
foreign marking is sensible, because opam-doc essentially is a data
package. It only contains documentation in portable file formats and
lacks dependencies or maintainer scripts. It should also be considered
whether opam really needs to depend on opam-doc. Maybe a recommendation
would suffice. Please consider applying the attached patch.

Helmut
diff --minimal -Nru opam-2.0.5/debian/changelog opam-2.0.5/debian/changelog
--- opam-2.0.5/debian/changelog 2019-08-17 17:37:02.0 +0200
+++ opam-2.0.5/debian/changelog 2019-09-15 20:16:38.0 +0200
@@ -1,3 +1,10 @@
+opam (2.0.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark opam-doc Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 15 Sep 2019 20:16:38 +0200
+
 opam (2.0.5-1) unstable; urgency=medium
 
   * New upstream version 2.0.5
diff --minimal -Nru opam-2.0.5/debian/control opam-2.0.5/debian/control
--- opam-2.0.5/debian/control   2019-08-17 17:37:02.0 +0200
+++ opam-2.0.5/debian/control   2019-09-15 20:16:36.0 +0200
@@ -79,6 +79,7 @@
 
 Package: opam-doc
 Architecture: all
+Multi-Arch: foreign
 Section: doc
 Depends:
  ${ocaml:Depends},


Bug#940327: convert libpbseq-dev to Architecture: any

2019-09-15 Thread Helmut Grohne
Package: libpbseq-dev
Version: 5.3.1+dfsg-2.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:blasr src:pbdagcon

The affected package fail to satisfy their cross Build-Depends, because
their dependency on libpbseq-dev is unsatisfiable. In general,
Architecture: all packages can never satisfy cross build dependencies
unless marked Multi-Arch: foreign or annotated :native. In this case,
such a marking would be fatally wrong, because the architecture
constraint would not be passed down to its own dependencies. This is
known as the "multiarch interpreter problem". In general, transitional
packages and metapackages should match the architecture of their
dependencies. Please consider applying the attached patch.

Helmut
diff --minimal -Nru pbseqlib-5.3.1+dfsg/debian/changelog 
pbseqlib-5.3.1+dfsg/debian/changelog
--- pbseqlib-5.3.1+dfsg/debian/changelog2019-02-06 08:02:44.0 
+0100
+++ pbseqlib-5.3.1+dfsg/debian/changelog2019-09-15 20:41:33.0 
+0200
@@ -1,3 +1,10 @@
+pbseqlib (5.3.1+dfsg-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Covnert libpbseq-dev to Architecture: any. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 15 Sep 2019 20:41:33 +0200
+
 pbseqlib (5.3.1+dfsg-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru pbseqlib-5.3.1+dfsg/debian/control 
pbseqlib-5.3.1+dfsg/debian/control
--- pbseqlib-5.3.1+dfsg/debian/control  2019-02-06 08:02:44.0 +0100
+++ pbseqlib-5.3.1+dfsg/debian/control  2019-09-15 20:41:09.0 +0200
@@ -31,12 +31,12 @@
  This is a metapackage that depends on the pbseqlib component shared libraries.
 
 Package: libpbseq-dev
-Architecture: all
+Architecture: any
 Section: libdevel
 Depends: ${misc:Depends},
- libpbdata-dev (>= ${source:Version}),
- libpbihdf-dev (>= ${source:Version}),
- libblasr-dev  (>= ${source:Version})
+ libpbdata-dev (= ${binary:Version}),
+ libpbihdf-dev (= ${binary:Version}),
+ libblasr-dev  (= ${binary:Version})
 Description: library for analyzing PacBio sequencing data (development files)
  Blasr_libcpp is a library used by blasr and other executables such as
  samtoh5, loadPulses for analyzing PacBio sequences. This library contains


Bug#940326: mark libgoffice-0.10-10-common Multi-Arch: foreign

2019-09-15 Thread Helmut Grohne
Package: libgoffice-0.10-10-common
Version: 0.10.45-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:abiword src:gnome-chemistry-utils src:gnumeric 
src:grisbi src:nip2

The affected packages fail to satisfy their cross Build-Depends, because
their transitive dependency on libgoffice-0.10-10-common is
unsatisfiable. In general, Architecture: all packages can never satisfy
cross build dependencies unless marked Multi-Arch: foreign or annotated
:native. In this case, the foreign marking is reasonable, because
libgoffice-0.10-10-common is a data package. It doesn't have any
dependencies nor maintainer scripts and only contains locale data.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru goffice-0.10.45/debian/changelog 
goffice-0.10.45/debian/changelog
--- goffice-0.10.45/debian/changelog2019-08-21 12:13:48.0 +0200
+++ goffice-0.10.45/debian/changelog2019-09-15 20:53:17.0 +0200
@@ -1,3 +1,11 @@
+goffice (0.10.45-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark libgoffice-0.10-10-common Multi-Arch: foreign. (Closes: #-1)
+  * Mark libgoffice-0.10-doc Multi-Arch: foreign.
+
+ -- Helmut Grohne   Sun, 15 Sep 2019 20:53:17 +0200
+
 goffice (0.10.45-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru goffice-0.10.45/debian/control 
goffice-0.10.45/debian/control
--- goffice-0.10.45/debian/control  2019-08-21 12:13:48.0 +0200
+++ goffice-0.10.45/debian/control  2019-09-15 20:53:17.0 +0200
@@ -60,6 +60,7 @@
 
 Package: libgoffice-0.10-10-common
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Description: Document centric objects library - common files
  GOffice is a library of document centric objects and utilities building on
@@ -81,6 +82,7 @@
 Package: libgoffice-0.10-doc
 Section: doc
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Breaks: libgoffice-0.10-dev (<< 0.10.4)
 Replaces: libgoffice-0.10-dev (<< 0.10.4)


Bug#936631: gnumed-server: py3 available upstream

2019-09-15 Thread Karsten Hilbert
Package: gnumed-server
Version: 22.7-1
Followup-For: Bug #936631

There is py3 support available upstream but it needs to
be polished and released.

Karsten


-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 
'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 5.2.0-2-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages gnumed-server depends on:
ii  anacron   2.3-28
ii  bsd-mailx [mail-reader]   8.1.2-0.20180807cvs-1
ii  bzip2 1.0.6-9.2~deb10u1
ii  cron  3.0pl1-134
ii  debconf   1.5.71
ii  gnupg 2.2.12-1+deb10u1
ii  gnupg22.2.12-1+deb10u1
ii  kmail [mail-reader]   4:18.08.3-1
ii  mutt [mail-reader]1.10.1-2.1
ii  openssl   1.1.1c-1
ii  postgresql11+200+deb10u2
ii  postgresql-client 11+200+deb10u2
ii  postgresql-client-11 [postgresql-client]  11.5-1+deb10u1
ii  python2.7.16-1
ii  python-egenix-mxdatetime  3.2.9-1
ii  python-psycopg2   2.7.7-1
ii  rsync 3.1.3-6
ii  sudo  1.8.27-1

Versions of packages gnumed-server recommends:
pn  barman  

Versions of packages gnumed-server suggests:
pn  bacula-console   
ii  orthanc  1.5.6+dfsg-1
ii  orthanc-postgresql   3.2-1
ii  orthanc-webviewer2.5-1
ii  postgresql-contrib   11+200+deb10u2
ii  postgresql-filedump  11.0-1
pn  postgresql-plr   

-- no debconf information



Bug#940332: RFH: syncthing

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello,

I haven't had enough time to keep up with Syncthing upstream updates for
the past months.

I don't mind putting some time into the Syncthing packaging from time to
time but I can no longer handle it by myself.

I would love for someone to help or take over! Note that I'd be willing
to give pointers of sponsor uploads if needed.

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#940434: RFA: golang-github-tj-go-spin

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello!

I'd like to find new maintainers for some of my packages because I have
had less time for Debian. I'd like to focus the small amount of time
that I have for Debian on other things.

For now, I intend to do my best to keep maintaining this package.
However, I will probably retitle this bug with the 'O:' prefix at some
point, indicating that I have orphaned it.

Feel free to upload a new version of the package and remove me from the
uploaders in debian/control.

Feel free to contact me with any questions. Also note that I always
willing to sponsor uploads!

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#940435: RFA: golang-github-tjfoc-gmsm

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello!

I'd like to find new maintainers for some of my packages because I have
had less time for Debian. I'd like to focus the small amount of time
that I have for Debian on other things.

For now, I intend to do my best to keep maintaining this package.
However, I will probably retitle this bug with the 'O:' prefix at some
point, indicating that I have orphaned it.

Feel free to upload a new version of the package and remove me from the
uploaders in debian/control.

Feel free to contact me with any questions. Also note that I always
willing to sponsor uploads!

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#940436: RFA: golang-github-tv42-zbase32

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello!

I'd like to find new maintainers for some of my packages because I have
had less time for Debian. I'd like to focus the small amount of time
that I have for Debian on other things.

For now, I intend to do my best to keep maintaining this package.
However, I will probably retitle this bug with the 'O:' prefix at some
point, indicating that I have orphaned it.

Feel free to upload a new version of the package and remove me from the
uploaders in debian/control.

Feel free to contact me with any questions. Also note that I always
willing to sponsor uploads!

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#940441: RFA: golang-go.pedge-env

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello!

I'd like to find new maintainers for some of my packages because I have
had less time for Debian. I'd like to focus the small amount of time
that I have for Debian on other things.

For now, I intend to do my best to keep maintaining this package.
However, I will probably retitle this bug with the 'O:' prefix at some
point, indicating that I have orphaned it.

Feel free to upload a new version of the package and remove me from the
uploaders in debian/control.

Feel free to contact me with any questions. Also note that I always
willing to sponsor uploads!

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#940444: RFA: golang-gopkg-h2non-filetype.v1

2019-09-15 Thread Alexandre Viau
Package: wnpp
Severity: normal

Hello!

I'd like to find new maintainers for some of my packages because I have
had less time for Debian. I'd like to focus the small amount of time
that I have for Debian on other things.

For now, I intend to do my best to keep maintaining this package.
However, I will probably retitle this bug with the 'O:' prefix at some
point, indicating that I have orphaned it.

Feel free to upload a new version of the package and remove me from the
uploaders in debian/control.

Feel free to contact me with any questions. Also note that I always
willing to sponsor uploads!

Cheers,

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature


Bug#940282: lintian: False positive library-not-linked-against-libc on Octave add-ons

2019-09-15 Thread Rafael Laboissière

Package: lintian
Version: 2.21.0
Severity: normal
Tags: patch

Checking the octave-stk package against the current version of Lintian 
in unstable (2.21.0), yields several errors like this one:


E: octave-stk: library-not-linked-against-libc 
usr/lib/x86_64-linux-gnu/octave/packages/stk-2.6.0/x86_64-pc-linux-gnu-api-v52/__stk_dist_matrixx__.mex

I believe that these are false positives.  The *.mex files (like *.oct 
files) are dynamically linked objects that are loaded at runtime by 
Octave and contains extensions that add functionality to the program 
(like add-ons).


These files are produced by mkoctfile, which is called by the 
dh-octave insfrastructure, on which most of the packages providing 
Octave add-ons build-depend.  These *.mex and *.oct are never 
underlinked, as itcan be checked running, for instance:


ldd -r __stk_dist_matrixx__.mex

I proposed a very simplistic patch for fixing the problem as a merge 
request against the Lintian Git repository at salsa.d.o:


https://salsa.debian.org/lintian/lintian/merge_requests/258

My knowledge on the internals of Lintian are very limited, so I 
apologize in advance if this patch is not appropriate.


Best,

Rafael Laboissière



Bug#884516: python-bayespy: FTBFS and Debci failure on several architectures

2019-09-15 Thread Graham Inggs
Control: severity -1 important

Arch:all packages are only required to build on amd64.
There are still autopkgtest failures on several architectures, which
are reproducible on the porterboxes, so downgrading the severity, but
leaving the bug open.



Bug#887122: python2.7

2019-09-15 Thread Pavlo Boiko
In may case the error was provoked by switching to python3.7 by default. 
So I changed the first line of obamenu to ensure that the script is 
executed by python2.7




Bug#940284: autogeneration of ssl key in ssl server mode of ncat is broken

2019-09-15 Thread Stefan Baur
Package: ncat
Version: 7.70+dfsg1-6

When calling ncat 7.70 like so:

ncat --ssl -l -p 4223 -v

It reports:

Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Generating a temporary 1024-bit RSA key. Use --ssl-key and
--ssl-cert to use a permanent one.
Ncat: SHA-1 fingerprint: 0EE7 DDAD 7284 7826 D49D 9277 B456 371D 1652 C887
Ncat: SSL_CTX_use_certificate(): error:140AB18F:SSL
routines:SSL_CTX_use_certificate:ee key too small. QUITTING.

... and quits.

Expected behavior, as displayed by ncat 7.60:

Ncat: Version 7.60 ( https://nmap.org/ncat )
Ncat: Generating a temporary 1024-bit RSA key. Use --ssl-key and
--ssl-cert to use a permanent one.
Ncat: SHA-1 fingerprint: 88D6 3917 08F9 A7A2 555A A97F 9567 D863 DC4F C6EF
Ncat: Listening on :::4223
Ncat: Listening on 0.0.0.0:4223

Note that the actual cause might be the OpenSSL version being different
as well. Buster has OpenSSL 1.1.1c, if I'm not mistaken; while the
system where I tried out ncat 7.60 has OpenSSL 1.1.1 (without the "c").

However, if OpenSSL by default requires a minimum key length larger than
1024 bits, then ncat should either default to a larger key length or
offer a commandline parameter to specify an arbitrary key length.

It seems to be fixed in ncat 7.80, which defaults to a 2048-bit key now:

Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Generating a temporary 2048-bit RSA key. Use --ssl-key and
--ssl-cert to use a permanent one.
Ncat: SHA-1 fingerprint: 7612 C7AD 2B90 48DD 6932 2745 A324 F590 3361 16C3
Ncat: Listening on :::4223
Ncat: Listening on 0.0.0.0:4223

Would be possible to either get 7.80 into Buster, or to backport the
particular change into the 7.70 we have in Buster?

I am aware that it is possible to specify a key and cert file; but that
is only acceptable as a workaround, not as a solution.

Kind Regards,
Stefan Baur



Bug#940286: golang-github-anacrolix-missinggo-dev has circular Depends on golang-github-anacrolix-tagflag-dev

2019-09-15 Thread Bill Allombert
Package: golang-github-anacrolix-missinggo-dev
Version: 2.1.0-4
Severity: important

Hello Debian Go Packaging Team,

There is a circular dependency between golang-github-anacrolix-missinggo-dev 
and golang-github-anacrolix-tagflag-dev:

golang-github-anacrolix-missinggo-dev   :Depends: 
golang-github-anacrolix-tagflag-dev
golang-github-anacrolix-tagflag-dev :Depends: 
golang-github-anacrolix-missinggo-dev

Circular dependencies are known to cause problems during upgrade between
stable releases, so we should strive to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#939178: release-notes: Describe name selection rules in the "Migrating from legacy network interface names" section

2019-09-15 Thread Justin B Rye
Here's a patch for the Release Notes adding another common corner-case
to the list of things to beware of, plus an updated set of external
links including "https://wiki.debian.org/NetworkInterfaceNames;.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/issues.dbk b/en/issues.dbk
index 3105a90f..524f2650 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -150,8 +150,7 @@ information mentioned in .
 
  The alternative is to switch to a supported mechanism for enforcing
  the old naming scheme, such as a systemd .link
- file (see 
- systemd.link(5)).
+ file (see systemd.link(5)).
  The net.ifnames=0 kernel commandline option might
  also work for systems with only one network interface (of a given type).
 
@@ -173,9 +172,10 @@ $ udevadm test-builtin net_id /sys/class/net/eth0 2>/
 
 
   This should give enough information to devise a migration plan. (If the
-  udevadm output includes an onboard
-  name, that takes priority; MAC-based names are normally treated as a
-  fallback, but may be needed for USB network hardware.)
+  udevadm output includes an onboard or
+  slot name, that takes priority; MAC-based names are
+  normally treated as a fallback, but may be needed for USB network
+  hardware.)
 
 
   Once you are ready to carry out the switch, disable
@@ -194,9 +194,9 @@ $ sudo update-initramfs -u
  names. Adjust any remaining configuration files, and test your system.
 
 
- See the
- https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/;>upstream
- documentation and the udev
+ See the wiki, https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html;>upstream
+ documentation, and the udev
  README.Debian for further information.
 
   


Bug#940294: ITP: r-cran-propclust -- Propensity Clustering and Decomposition

2019-09-15 Thread Steffen Moeller
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-propclust -- Propensity Clustering and Decomposition
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-propclust
  Version : 1.4
  Upstream Author : John Michael O Ranola
* URL : https://cran.r-project.org/package=PropClust
* License : GPL-2+
  Programming Lang: GNU R
  Description : Propensity Clustering and Decomposition
 Implementation of propensity clustering and decomposition as described
 in Ranola et al. (2013) . Propensity
 decomposition can be viewed on the one hand as a generalization of the
 eigenvector-based approximation of correlation networks, and on the
 other hand as a generalization of random multigraph models and conformity-
 based decompositions.

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



Bug#940297: ca-certificates-java: circular dependency hell

2019-09-15 Thread Bill Allombert
Package: ca-certificates-java
Version: 20190909
Severity: important

Hello Debian Java Maintainers,

There is a circular dependency between ca-certificates-java, 
default-jre-headless and openjdk-11-jre-headless:

ca-certificates-java:Depends: default-jre-headless
default-jre-headless:Depends: openjdk-11-jre-headless
openjdk-11-jre-headless :Depends: ca-certificates-java (>= 20190405~)

Complex circular dependencies are known to cause problems during upgrade, so we
should try to get rid of them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#940303: libreoffice-common: circular dependency hell

2019-09-15 Thread Bill Allombert
On Sun, Sep 15, 2019 at 01:51:38PM +0200, Rene Engelhard wrote:
> can you use some sane title instead of just accusing people directly
> there?

Hello Rene!

I did not plan to accuse anybody. 
Are you objecting to the vocable 'dependency hell' ?

> > libreoffice-style-colibre   :Depends: libreoffice-common (= 1:6.3.1-1)
> > libreoffice-style-tango :Depends: libreoffice-common (= 1:6.3.1-1)
> 
> And of couse the icons need LO to make sense, and far more important,
> due to dh_linkdocs to save space -common is even needed to have
> /usr/share/doc (and that one is mandated by policy).

Policy allows to use separate
/usr/share/doc/libreoffice-common
/usr/share/doc/libreoffice-style-colibre and
/usr/share/doc/libreoffice-style-tango
directories which are not symlinks and copy the copyright file instead
and this way you do not have to add an unnecessary dependency.

The provision for the symlink in policy should not be seen as a
justification for unnecessary dependencies.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#940313: python3-osprofiler fails to install

2019-09-15 Thread peter green

Package: python3-osprofiler
Version: 2.6.0-1
Severity: grave

python3-osprofiler fails to install, I first noticed this in an autopkgtest, 
but I was able to reproduce it in a local sid chroot too.


Setting up python3-osprofiler (2.6.0-1) ...
update-alternatives: error: alternative path /usr/bin/python3-osprofiler 
doesn't exist
dpkg: error processing package python3-osprofiler (--configure):
  installed python3-osprofiler package post-installation script subprocess 
returned error exit status 2




Bug#891993: syrthes-gui uses obsolete libs Qt4 and Python2

2019-09-15 Thread Gilles Filippini
Hi,

Moritz Mühlenhoff a écrit le 13/09/2019 à 23:18 :
> On Mon, Aug 19, 2019 at 02:12:35AM -0400, Scott Kitterman wrote:
>> On Sat, 03 Mar 2018 21:16:22 +0100 Andreas Beckmann  wrote:
>>> Source: syrthes
>>> Version: 4.3.0-dfsg1-2
>>> Severity: serious
>>> Tags: sid buster
>>> Justification: blocks python-qwt5-qt4 removal
>>> Control: block 886779 with -1
>>>
>>> Hi,
>>>
>>> src:syrthes Build-Depends on python-qwt5-qt4 which is scheduled for
>>> removal (#886779). Please switch to a Qt5 solution or drop the
>>> (Build-)Dependency altogether.
>>>
>>>
>>> Andreas
>>
>> These (along with python-qwt5-qt4) are being removed this cycyle.  Upstream 
>> does not have a Qt5/Python3 release yet.  If the Python3/Qt4 requirements 
>> are 
>> confined to the gui, maybe just that part can be dropped until upstream 
>> releases a version we can support.
> 
> Hi Gilles,
> syrthes is the only remaining packages blocking the removal of pyqwt5. Are
> you planning to port the GUI yourself, should we (temporarily, until fixed)
> drop the syrthes-gui package or if that's not an option, should syrthes be
> (temporarily) removed altogether?

Syrthes' upstream is quite unresponsive. A version 5 should be on its
way but there is no place to download it from and the preview I had more
than one year ago brought many dependencies with unclear licensing.

I think the best option for now would be to just drop syrthes-gui.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature


Bug#939961: FTBFS with OCaml 4.08.0 (safe strings)

2019-09-15 Thread Stéphane Glondu
Le 14/09/2019 à 23:12, Andy Li a écrit :
> You package haxe FTBFS with OCaml 4.08.0 because -safe-string is now
> the default. Full log:
> 
>   https://ocaml.debian.net/transitions/ocaml-4.08.0/pool/haxe.log
> 
> 
> The link returns ERR_NAME_NOT_RESOLVED for me. Is it down?

No. But it is IPv6 only.

> Please fix your package so that it compiles with -safe-string. This is
> possible with the version of OCaml currently in unstable (4.05.0).
> 
> 
> The upcoming version of Haxe (4.0.0) will be safe-string compatible, but
> the current version will remain incompatible (difficult to patch).
> I will just add "OCAMLPARAM=safe-string=0,_" as a workaround. Is that okay?

If that works and is temporary, OK.


Cheers,

-- 
Stéphane



Bug#940317: hplip: No more printing

2019-09-15 Thread Nicolas Patrois
Package: hplip
Version: 3.19.8+dfsg0-1
Severity: important

Dear Maintainer,

I can’t print anymore, neither with a Photosmart 4780 nor with an Envy 5534 (.
Both used to work.
In fact, the jobs seem frozen in the queue.

I send the jobs and immediately, I’m informed that the job has been completed.
It has not been printed.
I checked hp-check and it crashes (see log). Maybe Python 2 to 3 went wrong.
Yet, before crashing, hp-check shows two errors:

 error: gsGhostScript - PostScript and PDF language interpreter and
previewer REQUIRED7.059.28MISSING'gs needs
to be installed'

But gs is installed.

 error: libnetsnmp-devel libnetsnmp-devel - SNMP networking library development
files REQUIRED5.0.9   -   MISSING'libnetsnmp-
devel needs to be installed'

This library seems no more to exist: I can’t find it with apt-cache, apt-file,
aptitude nor dpkg.

n.



-- Package-specific info:
Saving output in log file: /home/nicolas/hp-check.log

HP Linux Imaging and Printing System (ver. 3.19.8)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling 
the HPLIP supplied  
tarball (.tar.gz or .run) to determine if the proper dependencies are installed 
to successfully  
compile HPLIP.  
 
2. Run-time check mode (-r or --run): Use this mode to determine if a distro 
supplied package
(.deb, .rpm, etc) or an already built HPLIP supplied tarball has the proper 
dependencies 
installed to successfully run.  
 
3. Both compile- and run-time check mode (-b or --both) (Default): This mode 
will check both of  
the above cases (both compile- and run-time dependencies).  
 

Check types:
 
a. EXTERNALDEP - External Dependencies  
 
b. GENERALDEP - General Dependencies (required both at compile and run time)
 
c. COMPILEDEP - Compile time Dependencies   
 
d. [All are run-time checks]
 
PYEXT SCANCONF QUEUES PERMISSION
 

Status Types:
OK
MISSING   - Missing Dependency or Permission or Plug-in
INCOMPAT  - Incompatible dependency-version or Plugin-version

Gtk-Message: 16:08:22.387: Failed to load module "atk-bridge"
warning: debian-bullseye/sid version is not supported. Using debian-10.0 
versions dependencies to verify and install...

---
| SYSTEM INFO |
---

 Kernel: 4.17.0-3-686-pae #1 SMP Debian 4.17.17-1 (2018-08-18) GNU/Linux
 Host: nicolas.home
 Proc: 4.17.0-3-686-pae #1 SMP Debian 4.17.17-1 (2018-08-18) GNU/Linux
 Distribution: debian bullseye/sid
 Bitness: 32 bit


---
| HPLIP CONFIGURATION |
---

HPLIP-Version: HPLIP 3.19.8
HPLIP-Home: /usr/share/hplip
warning: HPLIP-Installation: Auto installation is not supported for debian 
distro  bullseye/sid version 

Current contents of '/etc/hp/hplip.conf' file:
# hplip.conf.  Generated from hplip.conf.in by configure.

[hplip]
version=3.19.8

[dirs]
home=/usr/share/hplip
run=/var/run
ppd=/usr/share/ppd/hplip/HP
ppdbase=/usr/share/ppd/hplip
doc=/usr/share/doc/hplip
html=/usr/share/doc/hplip-doc
icon=no
cupsbackend=/usr/lib/cups/backend
cupsfilter=/usr/lib/cups/filter
drv=/usr/share/cups/drv
bin=/usr/bin
apparmor=/etc/apparmor.d
# Following values are determined at configure time and cannot be changed.
[configure]
network-build=yes
libusb01-build=no
pp-build=no
gui-build=yes
scanner-build=yes
fax-build=yes
dbus-build=yes
cups11-build=no
doc-build=yes
shadow-build=no
hpijs-install=yes
foomatic-drv-install=yes
foomatic-ppd-install=no
foomatic-rip-hplip-install=no
hpcups-install=yes
cups-drv-install=yes
cups-ppd-install=no
internal-tag=3.19.8
restricted-build=no
ui-toolkit=qt5
qt3=no
qt4=no
qt5=yes
policy-kit=yes
lite-build=no
udev_sysfs_rules=no
hpcups-only-build=no
hpijs-only-build=no
apparmor_build=no
class-driver=no


Current contents of '/var/lib/hp/hplip.state' file:
[plugin]
installed = 1
eula = 1
version = 3.14.6



Current contents of '~/.hplip/hplip.conf' file:
[commands]
scan = /usr/bin/simple-scan %SANE_URI%

[fax]
email_address = 
voice_phone = 

[last_used]
device_uri = "hp:/net/ENVY_5530_series?hostname=HPD0BF9CAFD037.local"
printer_name = HP-ENVY-5530-series

Bug#940319: backintime: run test suite during build

2019-09-15 Thread Jonathan Wiltshire
Source: backintime
Version: 1.2.1-1
Severity: wishlist

In 1.2 upstream added a test suite. We should run it during build
(cd common && $(MAKE) test) but it needs to be able to write to the home
directory, which is disabled on Debian auto-builders. Need to find
a solution to that.

-- System Information:
Debian Release: 10.1
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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



Bug#930997: cmake: reprotest's 'setarch linux32 dh_auto_configure' on amd64 results in CMAKE_SYSTEM_PROCESSOR = i386

2019-09-15 Thread Niels Thykier
Control: reassign -1 reprotest
Control: tags -1 -moreinfo

Helmut Grohne:
> Hi Niels,
> 
> On Sat, Sep 14, 2019 at 06:08:00AM +, Niels Thykier wrote:
>> Is there any update on this?  At the moment, this bug is not actionable
>> and sprayed over three packages.
> 
> No. I don't think there are any news here. I had hoped that my previous
> mails would have made my position clear. Let me try to be more explicit:
> I think that running native amd64 builds in linux32 is broken and that
> any tool doing so (e.g. reprotest) is buggy.
> 
> Having debhelper pass CMAKE_SYSTEM_PROCESSOR is a nice idea, but doing
> so will break a fair number of packages in subtle ways. Therefore I
> recommend not doing that (other than for cross compilation).
> 
> This is basically repeating what I already said. If you concur, the
> logical next step is reassigning to reprotest.
> 
> Helmut
> 

Thanks for clarifying; I missed that part.

Reassigning to reprotest

Thanks,
~Niels



Bug#940287: pki-base has circular Depends on python3-pki-base

2019-09-15 Thread Bill Allombert
Package: pki-base
Version: 10.7.3-3
Severity: important

Hello Debian FreeIPA Team,

There is a circular dependency between pki-base and python3-pki-base:

pki-base:Depends: python3-pki-base
python3-pki-base:Depends: pki-base (= 10.7.3-3)

Circular dependencies are known to cause problems during upgrade between
stable releases, so we should strive to avoid them.

See threads 
http://lists.debian.org/debian-devel/2005/06/msg02111.html
http://lists.debian.org/debian-devel/2005/11/msg01101.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#931950: transition: libgeotiff

2019-09-15 Thread Adam D. Barratt
On Sun, 2019-09-15 at 08:27 +0200, Sebastiaan Couwenberg wrote:
> On 9/10/19 8:11 AM, Sebastiaan Couwenberg wrote:
> > libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1)
> > cannot
> > be removed from testing due to gnudatalanguage, which I don't
> > understand. But this should be resolved when the package get
> > autoremoved
> > on the 14th.
> 
> gnudatalanguage was not removed yesterday, it's still marked for
> removal on 14 September.

It was removed in the 10:00 run on the 15th, which was the first run
after it was in the auto-removals hint list. You just need a little
more patience.

> Version 0.9.9-10+b1 of the gnudatalanguage binary packages is in
> testing,

Not any longer.

Regards,

Adam



Bug#940295: libeclipse-compare-java: circular dependency hell

2019-09-15 Thread Bill Allombert
Package: libeclipse-compare-java
Version: 3.7.600+eclipse4.12-1
Severity: important

Hello Debian Java Maintainers,

There is a circular dependency between libeclipse-compare-java, 
libeclipse-ui-editors-java and libeclipse-ui-workbench-texteditor-java:

libeclipse-compare-java :Depends: libeclipse-ui-editors-java, 
libeclipse-ui-workbench-texteditor-java
libeclipse-ui-editors-java  :Depends: 
libeclipse-ui-workbench-texteditor-java
libeclipse-ui-workbench-texteditor-java :Depends: 
libeclipse-compare-java

Complex circular dependencies are known to cause problems during upgrade, so we
should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

2019-09-15 Thread Jonas Smedegaard
Quoting Johannes Schauer (2019-09-14 18:26:57)
> Hi,
> 
> Quoting Patrick Schleizer (2019-09-14 08:00:00)
> > cowbuilder (or pbuilder?) calls debootstrap with:
> > 
> > + args='--include=apt --variant=buildd --force-check-gpg buster 
> > /var/cache/pbuilder/base.cow_amd64 http://HTTPS///deb.debian.org/debian'
> > 
> > I.e. it is possible to pass an apt repository URI through command line
> > (above last argument).
> > 
> > However, I am translating that in the wrapper to:
> > 
> > --verbose --architectures=amd64
> > --aptopt=/home/user/whonix_binary/aptgetopt.conf
> > --include=apt,sudo,devscripts,debhelper,strip-nondeterminism,fakeroot,apt-transport-tor,apt-transport-https,python,eatmydata,aptitude,cowdancer
> > buster /var/cache/pbuilder/base.cow_amd64
> > /home/user/Whonix/build_sources/debian_stable_current_clearnet.list
> > 
> > Using a file
> > /home/user/Whonix/build_sources/debian_stable_current_clearnet.list
> > which contains both, Debian "standard" repository as well as Debian
> > security repository.
> > 
> > This is to make use of mmdebstrap excellent security feature to
> > bootstrap from two repositories at once. If the APT version in Debian
> > "standard" repository had a vulnerability, then the vulnerable version
> > would be installed first before vulnerable APT would be used to upgrade
> > in a later step from Debian security repository.
> > 
> > "Incompatibility" is perhaps a far stretched term. How do we "teach"
> > grml-debootstrap, cowbuilder (or pbuilder?) "use both, Debian "standard"
> > repository and Debian security repository when using mmdebstrap"?
> > 
> > It's like "the ecosystem does not take advantage of mmdebstrap" yet.
> 
> Okay, but as far as I can see there is nothing that can be done in 
> mmdebstrap about this, right?

If mmdebstrap were to support curl-style URL expansion, then current 
wrappers for debootstrap supporting only a single string could be abused 
to pass an expandable set of strings, like this:

Perhaps mmdebstrab could support curl-style glob expansion of URLs + 
suite splitting, to allow passing multiple apt lines through wrappers 
which expects only a single base URL, like this:

  
https://{deb.debian.org/debian/dists/{buster,buster-updates},security.debian.org/debian-security/dists/buster/updates}

expanding to this:

  https://deb.debian.org/debian buster
  https://deb.debian.org/debian buster-updates
  https://security.debian.org/debian-security buster/updates

Here's a quick one-line that maybe better explains what I mean:

echo 
'https://{deb.debian.org/debian/dists/{buster,buster-updates},security.debian.org/debian-security/dists/buster/updates}'
 | perl -MFile::Glob=:bsd_glob -nE 'say map { s,/dists/, ,r } bsd_glob($_, 
GLOB_BRACE | GLOB_NOMAGIC )'


 - Jonas

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

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


signature.asc
Description: signature


Bug#940302: dmeventd has circular Depends on liblvm2cmd2.03

2019-09-15 Thread Bill Allombert
Package: dmeventd
Version: 2:1.02.155-3
Severity: important

Hello Debian LVM Team,

There is a circular dependency between dmeventd and liblvm2cmd2.03:

dmeventd:Depends: liblvm2cmd2.03 (>= 2.03.02)
liblvm2cmd2.03  :Depends: dmeventd

Circular dependencies involving shared libraries are known to cause problems
during upgrade between stable releases, so we should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#940306: uscan: Missing argument in sprintf at /usr/share/perl5/Devscripts/MkOrigtargz.pm

2019-09-15 Thread Yann Dirson
Package: devscripts
Version: 2.19.5+deb10u1
Severity: normal

In the case where a .tar url does not really point to a tarfile, uscan
does report the problem, but only after a printf error.

Additionally, it does not keep the downloaded file, which forces manual
re-download to check what really happenned.

yann@home:jam-2.6$ uscan
uscan: Newest version of jam on remote site is 2.6.1, local version is
2.6
uscan:=> Newer package available from
  
https://swarm.workshop.perforce.com/projects/perforce_software-jam/files/main/jam-2.6.1.tar
Missing argument in sprintf at /usr/share/perl5/Devscripts/MkOrigtargz.pm line 
575.
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
uscan: error: tar --list --auto-compress --file ../jam_2.6.1.orig.tar.
subprocess returned exit status 2
yann@home:jam-2.6$ file jam-2.6.1.tar
jam-2.6.1.tar: cannot open `jam-2.6.1.tar' (No such file or directory)
yann@home:jam-2.6$ wget 
https://swarm.workshop.perforce.com/projects/perforce_software-jam/files/main/jam-2.6.1.tar
--2019-09-15 13:26:56-- 
https://swarm.workshop.perforce.com/projects/perforce_software-jam/files/main/jam-2.6.1.tar
Resolving swarm.workshop.perforce.com (swarm.workshop.perforce.com)...
107.1.244.153
Connecting to swarm.workshop.perforce.com
(swarm.workshop.perforce.com)|107.1.244.153|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘jam-2.6.1.tar’

jam-2.6.1.tar   [ <=> ]   8.72K  --.-KB/s   
 in 0.001s

2019-09-15 13:26:57 (16.9 MB/s) - ‘jam-2.6.1.tar’ saved [8932]

yann@home:jam-2.6$ file jam-2.6.1.tar
jam-2.6.1.tar: HTML document, ASCII text, with very long lines




-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBSIGN_KEYID=74AF05DDD92027F5F0C3CDD50D85F29625A3F9FD
DGET_UNPACK=no
DEBDIFF_SHOW_MOVED=yes

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (900, 'testing'), (500, 'stable-debug'), (500, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.23-1
ii  file  1:5.35-4
ii  gnupg 2.2.12-1+deb10u1
ii  gnupg22.2.12-1+deb10u1
ii  gpgv  2.2.12-1+deb10u1
ii  libc6 2.28-10
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-2
ii  patchutils0.3.4-2
ii  perl  5.28.1-6
ii  python3   3.7.3-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.2
ii  at  3.1.23-1
ii  curl7.64.0-4
ii  dctrl-tools 2.24-3
ii  debian-keyring  2019.02.25
ii  dput1.0.3
ii  equivs  2.2.0
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.16-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.15.0
ii  man-db  2.8.5-2
ii  patch   2.7.6-3+deb10u1
ii  python3-apt 1.8.4
ii  python3-debian  0.1.35
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-5
ii  strace  4.26-0.2
ii  unzip   6.0-23+deb10u1
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
ii  adequate 0.15.2
ii  autopkgtest  5.10
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1
ii  build-essential  12.6
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper12.1.1
ii  devscripts-el40.3
ii  diffoscope   113
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  

Bug#940298: debhelper: Should we use meson --native-file ?

2019-09-15 Thread Niels Thykier
(Forgot to X-Debugs-CC Helmut and Jussi)

Niels Thykier:
> Package: debhelper
> Version: 12.5.4
> Severity: important
> 
> Hi,
> 
> I think it is time for a reboot of #919117, comment #20 if we want this for 
> bullseye:
> 
> """
> On Sun, Jan 13, 2019 at 12:42 AM Helmut Grohne  wrote:
> 
>> I think this discrepancy is a design bug in Meson. Meson should either
>> use environment variables or not. For native compilation, you can simply
>> use a native file. Artificially handling things differently just makes
>> cross compilation unnecessarily hard.
> 
> Using only native and cross files is exactly the thing that we want to
> do and are working towards. Sadly it is likely that we will never be
> able to get rid of the envvar support. For all the gory details see
> for example:
> 
> https://github.com/mesonbuild/meson/issues/4664
> """
> 
> AFAICT, it would just be a question of doing:
> 
> """
> /usr/share/meson/debcrossgen -a"$DEB_BUILD_ARCH" 
> -o"$DIR/meson-native-file.conf"
> /usr/share/meson/debcrossgen -a"$DEB_HOST_ARCH" -o"$DIR/meson-cross-file.conf"
> meson --native-file "$DIR/meson-native-file.conf" --cross-file 
> "$DIR/meson-cross-file.conf" ...
> """
> 
> OR does it need a special case for cross-building vs. native?
> 
> """
> /usr/share/meson/debcrossgen -a"$DEB_BUILD_ARCH" 
> -o"$DIR/meson-native-file.conf"
> if (is_cross_compiling()) {
>   /usr/share/meson/debcrossgen -a"$DEB_HOST_ARCH" 
> -o"$DIR/meson-cross-file.conf"
>   meson --native-file "$DIR/meson-native-file.conf" --cross-file 
> "$DIR/meson-cross-file.conf" ...
> } else {
>   meson --native-file "$DIR/meson-native-file.conf" ...
> }
> """
> 
> @Helmut, @Jussi:
> 
>  * Do we agree on the above approach?
> 
>  * Do you see any issues with this approach?
> 
> AFAIUI, the advantage is that we will use the same code path for
> native and cross-building plus the meson upstream prefer this approach
> over status-quo.
> 
> Thanks,
> ~Niels
> 



Bug#940304: ITP: r-cran-randomglm -- Random General Linear Model Prediction

2019-09-15 Thread Steffen Moeller
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-randomglm -- Random General Linear Model Prediction
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-randomglm
  Version : 1.02
  Upstream Author : Lin Song
* URL : https://cran.r-project.org/package=randomGLM
* License : GPL-2+
  Programming Lang: GNU R
  Description : Random General Linear Model Prediction
 The package implements a bagging predictor based on
 general linear models

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



Bug#940305: debian-edu-artwork has circular Depends on debian-edu-artwork-buster|debian-edu-artwork-lines|debian-edu-artwork-softwaves

2019-09-15 Thread Bill Allombert
Package: debian-edu-artwork
Version: 2.10.5-2
Severity: important

Hello Debian Edu Developers,

There is a circular dependency between debian-edu-artwork and 
debian-edu-artwork-buster|debian-edu-artwork-lines|debian-edu-artwork-softwaves:

debian-edu-artwork  :Depends: debian-edu-artwork-buster | 
debian-edu-artwork-softwaves | debian-edu-artwork-lines
debian-edu-artwork-buster   :Depends: debian-edu-artwork
debian-edu-artwork-lines:Depends: debian-edu-artwork
debian-edu-artwork-softwaves:Depends: debian-edu-artwork

Circular dependencies are known to cause problems during upgrade,
so we should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#940303: libreoffice-common: circular dependency hell

2019-09-15 Thread Rene Engelhard
reassign 940303 
libreoffice-common,libreoffice-style-colibre,libreoffice-style-tango
severity 940303 normal
retitle 940303 libreoffice-common: circular dependency between -common
and -style-{colibre,tango}
tag 940303 + wontfix
thanks

Hi,

can you use some sane title instead of just accusing people directly
there?

On Sun, Sep 15, 2019 at 01:33:05PM +0200, Bill Allombert wrote:
> Package: libreoffice-common
> Version: 1:6.3.1-1
> Severity: important

No.

> There is a circular dependency between libreoffice-common,
> libreoffice-style-colibre and libreoffice-style-tango:
> 
> libreoffice-common:Depends: libreoffice-style-colibre, 
> libreoffice-style-tango

Of course it does. LO needs icons.

> libreoffice-style-colibre :Depends: libreoffice-common (= 1:6.3.1-1)
> libreoffice-style-tango   :Depends: libreoffice-common (= 1:6.3.1-1)

And of couse the icons need LO to make sense, and far more important,
due to dh_linkdocs to save space -common is even needed to have
/usr/share/doc (and that one is mandated by policy).

> Complex circular dependencies are known to cause problems during upgrade, so 
> we
> should try to avoid them.

If you need stuff during the upgrade. You don't need icons during
a upgrade. And when the upgrade is done you have a consistent thing.

Please file bugs on stuff really having a problem with this. This one
does not.

Regards,

Rene



Bug#938804: vtk6: Python2 removal in sid/bullseye

2019-09-15 Thread peter green

severity 938804 serious
thanks

python-vtk6 depends on the python-autobahn binary package which has already 
been dropped by the python-autobahn source package.



Bug#940315: zope.testrunner autopkgtest failure.

2019-09-15 Thread peter green

Package: zope.testrunner
Version: 4.4.9-3
Severity: serious


autopkgtest [06:13:47]: test all-2: [---
bash: /tmp/autopkgtest-lxc.v65a_j_9/downtmp/build.cMu/src/debian/tests/all-2: 
/usr/bin/python: bad interpreter: No such file or directory
autopkgtest [06:13:47]: test all-2: ---]
autopkgtest [06:13:47]: test all-2:  - - - - - - - - - - results - - - - - - - 
- - -
all-2FAIL non-zero exit status 126
autopkgtest [06:13:47]: test all-2:  - - - - - - - - - - stderr - - - - - - - - 
- -
bash: /tmp/autopkgtest-lxc.v65a_j_9/downtmp/build.cMu/src/debian/tests/all-2: 
/usr/bin/python: bad interpreter: No such file or directory

It looks like while the package has dropped python2 support, some of the 
autopkgtest stuff is still trying to use it.



Bug#940316: zope.testing autopkgtest failure.

2019-09-15 Thread peter green

Package: zope.testing
Version: 4.6.2-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/z/zope.testing/2966135/log.gz


autopkgtest [06:13:32]: test all: [---
Traceback (most recent call last):
   File "/usr/bin/zope-testrunner", line 9, in 
 load_entry_point('zope.testrunner==4.4.9', 'console_scripts', 
'zope-testrunner')()
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/__init__.py", line 
27, in run
 failed = run_internal(defaults, args, script_parts=script_parts, cwd=cwd)
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/__init__.py", line 
44, in run_internal
 runner.run()
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/runner.py", line 159, 
in run
 feature.global_setup()
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 479, 
in global_setup
 tests = find_tests(self.runner.options, self.runner.found_suites)
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 168, 
in find_tests
 for suite in found_suites:
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 179, 
in find_suites
 for fpath, package in find_test_files(options):
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 238, 
in find_test_files
 for f, package in find_test_files_(options):
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 266, 
in find_test_files_
 for (p, package) in test_dirs(options, {}):
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 321, 
in test_dirs
 p = import_name(p)
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 395, 
in import_name
 __import__(name)
ImportError: No module named testing



It looks like while the package has dropped python2 support, some of the 
autopkgtest stuff is still trying to use it.



Bug#925518: Sponsored Post Collaboration - planet.ubuntu.com

2019-09-15 Thread Jason Turner
Hello,

Jason here from Source Global Media  - We are a reputed Digital Marketing
Agency working with variety of clients from UK, USA,  France, Greece,
Finland, Germany and Spain

We are interested in developing partnerships with companies / webmaster
such as yourself to check if you can publish sponsored content for our
clients on your website i.e. - planet.ubuntu.com

If you can publish sponsored content on  planet.ubuntu.com  , please email
us information with prices.

Looking forward to start the business with you.

Best regards,



[image: beacon]


Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-15 Thread peter green

> tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))

Thanks to this hint

This hint was *wrong*, it will introduce garbage into the string and the 
"rotor" code is clearly designed to work with byte strings, not unicode strings.

Change it to

"tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )"




Bug#782952: Bug #782951: Please provide a python3 module

2019-09-15 Thread Scott Kitterman
severity 782952 serious
thanks

python-pyramid-tm depends on python-pyramid which depends on python-
zope.deprecation which has already been dropped by the zope.deprecation source 
package.

Scott K



Bug#931551: transition: llvm-defaults to 8

2019-09-15 Thread Shengjing Zhu
Hi,

On Sun, Jul 07, 2019 at 04:29:31PM +0200, Sylvestre Ledru wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello
> 
> Now that we release buster, I would like to move llvm-defaults to 
> llvm-toolchain-8.
> 
> Thanks,
> Sylvestre
> 
> Ben file:
> 
> title = "llvm-defaults";
> 
> Affected: .depends ~ /(clang|llvm)1?-?[345678]/
> Good: .depends ~ /(clang|llvm)1?-?[8]/
> Bad: .depends ~ /(clang|llvm)1?-?[34567]/
> 

I recently package ccls, which depends on libllvm[1].
I'm curious why this ben file doesn't include libllvm?
And should I rebuild ccls manually? Or it will be handled by RT.
I don't see ccls is on [2].

[1] https://tracker.debian.org/pkg/ccls
[2] https://release.debian.org/transitions/html/llvm-defaults.html

Thanks
Shengjing Zhu


signature.asc
Description: PGP signature


Bug#940285: segmentation fault at start

2019-09-15 Thread Arturo Borrero Gonzalez
Package: gimp
Version: 2.10.8-2+b1
Severity: important
Tags: upstream

Hi,

thanks for your work on this package, is really appreciated.

Today I was trying to open a jpeg in gimp and saw this segfault when starting 
it:

```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-multiarch --disable-werror 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa 
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20190827 (Debian 9.2.1-6) 

using GEGL version 0.4.12 (compiled against version 0.4.14)
using GLib version 2.60.6 (compiled against version 2.60.6)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.1)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```
/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x398)[0x7f8865565f98]
gimp-2.10(+0xd1590)[0x5614c6c77590]
gimp-2.10(+0xd19b8)[0x5614c6c779b8]
gimp-2.10(+0xd2029)[0x5614c6c78029]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13510)[0x7f8864a9d510]
gimp-2.10(gimp_gegl_mask_is_empty+0x91)[0x5614c7062411]
gimp-2.10(+0x3b7810)[0x5614c6f5d810]
gimp-2.10(+0x42ec18)[0x5614c6fd4c18]
gimp-2.10(+0x3d5b50)[0x5614c6f7bb50]
gimp-2.10(+0x42f2aa)[0x5614c6fd52aa]
gimp-2.10(gimp_drawable_set_buffer_full+0x1cb)[0x5614c6f7a9bb]
gimp-2.10(gimp_drawable_set_buffer+0x11d)[0x5614c6f7af9d]
gimp-2.10(gimp_drawable_new+0x106)[0x5614c6f7b296]
gimp-2.10(gimp_layer_new+0x90)[0x5614c6fd84d0]
gimp-2.10(+0x3319cc)[0x5614c6ed79cc]
gimp-2.10(gimp_procedure_execute+0x237)[0x5614c6f10577]
gimp-2.10(gimp_pdb_execute_procedure_by_name_args+0x1e9)[0x5614c6f09a39]
gimp-2.10(gimp_plug_in_handle_message+0x216)[0x5614c6f14626]
gimp-2.10(+0x36cf91)[0x5614c6f12f91]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x158)[0x7f8864c43898]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4ec88)[0x7f8864c43c88]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7f8864c43f82]
gimp-2.10(gimp_plug_in_manager_call_run+0x5fc)[0x5614c6f2435c]
gimp-2.10(+0x376dbe)[0x5614c6f1cdbe]
gimp-2.10(gimp_procedure_execute+0x237)[0x5614c6f10577]
gimp-2.10(gimp_pdb_execute_procedure_by_name_args+0x1e9)[0x5614c6f09a39]
gimp-2.10(gimp_pdb_execute_procedure_by_name+0x3cd)[0x5614c6f09efd]
gimp-2.10(file_open_image+0x33d)[0x5614c700a6fd]
gimp-2.10(file_open_with_proc_and_display+0x29d)[0x5614c700b64d]
gimp-2.10(file_open_from_command_line+0x1b4)[0x5614c700beb4]
gimp-2.10(app_run+0x304)[0x5614c6c76d14]
gimp-2.10(main+0x36e)[0x5614c6c7664e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f88648eebbb]
gimp-2.10(_start+0x2a)[0x5614c6c767da]

```


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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.8-2
ii  libc62.29-1
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2+b1
ii  libglib2.0-0 2.60.6-2
ii  libgs9

Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

2019-09-15 Thread Patrick Schleizer
Happy to report that both invocations of grml-debootstrap and pbuilder /
cowbuilder are compatible with mmdebstrap.

Johannes Schauer:
> you seem to claim that mmdebstrap does not support the --arch argument. But it
> does. It does so by configuring Getopt::Long with auto_abbrev. This means that
> a long option like --architectures can also be written with less characters. 
> It
> works on my system. It does not on yours? Also from the man page:
> 
>  Long options require a double dash and may be abbreviated to uniqueness.


Magic. :)

Works for me. :)

>> Using a file
>> /home/user/Whonix/build_sources/debian_stable_current_clearnet.list
>> which contains both, Debian "standard" repository as well as Debian
>> security repository.
>>
>> This is to make use of mmdebstrap excellent security feature to
>> bootstrap from two repositories at once. If the APT version in Debian
>> "standard" repository had a vulnerability, then the vulnerable version
>> would be installed first before vulnerable APT would be used to upgrade
>> in a later step from Debian security repository.
>>
>> "Incompatibility" is perhaps a far stretched term. How do we "teach"
>> grml-debootstrap, cowbuilder (or pbuilder?) "use both, Debian "standard"
>> repository and Debian security repository when using mmdebstrap"?
>>
>> It's like "the ecosystem does not take advantage of mmdebstrap" yet.
> 
> Okay, but as far as I can see there is nothing that can be done in mmdebstrap
> about this, right?


Maybe not.

I guess the problem indeed isn't mmdebstrap but how other tools are
invoking $DEBOOTSTRAP.

Do you think you could contact pbuilder / cowbuilder / grml-debootstrap
to see how invocation of debootstrap (single repository) vs mmdebstrap
(Debian "standard" repository + Debian security repository) invocation
could be sorted out?

Not sure how crazy would it be to have mmdebstrap auto inject the Debian
security repository? Perhaps keep mmdebstrap as is but have a wrapper
mmdebstrap-sec-repo (or so) that injects it?

>> Not sure anymore why I added:
>> --include=apt,sudo,devscripts,debhelper,strip-nondeterminism,fakeroot,apt-transport-tor,apt-transport-https,python,eatmydata,aptitude,cowdancer
>>
>> apt-transport-https might be required to support https repositories in
>> sources list.
> 
> Yes, old apt versions (1.4.9 and earlier) require that package. It is since a
> dummy package.


Yay.

>> apt-transport-tor might be required to support tor+https and .onion in
>> sources list.
> 
> Yes, but mmdebstrap auto-detects tor URLs and adds the package. This behaviour
> is also documented in its man page.


Magic. :)

#

When mmdebstrap finished, there is still a leftover.

/etc/apt/apt.conf.d/99mmdebstrap

My apt options are good during build (apt cache etc.) but bad in the
final VM image.

Should this file be deleted?

#

mmdebstrap fails when /etc/hostname is missing. An empty /etc/hostname
works for me. Sometimes it's not wanted to leak any host files into the
folder (reproducible builds, privacy, and whatnot). Could you please
have mmdebstrap handle non-existing /etc/hostname (and other system
files (/etc/host /etc/resolv.conf?) gracefully?

#

minor:

>From home folder (in a Qubes Debian VM):

./mmdebstrap --include=apt --variant=buildd --force-check-gpg buster
./test https://deb.debian.org/debian

I: The option --force-check-gpg is a no-op. It only exists for
compatibility with some debootstrap wrappers.
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
mkdir /home/user/test: Permission denied at ./mmdebstrap line 992.

ls -la

drwxr-xr-x  2 10 10   4096 Sep 15 06:07 test

#

minor:

> I: The option --force-check-gpg is a no-op. It only exists for
compatibility with some debootstrap wrappers.


Not sure that implies insecurity. I know gpg signatures are verified but
could confuse others. Perhaps just drop that option from output. Keep it
in man page / command line help only. Users / wrappers using
--force-check-gpg get what they expect anyhow. No need to notify.

Cheers,
Patrick



Bug#940299: RM: minetest-mod-torches -- RoM; obsolete and abandoned upstream

2019-09-15 Thread Julien Puydt
Package: ftp.debian.org

The newer versions of the minetest game have better than what it provides

It's abandoned upstream.

This package has no rdeps.

I'm the package maintainer (within the Debian Games Team), and I'm
proposing to drop it off Debian unstable (and testing, with another bug
report).

JP



Bug#940301: mono-runtime: circular dependency hell

2019-09-15 Thread Bill Allombert
Package: mono-runtime
Version: 5.18.0.240+dfsg-5
Severity: important

Hello Debian Mono Group,

There is a circular dependency between mono-runtime, libmono-corlib4.5-cil, 
libmono-security4.0-cil, libmono-system-configuration4.0-cil, 
libmono-system-core4.0-cil, libmono-system-numerics4.0-cil, 
libmono-system-security4.0-cil, libmono-system-xml4.0-cil, 
libmono-system4.0-cil, mono-4.0-gac, mono-gac, mono-runtime-common and 
mono-runtime-sgen:

mono-runtime:Depends: mono-runtime-sgen (= 5.18.0.240+dfsg-5)
libmono-corlib4.5-cil   :Depends: mono-runtime (>= 5.18.0.240), mono-runtime 
(<< 5.18.0.241)
libmono-security4.0-cil :Depends: libmono-corlib4.5-cil (>= 
5.18.0.240), libmono-system4.0-cil (>= 5.18.0.240)
libmono-system-configuration4.0-cil :Depends: libmono-corlib4.5-cil (>= 
5.18.0.240), libmono-system-security4.0-cil (>= 5.18.0.240), 
libmono-system-xml4.0-cil (>= 4.6.1.3), libmono-system4.0-cil (>= 5.18.0.240), 
mono-runtime (>= 5.18.0.240), mono-runtime (<< 5.18.0.241)
libmono-system-core4.0-cil  :Depends: libmono-corlib4.5-cil (>= 
5.18.0.240), libmono-system4.0-cil (>= 5.18.0.240), mono-runtime-common (>= 
5.18.0.240+dfsg)
libmono-system-numerics4.0-cil  :Depends: libmono-corlib4.5-cil (>= 5.18.0.240)
libmono-system-security4.0-cil  :Depends: libmono-corlib4.5-cil (>= 
5.18.0.240), libmono-system-core4.0-cil (>= 5.18.0.240), 
libmono-system-numerics4.0-cil (>= 5.16.0.220), libmono-system-xml4.0-cil (>= 
4.6.1.3), libmono-system4.0-cil (>= 5.18.0.240)
libmono-system-xml4.0-cil   :Depends: libmono-corlib4.5-cil (>= 
5.18.0.240), libmono-system-configuration4.0-cil (>= 4.0.0~alpha1), 
libmono-system4.0-cil (>= 5.18.0.240)
libmono-system4.0-cil   :Depends: libmono-corlib4.5-cil (>= 5.18.0.240), 
libmono-security4.0-cil (>= 4.6.1.3), libmono-system-configuration4.0-cil (>= 
4.0.0~alpha1), libmono-system-core4.0-cil (>= 5.18.0.240), 
libmono-system-xml4.0-cil (>= 4.6.1.3), mono-runtime (>= 5.18.0.240), 
mono-runtime-common (>= 5.18.0.240+dfsg), mono-runtime (<< 5.18.0.241)
mono-4.0-gac:Depends: libmono-corlib4.5-cil (>= 5.18.0.240), 
libmono-security4.0-cil (>= 4.6.1.3), libmono-system-security4.0-cil (>= 
5.18.0.240), libmono-system4.0-cil (>= 5.18.0.240)
mono-gac:Depends: mono-4.0-gac (= 5.18.0.240+dfsg-5)
mono-runtime-common :Depends: mono-gac (= 5.18.0.240+dfsg-5)
mono-runtime-sgen   :Depends: mono-runtime-common (= 5.18.0.240+dfsg-5)

Complex circular dependencies are known to cause problems during upgrade, so we
should try to get rid of them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#940298: debhelper: Should we use meson --native-file ?

2019-09-15 Thread Niels Thykier
Package: debhelper
Version: 12.5.4
Severity: important

Hi,

I think it is time for a reboot of #919117, comment #20 if we want this for 
bullseye:

"""
On Sun, Jan 13, 2019 at 12:42 AM Helmut Grohne  wrote:

> I think this discrepancy is a design bug in Meson. Meson should either
> use environment variables or not. For native compilation, you can simply
> use a native file. Artificially handling things differently just makes
> cross compilation unnecessarily hard.

Using only native and cross files is exactly the thing that we want to
do and are working towards. Sadly it is likely that we will never be
able to get rid of the envvar support. For all the gory details see
for example:

https://github.com/mesonbuild/meson/issues/4664
"""

AFAICT, it would just be a question of doing:

"""
/usr/share/meson/debcrossgen -a"$DEB_BUILD_ARCH" -o"$DIR/meson-native-file.conf"
/usr/share/meson/debcrossgen -a"$DEB_HOST_ARCH" -o"$DIR/meson-cross-file.conf"
meson --native-file "$DIR/meson-native-file.conf" --cross-file 
"$DIR/meson-cross-file.conf" ...
"""

OR does it need a special case for cross-building vs. native?

"""
/usr/share/meson/debcrossgen -a"$DEB_BUILD_ARCH" -o"$DIR/meson-native-file.conf"
if (is_cross_compiling()) {
  /usr/share/meson/debcrossgen -a"$DEB_HOST_ARCH" -o"$DIR/meson-cross-file.conf"
  meson --native-file "$DIR/meson-native-file.conf" --cross-file 
"$DIR/meson-cross-file.conf" ...
} else {
  meson --native-file "$DIR/meson-native-file.conf" ...
}
"""

@Helmut, @Jussi:

 * Do we agree on the above approach?

 * Do you see any issues with this approach?

AFAIUI, the advantage is that we will use the same code path for
native and cross-building plus the meson upstream prefer this approach
over status-quo.

Thanks,
~Niels



Bug#940300: RM: minetest-mod-torches -- RoM; obsolete and abandoned upstream

2019-09-15 Thread Julien Puydt
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: rm


The newer versions of the minetest game have better than what it provides

It's abandoned upstream.

This package has no rdeps.

I'm the package maintainer (within the Debian Games Team), and I'm
proposing to drop it off Debian testing (and unstable, with another bug
report).

JP



Bug#940303: libreoffice-common: circular dependency hell

2019-09-15 Thread Bill Allombert
Package: libreoffice-common
Version: 1:6.3.1-1
Severity: important

Hello Debian LibreOffice Maintainers,

There is a circular dependency between libreoffice-common,
libreoffice-style-colibre and libreoffice-style-tango:

libreoffice-common  :Depends: libreoffice-style-colibre, 
libreoffice-style-tango
libreoffice-style-colibre   :Depends: libreoffice-common (= 1:6.3.1-1)
libreoffice-style-tango :Depends: libreoffice-common (= 1:6.3.1-1)

Complex circular dependencies are known to cause problems during upgrade, so we
should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#940309: tmux: Random segfaults

2019-09-15 Thread Kamil Jonca
Package: tmux
Version: 2.9a-3
Severity: important

At random moments tmux segfaults, destroying all sessions.
in dmesg we have:

[173131.642689] tmux: server[3258]: segfault at e1 ip 56262a6221a4 sp 
7ffccc134c30 error 6 in tmux[56262a5eb000+6]
[173131.642703] Code: 48 c7 85 30 01 00 00 00 00 00 00 89 45 00 41 8b 47 1c 48 
c1 e0 04 48 03 47 18 bf 01 00 00 00 48 8b 50 08 48 89 95 38 01 00 00 <48> 89 2a 
48 8d 95 30 01 00 00 48 89 50 08 e8 79 55 02 00 8b 55 08

KJ

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
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)
LSM: AppArmor: enabled

Versions of packages tmux depends on:
ii  libc6   2.29-1
ii  libevent-2.1-6  2.1.8-stable-4
ii  libtinfo6   6.1+20190803-1
ii  libutempter01.1.6-3+b1

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information



Bug#940308: picard: new release 2.2

2019-09-15 Thread Cord Beermann
Package: picard
Version: 2.1.3-2
Severity: wishlist

New release available. 

https://picard.musicbrainz.org/changelog/

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

Kernel: Linux 5.2.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 picard depends on:
ii  libc6 2.29-1
ii  libchromaprint-tools  1.4.3-3
ii  python3   3.7.3-1
ii  python3-libdiscid 1.0-5
ii  python3-mutagen   1.40.0-2
ii  python3-pyqt5 5.12.3+dfsg-2

picard recommends no packages.

Versions of packages picard suggests:
ii  hicolor-icon-theme  0.17-2

-- debconf-show failed



Bug#940303: libreoffice-common: circular dependency hell

2019-09-15 Thread Rene Engelhard
Hi,

On Sun, Sep 15, 2019 at 02:14:39PM +0200, Bill Allombert wrote:
> On Sun, Sep 15, 2019 at 01:51:38PM +0200, Rene Engelhard wrote:
> > can you use some sane title instead of just accusing people directly
> > there?
> 
> Hello Rene!
> 
> I did not plan to accuse anybody. 
> Are you objecting to the vocable 'dependency hell' ?

Yes.

> > > libreoffice-style-colibre :Depends: libreoffice-common (= 
> > > 1:6.3.1-1)
> > > libreoffice-style-tango   :Depends: libreoffice-common (= 1:6.3.1-1)
> > 
> > And of couse the icons need LO to make sense, and far more important,
> > due to dh_linkdocs to save space -common is even needed to have
> > /usr/share/doc (and that one is mandated by policy).
> 
> Policy allows to use separate
> /usr/share/doc/libreoffice-common
> /usr/share/doc/libreoffice-style-colibre and
> /usr/share/doc/libreoffice-style-tango
> directories which are not symlinks and copy the copyright file instead
> and this way you do not have to add an unnecessary dependency.

True.
But this is done for all other _all packages and a exception just for
those can get confusing.

> The provision for the symlink in policy should not be seen as a
> justification for unnecessary dependencies.

And what are you going to do with icons without the rest of LO?

OK; I could recommend it...

Regards,

Rene



Bug#935526: pulseaudio: Pulseaudio no longer recognizes USB devices

2019-09-15 Thread Guus Sliepen
On Mon, Sep 09, 2019 at 08:53:46PM -0300, Felipe Sateler wrote:

> Could you please attach a verbose log of pulseaudio, both versions?
> https://wiki.ubuntu.com/PulseAudio/Log

Attached are the logs from both versions. Let me know if I need to
provide any other information.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


pulseverbose-12.2-4.log.gz
Description: application/gzip


pulseverbose-12.99.2-1.log.gz
Description: application/gzip


signature.asc
Description: PGP signature


Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

2019-09-15 Thread Johannes Schauer
Hi,

Quoting Jonas Smedegaard (2019-09-15 13:18:18)
> If mmdebstrap were to support curl-style URL expansion, then current 
> wrappers for debootstrap supporting only a single string could be abused 
> to pass an expandable set of strings, like this:
> 
> Perhaps mmdebstrab could support curl-style glob expansion of URLs + 
> suite splitting, to allow passing multiple apt lines through wrappers 
> which expects only a single base URL, like this:
> 
>   
> https://{deb.debian.org/debian/dists/{buster,buster-updates},security.debian.org/debian-security/dists/buster/updates}
> 
> expanding to this:
> 
>   https://deb.debian.org/debian buster
>   https://deb.debian.org/debian buster-updates
>   https://security.debian.org/debian-security buster/updates
> 
> Here's a quick one-line that maybe better explains what I mean:
> 
> echo 
> 'https://{deb.debian.org/debian/dists/{buster,buster-updates},security.debian.org/debian-security/dists/buster/updates}'
>  | perl -MFile::Glob=:bsd_glob -nE 'say map { s,/dists/, ,r } bsd_glob($_, 
> GLOB_BRACE | GLOB_NOMAGIC )'
> 

what I still don't understand is why this would be needed.

Currently, if you do:

mmdebstrap buster ./output-directory

Then the resulting sources.list will be equal to what you wrote above.

Maybe I'm just dumb here but could either of you please go back to the start
and try to explain precisely what it is, that you think is missing from
mmdebstrap and why you need it?

Thanks!

cheers, josch


signature.asc
Description: signature


Bug#940028: launching d-i on multiple consoles doesn't play well with preseeding

2019-09-15 Thread Cyril Brulebois
Hi Sergio,

Sergio Gelato  (2019-09-11):
> This seems to be new behaviour since stretch, introduced in version 1.128 of
> package rootskel.

From the rest of your mail I'm assuming you meant buster here.

> I suspect that the two debian-installer instances are racing each
> other. To confirm this, I unpacked initrd.gz, made a simple change to
> sbin/reopen-console (adding inittab entries only for cons in
> $preferred instead of for cons in $consoles), repacked, and run an
> installation again with much better results (no more questions from
> localechooser).
> 
> I do appreciate that for interactive d-i use it's nice to have it show
> up on all consoles; but not at the expense of breaking fully automated
> installation.

Agreed. You're not the only one reporting such issues, and I'd really
like feature authors to fix the regression they introduced. That's not
the first time steal-ctty appears in bug report.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

2019-09-15 Thread Jonas Smedegaard
Quoting Johannes Schauer (2019-09-15 14:58:55)
> Quoting Jonas Smedegaard (2019-09-15 13:18:18)
> > If mmdebstrap were to support curl-style URL expansion, then current 
> > wrappers for debootstrap supporting only a single string could be 
> > abused to pass an expandable set of strings, like this:
> > 
> > Perhaps mmdebstrab could support curl-style glob expansion of URLs + 
> > suite splitting, to allow passing multiple apt lines through 
> > wrappers which expects only a single base URL, like this:
> > 
> >   
> > https://{deb.debian.org/debian/dists/{buster,buster-updates},security.debian.org/debian-security/dists/buster/updates}
> > 
> > expanding to this:
> > 
> >   https://deb.debian.org/debian buster
> >   https://deb.debian.org/debian buster-updates
> >   https://security.debian.org/debian-security buster/updates
> > 
> > Here's a quick one-line that maybe better explains what I mean:
> > 
> > echo 
> > 'https://{deb.debian.org/debian/dists/{buster,buster-updates},security.debian.org/debian-security/dists/buster/updates}'
> >  | perl -MFile::Glob=:bsd_glob -nE 'say map { s,/dists/, ,r } bsd_glob($_, 
> > GLOB_BRACE | GLOB_NOMAGIC )'
> > 
> 
> what I still don't understand is why this would be needed.
> 
> Currently, if you do:
> 
> mmdebstrap buster ./output-directory
> 
> Then the resulting sources.list will be equal to what you wrote above.
> 
> Maybe I'm just dumb here but could either of you please go back to the 
> start and try to explain precisely what it is, that you think is 
> missing from mmdebstrap and why you need it?

Builtin default of mmdebstrap is nice.

Various debootstrap wrappers exist which supports replacing debootstrap 
with an alternative command (e.g. cdebootstrap) but they commonly do not 
support passing arbitrary commandline arguments.

What I (and we, I guess) want is that the nice default be overridable, 
not only by passing options different from debootstrap but also in a way 
supported by these pre-existing debootstrap wrappers.

Example: Bootstrapping a system omitting security updates e.g. because 
an updated linux kernel is broken on my special setup.

Example: Bootstrapping a system additionally including backports.d.o.

Example: Bootstrapping a system additionally including my custom addons.


 - Jonas

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

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


signature.asc
Description: signature


Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

2019-09-15 Thread Johannes Schauer
Hi,

Quoting Jonas Smedegaard (2019-09-15 15:14:13)
> > what I still don't understand is why this would be needed.
> > 
> > Currently, if you do:
> > 
> > mmdebstrap buster ./output-directory
> > 
> > Then the resulting sources.list will be equal to what you wrote above.
> > 
> > Maybe I'm just dumb here but could either of you please go back to the 
> > start and try to explain precisely what it is, that you think is 
> > missing from mmdebstrap and why you need it?
> 
> Builtin default of mmdebstrap is nice.
> 
> Various debootstrap wrappers exist which supports replacing debootstrap 
> with an alternative command (e.g. cdebootstrap) but they commonly do not 
> support passing arbitrary commandline arguments.
> 
> What I (and we, I guess) want is that the nice default be overridable, 
> not only by passing options different from debootstrap but also in a way 
> supported by these pre-existing debootstrap wrappers.

I agree that it's important to allow defaults be overridable.

But even if mmdebstrap would add more options, as you already point out:
wrappers do not allow passing additional options. I guess that's where the idea
of mmdebstrap-sec-repo came from?

> Example: Bootstrapping a system omitting security updates e.g. because 
> an updated linux kernel is broken on my special setup.

You have multiple options:

$ mmdebstrap stable ./output-directory http://deb.debian.org/debian
$ mmdebstrap stable ./output-directory "deb http://deb.debian.org/debian 
stable main"
$ mmdebstrap stable ./output-directory /path/to/sources.list
$ mmdebstrap stable ./output-directory - < /path/to/sources.list

I have added some new entries to the man page that list these to avoid
confusion in the future.

> Example: Bootstrapping a system additionally including backports.d.o.

Just add a "deb http://...; line to mmdebstrap.

> Example: Bootstrapping a system additionally including my custom addons.

Just add a "deb http://...; line to mmdebstrap.

I guess the problem then is, that wrappers don't allow to pass additional
debootstrap options?

I see two ways forward:

 1. file wishlist bugs against the wrappers, asking them to allow passing
additional options to their $DEBOOTSTRAP invocation

 2. create any number of mmdebstrap wrappers that you need which do exactly
what you want

What do you think?

Thanks!

cheers, josch


signature.asc
Description: signature


Bug#940320: matplotlib2 build-depends on package that is cruft in unstable and gone in testing.

2019-09-15 Thread peter green

Package: matplotlib2
Version: 2.2.4-1
Severity: serious

matplotlib2 build-depends on python-cxx-dev, this package is no longer built by 
the pycxx source package. It is still present in unstable as a cruft package, 
but is completely gone from testing.



Bug#940279: wham-align: FTBFS with GCC 9: undefined reference to `pthread_create'

2019-09-15 Thread Graham Inggs
Source: wham-align
Version: 0.1.5-1
Severity: serious
Tags: bullseye sid
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-9

Hi Maintainer

As can be seen on reproducible builds [1], wham-align FTBFS with GCC 9.


Regards
Graham


[1]



g++ -lpthread -o wham sequence.o hash.o embedhash.o main.o aligner.o
interval.o edit_distance.o error.o short.o hitset.o model.o
perfcounters.o writer.o
g++ -lpthread -o wham-build sequence.o hash.o embedhash.o builder.o
aligner.o interval.o edit_distance.o error.o short.o hitset.o model.o
perfcounters.o writer.o
/usr/bin/ld: main.o: in function `align(char*, AlignInfo*, char*, int)':
./main.cpp:466: undefined reference to `pthread_create'
/usr/bin/ld: ./main.cpp:466: undefined reference to `pthread_create'
/usr/bin/ld: ./main.cpp:475: undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
make[1]: *** [makefile:19: wham] Error 1
make[1]: Leaving directory '/build/1st/wham-align-0.1.5'
dh_auto_build: make -j16 "INSTALL=install --strip-program=true"
returned exit code 2



Bug#940280: spoa: FTBFS with GCC 9: some symbols or patterns disappeared

2019-09-15 Thread Graham Inggs
Source: spoa
Version: 3.0.0-1
Severity: serious
Tags: bullseye sid
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-9

Hi Maintainer

As can be seen on reproducible builds [1], spoa FTBFS with GCC 9.

Common build failures are new warnings resulting in build failures
with -Werror turned on, or new/dropped symbols in Debian symbols
files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-9/porting_to.html

GCC 9 also passes the linker option --as-needed by default; typical
build issues are passing libraries before object files to the linker,
or underlinking of convenience libraries built from the same source.

I've include what I think is the relevant part of the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/spoa.html


dpkg-gensymbols: warning: some new symbols appeared in the symbols
file: see diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libspoa3/DEBIAN/symbols doesn't match
completely debian/libspoa3.symbols
--- debian/libspoa3.symbols (libspoa3_3.0.0-1_amd64)
+++ dpkg-gensymbolsVs0TTc 2019-09-01 18:18:56.118394192 -1200
@@ -68,7 +68,8 @@
  _ZNK4spoa5Graph8subgraphEjjRSt6vectorIiSaIiEE@Base 1.1.3
  
_ZNK4spoa5Graph9print_dotERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
1.1.5
  _ZNKSt5ctypeIcE8do_widenEc@Base 1.1.5
- 
_ZNSt10_HashtableIjjSaIjENSt8__detail9_IdentityESt8equal_toIjESt4hashIjENS1_18_Mod_range_hashingENS1_20_Default_ranged_hashENS1_20_Prime_rehash_policyENS1_17_Hashtable_traitsILb0ELb1ELb121_M_insert_unique_nodeEmmPNS1_10_Hash_nodeIjLb0EEEm@Base
1.1.3
+#MISSING: 3.0.0-1#
_ZNSt10_HashtableIjjSaIjENSt8__detail9_IdentityESt8equal_toIjESt4hashIjENS1_18_Mod_range_hashingENS1_20_Default_ranged_hashENS1_20_Prime_rehash_policyENS1_17_Hashtable_traitsILb0ELb1ELb121_M_insert_unique_nodeEmmPNS1_10_Hash_nodeIjLb0EEEm@Base
1.1.3
+ 
_ZNSt10_HashtableIjjSaIjENSt8__detail9_IdentityESt8equal_toIjESt4hashIjENS1_18_Mod_range_hashingENS1_20_Default_ranged_hashENS1_20_Prime_rehash_policyENS1_17_Hashtable_traitsILb0ELb1ELb19_M_rehashEmRKm@Base
3.0.0-1
  _ZNSt11_Deque_baseIjSaIjEE17_M_initialize_mapEm@Base 1.1.3
  _ZNSt11_Deque_baseIjSaIjEED1Ev@Base 1.1.3
  _ZNSt11_Deque_baseIjSaIjEED2Ev@Base 1.1.3
dh_makeshlibs: failing due to earlier errors
make: *** [debian/rules:13: binary] Error 255
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2



Bug#940230: ircd-hybrid: use after free and crash

2019-09-15 Thread Dominic Hargreaves
Control: tags -1 + moreinfo

On Sat, Sep 14, 2019 at 11:54:53AM +0200, Julien Cristau wrote:
> Package: ircd-hybrid
> Version: 1:8.2.24+dfsg.1-1
> Severity: grave
> 
> Hi,
> 
> I just upgraded to buster and ircd keeps crashing.
> One case with a segfault in strcmp, other times with glibc aborts.

Does this happen with a default config file? If not, could you share your
configuration? (feel free to email it to me privately if you don't want
it to be public).

And although I suspect it's not the same problem, could you check whether
you have a dhparam.pem file created where your config file refers to it?
See 

Cheers,
Dominic.



Bug#874907: [hydrogen] Future Qt4 removal from Buster

2019-09-15 Thread Jonas Smedegaard
[sent again, avoiding UTF-8 mail header upsetting Debian mailhost]

Quoting Lisandro Damián Nicanor Pérez Meyer (2019-09-12 23:54:32)
> On Thu, 12 Sep 2019 at 17:37, Lisandro Damián Nicanor Pérez Meyer
>  wrote:
> >
> > On Mon, 30 Jul 2018 19:01:50 +0200 Reiner Herrmann  
> > wrote:
> > > Control: tags -1 + fixed-upstream
> > >
> > > The current upstream beta release supports Qt5.
> > > https://github.com/hydrogen-music/hydrogen/releases/tag/1.0.0-beta1
> >
> > I'll see if I can tackle it during the weekend.
> 
> Uuups, it uses cdbs. I'll prepare the NMU switching to dh. If this is
> not wanted please say so as soon as possible :-)

Thanks for the offer, but please don't if not familiar with CDBS.

I want to migrate to short-form dh but want to to it cautiously.


 - Jonas

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

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


signature.asc
Description: signature


Bug#940309: tmux: Random segfaults

2019-09-15 Thread Romain Francoise
Hi,

On Sun, Sep 15, 2019 at 2:12 PM Kamil Jonca  wrote:
> At random moments tmux segfaults, destroying all sessions.
> in dmesg we have: [...]

Thanks for the report. Can you try with 3.0-rc4 from experimental?



Bug#940318: ITP: lwt-log -- Lwt-friendly logging library

2019-09-15 Thread Stéphane Glondu
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 

* Package name: lwt-log
  Version : 1.1.1
  Upstream Author : Shawn Wagner and Jérémie Dimino
* URL : https://github.com/ocsigen/lwt_log
* License : LGPL-2.0+
  Programming Lang: OCaml
  Description : Lwt-friendly logging library

 Lwt_log is a Lwt-friendly logging library. The library is split into
 two ocamlfind packages. The "basic" lwt_log includes Unix log
 destination support, such as files and syslog, and
 Lwt_daemon. lwt_log.core is the pure-OCaml part of lwt_log, suitable
 for targeting JavaScript in the browser, or elsewhere where Unix is
 not available.

This is a new dependency of lambda-term and obus.

It will be maintained in ocaml-team.


Bug#931950: transition: libgeotiff

2019-09-15 Thread Sebastiaan Couwenberg
On 9/10/19 8:11 AM, Sebastiaan Couwenberg wrote:
> libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1) cannot
> be removed from testing due to gnudatalanguage, which I don't
> understand. But this should be resolved when the package get autoremoved
> on the 14th.

gnudatalanguage was not removed yesterday, it's still marked for removal
on 14 September.

Version 0.9.9-10+b1 of the gnudatalanguage binary packages is in
testing, but 0.9.9-10+b3 is in unstable. It seems that these two NMUs
never migrated to testing.

Can gnudatalanguage (and grib-api) be hinted out of testing to unblock
the removal of libgeotiff-dfsg?

Kind Regards,

Bas

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



Bug#940281: inputlirc: does not start because /run/lirc missing

2019-09-15 Thread Stefan Zechner
Package: inputlirc
Version: 30-1
Severity: important

Dear Maintainer,

I'm using inputlirc without any other lirc packages: dpkg -l|grep lirc
ii  inputlirc 30-1  
 amd64Zeroconf LIRC daemon using input event devices
ii  liblirc-client0:amd64 0.10.1-5.2
 amd64infra-red remote control support - client library

But service is not starting after reboot: systemctl status inputlirc
● inputlirc.service - Zeroconf LIRC daemon using input event devices
   Loaded: loaded (/lib/systemd/system/inputlirc.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-09-15 10:27:36 CEST; 45s 
ago
 Docs: man:inputlircd(8)
  Process: 628 ExecStart=/usr/sbin/inputlircd -f $OPTIONS $EVENTS (code=exited, 
status=71)
 Main PID: 628 (code=exited, status=71)

Sep 15 10:27:36 glotz inputlircd[628]: inputlircd: /dev/input/event5 does not 
support EV_KEY events
Sep 15 10:27:36 glotz inputlircd[628]: /dev/input/event4 3
Sep 15 10:27:36 glotz inputlircd[628]: /dev/input/event3 3
Sep 15 10:27:36 glotz inputlircd[628]: /dev/input/event5 does not support 
EV_KEY events
Sep 15 10:27:36 glotz inputlircd[628]: /dev/input/event2 17
Sep 15 10:27:36 glotz inputlircd[628]: /dev/input/event1 1f
Sep 15 10:27:36 glotz inputlircd[628]: /dev/input/event0 120013
Sep 15 10:27:36 glotz inputlircd[628]: Unable to bind AF_UNIX socket to 
/run/lirc/lircd: No such file or directory
Sep 15 10:27:36 glotz systemd[1]: inputlirc.service: Main process exited, 
code=exited, status=71/OSERR
Sep 15 10:27:36 glotz systemd[1]: inputlirc.service: Failed with result 
'exit-code'.

I have to manually create /run/lirc and: systemctl restart inputlirc 

Any idea what is missing?

Regards,
Stefan


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

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

Versions of packages inputlirc depends on:
ii  libc6  2.28-10

inputlirc recommends no packages.

Versions of packages inputlirc suggests:
ii  input-utils  1.0-1.1+b1
pn  lirc 

-- no debconf information


Bug#940283: Removing python-testtools breaks many packages

2019-09-15 Thread Jelmer Vernooij
Package: src:python-testtools
Version: 2.3.0-6
Severity: serious

The current upload drops the python 2 packages, which are still used by e.g. 
bzr and python-subunit, python-fixtures, python-testscenarios, python-daemon, 
python-fastimport.

Bug#940289: goaccess: not built with --with-openssl

2019-09-15 Thread Simon
Package: goaccess
Version: 1:1.2-4+b10
Severity: normal

Dear Maintainer,

Package is not built with --with-openssl so it is not possible to serve
the realtime html over a tls connection as the WebSocket does not have support.

Trying to pass ssl parameters on the command line gives errors message
goaccess: unrecognized option '--ssl-cert='

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

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

Versions of packages goaccess depends on:
ii  libbz2-1.01.0.6-9.2~deb10u1
ii  libc6 2.28-10
ii  libgeoip1 1.6.12-1
ii  libncurses6   6.1+20181013-2+deb10u1
ii  libtinfo6 6.1+20181013-2+deb10u1
ii  libtokyocabinet9  1.4.48-12
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages goaccess recommends:
ii  geoip-database20181108-1
pn  geoip-database-extra  

goaccess suggests no packages.

-- no debconf information



Bug#940290: q2-types: triangular dependency with q2-types, q2cli

2019-09-15 Thread Bill Allombert
Package: q2-types
Version: 2019.7.0-1
Severity: important

Hello Debian Med Packaging Team,

There is a trianglar dependency between q2-types, q2cli and qiime:

q2-types :Depends: qiime
q2cli:Depends: qiime
qiime:Depends: q2cli, q2-types

Complex circular dependencies are known to cause problems during upgrade, so we
should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



  1   2   3   >