Bug#800845: autopkgtest: Add support for nested VMs

[Martin Pitt]

Hey Christian,

sorry for the delay, the flu struck :(

Christian Seiler [2016-03-07 11:28 +0100]:
> I've attached a patch that updates the man page a bit to make
> the current semantics you are using clearer.

Thanks! I massaged this a bit further -- this is only really relevant
if a test calls adt-reboot-prepare.

> I get (w/ qemu-system 1:2.5+dfsg-4~bpo8+1) with current git master
> (no changes):
> mount: /dev/vdb1 is write-protected, mounting read-only
> 
> So I can't really reproduce it. :-(

I now get the same. I must have wrecked something on Monday, I figure.

So, I think we can finally put this bug to a rest :-)

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#817232: postinst trying to disable /etc/init.d/keyboard-setup

[Mateusz Łukasik]

Package: keyboard-configuration
Version: 1.137
Severity: grave

Dear Maintainer,

after D-U in stretch I have:

The following packages will be upgraded:
  keyboard-configuration
1 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
1 not fully installed or removed.
Need to get 0 B/747 kB of archives.
After this operation, 33.8 kB disk space will be freed.
Preconfiguring packages ...
Setting up libfdisk1:amd64 (2.27.1-4) ...
Processing triggers for libc-bin (2.21-9) ...
(Reading database ... 158941 files and directories currently installed.)
Preparing to unpack .../keyboard-configuration_1.138_all.deb ...
update-rc.d: warning /etc/init.d/keyboard-setup still exist. Terminating
dpkg: error processing archive /var/cache/apt/archives/keyboard-
configuration_1.138_all.deb (--unpack):
 subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/keyboard-configuration_1.138_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


System is running with file-rc as init.



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

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.58
ii  initscripts 2.88dsf-59.3
ii  liblocale-gettext-perl  1.07-1+b1

keyboard-configuration recommends no packages.

keyboard-configuration suggests no packages.

Versions of packages keyboard-configuration is related to:
ii  console-common0.7.89
ii  console-data  2:1.12-5
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.0.3-2

-- debconf information:
  keyboard-configuration/layoutcode: pl
* keyboard-configuration/variant: Polish
  keyboard-configuration/compose: No compose key
  keyboard-configuration/unsupported_options: true
  debian-installer/console-setup-udeb/title:
  keyboard-configuration/xkb-keymap: pl
  keyboard-configuration/toggle: No toggling
  keyboard-configuration/model: A4Tech KB-21
  keyboard-configuration/store_defaults_in_debconf_db: false
  keyboard-configuration/altgr: The default for the keyboard layout
  keyboard-configuration/variantcode:
  keyboard-configuration/optionscode:
  keyboard-configuration/unsupported_config_layout: true
  keyboard-configuration/unsupported_config_options: true
  keyboard-configuration/layout:
  keyboard-configuration/ctrl_alt_bksp: false
  keyboard-configuration/unsupported_layout: true
  keyboard-configuration/other:
  keyboard-configuration/switch: No temporary switch
  keyboard-configuration/modelcode: a4techKB21

Bug#817233: CVE-2016-1968

[Moritz Muehlenhoff]

Source: brotli
Severity: grave
Tags: security

Firefox fixed a buffer overflow in brotli:
https://www.mozilla.org/en-US/security/advisories/mfsa2016-30/

Please get in touch with upstream whether this also needs to be fixed
in the brotli source package in Debian.

Cheers,
Moritz

Bug#719624: Upgrading xrdp

[Andreas Tille]

On Tue, Mar 08, 2016 at 11:21:32PM +0100, Dominik George wrote:
> In that case, please let us finalise the work ;). I expect it to be done 
> until 
> middle of the week.

Sounds good.  My favourite way to do this would be to clone

   https://anonscm.debian.org/git/collab-maint/xrdp.git

to the new location

   https://anonscm.debian.org/git/debian-edu/pkg-team/xrdp.git

and insert the changes for 0.9.0~git20150902-1 there.  If you want help
from my side please make sure to commit pristine-tar to ensure that we
are working on the same code base.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#817231: rabbitvcs: All files in home folder removed

[Bastian Pranzas]

Source: rabbitvcs
Severity: critical
Justification: causes serious data loss

Dear Maintainer,

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

   * What led up to the situation?
I just wanted a quick and easy way to access my work svn from my home computer, 
so I googled and found rabbitvcs. I am running debian jessie and saw that it is 
in the repo, so I just installed it.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I just used it a few minutes:
- I conntected to my work svn using "browse repository" or similar, which 
worked nicely
- I went to a certain directory in the repo and tried to just copy a file out 
using drag into nautilus, which did nothing
- Next thing I tried was the "export" function, so I tried that and it told me 
something like "authentication failed"
- Then I tried to check out the folder containing the file, which gave the same 
problem
(I did all steps above from the repository browser)
- Note that at no point in time did the program ask me if I want to delete or 
overwrite anything. I might have used the program wrongly, but I assumed that 
because it is "easy to use" like tortoisesvn, that I don't have to read the 
documentation to prevent data loss.

   * What was the outcome of this action?
- Then I went back to nautilus and noticed that it won't show my user folders 
anymore, my desktop wallpaper was gone, etc
- I checked if there is anything mounted over my home folder, which wasn't the 
case

   * What outcome did you expect instead?
I expected the file/folder to appear where I tried to export/check them out.

I found this using google:
http://askubuntu.com/questions/473433/rabbitsvn-deleted-all-my-folders
which is basically the same story as mine.

On the rabbitvcs homepage in the "known issues" section, in the project bug 
tracker and the user mailing list of the project I found no mention of it. I 
wanted to report it to the mailing list, but it appears I can't get the right 
to post.

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

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

Bug#749833: scilab: Scilab include non-free codes

[Clément David]

Hi Maximiliano, Sylvestre,

Le lundi 29 février 2016 à 10:24 +0100, Sylvestre Ledru a écrit :
> Le 29/02/2016 à 09:54, Maximiliano Curia a écrit :
> > 
> > Control: block 816260 by 749833
> > 
> > Hi,
> > 
> > As a request from the release team I have removed the dependency of scilab 
> > from cantor, I'm adding this block to the corresponding bug in cantor as 
> > way 
> > to remember to reenable the backend once the problem is fixed.
> > 
> > Also, since there is a patch available upstream that's being stale for 
> > review 
> > for sometime now, wouldn't it be feasible to upload a patched scilab to 
> > experimental as a way to gather some testers/reviewers?
> > 
> > Happy hacking,
> Clément, François, could you help here?
> Thanks
> 
> Sylvestre

The current patch on the codereview is incomplete and will not provide a decent 
implementation for
now. You can provide a patched version for the 5.x family to iterate on the 
current patch
implementation. We will be happy to help you rebasing / validating it !

To conforms to the open-source licence, the problematic files will be removed 
before the 6.0.0
release. And the functionality will be present by either using a scilab 
implementation (eg. based on
the patchset) or RpolyPlusPlus [1] .

[1]: https://github.com/sweeneychris/RpolyPlusPlus

--
Clément

Bug#817214: mirror submission for mirror.amaze.com.au

[Donald Norwood]

Control: tags -1 moreinfo

Hi,

On Wed, 09 Mar 2016 05:06:29 + "Kris Shannon" 
wrote:

> Submission-Type: new
> Site: mirror.amaze.com.au
> Type: leaf
> Archive-architecture: amd64 i386 
> Archive-http: /debian/
> IPv6: no
> Archive-upstream: debian.uberglobalmirror.com
> Updates: four
> Maintainer: Kris Shannon 
> Country: AU Australia
> Location: Sydney
> Sponsor: Amaze Communication http://www.amaze.com.au/
> 
> 

http://mirror.amaze.com.au/ points to a series of open directories:
etc/apt/ which end at sources.list.

Please recheck your configuration.

Instructions for setting up a Debian mirror:
https://www.debian.org/mirror/ftpmirror

Best regards,

Donald Norwood
-Debian Mirrors Team



signature.asc
Description: OpenPGP digital signature

Bug#812804: blueman: File transfer does not work through tray icon menu

[Christopher Schramm]

Hi Ralf,

could you try and see if
https://github.com/blueman-project/blueman/commit/f7c0f6af1d7623775587abc1f439d96f3bc53c95
helps with your issue?

If you need assistance to apply it, just get in touch with me (off list).

Regards

Bug#817229: Please move soundfont to /usr/share/sounds/sf2

[Dmitry Eremin-Solenikov]

Package: freewheeling
Version: 0.6-2+b2
Severity: wishlist

On Debian systems soundfounts are usually placed in the
/usr/share/sounds/sf2 directory. Could you please move the soundfont
from your package to that dir?

--
With best wishes
Dmitry



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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages freewheeling depends on:
ii  fonts-dejavu  2.35-1
ii  fonts-dustin  20030517-10
ii  jackd 5
ii  libasound21.1.0-1
ii  libc6 2.21-9
ii  libfluidsynth11.1.6-3
ii  libfreetype6  2.6.1-0.1
ii  libgcc1   1:5.3.1-8
ii  libgnutls-openssl27   3.4.9-2
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20150825git1ed50c92~dfsg-1
ii  libogg0   1.3.2-1
ii  libsdl-gfx1.2-5   2.0.25-5
ii  libsdl-ttf2.0-0   2.0.11-3
ii  libsdl1.2debian   1.2.15+dfsg1-2
ii  libsndfile1   1.0.25-10
ii  libstdc++65.3.1-8
ii  libvorbis0a   1.3.5-3
ii  libvorbisenc2 1.3.5-3
ii  libvorbisfile31.3.5-3
ii  libx11-6  2:1.6.3-1
ii  libxml2   2.9.3+dfsg1-1

freewheeling recommends no packages.

freewheeling suggests no packages.

-- no debconf information

Bug#817228: Please move soundfont to /usr/share/sounds/sf2

[Dmitry Eremin-Solenikov]

Package: denemo-data
Version: 2.0.2-1
Severity: wishlist

On Debian systems soundfounts are usually placed in the
/usr/share/sounds/sf2 directory. Could you please move the soundfont
from your package to that dir?

--
With best wishes
Dmitry


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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#817230: Please move soundfont to /usr/share/sounds/sf2

[Dmitry Eremin-Solenikov]

Package: laborejo
Version: 0.8~ds0-1
Severity: wishlist

On Debian systems soundfounts are usually placed in the
/usr/share/sounds/sf2 directory. Could you please move the soundfont
from your package to that dir?

--
With best wishes
Dmitry



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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages laborejo depends on:
ii  fonts-freefont-ttf  20120503-4
ii  fonts-oflb-euterpe  1.1-5
ii  python3 3.5.1-1
ii  python3-pyqt4   4.11.4+dfsg-1+b2

Versions of packages laborejo recommends:
ii  jackd 5
ii  lilypond  2.18.2-4.1

laborejo suggests no packages.

-- no debconf information

Bug#795864: Submitted upstream

[Neil Muller]

This is being tracked upstream as https://gitlab.com/esr/irker/issues/6

-- 
Neil Muller
drnlmul...@gmail.com

I've got a gmail account. Why haven't I become cool?

Bug#817227: hardcoding package.path into binary makes luarocks non-lua-version-agnostic

[quae]

Package: luarocks

Filed upstream as https://github.com/keplerproject/luarocks/issues/511

On debian, /usr/bin/luarocks contains:
```lua
package.path = [[/usr/share/lua/5.1/?.lua;]]..package.path
```

Which is a show-stopper for having one luarocks installation handle
all lua versions, as this means that running `lua5.3 /usr/bin/luarocks
path --bin` results in a path of:
```
export 
LUA_PATH_5_3='/home/daurnimator/.luarocks/share/lua/5.3/?.lua;/home/daurnimator/.luarocks/share/lua/5.3/?/init.lua;/usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.3/?/init.lua;/usr/share/lua/5.1/?.lua;/usr/local/lib/lua/5.3/?.lua;/usr/local/lib/lua/5.3/?/init.lua;/usr/share/lua/5.3/?.lua;/usr/share/lua/5.3/?/init.lua;./?.lua;./?/init.lua'
```

---

This line doesn't seem to exist in other some distros (e.g. arch linux).

A possible solution is simply *not* running `make build`.

Bug#749650: Submitted upstream

[Neil Muller]

This being tracked upstream at https://gitlab.com/esr/irker/issues/5

Bug#817226: RFS: golang-gopkg-hlandau-svcutils.v1/1.0.7 -- utilities for writing services in Go

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "golang-gopkg-hlandau-svcutils.v1":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-hlandau-svcutils.v1.git

  cd golang-gopkg-hlandau-svcutils.v1 && pristine-tar checkout 
../golang-gopkg-hlandau-svcutils.v1_1.0.7.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  0bd087544eb33b52e91f3fbb7df21a97c9bc2be5 refs/heads/master
  71cef7df9677be1d694b584d1d68308610a1c413 refs/heads/pristine-tar
  5fafee7ff5bf3ccc3c7492a45f5b5759561ec86e refs/heads/upstream

It builds these binary packages:

  golang-gopkg-hlandau-svcutils.v1-dev -- utilities for writing services in Go

This package is a prerequisite for building acmetool [1], an automatic
certificate acquisition tool for Let's Encrypt [2].

[1] https://bugs.debian.org/817091
[2] https://letsencrypt.org/about/

More information about golang-gopkg-hlandau-svcutils.v1 can be obtained from

https://github.com/hlandau/svcutils

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817225: RFS: golang-gopkg-hlandau-configurable.v1/1.0.1 -- Go package for managing program configuration

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package 
"golang-gopkg-hlandau-configurable.v1":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-hlandau-configurable.v1.git

  cd golang-gopkg-hlandau-configurable.v1 && pristine-tar checkout 
../golang-gopkg-hlandau-configurable.v1_1.0.1.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  e6c305885d3120aa541894fa6ceb368547d697f1 refs/heads/master
  9e875150fae5e7426681fbc12e1731b345b3462a refs/heads/pristine-tar
  20aedd0dca28b522a66e6ba0ba3ef6dc4b1be3bb refs/heads/upstream

It builds these binary packages:

  golang-gopkg-hlandau-configurable.v1-dev -- Go package for managing program 
configuration

This package is a prerequisite for building acmetool [1], an automatic
certificate acquisition tool for Let's Encrypt [2].

[1] https://bugs.debian.org/817091
[2] https://letsencrypt.org/about/

More information about golang-gopkg-hlandau-configurable.v1 can be obtained from

https://github.com/hlandau/configurable

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817224: RFS: golang-github-square-go-jose/0.0~git20160304.0.7465d2b -- Javascript Object Signing and Encryption (JOSE) for Go

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "golang-github-square-go-jose":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-square-go-jose.git

  cd golang-github-square-go-jose && pristine-tar checkout 
../golang-github-square-go-jose_0.0~git20160304.0.7465d2b.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  a10aeacc0ae2079a5377301367ca0b1a343bf62d refs/heads/master
  ec040e4084e7cef4905b1e5f34236afc5e3eceb4 refs/heads/pristine-tar
  d2c75c29e10dca028f1193d1c6a94679e23cfb5d refs/heads/upstream

It builds these binary packages:

  golang-github-square-go-jose-dev -- Javascript Object Signing and Encryption 
(JOSE) for Go

This package is a prerequisite for building acmetool [1], an automatic
certificate acquisition tool for Let's Encrypt [2].

[1] https://bugs.debian.org/817091
[2] https://letsencrypt.org/about/

More information about golang-github-square-go-jose can be obtained from

https://github.com/square/go-jose

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817223: RFS: golang-github-satori-go.uuid/0.0~git20160218.0.e673fdd -- Go package for creating and parsing UUID

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "golang-github-satori-go.uuid":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-satori-go.uuid.git

  cd golang-github-satori-go.uuid && pristine-tar checkout 
../golang-github-satori-go.uuid_0.0~git20160218.0.e673fdd.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  8e47fcd79e7d5da8f8f881ef032c2c374b761aa4 refs/heads/master
  ae97aad9ba1e129f8c1e32b4465d7870f333d197 refs/heads/pristine-tar
  0363f19ea24b1699b4470caa10c0a39b02f139d7 refs/heads/upstream

It builds these binary packages:

  golang-github-satori-go.uuid-dev -- Go package for creating and parsing UUID

This package is a prerequisite for building acmetool [1], an automatic
certificate acquisition tool for Let's Encrypt [2].

[1] https://bugs.debian.org/817091
[2] https://letsencrypt.org/about/

More information about golang-github-satori-go.uuid can be obtained from

https://github.com/satori/go.uuid

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817222: RFS: golang-github-peterhellberg-link/0.0~git20151119.0.1053d3b -- Go package for parsing link headers

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "golang-github-peterhellberg-link":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-peterhellberg-link.git

  cd golang-github-peterhellberg-link && pristine-tar checkout 
../golang-github-peterhellberg-link_0.0~git20151119.0.1053d3b.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  f044b2535ef20182f64289a30b7a9bbb3305db45 refs/heads/master
  cd5580f8e0d60e6b75a363b1d300edd45cffcc44 refs/heads/pristine-tar
  71449cfb1e308c4b5e8564c850b9e53f021d6e22 refs/heads/upstream

It builds these binary packages:

  golang-github-peterhellberg-link-dev -- Go package for parsing link headers

This package is a prerequisite for building acmetool [1], an automatic
certificate acquisition tool for Let's Encrypt [2].

[1] https://bugs.debian.org/817091
[2] https://letsencrypt.org/about/

More information about golang-github-peterhellberg-link can be obtained from

https://github.com/peterhellberg/link

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817221: RFS: golang-github-ogier-pflag/0.0~git20160129.0.45c278a -- POSIX/GNU-style command-line flags for Go

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "golang-github-ogier-pflag":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-ogier-pflag.git

  cd golang-github-ogier-pflag && pristine-tar checkout 
../golang-github-ogier-pflag_0.0~git20160129.0.45c278a.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  49a8de1991e48750641b9fdfd4f8be7be3b93369 refs/heads/master
  4e71f6d9ab81c21233f9a46e278e510bf602eb22 refs/heads/pristine-tar
  3f5daa8a1f5fe465a9b7611180de78bd7cf71018 refs/heads/upstream

It builds these binary packages:

  golang-github-ogier-pflag-dev -- POSIX/GNU-style command-line flags for Go

This package is a prerequisite for building acmetool [1], an automatic
certificate acquisition tool for Let's Encrypt [2].

[1] https://bugs.debian.org/817091
[2] https://letsencrypt.org/about/

More information about golang-github-ogier-pflag can be obtained from

https://github.com/ogier/pflag

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817220: RFS: golang-github-mitchellh-go-wordwrap/0.0~git20150314.0.ad45545 -- Go package for wrapping words into multiple lines

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package 
"golang-github-mitchellh-go-wordwrap":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-mitchellh-go-wordwrap.git

  cd golang-github-mitchellh-go-wordwrap && pristine-tar checkout 
