Bug#905555: emacs-nox: fails to upgrade from 47.0

[Sven Joachim]

Package: emacs-nox
Version: 1:25.2+1-9
Severity: serious

Upgrading emacs-nox from 47.0 failed in a chroot for me:

,
| # apt-get dist-upgrade
| Reading package lists... Done
| Building dependency tree   
| Reading state information... Done
| Calculating upgrade... Done
| The following package was automatically installed and is no longer required:
|   emacs25-nox
| Use 'sudo apt autoremove' to remove it.
| The following packages will be REMOVED:
|   emacs25-bin-common emacs25-common
| The following NEW packages will be installed:
|   emacs-bin-common emacs-common
| The following packages will be upgraded:
|   emacs-nox emacs25-nox emacsen-common
| 3 upgraded, 2 newly installed, 2 to remove and 0 not upgraded.
| Need to get 0 B/16.3 MB of archives.
| After this operation, 78.8 kB disk space will be freed.
| Do you want to continue? [Y/n] 
| debconf: delaying package configuration, since apt-utils is not installed
| (Reading database ... 15154 files and directories currently installed.)
| Preparing to unpack .../emacs25-nox_1%3a25.2+1-9_all.deb ...
| Remove emacsen-common for emacs25
| emacsen-common: Handling removal of emacsen flavor emacs25
| Unpacking emacs25-nox (1:25.2+1-9) over (25.2+1-6+b3) ...
| (Reading database ... 15146 files and directories currently installed.)
| Removing emacs25-bin-common (25.2+1-6+b3) ...
| Removing emacs25-common (25.2+1-6) ...
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/scalable/mimetypes' not empty so not removed
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/scalable/apps' not empty so not removed
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/48x48/apps' not empty so not removed
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/32x32/apps' not empty so not removed
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/24x24/apps' not empty so not removed
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/16x16/apps' not empty so not removed
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/128x128/apps' not empty so not removed
| (Reading database ... 12537 files and directories currently installed.)
| Preparing to unpack .../emacsen-common_3.0.2_all.deb ...
| Unpacking emacsen-common (3.0.2) over (2.0.8) ...
| dpkg: warning: unable to delete old directory '/etc/emacs/site-start.d': 
Directory not empty
| dpkg: warning: unable to delete old directory '/etc/emacs': Directory not 
empty
| Selecting previously unselected package emacs-common.
| Preparing to unpack .../emacs-common_1%3a25.2+1-9_all.deb ...
| Unpacking emacs-common (1:25.2+1-9) ...
| Selecting previously unselected package emacs-bin-common.
| Preparing to unpack .../emacs-bin-common_1%3a25.2+1-9_i386.deb ...
| Unpacking emacs-bin-common (1:25.2+1-9) ...
| Preparing to unpack .../emacs-nox_1%3a25.2+1-9_i386.deb ...
| dpkg-query: no packages found matching emacs-nox:i386
| dpkg-query: package 'emacs-nox' is not installed
| Use dpkg --info (= dpkg-deb --info) to examine archive files,
| and dpkg --contents (= dpkg-deb --contents) to list their contents.
| dpkg-maintscript-helper: error: file '/usr/share/doc/emacs-nox' not owned by 
package 'emacs-nox:i386'
| dpkg-query: package 'emacs-nox' is not installed
| Use dpkg --info (= dpkg-deb --info) to examine archive files,
| and dpkg --contents (= dpkg-deb --contents) to list their contents.
| dpkg-maintscript-helper: error: file '/usr/share/doc/emacs-nox/copyright' not 
owned by package 'emacs-nox:i386'
| dpkg-query: package 'emacs-nox' is not installed
| Use dpkg --info (= dpkg-deb --info) to examine archive files,
| and dpkg --contents (= dpkg-deb --contents) to list their contents.
| dpkg-maintscript-helper: error: file '/usr/share/doc/emacs-nox/changelog.gz' 
not owned by package 'emacs-nox:i386'
| dpkg-maintscript-helper: error: directory '/usr/share/doc/emacs-nox' contains 
files not owned by package emacs-nox:i386, cannot switch to symlink
| dpkg: error processing archive 
/var/cache/apt/archives/emacs-nox_1%3a25.2+1-9_i386.deb (--unpack):
|  new emacs-nox package pre-installation script subprocess returned error exit 
status 1
| Errors were encountered while processing:
|  /var/cache/apt/archives/emacs-nox_1%3a25.2+1-9_i386.deb
| E: Sub-process /usr/bin/dpkg returned an error code (1)
`

The "dpkg-query: no packages found matching emacs-nox:i386" error
message looks suspicious, this really should not happen.


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

Kernel: Linux 4.18.0-rc8-nouveau (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 

Bug#905554: vim-syntastic: Removal or upgrade failed in vim-syntastic.prerm

[Xavier POINSARD]

Package: vim-syntastic
Version: 3.7.0-1+deb9u2
Severity: important

Dear Maintainer,

   * What led up to the situation?

Tried to remove the package since not used and concerned by security issue.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

sudo apt remove vim-syntastic

   * What was the outcome of this action?

Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  javascript-common libjs-jquery libruby2.1 libyaml-0-2 ruby2.1 
rubygems-integration vim-addon-manager
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  vim-syntastic
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 782 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 101184 files and directories currently installed.)
Removing vim-syntastic (3.7.0-1+deb9u2) ...
/var/lib/dpkg/info/vim-syntastic.prerm: 22: 
/var/lib/dpkg/info/vim-syntastic.prerm: vim-addon-manager: not found
dpkg: error processing package vim-syntastic (--remove):
 subprocess installed pre-removal script returned error exit status 127
Errors were encountered while processing:
 vim-syntastic

   * What outcome did you expect instead?

I expect the package to be removed.


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

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

Versions of packages vim-syntastic depends on:
ii  vim2:8.0.0197-4+deb9u1
ii  vim-addon-manager  0.5.6

vim-syntastic recommends no packages.

Versions of packages vim-syntastic suggests:
pn  checkstyle   
pn  chktex   
pn  closure-linter   
pn  cppcheck 
pn  foodcritic   
pn  hlint
pn  lacheck  
pn  libperl-critic-perl  
pn  libxml2-utils
pn  pep8 
pn  puppet-lint  
pn  pyflakes 
pn  pylint   
pn  python-flake8
pn  sparse   
pn  splint   
pn  tidy 

-- no debconf information

Bug#889780: O: stomper -- Python client implementation of the STOMP protocol

[Sergio Durigan Junior]

On Tuesday, February 06 2018, Tobias Frost wrote:

> The current maintainer of stomper, Simon Chopin  ,
> is apparently not active anymore.  Therefore, I orphan this package now.

Hi Tobias,

The stomper package is maintained by the Debian Python Modules Team
(DPMT); Simon is (was?) listed as an Uploader, not the maintainer.  I
don't think it's accurate to list the package as orphaned.

Cheers,

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


signature.asc
Description: PGP signature

Bug#905553: libdbus-glib-1-dev: install dbus-binding-tool into a Multi-Arch: foreign package

[Helmut Grohne]

Package: libdbus-glib-1-dev
Version: 0.110-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: block 873617 by -1
Control: affects -1 + src:ayatana-indicator-application src:cinnamon-session 
src:cinnamon-settings-daemon src:libunique src:mate-session-manager 
src:mate-settings-daemon src:notify-osd

Hi Simon,

I know you don't want to work on this package anymore. Yet it seems to
me that actual deprecation (like python2) is still quite far away. The
shared library has popcon rank <400 and reverse dependencies such as
firefox or libreoffice. The last upstream release happend in 2018. This
doesn't look that deprecated to me.

The affected packages fail to cross build from source, because they fail
to execute dbus-binding-tool. What needs doing is moving them to a
separate package that is marked Multi-Arch: foreign. This is less than
#873617 is asking for.

I know that you don't want to work on this package. As per constitution
you are not obliged to do the work. I therefore offer NMUing this patch.
Please raise your concerns if any.

Helmut
diff --minimal -Nru dbus-glib-0.110/debian/changelog 
dbus-glib-0.110/debian/changelog
--- dbus-glib-0.110/debian/changelog2018-01-30 11:37:38.0 +0100
+++ dbus-glib-0.110/debian/changelog2018-08-05 21:11:01.0 +0200
@@ -1,3 +1,10 @@
+dbus-glib (0.110-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Split dbus-binding-tool to a Multi-Arch: foreign package. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 05 Aug 2018 21:11:01 +0200
+
 dbus-glib (0.110-2) unstable; urgency=medium
 
   * d/rules: Transcode to UTF-8
diff --minimal -Nru dbus-glib-0.110/debian/control 
dbus-glib-0.110/debian/control
--- dbus-glib-0.110/debian/control  2018-01-30 11:37:38.0 +0100
+++ dbus-glib-0.110/debian/control  2018-08-05 21:11:01.0 +0200
@@ -50,6 +50,7 @@
 Depends:
  libdbus-1-dev (>= 1.1),
  libdbus-glib-1-2 (= ${binary:Version}),
+ libdbus-glib-1-dev-bin (= ${binary:Version}),
  libglib2.0-dev,
  ${misc:Depends},
  ${shlibs:Depends},
@@ -63,6 +64,28 @@
  .
  See the dbus description for more information about D-Bus in general.
 
+Package: libdbus-glib-1-dev-bin
+Section: oldlibs
+Architecture: any
+Multi-Arch: foreign
+Pre-Depends:
+ ${misc:Pre-Depends},
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Breaks: libdbus-glib-1-dev (<< 0.110-2.1~)
+Replaces: libdbus-glib-1-dev (<< 0.110-2.1~)
+Description: deprecated library for D-Bus IPC (development tools)
+ D-Bus is a message bus, used for sending messages between applications.
+ Conceptually, it fits somewhere in between raw sockets and CORBA in
+ terms of complexity.
+ .
+ This package provides development tools for a deprecated GLib-based
+ D-Bus library. New code should use GDBus, part of GLib, instead.
+ If you must use this implementation, use libdbus-glib-1-dev.
+ .
+ See the dbus description for more information about D-Bus in general.
+
 Package: libdbus-glib-1-doc
 Build-Profiles: 
 Section: doc
diff --minimal -Nru dbus-glib-0.110/debian/libdbus-glib-1-dev-bin.install 
dbus-glib-0.110/debian/libdbus-glib-1-dev-bin.install
--- dbus-glib-0.110/debian/libdbus-glib-1-dev-bin.install   1970-01-01 
01:00:00.0 +0100
+++ dbus-glib-0.110/debian/libdbus-glib-1-dev-bin.install   2018-08-05 
21:10:56.0 +0200
@@ -0,0 +1,2 @@
+debian/tmp/usr/bin/dbus-binding-tool
+debian/tmp/usr/share/man/man1/dbus-binding-tool.1*
diff --minimal -Nru dbus-glib-0.110/debian/libdbus-glib-1-dev.install 
dbus-glib-0.110/debian/libdbus-glib-1-dev.install
--- dbus-glib-0.110/debian/libdbus-glib-1-dev.install   2018-01-30 
11:37:38.0 +0100
+++ dbus-glib-0.110/debian/libdbus-glib-1-dev.install   2018-08-05 
21:10:53.0 +0200
@@ -1,6 +1,4 @@
-debian/tmp/usr/bin/dbus-binding-tool
 debian/tmp/usr/include/dbus*/dbus/*.h
 debian/tmp/usr/lib/*/libdbus-glib-*.a
 debian/tmp/usr/lib/*/libdbus-glib-*.so
 debian/tmp/usr/lib/*/pkgconfig/dbus-glib-1.pc
-debian/tmp/usr/share/man/man1/dbus-binding-tool.1*

Bug#898535: closed by Chow Loong Jin (Bug#898535: fixed in tinyxml2 6.2.0+dfsg-2)

[Chow Loong Jin]

On Sun, Aug 05, 2018 at 01:38:31PM +0200, Joachim Reichel wrote:
> On 03.08.2018 06:03, Debian Bug Tracking System wrote:
> > Changes:
> >  tinyxml2 (6.2.0+dfsg-2) unstable; urgency=medium
> >  .
> >* [7fdca1f] Rename package for abi break (Closes: #898535)
> 
> How do you plan to deal with the breakage that results from the renaming? Did
> you already ask for binNMUs?

No I haven't, but I plan to.

> I do not see a bug report that requests a
> transition slot, nor any discussion on debian-release.

Whoops, I was just going to binNMU all rdeps and be done with it since
it was a pretty short list. Considering that the current libtinyxml2-6
has already broken ABI, should I have requested and waited for a
transition slot instead?

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#905467: lintian: Please detect source-only non-free uploads w/o opt-in autobuild

[Chris Lamb]

Chris Lamb wrote:

> Updated in:
> 
>   […]

That should have been:

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


Regards,

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

Bug#861635: Why was I removed as the owner?

[Jason Gauci]

Also why is this changed to RFP?  I'm more than happy to maintain this
package since I'm the author :-)

Jason G.

Bug#904685: diffoscope: RuntimeError when trying to extract an encrypted file (.bmp)

[Chris Lamb]

fowarded 904685 
https://salsa.debian.org/reproducible-builds/diffoscope/merge_requests/10
thanks

Hi Ricardo,

> We can move this discussion over to the MR if that suits better. Just let
> me know.

Have responded on the merge request & let's move over there.


Regards,

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

Bug#905552: gamemode: Incomplete debian/copyright?

[Chris Lamb]

Source: gamemode
Version: 1.2-3
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Jonathan Carter , ftpmas...@debian.org

Hi,

I just ACCEPTed gamemode from NEW but noticed it was missing 
attribution in debian/copyright for at least what looks like a
inih code copy under the subprojects dir.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#905188: cryptsetup-initramfs: fails to install, remove, distupgrade, and install again

[Andreas Beckmann]

Followup-For: Bug #905188
Control: found -1 2:2.0.4-1
Control: tag -1 - moreinfo

That needs more work and testing ...
right now the package fails to install in sid.

  Selecting previously unselected package cryptsetup-initramfs.
  (Reading database ... 
(Reading database ... 5042 files and directories currently installed.)
  Preparing to unpack .../cryptsetup-initramfs_2%3a2.0.4-1_all.deb ...
  md5sum: /etc/cryptsetup-initramfs/conf-hook: No such file or directory
  /var/lib/dpkg/tmp.ci/preinst: 54: /var/lib/dpkg/tmp.ci/preinst: cannot create 
/etc/cryptsetup-initramfs/conf-hook.dpkg-new: Directory nonexistent
  dpkg: error processing archive 
/var/cache/apt/archives/cryptsetup-initramfs_2%3a2.0.4-1_all.deb (--unpack):
   new cryptsetup-initramfs package pre-installation script subprocess returned 
error exit status 2
  Errors were encountered while processing:
   /var/cache/apt/archives/cryptsetup-initramfs_2%3a2.0.4-1_all.deb


Andreas

Bug#905469: lintian: Please emit tag on direct access to dpkg database

[Guillem Jover]

Hi!

On Sun, 2018-08-05 at 05:37:15 +0100, Chris Lamb wrote:
> > This is one blocker that is getting in the way of deploying mtree
> > support as the dpkg database store, because .list, .md5sums and
> > .conffiles are intended to disappear from under /var/lib/dpkg/info/
> > and that will break all these packages and programs.
> 
> Ah, neat. I wasn't aware of this proposal and I hope Lintian can help
> get us to that quicker. (Is there a wishlist bug or similar with more
> info about this, just out of interest?)



> >   * Using «dpkg --status» for package status.
> >   * Using «dpkg --status» for Conffiles field.
> >   * Using «dpkg-query --listfiles» for file lists.
> >   * Using «dpkg-query --control-(list|show)» to get control file
> > information.
> 
> Cool. So, some quick questions:
> 
>  * Are there some existing packages that currently break that we can
>crib as testcases? 

Many, starting from codesearch.debian.net, I'm counting on the order of
100 or surroundings, after having downloaded them all and being in the
process of removing false-positives. Here are some examples:

 * .list
   - python-pyhsm.preinst
   - popularity-contest/popularity-contest
   - goplay/src/goplay.cpp

 * .md5sums
   - config-package-dev/dh_configpackage

 * .conffiles
   - hylafax-server.postinst (this one is in addition doubly bogus,
  as md5sums do not contain conffiles)
   - geda-symbols.postrm

 * .shlibs
   - libreoffice/debian/rules

 * .postinst
   - propellor/src/Propellor/Property/Ssh.hs
   - kickseed/setup/hd
   - lxc/templates/lxc-debian.in

 * /var/lib/dpkg/triggers/ (wow was not expecting this one)
   - ca-certificates-mono.postinst (should be a versioned dependency
instead, but some introspection
support from dpkg's side might be
nice)

>  * What files should actually be checked? We wouldn't want to fire on
>docs, just as one obvious example.

Right. I think in this case at least all binary packages, in the same
way we are now checking the sensible-utils stuff. Ideally also the
source package, because I've seen bogus usage there, but I fear, that
is prone to many false-positives, and it might be more difficult to
distinguish those there, so perhaps only the source packaging bits?

>  * What sort of severity level would you be looking for?

I'd probably distinguish between:

  - important: mtree-blockers (.list, .conffiles, .md5sums)
  - normal/pedantic: harmful maint-script case, as there's no other
available solution, info as long as it uses dpkg-query --control-path
interface, otherwise warnings (.prerm, .postrm)
  - normal: any other general control file

>  * Could you write a quick tag description? What you wrote in the
>introduction to this tag would be a good start at the very least.

Ok how about something like the descriptions for these as three new
tags, as a starting point?

,--- .list/.md5sums/.conffiles ---
Info: This file is internal to dpkg, and will disappear and change format.
 In addition for .conffiles and .md5sums the contents did not reflect
 pathname take overs from other packages.
 .
 Use the following interfaces instead:
 * «dpkg-query --listfiles » for .list.
 * «dpkg-query --control-show  md5sums» for .md5sums.
 * «dpkg-query -W -f='${Conffiles}' » for .conffiles.
`---

,--- .prerm/.postrm ---
Info: This file is stored within the internal dpkg database, and might
 get relocated, change storage format, and is not intended to be used
 directly by any other programs besides the dpkg suite of packages. That
 the current plain text formats and filesystem layout of the database is
 administrator friendly is by design, but that does not extend to other
 programs.
 .
 But as there might be cases where these maintainer scripts contain harmul
 code that perform irreversible actions that cannot be undone during
 postinst, it might be necessary to modify or remove them from the dpkg
 database. Even though this is very strongly discouraged, it is currently
 acceptabled as an exception, due to dpkg not providing yet any interface
 to solve this problem.
 .
 To get the pathname of those maintainer-scripts use
 «dpkg-query --control-path  »
 which will use the correct admindir, and internal database path. Even
 though the --control-path command is deprecated, it is acceptable to
 be used for this particular purpose only.
