Bug#897082: lintian: Please do not warn about debian-watch-uses-insecure-uri for ftp:// URIs

[Andreas Tille]

Package: lintian
Severity: normal

Hi,

lintian is warning (rather "informing") about insecure URIs when ftp is
used.  For instance the package seaview gets:

I: seaview source: debian-watch-uses-insecure-uri 
ftp://pbil.univ-lyon1.fr/pub/mol_phylogeny/seaview/archive/seaview_(.*)\.tar\.gz

Since there is no anonymous secure ftp this info is not very helpful IMHO.

Kind regards and thanks for maintaining lintian

Andreas.


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

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

Versions of packages lintian depends on:
ii  binutils  2.28-5
ii  bzip2 1.0.6-8.1
pn  diffstat  
ii  dpkg  1.18.24
ii  file  1:5.30-1+deb9u1
pn  gettext   
pn  intltool-debian   
ii  libapt-pkg-perl   0.1.32
pn  libarchive-zip-perl   
pn  libclass-accessor-perl
pn  libclone-perl 
ii  libdpkg-perl  1.18.24
pn  libemail-valid-perl   
pn  libfile-basedir-perl  
pn  libipc-run-perl   
ii  liblist-moreutils-perl0.416-1+b1
pn  libparse-debianchangelog-perl 
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-3+deb9u3
pn  libtext-levenshtein-perl  
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
pn  libxml-simple-perl
pn  libyaml-libyaml-perl  
ii  man-db2.7.6.1-2
pn  patchutils
ii  perl  5.24.1-3+deb9u3
pn  t1utils   
ii  xz-utils  5.2.2-1.2+b1

Versions of packages lintian recommends:
ii  dpkg 1.18.24
pn  libperlio-gzip-perl  
ii  perl 5.24.1-3+deb9u3
ii  perl-modules-5.24 [libautodie-perl]  5.24.1-3+deb9u3

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  dpkg-dev   
ii  libhtml-parser-perl3.72-3
ii  libtext-template-perl  1.46-1

Bug#896827: perl: FTBFS on riscv64: t/re/fold_grind timeout

[Niko Tyni]

On Thu, Apr 26, 2018 at 09:09:27AM +0200, Manuel A. Fernandez Montecelo wrote:
> 
> But since longer builds are not a problem for us, as long as it
> doesn't affect other architectures, it'll be better to increase the
> factor for this arch, to be on the safe side.

Thanks. I did this in 5.26.2-3, we'll see how it goes.
-- 
Niko

Bug#837509: installation-reports: Partial success on Novena (no USB during install)

[Michael Fincham]

Hi all,

On Sat, 24 Jun 2017 20:36:04 +0200, Cyril Brulebois wrote: 
> Can you please attach lsmod's output from the installed system?

Here's lsmod from a freshly installed stretch 20170615+deb9u3 installer build. 
This is with the
standard supplied WiFi / bluetooth card installed.

Module  Size  Used by
binfmt_misc 9306  1
joydev  9536  0
imx_ipuv3_crtc 10765  0
ath3k   7893  0
btusb  31088  0
btrtl   5113  1 btusb
btbcm   5955  1 btusb
btintel 7295  1 btusb
arc41958  2
asix   31435  0
snd_soc_imx_es8328  4039  0
usbnet 25926  1 asix
mii 4166  2 usbnet,asix
bluetooth 464225  5 btrtl,btintel,btbcm,ath3k,btusb
sg 23445  0
stmpe_ts4057  0
snd_soc_es8328_i2c  1536  1
imx_ipu_v3 76309  1 imx_ipuv3_crtc
snd_soc_es8328 16632  1 snd_soc_es8328_i2c
mma845215298  0
industrialio_triggered_buffer 1742  1 mma8452
kfifo_buf   2714  1 industrialio_triggered_buffer
ath9k  89781  0
industrialio   47740  3 mma8452,industrialio_triggered_buffer,kfifo_buf
sbs_battery 8266  0
snd_soc_imx_audmux  4970  1 snd_soc_imx_es8328
ath9k_common   22634  1 ath9k
ath9k_hw  419253  2 ath9k,ath9k_common
ath18696  3 ath9k_hw,ath9k,ath9k_common
snd_soc_fsl_ssi14648  2
imx_pcm_dma 1244  1 snd_soc_fsl_ssi
imx_pcm_fiq 5167  1 snd_soc_fsl_ssi
imx_ldb 8343  0
mac80211  584961  1 ath9k
snd_soc_core  146641  6
snd_soc_fsl_ssi,snd_soc_es8328_i2c,snd_soc_es8328,snd_soc_imx_es8328,imx_pcm_dma,imx_pcm_fiq
snd_pcm_dmaengine   3583  1 snd_soc_core imx2_wdt4228  0
snd_pcm83540  5
snd_soc_fsl_ssi,snd_pcm_dmaengine,snd_soc_es8328,snd_soc_core,imx_pcm_fiq 
snd_timer
20381  1 snd_pcm snd55441  4 
snd_timer,snd_soc_es8328,snd_soc_core,snd_pcm
imx_keypad  5683  0
soundcore   5571  1 snd
matrix_keymap   2339  1 imx_keypad
cfg80211  479516  4 mac80211,ath9k,ath,ath9k_common
rfkill 16819  3 bluetooth,cfg80211
spi_imx12565  0
dw_hdmi_imx 3203  0
imxdrm  5486  2 imx_ldb,imx_ipuv3_crtc
dw_hdmi14266  1 dw_hdmi_imx
drm_kms_helper117682  5 imx_ldb,imx_ipuv3_crtc,dw_hdmi,imxdrm
etnaviv66373  0
evdev  12804  1
leds_gpio   3390  0
drm   276542  8
imx_ldb,imx_ipuv3_crtc,etnaviv,dw_hdmi,dw_hdmi_imx,imxdrm,drm_kms_helper pwm_bl
4989  0 ip_tables  12425  0
x_tables   14864  1 ip_tables
autofs433093  2
ext4  553026  2
crc16   1274  2 bluetooth,ext4
jbd2   94340  1 ext4
crc32c_generic  1862  4
fscrypto   15434  1 ext4
ecb 2191  0
mbcache 5508  3 ext4
dm_mod103473  6
sd_mod 33243  2
pfuze100_regulator 13107  1
ahci_imx6207  1
libahci_platform6494  1 ahci_imx
libahci23377  2 libahci_platform,ahci_imx
libata193250  3 libahci_platform,libahci,ahci_imx
ci_hdrc_imx 7000  0
ci_hdrc35271  1 ci_hdrc_imx
extcon_core13057  1 ci_hdrc
ehci_hcd   65926  1 ci_hdrc
udc_core   26904  1 ci_hdrc
scsi_mod  188563  3 sd_mod,libata,sg
sdhci_esdhc_imx12223  0
sdhci_pltfm 3338  1 sdhci_esdhc_imx
sdhci  39644  2 sdhci_pltfm,sdhci_esdhc_imx
usbcore   199268  6 usbnet,ehci_hcd,ath3k,btusb,asix,ci_hdrc
usb_common  3659  3 udc_core,usbcore,ci_hdrc
i2c_imx15628  0
usbmisc_imx 6696  1 ci_hdrc_imx
phy_mxs_usb 6462  2
anatop_regulator4712  1
micrel  9942  1

-- 
Michael


pgpvick1Z6TlE.pgp
Description: PGP signature

Bug#896977: starlink-votable-java: new version misses versioned depends on packages from starjava-fits

[Paul Gevers]

Hi Ole,

On 27-04-18 22:51, Ole Streicher wrote:
> I didn't miss this. As I wrote in my last comment: starlink-votable-java
> works nicely with the old starlink-table-java.

Oops, I forgot to check the bug (why, o why doesn't the bts enable us to
auto-subscribe to all the bugs we report, ah right, Debian is a do-ocracy).

> It is just the tests that
> need to be updated, but for a user both packages play together well. In
> fact, the problem is *not* starlink-votable-java in this case, but it is
> a bug in starlink-table-java. It is already buggy, the bug just does not
> show up in the CI test with the old version of starlink-votable-java.
> And an update (for starlink-table-java) is already uploaded.

Ok

> IMO this is a problems with the CI tests: it is great to have the tests,
> and to see where we have incompatibilities. However often the problems
> shown are minor, and so for migration I would like to have a "that is
> OK" button there, which overrides a migration veto.

Migration isn't blocked (for now). Please read my proposed
announcement¹. In the far future, if/when we do block migration, filing
a bug against rele...@debian.org package can get you a badtest hint.
There is also bug 851558, which request the dep8 specification to an "do
not block migration on this test" feature. If individual DD's need
access to the "this is OK" feature, we'll need to come up with a
mechanism for that with the release team. In the current system, a
badhint test is needed, which can be created by them (so a bug against
rele...@debian.org could get you that; yes, work for humans, so not
perfectly for what you have in mind).

> Usually we allow packages to migrate when there is no "serious" bug, but
> many test failures would normally indicate only "normal" or "important"
> bugs, and should therefore (at least as an option) not hinder migration.
> Restricting the tests to RC stuff is also not a good solution here,
> since then I would lose a big utility for my QC. And usually I can't
> weight the importance for individual CI tests beforehand myself: they
> are written by upstream, and sometimes (astropy) they are so many
> (~10.000) that I have no chance to sort them. I usually check the result
> when I see a failure, and often need to contact upstream to estimate the
> severity of a failure.
> 
> So: Not all CI test failures show a "serious" (RC) problem with the
> upgraded package. In many cases the problem is minor, and the migration
> logic should take this into account.

Ack. That is the reason why we set up britney like we have, and why the
bugs that I file² are nearly all at the severity normal (some even
wishlist). I try to judge the severity when I file the bug, by trying to
understand (from the logs and changelog, often also the test code).

Paul

¹ https://gobby.debian.org/export/Teams/Release/using-autopkgtest
²
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org



signature.asc
Description: OpenPGP digital signature

Bug#897080: Please detect long descriptions starting with lowercase to catch short descriptions continuing into long

[Josh Triplett]

Package: lintian
Version: 2.5.84
Severity: wishlist

I don't know how well this will work or if it will produce false
positives, but inspired by having just reported yet another bug about a
package whose short description contained the start of a sentence that
continued into the long description, I wonder if Lintian could try to
detect that somehow.

One possibility would be to check for a long description that starts
with a lowercase letter, other than the case where the long description
starts with the package name or a word from the package name. That
*might* still produce some false positives, though.

If that still produces too many false positives, perhaps it would work
to check for a short description that looks like a sentence followed by
more words, and *then* a lowercase word starting the description. For
instance:

Description: words words words. Words words
 words words words. Words words words.


Does that seem plausible?

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

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

Versions of packages lintian depends on:
ii  binutils  2.30-16
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.5
ii  file  1:5.33-1
ii  gettext   0.19.8.1-6
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.34
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.99-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.2-2
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.25-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.3-2
ii  patchutils0.3.4-2
ii  perl  5.26.2-2
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.52-1

-- no debconf information

Bug#897081: wmfrog: Does not update weather regularly

[Yavor Doganov]

Package: wmfrog
Version: 0.3.1+git20161115-1
Severity: important

I launched wmfrog about 24 hrs ago with the arguments "-s LBWN -o +3 -m"
but it has updated only once since then.

$ LC_ALL=C ls -la ~/.wmapps/LBWN*
-rw-r--r-- 1 yavor yavor 113 Apr 27 20:29 /home/yavor/.wmapps/LBWN
-rw-r--r-- 1 yavor yavor   0 Apr 28 07:34 /home/yavor/.wmapps/LBWN_dat

The file LBWN_dat gets updated every 5 minutes (as expected) but LBWN
was updated only once and it seems the app is getting the data from
there.  FWIW, the wmweather package is working properly with the same
station (updating every 30 minutes).

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

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

Versions of packages wmfrog depends on:
ii  libc6 2.27-3
ii  libx11-6  2:1.6.5-1
ii  libxext6  2:1.3.3-1+b2
ii  libxpm4   1:3.5.12-1
ii  perl  5.26.2-2
ii  wget  1.19.4-1

wmfrog recommends no packages.

wmfrog suggests no packages.

-- no debconf information

Bug#897079: Short description continues into long description

[Josh Triplett]

Package: postgresql-10-wal2json
Version: 1.0-1
Severity: normal

> Description: wal2json is an output plugin for logical decoding. It means that
>  the plugin have access to tuples produced by INSERT and UPDATE. Also,
>  UPDATE/DELETE old row versions can be accessed depending on the configured
>  replica identity. Changes can be consumed using the streaming protocol
>  (logical replication slots) or by a special SQL API.

>From Policy 3.4.2. The extended description:

> Do not try to continue the single line synopsis into the extended
> description. This will not work correctly when the full description is
> displayed, and makes no sense where only the summary (the single line
> synopsis) is available.

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

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

Versions of packages postgresql-10-wal2json depends on:
ii  libc6  2.27-3
pn  postgresql-10  

postgresql-10-wal2json recommends no packages.

postgresql-10-wal2json suggests no packages.

Bug#897078: RFS: fcitx-qt5/1.2.2-2

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-input-met...@lists.debian.org a...@debian.org
czc...@debian.org

  Dear mentors and debian-input-method team members,

  I am looking for a sponsor for team package "fcitx-qt5". This upload fixes the
"break" relationship of new fcitx5-module-quickphrase-editor package against the
old fcitx-module-quickphrase-editor together with other minor fixes.

  Besides, I am looking for a DD to grant me the Master Role on Salsa packaging
repository (https://salsa.debian.org/debian/fcitx-qt5) so that I could push the
commits onto Salsa. After that, it would be great if someone could
help to delete
the old packaging repository
(https://anonscm.debian.org/git/pkg-ime/fcitx-qt5.git).

 * Package name: fcitx-qt5
   Version : 1.2.2-2
   Upstream Author : Weng Xuetian 
 * URL : https://github.com/fcitx/fcitx-qt5
 * License : GPL-2+
   Section : libs

  It builds those binary packages:

fcitx-frontend-qt5 - Free Chinese Input Toy of X - Qt5 IM Module frontend
 fcitx5-module-quickphrase-editor - Flexible Input Method Framework -
Quick Phrase editor module
 libfcitx-qt5-1 - Free Chinese Input Toy of X - D-Bus client libraries for Qt5
 libfcitx-qt5-data - Free Chinese Input Toy of X - data files for Qt5
integration
 libfcitx-qt5-dev - Free Chinese Input Toy of X - Devel files for libfcitx-qt5

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

  https://mentors.debian.net/package/fcitx-qt5


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

dget -x 
https://mentors.debian.net/debian/pool/main/f/fcitx-qt5/fcitx-qt5_1.2.2-2.dsc

  The new git packaging repo on Salsa (not updated for now):

https://salsa.debian.org/debian/fcitx-qt5

  The old git packaging repo on Alioth (updated for 1.2.2-2):

https://anonscm.debian.org/git/pkg-ime/fcitx-qt5.git

  Changes since the last upload:

fcitx-qt5 (1.2.2-2) unstable; urgency=medium
.
  * Team upload.
  * Bump Standards-Version to 4.1.4. (no changes needed)
  * d/patches: Backport upstream patch to fix FTBFS with Qt 5.11.
  * d/control: Fix versioned break relationship for quickphrase editor.

--
  Regards,
   Boyuan Yang

Bug#897077: RFS: fcitx/1:4.2.9.6-2

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: a...@debian.org czc...@debian.org
debian-input-met...@lists.debian.org

  Dear mentors and debian-input-method team members,

  I am looking for a sponsor for team package "fcitx". This upload
mainly focuses on the migration of Vcs packaging repo from Alioth to Salsa,
together with some other minor fixes.

 * Package name: fcitx
   Version : 1:4.2.9.6-2
   Upstream Author : Weng Xuetian 
 * URL : https://github.com/fcitx/fcitx
 * License : GPL-2+
   Section : utils

  It builds those binary packages:

fcitx - Flexible Input Method Framework
 fcitx-bin  - Flexible Input Method Framework - essential binaries
 fcitx-data - Flexible Input Method Framework - essential data files
 fcitx-frontend-all - Flexible Input Method Framework - frontends metapackage
 fcitx-frontend-gtk2 - Flexible Input Method Framework - GTK+ 2 IM
Module frontend
 fcitx-frontend-gtk3 - Flexible Input Method Framework - GTK+ 3 IM
Module frontend
 fcitx-frontend-qt4 - Flexible Input Method Framework - Qt4 IM Module frontend
 fcitx-libs - Flexible Input Method Framework - metapackage for libraries
 fcitx-libs-dev - Flexible Input Method Framework - library development files
 fcitx-module-dbus - Flexible Input Method Framework - D-Bus module
and IPC frontend
 fcitx-module-kimpanel - Flexible Input Method Framework - KIMPanel
protocol module
 fcitx-module-lua - Flexible Input Method Framework - Lua module
 fcitx-module-x11 - Flexible Input Method Framework - X11 module and
XIM frontend
 fcitx-modules - Flexible Input Method Framework - core modules
 fcitx-pinyin - Flexible Input Method Framework - classic Pinyin engine
 fcitx-qw   - Flexible Input Method Framework - QuWei engine
 fcitx-table - Flexible Input Method Framework - table engine
 fcitx-table-all - Flexible Input Method Framework - tables metapackage
 fcitx-table-bingchan - Flexible Input Method Framework - Bingchan table
 fcitx-table-cangjie - Flexible Input Method Framework - Cangjie table
 fcitx-table-dianbaoma - Flexible Input Method Framework - Dianbaoma table
 fcitx-table-erbi - Flexible Input Method Framework - Erbi table
 fcitx-table-wanfeng - Flexible Input Method Framework - Wanfeng table
 fcitx-table-wbpy - Flexible Input Method Framework - WubiPinyin table
 fcitx-table-wubi - Flexible Input Method Framework - Wubi table
 fcitx-table-ziranma - Flexible Input Method Framework - Ziranma table
 fcitx-tools - Flexible Input Method Framework - various tools
 fcitx-ui-classic - Flexible Input Method Framework - Classic user interface
 gir1.2-fcitx-1.0 - GObject introspection data for fcitx
 libfcitx-config4 - Flexible Input Method Framework - configuration
support library
 libfcitx-core0 - Flexible Input Method Framework - library of core functions
 libfcitx-gclient1 - Flexible Input Method Framework - D-Bus client
library for Glib
 libfcitx-qt0 - Flexible Input Method Framework - Meta package for Qt library
 libfcitx-utils0 - Flexible Input Method Framework - utility support library

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/f/fcitx/fcitx_4.2.9.6-2.dsc

  Salsa packaging repository:

https://salsa.debian.org/debian/fcitx

  Changes since the last upload:

fcitx (1:4.2.9.6-2) unstable; urgency=medium
.
  * Team upload.
  * d/control: Use Salsa repository for Vcs fields.
  * d/control: Bump Standards-Version to 4.1.4 (no changes needed).
  * d/control: Fix Break relationship with fcitx-module-quickphrase-editor,
let fcitx-modules recommends fcitx5-module-quickphrase-editor.


--
Regards,
Boyuan Yang

Bug#896969: Info received (Bug#896969: Acknowledgement (nlohmann-json: Version 3.1.2 is now available - any reason not to update?))

[Wookey]

On 2018-04-27 03:39 +, Debian Bug Tracking System wrote:
I have prepared a 3.1.2 package (just needed a uupdate and a couple of minor 
changes)

horizon-eda builds against that package so that works.

I'll test some of the others. 

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#897055: RFS: xml2/0.5-2 [QA]

[Boyuan Yang]

2018-04-28 1:05 GMT+08:00 Boyuan Yang <073p...@gmail.com>:
> Package: sponsorship-requests
> Severity: normal
>
>   Dear mentors,
>
>   I am looking for a sponsor for package "xml2" as a QA upload. The
> main point is the migration of Vcs fields from Alioth to Salsa:
>
>  * Package name: xml2
>Version : 0.5-2
>  * URL : [defunct]
>  * License : GPLv2
>Section : utils

Besides, it would be great if someone could help to delete the git repository on
Alioth platform ( scm.alioth.debian.org:/git/collab-maint/xml2.git )
together with this upload.

--
Thanks,
Boyuan Yang

Bug#897076: libjemalloc1: Version 3.6.0-11(unstable) error : Error in munmap(): Invalid argument

[Casey C]

Package: libjemalloc1
Version: 3.6.0-11(unstable)
Severity: important

Dear Maintainer,

When attempting to run a program which requires libjemalloc1 the error: 
": Error in munmap(): Invalid argument"
appears. This error is isolated to the Debian build 3.6.0-11(unastable). 
I downloaded and installed the Ubuntu version 3.6.0-9ubuntu1 and no longer
receive the error, and Blender now runs. 

-- System Information:
Debian Release: buster/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (500, 'unstable')
Architecture: powerpc (ppc64)

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

Versions of packages libjemalloc1 depends on:
ii  libc6  2.27-3

libjemalloc1 recommends no packages.

libjemalloc1 suggests no packages.

-- no debconf information

Bug#897075: nmu: hdf5_1.10.0-patch1+docs-4

[Drew Parsons]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

For some reason m68k and sh4 got missed in the mass binNMU of hdf5 for
the openmpi3 transition. openmpi3 is built on both (openmpi 3.0.1-8
for sh) so I don't think they should be skipped.

nmu hdf5_1.10.0-patch1+docs-4 . m68k sh4 . unstable . -m "Rebuild against 
libopenmpi3."

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

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

Bug#897074: md5sum -c hanging

[Wadih]

Package: coreutils
Version: 8.23-4
Debian Release: jessie/stable

The behavior when running "md5sum -c all.md5" with the "all.md5" file
containing the following as example:

(all.md5)
d41d8cd98f00b204e9800998ecf8427e  -

results in md5sum hanging as it is waiting for stdin inside the code which
shouldn't be since a script writer using "md5sum -c" is expecting a check &
return of control.

I stumbled on that behavior unexpectedly today, and found this existing bug
and I am adding my feedback. 

To give some context, the above file was generated inadvertently by a failed
"find" command which fed a null into md5sum:

(the stdin was null)find ./path -print0 | xargs -0 md5sum >
all.md5
^ find command failed, passing null to md5sum,
and thus the resulting file above

One might argue that the output of md5sum should remain as is including the
"-", however the "md5sum -c" command regardless shouldn't hang when
processing such a file. 

Also, this behavior has a security implication as it could be weaponized as
a denial of service my a malicious user crafting such a file in
anticipiation of "md5sum -c" reading it.

For that reason I am proposing the following minimally-intrusive solution to
correct this behavior:

  - Change the behavior of "md5sum -c" to ignore "-" file names in order not
to hang
  
The advantage with that solution would be: 

  - Less control logic will be required by script writers to ensure md5sum
doesn't hang when calling "md5sum -c"
  - Removes the denial of service possibility by a malicious user crafting
such a file in anticipiation of "md5sum -c" reading it

System information: 
3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26) x86_64 GNU/Linux

Bug#897073: [lxqt] Qlipper dependency

[Abdullah Ramazanoglu]

Oops, I sent the report prior to trying the version from
https://lxqt.debian.net/ experimental-snapshots. Experimental version seems to
work OK for now. Please allow me to try it out for a few days, to see if it
proves "dependency worthy".

Thank you and regards.
-- 
Abdullah Ramazanoglu

Bug#897072: RFS: btrfs-progs/4.15.1-2~bpo9+1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my continued support of backported
"btrfs-progs".  There was an RC bug against btrfs-progs for some time,
which is why it didn't migrate to testing, and why I was unable to
provide an updated backport.

Hi Gianfranco!

I've CCed you as usual, because you usually take care of sponsoring
this package.  Thank you very much for your continued support :-)