../golang-github-mitchellh-go-wordwrap_0.0~git20150314.0.ad45545.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  534df2c1596c79a47785d3f3322b1583b4efad6d refs/heads/master
  4194647951cb3fcc2b37930086cdbfa51d6b3daf refs/heads/pristine-tar
  668b0c9bd13d257f865cc57c21e54f1127edd278 refs/heads/upstream

It builds these binary packages:

  golang-github-mitchellh-go-wordwrap-dev -- Go package for wrapping words into 
multiple lines

This package is a prerequisite for building acmetool [1], an automatic
certificate acquisition tool for Let's Encrypt [2].

[1] https://bugs.debian.org/817091
[2] https://letsencrypt.org/about/

More information about golang-github-mitchellh-go-wordwrap can be obtained from

https://github.com/mitchellh/go-wordwrap

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817219: RFS: golang-github-jmhodges-clock/0.0~git20151001.0.3c4ebd2 -- Go package for testing time-dependent code

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "golang-github-jmhodges-clock":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-jmhodges-clock.git

  cd golang-github-jmhodges-clock && pristine-tar checkout 
../golang-github-jmhodges-clock_0.0~git20151001.0.3c4ebd2.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  364285c93ceac6f5c9512b7a9bc89b922339bcca refs/heads/master
  8e7299ba5709203a3cfc66ca75fdaca7fff2130e refs/heads/pristine-tar
  e1c997f70279af8310dad65030e2d5a8ae4daad2 refs/heads/upstream

It builds these binary packages:

  golang-github-jmhodges-clock-dev -- Go package for testing time-dependent code

This package is a prerequisite for building acmetool [1], an automatic
certificate acquisition tool for Let's Encrypt [2].

[1] https://bugs.debian.org/817091
[2] https://letsencrypt.org/about/

More information about golang-github-jmhodges-clock can be obtained from

https://github.com/jmhodges/clock

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817218: RFS: golang-github-hlandau-xlog/0.0~git20160208.0.c18de57 -- logging library for Go

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "golang-github-hlandau-xlog":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-hlandau-xlog.git

  cd golang-github-hlandau-xlog && pristine-tar checkout 
../golang-github-hlandau-xlog_0.0~git20160208.0.c18de57.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  906524f663837911e83ede60ac54e78caaa50076 refs/heads/master
  787851976d95e5a460e3129a9817786decbd4ab7 refs/heads/pristine-tar
  86261ea45f6f01981be04c38dd5bb67de92c5a81 refs/heads/upstream

It builds these binary packages:

  golang-github-hlandau-xlog-dev -- logging library for Go

This package is a prerequisite for building acmetool [1], an automatic
certificate acquisition tool for Let's Encrypt [2].

[1] https://bugs.debian.org/817091
[2] https://letsencrypt.org/about/

More information about golang-github-hlandau-xlog can be obtained from

https://github.com/hlandau/xlog

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817217: RFS: golang-github-erikdubbelboer-gspt/0.0~git20151120.0.bbaae60 -- setproctitle for Go

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "golang-github-erikdubbelboer-gspt":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-erikdubbelboer-gspt.git

  cd golang-github-erikdubbelboer-gspt && pristine-tar checkout 
../golang-github-erikdubbelboer-gspt_0.0~git20151120.0.bbaae60.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  71da05f03f870dcccf0460faf0082b3610f20470 refs/heads/master
  19f1bcd2d6f34b9421d0e61d4d5caa5ebcc9f304 refs/heads/pristine-tar
  9ae926ae4fb820f08fa2277f59761d9a8e6aa238 refs/heads/upstream

It builds these binary packages:

  golang-github-erikdubbelboer-gspt-dev -- setproctitle for Go

This package is a prerequisite for building acmetool [1], an automatic
certificate acquisition tool for Let's Encrypt [2].

[1] https://bugs.debian.org/817091
[2] https://letsencrypt.org/about/

More information about golang-github-erikdubbelboer-gspt can be obtained from

https://github.com/ErikDubbelboer/gspt

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817216: RFS: golang-github-alecthomas-units/0.0~git20151022.0.2efee85 -- Go package for parsing byte units

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "golang-github-alecthomas-units":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-alecthomas-units.git

  cd golang-github-alecthomas-units && pristine-tar checkout 
../golang-github-alecthomas-units_0.0~git20151022.0.2efee85.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  78b74d576d043f91dfd3179041e6fa39127d0d73 refs/heads/master
  0a0cc46532bdbd6f1ff6f026c1afe27dab8de0bf refs/heads/pristine-tar
  e0d811dcfb06208171dfbe82bc4a8f82e46c0697 refs/heads/upstream

It builds these binary packages:

  golang-github-alecthomas-units-dev -- Go package for parsing byte units

This package is a prerequisite for building acmetool [1], an automatic
certificate acquisition tool for Let's Encrypt [2].

[1] https://bugs.debian.org/817091
[2] https://letsencrypt.org/about/

More information about golang-github-alecthomas-units can be obtained from

https://github.com/alecthomas/units

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817215: RFS: golang-github-alecthomas-template/0.0~git20151201.0.14fd436 -- text templates with newline elision for Go

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "golang-github-alecthomas-template":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-alecthomas-template.git

  cd golang-github-alecthomas-template && pristine-tar checkout 
../golang-github-alecthomas-template_0.0~git20151201.0.14fd436.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  88f3eff4501e9fc6f76347f07f8e9e9935d49d8d refs/heads/master
  c5c5c0ee117a59637d45c37cf074a8ac58d153f7 refs/heads/pristine-tar
  5f650c8b9c47aea8d9ca276c356ef3ebd1ad1492 refs/heads/upstream

It builds these binary packages:

  golang-github-alecthomas-template-dev -- text templates with newline elision 
for Go

This package is a prerequisite for building acmetool [1], an automatic
certificate acquisition tool for Let's Encrypt [2].

[1] https://bugs.debian.org/817091
[2] https://letsencrypt.org/about/

More information about golang-github-alecthomas-template can be obtained from

https://github.com/alecthomas/template

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817209: ppc64le emulation on i386 is broken

[Michael Tokarev]

Hello!


09.03.2016 04:56, Ben Hutchings wrote:
> Package: qemu-user-static
> Version: 1:2.5+dfsg-5
> Severity: normal
> 
> In addition to bug #813698, I found that most Debian ppc64el binaries
> go horribly wrong when running on the i386 build of
> qemu-ppc64le-static even with QEMU_CPU=POWER8.  This seems to be
> related to system call translation.  The amd64 build seems to be fine.

I'm afraid i386 host in qemu receives almost no testing for a long time,
especially for 64bit targets.   Some places in the code use types such
as int or long to represent 64 bits, incl. syscall translation, or, if
that's done correctly, fail to translate high bits in host integers.

Anyway, can you be a bit more specific about the failures?  Maybe some
simple test cases, something reproducible, because I'm not sure I'll
find the right bugs when trying to reproduce this :)

Is 386 host important these days, when almost all x86 machines are
64bits-capable and have large address space not easily accessible
in 32bit mode?

Thanks,

/mjt

Bug#817214: mirror submission for mirror.amaze.com.au

[Kris Shannon]

Package: mirrors
Severity: wishlist
User: devscri...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.amaze.com.au
Type: leaf
Archive-architecture: amd64 i386 
Archive-http: /debian/
IPv6: no
Archive-upstream: debian.uberglobalmirror.com
Updates: four
Maintainer: Kris Shannon 
Country: AU Australia
Location: Sydney
Sponsor: Amaze Communication http://www.amaze.com.au/

Bug#817213: RFS: fgetty/0.7-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: fgetty
  Version : 0.7-1
  Upstream Author : Felix von Leitner 
* Url : https://www.fefe.de/fgetty
* Licenses: GPL-2+
  Section : admin

I take maintainership with acknowlegement of previous maintainer
(Gerrit Pape).

It builds those binary packages:

fgetty -- very small, efficient, console-only getty and login

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

http://mentors.debian.net/package/fgetty

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

http://mentors.debian.net/debian/pool/main/f/fgetty/fgetty_0.7-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

git://anonscm.debian.org/users/kaction-guest/fgetty.git

More information about fgetty can be obtained from https://www.fefe.de/fgetty

Changes since last upload:

  * New maintainer
  * New upstream release
  * Add watch file with GPG key verification
  * Add source/format to follow v3.0 source package format
  * Use debhelper instead of custom debian/rules
  * Drop checkpassword-pam. Upstream does not support it, and once written,