Ref: 
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_dpkg_be_told_to_avoid_invoking_a_harmful_prerm_or_postrm_from_an_installed_package_on_upgrade.3F
`---

,--- other database files ---
Info: This file is stored within the internal dpkg database, and might
 get relocated, change storage format, and is not intended to be used
 directly by any other programs besides the dpkg suite of packages. That
 the

Bug#905235: purge + install (not just upgrade) is broken

[Trent W. Buck]

Just in case it's not obvious,

  • emacs/testing & emacs-goodies/testing are installed
  • purge emacs-goodies-el/testing
  • install emacs-goodies-el/unstable

…has the same behaviour as

  • emacs/testing & emacs-goodies/testing are installed
  • upgrade emacs-goodies-el from /testing to /unstable

This seems to work though:

  • emacs/testing & emacs-goodies/testing are installed
  • purge emacs-goodies-el/testing
  • delete /usr/share/emacs25/site-lisp/emacs-goodies-el
  • install emacs-goodies-el/unstable
bash4$ dpkg-query -W emacs emacs25-lucid emacs-goodies-el
emacs   47.0
emacs-goodies-el
emacs25-lucid   25.2+1-6+b3
bash4$ sudo apt-get install emacs-goodies-el/unstable
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Selected version '40.0' (Debian:unstable [all]) for 'emacs-goodies-el'
Recommended packages:
  elpa-bm
The following NEW packages will be installed:
  emacs-goodies-el
0 upgraded, 1 newly installed, 0 to remove and 20 not upgraded.
Need to get 0 B/96.4 kB of archives.
After this operation, 265 kB of additional disk space will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell 
buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
Selecting previously unselected package emacs-goodies-el.
(Reading database ... 151916 files and directories currently installed.)
Preparing to unpack .../emacs-goodies-el_40.0_all.deb ...
Unpacking emacs-goodies-el (40.0) ...
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell 
buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
Processing triggers for install-info (6.5.0.dfsg.1-4) ...
Setting up emacs-goodies-el (40.0) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
Install emacs-goodies-el for emacs25
install/emacs-goodies-el: Handling emacs25, logged in /tmp/elc_COBIYx.log
Building autoloads for emacs25 in /usr/share/emacs25/site-lisp/emacs-goodies-el
ERROR: install script from emacs-goodies-el package failed
dpkg: error processing package emacs-goodies-el (--configure):
 installed emacs-goodies-el package post-installation script subprocess 
returned error exit status 1
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell 
buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
Errors were encountered while processing:
 emacs-goodies-el
[master 62d06a5] committing changes in /etc after apt run
 Author: twb 
 2 files changed, 20 insertions(+)
 create mode 100644 emacs/site-start.d/50emacs-goodies-el.el
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ==

-  Show old opportunities as well as new ones: how-can-i-help --old  -
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
bash4$ cat /tmp/elc_COBIYx.log
emacs25 -batch --no-site-file --multibyte --eval (setq load-path (cons "." 
load-path)) -l autoload --eval (setq generated-autoload-file (expand-file-name 
"emacs-goodies-loaddefs.el")) --eval (setq make-backup-files nil) -f 
batch-update-autoloads .
Warning (initialization): Ignoring obsolete arg --multibyte
align-string.el:0:0: error: file-error: (Opening input file No such file or 
directory /usr/share/emacs25/site-lisp/emacs-goodies-el/align-string.el)
bash4$ sudo dpkg -P emacs-goodies-el
(Reading database ... 151937 files and directories currently installed.)
Removing emacs-goodies-el (40.0) ...
Remove emacs-goodies-el for emacs25
remove/emacs-goodies-el: purging byte-compiled files for emacs25
Purging configuration files for emacs-goodies-el (40.0) ...
Processing triggers for install-info (6.5.0.dfsg.1-4) ...
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell 
buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
bash4$ sudo find /usr /etc -xdev -name align-string.el -ls
   598145  4 lrwxrwxrwx   1 root root   59 Aug  2 11:13 
/usr/share/emacs25/site-lisp/emacs-goodies-el/align-string.el -> 
/usr/share/emacs/site-lisp/emacs-goodies-el/align-string.el
bash4$ dpkg-query -W emacs emacs25-lucid emacs-goodies-el
emacs   47.0
emacs-goodies-el
emacs25-lucid   25.2+1-6+b3
bash4$ dpkg -S /usr/share/emacs25/site-lisp/emacs-goodies-el
dpkg-query: no path found matching pattern 
/usr/share/emacs25/site-lisp/emacs-goodies-el
bash4$ sudo rm -rf /usr/share/emacs25/site-lisp/emacs-goodies-el
bash4$ sudo apt-get install emacs-goodies-el/unstable
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Selected version '40.

Bug#905467: lintian: Please detect source-only non-free uploads w/o opt-in autobuild

[Chris Lamb]

Hi Guillem & Niels,

> > I seem to recall that "XS-Autobuild: Yes" requires being added to a
> > whitelist as well
[…]
> Yes, this is item 3 from the dev-ref link I provided. And I agree it's
> probably worth mentioning, or just pointing people to read the dev-ref
> for the most up-to-date process.

Updated in:

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


Regards,

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

Bug#905485: chrony: AppArmor in complain mode

[Kurt Roeckx]

On Sun, Aug 05, 2018 at 09:29:35PM +0200, Vincent Blut wrote:
> Hi Kurt,
> 
> On Sun, Aug 05, 2018 at 11:58:38AM +0200, Kurt Roeckx wrote:
> > Package: chrony
> > Version: 3.3-2
> > 
> > Hi,
> > 
> > Why is the AppArmor profile put into complain mode?
> 
> To avoid breaking chrony installations due to our (at the time) immature
> AppArmor profile for users upgrading to chrony 3.2-2. For new installs the
> profile is placed into “enforce” mode though.
> 
> > The preinst has this:
> > case "$1" in
> >upgrade)
> >APP_PROFILE="usr.sbin.chronyd"
> >APP_CONFFILE="/etc/apparmor.d/$APP_PROFILE"
> >APP_COMPLAIN="/etc/apparmor.d/force-complain/$APP_PROFILE"
> ># force-complain on upgrade from pre-shipped profile
> >if dpkg --compare-versions "$2" lt "3.2-2" ; then
> >mkdir -p `dirname "$APP_COMPLAIN"` 2>/dev/null || true
> >ln -sf "$APP_CONFFILE" "$APP_COMPLAIN"
> >fi
> >;;
> > 
> > 
> > What pre-shipped profiles is this about?
> 
> Pre-shipped profile corresponds to any chrony version lacking an AppArmor
> profile (i.e. chrony versions < 3.2-2).
> 
> > It seems to trigger for every upgraded, and I don't understand why.
> 
> Hope the above makes things clearer‽

Not really. As far as I know I have this new profile, but because
I upgraded I'm stuck in complain mode, even tough enforce mode
should work just fine. And I don't see the point.

You've installed a new profile, so it should work. Since it's a
config file, I might have edited it, but if it doesn't work it's
really my problem.



Kurt

Bug#905551: mutt: add OAUTHBEARER auth support

[Jonathan Nieder]

Jonathan Nieder wrote:

> I'll send a debdiff in a separate message.

Patch attached.  Thoughts of all kinds welcome.
>From 31e72e18b9a9c97d67b685bbbe5b1278f5381835 Mon Sep 17 00:00:00 2001
From: Jonathan Nieder 
Date: Sun, 5 Aug 2018 17:32:40 -0700
Subject: Apply Brandon Long's oauthbearer patches

---
 debian/changelog  |  11 +
 debian/patches/series |   3 +
 .../upstream/905551-oauthbearer-imap.patch| 237 +
 .../upstream/905551-oauthbearer-refresh.patch | 467 ++
 .../upstream/905551-oauthbearer-smtp.patch| 190 +++
 5 files changed, 908 insertions(+)
 create mode 100644 debian/patches/upstream/905551-oauthbearer-imap.patch
 create mode 100644 debian/patches/upstream/905551-oauthbearer-refresh.patch
 create mode 100644 debian/patches/upstream/905551-oauthbearer-smtp.patch

diff --git a/debian/changelog b/debian/changelog
index cc82620c..8dc191d7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+mutt (1.10.1-2) UNRELEASED; urgency=low
+
+  * debian/patches:
++ added upstream patches for OAUTHBEARER support by Brandon Long
+  (Closes: #905551).
+  + upstream/905551-oauthbearer-imap.patch
+  + upstream/905551-oauthbearer-smtp.patch
+  + upstream/905551-oauthbearer-refresh.patch
+
+ -- Jonathan Nieder   Sun, 05 Aug 2018 17:31:32 -0700
+
 mutt (1.10.1-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/patches/series b/debian/patches/series
index a19d2d26..12be8181 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,6 @@ debian-specific/828751-pinentry-gpg2-support.patch
 misc/gpg.rc-paths.patch
 misc/smime.rc.patch
 upstream/528233-readonly-open.patch
+upstream/905551-oauthbearer-imap.patch
+upstream/905551-oauthbearer-smtp.patch
+upstream/905551-oauthbearer-refresh.patch
diff --git a/debian/patches/upstream/905551-oauthbearer-imap.patch b/debian/patches/upstream/905551-oauthbearer-imap.patch
new file mode 100644
index ..06159d1c
--- /dev/null
+++ b/debian/patches/upstream/905551-oauthbearer-imap.patch
@@ -0,0 +1,237 @@
+From: Brandon Long 
+Date: Mon, 11 Jun 2018 10:39:49 -0700
+Subject: Initial support for OAUTHBEARER for IMAP.
+
+commit 798f749eeeb98ed04028521a2eb3e505c1a83574 upstream.
+
+Gmail supports RFC 7628 for using OAUTH with IMAP, and they really don't
+like you using password based auth.  You can still enable "less secure
+apps" and then generate an application specific password, but I figured it
+was time to support it.
+
+Being mutt, I punted on some of the "hard" work to an external script, ie
+getting/refreshing the OAUTH tokens.  This avoids the issue of how do you
+have a client-id and client-secret for an open source project, and the fact
+that OAUTH discovery is still nascent, so you'd likely need separate things
+for each of the providers.
+
+At least for Gmail, you can use the oauth2.py script from Google's
+gmail-oauth2-tools:
+https://github.com/google/gmail-oauth2-tools/blob/master/python/oauth2.py
+
+You'd need to get your own oauth client credentials for Gmail here:
+https://console.developers.google.com/apis/credentials
+
+Then, you'd use oauth2.py with --generate_oauth2_token to get a refresh
+token, and configure mutt with:
+
+set imap_authenticators="oauthbearer"
+set imap_user=""
+set imap_pass=`/path/to/oauth2.py --quiet --user=
+--client_id= --client_secret=
+--refresh_token=`
+
+For this patch, I didn't add any new configuration, but I'm open to
+suggestions on that.
+
+The patch also only support SASL-IR to reduce round-trips to the server,
+but it's certainly possible to change that if we think there are
+OAUTHBEARER IMAP servers that don't support SASL-IR.  It also requires the
+connection to be encrypted as the access token is re-usable for an hour or
+so.  Again, Gmail only allows encrypted IMAP connections, not sure if any
+OAUTHBEARER services allow non-encrypted.
+
+Turns out that auth failure leaves you in SASL mode, so I have a hack to
+issue a noop command on error.  Not sure if that's just OAUTHBEARER
+oddness, or whether I should be using lower level mutt imap functions.
+---
+ imap/Makefile.am|   7 +--
+ imap/auth.c |   1 +
+ imap/auth.h |   1 +
+ imap/auth_oauth.c   | 104 
+ imap/command.c  |   1 +
+ imap/imap_private.h |   1 +
+ 6 files changed, 112 insertions(+), 3 deletions(-)
+ create mode 100644 imap/auth_oauth.c
+
+diff --git a/imap/Makefile.am b/imap/Makefile.am
+index 527b044f..199f6d6b 100644
+--- a/imap/Makefile.am
 b/imap/Makefile.am
+@@ -13,12 +13,13 @@ else
+ AUTHENTICATORS = auth_anon.c auth_cram.c
+ endif
+ 
+-EXTRA_DIST = README TODO auth_anon.c auth_cram.c auth_gss.c auth_sasl.c
++EXTRA_DIST = README TODO auth_anon.c auth_cram.c auth_gss.c auth_oauth.c \
++	auth_sasl.c
+ 
+ AM_CPPFLAGS = -I$(top_srcdir) -I../intl
+ 
+ noinst_LIBRARIES = libimap.a
+ noinst_HEADERS = auth.h imap_private.h mess

Bug#905522: ghdl: Incomplete debian/copyright?

[Chris Lamb]

[adding Thorsten Alteholz  to CC]

Hi Andreas,

> > I just ACCEPTed ghdl from NEW but the FTP team noticed it was missing the
> > entire text of the CC license.
> 
> First, thanks for the ACCEPT.
> 
> The missing text of the CC license was the reason the package was
> rejected months ago. I included the full text in debian/copyright, among
> many other changes that came with using a more recent upstream which
> changes the library organization. Is there really still something
> missing (and what) or is this maybe some outdated ftpmaster notes for
> ghdl sticking around?

This is possible.

CCing in Thorsten Alteholz and quoting in full; as it was his note.
Thorsten, can you comment here?


Best wishes,

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

Bug#905550: pbuilder: Use a cgroup to allow cleaning up stray build processes

[Daniel Schepler]

As it happens, my patch just caught one of these cases in my local
setup to test builds of all packages from the archive.  So, I can now
provide sample output:

make[1]: Leaving directory '/build/fwupd-1.1.0'
dpkg-genbuildinfo --build=binary
dpkg-genchanges --build=binary >../fwupd_1.1.0-7+bpb1_amd64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
dpkg-source --after-build fwupd-1.1.0
dpkg-buildpackage: info: binary-only upload (no source included)
I: copying local configuration
I: unmounting /var/cache/pbuildd filesystem
I: unmounting dev/pts filesystem
I: unmounting dev/shm filesystem
I: unmounting proc filesystem
I: unmounting sys filesystem
W: Cleaning up stray processes from build
* system-pbuilder-27742.slice
  Loaded: loaded
  Active: active since Sun 2018-08-05 16:49:17 PDT; 2min 23s ago
   Tasks: 1
  Memory: 770.5M
  CGroup: /system.slice/system-pbuilder.slice/system-pbuilder-27742.slice
  `-run-rf0fc6f2d6b3b45f7b652a09facf17199.scope
