Bug#904797: test suite example package should build both any and all packages

[Ian Jackson]

Package: dgit
Version: 6.0
Severity: wishlist

This will involve g-f-b on the example git repo and probably messing
with some of the built soure package artefacts.

And it will probably make some tests fail.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#893302: lwjgl FTBFS with openjdk-9

[Emmanuel Bourg]

Control: reopen -1
Control: severity -1 important

I'm reopening the bug because ultimately this issue will have to be
fixed, but I'm lowering the severity to prevent the autoremoval.

Bug#846006: debian-cd: please provide flavor/spin netinst image for Debian Edu

[Wolfgang Schweer]

On Sat, Jul 28, 2018 at 03:17:02AM +0100, Steve McIntyre wrote:
> >This file seems to be missing some packages:
> >
> >https://salsa.debian.org/images-team/debian-cd/blob/b8045bd73ba44af23a6df3f7cf46a00a0b1d/tasks/buster/debian-edu
> >
> >IMO at least these udebs should be added
> >debian-edu-profile-udeb
> >ltsp-client-builder
> 
> ACK. Just added them back now. In discussion with Holger yesterday, we
> thought it was best to start with a small set and build up to what's
> needed.

Congratulations! Good progress with the latest ISO image.
IMO these packages need to be added as well:
exim4-daemon-heavy (sure)
sudo-ldap (most probably)

Wolfgang


signature.asc
Description: PGP signature

Bug#846006: debian-cd: please provide flavor/spin netinst image for Debian Edu

[Steve McIntyre]

On Sat, Jul 28, 2018 at 03:20:58AM +0100, Steve McIntyre wrote:
>On Fri, Jul 27, 2018 at 06:24:06PM +0200, Wolfgang Schweer wrote:
>>On Fri, Jul 27, 2018 at 06:14:22PM +0200, Wolfgang Schweer wrote:
>>> IMO at least these udebs should be added
>>> debian-edu-profile-udeb
>>> ltsp-client-builder
>>
>>Maybe consider as well:
>>udebs are missing on the ISO (even the debian-edu-install-udeb), also 
>>the kernel param 'desktop=xfce' (CONF.sh has a variable for it).
>>Maybe also the kernel param 'modules=debian-edu-install-udeb' is 
>>required.
>
>OK, I'll take a look. I've explicitly added "desktop=xfce" at build
>time, but it hasn't worked. I'll check that too.

New build in place now at the same URL, which looks much better to
me. Please take a look?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra

Bug#904798: chromium: Chromium failed to upgrade

[Remi Vanicat]

Package: chromium
Version: 68.0.3440.75-1~deb9u1
Severity: important

Upgrading chromium on a sid box failed :

  dpkg: erreur de traitement de l'archive 
/tmp/apt-dpkg-install-1RxXoY/23-chromium_68.0.3440.75-1~deb9u1_amd64.deb 
(--unpack) :
   tentative de remplacement de « /usr/lib/chromium/natives_blob.bin », qui 
appartient aussi au paquet chromium-common 67.0.3396.87-1
  dpkg-deb: erreur: coller subprocess was killed by signal (Relais brisé (pipe))

(in English: chromium_68.0.3440.75-1 try to replace
/usr/lib/chromium/natives_blob.bin that is also in chromium-common
67.0.3396.87-1)

Forcing the purge of chromium-common solve the problem for me,
chromium should probably conflict with it.

Thanks,
Rémi.

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

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

Versions of packages chromium depends on:
ii  libasound2   1.1.6-1
ii  libatk1.0-0  2.28.1-1
ii  libatomic1   8.1.0-12
ii  libavcodec57 7:3.4.3-1
ii  libavformat577:3.4.3-1
ii  libavutil55  7:3.4.3-1
ii  libc62.27-5
ii  libcairo21.15.10-3
ii  libcups2 2.2.8-5
ii  libdbus-1-3  1.12.8-3
ii  libdrm2  2.4.92-1
iu  libevent-2.0-5   2.0.21-stable-3
ii  libexpat12.2.5-3
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8.1.0-12
iu  libgdk-pixbuf2.0-0   2.36.12-1
ii  libglib2.0-0 2.56.1-2
ii  libgtk2.0-0  2.24.32-2
ii  libicu57 57.1-9
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.19-3
ii  libnss3  2:3.38-1
ii  libopenjp2-7 2.3.0-1
ii  libopus0 1.3~beta+20180518-1
ii  libpango-1.0-0   1.42.1-2
ii  libpangocairo-1.0-0  1.42.1-2
ii  libpangoft2-1.0-01.42.1-2
ii  libpci3  1:3.5.2-1
ii  libpng16-16  1.6.34-2
ii  libpulse011.1-5
iu  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.1.0-12
iu  libvpx4  1.6.1-3+deb9u1
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
iu  libwebpmux2  0.5.2-1
ii  libx11-6 2:1.6.5-1
ii  libx11-xcb1  2:1.6.5-1
ii  libxcb1  1.13-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-1
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2
ii  libxss1  1:1.2.2-1+b2
ii  libxtst6 2:1.2.3-1
ii  x11-utils7.7+4
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-7
ii  libgl1-mesa-dri   18.1.4-1

Versions of packages chromium suggests:
iu  chromium-driver68.0.3440.75-1~deb9u1
iu  chromium-l10n  68.0.3440.75-1~deb9u1
iu  chromium-shell 68.0.3440.75-1~deb9u1
pn  chromium-widevine  

-- no debconf information

Bug#846006: debian-cd: please provide flavor/spin netinst image for Debian Edu

[Holger Levsen]

On Sat, Jul 28, 2018 at 09:05:14AM +0200, Wolfgang Schweer wrote:
> Congratulations! Good progress with the latest ISO image.

yay! good the edu profile question?

> IMO these packages need to be added as well:

why?

> exim4-daemon-heavy (sure)
> sudo-ldap (most probably)

& thanks for testing!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#712426: /usr/bin/dh_sphinxdoc: dh_sphinxdoc: fails with "unknown JavaScript code"

[Hideki Yamane]

Hi,

On Sat, 15 Jun 2013 14:26:26 -0700 Nikolaus Rath  wrote:
> For the s3ql-beta package (not yet uploaded), dh_sphinxdoc fails with:
> 
>dh_installdocs
>   dh_sphinxdoc
>   dh_sphinxdoc: error: unknown JavaScript code:
>   debian/s3ql-beta/usr/share/doc/s3ql-beta/html/_static/jquery.js
>   make: *** [binary] Error 255

 Now I'm trying to update debian-policy package, and got same error.

> make[1]: Leaving directory '/build/debian-policy-4.1.6.0'
>dh_installdocs   
>dh_sphinxdoc   
>   
>  
> dh_sphinxdoc: error: unknown JavaScript code: 
> debian/debian-policy/usr/share/doc/debian-policy/policy.html/_static/searchtools.js
> 
> make: *** [debian/rules:4: binary] Error 255
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
> exit status 2
> I: copying local configuration
> E: Failed autobuilding of package

 The reason why I got this is I used "sphinx-build -b html", instead of
 broken "sphinx-build -M html". -b option works correctly, and now I got
 error.

 It's debian/rules file is very simple

> #!/usr/bin/make -f
> 
> %:
> dh $@ --with sphinxdoc

 Could you give me a suggestion, please?


-- 
Hideki Yamane 

Bug#904801: libmspack: libmspack now rejects blank CHM filenames

[Salvatore Bonaccorso]

Source: libmspack
Version: 0.5-1
Severity: important
Tags: patch security upstream

Cf. http://www.openwall.com/lists/oss-security/2018/07/26/1

https://github.com/kyz/libmspack/commit/72e70a921f0f07fee748aec2274b30784e1d312a

Regards,
Salvatore

Bug#904802: libmspack: off-by-one error in CHM PMGI/PMGL chunk number validity checks

[Salvatore Bonaccorso]

Source: libmspack
Version: 0.5-1
Severity: important
Tags: patch security upstream

Cf. http://www.openwall.com/lists/oss-security/2018/07/26/1

https://github.com/kyz/libmspack/commit/72e70a921f0f07fee748aec2274b30784e1d312a

Regards,
Salvatore

Bug#904800: libmspack: Fix off-by-one error in chmd TOLOWER() fallback

[Salvatore Bonaccorso]

Source: libmspack
Version: 0.5-1
Severity: important
Tags: patch security upstream

http://www.openwall.com/lists/oss-security/2018/07/26/1

https://github.com/kyz/libmspack/commit/4fd9ccaa54e1aebde1e4b95fb0163b699fd7bcc8

Regards,
Salvatore

Bug#904799: libmspack: kwaj_read_headers(): fix handling of non-terminated strings

[Salvatore Bonaccorso]

Source: libmspack
Version: 0.5-1
Severity: important
Tags: patch security upstream

Cf. http://www.openwall.com/lists/oss-security/2018/07/26/1

https://github.com/kyz/libmspack/commit/0b0ef9344255ff5acfac6b7af09198ac9c9756c8

Filling as individual bugs as no CVEs are yet assigned.

Regards,
Salvatore

Bug#904803: pugixml: please update to new version 1.9

[Gianfranco Costamagna]

Source: pugixml

Severity: wishlist

Version: 1.8.1-7