but is not maintained anymore. Averaged desktop setup should not
need anyway.
  * Remove outdated README.Debian
  * Reformat debian/copyright to follow DEP-5
  * Link checkpassword with gnu libc (Closes: #563335) with hardening
  * Add lintian overrides about static build and lack of dependencies
  * Write manpage for login1 and login2
  * New standards version -- 3.9.7 (No changes needed)

Regards,
  Dmitry Bogatov

Bug#813323: Second window of Eye of MATE don't get focus

[John Paul Adrian Glaubitz]

Control: forward -1 https://github.com/mate-desktop/eom/issues/119

On 03/08/2016 10:23 PM, Strelok wrote:
>> Yeah. But you're barking up the wrong tree. Unless this is a bug which
>> is only present in Debian, you have to report it to MATE's upstream
>> bug tracker which can be found in [1]. Debian is primarily dealing
>> with packaging, fixing such bugs is upstream's job.
> 
> I'm read abort this tree in https://www.debian.org/Bugs/Reporting :
> Don't file bugs upstream

I *strongly* disagree with the comments on this site. You should, in
fact, *always* report *upstream* bugs upstream.

> If you file a bug in Debian, don't send a copy to the upstream
> software maintainers yourself, as it is possible that the bug exists
> only in Debian. If necessary, the maintainer of the package will
> forward the bug upstream.

Yeah, so basically this says "Report the bug to the maintainer and hope
that the maintainer forwards your upstream bug report upstream just
to make sure the whole process of fixing the issue is delayed."

This is stupid. I'm asking to get this changed! Again, upstream bugs
should *always* be filed upstream otherwise chances are you are waiting
forever to get your bug fixed.

> But ok, I'm send bug report also to upstream
> (https://github.com/mate-desktop/eom/issues/119).

Great, thanks. I just linked the two reports.

Adrian

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

Bug#817206: s390-zfcp: [INTL:pt] Portuguese translation for debconf messages

[Christian PERRIER]

Quoting Américo Monteiro (a_monte...@gmx.com):
> Package: s390-zfcp
> version: 1.0.1
> Tags: l10n, patch
> Severity: wishlist
> 
> Updated Portuguese translation for s390-zfcp's debconf messages.
> Translator: Américo Monteiro 
> Feel free to use it.
> 
> For translation updates please contact 'Last Translator' or the
> Portuguese Translation Team .

Indeed, s390-zfcp is part of Debian Installer and should be translated
through its l10n system. And, localization was indeed removed in
recent changes, so I'm afraid this makes this translation now
useless:-(



signature.asc
Description: PGP signature

Bug#817212: RM: luasseq -- RoQA; taken over by texlive-base

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Hi,

please remove the obsolete source package luasseq from sid, the binary
package is now a transitional arch:all package built by texlive-base.


Andreas

Bug#817123: Can replicate with Dell XPS 15 9550

[Chris Lawrence]

I am having what appears to be the same problem since upgrading to 1.1.91-1
in testing from 1.1.90-5; network-manager seems, rather bizarrely, to now
believe my Broadcom Corporation BCM43602 802.11ac Wireless LAN SoC is a
wired card on boot-up.

However, "service network-manager restart" fixes the problem, detecting the
fact it's a wireless card correctly.

I'm attaching edited startup logs from 1.1.90-5 and 1.1.91-1 in case they
are helpful.


Chris


startup-log-1.1.90
Description: Binary data


startup-log-1.1.91
Description: Binary data

Bug#817211: ITP: ruby-rsync -- ruby wrapper and bindings for the rsync binary

[Sebastien Badia]

Package: wnpp
Severity: wishlist
Owner: Sebastien Badia 

* Package name: ruby-rsync
  Version : 1.0.9
  Upstream Author : Joshua Bussdieke
* URL : http://github.com/jbussdieker/ruby-rsync
* License : Expat
  Programming Lang: Ruby
  Description : ruby wrapper and bindings for the rsync binary

 Ruby/Rsync is a Ruby library that can synchronize files between remote
 hosts by wrapping a call to the rsync binary.

This package is a new depdendency of librarian-puppet. And it are going
to be maintained inside the Ruby Team (CCed).

Bug#817012: ruby-amqp and ruby-amq-client: error when trying to install together

[Andreas Beckmann]

On 2016-03-09 05:02, Sebastien Badia wrote:
> root@986c8ab6cb31:~# dpkg -i ruby-amqp_1.5.1-3_all.deb 
> Selecting previously unselected package ruby-amqp.
> (Reading database ... 18260 files and directories currently installed.)
> Preparing to unpack ruby-amqp_1.5.1-3_all.deb ...
> Unpacking ruby-amqp (1.5.1-3) ...
> Replacing files in old package ruby-amq-client (1.0.4-1) ...
> Setting up ruby-amqp (1.5.1-3) ...
> root@986c8ab6cb31:~# apt policy ruby-amq-client
> ruby-amq-client:
>   Installed: 1.0.4-1
>   Candidate: 1.0.4-1
>   Version table:
>  *** 1.0.4-1 100
> 100 /var/lib/dpkg/status
> root@986c8ab6cb31:~# apt policy ruby-amqp  
> ruby-amqp:
>   Installed: 1.5.1-3
>   Candidate: 1.5.1-3
>   Version table:
>  *** 1.5.1-3 100
> 100 /var/lib/dpkg/status

That looks like you only have a Replaces: ruby-amq-client without a
corresponding Breaks. If you remove ruby-amqp at this point,
ruby-amq-client will still be installed, but will be missing some files,
despite of dpkg considering it as correctly installed.


Andreas

Bug#817012: ruby-amqp and ruby-amq-client: error when trying to install together

[Sebastien Badia]

On Tue, Mar 08, 2016 at 09:15:01PM (+0100), Andreas Beckmann wrote:
> Hi,
> 
> removal of the old package is not sufficient, you still need to add 
> Breaks+Replaces:

Hi!

Oh indeed, Humrf… I missed this…

It should be ok in the version -3

Thanks! And sorry for the inconvenience.

root@986c8ab6cb31:~# apt policy ruby-amq-client
ruby-amq-client:
  Installed: 1.0.4-1
  Candidate: 1.0.4-1
  Version table:
 *** 1.0.4-1 100
100 /var/lib/dpkg/status
root@986c8ab6cb31:~# dpkg -i ruby-amqp_1.5.1-3_all.deb 
Selecting previously unselected package ruby-amqp.
(Reading database ... 18260 files and directories currently installed.)
Preparing to unpack ruby-amqp_1.5.1-3_all.deb ...
Unpacking ruby-amqp (1.5.1-3) ...
Replacing files in old package ruby-amq-client (1.0.4-1) ...
Setting up ruby-amqp (1.5.1-3) ...
root@986c8ab6cb31:~# apt policy ruby-amq-client
ruby-amq-client:
  Installed: 1.0.4-1
  Candidate: 1.0.4-1
  Version table:
 *** 1.0.4-1 100
100 /var/lib/dpkg/status
root@986c8ab6cb31:~# apt policy ruby-amqp  
ruby-amqp:
  Installed: 1.5.1-3
  Candidate: 1.5.1-3
  Version table:
 *** 1.5.1-3 100
100 /var/lib/dpkg/status

Seb


signature.asc
Description: PGP signature

Bug#816891: jessie-pu: package espeakup/1:0.71-19

[Cyril Brulebois]

Julien Cristau  (2016-03-07):
> cc += kibi
> 
> On Sun, Mar  6, 2016 at 11:21:24 +0100, Samuel Thibault wrote:
> 
> > Package: release.debian.org
> > Severity: normal
> > Tags: jessie
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> > Hello,
> > 
> > I'd like to upload to Jessie the attached changes to the espeakup
> > package.
> > 
> > The current Jessie debian installer got a bug which made it only support
> > german, english, french, and portuguese.  That is because the file
> > hierarchy of voices has changed in the updated upstream version, and
> > they had provided compatibility links, but only for those languages.
> > 
> > The attached change uses a mere recursive grep to find language
> > identifiers instead of hardcoding the path. That actually allows to drop
> > the special-casing of the nb language. The change also special cases
> > gallician, for which we have no native support, but the portuguese voice
> > should be fine enough, better than english anyway. It also makes the
> > espeakup daemon select the voice not only by name, but also by property,
> > just like the espeak program does, which is needed when the voice is
> > chosen by the language it supports and not by the identifier of the
> > voice.
> > 
> Since the changes affect d-i in stable, I'd like a kibi-ack.

The whole thing looks like a good idea, and I trust Samuel's tested this
properly, so feel free to accept it into p-u.


KiBi.


signature.asc
Description: Digital signature

Bug#735050: aptitude: Continues to remove conflicting package, although new package failed to download

[Manuel A. Fernandez Montecelo]

Control: fixed -1 aptitude/0.7.6-1
Control: close -1


Hi Manuel :-)


2014-01-12 10:56 Manuel Bilderbeek:

Package: aptitude
Version: 0.6.8.2-1.2
Severity: normal

Dear Maintainer,

I asked aptitude to install a new package, which conflicted with an
older package. So, it suggested to remove that package. So far so good.
However, the new package failed to download (some transient network
error). But to my surprise, the conflicting older package was still
removed. End result: no new and no old package installed...

I think this is wrong behaviour. I expect that in this situation also
the old package should not be removed after all as no new (conflicting)
package is going to be installed.


I believe that this has been fixed in 0.7.6-1, with sequences of actions
being more strict and aborting in the face of failures:

 * Abort with Failure (rather to continue with the installation) when packages
   fail to be fetched -- except if APT::Get::Fix-Missing is present and set to
   true.  When this happens, the actions in the command line also return with
   non-zero status.  (Closes: #121313, #302784)

 * [cmdline] Abort with Failure when actions cannot be taken
   (Closes: #121313, #430392, #445034, #498239, #576212, #639789, #798320)

   The Closes of #121313 overlap with other fixes, there are reports of each
   case merged.


If you find the problem again, please reopen.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#724032: I thought I said install // aptitude: "aptitude install" purges packages instead of updating them

[Manuel A. Fernandez Montecelo]

Control: fixed -1 aptitude/0.7.3-1
Control: close -1


Hi,

2013-09-22 12:50 jida...@jidanni.org:

Package: aptitude
Version: 0.6.8.2-1.2
Severity: wishlist

I thought I said install. So I just hit return. Looking closer I see it
was asking me about removing them.

Well OK, I'm sure it has its logic and mother knows best, but well... never 
mind.

# aptitude search ~U
i A tcl8.5  - Tcl (the Tool Command Language) v8.5 - she
i A tk8.5   - Tk toolkit for Tcl and X11, v8.5 - windowi
i A xserver-xorg-core   - Xorg X server - core server
# aptitude install ~U~n8
The following packages will be REMOVED:
 tcl8.5{pu} (D: tk8.5)  tk8.5{pu}
0 packages upgraded, 0 newly installed, 2 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 6,669 kB will be freed.
Do you want to continue? [Y/n/?]
[...]


So among the bugs below (not including merged bugs), fixed in 0.7.3...

 * Remove unneeded automatically installed packages in the same action
   (Closes: #478116, #564545, #637257, #368037, #486454, #738517,
   #789803, #77, #756507, #759764, #766702, #655483,#740009)

...there were several duplicates from you (maybe some of them were
caused by different underlying problems, but similar enough), including
at least:

 #590308, #637483, 661699, #713906, #779715, #738517, #77, #756507,
 #759764, #766702

basically saying "installing then purging leaves packages behind",
because istead of removing them in the same "session" that it removed
its reverse-dependencies (packages depending on those removed later), it
was deferring the action for another "session".


Well, so I am happy to report that this is the nth duplicate about this
issue :-)


In the command above, all of the Upgradable packages shown have been
auto-installed, of which tcl8.5 and tk8.5 had not reverse dependencies
and thus are being removed in that session.  xserver-xorg-core
supposedly had rev-depends installed, and thus not removed.

Why hadn't Tcl/Tk packages been removed before?  Because (lib)apt was
not marking them as "garbage", and it was in 0.7.3-1 that I implemented
extra checks in aptitude to try to proactively remove more packages that
apt was not removing at the same time that it removed the packages that
depended on them.

(I don't think that it's a terribly important problem, in fact I think
that it's pretty insignificant, and I think that everybody should
tolerate that aptitude / package-manager-du-jour removes some of the
garbage in the next session instead; but I thought that ~20 reports
about the same problem Ought to be Enough for Anyone and I decided that
I didn't want to get up to 640k about it).

Even if you are asking to install, aptitude was at least clever enough
to detect that they were unused and auto-installed, so it removed it at
the first opportunity, stealing Install's thunder.  Had you requested to
"install ~U" it would have removed the Tcl/Tk ones and would have
upgraded xserver-xorg-core.


So, in summary, I am still more happy to report that we can close this
bug now as another duplicate of the ones above.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#817210: systemd-resolve: segfaults upon domain name resolution

[Rostislav Pehlivanov]

Package: libnss-resolve
Version: 229-2
Severity: important

Dear maintainer:

If systemd-resolve is used as the default system dns resolver
(by replacing "dns" inside /etc/nsswitch.conf with "resolve"),
the process handling the resolving "/lib/systemd/systemd-resolved"
started by the service systemd-resolved will segfault upon domain name
resolution (e.g. ping  will crash the process). The service
gets restarted immediately after it segfaults and is able to resolve the
first domain name (but with a short delay), so it's mostly transparent
to the end user. However the dmesg log quickly gets filled with entries like:

"[ 7620.719971] systemd-resolve[3655]: segfault at 5c ip 5625f5934147 sp 
7ffc5acd7380 error 4 in systemd-resolved[5625f590c000+9d000"

I believe it started after libc6 was updated in Debian unstable, though
I am not sure it was the cause.

I did try to run gdb to at least find out where it crashes, but the process
doesn't function as it should without it being started as a service.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-rc6-youmu (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libnss-resolve depends on:
ii  libc62.22-1
ii  libselinux1  2.4-3+b1
ii  systemd  229-2

libnss-resolve recommends no packages.

libnss-resolve suggests no packages.

-- no debconf information

Bug#817207: glibc: kfreebsd-i386: illegal instruction in ld.so

[Steven Chamberlain]

Steven Chamberlain wrote:
> Upgrading libc0.1 breaks pretty much everything:

Actually not everything.  It broke the buildd though, because dpkg-deb
stopped working.  This was from dpkg-deb:

> | Core was generated by `ld-2.22.so'.
> | Program terminated with signal 4, Illegal instruction.
> | (gdb) bt full
> | #0  0x0100622b in ?? ()
> | No symbol table info available.
> | #1  0x62696c2f in ?? ()
> | No symbol table info available.
> | #2  0x3833692f in ?? ()
> | No symbol table info available.
> | #3  0x666b2d36 in ?? ()
> | No symbol table info available.
> | #4  0x01001a90 in ?? ()
> | No symbol table info available.
> | #5  0x in ?? ()
> | No symbol table info available.

It fails trying to map shared object liblzma.so.5:

| 2494 ld.so.1  NAMI  "/usr/bin/dpkg-deb"
| ...
| 2494 ld.so.1  NAMI  "/lib/i386-kfreebsd-gnu/libz.so.1"
| 2494 ld.so.1  NAMI  "/lib/i386-kfreebsd-gnu/liblzma.so.5"
| ...
| 2494 ld.so.1  PSIG  SIGILL SIG_DFL code=ILL_PRVOPC

There is something special about liblzma.so.5:

|   STACK off0x vaddr 0x paddr 0x align 2**2
| filesz 0x memsz 0x flags rwx

It requires a writable and executable stack!  which is rather rare, and
probably should be fixed in the affected libraries.  The kfreebsd
buildds have disallowed executable stacks since DebConf15 though.

I'm not sure why glibc 2.22 causes any regression here;  this code has
not changed since 2.21, but maybe something related to
DEFAULT_STACK_PERMS, PF_X or PT_GNU_STACK has changed recently.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#357828: logging should be locale-independent

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending
Control: unmerge -1

Marking as pending, then unmerging.

Unmerging because this was mostly about the dates and the other about
the messages, so keeping it separate just in case that it needs to be
reopened and treated differently than the other ones.

This one contradicts #489706, which was applied later than this and is
the current one... which suggests that maybe dates were already
localized before this bug, then changed, then changed again before the
other was submitted...

So it looks like date format strings were changed a few times back and
forth between being localized and not and that everybody has a different
opinion about it.

--
Manuel A. Fernandez Montecelo 


2006-03-19 18:48 Robert Bihlmeyer:

Package: aptitude
Version: 0.4.1-1
Severity: minor

It seems that at least the second line of each stanza (containing the
date) in /var/log/aptitude is depending on the locale that aptitude is
running under.

I think this is problematic.

Logfiles should be machine-parseable. But the parser has no easy way
to find out what locale was used, so it would need to be able handle
all of them, in principle.

Running aptitude a number of times, it will normally just append to
the current log. If the runs were made with different locales active,
this will result in a file with different date formats for the same
date, which seems evil. Surely evil is the case I am currently looking
at, where the encoding changes mid-file: some stanzas are in
iso8859-1, others in utf-8.

My proposal is to always pretend that something like "en_US.UTF-8" was
in effect for logging, i.e. encode in UTF-8 (though everything
*should* be ASCII, afaics) and use English messages, date format, etc.

Thanks for considering,
Robbe

Bug#814167: lwjgl: (Build-)Depends on OpenJDK 7

[Michael Gilbert]

> I have switched the build-dependency to default-jdk and changed
> JAVA_HOME in debian/rules accordingly. However the package FTBFS with
> OpenJDK 8. I guess packaging the latest upstream release would be the
> best option.

2.9.3 is supposed to support building without ant.  I looked at it a
while ago, and it isn't quite that simple.

lwjgl3 is also available, but it has a huge dependency stack with
almost none of it in Debian yet.

I have less interest in lwjgl now than I used to, and I may not be
able to find the time to work on it.

Best wishes,
Mike

Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key

[gustavo panizzo]

Package: pcscd
Version: 1.8.15-1
Followup-For: Bug #812087

Hello

I just want to provide more information about the issue, I have an
SmartCard reader (ok, it is usb internally) and a g10 smartcard.
I can reproduce the issue plugging my phone as MTP device.

If I had my phone connected while I started pcscd when I unplug it, pcscd
takes 100% of the CPU too.



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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 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: systemd (via /run/systemd/system)

Versions of packages pcscd depends on:
ii  init-system-helpers 1.28
ii  libc6   2.19-22
ii  libccid [pcsc-ifd-handler]  1.4.22-1
ii  libpcsclite11.8.15-1
ii  libudev1228-6
ii  lsb-base9.20160110

pcscd recommends no packages.

Versions of packages pcscd suggests:
ii  systemd  228-6

-- no debconf information

Bug#817209: ppc64le emulation on i386 is broken

[Ben Hutchings]

Package: qemu-user-static
Version: 1:2.5+dfsg-5
Severity: normal

In addition to bug #813698, I found that most Debian ppc64el binaries
go horribly wrong when running on the i386 build of
qemu-ppc64le-static even with QEMU_CPU=POWER8.  This seems to be
related to system call translation.  The amd64 build seems to be fine.

Ben.

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

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

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.1.6-1

Versions of packages qemu-user-static suggests:
ii  sudo  1.8.15-1.1

-- no debconf information

-- debsums errors found:
debsums: package qemu-user-static is not installed

Bug#817208: Cannot load library /usr/lib/kde4/kio_digikamdates.so

[Ryan Kavanagh]

Package: digikam
Version: 4:4.14.0-3
Severity: grave
Justification: renders package unusable

As of today, digikam no longer displays any pictures from my albums.

The following errors can be found in ~/.xsession-errors:

Could not open library '/usr/lib/kde4/kio_digikamdates.so'.
Cannot load library /usr/lib/kde4/kio_digikamdates.so: 
(/lib/x86_64-linux-gnu/libresolv.so.2: symbol __h_errno, version GLIBC_PRIVATE 
not defined in file libc.so.6 with link time reference)
Could not open library '/usr/lib/kde4/kio_digikamalbums.so'.
Cannot load library /usr/lib/kde4/kio_digikamalbums.so: 
(/lib/x86_64-linux-gnu/libresolv.so.2: symbol __h_errno, version GLIBC_PRIVATE 
not defined in file libc.so.6 with link time reference)

The following errors are printed to stderr:

digikam(22075): couldn't create slave: "Unable to create io-slave:
klauncher said: Error loading 'kio_digikamdates'.
"
digikam(22075)/digikam (core) Digikam::AlbumManager::slotDatesJobResult: Failed 
to list dates
digikam(22075)/digikam (core) Digikam::DNotificationWrapper: parent is null
digikam(22075): couldn't create slave: "Unable to create io-slave:
klauncher said: Error loading 'kio_digikamalbums'.
"
digikam(22075)/digikam (core) Digikam::ImageAlbumModel::slotResult: Failed to 
list url:  "Could not start process Unable to create io-slave:
klauncher said: Error loading 'kio_digikamalbums'.
."

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages digikam depends on:
ii  digikam-data4:4.14.0-3
ii  digikam-private-libs4:4.14.0-3
ii  kde-runtime 4:15.08.3-1+b1
ii  libc6   2.22-1
ii  libgcc1 1:5.3.1-11
ii  libgphoto2-62.5.9-3
ii  libgphoto2-port12   2.5.9-3
ii  libkdcraw23 4:15.08.0-1+b1
ii  libkdecore5 4:4.14.14-1+b1
ii  libkdeui5   4:4.14.14-1+b1
ii  libkexiv2-114:15.04.3-1
ii  libkhtml5   4:4.14.14-1+b1
ii  libkio5 4:4.14.14-1+b1
ii  libkipi11   4:15.08.3-1
ii  libknotifyconfig4   4:4.14.14-1+b1
ii  libkparts4  4:4.14.14-1+b1
ii  libopencv-core2.4v5 2.4.9.1+dfsg-1.3
ii  libopencv-imgproc2.4v5  2.4.9.1+dfsg-1.3
ii  libphonon4  4:4.8.3-2
ii  libqt4-dbus 4:4.8.7+dfsg-6
ii  libqt4-sql  4:4.8.7+dfsg-6
ii  libqt4-sql-sqlite   4:4.8.7+dfsg-6
ii  libqt4-xml  4:4.8.7+dfsg-6
ii  libqtcore4  4:4.8.7+dfsg-6
ii  libqtgui4   4:4.8.7+dfsg-6
ii  libsolid4   4:4.14.14-1+b1
ii  libstdc++6  5.3.1-11
ii  libthreadweaver44:4.14.14-1+b1
ii  perl5.22.1-8
ii  phonon  4:4.8.3-2

Versions of packages digikam recommends:
ii  chromium [www-browser]  49.0.2623.75-2
pn  ffmpegthumbs | mplayerthumbs
ii  google-chrome-stable [www-browser]  49.0.2623.87-1
ii  iceweasel [www-browser] 44.0.2-1
pn  kipi-plugins
ii  lynx [www-browser]  2.8.9dev8-4
ii  w3m [www-browser]   0.5.3-27

Versions of packages digikam suggests:
pn  digikam-doc 
pn  systemsettings  

-- no debconf information

-- 
|_)|_/  Ryan Kavanagh   | Debian Developer
| \| \  https://ryanak.ca/  | GPG Key 4A11C97A


signature.asc
Description: PGP signature

Bug#804203: ITP: golang-github-fatih-color -- Color package for Go (golang)

[Peter Colberg]

Hi Andrew,

On Tue, Mar 08, 2016 at 07:45:01PM -0500, Andrew Starr-Bochicchio wrote:
> Please feel free to go ahead and update the pkg-go git repo. Let me
> know if you still need a sponsor; I'd be happy to review and upload it
> for you.

Thanks for offering to review! I pushed the finished package to

https://anonscm.debian.org/git/pkg-go/packages/golang-github-fatih-color.git

If your review is positive, please go ahead with finalizing
the distribution and changelog timestamp before the upload.

Regards,
Peter

Bug#817207: glibc: kfreebsd-i386: illegal instruction in ld.so

[Steven Chamberlain]

Package: src:glibc
Version: 2.22-1
Severity: important
User: debian-...@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-...@lists.debian.org

Hi,

glibc/2.22 has a major problem on kfreebsd-i386.  It built on the
buildds, but the compiled ld-2.22.so is broken as seen on buildd finzi:

https://buildd.debian.org/status/fetch.php?pkg=mksh=kfreebsd-i386=52c-1=1457437296
| dpkg: error processing archive 
/var/cache/apt/archives/libc-bin_2.22-1_kfreebsd-i386.deb (--unpack):
|  subprocess dpkg-deb --control was killed by signal (Illegal instruction)
| Errors were encountered while processing:
|  /var/cache/apt/archives/libc-bin_2.22-1_kfreebsd-i386.deb

Upgrading libc0.1 breaks pretty much everything:

| Core was generated by `ld-2.22.so'.
| Program terminated with signal 4, Illegal instruction.
| (gdb) bt full
| #0  0x0100622b in ?? ()
| No symbol table info available.
| #1  0x62696c2f in ?? ()
| No symbol table info available.
| #2  0x3833692f in ?? ()
| No symbol table info available.
| #3  0x666b2d36 in ?? ()
| No symbol table info available.
| #4  0x01001a90 in ?? ()
| No symbol table info available.
| #5  0x in ?? ()
| No symbol table info available.

That corresponds to the 'ud2' instruction in the disassembly below:

|  /* The stack is presently not executable, but this module
| requires that it be executable.  We must change the
| protection of the variable which contains the flags used in
| the mprotect calls.  */
|#ifdef SHARED
|  if ((mode & (__RTLD_DLOPEN | __RTLD_AUDIT)) == __RTLD_DLOPEN)
|51fc:   8b 45 14mov0x14(%ebp),%eax
|51ff:   25 00 00 00 88  and$0x8800,%eax
|5204:   3d 00 00 00 80  cmp$0x8000,%eax
|5209:   0f 84 b9 01 00 00   je 53c8 
<_dl_map_object_from_fd+0x1258>
|}
|  __stack_prot |= PROT_READ|PROT_WRITE|PROT_EXEC;
|  __mprotect ((void *) p, s, PROT_READ);
|}
|  else
|__stack_prot |= PROT_READ|PROT_WRITE|PROT_EXEC;
|520f:   8b 85 70 ff ff ff   mov-0x90(%ebp),%eax
|5215:   83 88 1c ff ff ff 07orl$0x7,-0xe4(%eax)
|521c:   e8 af 2e 01 00  call   180d0 <__x86.get_pc_thunk.cx>
|5221:   81 c1 df cd 01 00   add$0x1cddf,%ecx
|5227:   29 d9   sub%ebx,%ecx
|5229:   74 02   je 522d 
<_dl_map_object_from_fd+0x10bd>
|522b:   0f 0b   ud2
|
|#ifdef check_consistency
|  check_consistency ();
|#endif
|
|  errval = (*GL(dl_make_stack_executable_hook)) (stack_endp);
|522d:   8b 8d 70 ff ff ff   mov-0x90(%ebp),%ecx

kFreeBSD 10 disallows executable stacks by default.  It can be allowed
again by sysctl kern.elf32.nxstack=0, but it would be better if glibc
didn't need this.  I wonder why this issue wasn't seen on kfreebsd-amd64
since executable stacks are not allowed there either.

Thanks.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-i386 (i386)

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


signature.asc
Description: Digital signature

Bug#804203: ITP: golang-github-fatih-color -- Color package for Go (golang)

[Andrew Starr-Bochicchio]

On Tue, Mar 8, 2016 at 2:23 AM, Peter Colberg  wrote:
> I noticed that you have already created a pkg-go repository for
> golang-github-fatih-color, although containing an older version.
>
> If you have no objections, I will push an updated upstream snapshot
> (which no longer depends on github.com/shiena/ansicolor) and submit
> a request for sponsored upload.

Hi Peter,

Please feel free to go ahead and update the pkg-go git repo. Let me
know if you still need a sponsor; I'd be happy to review and upload it
for you.

Thanks,

-- Andrew Starr-Bochicchio

   Ubuntu Developer 
   Debian Developer 
   PGP/GPG Key ID: D53FDCB1

Bug#817206: s390-zfcp: [INTL:pt] Portuguese translation for debconf messages

[Américo Monteiro]

Package: s390-zfcp
version: 1.0.1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for s390-zfcp's debconf messages.
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro


s390-zfcp_1.0.1_pt.po.gz
Description: GNU Zip compressed data

Bug#405506: aptitude cannot parse package file

[Manuel A. Fernandez Montecelo]

Control: tags -1 - moreinfo + pending


2014-02-05 21:22 To 405...@bugs.debian.org:

Control: tags -1 + moreinfo - unreproducible
Control: severity -1 wishlist
Control: retitle -1 handle corrupted pkgstate more gracefully

I think that if this bug is to be kept open and fixed, this proposal
from Daniel Burrows is the way to go (and the only remaining useful
bit from the bug report).  Retitling etc. accordingly.

-

 Maybe aptitude should offer to restore pkgstate.old or move the
corrupt file out of the way.  This would be a bit more graceful than
going "gaaack" and dying.

 The basic idea (if the user asks to recover) would be
   (1) move pkgstates to pkgstates.broken.NUM where NUM is the first
unused number (actually use link(2) to avoid clobbering existing
files).
   (2) if pkgstates.old exists, move it to pkgstates.
   (3) if pkgstates exists and is not parsable, go to (1) (i.e., move
pkgstates.old out of the way and start completely from scratch)


I addressed this, marking as +pending.

It doesn't offer to do all the things above, because it's complicate and
prone to get things wrong for something that shouldn't happen very often
at all... but now it detects when the file is corrupt/malformed and
suggests the user to try to recover from pkgstates.old.


--
Manuel A. Fernandez Montecelo 

Bug#813571: (no subject)

[Barry Warsaw]

I think this should now all be sorted out with python-virtualenv 15.0.0+ds-1
and python-pip 8.1.0-1.  I'm going to close this bug but if you're still
having a problem with those new versions, please reopen it.

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Alexis Murzeau]

2016-03-04 14:07 GMT+01:00 Matt Fleming :
>
> It must have been a herculean effort to take photos of the screen
> while the buggy kernel booted. Thank you!
>
> I'm not really seeing anything jumping out as obviously wrong apart
> from the fact that we don't have all of EFI_CONVENTIONAL_MEMORY mapped
> in the buggy kernel.
>
> Could you try this patch?
>
> ---
>
> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> index 49e4dd4a1f58..f5e77d240ff1 100644
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -241,15 +241,6 @@ int __init efi_setup_page_tables(unsigned long 
> pa_memmap, unsigned num_pages)
> efi_scratch.use_pgd = true;
>
> /*
> -* When making calls to the firmware everything needs to be 1:1
> -* mapped and addressable with 32-bit pointers. Map the kernel
> -* text and allocate a new stack because we can't rely on the
> -* stack pointer being < 4GB.
> -*/
> -   if (!IS_ENABLED(CONFIG_EFI_MIXED))
> -   return 0;
> -
> -   /*
>  * Map all of RAM so that we can access arguments in the 1:1
>  * mapping when making EFI runtime calls.
>  */
> @@ -268,6 +259,15 @@ int __init efi_setup_page_tables(unsigned long 
> pa_memmap, unsigned num_pages)
> }
> }
>
> +   /*
> +* When making calls to the firmware everything needs to be 1:1
> +* mapped and addressable with 32-bit pointers. Map the kernel
> +* text and allocate a new stack because we can't rely on the
> +* stack pointer being < 4GB.
> +*/
> +   if (!IS_ENABLED(CONFIG_EFI_MIXED))
> +   return 0;
> +
> page = alloc_page(GFP_KERNEL|__GFP_DMA32);
> if (!page)
> panic("Unable to allocate EFI runtime stack < 4GB\n");

Thanks for you suggestion.
Unfortunately, this patch doesn't make it works, the crash still
occurs (at the same RIP and traceback).

Using /dev/mem on a running system (with kernel 4.3), the memory
around RIP (0xaa9462ee) is :
aa9462d0  sub rsp,0x28
aa9462d4  lea rdx,[rip+0x2445] # 0xaa948720
aa9462db  mov ecx,0x4
aa9462e0  call func_aa9447c0  ; call to ConvertPointer(4, & 0xaa948720)
aa9462e5  mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
aa9462ec  xor eax,eax
aa9462ee  mov BYTE PTR [r11+0x1],0x1
aa9462f3  add rsp,0x28
aa9462f7  ret

The QWORD at address 0xaa948720 is 0 though on the running system.

I will try to investigate more but I'm open to any printk / patch tests.

Alexis Murzeau

Bug#816982: maxima: FTBFS when built with dpkg-buildpackage -A (tests fail)

[Camm Maguire]

tags 816982 unreproducible
thanks

Greetings!  Both dpkg-buildpackage -A and dpkg-buildpackage -B work for
me on barriere chroot.

Take care

Santiago Vila  writes:

> Package: src:maxima
> Version: 5.37.3-1
> User: sanv...@debian.org
> Usertags: binary-indep
> Severity: important
>
> Dear maintainer:
>
> I tried to build this package with "dpkg-buildpackage -A"
> (i.e. only architecture-independent packages), and it failed:
>
> 
> [...]
>  debian/rules build-indep
> mkdir -p debian/save
> [ -e debian/save/aclocal.m4 ] || cp aclocal.m4 debian/save/aclocal.m4
> mkdir -p debian/save
> [ -e debian/save/configure ] || cp configure debian/save/configure
> mkdir -p debian/save/interfaces/emacs/imaxima
> [ -e debian/save/interfaces/emacs/imaxima/stamp-vti ] || cp 
> interfaces/emacs/imaxima/stamp-vti 
> debian/save/interfaces/emacs/imaxima/stamp-vti
> mkdir -p debian/save/interfaces/emacs/imaxima
> [ -e debian/save/interfaces/emacs/imaxima/imaxima.info ] || cp 
> interfaces/emacs/imaxima/imaxima.info 
> debian/save/interfaces/emacs/imaxima/imaxima.info
> mkdir -p debian/save/interfaces/emacs/imaxima
> [ -e debian/save/interfaces/emacs/imaxima/version.texi ] || cp 
> interfaces/emacs/imaxima/version.texi 
> debian/save/interfaces/emacs/imaxima/version.texi
> mkdir -p debian/save/src
>
> [... snipped ...]
>
> Running tests in rtest_taylor: 149/149 tests passed (not counting 6 expected 
> errors)
> Running tests in rtest_dot: 60/60 tests passed
> Running tests in rtest_mset: 92/92 tests passed
> Running tests in rtest_boolean: 116/116 tests passed
> Running tests in rtest_round: 101/101 tests passed
> Running tests in rtest_map: 99/99 tests passed (not counting 3 expected 
> errors)
> Running tests in rtest_sign: 307/307 tests passed (not counting 7 expected 
> errors)
> Running tests in rtest_algebraic: 45/45 tests passed
> Running tests in rtest_gamma: 745/745 tests passed
> Running tests in rtest_expintegral: 210/210 tests passed
> Running tests in rtest_signum: 50/50 tests passed
> Running tests in rtest_lambert_w: 57/57 tests passed
> Running tests in rtest_elliptic: 87/87 tests passed
> Running tests in rtest_integrate: 812/812 tests passed
> Running tests in rtest_integrate_special: 53/53 tests passed
> Running tests in rtest_sqrt: 313/313 tests passed (not counting 1 expected 
> errors)
> Running tests in rtest_carg: 55/55 tests passed (not counting 2 expected 
> errors)
> Running tests in rtest_log: 121/121 tests passed
> Running tests in rtest_power: 72/72 tests passed (not counting 5 expected 
> errors)
> Running tests in rtestdefstruct: 32/32 tests passed
> Running tests in rtest_limit: 177/177 tests passed
> Running tests in rtest_powerseries: touch tmp
> cat tmp >debian/test_results.out
> grep -q "No unexpected errors found." debian/test_results.out
> debian/rules:73: recipe for target 'build-stamp' failed
> make: *** [build-stamp] Error 1
> dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
> 67/67 tests passed
> Running tests in rtest_laplace: 98/98 tests passed (not counting 11 expected 
> errors)
>
> Error summary:
> Errors found in /<>/tests/rtest15.mac, problems:
> (47 49 55 61 67 73 79 85 91 165 174)
> Error found in /<>/tests/rtest8.mac, problem:
> (133)
> 12 tests failed out of 10,408 total tests.
> real time   : 92.709 secs
> run-gbc time: 76.080 secs
> child run time  :  8.229 secs
> gbc time:  6.539 secs
> (%o0)done
> 
>
> Sorry not to have a fix, as I am reporting many bugs similar to
> this one. The common hints are:
>
> * If the only architecture-independent packages are dummy transitional
> ones and they were released with jessie, the easy fix is to drop them
> now.
>
> * When using "dh", it is allowed to use (independently)
> optional targets override_dh_foo-arch and override_dh_foo-indep
> (for several values of "foo").
>
>
> Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
> properly, the package would be suitable to be uploaded in source-only
> form if you wish.
>
> Thanks.
>
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#817146: gdal-bin: ogr2ogr segfault

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Andy,

Upstream had already fixed the issue in trunk, and now also backported
the fix to the 2.0 branch which I've included as a patch in the Debian
package.

The new gdal package with the segfault fix will be uploaded to unstable
shortly.

Kind Regards,

Bas

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

Bug#744077: nm.debian.org: encoding problems in e-mail headers

[Ben Finney]

On 06-Mar-2016, efkin wrote:
> This should fix email headers that were not
> properly rendered.

Thank you, efkin, for making a patch.

I think that is addressing the problem in the wrong place.

The template tag should not do any encoding. Instead, it should just
do template interpolation, and return the Unicode text.

Encoding that text for transmission should be done only after the
whole message is composed.

So I think the correct solution entails:

* In ‘backend.templatetags.nm.formataddr’, remove the ‘encode’
  call.

* In ‘backend.email.send_notification’, encode all fields of the
  header (using ‘email.header.Header’ as you suggest).

-- 
 \  “The history of Western science confirms the aphorism that the |
  `\ great menace to progress is not ignorance but the illusion of |
_o__)knowledge.” —Daniel J. Boorstin, historian, 1914–2004 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#817205: Unable to load dynamic library '/usr/lib/php/20151012/zlib.so'

[積丹尼 Dan Jacobson]

Package: php-common
Version: 1:35

Now getting these:

Cron    [ -x /usr/lib/php/sessionclean ] && 
/usr/lib/php/sessionclean

says:

PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php/20151012/zlib.so' - /usr/lib/php/20151012/zlib.so: cannot open 
shared object file: No such file or directory in Unknown on line 0

Bug#817176: qgis install fails trying to overwrite /usr/bin/qbrowser.bin

[Sebastiaan Couwenberg]

severity 817176 serious
severity 817178 serious
tags 817176 confirmed
tags 817178 confirmed
merge 817176 817178
thanks

Hi Ben & Stefano,

Sorry for breaking the upgrade. Unfortunately my piuparts tests didn't
catch this issue.

On 08-03-16 19:56, Ben Caradoc-Davies wrote:
> Workaround is to manually remove the diversions:
> 
> dpkg-divert --remove /usr/bin/qgis
> dpkg-divert --remove /usr/bin/qbrowser
> 
> Note that this was an upgrade from the previous qgis on unstable.

The qgis.preinst maintainer script should remove the old diversions. It
was used pre-2.8 to support multiple GRASS versions. The new GRASS
support in post 2.8 doesn't need the diversions any more.

I'm currently trying to figure out why the removal of the diversions is
not working as expected, I hope to have a fix ready soon.

On Tue, 8 Mar 2016 19:48:35 +0100 (CET) Stefano Costa wrote:
> after the failed installation I'm left with this binary:
>
> steko@spheniscus:~$ ls -l /usr/bin/qgis.bin.dpkg-new
> -rwxr-xr-x 1 root root 250 mar 8 08:10 /usr/bin/qgis.bin.dpkg-new

The .dpkg-new files should go away after the upgrade succeeds, but you
need to either remove the diversion manually (with the above dpkg-divert
commands) and continue the upgrade, or wait for the fixed version.

Kind Regards,

Bas

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

Bug#817204: nm.debian.org: ‘django-housekeeping’ is now in Debian Stretch

[Ben Finney]

Package: nm.debian.org
Severity: normal
Control: tags -1 + patch

The code base's README document gives installation instructions. Those
instructions specify to get the ‘django-housekeeping’ package from a
GitHub repository.

Now that bug#748875 (“ITP: django-housekeeping -- Pluggable
housekeeping framework for Django sites.”) is resolved, and Debian
Stretch now has the ‘python-django-housekeeping’ package version
“1.0-1”, should the installation instructions for ‘nm2’ direct the
reader to that package?

If so, attached is a patch which makes that change.

-- 
 \ “I believe our future depends powerfully on how well we |
  `\ understand this cosmos, in which we float like a mote of dust |
_o__) in the morning sky.” —Carl Sagan, _Cosmos_, 1980 |
Ben Finney 
diff --git a/README.md b/README.md
index 5acda6e..cb39fe5 100644
--- a/README.md
+++ b/README.md
@@ -4,20 +4,9 @@ Debian NM Front Desk web application
 ## Running this code on your own machine
 ### Dependencies
 