`-16261 gpg-agent --homedir
/tmp/fwupd-self-test/var/lib/fwupd/gnupg --use-standard-socket
--daemon

Aug 05 16:49:17 frobozz systemd[1]: Created slice system-pbuilder-27742.slice.
I: cleaning the build env
I: removing directory /build/chroot-amd64/ and its subdirectories
I: Current time: Sun Aug  5 16:51:41 PDT 2018
I: pbuilder-time-stamp: 1533513101
-- 
Daniel Schepler

Bug#905551: mutt: add OAUTHBEARER auth support

[Jonathan Nieder]

Package: mutt
Version: 1.10.1-1
Severity: wishlist
Tags: upstream patch fixed-upstream

Hi,

As described in
http://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20180611/000121.html,
Gmail supports RFC 7628 for oauth as a way of avoiding password based
auth.  Applying three upstream patches gets mutt to support this
reasonably well:

1. 798f749eeeb98ed04028521a2eb3e505c1a83574 (Initial support for
   OAUTHBEARER for IMAP, 2018-06-11)

2. fcd333986c0d15dec67870b7b74fef0e00e8c28b (Support for using
   OAUTHBEARER for smtp, 2018-06-12)

3. 98cc42365ac97b0dfeafadf5561043e06744fcf6 (Improve OAUTHBEARER
   support, 2018-06-26)

I'm running with those now, with the following configuration:

  set from=@gmail.com
  set folder=imaps://@gmail@imap.gmail.com/
  set smtp_url=smtps://@gmail@smtp.gmail.com:465/
  set spoolfile==INBOX
  set imap_authenticators="oauthbearer"
  set imap_user="@gmail.com"
  set imap_oauth_refresh_command="$HOME/bin/oauth2.py --quiet 
--user=@gmail.com --client_id= --client_secret= 
--refresh_token="
  set smtp_authenticators="oauthbearer"
  set smtp_oauth_refresh_command="$HOME/bin/oauth2.py --quiet 
--user=@gmail.com --client_id= --client_secret= 
--refresh_token="

It works like a charm.  oauth2.py is [1].   is $USER.  ,
, and  were generated following the
instructions at [2].

All three patches are in mutt "master", but I don't know how long it
will be until the next upstream release.  What do you think of
applying the patches in the meantime?  I'll send a debdiff in a
separate message.

Thanks,
Jonathan

[1] python/oauth2.py in https://github.com/google/gmail-oauth2-tools
[2] 
https://github.com/google/gmail-oauth2-tools/wiki/OAuth2DotPyRunThrough#creating-and-authorizing-an-oauth-token

Bug#887468: hpanel: Crashes with SIGSEGV sometimes

[Bernhard Übelacker]

On Wed, 17 Jan 2018 09:41:44 +1100 Paul Szabo  wrote:
> Dear Maintainer,
> 
> Running on x86_64, hpanel sometimes crashes with SIGSEGV.
> As yet I have not noticed what actions may cause this, so
> do not know how to make it happen at will.

Hello Paul,
just tried if I can reproduce the issue even when not being
the maintainer, unfortunately was not successful.

If you inspect the dmesg output you should notice a line with
some very basic information on the crash.

As you write it is also randomly on your side, probably you can
install the package systemd-coredump. This should collect a core
dump of crashing processes.

If then the next crash happens you can execute as root:
  coredumpctl gdb
And that should print some more information of the latest crash.

Kind regards,
Bernhard

Bug#905550: pbuilder: Use a cgroup to allow cleaning up stray build processes

[Daniel Schepler]

Package: pbuilder
Version: 0.229.3
Severity: wishlist
Tags: patch

I've written a small patch which isolates processes from a build into
a cgroup (named like system-pbuilder-N.slice where N comes
from the pbuilder PID).  Then, if it sees after the build is done that
there are still stray processes left over, it will print a warning to
the log along with a list of these processes, and then kill them.  (Of
course, this will only work on Linux systems running systemd.)

The attached patch is the output of "git diff" against the current
contents of https://salsa.debian.org/pbuilder-team/pbuilder.git .
-- 
Daniel
diff --git a/debian/changelog b/debian/changelog
index 3521bc57..866116d3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,9 @@ pbuilder (0.229.4) UNRELEASED; urgency=medium
 
   * WIP.
 
+  [ Daniel Schepler ]
+  * Clean up stray processes from builds on Linux systems running systemd.
+
  -- Mattia Rizzolo   Sun, 29 Jul 2018 15:44:12 +0200
 
 pbuilder (0.229.3) unstable; urgency=medium
diff --git a/pbuilder-checkparams b/pbuilder-checkparams
index f02c88ee..526d1993 100755
--- a/pbuilder-checkparams
+++ b/pbuilder-checkparams
@@ -83,6 +83,10 @@ while [ -n "$1" ]; do
 USENETWORK="$2"
 shift 2
 ;;
+--use-cgroup)
+USECGROUP="$2"
+shift 2
+;;
 --distribution)
 DISTRIBUTION="$2";
 OVERRIDE_APTLINES_WARN=yes
@@ -384,6 +388,14 @@ if [ -z "${CHROOTEXEC}" ]; then
 EATMYDATA=not-available
 fi
 fi
+if [ "$USECGROUP" = "yes" ]; then
+if systemctl is-system-running --quiet >/dev/null 2>&1 ; then
+CHROOTEXEC="systemd-run --quiet --scope --slice=system-pbuilder-$$.slice $CHROOTEXEC"
+else
+log.w "cgroups are not available on the host, not using them."
+USECGROUP=not-available
+fi
+fi
 fi
 
 # handle 'experimental' specially. -- required for raw pbuilder (create/update) only.
diff --git a/pbuilder-modules b/pbuilder-modules
index e7cad591..ca0037c9 100644
--- a/pbuilder-modules
+++ b/pbuilder-modules
@@ -529,6 +529,19 @@ function cleanbuildplace () {
 fi
 unloadhooks
 if [ "${INTERNAL_BUILD_UML}" != "yes" ]; then
+if [ "${USECGROUP}" = "yes" ]; then
+tasks="$(systemctl show system-pbuilder-$$.slice --property=TasksCurrent | tr -d '\n')"
+if [ "$tasks" != "TasksCurrent=0" -a "$tasks" != "TasksCurrent=[not set]" ]; then
+log.d "Waiting for systemd to register process exits"
+sleep 0.1s
+tasks="$(systemctl show system-pbuilder-$$.slice --property=TasksCurrent | tr -d '\n')"
+if [ "$tasks" != "TasksCurrent=0" -a "$tasks" != "TasksCurrent=[not set]" ]; then
+log.w "Cleaning up stray processes from build"
+systemctl status system-pbuilder-$$.slice
+systemctl stop system-pbuilder-$$.slice
+fi
+fi
+fi
 if [ -d "$BUILDPLACE" ]; then
 # A directory on the same partition as $BUILDPLACE, bind-mounted
 # into $BUILDPLACE, will be cleaned out by clean_subdirectories
diff --git a/pbuilderrc b/pbuilderrc
index bcd1d883..d0513c55 100644
--- a/pbuilderrc
+++ b/pbuilderrc
@@ -33,6 +33,7 @@ USEDEVFS=no
 USEDEVPTS=yes
 USESYSFS=yes
 USENETWORK=no
+USECGROUP=yes
 BUILDRESULT=/var/cache/pbuilder/result/
 
 # specifying the distribution forces the distribution on "pbuilder update"
diff --git a/pbuilderrc.5 b/pbuilderrc.5
index 05b907ab..1c597e61 100644
--- a/pbuilderrc.5
+++ b/pbuilderrc.5
@@ -481,6 +481,13 @@ Network is not available on a Debian buildd, so you might
 want to keep the default.
 Disabling network access currently only works on Linux.
 .TP
+.BI "USECGROUP=" "yes"
+Specify
+.B yes
+to use a cgroup to isolate build processes, so that any stray processes
+from the build can be cleaned up afterwords.
+This currently only works on Linux systems running systemd.
+.TP
 .BI "USESHM=" "yes"
 Specify
 .B yes

Bug#887457: freecad crashes with SIGSEGV if want to create a curve on a cylinder edge

[Bernhard Übelacker]

Hello Robert,
if you started the crashing application already with gdb then, after the
crash, please also call the "bt" command to get a complete call stack.
More information in [1].
And this is most helpful, if the debug packages got installed before,
e.g. freecad-dbgsym and at least the last frame shows libTKG2d.so.10 -
therefore liboce-modeling10-dbgsym.

>From that single line the crash did happen
in src/Geom2d/Geom2d_Curve.cxx, Line 80.

If you can reproduce the crash, probably you can give a more detailed
description which exact actions lead to this crash?

Kind regards,
Bernhard

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



(gdb) disassemble /m Geom2d_Curve::Value(double) const
Dump of assembler code for function Geom2d_Curve::Value(double) const:
78  {
   0x7fff7ea94d20 <+0>: sub$0x28,%rsp
   0x7fff7ea94d28 <+8>: mov%fs:0x28,%rax
   0x7fff7ea94d31 <+17>:mov%rax,0x18(%rsp)
   0x7fff7ea94d36 <+22>:xor%eax,%eax

79gp_Pnt2d P;
80D0(U,P);
   0x7fff7ea94d38 <+24>:mov(%rdi),%rax  <-- this was 
probably the instruction of the crash.
   0x7fff7ea94d3b <+27>:mov%rsp,%rsi
   0x7fff7ea94d49 <+41>:callq  *0x90(%rax)

81return P;
   0x7fff7ea94d5d <+61>:movsd  (%rsp),%xmm0
   0x7fff7ea94d62 <+66>:movsd  0x8(%rsp),%xmm1

82  }
   0x7fff7ea94d4f <+47>:mov0x18(%rsp),%rax
   0x7fff7ea94d54 <+52>:xor%fs:0x28,%rax
   0x7fff7ea94d68 <+72>:jne0x7fff7ea94d6f 

   0x7fff7ea94d6a <+74>:add$0x28,%rsp
   0x7fff7ea94d6e <+78>:retq
   0x7fff7ea94d6f <+79>:callq  0x7fff7ea851c0 <__stack_chk_fail@plt>

End of assembler dump.


(gdb) list Geom2d_Curve::Value
73  //function : Value
74  //purpose  :
75  
//===
76
77  gp_Pnt2d  Geom2d_Curve::Value(const Standard_Real U)const
78  {
79gp_Pnt2d P;
80D0(U,P);
81return P;
82  }

Bug#905549: fwupdate-amd64-signed: missing script/binary in /usr/lib/fwupdate/

[Eric Côté]

Package: fwupdate-amd64-signed
Version: 12+2
Severity: normal

=== >8 ===

Setting up fwupdate (12-2) ...
Installing fwupx64.efi to EFI system partition.
/var/lib/dpkg/info/fwupdate.postinst: 46: /var/lib/dpkg/info/fwupdate.postinst: 
/usr/lib/fwupdate/cleanup: not found
Setting up gir1.2-nm-1.0:amd64 (1.12.2-2) ...
Setting up fwupdate-amd64-signed (12+2) ...
/var/lib/dpkg/info/fwupdate-amd64-signed.postinst: 46: 
/var/lib/dpkg/info/fwupdate-amd64-signed.postinst: /usr/lib/fwupdate/cleanup: 
not found

=== 8< ===

I checked that dir, I only see the efi binaries, and that `install' script, no 
`cleanup' .

TY
Eric

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

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_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fwupdate-amd64-signed depends on:
ii  fwupdate  12-2

fwupdate-amd64-signed recommends no packages.

fwupdate-amd64-signed suggests no packages.

-- no debconf information

Bug#904917: general: Gnome randomly crash and restart to login.

[Simon Richter]

reassign 904917 gnome-shell
retitle 904917 gnome-shell: segmentation fault
thanks

Hi,

On 05.08.2018 23:54, Carl-Valentin Schmitt wrote:

> Is this a machine with nvidia graphics card and nvidia drivers?

Unlikely that this is the problem, the crash address was somewhere in
libgobject, which the nV drivers don't use directly.

I've reassigned the bug to the "gnome-shell" package, the maintainers
there should know better how to debug this further.

The address being dereferenced looks suspiciously like ASCII data, "x74f4f".

Note that the bug submitter has mentioned that he won't have time until
end of August.

   Simon



signature.asc
Description: OpenPGP digital signature

Bug#897767: closed by Mo Zhou (Bug#897767: fixed in highwayhash 0~20180209-g14dedec-5)

[Lumin]

control: retitle -1 non-x86 symbols out of date
control: severity -1 normal

This non-x86 arches are not my priorities currently. It doesn't deserve
another RFS bug to the mentors list, and it can be easily fixed by me when
I get my Debian Developer account.

On Mon, Aug 6, 2018 at 00:45 Adrian Bunk  wrote:

> Control: reopen -1
>
> On Mon, Jul 23, 2018 at 01:54:03AM +, Debian Bug Tracking System wrote:
> >...
> >  highwayhash (0~20180209-g14dedec-5) unstable; urgency=medium
> >  .
> >* Refresh symbols to avoid FTBFS with GCC-8 (Closes: #897767)
> >...
>
> unfortunately this fixed it only for amd64, the package still FTBFS
> on arm64/ppc64el/x32:
> https://buildd.debian.org/status/package.php?p=highwayhash
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
-- 
Best,

Bug#905548: python-pysam: FTBFS - tests fail: AttributeError: 'module' object has no attribute 'HAVE_LIBCURL'

[Andreas Beckmann]

Source: python-pysam
Version: 0.15.0.1+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

python-pysam FTBFS on all architectures with testsuite errors. I can
also reproduce this on amd64 in a clean pbuilder environment.

https://buildd.debian.org/status/package.php?p=python-pysam&suite=experimental

=== FAILURES ===
 TestEmptyHeader.test_bam_without_seq_in_header 

self = 

def test_bam_without_seq_in_header(self):
>   s = pysam.AlignmentFile(os.path.join(BAM_DATADIR, 
> "example_no_seq_in_header.bam"))

tests/AlignmentFile_test.py:1406: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
pysam/libcalignmentfile.pyx:734: in 
pysam.libcalignmentfile.AlignmentFile.__cinit__
???
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

>   ???
E   IOError: [Errno 2] could not open alignment file 
`/<>/python-pysam-0.15.0.1+ds/.pybuild/cpython2_2.7_pysam/build/tests/pysam_data/example_no_seq_in_header.bam`:
 No such file or directory

pysam/libcalignmentfile.pyx:933: IOError
___ TestRemoteFileHTTP.testFetchAll 

self = 

def setUp(self):
>   if not pysam.config.HAVE_LIBCURL or not check_url(self.url):
E   AttributeError: 'module' object has no attribute 'HAVE_LIBCURL'

tests/tabix_test.py:1049: AttributeError
 TestRemoteFileHTTP.testHeader _

self = 

def setUp(self):
>   if not pysam.config.HAVE_LIBCURL or not check_url(self.url):
E   AttributeError: 'module' object has no attribute 'HAVE_LIBCURL'

tests/tabix_test.py:1049: AttributeError
__ TestRemoteFileHTTPWithHeader.testFetchAll ___

self = 

def setUp(self):
>   if not pysam.config.HAVE_LIBCURL or not check_url(self.url):
E   AttributeError: 'module' object has no attribute 'HAVE_LIBCURL'

tests/tabix_test.py:1088: AttributeError
___ TestRemoteFileHTTPWithHeader.testHeader 

self = 

def setUp(self):
>   if not pysam.config.HAVE_LIBCURL or not check_url(self.url):
E   AttributeError: 'module' object has no attribute 'HAVE_LIBCURL'

tests/tabix_test.py:1088: AttributeError
=== warnings summary ===
.pybuild/cpython2_2.7_pysam/build/tests/AlignmentFile_test.py::TestTruncatedBAM::testTruncatedBam2
  
/<>/python-pysam-0.15.0.1+ds/.pybuild/cpython2_2.7_pysam/build/tests/AlignmentFile_test.py:1441:
 UserWarning: no BGZF EOF marker; file may be truncated
ignore_truncation=True)

.pybuild/cpython2_2.7_pysam/build/tests/samtools_test.py::SamtoolsTest::testStatements
  
/<>/python-pysam-0.15.0.1+ds/.pybuild/cpython2_2.7_pysam/build/tests/samtools_test.py:140:
 UserWarning: versions of pysam.samtools and samtools differ: 1.9 != 1.7
samtools_version))

-- Docs: http://doc.pytest.org/en/latest/warnings.html
 5 failed, 903 passed, 17 skipped, 2 warnings in 94.95 seconds =
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/<>/python-pysam-0.15.0.1+ds/.pybuild/cpython2_2.7_pysam/build; 
python2.7 -m pytest tests
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 returned 
exit code 13
make[1]: *** [debian/rules:31: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>/python-pysam-0.15.0.1+ds'
make: *** [debian/rules:24: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


Network access (beyond localhost) is not available during build.


Andreas

Bug#904917: general: Gnome randomly crash and restart to login.

[Carl-Valentin Schmitt]

Maybe try to uninstall all installed nvidia drivers, and then run your
machine with vesa.
I know oft Solus Linux that this was a bug in nvidia drivers.

Carl-Valentin Schmitt  schrieb am So., 5. Aug. 2018,
23:54:

> Is this a machine with nvidia graphics card and nvidia drivers?
>
> Riccardo Gagliarducci  schrieb am So., 5. Aug. 2018,
> 23:51:
>
>> I'm leaving for holidays, may I freeze this bug until end of August?
>>
>> In dmsg, I found:
>> [ 6737.746966] gnome-shell[2131]: segfault at 663466343778 ip
>> 7f0a52cf3c31 sp 7ffd58e51e98 error 4 in libgobject-
>> 2.0.so.0.5600.1[7f0a52cbe000+52000]
>>
>> But I'd like to investigate more...
>> Thank you,
>> Riccardo
>>
>>
>> Il giorno sab, 04/08/2018 alle 02.21 +0200, Simon Richter ha scritto:
>> > Hi,
>> >
>> > On 04.08.2018 01:32, Riccardo Gagliarducci wrote:
>> >
>> > > after firmware update it still happens ~once a day,
>> > > still without doing anything particular.
>> >
>> > Is anything listed in the kernel log?
>> >
>> > After a crash, log back in, then, as root:
>> >
>> > # cat /proc/uptime
>> >
>> > The first number is the number of seconds the system is running.
>> >
>> > # dmesg
>> >
>> > This will dump the kernel logfile to the console. At the beginning of
>> > each line is a timestamp. The uptime you got earlier gives you a
>> > rough
>> > estimate which lines are recent, these have a good chance of being
>> > related.
>> >
>> >Simon
>> >
>>
>>

Bug#904917: general: Gnome randomly crash and restart to login.

[Carl-Valentin Schmitt]

Is this a machine with nvidia graphics card and nvidia drivers?

Riccardo Gagliarducci  schrieb am So., 5. Aug. 2018,
23:51:

> I'm leaving for holidays, may I freeze this bug until end of August?
>
> In dmsg, I found:
> [ 6737.746966] gnome-shell[2131]: segfault at 663466343778 ip
> 7f0a52cf3c31 sp 7ffd58e51e98 error 4 in libgobject-
> 2.0.so.0.5600.1[7f0a52cbe000+52000]
>
> But I'd like to investigate more...
> Thank you,
> Riccardo
>
>
> Il giorno sab, 04/08/2018 alle 02.21 +0200, Simon Richter ha scritto:
> > Hi,
> >
> > On 04.08.2018 01:32, Riccardo Gagliarducci wrote:
> >
> > > after firmware update it still happens ~once a day,
> > > still without doing anything particular.
> >
> > Is anything listed in the kernel log?
> >
> > After a crash, log back in, then, as root:
> >
> > # cat /proc/uptime
> >
> > The first number is the number of seconds the system is running.
> >
> > # dmesg
> >
> > This will dump the kernel logfile to the console. At the beginning of
> > each line is a timestamp. The uptime you got earlier gives you a
> > rough
> > estimate which lines are recent, these have a good chance of being
> > related.
> >
> >Simon
> >
>
>

Bug#904917: general: Gnome randomly crash and restart to login.

[Riccardo Gagliarducci]

I'm leaving for holidays, may I freeze this bug until end of August?

In dmsg, I found: 
[ 6737.746966] gnome-shell[2131]: segfault at 663466343778 ip
7f0a52cf3c31 sp 7ffd58e51e98 error 4 in libgobject-
2.0.so.0.5600.1[7f0a52cbe000+52000]

But I'd like to investigate more...
Thank you,
Riccardo


Il giorno sab, 04/08/2018 alle 02.21 +0200, Simon Richter ha scritto:
> Hi,
> 
> On 04.08.2018 01:32, Riccardo Gagliarducci wrote:
> 
> > after firmware update it still happens ~once a day,
> > still without doing anything particular.
> 
> Is anything listed in the kernel log?
> 
> After a crash, log back in, then, as root:
> 
> # cat /proc/uptime
> 
> The first number is the number of seconds the system is running.
> 
> # dmesg
> 
> This will dump the kernel logfile to the console. At the beginning of
> each line is a timestamp. The uptime you got earlier gives you a
> rough
> estimate which lines are recent, these have a good chance of being
> related.
> 
>Simon
> 

Bug#905527: `apt show` fails to parse record for librust-winapi-dev (while `apt-cache show` succeeds)

[Antonio Terceiro]

On Sun, Aug 05, 2018 at 12:20:54PM -0300, Antonio Terceiro wrote:
> Package: apt
> Version: 1.6.3
> Severity: normal
> 
> ~$ apt-cache show librust-winapi-dev
> [... stuff ...]
> ~$ apt show librust-winapi-dev
> E: Unable to parse package file 
> /var/lib/apt/lists/ftp.br.debian.org_debian_dists_unstable_main_binary-amd64_Packages
>  (2)
> E: Internal Error, Unable to parse a package record
> 
> librust-winapi-dev as a massing Provides: field, which could be causing this.

It seems this time I really overachieved with typos, so just to be
clear: I meant "librust-winapi-dev *has* a *massive* Provides: field".


signature.asc
Description: PGP signature

Bug#881000: uuid command fail to use the real MAC address

[Simon Valiquette]

Package: uuid
Followup-For: Bug #881000
Control: tags -1 + moreinfo

Hello,


I was reading your bugreport about uuid, and wondered if it wasn't simply 
that you didn't notice that in your example, the MAC address was actually 
used and was at the end of the UUID, as expected.



If so, then please close this bug report as this is the expected behavior 
AFAIK.  If you do the following command many times, you will notice that 
the end of the UUID is always indeed a MAC address and not a random value:


$ uuid -v 1


Now, if the MAC address at the end of the UUID isn't the same as any of 
your network interface, then there would indeed be a problem.


I can't check as you didn't provide the output of /sbin/ifconfig, and also 
didn't also provide the UUID you expected to see, but I doubt that there 
is any bug here and that you simply misunderstood something.


Have a nice day,

Simon Valiquette

Bug#904685: diffoscope: RuntimeError when trying to extract an encrypted file (.bmp)

[Ricardo Gaviria]

Hi Chris,

Thanks for the swift feedback, and for sharing. I have issued a merge
request which can be found here
.
Have addressed your comments, including narrower exception, accompanied by
a comment, and one test case trying to compare 2 encrypted zipfiles.



*Isn't this a bit too "wide" an exception class to catch? How narrow canwe
safely make it?*

You are right that is too wide, the narrowest I think we can go is catching
a RuntimeError (which is not that narrow IMO) but that is what is thrown in
this case by the open() method in zipfile.py


If we want to be more explicit we could just explicitly check if the
archive is encrypted and raise a diffoscope exception accordingly:

+try:
+# Wrapped in a try block as exception may be raised due to
archive
+# being encrypted, already closed, or opened incorrectly see
library
+# zipfile.py line 1292
+with self.archive.open(member_name) as source,
open(targetpath, 'wb') as target:
+shutil.copyfileobj(source, target)
+return targetpath.decode(sys.getfilesystemencoding())
+except RuntimeError as exc:
+raise ContainerExtractionError(member_name, exc)

Not sure what is the best approach here.

We can move this discussion over to the MR if that suits better. Just let
me know.

Thanks again,
Ricardo






On Sun, Aug 5, 2018 at 4:00 AM Chris Lamb  wrote:

> tags 904685 + patch
> thanks
>
> Dear Ricardo,
>
> > Based on this bug, please find attached a proposed patch for handling
> > this error gracefully [..]
>
> Wow, thank you so much for this :)
>
> > Additionally, I see that I could have also just submitted a merge request
> > via salsa.debian.org. What is the usual workflow, email patches or merge
> > requests?
>
> It might depend more on the size of the patch and whether you were
> thinking of making more in the future. Using salsa also has the
> advantages of running the testsuite too, which may be useful here (see
> below). Please do join our group on salsa ...
>
> > I would gladly appreciate some feedback. I tried to update the changelog
> as
> > best as I understood here
> > .
>
> Sure thing.
>
> So, the debian/changelog entries for diffoscope are generated
> automatically upon release so updating the changelog is not required.
> In your commit message please suffix with "(Closes: #904685)" so the
> versions/state is handled properly though.
>
> (Furthermore, the "~reproducibleX" suffix as outlined on that page is
> typically used when we fork packages from /elsewhere/ in Debian and, as
> this project is part of the reproducible builds effort, there is no
> naturally need to fork..)
>
>
>targetpath = os.path.join(dest_dir,
> os.path.basename(member_name)).encode(
>sys.getfilesystemencoding(), errors='replace')
>   -with self.archive.open(member_name) as source, open(targetpath,
> 'wb') as target:
>   -shutil.copyfileobj(source, target)
>   -return targetpath.decode(sys.getfilesystemencoding())
>   +try:
>   +with self.archive.open(member_name) as source,
> open(targetpath, 'wb') as target:
>   +shutil.copyfileobj(source, target)
>   +return targetpath.decode(sys.getfilesystemencoding())
>   +except Exception as exc:
>   ^
>
> Isn't this a bit too "wide" an exception class to catch? How narrow can
> we safely make it?
>
>   +raise ContainerExtractionError(member_name, exc)
>
> I think I would also like to see:
>
>  * A comment in the except block explaining why we might be seeing an
>exception in the first place.
>
>  * A test :)
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>
-- 
Regards,
Ricardo Gaviria
Software Engineer, UniteLabs
*M: *+41 77 956 2376
*W: *http://unitelabs.ch
*In: *https://www.linkedin.com/in/ricardogaviria/

Bug#905545: data-xml-clojure: Please upgrade data-xml-clojure to 0.2.0-alpha5

[Elana Hashman]

On Sun, Aug 05, 2018 at 04:21:53PM -0400, Elana Hashman wrote:
> Please upgrade data-xml-clojure to 0.2.0-alpha5.

Currently, Leiningen depends on 0.0.8 directly. I don't think that
0.2.0-alpha5 would break any 0.0.8 APIs (Clojure is notorious for
their backwards-compatible guarantees) BUT I'd prefer to see this
tested in Leiningen before upgrading.

That appears to be the only rdep:

$ build-rdeps libdata-xml-clojure
Reverse Build-depends in main:
--

leiningen-clojure

Found a total of 1 reverse build-depend(s) for libdata-xml-clojure.

$ apt-cache rdepends libdata-xml-clojure
libdata-xml-clojure
Reverse Depends:


PR to Leiningen: https://github.com/technomancy/leiningen/pull/2456

Looks like the new 0.2.0-alpha5 version *does* break Leiningen so
let's get that fixed before upgrade.


signature.asc
Description: Digital signature

Bug#905305: emacs-common: terrible mess

[Cristian Ionescu-Idbohrn]

On Sun, 5 Aug 2018, Rob Browning wrote:
> 
> If you can tell what's going wrong, please consider filing bugs against
> the relevant add-on packages, or contacting #debian-emacsen or
> debian-emac...@lists.debian.org.

Thanks.

Showed up the culprit was initz package (which I don't use since quite 
a while back, anyway).  Removing it:

# emacs -nw -q --debug-init
*Messages* buffer:
run-hooks: Cannot open load file: No such file or directory, initz
package initz, version 0.0.11+20030603cvs-17.2, remove:
# apt-get --purge remove initz
ERROR: initz is broken - called emacs-package-remove as a 
   new-style add-on, but has no compat file.
# emacs -nw -q --debug-init
Error gone.

Ended up removing several packages (besides initz), for various 
reasons.

The only one I regret seeing go away is:

/usr/share/emacs25/site-lisp/emacs-goodies-el/align-string.el


Cheers,

-- 
Cristian

Bug#905547: jgit: Please upgrade jgit to 4.10.0

[Elana Hashman]

Source: jgit
Severity: wishlist
Control: block 891136 by -1

Please upgrade jgit to 4.10.0. This version is required for packaging
tools-deps-alpha-clojure, the new upstream dependency resolver that is
required to package the new upstream Clojure CLI.

Upgrading to this version would also appear to fix #878800. :)


signature.asc
Description: Digital signature

Bug#905546: jsch-agent-proxy: Please upgrade jsch-agent-proxy to 0.0.9

[Elana Hashman]

Source: jsch-agent-proxy
Severity: wishlist
Control: block 891136 by -1

Please upgrade jsch-agent-proxy to 0.0.9. This version is required for
packaging tools-deps-alpha-clojure, the new upstream dependency
resolver that is required to package the new upstream Clojure CLI.


signature.asc
Description: Digital signature

Bug#904988: /bin/su does not set $PATH

[Christoph Anton Mitterer]

>The problem is still that we need to choose between preserving
>old Debian behaviour or being in line with how every other
>distribution works. We can patch the defaults in debian, but do we
>want to be different?

If we can't be different, but have to do everywhere the same as
everyone else,... why do we need a separate distribution?


I think the main question here is:
Was something wrong with the old behaviour?
And I'd say: No.

Actually, having a sane path set when being root is what one
expects,... or have there been any bigger complaints about this in the
past?
Sure one can just type su - ... but why?


In the end it boils down to Debian users being "punished" in having
adapt to something else for not good reason :-(


Cheers,
Chris.

Bug#905545: data-xml-clojure: Please upgrade data-xml-clojure to 0.2.0-alpha5

[Elana Hashman]

Source: data-xml-clojure
Severity: wishlist
Control: block 891136 by -1

Please upgrade data-xml-clojure to 0.2.0-alpha5. This version is
required for packaging tools-deps-alpha-clojure, the new upstream
dependency resolver that is required to package the new upstream
Clojure CLI.


signature.asc
Description: Digital signature

Bug#874529:

[Allard Hendriksen]

Hi,

You can install the packages that I attached to my e-mail message to
(partly) fix the issue. I do not really understand why this one-line
patch is not backported by the maintainers..

I believe that this one-line error is not the only bug. User switching
works 80% of the time now, instead of never.

I hope that helps!

Cheers,

Allard

Laurent GUERBY writes:

> Hi,
>
> I get this bug on my debian stretch, any reason not not backport
> and release gdm3 again with the one liner for the obvious C thinko?
>
> https://github.com/GNOME/gdm/commit/60447f2016cd873b0a62a5885687d7b3a85
> 38d11#diff-daf9735fd40f92ad94e330eeab3c99a7
>
> g_object_set (display,
> -"seat-id", "seat0"
> +"seat-id", "seat0",
>
> Thanks!
>
> Laurent

Bug#905235: emacs-goodies-el failed to install due to old broken symlinks

[Nicholas D Steeves]

Control: tag -1 + pending

Hi Jörg and Göran,

In the absence of feedback I plan to upload a new revision of
emacs-goodies-el with a hard dependency on emacsen-common >= 3.0.2
sometime in the next 24h.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#905544: ddrescue fails to display / make progress

[Gary Dale]

Package: ddrescue
Version: 1.23-1
Severity: normal

Dear Maintainer,

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


   * What led up to the situation?
I have a 1T hard drive that has a hardware problem that makes it 
impossible to use productively


   * What exactly did you do (or not do) that was effective (or 
ineffective)?
The drive seems to have either a platter or controller issue that makes 
it incredibly slow.
However it passes the SMART tests. I tried initially copying the drive 
to a new one directly
using ddrescue but that proved too slow, so I simply reinstalled the OS 
on a new drive and
returned the unit to its owner (a friend of a friend). For the past 2 
months I've been using

ddrescue to try to make an image of the drive.

SMART test:

root@transponder:/home/garydale# smartctl -H /dev/sdc
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.16.0-2-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED


   * What was the outcome of this action?
After two months of trying, ddrescue reports that it is at 81.15% 
complete with another
49d 21m to go. For the last several days it has been mostly starting up, 
displaying results
for several seconds, then continuing to access the drive without 
updating the status display.


   * What outcome did you expect instead?
I would expect the status display to be updated regardless of trouble it 
might have accessing
the disk. Here's the output of the last run immediately before I pulled 
the USB cable:


root@transponder:/home/garydale# ddrescue  /dev/sdc4 -R ./WD/rescue4.img 
./WD/mapfile4

GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 796728 MB, tried: 150206 MB, bad-sector: 0 B, bad areas: 0

 ipos:   70903 MB, non-trimmed:  150206 MB,  current rate: 65536 B/s
 opos:   70903 MB, non-scraped:    0 B,  average rate: 48330 B/s
non-tried:   34820 MB,  bad-sector:    0 B,    error rate:   0 B/s
  rescued:  796748 MB,   bad areas:    0,    run time:  6m 59s
pct rescued:   81.15%, read errors:    0,  remaining time: 46d 16h 21m
  time since last successful read:  0s
Copying non-tried blocks... Pass 5 (backwards)


and here's what it displayed several seconds after I pulled the cable:

root@transponder:/home/garydale# ddrescue  /dev/sdc4 -R ./WD/rescue4.img 
./WD/mapfile4

GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 796728 MB, tried: 150206 MB, bad-sector: 0 B, bad areas: 0

 ipos:   70903 MB, non-trimmed:  150207 MB,  current rate:   0 B/s
 opos:   70903 MB, non-scraped:    0 B,  average rate: 922 B/s
non-tried:   34819 MB,  bad-sector:    0 B,    error rate: 5461 B/s
  rescued:  796749 MB,   bad areas:    0,    run time:  6h 16m 28s
pct rescued:   81.15%, read errors:    2,  remaining time: 49d 21m
  time since last successful read: 12s
Copying non-tried blocks... Pass 5 (backwards)
ddrescue: Input file disappeared: No such file or directory

The program doesn't respond to Ctrl-C. I have to cut power or pull the 
USB cord to interupt it. As you can see, it went for more than 6 hours 
without updating the progress display. During this time the disk light 
was flashing continuously.


Note: this last run was particularly productive in that the program 
continued updating the screen for several minutes. This was unusual. I 
had just switched to -R after several days of trying it in the forward 
direction. For some reason, -R seems to generally do a bit better than 
forward. However going 6 minutes in the -R direction was still unusual. 
I'd switched back to forward because -R had not been doing too well for 
the past week. When forward was doing just as badly, I switched back to -R.



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


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

Kernel: Linux 4.16.0-2-amd64 (SMP w/16 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ddrescue depends on:
ii  libc6  2.27-5

ddrescue recommends no packages.

ddrescue suggests no packages.

-- no debconf information

Bug#905517: emacs-goodies-el: unowned files after purge (policy 6.8, 10.8): /usr/share/emacs/site-lisp/emacs-goodies-el/emacs-goodies-loaddefs.el

[Nicholas D Steeves]

Control: tag -1 + pending

Hi Andreas,

On Sun, Aug 05, 2018 at 04:49:37PM +0200, Andreas Beckmann wrote:
> Package: emacs-goodies-el
> Version: 40.0
> Severity: important
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package left unowned files on
> the system after purge, which is a violation of policy 6.8 (or 10.8):
> 
> https://www.debian.org/doc/debian-policy/#details-of-removal-and-or-configuration-purging
> 
> Filing this as important as having a piuparts clean archive is a release
> goal since lenny.
> 
> From the attached log (scroll to the bottom...):
> 
> 0m47.8s ERROR: FAIL: Package purging left files on system:
>   /usr/share/emacs/site-lisp/emacs-goodies-el/ owned by: 
> emacs-goodies-el
>   /usr/share/emacs/site-lisp/emacs-goodies-el/emacs-goodies-loaddefs.el   
>  not owned

Thank you for this report.  I've added a prerm script and plan to make
one more change before uploading a release.  Also, just today I
finally got piuparts to work automatically on each build :-D  If you're
filing stretch2sid bugs, please also consider filing ones for:

  /etc/systemd/system/dbus-org.freedesktop.timesync1.service ->
  /lib/systemd/system/systemd-timesyncd.service   not owned
  /usr/local/share/fonts/not owned
  /usr/local/share/fonts/.uuid   not owned
  /usr/share/fonts/  owned by: fonts-dejavu-core
  /usr/share/fonts/.uuid not owned
  /usr/share/fonts/truetype/ owned by: fonts-dejavu-core
  /usr/share/fonts/truetype/.uuidnot owned
  /usr/share/fonts/truetype/dejavu/  owned by: fonts-dejavu-core
  /usr/share/fonts/truetype/dejavu/.uuid not owned


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#905543: ITP: tools-gitlibs-clojure -- Clojure API for programatically accessing git libraries

[Elana Hashman]

Package: wnpp
Owner: Elana Hashman 
Severity: wishlist
Control: block 891136 by -1

* Package name: tools-gitlibs-clojure
  Version : 0.2.64
  Upstream Author : Rich Hickey
* URL : https://github.com/clojure/tools.gitlibs
* License : EPL-1.0
  Programming Lang: Clojure
  Description : Clojure API for programatically accessing git libraries

This is a dependency of tools-deps-alpha, the package resolver and
manager for the new upstream clojure-cli.


signature.asc
Description: Digital signature

Bug#905542: xserver-xorg-video-nouveau: segmentation fault on startup every time

[Eric Cooper]

Thanks, I can confirm that rolling back to xserver-xorg-core 2:1.19.6-1
fixes the problem for me for now.

On Sun, Aug 5, 2018 at 3:55 PM Sven Joachim  wrote:

> Control: reassign -1 xserver-xorg-core
> Control: forcemerge 900550 -1
>
> On 2018-08-05 15:43 -0400, Eric Cooper wrote:
>
> > Package: xserver-xorg-video-nouveau
> > Version: 1:1.0.15-3
> > Severity: important
> >
> > I did an "apt-get upgrade" today that installed new
> > xserver-xorg-{core,nouveau} packages. Now X does not start on my system.
> > The same segmentation fault occurs every time I run "startx".
> > [...]
> > [   301.726] (EE)
> > [   301.726] (EE) Backtrace:
> > [   301.726] (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4d)
> [0x56123945b8dd]
> > [   301.726] (EE) 1: /usr/lib/xorg/Xorg (0x5612392a8000+0x1b7599)
> [0x56123945f599]
> > [   301.726] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f1b1ca8+0x128e0) [0x7f1b1ca928e0]
> > [   301.726] (EE) 3: /usr/lib/xorg/Xorg (miRenderColorToPixel+0xe)
> [0x5612393cfbde]
> > [   301.726] (EE) 4: /usr/lib/xorg/modules/libexa.so
> (0x7f1b19a8d000+0xf13b) [0x7f1b19a9c13b]
> > [   301.726] (EE) 5: /usr/lib/xorg/Xorg (0x5612392a8000+0x13a8b6)
> [0x5612393e28b6]
> > [   301.726] (EE) 6: /usr/lib/xorg/Xorg (0x5612392a8000+0x12ec1c)
> [0x5612393d6c1c]
> > [   301.726] (EE) 7: /usr/lib/xorg/Xorg (0x5612392a8000+0x5b008)
> [0x561239303008]
> > [   301.726] (EE) 8: /usr/lib/xorg/Xorg (0x5612392a8000+0x5f008)
> [0x561239307008]
> > [   301.726] (EE) 9: /lib/x86_64-linux-gnu/libc.so.6
> (__libc_start_main+0xe7) [0x7f1b1c8e5b17]
> > [   301.727] (EE) 10: /usr/lib/xorg/Xorg (_start+0x2a) [0x5612392f0d0a]
> > [   301.727] (EE)
> > [   301.727] (EE) Segmentation fault at address 0x8
> > [   301.727] (EE)
> > Fatal server error:
> > [   301.727] (EE) Caught signal 11 (Segmentation fault). Server aborting
>
> This is bug #900550 in xserver-xorg-core, a fix is pending in git[1].
>
> Cheers,
>Sven
>
>
> 1.
> https://salsa.debian.org/xorg-team/xserver/xorg-server/commit/aa7aaeb5223830a3670dc658152e28f125c17de8
>

Bug#905514: [cryptsetup-initramfs] Cannot create /etc/cryptsetup-initramfs/conf-hook.dpkg-new: Directory nonexistent

[Alf Gaida]

Source: cryptsetup
Followup-For: Bug #905514

Hi, the severity should not be normal as it successfully prevent new 
installations of the package :)

Cheers Alf

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

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

Bug#905321: linux-image-4.17.0-1-amd64: Screen flicker

[Sten Heinze]

Here's a link to a video of the flickering;

https://drive.google.com/file/d/1nZ4Z_Y1pDtylS11FqZ0PSU5a5G2QxAxM/

Sten

Bug#905542: xserver-xorg-video-nouveau: segmentation fault on startup every time

[Sven Joachim]

Control: reassign -1 xserver-xorg-core
Control: forcemerge 900550 -1

On 2018-08-05 15:43 -0400, Eric Cooper wrote:

> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.15-3
> Severity: important
>
> I did an "apt-get upgrade" today that installed new
> xserver-xorg-{core,nouveau} packages. Now X does not start on my system.
> The same segmentation fault occurs every time I run "startx".
> [...]
> [   301.726] (EE)
> [   301.726] (EE) Backtrace:
> [   301.726] (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4d) [0x56123945b8dd]
> [   301.726] (EE) 1: /usr/lib/xorg/Xorg (0x5612392a8000+0x1b7599) 
> [0x56123945f599]
> [   301.726] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 
> (0x7f1b1ca8+0x128e0) [0x7f1b1ca928e0]
> [   301.726] (EE) 3: /usr/lib/xorg/Xorg (miRenderColorToPixel+0xe) 
> [0x5612393cfbde]
> [   301.726] (EE) 4: /usr/lib/xorg/modules/libexa.so (0x7f1b19a8d000+0xf13b) 
> [0x7f1b19a9c13b]
> [   301.726] (EE) 5: /usr/lib/xorg/Xorg (0x5612392a8000+0x13a8b6) 
> [0x5612393e28b6]
> [   301.726] (EE) 6: /usr/lib/xorg/Xorg (0x5612392a8000+0x12ec1c) 
> [0x5612393d6c1c]
> [   301.726] (EE) 7: /usr/lib/xorg/Xorg (0x5612392a8000+0x5b008) 
> [0x561239303008]
> [   301.726] (EE) 8: /usr/lib/xorg/Xorg (0x5612392a8000+0x5f008) 
> [0x561239307008]
> [   301.726] (EE) 9: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xe7) 
> [0x7f1b1c8e5b17]
> [   301.727] (EE) 10: /usr/lib/xorg/Xorg (_start+0x2a) [0x5612392f0d0a]
> [   301.727] (EE)
> [   301.727] (EE) Segmentation fault at address 0x8
> [   301.727] (EE)
> Fatal server error:
> [   301.727] (EE) Caught signal 11 (Segmentation fault). Server aborting

This is bug #900550 in xserver-xorg-core, a fix is pending in git[1].

Cheers,
   Sven


1. 
https://salsa.debian.org/xorg-team/xserver/xorg-server/commit/aa7aaeb5223830a3670dc658152e28f125c17de8

Bug#891136: ITP: tools-deps-alpha-clojure -- functional API for dependency management and classpath creation

[Elana Hashman]

So I was thinking about this, because the vast majority of the work
consists of new uploads for S3 support... namely:

> - s3-wagon-private "1.3.1"
> - com.amazonaws/aws-java-sdk-core "1.11.184"
> - com.amazonaws/aws-java-sdk-kms "1.11.184"
> - com.amazonaws/aws-java-sdk-s3 "1.11.184"
> - software.amazon.ion/ion-java "1.0.2"
> - com.amazonaws/jmespath-java "1.11.184"
> - org.springframework.build/aws-maven "4.8.0.RELEASE"

Looking at the underlying code, it looks like patching out S3 support
is very straightforward.[*] And since S3 support is mainly for private
maven repos (i.e. to serve proprietary artifacts), I'm not too worried
about leaving out support for this in Debian. Of course, if someone
wants to package the Java SDK, they should feel free.

In that case, the remaining work for tools.deps is:

> Needs version bump:
> - data-xml-clojure to 0.2.0-alpha5
> - libjsch-agent-proxy-java to 0.0.9
> - jgit to 4.10.0
> 
> Needs new upload:
> - org.clojure/tools.gitlibs "0.2.64"

That is a manageable workload and I'd love to make it happen. So I'll
file an ITP for tools-gitlibs-clojure and version bump requests for
the other three.

- e

[*]: 
https://github.com/clojure/tools.deps.alpha/blob/884d7ae5b9c228ff795e4385291708102f1cd46d/src/main/clojure/clojure/tools/deps/alpha/util/maven.clj#L105-L106


signature.asc
Description: Digital signature

Bug#905542: xserver-xorg-video-nouveau: segmentation fault on startup every time

[Eric Cooper]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.15-3
Severity: important

I did an "apt-get upgrade" today that installed new
xserver-xorg-{core,nouveau} packages. Now X does not start on my system.
The same segmentation fault occurs every time I run "startx".

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
440] [10de:0de0] (rev a1)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.17.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-26)) #1 SMP Debian 4.17.8-1 (2018-07-20)

Xorg X server log files on system:
--
-rw-r--r-- 1 ecc ecc 23081 Jul  9 14:39 /home/ecc/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 ecc ecc 35236 Aug  5 15:37 /home/ecc/.local/share/xorg/Xorg.0.log

Contents of most recent Xorg X server log file 
(/home/ecc/.local/share/xorg/Xorg.0.log):

[   300.857]
X.Org X Server 1.20.0
X Protocol Version 11, Revision 0
[   300.859] Build Operating System: Linux 4.9.0-6-amd64 x86_64 Debian
[   300.859] Current Operating System: Linux xyzzy 4.17.0-1-amd64 #1 SMP Debian 
4.17.8-1 (2018-07-20) x86_64
[   300.859] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.17.0-1-amd64 
root=UUID=1bd202e7-8d8c-4170-8388-abddc49cd075 ro quiet
[   300.861] Build Date: 01 July 2018  05:07:24PM
[   300.861] xorg-server 2:1.20.0-3 (https://www.debian.org/support)
[   300.862] Current version of pixman: 0.34.0
[   300.863]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   300.863] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   300.865] (==) Log file: "/home/ecc/.local/share/xorg/Xorg.0.log", Time: Sun 
Aug  5 15:37:14 2018
[   300.866] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   300.866] (==) No Layout section.  Using the first Screen section.
[   300.866] (==) No screen section available. Using defaults.
[   300.866] (**) |-->Screen "Default Screen Section" (0)
[   300.866] (**) |   |-->Monitor ""
[   300.867] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   300.867] (==) Automatically adding devices
[   300.867] (==) Automatically enabling devices
[   300.867] (==) Automatically adding GPU devices
[   300.867] (==) Max clients allowed: 256, resource mask: 0x1f
[   300.867] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   300.867]Entry deleted from font path.
[   300.867] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   300.867] (==) ModulePath set to "/usr/lib/xorg/modules"
[   300.867] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   300.867] (II) Loader magic: 0x5612396eade0
[   300.867] (II) Module ABI versions:
[   300.867]X.Org ANSI C Emulation: 0.4
[   300.867]X.Org Video Driver: 24.0
[   300.867]X.Org XInput driver : 24.1
[   300.867]X.Org Server Extension : 10.0
[   300.868] (++) using VT number 1

[   300.871] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_31
[   300.873] (II) xfree86: Adding drm device (/dev/dri/card0)
[   300.874] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 paused 0
[   300.882] (--) PCI:*(1@0:0:0) 10de:0de0:1043:83b7 rev 161, Mem @ 
0xf600/16777216, 0xe800/134217728, 0xf200/33554432, I/O @ 
0xcc00/128, BIOS @ 0x/131072
[   300.883] (II) LoadModule: "glx"
[   300.883] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   300.884] (II) Module glx: vendor="X.Org Foundation"
[   300.884]compiled for 1.20.0, module version = 1.0.0
[   300.884]ABI class: X.Org Server Extension, version 10.0
[   300.884] (==) Matched nouveau as autoconfigured driver 0
[   300.884] (==) Matched nv as autoconfigured driver 1
[   300.884] (==) Matched modesetting as autoconfigured driver 2
[   300.884] (==) Matched fbdev as autoconfigured driver 3
[   300.884] (==) Matched vesa as autoconfigured driver 4
[   300.884] (==) Assigned the driver to the xf86ConfigLayout
[   300.884] (II) LoadModule: "nouveau"
[   300.884] (II) Loading /usr/

Bug#904895: #904895: standards.ieee.org should be accessed over https

[Luciano Bello]

I just uploaded the fix to unstable.

In the past, TLS AIA were a problem for some downloaders (IIUC, they
should be solved at this point tho):  https://bugs.debian.org/783096

I will wait a bit before updating old/stable to catch similar issues.

Thanks for your report

/luciano

Bug#905455: RFS: dmidecode/3.1-2

[Herbert Fortes]

Em 05-08-2018 16:14, Andrey Rahmatullin escreveu:

On Sun, Aug 05, 2018 at 03:54:23PM -0300, Herbert Fortes wrote:

Sorry, but can you please add to debian/rules:

export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
export DEB_CFLAGS_MAINT_APPEND = -fPIE

Why?

Becauso of 'blhc --all'

I'm sorry but that's not a valid reason.

Can you tell me why not?

Sure.
First of all, you should never do some change because some static analyzer
told you. You need to understand what did it tell you, why, and why it
thinks you should do that change.
blhc just analyzes build logs to make sure all expected flags are passed.
"--all   Force check for all +all (+pie, +bindnow) hardening flags. By default it's 
auto detected."
So if you use --all you either know that the package should pass the flags
for both pie and bindnow or must ignore the respective blhc warnings.
dpkg-buildflags(1) says that the pie hardening option has no effect on
most architectures, as it's enabled in gcc, so no flags are passed.
In such situations you need to check the result, in this case check
whether the binary has PIE enabled, not just blindly follow an
incorrectly used static analyzer (and even then you need to find out the
problem and not just pass some compiler/linker flags).



Ok. Thanks.

Bug#905541: spyder-unittest: autopkgtest fails with python3.7 in supported versions

[Paul Gevers]

Control: tags -1 ftbfs
Control: severity -1 serious

The reproducible-builds project shows that the same error causes the
package to build from source.

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/spyder-unittest.html

Paul



signature.asc
Description: OpenPGP digital signature

Bug#905541: spyder-unittest: autopkgtest fails with python3.7 in supported versions

[Paul Gevers]

Source: spyder-unittest
Version: 0.3.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: needs-update

Dear maintainers,

Currently the python3.7 transition¹ is going on, which means that
python3.7 is added to the supported python3 versions. However, since
python3-defaults added python3.7 support, your autopkgtest has been
failing. Because your test somehow depends on pandas, which needed a new
version which only yesterday migrated, I could not detect and report the
issue below earlier.

Could you please investigate? It seems you're processing the output from
pycodestyle when the error occurs, so I wouldn't be surprised if the bug
was there. In that case, please reassign this bug.

Paul

¹ https://release.debian.org/transitions/html/python3.7.html

https://ci.debian.net/data/autopkgtest/testing/amd64/s/spyder-unittest/773675/log.gz

=== FAILURES
===
_ test_run_tests_and_display_results[py.test]
__
CALL ERROR: Qt exceptions in virtual methods:

Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/spyder_unittest/backend/jsonstream.py",
line 92, in consume
len_encoding = int(txt[index:end_of_line1])
ValueError: invalid literal for int() with base 10:
'/usr/lib/python3/dist-packages/pycodestyle.py:113: FutureWarning:
Possible nested set at position 1'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/spyder_unittest/backend/pytestrunner.py",
line 44, in read_output
result = self.reader.consume(output)
  File
"/usr/lib/python3/dist-packages/spyder_unittest/backend/jsonstream.py",
line 95, in consume
% (repr(txt), index, end_of_line1))
ValueError: txt = '805\n{"event": "finished", "stdout":
"= test session starts
==\\nplatform linux -- Python 3.7.0,
pytest-3.6.4, py-1.5.4, pluggy-0.6.0\\nPyQt5 5.11.2 -- Qt runtime 5.10.1
-- Qt compiled 5.10.1\\nrootdir:
/tmp/pytest-of-debci/pytest-0/test_run_tests_and_display_res0,
inifile:\\nplugins: xvfb-1.0.0, qt-2.3.1\\ncollected 2
items\\n\\ntest_foo.py .F
   [100%]\\n\\n=== FAILURES
===\\n__
test_fail ___\\n\\n>   def test_fail():
assert 1+1 == 3\\nE   assert (1 + 1) == 3\\n\\ntest_foo.py:2:
AssertionError\\n== 1 failed, 1 passed in 0.06
seconds
==\\n"}\n/usr/lib/python3/dist-packages/pycodestyle.py:113:
FutureWarning: Possible nested set at position 1\n
EXTRANEOUS_WHITESPACE_REGEX = re.compile(r\'[[({] | []}),;:]\')\n'
index = 810  end_of_line1 = 909



signature.asc
Description: OpenPGP digital signature

Bug#905485: chrony: AppArmor in complain mode

[Vincent Blut]

Hi Kurt,

On Sun, Aug 05, 2018 at 11:58:38AM +0200, Kurt Roeckx wrote:

Package: chrony
Version: 3.3-2

Hi,

Why is the AppArmor profile put into complain mode?


To avoid breaking chrony installations due to our (at the time) immature 
AppArmor profile for users upgrading to chrony 3.2-2. For new installs 
the profile is placed into “enforce” mode though.



The preinst has this:
case "$1" in
   upgrade)
   APP_PROFILE="usr.sbin.chronyd"
   APP_CONFFILE="/etc/apparmor.d/$APP_PROFILE"
   APP_COMPLAIN="/etc/apparmor.d/force-complain/$APP_PROFILE"
   # force-complain on upgrade from pre-shipped profile
   if dpkg --compare-versions "$2" lt "3.2-2" ; then
   mkdir -p `dirname "$APP_COMPLAIN"` 2>/dev/null || true
   ln -sf "$APP_CONFFILE" "$APP_COMPLAIN"
   fi
   ;;


What pre-shipped profiles is this about?


Pre-shipped profile corresponds to any chrony version lacking an 
AppArmor profile (i.e. chrony versions < 3.2-2).



It seems to trigger for every upgraded, and I don't understand why.


Hope the above makes things clearer‽


Kurt


Warmly,
Vincent


signature.asc
Description: PGP signature

Bug#905540: dask.distributed: autopkgtest fails with python3.7 in supported versions

[Paul Gevers]

Source: dask.distributed
Version: 1.21.8+ds.1-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: needs-update

Dear maintainers,

Currently the python3.7 transition¹ is going on, which means that
python3.7 is added to the supported python3 versions. However, since
python3-defaults added python3.7 support, your autopkgtest has been
failing. Because your test somehow depends on pandas, which needed a new
version which only yesterday migrated, I could not detect and report the
issue below earlier.

Could you please investigate? The first error looks like the source
isn't ready for Python3.7 yet, I suggest you pick this up with upstream
and point upstream at PEP-479². I think the right action right now is to
claim that the package doesn't support Python3.7 (by adding the right
X-Python3-Version³ to debian/control?). Don't forget to check if the
autopkgtest also needs updates to test with the right versions.

There are a lot of timeout issues after the first error, I'm not sure if
they are separate issues or caused by the first.

Paul

¹ https://release.debian.org/transitions/html/python3.7.html
² https://docs.python.org/3.7/whatsnew/3.7.html#changes-in-python-behavior
³
https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dask.distributed/773696/log.gz

~~~ Captured stderr

Exception in thread Threaded map():
Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/distributed/tests/test_client.py", line
2350, in g
raise StopIteration(3)  # py2.7 compat.
StopIteration: 3

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
self.run()
  File "/usr/lib/python3.7/threading.py", line 865, in run
self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3/dist-packages/distributed/client.py", line
1202, in _threaded_map
args = [get(q) for q in qs_in]
  File "/usr/lib/python3/dist-packages/distributed/client.py", line
1202, in 
args = [get(q) for q in qs_in]
RuntimeError: generator raised StopIteration




signature.asc
Description: OpenPGP digital signature

Bug#905455: RFS: dmidecode/3.1-2

[Andrey Rahmatullin]

On Sun, Aug 05, 2018 at 03:54:23PM -0300, Herbert Fortes wrote:
> > > > > Sorry, but can you please add to debian/rules:
> > > > > 
> > > > > export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
> > > > > export DEB_CFLAGS_MAINT_APPEND = -fPIE
> > > > Why?
> > > Becauso of 'blhc --all'
> > I'm sorry but that's not a valid reason.
> Can you tell me why not?
Sure.
First of all, you should never do some change because some static analyzer
told you. You need to understand what did it tell you, why, and why it
thinks you should do that change.
blhc just analyzes build logs to make sure all expected flags are passed.
"--all   Force check for all +all (+pie, +bindnow) hardening flags. By default 
it's auto detected."
So if you use --all you either know that the package should pass the flags
for both pie and bindnow or must ignore the respective blhc warnings.
dpkg-buildflags(1) says that the pie hardening option has no effect on 
most architectures, as it's enabled in gcc, so no flags are passed.
In such situations you need to check the result, in this case check 
whether the binary has PIE enabled, not just blindly follow an 
incorrectly used static analyzer (and even then you need to find out the 
problem and not just pass some compiler/linker flags).

> 
> What I know is just 'blhc' is enough. But why not
> use '--all'?
> 
> I do not know much about that and I can learn new
> if you say a bit more.
> 
> 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#842815: Help needed for HDF5 1.10 transition of libsis-jhdf5-java

[Bernd Rinn]

Hello Andreas,

There are some good news: For porting JHDF5 to HDF 1.10, I got help from
Gerd Heber. I have been fixing some looes ends in the last couple of
days and now the porting is now. I still want to do some improvements to
the library (not dependent on the underlying HDF5 version) and need to
work on the Windows build, but there is nothing that would keep you from
updating the port in Debian unstable. The build procedure for Linux
won't change anymore.

The current version of JHDF5 building on top of HDF5 1.10.3-pre1, you
will find in (branch master):

https://sissource.ethz.ch/sispub/jhdf5

I plan to do in about 2 weeks time a JHDF5 pre-release to get feedback
from users outside my organization. The release should then be based on
HDF5 1.10.3 once that version has been released by the HDF group. If you
have anyone who could test the pre-release version or your port, please
feel free to forward this email to him or her.

All the best,
Bernd

On 08/04/2018 08:06 AM, Andreas Tille wrote:
> Hello Bernd,
> 
> On Mon, May 28, 2018 at 09:18:28AM +0200, Bernd Rinn wrote:
>> Hello Andreas,
>>
>> On 05/27/2018 07:12 AM, Andreas Tille wrote:
>>> Hello Bernd,
>>>
>>> sorry for nagging again but we now have another Dependency from
>>> sis-jhdf5 which makes a fix for this issue even more interesting.  As I
>>> said before I would also try a patch if you might hesitate to issue a
>>> completely new release.
>>
>> It is embarrassing to admit that I still haven't found the time to port
>> JHDF5 to HDF5 1.10.
>>
>> If you can come up with a patch to bridge to time that would be greatly
>> appreciated!
> 
> Since I personally do not even know what HDF5 is I can not help myself
> and as far as Gilles Filippini stated[1] chances are pretty low that we
> from Debian will be able to come up with a patch.  What do you think
> about the remark
> 
>Have you considered using libhdf5-java[2] or libjhdf5-java instead?
> 
> Well, several projects are using libsis-hdf5-java but it might be to
> join forces with one single Java library which keeps up with current
> development.  I have no idea in how far libsis-hdf5-java is different
> for the other libs but could you somehow imagine to unify the interface
> and join forces?
> 
> Kind regards
> 
>   Andreas.
> 
> [1] https://lists.debian.org/debian-science/2018/05/msg00112.html
> [2] https://support.hdfgroup.org/HDF5/
> [3] 
> 
>>> On Wed, Sep 06, 2017 at 12:50:56PM +0200, Andreas Tille wrote:
 Hello Bernd,

 On Wed, 23 Nov 2016 06:54:21 +0100, you wrote
> the migration of JHDF5 to HDF5 1.10 is ongoing and mostly depend on me
> having a block of time I can spend on it. Your analysis of the work that
> needs to be done is right from what I can see. The plan is to switch to
> using the JNI library from the HDF group wherever possible (it may still
> be necessary to have a small JNI library though as some calls appear to
> be missing).
>
> I will keep you updated.

 Is there any news, may be only a patch for the existing version we
 could try to fix the Debian package?

 Kind regards

Andreas.

 -- 
 http://fam-tille.de

 ___
 Debian-med-packaging mailing list
 debian-med-packag...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

>>>
>>
>> -- 
>> Dr. Bernd Rinn
>> Head Scientific IT Services
>> ETH Zurich IT Services
>> SIB Swiss Institute of Bioinformatics
>> Weinbergstr. 11 (WEC D 19), 8092 Zürich, Switzerland, +41 44 632 0608
>> Mattenstr. 26 (BSB 1.01), 4058 Basel, Switzerland, +41 61 387 3130
>>
> 
> 
> 

-- 
Dr. Bernd Rinn
Head Scientific IT Services
ETH Zurich IT Services
SIB Swiss Institute of Bioinformatics
Weinbergstr. 11 (WEC D 19), 8092 Zürich, Switzerland, +41 44 632 0608
Mattenstr. 26 (BSB 1.01), 4058 Basel, Switzerland, +41 61 387 3130



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#842815: Help needed for HDF5 1.10 transition of libsis-jhdf5-java

[Bernd Rinn]

Hello Andreas,

There are some good news: For porting JHDF5 to HDF 1.10, I got help from
Gerd Heber. I have been fixing some looes ends in the last couple of
days and now the porting is now. I still want to do some improvements to
the library (not dependent on the underlying HDF5 version) and need to
work on the Windows build, but there is nothing that would keep you from
updating the port in Debian unstable. The build procedure for Linux
won't change anymore.

The current version of JHDF5 building on top of HDF5 1.10.3-pre1, you
will find in (branch master):

https://sissource.ethz.ch/sispub/jhdf5

I plan to do in about 2 weeks time a JHDF5 pre-release to get feedback
from users outside my organization. The release should then be based on
HDF5 1.10.3 once that version has been released by the HDF group. If you
have anyone who could test the pre-release version or your port, please
feel free to forward this email to him or her.

All the best,
Bernd

On 08/04/2018 08:06 AM, Andreas Tille wrote:
> Hello Bernd,
> 
> On Mon, May 28, 2018 at 09:18:28AM +0200, Bernd Rinn wrote:
>> Hello Andreas,
>>
>> On 05/27/2018 07:12 AM, Andreas Tille wrote:
>>> Hello Bernd,
>>>
>>> sorry for nagging again but we now have another Dependency from
>>> sis-jhdf5 which makes a fix for this issue even more interesting.  As I
>>> said before I would also try a patch if you might hesitate to issue a
>>> completely new release.
>>
>> It is embarrassing to admit that I still haven't found the time to port
>> JHDF5 to HDF5 1.10.
>>
>> If you can come up with a patch to bridge to time that would be greatly
>> appreciated!
> 
> Since I personally do not even know what HDF5 is I can not help myself
> and as far as Gilles Filippini stated[1] chances are pretty low that we
> from Debian will be able to come up with a patch.  What do you think
> about the remark
> 
>Have you considered using libhdf5-java[2] or libjhdf5-java instead?
> 
> Well, several projects are using libsis-hdf5-java but it might be to
> join forces with one single Java library which keeps up with current
> development.  I have no idea in how far libsis-hdf5-java is different
> for the other libs but could you somehow imagine to unify the interface
> and join forces?
> 
> Kind regards
> 
>   Andreas.
> 
> [1] https://lists.debian.org/debian-science/2018/05/msg00112.html
> [2] https://support.hdfgroup.org/HDF5/
> [3] 
> 
>>> On Wed, Sep 06, 2017 at 12:50:56PM +0200, Andreas Tille wrote:
 Hello Bernd,

 On Wed, 23 Nov 2016 06:54:21 +0100, you wrote
> the migration of JHDF5 to HDF5 1.10 is ongoing and mostly depend on me
> having a block of time I can spend on it. Your analysis of the work that
> needs to be done is right from what I can see. The plan is to switch to
> using the JNI library from the HDF group wherever possible (it may still
> be necessary to have a small JNI library though as some calls appear to
> be missing).
>
> I will keep you updated.

 Is there any news, may be only a patch for the existing version we
 could try to fix the Debian package?

 Kind regards

Andreas.

 -- 
 http://fam-tille.de

 ___
 Debian-med-packaging mailing list
 debian-med-packag...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

>>>
>>
>> -- 
>> Dr. Bernd Rinn
>> Head Scientific IT Services
>> ETH Zurich IT Services
>> SIB Swiss Institute of Bioinformatics
>> Weinbergstr. 11 (WEC D 19), 8092 Zürich, Switzerland, +41 44 632 0608
>> Mattenstr. 26 (BSB 1.01), 4058 Basel, Switzerland, +41 61 387 3130
>>
> 
> 
> 

-- 
Dr. Bernd Rinn
Head Scientific IT Services
ETH Zurich IT Services
SIB Swiss Institute of Bioinformatics
Weinbergstr. 11 (WEC D 19), 8092 Zürich, Switzerland, +41 44 632 0608
Mattenstr. 26 (BSB 1.01), 4058 Basel, Switzerland, +41 61 387 3130



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#905455: RFS: dmidecode/3.1-2

[Andrey Rahmatullin]

On Sun, Aug 05, 2018 at 03:23:33PM -0300, Herbert Fortes wrote:
> > > Sorry, but can you please add to debian/rules:
> > > 
> > > export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
> > > export DEB_CFLAGS_MAINT_APPEND = -fPIE
> > Why?
> > 
> 
> Becauso of 'blhc --all'
Actually, I think using blhc with --all is wrong by itself.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#905455: RFS: dmidecode/3.1-2

[Herbert Fortes]

Em 05-08-2018 15:47, Andrey Rahmatullin escreveu:

On Sun, Aug 05, 2018 at 03:23:33PM -0300, Herbert Fortes wrote:

Sorry, but can you please add to debian/rules:

export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
export DEB_CFLAGS_MAINT_APPEND = -fPIE

Why?



Becauso of 'blhc --all'

I'm sorry but that's not a valid reason.



Can you tell me why not?

What I know is just 'blhc' is enough. But why not
use '--all'?

I do not know much about that and I can learn new
if you say a bit more.

Bug#905539: gcc-7 FTBFS with isl 0.20

[Helmut Grohne]

Source: gcc-7
Version: 7.3.0-27
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

Hi Matthias,

I'm not sure whether you're aware already, but I felt that it was best
to just document that gcc-7 fails to build against isl 0.20. I tried to
check the vcs on whether this is already pending, but since alioth is
offline finding the vcs is difficult. Maybe you could also update the
Vcs fields. Build log symptom:

| ../../src/gcc/graphite-optimize-isl.c: In function 'isl_schedule_node* 
get_schedule_for_node_st(isl_schedule_node*, void*)':
| ../../src/gcc/graphite-optimize-isl.c:57:52: error: 'isl_space_dim' was not 
declared in this scope
|unsigned dims = isl_space_dim (space, isl_dim_set);

Helmut

Bug#905538: ITP: gotest.tools -- go packages to support common testing patterns

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 

* Package name: gotest.tools
  Version : 2.1.0-1
  Upstream Author : gotest.tools authors
* URL : https://github.com/gotestyourself/gotest.tools
* License : Apache-2.0
  Programming Lang: Go
  Description : collection of go packages to support common testing patterns

 Gotest.tools is a collection of Go packages to augment 'testing' and
 support common testing patterns.
 .
 It is a dependency of Docker version 18.06.
 .
 This package will be maintained within the Go team.

Bug#905455: RFS: dmidecode/3.1-2

[Andrey Rahmatullin]

On Sun, Aug 05, 2018 at 03:23:33PM -0300, Herbert Fortes wrote:
> > > Sorry, but can you please add to debian/rules:
> > > 
> > > export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
> > > export DEB_CFLAGS_MAINT_APPEND = -fPIE
> > Why?
> > 
> 
> Becauso of 'blhc --all'
I'm sorry but that's not a valid reason.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#905455: RFS: dmidecode/3.1-2

[Herbert Fortes]

Em 05-08-2018 15:27, Jörg Frings-Fürst escreveu:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Herbert,

thanks for your review.

Am Sonntag, den 05.08.2018, 15:02 -0300 schrieb Herbert Fortes:

Hi,


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dmidecode"

 Package name: dmidecode
 Version : 3.1-2
 Upstream Author : dmidecode-de...@nongnu.org
 URL : https://nongnu.org/dmidecode/
 License : GPL-2+
 Section : utils

It builds those binary packages:

   dmidecode  - SMBIOS/DMI table decoder
   dmidecode-udeb - SMBIOS/DMI table decoder (udeb) (udeb)



Sorry, but can you please add to debian/rules:

export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
export DEB_CFLAGS_MAINT_APPEND = -fPIE

It is just a copy and paste :)



Blame on me :-(

Added, tested and uploaded again.



thanks for your patience Jörg

Uploaded.



Regards,
Herbert

Bug#897060: Bug gone?

[Joris Baum]

The bug seems to be gone. I have not experienced it in a while and
waiting before entering my decryption key does not seem to do the trick
any longer.

Bug#904514: closed by Georges Khaznadar (Bug#904514: fixed in expeyes 4.4.3+dfsg-3)

[Andreas Beckmann]

Control: found -1 4.4.3+dfsg-3

On 2018-08-05 01:51, Debian Bug Tracking System wrote:
>* promoted the recommendation python3-expeyes <- udev to a dependency.

udev was a red herring. This change can be reverted.


The problem is most likely this code from the postinst:

## this was not managed properly by debian/rules:
if which py3compile >/dev/null 2>&1; then
py3compile -p python-expeyes
fi

I can totally confirm your comment. Why does python3-expeyes try to do
anything at all with the python2 variant ?


Andreas

Bug#905531: Info received (snmpd: Stupid error during dist-upgrade)

[Paul Gevers]

Interesting,

(not the b1, but I only had the regular build on the buildd)

libsnmp30_5.7.2.1+dfsg-1+deb8u1_amd64.deb
-
 Depends: libc6 (>= 2.17), libpci3 (>= 1:3.2.1-1), libperl5.20 (>=
5.20.2), libsensors4 (>= 1:3.0.0), libssl1.0.0 (>= 1.0.0), libwrap0 (>=
7.6-4~), libsnmp-base

So it's libperl5.20 as far as I can tell. Which version of libsnmp30 do
you have installed?

And do you have libperl5.14 installed?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#905455: RFS: dmidecode/3.1-2

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Herbert,

thanks for your review.

Am Sonntag, den 05.08.2018, 15:02 -0300 schrieb Herbert Fortes:
> Hi,
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Package: sponsorship-requests
> > Severity: normal
> > 
> > Dear mentors,
> > 
> >I am looking for a sponsor for my package "dmidecode"
> > 
> > Package name: dmidecode
> > Version : 3.1-2
> > Upstream Author : dmidecode-de...@nongnu.org
> > URL : https://nongnu.org/dmidecode/
> > License : GPL-2+
> > Section : utils
> > 
> >It builds those binary packages:
> > 
> >   dmidecode  - SMBIOS/DMI table decoder
> >   dmidecode-udeb - SMBIOS/DMI table decoder (udeb) (udeb)
> > 
> 
> Sorry, but can you please add to debian/rules:
> 
> export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
> export DEB_CFLAGS_MAINT_APPEND = -fPIE
> 
> It is just a copy and paste :)
> 

Blame on me :-(

Added, tested and uploaded again.


> 
> 
> Regards,
> Herbert

CU 
Jörg


- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAltnQYgACgkQCfifPIyh
0l12Bw/8D6xKtjAKzcZz7+2WEAv4WoeR3H3Fi3pdkXvazD4gyTV8jRtQwmed7HKR
L9+8yhrPKnkg3Rb3ALA+9zZVbjpvnEpvEgULLREX3fpFuHoGHJ+gFakAEb2mptj0
6XI5yksJid7lfJFXGyNScZyW3Ogz/Is5PgBcD2cOq5jALPqas9KEGjFg1/VT3UFY
Eu/bLZ/r4lEL4mOu2X9WcuWau+EHYbES7UeTjghv7xI+kXm25rPm5nERihiNm+eW
hRJ+1JrbOQWO3FmqE4bHX+jYY/QsZIrYm7A4290r48v6SLxoKa8AfmQSLxHGpWsp
VClfvgj0WUzBbpL7hyko2UGRABm9CqlOOJ7SxTFM/f6Cv94T1TuQiWgtx9c2vsw3
uiEPEKFhSexsHDRe8uQ8hKxVxYNFaXH5opGYbnd+OdLXLOdc4kWD4nzefx5hDi3p
kJI3Au7G0Bn+Tgi3Kozg9rbQ7CGqK9G2ErNhkqbjWI7yaSbOKZ5yRmoFmLJjjVvX
9bzvhiTzN+RKAxK/8MctwW8gWJKnzY4KW4kwQ4MUtp6U7orXMn9fl0M85HgPNV7R
Sppk4bOpHUn/GL4i/KJrP4J0soHfiToaSQS9CENyRZQkdgzCDIWUIWPVuaJ594IC
SRuCum+iXx/LI5EN/QqfTZ2pof86pZEHChhndQoZFxe48QxlR1s=
=P0z5
-END PGP SIGNATURE-

Bug#905537: Should require LLVM >=3.9

[Andreas Ferber]

Source: qttools-opensource-src
Version: 5.11.1-3
Severity: normal

Hi,

when trying to build the package on Debian Stable (plus various other
backports of course), it fails, with the important message being:

-
LLVM/Clang version >= 3.9.0 required, version provided: 3.8.1.
Clang was found in /usr/lib/llvm-3.8. Set the LLVM_INSTALL_DIR
environment variable to override.
-

I think the LLVM build dependencies (libclang-dev, llvm-dev) should
therefore be versioned with (>= 3.9).

Regards,
Andreas Ferber

Bug#905455: RFS: dmidecode/3.1-2

[Herbert Fortes]

Em 05-08-2018 15:10, Andrey Rahmatullin escreveu:

On Sun, Aug 05, 2018 at 03:02:39PM -0300, Herbert Fortes wrote:

Sorry, but can you please add to debian/rules:

export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
export DEB_CFLAGS_MAINT_APPEND = -fPIE

Why?



Becauso of 'blhc --all'

Bug#888556: Acknowledgement (libetsf-io-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc/libetsf-io-dev/AUTHORS)

[Adrian Bunk]

On Fri, Feb 02, 2018 at 12:28:09AM +0100, Andreas Beckmann wrote:
> This is probably fixed in latest debhelper, #888294

No, doesn't seem so.

$ debdiff libetsf-io-doc_1.0.4-1.1_all.deb libetsf-io-doc_1.0.4-2_all.deb 
...
Files in second .deb but not in first
-
-rw-r--r--  root/root   /usr/share/doc/libetsf-io-dev/AUTHORS
-rw-r--r--  root/root   /usr/share/doc/libetsf-io-dev/README
-rw-r--r--  root/root   /usr/share/doc/libetsf-io-dev/TODO

Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/share/doc/libetsf-io-doc/AUTHORS
-rw-r--r--  root/root   /usr/share/doc/libetsf-io-doc/README
-rw-r--r--  root/root   /usr/share/doc/libetsf-io-doc/TODO
...


This looks related to the dh_installdocs changes in compat 11.


> Andreas

cu
Adrian

-- 

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

Bug#905531: Info received (snmpd: Stupid error during dist-upgrade)

[Teo Tei]

# locate libperl.so.5.14
/usr/lib/libperl.so.5.14
/usr/lib/libperl.so.5.14.2

# ls -la /usr/lib/libperl.so.5.14
ls: cannot access /usr/lib/libperl.so.5.14: No such file or directory

# ls -la /usr/lib/libperl.so.5.14.2
ls: cannot access /usr/lib/libperl.so.5.14.2: No such file or directory

# ldd /usr/sbin/snmpd
linux-vdso.so.1 (0x7fff4f5c9000)
libnetsnmpagent.so.30 => /usr/lib/x86_64-linux-gnu/libnetsnmpagent.so.30
(0x7febf5ab)
libnetsnmpmibs.so.30 => /usr/local/lib/libnetsnmpmibs.so.30
(0x7febf5642000)
libnetsnmp.so.30 => /usr/lib/x86_64-linux-gnu/libnetsnmp.so.30
(0x7febf535d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7febf505c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7febf4cb1000)
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x7febf4aa6000)
libperl.so.5.20 => /usr/lib/x86_64-linux-gnu/libperl.so.5.20
(0x7febf46e5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7febf44e1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7febf42c4000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x7febf408d000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7febf3e85000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x7febf3a88000)
/lib64/ld-linux-x86-64.so.2 (0x7febf5d1f000)
libperl.so.5.14 => not found
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7febf387)


2018-08-05 19:57 GMT+02:00 Debian Bug Tracking System :

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Net-SNMP Packaging Team 
>
> If you wish to submit further information on this problem, please
> send it to 905...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 905531: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905531
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#905455: RFS: dmidecode/3.1-2

[Andrey Rahmatullin]

On Sun, Aug 05, 2018 at 03:02:39PM -0300, Herbert Fortes wrote:
> Sorry, but can you please add to debian/rules:
> 
> export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
> export DEB_CFLAGS_MAINT_APPEND = -fPIE
Why?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#829417: dosemu: *** stack smashing detected ***: /usr/bin/xdosemu terminated

[Bernhard Übelacker]

Am 04.08.2018 um 21:53 schrieb Wolfgang Grünstern:
> Thank you,
> will the Debian version receive the patch next time automatically?
> Kind Regards,
> Wolfgang



Hello Wolfgang,
that would be up to the package maintainer, I think.
Probably the best would be to try to get in contact with him directly.

But I am unsure how the chances are because the package is currently
removed from testing because of bug [866965].
Probably that needs to be resolved one way or another
before a new upload would be done?

Kind regards,
Bernhard

Bug#905455: RFS: dmidecode/3.1-2

[Herbert Fortes]

Hi,


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: normal

Dear mentors,

   I am looking for a sponsor for my package "dmidecode"

Package name: dmidecode
Version : 3.1-2
Upstream Author : dmidecode-de...@nongnu.org
URL : https://nongnu.org/dmidecode/
License : GPL-2+
Section : utils

   It builds those binary packages:

  dmidecode  - SMBIOS/DMI table decoder
  dmidecode-udeb - SMBIOS/DMI table decoder (udeb) (udeb)



Sorry, but can you please add to debian/rules:

export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
export DEB_CFLAGS_MAINT_APPEND = -fPIE

It is just a copy and paste :)



Regards,
Herbert

Bug#905531: snmpd: Stupid error during dist-upgrade

[Teo Tei]

The actual error seems to be this:

# service snmpd restart
[] Restarting SNMP services::/usr/sbin/snmpd: error while loading
shared libraries: libperl.so.5.14: cannot open shared object file: No such
file or directory


2018-08-05 19:45 GMT+02:00 Niels Thykier :
>
> Thanks for the update.  Could you kindly write that on the bug report so
> the package maintainer can see it and handle it (or allow me to forward
> your email)?
>
> You can post it to the bug by emailing: 905...@bugs.debian.org
>
>
Sorry, I thought that was what I was doing by replying to the email.

Bug#892016: scratch: segfault in lookupMethodInClass upon trying to load an image from the webcam

[Bernhard Übelacker]

Hello Wouter,
thanks for this additional information.

I could reproduce the issue with a usb webcam inside a buster amd64 VM.
Unfortunately this camera button was with the german translation not
visible with the small resolution of that VM.

It took a little time to get into the smalltalk side of things.
But I think I have found a problem - on the c side of the plugins.



(gdb) bt
#0  0x7fffafa33c82 in convertImageRGB24toARGB32 (cam=0x7fffafa37180 
) at ./unix/plugins/CameraPlugin/sqCamera-linux.c:333
#1  0x7fffafa33f2a in convertImage (cam=0x7fffafa37180 ) at 
./unix/plugins/CameraPlugin/sqCamera-linux.c:412
#2  0x7fffafa34d10 in CameraGetFrame (camNum=1, buf=0x7fffb2b9fcb4 "", 
pixelCount=76800) at ./unix/plugins/CameraPlugin/sqCamera-linux.c:836
#3  0x7fffafa3352c in primGetFrame () at 
./unix/src/plugins/CameraPlugin/CameraPlugin.c:160
#4  0x55578ca4 in dispatchFunctionPointer 
(aFunctionPointer=0x7fffafa33461 ) at 
./build-tree/gnu-interp.c:3809
#5  0x555769f8 in callExternalPrimitive (functionID=0x7fffafa33461 
) at ./build-tree/gnu-interp.c:2512
#6  0x5558fc92 in primitiveExternalCall () at 
./build-tree/gnu-interp.c:17732
#7  0x55578ca4 in dispatchFunctionPointer 
(aFunctionPointer=0x5558faf0 ) at 
./build-tree/gnu-interp.c:3809
#8  0x5558227a in interpret () at ./build-tree/gnu-interp.c:9339
#9  0x555a7cef in main (argc=8, argv=0x7fffe2a8, 
envp=0x7fffe2f0) at ./unix/vm/sqUnixMain.c:1458

(gdb) list convertImageRGB24toARGB32
319 static void
320 convertImageRGB24toARGB32 (camPtr cam)
321 {
322 unsigned char *src = cam->inBuffer;
323 unsigned long int *dst = cam->sqBuffer;   <-- 
sizeof(*dst) == 8, should be 4 ?
324 unsigned long int pixelCount = cam->sqPixels;
325 unsigned long int pixel;
326 int i;
327
328 if (0 == dst) return;
329
330 for ( i = 0; i < pixelCount; i++) {
331 pixel = 0xFF00 | (*src++ << 16);
332 pixel = pixel | (*src++ << 8);
333 *dst++  = pixel | *src++;
334 }
335 }



Here the buffer allocated in the squeak-vm is given to primGetFrame
and gets finally the image written to in convertImageRGB24toARGB32.
Unfortunately these conversion functions use "unsigned long int *dst",
with a long int having a size of 8 bytes at amd64, while we got
just 4 bytes per pixel reserved from squeak-vm, therefore
overrunning our reserved buffer.


When just installing the packages the plugin so.CameraPlugin gets
used from the package squeak-plugins-scratch.
But a similar so.CameraPlugin is already packaged with squeak-vm.

 squeak-vm: /usr/lib/squeak/4.10.2.2614/so.CameraPlugin
squeak-plugins-scratch: /usr/lib/scratch/plugins/so.CameraPlugin

So this probably should be clarified if the plugins are really
needed in both packages.


Therefore this report should be changed to packages
squeak-vm and squeak-plugins-scratch?


Attached both patches change this buffer element size in the conversion
function from 8 to 4. With them applied both plugins were able to
show me the picture from the webcam inside scratch.


Kind regards,
Bernhard
Description: Make camera plugin work at amd64 platform.
 The convertImageRGB* using a "unsigned long int" pointer.
 Unfortunately is sizeof(unsigned long int) at amd64 8 bytes.
 Therefore the buffer allocated at smalltalk-side and given to
 c-side to receive the picture is being overrun.

Author: Bernhard Übelacker 

Bug-Debian: https://bugs.debian.org/892016
Forwarded: no
Last-Update: 2018-08-05

--- squeak-plugins-scratch-1.4.0.2~svn.r83.orig/camera/sqCamera-linux.c
+++ squeak-plugins-scratch-1.4.0.2~svn.r83/camera/sqCamera-linux.c
@@ -320,11 +320,14 @@ static void
 convertImageRGB24toARGB32 (camPtr cam)
 {
 	unsigned char 	  *src = cam->inBuffer;
-	unsigned long int *dst = cam->sqBuffer;
+	unsigned int  *dst = cam->sqBuffer;
 	unsigned long int pixelCount = cam->sqPixels;
 	unsigned long int pixel;
 	int i;
 
+	if (sizeof(*dst) != 4)
+		printf("Invalid buffer element size, expect crash: %i should be %i\n", sizeof(*dst), 4);
+
 	if (0 == dst) return;
 
 	for ( i = 0; i < pixelCount; i++) {
@@ -339,11 +342,14 @@ static void
 convertImageRGB444toARGB32 (camPtr cam)
 {
 	unsigned char 	  *src = cam->inBuffer;
-	unsigned long int *dst = cam->sqBuffer;
+	unsigned int  *dst = cam->sqBuffer;
 	unsigned long int pixelCount = cam->sqPixels;
 	unsigned long int r,g,b,pixel;
 	int i;
 
+	if (sizeof(*dst) != 4)
+		printf("Invalid buffer element size, expect crash: %i should be %i\n", sizeof(*dst), 4);
+
 	if (0 == dst) return;
 
 	/* Byte0: (g)ggg(b)bbb, Byte1: (r)rrr */
@@ -365,11 +371,14 @@ static void
 convertImageRGB565toARGB32 (camPtr cam)
 {
 	unsigned char 	  *src = cam->inBuffer;
-	unsigned long int *dst = cam->sqBuffer;
+	unsigned int  *dst = cam->sqBuffer;
 	unsigned long int p

Bug#905536: python3.7: disable -O3 on ia64 due to compiler bug

[Jason Duerstock]

Source: python3.7
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Dear Maintainer,

The attached patch includes a number of fixes to python3.7's
debian/rules:
1) Due to a gcc bug[1], -O3 needs to be disabled on ia64.
2) The -O2 override for m68k added for Debian bug #326903 is
no longer needed, and was removed
3) The -mieee and -O2 overrides for DEC Alpha added for Debian
bug #212912 are no longer needed, and were removed

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412

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

Kernel: Linux 4.17.0-1-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- debian/rules.orig   2018-08-05 13:09:54.027342191 -0400
+++ debian/rules2018-08-05 13:12:50.900361875 -0400
@@ -160,14 +160,9 @@
 OPT_CFLAGS   := $(filter-out -O%,$(DPKG_CFLAGS)) # default is -O3
 DEBUG_CFLAGS := $(patsubst -O%,-Og,$(DPKG_CFLAGS))
 
-# on alpha, use -O2 only, use -mieee
-ifeq ($(DEB_HOST_ARCH),alpha)
-OPT_CFLAGS += -mieee
-DEBUG_CFLAGS += -mieee
-EXTRA_OPT_FLAGS += -O2
-endif
-ifeq ($(DEB_HOST_ARCH),m68k)
-EXTRA_OPT_FLAGS += -O2
+# on ia64, disable -O3 until gcc bug #85412 is fixed
+ifeq ($(DEB_HOST_ARCH),ia64)
+EXTRA_OPT_CFLAGS += -O2
 endif
 ifneq (,$(filter $(DEB_HOST_ARCH), ppc64 ppc64el))
 OPT_CFLAGS += -fexceptions

Bug#905467: lintian: Please detect source-only non-free uploads w/o opt-in autobuild

[Guillem Jover]

On Sun, 2018-08-05 at 08:06:00 +, Niels Thykier wrote:
> Chris Lamb:
> > tags 905467 + pending
> > thanks
> > 
> > Implemented in Git, pending upload:
> > 
> >   
> > https://salsa.debian.org/lintian/lintian/commit/514313860d51930c986bbcb3eca6ec4ac7905852

> I seem to recall that "XS-Autobuild: Yes" requires being added to a
> whitelist as well as having the header (A slightly dated reference:
> https://lwn.net/Articles/211820/ - given it is using ".net" and not ".org")

Yes, this is item 3 from the dev-ref link I provided. And I agree it's
probably worth mentioning, or just pointing people to read the dev-ref
for the most up-to-date process.

Thanks,
Guillem

Bug#905535: RFP: node-autod -- Auto generate dependencies and devDependencies by parsing nodejs projects

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-autod
  Version : 3.0.1
  Upstream Author : dead-horse
* URL : notabug.org/themusicgod1/autod
* License : MIT
  Programming Lang: javascript
  Description : Auto generate dependencies and devDependencies by parsing 
nodejs projects

autod will parse all the js files in 'path' and get the latest dependencies 
version from
registry.npmjs.org (or other similar registries).  You can write a plugin for 
autod to decide
how to parse dependencies.

Bug#905522: ghdl: Incomplete debian/copyright?

[Andreas Bombe]

On Sun, Aug 05, 2018 at 03:58:00PM +0100, Chris Lamb wrote:
> Source: ghdl
> Version: 0.35+git20180503+dfsg-1
> Severity: serious
> Justication: Policy 12.5
> X-Debbugs-CC: Andreas Bombe , ftpmas...@debian.org, Thorsten 
> Alteholz 
> 
> Hi,
> 
> I just ACCEPTed ghdl from NEW but the FTP team noticed it was missing the
> entire text of the CC license.

First, thanks for the ACCEPT.

The missing text of the CC license was the reason the package was
rejected months ago. I included the full text in debian/copyright, among
many other changes that came with using a more recent upstream which
changes the library organization. Is there really still something
missing (and what) or is this maybe some outdated ftpmaster notes for
ghdl sticking around?

Bug#905534: metview: FTBFS on hppa - build incorrectly links against libemosR64.a

[John David Anglin]

Source: metview
Version: 5.1.1-1
Severity: normal

Dear Maintainer,

The metview build fails on hppa because it incorrectly links against
libemosR64.a when linking the shared library libMvMars.so.0.0.0:

/usr/bin/c++ -fPIC -g -O2 -fdebug-prefix-map=/<>=. -std=c++11 
-Wdate-time -D_FORTIFY_SOURCE=2 -pipe -std=c++11 -fpermissive 
-Wno-write-strings -Wno-deprecated -O3 -DNDEBUG  -Wl,--disable-new-dtags 
-shared -Wl,-soname,libMvMars.so.0d -o ../../lib/libMvMars.so.0.0.0 
CMakeFiles/MvMars.dir/__/libMarsClient/tcp.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/server.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/request.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/expand.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/hash.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/memory.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/logfile.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/options.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/api.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/apibase.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/base.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/netbase.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/netcdf.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/hdf5.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/nullbase.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/fdb5base.cc.o 
CMakeFiles/MvMars.dir/__/libMarsClient/forwardbase.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/gribbase.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/nfdbbase.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/dhsbase.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/odb.cc.o 
CMakeFiles/MvMars.dir/__/libMarsClient/odbbase.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/multibase.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/archive.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/retrieve.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/ibmblk.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/lock.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/files.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/sh2ll.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/guess.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/hypercube.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/check.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/environ.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/handler.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/target.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/grib.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/calc.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/field.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/list.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/tools.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/hidden.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/index.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/bufr.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/externf.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/service.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/xservice.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/udp.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/queue.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/variable.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/filebase.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/account.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/cos.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/pproc.cc.o 
CMakeFiles/MvMars.dir/__/libMarsClient/pproc_none.cc.o 
CMakeFiles/MvMars.dir/__/libMarsClient/restricted.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/wind.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/control.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/stream.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/remove.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/authenticate.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/flatfilebase.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/time.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/timer.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/json.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/version.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/statistics.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/metadata.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/ecaccess.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/free.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/schedule.c.o 
CMakeFiles/MvMars.dir/__/libMarsClient/pproc_emos.cc.o 
CMakeFiles/MvMars.dir/langy.c.o CMakeFiles/MvMars.dir/rpcmars.c.o 
CMakeFiles/MvMars.dir/mars_client_version.c.o 
-Wl,-rpath,/usr/lib/hppa-linux-gnu/hdf5/serial: 
/usr/lib/hppa-linux-gnu/libemosR64.a -lterralib -lemosR64 
/usr/lib/hppa-linux-gnu/libeccodes_f90.so.0 -lpng -lz -laec -lm -lopenjp2 
-lnetcdf_c++ -lnetcdf /usr/lib/hppa-linux-gnu/hdf5/serial/libhdf5.so -lpthread 
-lsz -ldl /usr/lib/hppa-linux-gnu/libOdb.so.0d -lcurl 
/usr/lib/hppa-linux-gnu/libeccodes.so.0 
/usr/lib/hppa-linux-gnu/libeccodes_memfs.so.0 -lpthread -lfftw3 -lpng -lz -laec 
-lm -lopenjp2 /usr/lib/hppa-linux-gnu/libecml.so.0d -leckit -leckit_cmd 
-lmetkit -lgfortran 
/usr/bin/ld: CMakeFiles/MvMars.dir/__/libMarsClient/files.c.o: in function 
`marstmp':
./debian/build/src/libMars/./src/libMarsClient/files.c:21: warning: the use of 
`tempnam' is dangerous, better use `mkstemp'
/usr/bin/ld: 