Package name: btrfs-progs
Version : 4.15.1-2~bpo9+1
Upstream Author : linux-bt...@vger.kernel.org
URL : http://btrfs.wiki.kernel.org/
License : GPL-2
Section : admin

It builds these binary packages:

  btrfs-progs - Checksumming Copy on Write Filesystem utilities
  btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb) 
(udeb)
  btrfs-tools - transitional dummy package

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

  https://mentors.debian.net/package/btrfs-progs

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

dget -x 
https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.15.1-2~bpo9+1.dsc


More information about btrfs-progs can be obtained from 
http://btrfs.wiki.kernel.org/

Changes since the last upload:

btrfs-progs (4.15.1-2~bpo9+1) stretch-backports; urgency=medium

  * Rebuild for stretch-backports.

 -- Nicholas D Steeves   Fri, 27 Apr 2018 20:48:43 -0400

btrfs-progs (4.15.1-2) unstable; urgency=medium

  * If libzstd is provided in both deb & udeb variants (such as Ubuntu
bionic) enable zstd support. If libzstd is not provided with both deb
& udeb variants (such as current Debian unstable) disable zstd
support. If and when libzstd is provided in both deb & udeb variants,
a binNMU of this package is sufficient to enable zstd support. Closes:
#886968
  * Drop obsolete lintian overrides.
  * Add alternative email address as uploader.

 -- Dimitri John Ledkov   Sat, 21 Apr 2018 11:59:50 +0100

btrfs-progs (4.15.1-1) unstable; urgency=medium

  * New upstream release

 -- Dimitri John Ledkov   Mon, 19 Feb 2018 15:50:12 +

btrfs-progs (4.14.1-1) unstable; urgency=medium

  * New upstream release.
  * Add libzstd-dev build dependency.

 -- Dimitri John Ledkov   Thu, 11 Jan 2018 15:43:20 +

btrfs-progs (4.13.3-1~bpo9+1) unstable; urgency=medium


Regards,
Nicholas D Steeves

Bug#894371: gdcm FTBFS with openjdk-9

[peter green]

As a workaround to let the poppler transition complete in raspbian I whipped up 
a version of the package that forces openjdk-8.

A debdiff should appear soon at https://debdiffs.raspbian.org/main/g/gdcm/

No intent to NMU in Debian.

Bug#896914: quassel: Implement custom deserializer to add our own sanity checks)

[Scott Kitterman]

I'm running the patched quassel core on Stretch and it is working fine.

Scott K

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

Bug#776798: catfish: never stops searching -- doesn't find anything

[Awtul]

Package: catfish
Version: 1.4.4-1
Followup-For: Bug #776798

Dear Maintainer,

I confirm the bug. 
('catfish' won't stop searching and doesn't find anything.
Also, it's UI won't close, manual termination is required.)
'mlocate' installed.

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

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

Versions of packages catfish depends on:
ii  gir1.2-gdkpixbuf-2.0  2.36.11-2
ii  gir1.2-glib-2.0   1.56.1-1
ii  gir1.2-gtk-3.03.22.30-1
ii  gir1.2-pango-1.0  1.42.1-1
ii  python3   3.6.5-3
ii  python3-gi-cairo  3.28.2-1
ii  python3-pexpect   4.2.1-1

Versions of packages catfish recommends:
ii  mlocate  0.26-2

catfish suggests no packages.

-- no debconf information

Bug#897059: libgphoto2-6: libgphoto2 causes corrupted image file transfers

[Matti Hämäläinen]

Hello,

I tested against the current upstream GIT version 
(91a8425a4fa27def793fa9db2bcb4a71c26c927b)

of libgphoto2, and the problem exists there as well.

If gphoto debug logs are needed, I can provide ones against working 2.5.16 
and non-working, but they are rather large (about 100M uncompressed each, 75M 
both tar+xz'd).


Thanks in advance.

--
] ccr/TNSP ^ pWp  ::  c...@tnsp.org  ::  https://tnsp.org/~ccr/
] https://tnsp.org/hg/ -- https://www.openhub.net/accounts/ccr
] PGP key: 7BED 62DE 898D D1A4 FC4A  F392 B705 E735 307B AAE3

Bug#897071: texmaker does notr start "symbol lookup error" and "undefined symbol: synctex_next_result"

[wzab]

Package: texmaker
Version: 5.0.2-1+b1
Severity: important

Dear Maintainer,

When I try to start texmaker, it does not start. Instead I get the
following:

$ texmaker
texmaker: symbol lookup error: texmaker: undefined symbol:
synctex_next_result

The result is fully reproducible.

With best regards,
Wojtek

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

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

Versions of packages texmaker depends on:
ii  libc6 2.27-3
ii  libgcc1   1:8-20180414-1
ii  libgl11.0.0-2
ii  libqt5concurrent5 5.10.1+dfsg-5
ii  libqt5core5a [qtbase-abi-5-10-0]  5.10.1+dfsg-5
ii  libqt5gui55.10.1+dfsg-5
ii  libqt5network55.10.1+dfsg-5
ii  libqt5printsupport5   5.10.1+dfsg-5
ii  libqt5script5 5.10.1+dfsg-2
ii  libqt5widgets55.10.1+dfsg-5
ii  libqt5xml55.10.1+dfsg-5
ii  libstdc++68-20180414-1
ii  libsynctex1   2018.20180416.47457-1
ii  texmaker-data 5.0.2-1

Versions of packages texmaker recommends:
ii  aspell0.60.7~20110707-4
ii  asymptote 2.44-1
ii  ghostscript   9.22~dfsg-2.1
ii  hunspell-en-us [hunspell-dictionary]  1:2017.08.24
pn  latex-beamer  
ii  myspell-pl [myspell-dictionary]   20170707-1
ii  netpbm2:10.0-15.3+b2
ii  psutils   1.17.dfsg-4
ii  texlive-lang-english  2018.20180416-1
ii  texlive-latex-extra   2018.20180416-1

Versions of packages texmaker suggests:
pn  texlive-lang-all  

-- no debconf information

Bug#897046: RFS: link-grammar/5.4.4-1 [QA upload]

[Sergio Durigan Junior]

[ Adding debian-legal to the Cc list.  ]

On Friday, April 27 2018, Fabian Wolff wrote:

> Dear mentors,
>
> I am looking for a sponsor for a QA upload of the link-grammar
> package.
[...]
> The package is available on Mentors:
>
>   https://mentors.debian.net/package/link-grammar

So, here's the other thing I noticed.  d/copyright doesn't seem to be
up-to-date.  Also, I don't see any mention about the "debian/" directory
on d/copyright, which might be a problem.  I understand the package is
already at this state, but I think it may be a good idea to fix it.

First, I'd recommend re-checking d/copyright and making sure new
copyrights are properly listed.  I've found a few notices mentioning
2017/2018, so it's a good idea to list them.  I understand this is a
very boring task, but it's something we take seriously at Debian.

As for the "debian/" directory, I *think* it should be enough to list
everybody who has ever touched the debian/ directory.  I used the
following one-liner to get a formatted list:

  $ git log --date="format:%Y" --format="Copyright %ad %an <%ae>" debian/ | 
sort -u
  Copyright 2009 Ken Bloom 
  Copyright 2010 Ken Bloom 
  Copyright 2011 Ken Bloom 
  Copyright 2015 Wookey 
  Copyright 2016 Gianfranco Costamagna 
  Copyright 2016 Gianfranco Costamagna 
  Copyright 2016 Jeremy Bicha 
  Copyright 2016 Jeremy Bicha 
  Copyright 2017 Adrian Bunk 
  Copyright 2017 Jeremy Bicha 
  Copyright 2017 Steve Langasek 
  Copyright 2018 Fabian Wolff 

After massaging a bit:

  Copyright 2009-2011 Ken Bloom 
  Copyright 2015 Wookey 
  Copyright 2016 Gianfranco Costamagna 
  Copyright 2016-2017 Jeremy Bicha 
  Copyright 2017 Adrian Bunk 
  Copyright 2017 Steve Langasek 
  Copyright 2018 Fabian Wolff 

So I think it should be enough to put these lines there.  As for the
licence...  Well, I'd choose the same licence as the package, although
if we are to be pedantic here, the right thing would be to get in touch
with everyone above and getting their confirmation.  I don't know...

Anyway, I am copying debian-legal here, hoping that someone more
knowledgeable can shed some light.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#897046: RFS: link-grammar/5.4.4-1 [QA upload]

[Sergio Durigan Junior]

On Friday, April 27 2018, Fabian Wolff wrote:

> I am looking for a sponsor for a QA upload of the link-grammar
> package.
>
> My changes are summarized in the latest changelog entry:
>
>   link-grammar (5.4.4-1) unstable; urgency=medium
>
> * QA upload.
> * New upstream release.
> * Update symbols file.
> * Remove trailing whitespace from debian/changelog in order to
>   silence the file-contains-trailing-whitespace Lintian tag.
> * Upgrade to debhelper compat version 11.
> * Remove the empty file debian/patches/series.
> * Use HTTPS URI in debian/watch.
> * Upgrade to Standards-Version 4.1.4 (no changes).
> * Add debian/python3-link-grammar.lintian-overrides to override the
>   python-package-depends-on-package-from-other-python-variant
>   Lintian tag.
> * Update Vcs-Browser and Vcs-Git fields in debian/control.
> * Update Homepage field in debian/control and Source field in
>   debian/copyright to use HTTPS.
> * Remove incorrect Multi-Arch fields in debian/control.
>
>-- Fabian Wolff   Fri, 27 Apr 2018 15:35:36 +0200

Hey Fabian,

Thanks for taking care of this package.

> I have to admit that I'm not entirely sure about the Multi-Arch fields
> that I removed. The link-grammar binary package installs an
> architecture-dependent binary into /usr/bin, but it was marked
> Multi-Arch: foreign, which looked suspect to me. Also, the
> liblink-grammar-java package seems to have an incorrect Multi-Arch
> field according to the Multiarch hinter:
>
>   https://tracker.debian.org/pkg/link-grammar

Yeah, the link-grammar package shouldn't be "Multi-Arch: foreign"
indeed.  As for the "Multi-Arch: same" issue, I also agree with your
solution; it seems that removing the field is the most sensible approach
here.

> Other than that, I made sure that the autopkgtests pass and that the
> package is mostly Lintian-clean, save for several
> package-has-unnecessary-activation-of-ldconfig-trigger warnings
> (which, according to the Lintian tag documentation, might be due to a
> debhelper bug) and an orig-tarball-missing-upstream-signature warning
> (which I would blame on git-buildpackage, see #872864).

Agreed about both warnings.

I have a few more things to say, but I'll send another e-mail soon.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#895785: RFA: impacket -- Python module to easily build and dissect network protocols

[eamanu15]

Hello Arnaud,

I am interesting to maintain the package.

Regards!
Emmanuel
-- 
Arias Emmanuel
https://www.linkedin.com/in/emmanuel-arias-437a6a8a
http://eamanu.com

Bug#897070: udev: systemd-udevd exits with SIGABRT in __open_nocancel

[Nathaniel Morck Beaver]

Package: udev
Version: 232-25+deb9u3
Severity: normal

Backtraces attached. I do not know how to reliably reproduce.

I cannot install debugging symbols because udeb-dbgsym is only available 
for version 232-25+deb9u2, not stretch-updates version 232-25+deb9u3 
(see policy.txt).


Sincerely,

Nathaniel Beaver

-- Package-specific info:

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8)

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

Versions of packages udev depends on:
ii  adduser  3.115
ii  dpkg 1.18.24
ii  libacl1  2.2.52-3+b1
ii  libblkid12.29.2-1+deb9u1
ii  libc62.24-11+deb9u3
ii  libkmod2 23-2
ii  libselinux1  2.6-3+b3
ii  libudev1 232-25+deb9u3
ii  lsb-base 9.20161125
ii  procps   2:3.3.12-3
ii  util-linux   2.29.2-1+deb9u1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  237-3~bpo9+1

-- debconf information:
  udev/title/upgrade:
  udev/sysfs_deprecated_incompatibility:
  udev/new_kernel_needed: false
  udev/reboot_needed:
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /lib/systemd/systemd-udevd...(no debugging symbols 
found)...done.
[New LWP 14290]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/lib/systemd/systemd-udevd'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7fcedcadf820 in __open_nocancel () at 
../sysdeps/unix/syscall-template.S:84
84  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) info proc
exe = '/lib/systemd/systemd-udevd'
(gdb) info locals
No locals.
(gdb) info args
No symbol table info available.
(gdb) info frame
Stack level 0, frame at 0x7ffc5a162800:
 rip = 0x7fcedcadf820 in __open_nocancel 
(../sysdeps/unix/syscall-template.S:84); saved rip = 0x5612af359e26
 called by frame at 0x7ffc5a162df0
 source language asm.
 Arglist at 0x7ffc5a1627f0, args: 
 Locals at 0x7ffc5a1627f0, Previous frame's sp is 0x7ffc5a162800
 Saved registers:
  rip at 0x7ffc5a1627f8
(gdb) info threads
  Id   Target Id Frame 
* 1Thread 0x7fcedd93d8c0 (LWP 14290) 0x7fcedcadf820 in __open_nocancel 
() at ../sysdeps/unix/syscall-template.S:84
(gdb) thread apply all backtrace full

Thread 1 (Thread 0x7fcedd93d8c0 (LWP 14290)):
#0  0x7fcedcadf820 in __open_nocancel () at 
../sysdeps/unix/syscall-template.S:84
No locals.
#1  0x5612af359e26 in ?? ()
No symbol table info available.
#2  0x5612af372a23 in ?? ()
No symbol table info available.
#3  0x5612af383a47 in ?? ()
No symbol table info available.
#4  0x5612af354439 in ?? ()
No symbol table info available.
#5  0x7fcedc7502e1 in __libc_start_main (main=0x5612af352f00, argc=1, 
argv=0x7ffc5a163468, init=, fini=, 
rtld_fini=, stack_end=0x7ffc5a163458) at ../csu/libc-start.c:291
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -7324092598545396681, 
94638248908224, 140721819890784, 0, 0, -3925323821375927241, 
-3899134251688244169}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 
0x7ffc5a163478, 0x7fcedd9a7170}, data = {prev = 0x0, cleanup = 0x0, canceltype 
= 1511404664}}}
not_first_call = 
#6  0x5612af3555ea in ?? ()
No symbol table info available.
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type 

Bug#892147: Please create the Pragha package with complete audio (api) support