-apt-get install python-django python-ldap python-psycopg2 python-xapian \
- python-debian python-django-south python-markdown \
- python-debiancontributors
-
-# https://github.com/spanezz/django-housekeeping
-git clone https://github.com/spanezz/django-housekeeping
-  (you can either build the package from it or symlink the module directory
-  into the contributors.debian.org sources)
-
-# build the package
-fakeroot debian/rules clean binary
-
-# install the package
-dpkg -i  ../python-django-housekeeping_0.1-1_all.deb
+apt-get install python-markdown python-ldap python-psycopg2 python-xapian \
+ python-django python-django-south python-django-housekeeping \
+ python-debian python-debiancontributors
 
 # https://github.com/jsocol/django-ratelimit
 git clone https://github.com/jsocol/django-ratelimit.git


signature.asc
Description: PGP signature

Bug#817203: ITP: libplack-middleware-logany-perl -- use Log::Any to handle logging from your Plack app

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libplack-middleware-logany-perl
  Version : 0.001
  Upstream Author : Michael Alan Dorman 
* URL : https://metacpan.org/pod/Plack::Middleware::LogAny
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : use Log::Any to handle logging from your Plack app

 Plack::Middleware::LogAny  is a Plack::Middleware component that allows
 you to use Log::Any to handle the logging object, psgix.logger.
 .
 It really tries to be the thinnest possible shim, so it doesn't handle
 any configuration beyond setting the category to which messages from
 plack might be logged.
 .
 Plack is a set of tools similar to Ruby's Rack or Python's Paste for
 WSGI. It implements the Perl Server Gateway Interface (PSGI) standard
 interface, which allows developers to decouple their web application
 framework from the local web server environment.

The package will be maintained in the Debian Perl team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW32BuAAoJECx8MUbBoAEh/s8P/Aw5aKMCHRulTSt2ut7M1HVn
PKV9n/8MuFFKvgxqLpY9E58vNycW1CrHUNdSlexdeOW4RzE66u64HM73xSbQyxvB
L8XJ/QnDOVPnocBUWjAVTbDAHuNp8ADQ8XYGclZY++N6NYpaWtjsXX6IdOqJdL7B
nRWakrmGdC0QYmgmF9epIGgXvUZ5lKzviX3iOtTpRIRiiP5MwUlaSg4UkI1EZQaM
I+U745FedNMMbeDoU/w0PmDQS/C/rXdPmBBdlutXOipNfbprRRw4Q1qXAV1/w9yS
YwwzBZ8O5PHvpsGF7JCBmqKL+sLIR8lNXYSFYMgEQLj4K2kCZv2OT8hbjdE2cPwX
RpjgjSaBEq7Km0L+p1lfPLUlmw9k7LaHV+tiC3wgKYwudSmr139VkplpaHiZrcq9
Cp1eInyLQ2RoVVybUTlcXM3Wh4OWwOLtd8sV+uE3cIlCBVSYTPVJsv6y2nhlux1P
whRrxswPX41HF5ADepczEXetN5JfLPffiB6qLwDU1aWAebkm7ee9OQhcqNdzs3jr
tGkCy66TQdOUvIsyl4fHnlz0ZlSrcsZFzcMXKEWPAkXtnVKRSjTln37ceJjC9f/z
Yzx/Mqi9x6qfUo20MQLBOSPv+OXn+3vHeFqDm2JOIEzS3IcA+1Y0p7SC/giWzPM5
YINmilwtaaC0q/z5bXVR
=vTMh
-END PGP SIGNATURE-

Bug#817202: zlib.ini causes: unable to delete old directory '/etc/php/mods-available': Directory not empty

[積丹尼 Dan Jacobson]

Package: php-common
Version: 1:35

Unpacking php-common (1:35) over (1:7.0+32) ...
dpkg: warning: unable to delete old directory '/etc/php/mods-available': 
Directory not empty
Preparing to unpack .../php-cli_1%3a7.0+35_all.deb ...

$ ls -Rl /etc/php/mods-available
/etc/php/mods-available:
total 4
-rw-r--r-- 1 root root 70 02-26 19:38 zlib.ini

Bug#803829: kino: diff for NMU version 1.3.4-2.2

[Sebastian Ramacher]

Control: tags 803829 + pending

Dear maintainer,