Bug#860932: dpkg-shlibdeps should throw an error when generating unsatisfiable dependencies

[Guillem Jover]

Hi!

On Sat, 2017-04-22 at 09:07:01 +0200, Johannes Schauer wrote:
> Package: dpkg
> Version: 1.18.23
> Severity: wishlist

> I recently hacked on a series of packages when I noticed that
> dpkg-shlibdeps emitted the following dependency for my new packaging of
> src:linphone:
> 
> libbellesip0 (>= 1.6.1), libbellesip0 (<< 1.6.0)
> 
> The reason for that was probably that the source package libbellesip0
> came from had debian/libbellesip0.symbols file which enforced the
> "libbellesip0 (<< 1.6.0)" version restriction while at the same time the
> symbols indicated that "libbellesip0 (>= 1.6.1)" was needed. From
> debian/libbellesip0.symbols:
> 
> libbellesip.so.0 libbellesip0 #MINVER#, libbellesip0 (<< 1.6.0)
> [...]
> belle_sip_body_handler_begin_recv_transfer@Base 1.6.1
> belle_sip_body_handler_begin_send_transfer@Base 1.6.1
> [...]
> 
> I think there are several places here that could emit some sort of error
> message. One is when building src:linphone, dpkg-shlibdeps could
> probably check whether the final dependency string it puts into the
> substitution variable is satisfiable at all and emit a warning or throw
> an error if that's not the case.

