Bug#946197: Let's switch to OpenRC?

[Thomas Goirand]

On 12/6/19 2:30 AM, Benda Xu wrote:
> Hi Thomas,
> 
> Thomas Goirand  writes:
> 
>>> The last time I looked (years ago), there were features in sysvinit
>>> which weren't in OpenRC (yet). IIRC not having concurrent execution of
>>> boot scripts was one of the missing features and the reason for e.g.
>>> our derivative distribution GRML to not switch to OpenRC some years
>>> ago.
>>
>> OpenRC does have parallel execution of scripts, it works well, but when
>> activated, the display output is still a bit ugly. I'm not sure why (I
>> haven't investigated). If the issue is just the screen output, then
>> probably it can be worked on.
> 
> The ugly output is caused by
> /lib/lsb/init-functions.d/20-left-info-blocks from lsb-base.

I don't have such file in my system. Has it moved somewhere else?

> Thomas Goirand  writes:
>> Benda Xu  wrote:
>>> I think it would be time when OpenRC has a systemd .ini parser, to
>>> also make use of systemd units.
>>
>> Do you think this could be written?
> 
> I think so.  It's on my agenda.  Anyone is welcomed is she wants to
> join.

This feels like an exciting feature. I wouldn't know where to start, but
by all means, if I can help, let me know.

Cheers,

Thomas Goirand (zigo)

Bug#946248: ITP: stacer -- Linux system optimizer and monitoring

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: stacer
  Version : 1.1.0
  Upstream Authors: Oguzhan Inan 
* URL : https://github.com/oguzhaninan/Stacer/
* License : GPL-3+
  Description : Linux system optimizer and monitoring
 Monitor your system (CPU, memory, disk) in a graphical application 
(qt).
 Change and monitor your services. Summarizes basic system information 
and

 can show network download/upload speeds/totals.

Package is availabe at http://phd-sid.ethz.ch/debian/stacer/

Bug#946247: nmu: rdkit_201903.1-2

[merkys]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 945985 by -1

nmu rdkit_201903.1-2 . ANY . unstable . -m 'Rebuild against 
libschroedinger-maeparser-dev >= 1.2.2-1'

Hello,

I want to request binNMU for rdkit to rebuild it with newer version of
libschroedinger-maeparser-dev. This should fix #945985.

Thanks,
Andrius

Bug#946246: nvidia-kernel-dkms: Backport 430.64-1 to Buster for compat. with backported 5.3 kernel

[Thomas Lamprecht]

Package: nvidia-kernel-dkms
Version: 430.64-1
Severity: wishlist

Dear Maintainer,

This is a request for considering to backport the the 430.64 based nvidia
graphics driver for Debian Buster.
The backport could be justified with the reason that the 5.3 Kernel landed in
Buster Backports, and the nvidia DKMS version shipped with Buster is not yet
compatible with that kernel.
Re-building the current version from testing (430.64-1) works fine with that
kernel, so it could be a good fit for backporting, IMO.

Thanks for your consideration,
cheers,
Thomas

Bug#946223: [NMU] FTFBS with CGAL 5.0

[Anton Gladky]

Hi Joachim,

thanks for the patch! Yade is building already in experimental,
but not on all archs. I will try to fix it as soon as possible and upload
to unstable.

Regards

Anton

Am Do., 5. Dez. 2019 um 21:27 Uhr schrieb Joachim Reichel :
>
> Source: yade
> Version: 2019.01a-3
> Severity: serious
> Tags: ftbfs
> Control: block 944417 by -1
>
> Hi,
>
> the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS.
> Attached are two patches that fix the problem. In addition, one needs to add
> "Build-Depends: libcgal-dev (>= 5.0~).
>
> Just applying these two patches is not enough due to bug #938859. What is your
> planned timeline for an upload to unstable?
>
> Best regards,
>   Joachim
>
> -- System Information:
> Debian Release: 10.2
>   APT prefers stable-debug
>   APT policy: (800, 'stable-debug'), (800, 'stable'), (700, 'testing-debug'), 
> (700, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#946229: [NMU] FTFBS with CGAL 5.0

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Joachim,

On 12/5/19 10:22 PM, Joachim Reichel wrote:
> the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS. I
> intend to NMU the package with the attached diff to DELAYED/5-day.

Thanks for the patch. There is no need for an NMU, I've uploaded a new
revision.

Kind Regards,

Bas

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

Bug#914821: libio-pty-perl: New upstream version - 1.12

[Xavier]

Le 05/12/2019 à 17:17, gregor herrmann a écrit :
> On Thu, 05 Dec 2019 12:15:27 +0100, Joergen Haegg wrote:
> 
>>> Also if you want, package maintainance can be taken under Pkg-Perl umbrella.
>> That would probably be better.
> 
> Excellent, thank you!
> 
> So who wants to do the takeover? Felix, Xavier? I can as well.

Hi,

I'm going to takeover

Bug#946245: new version available

[Gürkan Myczko]

Package: ansible
Version: 2.8.6+dfsg-1
Severity: wishlist

There's a newer version:
https://github.com/ansible/ansible/releases

Thank you,
Gürkan

Bug#946244: new version available

[Gürkan Myczko]

Package: hdfview
Version: 2.11.0+dfsg-3
Severity: wishlist

There's a new homepage, and newer version:
https://www.hdfgroup.org/downloads/hdfview/

Thank you,
Gürkan

Bug#946243: kde-config-sddm:obsolete-conffile /etc/dbus-1/system.d/org.kde.kcontrol.kcmsddm.conf

[shirish शिरीष]

Package: kde-config-sddm
Version: 4:5.14.5-1+b1
Severity: normal

User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

See adequate [1]

$ pkg=kde-config-sddm ; adequate $pkg ; dpkg-query -W
-f='${Conffiles}\n' $pkg | grep obsolete
kde-config-sddm: obsolete-conffile
/etc/dbus-1/system.d/org.kde.kcontrol.kcmsddm.conf
 /etc/dbus-1/system.d/org.kde.kcontrol.kcmsddm.conf
4b4fa6f5ba4d7cddd27948c85813e8ce obsolete

1.  https://salsa.debian.org/debian/adequate

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

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

Versions of packages kde-config-sddm depends on:
ii  kio 5.62.1-2+b1
ii  libc6   2.29-3
ii  libkf5archive5  5.62.0-1
ii  libkf5authcore5 5.62.0-1+b1
ii  libkf5configcore5   5.62.0-1+b1
ii  libkf5configwidgets55.62.0-1+b1
ii  libkf5coreaddons5   5.62.0-1
ii  libkf5i18n5 5.62.0-1
ii  libkf5kiowidgets5   5.62.1-2+b1
ii  libkf5newstuff5 5.62.0-1+b1
ii  libkf5widgetsaddons55.62.0-1+b1
ii  libqt5core5a5.12.5+dfsg-2
ii  libqt5gui5  5.12.5+dfsg-2
ii  libqt5quickwidgets5 5.12.5-3
ii  libqt5widgets5  5.12.5+dfsg-2
ii  libqt5x11extras55.12.5-1
ii  libstdc++6  9.2.1-21
ii  libx11-62:1.6.8-1
ii  libxcursor1 1:1.2.0-2
ii  qml-module-qtquick-layouts  5.12.5-3
ii  qml-module-qtquick2 5.12.5-3

kde-config-sddm recommends no packages.

kde-config-sddm suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#946242: fatal: privsep_preauth: preauth child terminated by signal 31

[crunch]

Package: openssh-server
Version: 1:7.9p1-10+deb10u1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation? apt upgrade lead to openssh-server
   * being unusable.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?  bug #941663 supposedly fixed this issue in the
 version I upgraded to but the symptom remains. Also tried
 installing 8.1 version but that did not fix the issue either. I am
 running a 3.16 kernel because a 4.x kernel is not supported on my 
 hardware (AMD Geode LX processor).
   * What was the outcome of this action? no change
   * What outcome did you expect instead? to login

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


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

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

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

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

-- Configuration Files:
/etc/default/ssh changed:
SSHD_OPTS=-4


-- debconf information:
* ssh/use_old_init_script: true
* openssh-server/permit-root-login: true
  ssh/encrypted_host_key_but_no_keygen:
  openssh-server/password-authentication: false
  ssh/vulnerable_host_keys:
  ssh/new_config: true
  ssh/disable_cr_auth: false

Bug#946241: ffmpeg: please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: ffmpeg
Version: 7:4.2.1-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The ffmpeg tests currently fail in this environment, one because it is a
build test that does not invoke the toolchain in a cross-aware manner, and
another because it references a test dependency (libavcodec-extras) that
can't be installed as a foreign arch dependency.

I've verified that the attached patch lets the tests successfully build (and
run) i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ffmpeg-4.2.1/debian/tests/control ffmpeg-4.2.1/debian/tests/control
--- ffmpeg-4.2.1/debian/tests/control   2019-11-01 18:17:31.0 -0700
+++ ffmpeg-4.2.1/debian/tests/control   2019-12-05 17:17:44.0 -0800
@@ -5,4 +5,4 @@
 Depends: ffmpeg
 
 Tests: encdec-extra
-Depends: ffmpeg, libavcodec-extra
+Depends: ffmpeg, libavcodec-extra58
diff -Nru ffmpeg-4.2.1/debian/tests/examples ffmpeg-4.2.1/debian/tests/examples
--- ffmpeg-4.2.1/debian/tests/examples  2019-11-01 18:17:31.0 -0700
+++ ffmpeg-4.2.1/debian/tests/examples  2019-12-05 17:29:02.0 -0800
@@ -10,6 +10,10 @@
 cp -r /usr/share/doc/ffmpeg/examples ./
 cd examples
 
+if [ -n "$DEB_HOST_MULTIARCH" ]; then
+export CC="$DEB_HOST_GNU_TYPE-gcc"
+export PKG_CONFIG_PATH="/usr/lib/$DEB_HOST_MULTIARCH/pkgconfig"
+fi
 echo "building the examples..."
 ret=0
 make -k all 2>&1

Bug#946196: udev: documented way to prevent interface renaming stopped working

[Benjamin Poirier]

On 2019/12/05 11:34, Michael Biebl wrote:
[...]
> 
> The old 73-usb-net-by-mac.rules file contained:
> 
> TEST!="/etc/systemd/network/99-default.link", \
> 
> This check can't be expressed via .link files.
> The new 73-usb-net-by-mac.link link file does respect the net.ifnames=0
> kernel command line parameter, though.
> 
> I don't see a good way of fixing this with .link files, aside from
> documenting this change. We could say that users have to symlink
> 73-usb-net-by-mac.link as well (or symlink 80-net-setup-link.rules,
> which does the actual renaming).

I think documenting that 73-usb-net-by-mac.link needs to be symlinked as
well is the best approach. It diverges from the upstream instructions in
eg.
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/#idontlikethishowdoidisablethis
but then, Debian diverges from upstream by adding
73-usb-net-by-mac.rules or .link.

> 
> The other alternative would be to revert the changes from #941636, but I
> kinda like the new .link based approach and would prefer to keep it.
> 
> Thoughts?

Like I pointed out in 941636, that simple TEST for the existence of
/etc/systemd/network/99-default.link is too basic and can lead to
counterintuitive behavior as well:

> This is an incomplete way of reimplementing udev functionality. In
> particular, the user will get a different behavior if they do
>   $ cp /lib/systemd/network/99-default.link /etc/systemd/network/
> even though the naming rules are effectively the same.

So I don't think it was good.


signature.asc
Description: PGP signature

Bug#946201: ibus: some keystrokes are taken in account

[gpe]

Le vendredi 06 décembre 2019 à 10:18 +0900, Changwoo Ryu a écrit :
> Control: tags -1 + moreinfo
> 
> 2019년 12월 5일 (목) 오후 7:06, gpe92 님이 작성:
> > Package: ibus
> > Version: 1.5.21-3
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > Since ibus comes in testing I encounter lot of problems with keystrokes
> > which are not taken in account. Especially the accentuated characters
> > (french keyboard) and some specific characters, for example * needs to
> > be stroke 4 or 5 times before taking in account.
> > Another problem is that the compose key is no longer take in account ...
> 
> I can't reproduce it with GNOME/X11 session and fr layout. I had no
> problem to input accentuated characters, asterisk, the AltGr key.
> 
> Please be more specific. Which application did you use? Does it occur
> in all applications and always?

It is in all applications: terminal, galculator, evolution, etc.
After discussion on debian-user-french it seems that I'm not the alone which is
encountering this problem.

> 
> > == locale ==
> > LANG=fr_FR.UTF-8
> > LANGUAGE=
> > LC_CTYPE="C"
> > LC_NUMERIC="C"
> > LC_TIME="C"
> > LC_COLLATE="C"
> > LC_MONETARY="C"
> > LC_MESSAGES="C"
> > LC_PAPER="C"
> > LC_NAME="C"
> > LC_ADDRESS="C"
> > LC_TELEPHONE="C"
> > LC_MEASUREMENT="C"
> > LC_IDENTIFICATION="C"
> > LC_ALL=C
> 
> This can be a problem. 'C" locale is basically ASCII only so some
> characters won't be input in some applications.

It is weird because if I input locale command in a terminal I get:

LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC=fr_FR.UTF-8
LC_TIME=fr_FR.UTF-8
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY=fr_FR.UTF-8
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER=fr_FR.UTF-8
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT=fr_FR.UTF-8
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

Bug#716334: [Mayhem] Bug report on sunpinyin-utils: slmthread crashes with exit status 139

[Changwoo Ryu]

Control: forcemerge 716334 716344 716401 716402 716403
Control: forwarded 716334 https://github.com/sunpinyin/sunpinyin/issues/98
Control: retitle 716334 sunpinyin-utils: Crashes by missing fopen()
failure checks

Still reproducible. All these crashes are by missing fopen() error
checks. Merging bugs.

Bug#946197: Let's switch to OpenRC?

[Benda Xu]

Hi Thomas,

Thomas Goirand  writes:

>> The last time I looked (years ago), there were features in sysvinit
>> which weren't in OpenRC (yet). IIRC not having concurrent execution of
>> boot scripts was one of the missing features and the reason for e.g.
>> our derivative distribution GRML to not switch to OpenRC some years
>> ago.
>
> OpenRC does have parallel execution of scripts, it works well, but when
> activated, the display output is still a bit ugly. I'm not sure why (I
> haven't investigated). If the issue is just the screen output, then
> probably it can be worked on.

The ugly output is caused by
/lib/lsb/init-functions.d/20-left-info-blocks from lsb-base.

Thomas Goirand  writes:

> Benda Xu  wrote:
>> I think it would be time when OpenRC has a systemd .ini parser, to
>> also make use of systemd units.
>
> Do you think this could be written?

I think so.  It's on my agenda.  Anyone is welcomed is she wants to
join.

Yours,
Benda

Bug#946201: ibus: some keystrokes are taken in account

[Changwoo Ryu]

Control: tags -1 + moreinfo

2019년 12월 5일 (목) 오후 7:06, gpe92 님이 작성:
>
> Package: ibus
> Version: 1.5.21-3
> Severity: normal
>
> Dear Maintainer,
>
> Since ibus comes in testing I encounter lot of problems with keystrokes
> which are not taken in account. Especially the accentuated characters
> (french keyboard) and some specific characters, for example * needs to
> be stroke 4 or 5 times before taking in account.
> Another problem is that the compose key is no longer take in account ...

I can't reproduce it with GNOME/X11 session and fr layout. I had no
problem to input accentuated characters, asterisk, the AltGr key.