I've prepared an NMU for kino (versioned as 1.3.4-2.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
Sebastian Ramacher
diff -u kino-1.3.4/debian/changelog kino-1.3.4/debian/changelog
--- kino-1.3.4/debian/changelog
+++ kino-1.3.4/debian/changelog
@@ -1,3 +1,12 @@
+kino (1.3.4-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Andreas Cadhalpun ]
+  * Fix build against ffmpeg 3.0. (Closes: #803829)
+
+ -- Sebastian Ramacher   Wed, 09 Mar 2016 00:09:24 +0100
+
 kino (1.3.4-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u kino-1.3.4/debian/patches/series kino-1.3.4/debian/patches/series
--- kino-1.3.4/debian/patches/series
+++ kino-1.3.4/debian/patches/series
@@ -7,0 +8 @@
+ffmpeg_2.9.patch
only in patch2:
unchanged:
--- kino-1.3.4.orig/debian/patches/ffmpeg_2.9.patch
+++ kino-1.3.4/debian/patches/ffmpeg_2.9.patch
@@ -0,0 +1,166 @@
+Description: Replace deprecated FFmpeg API
+Author: Andreas Cadhalpun 
+Last-Update: <2015-11-02>
+
+--- 1.3.4.orig/src/frame.cc
 1.3.4/src/frame.cc
+@@ -57,7 +57,7 @@ using std::endl;
+ #include "preferences.h"
+ 
+ #if LIBAVUTIL_VERSION_INT >= (50<<16)
+-#define PIX_FMT_YUV422 PIX_FMT_YUYV422
++#define AV_PIX_FMT_YUV422 AV_PIX_FMT_YUYV422
+ #endif
+ 
+ 
+@@ -1059,7 +1059,7 @@ void Frame::ExtractHeader( void )
+ int Frame::ExtractRGB( void * rgb )
+ {
+ #if defined(HAVE_LIBAVCODEC)
+-	AVFrame *frame = avcodec_alloc_frame();
++	AVFrame *frame = av_frame_alloc();
+ 	AVPicture dest;
+ 	int got_picture;
+ 
+@@ -1071,17 +1071,17 @@ int Frame::ExtractRGB( void * rgb )
+ 	avcodec_decode_video2( libavcodec, frame, _picture,  );
+ 	if ( got_picture )
+ 	{
+-		avpicture_fill( , static_cast( rgb ), PIX_FMT_RGB24, GetWidth(), GetHeight() );
++		avpicture_fill( , static_cast( rgb ), AV_PIX_FMT_RGB24, GetWidth(), GetHeight() );
+ #if defined(HAVE_SWSCALE)
+ 		if ( !imgConvertRgbCtx )
+ 			imgConvertRgbCtx = sws_getContext( libavcodec->width, libavcodec->height, libavcodec->pix_fmt,
+-GetWidth(), GetHeight(), PIX_FMT_RGB24, SWS_FAST_BILINEAR, NULL, NULL, NULL );
++GetWidth(), GetHeight(), AV_PIX_FMT_RGB24, SWS_FAST_BILINEAR, NULL, NULL, NULL );
+ 		sws_scale( imgConvertRgbCtx, frame->data, frame->linesize, 0, libavcodec->height, dest.data, dest.linesize );
+ #else
+-		img_convert( , PIX_FMT_RGB24, reinterpret_cast( frame ), libavcodec->pix_fmt, GetWidth(), GetHeight() );
++		img_convert( , AV_PIX_FMT_RGB24, reinterpret_cast( frame ), libavcodec->pix_fmt, GetWidth(), GetHeight() );
+ #endif
+ 	}
+-	av_free( frame );
++	av_frame_free(  );
+ #else
+ 	unsigned char *pixels[ 3 ];
+ 	int pitches[ 3 ];
+@@ -1124,7 +1124,7 @@ int Frame::ExtractPreviewRGB( void *rgb )
+ int Frame::ExtractYUV( void *yuv )
+ {
+ #if defined(HAVE_LIBAVCODEC)
+-	AVFrame *frame = avcodec_alloc_frame();;
++	AVFrame *frame = av_frame_alloc();;
+ 	AVPicture output;
+ 	int got_picture;
+ 
+@@ -1136,17 +1136,17 @@ int Frame::ExtractYUV( void *yuv )
+ 	avcodec_decode_video2( libavcodec, frame, _picture,  );
+ 	if ( got_picture )
+ 	{
+-		avpicture_fill( , static_cast( yuv ), PIX_FMT_YUV422, GetWidth(), GetHeight() );
++		avpicture_fill( , static_cast( yuv ), AV_PIX_FMT_YUV422, GetWidth(), GetHeight() );
+ #if defined(HAVE_SWSCALE)
+ 		if ( !imgConvertYuvCtx )
+ 			imgConvertYuvCtx = sws_getContext( libavcodec->width, libavcodec->height, libavcodec->pix_fmt,
+-GetWidth(), GetHeight(), PIX_FMT_YUV422, SWS_FAST_BILINEAR, NULL, NULL, NULL );
++GetWidth(), GetHeight(), AV_PIX_FMT_YUV422, SWS_FAST_BILINEAR, NULL, NULL, NULL );
+ 		sws_scale( imgConvertYuvCtx, frame->data, frame->linesize, 0, libavcodec->height, output.data, output.linesize );
+ #else
+-		img_convert( , PIX_FMT_YUV422, (AVPicture *)frame, libavcodec->pix_fmt, GetWidth(), GetHeight() );
++		img_convert( , AV_PIX_FMT_YUV422, (AVPicture *)frame, libavcodec->pix_fmt, GetWidth(), GetHeight() );
+ #endif
+ 	}
+-	av_free( frame );
++	av_frame_free(  );
+ #else
+ 	unsigned char *pixels[ 3 ];
+ 	int pitches[ 3 ];
+@@ -1163,7 +1163,7 @@ int Frame::ExtractYUV( void *yuv )
+ int Frame::ExtractYUV420( uint8_t *yuv, uint8_t *output[ 3 ] )
+ {
+ #if defined(HAVE_LIBAVCODEC)
+-	AVFrame *frame = avcodec_alloc_frame();
++	AVFrame *frame = av_frame_alloc();
+ 	int got_picture;
+ 
+ 	AVPacket pkt;
+@@ -1175,7 +1175,7 @@ int Frame::ExtractYUV420( uint8_t *yuv, uint8_t *output[ 3 ] )
+ 
+ 	int width = GetWidth(), height = GetHeight();
+ 
+-	if ( libavcodec->pix_fmt == PIX_FMT_YUV420P )   // PAL
++	if ( libavcodec->pix_fmt == AV_PIX_FMT_YUV420P )   // PAL
+ 	{
+ 		int h2 = height / 2;
+ 		int w2 = width / 2;
+@@ -1203,7 +1203,7 @@ int Frame::ExtractYUV420( uint8_t *yuv, uint8_t *output[ 3 ] )
+ 			}
+ 		}
+ 	}
+-	else // libavcodec.pix_fmt == PIX_FMT_YUV411P // NTSC
++	else // libavcodec.pix_fmt == 

Bug#817191: bugs.debian.org: Version pseudoheader ignored

[Jakub Wilk]

* Colin Watson , 2016-03-08, 22:46:

On Tue, Mar 08, 2016 at 10:17:12PM +0100, Jakub Wilk wrote:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817128#23 is a 
message sent to -done with Version pseudoheader. The bug was closed, 
but fixed version wasn't recorded. (Maybe it's because the message is 
multi-part?)


IIRC Version is only honoured if there's also a Package or Source 
pseudo-header.


Hmm, I've never seen lone Version fail to work before.
Latest example were I saw it did the job is #772705.

--
Jakub Wilk

Bug#817201: gnukhata-core-engine: wrong section: should be in utils (not python)

[Jonas Smedegaard]

Package: gnukhata-core-engine
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The package section python is for python libraries, not anything written
in python.

(yes, hledger is also in wrong section but) similar to ledger it should
be in section utils.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW31o4AAoJECx8MUbBoAEhPDsP/R44bfL3txk2/VPInIZWoIbT
MAo62tkH3Yov0ApVepKB0JQzmS+qbHvACM2UAvkf6z7Nk/aNOE+bov5mphYbAvmj
3n1IQFB7UBjDQ/NHY+bOP7ukEQu/DQj4SQTljR0joAgCrJ+VcJUpqJFUpt3Oys2g
EOX4dVVpxOa+GLNRYko+lWeaa7uYZXl5YFTYP+NVZ/FwF4R7laiplOEJwpRK6iRZ
HaBW44UsZ4KY0msEXxhUUKvOvhWzZNA/5OvdSN0jJdgZgoQX0GMMdA5f166YwXVx
+JbzuG+Y2AMpu18eoucdDVVttAA1r2ARpeQChw/CT9+5ADTzIzXfD5ljEZRWefge
1oeMZUkOkrkJxzCxdRNyyBCYGV42Qi7trfA5f4YAWEgdXJI5x8zlbLLmLvWf0VCF
ntkUCKvpJ0VWsox1vi7mbQdgC3IRN6/YXgCcQuuO1jNNs2QfDO4a5/j3zIsJcKfa
rvp2mf+1kVaXmXgojgH88NMk8y3zsbuiY/K3JdaqWltDQZ56ANK/f2UM3cUfnxrL
xmeJKb6UArq3nfjr0e3aWA35E5kEGY+7wSA6O8AFxzeE7/oVDp1+reGt+XFGzjXu
BY6lF7JHn1HFE2MWqJM3rTUiSw/NGpgYRdbpRInuk1zD7JowMMXpVGYHH9Fwz3H+
9IA1JRWaDJngillU7Wfb
=//fU
-END PGP SIGNATURE-

Bug#803837: lightspark: diff for NMU version 0.7.2+git20150512-2.1

[Sebastian Ramacher]

Control: tags 803837 + pending

Dear maintainer,