Hmm, I'm not sure this one is actionable. There's nothing requiring a
package to define dependencies on itself, so while the .symbols will
be present when the shared library package is present, and while we
could check the satisfiability for that one, nothing says all injected
dependencies are going to be present.

> Maybe another thing that could be done would be to warn if a *.symbols
> file is seen with such a dependency restriction as showcased above. But
> I don't know if it's possible to do this reliable or if there are cases
> where this will lead to false positives.

This one seems too specific, and would probably need to check each
individual symbol to see whether it matches only on any such constrain on
the binary package itself, including any Provides from any binary package
generated by the same source, etc.?

My feeling is that this might be too much complexity for something
that is simply a bug, which should be easy to spot at installation
time? I'm happy to consider patches, but I'm not sure I'm going to be
working on this myself. :)

Thanks,
Guillem

Bug#905533: libmtp9: Device 0 (VID=2ae5 and PID=6764) is UNKNOWN in libmtp v1.1.13. Fairphone FP2 LineageOS 14.1

[E.Waelde]

Package: libmtp9
Version: 1.1.13-1
Severity: important
Tags: upstream

Dear Maintainer,

thank you for providing libmtp!

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

   * What led up to the situation?

I'm conncting a Fairphone2(LineageOS 14.1 Android 7.1.2) to my Debian system.