Please update to version 1.9, it is needed for the new poedit (I relaxed the 
dependency constraint,

but I'm really unsure about what does it might break!)


I can NMU if necessary,


(it would also be nice to fix the wchar bug in this upload)



I took the liberty to push on salsa.d.o the changes I did, with some (hopefully 
appreciated) polishing

of the packaging, such as fixing lintian warnings, and updating versions (and 
use https/new VCS fields)


* Non-maintainer upload (Closes: #-1)

* Move vcs to salsa.d.o

* Drop duplicated "section" libs

* Bump std-version to 4.1.5, no changes required

* New upstream release

* Patch refresh

* Update copyright file


let me know if I can push the package!

I'm doing a test build here

http://debomatic-amd64.debian.net/distribution#unstable/pugixml/1.9-0.1/buildlog



thanks!



G.

Bug#904785: python-xarray autopkg tests fail on arm64

[Graham Inggs]

Control: user debian...@lists.debian.org
Control: usertags -1 regression

On 28 July 2018 at 04:43, Matthias Klose  wrote:
> the python-xarray autopkg tests fail on arm64, as seen in
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/arm64/p/python-xarray/20180728_004139_2ff97@/log.gz
>
> I assume you can reproduce these when building the package on an arm64 porter 
> box.

These tests only started to fail with the upload of python-array
0.10.2-1.  Previously, the NetCDF tests were not run.

The same failures occur on armhf, and I believe the cause is different
NaN behaviour on x86 and ARM CPUs [1].

If the problem isn't in python-xarray itself, perhaps the solution is
just to skip these failing tests on ARM.

[1] https://github.com/numpy/numpy/issues/8325

Bug#904804: debootstrap: Unable to deboostrap a sid environment on stretch

[Nicolas Braud-Santoni]

Package: debootstrap
Version: 1.0.89
Severity: important
Control: tag -1 + sid stretch

Hi,

I just realised it's currently impossible to debootstrap a sid (build)
environment on Debian stretch, creating difficulties for attendees of the
DebConf packaging workshop, presumably because of util-linux being
uninstallable.

Please find included the build log; the exact debootstrap invocation was:
  sudo debootstrap sid /tmp/debootstrap http://localhost:3142/debian

(localhost:3142 being a freshly-initialized apt-cacher)


Best,

  nicoo

PS: Apologies if this is assigned to the wrong package, I was unsure whether to
assign it to debootstrap or util-linux.
gpgv: Signature made Sat 28 Jul 2018 02:26:40 AM GMT
gpgv:using RSA key A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553
gpgv: Good signature from "Debian Archive Automatic Signing Key (7.0/wheezy) 
"
gpgv: Signature made Sat 28 Jul 2018 02:26:41 AM GMT
gpgv:using RSA key 126C0D24BD8A2942CC7DF8AC7638D0442B90D010
gpgv: Good signature from "Debian Archive Automatic Signing Key (8/jessie) 
"
gpgv: Signature made Sat 28 Jul 2018 02:26:41 AM GMT
gpgv:using RSA key 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC
gpgv: Good signature from "Debian Archive Automatic Signing Key (9/stretch) 
"
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing architecture
Selecting previously unselected package base-passwd.
(Reading database ... 0 files and directories currently installed.)
Preparing to unpack .../base-passwd_3.5.45_amd64.deb ...
Unpacking base-passwd (3.5.45) ...
dpkg: base-passwd: dependency problems, but configuring anyway as you requested:
 base-passwd depends on libc6 (>= 2.8); however:
  Package libc6 is not installed.
 base-passwd depends on libdebconfclient0 (>= 0.145); however:
  Package libdebconfclient0 is not installed.

Setting up base-passwd (3.5.45) ...
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 24 package 'dpkg':
 missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 24 package 'dpkg':
 missing architecture
Selecting previously unselected package base-files.
dpkg: regarding .../base-files_10.1_amd64.deb containing base-files, 
pre-dependency problem:
 base-files pre-depends on awk
  awk is not installed.

dpkg: warning: ignoring pre-dependency problem!
(Reading database ... 41 files and directories currently installed.)
Preparing to unpack .../base-files_10.1_amd64.deb ...
Unpacking base-files (10.1) ...
dpkg: base-files: dependency problems, but configuring anyway as you requested:
 base-files depends on awk; however:
  Package awk is not installed.

Setting up base-files (10.1) ...
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 51 package 'dpkg':
 missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 51 package 'dpkg':
 missing architecture
dpkg: regarding .../dpkg_1.19.0.5+b1_amd64.deb containing dpkg, pre-dependency 
problem:
 dpkg pre-depends on libbz2-1.0
  libbz2-1.0 is not installed.

dpkg: warning: ignoring pre-dependency problem!
dpkg: regarding .../dpkg_1.19.0.5+b1_amd64.deb containing dpkg, pre-dependency 
problem:
 dpkg pre-depends on libc6 (>= 2.14)
  libc6 is not installed.

dpkg: warning: ignoring pre-dependency problem!
dpkg: regarding .../dpkg_1.19.0.5+b1_amd64.deb containing dpkg, pre-dependency 
problem:
 dpkg pre-depends on liblzma5 (>= 5.2.2)
  liblzma5 is not installed.

dpkg: warning: ignoring pre-dependency problem!
dpkg: regarding .../dpkg_1.19.0.5+b1_amd64.deb containing dpkg, pre-dependency 
problem:
 dpkg pre-depends on libselinux1 (>= 2.3)
  libselinux1 is not installed.

dpkg: warning: ignoring pre-dependency problem!
dpkg: regarding .../dpkg_1.19.0.5+b1_amd64.deb containing dpkg, pre-dependency 
problem:
 dpkg pre-depends on zlib1g (>= 1:1.1.4)
  zlib1g is not installed.

dpkg: warning: ignoring pre-dependency problem!
(Reading database ... 121 files and directories currently installed.)
Preparing to unpack .../dpkg_1.19.0.5+b1_amd64.deb ...
Unpacking dpkg (1.19.0.5+b1) over (1.19.0.5+b1) ...
dpkg: dpkg: dependency problems, but configuring anyway as you requested:
 dpkg depends on libbz2-1.0; however:
  Package libbz2-1.0 is not installed.
 dpkg depends on libc6 (>= 2.14); however:
  Package libc6 is not installed.
 dpkg depends on liblzma5 (>= 5.2.2); however:
  Package liblzma5 is not installed.
 dpkg depends on libselinux1 (>= 2.3); however:
  Package libselinux1 is not installed.
 dpkg depends on zlib1g (>= 1:1.1.4); however:
  Package zlib1g is not installed.
 dpkg depends on tar (>= 1.28-1); however:
  Package tar is not installed.

Setting up dpkg (1.19.0.5+b1) ...
Selecting previously unselected package libc6:amd64.
(Reading database ... 371 files and directories currently installed.)
Preparing to unpack .../libc6_2.27-5_amd64.deb ...
Unpacking libc6:amd64 (

Bug#904805: emacs-goodies-el: drop button-lock.el, wiki-nav.el

[David Bremner]

Package: emacs-goodies-el
Version: 39.0
Severity: normal

I started packaging button-lock, but the latest upstream (from 2015) doesn't 
byte-compile

╭─ rocinante:software/debian/emacsen-team/button-lock 
╰─ (git)-[master]-% make   
/etc/alternatives/emacs -Q --batch --eval\
"(progn\
  (setq byte-compile-error-on-warn t)  \
  (batch-byte-compile))" *.el

In toplevel form:
button-lock.el:492:14:Error: ‘font-lock-fontify-buffer’ is for interactive use 
only; use ‘font-lock-ensure’ or ‘font-lock-flush’ instead.

In toplevel form:
wiki-nav.el:785:14:Error: ‘font-lock-fontify-buffer’ is for interactive use 
only; use ‘font-lock-ensure’ or ‘font-lock-flush’ instead.
make: *** [Makefile:45: build] Error 1

I guess that's not too hard to fix, but the fact that it's still open
after 3 years is offputting. The warning that triggers this failure is
at least that old.

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

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

Versions of packages emacs-goodies-el depends on:
ii  bash 4.4.18-3.1
ii  dpkg 1.19.0.5+b1
ii  emacs1:25.2+1-7
ii  emacs-gtk [emacsen]  1:25.2+1-7
ii  emacsen-common   3.0.0
ii  install-info 6.5.0.dfsg.1-4

Versions of packages emacs-goodies-el recommends:
ii  elpa-browse-kill-ring   2.0.0-1
ii  elpa-debian-el  37.0
ii  elpa-diminish   0.45-2
ii  elpa-dpkg-dev-el37.0
ii  elpa-graphviz-dot-mode  0.4+41+gc456a2b-1
ii  elpa-htmlize1.53-1
ii  elpa-markdown-mode  2.3+154-1
ii  perl-doc5.26.2-6
ii  wget1.19.5-1

emacs-goodies-el suggests no packages.

-- no debconf information

Bug#871835: speed up for debootstrap

[Hideki Yamane]

On Fri, 27 Jul 2018 11:25:40 +0200
Cyril Brulebois  wrote:
> For some reason it seems I didn't follow up to this bug report but I'm
> pretty sure I did reply on debian-boot@ in some way: we need automated
> tests before and after those patches. And we need to make sure they
> yield the exact same results. Please don't merge the whole stack of
> patches without such checks.

 I heard about Thomas has set his test system and works well.
 It'd be better to share its info, then.


-- 
Hideki Yamane 

Bug#904806: emacs-goodies-el: drop ascii.el

[David Bremner]

Package: emacs-goodies-el
Version: 39.0
Severity: normal

There's no upstream other than emacswiki. Melpa is not providing these
packages any more and we should not either.

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

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

Versions of packages emacs-goodies-el depends on:
ii  bash 4.4.18-3.1
ii  dpkg 1.19.0.5+b1
ii  emacs1:25.2+1-7
ii  emacs-gtk [emacsen]  1:25.2+1-7
ii  emacsen-common   3.0.0
ii  install-info 6.5.0.dfsg.1-4

Versions of packages emacs-goodies-el recommends:
ii  elpa-browse-kill-ring   2.0.0-1
ii  elpa-debian-el  37.0
ii  elpa-diminish   0.45-2
ii  elpa-dpkg-dev-el37.0
ii  elpa-graphviz-dot-mode  0.4+41+gc456a2b-1
ii  elpa-htmlize1.53-1
ii  elpa-markdown-mode  2.3+154-1
ii  perl-doc5.26.2-6
ii  wget1.19.5-1

emacs-goodies-el suggests no packages.

-- no debconf information

Bug#904807: josm: chinese fonts in editor

[Ralf Treinen]

Package: josm
Version: 0.0.svn14026+dfsg-1
Severity: normal

Hi,

Chinese characters are for me not usable in josm, they appear just
as a box. I suppose that these are traditional chinese characters
since I try to edit a map in Taiwan. For instance, the name
of the object 

https://www.openstreetmap.org/way/340655083

appears for me in josm, both in the map pane and in the editor windows,
only as boxes. However, the selector tool for downloading a portion
of a map indicates the names in chinese characters, as does the map
rendering in firefox. I basically know nothing about CJK stuff so I
just installed task-chinese-t but this didn't help.

-Ralf.

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

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

Versions of packages josm depends on:
ii  default-jre [java9-runtime] 2:1.10-67
ii  fonts-noto  20171026-2
ii  jmapviewer  2.7+dfsg-2
ii  libcommons-compress-java1.17-1
ii  libcommons-logging-java 1.2-2
ii  libgettext-commons-java 0.9.6-6
ii  liboauth-signpost-java  1.2.1.2-1.5
ii  libsvgsalamander-java   1.1.1+dfsg-2
ii  openjdk-10-jre [java9-runtime]  10.0.2+13-1
ii  proj-data   5.1.0-1

Versions of packages josm recommends:
ii  josm-l10n  0.0.svn14026+dfsg-1

josm suggests no packages.

-- no debconf information

Bug#891872: transition: curl

[Emilio Pozuelo Monfort]

On 25/07/18 22:01, Sebastian Andrzej Siewior wrote:
> On 2018-07-25 10:47:50 [+0200], Emilio Pozuelo Monfort wrote:
>>> Any suggestions from the D-Science folks?
>>
>> Maybe send this to the scilab bug rather than the curl transition one?
> 
> I Cced the scilab folks. I was more interrested in the release team's
> opinion if it is worth fixing those and get it built in order to
> complete the curl transition or if it does not make sense (to fix only
> one of those RC bugs) and breaking the package (i.e. removing libcurl3
> from unstable) would be an option.

We never break packages in testing (unless it's a critical situation, and this
obviously isn't). Also the cruft package in unstable doesn't hurt much, so it
can be left around for a while longer. What we want to do here is to get rid of
the old library in testing in order to finish the transition there: the only two
options for that are to remove scilab or to fix it. Given it's a key package and
probably has rdeps that'd mean the latter.

Cheers,
Emilio

Bug#904808: libcap-ng0: libcap-ng's use of pthread_atfork causes segfaults

[Stefan Fritsch]

Package: libcap-ng0
Version: 0.7.9-1
Severity: grave
Justification: renders package unusable

Hi,

apache httpd loads and unloads modules during a reload of the server
configuration. This causes the pthread_atfork entry that is installed by
libcap-ng0 to point to code that is no longer in the process, causing a
segfault at the next fork.

See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902657

There is already an upstream bug report about this:

https://github.com/stevegrubb/libcap-ng/issues/5

Since there is no interface to undo a pthread_atfork() call, there is no
way a shared library can call pthread_atfork() in a safe way. libcap-ng0
should not do it.

Cheers,
Stefan

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

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

Versions of packages libcap-ng0 depends on:
ii  libc6  2.27-5

libcap-ng0 recommends no packages.

libcap-ng0 suggests no packages.

-- no debconf information

Bug#904804: debootstrap: Unable to deboostrap a sid environment on stretch

[Hideki Yamane]

control: reassign -1 util-linux

Hi,

On Sat, 28 Jul 2018 15:47:39 +0800
Nicolas Braud-Santoni  wrote:
> I just realised it's currently impossible to debootstrap a sid (build)
> environment on Debian stretch, creating difficulties for attendees of the
> DebConf packaging workshop, presumably because of util-linux being
> uninstallable.

 I confirmed it with current debootstrap on sid, but it's not
 debootstrap's fault but it's in repo.

>>  login (1:4.5-1.1) breaks util-linux (<< 2.32-0.2~) and is installed.

> shadow (1:4.5-1.1) unstable; urgency=medium
> 
>   * Non-maintainer upload (greetings from DebCamp/DebConf Taiwan).
>   * Stop shipping su and break old util-linux version. (See #833256)
> - Breaks on old version to force lockstep upgrade, which should
>   really be a depends-new-version (and can be switched around
>   together with util-linux once the transition is finished).
>   Using Breaks/Depends the 'wrong' way around is to make apt
>   unpack things in the 'right' order (avoiding any gaps where
>   /bin/su is not available during the upgrade phase).
> 
>  -- Andreas Henriksson   Fri, 27 Jul 2018 10:07:37 +0200

 However, util-linux is (2.32-0.1). I'm not sure which side should care
 about it, but once reassign to util-linux.
  
 
-- 
Hideki Yamane 

Bug#846006: debian-cd: please provide flavor/spin netinst image for Debian Edu

[Wolfgang Schweer]

On Sat, Jul 28, 2018 at 07:18:14AM +, Holger Levsen wrote:
> On Sat, Jul 28, 2018 at 09:05:14AM +0200, Wolfgang Schweer wrote:
> > Congratulations! Good progress with the latest ISO image.
> 
> yay! good the edu profile question?

yes.
 
> > IMO these packages need to be added as well:
> 
> why?
> 
> > exim4-daemon-heavy (sure)
> > sudo-ldap (most probably)

the base system installation fails due to missing exim4-daemon-heavy on 
the ISO image (expected, because it's non-standard but required for 
edu).

iirc sudo-ldap needs to be there to prevent the simple sudo 
(standard) to get installed.

keep on going :)
I'll test the ISO image if time permits.

Wolfgang


signature.asc
Description: PGP signature

Bug#904777: transition: libraw

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 27/07/18 23:05, Matteo F. Vescovi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> I'm filing this bug for a new transition of libraw package.
> 
> On June 29, 2018 the 0.19.0 stable version has been released by
> upstream.
> 
> On July 23 and 26, 2018 a couple of testing-purpose packages has been
> uploaded to experimental, the first as first attempt to check the
> packaging on all architectures, the latter to fix a bunch of FTBFS due
> to C++ symbols.
> 
> So, following the auto-libraw checklist[1], here is the list of source
> packages reverse-depending on libraw and the results of the builds:
> 
>  * deepin-image-viewer_1.2.23-1 => OK
>  * efl_1.20.7-6 => OK
>  * entangle_0.7.2-1 => OK
>  * fotoxx_18.01.1-2 => OK
>  * freeimage_3.17.0+ds1-5 => OK
>  * gegl_0.4.2-1 => OK
>  * gthumb_3:3.6.1-1 => OK
>  * krita_1:4.1.1+dfsg-1 => FTBFS
>  * kstars_5:2.9.6-1 => FTBFS
>  * libkf5kdcraw_17.08.3-1 => FTBFS
>  * luminance-hdr_2.5.1+dfsg-3 => OK
>  * nomacs_3.10.2+dfsg-1 => OK
>  * openimageio_1.8.12~dfsg0-1 => OK
>  * shotwell_0.28.3-1 => OK
>  * siril_0.9.9-1 => OK
> 
> All the FTBFS (3) are caused by some changes in libraw 0.19.0 compared
> to older 0.18.xx version.

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

Cheers,
Emilio

Bug#903853: transition: removal of nepomuk support from src:kde4libs

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 15/07/18 22:33, Pino Toscano wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> I'd like to remove the support for Nepomuk in src:kde4libs.
> 
> Since Nepomuk has been deprecated, and already unused in Debian for
> quite some time, this allows us to drop src:soprano &
> src:shared-desktop-ontologies. The result is the drop of 3 library
> packages from src:kde4libs: libnepomuk4, libnepomukquery4a, and
> libnepomukutils4.
> 
> The reason of this transition is that libnepomuk was so far listed as
> public library dependency for the kde4 versions of kio (libkio5), and
> kparts (libkparts4), resulting in overlinking. Fortunately, almost all
> the packages either already link in as-needed more, or switched to KDE
> Frameworks 5. The only exception is src:kpartsplugin.
> 
> Hence, the plan is the following:
> 1) upload src:kde4libs without Nepomuk support
> 2) binNMU src:kpartsplugin
> 
> I verified that src:kpartsplugin builds fine even without Nepomuk
> libraries, effectively not linking against them anymore. I also did
> a rebuild of all the other sources still using kdelibs 4.x, and there
> were no changes in their build.
> 
> PS: since I uploaded kde4libs 4:4.14.38-1 yesterday, I'd wait for it to
> migrate to testing, first.

Please go ahead.

Cheers,
Emilio

Bug#904809: emacs-goodies-el: drop color-theme.el

[David Bremner]

Package: emacs-goodies-el
Version: 39.0
Severity: normal

My reasoning is as follows:

- It's unmaintained since 2009
- it seems to have no rdeps in Debian
- it has few rdeps in Melpa.

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

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

Versions of packages emacs-goodies-el depends on:
ii  bash 4.4.18-3.1
ii  dpkg 1.19.0.5+b1
ii  emacs1:25.2+1-7
ii  emacs-gtk [emacsen]  1:25.2+1-7
ii  emacsen-common   3.0.0
ii  install-info 6.5.0.dfsg.1-4

Versions of packages emacs-goodies-el recommends:
ii  elpa-browse-kill-ring   2.0.0-1
ii  elpa-debian-el  37.0
ii  elpa-diminish   0.45-2
ii  elpa-dpkg-dev-el37.0
ii  elpa-graphviz-dot-mode  0.4+41+gc456a2b-1
ii  elpa-htmlize1.53-1
ii  elpa-markdown-mode  2.3+154-1
ii  perl-doc5.26.2-6
ii  wget1.19.5-1

emacs-goodies-el suggests no packages.

-- no debconf information

Bug#902657: Segfault is caused by libcap-ng0 0.7.9

[Stefan Fritsch]

retitle 902657 graceful/restart results in segfault if libcap-ng0 is loaded
severity 902657 important
block 902657 by 904808
thanks

The problem is caused by  libcap-ng0 0.7.9 . This is usually pulled in by php 
extensions. There is nothing apache can do.

Unfortunately, downgrading to 0.7.7 from stretch is not possible due to 
dependencies.

Bug#904774: stretch-pu: package sympa/6.2.16~dfsg-3+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2018-07-27 at 20:20 +0200, Salvatore Bonaccorso wrote:
> Sympa in stable is affected by 863631, where on every update of
> sympa, the values reinjectend to sympa config file were false doe to
> an issue in the shell function used to prefill the debconf questions.
> 
> This was earlier fixed for buster, but updates within stretch will
> still have the problem.
> 
> Now, there is a security update planned for CVE-2018-1000550 and for
> the above reason I would include the cherry picked fix for the above,
> but would like to get an official ack, given it's not for the
> security fix.

That looks fine to me, thanks.

Regards,

Adam

Bug#904810: emacs-goodies-el: drop muttrc-mode.el

[David Bremner]

Package: emacs-goodies-el
Version: 39.0
Severity: normal

This is only (?) available from emacswiki. Melpa doesn't provide these
packages anymore and neither should we.

I guess it has also not been updated since 2009

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

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

Versions of packages emacs-goodies-el depends on:
ii  bash 4.4.18-3.1
ii  dpkg 1.19.0.5+b1
ii  emacs1:25.2+1-7
ii  emacs-gtk [emacsen]  1:25.2+1-7
ii  emacsen-common   3.0.0
ii  install-info 6.5.0.dfsg.1-4

Versions of packages emacs-goodies-el recommends:
ii  elpa-browse-kill-ring   2.0.0-1
ii  elpa-debian-el  37.0
ii  elpa-diminish   0.45-2
ii  elpa-dpkg-dev-el37.0
ii  elpa-graphviz-dot-mode  0.4+41+gc456a2b-1
ii  elpa-htmlize1.53-1
ii  elpa-markdown-mode  2.3+154-1
ii  perl-doc5.26.2-6
ii  wget1.19.5-1

emacs-goodies-el suggests no packages.

-- no debconf information

Bug#904199: stretch-pu: package clamav/ 0.100.0+dfsg-0+deb9u2

[Adam D. Barratt]

On Sat, 2018-07-21 at 15:02 +0200, Sebastian Andrzej Siewior wrote:
> clamav upstream published a new version which contains security
> relevant bug fixes, two of them have a CVE number assigned:
> 
> CVE-2018-0360
>   HWP integer overflow, infinite loop vulnerability. Reported by
> Secunia
>   Research at Flexera.
> 
> CVE-2018-0361
>   ClamAV PDF object length check, unreasonably long time to parse
>   relatively small file. Reported by aCaB.

Was the intent that the package would be pushed via -updates?

Regards,

Adam

Bug#904811: /usr/bin/pbuilder-dist: pbuild-dist fails when /home is in a different partition

[Helen Koike]

Package: ubuntu-dev-tools
Version: 0.165
Severity: important
File: /usr/bin/pbuilder-dist

Dear Maintainer,

I have /home in a different partition from root /, and pbuilder-dist installs 
files
under /home/user/pbuilder/ folder. Causing the following error when
trying to build a package:

ln: failed to create hard link 
'/home/koike/pbuilder/aptcache/debian/libxdamage1_1%3a1.1.4-3_amd64.deb' => 
'/var/cache/pbuilder/build/16417/var/cache/apt/archives/libxdamage1_1%3a1.1.4-3_amd64.deb':
 Invalid cross-device link

This happends because it is trying to create a hardlink between two
different partitions.

My current partitions/mouting points:

/dev/mapper/floko--vg-root /
/dev/mapper/floko--vg-home /home

How to reproduce:

mkdir tmp && cd tmp
apt source ibus-chewing debhelper
pbuilder-dist buster amd64 create
pbuilder-dist buster amd64 build ibus-chewing_1.5.1-3.dsc


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

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

Versions of packages ubuntu-dev-tools depends on:
ii  binutils   2.30-20
ii  dctrl-tools2.24-2+b1
ii  devscripts 2.18.3
ii  diffstat   1.61-1+b1
ii  distro-info0.18
ii  dpkg-dev   1.19.0.5
ii  lsb-release9.20170808
ii  perl   5.26.2-5
ii  python 2.7.15~rc1-1
ii  python-apt 1.6.0
ii  python-debian  0.1.32
ii  python-distro-info 0.18
ii  python-httplib20.9.2+dfsg-1
ii  python-launchpadlib1.10.6-1
ii  python-lazr.restfulclient  0.14.0-1
ii  python-ubuntutools 0.165
ii  sensible-utils 0.0.12
ii  sudo   1.8.23-1

Versions of packages ubuntu-dev-tools recommends:
ii  bzr 2.7.0+bzr6622-11
ii  bzr-builddeb2.8.10
ii  ca-certificates 20170717
ii  debian-archive-keyring  2017.7
ii  debian-keyring  2018.03.24
ii  debootstrap 1.0.102
ii  dput1.0.2
ii  genisoimage 9:1.1.11-3+b2
ii  libwww-perl 6.33-1
ii  lintian 2.5.88
ii  patch   2.7.6-2
ii  pbuilder0.229.3
ii  python-dns  2.3.6-4
ii  python-soappy   0.12.22-1
ii  quilt   0.65-1
ii  reportbug   7.1.10

Versions of packages ubuntu-dev-tools suggests:
ii  python 2.7.15~rc1-1
ii  python-simplejson  3.15.0-1+b1
ii  qemu-user-static   1:2.12+dfsg-1+b1

-- no debconf information

Bug#904812: emacs-goodies-el: drop miniedit.el

[David Bremner]

Package: emacs-goodies-el
Version: 39.0
Severity: normal

this package has no active upstream. last update was 2010

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

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

Versions of packages emacs-goodies-el depends on:
ii  bash 4.4.18-3.1
ii  dpkg 1.19.0.5+b1
ii  emacs1:25.2+1-7
ii  emacs-gtk [emacsen]  1:25.2+1-7
ii  emacsen-common   3.0.0
ii  install-info 6.5.0.dfsg.1-4

Versions of packages emacs-goodies-el recommends:
ii  elpa-browse-kill-ring   2.0.0-1
ii  elpa-debian-el  37.0
ii  elpa-diminish   0.45-2
ii  elpa-dpkg-dev-el37.0
ii  elpa-graphviz-dot-mode  0.4+41+gc456a2b-1
ii  elpa-htmlize1.53-1
ii  elpa-markdown-mode  2.3+154-1
ii  perl-doc5.26.2-6
ii  wget1.19.5-1

emacs-goodies-el suggests no packages.

-- no debconf information

Bug#904662: stretch-pu: package sddm/0.14.0-4+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2018-07-26 at 12:45 +0200, Salvatore Bonaccorso wrote:
> sddm in stable is affected by the following issues, which are both
> fixed in unstable already and I would like to propose a fix for the
> next point release.
> 
>  - #898191: sddm: Does not honor PAM's ambient supplemental groups
> (via
>    e.g. pam_group.so)
> 
[...]
>  - #878956: sddm doesn't update utmp or wtmp
> 
>    If someone logs in via sddm, sddm does not update utmp and wtmp
> and
>    e.g. as consequence  'w' and 'who' would not show the logged in
> user.
>    Nor will last or lastb record the logins/failed logins.

>From the SRM side, please feel free to go ahead.

Regards,

Adam

Bug#904813: emacs-goodies-el: drop dedicated.el

[David Bremner]

Package: emacs-goodies-el
Version: 39.0
Severity: normal

this package is orphaned upstream, has not been updated since 2009

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

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

Versions of packages emacs-goodies-el depends on:
ii  bash 4.4.18-3.1
ii  dpkg 1.19.0.5+b1
ii  emacs1:25.2+1-7
ii  emacs-gtk [emacsen]  1:25.2+1-7
ii  emacsen-common   3.0.0
ii  install-info 6.5.0.dfsg.1-4

Versions of packages emacs-goodies-el recommends:
ii  elpa-browse-kill-ring   2.0.0-1
ii  elpa-debian-el  37.0
ii  elpa-diminish   0.45-2
ii  elpa-dpkg-dev-el37.0
ii  elpa-graphviz-dot-mode  0.4+41+gc456a2b-1
ii  elpa-htmlize1.53-1
ii  elpa-markdown-mode  2.3+154-1
ii  perl-doc5.26.2-6
ii  wget1.19.5-1

emacs-goodies-el suggests no packages.

-- no debconf information

Bug#904814: emacs-goodies-el: drop pp-c-l

[David Bremner]

Package: emacs-goodies-el
Version: 39.0
Severity: normal

This package is only provided via emacswiki. melpa is not hosting
these packages any more and neither should we.

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

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

Versions of packages emacs-goodies-el depends on:
ii  bash 4.4.18-3.1
ii  dpkg 1.19.0.5+b1
ii  emacs1:25.2+1-7
ii  emacs-gtk [emacsen]  1:25.2+1-7
ii  emacsen-common   3.0.0
ii  install-info 6.5.0.dfsg.1-4

Versions of packages emacs-goodies-el recommends:
ii  elpa-browse-kill-ring   2.0.0-1
ii  elpa-debian-el  37.0
ii  elpa-diminish   0.45-2
ii  elpa-dpkg-dev-el37.0
ii  elpa-graphviz-dot-mode  0.4+41+gc456a2b-1
ii  elpa-htmlize1.53-1
ii  elpa-markdown-mode  2.3+154-1
ii  perl-doc5.26.2-6
ii  wget1.19.5-1

emacs-goodies-el suggests no packages.

-- no debconf information

Bug#904307: stretch-pu: package multipath-tools/0.6.4-5+deb9u1

[Adam D. Barratt]

Control: tags -1 + moreinfo d-i

On Mon, 2018-07-23 at 06:34 +, Chris Hofstaedtler wrote:
> The update would fix #859157, which is causing me headache on our
> production servers. Basically multipathd just hangs randomly after
> some time.
> 

This looks OK to me, thanks, but as multipath-tools produces a udeb it
will need a KiBi-ack; CCing and tagging accordingly.

Regards,

Adam

Bug#904779: openmpi-bin: any program hangs on first MPI call (e.g. MPI_Init())

[Alastair McKinstry]

I cannot reproduce this problem. Can we debug it further ?

(1) How did you execute it ? mpiexec command line , etc?

(2) Can you give the output of :

$ dpkg -l | grep pmix

$ dpkg -l | grep psm

Any changes to /etc/openmpi/* files or environmental variables

Best regards

Alastair


On 27/07/2018 23:53, Giacomo Mulas wrote:

Package: openmpi-bin
Version: 3.1.1.real-4+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

since the latest wave of package updates (gnu compilers big version switch +
new openmpi package) even the simplest code, compiled by mpicc.openmpi (or
mpif90.openmpi) hangs forever on first initialisation of MPI.  Even the
following "hello world" does it on my machine:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


int main(int argc, char **argv){

   int nprocs=0, myrank=0, ierr=0;

   
   ierr = MPI_Init( &argc, &argv);

   ierr = MPI_Comm_rank(MPI_COMM_WORLD, &myrank);
   ierr = MPI_Comm_size(MPI_COMM_WORLD, &nprocs);

   printf("MPI_Init call ok\n");
   printf("My rank is = %d\n", myrank);
   printf("number of procs is = %d\n", nprocs);
   printf("\n");
   ierr = MPI_Finalize();
   printf("MPI_Finalize call ok, returned %d\n", ierr);
   return 0;

}


Of course, this makes the package completely unusable for me.  I don't know
whether this can be related to bug #584699: in fact my laptop is not really
multihomed.  Please let me know if there is something I can do to help
pinpoint this.  By the way, the above snippet of code works perfectly if
compiled and run under mpich.


Best regards
Giacomo Mulas


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

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

Versions of packages openmpi-bin depends on:
ii  libc62.27-5
ii  libevent-2.1-6   2.1.8-stable-4
ii  libevent-pthreads-2.1-6  2.1.8-stable-4
ii  libhwloc51.11.10-3
ii  libopenmpi3  3.1.1.real-4+b1
ii  openmpi-common   3.1.1.real-4+b1
ii  openssh-client [ssh-client]  1:7.7p1-3

openmpi-bin recommends no packages.

Versions of packages openmpi-bin suggests:
ii  gfortran  4:8.1.0-1

-- no debconf information


--
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#904811: workaround

[Helen Koike Fornazier]

I found the documentation to fix this:

https://pbuilder-docs.readthedocs.io/en/latest/faq.html#avoiding-the-ln-invalid-cross-device-link-message

We just need to set:

APTCACHEHARDLINK=no

But it would be nice if it could detect automatically, so moving this
bug to whishlist.

Bug#904199: stretch-pu: package clamav/ 0.100.0+dfsg-0+deb9u2

[Sebastian Andrzej Siewior]

On 2018-07-28 09:24:28 [+0100], Adam D. Barratt wrote:
> Was the intent that the package would be pushed via -updates?

Yes, please. If you need additinal information I can provide then on
Sunday evening.

> Regards,
> 
> Adam

Sebastian

Bug#900486: python-pydap: FTBFS and Debci failure with NumPy 1.14

[Graham Inggs]

Control: clone -1 -2
Control: tags -1 + patch
Control: retitle -2 FTBFS and Debci failure with Python 3.7
Control: tags -2 + ftbfs

Hi Maintainer

On 28 July 2018 at 07:38, Matthias Klose  wrote:
> === FAILURES 
> ===
> ___ TestDODSResponseNestedSequence.test_body 
> ___
...
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _
>
> var = 
>
> @dods.register(StructureType)
> def _structuretype(var):
> for child in var.children():
>>   for block in dods(child):
> E   RuntimeError: generator raised StopIteration
>
> /usr/lib/python3/dist-packages/pydap/responses/dods.py:85: RuntimeError

This is a new failure caused by a deliberate change of behaviour in
Python 3.7 [1] (PEP 479).

Regards
Graham


[1] https://docs.python.org/3.7/whatsnew/3.7.html#changes-in-python-behavior

Bug#891812: util-linux: FTBFS on hurd-i386: calls pty_init_slave unconditionally

[Samuel Thibault]

Hello,

Samuel Thibault, le dim. 27 mai 2018 18:00:02 +0200, a ecrit:
> Andreas Henriksson, le lun. 21 mai 2018 22:45:54 +0200, a ecrit:
> > Any chance you can test if by any chance the following upstream commit
> > fixes the (libmount-related) build issue on hurd (or if additional
> > upstream fixing is needed for hurd)?
> > 
> > https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=061d1a51097c3c025ff46173f10aa135f9a610d4
> 
> As Svante mentioned it will not work because GNU/Hurd does not provide
> the linuxish mount() interface (which is about to change, btw ;)
> The attached patch fixes the build.

And now it becomes really critical for the hurd-i386 port since the
shadow break, we really need to have the new version of util-linux built
otherwise we can't build anything on the buildds.

Could you please reupload util-linux with the attached patch from
upstream?

Samuel
commit 061d1a51097c3c025ff46173f10aa135f9a610d4
Author: Karel Zak 
Date:   Thu Mar 22 14:05:17 2018 +0100

libmount: include sys/mount.h only if necessary

Addresses: https://github.com/systemd/systemd/issues/8507
Signed-off-by: Karel Zak 

commit c0bdff9997d032e6be2bd89e89d3e06fa02a5c3f
Author: Karel Zak 
Date:   Tue May 29 10:06:00 2018 +0200

libmount: include sys/mount.h on Linux only

Addresses: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=891812
Signed-off-by: Karel Zak 

diff --git a/libmount/src/libmount.h.in b/libmount/src/libmount.h.in
index 8f323fcbf..11fd759fa 100644
--- a/libmount/src/libmount.h.in
+++ b/libmount/src/libmount.h.in
@@ -28,7 +28,14 @@ extern "C" {
 #include 
 #include 
 #include 
-#include 
+
+/* Make sure libc MS_* definitions are used by default. Note that MS_* flags
+ * may be already defined by linux/fs.h or another file -- in this case we
+ * don't want to include sys/mount.h at all to avoid collisions.
+ */
+#if defined(__linux__) && !defined(MS_RDONLY)
+# include 
+#endif
 
 #define LIBMOUNT_VERSION   "@LIBMOUNT_VERSION@"
 #define LIBMOUNT_MAJOR_VERSION   @LIBMOUNT_MAJOR_VERSION@

Bug#902936: fixed in zutils 1.7-2

[Ben Hutchings]

Control: tag -1 moreinfo

On Wed, 25 Jul 2018 09:35:39 + Daniel Baumann 
 wrote:
[...]
>* Skipping zcat for now (Closes: #902936, #903931).
[...]

But you didn't actually do that.

And now you've reassigned this back to initramfs-tools with no
explanation.

It doesn't matter what the input is, if it can trigger a double-free
then that's a bug - in zutils.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


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

Bug#902936: fixed in zutils 1.7-2

[Daniel Baumann]

On 07/28/2018 11:05 AM, Ben Hutchings wrote:
>>* Skipping zcat for now (Closes: #902936, #903931).
> [...]
> 
> But you didn't actually do that.

when installing zutils 1.7-2, /bin/zcat remains untouched. can you
please elaborate why you think i "didn't actually do that"?

> And now you've reassigned this back to initramfs-tools with no
> explanation.

did you see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903931#47
and following?

Regards,
Daniel

Bug#904817: lintian: Warn that depending on both Python 2 and Python 3 interpreters is unusual, likely a mistake?

[Stuart Prescott]

Package: lintian
Version: 2.5.94
Severity: wishlist

Dear Maintainer,

In the upload of translate-toolkit 2.3.0-3, I ended up with the following:

Depends: python3, python3-pkg-resources, python3-six, python3-translate, 
python3:any, python:any

such that the package depended on both the Python 2 and Python 3 interpreters.
It is unlikely that this is desired (and was not in this case!). My mistake
was that there was one script that still had a #!/usr/bin/python even though
everything had supposedly been converted to Python 3.

Variants of python/python:any/python2.7/python2.7:any mixed with variants of
python3/python3:all/python3.x/python3.x:any are likely to be incorrect.

(Perhaps there are indeed legitimate use cases for this that I haven't
imagined and consulting d-python@ might be sensible.)

cheers
Stuart

Bug#904816: emacs-goodies-el: dpkg-dev-el and debian-el dropped without replacement in unstable

[Sven Joachim]

Source: emacs-goodies-el
Version: 39.0
Severity: serious

The dpkg-dev-el and debian-el binary packages have been dropped from
src:emacs-goodies-el, but their elpafied replacements are so far only
available in experimental.

For now the old versions of {dpkg-dev,debian}-el from emacs-goodies-el
36.4 are still in the archive, but I think the 37.x versions need to be
uploaded to unstable before emacs-goodies-el is suitable for testing.


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

Bug#904253: RFS: golang-github-lucasb-eyer-go-colorful - please use expat in d/copyright

[Paride Legovini]

Alexandre Viau wrote on 28/07/2018:
> Hello,
> 
> d/copyright for golang-github-lucasb-eyer-go-colorful says:
> 
>> License: MIT
> 
> However, the short name for this license is "Expat".

Done. That's what I usually do, not sure why I forgot about it.
Thanks for pointing it out.

Paride



signature.asc
Description: OpenPGP digital signature

Bug#904749: make: patch of arscan.c fails dependency testing

[Philipp Wolski]

Hi,


the new patch looks good.

It also passes the se_main compile and an entire rebuilt of the project.

Thank you !


> Although alloca(INT_MAX) is not going to well!

Reminds me of a popular song: "(Don't) Fear the OOM-Reaper" with the 
background vocals singing "just add more hardware"...



Philipp Wolski

Bug#904818: emacs-goodies-el: drop keydef.el

[David Bremner]

Package: emacs-goodies-el
Version: 39.0
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Unmaintained, no updates since 2009

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

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

Versions of packages emacs-goodies-el depends on:
ii  bash 4.4.18-3.1
ii  dpkg 1.19.0.5+b1
ii  emacs1:25.2+1-7
ii  emacs-gtk [emacsen]  1:25.2+1-7
ii  emacsen-common   3.0.0
ii  install-info 6.5.0.dfsg.1-4

Versions of packages emacs-goodies-el recommends:
ii  elpa-browse-kill-ring   2.0.0-1
ii  elpa-debian-el  37.0
ii  elpa-diminish   0.45-2
ii  elpa-dpkg-dev-el37.0
ii  elpa-graphviz-dot-mode  0.4+41+gc456a2b-1
ii  elpa-htmlize1.53-1
ii  elpa-markdown-mode  2.3+154-1
ii  perl-doc5.26.2-6
ii  wget1.19.5-1

emacs-goodies-el suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAltcOlAACgkQ8gKXHaSn
niy4qgv8CgR4U921t5AA28OG31i4DRZKKM70gWyMHB6rIF3SR9ZbAut9NhKOJeG3
EzI4ohH+MTbKNGHB+wtcGI4ZEPtPmvZuKW8akx8krKhdtPuQtVKaFP0rvgR0cYZ4
DGMkbmbDkNXvYBjQ98RWX2eU528ctg/bOwyQOrEGNcPGnonRo0s/+HFoHXg/N/bb
Rh7y2SPo2Bf2BylejQhqkLmkhPnMqnqhgDf8gt3IgsAeUVyh5SXM6KIE46vARMos
IbKAN63iQa402qRdJijn1toE4IItynakYWGtov2ZsnZLhtOZkqFylzIdQihxoZDH
eWJO4tcHeIGugAQfQrhUofwCg/ub9WDLn/jULU3TyY9xbZDOYwt/GKa8ptybIWCW
JlLQ6CxizAjjY7tsaT7qk/ptCB87Y1/c4W/6+zPlCWZSGKSYJuuYuJ91DdZEpB/i
UWsDtcnqb2uye0G+Qzaie5tl91fnDKMSqH+qWWLFXNu9KDn8PsACrzZCI1HaDcke
WO4tRFxn
=+LHh
-END PGP SIGNATURE-

Bug#904250: RFS - golang-github-ulule-limiter - don't skip all tests

[Paride Legovini]

Alexandre Viau wrote on 28/07/2018:
> Hello,
> 
> I have noticed that you skip all tests in golang-github-ulule-limiter.
> 
> However, there is only two tests that require redis.
> 
> I think that it would be best to skip only these two tests.
> 
> You can simply write a patch that adds t.Skip() to these tests.

Hello Alexandre,

I think I've found a better way to skip that test, without patching.
Please check my last commits when you have time.

Cheers,

Paride



signature.asc
Description: OpenPGP digital signature

Bug#904775: [Pkg-shadow-devel] Bug#904775: Broken dependencies

[Bálint Réczey]

Hi Sven,

2018-07-28 12:36 GMT+08:00 Sven Joachim :
> On 2018-07-27 21:36 +0200, Alf Gaida wrote:
>
>> Package: login
>> Version: 1:4.5-1
>> Severity: grave
>>
>> Dear Maintainer,
>> please don't break util-linux that is not even released. At least _one_ 
>> valid util-linux
>> should be available.
>
> Why was util-linux 2.32-0.2 not uploaded along shadow 1:4.5-1.1 to avoid
> this breakage?

There were issues with the util-linux upload but now it is building on
the buildds and should fix the breakage soon. I keep the RC bug open
till we are confident that everything went fine.

Sorry for the temporary inconvenience.

Cheers,
Balint

Bug#904262: python-fabio builds for the default python3 version, but tests with all supported versions.

[Matthias Klose]

On 22.07.2018 15:23, PICCA Frederic-Emmanuel wrote:
>> your autopkg tests loops over all *supported* python versions, but you only
>> build the extension for the *default* python3 version.  Try build-depending 
>> on
>> python3-all-dev instead and see that you have extensions built for both 3.6 
>> and
>> 3.7.  Building in unstable, of course.
> 
> But , I already depends on python3-all-dev ???
> 
> https://sources.debian.org/src/python-fabio/0.6.0+dfsg-1/debian/control/
> 
> I think that  this is due to the python3.7 transtion which is ot over for 
> python-fabio.
> 
> right ?

my bad. I can confirm that it builds, when all dependencies are in place.

Bug#902936: fixed in zutils 1.7-2

[Ben Hutchings]

Control: tag -1 - moreinfo
Control: unmerge -1
Control: reassign -1 zutils
Control: clone -1 -2
Control: retitle -1 zutils installs an incompatible replacement for GNU zcat
Control: close -1 1.7-2
Control: retitle -2 Double-free when using zutils zcat -t on some input
Control: severity -2 important
Control: tag -2 security

On Sat, 2018-07-28 at 11:21 +0200, Daniel Baumann wrote:
> On 07/28/2018 11:05 AM, Ben Hutchings wrote:
> > >* Skipping zcat for now (Closes: #902936, #903931).
> > 
> > [...]
> > 
> > But you didn't actually do that.
> 
> when installing zutils 1.7-2, /bin/zcat remains untouched. can you
> please elaborate why you think i "didn't actually do that"?

Sorry, I looked at the file list on packages.debian.org which turns out
to be stale even though it's showing the current version number.

> > And now you've reassigned this back to initramfs-tools with no
> > explanation.
> 
> did you see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903931#47
> and following?

It didn't show up on this bug's message log because you didn't write
the control commands properly.

So, you conveyed the upstream author's explanation, but it doesn't
answer why it's OK to install that version of zcat as a replacement for
GNU zcat.  I'm sure some people like to have all the cat options when
using zcat interactively, but it is also used programmatically and
probably not only by initramfs-tools.  You seem to have accepted that
and fixed it, so I don't know why you then assigned the bug back.

The double-free bug in zutils zcat is presumably still unfixed, so I'm
cloning a separate bug for that.

I'm leaving #903931 assigned to initramfs-tools since I might as well
work around the zcat incompatibility.  But please don't take it as a
cue to revert the change in zutils, when that is closed.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


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

Bug#904820: mate-applet-topmenu: topmenu not working

[Stefan Kadow]

Package: mate-applet-topmenu
Version: 0.3-1
Severity: grave
Justification: renders package unusable

Add to panel works, but you will see almost nothing but some pixels.
Each GTK app keeps its menu in its own window, no menu in panel.

I tried the stable and backports versions.

Everything looks good in systemd-journal:
Jul 28 11:57:52 zeit dbus-daemon[619]: Activating service 
name='org.mate.panel.applet.TopMenuMatePanelAppletFactory'
Jul 28 11:57:52 zeit dbus-daemon[619]: Successfully activated service 
'org.mate.panel.applet.TopMenuMatePanelAppletFactory'


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

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

Versions of packages mate-applet-topmenu depends on:
ii  libatk1.0-0   2.28.1-1~bpo9+1
ii  libc6 2.24-11+deb9u3
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libmate-panel-applet-4-1  1.20.2-1~bpo9+1
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libtopmenu-client-gtk3-0  0.3-1
ii  libtopmenu-server-gtk3-0  0.3-1
ii  mate-panel1.20.2-1~bpo9+1
ii  topmenu-gtk-common0.3-1

mate-applet-topmenu recommends no packages.

mate-applet-topmenu suggests no packages.

-- no debconf information

Bug#904612: packaging of qcoan fully revised

[Elmar Stellnberger]

The packaging quality of qcoan has been highly improved since my 
original RFS. There are no more lintian errors that should be resolved 
and with the advice from wRAR at #debian-mentors I have improved the 
package internals (no nested .tar.bz2, debian/install list).


see: https://mentors.debian.net/package/qcoan

Bug#904821: mbedtls: CVE-2018-0497, CVE-2018-0498: Remote plaintext recovery on use of CBC based ciphersuites through a timing side-channel

[James Cowgill]

Source: mbedtls
Version: 2.1.2-1
Severity: grave
Tags: security upstream

This security advisory was published for mbedTLS. All versions since 1.2
are affected.

https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2018-02

CVE-2018-0497:
Remote plaintext recovery on use of CBC based ciphersuites through a
timing side-channel

CVE-2018-0498:
Plaintext recovery on use of CBC based ciphersuites through a cache
based side-channel

James



signature.asc
Description: OpenPGP digital signature

Bug#903526: python 3.7 compatibility

[Matthias Klose]

Control: tags -1 + patch

fixed upstream:
https://github.com/pycontribs/jira/commit/206f62b490d792a9c4a10680489ef9f7bc10cb3f

that should be fixed in the 2.0.0 release as well.

Bug#904822: linux-image-4.17.0-1-amd64: Freeze/timing/interrupt problems since 4.17

[Nicolas George]

Package: src:linux
Version: 4.17.8-1
Severity: normal

Dear Maintainer,

Since kernel 4.17.8-1 have migrated to testing, I have been experiencing the
two following issues, that I believe are related:

- Processes doing disk accesses sometimes go into D state, while the
  disk itself is idle and the kernel reports nothing spurious (in
  particular no hardware timeout nor bus reset), and stay there several
  seconds or many minutes.

- The audio device takes a noticeable time to open.

Both could be explained by some kind of interrupt problem.

For the audio device, I have the following strace output for "aplay -f
S16_LE -r 48000 -c 2 /dev/zero":

1532683807.044375 ioctl(3, SNDRV_CTL_IOCTL_PCM_PREFER_SUBDEVICE, 
0x7fffbb82edcc) = 0 <0.06>
1532683807.044393 openat(AT_FDCWD, "/dev/snd/pcmC0D0p", 
O_RDWR|O_NONBLOCK|O_CLOEXEC) = 4 <0.161654>
1532683807.206124 fcntl(4, F_SETFD, FD_CLOEXEC) = 0 <0.18>

Notice the 0.16 seconds to open pcmC0D0p. If the same command is run less
than a few seconds after the last use of the audio device, it goes down to:

1532683819.333547 ioctl(3, SNDRV_CTL_IOCTL_PCM_PREFER_SUBDEVICE, 
0x7fffd28eadec) = 0 <0.06>
1532683819.333565 openat(AT_FDCWD, "/dev/snd/pcmC0D0p", 
O_RDWR|O_NONBLOCK|O_CLOEXEC) = 4 <0.22>
1532683819.333599 fcntl(4, F_SETFD, FD_CLOEXEC) = 0 <0.05>

With kernel 4.16.0-2-amd64, it is always fast:

1532770761.849012 ioctl(3, SNDRV_CTL_IOCTL_PCM_PREFER_SUBDEVICE, 
0x7ffeb256f63c) = 0 <0.06>
1532770761.849034 openat(AT_FDCWD, "/dev/snd/pcmC0D0p", 
O_RDWR|O_APPEND|O_NONBLOCK|O_CLOEXEC) = 4 <0.12>
1532770761.849064 fcntl(4, F_SETFD, FD_CLOEXEC) = 0 <0.05>

For the problem with processes in D state, I have the following kernel
backtrace. The hard drive was behaving normally at the time, mostly idle (by
ear):

[32866.954230] INFO: task md0_raid1:200 blocked for more than 120 seconds.
[32866.954241]   Tainted: G  I   4.17.0-1-amd64 #1 Debian 
4.17.8-1
[32866.954245] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[32866.954249] md0_raid1   D0   200  2 0x8000
[32866.954257] Call Trace:
[32866.954273]  ? __schedule+0x291/0x870
[32866.954280]  schedule+0x28/0x80
[32866.954299]  md_super_wait+0x6e/0xa0 [md_mod]
[32866.954312]  ? finish_wait+0x80/0x80
[32866.954326]  write_page+0x249/0x330 [md_mod]
[32866.954333]  ? __schedule+0x299/0x870
[32866.954347]  md_update_sb.part.62+0x367/0x840 [md_mod]
[32866.954361]  md_check_recovery+0x4ab/0x570 [md_mod]
[32866.954371]  raid1d+0x5c/0x880 [raid1]
[32866.954383]  ? lock_timer_base+0x67/0x80
[32866.954389]  ? try_to_del_timer_sync+0x4d/0x80
[32866.954396]  ? del_timer_sync+0x35/0x40
[32866.954403]  ? schedule_timeout+0x181/0x380
[32866.954415]  ? find_pers+0x70/0x70 [md_mod]
[32866.954426]  ? md_thread+0x122/0x160 [md_mod]
[32866.954434]  ? handle_read_error+0x4c0/0x4c0 [raid1]
[32866.954445]  md_thread+0x122/0x160 [md_mod]
[32866.954453]  ? finish_wait+0x80/0x80
[32866.954464]  kthread+0x113/0x130
[32866.954472]  ? kthread_create_worker_on_cpu+0x70/0x70
[32866.954480]  ret_from_fork+0x35/0x40
[32866.954490] INFO: task systemd-journal:339 blocked for more than 120 seconds.
[32866.954495]   Tainted: G  I   4.17.0-1-amd64 #1 Debian 
4.17.8-1
[32866.954498] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[32866.954502] systemd-journal D0   339  1 0x0104
[32866.954508] Call Trace:
[32866.954515]  ? __schedule+0x291/0x870

Regards,

-- 
  Nicolas George


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: ZOTAC
product_name: ZBOX-ID91
product_version: XX
chassis_vendor: NA
chassis_version: NA
bios_vendor: American Megatrends Inc.
bios_version: B206P009
board_vendor: ZOTAC
board_name: ZBOX-ID91
board_version: XX

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 4th Gen Core Processor DRAM 
Controller [8086:0c00] (rev 06)
Subsystem: ZOTAC International (MCO) Ltd. 4th Gen Core Processor DRAM 
Controller [19da:b206]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: hsw_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Generation Core 
Processor Family Integrated Graphics Controller [8086:041e] (rev 06) (prog-if 
00 [VGA controller])
Subsystem: ZOTAC International (MCO) Ltd. 4th Generation Core Processor 
Family Integrated Graphics Controller [19da:b206]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
Processor HD Audio Controller [8086:0c0c] (rev 06)
 

Bug#904824: ITP: golang-github-gdamore-tcell -- Cell based view for text terminals

[Paride Legovini]

Package: wnpp
Severity: wishlist
Owner: Paride Legovini 

* Package name: golang-github-gdamore-tcell
  Version : 1.1.0
  Upstream Author : Garrett D'Amore
* URL : https://github.com/gdamore/tcell
* License : Apache-2.0 
  Programming Lang: Go 
  Description : Cell based view for text terminals

 Package tcell provides a cell based view for text terminals, like xterm.
 It was inspired by termbox, but differs from termbox in some important
 ways. It also adds substantial functionality beyond termbox.

This is a depdendency of browsh (ITP #904132).
The package will be maintained in the Go team.

Paride

Bug#904823: src:isdnutils: Making build reproducible

[Christoph Biedl]

Package: src:isdnutils
Version: 1:3.25+dfsg1-9
Severity: wishlist
Tags: patch pending

For the records: The attached patch makes the creation of dest.cdb
reproducible, thus the entire build. Will be part of the next upload.

Christoph
Description: CDB_File_Dump: Sort keys when dumping, making the created file reproducible
Author: Christoph Biedl 
Date: 2018-07-28
Forwarded: not-yet

--- a/isdnlog/tools/dest/CDB_File_Dump.pm
+++ b/isdnlog/tools/dest/CDB_File_Dump.pm
@@ -103,9 +103,9 @@
 sub DESTROY {
 my $self = $_[0];
 my $fh = $self->{fh};
-my ($key, $value);
-while (($key, $value) = each(%{ $self->{data} })) {
-	print $fh "+",length($key),",",length($value),":",$key,"->",$value,"\n";
+foreach my $key (sort keys %{ $self->{data} }) {
+my $value = $self->{data}{$key};
+print $fh "+",length($key),",",length($value),":",$key,"->",$value,"\n";
 }
 }
 1;


signature.asc
Description: PGP signature

Bug#904746: Bug#904745: RFS: mint-y-icons/1.3.0-1 [ITP]

[Adam Borowski]

On Fri, Jul 27, 2018 at 03:04:04PM +0200, pavel-re...@email.cz wrote:
> * Package name: mint-y-icons
>   Version : 1.3.0-1
> * URL : https://github.com/linuxmint/mint-y-icons
> * License : GPL-3+, CC-BY-SA-4.0

> * Package name: mint-y-theme
>   Version : 1.2.3-1
>   Upstream Author : Clement Lefebvre  r...@linuxmint.com
> * URL : https://github.com/linuxmint/mint-y-theme

> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/mint-y-icons

Hi!
I've done only a very cursory review so far, and I see:

* menu bar in GTK3 programs is squashed, here's a screenshot:
  https://angband.pl/tmp/mint-y-menu.png
  GTK2 programs are ok, so are QT (QT uses GTK2 theme, I think it can be
  configured for GTK3 these days though)

* both in -theme and -icons, you ship pre-built files, and don't even delete
  them during build.  That makes it hard to ensure that what you install is
  indeed built from provided source.

  It would be best to repack the .orig tarballs to remove usr/ dirs inside
  -- besides making things unclear, they also waste space, and might
  possibly include parts that don't have source.

* the copyright files in both -theme and -icons need to include all authors
  (you can often get away with naming a group, though).  They don't even
  list files in debian/ (the packaging).  In -theme, the README.md says it
  is based on Arc.  In -icons, there's a long list of themes some categories
  of icons have been copied from.  Those authors need to be mentioned. 

  There's a disagreement on how detailed the list should be: some people
  want everything to be accurate down every file, others say something like:
  Files: *Copyright: 1991-2012 Linus Torvalds and many others
  You need to do it detailed enough to pass ftpmasters' review, and their
  minimal requirements tend to be somehwere in the middle.  And here, you
  didn't list most authors at all, even as part of a group.


Meow!

(.sig related -- but no matter how _I_ feel about copyright, with a DD hat
on I still need to respect it, as it's not up to me to decide)
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#904652: Having the same trouble

[Manolinux]

I have the same issue.

Strange thing is that alsa detects the devices.

---
$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 1: ALC269VB Digital [ALC269VB Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
---

But not pulse:

---
$ pacmd list-cards
0 card(s) available.
---

VLC can reproduce audio if the sound device is setup trhough alsa.
anyother test throws the same result: alsa detects the devices without
error, pulse does not detect de devices (but I didnt see any error).

Bug#883182: libsane-hpaio: SCL scan resolutions list too restrictive

[Geoff Clare]

I have reported this upstream as suggested by Brian.

See https://bugs.launchpad.net/hplip/+bug/1784118

Bug#904825: aces3 ftbfs in unstable

[Matthias Klose]

Package: src:aces3
Version: 3.0.8-5.1
Tags: sid buster
Severity: serious

aces3 ftbfs in unstable:

[...]
mpif77 -DMPIF2C -DMPI2 -DC_SUFFIX -DCB_SUFFIX -D__fortran -D__fortran77 -g -O2
-Wall -fno-aggressive-loop-optimizations  -o xaces3 \
   find_seg.o reorder_coefficients.o reorder_rohf.o joda_exit.o
clear_static_data_requests.o init_data.o nuclear_nuclear_repulsion_energy.o
worker_termination.o check_jodadone.o find_jobflow.o
write_default_sial_programs.o int_send_common.o int_gen_sizer.o geometry.o
reset_internal_system_data.o write_zmat_auto.o get_sial_config_params.o
aces_com_parallel_aces.o nuclear_nuclear_gradient.o beta.o scf_init.o
set_ecp_charges.o worker_work.o decode_fmo_params.o timer_data.o
descramble_coefficients.o int_gen_init.o handle_gradient.o molread.o
det_segsizes.o handle_hessian.o worker_init.o joda_prep.o verify_aces2_params.o
c_exit.o sumz.o  ../sia/manager/check_consistency.o
../sia/manager/check_for_server_array.o ../sia/manager/check_preparesum_work.o
../sia/manager/check_work_stack_for_delay.o ../sia/manager/claim_memory_block.o
../sia/manager/clear_server_stats.o ../sia/manager/diskcall.o
../sia/manager/distribute_server_info.o ../sia/manager/do_backup.o
../sia/manager/find_clean_block.o ../sia/manager/find_free_diskloc.o
../sia/manager/find_oldest_dirty_block.o ../sia/manager/find_server_table_ptr.o
../sia/manager/insert_work_node.o ../sia/manager/make_free_block.o
../sia/manager/mark_block_clean.o ../sia/manager/mark_block_dirty.o
../sia/manager/pop_clean_block.o ../sia/manager/pop_work_node.o
../sia/manager/prequest_copy_slice.o ../sia/manager/print_server_data.o
../sia/manager/process_prepare_message.o
../sia/manager/process_preparesum_message.o
../sia/manager/process_prequest_message.o
../sia/manager/process_request_message.o
../sia/manager/process_server_blocks_to_list_msg.o
../sia/manager/process_server_blocks_to_list_no_mpi_io.o
../sia/manager/process_server_checkpoint_msg.o
../sia/manager/process_server_commit_msg.o
../sia/manager/process_server_copy_message.o
../sia/manager/process_server_delete_message.o
../sia/manager/process_server_list_to_blocks_msg.o
../sia/manager/process_server_restart_msg.o
../sia/manager/process_work_queue_entry.o ../sia/manager/ptr_check.o
../sia/manager/push_clean_block.o ../sia/manager/push_work_node.o
../sia/manager/remove_from_dirty_list.o ../sia/manager/remove_work_head.o
../sia/manager/server_abort_job.o ../sia/manager/sip_server_init.o
../sia/manager/sip_server_work.o ../sia/manager/syscopy.o
../sia/manager/translate_key.o ../sia/worker/block_map_table_setup.o
../sia/worker/build_segment_table.o ../sia/worker/built_cmp2zmat.o
../sia/worker/determine_stack_blocksizes.o ../sia/worker/fragment_orbitals.o
../sia/worker/fshells_to_segments.o ../sia/worker/get_subrange_segments.o
../sia/worker/get_symbolic_constant.o ../sia/worker/init_c.o
../sia/worker/init_eps.o ../sia/worker/init_fock.o ../sia/worker/init_fockrohf.o
../sia/worker/init_oed_integrals.o ../sia/worker/print_symbolic_constants.o
../sia/worker/refill_block_map_table.o ../sia/worker/remap.o
../sia/worker/send_static_data.o ../sia/worker/shells_to_segments.o
../sia/worker/sial_compile_and_send_tables.o
../sia/worker/sial_compile_and_send_tables1.o ../sia/worker/sip_fmain.o
../sia/worker/stack_distribution.o ../sia/worker/vmlgen.o
../sia/worker/vtdemo_init.o ../sia/worker/write_eig_data.o
../aces/aces_library/special_directory/direct_integral/aces_to_erd.o
../aces/aces_library/special_directory/direct_integral/binpack.o
../aces/aces_library/special_directory/direct_integral/comp_dipole_moment.o
../aces/aces_library/special_directory/direct_integral/comp_first_moment.o
../aces/aces_library/special_directory/direct_integral/comp_fock_der.o
../aces/aces_library/special_directory/direct_integral/comp_overlap_der.o
../aces/aces_library/special_directory/direct_integral/comp_return_derv_xyz.o
../aces/aces_library/special_directory/direct_integral/comp_return_h1.o
../aces/aces_library/special_directory/direct_integral/comp_return_h1_nodiag.o
../aces/aces_library/special_directory/direct_integral/comp_return_ovl.o
../aces/aces_library/special_directory/direct_integral/comp_return_x.o
../aces/aces_library/special_directory/direct_integral/comp_return_xx.o
../aces/aces_library/special_directory/direct_integral/comp_return_xy.o
../aces/aces_library/special_directory/direct_integral/comp_return_xz.o
../aces/aces_library/special_directory/direct_integral/comp_return_y.o
../aces/aces_library/special_directory/direct_integral/comp_return_yy.o
../aces/aces_library/special_directory/direct_integral/comp_return_yz.o
../aces/aces_library/special_directory/direct_integral/comp_return_z.o
../aces/aces_library/special_directory/direct_integral/comp_return_zz.o
../aces/aces_library/special_directory/direct_integral/comp_second_moment.o
../aces/aces_library/special_directory/direct_integral/compute_der2_batch.o
../aces/aces_library/special_directory/direct_integral/compute_der_batch.o
../aces/aces_

Bug#904791: Report against libfprint instead of fprintd, and info about prepared NMU

[Boyuan Yang]

Control: retitle -1 libfprint: Please switch upstream and follow
latest fprintd release (0.8.2)
Control: reassign -1 libfprint
X-Debbugs-CC: der...@debian.org o...@debian.org bi...@debian.org


Dear libfprint maintainers,

I have prepared a new upload for libfprint v0.8.2 as an NMU. You may
find my work here:

  https://salsa.debian.org/hosiet-guest/libfprint.git

Changes since the last upload:

 libfprint (1:0.8.2-0.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * New 0.8.2 upstream release, with ABI breakage but no API breakage:
 - Add Elan driver
 - Integrate several security fixes (Closes: #890827)
 - Remove already replaced UPEKE2 driver
 - Add USB ID for TNP Nano USB Fingerprint Reader
 - Various fixes
 - Port to meson build system
 - Port to gtk-doc documentation system
   * debian: Apply "wrap-and-sort -abst" to sort file contents
   * debian/control:
 - Bump Standards-Version to 4.1.5
 - Use Priority: optional instead of deprecated Priority: extra
 - Update Vcs fields to use git repository on Salsa Debian group
 - Bump debhelper compat to v11.
 - Add new build dependencies: udev, meson, gtk-doc-tools
   * debian/changelog: Remove trailing spaces.
   * debian/patches:
 - Remove old leftover for backported patches
 - Backport upstream fix for building with new meson
 - Block old patches for kFreeBSD for now, they would cause conflicts
   * debian/rules:
 - Modernize packaging instructions for meson buildsystem
 - Update searching for .rules file in override_dh_installudev
   * debian/gbp.conf: Removed to use default git repository layout
   * debian/libfprint-dev.install: Remove installation of legacy .la/.a files
   * debian/libfprint0.symbols:
 - Add new symbols introduced in new release
 - Manually tweak the version requirement for one symbol due to upstream
   ABI breakage

The new release introduces ABI breakage but no API breakage thus no
transition would be needed.
However, a rebuild (binNMU) might be needed for fprintd and fprintd-demo.

Please consider reviewing my work. I'd be glad to provide with more help.

--
Regards,
Boyuan Yang

Bug#904826: Wrong Pressure in plungin weather

[Jörg Frings-Fürst]

Package: lxpanel
Version: 0.9.3-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

in the weather plugin the pressure is very high (32812,12 mb)  (see
screenshot).





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

Kernel: Linux 4.17.0-1-amd64 (SMP w/6 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 lxpanel depends on:
ii  libasound2   1.1.6-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-5
ii  libcairo21.15.10-3
ii  libfm-gtk4   1.3.0.2-1
ii  libfm-modules1.3.0.2-1
ii  libfm4   1.3.0.2-1
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libgdk-pixbuf2.0-0   2.36.12-1
ii  libglib2.0-0 2.56.1-2
ii  libgtk2.0-0  2.24.32-2
ii  libiw30  30~pre9-12+b1
ii  libkeybinder00.3.1-1
ii  libmenu-cache3   1.1.0-1
ii  libpango-1.0-0   1.42.1-2
ii  libpangocairo-1.0-0  1.42.1-2
ii  libpangoft2-1.0-01.42.1-2
ii  libwnck222.30.7-5.1
ii  libx11-6 2:1.6.5-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  lxmenu-data  0.1.5-2
ii  lxpanel-data 0.9.3-1

Versions of packages lxpanel recommends:
ii  gnome-terminal [x-terminal-emulator]  3.28.2-1
ii  lxterminal [x-terminal-emulator]  0.3.1-2
ii  mate-terminal [x-terminal-emulator]   1.20.1-1
ii  pavucontrol   3.0-4
ii  xfce4-terminal [x-terminal-emulator]  0.8.7.4-1
ii  xkb-data  2.23.1-1
ii  xterm [x-terminal-emulator]   333-1

Versions of packages lxpanel suggests:
ii  firefox [www-browser] 61.0.1-1
ii  firefox-esr [www-browser] 52.9.0esr-1
ii  google-chrome-stable [www-browser]68.0.3440.75-1
ii  google-chrome-unstable [www-browser]  69.0.3497.12-1
ii  menu  2.1.47+b1
ii  w3m [www-browser] 0.5.3-36+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAltcTucACgkQCfifPIyh
0l1wqRAAn+akgzeZSCag5UU0Kf8vWO1mVvo35arD96rLS5Gep9O14Os75iGaSrFC
XxC/hxSf3SY1dmtYskhgsIiFzlWMhAvdyRsHtCSn4IOElBeoB0DDxY4Q/L/KR9LY
R3H9fp5dlfuT9whmvFkJgLxfTO9sRKBV6Vz3O6fDgivKcrac1337OXQ0yHG+sYC0
lY2QhqnGRKvheEkVPg8Z6HtQixLk4s0gcyh0TccwrKiJNMcsg6lLv1OJSfCmeEOW
ARqf8UYc7bV4TBgSnUfVJWpuu9iPwpz/Mz2y7Bmu7cWJzBlnS/F6XcKewkj7yi+X
ZsryO/icVCSVMm/vGq7n3HzfjZ7ggXI2hRAd1Co6jHK31tr85C6EKonYAsc8Fc/Q
cXsHghLY9tx0/AJqtInq2mAmtznxqJ9XIUAfghuJylGt7uV75cFVGOdVny7+i3aB
qziHv4sA7GJvimK3WYTX3q/x19rYo4E2ZtCBfgk4c0zT1AdE3FZKsqcshOHgJW9d
DHb3OuXOcFUIL5AY10mn8S0P9r+XMP3w8kSiX3LVTaVvgfC+CZBJ3eXMh7douw/k
n3N7gK6U4zEEDWAcV6oxBsytdgo5c2X9oOgUhVTrUp83FwZfxr7mHUwdq49WF/ZY
YVlHevosMAvfWCGRt5qs6b4OqsDnq8wkxrYQf64Hef/TjSELXXQ=
=HTBG
-END PGP SIGNATURE-

Bug#904827: The setup windows from the plugins can't close via X and menu -> close

[Jörg Frings-Fürst]

Package: lxpanel
Version: 0.9.3-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

all setupwindows from the panel plugins can't close via X and menue - > close.

CU
Jörg



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

Kernel: Linux 4.17.0-1-amd64 (SMP w/6 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 lxpanel depends on:
ii  libasound2   1.1.6-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-5
ii  libcairo21.15.10-3
ii  libfm-gtk4   1.3.0.2-1
ii  libfm-modules1.3.0.2-1
ii  libfm4   1.3.0.2-1
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libgdk-pixbuf2.0-0   2.36.12-1
ii  libglib2.0-0 2.56.1-2
ii  libgtk2.0-0  2.24.32-2
ii  libiw30  30~pre9-12+b1
ii  libkeybinder00.3.1-1
ii  libmenu-cache3   1.1.0-1
ii  libpango-1.0-0   1.42.1-2
ii  libpangocairo-1.0-0  1.42.1-2
ii  libpangoft2-1.0-01.42.1-2
ii  libwnck222.30.7-5.1
ii  libx11-6 2:1.6.5-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  lxmenu-data  0.1.5-2
ii  lxpanel-data 0.9.3-1

Versions of packages lxpanel recommends:
ii  gnome-terminal [x-terminal-emulator]  3.28.2-1
ii  lxterminal [x-terminal-emulator]  0.3.1-2
ii  mate-terminal [x-terminal-emulator]   1.20.1-1
ii  pavucontrol   3.0-4
ii  xfce4-terminal [x-terminal-emulator]  0.8.7.4-1
ii  xkb-data  2.23.1-1
ii  xterm [x-terminal-emulator]   333-1

Versions of packages lxpanel suggests:
ii  firefox [www-browser] 61.0.1-1
ii  firefox-esr [www-browser] 52.9.0esr-1
ii  google-chrome-stable [www-browser]68.0.3440.75-1
ii  google-chrome-unstable [www-browser]  69.0.3497.12-1
ii  menu  2.1.47+b1
ii  w3m [www-browser] 0.5.3-36+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAltcT/EACgkQCfifPIyh
0l32Eg//Y3xmQ9rc0rbre64DJjr0rLHI4vUJpYe6Q0B3tNljj1bLjPmyVRGSacVm
3r3kjLBxTwMkBqUFVpG/mPpVFKTxArP3/h8pzkIJNQHMNWTjLERD9OTHPSNvb+z3
bTFwFpXlwjrHJr+4baIQopkOiyyqZY0R6O39T5zNTgxFsDNjo246YUsG89KXbdvt
dbFYVAl+GdT/BzhztAzqt87x7AucsGgHn7PpKjP/l6v5JWeUf+rY1wbIQaNJggeB
PEIrx7XeDZpJhem1pZI2jeaFRLNReUSVJEpEOl450S4weyDHCtKpLqlQOkzv3uxN
4Ae85d2BDd3vkfERBJp5ULbcIBVhNF0W+MKRgmOz2gaLrKCcRfu06TWROUEBovkM
J8a3QnPRMLh6iTgm3Kl1VKcR4Lpw4adEFzpxhaY0bYZomDP1c5wwLEEvjqkYxlGQ
qElR9cc/0d6vqV8A1fJOwxh8BgGIA6pDEDwqXsYxtRSEdQhdinFivuI4OxOJ2tqO
g1RPkk68n2ejkwaZhtiDOOJrzXXqpJ5OLkRw0rhRXREHn6vGFD4ufA5KfpCMTm64
TLwtwrIOlTHYk0/5V4rDpOOPhzpoA65BUG0mOnYno46IJlGeda7d8ECuYQnRWvik
Rm/9Qnh8Q2N47LGwvAXV1KPEW55GKkl3Im1zjt0BYPCg5v8Gc5g=
=W59Y
-END PGP SIGNATURE-

Bug#904588: supercollider: Stretch i386 Supercollider fails with segmentation fault

[Bernhard Übelacker]

Hello Knut Jackowski,
I tried to reproduce the issue with a Stretch i386 VM.

"Unfortunately" the scide gui opened without a problem.

So maybe you could deliver some more information about
the crash by following this guide [1].

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

This mail is written in the assumption that BunsenLabs
does not recompile every package for their distribution?

Kind regards,
Bernhard

Bug#818469: /usr/share/hplip/base/sixext.py: Printing from some PDF files fails in pdftops conversion with python UTF8 error

[Brian Potkin]

On Thu 17 Mar 2016 at 10:34:30 +, jgiemail-deb...@yahoo.es wrote:

> Package: hplip-data
> Version: 3.16.2+repack0-7
> Severity: normal
> File: /usr/share/hplip/base/sixext.py
> Tags: patch
> 
> Dear Debian Maintainer,
> 
> Trying to print some PDF files from atril (MATE's desktop environment viewer) 
> fails
> with print error:
> 
> "There was a problem processing document ..."
> 
> I tried with the hplip-data in testing (3.16.2+repack0-4), and the one in
> unstable (3.16.2+repack0-7).

[error_log snipped]

> The error lines  are:
> 
> D [17/Mar/2016:09:27:43 +0100] [Job 267] File 
> \"/usr/share/hplip/base/sixext.py\", line 109, in to_bytes_utf8
> D [17/Mar/2016:09:27:43 +0100] [Job 267] return s.encode(\"utf-8\")
> D [17/Mar/2016:09:27:43 +0100] [Job 267] UnicodeEncodeError: \'utf-8\' codec 
> can\'t encode character \'\\udce2\' in position 31: surrogates not allowed
> 
> ==
> 
> I found a solution (or workaroud) at:
> https://bugs.launchpad.net/hplip/+bug/1498366
> 
> Change line 109 in /usr/share/hplip/base/sixext.py 
> "return s.encode("utf-8")"
> with
> "return s.encode("utf-8", errors="surrogateescape")".
> 
> with this change, the filter works, and the printer prints.

Upstream appear willing to fix this issue. LP #1498366 has

 Changed in hplip:
 status:In Progress → Fix Committed

from  kritika arora (kritika-arora1) on 2017-02-07.

However, hplip_3.18.6+dfsg0.orig.tar.xz in experimental has no mention
of "surrogate". Perhaps the fix has been done in another way (test) or
it will appear in a future release of hplip. I'd suggest some gentle
prodding at #1498366 to ascertain upstream's intentions.

Regards,

Brian.

Bug#904775: [Pkg-shadow-devel] Bug#904775: Broken dependencies

[Tobias Frost]

> 
> There were issues with the util-linux upload but now it is building
on
> the buildds and should fix the breakage soon. 

Please make that sure by a versioned B-D next time.

--
tobi

Bug#783165:

[Ohams Kalus]

Ohams Kalus vagyok; Láttam az Ön e-mail címét a weboldalon, és úgy
döntöttem, hogy felveszi a kapcsolatot az e-mail címmel, hogy
megtudja, érvényes-e, várni fogom a választ. Kösz

Bug#904692: seahorse: Segfault few seconds after start

[Bernhard Übelacker]

Hello Tobias Bengfort,
I tried to reproduce by just starting seahorse in a VM,
but the crash did not happen here.

Probably you can follow the steps in [1] to locate
where the crash happens?

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

Kind regards,
Bernhard

Bug#860158: python-pbcore: prints warnings with recent h5py on ppc64el

[Graham Inggs]

Control: block -1 by 902553

This will be fixed by h5py 2.8.0.

Bug#904652: Having the same trouble

[Manolinux]

The problem is with a root timidity process:

https://lists.debian.org/debian-user/2018/06/msg00641.html

Killing timidity process make them appear again.



On Sat, 28 Jul 2018 12:50:12 +0200 Manolinux  wrote:
> I have the same issue.
> 
> Strange thing is that alsa detects the devices.
> 
> ---
> $ aplay -l
>  List of PLAYBACK Hardware Devices 
> card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
>   Subdevices: 0/1
>   Subdevice #0: subdevice #0
> card 0: PCH [HDA Intel PCH], device 1: ALC269VB Digital [ALC269VB Digital]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> ---
> 
> But not pulse:
> 
> ---
> $ pacmd list-cards
> 0 card(s) available.
> ---
> 
> VLC can reproduce audio if the sound device is setup trhough alsa.
> anyother test throws the same result: alsa detects the devices without
> error, pulse does not detect de devices (but I didnt see any error).
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#904652: pulseaudio: looses device and replace it with dummy package so no sound possible

[Charlemagne Lasse]

found 904652 11.1-5
thanks

> i didn't do anything.
> Upgrading the system like always.
> Suddenly there was no sound available.

Change /etc/pulse/default.pa to automatically load module-alsa-sink on
boot (module-udev-detect is broken and will not load the alsa-sink
anymore)

This is also a problem in buster (which is still using 11.1-5)

Bug#904828: lilypond: should Suggest python-lxml

[Benjamin Barenblat]

Package: lilypond
Version: 2.19.81+really-2.18.2-13
Severity: wishlist

If you pass `--lxml` to musicxml2ly(1), the program will "use
lxml.etree; uses less memory and cpu time". It would be great if the
package Suggested python-lxml, which is required to use this feature.

Bug#904817: lintian: Warn that depending on both Python 2 and Python 3 interpreters is unusual, likely a mistake?

[Chris Lamb]

Hi Stuart,

> In the upload of translate-toolkit 2.3.0-3, I ended up with the following:
> 
> Depends: python3, python3-pkg-resources, python3-six, python3-translate, 
> python3:any, python:any
> 
> such that the package depended on both the Python 2 and Python 3 interpreters.

Thinking about it, we have:

  
https://lintian.debian.org/tags/python-package-depends-on-package-from-other-python-variant.html

This won't trigger for packages unless they are called /
^python([23]?)-/ however. Indeed, this seems to be required so we
"know" that a package is a "2" or a "3".

Would this have matched otherwise?


Regards,

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

Bug#904715: startxfce4 fails

[Ian MacKinnell]

After failing to log into XFCE ...

I tried a different display manager to lightdm (I installed Slim to no 
avail).


I tried creating a new user account - that did not work.

I also checked the permissions of .Xauthority and various other files - 
no use.


The only thing that worked was...

I used Ctl-Alt-F1 to get a normal terminal, and then installed LXDE (apt 
install task-lxde-desktop). After rebooting I was able to log into LXDE 
without any problem.

Bug#891128: debmake-doc build issue

[Osamu Aoki]

Hi,

On Fri, Jul 27, 2018 at 12:20:14AM +0900, Osamu Aoki wrote:
...
> Still, there are more issues.  I will work on this.

It is no more "make -j1"i for debian/rules.  This was causing somewhat
cryptic failure.   Fixed.

Osamu

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 27 de julio de 2018 20:45:04 -03 John Paul Adrian Glaubitz 
escribió:
> On 07/28/2018 01:41 AM, Manuel A. Fernandez Montecelo wrote:
> > I was using codesearch.d.n and there are 83 that match "qdoc":
> > https://codesearch.debian.net/search?q=%5CWqdoc%5CW
> 
> Wait a minute. How can there be 83 packages already using qdoc when
> Lisandro just uploaded the version of qttools to unstable which first
> contained the qdoc utility. I am confused.

qdoc is a really old utility, comes from qt4 at very least.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#900722: go-mode.el: diff for NMU version 3:1.5.0-1.1

[Hilko Bengen]

* Sean Whitton:

> Okay.  Applied.
>
> I'm not sure why the repo is under the emacsen-team when the package is
> not maintainer.  Perhaps you would be willing to switch it to team
> maintainance.

Sure, that was the intention. I'll change the Maintainer field.

Cheers,
-Hilko

Bug#903128: Acknowledgement (linux-image-4.16.0-2-amd64: bridge stops passing non-local traffic (reversion from 4.16.0-1-amd64))

[Scott Bailey]

New version 4.17.0-1-amd64 fixes this problem for me. This report can be marked 
as resolved and closed.

Thanks,

Scott

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Salvatore Bonaccorso]

Hi Guillem,

On Fri, Mar 02, 2018 at 01:25:51AM +0100, Guillem Jover wrote:
> On Thu, 2018-03-01 at 15:22:30 +, Holger Levsen wrote:
> > On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:
> > > Any news regarding this proposal from Ansgar? We were biten now
> > > several times already by this (e.g. php update, curl via
> > > security.d.o).
> > 
> > Guilem, what's your stance on this bug?
> 
> I think it should be fixed. I've just not come up with something that
> would seem a generic/clean way to do that. :(
> 
> > We (reproducible builds) really dont want "our" tools (=.buildinfo files)
> > to cause grief to other teams in Debian, and especially not on a regular
> > basis... so as a first step to fix this, I'd like to collect opinions
> > how to best fix this issue here.
> 
> The problem got introduced when I proposed changing the filename
> format, and dropping the annoying timestamp. I also though there was
> talk at some point initially about DAK renaming those files to cope
> with possible multiple uploads if the conflicting names?
> 
> Renaming the arch buildinfo to _source.buildinfo seems wrong, and even
> then I'm not sure how to cleanly transfer that knowledge from
> dpkg-buildpackage to dpkg-genbuildinfo.
> 
> I guess, the ideal solution would be to qualify the buildinfo file
> with the builder user and hostname, because that in a way denotes the
> build environment. But that seems like too much leakage. As in:
> 
>   pkgfoo_1.0.0-1_mips64el_username@hostname.buildinfo
> 
> Perhaps just using the maintainer email address might be enough though,
> the one from the -m option or from the changelog, which AFAIR buildds
> do set? But this seems like it can produce quite ugly filenames:
> 
>   
> pkgfoo_1.0.0-1_mips64el_buildd_mipsel-mipsel-sil...@buildd.debian.org.buildinfo
> 
> not to mention that both of these "break" the conventional pattern, which
> is still used by things like the debian/files parser and injector.
> 
> Perhaps the simplest and more correct might be to name it using
> something like source+amd64 as the arch name, which seems like a
> dubious arch, but at least is accurate and might be trivial to
> implement, taking care of not ending up with such fake arch in
> unexpected places…

Do you know, was there any (non-logged) progress for this issue? I'm
asking back since we had for security uploads now since then several
times problems were we had to workaround it by reuploading the buildd
uploads renamed.

Thanks all for your work!

Regards,
Salvatore

Bug#823890: python-openbabel: doc-base error: openbabel and pybel already define html format

[Heine Larsen]

Tags:patch

The two doc-base files for python-openbabel use the same document-id and format 
for two different documents.
As in understand, only different formats of the same document should share 
document-id in doc-base registrations .
Using different document-ids in the "Document:" field solves the conflict.

Heine Larsen

diff -u orig/openbabel-2.4.1+dfsg/debian/python-openbabel.doc-base.openbabel 
openbabel-2.4.1+dfsg/debian/python-openbabel.doc-base.openbabel
--- orig/openbabel-2.4.1+dfsg/debian/python-openbabel.doc-base.openbabel
2018-06-23 14:13:54.0 +0200
+++ openbabel-2.4.1+dfsg/debian/python-openbabel.doc-base.openbabel 2018-07-28 
14:38:12.055348368 +0200
@@ -1,4 +1,4 @@
-Document: python-openbabel
+Document: python-openbabel-openbabel
 Title: pybel Python module for accessing OpenBabel
 Author: The Open Babel Authors 
 Abstract: pybel - A Python module for accessing OpenBabel
diff -u orig/openbabel-2.4.1+dfsg/debian/python-openbabel.doc-base.pybel 
openbabel-2.4.1+dfsg/debian/python-openbabel.doc-base.pybel
--- orig/openbabel-2.4.1+dfsg/debian/python-openbabel.doc-base.pybel   
2018-06-23 14:13:54.0 +0200
+++ openbabel-2.4.1+dfsg/debian/python-openbabel.doc-base.pybel 2018-07-28 
14:38:21.959329275 +0200
@@ -1,4 +1,4 @@
-Document: python-openbabel
+Document: python-openbabel-pybel
 Title: pybel Python module for accessing OpenBabel
 Author: The Open Babel Authors 
 Abstract: pybel - A Python module for accessing OpenBabel

Bug#903804: debmake-doc: Proofreading Comments

[Osamu Aoki]

Hi,

I speak no French but ... (but I used to live in French speaking area)

On Fri, Jul 20, 2018 at 07:27:37AM -0700, Paul Hardy wrote:
> By pure coincidence, the Wikipedia page on gettext shows that gettext
> will correctly translate "My name is %s" into "Je m'appelle %s" in
> French.  So changing the po example on p. 122 of debmake-doc.en.pdf
> from
> 
>   msgid "Hello, I am %s!\n"
> 
> to
> 
>  msgid "Hello, my name is %s!\n"

"I am %s" alone can have 2 translation string options in French since
"%s" may be a name or a job title.  I wasn't paying attention.  Clearly,
this text with "Hello" should be followed by name.
 
> should fix that.  See this excerpt at https://en.wikipedia.org/wiki/Gettext
> 
>  #: src/name.c:36
>  msgid "My name is %s.\n"
>  msgstr "Je m'appelle %s.\n"

Well... true.  But this PO in this document was a variant of "hello
world" program

msgid "Hello.  My name is %s.\n"
msgstr "Bonjour. Je m'appelle %s.\n"

Never blindly trust google translate ;-)

I will work on it.

Osamu 

Bug#883950: Next steps on "[GPL-3+]" proposal

[Stuart Prescott]

>> We now know that we can go ahead with the main proposal to introduce the
>> "[GPL-3+]" notation into our machine-readable copyright format.
[...]
> I can't contribute much to
> the further discussion because I believe the quintessential points were
> already discussed and approved and the only thing left is merely to
> document and announce it.

I do not believe there is anything like consensus on the introduction of 
brackets like this and, to the contrary, I think it is more likely a rough 
consensus that this proposal can proceed *without* the addition of brackets, 
modulo approval from ftp-master. The brackets are cryptic, unnecessarily, 
and complicate the format for those trying to machine parse it (which is, 
after all, a significant reason for the format to exist).

Let us consider this proposed syntax in terms of what someone unfamiliar 
with the format is going to see: 

 Files: foo/*.c
 License: [GPL-3+]

The proposal is that the user is to get from that particular sequence of 8 
characters to the meaning:

 On Debian systems, the complete text of the GNU General Public License,
 can be found in /usr/share/common-licenses/GPL-3.

via documentation such as /usr/share/common-licenses/README and/or 
/etc/motd. 

However, if the user knows to look in some documentation to read "[...] 
means look in /usr/share/common-licenses", then we can equally assume that 
we can just include in the exact same documentation "You will find common 
license texts in /usr/share/common-licenses". Conversely, claiming that a 
user might not find the documentation to know to look in /usr/share/common-
licenses is also to claim that they would not know to look in the 
documentation to find what [...] means.

Either we believe:

* the users can find the docs and the brackets are unnecessary, or

* the users cannot find the docs and this entire proposal to omit the 
boilerplate text is unacceptable.

I do not see a third option where the brackets convey additional 
information.

>From my perspective, the brackets are only making work for people who will 
have to rewrite parsers because the license short names are not the opaque 
tokens originally given in copyright-format/1.0.*

Given they are unnecessary and actively harmful, let's not adopt this 
syntax.


Stuart


* almost opaque, given "+" and the equivalence of trailing dot-zeros


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

Bug#903165: On boot squid.service starts but doesn't work

[Amos Jeffries]

Ah, thank you. I have looked into that network-online.target and it
seems we do need to make it a requirement for Squid to be started. This
should be fixed in the next release.

Amos

Bug#904829: chuck: Adding a shred to a running server leads to the server segfault

[Al Nikolov]

Package: chuck
Version: 1.2.0.8.dfsg-1.5
Severity: important

Dear Maintainer,

Start the server:

%>chuck --loop

>From another shell add a shred:

%>chuck + /usr/share/doc/chuck/examples/basic/foo

The server exits with the message:

[chuck](VM): sporking incoming shred: 1 (foo)...Segmentation fault

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

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

Versions of packages chuck depends on:
ii  libasound21.1.3-5
ii  libc6 2.24-11+deb9u3
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.10+20150825git1ed50c92~dfsg-5
ii  libsndfile1   1.0.27-3
ii  libstdc++66.3.0-18+deb9u1

chuck recommends no packages.

Versions of packages chuck suggests:
ii  jackd  5

-- no debconf information

Bug#904817: lintian: Warn that depending on both Python 2 and Python 3 interpreters is unusual, likely a mistake?

[Stuart Prescott]

Hi Chris,

> https://lintian.debian.org/tags/python-package-depends-on-package-from-othe
> r-python-variant.html
> 
> This won't trigger for packages unless they are called /
> ^python([23]?)-/ however. Indeed, this seems to be required so we
> "know" that a package is a "2" or a "3".
> 
> Would this have matched otherwise?

Only module packages are called python{,3}-foo, while applications packages do 
not have the binary prefix and we have plenty of python applications packages, 
packages that include both applications and private modules or even packages 
that include applications and public modules. For all of them, dependencies on 
both Python runtimes is most likely still incorrect.

This is probably "Certainty: wild guess" material as I'm sure there are a 
handful of legitimate use cases for depending on both Python 2 and Python 3, 
but my feeling is that the vast majority of such dependencies would be 
mistakes.

(yes, if this were python-translate-toolkit then it would have been caught, 
but that package name would also be incorrect for the package)

cheers
Stuart



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

Bug#904817: lintian: Warn that depending on both Python 2 and Python 3 interpreters is unusual, likely a mistake?

[Chris Lamb]

Hi Stuart,

> > This won't trigger for packages unless they are called /
> > ^python([23]?)-/ however
[…]
> Only module packages are called python{,3}-foo, while applications packages 
> do 
> not have the binary prefix

Right, exactly; would your package have triggered this error *if* the
requirement to match /^python([23]?)-/ was not present? :)


Best wishes,

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

Bug#904817: lintian: Warn that depending on both Python 2 and Python 3 interpreters is unusual, likely a mistake?

[Stuart Prescott]

On Saturday, 28 July 2018 15:58:55 AEST Chris Lamb wrote:
> Hi Stuart,
> 
> > > This won't trigger for packages unless they are called /
> > > ^python([23]?)-/ however
> 
> […]
> 
> > Only module packages are called python{,3}-foo, while applications
> > packages do not have the binary prefix
> 
> Right, exactly; would your package have triggered this error *if* the
> requirement to match /^python([23]?)-/ was not present? :)

I believe that is correct, yes.

Stuart

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

Bug#883950: Next steps on "[GPL-3+]" proposal

[Simon McVittie]

On Sun, 29 Jul 2018 at 00:50:34 +1000, Stuart Prescott wrote:
> Let us consider this proposed syntax in terms of what someone unfamiliar 
> with the format is going to see

Along these lines, it might be helpful for people with an interest in
pushing this forward to convert some d/copyright files to their proposed
syntax, as concrete examples of what they're proposing. The ftp team
might also find it easier to approve or reject proposals when looking at
a concrete example?

Having redone its copyright file recently, I can suggest mutter as a
potential test case for this that is non-trivial, but not so verbose
as to be opaque: it has a mixture of various GPL-, LGPL- and BSD-based
licenses, including GPL-2+ with the Autoconf exception.

adwaita-icon-theme is a more pathological example with many Creative
Commons licenses, including at least one that is considered to be
non-Free (but is included in a triple-license with a Free option).

smcv

Bug#904307: stretch-pu: package multipath-tools/0.6.4-5+deb9u1

[Cyril Brulebois]

Hi,

Adam D. Barratt  (2018-07-28):
> Control: tags -1 + moreinfo d-i
> 
> On Mon, 2018-07-23 at 06:34 +, Chris Hofstaedtler wrote:
> > The update would fix #859157, which is causing me headache on our
> > production servers. Basically multipathd just hangs randomly after
> > some time.
> > 
> 
> This looks OK to me, thanks, but as multipath-tools produces a udeb it
> will need a KiBi-ack; CCing and tagging accordingly.

Thanks; looks fine to me.


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


signature.asc
Description: PGP signature

Bug#743948: hwinfo triggers "stack smashing" detector

[Bernhard Übelacker]

Hello,
tried to look if this issue could be closed.
Unfortunately can also not reproduce it in a Debian Jessie i386 VM
with 21.0-1 from snapshot.debian.org.

Following the mail from message #20 [1], it leads to a bug in [2] which
points in the attachement to the function read_klog.

Upstream got a patch in that function in [3] that points to "bnc #870383".
This could possibly be bugzilla.novell.com [4] to which I unfortunately
have no access.


Running 21.0-1 with valgrind points also to that function.

> floppy.1: get nvram==1368== Source and destination overlap in 
> strcpy(0x4b95ab3, 0x4b95ac2)
==1368==at 0x402D536: strcpy (vg_replace_strmem.c:458)
==1368==by 0x4071DD1: read_klog (in /usr/lib/i386-linux-gnu/libhd.so.21.0)
==1368==by 0x405602F: hd_scan_floppy (in 
/usr/lib/i386-linux-gnu/libhd.so.21.0)
==1368==by 0x40602CE: hd_scan (in /usr/lib/i386-linux-gnu/libhd.so.21.0)
==1368==by 0x4060F2C: hd_list (in /usr/lib/i386-linux-gnu/libhd.so.21.0)
==1368==by 0x804C113: ??? (in /usr/sbin/hwinfo)
==1368==by 0x804A00D: ??? (in /usr/sbin/hwinfo)
==1368==by 0x4249A62: (below main) (libc-start.c:287)


Both 21.3-1 and 21.6-1 do not show such a warning with valgrind.

Unfortunately 21.3-1 has already the change from [4] included but
is in message #15 said to still show a stack smashing.


[1] http://lists.opensuse.org/opensuse-factory/2012-08/msg00099.html
[2] https://bugzilla.opensuse.org/show_bug.cgi?id=774430
[3] 
https://github.com/openSUSE/hwinfo/commit/52c8ece11cfa88fa9eca2bf4ed9be844a8077840#diff-2e22318ded9983bf2a7311062a58f18c
[4] https://bugzilla.novell.com/show_bug.cgi?id=870383

Kind regards,
Bernhard

Bug#903804: debmake-doc: Proofreading Comments

[Osamu Aoki]

Hi,


On Fri, Jul 20, 2018 at 07:27:37AM -0700, Paul Hardy wrote:
...
>  #: src/name.c:36
>  msgid "My name is %s.\n"
>  msgstr "Je m'appelle %s.\n"

So my example is French now.
This part needs to be changed too ;-)

For this part, instead of taking your suggestion 
---
-Let's add Japanese translation.
+Let's add Japanese a translation.
---
I changed it to 

Let's add a translation for French.

Osamu

PS: Somehow your patch didn't apply cleanly.  I made my best to merge
it.

Bug#904830: fio not started

[Soukaku]

Package: fio
Version: 3.6-4
Severity: critical
Tags: a11y
Justification: breaks unrelated software

Dear Maintainer,

Even if you try to start fio, the following errors are displayed and can not be 
used.

soukaku@vhost01:[~]$ fio
Illegal instruction

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

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

Versions of packages fio depends on:
ii  glusterfs-common 4.1.2-1
ii  init-system-helpers  1.51
ii  libaio1  0.3.111-1
ii  libc62.27-5
ii  libibverbs1  19.0-1
ii  libnuma1 2.0.11-2.2
ii  librados210.2.5-7.2
ii  librbd1  10.2.5-7.2
ii  librdmacm1   19.0-1
ii  python2.72.7.15-1
ii  zlib1g   1:1.2.11.dfsg-1

fio recommends no packages.

Versions of packages fio suggests:
ii  gfio  3.6-4
ii  gnuplot   5.2.2+dfsg1-2
ii  gnuplot-qt [gnuplot]  5.2.2+dfsg1-2
pn  python-scipy  

-- no debconf information

Bug#904831: [geany-plugin-keyrecord] Please fix short description

[s3v]

Package: geany-plugin-keyrecord
Severity: minor


Dear maintainer,
 please fix short description for geany-plugin-keyrecord package.
Actually this description reads:

 git change bar plugin for Geany

but it is the same as geany-plugin-git-changebar package.

Regards.

Bug#904753: python3-wxgtk4.0: wx.glcanvas.GLCanvas causes segfault

[Scott Talbert]

reassign 904753 libwxgtk3.0-gtk3-0v5
retitle 904753 wxGLCanvas doesn't work on Wayland
forwarded 904753 https://trac.wxwidgets.org/ticket/17702
thanks

On Sat, 28 Jul 2018, Olly Betts wrote:


On Fri, Jul 27, 2018 at 03:24:51PM +0100, David Miguel Susano Pinto wrote:

The GLCanvas class from wx causes a segfault.  This bug was not
present in Debian Jessie [...]


wxpython4.0 isn't available in Jessie (and 4.0 was a complete rewrite,
so comparing with wxpython3.0 is rather meaningless).


The issue is that wxGLCanvas makes X11 calls which crash on Wayland.  I 
have been working on fixing this for a while, but it is taking some time.


Scott

Bug#901180: release notes fails to build in a clean checkout

[Baptiste Jammet]

Bonjour, 

Dixit Laura Arjona Reina, le 09/06/2018 :

>I guess the "transcount" script needs to be adapted to use git instead
>of subversion.

The attached patch works, but the statistics for ca & cs are wrong
because the svn revision tracked now don't match the actual git hash.
And ca & cs translators will need to find the git hash
corresponding to the old svn revision to know where to look back to
update the translation. This have to be done only once, but before to
keep correct stats.

Baptiste
diff --git a/transcount b/transcount
index 2d8c9be2..20c84dd7 100755
--- a/transcount
+++ b/transcount
@@ -21,10 +21,8 @@ if __name__ == "__main__":
 total = sum(sizes.values())
 revisions = {}
 for fn in filenames:
-for attr in os.popen("svn info %s/%s" % (origlang, fn)).readlines():
-if attr.startswith("Last Changed Rev:"):
-_, revision = attr.split(":", 1)
-revisions[fn] = int(revision)
+for attr in os.popen("git log --format=%%H -n 1 %s/%s" % (origlang, fn)).readlines():
+revisions[fn] = attr
 # looking for marker: "^$"
 rev_re = re.compile("^\s*\s*$")
 for lng in targetlangs:
@@ -34,11 +32,11 @@ if __name__ == "__main__":
 match = rev_re.match(line)
 if match:
 revision = int(rev_re.match(line).group(1))
-if revision >= revisions[fn]:
+if revision == revisions[fn]:
 # Current! Count 100%.
 stats += sizes[fn]
 else:
-# SVN revision not current. Count 50%.
+# Git revision not current. Count 50%.
 stats += sizes[fn]/2.
 value = float(stats)/(total/100.)
 print "%s: ~%d%% (~%.2f%%)." % (lng, int(round(value)), value)


pgpSuciiOX5gc.pgp
Description: Signature digitale OpenPGP

Bug#904753: python3-wxgtk4.0: wx.glcanvas.GLCanvas causes segfault

[Scott Talbert]

On Fri, 27 Jul 2018, Carnë Draug wrote:


The GLCanvas class from wx causes a segfault.  This bug was not
present in Debian Jessie, and is also not present when installing
directly from upstream (although I have not yet managed to do it in
Debian).



Are you running on Wayland by chance?


Seems like it.

   $ loginctl show-session 2 -p Type
   Type=wayland

I didn't even knew about it, this seems to be the default since I
never changed it.


This may take some time to fix.  As a workaround, before using GLCanvas, 
you can set:


GDK_BACKEND=x11

and it should work.

Scott

Bug#904832: Have a working su again

[Alf Gaida]

Package: util-linux
Version: 2.32-0.2
Severity: grave

Hi,

Take over /bin/su from login/src:shadow (See #833256)
seems to work fine now - except a few things

as root:
su agaida works fine
su - agaida ask for a password

not really a expected outcome as it break several scripts and
configuration routines - like in jenkins.

Cheers Alf


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

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 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 util-linux depends on:
ii  fdisk  2.32-0.2
ii  libaudit1  1:2.8.3-1+b1
ii  libblkid1  2.32-0.2
ii  libc6  2.27-5
ii  libmount1  2.32-0.2
ii  libpam0g   1.1.8-3.7
ii  libselinux12.8-1+b1
ii  libsmartcols1  2.32-0.2
ii  libsystemd0239-7
ii  libtinfo6  6.1+20180714-1
ii  libudev1   239-7
ii  libuuid1   2.32-0.2
ii  login  1:4.5-1.1
ii  zlib1g 1:1.2.11.dfsg-1

util-linux recommends no packages.

Versions of packages util-linux suggests:
pn  dosfstools  
ii  kbd 2.0.4-3
ii  util-linux-locales  2.32-0.2

-- debconf information:
  util-linux/noauto-with-nonzero-passnum:

Bug#807553: Request for co-maintenance of alfred init script

[Steffen Möller]

Hello,

I am about to upload 2018.2 of alfred. Over here I just start alfred
manually after every boot. Admittedly, an init script would be nicer. I
have seen the one you referenced but I do not think batman-vis etc
should be started together with alfred. That should be another init
script. And, in an ideal world that should be part of the upstream
source tree. We (you) should hence plan to contribute that (these) back.

Please consider to help me out with an explicit patch for me to merge
against https://github.com/ffoh/debian-alfred. I happily grant commit
privileges.

Best,

Steffen