I've prepared an NMU for lightspark (versioned as 0.7.2+git20150512-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
Sebastian Ramacher
diff -Nru lightspark-0.7.2+git20150512/debian/changelog lightspark-0.7.2+git20150512/debian/changelog
--- lightspark-0.7.2+git20150512/debian/changelog	2015-07-15 17:21:27.0 +0200
+++ lightspark-0.7.2+git20150512/debian/changelog	2016-03-08 23:54:01.0 +0100
@@ -1,3 +1,12 @@
+lightspark (0.7.2+git20150512-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Andreas Cadhalpun ]
+  * Fix build with ffmpeg 3.0. (Closes: #803837)
+
+ -- Sebastian Ramacher   Tue, 08 Mar 2016 23:54:00 +0100
+
 lightspark (0.7.2+git20150512-2) unstable; urgency=medium
 
   * Run dpkg-vendor at build time (Closes: #790807).
diff -Nru lightspark-0.7.2+git20150512/debian/patches/ffmpeg_2.9.patch lightspark-0.7.2+git20150512/debian/patches/ffmpeg_2.9.patch
--- lightspark-0.7.2+git20150512/debian/patches/ffmpeg_2.9.patch	1970-01-01 01:00:00.0 +0100
+++ lightspark-0.7.2+git20150512/debian/patches/ffmpeg_2.9.patch	2016-03-08 23:53:29.0 +0100
@@ -0,0 +1,105 @@
+Description: Replace deprecated FFmpeg API
+Author: Andreas Cadhalpun 
+Last-Update: <2015-11-02>
+
+--- lightspark-0.7.2+git20150512.orig/src/backends/decoder.cpp
 lightspark-0.7.2+git20150512/src/backends/decoder.cpp
+@@ -166,7 +166,7 @@ FFMpegVideoDecoder::FFMpegVideoDecoder(L
+ 	else
+ 		status=INIT;
+ 
+-	frameIn=avcodec_alloc_frame();
++	frameIn=av_frame_alloc();
+ }
+ 
+ FFMpegVideoDecoder::FFMpegVideoDecoder(AVCodecContext* _c, double frameRateHint):
+@@ -201,7 +201,7 @@ FFMpegVideoDecoder::FFMpegVideoDecoder(A
+ 	if(fillDataAndCheckValidity())
+ 		status=VALID;
+ 
+-	frameIn=avcodec_alloc_frame();
++	frameIn=av_frame_alloc();
+ }
+ 
+ FFMpegVideoDecoder::~FFMpegVideoDecoder()
+@@ -210,7 +210,7 @@ FFMpegVideoDecoder::~FFMpegVideoDecoder(
+ 	avcodec_close(codecContext);
+ 	if(ownedContext)
+ 		av_free(codecContext);
+-	av_free(frameIn);
++	av_frame_free();
+ }
+ 
+ //setSize is called from the routine that inserts new frames
+@@ -274,7 +274,7 @@ bool FFMpegVideoDecoder::decodeData(uint
+ 	assert_and_throw(ret==(int)datalen);
+ 	if(frameOk)
+ 	{
+-		assert(codecContext->pix_fmt==PIX_FMT_YUV420P);
++		assert(codecContext->pix_fmt==AV_PIX_FMT_YUV420P);
+ 
+ 		if(status==INIT && fillDataAndCheckValidity())
+ 			status=VALID;
+@@ -301,7 +301,7 @@ bool FFMpegVideoDecoder::decodePacket(AV
+ 	assert_and_throw(ret==(int)pkt->size);
+ 	if(frameOk)
+ 	{
+-		assert(codecContext->pix_fmt==PIX_FMT_YUV420P);
++		assert(codecContext->pix_fmt==AV_PIX_FMT_YUV420P);
+ 
+ 		if(status==INIT && fillDataAndCheckValidity())
+ 			status=VALID;
+@@ -476,7 +476,7 @@ FFMpegAudioDecoder::FFMpegAudioDecoder(L
+ 	else
+ 		status=INIT;
+ #if HAVE_AVCODEC_DECODE_AUDIO4
+-	frameIn=avcodec_alloc_frame();
++	frameIn=av_frame_alloc();
+ #endif
+ }
+ 
+@@ -502,7 +502,7 @@ FFMpegAudioDecoder::FFMpegAudioDecoder(L
+ 	if(fillDataAndCheckValidity())
+ 		status=VALID;
+ #if HAVE_AVCODEC_DECODE_AUDIO4
+-	frameIn=avcodec_alloc_frame();
++	frameIn=av_frame_alloc();
+ #endif
+ }
+ 
+@@ -522,7 +522,7 @@ FFMpegAudioDecoder::FFMpegAudioDecoder(A
+ 	if(fillDataAndCheckValidity())
+ 		status=VALID;
+ #if HAVE_AVCODEC_DECODE_AUDIO4
+-	frameIn=avcodec_alloc_frame();
++	frameIn=av_frame_alloc();
+ #endif
+ }
+ 
+@@ -532,7 +532,7 @@ FFMpegAudioDecoder::~FFMpegAudioDecoder(
+ 	if(ownedContext)
+ 		av_free(codecContext);
+ #if HAVE_AVCODEC_DECODE_AUDIO4
+-	av_free(frameIn);
++	av_frame_free();
+ #endif
+ }
+ 
+@@ -607,7 +607,7 @@ uint32_t FFMpegAudioDecoder::decodeData(
+ 	}
+ 
+ #if HAVE_AVCODEC_DECODE_AUDIO4
+-	avcodec_get_frame_defaults(frameIn);
++	av_frame_unref(frameIn);
+ 	int frameOk=0;
+ 	int32_t ret=avcodec_decode_audio4(codecContext, frameIn, , );
+ 	if(frameOk==0)
+@@ -664,7 +664,7 @@ uint32_t FFMpegAudioDecoder::decodePacke
+ 	int maxLen=AVCODEC_MAX_AUDIO_FRAME_SIZE;
+ 
+ #if HAVE_AVCODEC_DECODE_AUDIO4
+-	avcodec_get_frame_defaults(frameIn);
++	av_frame_unref(frameIn);
+ 	int frameOk=0;
+ 	int ret=avcodec_decode_audio4(codecContext, frameIn, , pkt);
+ 	if(frameOk==0)
diff -Nru lightspark-0.7.2+git20150512/debian/patches/series lightspark-0.7.2+git20150512/debian/patches/series
--- lightspark-0.7.2+git20150512/debian/patches/series	2015-07-15 17:21:27.0 +0200
+++ lightspark-0.7.2+git20150512/debian/patches/series	2016-03-08 23:53:29.0 +0100
@@ -3,3 +3,4 @@
 #fix-for-llvm35.patch
 #libav10.patch
 assert.patch
+ffmpeg_2.9.patch


signature.asc
Description: PGP signature

Bug#814883: lcms2: please add a way for clients to set the creation date/time in profile headers

[Thomas Weber]

Hi, 

On Tue, Feb 16, 2016 at 11:03:00AM +0100, Jérémy Bobbio wrote:
> Package: liblcms2-dev
> Version: 2.6-3
> Severity: wishlist
> Tag: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps toolchain
> 
> Hi!
> 
> liblcms will currently always use the current time to set the creation
> time in profile headers. In the context of the “Reproducible Builds”
> effort [1], this will prevent colord from building its profiles
> bit-for-bit identical, despite having the exact same source.
> 
> The attached patch adds cmsSetHeaderCreationDateTime() to allow clients
> to set an explicit creation date/time for a profile.

I am reluctant to change the API of lcms2 (mostly I am worried that
upstream or other distributions might choose a different way). So, I
will be sending this to upstream first and try to get it included there.

Thanks
Thomas

Bug#798530: [aptitude] safe-upgrade is marking packages as manually installed

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Jon,

2015-09-10 11:23 Jon Ander Peñalba:


Some packages are being marked as manually installed after running
'aptitude safe-upgrade', is this normal behavior?


No, it's not.

There have been several cases of these problems of missing auto-flags
being fixed in the last few versions.

Would you be able to upgrade to version 0.7.8, test it for a while, and
verify if you keep seeing the same type of behaviour?

If you keep seeing the behaviour, please tell me a clear test case as
you did in the original report (thanks for that!).


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#817191: bugs.debian.org: Version pseudoheader ignored

[Colin Watson]

On Tue, Mar 08, 2016 at 10:17:12PM +0100, Jakub Wilk wrote:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817128#23 is a message
> sent to -done with Version pseudoheader. The bug was closed, but fixed
> version wasn't recorded. (Maybe it's because the message is multi-part?)

IIRC Version is only honoured if there's also a Package or Source
pseudo-header.  (It can be a little difficult to work out what to do in
some edge cases otherwise.)

-- 
Colin Watson   [cjwat...@debian.org]

Bug#817199: transcode: should this package be removed?

[Sebastian Ramacher]

Package: transcode
Version: 3:1.1.7-9
Severity: serious
Tags: sid stretch

transcode is dead upstream since many years and it is also no longer really
maintained Debian. We just keep sticking patches on top of it. I suppose most of
its use-cases are also covered by other tools already available in Debian. Also,
support for modern containers like mp4 is still very limited. So I think it's
time to let it go.

What do you think?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#817200: RFA: yt -- Framework for analyzing and visualizing simulation data

[Kacper Kowalik]

Package: wnpp
X-Debbugs-CC: debian-as...@lists.debian.org, debian-de...@lists.debian.org

As per my mail to yt-dev mailing list:

http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2016-March/019977.html

I no longer have resources to keep maintaining this package. I hope new 
maintainer will step up soon.


Cheers,
Kacper

Bug#653284: unreasonable "Do not install"

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Harri,

2011-12-26 13:01 Harald Dunkel:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: aptitude
Version: 0.6.4-1.2

If I try to install a single package "A" using

aptitude update
aptitude upgrade
aptitude install A

and run into a conflict with already installed packages,
then aptitude shows me several optional configurations to
resolve the conflict.

But why does it show me so many different package configu-
rations adding and removing tons of other packages, _not_
touching A's current state ("Not Installed")?


I don't know if I understand very well what you say, because the subject
seems to contradict what I understand from the above (would be more
like: "Unreasonable try-too-hard-to-install rather than keep requested
uninstalled").

In general, I think that the bug is not very actionable as it is.


For example, from your example above, you might want to install
A=awesome-media-player-ng that conflicts with awesome-media-player.  So
aptitude, seeing that you want the new awesome-media-player-ng
installed, it offers several solutions, including possibly removing tons
of libraries or upggrading them, to try to keep you happy.

After searching for a while to try to satisfy your request, maybe it
decides that upgrading some libraries is better than not touching them
at all, even if your request cannot be granted, because in the
calculations about costs and benefits it thinks that there's a net gain
in going ahead with the given solution.  The solutions might be
unintuitive, because maybe it reaches the conclusion that upgrading 3 is
not worth it (ranks worse than some other solution), but upgrading 6 is
good because it's just over a point higher than the next solution.

I think that the nature of the resolver leads to these "open solutions"
when anything can be valid or not, depending on the specific case.

If the system has multi-arch enabled, or you mix several of
stable/testing/unstable/experimental, and there are ongoing library
transitions involved in the conflicts, and depending on the pinning and
all that, the situation becomes very unwieldy and difficult to reason
about very quickly.  The suggestions that it gives can be very stupid
sometimes.


After reading hundreds of bug reports and seeing these cases mentioned
more than once, the reason why it tries very hard to install what you
requested is (according to the original developer) because it assumes
that you know what you are doing and that you really want to install it,
and it doesn't know if the packages that conflict and have to be removed
are more important to you or not that the one that you want to install,
or if your new package is worth 3 removals that you don't care about,
but not 1 removal which you do care about.  Sometimes, even the one that
you requested can be uninstallable, but aptitude keeps trying to give
suggestions.

Not having delved at all in the mysterious inner mechanisms about how
aptitude resolver works [*], I think that this is because it reaches a
partial solution where some packages need to be
upgraded/removed/whatever, then it decides that A cannot be installed
anyway, so the solution in the end is to suggest to upgrade or remove a
bunch of packages even if the one that you requested cannot be
installed, because they rank better than what one would expect that it
would be the default solution (not touching any package).  Maybe the
should-be-default ranks lower than the others because it was given a big
negative score for not honouring your request.

 [*] and it did change a lot during the years where the original
 developer was active, so maybe the explanation that he gave in a
 bug in 2007 about why the resolver works in one way was invalid by
 the next release
 


There might be several causes underlying this.  There are still bugs
currently open about aptitude not trying hard enough to do what the user
requests (and there were others closed in the past), so maybe the
original developer pushed too far in this direction because of users
requesting this insistently.  Changing this behaviour by now is always
risky, because it can trigger another set of problems that could be
worse than the current ones.

Similar case is the one commented that maybe once the resolver kicks in,
it reaches the conclusion that upgrading packages (even if A is not
touched) is a net positive because upgrades are sanctioned as "good",
for example, so they rank better in the solutions (with the default
costs) that not doing anything at all.  Tweaking the resolver costs to
change this behaviour is also tricky for the same reasons.

Another reason might be that simply there's a bug (or many!), but for
that we need to have a clear example of packages where this happens, and
then have somebody brave enough to dive into the abyss.

That's why I think that the bug as it is is not very actionable.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#817198: libpam-script: Segv crash with NULL pointer in pam_sm_chauthtok with bad input

[Dave Olson]

Package: libpam-script
Version: 1.1.7-1
Severity: important

Dear Maintainer,

When passed an incorrect password on stdin, the passwd program crashes
in libpam-script when libpam-script is not configured (that is,
installed, but no configuration has been done).

Here is a simple way to reproduce it.  The gdb session comes from
re-building libpam-script leaving symbols.  The crash is the same
in the standard package.  This was seen when running as root.  Presumably
would happen for a normal user with the original passwd supplied.

It would appear that the validity of the password variable is not checked.

#  /bin/echo -e 'cn321\\ncn321' > /tmp/d  # (note the extra backslash)

# gdb -q /usr/bin/passwd
Reading symbols from /usr/bin/passwd...(no debugging symbols found)...done.
(gdb) r < /tmp/d
Starting program: /usr/bin/passwd < /tmp/d
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
New password: New password (again): 
Program received signal SIGSEGV, Segmentation fault.
__strcmp_sse2 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210
210 ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory.
(gdb) bt
#0  __strcmp_sse2 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210
#1  0x7f8e3a5979b9 in pam_sm_chauthtok (pamh=0x7f8e3cc5f2a0, flags=8192, 
argc=0, 
argv=0x7f8e3cc5fad0) at pam_script.c:392
#2  0x7f8e3b823f8f in ?? () from /lib/x86_64-linux-gnu/libpam.so.0
#3  0x7f8e3b828513 in pam_chauthtok () from 
/lib/x86_64-linux-gnu/libpam.so.0
#4  0x7f8e3bc58032 in ?? ()
#5  0x7f8e3bc56c08 in ?? ()
#6  0x7f8e3ae4ab45 in __libc_start_main (main=0x7f8e3bc56160, argc=1, 
argv=0x7ffd654951a8, init=, fini=, 
rtld_fini=, stack_end=0x7ffd65495198) at libc-start.c:287
#7  0x7f8e3bc57028 in ?? ()
(gdb) up
#1  0x7f8e3a5979b9 in pam_sm_chauthtok (pamh=0x7f8e3cc5f2a0, flags=8192, 
argc=0, 
argv=0x7f8e3cc5fad0) at pam_script.c:392
392 if (strcmp(new_password, password)) {
(gdb) l
387 if (retval != PAM_SUCCESS)
388 return retval;
389 pam_get_item(pamh, PAM_AUTHTOK, (void*) );
390 
391 /*  Check if new password's are the same */
392 if (strcmp(new_password, password)) {
393 retval = pam_script_senderr(pamh, flags, argc, argv,
394 "You must enter the same password twice.");
395 if (retval != PAM_SUCCESS)
396 return retval;
(gdb) p password
$1 = 0x0
(gdb) p new_password
$2 = "cn321\\ncn321", '\000' 


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/40 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: systemd (via /run/systemd/system)

Bug#817057: network-manager-openconnect: Update unstable version to latest Upstream Build

[Mike Miller]

Control: severity -1 important

On Tue, Mar 08, 2016 at 08:04:42 +0100, Michael Stapelberg wrote:
> Thanks for clarifying the issue you’re seeing. I don’t think this is
> related to the D-Bus changes.
> 
> Also, to be clear: I’m not the maintainer of this package, I sponsored
> mtmiller@’s uploads, who maintains the package.

Thanks for responding for me ;)

Yikes, out of order quoting:

> On Tue, Mar 8, 2016 at 3:09 AM, Ryan Chewning  wrote:
> > On Mon, Mar 7, 2016 at 12:22 PM, Michael Stapelberg  >>>
> >>> The latest builds of networkmanager in testing/unstable no longer
> >>> support dbus. https://blogs.gnome.org/dcbw/2016/02/19/die-dbus-glib-die/
> >>>
> >>
> >> I’m only a bystander for the purpose of this bug, but “networkmanager […]
> >> no longer supports dbus” conflicts with the article you refer to, which
> >> mentions:
> >>
> >> """
> >> I cannot understate how much work this was and how much careful planning
> >> we (well, mostly Dan Winship) did to ensure we didn’t break backwards
> >> compatibility of either the utility libraries or the D-Bus interface.
> >> """
> >>
> >> The way I read this, the new networkmanager version is
> >> backwards-compatible with regards to its D-Bus interface.
> >>
> >> Can you clarify? If it turns out that it’s actually backwards-compatible,
> >> is severity: grave still justified?

My understanding is that it is backwards-compatible (e.g. I am still
able to connect via nm-openconnect on my system). However, they do seem
to have dropped support for old-style plugins in the
nm-connection-editor, possibly nm-applet. I use gnome-shell which still
allows me to create, edit, and connect to OpenConnect VPNs perfectly.

I'm downgrading to important. Request for a new version would normally
be wishlist. This package is still mostly working for users with
existing VPNs or who use gnome-shell or manage VPNs with keyfiles
manually, but not for nm-applet users.

> >>> There is an updated version of the network-manager-openconnect but it is
> >>> failing to be pulled down by uscan. Manual intervention is needed.

JFTR, manual intervention is always required. I don't know why the
tracker and udd are reporting upstream failures, uscan works locally for
me, but that's a separate issue (if I understand what you meant).

-- 
mike

Bug#803862: strigi: diff for NMU version 0.7.8-2.1

[Sebastian Ramacher]

Control: tags 803862 + pending

Dear maintainer,

I've prepared an NMU for strigi (versioned as 0.7.8-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
Sebastian Ramacher
diff -Nru strigi-0.7.8/debian/changelog strigi-0.7.8/debian/changelog
--- strigi-0.7.8/debian/changelog	2015-08-07 18:33:38.0 +0200
+++ strigi-0.7.8/debian/changelog	2016-03-08 23:26:15.0 +0100
@@ -1,3 +1,12 @@
+strigi (0.7.8-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Andreas Cadhalpun ]
+  * Fix build against ffmpeg 3.0. (Closes: #803862)
+
+ -- Sebastian Ramacher   Tue, 08 Mar 2016 23:23:53 +0100
+
 strigi (0.7.8-2) unstable; urgency=medium
 
   * Rename lib packages to their v5 version (gcc5 transition).
diff -Nru strigi-0.7.8/debian/patches/ffmpeg_2.9.patch strigi-0.7.8/debian/patches/ffmpeg_2.9.patch
--- strigi-0.7.8/debian/patches/ffmpeg_2.9.patch	1970-01-01 01:00:00.0 +0100
+++ strigi-0.7.8/debian/patches/ffmpeg_2.9.patch	2016-03-08 23:23:16.0 +0100
@@ -0,0 +1,35 @@
+Description: Replace deprecated FFmpeg API
+Author: Andreas Cadhalpun 
+Last-Update: <2015-11-02>
+
+--- strigi-0.7.8.orig/libstreamanalyzer/plugins/endplugins/ffmpegendanalyzer.cpp
 strigi-0.7.8/libstreamanalyzer/plugins/endplugins/ffmpegendanalyzer.cpp
+@@ -355,7 +355,7 @@ FFMPEGEndAnalyzer::analyze(AnalysisResul
+ #endif
+ 
+   if(fc->bit_rate)
+-ar.addValue(factory->bitrateProperty, fc->bit_rate);
++ar.addValue(factory->bitrateProperty, (uint32_t)fc->bit_rate);
+   else if (fc->duration!= no_bitrate && fc->duration > 0) {
+ cout<<"Trying to estimate bitrate\n";
+ int64_t size;
+@@ -412,8 +412,8 @@ FFMPEGEndAnalyzer::analyze(AnalysisResul
+ if (size_t len = strlen(p->name)) {
+   ar.addTriplet(streamuri, codecPropertyName, string(p->name, len));
+ }
+-  } else if (size_t len = strlen(codec.codec_name)) {
+-ar.addTriplet(streamuri, codecPropertyName, string(codec.codec_name, len));
++  } else if (size_t len = strlen(avcodec_get_name(codec.codec_id))) {
++ar.addTriplet(streamuri, codecPropertyName, string(avcodec_get_name(codec.codec_id), len));
+   }
+ /*
+ 00792 } else if (enc->codec_id == CODEC_ID_MPEG2TS) {
+@@ -486,7 +486,7 @@ FFMPEGEndAnalyzer::analyze(AnalysisResul
+   outs << stream.avg_frame_rate.num / stream.avg_frame_rate.den;
+   ar.addTriplet(streamuri, frameRatePropertyName, outs.str());
+ }
+-if (codec.pix_fmt != PIX_FMT_NONE) {}//FIXME pixel format
++if (codec.pix_fmt != AV_PIX_FMT_NONE) {}//FIXME pixel format
+   }
+   
+ }
diff -Nru strigi-0.7.8/debian/patches/series strigi-0.7.8/debian/patches/series
--- strigi-0.7.8/debian/patches/series	2015-08-07 18:33:38.0 +0200
+++ strigi-0.7.8/debian/patches/series	2016-03-08 23:23:16.0 +0100
@@ -1,2 +1,3 @@
 deepgrep_mayhem_fix.diff
 libav10.patch
+ffmpeg_2.9.patch


signature.asc
Description: PGP signature

Bug#794326: Fixed has been verified on ubuntu xenial 16.04

[Yangzheng Bai]

https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1552939
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Bug#817166: pinba-engine-mysql: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Vincent Bernat]

 ❦  8 mars 2016 16:52 GMT, Santiago Vila  :

> # Install MySQL engine into the right directory. Get rid of unwanted files
> chrpath -d debian/pinba-engine-mysql-5.6/libpinba_engine.so.0.0.0
> open: No such file or directory
> elf_open: Invalid argument
> debian/rules:27: recipe for target 'override_dh_install' failed
> make[1]: *** [override_dh_install] Error 1
> make[1]: Leaving directory '/<>'
> debian/rules:14: recipe for target 'binary-indep' failed
> make: *** [binary-indep] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
> status 2
> 

Seems easy to fix. I'll upload soon.
-- 
By trying we can easily learn to endure adversity.  Another man's, I mean.
-- Mark Twain


signature.asc
Description: PGP signature

Bug#817197: ITP: vhostmd -- Virtualisation host metrics daemon

[Michael-John Turner]

Package: wnpp
Severity: wishlist
Owner: Michael-John Turner 

* Package name: vhostmd
  Version : 0.4
  Upstream Author : Jim Fehlig 
* URL : https://gitorious.org/vhostmd/vhostmd/
* License : GPL
  Programming Lang: C
  Description : Virtualisation host metrics daemon

Daemon vhostmd provides a "metrics communication channel" between a host
and its hosted virtual machines, allowing limited introspection of host
resource usage from within virtual machines.

vhostmd is useful for virtualisation hosts to monitor metrics within
guests - it supports both KVM and Xen. The daemon is available as
standard in RHEL and SUSE, amongst others.

I'm a former DD (mj@d.o) looking to reapply for DD status so would need a
sponsor.

Bug#719624: Upgrading xrdp

[Dominik George]

Hi,

> 
> On Tue, Mar 08, 2016 at 06:59:32PM +0100, Dominik George wrote:
> > most of your concerns are being addressed already (restoring history and
> > such).
> The current master branch of the repository you named[1] starts with
> 
> 
> xrdp (0.9.0~git20150318-1~alpha1) teckids; urgency=medium
> 
>   * New upstream git snapshot
>   * Document legal issues at https://github.com/neutrinolabs/xrdp/issues/232
> 
>  -- Thorsten Glaser   Wed, 18 Mar 2015 21:22:35
> +0100
> 
> 
> which contradicts your statement.

No, it doesn't. You simply need a grammar book - I said your concerns „are 
being addressed“, not „have already been addressed“.

I have a list of tasks to do on the package, which includes both your issues 1 
and 1, so…

> I also do not like that you just drop
> my concerns 1. and 2. which are not dealt with - otherwise I would not
> have asked.

…I did not drop anything.

> 
> > Please do not make it more difficult, an experienced DD (Mike Gabriel) is
> >working with us.
> I also do not like this "proof by authority" attitude.  I would not
> claim that I'm more right since I'm a longer experienced DD than Mike.

Your attitude of simply casting criticism in our direction is not helpful 
either. I am currently trying to address all the issues Mike had when we asked 
him to sponsor, which almost match yours 1:1.

> 
> > >  3. Why do you plan
> > >  
> > >  a) a non-official (random?) Git commit rather than a release?
> > 
> > Because there is no current release. Upstream does not make releases
> > anymore. The picked commit is not random. It is verified to work and
> > includes a lot of stuff we negotiated with upstream (license issues,
> > patches from Debian, etc.). It's the best we could get, and it works.
> That's nice to know and I'd love to have something well tested.  My only
> interest is to have some reliably working xrdp quickly.

In that case, please let us finalise the work ;). I expect it to be done until 
middle of the week.

> 
> > >  b) uploading to experimental rather than unstable?
> > 
> > Because the package is a major change (e.g. switching from x11vnc to
> > x11rdp by default).
> That's not a good reason for choosing experimental per se.  If there are
> no depnedencies to adapt to undergo a transition a well tested package
> can perfectly go to unstable.  Experimental is close to not tested and
> if you want some relevant number of users besides your closed circle you
> should push to unstable soon.  Otherwise you might get it in short before
> the freeze which might incover problems to late.

OK, thanks for the hint!

> 
> I insist that the parallel development of a totally separate package is
> very unfortunate,

I agree. Looking at the changelog, you might find that I did not decide or do 
that, but that I took over the new package and am now „cleaning up“.

> has caused duplicated work for me since it was not
> announced.

Well, actually, I do not think this is entirely my fault. See, there was an 
ITA, and that should have made you ask before doing any work. You knew that I 
was working on it, so you could have asked for a status before doing separate 
work.

That said, it was *you* who decided to work on it, when in fact there was a 
clear information that someone else is doing it right now.

> I realised that you basically ignored history, which is
> simply wrong.

Yes, it is, and I know it. It was not my decision, and after Mike raised his 
concerns about it as well, I started rebasing the work on the old repository. 
But it takes some time. Please let me finish it.

> I also have further concerns:
> […]

After fixing the issues Mike listed, I will happily come back to you to find 
out if there is anything else that could be improved.

Cheers,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-151-61623918

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

Bug#817195: xserver-xorg-video-intel: xserver hangs when unplugging VGA external display

[Anders Hammarquist]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20160218-1
Severity: normal

If an external display has been active on the VGA port, the
X server switches the display to a text console when the VGA
cable is unplugged, and trying to return (with Alt+Fnn) to
the X server vt hangs the console. Alt-Sysreq-K will successfully
kill the X-server (and start another working one from gdm3). This
happens irrespective of if the external display is actually in use
when the cable is unplugged or not. (e.g. xrandr --output VGA1 --off
before unplugging does not help) However, if the VGA cable has just
been plugged in, but not used to display (Xorg?) video, nothing
untoward happens when unplugging.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Oct  1  2009 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Feb  9 11:54 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 
Integrated Graphics Controller (primary) [8086:2a02] (rev 0c)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1435 Oct  4  2009 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"

Option  "XkbKeycodes"  "xfree86(thinkpadz60)+aliases(qwerty)"
Option  "XkbTypes" "complete"
Option  "XkbCompat""complete"
Option  "XkbSymbols"   
"pc+us+inet(media_nav_acpi_common)+se:2+group(lctrl_lshift_toggle)+private/modkeys+compose(rctrl)"
Option  "XkbGeometry"  "thinkpad(intl)"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
EndSection

Section "Device"
Identifier  "Configured Video Device"
EndSection

Section "Monitor"
Identifier  "Configured Monitor"
EndSection

Section "Screen"
SubSection "Display"
Virtual 4096 4096
EndSubSection
Identifier  "Default Screen"
Monitor "Configured Monitor"
EndSection

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

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1

Kernel version (/proc/version):
---
Linux version 4.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160121 (Debian 5.3.1-7) ) #1 SMP Debian 4.3.5-1 (2016-02-06)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 28033 Aug 30  2010 /var/log/Xorg.20.log
-rw-r--r-- 1 root root 26944 Feb  8  2015 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 18924 Feb 18 16:52 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[17.918] 
X.Org X Server 1.17.3
Release Date: 2015-10-26
[17.918] X Protocol Version 11, Revision 0
[17.918] Build Operating System: Linux 3.16.0-4-amd64 i686 Debian
[17.918] Current Operating System: Linux luggage 4.3.0-1-amd64 #1 SMP 
Debian 4.3.3-7 (2016-01-19) x86_64
[17.918] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.3.0-1-amd64 
root=/dev/mapper/vg0-root ro usbcore.autosuspend=1
[17.918] Build Date: 27 October 2015  11:29:29PM
[17.918] xorg-server 2:1.17.3-2 (http://www.debian.org/support) 
[17.918] Current version of pixman: 0.33.6
[17.918]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[17.918] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[17.918] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb  6 10:44:44 
2016
[17.918] (==) Using config file: "/etc/X11/xorg.conf"
[17.918] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[17.920] (==) No Layout section.  Using the first Screen section.
[17.920] (**) |-->Screen "Default Screen" (0)
[17.920] (**) |   |-->Monitor "Configured Monitor"
[17.921] (==) No device specified for screen "Default Screen".
 

Bug#817196: RM: sflphone -- RoQA; RC-buggy, unmaintained, replaced by ring

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal

Please remove sflphone from unstable. It is RC-buggy (#804615, #805095) and
is effectively NMU-maintained since 2014. sflphone will gain another RC bug once
the ffmpeg transition starts (#803859). It will also be replaced by ring
(currently ITPed #816707).

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#815248: liblcms2: Writes uninitialized strings when writing named colors

[Thomas Weber]

Hi, 

On Sat, Feb 20, 2016 at 01:35:37PM +0100, Jérémy Bobbio wrote:
> Package: liblcms2
> Version: 2.6-3
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: toolchain randomness
> 
> Hi!
> 
> When writing named colors, liblcms2 currently writes uninitialized memory
> when the prefix, suffix, or root color name strings are not
> 32-characters long (including the NULL terminator). This prevents colord
> from building reproducibly.
> 
> The attached patch will zero the memory before copying the profile
> strings to ensure a consistent output.

I am a bit unsure about the fact that you reduced the size of root[33]
to root[32]. Even if this works out okay in the current code base, such
a change should be made globally (i.e., _cms_NAMEDCOLORLIST_struct
should be changed).

What is your opinion on that?

Thomas

Bug#814517: Acknowledgement (wpasupplicant: Unstable connection after laptop suspend)

[Paul "LeoNerd" Evans]

Hi all,

Is there any way I can provide more information to help someone debug
this issue? It's been a month now and nobody's replied at all.

I'm quite happy to fiddle with local configs and get more debug logging
to send in, if someone could explain to me what information is likely
to be useful. As it happens almost every time I move from home to my
office or back, it's readily repeatable.

Please let me know how I can help,

-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS

Bug#719624: Upgrading xrdp

[Andreas Tille]

Hi,

On Tue, Mar 08, 2016 at 06:59:32PM +0100, Dominik George wrote:
> most of your concerns are being addressed already (restoring history and 
> such).

The current master branch of the repository you named[1] starts with


xrdp (0.9.0~git20150318-1~alpha1) teckids; urgency=medium

  * New upstream git snapshot
  * Document legal issues at https://github.com/neutrinolabs/xrdp/issues/232

 -- Thorsten Glaser   Wed, 18 Mar 2015 21:22:35 
+0100


which contradicts your statement.  I also do not like that you just drop
my concerns 1. and 2. which are not dealt with - otherwise I would not
have asked.

> Please do not make it more difficult, an experienced DD (Mike Gabriel) is 
>working with us.

I also do not like this "proof by authority" attitude.  I would not
claim that I'm more right since I'm a longer experienced DD than Mike.

> >  3. Why do you plan
> >  a) a non-official (random?) Git commit rather than a release?
> 
> Because there is no current release. Upstream does not make releases anymore. 
> The picked commit is not random. It is verified to work and includes a lot of 
> stuff we negotiated with upstream (license issues, patches from Debian, 
> etc.). It's the best we could get, and it works.

That's nice to know and I'd love to have something well tested.  My only
interest is to have some reliably working xrdp quickly.
 
> >  b) uploading to experimental rather than unstable?
> 
> Because the package is a major change (e.g. switching from x11vnc to x11rdp 
> by default).

That's not a good reason for choosing experimental per se.  If there are
no depnedencies to adapt to undergo a transition a well tested package
can perfectly go to unstable.  Experimental is close to not tested and
if you want some relevant number of users besides your closed circle you
should push to unstable soon.  Otherwise you might get it in short before
the freeze which might incover problems to late.

I insist that the parallel development of a totally separate package is
very unfortunate, has caused duplicated work for me since it was not
announced.  I realised that you basically ignored history, which is
simply wrong.

I also notice that the packaging in alioth Git[1] mentiones different
Vcs-* URLs which is broken but might be the reason that we are talking
possibly about different things.  Please explain the differences between
your statements and the code in alioth or push the latest state to
alioth.

I also have further concerns:

  4. Please use DEP3 headers

  5. Standards Version should be 3.9.7

  6. Please close bugs in BTS if any are closed.

Kind regards

   Andreas.

[1] 
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=debian-edu/pkg-team/xrdp.git;a=summary

-- 
http://fam-tille.de

Bug#817194: gpac: new upstream version and moved to github

[Sebastian Ramacher]

Source: gpac
Version: 0.5.2-426-gc5ad4e4+dfsg5-1
Severity: wishlist

A new upstream version is available (0.6.0):
https://github.com/gpac/gpac/releases/tag/v0.6.0.

Development also moved to github, so the watch file needs an update.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#816861: fuser does not show the PID that keeps busy a schroot mount-point

[Franco Martelli]

On 08/03/2016 at 10:52, Craig Small wrote:
> It actually finds the process you are looking for, however it also finds
> a lot of other processes.
Yes, this is true, sorry my mistake.
> 
> ~# fuser -m
> /var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316
> 
> Find something that is in that mount point OR the device of this file.
But this is not always true, please consider this scenario:
first start a schroot session:
~$ schroot -c kubuntu --
then open a terminal and as root type:
~# service cups restart
~# mount|grep -m1 kubuntu
/dev/mapper/ld0-lv2 on
/var/lib/schroot/mount/kubuntu-8565f027-6e05-4a41-811c-48836261f5ee type
ext4 (rw,relatime,stripe=256,data=ordered)
~# fuser -m
/var/lib/schroot/mount/kubuntu-8565f027-6e05-4a41-811c-48836261f5ee
/var/lib/schroot/mount/kubuntu-8565f027-6e05-4a41-811c-48836261f5ee:
12936rce
~#
then came back to the schroot's session shell and logout:
~$ logout
E: 10mount: rmdir: failed to remove
'/var/lib/schroot/mount/kubuntu-8565f027-6e05-4a41-811c-48836261f5ee':
Device or resource busy
E: kubuntu-8565f027-6e05-4a41-811c-48836261f5ee: Chroot setup failed:
stage=setup-stop
as you can see "fuser" shown only one process keeping busy the
mount-point but also cups did it, in fact schroot fails on exit.
Is it because cups does not open any file on that file-system?
> 
> However there is something odd about that mount point.
> 
> /proc/2061/mountinfo:196 41 253:3 /
> /var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316
> rw,relatime shared:135 - ext4 /dev/mapper/ld0-lv2
> rw,stripe=256,data=ordered
> 
>  Device 253:3
> I suspect this device is more than just your schroot.
> It looks awfully like /dev/dm-3
> 
> $ ls -l /dev/dm-3
> brw-rw 1 root disk 253, 3 Mar  1 19:33 /dev/dm-3
> 
> so.. considering the chroot device id is the same as whatever /dev/dm-3
> is, you'll get a long list of processes because it probably something
> like /home
I get an useless list of processes querying
"/var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316"
because it's the same as querying any other directory on the root
file-system.
However the device /dev/dm-3 has a symlink to ld0-lv2 that it was the
properly schroot's device to mount:
~# ls -la /dev/mapper/ld0-lv2
lrwxrwxrwx 1 root root 7 mar  5 19:49 /dev/mapper/ld0-lv2 -> ../dm-3
~# ls -la /dev/dm-3
brw-rw 1 root disk 253, 3 mar  5 19:49 /dev/dm-3

Thank again, best regards
-- 
Franco Martelli

Bug#817193: failing tests: test_gzip.py::test_metadata, test_ipk.py::test_metadata, test_java.py::test_diff

[Zbigniew Jędrzejewski-Szmek]

Package: diffoscope
Version: 48

Hi,

I'm trying to package diffoscope for Fedora and the tests listed
in $subject are failing. Seems to be some timezone issue:

= FAILURES 
==
_ test_differences 
__

differences = [, ]>]>]

@pytest.mark.skipif(not guestfs_working(), reason='guestfs not working on 
the system')
@pytest.mark.skipif(tool_missing('qemu-img'), reason='missing qemu-img')
@pytest.mark.skipif(miss_guestfs, reason='guestfs is missing')
def test_differences(differences):
assert differences[0].source1 == 'test1.ext4.tar'
tarinfo = differences[0].details[0]
tardiff = differences[0].details[1]
encodingdiff = tardiff.details[0]
assert tarinfo.source1 == 'file list'
assert tarinfo.source2 == 'file list'
assert tardiff.source1 == './date.txt'
assert tardiff.source2 == './date.txt'
assert encodingdiff.source1 == 'encoding'
assert encodingdiff.source2 == 'encoding'
expected_diff = open(os.path.join(os.path.dirname(__file__), 
'../data/ext4_expected_diffs'), encoding='utf-8').read()
found_diff = tarinfo.unified_diff + tardiff.unified_diff + 
encodingdiff.unified_diff
>   assert expected_diff == found_diff
E   assert '@@ -1,3 +1,3...cii\n+utf-8\n' == '@@ -1,3 +1,3 ...cii\n+utf-8\n'
E   @@ -1,3 +1,3 @@
E - -drwxr-xr-x   0000 2015-12-02 
16:01:40.00 ./
E - +drwxr-xr-x   0000 2015-12-02 
16:03:11.00 ./
E -  drwx--   0000 2015-12-02 
16:00:55.00 ./lost+found/
E + -drwxr-xr-x   0 root (0) root (0)0 
2015-12-02 16:01:40.00 ./
E + +drwxr-xr-x   0 root (0) root (0)0 
2015-12-02 16:03:11.00 ./
E +  drwx--   0 root (0) root (0)0 
2015-12-02 16:00:55.00 ./lost+found/
E   --rw-rw-rw-   0 1234 1234   28 2015-12-02 
16:01:40.00 ./date.txt
E   +-r--r--r--   0 4321 4321   44 2015-12-02 
16:03:11.00 ./date.txt
E   @@ -1 +1 @@
E   -Wed Dec 2 17:01:40 CET 2015
E   +jeudi 3 décembre 2015, 06:03:11 (UTC+1400)
E   @@ -1 +1 @@
E   -us-ascii
E   +utf-8

tests/comparators/test_fsimage.py:85: AssertionError
___ test_metadata 
___

differences = [, ]

def test_metadata(differences):
assert differences[0].source1 == 'metadata'
assert differences[0].source2 == 'metadata'
expected_diff = open(os.path.join(os.path.dirname(__file__), 
'../data/gzip_metadata_expected_diff')).read()
>   assert differences[0].unified_diff == expected_diff
E   assert '@@ -1 +1 @@\..., from Unix\n' == '@@ -1 +1 @@\n..., from Unix\n'
E   @@ -1 +1 @@
E - -gzip compressed data, last modified: Tue Jun 23 06:12:28 2015, max 
compression, from Unix
E ?   -
E + -gzip compressed data, last modified: Tue Jun 23 10:12:28 2015, max 
compression, from Unix
E ?  +
E - +gzip compressed data, last modified: Tue Jun 23 06:12:28 2015, 
from Unix
E ?   -
E + +gzip compressed data, last modified: Tue Jun 23 10:12:28 2015, 
from Unix
E ?  +

tests/comparators/test_gzip.py:54: AssertionError
___ test_metadata 
___

differences = [, , ]>]>]>]

def test_metadata(differences):
assert differences[0].source1 == 'metadata'
expected_diff = open(os.path.join(os.path.dirname(__file__), 
'../data/ipk_metadata_expected_diff')).read()
>   assert differences[0].unified_diff == expected_diff
E   assert '@@ -1 +1 @@\..., from Unix\n' == '@@ -1 +1 @@\n..., from Unix\n'
E   @@ -1 +1 @@
E - -gzip compressed data, last modified: Mon May 18 19:26:52 2015, 
from Unix
E ?  ^^
E + -gzip compressed data, last modified: Mon May 18 23:26:52 2015, 
from Unix
E ?  ^^
E - +gzip compressed data, last modified: Mon Jun  8 13:31:21 2015, 
from Unix
E ?   ^
E + +gzip compressed data, last modified: Mon Jun  8 17:31:21 2015, 
from Unix
E ?   ^

tests/comparators/test_ipk.py:52: AssertionError
_ test_diff 

Bug#817192: php5-cgi of version 5.6 tries to load libraries of version 5.4

[Elmar Stellnberger]

Package: php5-cgi
Version: 5.6.17+dfsg-3
Severity: normal

Dear Maintainer,


php5-cgi --version
Failed loading /usr/lib/php5.4/20100525/opcache.so: 
/usr/lib/php5.4/20100525/opcache.so: cannot open shared object file: No 
such file or directory
PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5.4/20100525/pdo.so' - /usr/lib/php5.4/20100525/pdo.so: 
cannot open shared object file: No such file or directory in Unknown on 
line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5.4/20100525/imagick.so' - 
/usr/lib/php5.4/20100525/imagick.so: cannot open shared object file: No 
such file or directory in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5.4/20100525/json.so' - /usr/lib/php5.4/20100525/json.so: 
cannot open shared object file: No such file or directory in Unknown on 
line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5.4/20100525/readline.so' - 
/usr/lib/php5.4/20100525/readline.so: cannot open shared object file: No 
such file or directory in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5.4/20100525/xsl.so' - /usr/lib/php5.4/20100525/xsl.so: 
cannot open shared object file: No such file or directory in Unknown on 
line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5.4/20100525/yac.so' - /usr/lib/php5.4/20100525/yac.so: 
cannot open shared object file: No such file or directory in Unknown on 
line 0

PHP 5.6.17-3 (cgi-fcgi)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies

However the /us/lib/php5.4 directory does not exist:


ls -l /usr/lib/php5/20131226/

insgesamt 844
-rw-r--r-- 1 root root 418376 Jun 17  2015 imagick.so
-rw-r--r-- 1 root root  39696 Jul  8  2015 json.so
-rw-r--r-- 1 root root 156152 Jän 15 10:10 opcache.so
-rw-r--r-- 1 root root 118344 Jän 15 10:10 pdo.so
-rw-r--r-- 1 root root  35672 Jän 15 10:10 readline.so
-rw-r--r-- 1 root root  35960 Jän 15 10:10 xsl.so
-rw-r--r-- 1 root root  48224 Okt 23  2014 yac.so

As it seems the php5-cgi binary has been compiled against too old shared 
libaries which are not in sync with the other libraries available for 
debian-testing.

all of it after a successful apt-get upgrade.

-- Package-specific info:
 Additional PHP 5 information 

 PHP 5 SAPI (php5query -S): 
cli
apache2
cgi

 PHP 5 Extensions (php5query -M -v): 
pdo (Enabled for cli by maintainer script)
pdo (Enabled for apache2 by maintainer script)
pdo (Enabled for cgi by maintainer script)
opcache (Enabled for cli by maintainer script)
opcache (Enabled for apache2 by maintainer script)
opcache (Enabled for cgi by maintainer script)
json (Enabled for cli by maintainer script)
json (Enabled for apache2 by maintainer script)
json (Enabled for cgi by maintainer script)
readline (Enabled for cli by maintainer script)
readline (Enabled for apache2 by maintainer script)
readline (Enabled for cgi by maintainer script)
imagick (Enabled for cli by maintainer script)
imagick (Enabled for apache2 by maintainer script)
imagick (Enabled for cgi by maintainer script)
xsl (Enabled for cli by maintainer script)
xsl (Enabled for apache2 by maintainer script)
xsl (Enabled for cgi by maintainer script)
yac (Enabled for cli by maintainer script)
yac (Enabled for apache2 by maintainer script)
yac (Enabled for cgi by maintainer script)

 Configuration files: 
[PHP]
allow_url_include = 0
always_populate_raw_post_data = 0
arg_separator.input = "&"
arg_separator.output = "&"
[Assertion]
assert.active = 1
assert.bail = 0
assert.quiet_eval = 0
assert.warning = 1
[PHP]
auto_detect_line_endings = 0
auto_globals_jit = 1
[bcmath]
bcmath.scale = 0
[cgi]
cgi.check_shebang_line = 1
cgi.discard_path = 0
cgi.fix_pathinfo = 1
cgi.force_redirect = 1
cgi.nph = 0
cgi.rfc2616_headers = 0
[date]
date.default_latitude = 31.7667
date.default_longitude = 35.2333
date.sunrise_zenith = 90.58
date.sunset_zenith = 90.58
[dba]
dba.default_handler = "flatfile"
[PHP]
default_mimetype = "text/html"
default_socket_timeout = 60
disable_functions = "system, show_source, passthru, shell_exec, exec, 
pcntl_exec, popen, posix_setuid, posix_seteuid, proc_open, chown, 
dbmopen, disk_free_space, diskfreespace"

display_errors = 1
enable_dl = 1
enable_post_data_reading = 1
error_reporting = 24567
[exif]
exif.decode_jis_intel = "JIS"
exif.decode_jis_motorola = "JIS"
exif.decode_unicode_intel = "UCS-2LE"
exif.decode_unicode_motorola = "UCS-2BE"
exif.encode_unicode = "ISO-8859-15"
[PHP]
exit_on_timeout = 0
extension_dir = "/usr/lib/php5.4/20100525"
[fastcgi]
fastcgi.logging = 1
[PHP]
file_uploads = 1
[filter]
filter.default = "unsafe_raw"
[gd]
gd.jpeg_ignore_warning = 0
[highlight]
highlight.comment = "#FF8000"
highlight.default = "#BB"
highlight.html = "#00"
highlight.keyword = "#007700"
highlight.string = "#DD"
[PHP]
html_errors = 1
[iconv]

Bug#816982: maxima: FTBFS when built with dpkg-buildpackage -A (tests fail)

[Camm Maguire]

Greetings!  If you could please provide the full build log I will try to
take a look.

Take care,

Santiago Vila  writes:

> Package: src:maxima
> Version: 5.37.3-1
> User: sanv...@debian.org
> Usertags: binary-indep
> Severity: important
>
> Dear maintainer:
>
> I tried to build this package with "dpkg-buildpackage -A"
> (i.e. only architecture-independent packages), and it failed:
>
> 
> [...]
>  debian/rules build-indep
> mkdir -p debian/save
> [ -e debian/save/aclocal.m4 ] || cp aclocal.m4 debian/save/aclocal.m4
> mkdir -p debian/save
> [ -e debian/save/configure ] || cp configure debian/save/configure
> mkdir -p debian/save/interfaces/emacs/imaxima
> [ -e debian/save/interfaces/emacs/imaxima/stamp-vti ] || cp 
> interfaces/emacs/imaxima/stamp-vti 
> debian/save/interfaces/emacs/imaxima/stamp-vti
> mkdir -p debian/save/interfaces/emacs/imaxima
> [ -e debian/save/interfaces/emacs/imaxima/imaxima.info ] || cp 
> interfaces/emacs/imaxima/imaxima.info 
> debian/save/interfaces/emacs/imaxima/imaxima.info
> mkdir -p debian/save/interfaces/emacs/imaxima
> [ -e debian/save/interfaces/emacs/imaxima/version.texi ] || cp 
> interfaces/emacs/imaxima/version.texi 
> debian/save/interfaces/emacs/imaxima/version.texi
> mkdir -p debian/save/src
>
> [... snipped ...]
>
> Running tests in rtest_taylor: 149/149 tests passed (not counting 6 expected 
> errors)
> Running tests in rtest_dot: 60/60 tests passed
> Running tests in rtest_mset: 92/92 tests passed
> Running tests in rtest_boolean: 116/116 tests passed
> Running tests in rtest_round: 101/101 tests passed
> Running tests in rtest_map: 99/99 tests passed (not counting 3 expected 
> errors)
> Running tests in rtest_sign: 307/307 tests passed (not counting 7 expected 
> errors)
> Running tests in rtest_algebraic: 45/45 tests passed
> Running tests in rtest_gamma: 745/745 tests passed
> Running tests in rtest_expintegral: 210/210 tests passed
> Running tests in rtest_signum: 50/50 tests passed
> Running tests in rtest_lambert_w: 57/57 tests passed
> Running tests in rtest_elliptic: 87/87 tests passed
> Running tests in rtest_integrate: 812/812 tests passed
> Running tests in rtest_integrate_special: 53/53 tests passed
> Running tests in rtest_sqrt: 313/313 tests passed (not counting 1 expected 
> errors)
> Running tests in rtest_carg: 55/55 tests passed (not counting 2 expected 
> errors)
> Running tests in rtest_log: 121/121 tests passed
> Running tests in rtest_power: 72/72 tests passed (not counting 5 expected 
> errors)
> Running tests in rtestdefstruct: 32/32 tests passed
> Running tests in rtest_limit: 177/177 tests passed
> Running tests in rtest_powerseries: touch tmp
> cat tmp >debian/test_results.out
> grep -q "No unexpected errors found." debian/test_results.out
> debian/rules:73: recipe for target 'build-stamp' failed
> make: *** [build-stamp] Error 1
> dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
> 67/67 tests passed
> Running tests in rtest_laplace: 98/98 tests passed (not counting 11 expected 
> errors)
>
> Error summary:
> Errors found in /<>/tests/rtest15.mac, problems:
> (47 49 55 61 67 73 79 85 91 165 174)
> Error found in /<>/tests/rtest8.mac, problem:
> (133)
> 12 tests failed out of 10,408 total tests.
> real time   : 92.709 secs
> run-gbc time: 76.080 secs
> child run time  :  8.229 secs
> gbc time:  6.539 secs
> (%o0)done
> 
>
> Sorry not to have a fix, as I am reporting many bugs similar to
> this one. The common hints are:
>
> * If the only architecture-independent packages are dummy transitional
> ones and they were released with jessie, the easy fix is to drop them
> now.
>
> * When using "dh", it is allowed to use (independently)
> optional targets override_dh_foo-arch and override_dh_foo-indep
> (for several values of "foo").
>
>
> Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
> properly, the package would be suitable to be uploaded in source-only
> form if you wish.
>
> Thanks.
>
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Scott Ashcroft]

The patch makes no difference.
Is there anything else I can do to help figure this out?

Cheers,
Scott

Bug#792321: Darlehen Angebot

[franczak . mariola]

Das Aspire Gelddarlehen bieten wir 3% für Business-Darlehen und persönliche 
Darlehen,

Füllen Sie das Formular aus, wenn interessiert

Vollständiger Name:
Sex:
Land:
Erforderliche Kreditbetrag :
Dauer:

Maria Enzo

Bug#815940: maxima: info files not where maxima expects them

[Kyanos]

On Thu, 25 Feb 2016 17:37:16 -0500 Sanjoy Mahajan  wrote:
> The info files are actually in /usr/share/info
>
> $ ls /usr/share/info/maxima*
> /usr/share/info/maxima.info-1.gz /usr/share/info/maxima.info-3.gz
> /usr/share/info/maxima.info-2.gz /usr/share/info/maxima.info.gz
>
> and are put there by maxima-doc:
>
> $ dpkg -S /usr/share/info/maxima.info-1.gz
> maxima-doc: /usr/share/info/maxima.info-1.gz
>
> Making symlinks fixes it:
>
> # cd /usr/share/doc/maxima/info
> # ln -s /usr/share/info/maxima.info-1.gz
> etc.

This seems to be a duplicate of #810578.

Kyanos

Bug#816682: live-installer: Inaccessible utility

[Cyril Brulebois]

Samuel Thibault  (2016-03-08):
> Iain R. Learmonth, on Tue 08 Mar 2016 11:17:43 +, wrote:
> > On 08/03/16 01:16, Cyril Brulebois wrote:
> > > Samuel Thibault wrote:
> > >> - adding the content of libgail-common-udeb and libatk-adaptor-udeb to
> > >> the d-i image used by the live installer.
> > 
> > If you can add the packages into the standard d-i used on debian-cd, I'm
> > happy to use the installer that is built by the d-i team, I don't want
> > to have to build our own installer and I want to be using only things
> > that are in Debian main.
> 
> Ok, so debian-boot, how do you feel about adding these two to the
> standard gtk images, even if the debian installer images won't
> use it?  That also pulls libdbus-1-3-udeb, libatspi0-udeb and
> libatk-bridge-2.0-0-udeb, making the compressed initrd image ~500KiB
> bigger, and the uncompressed initrd image ~1.3MiB bigger.

At first glance, I don't think this size increase warrants generating a
separate, extra gtk-for-live build to avoid making the gtk build bigger.


KiBi.


signature.asc
Description: Digital signature

Bug#816682: live-installer: Inaccessible utility

[Samuel Thibault]

Hello,

Iain R. Learmonth, on Tue 08 Mar 2016 11:17:43 +, wrote:
> On 08/03/16 01:16, Cyril Brulebois wrote:
> > Samuel Thibault wrote:
> >> - adding the content of libgail-common-udeb and libatk-adaptor-udeb to
> >> the d-i image used by the live installer.
> 
> If you can add the packages into the standard d-i used on debian-cd, I'm
> happy to use the installer that is built by the d-i team, I don't want
> to have to build our own installer and I want to be using only things
> that are in Debian main.

Ok, so debian-boot, how do you feel about adding these two to the
standard gtk images, even if the debian installer images won't
use it?  That also pulls libdbus-1-3-udeb, libatspi0-udeb and
libatk-bridge-2.0-0-udeb, making the compressed initrd image ~500KiB
bigger, and the uncompressed initrd image ~1.3MiB bigger.

Samuel

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Giulio Paci]

Hi Jakub,

On 08/03/2016 19:00, Jakub Wilk wrote:
> * Giulio Paci , 2016-03-07, 17:44:
>> I added a README.source
> 
> I don't like the phrase "build environment must not change during automated 
> builds". It makes me think of that you must not install or remove packages 
> when you package is
> building, which is technically true, but certainly not what you meant.

I rewrote that phrase so that now it is, hopefully, more clear.

>> On Friday I discovered an issue with this patch that, randomly, prevents 
>> tests to complete.
> 
> I saw the patch was updated in f083eb6924bf. Is this fixed now?

Probably.
The situation seems much much better than before (I did not experience test 
failures anymore), but, according to the author, it still requires testing.

> Typo in the patch header:
> idemppotent -> idempotent

Fixed.

> Why is "HopCroft" spelled with capital C?
> I've never seen this name spelled like that before.
> (Searching for "HopCroft" in codesearch.d.n revealed that there's an embedded 
> code copy of OpenFST in src:hfst. *sigh*)

I think the author of the patch just reproduced what he found on the code.
In the same code "Hopcroft" is spelled "HopCroft", "Hopcroft", "hopcroft", so I 
think the correct spelling is "Hopcroft".
However I would prefer not to fix it until the patch is known to be stable.

>>> I think the 500 MB/job limit is insufficient.
> [...]
>> I increased the limit to 2Gb/job, but I am not completely convinced about 
>> this new limit.
> 
> s/Gb/GB/ (unless you meant gigabits :-P)

And I also made this mistake two times in a single package... :-/

> Sounds good enough for me. Let's not overthink this. :)

Perfect!

>> How likely is it that we are going to compile with parallel=2 on an amd64 
>> system with 4Gb of RAM, without swap available?
> 
> Unlikely. Although we do seem to have an s390x buildd with only 3GB of RAM:
> https://db.debian.org/machines.cgi?host=zemlinsky

So we may have a failure there. :-/

> I'd remove "Increase per job required memory to 2Gb for parallel builds.", 
> because the previous version didn't have any limits, and you already said 
> "Limit parallelism on
> buildds in order not to run out of RAM" earlier.

You are right.

>>> We have automatic debug packages these days, so I'd drop the -dbg package.
>> Dropped the -dbg package.
> 
> Hmm, "According to https://wiki.debian.org/AutomaticDebugPackages; looks like 
> truncated sentence. Anyway, IMO the announcement message is a better source 
> of information on
> this: https://lists.debian.org/5675e791.6060...@thykier.net

I tried to improve that sentence.

> cppcheck says:
> [src/bin/fstcompile.cc:57]: (error) Memory leak: istrm
> [src/bin/fstdraw.cc:72]: (error) Memory leak: ostrm
> [src/bin/fstprint.cc:67]: (error) Memory leak: ostrm

Added a patch for these.

Bests,
Giulio.

Bug#813323: Second window of Eye of MATE don't get focus

[Strelok]

> Yeah. But you're barking up the wrong tree. Unless this is a bug which
> is only present in Debian, you have to report it to MATE's upstream
> bug tracker which can be found in [1]. Debian is primarily dealing
> with packaging, fixing such bugs is upstream's job.

I'm read abort this tree in https://www.debian.org/Bugs/Reporting :
Don't file bugs upstream

If you file a bug in Debian, don't send a copy to the upstream
software maintainers yourself, as it is possible that the bug exists
only in Debian. If necessary, the maintainer of the package will
forward the bug upstream.

But ok, I'm send bug report also to upstream
(https://github.com/mate-desktop/eom/issues/119).

Bug#815984: [Aqbanking-user] Fwd: Bug#815984: libaqbanking-data: missing translatable strings in libaqbanking

[Christian Stimming]

I've fixed the missing translation strings in upstream git. Once a new version 
is out (which would be 5.6.6 or higher), the strings will appear in de.po and 
I've also already added a German translation.

Regards,
Christian

Am Samstag, 5. März 2016, 22:53:01 schrieb Micha Lenk:
> Hallo,
> 
> ich habe über den Debian-Bugtracker den unten stehenden Bugreport
> bekommen. Ich kenne mich leider mit dem Internationalisierungs-Workflow
> von AqBanking überhaupt nicht aus. Kann mir jemand auf die Sprünge helfen?
> 
> Viele Grüße,
> Micha
> 
> 
>  Weitergeleitete Nachricht 
> Betreff: Bug#815984: libaqbanking-data: missing translatable strings in
> libaqbanking
> Weitersenden-Datum: Fri, 26 Feb 2016 11:33:01 +
> Weitersenden-Von: mechtilde 
> Weitersenden-An: debian-bugs-dist@lists.debian.org
> Weitersenden-CC: Micha Lenk 
> Datum: Fri, 26 Feb 2016 12:30:34 +0100
> Von: mechtilde 
> Antwort an: mechtilde , 815...@bugs.debian.org
> An: Debian Bug Tracking System 
> 
> Package: libaqbanking-data
> Version: 5.6.4beta-1
> Severity: normal
> Tags: l10n
> 
> missing these strings in the actual de.po for translation
> 
> src/plugins/backends/aqhbci/plugin/dialogs/dlg_editaccount.dlg
>   45  text="Prefer Single SEPA Transfer" />
>   46  text="Prefer Single SEPA Debit Note" />
>   79  name="getSepaButton" />
> 
> regards
> 
> Mechtilde
> 
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> libaqbanking-data depends on no packages.
> 
> Versions of packages libaqbanking-data recommends:
> ii  libaqbanking35  5.6.4beta-1
> 
> libaqbanking-data suggests no packages.
> 
> -- no debconf information
> 
> 
> ___
> Aqbanking-user mailing list
> aqbanking-u...@lists.aqbanking.de
> http://lists.aqbanking.de/cgi-bin/mailman/listinfo/aqbanking-user

Bug#810563: bs1770gain: FTBFS with FFmpeg 2.9/3.0 (Werror)

[Sebastian Ramacher]

On 2016-03-07 07:35:19, Peter Belkner wrote:
> [Andreas Cadhalpun]
> > Attached is a patch removing the use of -Werror, which is
> > a good practice for development builds, but just causes
> > unnecessary build failures for release builds.
> 
> Andreas, could you please let us know the cause for the error? Is it the
> following?
> 
>ffsox_source.c:157:7: error: 'av_free_packet' is deprecated
>[-Werror,-Wdeprecated-declarations]
>   av_free_packet(pkt);
>   ^
>/usr/local/include/libavcodec/avcodec.h:4040:6: note:
>'av_free_packet' has been explicitly marked deprecated here
>void av_free_packet(AVPacket *pkt);
>  ^
>1 error generated.
>make[2]: *** [ffsox_source.o] Error 1
>make[1]: *** [all-recursive] Error 1
>make: *** [all] Error 2

Seems so. A full build log is available at
https://people.debian.org/~sramacher/logs/ffmpeg3.0/bs1770gain_0.4.8-2_amd64-20160308-.log

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#817086: [Pkg-privacy-maintainers] Bug#817086: Bug#817086: clicking on circuits doesn't show any info

[Sascha Steinbiss]

Hi Paul,

thanks for your input.

>> It looks like you chose not to install tor’s recommended tor-geoipdb package.
> 
> I have recommends turned off by default.

I see, this confirms my suspicion.

>> I have created a patch to check for this error (see attached) and
>> will forward it upstream.
> 
> This would print (?) next to the IP address for every hop. I would go
> with a slightly different set of changes; don't show the country next
> to the IP address unless country info is available and have a text item
> suggesting to install the Tor GeoIP DB if it is missing.

Sounds good. I’ll see what I can do once I have figured how to do the i18n for 
that.

>> Also, I’ll make onioncircuits suggest tor-geoipdb. Any comments?
> 
> Recommends or Suggests seems reasonable.

OK, done in git. I’ll see to improving the output before a bugfix upload.

Cheers
Sascha

Bug#817191: bugs.debian.org: Version pseudoheader ignored

[Jakub Wilk]

Package: bugs.debian.org

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817128#23 is a 
message sent to -done with Version pseudoheader. The bug was closed, 
but fixed version wasn't recorded. (Maybe it's because the message is 
multi-part?)


--
Jakub Wilk

Bug#817190: autopkgtest: doesn't honour T(E)MPDIR

[Rene Engelhard]

Package: autopkgtest
Version: 3.19.3
Severity: important

Hi,

my last report was just possible because I did a mount /home/rene/tmp /tmp 
-obind.

Because:

(sid)root@frodo /tmp # df -h 
DateisystemGröße Benutzt Verf. Verw% Eingehängt auf
/dev/sda628G 22G  4.4G   84% /
tmpfs   1.6G 18M  1.5G2% /run
/dev/sda9   326G262G   48G   85% /home
/dev/sda7   3.7G8.3M  3.4G1% /tmp
tmpfs   773M 28K  773M1% /run/user/1000
rene has logged on pts/19 from :0.  

$ TMPDIR=/home/rene/tmp TEMPDIR=/home/rene/tmp adt-run -d -B --unbuilt-tree . 
--timeout-copy=1 -l adt.log --- null
adt-run: DBG: Parsed options: Namespace(apt_pocket=[], auto_control=True, 
copy=[], env=[], gainroot=None, logfile='adt.log', output_dir=None, 
set_lang=None, setup_commands=[], shell=False, shell_fail=False, summary=None, 
timeout_build=None, timeout_copy=1, timeout_factor=1.0, 
timeout_install=None, timeout_short=None, timeout_test=None, user=None, 
verbosity=2)
adt-run: DBG: Remaining arguments: ['-B', '--unbuilt-tree', '.']
adt-run: DBG: Interpreted actions: ['--no-built-binaries', '--unbuilt-tree', 
'.']
adt-run: DBG: Virt runner arguments: ['null']
adt-run: DBG: testbed init
adt-run [21:52:07]: version 3.19.3
adt-run [21:52:07]: host frodo; command line: /usr/bin/adt-run -d -B 
--unbuilt-tree . --timeout-copy=1 -l adt.log --- null
adt-run: DBG: got reply from testbed: ok
adt-run: DBG: testbed open, scratch=None
adt-run: DBG: sending command to testbed: open
adt-run: DBG: got reply from testbed: ok /tmp/adt-run.Vecb5V
adt-run: DBG: sending command to testbed: print-execute-command
adt-run: DBG: got reply from testbed: ok env
adt-run: DBG: sending command to testbed: capabilities
adt-run: DBG: got reply from testbed: ok isolation-machine 
downtmp-host=/tmp/adt-run.Vecb5V
adt-run: DBG: testbed capabilities: ['isolation-machine', 
'downtmp-host=/tmp/adt-run.Vecb5V']
adt-run: DBG: testbed command ['dpkg', '--print-architecture'], kind short, 
sout pipe, serr pipe, env []
adt-run: DBG: testbed command exited with code 0
adt-run [21:52:07]: testbed dpkg architecture: amd64
adt-run: DBG: testbed command ['which', 'eatmydata'], kind short, sout pipe, 
serr pipe, env []
adt-run: DBG: testbed command exited with code 1
adt-run: DBG: testbed command ['which', 'dpkg-query'], kind short, sout pipe, 
serr pipe, env []
adt-run: DBG: testbed command exited with code 0
adt-run: DBG: testbed command ['sh', '-ec', "dpkg-query --show -f 
'${Package}\\t${Version}\\n' > /tmp/adt-run.Vecb5V/testbed-packages"], kind 
short, sout raw, serr pipe, env []
adt-run: DBG: testbed command exited with code 0
adt-run: DBG: sending command to testbed: copyup 
/tmp/adt-run.Vecb5V/testbed-packages 
/home/rene/tmp/adt-run.output.ya7yuz0h/testbed-packages
adt-run: DBG: got reply from testbed: ok
adt-run: DBG: testbed command ['uname', '-srv'], kind short, sout pipe, serr 
pipe, env []
adt-run: DBG: testbed command exited with code 0
adt-run [21:52:07]: testbed running kernel: Linux 3.16.0-4-amd64 #1 SMP Debian 
3.16.7-ckt20-1+deb8u4 (2016-02-29)
adt-run: DBG: Binaries: initialising
adt-run [21:52:07]:  unbuilt-tree .
adt-run: DBG: blame += .
adt-run: DBG: testbed reset: modified=False, deps_installed=[](r: False), 
deps_new=[](r: False)
adt-run: DBG: testbed command ['mkdir', '-p', '/tmp/adt-run.Vecb5V'], kind 
short, sout raw, serr pipe, env []
adt-run: DBG: testbed command exited with code 0
adt-run: DBG: sending command to testbed: copydown ./ 
/tmp/adt-run.Vecb5V/ubtree-./

/tmp? But I set TMPDIR (and to be sure, TEMPDIR)...

1 (sid)rene@frodo ~/LibreOffice/git/master (git)-[master] % export 
TMPDIR=/home/rene/tmp; export TEMPDIR=/home/rene/tmp; adt-run -d -B 
--unbuilt-tree . --timeout-copy=1 -l adt.log --- null
adt-run: DBG: Parsed options: Namespace(apt_pocket=[], auto_control=True, 
copy=[], env=[], gainroot=None, logfile='adt.log', output_dir=None, 
set_lang=None, setup_commands=[], shell=False, shell_fail=False, summary=None, 
timeout_build=None, timeout_copy=1, timeout_factor=1.0, 
timeout_install=None, timeout_short=None, timeout_test=None, user=None, 
verbosity=2)
adt-run: DBG: Remaining arguments: ['-B', '--unbuilt-tree', '.']
adt-run: DBG: Interpreted actions: ['--no-built-binaries', '--unbuilt-tree', 
'.']
adt-run: DBG: Virt runner arguments: ['null']
adt-run: DBG: testbed init
adt-run [21:53:12]: version 3.19.3
adt-run [21:53:12]: host frodo; command line: /usr/bin/adt-run -d -B 
--unbuilt-tree . --timeout-copy=1 -l adt.log --- null
adt-run: DBG: got reply from testbed: ok
adt-run: DBG: testbed open, scratch=None
adt-run: DBG: sending command to testbed: open
adt-run: DBG: got reply from testbed: ok /tmp/adt-run.wsrBMY
adt-run: DBG: sending command to testbed: print-execute-command
adt-run: DBG: got reply from testbed: ok env
adt-run: DBG: sending command to testbed: capabilities
adt-run: DBG: got reply from