systemlog:
Aug  5 18:01:23 metis kernel: [21617.974947] usb 3-3.4.2: new high-speed USB
device number 9 using ehci-pci
Aug  5 18:01:23 metis kernel: [21618.084742] usb 3-3.4.2: New USB device found,
idVendor=2ae5, idProduct=6764, bcdDevice= 2.32
Aug  5 18:01:23 metis kernel: [21618.084754] usb 3-3.4.2: New USB device
strings: Mfr=1, Product=2, SerialNumber=3
Aug  5 18:01:23 metis kernel: [21618.084760] usb 3-3.4.2: Product: FP2
Aug  5 18:01:23 metis kernel: [21618.084766] usb 3-3.4.2: Manufacturer:
Fairphone
Aug  5 18:01:23 metis kernel: [21618.084772] usb 3-3.4.2: SerialNumber:
6caf40f1
Aug  5 18:01:23 metis mtp-probe: checking bus 3, device 9:
"/sys/devices/pci:00/:00:12.2/usb3/3-3/3-3.4/3-3.4.2"
Aug  5 18:01:23 metis mtp-probe: bus: 3, device: 9 was an MTP device

lsusb
Bus 003 Device 009: ID 2ae5:6764

lsusb -v -d2ae5:6764

Bus 003 Device 009: ID 2ae5:6764
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x2ae5
  idProduct  0x6764
  bcdDevice2.32
  iManufacturer   1 Fairphone
  iProduct2 FP2
  iSerial 3 6caf40f1
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   39
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol  0
  iInterface  4 MTP
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x001c  1x 28 bytes
bInterval   6
Binary Object Store Descriptor:
  bLength 5
  bDescriptorType15
  wTotalLength   22
  bNumDeviceCaps  2
  USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType16