[Gabriel F. T. Gomes]

On 22 Apr 2018, Jürgen Göricke wrote:

>I can also resolve the URL with curl and play it back with the
>gstreamer framework

Ack.  That's valuable information for me.

>but directly in pragha the link extracted with
>curl is not played back. At least the artist's name, the title played
>and the channel in the pragha are resolved as text, but unfortunately
>no music is played.

That's very curious, but at least it means that gstreamer is able to
read something from the parsed URL. :)

>And yes, the volume control in pragha _and_ the
>system is set to full volume.

Hehehe, thanks for checking and for reporting this, too.

>Small additional information, in audacious I can play any online
>streaming link immediately with curl, or similar workarounds without
>any effort. I also got this package from the Debian repository.

OK, thanks for checking.

>It would be nice, though, if pragha could also enable problem-free
>playback of the live streaming sources.

Indeed and I'll probably need a little help from you to try and
reproduce it on my system.

>How else can I help you to find the problem?

Since I want to reproduce the problem on my system, I need to learn how
to make a pulseaudio-free installation, so that I can have a system
similar to yours (my system has the full XFCE stack installed and it
brings pulseaudio by default, I think).

So...  When and if you can spare some time, could you please tell me
what you use on your system?

Did you install with debootstrap, netinst?
Which window manager (so I don't get pulseaudio unintentionally)?
Which audio related packages you installed (gstreamer*, *alsa*)?
Any other packages you believe I should pay attention to?

Please feel free to ignore my request if you don't wish to give that
many details about your computer (I honestly don't know if my request
is intrusive, hehehe).


Cheers,
Gabriel

Bug#897069: shutter: SIGSEGV in strlen ()

[Nathaniel Morck Beaver]

Package: shutter
Version: 0.93.1-1.3
Severity: normal

Segfaults upon exit sometimes. Backtrace is attached.

Sincerely,

Nathaniel Beaver

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8)

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

Versions of packages shutter depends on:
ii  imagemagick8:6.9.7.4+dfsg-11+deb9u4
ii  imagemagick-6.q16 [imagemagick]8:6.9.7.4+dfsg-11+deb9u4
ii  libfile-basedir-perl   0.07-1
ii  libfile-copy-recursive-perl0.38-1
ii  libfile-which-perl 1.21-1
ii  libglib-perl   3:1.324-1
ii  libgnome2-canvas-perl  1.002-4+b1
ii  libgnome2-gconf-perl   1.044-6+b1
ii  libgnome2-perl 1.046-3+b1
ii  libgnome2-vfs-perl 1.082-1+b3
ii  libgnome2-wnck-perl0.16-3+b3
ii  libgtk2-imageview-perl 0.05-2+b3
ii  libgtk2-perl   2:1.2499-1
ii  libgtk2-unique-perl0.05-2+b3
ii  libimage-magick-perl [perlmagick]  8:6.9.7.4+dfsg-11+deb9u4
ii  libjson-perl   2.90-1
ii  libjson-xs-perl3.030-1
ii  liblocale-gettext-perl 1.07-3+b1
ii  libnet-dbus-perl   1.1.0-4+b1
ii  libnet-dropbox-api-perl1.9-1
ii  libpath-class-perl 0.37-1
ii  libproc-processtable-perl  0.53-2
ii  libproc-simple-perl1.32-1
ii  librsvg2-common2.40.16-1+b1
ii  libsort-naturally-perl 1.03-1
ii  libwww-mechanize-perl  1.83-1
ii  libwww-perl6.15-1
ii  libx11-protocol-other-perl 29-2
ii  libx11-protocol-perl   0.56-7
ii  libxml-simple-perl 2.22-1
ii  perlmagick 8:6.9.7.4+dfsg-11+deb9u4
ii  procps 2:3.3.12-3
ii  xdg-utils  1.1.1-1

Versions of packages shutter recommends:
ii  libgoo-canvas-perl 0.06-2+b3
ii  libgtk2-appindicator-perl  0.15-1+b4

Versions of packages shutter suggests:
pn  gnome-web-photo 
ii  libimage-exiftool-perl  10.40-1
pn  libnet-dbus-glib-perl   
ii  nautilus-sendto 3.8.4-2+b1

-- no debconf information
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/perl...Reading symbols from 
/usr/lib/debug//usr/bin/perl...done.
done.

warning: core file may not match specified executable file.
[New LWP 15707]
[New LWP 15727]
[New LWP 15728]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/perl /usr/bin/shutter 
/home/nathaniel/archive/2017/personal/software/b'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
[Current thread is 1 (Thread 0x7fddf07fc2c0 (LWP 15707))]
(gdb) info proc
exe = '/usr/bin/perl /usr/bin/shutter 
/home/nathaniel/archive/2017/personal/software/b'
(gdb) info locals
No locals.
(gdb) info args
No symbol table info available.
(gdb) info frame
Stack level 0, frame at 0x7ffefefe40d0:
 rip = 0x7fddefbf7676 in strlen (../sysdeps/x86_64/strlen.S:106); saved rip = 
0x55ab0822d113
 called by frame at 0x7ffefefe4100
 source language asm.
 Arglist at 0x7ffefefe40c0, args: 
 Locals at 0x7ffefefe40c0, Previous frame's sp is 0x7ffefefe40d0
 Saved registers:
  rip at 0x7ffefefe40c8
(gdb) info threads
  Id   Target Id Frame 
* 1Thread 0x7fddf07fc2c0 (LWP 15707) strlen () at 
../sysdeps/x86_64/strlen.S:106
  2Thread 0x7fddd85d6700 (LWP 15727) 0x7fddefc5667d in poll () at 
../sysdeps/unix/syscall-template.S:84
  3Thread 0x7fddc700 (LWP 15728) 0x7fddefc5667d in poll () at 
../sysdeps/unix/syscall-template.S:84
(gdb) thread apply all backtrace full

Thread 3 (Thread 0x7fddc700 (LWP 15728)):
#0  0x7fddefc5667d in poll 

Bug#677350: please accept the parenthesed syntax subject(section), e.g. man ls(1)

[Paul Wise]

On Wed, 13 Jun 2012 12:32:04 +0100 Colin Watson wrote:

> Is it still worth it if you have to go to the effort of quoting it
> anyway?

Yes, it is much easier to type two quote characters and paste in the
middle of them than to paste then mangle to one of the accepted forms:

man 'ls(1)'
man ''

man ls.1
man .

man 1 ls
man 1 


-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#897068: openjdk-8: Please include patch to fix Zero on ia64

[John Paul Adrian Glaubitz]

Source: openjdk-8
Version: 8u162-b12-1
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Hi!

As promised in #897066, here's a patch to fix the Zero build
on ia64. Just copy it to debian/patches and add it to the
patch list in debian/rules.

I'm bootstrapping openjdk-8 for ia64 now.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- openjdk/hotspot/src/share/vm/runtime/os.cpp 2018-03-19 19:46:40.0 
+0100
+++ openjdk/hotspot/src/share/vm/runtime/os.cpp 2018-04-27 23:22:22.321348018 
+0200
@@ -1038,7 +1038,7 @@
 // if C stack is walkable beyond current frame. The check for fp() is not
 // necessary on Sparc, but it's harmless.
 bool os::is_first_C_frame(frame* fr) {
-#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32)
+#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32) && !defined(LINUX)
   // On IA64 we have to check if the callers bsp is still valid
   // (i.e. within the register stack bounds).
   // Notice: this only works for threads created by the VM and only if

Bug#897067: libserialport FTBFS on Alpha: no BOTHER symbol defined

[Michael Cree]

Source: libserialport
Version: 0.1.1-2
Severity: wishlist
User: debian-al...@lists.debian.org
Usertags: ftbfs
Tags: patch

libserialport FTBFS on Alpha [1] with:

linux_termios.c: In function 'set_termios_speed':
linux_termios.c:90:19: error: 'BOTHER' undeclared (first use in this
function)
  term->c_cflag |= BOTHER;

This is known upstream as bug #363 [2] and is fixed by upstream commit
6c8115820d2eb06ada96a48cdda7dc3467ae90d1 [3]. It does not look like
upstream has made any new formal release, nevertheless is there any
chance of getting an upload to Debian with this commit included?

Cheers,
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=libserialport=alpha=0.1.1-2=1502735836=0
[2] https://sigrok.org/bugzilla/show_bug.cgi?id=363
[3] 
https://sigrok.org/gitweb/?p=libserialport.git;a=commit;h=6c8115820d2eb06ada96a48cdda7dc3467ae90d1

Bug#895224: pdfpc movie playback with gstreamer 1.14.0

[Francesco Poli]

On Fri, 13 Apr 2018 13:58:30 +0100 Barak A. Pearlmutter wrote:

> Just pushed that (as a "Recommends:") per your github issue comment.
> Will upload upon confirmation that this fixes the issue.

Hey, I've just found out about this interesting development for this
bug report (I would have learned before, if I had been in Cc...).

I can confirm that, after a simple

  # aptitude install gstreamer1.0-gtk3

movie playback with pdfpc works again!

This is really great.
Thanks to both Lorenz and Barak!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpZPyPuSkaO6.pgp
Description: PGP signature

Bug#885284: gbirthday: Depends on unmaintained pygtk

[Jérôme]

Le Fri, 12 Jan 2018 11:13:20 +0100,
Rolf Leggewie  a écrit :

> On 11.01.2018 21:49, Jérôme wrote:
> > QBirthday now has a setup.py which makes it easier to install. I
> > hope it also makes it easier to create a .deb from the sources.
> >
> > Rolf (or anyone), would you like to package QBirthday?  
> 
> Jerome, thank you.  That sounds pretty good.  I shall look into it.

Hi Rolf.

Did you get the time to give it a look.

Is there anything I could do upstream to help?

Thanks.

-- 
Jérôme

Bug#883349: Acknowledgement (/etc/msmtprc should not be world readable)

[Simon Deziel]

On Sat, 2 Dec 2017 14:39:00 -0500 Simon Deziel  wrote:
> Please find attached a patch that:
> 
> * Removes world read access to /etc/msmtprc and chgrp to "mail".
> * Installs the msmtp binary as setgid and owned by "root:mail".

Seth Arnold from the Ubuntu security team quickly reviewed my patch and
found a blatant problem. Here's the IRC log

 sarnold: sdeziel: hrm, not sure I love that patch :/ ... normally most
 tools aren't written robustly enough to be setgid
 sarnold: sdeziel: if a user config file asks to log to something
 writable by group mail, what happens?
 ...
 sarnold: a dedicated group would definitely be safer

So when I'll have more time, I'll propose an updated patch that creates
a dedicated group to use with setgid.

Regards,
Simon

Bug#897066: openjdk-8: Please update zero-architectures.diff patch for ia64

[John Paul Adrian Glaubitz]

Source: openjdk-8
Version: 8u162-b12-1
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Hi!

Please replace zero-architectures.diff with the attached, updated
version which contains the autoconf definitions for ia64.

A hotspot-ia64.diff patch which is necessary to fix Hotspot (Zero)
on ia64 will be following shortly.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
# DP: Add support for zero architectures alpha, m68k, mips*, sh4

--- a/common/autoconf/platform.m4
+++ b/common/autoconf/platform.m4
@@ -42,6 +42,12 @@ AC_DEFUN([PLATFORM_EXTRACT_VARS_FROM_CPU
   VAR_CPU_BITS=32
   VAR_CPU_ENDIAN=little
   ;;
+alpha*)
+  VAR_CPU=alpha
+  VAR_CPU_ARCH=alpha
+  VAR_CPU_BITS=64
+  VAR_CPU_ENDIAN=little
+  ;;
 arm*)
   VAR_CPU=arm
   VAR_CPU_ARCH=arm
@@ -60,6 +66,54 @@ AC_DEFUN([PLATFORM_EXTRACT_VARS_FROM_CPU
   VAR_CPU_BITS=64
   VAR_CPU_ENDIAN=little
   ;;
+ia64)
+  VAR_CPU=ia64
+  VAR_CPU_ARCH=ia64
+  VAR_CPU_BITS=64
+  VAR_CPU_ENDIAN=little
+  ;;
+m68k)
+  VAR_CPU=m68k
+  VAR_CPU_ARCH=m68k
+  VAR_CPU_BITS=32
+  VAR_CPU_ENDIAN=big
+  ;;
+mips)
+  VAR_CPU=mips
+  VAR_CPU_ARCH=mips
+  VAR_CPU_BITS=32
+  VAR_CPU_ENDIAN=big
+  ;;
+mipsel)
+  VAR_CPU=mipsel
+  VAR_CPU_ARCH=mipsel
+  VAR_CPU_BITS=32
+  VAR_CPU_ENDIAN=little
+  ;;
+mipsn32)
+  VAR_CPU=mipsn32
+  VAR_CPU_ARCH=mipsn32
+  VAR_CPU_BITS=32
+  VAR_CPU_ENDIAN=big
+  ;;
+mipsn32el)
+  VAR_CPU=mipsn32el
+  VAR_CPU_ARCH=mipsn32el
+  VAR_CPU_BITS=32
+  VAR_CPU_ENDIAN=little
+  ;;
+mips64)
+  VAR_CPU=mips64
+  VAR_CPU_ARCH=mips64
+  VAR_CPU_BITS=64
+  VAR_CPU_ENDIAN=big
+  ;;
+mips64el)
+  VAR_CPU=mips64el
+  VAR_CPU_ARCH=mips64el
+  VAR_CPU_BITS=64
+  VAR_CPU_ENDIAN=little
+  ;;
 powerpc)
   VAR_CPU=ppc
   VAR_CPU_ARCH=ppc
@@ -78,6 +126,12 @@ AC_DEFUN([PLATFORM_EXTRACT_VARS_FROM_CPU
   VAR_CPU_BITS=64
   VAR_CPU_ENDIAN=little
   ;;
+sh*)
+  VAR_CPU=sh
+  VAR_CPU_ARCH=sh
+  VAR_CPU_BITS=32
+  VAR_CPU_ENDIAN=little
+  ;;
 s390)
   VAR_CPU=s390
   VAR_CPU_ARCH=s390
@@ -377,6 +431,12 @@ AC_DEFUN([PLATFORM_SETUP_LEGACY_VARS],
 
   # ZERO_ARCHDEF is used to enable architecture-specific code
   case "${OPENJDK_TARGET_CPU}" in
+alpha*)  ZERO_ARCHDEF=ALPHA ;;
+ia64)  ZERO_ARCHDEF=IA64 ;;
+m68k)  ZERO_ARCHDEF=M68K ;;
+mips|mipsn32|mips64)  ZERO_ARCHDEF=MIPS ;;
+mipsel|mipsn32el|mips64el)  ZERO_ARCHDEF=MIPSEL ;;
+sh*)   ZERO_ARCHDEF=ZERO_SH  ;;
 ppc) ZERO_ARCHDEF=PPC32 ;;
 ppc64)   ZERO_ARCHDEF=PPC64 ;;
 s390*)   ZERO_ARCHDEF=S390  ;;
--- a/common/autoconf/toolchain.m4
+++ b/common/autoconf/toolchain.m4
@@ -1354,6 +1354,8 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_COMPILER_
 *)
   ZERO_ARCHFLAG="${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}"
   esac
+  # use the default for the package builds
+  ZERO_ARCHFLAG=""
   TOOLCHAIN_COMPILER_CHECK_ARGUMENTS([$ZERO_ARCHFLAG], [], [ZERO_ARCHFLAG=""])
   AC_SUBST(ZERO_ARCHFLAG)
 

Bug#890878: RFS: company-irony

[Nicholas D Steeves]

Oops, that last link was supposed to be
https://github.com/Sarcasm/irony-mode/issues/172


signature.asc
Description: PGP signature

Bug#890878: RFS: company-irony

[Nicholas D Steeves]

Hi Alberto,