Please be more specific. Which application did you use? Does it occur
in all applications and always?

> == locale ==
> LANG=fr_FR.UTF-8
> LANGUAGE=
> LC_CTYPE="C"
> LC_NUMERIC="C"
> LC_TIME="C"
> LC_COLLATE="C"
> LC_MONETARY="C"
> LC_MESSAGES="C"
> LC_PAPER="C"
> LC_NAME="C"
> LC_ADDRESS="C"
> LC_TELEPHONE="C"
> LC_MEASUREMENT="C"
> LC_IDENTIFICATION="C"
> LC_ALL=C

This can be a problem. 'C" locale is basically ASCII only so some
characters won't be input in some applications.

Bug#946197: Let's switch to OpenRC?

[Thorsten Glaser]

On Thu, 5 Dec 2019, Thomas Goirand wrote:

> Thorsten Glaser 
> > Dropping sysvinit as it works and as admins know... no.
> > Absolutely NOT.
>
> Thorsten, do you have any point of argumentation besides "it works and
> we know it"? That's IMO a bit light...

I don’t want to learn a new init system. If I couldn’t have sysvinit
I’d likely go with systemd for knowledge reusability, even though it’s
a fat, intrusive, pile of things.

I’m a BSD person, I never even liked sysvinit and sysv-rc (I ran file-rc
for a while but it was not good eiter). I keep it, though, because it’s
proven, well-known, low-overhead technology.

So, by all means, add OpenRC support, but absolutely not at the cost of
something we can currently have. If it’s not possible to have both, I’ll
fight tooth and nails against OpenRC.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"

Bug#946239: lynkeos.app: missing Breaks+Replaces: lynkeos.app-common (<< 3.3+dfsg1)

[Andreas Beckmann]