bDevCapabilityType  2
bmAttributes   0x0002
  Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
bLength10
bDescriptorType16
bDevCapabilityType  3
bmAttributes 0x00
wSpeedsSupported   0x000f
  Device can operate at Low Speed (1Mbps)
  Device can operate at Full Speed (12Mbps)
  Device can operate at High Speed (480Mbps)
  Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport   1
  Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat   1 micro seconds
bU2DevExitLat 500 micro seconds
Device Status: 0x
  (Bus Powered)

--> so the device is seen by the system.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

Trying to access files on the the device via mtp fails:

ew@metis:~ 7 > mtp-filetree
Device 0 (VID=2ae5 and PID=6764) is UNKNOWN in libmtp v1.1.13.
Please report this VID/PID and the device model to the libmtp development team
Attempting to connect device(s)
Android device detected, assigning default bug flags
Error 1: Get Storage information failed.
Device: (NULL)
LIBMTP_Get_Storage(): Resource temporarily unavailable
OK.

Same error

Bug#905116: [PATCH v2] scripts/kernel-doc: Escape all literal braces in regexes

[Ben Hutchings]

Commit 720ac2ef479d ("PATCH scripts/kernel-doc") fixed the two
instances of literal braces that Perl 5.28 warns about, but there are
still more than it doesn't warn about.

Escape all left braces that are treated as literal characters.  Also
escape literal right braces, for consistency and to avoid confusing
bracket-matching in text editors.

Signed-off-by: Ben Hutchings 
---
v2: Rebase on top of commit 720ac2ef479d; reword accordingly

 scripts/kernel-doc | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 31a34ced55a3..8f0f508a78e9 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1062,7 +1062,7 @@ sub dump_struct($$) {
 my $x = shift;
 my $file = shift;
 
-if ($x =~ /(struct|union)\s+(\w+)\s*{(.*)}/) {
+if ($x =~ /(struct|union)\s+(\w+)\s*\{(.*)\}/) {
my $decl_type = $1;
$declaration_name = $2;
my $members = $3;
@@ -1148,20 +1148,20 @@ sub dump_struct($$) {
}
}
}
-   $members =~ 
s/(struct|union)([^\{\};]+)\{([^\{\}]*)}([^\{\}\;]*)\;/$newmember/;
+   $members =~ 
s/(struct|union)([^\{\};]+)\{([^\{\}]*)\}([^\{\}\;]*)\;/$newmember/;
}
 
# Ignore other nested elements, like enums
-   $members =~ s/(\{[^\{\}]*})//g;
+   $members =~ s/(\{[^\{\}]*\})//g;
 
create_parameterlist($members, ';', $file, $declaration_name);
check_sections($file, $declaration_name, $decl_type, $sectcheck, 
$struct_actual);
 
# Adjust declaration for better display
-   $declaration =~ s/([{;])/$1\n/g;
-   $declaration =~ s/}\s+;/};/g;
+   $declaration =~ s/([\{;])/$1\n/g;
+   $declaration =~ s/\}\s+;/};/g;
# Better handle inlined enums
-   do {} while ($declaration =~ s/(enum\s+{[^}]+),([^\n])/$1,\n$2/);
+   do {} while ($declaration =~ s/(enum\s+\{[^\}]+),([^\n])/$1,\n$2/);
 