On Wed, Mar 14, 2018 at 12:39:44PM -0400, Nicholas D Steeves wrote:
> Hi Alberto,
> 
> On Wed, Mar 14, 2018 at 09:34:07AM +0100, Alberto Luaces wrote:
>
> > > Because for now the most pressing issue is that it doesn't initialise
> > > properly...
> > >
> > >   Company backend 'company-clang' could not be initialized:
> > >   Company found no clang executable
> > >
> > > This was both with no configuration (and M-x company-mode), and with
> > > following upstream's README in a clean sid chroot.  I opened a random
> > > cpp from kdeconnect to test.  I suspect a documentation of
> > > configuration issue because I would have expected company-irony to
> > > load rather than company-clang...but it's possibly a bug.
> > >
> > > Please let me know how you made company-irony work.
> > 
> > Oh, yes, I think this is expected.  From the documentation at
> > 
> > /usr/share/doc/elpa-company-irony/README.md
> > 
> > --8<---cut here---start->8---
> > 
> > ## Configuration
> > 
> > Add `company-irony` to your company backends.
> > 
> > ~~~el
> > (eval-after-load 'company
> >   '(add-to-list 'company-backends 'company-irony))
> > ~~~
> > 
> > --8<---cut here---end--->8---
> 
> This is exactly one of the two things that I tried.  To be fair,
> company-irony's autocomplete seems to function properly despite this
> :-)
> 
> Could you patch README.md to show how to remove company-clang from
> company-backends, and also document that this warning is harmless (if
> it's harmless).

Any progress on this?

In pseudo code:

eval company-backends to check if company-clang is an element
  if non nil (eg: if the company-clang element exists)
remove company-clang from company-backends
(add-to-list 'company-backends 'company-irony)

Justification: company-clang and company-irony should not be used at
the same time, and company-irony replaces company-clang.

Also, here are some resources for patching the upstream description
and for improving the Debian description:

https://www.reddit.com/r/emacs/comments/26cxgl/fastest_c_completion_system/
https://github.com/Sarcasm/company-irony/issues/33
https://github.com/Sarcasm/company-irony/issues/33

Happy hacking,
Nicholas


signature.asc
Description: PGP signature

Bug#896979: xserver-xorg-video-nouveau: Crash when undocking Lenovo P50

[Sam Morris]

On Thu, 2018-04-26 at 18:45 +0200, Sven Joachim wrote:
> On 2018-04-26 14:13 +, Sam Morris wrote:
> 
> > Followup-For: Bug #896979
> > Control: tag -1 + patch
> > 
> > This patch (taken from
> > )
> > fixes
> > the problem for me.
> > 
> > (Note, I modified the patch to end the log message with a newline
> > character).
> > 
> > From 5533658dd1afa31557d4ec4b469181f1d592d8c8 Mon Sep 17
> > 00:00:00 2001
> > From: Ben Skeggs 
> > Date: Sat, 20 May 2017 00:29:27 +1000
> > Subject: [PATCH] remove support for maxwell and higher
> 
> I don't think this is a good idea, unless upstream agrees to it.  I
> would rather have us patch the xorg-server package to not use the
> nouveau driver by default on such cards, as we do for Intel GPUs.
> 
> For the record, Fedora currently uses the modesetting driver on all
> cards from GeForce 8 onwards[1].
> 
> Cheers,
>Sven
> 
> 
> 1. https://src.fedoraproject.org/rpms/xorg-x11-server/blob/master/f/0
> 001-xfree86-use-modesetting-driver-by-default-on-GeForce.patch

Either solution sounds good to me! =D

-- 
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9


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

Bug#897065: make: please use implicit rules for phony targets

[Uwe Kleine-König]

Package: make
Version: 4.1-9.1
Severity: wishlist

Hello,

I have a Makefile that works with a set of files and can run various
checks over them. A simplified variant looks as follows:

user@hostname:~/maketest$ cat Makefile 
all: check-debian check-ubuntu

check-%: list-%
@echo test for $< succeeded

.PHONY: all check-debian

With this Makefile (and the needed list files for debian and ubuntu:

user@hostname:~/maketest$ ls
list-debian  list-ubuntu  Makefile

) running make skips over check-debian's commands:

user@hostname:~/maketest$ make -r
test for list-ubuntu succeeded

When adding -d I get:

...
  Must remake target 'check-debian'.
  Successfully remade target file 'check-debian'.
...
  Must remake target 'check-ubuntu'.
Putting child 0x559b3ec13e70 (check-ubuntu) PID 32112 on the chain.
Live child 0x559b3ec13e70 (check-ubuntu) PID 32112 
test for list-ubuntu succeeded
Reaping winning child 0x559b3ec13e70 PID 32112 
Removing child 0x559b3ec13e70 PID 32112 from chain.
  Successfully remade target file 'check-ubuntu'.
...

This matches the documentation, which has:

The implicit rule search (see Implicit Rules) is skipped for
.PHONY targets.

I discussed this on irc and someone found an older GNU Make Manual
stating:

Since it knows that phony targets do not name actual files that
could be remade from other files, make skips the implicit rule
search for phony targets.

IMHO this reasoning is wrong as in my case implicit rules for phony
targets would be useful even though "check-debian" isn't the name of an
actual file.

My workaround for the Makefile is to not list the check-% targets in
.PHONY, but actually they are phony and I'd like to make use of the
advantages of declaring them as such.

Best regards
Uwe

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

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

Versions of packages make depends on:
ii  libc6  2.27-3

make recommends no packages.

Versions of packages make suggests:
ii  make-doc  4.2.1-1

-- no debconf information

Bug#897064: Please demote Recomends: minissdpd

[Michael Biebl]

Package: libminiupnpc16
Version: 2.0.20180222-1
Severity: wishlist

Hi,

libminiupnpc16 recommends minissdpd. That means, every applications that
links against libminiupnpc16 will pull in minissdpd.
In my specific case I noticed it because of transmission-gtk.

In a binary distribution like Debian, it's common to enable as many
features as feasible, which in most cases means, linking against a
specific library.
It should should be up to the actual application though, in this case
transmission-gtk, to add a recommends or depends on a specific daemon
like minissdpd, as only the application maintainer itself knows, if the
functionality provided by the library/daemon is important to the
application itself. It shouldn't be up to the library to pull in such
helper daemons.

Therefore, please consider dropping the Recommends on minissdpd or
lowering it to Suggests.

Regards,
Michael




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

Kernel: Linux 4.15.0-3-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 libminiupnpc16 depends on:
ii  libc6  2.27-3

Versions of packages libminiupnpc16 recommends:
pn  minissdpd  

libminiupnpc16 suggests no packages.

-- no debconf information

Bug#896950: libgtk[ada|gnatcoll]: autopkgtest depends on libfribidi-dev but doesn't declare that

[Nicolas Boulenguez]

Hi.

I am quite sure that neither libgtkada nor libgnacoll directly depends
on libfribidi.

As far as I understand,
* pango depends on fribidi and this dependency was not reflected for
  -dev packages. Some dependency was previously hiding the problem by
  installing libfribidi-dev for other reasons.
  (Investigating which dependency would not bring much).
* Someone noticed this
  (probably because the dependency does not install fribidi anymore).
  The gtkada tests currently fail in the testing distribution
  because of this bug in libpango-dev.
* This bug has been fixed in unstable two weeks ago by making
  libpango-dev depend on libfribidi-dev.

If this is correct, I suggest that we close both 896950 and 896951.

Bug#896977: starlink-votable-java: new version misses versioned depends on packages from starjava-fits

[Ole Streicher]

Hi Paul,

On 27.04.2018 22:25, Paul Gevers wrote:
> I wonder if you missed this piece of my comment (do you want a new bug
> for this?):
> 
> On 26-04-18 17:54, Paul Gevers wrote:
>> but
>> probably also that starlink-votable-java needs a versioned breaks on
>> starlink-table-java, as for starjava-table, also starjava-table packages
>> need to be upgraded for the test to pass.
> 
> starjava-table fails¹ (as expected) with the updated package (second try
> for trigger starjava-votable/2.0+2018.04.17-2).

I didn't miss this. As I wrote in my last comment: starlink-votable-java
works nicely with the old starlink-table-java. It is just the tests that
need to be updated, but for a user both packages play together well. In
fact, the problem is *not* starlink-votable-java in this case, but it is
a bug in starlink-table-java. It is already buggy, the bug just does not
show up in the CI test with the old version of starlink-votable-java.
And an update (for starlink-table-java) is already uploaded.

IMO this is a problems with the CI tests: it is great to have the tests,
and to see where we have incompatibilities. However often the problems
shown are minor, and so for migration I would like to have a "that is
OK" button there, which overrides a migration veto.

Usually we allow packages to migrate when there is no "serious" bug, but
many test failures would normally indicate only "normal" or "important"
bugs, and should therefore (at least as an option) not hinder migration.
Restricting the tests to RC stuff is also not a good solution here,
since then I would lose a big utility for my QC. And usually I can't
weight the importance for individual CI tests beforehand myself: they
are written by upstream, and sometimes (astropy) they are so many
(~10.000) that I have no chance to sort them. I usually check the result
when I see a failure, and often need to contact upstream to estimate the
severity of a failure.

So: Not all CI test failures show a "serious" (RC) problem with the
upgraded package. In many cases the problem is minor, and the migration
logic should take this into account.

Best regards

Ole

Bug#896977: starlink-votable-java: new version misses versioned depends on packages from starjava-fits

[Paul Gevers]

Hi Ole,

I wonder if you missed this piece of my comment (do you want a new bug
for this?):

On 26-04-18 17:54, Paul Gevers wrote:
> but
> probably also that starlink-votable-java needs a versioned breaks on
> starlink-table-java, as for starjava-table, also starjava-table packages
> need to be upgraded for the test to pass.

starjava-table fails¹ (as expected) with the updated package (second try
for trigger starjava-votable/2.0+2018.04.17-2).

Paul

¹ https://ci.debian.net/packages/s/starjava-table/testing/amd64/

run-tests:
[junit] Testsuite: uk.ac.starlink.table.BeanTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
elapsed: 0.123 sec
[junit]
[junit] Testsuite: uk.ac.starlink.table.ConcatTableTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time
elapsed: 0.141 sec
[junit]
[junit] Testsuite: uk.ac.starlink.table.ConstantTableTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
elapsed: 0.023 sec
[junit]
[junit] Testsuite: uk.ac.starlink.table.DomainTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
elapsed: 0.025 sec
[junit]
[junit] Testsuite: uk.ac.starlink.table.FormatsTest
[junit] Tests run: 11, Failures: 0, Errors: 4, Skipped: 0, Time
elapsed: 7.755 sec
[junit]
[junit] - Standard Error -
[junit] Apr 27, 2018 6:16:39 AM
uk.ac.starlink.fits.AbstractWideFits$HierarchWideFits checkHasHierarch
[junit] SEVERE: FitsFactory.useHierarch=false: HIERARCH-based wide
FITS table convention write will fail!
[junit] Apr 27, 2018 6:16:42 AM
uk.ac.starlink.fits.AbstractWideFits$HierarchWideFits checkHasHierarch
[junit] SEVERE: FitsFactory.useHierarch=false: HIERARCH-based wide
FITS table convention write will fail!
[junit] Apr 27, 2018 6:16:43 AM
uk.ac.starlink.fits.AbstractWideFits$HierarchWideFits checkHasHierarch
[junit] SEVERE: FitsFactory.useHierarch=false: HIERARCH-based wide
FITS table convention write will fail!
[junit] Apr 27, 2018 6:16:46 AM
uk.ac.starlink.fits.AbstractWideFits$HierarchWideFits checkHasHierarch
[junit] SEVERE: FitsFactory.useHierarch=false: HIERARCH-based wide
FITS table convention write will fail!
[junit] -  ---
[junit] Testcase: testVarFits(uk.ac.starlink.table.FormatsTest):
Caused an ERROR
[junit] Keyword too long
[junit] java.io.IOException: Keyword too long
[junit] at
uk.ac.starlink.fits.AbstractFitsTableWriter.writeTableHDU(AbstractFitsTableWriter.java:153)
[junit] at
uk.ac.starlink.fits.AbstractFitsTableWriter.writeStarTables(AbstractFitsTableWriter.java:104)
[junit] at
uk.ac.starlink.fits.AbstractFitsTableWriter.writeStarTable(AbstractFitsTableWriter.java:89)
[junit] at
uk.ac.starlink.table.StreamStarTableWriter.writeStarTable(StreamStarTableWriter.java:33)
[junit] at
uk.ac.starlink.table.FormatsTest.exerciseVarFits(FormatsTest.java:416)
[junit] at
uk.ac.starlink.table.FormatsTest.testVarFits(FormatsTest.java:406)
[junit] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] at
jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[junit] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] Caused by: nom.tam.fits.HeaderCardException: Keyword too long
[junit] at nom.tam.fits.HeaderCard.(HeaderCard.java:621)
[junit] at nom.tam.fits.HeaderCard.(HeaderCard.java:580)
[junit] at nom.tam.fits.Header.addValue(Header.java:417)
[junit] at
uk.ac.starlink.fits.FitsConstants.addTrimmedValue(FitsConstants.java:433)
[junit] at
uk.ac.starlink.fits.StandardFitsTableSerializer.addHeader(StandardFitsTableSerializer.java:411)
[junit] at
uk.ac.starlink.fits.StandardFitsTableSerializer.getHeader(StandardFitsTableSerializer.java:384)
[junit] at
uk.ac.starlink.fits.VariableFitsTableSerializer.getHeader(VariableFitsTableSerializer.java:75)
[junit] at
uk.ac.starlink.fits.AbstractFitsTableWriter.writeTableHDU(AbstractFitsTableWriter.java:148)
[junit]
[junit]
[junit] Testcase: testReadWrite(uk.ac.starlink.table.FormatsTest):
Caused an ERROR
[junit] Keyword too long
[junit] java.io.IOException: Keyword too long
[junit] at
uk.ac.starlink.fits.AbstractFitsTableWriter.writeTableHDU(AbstractFitsTableWriter.java:153)
[junit] at
uk.ac.starlink.fits.AbstractFitsTableWriter.writeStarTables(AbstractFitsTableWriter.java:104)
[junit] at
uk.ac.starlink.fits.AbstractFitsTableWriter.writeStarTable(AbstractFitsTableWriter.java:89)
[junit] at

Bug#886394: java.lang.ClassNotFoundException: javafx.scene.layout.HBox

[Tuxicoman]

Package: pdfsam
Version: 3.3.5-1
Followup-For: Bug #886394

Dear Maintainer,

I can reproduce the issue using Debian testing.

If I have openjdk-8-jre installed it works.
If I have openjdk-8-jre and openjdk-9-jre installed it doesn't work.
If I have openjdk-8-jre and openjdk-10-jre installed it doesn't work.



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

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

Versions of packages pdfsam depends on:
ii  libatinject-jsr330-api-java 1.0+ds1-5
ii  libbcmail-java  1.59-1
ii  libbcprov-java  1.59-1
ii  libcommons-io-java  2.6-2
ii  libcommons-lang3-java   3.5-2
ii  libfontawesomefx-java   8.9-1
ii  libgettext-commons-java 0.9.6-6
ii  libhibernate-validator-java 4.3.3-4
ii  libjackson2-jr-java 2.9.4-1
ii  liblogback-java 1:1.2.3-2
ii  libsambox-java  1.1.19-1
ii  libsejda-eventstudio-java   1.0.6-1
ii  libsejda-injector-java  1.0.2-1
ii  libsejda-java   3.2.38-1
ii  libslf4j-java   1.7.25-3
ii  openjdk-10-jre [java8-runtime]  10.0.1+10-3
ii  openjdk-8-jre [java8-runtime]   8u162-b12-1
ii  openjfx 8u141-b14-3

pdfsam recommends no packages.

pdfsam suggests no packages.

-- no debconf information

Bug#897059: [Pkg-phototools-devel] Bug#897059: libgphoto2-6: libgphoto2 causes corrupted image file transfers

[Herbert Fortes]

severity 897059 serious
thanks

I will read this tomorrow



Regards,
Herbert