Package: lynkeos.app
Version: 3.3+dfsg1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../96-lynkeos.app_3.3+dfsg1-1_amd64.deb ...
  Unpacking lynkeos.app (3.3+dfsg1-1) over (3.1+dfsg1-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-23KNpX/96-lynkeos.app_3.3+dfsg1-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/icons/Lynkeos_128x128x32.png', which is also 
in package lynkeos.app-common 3.1+dfsg1-2

There are B+R against not existing lynkeos-common (<< 3.3+dfsg1).


cheers,

Andreas


lynkeos.app_3.3+dfsg1-1.log.gz
Description: application/gzip

Bug#946240: grub-xen-host: Missing ARM Build

[Elliott Mitchell]

Package: grub-xen-host
Version: 2.04-4

grub-xen-host is only being built for i386 and amd64.  Xen includes
support for *some* ARM processors and so grub-xen-host should be
available for arm64 and armhf (I'm unsure about armel, a guest might run
armel, I don't know whether that is compatible with an armhf build).


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#946238: openstack-dashboard-apache: modifies conffiles (policy 10.7.3): /etc/openstack-dashboard/local_settings.d/_0005_debian_webroot.py

[Andreas Beckmann]

Package: openstack-dashboard-apache
Version: 3:16.0.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + openstack-dashboard

Hi,

during a test with piuparts I noticed your package modifies conffiles.
This is forbidden by the policy, see
https://www.debian.org/doc/debian-policy/ch-files.html#configuration-files

10.7.3: "[...] The easy way to achieve this behavior is to make the
configuration file a conffile. [...] This implies that the default
version will be part of the package distribution, and must not be
modified by the maintainer scripts during installation (or at any
other time)."

Note that once a package ships a modified version of that conffile,
dpkg will prompt the user for an action how to handle the upgrade of
this modified conffile (that was not modified by the user).

Further in 10.7.3: "[...] must not ask unnecessary questions
(particularly during upgrades) [...]"

If a configuration file is customized by a maintainer script after
having asked some debconf questions, it may not be marked as a
conffile. Instead a template could be installed in /usr/share and used
by the postinst script to fill in the custom values and create (or
update) the configuration file (preserving any user modifications!).
This file must be removed during postrm purge.
ucf(1) may help with these tasks.
See also https://wiki.debian.org/DpkgConffileHandling

In https://lists.debian.org/debian-devel/2012/09/msg00412.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

debsums reports modification of the following files,
from the attached log (scroll to the bottom...):

  /etc/openstack-dashboard/local_settings.d/_0005_debian_webroot.py

(This file is owned by openstack-dashboard.)


cheers,

Andreas


openstack-dashboard-apache_3:16.0.0-2.log.gz
Description: application/gzip

Bug#944389: LXC seems very untested under cgroup2 / unified hierarchy

[Ryutaroh Matsumoto]

LXC (github master branch) shows lots of problem when host Linux booted with
systemd.unified_cgroup_hierarchy, and it seems very untested to me.
I was able to find lots of problems as below.

https://github.com/lxc/lxc/issues/3211
https://github.com/lxc/lxc/issues/3208
https://github.com/lxc/lxc/issues/3206
https://github.com/lxc/lxc/issues/3201 (closed but the bug still exists)
https://github.com/lxc/lxc/issues/3198

In addition, the upstream developer seems reluctant to admit a problem, see
https://github.com/lxc/lxc/issues/3201

Ryutaroh

Bug#946231: Versions, Upstream version versus Debian version

[Simon McVittie]

On Thu, 05 Dec 2019 at 23:07:00 +0100, Geert Stappers wrote:
> Upstream is at version 0.116 ( 
> https://gitlab.freedesktop.org/polkit/polkit/-/tags )
> Debian version is 0.105-something ( 
> https://salsa.debian.org/utopia-team/polkit/blob/master/debian/changelog )
> 
> Debian changelog talks about changes from upstream version 0.114 and 0.116.

The latest upstream version is available in experimental.

The version in unstable is exactly what its version number indicates:
a very old upstream version, with the majority of the upstream changes
from later versions backported into it via debian/patches.

The reason for this is that upstream version
0.106 removed the "localauthority" backend (which
configures polkit via .ini-style files like for example
/var/lib/polkit-1/localauthority/10-vendor.d/org.freedesktop.Flatpak.pkla,
which can be overridden by sysadmin configuration in
/etc/polkit-1/localauthority or /var/lib/polkit-1/localauthority)
and replaced it with a new JavaScript-based backend (which
configures polkit via short JavaScript fragments like for example
/usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules, which can be
overridden by sysadmin configuration in /etc/polkit-1/rules.d).

The migration path between the two is not obvious, and some of the Debian
maintainers of polkit are strongly opposed to it being configured with
JavaScript files, so at the moment we are stuck with polkit 0.105.

One day, I want to stop patching changes from 0.11x into 0.105,
and instead start patching the "localauthority" backend into 0.11x,
so that we can stick to the upstream version in all respects except
for the configuration backend. However, all the maintainers of polkit
(both in Debian and upstream) mostly work on other things, so it's rare
that someone has enough uninterrupted time to do something like that.

There has been some upstream unhappiness with the current configuration
arrangements, mostly because the mozjs library that is used for the
JavaScript interpreter does not have a stable API; so it is possible that
a newer upstream version will either change the configuration language
(again), or change the JavaScript implementation to something more friendly
(most likely a smaller interpreter like duktape).

smcv

Bug#946126: lintian: Please complain about debian/NEWS.Debian

[Felix Lechner]

Hi Vincent,

On Thu, Dec 5, 2019 at 3:52 PM McIntyre, Vincent (CASS, Marsfield)
 wrote:
>
> I really don't know what's better. I lean toward adding it.

Lowercase 'd' added here:


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

Kind regards
Felix Lechner

Bug#429510: lintian check

[McIntyre, Vincent (CASS, Marsfield)]

Hello

lintian is now checking for this case (NEWS|TODO), see #946126.

Regards
Vince

Bug#946126: lintian: Please complain about debian/NEWS.Debian

[McIntyre, Vincent (CASS, Marsfield)]

On Thu, Dec 05, 2019 at 03:13:09PM -0800, Felix Lechner wrote:
>Hi Vincent,
>
>On Thu, Dec 5, 2019 at 2:32 PM McIntyre, Vincent (CASS, Marsfield)
> wrote:
>>

>> +} elsif ($basename =~ 
>> m/^(?:.*\.)?(?:changelog|NEWS|TODO).[dD]ebian$/o) {
>
>My check does not currently implement the lowercase 'd'. Please let me
>know if you would like to have it.

I really don't know what's better. I lean toward adding it.

>> Do you think there should be some restriction to avoid this warning
>> when something other than debhelper is in use?
>
>On something like this, which is both useful and rare, I will wait for
>bug reports to complain.

Sounds like the right choice to me.


>> I'm not sure what that something other would be.
>
>There are other build systems. You can find a relative measure of
>their popularity on https://trends.debian.net/#build-systems.
>

>>  - debian/README is ignored
>
>I am reluctant to do anything about it. Is the file sometimes used for
>unpublished developer notes?

I don't know, it seems possible. Now I'm reluctant too.

>>  - debian/TODO gets shipped as /usr/share/doc/rkhunter/TODO.Debian,
>>ie not gzipped.
>>  - debian/TODO.Debian is ignored.
>
>Thanks for looking into it. I also added TODO:
>
>
> https://salsa.debian.org/lintian/lintian/commit/54e2611c0a65d5377ddb0abb055b8105019e974b
>
>> This was debhelper 12.1.1~bpo9+1, if that matters.
>
>You may wish to amend #429510 with information about the new Lintian
>tags if they work for you. You could even mention the unison bug and
>gently remind the debhelper folks that the issue remains open.
>

Ok.

Regards
Vince

Bug#946197: Let's switch to OpenRC?

[Axel Beckert]

Hi Thomas,

Thomas Goirand wrote:
> > Maybe packages can ship them somewhere else than default, and openrc
> > uses dpkg-divert to get them into the expected path if and only if
> > openrc is installed.
> 
> Files in /etc/init.d are CONFFILE files. I don't think dpkg-divert works
> with CONFFILE files (does it?).

I think it does kinda work for most cases, but it is IIRC neither
supported nor recommended. Thanks for reminding me of that point!

> Even if it did work, we cannot have OpenRC reimplement all of the
> init scripts of Debian, these must be carried in each packages.

I would expect a fallback as systemd does. Init-scripts are the lowest
common denominator as they can be used as fallback for at least the
three best-known init systems in Buster. (I have no experience with
runit, s6, pid1, tini, dumb-init and maybe the one or two other
(container?) init systems of which I forgot the name.)

> > P.S.: One of the really cool things about Buster is that it offers 5
> > or 6 different init systems! Now that's what I call diversity.
> 
> How many of them have good support in every package?

None anymore. The only one which ever had that was sysvinit.

P.S.: Anyone ever has taken metainit into account in this discussion?
I must admit, I just stumbled upon it.

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

Bug#946170: libpam-cgfs: does nothing under cgroupv2 / unified hierarchy

[Ryutaroh Matsumoto]

The upstream maintainer seems to think that libpam-cgfs cannot work
under cgroup2 / unified hierarchy
as seen in the discussion of
https://github.com/lxc/lxc/issues/3198

Ryutaroh

Bug#909740: libsdl2-dev: No longer multi-arch co-installable

[Felix Geyer]

Hi Simon,

On 27.11.19 20:18, Simon McVittie wrote:
> In an attempt to unblock this bug I've implemented several versions of a
> solution to it, so that the SDL2 maintainers can choose their favourite
> and merge it.
>
> [...]
>
> Do the SDL2 maintainers have any comments on these MRs, or preference
> between them?

Thanks a lot for putting in all the work to implement, test and summarize them!

I'm leaning towards patching sdl2-config to call pkg-config
(https://salsa.debian.org/sdl-team/libsdl2/merge_requests/5).
My hope is that most software uses pkg-config or cmake to find SDL2.
This solution wouldn't introduce any weirdness (forwarding header) into
the default use cause.

I'll merge that one unless someone wants to convince me otherwise soon ;)

Cheers,
Felix

Bug#946236: aom: please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: aom
Version: 1.0.0.errata1-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The aom tests currently fail in this environment, because they are build
tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru aom-1.0.0.errata1/debian/tests/library-build 
aom-1.0.0.errata1/debian/tests/library-build
--- aom-1.0.0.errata1/debian/tests/library-build2019-09-01 
05:28:49.0 -0700
+++ aom-1.0.0.errata1/debian/tests/library-build2019-12-05 
15:26:36.0 -0800
@@ -10,10 +10,14 @@
 cp debian/tests/library-build.c "$AUTOPKGTEST_TMP"
 cd "$AUTOPKGTEST_TMP"
 
+if [ -n "$DEB_HOST_MULTIARCH" ]; then
+export PKG_CONFIG_PATH="/usr/lib/$DEB_HOST_MULTIARCH/pkgconfig"
+PREFIX="$DEB_HOST_GNU_TYPE-"
+fi
 # Compile with and without pkg-config
-gcc -Wall -Wextra -O2 library-build.c -o build1 -laom
+${PREFIX}gcc -Wall -Wextra -O2 library-build.c -o build1 -laom
 echo "build1: compiled"
-gcc -Wall -Wextra -O2 $(pkg-config --cflags aom) library-build.c -o build2 
$(pkg-config --libs aom)
+${PREFIX}gcc -Wall -Wextra -O2 $(pkg-config --cflags aom) library-build.c -o 
build2 $(pkg-config --libs aom)
 echo "build2: compiled"
 
 # Run the tests

Bug#946235: atk1.0: please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: atk1.0
Version: 2.34.1-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The atk1.0 tests currently fail in this environment, because they are build
tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru atk1.0-2.34.1/debian/tests/build atk1.0-2.34.1/debian/tests/build
--- atk1.0-2.34.1/debian/tests/build2019-10-10 03:34:07.0 -0700
+++ atk1.0-2.34.1/debian/tests/build2019-12-05 15:11:11.0 -0800
@@ -22,7 +22,11 @@
 }
 EOF
 
-gcc -Wall -Werror -o atk1.0-dev_test atk1.0-dev_test.c `pkg-config --cflags 
--libs atk`
+if [ -n "$DEB_HOST_MULTIARCH" ]; then
+export PKG_CONFIG_PATH="/usr/lib/$DEB_HOST_MULTIARCH/pkgconfig"
+PREFIX="$DEB_HOST_GNU_TYPE-"
+fi
+${PREFIX}gcc -Wall -Werror -o atk1.0-dev_test atk1.0-dev_test.c `pkg-config 
--cflags --libs atk`
 echo "build: OK"
 [ -x atk1.0-dev_test ]
 ./atk1.0-dev_test
diff -Nru atk1.0-2.34.1/debian/tests/tests atk1.0-2.34.1/debian/tests/tests
--- atk1.0-2.34.1/debian/tests/tests2019-10-10 03:34:07.0 -0700
+++ atk1.0-2.34.1/debian/tests/tests2019-12-05 15:12:09.0 -0800
@@ -4,8 +4,12 @@
 
 WORKDIR=$AUTOPKGTEST_TMP
 
+if [ -n "$DEB_HOST_MULTIARCH" ]; then
+export PKG_CONFIG_PATH="/usr/lib/$DEB_HOST_MULTIARCH/pkgconfig"
+PREFIX="$DEB_HOST_GNU_TYPE-"
+fi
 for i in testdocument testrole testrelation teststateset testvalue ; do
-   gcc tests/$i.c -o $WORKDIR/$i $(pkg-config --cflags --libs atk)
+   ${PREFIX}gcc tests/$i.c -o $WORKDIR/$i $(pkg-config --cflags --libs atk)
echo "build: OK"
[ -x $WORKDIR/$i ]
$WORKDIR/$i

Bug#946114: FTFBS with CGAL 5.0 (NMU)

[Joachim Reichel]

Uploaded to DELAYED/5-day.

Bug#946126: lintian: Please complain about debian/NEWS.Debian

[Felix Lechner]

Hi Vincent,

On Thu, Dec 5, 2019 at 2:32 PM McIntyre, Vincent (CASS, Marsfield)
 wrote:
>
> I can't see anything in policy that requires these naming minutiae.

We would like to shed the image of enforcer. Only a few Lintian tags
relate to policy. Lintian provides packaging advice for the benefit of
maintainers.

> +} elsif ($basename =~ 
> m/^(?:.*\.)?(?:changelog|NEWS|TODO).[dD]ebian$/o) {

My check does not currently implement the lowercase 'd'. Please let me
know if you would like to have it.

> Do you think there should be some restriction to avoid this warning
> when something other than debhelper is in use?

On something like this, which is both useful and rare, I will wait for
bug reports to complain.

> I'm not sure what that something other would be.

There are other build systems. You can find a relative measure of
their popularity on https://trends.debian.net/#build-systems.

>  - debian/README is ignored

I am reluctant to do anything about it. Is the file sometimes used for
unpublished developer notes?

>  - debian/TODO gets shipped as /usr/share/doc/rkhunter/TODO.Debian,
>ie not gzipped.
>  - debian/TODO.Debian is ignored.

Thanks for looking into it. I also added TODO:


https://salsa.debian.org/lintian/lintian/commit/54e2611c0a65d5377ddb0abb055b8105019e974b

> This was debhelper 12.1.1~bpo9+1, if that matters.

You may wish to amend #429510 with information about the new Lintian
tags if they work for you. You could even mention the unison bug and
gently remind the debhelper folks that the issue remains open.

Kind regards,
Felix Lechner

Bug#944417: Bug#946119: binNMU for gudhi, openems, and pygalmesh

[Joachim Reichel]

Hi Paul,

On 05.12.19 10:20, Paul Gevers wrote:
> Note: there is no need to create a new bug report for binNMU's that are
> part of a transition with a transition bug.

ok, thanks.

> That said, mips64el and mipsel FTBFS, can you please check what's going on?

I uploaded -4 which should fix this.

> On 04-12-2019 00:02, Joachim Reichel wrote:
>> please schedule binNMUs for gudhi, openems, and pygalmesh to support the
>> cgal_5.0 transition (see bug #944417).

Looking at the logs for pygalmesh I noticed that a binNMU will most likely not
work (see bug #946234). I'll prepare an NMU.

  Joachim

Bug#946234: [NMU] FTFBS with CGAL 5.0 (if cmake is absent)

[Joachim Reichel]

Source: pygalmesh
Version: 0.4.0-1
Severity: serious
Tags: ftbfs
Control: block 944417 by -1

Hi,

the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS (if
cmake is not present, see the other bug I just filed). I intend to NMU the
package with the attached diff to DELAYED/5-day.

Best regards,
  Joachim
diff -Nru pygalmesh-0.4.0/debian/changelog pygalmesh-0.4.0/debian/changelog
--- pygalmesh-0.4.0/debian/changelog2019-08-18 18:42:35.0 +0200
+++ pygalmesh-0.4.0/debian/changelog2019-12-05 23:07:13.0 +0100
@@ -1,3 +1,11 @@
+pygalmesh (0.4.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to fix FTBFS with CGAL >= 5.0 (Closes: #xx).
+  * Add Build-Depends: libcgal-dev (>= 5.0~).
+
+ -- Joachim Reichel   Thu, 05 Dec 2019 23:07:13 +0100
+
 pygalmesh (0.4.0-1) unstable; urgency=medium
 
   * set debian/watch to track upstream git tags,
diff -Nru pygalmesh-0.4.0/debian/control pygalmesh-0.4.0/debian/control
--- pygalmesh-0.4.0/debian/control  2019-08-18 18:42:35.0 +0200
+++ pygalmesh-0.4.0/debian/control  2019-12-05 23:07:13.0 +0100
@@ -5,7 +5,7 @@
 Uploaders: Drew Parsons 
 Build-Depends: debhelper-compat (= 12),
  dh-python, python3-all-dev, python3-setuptools,
- libcgal-dev,
+ libcgal-dev (>= 5.0~),
  libeigen3-dev,
  pandoc,
  python3-meshio,
diff -Nru pygalmesh-0.4.0/debian/patches/series 
pygalmesh-0.4.0/debian/patches/series
--- pygalmesh-0.4.0/debian/patches/series   1970-01-01 01:00:00.0 
+0100
+++ pygalmesh-0.4.0/debian/patches/series   2019-12-05 23:06:31.0 
+0100
@@ -0,0 +1 @@
+use-cgal-in-header-only-mode.patch
diff -Nru pygalmesh-0.4.0/debian/patches/use-cgal-in-header-only-mode.patch 
pygalmesh-0.4.0/debian/patches/use-cgal-in-header-only-mode.patch
--- pygalmesh-0.4.0/debian/patches/use-cgal-in-header-only-mode.patch   
1970-01-01 01:00:00.0 +0100
+++ pygalmesh-0.4.0/debian/patches/use-cgal-in-header-only-mode.patch   
2019-12-05 23:07:13.0 +0100
@@ -0,0 +1,14 @@
+Index: pygalmesh-0.4.0/setup.py
+===
+--- pygalmesh-0.4.0.orig/setup.py
 pygalmesh-0.4.0/setup.py
+@@ -48,8 +48,7 @@ ext_modules = [
+ get_pybind_include(),
+ get_pybind_include(user=True),
+ ],
+-# CGAL_ImageIO for generate_from_inr
+-libraries=["CGAL", "CGAL_ImageIO", "gmp", "mpfr"],
++libraries=["stdc++", "gmp", "mpfr"],
+ )
+ ]
+ 

Bug#946233: Non-deterministic build depending on presence of cmake

[Joachim Reichel]

Source: pygalmesh
Version: 0.4.0
Severity: normal

Hi,

as already pointed in bug #933848: the build system behaves completely
different based on the presence or absence of cmake.

With cmake:

---
 debian/rules build
dh build --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:217: dh_auto_configure --buildsystem=cmake 
--builddirectory="/mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build"
 -- -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.8 
-DPYTHON_LIBRARY:FILEPATH=/usr/lib/python3.8/config-3.8-x86_64-linux-gnu/libpython3.8.so
 -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.8 
cd .pybuild/cpython3_3.8_pygalmesh/build && cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.8 
-DPYTHON_LIBRARY:FILEPATH=/usr/lib/python3.8/config-3.8-x86_64-linux-gnu/libpython3.8.so
 -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.8 ../../..
---

Without cmake:

---
 debian/rules build
dh build --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:217: python3.8 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0'
dh_auto_build
I: pybuild base:217: /usr/bin/python3.8 setup.py build 
running build
running build_py
creating 
/mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh
copying pygalmesh/__about__.py -> 
/mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh
copying pygalmesh/cli.py -> 
/mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh
copying pygalmesh/main.py -> 
/mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh
copying pygalmesh/__init__.py -> 
/mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh
[...]
---

You should either add a Build-Depends or Build-Conflicts on cmake to make the
build deterministic.

With cmake, a binNMU would have been sufficient for the CGAL 5.0 transition.
Without cmake (which is likely the case on the buildds), a sourceful upload is
necessary.

Best regards,
  Joachim

Bug#946126: lintian: Please complain about debian/NEWS.Debian

[McIntyre, Vincent (CASS, Marsfield)]

On Thu, Dec 05, 2019 at 09:50:32AM -0800, Felix Lechner wrote:

>Implemented for NEWS, which was your primary concern:
>
>
> https://salsa.debian.org/lintian/lintian/commit/ae38f4d7301ba8a6064025b86984d49843d61355
>

Looks awesome. I was working on a hack but this is much better.
One question though. This is primarily an issue for debhelper,
I can't see anything in policy that requires these naming minutiae.
So when I started hacking I was playing with checks/debhelper.pm,
something like

--- a/checks/debhelper.pm
+++ b/checks/debhelper.pm
@@ -401,6 +401,9 @@ sub run {
 # Handle "control", [.]copyright, [.]changelog
 # and [.]NEWS
 _tag_if_executable($file);
+} elsif ($basename =~ 
m/^(?:.*\.)?(?:changelog|NEWS|TODO).[dD]ebian$/o) {
+# Debhelper will ignore changelog-ish files with a .Debian suffix
+tag 'dh-misnamed-changelog-in-source', $file;
 } elsif ($basename =~ m/^ex\.|\.ex$/i) {
 tag 'dh-make-template-in-source', $file;
 } elsif ($basename =~ m/^(?:(.*)\.)?maintscript$/) {

Do you think there should be some restriction to avoid this warning
when something other than debhelper is in use? I'm not sure what
that something other would be.

>> There may already be a similar check for debian/[README|TODO].Debian
>
>I could not find those checks, but would be happy to add the files.
>Unfortunately, I could not figure out from #429510 what the correct
>behavior should be. (For example, both README and README.Debian seem
>to be in use, but only the latter is shipped.) Please reopen the bug
>to add more files.

I think I overinterpreted one of the comments in that bug.
After rereading it (and checking by building a package - rkhunter fwiw),
 - debian/README is ignored
 - debian/README.Debian is shipped as README.Debian.gz

It seems best to leave things as they are for the README case;
the maintainer may want to have an ignored debian/README file.

I also tested TODO.
 - debian/TODO gets shipped as /usr/share/doc/rkhunter/TODO.Debian,
   ie not gzipped.
 - debian/TODO.Debian is ignored.

This was debhelper 12.1.1~bpo9+1, if that matters.

Cheers
Vince

Bug#946232: nss-mdns: please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: nss-mdns
Version: 0.14.1-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The nss-mdns tests /almost/ all pass in a cross environment, with the
exception of the remove-reinstall test, which fails because it winds up
acting on the amd64 package instead of the foreign-arch i386 package:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/n/nss-mdns/20191205_172326_4b1c4@/log.gz

The attached patch should be sufficient to let the test pass again, as
should be seen here shortly:

  http://autopkgtest.ubuntu.com/packages/n/nss-mdns/focal/i386

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

There are also several autopkgtests in your package which wind up testing
the amd64 version of libnss-mdns instead of the i386 version, and giving a
false positive test result.  I haven't taken the time to fix these, since
there are other tests that are at least minimally testing aspects of the
i386 package, so it's useful to have the autopkgtests for this package as a
whole passing rather than us ignoring the test failures unconditionally for
i386.

Thanks for considering,

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru nss-mdns-0.14.1/debian/tests/remove-reinstall 
nss-mdns-0.14.1/debian/tests/remove-reinstall
--- nss-mdns-0.14.1/debian/tests/remove-reinstall   2018-04-25 
15:30:42.0 -0700
+++ nss-mdns-0.14.1/debian/tests/remove-reinstall   2019-12-05 
13:58:02.0 -0800
@@ -11,26 +11,36 @@
 assert_succeeds avahi-set-host-name "$distinctive_hostname"
 sleep 3
 
-assert_succeeds apt-get -y purge libnss-mdns
+pkg=libnss-mdns
+if [ -n "$DEB_HOST_ARCH" ]; then
+pkg="$pkg:$DEB_HOST_ARCH"
+fi
+assert_succeeds apt-get -y purge "$pkg"
 
 assert_succeeds perl -i -pe 's/^hosts:.*/hosts: files dns/' /etc/nsswitch.conf
 
-assert_succeeds apt-get -y install libnss-mdns
+assert_succeeds apt-get -y install "$pkg"
 assert_hosts "hosts: files mdns4_minimal [NOTFOUND=return] dns"
-assert_succeeds getent hosts "$distinctive_hostname.local"
 
-assert_succeeds apt-get -y remove libnss-mdns
+# This is going to fail on a cross-test because 'getent' is from the testbed 
arch
+if [ -z "$DEB_HOST_ARCH" ]; then
+assert_succeeds getent hosts "$distinctive_hostname.local"
+fi
+
+assert_succeeds apt-get -y remove "$pkg"
 # No assertion about whether it's in nsswitch.conf: debian/tests/nss-behaviour
 # demonstrates that it doesn't actually matter
 assert_status 2 getent hosts "$distinctive_hostname.local"
 
 echo "# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500478;
 echo "# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782282;
-assert_succeeds apt-get -y install libnss-mdns
+assert_succeeds apt-get -y install "$pkg"
 assert_hosts "hosts: files mdns4_minimal [NOTFOUND=return] dns"
-assert_succeeds getent hosts "$distinctive_hostname.local"
+if [ -z "$DEB_HOST_ARCH" ]; then
+assert_succeeds getent hosts "$distinctive_hostname.local"
+fi
 
-assert_succeeds apt-get -y purge libnss-mdns
+assert_succeeds apt-get -y purge "$pkg"
 assert_hosts "hosts: files dns"
 assert_status 2 getent hosts "$distinctive_hostname.local"
 

Bug#740373: fetchmail: Generated emails about authentication failure is missing message-id

[Matthias Andree]

Am 05.12.19 um 09:07 schrieb Petter Reinholdtsen:
>
> Anyway, I was just curious what the answer to the question "why" would
> be.  Now I know.  Thank you for the clarifying answer. :)
>
The answer is actually a bit more complex, with aspects of "problem
already solved externally", "not mandated by standards", and "not
trivial to implement and document".

There are so many questions that will want to be asked back, for
instance, what should the domain part be, do we need to make it
configurable (either way it needs documentation) and all that. High
cost, little potential gain, I dare say not frequently needed, and as
shown the problem has already been solved by others externally - and in
a way (not quite coincidentally) that you can integrate into your setup.
And it's really only necessary for the specific circumstance that
further parts of the mail setup really fail in hard or very awkward ways
if the Message-ID is missing, and that seems to be a feature of older
notmuch implementations fixed a few releases ago.

There are other feature requests that won't catch a "wontfix" tag that
quickly because either they have low cost, or are hard to solve
externally (for instance, expire kept messages on server after N days)
or are otherwise more sensible to do without duplicating existing solutions.

Bug#946230: Bug in python3-dateutil

[Abdullah]

Package: python3-dateutil

Hi,
 Here is the package which is removed from pypi.org but still are in debian
 repos. So kindly remove them.

 Reference:
 https://www.zdnet.com/article/two-malicious-python-libraries-removed-from-pypi/


Abdullah

https://abdullah.today

C20F 2707 3025 2569 BAC5
534B 7820 6670 C19D 1580


signature.asc
Description: PGP signature

Bug#946231: Versions, Upstream version versus Debian version

[Geert Stappers]

Package: policykit-1
Version: 0.105-25
Severity: wishlist

Hello Utopia Team,

Summary is as in Subject: Versions, Upstream version versus Debian version

Upstream is at version 0.116 ( 
https://gitlab.freedesktop.org/polkit/polkit/-/tags )
Debian version is 0.105-something ( 
https://salsa.debian.org/utopia-team/polkit/blob/master/debian/changelog )

Debian changelog talks about changes from upstream version 0.114 and 0.116.


Having Debian version 0.105-25 installed
and invoking `pkaction --version` yields "0.105"

$ dpkg -l policykit-1 | grep ^ii
ii  policykit-10.105-25 amd64framework for managing 
administrative policies and privileges
$ pkaction --version
pkaction version 0.105
$ 



To me is this version "randomness" very unclear.

My wish is that the debian directory gets information on the idea behind
staying at version "0.105".

AFAIK would debian/README.source (
https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source
) a good place.




Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory

[Dimitri John Ledkov]

On Thu, 5 Dec 2019 at 21:33, Giovanni Mascellani  wrote:
>
> Il 05/12/19 22:15, Dimitri John Ledkov ha scritto:>> Also, I hope to
> finish working on 1.71 as soon as possible, so that we
> >> can start that migration.
> >
> > But 1.71 for sure will not have python2 bindings enabled. Thus
> > re-enabling python2 in boost is a stopgap until December 18th when
> > those reverse-deps will be removed from testing anyway.
>
> Wait, where does this date (December 18th) come from? Will all Python 2
> packages get deleted on that date? Is this documented anywhere?
>
> If it is already decided that Python 2 is going away very soon anyway (I
> didn't know this and I cannot find it written anywhere), then I agree
> there is no reason to re-enable Python 2.

All python2 bugs for leaf packages have been made RC on like 30th of
november, causing a tonne of packages to be scheduled for autoremoval.
Most of them are on 18th/19th December. See tracker.d.o for various
leaf packages.

And mirage itself, has already been removed from testing, has no
reverse deps, and is ready to be removed from unstable too. Not quite
sure why it hasn't already been removed from unstable.

-- 
Regards,

Dimitri.

Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory

[Dimitri John Ledkov]

On Thu, 5 Dec 2019 at 21:15, Joachim Reichel  wrote:
>
> Hi,
>
> it seems to me that other packages are also affected:
>
> - k3d FTBFS (bug #946225)
> - yade FTBFS (apparently fixed in experimental, see bug #938859)
>
> Even though these packages needs to be fixed, it might be a good idea not to
> break them right way and make e.g. the cgal_5.0 transition more difficult than
> necessary.

cgal transition is not made hard at all. Yade is scheduled for
autoremoval and so is pprepair.

pygalmesh is the last one that FTBFS during binNMU and I don't see any
actions on it -> I guess an RC bug is needed against it, to cause
autoremoval, and then cgal_5.0 transition will migrate.

Based on https://release.debian.org/transitions/html/cgal_5.0.html
with filter on bad, ignoring packages not in testing.

-- 
Regards,

Dimitri.

Bug#944689: failure is resolved in linux-image-5.4.0-trunk-amd64

[Bart Vanhaute]

Hello,

it seems the new linux image package from experimental
linux-image-5.4.0-trunk-amd64 does not exhibit the GPU initialization
failure problem.

boot log for this kernel version has:
[2.405213] i915 :00:02.0: VT-d active for gfx access
[2.405347] i915 :00:02.0: vgaarb: deactivate vga console
[2.425755] i915 :00:02.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[2.426608] i915 :00:02.0: firmware: direct-loading firmware
i915/kbl_dmc_ver1_04.bin
[2.427067] [drm] Finished loading DMC firmware
i915/kbl_dmc_ver1_04.bin (v1.4)
[2.443913] [drm] Initialized i915 1.6.0 20190822 for :00:02.0 on minor 0
[2.467784] fbcon: i915drmfb (fb0) is primary device
[3.623962] i915 :00:02.0: fb0: i915drmfb frame buffer device


regards,
Bart.

Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory

[Giovanni Mascellani]

Il 05/12/19 22:15, Dimitri John Ledkov ha scritto:>> Also, I hope to
finish working on 1.71 as soon as possible, so that we
>> can start that migration.
> 
> But 1.71 for sure will not have python2 bindings enabled. Thus
> re-enabling python2 in boost is a stopgap until December 18th when
> those reverse-deps will be removed from testing anyway.

Wait, where does this date (December 18th) come from? Will all Python 2
packages get deleted on that date? Is this documented anywhere?

If it is already decided that Python 2 is going away very soon anyway (I
didn't know this and I cannot find it written anywhere), then I agree
there is no reason to re-enable Python 2.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#946229: [NMU] FTFBS with CGAL 5.0

[Joachim Reichel]

Source: sfcgal
Version: 1.3.7-2
Severity: serious
Tags: ftbfs
Control: block 944417 by -1

Hi,

the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS. I
intend to NMU the package with the attached diff to DELAYED/5-day.

Best regards,
  Joachim
diff -Nru sfcgal-1.3.7/debian/changelog sfcgal-1.3.7/debian/changelog
--- sfcgal-1.3.7/debian/changelog   2019-08-18 07:57:14.0 +0200
+++ sfcgal-1.3.7/debian/changelog   2019-12-05 21:34:40.0 +0100
@@ -1,3 +1,11 @@
+sfcgal (1.3.7-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to fix FTBFS with CGAL >= 5.0 (Closes: #xx).
+  * Add Build-Depends: libcgal-dev (>= 5.0~).
+
+ -- Joachim Reichel   Thu, 05 Dec 2019 21:34:40 +0100
+
 sfcgal (1.3.7-2) unstable; urgency=medium
 
   * Bump Standards-Version to 4.4.0, no changes.
diff -Nru sfcgal-1.3.7/debian/control sfcgal-1.3.7/debian/control
--- sfcgal-1.3.7/debian/control 2019-08-18 07:55:35.0 +0200
+++ sfcgal-1.3.7/debian/control 2019-12-05 21:34:40.0 +0100
@@ -6,7 +6,7 @@
 Priority: optional
 Build-Depends: debhelper (>= 9.20160114),
cmake,
-   libcgal-dev (>= 4.10.1),
+   libcgal-dev (>= 5.0~),
libboost-all-dev,
libmpfr-dev,
libgmp-dev,
diff -Nru sfcgal-1.3.7/debian/patches/fix-ftbfs-with-cgal-5.x.patch 
sfcgal-1.3.7/debian/patches/fix-ftbfs-with-cgal-5.x.patch
--- sfcgal-1.3.7/debian/patches/fix-ftbfs-with-cgal-5.x.patch   1970-01-01 
01:00:00.0 +0100
+++ sfcgal-1.3.7/debian/patches/fix-ftbfs-with-cgal-5.x.patch   2019-12-05 
21:34:40.0 +0100
@@ -0,0 +1,44 @@
+Description: Require C++14 and CGAL >= 5.0
+Author: Joachim Reichel 
+Bug: https://github.com/Oslandia/SFCGAL/issues/198
+
+Index: sfcgal-1.3.7/CMakeLists.txt
+===
+--- sfcgal-1.3.7.orig/CMakeLists.txt
 sfcgal-1.3.7/CMakeLists.txt
+@@ -1,6 +1,8 @@
+ cmake_minimum_required( VERSION 2.8 )
+ project( SFCGAL )
+ 
++set(CMAKE_CXX_STANDARD 14)
++
+ set( CMAKE_DEBUG_POSTFIX "d" )
+ 
+ #
+@@ -51,19 +53,19 @@ endif()
+ 
+ # 4.3 minimal
+ # 4.13 recommended
+-find_package( CGAL 4.3 COMPONENTS Core REQUIRED )
++find_package( CGAL COMPONENTS Core REQUIRED )
+ message( STATUS "CGAL ${CGAL_VERSION} found" )
+ 
+ include_directories( ${CMAKE_BINARY_DIR}/include )
+ 
+ # For CGAL versions < 4.3, we add a local directory that contains some 
tweaked include files from unreleased versions
+ # They will overwrite files from the CGAL installation
+-if( "${CGAL_VERSION}" VERSION_LESS "4.3" )
+-  include_directories( patches/CGAL-4.2 )
+-elseif( "${CGAL_VERSION}" VERSION_LESS "4.10")
+-  include_directories( patches/CGAL-4.3 )
+-  add_definitions( "-DCGAL_INTERSECTION_VERSION=1" )
+-endif()
++# if( "${CGAL_VERSION}" VERSION_LESS "4.3" )
++#   include_directories( patches/CGAL-4.2 )
++# elseif( "${CGAL_VERSION}" VERSION_LESS "4.10")
++#   include_directories( patches/CGAL-4.3 )
++#   add_definitions( "-DCGAL_INTERSECTION_VERSION=1" )
++# endif()
+ 
+ #-- BOOST --
+ option( Boost_USE_AUTO_LINK "boost use autolink" OFF )
diff -Nru sfcgal-1.3.7/debian/patches/fix-linker-error.patch 
sfcgal-1.3.7/debian/patches/fix-linker-error.patch
--- sfcgal-1.3.7/debian/patches/fix-linker-error.patch  1970-01-01 
01:00:00.0 +0100
+++ sfcgal-1.3.7/debian/patches/fix-linker-error.patch  2019-12-05 
21:34:40.0 +0100
@@ -0,0 +1,82 @@
+Description: Force GMPXX as workaround for a linker error (used to be the
+  default for CGAL 4.x packages)
+Author: Joachim Reichel 
+Bug: https://github.com/Oslandia/SFCGAL/issues/198
+
+Index: sfcgal-1.3.7/CMakeLists.txt
+===
+--- sfcgal-1.3.7.orig/CMakeLists.txt
 sfcgal-1.3.7/CMakeLists.txt
+@@ -55,6 +55,7 @@ endif()
+ # 4.13 recommended
+ find_package( CGAL COMPONENTS Core REQUIRED )
+ message( STATUS "CGAL ${CGAL_VERSION} found" )
++add_definitions( "-DCGAL_USE_GMPXX=1" )
+ 
+ include_directories( ${CMAKE_BINARY_DIR}/include )
+ 
+Index: sfcgal-1.3.7/test/garden/CMakeLists.txt
+===
+--- sfcgal-1.3.7.orig/test/garden/CMakeLists.txt
 sfcgal-1.3.7/test/garden/CMakeLists.txt
+@@ -7,7 +7,7 @@ set( REGRESS_NAME garden-test-SFCGAL )
+ add_executable( ${REGRESS_NAME} ${SFCGAL_REGRESS_GARDEN_TEST_SOURCES} )
+ 
+ target_link_libraries( ${REGRESS_NAME} SFCGAL)
+-target_link_libraries( ${REGRESS_NAME} ${CGAL_3RD_PARTY_LIBRARIES} 
${Boost_LIBRARIES})
++target_link_libraries( ${REGRESS_NAME} gmpxx ${CGAL_3RD_PARTY_LIBRARIES} 
${Boost_LIBRARIES})
+ 
+ set_target_properties( ${REGRESS_NAME} PROPERTIES DEBUG_POSTFIX "d" )
+ install( TARGETS ${REGRESS_NAME} DESTINATION bin )
+Index: sfcgal-1.3.7/test/regress/convex_hull/CMakeLists.txt

Bug#946216: boost1.67: mpi-python appears to be broken

[Giovanni Mascellani]

Hi,

Il 05/12/19 18:53, Dimitri John Ledkov ha scritto:
> mpi-python3 appears to be completely broken. See autopkgtest, most
> likely an upstream issue.

autopkgtest seems clean on my computer. Which error do you see?

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory

[Dimitri John Ledkov]

On Thu, 5 Dec 2019 at 21:15, Joachim Reichel  wrote:
>
> Hi,
>
> it seems to me that other packages are also affected:
>
> - k3d FTBFS (bug #946225)
> - yade FTBFS (apparently fixed in experimental, see bug #938859)
>
> Even though these packages needs to be fixed, it might be a good idea not to
> break them right way and make e.g. the cgal_5.0 transition more difficult than
> necessary.

Please do not conflate different issues. FTBFS is most likely caused
by the change in -dev package soname symlinks with historic deprecated
ones removed, and only cross-distro/os/upstream ones remaining. I.e.
one must link explicitly against boost_pythonXY from now on.

-- 
Regards,

Dimitri.

Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory

[Dimitri John Ledkov]

On Thu, 5 Dec 2019 at 20:57, Giovanni Mascellani  wrote:
>
> Hi,
>
> Il 05/12/19 17:55, Dimitri John Ledkov ha scritto:
> > In principal I agree, in practice the only broken app today is ledger,
> > which should have by now uploaded without a python bridge enabled; or
> > build with python3 bridge as now available from upstream master (ported
> > by me after this issue was filed / escalated).
>
> Thanks for working on ledger, but it is not the only affected
> application. At least mirage is affected too. Are you sure there are not
> others? How?
>

mirage is RC buggy, not in testing, and should also be removed from
unstable too.

Are you seriously suggesting to keep RC buggy app working in unstable
for extra couple of weeks? It's to be slaughtered with the rest of
python2 apps and modules from unstable.

The only way to keep mirage available is to port it to python3 and python3-gir.

> > And no, unstable is not supported and frequently has uninstallable
> > packages, multiple known regressions, RC bugs, and automated autopkgtest
> > regressions. One should only dist-upgrade unstable packages they use, if
> > they are ok with the RC bugs and autopkgtest regressions automatically
> > identified in the builds anyway. Thus no, I will not be making
> > incremental uploads, to temporarily unbreak unstable users, using hacks
> > which are not the way we intend to ship in testing later as that is
> > added churn and drag on the development (ie. port/rebuild ledger in this
> > case).
>
> I don't agree. I ordinarily use unstable and usually everything runs
> fine. There are breakages every now and then, and I know that if
> unstable breaks I keep the pieces. But this does not mean that one
> should do that on purpose. There can be situations in which this is
> unavoidable, but clearly this is not one of those: there is not harm in
> keeping Python 2 enabled as long as users are still using it.
>

Huh, no. The whole purpose of python2 removal is to remove all python2
apps and modules from unstable.

They will not continue to work. We will only ship python2.7 itself for
one more stable cycle, without any apps or modules, and then it too
will be removed from unstable.

> Therefore I will upload a new version of boost1.67 temporarily reverting
> your patch. By the way, I don't think that boost1.67 will go in bullseye
> anyway: I hope to get rid of it well before that. So the point here is
> not getting the package in shape for the release; it is just avoid
> making the life of unstable's users unnecessarily complicated.
>

Go for it, it is not uncommon for us to ship multiple boost releases.
And e.g. boost1.62 is still in unstable, but I did file removal bug
for it.

Also why does one need to upload boost1.67 to unstable, if the one
from testing still works with ledger/mirage/etc?

> Also, I hope to finish working on 1.71 as soon as possible, so that we
> can start that migration.

But 1.71 for sure will not have python2 bindings enabled. Thus
re-enabling python2 in boost is a stopgap until December 18th when
those reverse-deps will be removed from testing anyway.

-- 
Regards,

Dimitri.

Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory

[Joachim Reichel]

Hi,

it seems to me that other packages are also affected:

- k3d FTBFS (bug #946225)
- yade FTBFS (apparently fixed in experimental, see bug #938859)

Even though these packages needs to be fixed, it might be a good idea not to
break them right way and make e.g. the cgal_5.0 transition more difficult than
necessary.

  Joachim

Bug#946228: FTBFS with CGAL 5.0

[Joachim Reichel]

Source: k3d
Version: 0.8.0.6-8
Severity: serious
Tags: ftbfs
Control: block 944417 by -1

Hi,

the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS.

Attached are two patches that fix the problem. In addition, one needs to add
"Build-Depends: libcgal-dev (>= 5.0~).

But just applying these two patches is not enough to unblock the transition due
to bug #946225.

Best regards,
  Joachim
Index: k3d-0.8.0.6/CMakeLists.txt
===
--- k3d-0.8.0.6.orig/CMakeLists.txt
+++ k3d-0.8.0.6/CMakeLists.txt
@@ -7,7 +7,7 @@ IF(${CMAKE_MAJOR_VERSION} GREATER 3 OR $
   CMAKE_POLICY(SET CMP0026 OLD)
 ENDIF()
 
-set(CMAKE_CXX_STANDARD 11)
+set(CMAKE_CXX_STANDARD 14)
 
 
 SET(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules")
Index: k3d-0.8.0.6/cmake/modules/K3DFindCGAL.cmake
===
--- k3d-0.8.0.6.orig/cmake/modules/K3DFindCGAL.cmake
+++ k3d-0.8.0.6/cmake/modules/K3DFindCGAL.cmake
@@ -7,11 +7,6 @@ FIND_PATH(K3D_CGAL_INCLUDE_DIR CGAL
)
 MARK_AS_ADVANCED(K3D_CGAL_INCLUDE_DIR)
 
-FIND_LIBRARY(K3D_CGAL_LIBRARY CGAL
-   DOC "The CGAL library"
-   )
-MARK_AS_ADVANCED(K3D_CGAL_LIBRARY)
-
 FIND_LIBRARY(K3D_MPFR_LIBRARY mpfr
DOC "The mpfr library"
)
@@ -22,7 +17,7 @@ FIND_LIBRARY(K3D_GMP_LIBRARY gmp
)
 MARK_AS_ADVANCED(K3D_GMP_LIBRARY)
 
-IF(K3D_CGAL_INCLUDE_DIR AND K3D_CGAL_LIBRARY AND K3D_MPFR_LIBRARY AND 
K3D_GMP_LIBRARY)
+IF(K3D_CGAL_INCLUDE_DIR AND K3D_MPFR_LIBRARY AND K3D_GMP_LIBRARY)
SET(K3D_CGAL_FOUND 1)
-ENDIF(K3D_CGAL_INCLUDE_DIR AND K3D_CGAL_LIBRARY AND K3D_MPFR_LIBRARY AND 
K3D_GMP_LIBRARY)
+ENDIF(K3D_CGAL_INCLUDE_DIR AND K3D_MPFR_LIBRARY AND K3D_GMP_LIBRARY)
 
Index: k3d-0.8.0.6/modules/cgal/CMakeLists.txt
===
--- k3d-0.8.0.6.orig/modules/cgal/CMakeLists.txt
+++ k3d-0.8.0.6/modules/cgal/CMakeLists.txt
@@ -6,7 +6,6 @@ K3D_BUILD_MODULE(k3d-cgal)
 K3D_CREATE_MODULE_PROXY(k3d-cgal)
 
 TARGET_LINK_LIBRARIES(k3d-cgal
-   ${K3D_CGAL_LIBRARY}
${K3D_MPFR_LIBRARY}
${K3D_GMP_LIBRARY}
${Boost_THREAD_LIBRARY}

Bug#939943: Please upload python-jsonschema version 3 to unstable

[Thomas Goirand]

On 12/5/19 11:47 AM, Ole Streicher wrote:
> Dear maintainer,
> 
> the version 3 of python-jsonschema is now in testing since a couple of
> months. Would it be possible to upload it to unstable as well?
> 
> I am also waiting for it, to upload a new version of gammapy, which
> fixes an RC bug.
> 
> Thank you!
> 
> Best
> 
> Ole

Hi,

Last time I checked, there was still some packages needing
python-jsonschema (by this, I mean, the Python 2 version of the
package). As this has changed, I can now upload the version with Py2
removal in Sid. I'll do this soon.

Cheers,

Thomas Goirand (zigo)

Bug#946227: libtext-bidi-perl: Please package misc/bidi urxvt extension

[Benjamin Barenblat]

Source: libtext-bidi-perl
Version: 2.15-1
Severity: wishlist

libtext-bidi-perl’s upstream includes a file, misc/bidi, that can be
used as a urxvt extension. (The extension filters terminal output
through fribidi to display RTL text correctly.) It would be great if
misc/bidi could be installed through apt.

It looks like Debian puts system extensions for urxvt in
/usr/lib/$DEB_HOST_MULTIARCH/urxvt/perl.

Bug#946225: FTBFS related to Boost.Python

[Joachim Reichel]

Source: k3d
Version: 0.8.0.6-8
Severity: serious
Tags: ftbfs

Hi,

your package FTBFS:

CMake Error at 
/usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find Boost (missing: python) (found suitable version "1.67.0",
  minimum required is "1.42")
Call Stack (most recent call first):
  /usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.15/Modules/FindBoost.cmake:2161 
(find_package_handle_standard_args)
  cmake/modules/K3DFindBoost.cmake:9 (FIND_PACKAGE)
  CMakeLists.txt:254 (INCLUDE)

This might have been caused by bug 945840.

Best regards,
  Joachim

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

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

Bug#946226: rxvt-unicode: installs Perl extensions in /usr/lib, not /usr/share

[Benjamin Barenblat]

Package: rxvt-unicode
Version: 9.22-6
Severity: wishlist

rxvt-unicode currently installs Perl extensions in
/usr/lib/$DEB_HOST_MULTIARCH/urxvt/perl. However, the FHS identifies
/usr/share as the preferred tree for architecture-independent data; 
Perl scripts should thus be installed in /usr/share.

This is definitely a wishlist item: The FHS says that
“application-specific, architecture-independent directories ... may,
however, be placed in /usr/lib for backwards compatibility, at the
distributor’s discretion.” Eventually, though, it would be nice to get
all the Perl into /usr/share.

Bug#946197: Let's switch to OpenRC?

[Thomas Goirand]

Hi Alex,

Axel Beckert 
> Thomas Goirand wrote:
> > OpenRC is actively maintained upstream,
>
> Sysvinit is AFAIK maintained upstream again since a year ago or so. So
> this is no reason to get rid of sysvinit. Note all the new upstream
> releases, Dmitry has uploaded in the past year:
> https://packages.qa.debian.org/s/sysvinit.html

I never wrote that sysv-rc isn't maintained, that's not the point I'm
trying to make.

> The last time I looked (years ago), there were features in sysvinit
> which weren't in OpenRC (yet). IIRC not having concurrent execution of
> boot scripts was one of the missing features and the reason for e.g.
> our derivative distribution GRML to not switch to OpenRC some years
> ago.

OpenRC does have parallel execution of scripts, it works well, but when
activated, the display output is still a bit ugly. I'm not sure why (I
haven't investigated). If the issue is just the screen output, then
probably it can be worked on.

> Yes, the fact that these runscripts use the same paths as classic
> initscripts in Debian is a pity.

Well, yes and no. If we are to keep standard shell script forever,
indeed, that's a pity. If we instead decide that it's time to move on,
and standardize with runscripts instead, then it's very nice that OpenRC
reuse the existing shell script, and allow us to slowly replace them.

The pity is to currently have to maintain runscripts *AND* shell
scripts, instead of simply deprecating these boring init scripts.

> I'd really prefer to continue to have both init systems in parallel
> (as long as they're maintained upstream), with different paths so that
> both can be used properly.

This is exactly what I think should not happen. If we give package
maintainers the chance to get rid of these ugly init scritps and replace
them by superior runscripts, then probably they will look at systemd
alternative differently, and agree to maintain/write runscripts, for
example to support non-linux ports.

If instead, we keep having old style shell script, which OpenRC also
support, I bet copper against gold that mostly everyone wont even bother
writing/maintaining runscripts, and keep pestering about init shell scripts.

> I'm though not really sure how much impact
> it will have to have different paths for the runscripts than upstream.

Writing a small patch to have OpenRC prefer a runscript with same name
in a different folder over a shell in /etc/init.d shouldn't be very
hard, but that's really not what I wish to happen. I really would like a
way so that we get rid of the old shell scripts for something more
modern and declarative.

> Maybe packages can ship them somewhere else than default, and openrc
> uses dpkg-divert to get them into the expected path if and only if
> openrc is installed.

Files in /etc/init.d are CONFFILE files. I don't think dpkg-divert works
with CONFFILE files (does it?). Even if it did work, we cannot have
OpenRC reimplement all of the init scripts of Debian, these must be
carried in each packages.

> P.S.: One of the really cool things about Buster is that it offers 5
> or 6 different init systems! Now that's what I call diversity.

How many of them have good support in every package?

Benda Xu  wrote:
> I think it would be time when OpenRC has a systemd .ini parser, to
> also make use of systemd units.

Do you think this could be written?

Thorsten Glaser 
> Dropping sysvinit as it works and as admins know... no.
> Absolutely NOT.

Thorsten, do you have any point of argumentation besides "it works and
we know it"? That's IMO a bit light...

Cheers,

Thomas Goirand (zigo)

Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory

[Giovanni Mascellani]

Hi,

Il 05/12/19 17:55, Dimitri John Ledkov ha scritto:
> In principal I agree, in practice the only broken app today is ledger,
> which should have by now uploaded without a python bridge enabled; or
> build with python3 bridge as now available from upstream master (ported
> by me after this issue was filed / escalated).

Thanks for working on ledger, but it is not the only affected
application. At least mirage is affected too. Are you sure there are not
others? How?

> And no, unstable is not supported and frequently has uninstallable
> packages, multiple known regressions, RC bugs, and automated autopkgtest
> regressions. One should only dist-upgrade unstable packages they use, if
> they are ok with the RC bugs and autopkgtest regressions automatically
> identified in the builds anyway. Thus no, I will not be making
> incremental uploads, to temporarily unbreak unstable users, using hacks
> which are not the way we intend to ship in testing later as that is
> added churn and drag on the development (ie. port/rebuild ledger in this
> case).

I don't agree. I ordinarily use unstable and usually everything runs
fine. There are breakages every now and then, and I know that if
unstable breaks I keep the pieces. But this does not mean that one
should do that on purpose. There can be situations in which this is
unavoidable, but clearly this is not one of those: there is not harm in
keeping Python 2 enabled as long as users are still using it.

Therefore I will upload a new version of boost1.67 temporarily reverting
your patch. By the way, I don't think that boost1.67 will go in bullseye
anyway: I hope to get rid of it well before that. So the point here is
not getting the package in shape for the release; it is just avoid
making the life of unstable's users unnecessarily complicated.

Also, I hope to finish working on 1.71 as soon as possible, so that we
can start that migration.

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#946224: ITP: ruby-jekyll-toc -- Jekyll plugin to generate a table of contents

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-jekyll-toc
  Version : 0.12.2
  Upstream Author : Toshimaru
* URL : https://github.com/toshimaru/jekyll-toc
* License : MIT
  Programming Lang: Ruby
  Description : Jekyll plugin to generate a table of contents

This is a configurable liquid filter plugin for Jekyll which generates a
table of contents as an unordered list. 

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl3pahoACgkQS80FZ8KW
0F3VWRAAvyyWHlguUNuBRm4Jy1oSv2flh9TZULbchZeHQ3b2JMYzVGIfVI1LKA4E
DmSe2/9ekhhMX0dByDAkZRFpNkY2a3Nhcknd+k7/VMo8wUQuJXpk7NdukuIRo7cH
N5hcHslbJOjKtYaC3z9pHFbxRn2B8/LjNJELzfBqJnIiqUWh2rB7lSc9fot97gwX
erVIpTwem4HoaSQFhkG1ozRiVReRrWEqFarRnl2E/nOEAtkak8/+WsOfoq9L0oys
i9pALsruyGwXTb5URC5tpv46EAe/pjvgJPKvr4wKhi11ItRz1Wqs2ySu7+Y31Rtp
C3U2gTs0XqRS+P9oWcqDC3JYaEm/RpTqKP2Z6yf4nuhgQ6blPDAhYmkyLwTPX6//
jzYlDx+smE2vk7ZK2EknfgDugQIdVFhpIk1nKoEXZOjteEtJmq9ubOENUQk6O4iD
zRkRVuhvyXfpTkkDc8lC9gUkaH5/yhAOWDiYOrPPmjk8SYTts7TJFTFQX4fVq5QU
ncdsL9OgAtRH2FJf5lk6wv787+u7POEjRwdwqt8ngJsWLhMj+5Lp3pvBvLg2t75K
n2XiKl8qilXWJGTpXrFKmca0+pXL+yDXuS/gZtAY4XEbfknmDD+Wr623p8FbbWVQ
vm3GAYmwAUX331KE+L246ZyCOJdFNgjg3XN691XZ9enxSyvL0Lc=
=MHyP
-END PGP SIGNATURE-

Bug#945389: Tried to upgrade skimage to see whether #945389 is fixed but failed

[Andreas Tille]

Hi Stefan,

On Thu, Dec 05, 2019 at 10:18:01AM -0800, Stefan van der Walt wrote:
> On Wed, 04 Dec 2019 09:53:03 +0100, Andreas Tille wrote:
> > Hmmm, I think the Cython files are generated in the build I did.
> 
> Sorry, I missed that!  I saw at the bottom of the log:
> 
> E   AttributeError: type object 'skimage.feature.orb_cy.array' has no
> attribute '__reduce_cython__'
> 
> Which is an error that has been fixed in Cython 0.28, supposedly:
> 
> https://github.com/cython/cython/issues/1894
> 
> But it looks like your compilation is using 0.29, so not sure why that
> is happening:
> 
> Get: 26 http://deb.debian.org/debian sid/main amd64 cython3 amd64
> 0.29.14-0.1+b1 [2117 kB]

Yes, that's the case.
 
> One possibility is that NumPy was compiled with an older version of
> Cython:
> 
> https://github.com/cython/cython/issues/1953#issuecomment-398128940
> 
> Do you know how I can check the source files for the NumPy 1.17 build
> that is used here?

According to

   
https://buildd.debian.org/status/fetch.php?pkg=numpy=amd64=1%3A1.17.4-3=1574041583=0

it was

   Get:48 https://cdn-aws.deb.debian.org/debian unstable/main amd64 cython3 
amd64 0.29.14-0.1 [1474 kB]

> The other errors seem to be because no suitable image plugin is
> registered.  This can typically be fixed by installing matplotlib or
> imageio beforehand,

I added Build-Depends: python3-imageio as well - but this did not
change anything.

> but it looks like you *do* have matplotlib
> installed.

Yep.

> Maybe the Cython module imports break everything so badly
> that the plugins cannot even load.

H, seems this is the only remaining explanation.  I admit I have no
idea.
 
> > Its correct that the _Maintainer_ is set to Debian Science team.  But
> > the actual members of the team (in Debian terminology the _Uploaders_)
> > are you and Yaroslav.
> 
> Thanks for updating that; I never had the ability to upload to anything
> other than mentors.

In the Debian Science team it is perfectly sufficient to commit changes
to the Git repository at salsa.debian.org and asking for sponsoring on
the Debian Science mailing list.  I'd love to take over sponsorship in
case you might want to commit in this way.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#946223: [NMU] FTFBS with CGAL 5.0

[Joachim Reichel]

Source: yade
Version: 2019.01a-3
Severity: serious
Tags: ftbfs
Control: block 944417 by -1

Hi,

the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS.
Attached are two patches that fix the problem. In addition, one needs to add
"Build-Depends: libcgal-dev (>= 5.0~).

Just applying these two patches is not enough due to bug #938859. What is your
planned timeline for an upload to unstable?

Best regards,
  Joachim

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Index: yade-2019.01a/CMakeLists.txt
===
--- yade-2019.01a.orig/CMakeLists.txt
+++ yade-2019.01a/CMakeLists.txt
@@ -299,7 +299,7 @@ IF(ENABLE_CGAL)
 
 FILE(GLOB CGAL_SRC_LIB "lib/triangulation/*.cpp")
 SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CGAL_DEFINITIONS} -DYADE_CGAL")
-SET(LINKLIBS  
"${LINKLIBS};${CGAL_LIBRARIES};${GMP_LIBRARIES};${GMPXX_LIBRARIES};")
+SET(LINKLIBS  "${LINKLIBS};${GMP_LIBRARIES};${GMPXX_LIBRARIES};")
 MESSAGE(STATUS "Found CGAL")
 SET(CONFIGURED_FEATS "${CONFIGURED_FEATS} CGAL")
 
Index: yade-2019.01a/cMake/FindCGAL.cmake
===
--- yade-2019.01a.orig/cMake/FindCGAL.cmake
+++ yade-2019.01a/cMake/FindCGAL.cmake
@@ -7,38 +7,26 @@
 # This module defines
 #  CGAL_DEFINITIONS: compiler flags for compiling with CGAL
 #  CGAL_INCLUDE_DIR: where to find CGAL.h
-#  CGAL_LIBRARIES: the libraries needed to use CGAL
 #  CGAL_FOUND: if false, do not try to use CGAL
 
-IF(CGAL_INCLUDE_DIR AND CGAL_LIBRARIES)
+IF(CGAL_INCLUDE_DIR)
 SET(CGAL_FOUND TRUE)
-ELSE(CGAL_INCLUDE_DIR AND CGAL_LIBRARIES)
+ELSE(CGAL_INCLUDE_DIR)
FIND_PATH(CGAL_INCLUDE_DIR CGAL/basic.h
 /usr/include/
 /usr/local/include/
 $ENV{ProgramFiles}/CGAL/*/include/
 $ENV{SystemDrive}/CGAL/*/include/
 )
-FIND_LIBRARY(CGAL_LIBRARIES NAMES CGAL libCGAL
-PATHS
-/usr/lib
-/usr/local/lib
-/usr/lib/CGAL
-/usr/lib64
-/usr/local/lib64
-/usr/lib64/CGAL
-$ENV{ProgramFiles}/CGAL/*/lib/ms
-$ENV{SystemDrive}/CGAL/*/lib/ms
-)
 
-IF(CGAL_INCLUDE_DIR AND CGAL_LIBRARIES)
+IF(CGAL_INCLUDE_DIR)
 SET(CGAL_FOUND TRUE)
-MESSAGE(STATUS "Found CGAL: ${CGAL_INCLUDE_DIR}, ${CGAL_LIBRARIES}")
+MESSAGE(STATUS "Found CGAL: ${CGAL_INCLUDE_DIR}")
INCLUDE_DIRECTORIES(${CGAL_INCLUDE_DIR})
-ELSE(CGAL_INCLUDE_DIR AND CGAL_LIBRARIES)
+ELSE(CGAL_INCLUDE_DIR)
 SET(CGAL_FOUND FALSE)
 MESSAGE(STATUS "CGAL not found.")
-ENDIF(CGAL_INCLUDE_DIR AND CGAL_LIBRARIES)
+ENDIF(CGAL_INCLUDE_DIR)
 
-MARK_AS_ADVANCED(CGAL_INCLUDE_DIR CGAL_LIBRARIES)
-ENDIF(CGAL_INCLUDE_DIR AND CGAL_LIBRARIES)
+MARK_AS_ADVANCED(CGAL_INCLUDE_DIR)
+ENDIF(CGAL_INCLUDE_DIR)
Index: yade-2019.01a/CMakeLists.txt
===
--- yade-2019.01a.orig/CMakeLists.txt
+++ yade-2019.01a/CMakeLists.txt
@@ -32,6 +32,8 @@
 project(Yade C CXX)
 cmake_minimum_required(VERSION 2.8.11)
 
+set(CMAKE_CXX_STANDARD 14)
+
 set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cMake")
 
 INCLUDE(FindPythonInterp)
@@ -83,7 +85,7 @@ ELSE()
   ENDIF()
 ENDIF()
 
-SET(CMAKE_CXX_FLAGS  "${CMAKE_CXX_FLAGS} -fPIC -O2 --param=ssp-buffer-size=4 
-Wformat -Wformat-security -Werror=format-security -Wall -std=c++11")
+SET(CMAKE_CXX_FLAGS  "${CMAKE_CXX_FLAGS} -fPIC -O2 --param=ssp-buffer-size=4 
-Wformat -Wformat-security -Werror=format-security -Wall -std=c++14")
 
 IF (DEBUG)
   SET(CMAKE_VERBOSE_MAKEFILE 1)

Bug#895696: firmware-ath9k-htc: workaround info. added on the wiki page

[Oleksij Rempel]

Hi Awalis,

Am 05.12.19 um 20:01 schrieb awalis:
> Package: firmware-ath9k-htc
> Version: 1.4.0-97-g75b3e59+dfsg-3
> Followup-For: Bug #895696
> 
> Dear Maintainer,
> 
> Done, the workaround was added into the wiki page. Please find the link below.
> 
> https://wiki.debian.org/ath9k_htc/open_firmware#Fix_the_.22Scan_but_not_Connect.22_issue_.28NetworkManager.29

Great work! Thank you!


> Regards,
> Awalis.
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> -- no debconf information



-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Bug#927313: parsinsert: probably broken on armhf, failing autopkgtests in Ubuntu

[Steve Langasek]

Hi Andreas,

On Thu, Dec 05, 2019 at 07:13:38PM +0100, Andreas Tille wrote:
> On Fri, Jul 26, 2019 at 02:52:34PM -0700, Steve Langasek wrote:

> > > So your suggestion is that for future uploads we should run the test
> > > written in Debian as autopkgtest as a test for the upstream code.

> > Yes, this would catch the problem earlier and fail to build the package on
> > architectures where it is broken. Then you could request the old binaries be
> > removed from the archive.

> I've implemented this and according to

>https://buildd.debian.org/status/package.php?p=parsinsert

> all architectures are passing.  Am I missing something?

Well, this package version appears to also build now in Ubuntu on arm64 and
armhf but not on ppc64el:

  https://launchpad.net/ubuntu/+source/parsinsert/1.04-6

so it looks like there has perhaps been improvement in the
cross-architecture compatibility of this package since the bug was initially
filed.

> > > > Note that these tests also fail on arm64, i386, and ppc64el in Ubuntu,
> > > > suggestings the packages are also broken there, but none of these are
> > > > regressions.
> > 
> > > Thanks a lot for these hints
> > 
> > My pleasure!
> 
> :-)
> 
> Kind regards
> 
>  Andreas.
> 
> -- 
> http://fam-tille.de

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#945389: Tried to upgrade skimage to see whether #945389 is fixed but failed

[Rebecca N. Palmer]

Stefan van der Walt wrote:

One possibility is that NumPy was compiled with an older version of
Cython:[...]
Do you know how I can check the source files for the NumPy 1.17 build
that is used here?


Source: https://sources.debian.org/src/numpy/1:1.17.4-3/
Build log: https://buildd.debian.org/status/package.php?p=numpy
numpy was built with cython3 0.29.14-0.1.  (Not +b1, but I _think_ "Add 
Python3.8 as supported version" means the ability to run cython3 itself 
in python3.8, not the ability to compile modules for python3.8.)

Bug#940232: False removing motivations

[Mattia Rizzolo]

Hello,


I'm sorry to hear that you are affected by a package removal.

On Thu, Dec 05, 2019 at 08:00:36PM +0100, Davide Prina wrote:
> I read that it is removed because:
> 
> 1) python2-only
> 
> it is not true. Tulip 5.3 work with Python 3.7[¹]

That might be true, but regardless, it's not true for the version we had
in the archive.

> 2) dead upstream;
> 
> it is not true. It has changed his home page, as I have reported in the bug
> report #851840: -> tulip: wrong project home page

Meh, indeed.  Looks really the maintainer really didn't properly care
about his package enough.

> 3) RC-buggy;  low popcon
> 
> in Debian there was a very old version, so who want to use it need to
> install the upstream latest version.

This though does mean that the archive version is not really used
anyway, so…

> I'm very displeased that this very good piece of software is not in Debian
> :-(

If anybody wants to re-introduce it with a newer version, compliant with
everything (python3, etc), then please look at
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#reintroducing-packages
for more details on how to accomplish it.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#946221: rspamd: segfault with pcre2 10.34, works with 10.32

[Andreas Hasenack]

Package: rspamd
Version: 1.9.4-2+b1
Severity: normal

Dear Maintainer,
rspamadm segfaults with pcre2 10.34. This can be seen in the ci
tests[1], for which rspamd has a bad-test[2] (?), and manually:

root@sid-rspamd:~# dpkg -l|grep pcre
ii  libpcre2-8-0:amd64 10.34-3+b1 amd64
New Perl Compatible Regular Expression Library- 8 bit runtime files
ii  libpcre3:amd64 2:8.39-12+b1   amd64
Old Perl 5 Compatible Regular Expression Library - runtime files
root@sid-rspamd:~# dpkg -l|grep rspam
ii  rspamd 1.9.4-2+b1 amd64
Rapid spam filtering system

root@sid-rspamd:~# rspamadm configtest
Segmentation fault (core dumped)

This also happens in Ubuntu, where there are no bad-test hints and
where rspamd is stuck in migration. In Ubuntu, if I try with pcre2
10.32-5, it works.

The full backtrace is as follows:
Starting program: /usr/bin/rspamadm configtest
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x76f85714 in pcre2_jit_compile_8 (code=0x0,
options=options@entry=1) at src/pcre2_jit_compile.c:13746
13746src/pcre2_jit_compile.c: No such file or directory.
#0  0x76f85714 in pcre2_jit_compile_8 (code=0x0,
options=options@entry=1) at src/pcre2_jit_compile.c:13746
re = 0x0
functions = 
executable_allocator_is_working = 1
#1  0x77aa1543 in rspamd_regexp_post_process
(r=0x7196af80) at ./src/libutil/regexp.c:190
jsz = 658
jit_flags = 1
jsz = 
jit_flags = 
__func__ = "rspamd_regexp_post_process"
#2  rspamd_regexp_new (pattern=0x73b7e6c9 "[$€$¢¥₽]",
flags=0x747e3600 "u", err=err@entry=0x7fffe940) at
./src/libutil/regexp.c:481
start = 
end = 
flags_str = 
err_str = 
res = 0x7196af80
explicit_utf = 1
r = 0x7196aec0
sep = 
real_pattern = 
err_off = 0
regexp_flags = 524288
rspamd_flags = 
err_code = 100
ncaptures = 658
strict_flags = 
__func__ = "rspamd_regexp_new"
#3  0x77b4b61d in rspamd_mime_expr_parse_regexp_atom
(cfg=, line=0x73b7e670 "/[$€$¢¥₽]/Hu",
pool=0x74632000) at ./src/libmime/mime_expressions.c:494
end = 
p = 
err = 0x0
re_flags = 0x747f1400
begin = 0x73b7e671 "[$€$¢¥₽]/Hu"
src = 0x73b7e668 "Subject=/[$€$¢¥₽]/Hu"
dbegin = 
start = 
brace = 
dend = 0x73b7e6d7 ""
extra = 0x73b7e6b8 "Subject"
result = 0x73b7e688
begin = 
end = 
p = 
src = 
start = 
brace = 
dbegin = 
dend = 
extra = 
result = 
err = 
re_flags = 
__func__ = "rspamd_mime_expr_parse_regexp_atom"
#4  rspamd_mime_expr_parse (line=, len=,
pool=0x74632000, ud=, err=0x7fffea60) at
./src/libmime/mime_expressions.c:799
a = 0x0
mime_atom = 0x73b7e650
p = 
end = 
c = 
real_ud = 
cfg = 
own_re = 
t = 
type = 
obraces = 
ebraces = 
state = 
prev_state = 
__func__ = "rspamd_mime_expr_parse"
#5  0x77a86378 in rspamd_parse_expression
(line=line@entry=0x74749480 "Subject=/[$€$¢¥₽]/Hu", len=, len@entry=0, subr=0x77d699e0 ,
subr_data=subr_data@entry=0x7fffeaf0,
pool=pool@entry=0x74632000, err=err@entry=0x7fffea60,
target=0x7fffea58) at ./src/libutil/expression.c:671
e = 0x747611d0
elt = {type = ELT_OP, p = {atom = 0x0, op = OP_INVALID, lim =
0}, flags = 0, priority = 0, value = 0}
atom = 
num_re = 0x74645fc0
op = 
op_stack = 
p = 
c = 
end = 
operand_stack = 0x747f4e60
tmp = 
state = 
__func__ = "rspamd_parse_expression"
#6  0x77b6842c in read_regexp_expression (pool=0x74632000,
symbol=0x74749460 "SUBJECT_HAS_CURRENCY",
line=line@entry=0x74749480 "Subject=/[$€$¢¥₽]/Hu",
ud=ud@entry=0x7fffeaf0, chain=) at
./src/plugins/regexp.c:81
e = 0x0
err = 0x0
__func__ = "read_regexp_expression"
#7  0x77b68e8f in regexp_module_config (cfg=0x74626800) at
./src/plugins/regexp.c:228
group = 0x0
flags = 0
priority = 0
description = 0x0
score = 0
is_lua = 0
valid_expression = 1
ud = {cfg = 0x74626800, conf_obj = 0x7467c780}
regexp_module_ctx = 0x73b75f40
cur_item = 0x73b7e630
sec = 0x747370c0
value = 0x7467c780
elt = 
it = 0x74625e00
res = 1
id = 
nre = 27
nlua = 0
nshots = 1
__func__ = 

Bug#946222: kronosnet: Dropped connections and segfaults in older version

[Boyuan Yang]

Source: kronosnet
Version: 1.8-2
Severity: important
X-Debbugs-CC: wf...@debian.org

Ben Tullis  于2019年12月5日周四 上午7:12写道：
> There have been some significant fixes implemented between the buster
> and bullseye versions of libknet1
>
> (Kronosnet is the new corosync communication protocol for HA clustering.
> The version in Buster suffers from dropped connections and segfaults
> when there is moderate network load.)
>
> There is an extensive discussion about the issue on the Proxmox forum:
> https://forum.proxmox.com/threads/pve-5-4-11-corosync-3-x-major-issues.56124/
>
> ...but I'm not aware of any current Debian bugs regarding this issue.
>
> Would it be appropriate to request a new backport of this version of the
> library to buster-backports, or is there some other mechanism by which
> it could be made available to stable-updates? I understand that
> backports is only supposed to be used for new features, rather than
> fixes, so I'm simply enquiring what the best method of getting this
> update into buster.

I guess uploading onto buster-backports is okay while the best
solution is to fix it in Debian Stable. I am converting the previous
email on debian-backports mailing list into a bug report so that the
original package maintainers are able to be aware of this issue. (They
are more familiar with this software and should be contacted first.)

Dear kronosnet maintainers: please evaluate this bug and see whether a
stable update is possible. Otherwise it's always okay to make a
backport.

-- 
Regards,
Boyuan Yang

Bug#895696: firmware-ath9k-htc: workaround info. added on the wiki page

[awalis]

Package: firmware-ath9k-htc
Version: 1.4.0-97-g75b3e59+dfsg-3
Followup-For: Bug #895696

Dear Maintainer,

Done, the workaround was added into the wiki page. Please find the link below.

https://wiki.debian.org/ath9k_htc/open_firmware#Fix_the_.22Scan_but_not_Connect.22_issue_.28NetworkManager.29

Regards,
Awalis.

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

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

-- no debconf information

Bug#940232: False removing motivations

[Davide Prina]

I read that Tulip has been removed from Debian, but I want to say that 
Tulip is a first class program that let you do easy some analysis that 
only professional software can do.


I read that it is removed because:

1) python2-only

it is not true. Tulip 5.3 work with Python 3.7[¹]

2) dead upstream;

it is not true. It has changed his home page, as I have reported in the 
bug report #851840: -> tulip: wrong project home page


3) RC-buggy;  low popcon

in Debian there was a very old version, so who want to use it need to 
install the upstream latest version.


It can seem very difficult to use, but it is not true, or that you don't 
have need of it, but it can manage a very large set of data and give you 
visual information that let you understand things that can be hard to 
detect elsewhere.


I'm very displeased that this very good piece of software is not in 
Debian :-(


Ciao
Davide

[¹]
https://sourceforge.net/projects/auber/files/tulip/tulip-5.3.1/

Bug#946213: RFS: git-delta/0.0.15 -- Syntax-highlighting pager for git and diff output

[Adam Borowski]

On Thu, Dec 05, 2019 at 11:03:57AM -0500, Dan Davison wrote:
> * Package name: git-delta
>Version : 0.0.15
>Upstream Author : Dan Davison dandavis...@gmail.com
> * URL : https://github.com/dandavison/delta

> It builds the following binary package:
> 
>   delta - A syntax-highlighting pager for git and diff output

That name is already used by an unrelated package.

> *.deb files for the latest version are at
> https://github.com/dandavison/delta/releases/tag/0.0.15

We need sources (ie, the .dsc file and stuff referenced from it) rather than
binary artefacts.

Without the source, I can't upload nor review anything.  On the other hand,
a glance at your tool's README seems awesome!


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#946220: Tries to register with gnome-keyring-daemon every second, spamming the journal

[Michael Biebl]

Package: nextcloud-desktop
Version: 2.6.1-1
Severity: important
Tags: patch fixed-upstream

Hi,

today I noticed, that my journal is spammed every second with this log
message:

Dez 05 19:48:54 pluto gnome-keyring-daemon[1622]: asked to register item 
/org/freedesktop/secrets/collection/login/, but it's already registered

$ journalctl | grep "asked to register item" | wc -l
24100

Turns out this is a nextcloud issue:
See https://github.com/nextcloud/desktop/issues/1592

Would be great if you can cherry-pick this fix for the Debian package.

Regards,
Michael



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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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 nextcloud-desktop depends on:
ii  libc6 2.29-3
ii  libcloudproviders00.3.0-3
ii  libgcc1   1:9.2.1-21
ii  libglib2.0-0  2.62.3-2
ii  libnextcloudsync0 2.6.1-1
ii  libqt5core5a  5.12.5+dfsg-2
ii  libqt5dbus5   5.12.5+dfsg-2
ii  libqt5gui55.12.5+dfsg-2
ii  libqt5keychain1   0.9.1-2
ii  libqt5network55.12.5+dfsg-2
ii  libqt5sql5-sqlite 5.12.5+dfsg-2
ii  libqt5webenginecore5  5.12.5+dfsg-3+b1
ii  libqt5webenginewidgets5   5.12.5+dfsg-3+b1
ii  libqt5webkit5 5.212.0~alpha3-5
ii  libqt5widgets55.12.5+dfsg-2
ii  libqt5xml55.12.5+dfsg-2
ii  libstdc++69.2.1-21
ii  nextcloud-desktop-common  2.6.1-1
ii  nextcloud-desktop-l10n2.6.1-1

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  2.6.1-1

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#946219: python3-nftables non-functional without libnftables-dev

[Michael Biebl]

Package: python3-nftables
Version: 0.9.3-1
Severity: serious

Hi Arturo,

thanks for packaging 0.9.3 so promptly.

Today I wanted to update firewalld to 0.8.0, which makes use of
python3-nftables. Unfortunately, I ran into problems. At first I
suspected that firewalld is buggy, but then it turned out, that
python3-nftables is the culprit. When running firewalld 0.8.0 in debug
mode, the problem became apparent:

# /usr/sbin/firewalld --nofork --nopid --debug
2019-12-05 19:44:13 DEBUG1: Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/firewall/server/decorators.py", line 53, 
in handle_exceptions
return func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/firewall/server/firewalld.py", line 77, 
in __init__
self.fw = Firewall()
  File "/usr/lib/python3/dist-packages/firewall/core/fw.py", line 88, in 
__init__
self.nftables_backend = nftables.nftables(self)
  File "/usr/lib/python3/dist-packages/firewall/core/nftables.py", line 173, in 
__init__
self.nftables = Nftables()
  File "/usr/lib/python3/dist-packages/nftables/nftables.py", line 77, in 
__init__
lib = cdll.LoadLibrary(sofile)
  File "/usr/lib/python3.7/ctypes/__init__.py", line 442, in LoadLibrary
return self._dlltype(name)
  File "/usr/lib/python3.7/ctypes/__init__.py", line 364, in __init__
self._handle = _dlopen(self._name, mode)
OSError: libnftables.so: cannot open shared object file: No such file or 
directory


It seems, that python3-nftables tries to load the .so symlink, not the
actual soversioned library.
Installing libnftables-dev, which provides the symlink, made
python3-nftables functional, but this is of course not a proper fix.

python3-nftables should load libnftables.so.1 instead.

Regards,
Michael



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

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

Versions of packages python3-nftables depends on:
ii  libnftables1  0.9.3-1
ii  python3   3.7.5-3

python3-nftables recommends no packages.

python3-nftables suggests no packages.

-- no debconf information

Bug#945389: Tried to upgrade skimage to see whether #945389 is fixed but failed

[Stefan van der Walt]

Hi Andreas,

On Wed, 04 Dec 2019 09:53:03 +0100, Andreas Tille wrote:
> Hmmm, I think the Cython files are generated in the build I did.

Sorry, I missed that!  I saw at the bottom of the log:

E   AttributeError: type object 'skimage.feature.orb_cy.array' has no
attribute '__reduce_cython__'

Which is an error that has been fixed in Cython 0.28, supposedly:

https://github.com/cython/cython/issues/1894

But it looks like your compilation is using 0.29, so not sure why that
is happening:

Get: 26 http://deb.debian.org/debian sid/main amd64 cython3 amd64
0.29.14-0.1+b1 [2117 kB]

One possibility is that NumPy was compiled with an older version of
Cython:

https://github.com/cython/cython/issues/1953#issuecomment-398128940

Do you know how I can check the source files for the NumPy 1.17 build
that is used here?

The other errors seem to be because no suitable image plugin is
registered.  This can typically be fixed by installing matplotlib or
imageio beforehand, but it looks like you *do* have matplotlib
installed.  Maybe the Cython module imports break everything so badly
that the plugins cannot even load.

> Its correct that the _Maintainer_ is set to Debian Science team.  But
> the actual members of the team (in Debian terminology the _Uploaders_)
> are you and Yaroslav.

Thanks for updating that; I never had the ability to upload to anything
other than mentors.

Best regards,
Stéfan

Bug#946218: RM: boost1.62 -- ROM; obsolete, superseeded by boost1.67

[Dimitri John Ledkov]

Package: ftp.debian.org
Severity: normal

please remove boost1.62 from the unstable, superseeded by boost1.67

Also remove remaining reverse depends of boost1.62, or leave them uninstallable:

cclive
cryptominisat
dbus-cpp

Regards,

Dimitri.

Bug#927313: parsinsert: probably broken on armhf, failing autopkgtests in Ubuntu

[Andreas Tille]

Control: tags -1 unreproducible

On Fri, Jul 26, 2019 at 02:52:34PM -0700, Steve Langasek wrote:
> 
> > So your suggestion is that for future uploads we should run the test
> > written in Debian as autopkgtest as a test for the upstream code.
> 
> Yes, this would catch the problem earlier and fail to build the package on
> architectures where it is broken. Then you could request the old binaries be
> removed from the archive.

I've implemented this and according to

   https://buildd.debian.org/status/package.php?p=parsinsert

all architectures are passing.  Am I missing something?
 
> > > Note that these tests also fail on arm64, i386, and ppc64el in Ubuntu,
> > > suggestings the packages are also broken there, but none of these are
> > > regressions.
> 
> > Thanks a lot for these hints
> 
> My pleasure!

:-)

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#850946: pinentry-curses: does not quit on Ctrl-C (SIGINT), still grabs keys, takes 100% CPU time

[Vincent Lefevre]

Control: reassign -1 gpg-agent 2.2.17-3
Control: retitle -1 gpg-agent: does not terminate pinentry on Ctrl-C (SIGINT)

On 2017-01-11 15:05:50 +0100, Vincent Lefevre wrote:
> When I use
> 
> pinentry-program /usr/bin/pinentry-curses
> 
> in ~/.gnupg/gpg-agent.conf and I do:
> 
> $ gpg -d file.gpg
> 
> I get:
> 
> ┌──┐
> │ Enter passphrase │
> │  │
> │  │
> │ Passphrase:  │
> │  │
> │  │
> └──┘
> 
> Then if I type Ctrl-C, I get back to the shell, but pinentry-curses
> is still running and grab keys, making the terminal and the shell
> unusable: some keys go to the shell (I've tried with both bash and
> zsh), other keys go to pinentry-curses, randomly. If I quit the
> terminal, then pinentry-curses takes 100% CPU time until I manually
> kill it.

According to the upstream bug, the issue is in gpg-agent (and fixed
there upstream, not yet in Debian). Thus reassigning the bug.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#916439: libboost-python1.67-dev: Linking issues, can't find reference to PySlice_New and other symbols

[Dimitri John Ledkov]

On Fri, 14 Dec 2018 13:34:55 + Witold Baryluk
 wrote:
> Package: libboost-python1.67-dev
> Version: 1.67.0-11
> Severity: important
>
>
> Hi,
>
> I was just trying to build LuxCore from source, and after installing all 
> needed
> dependencies, installing Intel Embree manually, I could start compilation of 
> LuxCore,
> (I can provide quick instructions how to do it exactly, it is pretty easy).
>
> however the last step, the linking of the main executable fails:
>

Depending on how boost-python is used one may want to link pythonX.Y,
need to link, or actually not want it at all!

What is LuxCore? Can you point to their configury?

Here is a correct way of doing Cmake + Boost::Python + Python
https://salsa.debian.org/debian/boost/raw/master/debian/tests/srcs/python/CMakeLists.txt

Hopefully, that helps.

Regards,

Dimitri.

Bug#946217: CVE-2019-19333 & CVE-2019-19334 in libyang

[David Lamparter]

Package: libyang0.16
Version: 0.16.105-1
Tags: security
Severity: grave

This is a security issue tracking bug for CVEs:
- CVE-2019-19333
- CVE-2019-19334

Both issues are bugs in processing YANG models and may affect users
loading or validating untrusted YANG models.  This is a relatively rare
use case as normal application use of libyang would rely on application
supplied models.

Fixes are available upstream.

As the package maintainer, my plan for unstable is to ship a 0.16.105-2
quickly, followed by actually bringing 1.0.x into unstable.

I've contacted the Debian security team wrt. fixing this for buster.


-David

Bug#946216: boost1.67: mpi-python appears to be broken

[Dimitri John Ledkov]

Package: boost1.67
Version: 1.67.0-15
Severity: important

Dear Maintainer,

mpi-python3 appears to be completely broken. See autopkgtest, most
likely an upstream issue.

Regards,

Dimitri.

Bug#946126: lintian: Please complain about debian/NEWS.Debian

[Felix Lechner]

Hi Vincent,

On Tue, Dec 3, 2019 at 6:33 PM Vincent McIntyre  wrote:
>
> The reason for this appears to be longstanding, see bug 429510.

That bug indicates that the behavior is inconsistent between README/NEWS/TODO.

> Perhaps lintian could warn about this?

Implemented for NEWS, which was your primary concern:


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

> There may already be a similar check for debian/[README|TODO].Debian

I could not find those checks, but would be happy to add the files.
Unfortunately, I could not figure out from #429510 what the correct
behavior should be. (For example, both README and README.Debian seem
to be in use, but only the latter is shipped.) Please reopen the bug
to add more files.

Thank you for helping to make Lintian better.

Kind regards
Felix Lechner

Bug#946198: Since upgrading to 1.25.13 no remote printer is made available anymore

[Brian Potkin]

Thank you for your report, Michael.



On Thu 05 Dec 2019 at 10:28:20 +0100, Michael Meskes wrote:

> Package: cups-browsed
> Version: 1.25.13-1
> Severity: serious
> 
> Since upgrading the package all remote printers are gone from my printers 
> list.
> Downgrading to the latest version brings them all back.

Which printers list? An application dialog?

> I made this bug serious in case the problem is a general one. If not, feel 
> free
> to downgrade. Upgrading the package and losing the ability to print in the
> process is an unpleasant surprise, though.

The outputs of 'lpstat -a' and 'lpstat -l -e', please. Activating logging
in cups-browsed.conf and taking a look at a log wouldn't be a bad idea.

Regards,

Brian.

Bug#935951: fonts-noto-color-emoji: was updated on August 2019 to support Unicode 12.0 Emoji

[Lisandro Damián Nicanor Pérez Meyer]

On 19/11/01 02:05, Clint Adams wrote:
> On Wed, Aug 28, 2019 at 11:52:23AM -0400, Jeremy Bicha wrote:
> > Google has not officially released the font update. Google tends to
> > not make an official release of the Unicode update until the new
> > Android version is released. Android 10 is expected to be released in
> > a few days.
> > 
> > https://github.com/googlefonts/noto-emoji/releases
> 
> I am not sure what https://github.com/googlefonts/noto-emoji/issues/280
> is telling us.

FWIW, it has been tagged: 


I have just noticed that I can't still render mate-beverage, which for us 
argentinians is quite special :-)

Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory

[Dimitri John Ledkov]

On Tue, 3 Dec 2019 22:03:29 +0100 Giovanni Mascellani 
wrote:
> Hi,
>
> Il 01/12/19 23:33, Dimitri John Ledkov ha scritto:
> > All the broken packages, are RC buggy themselves already. Anything that
> > is using py2 is RC buggy.
>
> I'm sorry, but this does not look like the way Python maintainers asked
> to deal with reverse dependencies: from [1] it is clear that you should
> not remove Python 2 support if you have reverse dependencies using it.
> The right way is to keep Python 2 and make the rev dep's bug affect
#936227.
>
>  [1] https://wiki.debian.org/Python/2Removal
>
> People are using unstable. I agree with the principle that Python 2
> applications should disappear as soon as possible, but breaking things
> randomly is not going to do any good.
>
> Please, if you see a mistake in my reasoning explain me, otherwise I
> will re-enable Python 2 support for 1.67.0 in Debian (I have no idea
> about policies in Ubuntu) until reverse dependencies are clean.
>
> Incidentally, it seems that ledger does not have any Python 2 removal
> related bug. I would file one.
>

In principal I agree, in practice the only broken app today is ledger,
which should have by now uploaded without a python bridge enabled; or build
with python3 bridge as now available from upstream master (ported by me
after this issue was filed / escalated).

It is unfortunate that python2 bridge is built and linked into ledger by
default, even when unused. (i.e. people who don't care about python-bridge
are broken)

There is no class issue of any other debs. And ledger upload is pending, as
discussed with ledger maintainer.

Ledger needs to be fixed regardless, and is getting fixed shortly. I don't
think it's worthwhile rebuilding boost with reintroduced python2 at this
point.

And no, unstable is not supported and frequently has uninstallable
packages, multiple known regressions, RC bugs, and automated autopkgtest
regressions. One should only dist-upgrade unstable packages they use, if
they are ok with the RC bugs and autopkgtest regressions automatically
identified in the builds anyway. Thus no, I will not be making incremental
uploads, to temporarily unbreak unstable users, using hacks which are not
the way we intend to ship in testing later as that is added churn and drag
on the development (ie. port/rebuild ledger in this case).

Regards,

Dimitri.

Bug#922818:

[Didin Sahidin]

Bug#946214: chicken: FTBFS on armel

[Davide Puricelli]

On Thu, Dec 05, 2019 at 04:05:52PM +, Ivo De Decker wrote:
> package: src:chicken
> version: 5.1.0-1
> severity: serious
> tags: ftbfs
> 
> Hi,
> 
> The latest upload of chicken to unstable fails on armel:
> 
> https://buildd.debian.org/status/package.php?p=chicken
> 
> Note that, in addiotion to a fix for this FTBFS, a source-only upload is
> necessary to allow migration to testing (the last upload included binaries for
> amd64).
> 
> Cheers,
> 
> Ivo


Hello, I have being working on this issue with upstream and the new
upcoming release of Chicken (out in a few days) will address the build
error on armel.
Next upload will be source-only.

Regards,
-- 
Davide Puricelli
http://www.puricelli.info | http://www.debian.org

Time looked like snow dropping silently into a black room -- Ray Bradbury

Bug#922818:

[Didin Sahidin]

Bug#914821: Re: libio-pty-perl: New upstream version - 1.12

[gregor herrmann]

On Thu, 05 Dec 2019 12:15:27 +0100, Joergen Haegg wrote:

> > Also if you want, package maintainance can be taken under Pkg-Perl umbrella.
> That would probably be better.

Excellent, thank you!

So who wants to do the takeover? Felix, Xavier? I can as well.


Joergen, I see that you also maintain libexpect-perl; should we move
this under the pkg-perl umbrella as well?


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#946215: prometheus-varnish-exporter: FTBFS i386, mips64el, mipsel, ppc64el, s390x

[Ivo De Decker]

package: src:prometheus-varnish-exporter
version: 1.5-1
severity: serious
tags: ftbfs

Hi,

The latest upload of prometheus-varnish-exporter to unstable fails on all
architectures:

https://buildd.debian.org/status/package.php?p=prometheus-varnish-exporter

Cheers,

Ivo

Bug#945986: Converting a disk with a backing chain including one resized is stucked in a loop

[Michael Tokarev]

Control: fixed -1 1:2.10.0-1

05.12.2019 18:35, Michael Tokarev wrote:

Control: fixed -1 1:3.1+dfsg-8+deb10u3


Actually this is fixed by this commit:

commit c61e684e44272f2acb2bef34cf2aa234582a73a9
Author: Eric Blake 
Date:   Thu May 4 21:15:00 2017 -0500

block: Exploit BDRV_BLOCK_EOF for larger zero blocks

When we have a BDS with unallocated clusters, but asking the status
of its underlying bs->file or backing layer encounters an end-of-file
condition, we know that the rest of the unallocated area will read as
zeroes.  However, pre-patch, this required two separate calls to
bdrv_get_block_status(), as the first call stops at the point where
the underlying file ends.  Thanks to BDRV_BLOCK_EOF, we can now widen
the results of the primary status if the secondary status already
includes BDRV_BLOCK_ZERO.

In turn, this fixes a TODO mentioned in iotest 154, where we can now
see that all sectors in a partial cluster at the end of a file read
as zero when coupling the shorter backing file's status along with our
knowledge that the remaining sectors came from an unallocated cluster.

Also, note that the loop in bdrv_co_get_block_status_above() had an
inefficent exit: in cases where the active layer sets BDRV_BLOCK_ZERO
but does NOT set BDRV_BLOCK_ALLOCATED (namely, where we know we read
zeroes merely because our unallocated clusters lie beyond the backing
file's shorter length), we still ended up probing the backing layer
even though we already had a good answer.

Which went into qemu 2.10.

However, backporting it to 2.8 requires a bit more of background,
i/o subsystem has been modified significantly between 2.8 and 2.10.

Thanks,

/mjt

Bug#946213: RFS: git-delta/0.0.15 -- Syntax-highlighting pager for git and diff output

[Dan Davison]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "git-delta":

* Package name: git-delta
   Version : 0.0.15
   Upstream Author : Dan Davison dandavis...@gmail.com
* URL : https://github.com/dandavison/delta
* License : MIT
* Vcs : https://github.com/dandavison/delta
   Section : devel

It builds the following binary package:

  delta - A syntax-highlighting pager for git and diff output

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

  https://github.com/dandavison/delta

*.deb files for the latest version are at
https://github.com/dandavison/delta/releases/tag/0.0.15


Thanks,

Dan Davison

Bug#946214: chicken: FTBFS on armel

[Ivo De Decker]

package: src:chicken
version: 5.1.0-1
severity: serious
tags: ftbfs

Hi,

The latest upload of chicken to unstable fails on armel:

https://buildd.debian.org/status/package.php?p=chicken

Note that, in addiotion to a fix for this FTBFS, a source-only upload is
necessary to allow migration to testing (the last upload included binaries for
amd64).

Cheers,

Ivo

Bug#946041: fixed in unison 2.48.4-3

[gregor herrmann]

On Thu, 05 Dec 2019 10:23:59 +0100, Stéphane Glondu wrote:

> > I seems that the NEWS file hasn't made it into the binary package;
> > probably because in the source package it's called debian/NEWS.Debian
> > whereas dh_installchangelogs looks for debian/NEWS or
> > debian/PACKAGE.NEWS (and then installs it as
> > /u/s/d/PACKAGE/NEWS.Debian).
> Fixed in 2.48.4-4.

Thank you!


Cheers,
gregor 

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


signature.asc
Description: Digital Signature

Bug#946212: dbus-python: unsatisfiable cross Build-Depends sphinx-common

[Helmut Grohne]

Source: dbus-python
Version: 1.2.14-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

dbus-python cannot satisfy its cross Build-Depends, because the
dependency on sphinx-common is not satisfiable. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch: foreign or annotated :native. In this case, we can
fully elide the depedency from an arch-only build by making the dh addon
optional. Please consider applying the attached patch.

Helmut
diff --minimal -Nru dbus-python-1.2.14/debian/changelog 
dbus-python-1.2.14/debian/changelog
--- dbus-python-1.2.14/debian/changelog 2019-11-25 20:18:13.0 +0100
+++ dbus-python-1.2.14/debian/changelog 2019-12-05 16:13:09.0 +0100
@@ -1,3 +1,10 @@
+dbus-python (1.2.14-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Cross satisfiability: remove sphinx-common dependency. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 05 Dec 2019 16:13:09 +0100
+
 dbus-python (1.2.14-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru dbus-python-1.2.14/debian/control 
dbus-python-1.2.14/debian/control
--- dbus-python-1.2.14/debian/control   2019-11-25 20:18:13.0 +0100
+++ dbus-python-1.2.14/debian/control   2019-12-05 16:12:59.0 +0100
@@ -27,7 +27,6 @@
  python3-all-dev,
  python3-gi,
  python3-tap ,
- sphinx-common,
  xmlto,
 Build-Depends-Indep:
  python3-sphinx,
diff --minimal -Nru dbus-python-1.2.14/debian/rules 
dbus-python-1.2.14/debian/rules
--- dbus-python-1.2.14/debian/rules 2019-11-25 20:18:13.0 +0100
+++ dbus-python-1.2.14/debian/rules 2019-12-05 16:07:55.0 +0100
@@ -21,7 +21,8 @@
 FLAVOURS := $(patsubst %,%-dbg,$(PYTHON2) $(PYTHON3)) $(PYTHON2) $(PYTHON3)
 
 %:
-   dh $@ --with sphinxdoc --buildsystem=autoconf
+   dh $@ $(DH_ADDONS) --buildsystem=autoconf
+build binary %-indep: DH_ADDONS=--with=sphinxdoc
 
 # The special case for 2.7-dbg is a workaround. Python 2 doesn't have the
 # LDVERSION sysconfig variable, which would give AX_PYTHON_DEVEL the

Bug#945986: Converting a disk with a backing chain including one resized is stucked in a loop

[Michael Tokarev]

Control: fixed -1 1:3.1+dfsg-8+deb10u3

02.12.2019 12:55, DarthDragon wrote:

Package: qemu-utils
Version: 1:2.8+dfsg-6+deb9u8


Hmm. This is oldstable. Why can't you run current stable?
At least use the qemu-img utility from current stable if
you can't upgrade whole system. Oldstable receives only
critical fixes, and since this issue hasn't been reported
before, during whole debian 9.0 stretch cycle..
You provided a relatively simple testcase, yet it needs
quite some work still to find out where the bug has been
fixed.


Converting with buster version (1:3.1+dfsg-8+deb10u3) is working.


Marking as fixed in buster.

Thanks!

/mjt

Bug#946098: Please move the VCS to the DPMT Salsa group

[Louis-Philippe Véronneau]

On 19-12-05 06 h 45, Martin Pitt wrote:
> I'd like to remove the old repo at
> https://salsa.debian.org/debian/python-dbusmock/edit , but despite the
> "Advanced" title saying "Housekeeping, export, path, transfer, remove,
> archive", there is no removal there. So for now I just pushed a commit there
> that removes all files and replaces them with a README.

As per the Salsa documentation [1], you need to ask the Salsa admins to
delete a repository in the Debian group.

You can contact them here [2].

Cheers,

[1]:
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

[2]: https://wiki.debian.org/Salsa/Doc#Support

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#946211: php7.3-fpm: does not depend on used procps

[Adrian Heine]

Package: php7.3-fpm
Severity: minor

php7.3-fpm.service uses /bin/kill but the package doesn't depend on procps.

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

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

Versions of packages php7.3-fpm depends on:
ii  libapparmor12.13.3-7
ii  libargon2-1 0~20171227-0.2
ii  libc6   2.29-3
ii  libmagic1   1:5.37-6
ii  libpcre2-8-010.34-3+b1
ii  libsodium23 1.0.18-1
ii  libssl1.1   1.1.1d-2
ii  libsystemd0 244-3
ii  libxml2 2.9.4+dfsg1-8
ii  mime-support3.64
pn  php7.3-cli  
pn  php7.3-common   
pn  php7.3-json 
pn  php7.3-opcache  
ii  tzdata  2019c-3
ii  ucf 3.0038+nmu1
ii  zlib1g  1:1.2.11.dfsg-1+b1

php7.3-fpm recommends no packages.

Versions of packages php7.3-fpm suggests:
pn  php-pear  

Bug#946210: qemu-system-x86: VNC unix socket deleted after first client disconnects

[Michael Tokarev]

Control: fixed -1 1:4.1-1

05.12.2019 15:33, Richard Braun wrote:

The problem has been fixed upstream.

See https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg02774.html
for the details.


Thanks for the link. I'll see if this can be fixed in buster.
This is upstream commit 73564c407caedf992a1c688b5fea776a8b56ba2a.

/mjt

Bug#946208: rust-onig: autopkgtest times out and creates insane log size (1.1 GB compressed)

[Paride Legovini]

Paul Gevers wrote on 05/12/2019:
> Source: rust-onig
> Version: 5.0.0-1
> X-Debbugs-CC: debian...@lists.debian.org
> Severity: important
> User: debian...@lists.debian.org
> Usertags: timeout issue
> 
> Dear maintainers,
> 
> Since version 5.0.0-1 of your package your package has an autopkgtest,
> great. However, it is bringing the ci.d.n infrastructure down because of
> the insane log file it is creating in the forth test (we'll fix that as
> well). The test doesn't even finish before it times out (after 2:47h).
> 
> admin@ci-worker07:~$ sudo ls -alh /command4-stderr.gz
> -rw-r--r-- 1 debci debci 1.1G Dec  5 11:02 /command4-stderr.gz
> admin@ci-worker07:~$ sudo cat /summary
> command1 FAIL non-zero exit status 101
> command2 PASS
> command3 PASS
> command4 FAIL timed out
> 
> Can you please disable the fourth test or make sure that the log isn't
> so incredibly big?

Hi Paul,

Thanks for the heads-up. That's not normal; I'll disable the test for
the moment and then we'll try to understand what's happening there.

Paride

Bug#944744: bitcoind: Status of the Bitcoin Core package in Debian

[Marco Falke]

> What I expect to be realistic is including e.g. 0.20.0 shortly before
> freeze of bullseye, have it included when bullseye becomes stable 3-6
> months later, and then when 0.20.1 comes out cherry-pick
> security-related patches from that (or possibly use upstream release
> directly if it _only_ contains conservative minimal security-related
> changes) and push that the stable, and repeat for each minor release of
> 0.20 branch, and finally when upstream drops support for 0.20 branch
> either let it bitrot until a severe flaw is discovered that noone
> contributes a patch for, or proactively kick it out of stable/unstable.


I expect bullseye to be around until at least 2026, which would
coincide with the release of Bitcoin Core 32 or so. We don't have the
resources to maintain ten major versions of Bitcoin Core, so we'd have
to provide LTS versions of Bitcoin Core. However, with the code base
changing rapidly, security backports become non-trivial not only in
cherry-picking them, but also in evaluating their impact and
interactions with the code base at the time in the past. Given that
the Debian Bitcoin Core package replaced our subtree dependencies with
system dependencies, doesn't help in that regard. See also slightly
related https://twitter.com/videolan/status/1153976062361178112

The alternative to kick the package out after it is considered no
longer secure and removing it from users without replacement doesn't
seem too convincing either.

Finally, I wonder what the quality assurance process for the Debian
Bitcoin Core package looks like. Given that the package is heavily
modified (e.g. subtree dependencies), it does not fully benefit from
the upstream release process testing.

-- Marco

Bug#946043: ITP: python3-flask-caching -- caching module for flask apps

[Jonathan Carter]

On 2019/12/05 15:15, Matthias Klose wrote:
> On 03.12.19 11:33, Jonathan Carter wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Jonathan Carter 
>>
>> * Package name: python3-flask-caching
>>   Version : 1.8.0
>>   Upstream Author : Peter Justin
>> * URL : https://github.com/sh4nks/flask-caching
>> * License : BSD-3-clause
>>   Programming Lang: Python
>>   Description : caching module for flask apps
>>
>> Flask extension that provides smart caching support.
>>
>> This is a fork of python3-flask-cache that is still maintained,
>> which maintains a high level of backward compatibility and new
>> features.
>>
>> This package will be maintained as part of the Debian Python modules team.
> 
> I don't understand why you have the '3' in the source name.

Just a mistake in the ITP, actual source name is just flask-caching.

-Jonathan


-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

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

[李健秋]

Package: libsnappy-dev
Followup-For: Bug #940330

Dear Maintainer,

I hit the same issue. And I found add "POSITION_INDEPENDENT_CODE on" in
CMakelists.txt solves the problem:
```
-SET_TARGET_PROPERTIES(snappy-static PROPERTIES OUTPUT_NAME snappy)
+SET_TARGET_PROPERTIES(snappy-static PROPERTIES POSITION_INDEPENDENT_CODE on 
OUTPUT_NAME snappy)
```

Best regards,
-Andrew