my @def_args = split /\n/, $declaration;
my $level = 1;
@@ -1171,12 +1171,12 @@ sub dump_struct($$) {
$clause =~ s/\s+$//;
$clause =~ s/\s+/ /;
next if (!$clause);
-   $level-- if ($clause =~ m/(})/ && $level > 1);
+   $level-- if ($clause =~ m/(\})/ && $level > 1);
if (!($clause =~ m/^\s*#/)) {
$declaration .= "\t" x $level;
}
$declaration .= "\t" . $clause . "\n";
-   $level++ if ($clause =~ m/(\{)/ && !($clause =~m/}/));
+   $level++ if ($clause =~ m/(\{)/ && !($clause =~m/\}/));
}
output_declaration($declaration_name,
   'struct',
@@ -1244,7 +1244,7 @@ sub dump_enum($$) {
 # strip #define macros inside enums
 $x =~ s@#\s*((define|ifdef)\s+|endif)[^;]*;@@gos;
 
-if ($x =~ /enum\s+(\w+)\s*{(.*)}/) {
+if ($x =~ /enum\s+(\w+)\s*\{(.*)\}/) {
$declaration_name = $1;
my $members = $2;
my %_members;
@@ -1785,7 +1785,7 @@ sub process_proto_type($$) {
 }
 
 while (1) {
-   if ( $x =~ /([^{};]*)([{};])(.*)/ ) {
+   if ( $x =~ /([^\{\};]*)([\{\};])(.*)/ ) {
 if( length $prototype ) {
 $prototype .= " "
 }


signature.asc
Description: Digital signature

Bug#897767: closed by Mo Zhou (Bug#897767: fixed in highwayhash 0~20180209-g14dedec-5)

[Adrian Bunk]

Control: reopen -1

On Mon, Jul 23, 2018 at 01:54:03AM +, Debian Bug Tracking System wrote:
>...
>  highwayhash (0~20180209-g14dedec-5) unstable; urgency=medium
>  .
>* Refresh symbols to avoid FTBFS with GCC-8 (Closes: #897767)
>...

unfortunately this fixed it only for amd64, the package still FTBFS
on arm64/ppc64el/x32:
https://buildd.debian.org/status/package.php?p=highwayhash

cu
Adrian

-- 

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

Bug#903330: glogg: diff for NMU version 1.1.4-1.1

[Adrian Bunk]

Control: tags 903330 + patch
Control: tags 903330 + pending

Dear maintainer,

I've prepared an NMU for glogg (versioned as 1.1.4-1.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

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

diff -Nru glogg-1.1.4/debian/changelog glogg-1.1.4/debian/changelog
--- glogg-1.1.4/debian/changelog	2017-08-11 21:24:53.0 +0300
+++ glogg-1.1.4/debian/changelog	2018-08-05 19:33:01.0 +0300
@@ -1,3 +1,11 @@
+glogg (1.1.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/docs: Adjust for upstream README -> README.md rename.
+(Closes: #903330)
+
+ -- Adrian Bunk   Sun, 05 Aug 2018 19:33:01 +0300
+
 glogg (1.1.4-1) unstable; urgency=medium
 
   * New upstream version 1.1.4 (closes: #853422)
diff -Nru glogg-1.1.4/debian/docs glogg-1.1.4/debian/docs
--- glogg-1.1.4/debian/docs	2017-08-11 21:24:53.0 +0300
+++ glogg-1.1.4/debian/docs	2018-08-05 19:32:55.0 +0300
@@ -1,3 +1,3 @@
-README
+README.md
 TODO
 doc/*.html

Bug#905454: php-common: Update to php-common (1:62) stuck in php.common-post at systemd-tty-ask

[Michael Biebl]

Am 05.08.2018 um 18:14 schrieb Jaap Keuter:

> As a further experiment I've entered the following in a bash shell to see what
> would happen:
> 
> $ systemctl start phpsessionclean.timer
> 
> It pops up a dialog "Authentication Required - PolicyKit1 KDE Agent"
> which says "Authentication is required to start 'phpsessionclean.timer".
> It sits there for 25 seconds, after which it disappears outputting on the 
> shell:
> "Failed to start phpsessionclean.timer: Connection timed out
> See system logs and 'systemctl status phpsessionclean.timer' for details."
> 
> So this is what might be happening on the update as well. As I was doing other
> things at the time, the dialog must have long since disappeared during the 
> update.


"$" indicates, that you were running the above command as unprivileged
user. In that case it is expected that you are prompted for authentication.

dpkg/apt must be run with root privileges, in which case no separate
authentication is required.
"sudo systemctl start phpsessionclean.timer" will/should not trigger a
polkit authentication dialog.

>> Assuming you haven't rebooted the system, please also include the output
>> of "journalctl -alb" and dmesg.

If you have persistent journal enabled, you might still have the logs
from the previous boot.

Now that you've rebooted, does "sudo apt install --reinstall php-common"
trigger this issue again, ie. do you have a way to reproduce it?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#905532: ivulncheck-web: unowned files after purge (policy 6.8, 10.8): /etc/ivulncheck/htpasswd_web

[Andreas Beckmann]

Package: ivulncheck-web
Version: 0.1.65-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/#details-of-removal-and-or-configuration-purging

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

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

1m1.1s ERROR: FAIL: Package purging left files on system:
  /etc/ivulncheck/   owned by: ivulncheck-web
  /etc/ivulncheck/htpasswd_web   not owned
  /var/log/ivulncheck/   not owned


cheers,

Andreas


ivulncheck-web_0.1.65-1.log.gz
Description: application/gzip

Bug#905116: [PATCH] scripts/kernel-doc: Escape all literal braces in regexes

[Ben Hutchings]

Braces are usually metacharacters in regexes, used to specify a
number of repetitions or as part of an escape sequence.  If this
interpretation is not possible then Perl currently treats them
as literal characters.

Perl 5.28 has deprecated the literal interpretation of left braces,
and Perl 5.32 will remove it (resulting in a fatal error).

Escape all left braces that are treated as literal characters.  Also
escape literal right braces, for consistency and to avoid confusing
bracket-matching in text editors.

References: https://bugs.debian.org/905116
Signed-off-by: Ben Hutchings 
---
I tested that the output of "make xmldocs" is identical before and
after this change, whether using Perl 5.26 or 5.28.

Ben.

 scripts/kernel-doc | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 0057d8eafcc1..8f0f508a78e9 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1062,7 +1062,7 @@ sub dump_struct($$) {
 my $x = shift;
 my $file = shift;
 
-if ($x =~ /(struct|union)\s+(\w+)\s*{(.*)}/) {
+if ($x =~ /(struct|union)\s+(\w+)\s*\{(.*)\}/) {
my $decl_type = $1;
$declaration_name = $2;
my $members = $3;
@@ -1148,20 +1148,20 @@ sub dump_struct($$) {
}
}
}
-   $members =~ 
s/(struct|union)([^\{\};]+)\{([^\{\}]*)}([^\{\}\;]*)\;/$newmember/;
+   $members =~ 
s/(struct|union)([^\{\};]+)\{([^\{\}]*)\}([^\{\}\;]*)\;/$newmember/;
}
 
# Ignore other nested elements, like enums
-   $members =~ s/({[^\{\}]*})//g;
+   $members =~ s/(\{[^\{\}]*\})//g;
 
create_parameterlist($members, ';', $file, $declaration_name);
check_sections($file, $declaration_name, $decl_type, $sectcheck, 
$struct_actual);
 
# Adjust declaration for better display
-   $declaration =~ s/([{;])/$1\n/g;
-   $declaration =~ s/}\s+;/};/g;
+   $declaration =~ s/([\{;])/$1\n/g;
+   $declaration =~ s/\}\s+;/};/g;
# Better handle inlined enums
-   do {} while ($declaration =~ s/(enum\s+{[^}]+),([^\n])/$1,\n$2/);
+   do {} while ($declaration =~ s/(enum\s+\{[^\}]+),([^\n])/$1,\n$2/);
 
my @def_args = split /\n/, $declaration;
my $level = 1;
@@ -1171,12 +1171,12 @@ sub dump_struct($$) {
$clause =~ s/\s+$//;
$clause =~ s/\s+/ /;
next if (!$clause);
-   $level-- if ($clause =~ m/(})/ && $level > 1);
+   $level-- if ($clause =~ m/(\})/ && $level > 1);
if (!($clause =~ m/^\s*#/)) {
$declaration .= "\t" x $level;
}
$declaration .= "\t" . $clause . "\n";
-   $level++ if ($clause =~ m/({)/ && !($clause =~m/}/));
+   $level++ if ($clause =~ m/(\{)/ && !($clause =~m/\}/));
}
output_declaration($declaration_name,
   'struct',
@@ -1244,7 +1244,7 @@ sub dump_enum($$) {
 # strip #define macros inside enums
 $x =~ s@#\s*((define|ifdef)\s+|endif)[^;]*;@@gos;
 
-if ($x =~ /enum\s+(\w+)\s*{(.*)}/) {
+if ($x =~ /enum\s+(\w+)\s*\{(.*)\}/) {
$declaration_name = $1;
my $members = $2;
my %_members;
@@ -1785,7 +1785,7 @@ sub process_proto_type($$) {
 }
 
 while (1) {
-   if ( $x =~ /([^{};]*)([{};])(.*)/ ) {
+   if ( $x =~ /([^\{\};]*)([\{\};])(.*)/ ) {
 if( length $prototype ) {
 $prototype .= " "
 }


signature.asc
Description: Digital signature

Bug#905454: php-common: Update to php-common (1:62) stuck in php.common-post at systemd-tty-ask

[Jaap Keuter]

On 05-08-18 09:29, Michael Biebl wrote:
> Am 05.08.2018 um 09:12 schrieb Michael Biebl:
> 
>> hm, update-debian.s /home/jaap/bin/update-debian.sh
>> /home/jaap/bin/update-debian.sh...
>> How exactly do you trigger the update?
>> Is system fully booted at this point?
>> Can you provide us with steps how to reproduce the issue?

Sure, the process tree shows what's going on. let me elaborate.

konsole -session 10dd616e7500015331903250014310008_1533191244_922307
Booted into a KDE plasma session, which gives me konsole.

  |   |   |-bash
Konsole runs bash as the shell.

  |   |   |   `-update-debian.s /home/jaap/bin/update-debian.sh
In the shell I manually run a script
(https://gitlab.com/JaapKeuter/update-debian) that supports me in updating 
Debian.

  |   |   |   `-sudo aptitude
The script runs sudo aptitude to do the updates. I have typed in my password for
sudo.

  |   |   |   `-aptitude
It runs aptitude to do the work.

  |   |   |   |-dpkg --status-fd 96 --configure --pending
It runs dpkg to work with the package.

  |   |   |   |   `-php-common.post
/var/lib/dpkg/info/php-common.postinst configure 1:61
It runs the package script to finish up the update of the package.

  |   |   |   |   `-systemctl start phpsessionclean.timer
It runs systemctl to start a systemd timer.

  |   |   |   |   `-systemd-tty-ask --watch

It runs systemd-tty-ask-password-agent to ask for permission.


As a further experiment I've entered the following in a bash shell to see what
would happen:

$ systemctl start phpsessionclean.timer

It pops up a dialog "Authentication Required - PolicyKit1 KDE Agent"
which says "Authentication is required to start 'phpsessionclean.timer".
It sits there for 25 seconds, after which it disappears outputting on the shell:
"Failed to start phpsessionclean.timer: Connection timed out
See system logs and 'systemctl status phpsessionclean.timer' for details."

So this is what might be happening on the update as well. As I was doing other
things at the time, the dialog must have long since disappeared during the 
update.

> 
> Please also attach the output of "reportbug --template systemd" to this
> bug report,

Done, see reportbug-systemd-backup-20180805-3946-zyzamfhh.gz


> Assuming you haven't rebooted the system, please also include the output
> of "journalctl -alb" and dmesg.
> 

The system is normally switched off, so that info isn't available anymore.




reportbug-systemd-backup-20180805-3946-zyzamfhh.gz
Description: application/gzip

Bug#905514: Reproduced in Gitlab CI

[Inaki Malerba]

Dear maintainer, you can find the bug reproduced on the following
pipeline [1], adding our generic CI script [2].

1_ https://salsa.debian.org/ina-guest/cryptsetup/-/jobs/36815

2_ https://salsa.debian.org/salsa-ci-team/pipeline/


Saludos

-- 
- ina




signature.asc
Description: OpenPGP digital signature

Bug#905531: snmpd: Stupid error during dist-upgrade

[Niels Thykier]

Control: tags -1 moreinfo

On Sun, 05 Aug 2018 15:25:25 + "teo8...@gmail.com"
 wrote:
> Package: snmpd
> Version: 5.7.2.1+dfsg-1+deb8u1+b1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> I ran apt dist-upgrade
> 
>* What was the outcome of this action?
>
> It ended with an error related to snmpd. These are the last lines of output:
> 
> Replacing config file /etc/perl/XML/SAX/ParserDetails.ini with new version
> Processing triggers for libc-bin (2.19-18+deb8u10) ...
> Processing triggers for systemd (215-17+deb8u7) ...
> Processing triggers for libapache2-mod-php5 (5.6.36+dfsg-0+deb8u1) ...
> Processing triggers for libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u7) ...
> Processing triggers for dictionaries-common (1.23.17) ...
> Errors were encountered while processing:
>  snmpd
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> 
> And there's no indication of what to do to fix it. It doesn't even tell me if 
> snmpd will be working or not.
> 
> 
> * What outcome did you expect instead?
> 
> The error shouldn't exist in the first place, but if something went wrong, 
> you must tell me WHAT THE FUCK it is that went wrong and what I am supposed 
> to d
> o.
> 
> 
>[...]


Hi,

What you see there is presumably the summary information at the end of
the upgrade and not the actual error.  If you still have the upgrade
log, then please attach it to the bug.  Otherwise, you may be able to
retrigger the problem by running (as root):

   dpkg --configure -a

Thanks,
~Niels

Bug#886448: [Piuparts-devel] correctly pass --extra-package debs to piuparts

[Johannes Schauer]

Hi Andreas,

Quoting Andreas Beckmann (2018-08-05 16:08:31)
> > I would've expected that piuparts would support the latter. It would be more
> > convenient to the user if piuparts would take care of creating the repo than
> > the user having to do it themselves. That's also how sbuild and autopkgtest 
> > do
> > it when the user gives them extra debs. Neither of those two requires the 
> > user
> > to do the repo setup themselves.
> 
> copying all the debs is a waste, especially if you want to test a lot of
> packages all needing the same tree. (I assume you will test each package
> binary individually ..., and you will test install and upgrade scenarios)
> Doing just
>   (cd /path/to/repo && dpkg-scanpackages . > Packages)
> is cheap, and should be easily scriptable.
> (piuparts won't do it, because it will not modify arbitrary directory
> trees given as input to it)

indeed, piuparts should never change the contents of such a directory that it
is given on the command line.

But I still don't see how it's a waste. It's the same that sbuild, pbuilder and
autopkgtest do. At the beginning they copy the extra .debs that they are given
into a temporary location inside the chroot (or a location accessible by the
chroot), create the apt archive and then use it for the rest of the processing.
All this is only done *once* at the beginning of an sbuild, pbuilder or
autopkgtest invocation. Why can piuparts not do the same?

> 
> >> All you need to provide is a local directory with all the .debs and a
> >> Packages file in there. Does not need to be signed or have a Release file 
> >> or
> >> anything fancy.
> > 
> > Oh? Does that mean that apt can now use a plain directory without a Release
> > file using a line like:
> > 
> > deb file:///directory/inside/schroot/ ./
> > 
> > I thought a Release file was required by apt? If I require using the above I
> > get the following when doing $(apt update):
> > 
> > E: The repository 'file:/home/josch/repository ./ Release' does not have a 
> > Release file.
> > 
> > So how does apt not require a Release file?
> Use with it with [trusted=yes]

Thanks!

> as does piuparts if you just give a plain path:
> 
> piuparts ... --bindmount /tmp/my-repo --extra-repo /tmp/my-repo

It is not documented in the man page, that piuparts also accepts a directory.
It says there, that it expects a string for apt's sources.list.

> How do you call piuparts anyway?

Like this:

sudo -- piuparts --schroot unstable-amd64-sbuild pkg_ver_arch.changes

> If this should be fixed in piuparts, then probably by adding some driver
> script that takes e.g. a bunch of .changes files as parameter, builds a repo
> of all the .debs and runs piuparts on each binary package, possibly multiple
> times.

Why does it need multiple .changes files for this? I don't have a .changes file
for the .deb I want to pass.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#905531: snmpd: Stupid error during dist-upgrade

[teo8...@gmail.com]

Package: snmpd
Version: 5.7.2.1+dfsg-1+deb8u1+b1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

I ran apt dist-upgrade

   * What was the outcome of this action?
   
It ended with an error related to snmpd. These are the last lines of output:

Replacing config file /etc/perl/XML/SAX/ParserDetails.ini with new version
Processing triggers for libc-bin (2.19-18+deb8u10) ...
Processing triggers for systemd (215-17+deb8u7) ...
Processing triggers for libapache2-mod-php5 (5.6.36+dfsg-0+deb8u1) ...
Processing triggers for libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u7) ...
Processing triggers for dictionaries-common (1.23.17) ...
Errors were encountered while processing:
 snmpd
E: Sub-process /usr/bin/dpkg returned an error code (1)


And there's no indication of what to do to fix it. It doesn't even tell me if 
snmpd will be working or not.


* What outcome did you expect instead?

The error shouldn't exist in the first place, but if something went wrong, you 
must tell me WHAT THE FUCK it is that went wrong and what I am supposed to d
o.


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


-- System Information:
Debian Release: 8.11
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages snmpd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  libc6  2.19-18+deb8u10
ii  libsnmp-base   5.7.2.1+dfsg-1+deb8u1
ii  libsnmp30  5.7.2.1+dfsg-1+deb8u1+b1
ii  lsb-base   4.1+Debian13+nmu1

snmpd recommends no packages.

Versions of packages snmpd suggests:
pn  snmptrapd  

-- Configuration Files:
/etc/snmp/snmptrapd.conf a2ee110581a5a9a1e2252400cb176bcc [Errno 2] No such 
file or directory: u'/etc/snmp/snmptrapd.conf a2ee110581a5a9a1e2252400cb176bcc'

-- debconf information:
  snmpd/upgradefrom521:

Bug#905529: debianutils: [INTL:de] updated German man page translation

[Helge Kreutzmann]

Package: debianutils
Version: 4.8.6
Severity: wishlist
Tags: patch l10n

Please find the updated German man page translation for debianutils
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of debianutils man page template to German
# Copyright (C) Helge Kreutzmann , 2011, 2012, 2017, 2018.
# This file is distributed under the same license as the debianutils package.
#
msgid ""
msgstr ""
"Project-Id-Version: debianutils man page 4.8.6\n"
"POT-Creation-Date: 2018-05-15 07:57-0400\n"
"PO-Revision-Date: 2018-08-05 17:41+0200\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: de \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: utf-8\n"

#. type: TH
#: ../add-shell.8:1
#, no-wrap
msgid "ADD-SHELL"
msgstr "ADD-SHELL"

#. type: TH
#: ../add-shell.8:1
#, no-wrap
msgid "12 May 2011"
msgstr "12. Mai 2011"

#. type: SH
#: ../add-shell.8:2 ../installkernel.8:2 ../ischroot.1:3 ../remove-shell.8:2
#: ../run-parts.8:9 ../savelog.8:3 ../tempfile.1:3 ../which.1:3
#, no-wrap
msgid "NAME"
msgstr "NAME"

#. type: Plain text
#: ../add-shell.8:4
msgid "add-shell - add shells to the list of valid login shells"
msgstr "add-shell - Shells zu der Liste der gültigen Anmelde-Shells hinzufügen"

#. type: SH
#: ../add-shell.8:4 ../installkernel.8:4 ../ischroot.1:5 ../remove-shell.8:4
#: ../run-parts.8:11 ../savelog.8:5 ../tempfile.1:5 ../which.1:5
#, no-wrap
msgid "SYNOPSIS"
msgstr "ÜBERSICHT"

#. type: Plain text
#: ../add-shell.8:8
msgid "B I [I...]"
msgstr "B I [I…]"

#. type: SH
#: ../add-shell.8:8 ../installkernel.8:6 ../ischroot.1:8 ../remove-shell.8:8
#: ../run-parts.8:20 ../savelog.8:9 ../tempfile.1:9 ../which.1:7
#, no-wrap
msgid "DESCRIPTION"
msgstr "BESCHREIBUNG"

#. type: Plain text
#: ../add-shell.8:13
msgid ""
"B copies I to I, adds the given "
"shells to this file if they are not already present, and copies this "
"temporary file back to I."
msgstr ""
"B kopiert I nach I, fügt die "
"angegebenen Shells zu dieser Datei hinzu falls sie dort noch nicht enthalten "
"sind und kopiert die temporäre Datei wieder zu I zurück."

#. type: Plain text
#: ../add-shell.8:15
msgid "The shells must be provided by their full pathnames."
msgstr "Die Shells müssen mit ihrem vollen Pfadnamen angegeben werden."

#. type: SH
#: ../add-shell.8:15 ../remove-shell.8:13 ../savelog.8:159 ../tempfile.1:86
#, no-wrap
msgid "SEE ALSO"
msgstr "SIEHE AUCH"

#. type: Plain text
#: ../add-shell.8:16 ../remove-shell.8:14
msgid "B(5)"
msgstr "B(5)"

#. type: TH
#: ../installkernel.8:1
#, no-wrap
msgid "INSTALLKERNEL"
msgstr "INSTALLKERNEL"

#. type: TH
#: ../installkernel.8:1
#, no-wrap
msgid "7 Jan 2001"
msgstr "7. Jan. 2001"

#. type: TH
#: ../installkernel.8:1
#, no-wrap
msgid "Debian Linux"
msgstr "Debian Linux"

#. type: Plain text
#: ../installkernel.8:4
msgid "installkernel - install a new kernel image"
msgstr "installkernel - installiert ein neues Kernel-Image"

#. type: Plain text
#: ../installkernel.8:6
msgid "BI"
msgstr "BI"

#. type: Plain text
#: ../installkernel.8:13
msgid ""
"B installs a new kernel image onto the system from the Linux "
"source tree.  It is called by the Linux kernel makefiles when B is invoked there."
msgstr ""
"B installiert ein neues Kernel-Image auf das System aus dem "
"Linux-Quellbaum. Es wird von den Linux-Kernel-Makefiles aufgerufen, wenn "
"dort B ausgeführt wird."

#. type: Plain text
#: ../installkernel.8:22
msgid ""
"The new kernel is installed into I<{directory}/vmlinuz-{version}>.  If a "
"symbolic link I<{directory}/vmlinuz> already exists, it is refreshed by "
"making a link from I<{directory}/vmlinuz> to the new kernel, and the "
"previously installed kernel is available as I<{directory}/vmlinuz.old>."
msgstr ""
"Der neue Kernel wird in I<{Verzeichnis}/vmlinuz-{Version}> installiert. "
"Falls bereits ein symbolischer Link I<{Verzeichnis}/vmlinuz> existiert, wird "
"er erneuert, indem ein Link von I<{Verzeichnis}/vmlinuz> auf den neuen "
"Kernel gelegt wird. Der vorher installierte Kernel ist unter I<{Verzeichnis}/"
"vmlinuz.old> verfügbar."

#. type: SH
#: ../installkernel.8:22 ../ischroot.1:35 ../savelog.8:152 ../tempfile.1:69
#, no-wrap
msgid "BUGS"
msgstr "FEHLER"

#. type: Plain text
#: ../installkernel.8:25
msgid ""
"installkernel resides in /sbin only because the Linux kernel makefiles call "
"it from there.  It should really be in /usr/sbin.  It isn't needed to boot a "
"system."
msgstr ""
"installkernel liegt nur in /sbin, da die Makefiles des Linux-Kernels es von "
"dort aufrufen. Es sollte sich wirklich in /usr/sbin befinden. Es wird nicht "
"benötigt, um ein System zu starten."

#. type: TH
#: ../ischroot.1:2
#, no-wrap
msgid "ISCHROOT"
msgstr "ISCHROOT"

#. type: TH
#: ../ischroot.1:2
#, no-wrap
msgid "30 May 2011"

Bug#905530: /usr/bin/apt-key: apt-key features are unusable without dirmngr

[Kurtis O'Donnell]

Package: apt
Version: 1.4.8
Severity: normal
File: /usr/bin/apt-key


When I installed Debian (using the network installer), I wanted to get 
better icons but when I needed to use 'apt-key' to get the key
it would give an error stating that /usr/bin/dirmngr was missing. 

I knew how to get it, but it should have either came pre-installed or
have the command output that it needs dirmngr for a feature. 



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

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

Versions of packages apt depends on:
ii  adduser 3.115
ii  debian-archive-keyring  2017.5
ii  gpgv2.1.18-8~deb9u2
ii  init-system-helpers 1.48
ii  libapt-pkg5.0   1.4.8
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libstdc++6  6.3.0-18+deb9u1

Versions of packages apt recommends:
ii  gnupg  2.1.18-8~deb9u2

Versions of packages apt suggests:
pn  apt-doc 
ii  dpkg-dev1.18.25
ii  powermgmt-base  1.31+nmu1
pn  python-apt  
ii  synaptic0.84.2

-- no debconf information

Bug#905528: mount: nofail

[Seamus de Mora]

Package: mount
Version: 2.29.2-1+deb9u1
Severity: normal

Dear Maintainer,

I have modified the file at `/etc/fstab` to add instructions to `mount` for
mounting a "USB thumb drive" (LABEL=SANDISK16GB); please see the file
contents below. Note the use of the `nofail` option. When I omit this
option, and that USB thumb drive is not plugged in, my system will no
longer complete the boot process. This behavior is contrary to the
documentation in `man mount`, and `man fstab`. I am unable to tell if this
is an error in the documentation, or in the code, but judging from various
postings online (stackexchange sites, etc), this error may not be
consistent across all platforms and versions.

The documentation describes the `nofail` option as follows: "Do not report
errors for this device if it does not exist." "Do not report errors" is
quite a different thing than "Halt the boot process". Furthermore, the
consequences can be severe for a certain class of users if this option is
not specified, and a reboot is attempted without the device.

$ cat /etc/fstab

proc/proc   procdefaults  0   0

PARTUUID=bb8517b1-01  /boot   vfatdefaults  0   2

PARTUUID=bb8517b1-02  /   ext4defaults,noatime  0   1

# a swapfile is not a swap partition, no line here

#   use  dphys-swapfile swap[on|off]  for that

LABEL=SANDISK16GB /home/pi/mntThumbDrv exfat rw,user,nofail 0 0

# LABEL=SANDISK16GB /home/pi/mntThumbDrv exfat rw,user 0 0


-- System Information:
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.4 (stretch)
Release: 9.4
Codename: stretch
Architecture: armv7l

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

Versions of packages mount depends on:
ii  libblkid1  2.29.2-1+deb9u1
ii  libc6  2.24-11+deb9u3
ii  libmount1  2.29.2-1+deb9u1
ii  libselinux12.6-3
ii  libsmartcols1  2.29.2-1+deb9u1
ii  libudev1   232-25+deb9u4

mount recommends no packages.

Versions of packages mount suggests:
ii  nfs-common  1:1.3.4-2.1

-- no debconf information

Bug#905305: emacs-common: terrible mess

[Rob Browning]

Cristian Ionescu-Idbohrn  writes:

> I can see that some of those packages are no longer available from the
> archive:
>
>   css-mode elib elserv html-helper-mode remember-el x-pgp-sig-el
>
> Still, they don't seem to be the ones failing 'init', AFAICT.
>
> I guess emacs-common is not the root of the problem here, but I have
> a hard time figuring out what is.  Please feel free reassigning.
>
> Still wondering.  Is there anything _I_ can do to clean up the mess?

Sorry you're having trouble.  The unversioning (emacs25-lucid ->
emacs-lucid, etc.) is one of the most substantial changes we've ever
made to the emacs infrastructure, and as a result, unstable's likely to
be much more unstable than usual with respect to emacs and the add-on
packages, but we hope things will settle down soon.

In addition to the emacs package changes, many of the add-on packages
have needed adjustment, and in concert, they're also being moved to the
dh-elpa infrastructure by the emacsen-team
(https://salsa.debian.org/emacsen-team #debian-emacs, etc.).

If you haven't already, it might well be that, upgrading to the newer
(unstable) elpa-foo versions of some of your add-on packages will help
alleviate your problems.

If you can tell what's going wrong, please consider filing bugs against
the relevant add-on packages, or contacting #debian-emacsen or
debian-emac...@lists.debian.org.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#905527: `apt show` fails to parse record for librust-winapi-dev (while `apt-cache show` succeeds)

[Antonio Terceiro]

Package: apt
Version: 1.6.3
Severity: normal

~$ apt-cache show librust-winapi-dev
[... stuff ...]
~$ apt show librust-winapi-dev
E: Unable to parse package file 
/var/lib/apt/lists/ftp.br.debian.org_debian_dists_unstable_main_binary-amd64_Packages
 (2)
E: Internal Error, Unable to parse a package record

librust-winapi-dev as a massing Provides: field, which could be causing this.

I just reproduced this on a clean sid container with nothing but a
standard sources.list, so I am not attaching a copy of the Packages
file. I have saved a copy locally, however, and can provide one if you
want.


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

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

Versions of packages apt depends on:
ii  adduser 3.117
ii  debian-archive-keyring  2017.7
ii  gpgv2.2.9-1
ii  libapt-pkg5.0   1.6.3
ii  libc6   2.27-5
ii  libgcc1 1:8.2.0-3
ii  libgnutls30 3.5.19-1
ii  libseccomp2 2.3.3-3
ii  libstdc++6  8.2.0-3

Versions of packages apt recommends:
ii  ca-certificates  20180409

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.19.0.5
ii  gnupg2.2.9-1
ii  powermgmt-base   1.33

-- no debconf information


signature.asc
Description: PGP signature

Bug#905520: lvm2: Ensure COW device is writable even for read-only thick snapshots

[Ben Hutchings]

Control: found -1 2.02.168-2

Please fix this in a stable update as well as in unstable.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that
there are so many of them.



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