Em 27-04-2018 16:23, Matti Hamalainen escreveu:
> Package: libgphoto2-6
> Version: 2.5.17
> Severity: normal
> 
> Dear Maintainer,
> 
> After upgrading libgphoto2 to latest packaged version 2.5.17, I immediately
> noticed that the CR2 RAW files fetched via "gphoto2 -P" were unreadable by
> Darktable, Adobe Lightroom and other RAW image software. My cameras are Canon
> EOS 7D Mark II and Canon EOS 500D, connected via USB. The problem occurs with
> both cameras.
> 
> I quickly noticed that repeated transfers resulted in files with different
> SHA256 sums. Downgrading to libgphoto2 to previous 2.5.16 makes the problem go
> away, checksums are always consistent. With 2.5.17, each file had different
> checksum for each transfer, pointing to serious corruption.
> 
> I should state that this is a VERY SERIOUS ISSUE! Usually when I transfer
> photos from camera, I also immediately delete them from the camera's memory
> card. Fortunately I noticed the problem with only few pictures taken, so I
> personally suffered almost no loss... but it could have been much worse!
> 
> I have no idea if this affects only Canon cameras, as the changelog for 2.5.17
> states various EOS -related changes, but I think notifying upstream would be
> appropriate.
> 
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.16.5-qcmm (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> 
> ___
> Pkg-phototools-devel mailing list
> pkg-phototools-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-phototools-devel
> 

Bug#897063: Doesn't detect permanent MAC on 802.1q VLAN interfaces

[Andras Korn]

Package: macchanger
Version: 1.7.0-5.3+b1
Severity: normal
Tags: upstream

Hi,

# ip link add link eth0 name test type vlan id 42

# macchanger -r test
Current MAC:   54:ee:75:49:b1:ae (Wistron InfoComm(Kunshan)Co.,Ltd.)
Permanent MAC: 00:00:00:00:00:00 (XEROX CORPORATION)
New MAC:   ee:a1:b2:41:01:d6 (unknown)

# macchanger -p test
Current MAC:   ee:a1:b2:41:01:d6 (unknown)
Permanent MAC: 00:00:00:00:00:00 (XEROX CORPORATION)
[ERROR] Could not change MAC: interface up or insufficient permissions: Cannot 
assign requested address

I think this should work; macchanger should detect that it's dealing with a
VLAN interface, get the permanent MAC from the parent interface, and use
that when -p is given.

András

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

Kernel: Linux 4.1.48-vs2.3.8.5.3+zfs20171219-caeeng (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages macchanger depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  dpkg   1.19.0.5
ii  install-info   6.5.0.dfsg.1-2
ii  libc6  2.27-3

macchanger recommends no packages.

macchanger suggests no packages.

-- 
A picture is worth a thousand words, but it uses ten thousand times the memory.

Bug#896935: thunderbird: Do not honour offline mode

[Carsten Schoenert]

Please use Reply All, otherwise it's not tracked into the bugtracker.

On 4/26/18 5:32 PM, Ilari Halminen wrote:
> And I get it back even if I still have offline mode enabled.
> 
> Ilari H
> 
> Ilari Halminen kirjoitti 26.04.2018 klo 18:30:
>> I check it by for example
>>
>> by first going to offline mode and then sending this  reply to you and 
>> my another alias. If I get reply back, as it should, then I am still 
>> in online. I do it now.

I can't reproduce this on my side, I always get not button 'Send' and
instead a 'Send Later' that is quite logical in may eyes.

Please retry with a new clear profiles, such issues are mostly related
to some entries in the profiles which causes such issues.

-- 
Regards
Carsten

Bug#897062: android-platform-external-libunwind FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: android-platform-external-libunwind
Version: 7.0.0+r1-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

android-platform-external-libunwind fails to cross build from source,
because it uses the build architecture compiler. Using dh_auto_build
fixes that. Please consider applying the attached patch.

Helmut
diff --minimal -Nru 
android-platform-external-libunwind-7.0.0+r1/debian/changelog 
android-platform-external-libunwind-7.0.0+r1/debian/changelog
--- android-platform-external-libunwind-7.0.0+r1/debian/changelog   
2016-12-26 00:09:38.0 +0100
+++ android-platform-external-libunwind-7.0.0+r1/debian/changelog   
2018-04-27 19:47:51.0 +0200
@@ -1,3 +1,10 @@
+android-platform-external-libunwind (7.0.0+r1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use dh_auto_build. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 27 Apr 2018 19:47:51 +0200
+
 android-platform-external-libunwind (7.0.0+r1-4) unstable; urgency=medium
  
   [ Hans-Christoph Steiner]
diff --minimal -Nru android-platform-external-libunwind-7.0.0+r1/debian/rules 
android-platform-external-libunwind-7.0.0+r1/debian/rules
--- android-platform-external-libunwind-7.0.0+r1/debian/rules   2016-12-26 
00:03:56.0 +0100
+++ android-platform-external-libunwind-7.0.0+r1/debian/rules   2018-04-27 
19:47:49.0 +0200
@@ -8,7 +8,7 @@
dh $@ --without autoreconf
 
 override_dh_auto_build:
-   make -f debian/libunwind.mk
+   dh_auto_build -Smakefile -- -f debian/libunwind.mk
 
 override_dh_auto_clean:
make clean -f debian/libunwind.mk

Bug#897061: libuv1: FTBFS on hurd-i386: PATH_MAX undefined (and kfreebsd as well)

[Samuel Thibault]

Package: libuv1
Version: 1.18.0-3
Severity: important
Tags: patch

Hello,

libuv1 currently FTBFS on hurd-i386 because it unconditionally uses
PATH_MAX. The attached patch fixes this.

Also, the symbols file is only accurate for the Linux port, here is a
fix for that too.  Some symbols are really Linux-only in the source
code, they pose problem on kfreebsd as seen in buildd logs, so the patch
should fix the build there too.

Samuel

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

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

Versions of packages libuv1 depends on:
ii  libc6  2.27-3

libuv1 recommends no packages.

libuv1 suggests no packages.

-- no debconf information

-- 
Samuel
 bah à défaut de ligne TGV, ils ont un GR
 -+- #ens-mim - comment ça, paumé ?! -+-
Index: libuv1-1.18.0/src/unix/fs.c
===
--- libuv1-1.18.0.orig/src/unix/fs.c
+++ libuv1-1.18.0/src/unix/fs.c
@@ -436,8 +436,14 @@ static ssize_t uv__fs_pathmax_size(const
 static ssize_t uv__fs_readlink(uv_fs_t* req) {
   ssize_t len;
   char* buf;
+  struct stat st;
+  int ret;
 
-  len = uv__fs_pathmax_size(req->path);
+  ret = lstat(req->path, );
+  if (ret != 0) {
+return -1;
+  }
+  len = st.st_size;
   buf = uv__malloc(len + 1);
 
   if (buf == NULL) {
@@ -451,7 +457,6 @@ static ssize_t uv__fs_readlink(uv_fs_t*
   len = readlink(req->path, buf, len);
 #endif
 
-
   if (len == -1) {
 uv__free(buf);
 return -1;
@@ -464,9 +469,16 @@ static ssize_t uv__fs_readlink(uv_fs_t*
 }
 
 static ssize_t uv__fs_realpath(uv_fs_t* req) {
-  ssize_t len;
   char* buf;
 
+#if _POSIX_VERSION >= 200809L
+  buf = realpath(req->path, NULL);
+  if (buf == NULL) {
+return -1;
+  }
+#else
+  ssize_t len;
+
   len = uv__fs_pathmax_size(req->path);
   buf = uv__malloc(len + 1);
 
@@ -479,6 +491,7 @@ static ssize_t uv__fs_realpath(uv_fs_t*
 uv__free(buf);
 return -1;
   }
+#endif
 
   req->ptr = buf;
 
--- debian/libuv1.symbols.orig  2018-04-27 19:23:52.0 +
+++ debian/libuv1.symbols   2018-04-27 19:37:32.0 +
@@ -1,5 +1,5 @@
 libuv.so.1 libuv1 #MINVER#
- uv__accept4@Base 1.11.0
+ (arch=linux-any)uv__accept4@Base 1.11.0
  uv__accept@Base 1.11.0
  uv__async_close@Base 1.11.0
  uv__async_fork@Base 1.18.0
@@ -12,37 +12,37 @@
  uv__close_nocheckstdio@Base 1.11.0
  uv__count_bufs@Base 1.11.0
  uv__dup2_cloexec@Base 1.11.0
- uv__dup3@Base 1.11.0
+ (arch=linux-any)uv__dup3@Base 1.11.0
  uv__dup@Base 1.11.0
- uv__epoll_create1@Base 1.11.0
- uv__epoll_create@Base 1.11.0
- uv__epoll_ctl@Base 1.11.0
- uv__epoll_pwait@Base 1.11.0
- uv__epoll_wait@Base 1.11.0
- uv__eventfd2@Base 1.11.0
- uv__eventfd@Base 1.11.0
+ (arch=linux-any)uv__epoll_create1@Base 1.11.0
+ (arch=linux-any)uv__epoll_create@Base 1.11.0
+ (arch=linux-any)uv__epoll_ctl@Base 1.11.0
+ (arch=linux-any)uv__epoll_pwait@Base 1.11.0
+ (arch=linux-any)uv__epoll_wait@Base 1.11.0
+ (arch=linux-any)uv__eventfd2@Base 1.11.0
+ (arch=linux-any)uv__eventfd@Base 1.11.0
  uv__free@Base 1.11.0
- uv__fs_event_close@Base 1.11.0
+ (arch=!hurd-any)uv__fs_event_close@Base 1.11.0
  uv__fs_poll_close@Base 1.11.0
  uv__fs_scandir_cleanup@Base 1.11.0
  uv__getaddrinfo_translate_error@Base 1.11.0
  uv__getiovmax@Base 1.11.0
  uv__getpwuid_r@Base 1.11.0
  uv__handle_type@Base 1.11.0
- uv__hrtime@Base 1.11.0
+ (arch=!hurd-any)uv__hrtime@Base 1.11.0
  uv__idle_close@Base 1.11.0
- uv__inotify_add_watch@Base 1.11.0
- uv__inotify_fork@Base 1.18.0
- uv__inotify_init1@Base 1.11.0
- uv__inotify_init@Base 1.11.0
- uv__inotify_rm_watch@Base 1.11.0
+ (arch=linux-any)uv__inotify_add_watch@Base 1.11.0
+ (arch=linux-any)uv__inotify_fork@Base 1.18.0
+ (arch=linux-any)uv__inotify_init1@Base 1.11.0
+ (arch=linux-any)uv__inotify_init@Base 1.11.0
+ (arch=linux-any)uv__inotify_rm_watch@Base 1.11.0
  uv__io_active@Base 1.11.0
- uv__io_check_fd@Base 1.11.0
+ (arch=!hurd-any)uv__io_check_fd@Base 1.11.0
  uv__io_close@Base 1.11.0
  uv__io_feed@Base 1.11.0
- uv__io_fork@Base 1.18.0
+ (arch=!hurd-any)uv__io_fork@Base 1.18.0
  uv__io_init@Base 1.11.0
- uv__io_poll@Base 1.11.0
+ (arch=!hurd-any)uv__io_poll@Base 1.11.0
  uv__io_start@Base 1.11.0
  uv__io_stop@Base 1.11.0
  uv__loop_close@Base 1.11.0
@@ -56,26 +56,26 @@
  uv__nonblock_ioctl@Base 1.11.0
  uv__open_cloexec@Base 1.11.0
  uv__open_file@Base 1.11.0
- uv__pipe2@Base 1.11.0
+ (arch=linux-any)uv__pipe2@Base 1.11.0
  uv__pipe_close@Base 1.11.0
- 

Bug#873033: ITP: opengcs -- Guest Compute Service for Linux Hyper-V Container

[Balint Reczey]

Hi,

On Wed, Aug 23, 2017 at 10:37 PM, Balint Reczey
 wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Balint Reczey 
>
> * Package name: opengcs
>   Version : 0.3.1+git20170816.24.3193f23-1
>   Upstream Author : Microsoft
> * URL : https://github.com/Microsoft/opengcs
> * License : MIT
>   Programming Lang: Go
>   Description : Guest Compute Service for Linux Hyper-V Container
>
>  Open Guest Compute Service is a Linux-based open source project to
>  further the development of a production quality implementation of
>  Linux Hyper-V container on Microsoft Windows (LCOW).
>  It's designed to run inside a custom Linux OS for supporting Linux
>  container payload.

Opengcs can be used in a very specific environment and I think it may
not be particularly useful to have it packaged and maintained in
Debian, while it would require effort to keep it updated. Considering
that instead of converting the bug to RFP I'm just closing it, feel
free to reopen the bug as an RFP or ITP if feel so.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#897060: linux-image-4.15.0-3-amd64: System does not boot after upgrading to buster

[Joris]

Package: src:linux
Version: 4.15.17-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

I upgraded to buster from stretch according to the wiki. I did abort the
configuration of minissdp by pressing Esc, when I was asked for the interface
IP. Upon reboot the screen stays black and I cannot use ctrl+alt+f[1-6] after I
decrypt my hard drive.

When booting in recovery mode from GRUB the system successfully boots (most of
the time).

The journal shows:
kernel: BUG: unable to handle kernel NULL pointer dereference at

kernel: IP:   (null)


Here is the log from the previous boot:
Apr 27 20:02:54 gumbox kernel: iTCO_wdt: initialized. heartbeat=30 sec
(nowayout=0)
Apr 27 20:02:54 gumbox systemd[1]: Starting Load/Save RF Kill Switch Status...
Apr 27 20:02:54 gumbox kernel: Adding 1990652k swap on /dev/mapper/gumbox--vg-
swap_1.  Priority:-2 extents:1 across:1990652k SSFS
Apr 27 20:02:54 gumbox kernel: iTCO_wdt: initialized. heartbeat=30 sec
(nowayout=0)
Apr 27 20:02:54 gumbox systemd[1]: Starting Load/Save RF Kill Switch Status...
Apr 27 20:02:54 gumbox kernel: i915 :00:02.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=io+mem:owns=io+mem
Apr 27 20:02:54 gumbox kernel: intel_powerclamp: No package C-state available
Apr 27 20:02:54 gumbox kernel: iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUG
disabled
Apr 27 20:02:54 gumbox kernel: iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUGFS
disabled
Apr 27 20:02:54 gumbox kernel: iwlwifi :03:00.0:
CONFIG_IWLWIFI_DEVICE_TRACING disabled
Apr 27 20:02:54 gumbox kernel: iwlwifi :03:00.0: Detected Intel(R) Ultimate
N WiFi Link 5300 AGN, REV=0x24
Apr 27 20:02:54 gumbox systemd[1]: Found device /dev/mapper/gumbox--vg-swap_1.
Apr 27 20:02:54 gumbox kernel: uvcvideo 1-6:1.0: Entity type for entity Camera
1 was not initialized!
Apr 27 20:02:54 gumbox kernel: uvcvideo 1-6:1.0: Entity type for entity Camera
1 was not initialized!
Apr 27 20:02:54 gumbox kernel: input: UVC Camera (17ef:480c): Integra as
/devices/pci:00/:00:1a.7/usb1/1-6/1-6:1.0/input/input13
Apr 27 20:02:54 gumbox kernel: usbcore: registered new interface driver
uvcvideo
Apr 27 20:02:54 gumbox kernel: USB Video Class driver (1.1.1)
Apr 27 20:02:54 gumbox kernel: [drm] Supports vblank timestamp caching Rev 2
(21.10.2013).
Apr 27 20:02:54 gumbox kernel: [drm] Driver supports precise vblank timestamp
query.
Apr 27 20:02:54 gumbox systemd-udevd[367]: link_config: autonegotiation is
unset or enabled, the speed and duplex are not writable.
Apr 27 20:02:54 gumbox kernel: i915 :00:02.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=io+mem:owns=io+mem
Apr 27 20:02:54 gumbox kernel: intel_powerclamp: No package C-state available
Apr 27 20:02:54 gumbox kernel: iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUG
disabled
Apr 27 20:02:54 gumbox kernel: iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUGFS
disabled
Apr 27 20:02:54 gumbox kernel: iwlwifi :03:00.0:
CONFIG_IWLWIFI_DEVICE_TRACING disabled
Apr 27 20:02:54 gumbox kernel: iwlwifi :03:00.0: Detected Intel(R) Ultimate
N WiFi Link 5300 AGN, REV=0x24
Apr 27 20:02:54 gumbox systemd[1]: Found device /dev/mapper/gumbox--vg-swap_1.
Apr 27 20:02:54 gumbox systemd[1]: Activating swap /dev/mapper/gumbox--vg-
swap_1...
Apr 27 20:02:54 gumbox systemd[1]: Created slice system-lvm2\x2dpvscan.slice.
Apr 27 20:02:54 gumbox systemd[1]: Starting LVM2 PV scan on device 254:0...
Apr 27 20:02:54 gumbox systemd[1]: Listening on Load/Save RF Kill Switch Status
/dev/rfkill Watch.
Apr 27 20:02:54 gumbox kernel: iTCO_vendor_support: vendor-support=0
Apr 27 20:02:54 gumbox kernel: iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
Apr 27 20:02:54 gumbox kernel: iTCO_wdt: Found a ICH9M-E TCO device (Version=2,
TCOBASE=0x1060)
Apr 27 20:02:54 gumbox kernel: iTCO_wdt: initialized. heartbeat=30 sec
(nowayout=0)
Apr 27 20:02:54 gumbox systemd[1]: Starting Load/Save RF Kill Switch Status...
Apr 27 20:02:54 gumbox kernel: Adding 1990652k swap on /dev/mapper/gumbox--vg-
swap_1.  Priority:-2 extents:1 across:1990652k SSFS
Apr 27 20:02:54 gumbox kernel: BUG: unable to handle kernel NULL pointer
dereference at 
Apr 27 20:02:54 gumbox kernel: PGD 0 P4D 0
Apr 27 20:02:54 gumbox kernel: Oops: 0010 [#1] SMP PTI
Apr 27 20:02:54 gumbox kernel: Modules linked in: iTCO_wdt iTCO_vendor_support
arc4 wmi_bmof iwldvm(+) coretemp kvm_intel mac80211 uvcvideo snd_hda_codec_cone
Apr 27 20:02:54 gumbox kernel:  usb_common e1000e ptp pps_core thermal
Apr 27 20:02:54 gumbox kernel: CPU: 1 PID: 373 Comm: systemd-udevd Not tainted
4.15.0-3-amd64 #1 Debian 4.15.17-1
Apr 27 20:02:54 gumbox kernel: Hardware name: LENOVO 74558HG/74558HG, BIOS
6DET72WW (3.22 ) 10/25/2012
Apr 27 20:02:54 gumbox kernel: RIP: 0010:  (null)
Apr 27 20:02:54 gumbox kernel: RSP: :9af7c07b79e0 EFLAGS: 00010206
Apr 27 20:02:54 gumbox kernel: RAX:  RBX: 886775d88000 RCX:
003e
Apr 27 20:02:54 gumbox kernel: RDX: c0b3eaa8 

Bug#897020: Usage of -s is broken

[Guilhem Moulin]

FYI I just refactored and simplified the option/argument verification
logic.  Here are examples of command invocations with 0, 1, or 2
non-optional arguments.


Listening on AF_UNIX socket /tmp/sock (nc.openbsd <1.187-1 supports only
the second invocation).

$ strace -e trace=bind nc -U -l -s /tmp/sock
bind(3, {sa_family=AF_UNIX, sun_path="/tmp/sock"}, 110) = 0

$ strace -e trace=bind nc -U -l /tmp/sock
bind(3, {sa_family=AF_UNIX, sun_path="/tmp/sock"}, 110) = 0

Listening on AF_INET socket 127.0.0.1:12345 (nc.traditional 1.10-41.1
supports only the first invocation, and nc.openbsd <1.187-1 supports
only the second one).

$ strace -e trace=bind nc -l -s 127.0.0.1 -p 12345
bind(3, {sa_family=AF_INET, sin_port=htons(12345), 
sin_addr=inet_addr("127.0.0.1")}, 16) = 0

$ strace -e trace=bind nc -l 127.0.0.1 12345
bind(3, {sa_family=AF_INET, sin_port=htons(12345), 
sin_addr=inet_addr("127.0.0.1")}, 16) = 0

Listening on AF_INET socket ADDR_ANY:12345 (nc.traditional 1.10-41.1
supports only the first invocation, and nc.openbsd <1.187-1 supports
only the second one).

$ strace -e trace=bind nc -l -p 12345
bind(3, {sa_family=AF_INET, sin_port=htons(12345), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0

$ strace -e trace=bind nc -l 12345
bind(3, {sa_family=AF_INET, sin_port=htons(12345), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0

Connecting to AF_UNIX socket /tmp/sock

$ strace -e trace=socket,bind,connect nc -NU /tmp/sock 

signature.asc
Description: PGP signature

Bug#897059: libgphoto2-6: libgphoto2 causes corrupted image file transfers

[Matti Hamalainen]

Package: libgphoto2-6
Version: 2.5.17
Severity: normal

Dear Maintainer,

After upgrading libgphoto2 to latest packaged version 2.5.17, I immediately
noticed that the CR2 RAW files fetched via "gphoto2 -P" were unreadable by
Darktable, Adobe Lightroom and other RAW image software. My cameras are Canon
EOS 7D Mark II and Canon EOS 500D, connected via USB. The problem occurs with
both cameras.

I quickly noticed that repeated transfers resulted in files with different
SHA256 sums. Downgrading to libgphoto2 to previous 2.5.16 makes the problem go
away, checksums are always consistent. With 2.5.17, each file had different
checksum for each transfer, pointing to serious corruption.

I should state that this is a VERY SERIOUS ISSUE! Usually when I transfer
photos from camera, I also immediately delete them from the camera's memory
card. Fortunately I noticed the problem with only few pictures taken, so I
personally suffered almost no loss... but it could have been much worse!

I have no idea if this affects only Canon cameras, as the changelog for 2.5.17
states various EOS -related changes, but I think notifying upstream would be
appropriate.




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

Kernel: Linux 4.16.5-qcmm (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)

Bug#895593: inadequate apparmor profile

[Reiner Herrmann]

Hi Giuseppe,

thanks for your report!

On Fri, Apr 13, 2018 at 10:14:01AM +0200, Giuseppe Bilotta wrote:
> audit: type=1400 audit(1523606448.089:48): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/home/USERNAME/.config/gtk-3.0/settings.ini" pid=4505 comm="surf" 
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
> audit: type=1400 audit(1523606486.893:88): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" name="/proc/4564/smaps" pid=4564 
> comm="WebKitWebProces" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
> audit: type=1400 audit(1523606448.561:55): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" name="/run/user/1000/dconf/user" 
> pid=4524 comm="WebKitNetworkPr" requested_mask="wc" denied_mask="wc" 
> fsuid=1000 ouid=1000
> audit: type=1400 audit(1523606448.257:50): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/home/USERNAME/.cache/gtk-3.0/compose/93817a95.cache" pid=4505 
> comm="pool" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

I'm adding these in the next upload to the whitelist.

> audit: type=1400 audit(1523606448.297:52): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/usr/share/fontconfig/conf.avail/" pid=4505 comm="surf" 
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

abstractions/fonts should already have this allowed:
  /usr/share/fontconfig/conf.avail/**  r,
I'll also add a whitelist for the directory itself.

> audit: type=1400 audit(1523606448.257:49): apparmor="DENIED" 
> operation="file_mmap" profile="/usr/bin/surf" 
> name="/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so" pid=4505 
> comm="surf" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0

surf doesn't complain about this for me.
Are you using this module somehow?

Kind regards,
   Reiner


signature.asc
Description: PGP signature

Bug#828741: libdatrie patch

[Ondrej Novy]

Hi,

2018-04-27 16:11 GMT+02:00 Andreas Tille :
>
> Ondřej, I hope you are fine if I just did the upload.


no problem, thanks for upload.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Bug#896530: No patch is required for python3-ase to use python3-spglib v1.10.3

[Andrius Merkys]

Dear Maintainers,

I was wrong -- no patch is necessary for python3-ase to use
python3-spglib v1.10.3. Therefore, dependency on python3-spglib might be
added as soon as python3-spglib is uploaded.

Best,
Andrius

Bug#897058: ITP: libocxl -- library to implement a userspace driver for OpenCAPI accelerators

[Frédéric Bonnard]

Package: wnpp
Severity: wishlist

LibOCXL provides an access library which allows the user to implement a
userspace driver for an OpenCAPI accelerator.
LibOCXL provides functions to attach to an AFU and transfer data to &
from the MMIO areas on the AFU. AFU IRQs can be queried either by IRQ
handles, or by associating a callback to the IRQ.

License: Apache-2.0
Copyright: 2017 International Business Machines Corporation and others.
URL: https://github.com/OpenCAPI/libocxl


pgpODWlmsDJzl.pgp
Description: PGP signature


pgptLk2BKcAUU.pgp
Description: PGP signature

Bug#896861: More notes on Open MPI / sometimes "-l" issues

[Jeff Squyres (jsquyres)]

On Apr 27, 2018, at 2:02 PM, Alastair McKinstry  
wrote:
> 
>> If we're not able to get the CI build product, has anyone been able to 
>> reproduce the error manually?
> No one's caught it manually yet :-(

Computers are hard.

> Debian libtool has a bunch of patches applied
> (https://sources.debian.org/src/libtool/2.4.6-2.1/debian/patches/)
> but nothing has changed in libtool in years.

Ok.

Could it be a dependent library that is generating (somehow) a faulty .la file? 
 Then the Open MPI libtool would be reading that and somehow getting a blank 
library name...?  (That's a complete guess)

> Two notes: (1) We run the build system / make in parallel.

Should be ok.  We do parallel builds all the time.

> (2) When it
> fails, its always at this spot.
> Whats special about this point in the makefile?

It's Fortran...?

That's the only thing I can think of.  But honestly -- it's a fairly vanilla 
Automake-ized Makefile.am.


https://github.com/open-mpi/ompi/blob/master/ompi/mpi/fortran/use-mpi-ignore-tkr/Makefile.am

The only interesting thing in that Makefile.am is that we generate 2 files 
(mpi-ignore-tkr-sizeof.h and mpi-ignore-tkr-sizeof.f90), but those are clearly 
delineated as dependencies.

Maybe you can put a patch in that Makefile.am that causes libtool to be cat'ed 
(or even emailed to yourself -- hah!) so that we can potentially run it 
manually / trace it to see where this blank library name is coming from...?

-- 
Jeff Squyres
jsquy...@cisco.com

Bug#896861: More notes on Open MPI / sometimes "-l" issues

[Alastair McKinstry]

On 27/04/2018 18:32, Jeff Squyres (jsquyres) wrote:
> Ah -- you *are* running autogen and re-bootstrapping our tarballs with your 
> own versions of the GNU Autotools.
>
> What versions are you running of m4, Autoconf, Automake, and Libtool?
>
> Open MPI v3.0.x is built with m4 1.4.17, Autoconf 2.69, Automake 1.15, and 
> Libtool 2.4.6.
automake 1.15.1
autoconf 2.69
libtool 2.4.6   
> If it really is libtool that is inserting this errant -l without a following 
> library name, I think we need to know what version of libtool (plus any 
> Debian-specific patches?) you are using to bootstrap Open MPI's build 
> process, and see/trace the libtool that is being used to see where that 
> errant -l is coming from.
>
> If we're not able to get the CI build product, has anyone been able to 
> reproduce the error manually?
No one's caught it manually yet :-(

Debian libtool has a bunch of patches applied
(https://sources.debian.org/src/libtool/2.4.6-2.1/debian/patches/)
but nothing has changed in libtool in years.

Two notes: (1) We run the build system / make in parallel. (2) When it
fails, its always at this spot.
Whats special about this point in the makefile?



-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
 believing the innocent had everything to fear, mostly from the guilty but in 
the longer term
 even more from those who say things like “The innocent have nothing to fear.”
 - T. Pratchett, Snuff

Bug#897057: libseccomp: support building without python

[Helmut Grohne]

Source: libseccomp
Version: 2.3.3-1
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libseccomp added Python bindings. That's nice, but it introduces a cycle
unfortunately. We need libseccomp for systemd and systemd comes quite
early as libsystemd-dev has quite a few reverse dependencies. Thus we
need to build libseccomp before we built python. The attached patch
implements that using the standard nopython build profile. I verified
that the build profile is clean using reproducible builds. Please
consider applying it soonish.

Helmut
diff --minimal -Nru libseccomp-2.3.3/debian/changelog 
libseccomp-2.3.3/debian/changelog
--- libseccomp-2.3.3/debian/changelog   2018-04-22 23:55:03.0 +0200
+++ libseccomp-2.3.3/debian/changelog   2018-04-27 18:33:50.0 +0200
@@ -1,3 +1,10 @@
+libseccomp (2.3.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support the nopython build profile. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 27 Apr 2018 18:33:50 +0200
+
 libseccomp (2.3.3-1) unstable; urgency=medium
 
   * New upstream release. (Closes: #895417)
diff --minimal -Nru libseccomp-2.3.3/debian/control 
libseccomp-2.3.3/debian/control
--- libseccomp-2.3.3/debian/control 2018-04-22 23:33:25.0 +0200
+++ libseccomp-2.3.3/debian/control 2018-04-27 18:33:50.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Kees Cook 
 Uploaders: Luca Bruno , Felix Geyer 
-Build-Depends: debhelper (>= 10~), linux-libc-dev, dh-python, python-all-dev, 
python3-all-dev, cython, cython3
+Build-Depends: debhelper (>= 10~), linux-libc-dev, dh-python , 
python-all-dev , python3-all-dev , cython , 
cython3 
 Standards-Version: 3.9.7
 Homepage: https://github.com/seccomp/libseccomp
 Vcs-Git: https://salsa.debian.org/debian/libseccomp.git
@@ -44,6 +44,7 @@
  the supported architectures.
 
 Package: python-seccomp
+Build-Profiles: 
 Architecture: linux-any
 Multi-Arch: same
 Section: python
@@ -54,6 +55,7 @@
  prctl() syscall.
 
 Package: python3-seccomp
+Build-Profiles: 
 Architecture: linux-any
 Multi-Arch: same
 Section: python
diff --minimal -Nru libseccomp-2.3.3/debian/rules libseccomp-2.3.3/debian/rules
--- libseccomp-2.3.3/debian/rules   2018-04-22 23:54:43.0 +0200
+++ libseccomp-2.3.3/debian/rules   2018-04-27 18:33:47.0 +0200
@@ -8,8 +8,13 @@
 export V=1
 
 %:
+ifeq ($(filter nopython,$(DEB_BUILD_PROFILES)),)
dh $@ --with python2,python3
+else
+   dh $@
+endif
 
+ifeq ($(filter nopython,$(DEB_BUILD_PROFILES)),)
 override_dh_auto_configure:
dh_auto_configure -- --enable-python
 
@@ -24,6 +29,7 @@
set -e && for pyver in `py3versions -s`; do \
dh_auto_install --sourcedirectory=src/python -- PYTHON=$$pyver; 
\
done
+endif
 
 override_dh_auto_clean:
dh_auto_clean

Bug#887155: swi-prolog FTBFS on armel/armhf/mipsel: Not enough resources: no_memory

[Lev Lamberov]

Hi Benjamin,

Пт 27 апр 2018 @ 17:06 Benjamin Lorenz :

> It seems a fix for this bug was merged into the upstream stable
> repository some time ago:
> https://github.com/SWI-Prolog/swipl/commit/3923765d56e5
>
> I have an unstable i386 VM where I could reproduce these memory errors
> and adding this to the patches resolves it.
>
> Since there is still no new upstream release and to avoid the
> autoremoval of this (+ a few downstream packages [1]), could you try to
> create a new debian release for 7.6.4 with this patch and the one for
> #893421.
>
> With these two patches the package was successfully built with java 9 on
> the VM where I previously had these memory errors.

Thank you for the information! I'll upload the fixed package in the next
couple of hours.

Regards,
Lev

Bug#897035: Should Suggest: ncurses-doc

[Sven Joachim]

Control: tags -1 + pending

On 2018-04-27 13:06 +0200, Yuri D'Elia wrote:

> Package: libncurses-dev
> Version: 6.1+20180210-2
> Severity: minor
>
> The old libncurses5-dev packages suggested the development documentation in 
> ncurses-doc.
> It would be nice do the same in the new package.

Absolutely.  I had _planned_ to transfer this field to the
libncurses-dev package, but botched that.  Fixed in git[1], thanks for
noticing!

Cheers,
   Sven


1. 
https://salsa.debian.org/debian/ncurses/commit/0f0f5cbaddaeeb313f15187b86cbe76552dc8200

Bug#896446: gotcha (am-utils: segfaulting error 4 in libc-2.27.so with kernels 4.+)

[Christian Montanari]

this patch works better...


diff --git a/amd/srvr_nfs.c b/amd/srvr_nfs.c
index 99624311..7c1c2ea0 100644
--- a/amd/srvr_nfs.c
+++ b/amd/srvr_nfs.c
@@ -958,7 +958,7 @@ no_dns:
   ITER(fs, fserver, _srvr_list) {
 if (STREQ(host, fs->fs_host) &&
nfs_version == fs->fs_version &&
-   STREQ(nfs_proto, fs->fs_proto)) {
+   (!nfs_proto || !fs->fs_proto || STREQ(nfs_proto, fs->fs_proto))) {
   /*
* fill in the IP address -- this is only needed
* if there is a chance an IP address will change

this nfs_proto, unset,  is being copied back into the "fs->fs_proto" structure 
and loops again.

-- 

Bug#896861: More notes on Open MPI / sometimes "-l" issues

[Jeff Squyres (jsquyres)]

On Apr 27, 2018, at 12:57 PM, Alastair McKinstry  
wrote:
> 
> Before configure the following is run:
> 
> (cd config && autom4te --language=m4sh opal_get_version.m4sh -o
> opal_get_version.sh)
> ./autogen.pl --force

Ah -- you *are* running autogen and re-bootstrapping our tarballs with your own 
versions of the GNU Autotools.

What versions are you running of m4, Autoconf, Automake, and Libtool?

Open MPI v3.0.x is built with m4 1.4.17, Autoconf 2.69, Automake 1.15, and 
Libtool 2.4.6.

> Then (in this case):
> 
> ./configure --build=powerpc64-linux-gnu --prefix=/usr 
>   --includedir=\${prefix}/include --mandir=\${prefix}/share/man 
> --infodir=\${prefix}/share/info 
>   --sysconfdir=/etc --localstatedir=/var --disable-silent-rules 
> --libdir=\${prefix}/lib/powerpc64-linux-gnu 
>   --libexecdir=\${prefix}/lib/powerpc64-linux-gnu --runstatedir=/run 
> --disable-maintainer-mode 
>   --disable-dependency-tracking --with-verbs 
> --with-pmix=/usr/lib/powerpc64-linux-gnu/pmix 
>  --with-jdk-dir=/usr/lib/jvm/default-java --enable-mpi-java 
> --enable-opal-btl-usnic-unit-tests --disable-wrapper-rpath 
>  --with-libevent=external --enable-mpi-thread-multiple --disable-silent-rules 
> --enable-mpi-cxx 
>   --with-hwloc=/usr/ --with-libltdl=/usr/ --with-devel-headers --with-slurm 
> --with-sge --without-tm
>  --disable-vt --sysconfdir=/etc/openmpi 
> --libdir=\${prefix}/lib/powerpc64-linux-gnu/openmpi/lib 
>   --includedir=\${prefix}/lib/powerpc64-linux-gnu/openmpi/include
> configure: WARNING: unrecognized options: --disable-maintainer-mode, 
> --enable-mpi-thread-multiple, --disable-vt
> checking for perl... perl

This all generally looks fine.

If it really is libtool that is inserting this errant -l without a following 
library name, I think we need to know what version of libtool (plus any 
Debian-specific patches?) you are using to bootstrap Open MPI's build process, 
and see/trace the libtool that is being used to see where that errant -l is 
coming from.

If we're not able to get the CI build product, has anyone been able to 
reproduce the error manually?

-- 
Jeff Squyres
jsquy...@cisco.com

Bug#897056: kdump grub cmdline value squashes user-provided one

[Alice Goldfuss]

Package: kdump-tools
Version: 1:1.6.3-2

Kernel: 4.9.0-0.bpo.5-amd64 #1 SMP Debian 4.9.65-3+deb9u2~bpo8+1
(2017-01-05) x86_64 GNU/Linux
Lib:  2.19-18+deb8u10


Perhaps related to #877250


The package adds this value to kdump-tools.grub.default:

GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT
crashkernel=384M-:128M"

This setting may work for most boxes, but we have kubernetes hosts with
large memory footprints that need at least 256M.

We set this value in Puppet, but the package value is added after it in the
cmdline and therefore trumps it:

BOOT_IMAGE=/vmlinuz-4.9.0-0.bpo.5-amd64  crashkernel=256M  crashkernel=384M-:128M

So, when these boxes crash, they get stuck (with no logging indicating what
the issue is) and don’t come back without manual intervention. They also
don’t record a crash dump.

I chased this bad behavior for 3+ months and would really like to see it
resolved at the package level.

My suggestion is to remove the value or replace it with crashkernel=auto
where supported. Also, better logging (something like “Unable to create
crash dump. Crashkernel size too small.”) would have helped me solve this
issue in a day.

Thanks!
Alice

Bug#896572: message: Cannot use GPU in CPU-only Caffe (caffe-cuda build)

[Юрий Жаворонков]

I'm sorry that i have misled You. Before the ussage, I forgot to remove the 
manually compiled caffe-cpu and sent a bug report ;(

Now i pugre it and reinstall caffe-cuda package, but on command "optirun caffe 
device_query -gpu all"
it take me: 
Check failed: error == cudaSuccess (30 vs. 0)  unknown error
*** Check failure stack trace: ***
@ 0x7f2ad760b13d  google::LogMessage::Fail()
@ 0x7f2ad760cfa3  google::LogMessage::SendToLog()
@ 0x7f2ad760accb  google::LogMessage::Flush()
@ 0x7f2ad760d98e  google::LogMessageFatal::~LogMessageFatal()
@   0x40a4fb  (unknown)
@   0x409f9b  device_query()
@   0x40dae9  main
@ 0x7f2ad5b122e1  __libc_start_main
@   0x409c4a  _start
@  (nil)  (unknown)

26.04.2018, 12:36, "Lumin" :
> control: tag -1 +moreinfo
>
> Hello Programmeur,
>
> Thank you for this report.
> However this issue seems strange ... it should not happen ...
>
> According to the source file,
>
> include/caffe/util/device_alternate.hpp
> 4:#ifdef CPU_ONLY // CPU-only Caffe.
> 10:#define NO_GPU LOG(FATAL) << "Cannot use GPU in CPU-only Caffe: check 
> mode."
>
> This error message will only appear when your caffe is compiled CPU-only.
> Could you please provide me the following information:
>
> 1. Type this command in your terminal: `which caffe`, and paste the
> output in the mail.
> If it is not /usr/bin/caffe, then the answer is clear: you are
> running your self-built
> CPU-only caffe.
>
> 2. The output of the following two commands:
> 1. "apt list libcaffe\*"
> 2. "apt show libcaffe-cuda1"
>
> Have a good day.
>
> --
> Best,

-- 
С уважением,
Жаворонков Ю. Г.
+79528693394

Bug#845297: Migration to Salsa

[Laura Arjona Reina]

Hello

El 27/04/18 a las 17:43, Steve McIntyre escribió:
> On Wed, Apr 18, 2018 at 11:01:03AM +0200, Laura Arjona Reina wrote:
>> Hello again
>>
>> El 18/04/18 a las 01:33, Laura Arjona Reina escribió:
>>
>>>
>>> * I will copy the migrated-to-git webwml repos (the tests) to
>>> https://salsa.debian.org/groups/webmaster-team/webwml/ labelling them as
>>> tests so people don't get confused. If you want to hack on those and you
>>> were not added as "developer" of the group yet, please request join the
>>> group and me or other admin will grant permissions.
>>
>> This is done now:
>>
>> https://salsa.debian.org/webmaster-team/webwml/test_webwml_cvs2git
>> https://salsa.debian.org/webmaster-team/webwml/test_webwml
>>
>> I will remove the "test repos" in my personal space in Salsa, and in Alioth.
> 
> Cool.
> 
> So... Laura and I were talking on IRC yesterday. I've been swamped
> with a range of family things that removed my "free" time over the
> last few months, so I've been unable to really help much so far. Laura
> has been talking about running a sprint to work on the migration. I
> think that sounds like a splendid idea, but I can't really travel much
> at the moment. However, I'm thinking of taking some vacation (a week
> or so) from my day job during May to get stuck in here. When are other
> people available?
>

For now I have May free so I am available mostly European
evenings/nights but probably at other times too.

I cannot travel much at this moment either but if we decide 2-3 days to
do a "distributed" or "remote" sprint I would do my best to be more
available (remotely) for website work in those days.

> What can I help with? I'm OK-ish in perl, so I'm thinking of looking
> at the translation workflow stuff, unless that's already in hand. 

Yes please! I would propose to work in this repo:

https://salsa.debian.org/webmaster-team/webwml/test_webwml_cvs2git

and when we have ready the new scripts or adapted the current ones, we
can make patches of those commits and apply them in the CVS webwml repo,
and then when we run again the cvs2git script for the final migration,
the resultant repo will contain the good scripts.

Is
> https://wiki.debian.org/WebsiteGitTransition still the canonical place
> to track the planning?
> 

I have just reviewed and updated it with the current status of things.
So as for today, I think that reading the wiki page (alone) should give
an idea of what has been done, the remaining work, and the other
ideas/approaches that we could try.

Cheers

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#897055: RFS: xml2/0.5-2 [QA]

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for package "xml2" as a QA upload. The
main point is the migration of Vcs fields from Alioth to Salsa:

 * Package name: xml2
   Version : 0.5-2
 * URL : [defunct]
 * License : GPLv2
   Section : utils


  It builds those binary packages:

xml2  - Convert between XML, HTML, CSV and a line-oriented format


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

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


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

dget -x https://mentors.debian.net/debian/pool/main/x/xml2/xml2_0.5-2.dsc


  Salsa packaging repository:

https://salsa.debian.org/debian/xml2.git


  Changes since the last upload:

   xml2 (0.5-2) unstable; urgency=medium
 .
   * QA upload.
   * d/control: Use Salsa repo for Vcs fields.
   * d/rules: Use "dh_missing --fail-missing".
   * Bump Standards-Version to 4.1.4 (no changes needed).
   * Bump debhelper compat to v11.


  Regards,
   Boyuan Yang

Bug#897054: qemu: add support for AMD Zen SMT (Hyperthreading)

[Maxime Lombard]

Source: qemu
Version: 2.12+dfsg-1
Severity: wishlist
Tags: patch

Dear Maintainer,

Hello guys,

I would like to know if you have the possibility to add an unofficial patch in 
"debian/patches".
This patch add the support for the AMD Zen (Ryzen) SMT/Hyperthreading.

Without it, if i configure Qemu's script / virt-manager processor option like 
this :

Socket = 1 ; Cores = 6 ; Threads = 2

CPU-Z on my Windows 10 VM return that i have 1 Core and 12 Threads.

This patch needs a patch applied in the Kernel. Fortunatly, this patch was 
added in the Kernel 4.16 so it will be on Unstable soon (I hope).

The patch for Qemu :
https://patchwork.kernel.org/patch/10040903/raw/


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

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

Bug#897053: muon exit with segment fault when check for update

[Antonio]

Package: muon
Version: 4:5.8.0-1

Dear Maintainer,
when start muon and check for update, the program exit with segfault:

kf5.kwidgetsaddons: Invalid pixmap specified.
kf5.kwidgetsaddons: No frame loaded
kf5.kwidgetsaddons: No frame loaded
kf5.kwidgetsaddons: No frame loaded
Couldn't find the
/usr/lib/python3/dist-packages/DistUpgrade/DistUpgradeFetcherKDE.py file
kf5.kwidgetsaddons: No frame loaded
kf5.kwidgetsaddons: No frame loaded
kf5.kwidgetsaddons: No frame loaded
kf5.kwidgetsaddons: No frame loaded
kf5.kwidgetsaddons: No frame loaded
kf5.kwidgetsaddons: No frame loaded
Errore di segmentazione



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

Kernel: Linux 4.16.5-custom (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=it_IT, LC_CTYPE=it_IT (charmap=ISO-8859-1), LANGUAGE=it
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages muon depends on:
ii  apt-xapian-index  0.49
ii  kio   5.44.0-2
ii  libc6 2.27-3
ii  libdebconf-kde1   1.0.3-1
ii  libkf5completion5 5.44.0-1
ii  libkf5configcore5 5.44.0-1
ii  libkf5configgui5  5.44.0-1
ii  libkf5configwidgets5  5.44.0-1
ii  libkf5coreaddons5 5.44.0-1
ii  libkf5dbusaddons5 5.44.0-1
ii  libkf5i18n5   5.44.0-1
ii  libkf5iconthemes5 5.44.0-1
ii  libkf5kiocore55.44.0-2
ii  libkf5widgetsaddons5  5.44.0-1
ii  libkf5xmlgui5 5.44.0-2+b1
ii  libqapt3  3.0.4-1
ii  libqapt3-runtime  3.0.4-1
ii  libqt5core5a  5.10.1+dfsg-5
ii  libqt5gui55.10.1+dfsg-5
ii  libqt5network55.10.1+dfsg-5
ii  libqt5widgets55.10.1+dfsg-5
ii  libstdc++68-20180425-1

muon recommends no packages.

muon suggests no packages.

-- no debconf information

Bug#895710: Please close 895710

[John David Anglin]

 Forwarded Message 
Subject:Re: Repeated mess with sbuild
Date:   Fri, 27 Apr 2018 11:23:47 +0200
From:   John Paul Adrian Glaubitz 
To: 	John David Anglin , Helge Deller 
, James Clarke , glaub...@debian.org




Hi Dave!

On 04/21/2018 08:43 PM, John David Anglin wrote:

The +b1 upload is broken.  It is missing haddock.  Since there is no log, it's 
impossible
to see what went wrong.  Debian bug is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895710

The same problem appears to be present for m68k and sh4.

I did a nmu for +b2.


This isn't a bug, but just a result of the cross-compilation of GHC for which
haddock is disabled. I simply forgot the native build after the initial
bootstrap.

Native building on sh4 is not possible at the moment though, I will take care
of m68k later. You can close the bug report as invalid.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#896704: RFS: python-picklable-itertools/0.1.1-2 [RC]

[Fabian Wolff]

On Fri, Apr 27, 2018 at 12:47:12PM -0400, Sergio Durigan Junior wrote:
> I've uploaded the package now.

Great, thank you!

Bug#896861: More notes on Open MPI / sometimes "-l" issues

[Alastair McKinstry]

> Note the "-l" hanging out there by itself.
>
> I also note the "-levent_pthreads" immediately preceding it, which is the 
> last argument from the Open MPI-issued compile line.
>
> That means that libtool itself is adding the -l without a following library 
> name (or erroneously blank following library name).
>
> It might be worth checking the .la files that libtool is examining -- perhaps 
> from elsewhere on the system / outside the source/build trees -- here to see 
> if there are any unexpectedly-empty library names.  If those .la files got 
> built incorrectly somehow, that could lead to link errors later like this...?
>
> Is it possible to check the build product from your automated CI like this?
Not sure.
We can re-run the build until it fails (no luck so far), but we don't
have the image.

> This is using the Open MPI-bootstrap-provided libtool, right (i.e., from the 
> Open MPI 3.0.x tarball)?  I.e., you didn't invoke "autogen.pl" again to 
> re-bootstrap the Open MPI build system, right?
>
Before configure the following is run:

    (cd config && autom4te --language=m4sh opal_get_version.m4sh -o
opal_get_version.sh)
    ./autogen.pl --force

Then (in this case):

./configure --build=powerpc64-linux-gnu --prefix=/usr 
   --includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info 
   --sysconfdir=/etc --localstatedir=/var --disable-silent-rules 
--libdir=\${prefix}/lib/powerpc64-linux-gnu 
   --libexecdir=\${prefix}/lib/powerpc64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode 
   --disable-dependency-tracking --with-verbs 
--with-pmix=/usr/lib/powerpc64-linux-gnu/pmix 
  --with-jdk-dir=/usr/lib/jvm/default-java --enable-mpi-java 
--enable-opal-btl-usnic-unit-tests --disable-wrapper-rpath 
  --with-libevent=external --enable-mpi-thread-multiple --disable-silent-rules 
--enable-mpi-cxx 
   --with-hwloc=/usr/ --with-libltdl=/usr/ --with-devel-headers --with-slurm 
--with-sge --without-tm
  --disable-vt --sysconfdir=/etc/openmpi 
--libdir=\${prefix}/lib/powerpc64-linux-gnu/openmpi/lib 
   --includedir=\${prefix}/lib/powerpc64-linux-gnu/openmpi/include
configure: WARNING: unrecognized options: --disable-maintainer-mode, 
--enable-mpi-thread-multiple, --disable-vt
checking for perl... perl

 
regards
Alastair



-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
 believing the innocent had everything to fear, mostly from the guilty but in 
the longer term
 even more from those who say things like “The innocent have nothing to fear.”
 - T. Pratchett, Snuff

Bug#895836: flex: Upgrading from 2.6.1-1.3 to 2.6.4-6 breaks apache module loading

[Robbie Harwood]

Thanks Adrian!

Timo, this is fixed in upstream PR 179.

Thanks,
--Robbie

Bug#897025: RFS: node-v8-compile-cache

[Paolo Greppi]

Hi, I have packaged node-v8-compile-cache:
https://salsa.debian.org/js-team/v8-compile-cache

I am Cc-ing the ITP.

Please someone sponsor the upload.

Paolo

Bug#897052: [virtualbox-ext-pack] Hash mismatch between package and virtualbox website

[Carlos C Soto]

Package: virtualbox-ext-pack
Version: 5.2.10-3
Severity: normal

--- Please enter the report below this line. ---

When installing the package virtualbox-ext-pack it fails:

Hash mismatch Oracle_VM_VirtualBox_Extension_Pack-5.2.10.vbox-extpack: 
expected 
8c31bc1d0337e6668e0d9140defc6deaf265087f855783dd09b873a064a70703, or 
wrong accept-license key



Inside the package file debian/postinst.in it contains:

version=#VERSION#
hash=8c31bc1d0337e6668e0d9140defc6deaf265087f855783dd09b873a064a70703
file=Oracle_VM_VirtualBox_Extension_Pack-$version.vbox-extpack
accept_license=56be48f923303c8cababb0bb4c478284b688ed23f16d775d729b89a2e8e5f9eb


But according to 
https://www.virtualbox.org/download/hashes/5.2.10/SHA256SUMS


8c31bc1d0337e6668e0d9140defc6deaf265087f855783dd09b873a064a70703 
*Oracle_VM_VirtualBox_Extension_Pack-5.2.10-122088.vbox-extpack
5eef217dbe0a8e8caf383ea8db83344517af0f9093041b5345c8468a427b327b 
*Oracle_VM_VirtualBox_Extension_Pack-5.2.10-122406.vbox-extpack
5eef217dbe0a8e8caf383ea8db83344517af0f9093041b5345c8468a427b327b 
*Oracle_VM_VirtualBox_Extension_Pack-5.2.10.vbox-extpack
...


The downloaded file actually constains 
5eef217dbe0a8e8caf383ea8db83344517af0f9093041b5345c8468a427b327b

So, I think that this package should be updated to match with virtualbox 
publication.


Thanks for your package :)




--- System information. ---
Architecture:
Kernel: Linux 4.15.0-3-amd64

Debian Release: buster/sid
990 testing httpredir.debian.org
500 stretch download.docker.com
500 stable repo.vivaldi.com
500 stable repo.skype.com
500 stable packages.microsoft.com
500 stable dl.google.com
500 stable dl.bintray.com
500 sid linux.dropbox.com
500 artful ppa.launchpad.net
200 unstable httpredir.debian.org
1 experimental httpredir.debian.org

--- Package information. ---
Depends (Version) | Installed
===-+-=
virtualbox (<< 5.2.10-dfsg-z) | 5.2.10-dfsg-2
OR virtualbox-5.2 |
virtualbox (>= 5.2.10-dfsg-0~) | 5.2.10-dfsg-2
OR virtualbox-5.2 |
wget | 1.19.4-1
debconf (>= 0.5) | 1.5.66
OR debconf-2.0 |


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#873508: sparse test failures & PATH_MAX

[Luc Van Oostenryck]

On Fri, Apr 27, 2018 at 09:33:55AM +0200, Uwe Kleine-König wrote:
> On 04/27/2018 09:33 AM, Luc Van Oostenryck wrote:
> > On Fri, Apr 27, 2018 at 07:56:38AM +0200, Uwe Kleine-König wrote:
> >> Hello,
> >>
> >>> [..]
> >>
> >> Just a heads up: I uploaded 0.5.2 to Debian and there are problems left
> >> on hurd-i386 (where PATH_MAX isn't defined[1])
> >> ...
> >> [1]
> >> https://buildd.debian.org/status/fetch.php?pkg=sparse=hurd-i386=0.5.2-1=1524168405=0
> > 
> > Thanks for the repport.
> > I'll see what can be done.
> 
> I think the default idiom is:
> 
> #ifndef PATH_MAX
> #define PATH_MAX 4096
> #endif

Yes.
I had hoped to avoid this together with removing a memcpy() but things are
more annoying than I had first thought.

Best regards,
-- Luc

Bug#896861: More notes on Open MPI / sometimes "-l" issues

[Jeff Squyres (jsquyres)]

Thanks to Alastair for filing https://github.com/open-mpi/ompi/issues/5114 to 
inform us upstream of this issue.

When this problem occurs, can you tell:

1. Is the errant "-l" being added by libtool (i.e., at "make" time)?
2. Or is the errant "-l" being added by configure (i.e., at "./configure" time)?

Looking at the very bottom of one of the logs on this ticket 
(https://buildd.debian.org/status/fetch.php?pkg=openmpi=ppc64=3.0.1-9=1524654706=0)
 -- extra blank lines inserted below for just for clarity):

-
make[3]: Entering directory 
'/<>/ompi/mpi/fortran/use-mpi-ignore-tkr'

/bin/bash ../../../../libtool  --tag=FC   --mode=link gfortran 
-I../../../../ompi/include -I../../../../ompi/include -I../../../.. 
-I../../../..  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -O3 -version-info 40:0:0  -Wl,-z,relro   -L/usr//lib  
-o libmpi_usempi_ignore_tkr.la -rpath /usr/lib/powerpc64-linux-gnu/openmpi/lib 
mpi-ignore-tkr.lo mpi-ignore-tkr-sizeof.lo /<>/opal/libopen-pal.la 
-lrt -lm -lutil   -lhwloc  -levent -levent_pthreads

libtool: link: gfortran -shared  -fPIC  .libs/mpi-ignore-tkr.o 
.libs/mpi-ignore-tkr-sizeof.o   -Wl,-rpath -Wl,/<>/opal/.libs 
-Wl,-rpath -Wl,/usr/lib/powerpc64-linux-gnu/openmpi/lib -L/usr//lib 
/<>/opal/.libs/libopen-pal.so -lrt -lutil -lhwloc -levent 
-levent_pthreads -l -L/usr/lib/gcc/powerpc64-linux-gnu/7 
-L/usr/lib/gcc/powerpc64-linux-gnu/7/../../../powerpc64-linux-gnu 
-L/usr/lib/gcc/powerpc64-linux-gnu/7/../../../../lib -L/lib/powerpc64-linux-gnu 
-L/lib/../lib -L/usr/lib/powerpc64-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/powerpc64-linux-gnu/7/../../.. -lgfortran -lm -lc -lgcc_s  -g 
-O2 -fstack-protector-strong -O3 -Wl,-z -Wl,relro   -pthread -Wl,-soname 
-Wl,libmpi_usempi_ignore_tkr.so.40 -o .libs/libmpi_usempi_ignore_tkr.so.40.0.0

/usr/bin/powerpc64-linux-gnu-ld: cannot find 
-l-L/usr/lib/gcc/powerpc64-linux-gnu/7

collect2: error: ld returned 1 exit status

make[3]: *** [Makefile:1866: libmpi_usempi_ignore_tkr.la] Error 1


I see:

/usr/bin/powerpc64-linux-gnu-ld: cannot find 
-l-L/usr/lib/gcc/powerpc64-linux-gnu/7

But the real problem looks like "-l" was added with either no library name, or 
a *blank* library name following it.  In the middle of the long "libtool:" line:


... -levent_pthreads -l -L/usr/lib/gcc/powerpc64-linux-gnu/7 ...


Note the "-l" hanging out there by itself.

I also note the "-levent_pthreads" immediately preceding it, which is the last 
argument from the Open MPI-issued compile line.

That means that libtool itself is adding the -l without a following library 
name (or erroneously blank following library name).

It might be worth checking the .la files that libtool is examining -- perhaps 
from elsewhere on the system / outside the source/build trees -- here to see if 
there are any unexpectedly-empty library names.  If those .la files got built 
incorrectly somehow, that could lead to link errors later like this...?

Is it possible to check the build product from your automated CI like this?

This is using the Open MPI-bootstrap-provided libtool, right (i.e., from the 
Open MPI 3.0.x tarball)?  I.e., you didn't invoke "autogen.pl" again to 
re-bootstrap the Open MPI build system, right?

-- 
Jeff Squyres
jsquy...@cisco.com

Bug#897051: gnome-software-plugin-flatpak: crashes on one-click install

[Johannes Rohr]

Package: gnome-software-plugin-flatpak
Version: 3.28.1-1
Severity: important

When I try to install a package by clicking a link at flathub.org, e.g. on 
https://flathub.org/apps/details/org.gnome.FeedReader
gnome-software immediately ѕegfaults.

Here is the console output:

15:45:18:0628 Gs  pushing back entry for overview
15:45:18:0629 As  run 0x563329a72140~GsPlugin::*(gs_plugin_file_to_app)
15:45:18:0629 As  run 0x563329a72140~GsPlugin::fwupd(gs_plugin_file_to_app)
15:45:18:0629 As  run 
0x563329a72140~GsPlugin::packagekit-local(gs_plugin_file_to_app)
15:45:18:0629 As  run 0x563329a72140~GsPlugin::flatpak(gs_plugin_file_to_app)
15:45:18:0629 Gs  recursively removing directory 
'/home/jr/.cache/gnome-software/flatpak'
15:45:18:0947 flatpak Imported 1 GPG key to remote "org.gnome.FeedReader-origin"
Speicherzugriffsfehler (that's German for segfault)

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

Kernel: Linux 4.15.0-3-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 gnome-software-plugin-flatpak depends on:
ii  flatpak 0.11.4-1
ii  gnome-software  3.28.1-1
ii  libappstream-glib8  0.7.7-2
ii  libc6   2.27-3
ii  libflatpak0 0.11.4-1
ii  libgdk-pixbuf2.0-0  2.36.11-2
ii  libglib2.0-02.56.1-2
ii  libgtk-3-0  3.22.30-1

gnome-software-plugin-flatpak recommends no packages.

gnome-software-plugin-flatpak suggests no packages.

-- no debconf information

Bug#845297: Migration to Salsa

[Steve McIntyre]

On Wed, Apr 18, 2018 at 11:01:03AM +0200, Laura Arjona Reina wrote:
>Hello again
>
>El 18/04/18 a las 01:33, Laura Arjona Reina escribió:
>
>> 
>> * I will copy the migrated-to-git webwml repos (the tests) to
>> https://salsa.debian.org/groups/webmaster-team/webwml/ labelling them as
>> tests so people don't get confused. If you want to hack on those and you
>> were not added as "developer" of the group yet, please request join the
>> group and me or other admin will grant permissions.
>
>This is done now:
>
>https://salsa.debian.org/webmaster-team/webwml/test_webwml_cvs2git
>https://salsa.debian.org/webmaster-team/webwml/test_webwml
>
>I will remove the "test repos" in my personal space in Salsa, and in Alioth.

Cool.

So... Laura and I were talking on IRC yesterday. I've been swamped
with a range of family things that removed my "free" time over the
last few months, so I've been unable to really help much so far. Laura
has been talking about running a sprint to work on the migration. I
think that sounds like a splendid idea, but I can't really travel much
at the moment. However, I'm thinking of taking some vacation (a week
or so) from my day job during May to get stuck in here. When are other
people available?

What can I help with? I'm OK-ish in perl, so I'm thinking of looking
at the translation workflow stuff, unless that's already in hand. Is
https://wiki.debian.org/WebsiteGitTransition still the canonical place
to track the planning?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds

Bug#897021: RFS: node-peek-stream

[Paolo Greppi]

Hi, I have packaged node-peek-stream:
https://salsa.debian.org/js-team/node-peek-stream

I am Cc-ing the ITP.

Please someone sponsor the upload.

Paolo

Bug#896704: RFS: python-picklable-itertools/0.1.1-2 [RC]

[Fabian Wolff]

On Tue, Apr 24, 2018 at 10:55:00PM -0400, Sergio Durigan Junior wrote:
> Or you can also move the package under the Debian Python Modules Team
> umbrella, if it makes more sense.  Packaging Python modules with the
> DPMT is the preferred way nowadays, but that's really up to you (and
> just to be clear, I have no problem if you decide to maintain the
> package by yourself).

I have joined the DPMT and created a repository there:

  https://salsa.debian.org/python-team/modules/python-picklable-itertools

I have also set the DPMT as Maintainer in debian/control.

> I think it's best if we keep the package unchanged for now.  Sorry about
> this extra round-trip, but can you please re-add the Python 2 package?
> 
> Actually, I've just noticed that the lintian flag in question
> ("new-package-should-not-package-python2-module") only applies to the
> first upload of the package, and will actually be gone once we upload
> this next version, so there's really nothing that needs to be done from
> your part about it.  I'm sorry about the noise.
> 
> Once you reintroduce the Python 2 package, I'll do the upload.

I have reuploaded the package to Mentors:

  https://mentors.debian.net/package/python-picklable-itertools

Best regards,
Fabian

Bug#681326: pristine-tar: Directly accessing .git directory

[Ian Jackson]

Ian Jackson writes ("Re: Bug#681326: pristine-tar: Directly accessing .git 
directory"):
> *With* or *in* a worktree ?  Anyway, I will try it and report back.

I just tried it in a worktree.  It worked.

I think this means that either
 (i) this bug was fixed since pristine-tar 1.25
or
 (ii) the diagnosis in the original report is wrong.

I hate git subtrees with a vengeance so I am not investigating further
:-).  Sorry for the noise.

Ian.

Bug#896691: RFS: safe-regex

[Paolo Greppi]

Hi, I have packaged node-safe-regex:
https://salsa.debian.org/js-team/node-safe-regex

It requires node-ret which is already in the NEW queue.
I have tested the build with sbuild --extra-package

I am Cc-ing the ITP.

Please someone sponsor the upload.

Paolo

Bug#897050: git-deborig does not work in a worktree

[Ian Jackson]

Package: devscripts
Version: 2.18.2

A tree made with `git worktree add' has a file for .git, rather than a
directory.

In such a tree, git-deborig does this:

$ git-deborig
pwd doesn't look like a Debian source package in a git repository ..
$

git-deborig may want to use  git rev-parse --git-dir

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#897049: zita-resampler FTCBFS: multiple reasons

[Helmut Grohne]

Source: zita-resampler
Version: 1.6.0-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

zita-resampler fails to cross build from source for multiple reasons:
 * The upstream build system hard codes g++ as the compiler.
 * The debian packaging does not always supply a cross compiler to make.
   Use dh_auto_build to fix that.
 * ldconfig does not work during cross compilation.
The attached patch fixes all of that. Please consider applying it.

Helmut
diff --minimal -Nru zita-resampler-1.6.0/debian/changelog 
zita-resampler-1.6.0/debian/changelog
--- zita-resampler-1.6.0/debian/changelog   2016-11-01 19:35:32.0 
+0100
+++ zita-resampler-1.6.0/debian/changelog   2018-04-26 05:47:12.0 
+0200
@@ -1,3 +1,13 @@
+zita-resampler (1.6.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Make g++ substitutable.
++ Let dh_auto_build substitute pass cross tools to make.
++ Don't use ldconfig at build time.
+
+ -- Helmut Grohne   Thu, 26 Apr 2018 05:47:12 +0200
+
 zita-resampler (1.6.0-2) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru zita-resampler-1.6.0/debian/patches/01-makefile.patch 
zita-resampler-1.6.0/debian/patches/01-makefile.patch
--- zita-resampler-1.6.0/debian/patches/01-makefile.patch   2016-10-31 
14:53:39.0 +0100
+++ zita-resampler-1.6.0/debian/patches/01-makefile.patch   2018-04-26 
05:47:12.0 +0200
@@ -76,7 +76,7 @@
install -m 644 $(ZITA-RESAMPLER_MIN) $(DESTDIR)$(PREFIX)/$(LIBDIR)
ln -sf $(ZITA-RESAMPLER_MIN) 
$(DESTDIR)$(PREFIX)/$(LIBDIR)/$(ZITA-RESAMPLER_SO)
 -  ldconfig
-+  /sbin/ldconfig -n $(DESTDIR)$(PREFIX)/$(LIBDIR)
++  ln -sf $(ZITA-RESAMPLER_MIN) 
$(DESTDIR)$(PREFIX)/$(LIBDIR)/$(ZITA-RESAMPLER_MAJ)
  
  uninstall:
/bin/rm -rf $(DESTDIR)$(PREFIX)/include/zita-resampler
diff --minimal -Nru zita-resampler-1.6.0/debian/patches/02-cross.patch 
zita-resampler-1.6.0/debian/patches/02-cross.patch
--- zita-resampler-1.6.0/debian/patches/02-cross.patch  1970-01-01 
01:00:00.0 +0100
+++ zita-resampler-1.6.0/debian/patches/02-cross.patch  2018-04-26 
05:47:12.0 +0200
@@ -0,0 +1,31 @@
+--- zita-resampler-1.6.0.orig/apps/Makefile
 zita-resampler-1.6.0/apps/Makefile
+@@ -36,7 +36,7 @@
+ ZRESAMPLE_O = zresample.o audiofile.o dither.o
+ zresample:LDLIBS += -lzita-resampler -lsndfile -lrt
+ zresample:$(ZRESAMPLE_O)
+-  g++ $(LDFLAGS) -o $@ $(ZRESAMPLE_O) $(LDLIBS)
++  $(CXX) $(LDFLAGS) -o $@ $(ZRESAMPLE_O) $(LDLIBS)
+ $(ZRESAMPLE_O):
+ -include $(ZRESAMPLE_O:%.o=%.d)
+ 
+@@ -44,7 +44,7 @@
+ ZRETUNE_O = zretune.o audiofile.o dither.o
+ zretune:  LDLIBS += -lzita-resampler -lsndfile -lrt
+ zretune:  $(ZRETUNE_O)
+-  g++ $(LDFLAGS) -o $@ $(ZRETUNE_O) $(LDLIBS)
++  $(CXX) $(LDFLAGS) -o $@ $(ZRETUNE_O) $(LDLIBS)
+ $(ZRETUNE_O):
+ -include $(ZRETUNE_O:%.o=%.d)
+ 
+--- zita-resampler-1.6.0.orig/libs/Makefile
 zita-resampler-1.6.0/libs/Makefile
+@@ -46,7 +46,7 @@
+ 
+ 
+ $(ZITA-RESAMPLER_MIN): $(ZITA-RESAMPLER_O)
+-  g++ -shared $(LDFLAGS) -Wl,-soname,$(ZITA-RESAMPLER_MAJ) -o 
$(ZITA-RESAMPLER_MIN) $(ZITA-RESAMPLER_O) $(ZITA-RESAMPLER_DEP)
++  $(CXX) -shared $(LDFLAGS) -Wl,-soname,$(ZITA-RESAMPLER_MAJ) -o 
$(ZITA-RESAMPLER_MIN) $(ZITA-RESAMPLER_O) $(ZITA-RESAMPLER_DEP)
+ 
+ $(ZITA-RESAMPLER_O):  $(ZITA-RESAMPLER_H)
+ 
diff --minimal -Nru zita-resampler-1.6.0/debian/patches/series 
zita-resampler-1.6.0/debian/patches/series
--- zita-resampler-1.6.0/debian/patches/series  2016-10-31 14:53:39.0 
+0100
+++ zita-resampler-1.6.0/debian/patches/series  2018-04-26 05:47:12.0 
+0200
@@ -1 +1,2 @@
 01-makefile.patch
+02-cross.patch
diff --minimal -Nru zita-resampler-1.6.0/debian/rules 
zita-resampler-1.6.0/debian/rules
--- zita-resampler-1.6.0/debian/rules   2016-10-31 14:53:39.0 +0100
+++ zita-resampler-1.6.0/debian/rules   2018-04-26 05:47:12.0 +0200
@@ -15,7 +15,7 @@
 
 override_dh_auto_install:
dh_auto_install
-   $(MAKE) -C apps/ DESTDIR=$(CURDIR)/debian/tmp
+   dh_auto_build -Dapps -- DESTDIR=$(CURDIR)/debian/tmp
$(MAKE) -C apps/ DESTDIR=$(CURDIR)/debian/tmp install
 
 override_dh_installchangelogs:

Bug#897048: bsdgames: make choice of c compiler more flexible

[Helmut Grohne]

Source: bsdgames
Version: 2.17-26
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

While trying to cross build bsdgames, I noticed that it would always
select gcc and g++ as compilers. The attached patch does not make
bsdgames cross buildable, but it makes bsdgames use a more suitable
compiler:
 * For cross compilation dpkg's buildtools.mk has sane defaults.
 * Using the CC and CXX variables allows builders to override the
   compiler e.g. with clang in a uniform way.

Cross building still fails, because bsdgames has a few support utilities
that are run during build. Its build system does not properly
differentiate these tools for use with different compilers.

Please consider applying the attached patch to improve the compiler
choice nonetheless.

Helmut
diff --minimal -Nru bsdgames-2.17/debian/changelog 
bsdgames-2.17/debian/changelog
--- bsdgames-2.17/debian/changelog  2017-11-01 17:37:54.0 +0100
+++ bsdgames-2.17/debian/changelog  2018-04-26 19:37:43.0 +0200
@@ -1,3 +1,11 @@
+bsdgames (2.17-26.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use user supplied CC/CXX with sane defaults for cross compilation.
+(Closes: #-1)
+
+ -- Helmut Grohne   Thu, 26 Apr 2018 19:37:43 +0200
+
 bsdgames (2.17-26) unstable; urgency=medium
 
   * Fix FTBFS with libncurses6.
diff --minimal -Nru bsdgames-2.17/debian/rules bsdgames-2.17/debian/rules
--- bsdgames-2.17/debian/rules  2016-04-05 10:27:54.0 +0200
+++ bsdgames-2.17/debian/rules  2018-04-26 19:37:43.0 +0200
@@ -2,6 +2,9 @@
 
 # Use all hardening features
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+-include /usr/share/dpkg/buildtools.mk
+export bsd_games_cfg_cc=$(CC)
+export bsd_games_cfg_cxx=$(CXX)
 
 %:
dh $@

Bug#887155: swi-prolog FTBFS on armel/armhf/mipsel: Not enough resources: no_memory

[Benjamin Lorenz]

Dear Lev,

It seems a fix for this bug was merged into the upstream stable
repository some time ago:
https://github.com/SWI-Prolog/swipl/commit/3923765d56e5

I have an unstable i386 VM where I could reproduce these memory errors
and adding this to the patches resolves it.

Since there is still no new upstream release and to avoid the
autoremoval of this (+ a few downstream packages [1]), could you try to
create a new debian release for 7.6.4 with this patch and the one for
#893421.

With these two patches the package was successfully built with java 9 on
the VM where I previously had these memory errors.

Best,
Benjamin

[1] I'm a developer for polymake which would also be affected by the
removal since it depends on ppl which in depends on swipl.

Bug#897047: ttf-ancient-fonts: New version has non-free license

[Jeremy Bicha]

Source: ttf-ancient-fonts
Version: 2.60-1
Severity: important

It appears that sometime after January 29, 2018, (according to the
Wayback Machine) that ttf-ancient-fonts changed their license to
"personal, non-commercial use". That means that the latest version of
the fonts are no longer compliant with the DFSG and can't be
distributed in Debian main.

https://web.archive.org/web/20180129230141/http://users.teilar.gr/~g1951d/

(Click the blue arrow at the top of the page to see the next snapshot
which includes the license change.)

Thanks,
Jeremy Bicha

Bug#897020: Usage of -s is broken

[Guilhem Moulin]

Control: tag -1 pending

Hi Christian,

On Fri, 27 Apr 2018 at 10:22:55 +0200, Christian Ehrhardt wrote:
> It realizes no more options are there and then ends at
>  } else if (argv[0] && argv[1]) {
>  host = argv[0];
>  uport = [1];
>  if (pflag || sflag)
>  usage(1);
> 
> Thereby this check doesn't allow slfag/pflag along with "two arg usage"

Oops the regression was introduced in


https://salsa.debian.org/debian/netcat-openbsd/commit/2ebffb014c830e49f6fad600c59cc1b82fe356a4

following an attempt to close #861062 and allow -s/-p to specify the
destination in listen mode, rather than via non-optional parameter(s).

Thus -s and -p should be allowed when the destination is given via 2
non-optional parameters; but only if -l is unset.  Fixed in


https://salsa.debian.org/debian/netcat-openbsd/commit/338b1fa7c3db9bd791095f51325b3287330dac7d

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#828741: libdatrie patch

[Andreas Tille]

Hi,

On Fri, Apr 27, 2018 at 01:18:58PM +0200, Filip Pytloun wrote:
> yes, I am waiting for onovy to sponsor the package. 

Ondřej, I hope you are fine if I just did the upload.  I think there is
no real need to wait any longer.  Hopefully you do not have any pending
changes.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#897045: RFS: libgpg-error/1.29-4~bpo9+1

[Jacob Adams]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "libgpg-error"

 * Package name: libgpg-error
   Version : 1.29-4~bpo9+1
   Upstream Author : GnuPG developers 
 * URL : https://www.gnupg.org/software/libgpg-error/index.html
 * License : LGPL-2.1+
   Section : libs

  It builds those binary packages:

gpgrt-tools - GnuPG development runtime library (executable tools)
 libgpg-error-dev - GnuPG development runtime library (developer tools)
 libgpg-error-mingw-w64-dev - library of error values and messages in
GnuPG (Windows developmen
 libgpg-error0 - GnuPG development runtime library
 libgpg-error0-udeb - library for common error values and messages in
GnuPG components (udeb)

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

  https://mentors.debian.net/package/libgpg-error


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

dget -x
https://mentors.debian.net/debian/pool/main/libg/libgpg-error/libgpg-error_1.29-4~bpo9+1.dsc

  Changes since the last upload:

libgpg-error (1.29-4~bpo9+1) stretch-backports; urgency=medium

  * Rebuild for stretch-backports.

 -- Jacob Adams   Tue, 24 Apr 2018 14:47:15 -0400

This package is a dependency for libgpgme which I would like to backport
for my GSoC 2018 project. I will file an RFS for libgpgme once the
latest version migrates to testing.



signature.asc
Description: OpenPGP digital signature

Bug#897046: RFS: link-grammar/5.4.4-1 [QA upload]

[Fabian Wolff]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a QA upload of the link-grammar
package.

My changes are summarized in the latest changelog entry:

  link-grammar (5.4.4-1) unstable; urgency=medium

* QA upload.
* New upstream release.
* Update symbols file.
* Remove trailing whitespace from debian/changelog in order to
  silence the file-contains-trailing-whitespace Lintian tag.
* Upgrade to debhelper compat version 11.
* Remove the empty file debian/patches/series.
* Use HTTPS URI in debian/watch.
* Upgrade to Standards-Version 4.1.4 (no changes).
* Add debian/python3-link-grammar.lintian-overrides to override the
  python-package-depends-on-package-from-other-python-variant
  Lintian tag.
* Update Vcs-Browser and Vcs-Git fields in debian/control.
* Update Homepage field in debian/control and Source field in
  debian/copyright to use HTTPS.
* Remove incorrect Multi-Arch fields in debian/control.

   -- Fabian Wolff   Fri, 27 Apr 2018 15:35:36 +0200


I have to admit that I'm not entirely sure about the Multi-Arch fields
that I removed. The link-grammar binary package installs an
architecture-dependent binary into /usr/bin, but it was marked
Multi-Arch: foreign, which looked suspect to me. Also, the
liblink-grammar-java package seems to have an incorrect Multi-Arch
field according to the Multiarch hinter:

  https://tracker.debian.org/pkg/link-grammar

Other than that, I made sure that the autopkgtests pass and that the
package is mostly Lintian-clean, save for several
package-has-unnecessary-activation-of-ldconfig-trigger warnings
(which, according to the Lintian tag documentation, might be due to a
debhelper bug) and an orig-tarball-missing-upstream-signature warning
(which I would blame on git-buildpackage, see #872864).

The package is available on Mentors:

  https://mentors.debian.net/package/link-grammar

Thank you!

Best regards,
Fabian

Bug#874146: FTBFS with Java 9: all tests fail

[Chris Lamb]

Chris Lamb wrote:

> Patch attached.

I intend to NMU this package. May I be granted access to ruby-team
on salsa.debian.org so I can push my changes and, if you wish,
"Team upload" instead? I have requested access on salsa.debian.org
itself.

I will update/refresh the packaging at the same time.


Regards,

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

Bug#897044: texinfo manual should be packaged

[Sébastien Villemot]

Package: cl-babel
Version: 20171213.git546fa82-1
Severity: wishlist

The texinfo manual should be packaged (in HTML, PDF and Info formats) and
registered into doc-base.

This first requires texinfo-docstrings to be packaged in Debian.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#897043: autopkgtest should exercise testsuite

[Sébastien Villemot]

Package: cl-babel
Version: 20171213.git546fa82-1
Severity: wishlist

The autopkgtest currently only loads the ASDF systems (babel and babel-streams).

It should also exercise the testsuite in the babel-tests system, but this first
requires hu.dwim.stefil to be packaged.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#895836: flex: Upgrading from 2.6.1-1.3 to 2.6.4-6 breaks apache module loading

[Adrian Bunk]

Control: reassign -1 libapache2-mod-auth-gssapi 1.6.0-1
Control: libapache2-mod-auth-gssapi is broken if libfl-dev is installed during 
the build

On Mon, Apr 16, 2018 at 01:14:48PM -0400, Robbie Harwood wrote:
> Package: flex
> Version: 2.6.4-6
> Severity: important
> 
> Dear Maintainer,
> 
> After upgrading the version of flex, mod_auth_gssapi (in Debian,
> libapache2-mod-auth-gssapi) can no longer be used.  In particular,
> apache fails with:
> 
> apache2: Syntax error on line 78 of 
> /root/mod_auth_gssapi/testsdir/httpd/httpd.conf: Cannot load 
> ./mod_auth_gssapi.so into server: /usr/lib/x86_64-linux-gnu/libfl.so.2: 
> undefined symbol: yylex

This is actually a bug in libapache2-mod-auth-gssapi, and it is only 
present when building the package with libfl-dev installed (which is
not during the build of the package in the archive).

The following line is wrong and should be removed:
https://sources.debian.org/src/libapache2-mod-auth-gssapi/1.6.0-1/src/Makefile.am/#L24

libfl has the uncommon property of being a library that expects a symbol 
provided from elsewhere.

This can make unnecessary linking harmful.

Static linking works since unused objects are discarded by the linker,
but this is not true for a shared library (might work with --as-needed).

For linking into programs or libraries the linker gives an error,
but for plugins this fails during loading.

> Thanks!

cu
Adrian

-- 

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

Bug#897042: pound: Enable sending the certificate in a single header line

[Claudio Nieder]

Package: pound
Version: 2.7-1.3

When pound listens on an https connection it will forward client certificate in 
the X-SSL-certificate header. By default it will transfer the certificate in 
multiple lines as was allowed historically in http.

RFC7230 deprecates this behaviour and more and more http servers reject 
requests with such headers and return a 400 Bad Request error message.

As discussed in the pound mailing list 
(http://www.apsis.ch/pound/pound_list/archive/2018/2018-04/1524178583000#1524337674000)
 pound is capable to send the X-SSL-certificate in a single line and thus 
conform to the RFC by compiling it using the --enable-cert1l option on 
configure. But one must specify this option, it is not the default.

To conform to RFC7230 the pound package should be rebuilt using the 
—enable-cert1l option when doing the configure step.

Thank you very much,
claudio
-- 
Claudio Nieder, Ruhestrasse 7, CH-8045 Zürich, Tel +4179 357 6743, 
www.claudio.ch

Bug#883180: help with zlib package ?

[Mark Brown]

> On 27 Apr 2018, at 14:03, Jérémy Lal  wrote:
> 
> Not directly related, but kind of a bug
> please fix your email address broo...@debian.org: it isn't working.

I seem to get a reasonable amount of mail there and the test mail I just sent 
to myself arrived fine... whatever problem you believe exists you’ll have to 
tell me what it is. 

> 
> Jérémy 
> 

Bug#897041: FTBFS: mismatch with heist

[Clint Adams]

Source: haskell-snap
Version: 1.0.0.2-2
Severity: serious

Unfortunately, heist got ahead, so one solution is to patch snap for
newer heist.

Bug#883180: help with zlib package ?

[Jérémy Lal]

Not directly related, but kind of a bug
please fix your email address broo...@debian.org: it isn't working.

Jérémy