Bug#838418: libreoffice-gtk3: Font corruption - both content and dialogs

[Rene Engelhard]

tag 838418 + moreinfo
thanks

On Wed, Sep 21, 2016 at 07:37:11AM +0200, Rene Engelhard wrote:
> > Upgrade of libreoffice. It was definitely working fine on August 16th,
> > then I haven't done any upgrades until this last week, so I suspect the
> > move from 5.2.0 to 5.2.1
> 
> I will never understand why on earth people think it's a good idea to
> upgrade unstable only that rarely? That makes it harder to find out which
> exact upgrade was the problem. You use unstable, if you want a stable system
> (as in non-changing) use stable or (lesser changing than unstable) testing.

Especially as end of August we got Gtk 3.0 3.21.x What happens if you downgrade
that one to 3.20.9? (see snapshot.debian.org?

Regards,
 
Rene

Bug#838418: libreoffice-gtk3: Font corruption - both content and dialogs

[Rene Engelhard]

found 838418 1:5.2.1-1
thanks
 
On Tue, Sep 20, 2016 at 11:25:58PM +0100, Simon John wrote:
> Package: libreoffice-gtk3
> Version: 1:5.2.1-3

Obviously wrrong. Because you say below that 1:5.2.1-1 has the same problem.
So please take some care on reporting bugs, especially if it's RC and your
bug will block other RC bugfixes to enter testing.

> Upgrade of libreoffice. It was definitely working fine on August 16th,
> then I haven't done any upgrades until this last week, so I suspect the
> move from 5.2.0 to 5.2.1

I will never understand why on earth people think it's a good idea to
upgrade unstable only that rarely? That makes it harder to find out which
exact upgrade was the problem. You use unstable, if you want a stable system
(as in non-changing) use stable or (lesser changing than unstable) testing.

> Its not a driver issue as I get the same problem on Nvidia (nouveau)
> desktop and Intel laptop.

Any special fonts or anything else which might be special?

Regards,

Rene

Bug#832717: package [ openjdk-8-jdk-headless ] tags 794502 + patch

[U B, Avinash]

Thanks Matthias, I wasn't aware of these packaging policies, please suggest me 
a possible way to handle this case.

Regards,
Avinash
HPE

Bug#838434: gnome-settings-daemon 100% CPU usage on login

[Felipe Ortiz]

Package: gnome-settings-daemon
Version: 3.21.92.1-1
Severity: normal

Dear Maintainer,

After login gnome-settings-daemon use a 100% of my CPU and other wierd
behavior like multimedia keys malfunction, screen brightness applet
doesn't work (work fine with function keys) and in gnome-control-center
can not access to "power" section. Before login CPU usage is normal and
multimedia keys work as usual.

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

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

Versions of packages gnome-settings-daemon depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gsettings-desktop-schemas3.21.4-2
ii  libasound2   1.1.2-1
ii  libc62.24-3
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libcolord2   1.3.3-2
ii  libcups2 2.2.0-1
ii  libfontconfig1   2.11.0-6.7
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libgeoclue-2-0   2.4.3-1
ii  libgeocode-glib0 3.20.1-1
ii  libglib2.0-0 2.50.0-1
ii  libgnome-desktop-3-123.22.0-1
ii  libgtk-3-0   3.21.6-1
ii  libgudev-1.0-0   230-3
ii  libgweather-3-6  3.20.3-1
ii  liblcms2-2   2.7-1
ii  libnm0   1.4.0-3
ii  libnotify4   0.7.6-2
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26-1
ii  libpam-systemd   231-7
ii  libpango-1.0-0   1.40.2-1
ii  libpangocairo-1.0-0  1.40.2-1
ii  libpolkit-gobject-1-00.105-16
ii  libpulse-mainloop-glib0  9.0-3
ii  libpulse09.0-3
ii  librsvg2-2   2.40.16-1
ii  libupower-glib3  0.99.4-4
ii  libwacom20.22-1
ii  libwayland-client0   1.11.0-2
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1
ii  libxi6   2:1.7.6-1
ii  libxtst6 2:1.2.2-1+b1
ii  nautilus-data3.22.0-1

Versions of packages gnome-settings-daemon recommends:
ii  iio-sensor-proxy  1.3-1
ii  pulseaudio9.0-3

gnome-settings-daemon suggests no packages.

-- no debconf information

Bug#838433: gitlab: Error 500 on some projects

[Dmitry Smirnov]

Package: gitlab
Version: 8.11.3+dfsg1-3
Severity: important
Control: forwarded -1 https://gitlab.com/gitlab-org/gitlab-ce/issues/21564

Upgrade from 8.10.5+dfsg-3 to 8.11.3+dfsg1-3 broke some projects:


Processing by ProjectsController#show as HTML
  Parameters: {"namespace_id"=>"team", "id"=>"myproject"}
Completed 500 Internal Server Error in 96ms (ActiveRecord: 8.8ms)

OpenSSL::Cipher::CipherError (bad decrypt):
  app/models/project.rb:489:in `import_url'
  app/models/project.rb:525:in `external_import?'
  app/models/project.rb:517:in `import?'
  app/models/project.rb:533:in `import_in_progress?'
  app/controllers/projects_controller.rb:94:in `show'
  lib/gitlab/request_profiler/middleware.rb:15:in `call'
  lib/gitlab/middleware/go.rb:16:in `call'


To resolve the problem I had to run the following command
from gitlab rails console:


Project.where.not(import_url: nil).each { |p| p.import_data.destroy if 
p.import_data }


Since manual step is required to upgrade a NEWS file with instructions
would be much appreciated. It would be even better if it is possible
to automate this action.

Thanks.

-- 
Cheers,
 Dmitry Smirnov.

---

Good luck happens when preparedness meets opportunity.



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

Bug#832718: package [ openjdk-8-jdk-headless ] tags 794502 + patch

[U B, Avinash]

Thanks Matthias, I wasn't aware of these packaging policies, please suggest me 
a possible way to handle this case.

Regards,
Avinash
HPE

Bug#838431: systemd.postinst fails because the systemd-timesync user already exists when upgrading

[Michael Biebl]

Am 21.09.2016 um 06:29 schrieb Michael Biebl:
> Control: tags -1 moreinfo unreproducible
> Control: severity -1 important
> 
> Am 21.09.2016 um 05:31 schrieb Grond:
>>  Setting up systemd (215-17+deb8u5) ...
>>  addgroup: The group `systemd-journal' already exists as a system group. 
>> Exiting.
>>  dpkg: error processing package systemd (--configure):
>>   subprocess installed post-installation script returned error exit 
>> status 1
> 
> ...
> 
>> `getent` queries for the other systemd users referenced in the above have 
>> similar results.
>> Apparently, `adduser` returns a non-zero exit status when told to create a 
>> user that already
>> exists, even if the --quiet flag is given.
> 
> If that's the case, then this would be a bug in adduser and not systemd.
> I can't reproduce that though
> 
> # getent passwd systemd-timesync
> systemd-timesync:x:108:113:systemd Time
> Synchronization,,,:/run/systemd:/bin/false
> 
> # adduser --quiet --system --group --no-create-home --home /run/systemd
> --gecos "systemd Time Synchronization" systemd-timesync
> 
> # echo $?
> 0
> 
>> Since the whole script is run under `set -e`, when the `adduser` command 
>> fails, the entire
>> systemd.postist script aborts.
> 
> Can you add "set -e" to systemd.postinst and then run
> dpkg --configure -a and attach the log. Somehow I suspect the addgroup /
> adduser message is a red herring.
> 

Just to be sure, please run
# adduser --system --group --no-create-home --home /run/systemd
 --gecos "systemd Time Synchronization" systemd-timesync
# echo $?

and attach the output


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



signature.asc
Description: OpenPGP digital signature

Bug#838431: systemd.postinst fails because the systemd-timesync user already exists when upgrading

[Michael Biebl]

Control: tags -1 moreinfo unreproducible
Control: severity -1 important

Am 21.09.2016 um 05:31 schrieb Grond:
>   Setting up systemd (215-17+deb8u5) ...
>   addgroup: The group `systemd-journal' already exists as a system group. 
> Exiting.
>   dpkg: error processing package systemd (--configure):
>subprocess installed post-installation script returned error exit 
> status 1

...

> `getent` queries for the other systemd users referenced in the above have 
> similar results.
> Apparently, `adduser` returns a non-zero exit status when told to create a 
> user that already
> exists, even if the --quiet flag is given.

If that's the case, then this would be a bug in adduser and not systemd.
I can't reproduce that though

# getent passwd systemd-timesync
systemd-timesync:x:108:113:systemd Time
Synchronization,,,:/run/systemd:/bin/false

# adduser --quiet --system --group --no-create-home --home /run/systemd
--gecos "systemd Time Synchronization" systemd-timesync

# echo $?
0

> Since the whole script is run under `set -e`, when the `adduser` command 
> fails, the entire
> systemd.postist script aborts.

Can you add "set -e" to systemd.postinst and then run
dpkg --configure -a and attach the log. Somehow I suspect the addgroup /
adduser message is a red herring.

> Fixing the problem is as simple as appending ' || true' to the end of each of 
> the
> problematic `adduser` commands

Nope, that would we a hack, not a fix


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



signature.asc
Description: OpenPGP digital signature

Bug#773065: closed by Debian FTP Masters <ftpmas...@ftp-master.debian.org> (Bug#838316: Removed package(s) from unstable)

[Helmut Grohne]

Control: reopen -1
Control: reassign -1 src:gcc-6

On Tue, Sep 20, 2016 at 10:19:12PM +, Debian Bug Tracking System wrote:
> Please allow selecting the target architecture using "dpkg-buildpackage
> --target-arch" again. This ability was removed in 4.9.2-7 when #768167
> was fixed.
> 
> I am attaching a diff that enables target selection via:
>  * dpkg-buildpackage --target-arch
>  * debian/target
>  * DEB_GCC_TARGET

As far as I can tell, the issue is still present in later versions and
a rebased patch is available from cross-gcc-dev (e.g.
http://sources.debian.net/src/cross-gcc/101/patches/gcc-6/0006-Allow-target-selection-via-dpkg-buildpackage-target-.patch/).

Thus reopening.

Helmut

Bug#838392: dpkg: should build-depend on hurd-dev

[Helmut Grohne]

Hi Samuel,

On Wed, Sep 21, 2016 at 12:26:16AM +0200, Samuel Thibault wrote:
> Sure, but dpkg is part of build-essential too, and so AIUI it thus
> needs to explain how it is supposed to build within the build-essential
> bootstrap.

I think Guillem is right here: With our current tools, it is not useful
to add such dependencies. The original error was me installing a too low
stage of hurd-dev (I built the right stage, but apparently failed to
install it, i.e. pebcak). So there are two aspects that could be
improved:

 * We could gain a way to indicate that a source package does not
   implicitly depend on build-essential. Then dpkg, could spell out the
   subset of build-essential it actually needs. This would be very
   useful for bootstrapping, but is not something we can implement
   tomorrow (well, we can: Add a new header ;).

 * Have hurd stop producing packages with varying interfaces. From my
   pov, the real issue is that hurd stage2 produced a hurd-dev package
   that doesn't mean the same thing as the real hurd-dev package. So
   what I'd rather see here is to go the same route as stage1 (which
   doesn't work due to #818618 yet): Rename stage2's hurd-dev to
   something else, have it and the real hurd-dev provide the actual
   functionality and move over the critical rdeps (mainly gcc + glibc).

Neither of these is particularly urgent from my pov, because working
around them is either done already or trivial. But implementing them,
will make bootstrapping easier in the long run.

> At the very best I'd make hurd-dev provide a libps-dev which dpkg would
> depend on, but that'd be purely artificial since we don't actually ever
> build a separate libps-dev package, the stage3 hurd-dev package already
> provides everything that build-essential is supposed to provide.

Yes, that helps for the above mentioned reason.

Thus I suggest to close this bug or turn it into wishlist bugs for the
above.

Helmut

Bug#838432: gnome-packagekit: Update to 3.22

[Jeremy Bicha]

Package: gnome-packagekit
Version: 3.20.0-1
Severity: wishlist
Tags: patch

I see you waited until gnome-packagekit 3.22 was released to update
the Debian package to 3.20. :)

Anyway, I think these patches will help.

Thanks,
Jeremy Bicha


0001-Drop-obsolete-disable-scrollkeeper-configure-flag.patch
Description: Binary data


0002-Drop-obsolete-builddeb-Zxz-it-s-the-default-now.patch
Description: Binary data


0003-Update-install-file-for-renamed-.desktop-files.patch
Description: Binary data


0004-Build-depend-on-autoconf-archive.patch
Description: Binary data


0005-Bump-debhelper-compat-to-10.patch
Description: Binary data

Bug#838431: systemd.postinst fails because the systemd-timesync user already exists when upgrading

[Grond]

Package: systemd
Version: 215-17+deb8u5
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I recently was upgrading my system with `aptitude upgrade`.
Everything was working fine up until dpkg tried to configure the new
version of the systemd package (215-17+deb8u5).
Here is some representative output from aptitude/dpkg:

Setting up systemd (215-17+deb8u5) ...
addgroup: The group `systemd-journal' already exists as a system group. 
Exiting.
dpkg: error processing package systemd (--configure):
 subprocess installed post-installation script returned error exit 
status 1
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
Setting up systemd (215-17+deb8u5) ...
addgroup: The group `systemd-journal' already exists as a system group. 
Exiting.
dpkg: error processing package systemd (--configure):
 subprocess installed post-installation script returned error exit 
status 1
Errors were encountered while processing:
 systemd

In spite of the error messages, which would indicate debain/systemd.postinst 
line 100:

addgroup --system systemd-journal

As the culprit, testing reveals that the problem is line 102:

adduser --quiet --system --group --no-create-home --home /run/systemd \
--gecos "systemd Time Synchronization" systemd-timesync
adduser --quiet --system --group --no-create-home --home 
/run/systemd/netif \
--gecos "systemd Network Management" systemd-network
adduser --quiet --system --group --no-create-home --home 
/run/systemd/resolve \
--gecos "systemd Resolver" systemd-resolve
adduser --quiet --system --group --no-create-home --home /run/systemd \
--gecos "systemd Bus Proxy" systemd-bus-proxy

`getent user systemd-timesync`:

systemd-timesync:x:100:103:systemd Time 
Synchronization,,,:/run/systemd:/bin/false

`getent` queries for the other systemd users referenced in the above have 
similar results.
Apparently, `adduser` returns a non-zero exit status when told to create a user 
that already
exists, even if the --quiet flag is given.
Since the whole script is run under `set -e`, when the `adduser` command fails, 
the entire
systemd.postist script aborts.

Fixing the problem is as simple as appending ' || true' to the end of each of 
the
problematic `adduser` commands

-- Package-specific info:

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
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 systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-59
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-6
ii  libc6   2.19-18+deb8u6
ii  libcap2 1:2.24-8
ii  libcap2-bin 1:2.24-8
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.3-2+deb8u2
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libpam0g1.1.8-3.1+deb8u1+b1
ii  libselinux1 2.3-2
ii  libsystemd0 215-17+deb8u5
ii  mount   2.25.2-6
ii  sysv-rc 2.88dsf-59
ii  udev215-17+deb8u5
ii  util-linux  2.25.2-6

Versions of packages systemd recommends:
ii  dbus1.8.20-0+deb8u1
pn  libpam-systemd  

Versions of packages systemd suggests:
pn  systemd-ui  

-- no debconf information

Bug#794520: linux-image-4.6.1-1~bpo8+1 AMD A8-7100, no thermal information

[Raphaël]

1) Issue about thermal information still exists (4.6.1-1~bpo8+1)
   (I guess my machine sometimes freezes under load because of this)

2) Issue about backlight still exists (4.6.1-1~bpo8+1)
   (even if, hopefully, I can still write values to 
/sys/class/backlight/radeon_bl0/brightness directly)


Any hint/help/upstream bug-report/patch references ?

Bug#838430: volti: traceback on startup

[Toni Mueller]

Package: volti
Version: 0.2.3-7
Severity: important

Dear Maintainer,

I can't use volti because everytime I try to start it, it crashes:

$ volti
[alsactrl.py:__init__:41] can't open Master control for card HDMI,
trying to select first available mixer channel

[alsactrl.py:__init__:49] can't open first available control for card
HDMI
error: list index out of range
Traceback (most recent call last):
  File "/usr/bin/volti", line 52, in 
volti = main.VolumeTray()
  File "/usr/lib/volti/volti/main.py", line 124, in __init__
self.watchid = gobject.io_add_watch(fd, eventmask, self.update)
TypeError: an integer is required
$ 

This happens on a Dell Latitude E7440, which I have installed with
Jessie and then immediately upgraded to Stretch.


Cheers,
Toni



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

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

Versions of packages volti depends on:
ii  python-alsaaudio  0.7-1
ii  python-dbus   1.2.4-1
ii  python-gobject3.21.92-1
ii  python-gtk2   2.24.0-5
ii  python-xlib   0.14+20091101-5
pn  python:any

volti recommends no packages.

volti suggests no packages.

-- no debconf information

Bug#838429: zsh-antigen: broken package - only contains an invalid symlink

[Ondra Lengal]

Package: zsh-antigen
Version: 1.1.2-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I encountered the following bug in unstable that makes the package unusable.
The content of the zsh-antigen package is:

% dtrx -l zsh-antigen_1.1.2-1_all.deb
./
./usr/
./usr/share/
./usr/share/doc/
./usr/share/doc/zsh-antigen/
./usr/share/doc/zsh-antigen/README.Debian
./usr/share/doc/zsh-antigen/README.mkd.gz
./usr/share/doc/zsh-antigen/changelog.Debian.gz
./usr/share/doc/zsh-antigen/changelog.gz
./usr/share/doc/zsh-antigen/copyright
./usr/share/zsh-antigen/
./usr/share/zsh-antigen/antigen.zsh

and the file ./usr/share/zsh-antigen/antigen.zsh is just a symlink to
bin/antigen.zsh (which is not present), so when starting zsh, I just get

.zshrc:source:3: no such file or directory: /usr/share/zsh-antigen/antigen.zsh
.zshrc:6: command not found: antigen
.zshrc:9: command not found: antigen
.zshrc:12: command not found: antigen
.zshrc:13: command not found: antigen
.zshrc:14: command not found: antigen
.zshrc:15: command not found: antigen
.zshrc:16: command not found: antigen
.zshrc:17: command not found: antigen
.zshrc:18: command not found: antigen
.zshrc:21: command not found: antigen

  Best regards,
 Ondra



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

Kernel: Linux 4.5.0-2-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 zsh-antigen depends on:
ii  git  1:2.9.3-1
ii  zsh  5.2-5

zsh-antigen recommends no packages.

zsh-antigen suggests no packages.

-- no debconf information

Bug#803420: gnome shouldn't indirectly depend on packagekit

[Josh Triplett]

On Wed, Sep 21, 2016 at 02:55:38AM +0200, Matthias Klumpp wrote:
> 2016-09-21 0:48 GMT+02:00 Josh Triplett :
> > While it makes sense that gnome-packagekit should depend on packagekit
> > if it can't function without packagekit installed, that then suggests
> > that gnome should recommend gnome-packagekit rather than depending on
> > it.
> >
> > Having packagekit installed has (or had, it might not anymore) some
> > system-wide side-effects,
> 
> Concrete examples please, none of these "effects" should happen unless
> triggered by something else in the system.
> 
> > such as letting gnome-packagekit invoke the
> > systemd offline-upgrade functionality
> 
> gnome-packagekit never does that. GNOME Software however, can do that,
> but that's hardly the fault of PackageKit.
> If anything, this should be solved in GNOME Software, which is the
> sole thing triggering offline-upgrades at time.

Good to know, thank you.  I didn't realize that behavior was limited to
GNOME Software.  That completely addresses my concern.

> > which isn't well-established or
> > tested in Debian.
> 
> I tested that on my machine and in a couple of VMs and couldn't spot
> any issues. The integration with Plymouth could be better, but aside
> from that, I saw no problems.

I don't just mean testing the mechanism itself, but testing its use for
many different variations on system upgrades and software installations.
It isn't the common path, so it doesn't get nearly as much testing.
Changing that would require a significant fraction of unstable and
testing users to actually use the offline update mechanism as their
primary updater for an extended period of time.

- Josh Triplett

Bug#838412: Typo: asyncronously -> asynchronously

[James McCoy]

Control: tag -1 fixed-upstream

On Tue, Sep 20, 2016 at 11:32:44PM +0200, Christoph Biedl wrote:
> lintian[1] complained about a typo in one of the files subversion
> creates on the server side. So I'm asking you to fix this as below
> when convenient.

Thanks!  I've committed the fix upstream.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#832840: license-reconcile: diff for NMU version 0.12+nmu1

[gustavo panizzo (gfa)]

On Tue, Sep 20, 2016 at 06:42:51AM +0800, gustavo panizzo (gfa) wrote:
> On Mon, Sep 19, 2016 at 07:15:50PM +0200, gregor herrmann wrote:
> > On Mon, 19 Sep 2016 00:32:17 +0800, gustavo panizzo (gfa) wrote:
> > 
> > > I've attached the debdiff, I'll push my changes to the git repo after
> > > the NMU has been uploaded, let me know if you don't agree with any of
> > > this.
> > 
> > Thanks for your help.
> > 
> > It might be easier to push the changes to the git repo before an
> > upload, with 0.12 instead of 0.12+nmu1, and we can do a regular tram
> > upload. -- Whatever you prefer.
> 
> I have no preference on the matter, and you are the maintainer.
> I've tried to push to the git repo but I have no perms. so I've attached
> the diff between HEAD and your last commit to this email

or you can clone from
git.debian.org:/srv/home/users/gfa-guest/public_git/license-reconcile



-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: https://keybase.io/gfa

Bug#838428: casacore: FTBFS on sparc64: four FIPS-related tests fail

[Aaron M. Ucko]

Source: casacore
Version: 2.1.0-2
Severity: important
Justification: fails to build from source

The sparc64 build of casacore failed with test errors, as detailed
below.  Could you please take a look?

Thanks!

  Start 370: tfits4
  370/447 Test #370: tfits4 ...***Failed0.14 sec
  Bus error
  FAIL (execution failure): ./tfits4
  
  [...]
  Start 373: tfits_ascTbl
  373/447 Test #373: tfits_ascTbl .***Failed0.15 sec
  Bus error
  FAIL (execution failure): ./tfits_ascTbl
  
  Start 374: tfits_binTbl1
  374/447 Test #374: tfits_binTbl1 ***Failed0.14 sec
  Bus error
  FAIL (execution failure): ./tfits_binTbl1
  
  [...]
  
  Start 431: tFITSExtImage
  431/447 Test #431: tFITSExtImage ***Failed0.26 sec
  2016-09-20 17:31:29 INFOFITSCoordinateUtil::fromFITSHeader  
passing empty or nonexistant spectral Coordinate axis
  2016-09-20 17:31:29 INFOFITSCoordinateUtil::fromFITSHeader  
passing empty or nonexistant spectral Coordinate axis
  2016-09-20 17:31:29 INFOImageFITSConverterImpl::FITSToImage 
Created (temp)image of shape [10, 10]
  2016-09-20 17:31:29 INFOImageFITSConverterImpl::FITSToImage Copy 
FITS file to 'Temporary_Image' All pixels fit in memory (100 pixels).
  2016-09-20 17:31:29 INFOImageFITSConverterImpl::FITSToImage No 
usable restoring beam information found.
  data differ, tol = 1e-05
  1, 0
  aipserror: error (/<>/images/Images/test/tFITSExtImage.cc : 141) 
Failed AlwaysAssert allNear(dataArray, dataMask, fitsArray, fitsMask)
  FAIL (execution failure): ./tFITSExtImage

Bug#838384: krb5-user: k5srvutil man page claims it can add new keys to the keytab, but it cannot

[Benjamin Kaduk]

Hi dkg,

On Tue, 20 Sep 2016, Daniel Kahn Gillmor wrote:

> k5srvutil(1) says:
>
> DESCRIPTION
>k5srvutil allows an administrator to list or change keys currently in a
>keytab or to add new keys to the keytab.
>
> However, the only k5srvutil subcommands are:
>
>  list
>  change
>  delold
>  delete
>
> none of these are capable of adding new keys to the keytab (change
> updates keys to a new version of the key, but that's not what's
> usually meant by "add new keys").

Actually, the documentation is quite poor in this space -- 'change' only
adds the new keys, leaving the old ones in place; 'delold' is required to
remove the old keys (and actually gain the security benefit of fresh keys
for services, since all keys in the keytab, even not-latest-kvno ones,
will be used to accept incoming connections).

It's unclear to me whether this behavior matches up with your perception
of what "add new keys" should mean.  (It is the case that if you want to
add new keys from a password, or even raw keys, you have to use ktutil and
not k5srvutil, which is secretly just a thin wrapper around kadmin.)  So
more input is desired, and then we can work on sending patches upstream.

-Ben

Bug#838427: casacore: FTBFS on hppa: tFFTServer{,2} fail

[Aaron M. Ucko]

Source: casacore
Version: 2.1.0-2
Severity: important
Justification: fails to build from source

The hppa build of casacore failed:

Start 277: tFFTServer
277/447 Test #277: tFFTServer ...***Failed0.48 sec
(/<>/scimath/Mathematics/test/tFFTServer.cc : 1351) Failed 
AlwaysAssert allNearAbs(result, expectedResult, epsilon)
FAIL (execution failure): ./tFFTServer

Start 278: tFFTServer2
278/447 Test #278: tFFTServer2 ..***Failed0.71 sec
(/<>/scimath/Mathematics/test/tFFTServer2.cc : 1099) Failed 
AlwaysAssert !near(result(4).imag(), 0.0f, FLT_EPSILON)
FAIL (execution failure): ./tFFTServer2

Per #838425, there was one other test failure, of test 447 (tConvert).
Could you please take a look?

Thanks!

Bug#830254: casacore: FTBFS on mips64el: three tests fail

[Aaron M. Ucko]

Source: casacore
Version: 2.1.0-2
Followup-For: Bug #830254

As of 2.1.0-2, there are six failures:

274 - tClassicalStatistics (Failed)
277 - tFFTServer (Failed)
278 - tFFTServer2 (Failed)
282 - tHingesFencesStatistics (Failed)
353 - tLCEllipsoid (Failed)
431 - tFITSExtImage (Failed)

https://buildd.debian.org/status/fetch.php?pkg=casacore=mips64el=2.1.0-2=1474401550

Could you please take a look?

Thanks!

Bug#774153: Seems to still be present

[Paul Tagliamonte]

On Tue, Sep 20, 2016 at 06:27:14PM -0400, Paul Tagliamonte wrote:
> I'm not totally sure what's going on here since this is a Jessie ->
> Jessie upgrade, and the version went from 215-17+deb8u4 ->
> 215-17+deb8u5, which makes mismatches in systemctl and the running
> systemd a bit suspect in my mind (same upstream version, right?)

One thing that was bugging me was that the system was restarted after
the change, but upon further reflection, I had a thought that since
udev.postinst never runs, initramfs is never updated, and pid 1 would
still be the "old" initramfs systemd. I wonder if that's part of it?

Also; attached the actual strace. I forgot in my last mail.

Cheers,
  Paul
4475  execve("/bin/systemctl", ["systemctl", "stop", "udev.service"], [/* 12 
vars */]) = 0
4475  brk(0)= 0x7f2905cc4000
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4475  mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f290597c000
4475  access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
4475  open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
4475  fstat(3, {st_mode=S_IFREG|0644, st_size=51491, ...}) = 0
4475  mmap(NULL, 51491, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f290596f000
4475  close(3)  = 0
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4475  open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
4475  read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20o\0\0\0\0\0\0"..., 832) = 832
4475  fstat(3, {st_mode=S_IFREG|0755, st_size=137440, ...}) = 0
4475  mmap(NULL, 2213008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0x7f29052c
4475  mprotect(0x7f29052d8000, 2093056, PROT_NONE) = 0
4475  mmap(0x7f29054d7000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f29054d7000
4475  mmap(0x7f29054d9000, 13456, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f29054d9000
4475  close(3)  = 0
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4475  open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
4475  read(3, 
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\34\2\0\0\0\0\0"..., 832) = 832
4475  fstat(3, {st_mode=S_IFREG|0755, st_size=1738176, ...}) = 0
4475  mmap(NULL, 3844640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0x7f2904f15000
4475  mprotect(0x7f29050b6000, 2097152, PROT_NONE) = 0
4475  mmap(0x7f29052b6000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a1000) = 0x7f29052b6000
4475  mmap(0x7f29052bc000, 14880, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f29052bc000
4475  close(3)  = 0
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4475  open("/lib/x86_64-linux-gnu/libselinux.so.1", O_RDONLY|O_CLOEXEC) = 3
4475  read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20c\0\0\0\0\0\0"..., 832) = 832
4475  fstat(3, {st_mode=S_IFREG|0644, st_size=142728, ...}) = 0
4475  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f290596e000
4475  mmap(NULL, 2246896, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0x7f2904cf
4475  mprotect(0x7f2904d11000, 2097152, PROT_NONE) = 0
4475  mmap(0x7f2904f11000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x21000) = 0x7f2904f11000
4475  mmap(0x7f2904f13000, 6384, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2904f13000
4475  close(3)  = 0
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4475  open("/lib/x86_64-linux-gnu/liblzma.so.5", O_RDONLY|O_CLOEXEC) = 3
4475  read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P(\0\0\0\0\0\0"..., 832) = 832
4475  fstat(3, {st_mode=S_IFREG|0644, st_size=141752, ...}) = 0
4475  mmap(NULL, 2236936, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0x7f2904acd000
4475  mprotect(0x7f2904aef000, 2093056, PROT_NONE) = 0
4475  mmap(0x7f2904cee000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x21000) = 0x7f2904cee000
4475  close(3)  = 0
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4475  open("/lib/x86_64-linux-gnu/libgcrypt.so.20", O_RDONLY|O_CLOEXEC) = 3
4475  read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\216\0\0\0\0\0\0"..., 832) = 
832
4475  fstat(3, {st_mode=S_IFREG|0644, st_size=924096, ...}) = 0
4475  mmap(NULL, 3020448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0x7f29047eb000
4475  mprotect(0x7f29048c3000, 2097152, PROT_NONE) = 0
4475  mmap(0x7f2904ac3000, 40960, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd8000) = 0x7f2904ac3000
4475  close(3)  = 0
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 

Bug#830251: casacore: FTBFS on mips: tests fail or time out

[Aaron M. Ucko]

Source: casacore
Version: 2.1.0-2
Followup-For: Bug #830251

As of 2.1.0-2, the timeouts are gone, but the failures remain.  One is
test 447 (tConvert), per #838425.  The others all involve FITS: test
376 (tFITS) fails with

  An unrecoverable error occurred: 
  (/«PKGBUILDDIR»/fits/FITS/test/tFITS.cc : 94) Unrecoverable AlwaysAssertExit: 
allEQ(m,m2)
  FAIL (execution failure): ./tFITS

and tests 431 (tFITSExtImage), 432 (tFITSExtImageII) and 433
(tFITSImage) all fail with

  Failed AlwaysAssert allNear(dataArray, dataMask, fitsArray, fitsMask)

at various source lines.  Could you please take a look?  You can find
the full log at

https://buildd.debian.org/status/fetch.php?pkg=casacore=mips=2.1.0-2=1474381523

Thanks!

Bug#838410: RFA: ccze -- A robust, modular log coloriser

[Axel Beckert]

Hi,

Tobias Frost wrote:
> The current maintainer of ccze, Stephen Gran ,
> looks for someone to take over this package.

If no one else is interested, I'd take it over.

But maybe Gergely (in Cc) is intererested in taking the package back
as he maintained it in the past and is also the upstream maintainer.

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

Bug#838426: ITP: sirikali -- manage user encrypted volumes

[David Steele]

Package: wnpp
Severity: wishlist
Owner: David Steele 

* Package name: sirikali
  Version : 1.1.0-1
  Upstream Author : Mhogo Mchungu 
* URL : https://mhogomchungu.github.io/sirikali/
* License : GPL
  Programming Lang: C++
  Description : manage user encrypted volumes

 Sirikali provides a Qt/C++ GUI front end for managing FUSE-based
 encrypted file systems, allowing the user to create, mount, and
 unmount encrypted volumes. The services cryfs (ITP[1]), encfs[2]
 gocryptfs, and securefs are supported. It also supports a number of
 key management mechanisms.

 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837127
 [2] https://packages.debian.org/sid/encfs

Bug#805259: automatically move instead of close bugs in removed (upgraded) package versions

[Frank Heckenbach]

I've just experienced another such case after gcc-4.9 was "removed"
(#785249, which was reported upstream, and probably a whole more,
some of which are probably lost now).

PS: It's quite ironic that a bug report in which I also complained
about so many Debian bug reports sitting idly in the bug database
for years has now itself been sitting idly in the database for
almost a year without as much as a single response (not even a
"wontfix" if you don't care about this problem). To repeat myself, I
really wonder why I should report bugs at all anymore. :(

Bug#838425: casacore: FTBFS on armel, armhf, mips, and hppa: tConvert assertion failure

[Aaron M. Ucko]

Source: casacore
Version: 2.1.0-2
Severity: important
Justification: fails to build from source

Builds of casacore on armel, armhf, and mips, and the non-release
architecture hppa all encountered identical assertion failures in test
447 (tConvert):

  Traceback (most recent call last):
File "tConvert.py", line 189, in 
  dotest(t)
File "tConvert.py", line 65, in dotest
  print t.testvh (a);
  RuntimeError: (/«PKGBUILDDIR»/casacore/python/Converters/PycArrayComCC.h : 
310) Failed AlwaysAssert PyArray_ISCONTIGUOUS(po) && PyArray_ISALIGNED(po) && 
!PyArray_ISBYTESWAPPED(po)
  FAIL (execution failure): ./tConvert

On most of these architectures, there was at least one other test
failure, which I'll report separately if I haven't already.

Could you please take a look?

Thanks!

Bug#838424: casacore: FTBFS on arm64 and s390x: several tests fail

[Aaron M. Ucko]

Source: casacore
Version: 2.1.0-2
Severity: important
Justification: fails to build from source

Builds of casacore on arm64 and s390x still encounter several test
failures even with -fsigned-char in effect:

- Tests 244 (tLSQaips), 245 (tLSQFit), 353 (tLCEllipsoid), and 431
  (tFITSExtImage) fail with identical numeric discrepancies.

- Tests 274 (tClassicalStatistics) and 282 (tHingesFencesStatistics)
  both fail with no further details reported.

Could you please take a look?

Thanks!

Bug#838423: casacore: FTBFS on non-Linux: linux//nfs_fs.h: No such file or directory

[Aaron M. Ucko]

Source: casacore
Version: 2.1.0-2
Severity: important
Justification: fails to build from source

Builds of casacore for kFreeBSD and the Hurd are failing:

  /<>/casa/OS/Directory.cc:493:27: fatal error: linux//nfs_fs.h: 
No such file or directory

Please fix this file to account for operating systems other than Linux
and Mac OS X.

Thanks!

Bug#838422: casacore: FTBFS on PowerPC variants: HostInfo prototype mismatches

[Aaron M. Ucko]

Source: casacore
Version: 2.1.0-2
Severity: important
Justification: fails to build from source

Thanks for looking into my previous reports.

Alas, builds of casacore on PowerPC variants (powerpc and ppc64el, and
the non-release ppc64 architecture) are now failing:

  cd /«PKGBUILDDIR»/obj-powerpc-linux-gnu/casa && /usr/bin/c++   
-DCFITSIO_VERSION_MAJOR=3 -DCFITSIO_VERSION_MINOR=380 -DHAVE_FFTW3 
-DHAVE_FFTW3_THREADS -DHAVE_READLINE -DUSE_THREADS -DWCSLIB_VERSION_MAJOR=5 
-DWCSLIB_VERSION_MINOR=15 -Dcasa_casa_EXPORTS -I/«PKGBUILDDIR» 
-I/«PKGBUILDDIR»/obj-powerpc-linux-gnu  -fcx-fortran-rules -g -O2 
-fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -fsigned-char 
-std=c++11 -pthread -fPIC   -o CMakeFiles/casa_casa.dir/OS/HostInfo.cc.o -c 
/«PKGBUILDDIR»/casa/OS/HostInfo.cc
  /«PKGBUILDDIR»/casa/OS/HostInfo.cc:259:5: error: prototype for 'casa::Int 
casa::HostInfo::numCPUs()' does not match any in class 'casa::HostInfo'
   Int HostInfo::numCPUs( ) { return 0; }
   ^~~~
  In file included from /«PKGBUILDDIR»/casa/OS/HostInfo.cc:30:0:
  /«PKGBUILDDIR»/casacore/casa/OS/HostInfo.h:116:16: error: candidate is: 
static casa::Int casa::HostInfo::numCPUs(bool)
   static Int numCPUs(bool use_aipsrc=false);
  ^~~
  /«PKGBUILDDIR»/casa/OS/HostInfo.cc:260:11: error: prototype for 'ptrdiff_t 
casa::HostInfo::memoryTotal()' does not match any in class 'casa::HostInfo'
   ptrdiff_t HostInfo::memoryTotal( ) { return -1; }
 ^~~~
  In file included from /«PKGBUILDDIR»/casa/OS/HostInfo.cc:30:0:
  /«PKGBUILDDIR»/casacore/casa/OS/HostInfo.h:121:22: error: candidate is: 
static ptrdiff_t casa::HostInfo::memoryTotal(bool)
   static ptrdiff_t memoryTotal(bool use_aipsrc=false);
^~~

AFAICT, the issue is that, on these architectures, g++ in strict
-std=c++11 mode doesn't predefine __linux, just __linux__, so
aipsenv.h leaves AIPS_LINUX undefined and HostInfo.cc falls back on
stubs that don't match HostInfo.h's prototypes.  (FWIW, there's no
such problem in -std=gnu++11 mode.)

Could you please take a look?

Thanks!

Bug#803420: gnome shouldn't indirectly depend on packagekit

[Matthias Klumpp]

2016-09-21 0:48 GMT+02:00 Josh Triplett :
> While it makes sense that gnome-packagekit should depend on packagekit
> if it can't function without packagekit installed, that then suggests
> that gnome should recommend gnome-packagekit rather than depending on
> it.
>
> Having packagekit installed has (or had, it might not anymore) some
> system-wide side-effects,

Concrete examples please, none of these "effects" should happen unless
triggered by something else in the system.


> such as letting gnome-packagekit invoke the
> systemd offline-upgrade functionality

gnome-packagekit never does that. GNOME Software however, can do that,
but that's hardly the fault of PackageKit.
If anything, this should be solved in GNOME Software, which is the
sole thing triggering offline-upgrades at time.

> which isn't well-established or
> tested in Debian.

I tested that on my machine and in a couple of VMs and couldn't spot
any issues. The integration with Plymouth could be better, but aside
from that, I saw no problems.

> While I'd love to see Debian using that
> infrastructure eventually, right now having packagekit installed may
> lead to serious unexpected problems.

Such as? If that happens, we will get bug reports, and fix bugs ;-)
(KDE has had packagekit installed by default for ages, with zero
complaints about any unexpected things happening (with the exception
of not being able to use apt when the cache is locked by pkd))

Cheers,
Matthias

Bug#838421: python-xlsxwriter: New upstream version available / intent to NMU

[Hilko Bengen]

Package: python-xlsxwriter
Version: 0.7.3-1
Severity: wishlist

Hi,

plaso 1.5.0 which I'd like to upload requires python-xlswriter 0.9.3.
Based upon the packaging git at
https://anonscm.debian.org/git/python-modules/packages/xlsxwriter.git, I
have created a new upstream version with otherwise minimal changes which
I'd like to NMU.

Cheers,
-Hilko

Bug#838420: gifsicle: incorrect escape for 8-bit characters on platforms with signed char

[Yuriy M. Kaminskiy]

Package: gifsicle
Version: 1.86-1
Severity: minor
Tags: upstream patch

Dear Maintainer,

When showing comment containing non-ASCII characters, `gifsicle -I` 
shows incorrect escape code (\364 instead of \364) on platforms 
with signed char (e.g. x86{,_64}).

Patches against 1.86 and 1.88 attached.

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

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

Versions of packages gifsicle depends on:
ii  libc6 2.19-18+deb8u4
ii  libice6   2:1.0.9-1+b1
ii  libsm62:1.2.2-1+b1
ii  libx11-6  2:1.6.2-3

gifsicle recommends no packages.

gifsicle suggests no packages.

-- no debconf information

Index: gifsicle-1.86/src/support.c
===
--- gifsicle-1.86.orig/src/support.c
+++ gifsicle-1.86/src/support.c
@@ -310,7 +310,7 @@ safe_puts(const char *s, uint32_t len, F
case '\v': fputs("\\v", f); break;
case '\\': fputs("", f); break;
case 0:	  if (len > 1) fputs("\\000", f); break;
-   default:	  fprintf(f, "\\%03o", *s); break;
+   default:	  fprintf(f, "\\%03o", *s & 0xFF); break;
   }
 }
   if (last_safe != s) {

Index: gifsicle-1.88/src/support.c
===
--- gifsicle-1.88.orig/src/support.c
+++ gifsicle-1.88/src/support.c
@@ -311,7 +311,7 @@ safe_puts(const char *s, uint32_t len, F
case '\v': fputs("\\v", f); break;
case '\\': fputs("", f); break;
case 0:if (len > 1) fputs("\\000", f); break;
-   default:   fprintf(f, "\\%03o", *s); break;
+   default:   fprintf(f, "\\%03o", *s & 0xFF); break;
   }
 }
   if (last_safe != s) {

Bug#837649: debootstrap: Add support for Packages.xz

[Ansgar Burchardt]

Ansgar Burchardt writes:
> debootstrap should support archives that only provide Packages.xz.
>
> I'll try to take a look at implementing this soon.  From a quick glance
> it shouldn't be too difficult given several compression formats are
> already supported (bz2, gz, uncompressed).

I've prepared a patch for this[1].  It worked for me with both a
Packages.xz suite (stretch) and one only providing Package.bz2, but not
.xz (squeeze).

Ansgar

  [1] 
https://github.com/aburch/debootstrap/commit/1689d645aacb0bc3f9edb86526f67e776469942a

Bug#755848: Patch

[Eric Desrochers]

This patch include a script under finish-install.d/56netcfg-hostname that 
detect if netcfg/hostname is set in preseed file and override the hostname at 
the end of the installation. If not set then it keeps the hostname as is.
>From 53522b8129f9542a1d7c9a21344d8b8b2732c9ce Mon Sep 17 00:00:00 2001
From: Eric Desrochers 
Date: Tue, 20 Sep 2016 20:02:16 -0400
Subject: [PATCH] Fix netcfg/hostname that does not set hostname

---
 finish-install.d/56netcfg-hostname | 17 +
 1 file changed, 17 insertions(+)
 create mode 100755 finish-install.d/56netcfg-hostname

diff --git a/finish-install.d/56netcfg-hostname b/finish-install.d/56netcfg-hostname
new file mode 100755
index 000..2256c5b
--- /dev/null
+++ b/finish-install.d/56netcfg-hostname
@@ -0,0 +1,17 @@
+#! /bin/sh
+set -e
+
+PROGNAME=$(basename $0)
+CURRENT_HOSTNAME=`/bin/hostname`
+NETCFG_HOSTNAME=`/bin/debconf-get netcfg/hostname`
+
+# Override hostname, if "netcfg/hostname" is set in preseed file. #
+if [ -n "$NETCFG_HOSTNAME" ]; then
+/bin/sed -i "s/$CURRENT_HOSTNAME/$NETCFG_HOSTNAME/" /target/etc/hostname
+/bin/sed -i "s/$CURRENT_HOSTNAME/$NETCFG_HOSTNAME/" /target/etc/hosts
+/usr/bin/logger "$PROGNAME: d-i netcfg/hostname $NETCFG_HOSTNAME took precedence"
+
+# Keep hostname as is, if "netcfg/hostname" is not set in preseed file. #
+else
+exit 0
+fi
-- 
2.5.0

Bug#831754: enabling tap to click is missing

[Michael Biebl]

Version: 3.22.0-1

On Tue, 19 Jul 2016 10:10:01 +0530 Pirate Praveen 
wrote:
> package: gnome-control-center
> version: 1:3.20.1-2
> severity: important
> 
> Tap to click is a popular option for touchppads and this option was
> available in jessie. Its a regression.
> 

This has been fixed in 3.22


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



signature.asc
Description: OpenPGP digital signature

Bug#830178: I cannot reproduce it

[Santiago Vila]

I also attach one of the files which are supposed to be useful
to debug this: /tmp/sphinx-err-pW9FlZ.log from one of the builds.

Thanks.
# Sphinx version: 1.4.6
# Python version: 2.7.12+ (CPython)
# Docutils version: 0.12 release
# Jinja2 version: 2.8
# Last messages:
#   /build/mako-1.0.4+ds1/doc/build/usage.rst:175: WARNING: py:class reference 
target not found: Lexer
#   /build/mako-1.0.4+ds1/doc/build/usage.rst:175: WARNING: py:class reference 
target not found: Lexer
#   /build/mako-1.0.4+ds1/doc/build/usage.rst:5: WARNING: py:class reference 
target not found: object
#   /build/mako-1.0.4+ds1/doc/build/usage.rst:51: WARNING: py:class reference 
target not found: NotImplementedError
#   /build/mako-1.0.4+ds1/doc/build/usage.rst:51: WARNING: py:class reference 
target not found: TemplateLookupException
#   /build/mako-1.0.4+ds1/doc/build/usage.rst:5: WARNING: py:class reference 
target not found: object
#   generating indices...
#   genindex
#   The name of the builder is: html
#   The name of the builder is: html
# Loaded extensions:
#   sphinx.ext.autodoc (1.4.6) from 
/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.pyc
#   sphinx.ext.intersphinx (1.4.6) from 
/usr/lib/python2.7/dist-packages/sphinx/ext/intersphinx.pyc
#   changelog (unknown version) from 
/usr/lib/python2.7/dist-packages/changelog/__init__.pyc
#   builder.builders (unknown version) from 
/build/mako-1.0.4+ds1/doc/build/builder/builders.py
#   alabaster (0.7.8) from 
/usr/lib/python2.7/dist-packages/alabaster/__init__.pyc
#   sphinx_paramlinks (unknown version) from 
/usr/lib/python2.7/dist-packages/sphinx_paramlinks/__init__.pyc
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/sphinx/cmdline.py", line 244, in main
app.build(opts.force_all, filenames)
  File "/usr/lib/python2.7/dist-packages/sphinx/application.py", line 297, in 
build
self.builder.build_update()
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py", line 
251, in build_update
'out of date' % len(to_build))
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py", line 
325, in build
self.finish()
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/html.py", line 462, in 
finish
self.finish_tasks.add_task(self.gen_indices)
  File "/usr/lib/python2.7/dist-packages/sphinx/util/parallel.py", line 40, in 
add_task
res = task_func()
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/html.py", line 478, in 
gen_indices
self.write_genindex()
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/html.py", line 538, in 
write_genindex
self.handle_page('genindex', genindexcontext, 'genindex.html')
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/html.py", line 803, in 
handle_page
output = self.templates.render(templatename, ctx)
  File "/build/mako-1.0.4+ds1/doc/build/builder/builders.py", line 70, in render
return self.lookup.get_template(template).render_unicode(**context)
  File "/build/mako-1.0.4+ds1/mako/template.py", line 454, in render_unicode
as_unicode=True)
  File "/build/mako-1.0.4+ds1/mako/runtime.py", line 829, in _render
**_kwargs_for_callable(callable_, data))
  File "/build/mako-1.0.4+ds1/mako/runtime.py", line 864, in _render_context
_exec_template(inherit, lclcontext, args=args, kwargs=kwargs)
  File "/build/mako-1.0.4+ds1/mako/runtime.py", line 890, in _exec_template
callable_(context, *args, **kwargs)
  File "base_mako", line 64, in render_body
  File "layout_mako", line 178, in render_body
  File "genindex_mako", line 71, in render_body
ValueError: too many values to unpack

Bug#838343: linux-image-4.6.0-1-amd64: allow a patch that makes elder radeon cards UltraHD ready

[Ben Hutchings]

Control: tag -1 moreinfo

Please let us know when these have been reviewed and accepted upstream.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment
destroyed.
 - Carolyn
Scheppner


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

Bug#817656: root-tail: Removal of debhelper compat 4

[Axel Beckert]

Hi Francesco,

Francesco Poli wrote:
> On Sun, 28 Aug 2016 16:08:03 +0200 Francesco Poli wrote:
> > I am a user of root-tail and I find it very nice and useful.
> > Thanks for maintaining it in Debian!
> > 
> > However, I am beginning to worry about the status of this package:
> > it has been removed from Debian testing, because of the RC bug I am
> > replying to (#817656), it has stayed out of Debian testing since then
> > and I cannot see any visible progress in addressing the issue.
> > 
> > Are you working on the packaging issues? Will they be solved soon?
> > If so, could you please send a status update to the bug address?

root-tail has just been orphaned by the MIA team on behalf of Stephen
Gran, see https://bugs.debian.org/838406.

I'm preparing a QA upload of root-tail fixing this bug and updating
the packaging to the current state of the art.

I also created a packaging git repository at
https://anonscm.debian.org/cgit/collab-maint/root-tail.git/ (will be
visibile in about an hour or so) for future root-tail maintenance.

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

Bug#830178: I cannot reproduce it

[Santiago Vila]

You will have to keep trying, then.

I attach five different build logs from five different autobuilders,
and it's not just me who can reproduce this, it's also reproducible
here:

https://tests.reproducible-builds.org/debian/rb-pkg/testing/amd64/mako.html

The only thing I can say are general things, for example:

* Try installing exactly the same list of packages I install by default
in my chroot. While this list does indeed contain some non-build-essential
packages like debhelper, doing so will increase the probability that
you can also reproduce this.

See "list.txt" attached.

* Try to use sbuild (as I do) to build the package and make a diff
between your build log and any of the ones I'm attaching here.

* I'm using sbuild in this way:

sbuild --resolve-alternatives --arch-all --no-arch-any -d ${dist} 
${package}_${version}

In this case dist is "stretch" and ${package}_${version} is "mako_1.0.4+ds1-1".

* In .sbuildrc I have a line like this one:

$ENV{'DEB_BUILD_OPTIONS'} = 'parallel=1';

This should really be enough, this is not a FTBFS which happens randomly
(I've reported several of those, and they are a lot more difficult to debug),

This one should be reproducible every time.

Thanks.


mako_1.0.4+ds1-1_amd64-20160920T222901Z.gz
Description: application/gzip


mako_1.0.4+ds1-1_amd64-20160920T222902Z.gz
Description: application/gzip


mako_1.0.4+ds1-1_amd64-20160920T222905Z.gz
Description: application/gzip


mako_1.0.4+ds1-1_amd64-20160920T222908Z.gz
Description: application/gzip


mako_1.0.4+ds1-1_amd64-20160920T230802Z.gz
Description: application/gzip
adduser
apt
autoconf
automake
autopoint
autotools-dev
base-files
base-passwd
bash
binutils
bsdmainutils
bsdutils
build-essential
bzip2
coreutils
cpp
cpp-6
dash
debconf
debhelper
debian-archive-keyring
debianutils
dh-autoreconf
dh-strip-nondeterminism
diffutils
dpkg
dpkg-dev
e2fslibs
e2fsprogs
eatmydata
fakeroot
file
findutils
g++
g++-6
gcc
gcc-5-base
gcc-6
gcc-6-base
gettext
gettext-base
gpgv
grep
groff-base
gzip
hostname
init-system-helpers
insserv
intltool-debian
less
libacl1
libapt-pkg5.0
libarchive-zip-perl
libasan3
libatomic1
libattr1
libaudit-common
libaudit1
libblkid1
libbsd0
libbz2-1.0
libc-bin
libc-dev-bin
libc-l10n
libc6
libc6-dev
libcap-ng0
libcc1-0
libcilkrts5
libcomerr2
libcroco3
libdb5.3
libdebconfclient0
libdpkg-perl
libeatmydata1
libfakeroot
libfdisk1
libffi6
libfile-stripnondeterminism-perl
libgcc-6-dev
libgcc1
libgcrypt20
libgdbm3
libglib2.0-0
libgmp10
libgomp1
libgpg-error0
libicu57
libisl15
libitm1
liblsan0
liblz4-1
liblzma5
libmagic-mgc
libmagic1
libmount1
libmpc3
libmpfr4
libmpx2
libncurses5
libncursesw5
libpam-modules
libpam-modules-bin
libpam-runtime
libpam0g
libpcre3
libperl5.22
libpipeline1
libquadmath0
libselinux1
libsemanage-common
libsemanage1
libsepol1
libsigsegv2
libsmartcols1
libss2
libstdc++-6-dev
libstdc++6
libsystemd0
libtimedate-perl
libtinfo5
libtool
libtsan0
libubsan0
libudev1
libunistring0
libustr-1.0-1
libuuid1
libxml2
linux-libc-dev
locales
login
m4
make
man-db
mawk
mount
multiarch-support
nano
ncurses-base
ncurses-bin
passwd
patch
perl
perl-base
perl-modules-5.22
po-debconf
sed
sensible-utils
startpar
sysv-rc
sysvinit-utils
tar
tzdata
util-linux
xz-utils
zlib1g

Bug#250337: ITS Service Help Desk

[Romas Kerry]

Dear E-mail User

Please Log on to OutlookWeb Access to update 
your outlook account to the new secured version.

Thank You






















This information is directed in confidence solely to the person named above and 
may not otherwise be distributed, copied or disclosed. Therefore, this 
information should be considered strictly confidential. If you have received 
this email in error, please notify the sender immediately via a return email 
for further direction. Thank you for your assistance.

Bug#837372: #3872: when using gpgme, the signature information is brightyellow making it difficult to read

[Mutt]

#3872: when using gpgme, the signature information is brightyellow making it
difficult to read
+--
  Reporter:  antonio@…  |  Owner:  mutt-dev
  Type:  defect | Status:  closed
  Priority:  minor  |  Milestone:
 Component:  crypto |Version:  1.7.0
Resolution:  fixed  |   Keywords:
+--
Changes (by Antonio Radici ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"405cbc43c3acc6cec944110f4a8d8b0b1977d4f8"
 6793:405cbc43c3ac]:
 {{{
 #!CommitTicketReference repository=""
 revision="405cbc43c3acc6cec944110f4a8d8b0b1977d4f8"
 Use body color for gpgme output. (closes #3872)

 When switching from pgp_* commands to crypt_use_gpgme=yes, Peter
 Colberg noticed that the output was colored 'brightyellow'.

 The issue is that crypt-gpgme.c uses state_attach_puts in various
 places where it should use state_puts to maintain compatibility with
 the previous behavior in pgp.c.
 }}}

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Bug#803420: gnome shouldn't indirectly depend on packagekit

[Josh Triplett]

While it makes sense that gnome-packagekit should depend on packagekit
if it can't function without packagekit installed, that then suggests
that gnome should recommend gnome-packagekit rather than depending on
it.

Having packagekit installed has (or had, it might not anymore) some
system-wide side-effects, such as letting gnome-packagekit invoke the
systemd offline-upgrade functionality, which isn't well-established or
tested in Debian.  While I'd love to see Debian using that
infrastructure eventually, right now having packagekit installed may
lead to serious unexpected problems.

- Josh Triplett

Bug#706362: Bug #706362: bacula-director-pgsql: upgrade scripts may not set permissions

[Carsten Leonhardt]

Control: tag -1 moreinfo

Hi,

I'm looking through old bug reports for the bacula package.

You reported wrong/missing access privileges after restoring an old
catalog backup and then manually upgrading it by running the upgrade
scripts.

You noted that some tables have empty access privileges, while most had
specific privileges for bacula.

On current installations, the column "Access privileges" in the \dp
output of psql is empty, yet everything works, including running the
upgrade scripts as the bacula user. Did you actually have problems after
your restore+upgrade and before further changing the access privileges?

 - Carsten

Bug#838411: liblegacytaskmanager5 shows up as broken

[Diederik de Haas]

On woensdag 21 september 2016 03:01:16 CEST shirish शिरीष wrote:
> liblegacytaskmanager5 shows up as broken, have no idea why.
> 
> ┌─[shirish@debian] - [~] - [10047]
> └─[$] aptitude search \~b  | grep liblegacytaskmanager5
> 
> iB liblegacytaskmanager5 - Plasma Workspace for KF5 library

Have you tried 'aptitude reinstall liblegacytaskmanager5' ?
It usually fixes things or tell you why it is broken; both sound useful and 
worth a try.

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

Bug#838418: libreoffice-gtk3: Font corruption - both content and dialogs

[Simon John]

Package: libreoffice-gtk3
Version: 1:5.2.1-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Upgrade of libreoffice. It was definitely working fine on August 16th,
then I haven't done any upgrades until this last week, so I suspect the
move from 5.2.0 to 5.2.1

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

Loaded a spreadsheet, then changed a filter or preference that caused
the display to refresh.

   * What was the outcome of this action?

Cell content was illegible - sometimes just garbarge, sometimes the
characters were replaced with other (random?) characters, sometimes some
characters were emboldened.

Also dialog boxes were corrupted - such as the save/discard/cancel
buttons, and even the text in the input line.

I tried various things - deleting the user profile, running as root,
rolling back to 5.2.1-1, reinstalling fonts, nothing worked other than
uninstalling libreoffice-gtk3.

Its not a driver issue as I get the same problem on Nvidia (nouveau)
desktop and Intel laptop.



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

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
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 libreoffice-gtk3 depends on:
ii  dpkg  1.18.10
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-3
ii  libcairo-gobject2 1.14.6-1+b1
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.10-1
ii  libdbus-glib-1-2  0.108-1
ii  libgcc1   1:6.2.0-4
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libgl1-mesa-glx [libgl1]  12.0.3-1
ii  libglew2.02.0.0-3
ii  libglib2.0-0  2.49.7-1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgtk-3-03.21.6-1
ii  libice6   2:1.0.9-1+b1
ii  libpango-1.0-01.40.2-1
ii  libpangocairo-1.0-0   1.40.2-1
ii  libreoffice-core  1:5.2.1-3
ii  libsm62:1.2.2-1+b1
ii  libstdc++66.2.0-4
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  uno-libs3 5.2.1-3
ii  ure   5.2.1-3

Versions of packages libreoffice-gtk3 recommends:
ii  libreoffice-style-tango  1:5.2.1-3

Versions of packages libreoffice-gtk3 suggests:
ii  libreofficekit-data  1:5.2.1-3

-- no debconf information

Bug#838417: ITP: go-wire -- Go library for encoding/decoding structures into binary and JSON format

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: go-wire
  Version : 1.0
  Upstream Author : the Tendermint Project
* URL : https://github.com/tendermint/go-wire
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library for encoding/decoding structures into binary and 
JSON format


 This software implements Go bindings for the Wire
 encoding protocol. The goal of the Wire encoding
 protocol is to be a simple language-agnostic
 encoding protocol for rapid prototyping of
 blockchain applications.
 .
 This package also includes a compatible (and
 slower) JSON codec.

Bug#838392: dpkg: should build-depend on hurd-dev

[Samuel Thibault]

Guillem Jover, on Wed 21 Sep 2016 00:17:05 +0200, wrote:
> On Tue, 2016-09-20 at 21:26:16 +0200, Samuel Thibault wrote:
> > dpkg needs to build-depend on hurd-dev because it uses  and
> > . It happens that libc0.3-dev depends on it, and thus hurd-dev
> > gets pulled on a normal system. But when bootstrapping, libc0.3-dev does
> > not depend on hurd-dev yet. So dpkg should explicitly build-depend on
> > hurd-dev to be able to be compiled with the bootstrap libc build.
> 
> As I replied to Helmut when he brought this up on IRC, I think adding
> what you proposed would be (currently) wrong. hurd-dev is already
> build-essential, and if we have to spell those explicitly we might as
> well stop having build-essential at all.

Sure, but dpkg is part of build-essential too, and so AIUI it thus
needs to explain how it is supposed to build within the build-essential
bootstrap.

> If this is causing problems when rebootstrapping, then this tells me
> we might need some stages somewhere or some build profile restricted
> dependencies, new virtual packages, or packages split or…

At the very best I'd make hurd-dev provide a libps-dev which dpkg would
depend on, but that'd be purely artificial since we don't actually ever
build a separate libps-dev package, the stage3 hurd-dev package already
provides everything that build-essential is supposed to provide.

Samuel

Bug#774153: Seems to still be present

[Paul Tagliamonte]

found 774153 215-17+deb8u5
tags 774153 - moreinfo
retitle 774153 systemd-tty-ask-password hangs udev postinst until daemon-reexec 
is run
thanks

A friend of mine hit this bug, and it presented in a pretty nasty way.
Some details:

The system was running Jessie, and upgraded from Wheezy when Jessie came
out. The system was restarted 8 days ago, and had this issue present
itself when systemd/udev was updated. The system was running
215-17+deb8u4 before installing 215-17+deb8u5.

In udev's postinst, it asks for a udev stop, which winds up hanging
because systemctl is asking systemd-tty-ask-password-agent for something.

This causes dpkg to hang because the postinst hangs. This wound up
causing a bit of a headache in an (routine!) stable upgrade, and this
caused a friend bunch of lost time to strace trying to track this one
down.

After a bit of digging, I came accross this bug which sounded similar
enough that I tried a `systemctl daemon-reexec`. This wound up fixing
udev from blocking, and let my friend finish the system upgrade.

I'm not totally sure what's going on here since this is a Jessie ->
Jessie upgrade, and the version went from 215-17+deb8u4 ->
215-17+deb8u5, which makes mismatches in systemctl and the running
systemd a bit suspect in my mind (same upstream version, right?)

As such, I've retitled the bug according to my latest understanding of
this problem. I've also removed the moreinfo tag.

I've attached an strace of the stop that was sent to me, I've CC'd
weaver as well. Happy to provide more thoughts, but I don't know how to
reproduce this, so I tried to dump as much as I know about the failure
mode.


FWIW, this seems like it is still a bug that impacts stable -- I don't
want to play severity ping-pong, but bumping this above normal might be
worth it.

<3,
   paultag


signature.asc
Description: PGP signature

Bug#838392: dpkg: should build-depend on hurd-dev

[Guillem Jover]

Hi!

On Tue, 2016-09-20 at 21:26:16 +0200, Samuel Thibault wrote:
> Package: dpkg
> Version: 1.18.10
> Severity: normal
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap

> dpkg needs to build-depend on hurd-dev because it uses  and
> . It happens that libc0.3-dev depends on it, and thus hurd-dev
> gets pulled on a normal system. But when bootstrapping, libc0.3-dev does
> not depend on hurd-dev yet. So dpkg should explicitly build-depend on
> hurd-dev to be able to be compiled with the bootstrap libc build.

As I replied to Helmut when he brought this up on IRC, I think adding
what you proposed would be (currently) wrong. hurd-dev is already
build-essential, and if we have to spell those explicitly we might as
well stop having build-essential at all.

If this is causing problems when rebootstrapping, then this tells me
we might need some stages somewhere or some build profile restricted
dependencies, new virtual packages, or packages split or…

Thanks,
Guillem

Bug#838388: debootstrap: Fails to strap squeeze since 1.0.83

[Ansgar Burchardt]

tag 838388 + patch
thanks

Ansgar Burchardt writes:
> Ah, I'm to blame for that.  [1] added `-k` to the options passed to tar
> in order to avoid replacing the new symlinks from / to /usr with real
> directories.  However it looks like tar returns an error when there are
> actual file conflicts (as opposed to just symlink vs. directory).
>
> Only adding -k for newer distributions (i.e. the ones that merged-/usr
> supports) should work around the problem.

I pushed a patch implementing this to my debootstrap repository[2].  It
worked for Squeeze (w/o merged-/usr) and Stretch (w/ merged-/usr).

Ansgar

  [2] 
https://github.com/aburch/debootstrap/commit/5bb1da69596828821fe43b3ee63f733e4b8672e7

Bug#838379: dpkg-dev: Add Testsuite: autopkgtest when a debian/tests/control.autodep8 exists

[Guillem Jover]

Control: severity -1 wishlist
Control: tag -1 moreinfo

On Tue, 2016-09-20 at 13:16:14 -0400, Barry Warsaw wrote:
> Package: dpkg-dev
> Version: 1.18.10
> Severity: normal

> I have a Python package that only contains a d/tests/control.autodep8
> file, not a d/tests/control file.  This requires the addition of an
> explicit Testsuite: autopkgtest-pkg-python header to d/control whereas
> the existance of d/tests/control would add this automatically.  IWBNI
> the same logic applied to d/tests/control.autodep8

There are multiple problems with this request. First that control file
is not documented in the autopkgtest spec AFAICS, it seems to be
documented in the autodep8 package though. Knowing what to use as the
Testsuite value would imply replicating the same logic autodep8 has
to infer what kind of tests are to be run, with all the Debian specic
policy that that implies (package names, etc).

(This is very mild annoyance, but every time I see a “depN” reference,
I've to lookup those names, and we have less than 20 AFAIR, they are
still very non-intuitive, I'd rather not see those extend. :)

As it stands I don't think I'd want to see this implemented in
dpkg-dev. Because if such file contained the type of pkg the test are
supposed to use so that dpkg-dev could pick that up, then one might as
well spell it instead in the debian/control file?

Thanks,
Guillem

Bug#837940: gnome-twitch-player-backend-mpv-opengl: immediate segmentation fault

[Tim Dengel]

Hi Jonas,

since apparently replies to bugs are not automatically sent to the
submitter, you probably didn't get my previous message. Sorry for that :(

Anyways, here it is:



On Thu, 15 Sep 2016 19:58:39 +0200 Jonas Smedegaard  wrote:
> Package: gnome-twitch-player-backend-mpv-opengl
> Version: 0.3.0-1
> Severity: grave
> Justification: renders package unusable
>
> Selecting mpv backend immediately causes segmentation fault.

Hi Jonas,

I can not reproduce this. Can you provide one (or more) of the following
things?

1. Log messages (i.e. run gnome-twitch in a terminal, maybe with a lower
logging level by giving it "--log-level=debug" or something as an argument)

2. A backtrace (install the dbgsym packages for gnome-twitch and
gnome-twitch-player-backend-mpv-opengl and run gnome-twitch in gdb, then
get a full backtrace with the "bt full" command.

3. A core dump (I would rather prefer the first two, if they are meaningful)

It would also be interesting to know what kind of graphics hardware you
have (Intel, NVIDIA, AMD...) and if you have tried other backends (and
whether they work). From your report it seems that the segfault happens
directly on selecting the backend, not on playback, is that correct?
Were you selecting it from the settings dialog[1] outside of a stream,
or when you were prompted to select one when trying to watch a stream?
Does the same happen when you try the other one of the two methods?

Sincerely,
Tim Dengel


[1] You can reach that dialog by clicking on the "gnome-twitch" item in
gnome's "task bar" and then selecting "settings"

Bug#838416: ITP: roughtime -- Secure time synchronisation

[Chris Lamb]

Package: wnpp
Severity: wishlist
Owner: Chris Lamb 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: roughtime
  Upstream Author : Google, Inc.
* URL : https://roughtime.googlesource.com/roughtime
* License : Apache 2.0
  Programming Lang: Go
  Description : Secure time synchronisation

Roughtime is a protocol that aims to achieve rough time synchronisation
in a secure way that doesn't depend on any particular time server, and
in such a way that, if a time server does misbehave, clients end up with
cryptographic proof of it.

  -- 


Regards,

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

Bug#720260: Deprecated ?

[Aurélien COUDERC]

Reassigning to Gnome as it’s more about Gnome environment than desktop-base
that’s about theming for Debian.

The program you must be refering to must be « assogiate » which was a
GTK2 file
association editor. It’s been deprecated and not packaged anymore starting
with Jessie.
Maybe the files association functionality available in Nautilus default
file
manager (right click, Properties, Open With tab) could be considered a
sufficient replacement ?


Regards,
--Aurélien

Bug#838414: gpick: colors.txt is non-free

[Francesco Poli]

Control: found -1 gpick/0.2.4-1


On Tue, 20 Sep 2016 23:46:04 +0200 Francesco Poli (wintermute) wrote:

> Package: gpick
> Version: 0.2.5-2

I see that the non-free restriction is not new: I am therefore marking
this bug as found in the oldstable version of the package...


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


pgpmpNqKpsqYl.pgp
Description: PGP signature

Bug#644240: bat: ASSERT failure in QList::operator[]: "index out of range"

[Carsten Leonhardt]

Control: tag -1 + moreinfo unreproducible

Bună Teodor,

I was looking at this old bug report:

> Sometimes when I select to restore "All files" from a specific job,
> 'bat' will crash with this message:
> | ASSERT failure in QList::operator[]: "index out of range", file
> |   /usr/include/qt4/QtCore/qlist.h, line 447
> | Aborted

do you still have this problem with a current bacula version?

I can't reproduce this with version 7.4.3 with the information I have.

 - Carsten

Bug#838395: libvdpau FTCBFS: fails to pass --host to configure

[Luca Boccassi]

On Tue, 2016-09-20 at 23:35 +0200, Andreas Beckmann wrote:
> Control: tag -1 pending
> 
> On 2016-09-20 21:43, Helmut Grohne wrote:
> > libvdpau fails to cross build from source, because it doesn't pass
> > --host to configure and thus uses the build architecture toolchain.
> > Replacing the explicit ./configure invocation with dh_auto_configure
> > fixes the cross build, because dh_auto_configure knows the right flags.
> > It also simplifies the rules file. Please consider applying the attached
> > patch.
> 
> Thanks, applied in GIT.
> 
> Andreas

Tested i386 and amd64, looks fine.

Kind regards,
Luca Boccassi


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

Bug#838415: Wrong package name, installs typelib file into wrong directory

[Michael Biebl]

Package: gir1.2-urfkill-glib0
Version: 0.5.0-4
Severity: serious

Hi,

please follow /usr/share/doc/gobject-introspection/policy.txt when
package typelib files.

In case of gir1.2-urfkill-glib0, debian/gir1.2-urfkill-glib0.install is
broken and installs the files as
/usr/lib/Urfkill-0.5.typelib

Since multiarch paths are allowed for typelib files, just use
usr/lib/*/girepository-1.0/Urfkill-*.typelib

Please also name the package accordingly, in your case, this would be
gir1.2-urfkill-0.5

Last but not least, you need to use the gir addon via

dh $@ --with gir




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

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

Bug#838413: RM: linux-signed [armel] -- ROM; no longer built on this architecture

[Ben Hutchings]

On Tue, 2016-09-20 at 22:37 +0100, Ben Hutchings wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Due to limitations of kernel-wedge, linux-signed no longer builds
> packages for any armel flavour - previously it built
> linux-image-4.6.0-1-versatile.  Please remove the old binary.

Actually linux-image-4.6.0-1-versatile-signed

Ben.

-- 
Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it
in
your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'


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

Bug#838414: gpick: colors.txt is non-free

[Francesco Poli (wintermute)]

Package: gpick
Version: 0.2.5-2
Severity: serious
Justification: Policy 2.2.1


Hello and thanks for maintaining this little tool in Debian!

I noticed that the license for file share/gpick/colors.txt fails
to meet the DFSG, as it includes at least one non-free restriction.
Clause 5 states:

|  5. These RGB colour formulations may not be used to the detriment of
|  Resene Paints Ltd.

This is a non-free restriction on use, which does not comply with
DFSG#6 (No Discrimination Against Fields of Endeavor).

This file is therefore unfit for the main Debian archive.

Possible solutions I can think of:

 A) get in touch with the colors.txt copyright holders (Resene Paints
Ltd.) and persuade them to drop the troublesome clause or, even
better, to re-license the file under well-known and widely used
DFSG-free terms (such as, for instance, the 3-clause BSD license
adopted by the rest of gpick)

 B) find a DFSG-free replacement for share/gpick/colors.txt and use it
in stead of the non-free one

 C) drop share/gpick/colors.txt from the package, if possible

 D) move the gpick package to the non-free archive (I hope this will
*not* happen!)

I hope solution A may be persued soon.
Solution B (or C) may be chosen as a temporary quick fix, while trying
to achieve solution A.

Thanks for your time!
Bye.

Bug#838399: Pending fixes for bugs in the libdate-convert-perl package

[pkg-perl-maintainers]

tag 838399 + pending
thanks

Some bugs in the libdate-convert-perl package are closed in revision
44e5b1e1176cc8ad5b2c288426d5046e87b90110 in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libdate-convert-perl.git/commit/?id=44e5b1e

Commit message:

Remove Stephen Gran from Uploaders on request of the MIA team.

Closes: #838399

Bug#811674: FTBFS with GCC 6: multiple errors

[Vincent Lefevre]

Control: tags -1 patch

On 2016-09-19 17:12:17 +0200, Emilio Pozuelo Monfort wrote:
> On Tue, 19 Jan 2016 16:50:22 -0800 Martin Michlmayr  wrote:
> > This package fails to build with GCC 6.  GCC 6 has not been released
> > yet, but it's expected that GCC 6 will become the default compiler for
> > stretch.
> 
> Any news on this? This is blocking the boost1.58 removal, which in
> turn is blocking the ongoing openmpi transition. I'd appreciate if
> you could take a look at this.

The main difference between GCC 6 and the previous version for C++ is:

  The default mode for C++ is now -std=gnu++14 instead of -std=gnu++98.

(from https://gcc.gnu.org/gcc-6/changes.html), as incompatible changes
have been introduced in the new C++ standard.

This seems to be the cause of the failure here. One simple solution,
IMHO, is to switch back to -std=gnu++98. This is what the attached
patch does. I was not sure where to put -std=gnu++98, but with what
I did, it applies only to GCC, not to clang. So, I suppose that this
is what is expected. On my machine, ceph builds without any error
with this patch, but I have not tested the behavior when installed
(I don't see why there would be any new problem).

I don't think it would be worth to try to make this version C++14
compliant while there is a new version upstream (see the package in
experimental, for instance).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Index: ceph-0.80.11/src/Makefile-env.am
===
--- ceph-0.80.11.orig/src/Makefile-env.am
+++ ceph-0.80.11/src/Makefile-env.am
@@ -80,7 +80,7 @@ AM_CXXFLAGS = \
-Wnon-virtual-dtor \
-Wno-invalid-offsetof
 if !CLANG
-   AM_CXXFLAGS += -Wstrict-null-sentinel
+   AM_CXXFLAGS += -Wstrict-null-sentinel -std=gnu++98
 endif
 
 # note: this is position dependant, it affects the -l options that

Bug#838413: RM: linux-signed [armel] -- ROM; no longer built on this architecture

[Ben Hutchings]

Package: ftp.debian.org
Severity: normal

Due to limitations of kernel-wedge, linux-signed no longer builds
packages for any armel flavour - previously it built
linux-image-4.6.0-1-versatile.  Please remove the old binary.

Bug#838412: Typo: asyncronously -> asynchronously

[Christoph Biedl]

Source: subversion
Version: 1.9.4-3
Severity: minor
Tags: upstream

Dear Maintainer,

lintian[1] complained about a typo in one of the files subversion
creates on the server side. So I'm asking you to fix this as below
when convenient.

Regards,

Christoph

[1] Okay, this might require an explanation. To ease the work of a
subversion administrator, I create manpages from these template files
as part of a packaging process. Yes that's as weird as it sounds. The
resulting Debian packages are inspected by lintian, and so I learned
about it.

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

Kernel: Linux 4.4.20 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

diff --git a/subversion/libsvn_repos/repos.c b/subversion/libsvn_repos/repos.c
index dc0caf5..1d62aeb 100644
--- a/subversion/libsvn_repos/repos.c
+++ b/subversion/libsvn_repos/repos.c
@@ -712,7 +712,7 @@ create_hooks(svn_repos_t *repos, apr_pool_t *pool)
 "# Because the locks have already been created and cannot be undone,"NL
 "# the exit code of the hook program is ignored.  The hook program"  NL
 "# can use the 'svnlook' utility to examine the paths in the repository" NL
-"# but since the hook is invoked asyncronously the newly-created locks"  NL
+"# but since the hook is invoked asynchronously the newly-created locks" NL
 "# may no longer be present."
NL;
   script =
 "REPOS=\"$1\""   NL



signature.asc
Description: Digital signature

Bug#828594: virtuoso-opensource: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

control: tags -1 patch
control: forwarded -1 https://github.com/openlink/virtuoso-opensource/pull/583

On 2016-09-10 17:39:04 [+0200], Kurt Roeckx wrote:
> You already had to include that file to get it working, and that seems to be
> a message form 2001.  So you really can't say they haven't been warned.

okay.

> > That part where I replaced d2i_ASN1_BOOLEAN() looks like
> > they copied it from old openssl code.
> 
> I'm not sure that that code you replaced it with is correct or not.

this makes two people then.

> > @@ -854,16 +857,18 @@ bif_smime_sign (caddr_t * qst, caddr_t * err_ret, 
> > state_slot_t ** args)
> >  }
> >  
> >certs = sk_X509_new_null ();
> > +#if HALP
> >if (store && store->objs)
> >  {
> >for (inx = 0; inx < sk_X509_OBJECT_num (store->objs); inx++)
> > {
> >   X509_OBJECT *obj = sk_X509_OBJECT_value (store->objs, inx);
> > - if (obj->type == X509_LU_X509)
> > + if (X509_OBJECT_get_type(obj) == X509_LU_X509)
> > sk_X509_push (certs, X509_dup (obj->data.x509));
> > }
> >  
> >  }
> > +#endif
> 
> Are you looking for X509_STORE_get0_objects(store) instead of
> store->objs?

correct.

> > @@ -1488,6 +1496,7 @@ bif_get_certificate_info (caddr_t * qst, caddr_t * 
> > err_ret, state_slot_t ** args
> > int n, i, len;
> > char *s, *data_ptr;
> > BIO *mem = BIO_new (BIO_s_mem ());
> > +#if HALP
> > for (i = 0; NULL != subj && i < sk_X509_NAME_ENTRY_num(subj->entries); 
> > i++)
> >   {
> > ne = sk_X509_NAME_ENTRY_value(subj->entries,i);
> 
> I think you're looking for:
> for (i = 0; NULL != subj && i < X509_NAME_entry_count(subj); i++)
> {
> X509_NAME_ENTRY *ne = X509_NAME_get_entry(subj, i);
> 
exactly. Thank you.

The patch attached should contain the changes. And I forwarded ported to
their latest develop branch and created a pull request.

> 
> Kurt

Sebastian
>From 823092cccbd8e2ab9bfad6c3d3df791a7ffa76fc Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Mon, 5 Sep 2016 10:49:54 +
Subject: [PATCH] virtuoso-opensource: build against openssl 1.1.0

Signed-off-by: Sebastian Andrzej Siewior 
---
 libsrc/Dk/Dkernel.c  |   6 +-
 libsrc/Wi/bif_crypto.c   | 120 ++
 libsrc/Wi/http.c |   2 +-
 libsrc/Wi/xmlenc.c   | 319 +++
 libsrc/Wi/xmlenc.h   | 193 ++--
 libsrc/Wi/xmlenc_algos.c | 132 +++-
 libsrc/util/sslengine.c  |   6 +-
 7 files changed, 524 insertions(+), 254 deletions(-)

diff --git a/libsrc/Dk/Dkernel.c b/libsrc/Dk/Dkernel.c
index c8dfbf7..82c77cb 100644
--- a/libsrc/Dk/Dkernel.c
+++ b/libsrc/Dk/Dkernel.c
@@ -4930,7 +4930,11 @@ ssl_server_init ()
 # if (OPENSSL_VERSION_NUMBER >= 0x00908000L)
   SSL_library_init ();
 # endif
-  SSLeay_add_all_algorithms ();
+#if OPENSSL_VERSION_NUMBER < 0x1010
+  SSLeay_add_all_algorithms();
+#else
+  OpenSSL_add_all_algorithms();
+#endif
   PKCS12_PBE_add ();		/* stub */
 
 #ifdef NO_THREAD
diff --git a/libsrc/Wi/bif_crypto.c b/libsrc/Wi/bif_crypto.c
index c759d11..3bfc588 100644
--- a/libsrc/Wi/bif_crypto.c
+++ b/libsrc/Wi/bif_crypto.c
@@ -181,21 +181,26 @@ box_hmac (caddr_t box, caddr_t key, int alg)
   unsigned char temp[EVP_MAX_MD_SIZE];
   unsigned int size = 0;
   caddr_t res = NULL;
-  HMAC_CTX ctx;
+  HMAC_CTX *ctx;
   const EVP_MD *md = EVP_sha1 ();
 
   if (alg == 1)
 md = EVP_ripemd160 ();
 
-  HMAC_Init (, key, box_length (key) - DV_STRINGP (key) ? 1 : 0, md);
-  box_hmac_1 (box, );
-  HMAC_Final (, temp, );
+  ctx = HMAC_CTX_new();
+  if (!ctx)
+	  return res;
+
+  HMAC_Init_ex (ctx, key, box_length (key) - DV_STRINGP (key) ? 1 : 0, md, NULL);
+  box_hmac_1 (box, ctx);
+  HMAC_Final (ctx, temp, );
   if (size)
 {
   res = dk_alloc_box (size + 1, DV_SHORT_STRING);
   memcpy (res, temp, size);
   res[size] = 0;
 }
+  HMAC_CTX_free(ctx);
   return res;
 }
 
@@ -347,14 +352,12 @@ asn1_parse_to_xml (BIO * bp, unsigned char **pp, long length, int offset, int de
 	{
 	  int ii;
 
-	  opp = op;
-	  ii = d2i_ASN1_BOOLEAN (NULL, , len + hl);
-	  if (ii < 0)
+	  if (len + hl < 1)
 		{
 		  if (BIO_write (bp, "Bad boolean\n", 12))
 		goto end;
 		}
-	  BIO_printf (bp, "%d", ii);
+	  BIO_printf (bp, "%d", p[0]);
 	}
 	  else if (tag == V_ASN1_BMPSTRING)
 	{
@@ -415,7 +418,7 @@ asn1_parse_to_xml (BIO * bp, unsigned char **pp, long length, int offset, int de
 		}
 	  if (os != NULL)
 		{
-		  M_ASN1_OCTET_STRING_free (os);
+		  ASN1_STRING_free (os);
 		  os = NULL;
 		}
 	}
@@ -448,7 +451,7 @@ asn1_parse_to_xml (BIO * bp, unsigned char **pp, long length, int offset, int de
 		  if (BIO_write (bp, "BAD INTEGER", 11) <= 0)
 		goto end;
 		}
-	  M_ASN1_INTEGER_free (bs);
+	  ASN1_STRING_free (bs);
 	}
 	  else if (tag == V_ASN1_ENUMERATED)
 	{
@@ -479,7 +482,7 

Bug#838395: libvdpau FTCBFS: fails to pass --host to configure

[Andreas Beckmann]

Control: tag -1 pending

On 2016-09-20 21:43, Helmut Grohne wrote:
> libvdpau fails to cross build from source, because it doesn't pass
> --host to configure and thus uses the build architecture toolchain.
> Replacing the explicit ./configure invocation with dh_auto_configure
> fixes the cross build, because dh_auto_configure knows the right flags.
> It also simplifies the rules file. Please consider applying the attached
> patch.

Thanks, applied in GIT.

Andreas

Bug#838403: Pending fixes for bugs in the liblwp-authen-wsse-perl package

[pkg-perl-maintainers]

tag 838403 + pending
thanks

Some bugs in the liblwp-authen-wsse-perl package are closed in
revision 81cca266de661d8c0c113d80aae96833f69c7d03 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/liblwp-authen-wsse-perl.git/commit/?id=81cca26

Commit message:

Remove Stephen Gran from Uploaders on request of the MIA team.

Closes: #838403

Bug#838400: Pending fixes for bugs in the libconfig-apacheformat-perl package

[pkg-perl-maintainers]

tag 838400 + pending
thanks

Some bugs in the libconfig-apacheformat-perl package are closed in
revision 10acb516f08925b92488ee3b78d96d3b04909065 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libconfig-apacheformat-perl.git/commit/?id=10acb51

Commit message:

Remove Stephen Gran from Uploaders on request of the MIA team.

Closes: #838400

Bug#838411: liblegacytaskmanager5 shows up as broken

[shirish शिरीष]

Package: liblegacytaskmanager5
Version: 4:5.7.4-1
Severity: normal

Dear Maintainer,
liblegacytaskmanager5 shows up as broken, have no idea why.

┌─[shirish@debian] - [~] - [10047]
└─[$] aptitude search \~b  | grep liblegacytaskmanager5

iB liblegacytaskmanager5 - Plasma Workspace for KF5 library

Except for libc6 and its brethen, all the others are from either
testing or unstable whichever is newer.

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

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

Versions of packages liblegacytaskmanager5 depends on:
ii  libc6 2.23-5
ii  libkf5activities5 5.25.0-1
ii  libkf5completion5 5.25.0-1
ii  libkf5configcore5 5.25.0-1
ii  libkf5configwidgets5  5.25.0-1
ii  libkf5coreaddons5 5.25.0-1
ii  libkf5i18n5   5.25.0-1
ii  libkf5iconthemes5 5.25.0-1
ii  libkf5kiocore55.25.0-1
ii  libkf5kiowidgets5 5.25.0-1
ii  libkf5service-bin 5.25.0-1
ii  libkf5service55.25.0-1
ii  libkf5widgetsaddons5  5.25.0-1
ii  libkf5windowsystem5   5.25.0-1
ii  libprocesscore7   4:5.7.4-1
ii  libqt5core5a  5.6.1+dfsg-3+b1
ii  libqt5gui55.6.1+dfsg-3+b1
ii  libqt5widgets55.6.1+dfsg-3+b1
ii  libqt5x11extras5  5.6.1-2
ii  libstdc++66.1.1-11
ii  libx11-6  2:1.6.3-1

liblegacytaskmanager5 recommends no packages.

liblegacytaskmanager5 suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#776622: dahdi-linux: please make the build reproducible

[Tzafrir Cohen]

On Fri, Sep 16, 2016 at 09:50:54AM +0100, Chris Lamb wrote:
> Dear Maintainer,
> 
> > Source: dahdi-linux
> > Version: 1:2.3.0.1+dfsg-2
> > Tags: patch
> 
> There hasn't seem to be any update on this bug in 32 days, in which
> time the Reproducible Builds effort has come on a long way. :)
> 
> Would you consider applying this patch and uploading?

Thanks for the reminder. Half of this has already been fixed upstream. I
have applied the other half. I'm waiting for a followup on another issue
and this should be uploaded this week.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Bug#835866: Additional information

[Benoît Merlet]

Hi all,

I can confirm there is an issue with Google Authentication page not 
being rendered properly with icedove 1:45.2.0-4+b1.


I'm having the issue with the following extension not working anymore: 
https://addons.mozilla.org/fr/thunderbird/addon/google-calendar-tab/


Cheers,
Benoît

Bug#838410: RFA: ccze -- A robust, modular log coloriser

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of ccze, Stephen Gran ,
looks for someone to take over this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: ccze
Binary: ccze
Version: 0.2.1-2
Maintainer: Stephen Gran 
Build-Depends: libpcre3-dev, libncurses5-dev
Architecture: any
Standards-Version: 3.7.2
Format: 1.0
Files:
 8d772f3a465afed7960f84ddc4e3405d 557 ccze_0.2.1-2.dsc
 221966bce7c5f011eca38157241a0432 139795 ccze_0.2.1.orig.tar.gz
 7f16b35068517f63b4bcfa18505881b4 71939 ccze_0.2.1-2.diff.gz
Checksums-Sha256:
 15a10cedd94fde0d0602ab3642cd75b796a29d27817fecb513f66bdc83740f00 557 
ccze_0.2.1-2.dsc
 853e124d9d91519318b589556dcf3035859a90a9bff40105b1d516775f358f57 71939 
ccze_0.2.1-2.diff.gz
 8263a11183fd356a033b6572958d5a6bb56bfd2dba801ed0bff276cfae528aa3 139795 
ccze_0.2.1.orig.tar.gz
Directory: pool/main/c/ccze
Priority: source
Section: utils

Package: ccze
Binary: ccze
Version: 0.2.1-2
Maintainer: Stephen Gran 
Build-Depends: libpcre3-dev, libncurses5-dev
Architecture: any
Standards-Version: 3.7.2
Format: 1.0
Files:
 8d772f3a465afed7960f84ddc4e3405d 557 ccze_0.2.1-2.dsc
 221966bce7c5f011eca38157241a0432 139795 ccze_0.2.1.orig.tar.gz
 7f16b35068517f63b4bcfa18505881b4 71939 ccze_0.2.1-2.diff.gz
Checksums-Sha1:
 5804ae3d88dae90d0abc19457ef46e894c07b5ee 557 ccze_0.2.1-2.dsc
 a0ef47e39e9d7d30f0a926c9cc5fe2fc912ca103 71939 ccze_0.2.1-2.diff.gz
 a265e826be8018cd2f1b13ea1e96e27cc1941d02 139795 ccze_0.2.1.orig.tar.gz
Checksums-Sha256:
 15a10cedd94fde0d0602ab3642cd75b796a29d27817fecb513f66bdc83740f00 557 
ccze_0.2.1-2.dsc
 853e124d9d91519318b589556dcf3035859a90a9bff40105b1d516775f358f57 71939 
ccze_0.2.1-2.diff.gz
 8263a11183fd356a033b6572958d5a6bb56bfd2dba801ed0bff276cfae528aa3 139795 
ccze_0.2.1.orig.tar.gz
Directory: pool/main/c/ccze
Priority: source
Section: utils

Package: ccze
Source: ccze (0.2.1-2)
Version: 0.2.1-2+b1
Installed-Size: 150
Maintainer: Stephen Gran 
Architecture: amd64
Replaces: colorize (<= 0.3.1-2)
Depends: libc6 (>= 2.3), libncurses5 (>= 6), libpcre3 (>= 1:8.35), libtinfo5 
(>= 6)
Description-en: A robust, modular log coloriser
 CCZE is a robust and modular log coloriser, with plugins for apm,
 exim, fetchmail, httpd, postfix, procmail, squid, syslog, ulogd,
 vsftpd, xferlog and more.
Description-md5: 502916b60d2c9d860fe6d027ee235e89
Tag: devel::prettyprint, interface::commandline, role::program,
 scope::utility, use::checking, use::filtering, use::monitor,
 use::searching, use::viewing, works-with::logfile,
 works-with::software:running, works-with::software:source,
 works-with::text
Section: utils
Priority: extra
Filename: pool/main/c/ccze/ccze_0.2.1-2+b1_amd64.deb
Size: 66610
MD5sum: 75f7f75e08933573a806d3779f0c1ec8
SHA256: dbfbde72b4cdc6c3b19c486740175e1a64264811fcfbe881f418bf587b4e5cf4

Package: ccze
Source: ccze (0.2.1-2)
Version: 0.2.1-2+b1
Installed-Size: 150
Maintainer: Stephen Gran 
Architecture: amd64
Replaces: colorize (<= 0.3.1-2)
Depends: libc6 (>= 2.3), libncurses5 (>= 6), libpcre3 (>= 1:8.35), libtinfo5 
(>= 6)
Description-en: A robust, modular log coloriser
 CCZE is a robust and modular log coloriser, with plugins for apm,
 exim, fetchmail, httpd, postfix, procmail, squid, syslog, ulogd,
 vsftpd, xferlog and more.
Description-md5: 502916b60d2c9d860fe6d027ee235e89
Tag: devel::prettyprint, interface::commandline, role::program,
 scope::utility, use::checking, use::filtering, use::monitor,
 use::searching, use::viewing, works-with::logfile,
 works-with::software:running, works-with::software:source,
 works-with::text
Section: utils
Priority: extra
Filename: pool/main/c/ccze/ccze_0.2.1-2+b1_amd64.deb
Size: 66610
MD5sum: 75f7f75e08933573a806d3779f0c1ec8
SHA256: dbfbde72b4cdc6c3b19c486740175e1a64264811fcfbe881f418bf587b4e5cf4



signature.asc
Description: PGP signature

Bug#838398: Updating the ccze Uploaders list

[Tobias Frost]

Control: close -1

sorry, this was meant to be a RFA bug. Closing.

On Tue, 20 Sep 2016 22:45:19 +0200 Tobias Frost 
wrote:
> Source: ccze
> Version: 0.2.1-2
> Severity: minor
> User: m...@qa.debian.org
> Usertags: mia-teammaint
> 
> Stephen Gran  wishes no longer to be uploader of
ccze.
> 
> We are tracking their status in the MIA team and would like to ask
you
> to remove them from the Uploaders list of the package so we can close
> that part of the file.
> 
> (If the person is listed as Maintainer, what we are asking is to
please
> step in as a new maintainer.)
> 
> Thanks.
> 
> 

Bug#795458: dahdi-linux: have a debian/README.source

[Tzafrir Cohen]

On Mon, Aug 17, 2015 at 08:45:34PM +0300, Tzafrir Cohen wrote:
> On Mon, Aug 17, 2015 at 12:41:52PM +0200, Geert Stappers wrote:
> > On Sun, Aug 16, 2015 at 10:55:44PM +0300, Tzafrir Cohen wrote:
> > > On Fri, Aug 14, 2015 at 09:50:53AM +0200, Geert Stappers wrote:
> > > > 
> > > > Please provide a debian/README.source that tells
> > > > how to build the dahdi-linux package
> > > 
> > > Quoting the top of README.Debian from dahdi-linux / dahdi-source:
> > > 
> > > Building kernel modules
> > > ---
> > > First, install dahdi-source package if you have not yet done so.
> > > 
> > > You can build and install the modules package (as root) with the 
> > > following command:
> > > # module-assistant a-i dahdi
> > > 
> > > 
> > 
> > Benefits of knowning to build dahdi packages from
> > Debian version control system:
> > 
> > * Avoiding installing build dependencies on computer(s) with the DAHDI 
> > hardware
> > * Building on faster computer
> > * Having the workflow documented, making Aloith pkg-voip team stronger
> 
> The package has a script, intended for internal testing, that runs m-a
> build at the end of the pacage build to build a modules package:
> debian/modulestest .
> 
> Internally (in Xorcom) we have a modified package that builds kernel
> modules at dahdi-linux package build time. The down side to that is that
> you can only build modules for a single kernel (and have to set that
> kernel version ahead of build time. We use an ugly hack to set that as
> you really can't edit the build-depends in a package at build time.
> 
> So, are you looking for better documentation of debian/modulestest ?

Documenting this more explicitly in the README.Debian and closing the
bug.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Bug#838408: RFA: randomsound -- ALSA sound card related entropy gathering daemon

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of randomsound, Stephen Gran ,
looks for someone to take over this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: randomsound
Binary: randomsound
Version: 0.2-5
Maintainer: Stephen Gran 
Build-Depends: debhelper (>= 5)
Architecture: any
Standards-Version: 3.8.3
Format: 1.0
Files:
 6dd385c9774b238f650262ff78722d6b 1012 randomsound_0.2-5.dsc
 76766477db530269045939dd9988c535 6648 randomsound_0.2.orig.tar.gz
 9e82ee5de6a687c57ab0d0323f9f48c9 4264 randomsound_0.2-5.diff.gz
Checksums-Sha256:
 c3e033656c328c9d92a28c2e687508586947d8159e4b3e4fdc1754a3b1ada9b5 1012 
randomsound_0.2-5.dsc
 3c28f78b0a911509f39507a6b21769b5d013e0fc32065826d8fc4a0a01f3ed15 6648 
randomsound_0.2.orig.tar.gz
 e92c5dbdf3edec254d316fa24182a5be3b27bc96ef239cd458912c9c18cf1aa8 4264 
randomsound_0.2-5.diff.gz
Homepage: http://www.digital-scurf.org/software/randomsound
Directory: pool/main/r/randomsound
Priority: source
Section: admin

Package: randomsound
Binary: randomsound
Version: 0.2-5
Maintainer: Stephen Gran 
Build-Depends: debhelper (>= 5)
Architecture: any
Standards-Version: 3.8.3
Format: 1.0
Files:
 6dd385c9774b238f650262ff78722d6b 1012 randomsound_0.2-5.dsc
 76766477db530269045939dd9988c535 6648 randomsound_0.2.orig.tar.gz
 9e82ee5de6a687c57ab0d0323f9f48c9 4264 randomsound_0.2-5.diff.gz
Checksums-Sha1:
 167e48ea7f51d145febe2942a7a652c61d30cc90 1012 randomsound_0.2-5.dsc
 a06a907ece0526d53bc7d5e0eecd1d2979642eb7 6648 randomsound_0.2.orig.tar.gz
 f4a024609386c252226a7eab89a63e42a42a86c4 4264 randomsound_0.2-5.diff.gz
Checksums-Sha256:
 c3e033656c328c9d92a28c2e687508586947d8159e4b3e4fdc1754a3b1ada9b5 1012 
randomsound_0.2-5.dsc
 3c28f78b0a911509f39507a6b21769b5d013e0fc32065826d8fc4a0a01f3ed15 6648 
randomsound_0.2.orig.tar.gz
 e92c5dbdf3edec254d316fa24182a5be3b27bc96ef239cd458912c9c18cf1aa8 4264 
randomsound_0.2-5.diff.gz
Homepage: http://www.digital-scurf.org/software/randomsound
Directory: pool/main/r/randomsound
Priority: source
Section: admin

Package: randomsound
Version: 0.2-5
Installed-Size: 104
Maintainer: Stephen Gran 
Architecture: amd64
Depends: libc6 (>= 2.2.5), alsa-utils
Description-en: ALSA sound card related entropy gathering daemon
 Using the low order bit of the ADC output of your sound card,
 randomsound gathers entropy, debiases it and offers it up to your
 kernel's random pool.
Description-md5: b19b7173c2d5ee546040139b48e961d4
Homepage: http://www.digital-scurf.org/software/randomsound
Tag: implemented-in::c, interface::daemon, role::program, scope::utility,
 works-with::audio
Section: admin
Priority: extra
Filename: pool/main/r/randomsound/randomsound_0.2-5_amd64.deb
Size: 11214
MD5sum: 9f674baa9fd566433c606a76644e
SHA256: 9b5d2f4ff4e0afc9f35e95740eb7d8fbc5b8ca762dd818bbcd0379a1abf7d1c2

Package: randomsound
Version: 0.2-5
Installed-Size: 104
Maintainer: Stephen Gran 
Architecture: amd64
Depends: libc6 (>= 2.2.5), alsa-utils
Description-en: ALSA sound card related entropy gathering daemon
 Using the low order bit of the ADC output of your sound card,
 randomsound gathers entropy, debiases it and offers it up to your
 kernel's random pool.
Description-md5: b19b7173c2d5ee546040139b48e961d4
Homepage: http://www.digital-scurf.org/software/randomsound
Tag: implemented-in::c, interface::daemon, role::program, scope::utility,
 works-with::audio
Section: admin
Priority: extra
Filename: pool/main/r/randomsound/randomsound_0.2-5_amd64.deb
Size: 11214
MD5sum: 9f674baa9fd566433c606a76644e
SHA256: 9b5d2f4ff4e0afc9f35e95740eb7d8fbc5b8ca762dd818bbcd0379a1abf7d1c2



signature.asc
Description: PGP signature

Bug#838409: RFA: libbot-basicbot-perl -- simple irc bot baseclass

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of libbot-basicbot-perl, Stephen Gran ,
looks for someone to take over this package.

(CC'ing the Debian Perl Group -- maybe they are interested in this package)

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: libbot-basicbot-perl
Binary: libbot-basicbot-perl
Version: 0.89-1
Maintainer: Stephen Gran 
Build-Depends: debhelper (>= 5), libmodule-build-perl
Build-Depends-Indep: perl (>= 5.6.10-12), libpoe-component-irc-perl (>= 4.0), 
libpoe-perl (>= 0.22)
Architecture: all
Standards-Version: 3.9.4
Format: 1.0
Files:
 9a2c4eabbcf4d993d591b6e92415ad6e 1903 libbot-basicbot-perl_0.89-1.dsc
 34bc132338ce3fad601050a7815dbe41 31248 libbot-basicbot-perl_0.89.orig.tar.gz
 91ed485e3979e07e7955bb856cecc916 2281 libbot-basicbot-perl_0.89-1.diff.gz
Checksums-Sha256:
 0eae67350b9ba26322e3caafca5b219995a2ca9492d0d4871d43c879db51c812 1903 
libbot-basicbot-perl_0.89-1.dsc
 4c39b018d878db3286946955382625d9c9056a64128d77dbc57e5aaeab2f3948 31248 
libbot-basicbot-perl_0.89.orig.tar.gz
 92aa4f464318892b010dce910cb2008b704516e4f44ad48b9a43b1841b05f8b0 2281 
libbot-basicbot-perl_0.89-1.diff.gz
Homepage: http://search.cpan.org/dist/Bot-BasicBot/
Package-List: 
 libbot-basicbot-perl deb perl optional
Directory: pool/main/libb/libbot-basicbot-perl
Priority: source
Section: perl

Package: libbot-basicbot-perl
Binary: libbot-basicbot-perl
Version: 0.89-1
Maintainer: Stephen Gran 
Build-Depends: debhelper (>= 5), libmodule-build-perl
Build-Depends-Indep: perl (>= 5.6.10-12), libpoe-component-irc-perl (>= 4.0), 
libpoe-perl (>= 0.22)
Architecture: all
Standards-Version: 3.9.4
Format: 1.0
Files:
 9a2c4eabbcf4d993d591b6e92415ad6e 1903 libbot-basicbot-perl_0.89-1.dsc
 34bc132338ce3fad601050a7815dbe41 31248 libbot-basicbot-perl_0.89.orig.tar.gz
 91ed485e3979e07e7955bb856cecc916 2281 libbot-basicbot-perl_0.89-1.diff.gz
Checksums-Sha1:
 a1bc742a95767eec5e67b88fe502e277cc3b8cf8 1903 libbot-basicbot-perl_0.89-1.dsc
 af1a694ee93229a3f96bc231fccf369fa3f015d2 31248 
libbot-basicbot-perl_0.89.orig.tar.gz
 ea4d1636cec026cb6b62a4c6d577450a957624c9 2281 
libbot-basicbot-perl_0.89-1.diff.gz
Checksums-Sha256:
 0eae67350b9ba26322e3caafca5b219995a2ca9492d0d4871d43c879db51c812 1903 
libbot-basicbot-perl_0.89-1.dsc
 4c39b018d878db3286946955382625d9c9056a64128d77dbc57e5aaeab2f3948 31248 
libbot-basicbot-perl_0.89.orig.tar.gz
 92aa4f464318892b010dce910cb2008b704516e4f44ad48b9a43b1841b05f8b0 2281 
libbot-basicbot-perl_0.89-1.diff.gz
Homepage: http://search.cpan.org/dist/Bot-BasicBot/
Package-List: 
 libbot-basicbot-perl deb perl optional
Directory: pool/main/libb/libbot-basicbot-perl
Priority: source
Section: perl

Package: libbot-basicbot-perl
Version: 0.89-1
Installed-Size: 107
Maintainer: Stephen Gran 
Architecture: all
Depends: perl, libpoe-component-irc-perl (>= 4.0), libpoe-perl (>= 0.22)
Description-en: simple irc bot baseclass
 Basic bot system designed to make it easy to do simple bots, optionally
 forking longer processes (like searches) concurrently in the background.
 .
 Designed primarily to be used as a superclass for other programs.
Description-md5: 2644adf405ca5f195f7cc1e9f4d5ca9d
Homepage: http://search.cpan.org/dist/Bot-BasicBot/
Tag: devel::lang:perl, devel::library, implemented-in::perl
Section: perl
Priority: optional
Filename: 
pool/main/libb/libbot-basicbot-perl/libbot-basicbot-perl_0.89-1_all.deb
Size: 36632
MD5sum: 90c99c7c4274159673857ab5cca69e67
SHA256: 44695b7c2a65be9f73003bc46396d6a56e05e9776e3d2800035c2566a9bb3fa1

Package: libbot-basicbot-perl
Version: 0.89-1
Installed-Size: 107
Maintainer: Stephen Gran 
Architecture: all
Depends: perl, libpoe-component-irc-perl (>= 4.0), libpoe-perl (>= 0.22)
Description-en: simple irc bot baseclass
 Basic bot system designed to make it easy to do simple bots, optionally
 forking longer processes (like searches) concurrently in the background.
 .
 Designed primarily to be used as a superclass for other programs.
Description-md5: 2644adf405ca5f195f7cc1e9f4d5ca9d
Homepage: http://search.cpan.org/dist/Bot-BasicBot/
Tag: devel::lang:perl, devel::library, implemented-in::perl
Section: perl
Priority: optional
Filename: 
pool/main/libb/libbot-basicbot-perl/libbot-basicbot-perl_0.89-1_all.deb
Size: 36632
MD5sum: 90c99c7c4274159673857ab5cca69e67
SHA256: 44695b7c2a65be9f73003bc46396d6a56e05e9776e3d2800035c2566a9bb3fa1



signature.asc
Description: PGP signature

Bug#838407: RFA: cdlabelgen -- generates front cards and tray cards for CDs and DVDs

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of cdlabelgen, Stephen Gran ,
looks for someone to take over this package.

(note that the maintainer Juan Manuel Garcia Molina  has
retired, so this package has currently no active maintainer anymore. See 
#759677)

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: cdlabelgen
Binary: cdlabelgen
Version: 4.1.0-2
Maintainer: Juan Manuel Garcia Molina 
Uploaders: Stephen Gran 
Build-Depends: debhelper (>> 5.0.0)
Build-Depends-Indep: perl
Architecture: all
Standards-Version: 3.8.0
Format: 1.0
Files:
 89dfacd919b38145d609c001fc8dec89 1101 cdlabelgen_4.1.0-2.dsc
 96b5b70e6e0298d65b9a4ece4595d3e9 192532 cdlabelgen_4.1.0.orig.tar.gz
 fa7063c1c7983fbe9b0cc226b7d96f60 19104 cdlabelgen_4.1.0-2.diff.gz
Checksums-Sha256:
 5538764dfd23fa517049c4eb1ccc84802b5a93e4669c4d518b64c9cc88271fa0 1101 
cdlabelgen_4.1.0-2.dsc
 8b481f7ddd84c6a1e7c61ddf147c20f32c579cff38fa346ac2ebe000d47d3d2f 192532 
cdlabelgen_4.1.0.orig.tar.gz
 a3ba4476bb501be31921093b6118778b36bfe7f12e6852a9b5ea3f2cd77d81b6 19104 
cdlabelgen_4.1.0-2.diff.gz
Homepage: http://www.aczoom.com/tools/cdinsert/
Directory: pool/main/c/cdlabelgen
Priority: source
Section: graphics

Package: cdlabelgen
Binary: cdlabelgen
Version: 4.1.0-2
Maintainer: Juan Manuel Garcia Molina 
Uploaders: Stephen Gran 
Build-Depends: debhelper (>> 5.0.0)
Build-Depends-Indep: perl
Architecture: all
Standards-Version: 3.8.0
Format: 1.0
Files:
 89dfacd919b38145d609c001fc8dec89 1101 cdlabelgen_4.1.0-2.dsc
 96b5b70e6e0298d65b9a4ece4595d3e9 192532 cdlabelgen_4.1.0.orig.tar.gz
 fa7063c1c7983fbe9b0cc226b7d96f60 19104 cdlabelgen_4.1.0-2.diff.gz
Checksums-Sha1:
 828eef8e86cb8551bdb7ecbe4bd05423f1c35e8c 1101 cdlabelgen_4.1.0-2.dsc
 b474311cb089a4c520637ac83a55009b8a242bd1 192532 cdlabelgen_4.1.0.orig.tar.gz
 2f598f7066fcf737dd7aa22c1332f03a0f8f10aa 19104 cdlabelgen_4.1.0-2.diff.gz
Checksums-Sha256:
 5538764dfd23fa517049c4eb1ccc84802b5a93e4669c4d518b64c9cc88271fa0 1101 
cdlabelgen_4.1.0-2.dsc
 8b481f7ddd84c6a1e7c61ddf147c20f32c579cff38fa346ac2ebe000d47d3d2f 192532 
cdlabelgen_4.1.0.orig.tar.gz
 a3ba4476bb501be31921093b6118778b36bfe7f12e6852a9b5ea3f2cd77d81b6 19104 
cdlabelgen_4.1.0-2.diff.gz
Homepage: http://www.aczoom.com/tools/cdinsert/
Directory: pool/main/c/cdlabelgen
Priority: source
Section: graphics

Package: cdlabelgen
Version: 4.1.0-2
Installed-Size: 572
Maintainer: Juan Manuel Garcia Molina 
Architecture: all
Depends: perl
Recommends: ghostscript
Description-en: generates front cards and tray cards for CDs and DVDs
 cdlabelgen was designed to simplify the process of
 generating labels for CDs and DVDs. It originated as a program
 to allow auto generation of front cards and tray cards for CDs
 burned via an automated mechanism (specifically for archiving
 data), but has now become popular for labelling CD
 compilations of mp3's, and copies of CDs. Note that cdlabelgen
 does not actually print anything--it just spits out
 postscript, which you can then do with as you please.
 .
Description-md5: 1c2d01e976467eb19764b247de9e88e3
Homepage: http://www.aczoom.com/tools/cdinsert/
Tag: hardware::storage:cd, implemented-in::perl, interface::commandline,
 role::program, works-with-format::postscript
Section: graphics
Priority: optional
Filename: pool/main/c/cdlabelgen/cdlabelgen_4.1.0-2_all.deb
Size: 188518
MD5sum: 6024a0281c5fe6477ed098c2f8b94778
SHA256: ebe04e352e5920031ec906e599c0b7a4bfc86c4b8e451d4e36f1e142a8c890c9

Package: cdlabelgen
Version: 4.1.0-2
Installed-Size: 572
Maintainer: Juan Manuel Garcia Molina 
Architecture: all
Depends: perl
Recommends: ghostscript
Description-en: generates front cards and tray cards for CDs and DVDs
 cdlabelgen was designed to simplify the process of
 generating labels for CDs and DVDs. It originated as a program
 to allow auto generation of front cards and tray cards for CDs
 burned via an automated mechanism (specifically for archiving
 data), but has now become popular for labelling CD
 compilations of mp3's, and copies of CDs. Note that cdlabelgen
 does not actually print anything--it just spits out
 postscript, which you can then do with as you please.
 .
Description-md5: 1c2d01e976467eb19764b247de9e88e3
Homepage: http://www.aczoom.com/tools/cdinsert/
Tag: hardware::storage:cd, implemented-in::perl, interface::commandline,
 role::program, works-with-format::postscript
Section: graphics
Priority: optional
Filename: pool/main/c/cdlabelgen/cdlabelgen_4.1.0-2_all.deb
Size: 188518
MD5sum: 6024a0281c5fe6477ed098c2f8b94778
SHA256: 

Bug#838406: O: root-tail -- Displays select log files in the X root window

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of root-tail, Stephen Gran ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: root-tail
Binary: root-tail
Version: 1.2-3
Maintainer: Stephen Gran 
Build-Depends: debhelper (>= 4.0), libx11-dev, x11proto-core-dev
Architecture: any
Standards-Version: 3.8.0
Format: 1.0
Files:
 35c6708806bf7eb988b83841bbc3fd74 971 root-tail_1.2-3.dsc
 5a4b3c4c7ab3bed1f4575e9688aac5de 20805 root-tail_1.2.orig.tar.gz
 c1bb812b06a3c8268e142bf31b89a90b 3392 root-tail_1.2-3.diff.gz
Checksums-Sha256:
 99c376b7c051736dcbe40ad2c52c62191dccb5cb89d6d9b05d69b508a1178462 971 
root-tail_1.2-3.dsc
 08fb829cc0edd533aaf2af7bcf12d877a6ff51d60c59be48ba354c5940b80691 20805 
root-tail_1.2.orig.tar.gz
 85eb3421c70bd98a59927814b36b531d4904e75d9036bb2dce4aa95153d624da 3392 
root-tail_1.2-3.diff.gz
Directory: pool/main/r/root-tail
Priority: source
Section: x11

Package: root-tail
Version: 1.2-3
Installed-Size: 84
Maintainer: Stephen Gran 
Architecture: amd64
Depends: libc6 (>= 2.7-1), libx11-6
Description-en: Displays select log files in the X root window
 Root-tail, is a program that displays one or more log files,
 on the X root window, through the use of transparent windows.
Description-md5: 45dc834669099cf4e1da72279cc56f22
Tag: admin::monitoring, implemented-in::c, interface::graphical,
 interface::x11, role::program, scope::utility, uitoolkit::xlib,
 use::monitor, works-with::logfile, x11::application
Section: x11
Priority: optional
Filename: pool/main/r/root-tail/root-tail_1.2-3_amd64.deb
Size: 22154
MD5sum: bbc70f7164fd160641e12cf8d7dc2854
SHA256: de89c7e9ccdf536569cabaf6122b3fe84fe08bbdfaa08414b455ffd1eab55e1a



signature.asc
Description: PGP signature

Bug#825800: graphicsmagick: CVE-2016-5118

[Carsten Leonhardt]

László Böszörményi (GCS)  writes:

> On Tue, Sep 20, 2016 at 9:56 AM, Stephan Großberndt
>  wrote:

>> Do you think 1.3.25-2 might be the used for a stable update?
>  Upgrade to a newer version in stable is not easy and I can remember
> one, maybe two cases when it was allowed.
> In this case I'm not sure it should be the path.

It's done regularly with MySQL, so I'd say asking the release team
wouldn't hurt.

 - Carsten

Bug#823952: dahdi-source: AXE400PL + linux 3.16.0-4-686-pae + dahdi 1:2.10.2-2

[Tzafrir Cohen]

Hi,

On Tue, May 10, 2016 at 06:54:46PM +0200, Carlos Martin wrote:

> When system loads dahdi module yo can see the message "Warning: Span WCTDM/4 
> didn't specify a spantype. Please fix driver!"

> Kernel driver in use: wctdm

Thanks for your report and sorry for not answering earlier.

>From what I can see, this issue should apply to original Digium cards as
well. As you can see in lspci, the driver handling this card is wctdm.
Sorry for not picking this up earlier.

The fix for this should be the following patch:

diff --git a/drivers/dahdi/wctdm.c b/drivers/dahdi/wctdm.c
index 9f43e52..cf5a537 100644
--- a/drivers/dahdi/wctdm.c
+++ b/drivers/dahdi/wctdm.c
@@ -2411,6 +2411,7 @@ static int wctdm_initialize(struct wctdm *wc)
wc->span.channels = NUM_CARDS;
wc->span.flags = DAHDI_FLAG_RBS;
wc->span.ops = _span_ops;
+   wc->span.spantype = SPANTYPE_ANALOG_MIXED;
 
list_add_tail(>span.device_node, >ddev->spans);
if (dahdi_register_device(wc->ddev, >dev->dev)) {

Any chance you could test this? I'll try to see if I have any such card
available.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Bug#837753: nvidia-kernel-dkms: does not build for x86_64 kernel on i386 userspace

[Luca Boccassi]

On Sun, 2016-09-18 at 21:18 +0200, Andreas Beckmann wrote:
> On 2016-09-14 13:01, Luca Boccassi wrote:
> > This is already fixed in SVN, pending upload.
> 
> Uploaded to unstable (361xx). Does this need updating for 364 (which
> adds another kernel module)?
> 
> 
> Andreas

No more changes needed for 364 and 367, builds fine with both in an i386
chroot with amd64 headers/dkms package.

Kind regards,
Luca Boccassi


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

Bug#838388: debootstrap: Fails to strap squeeze since 1.0.83

[Ansgar Burchardt]

Stephan Sürken writes:
> On Di, 2016-09-20 at 21:09 +0200, Julien Cristau wrote:
>> > It always exits here with exit code 2, without any further error
>> > message (not even when using --verbose).
>> >
>> There should be a log inside the target directory.
>
> ah, sure ;).
>
> debootstrap/debootstrap.log says:
>
> ---
> gpgv: Signature made Sat Apr 25 13:01:30 2015 CEST
> gpgv:using RSA key AED4B06F473041FA
> gpgv: Good signature from "Debian Archive Automatic Signing Key (6.0/squeeze) 
> "
> gpgv: Signature made Sat Apr 25 13:05:42 2015 CEST
> gpgv:using RSA key 64481591B98321F9
> gpgv: Good signature from "Squeeze Stable Release Key 
> "
> tar: ./usr/share/man/man1/sh.1.gz: Cannot create symlink to 'dash.1.gz': File 
> exists
> tar: ./bin/sh: Cannot create symlink to 'dash': File exists
> tar: Exiting with failure status due to previous errors

Ah, I'm to blame for that.  [1] added `-k` to the options passed to tar
in order to avoid replacing the new symlinks from / to /usr with real
directories.  However it looks like tar returns an error when there are
actual file conflicts (as opposed to just symlink vs. directory).

Only adding -k for newer distributions (i.e. the ones that merged-/usr
supports) should work around the problem.

Just --keep-directory-symlink would of course be ideal, but I doubt it
is supported everywhere (being a long option to start with).

Ansgar

  [1] 
https://anonscm.debian.org/cgit/d-i/debootstrap.git/commit/?id=6b79352a205a96cee441ae0c6247c4616097a517

Bug#838336: gnome-control-center: Keybinding panel fail to open

[Michael Biebl]

Am 20.09.2016 um 11:37 schrieb Raphael Hertzog:
> Hi,
> 
> On Tue, 20 Sep 2016, Michael Biebl wrote:
>>> (gnome-control-center:24830): Gtk-CRITICAL **: Error building template
>>> class 'CcKeyboardPanel' for an instance of type 'CcKeyboardPanel':
>>> .:2:1622 Invalid property: GtkScrolledWindow.propagate_natural_width
>> ...
>>> Versions of packages gnome-control-center depends on:
>>> ii  libgtk-3-0 3.21.5-3
>>
>> Does upgrading libgtk-3-0 to 3.21.6-1 fix the problem?
> 
> Yes. I already had a similar report on the Kali side:
> https://bugs.kali.org/view.php?id=3579
> 
> But gtk+3.0 3.21.6 is tangled with the libc6 transition
> right now and it doesn't migrate although it should since
> it has waited 5 days already.
> 
> It might make sense to do a quick tpu upload to get fixes in testing?

You have my ok to do so.


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



signature.asc
Description: OpenPGP digital signature

Bug#838336: gnome-control-center: Keybinding panel fail to open

[Mathieu R.]

2016-09-20 5:37 GMT-04:00 Raphael Hertzog :

>
> > Does upgrading libgtk-3-0 to 3.21.6-1 fix the problem?
>
>
Upgrading it from sid work

Bug#837607: jessie-pu: package elog/2.9.2+2014.05.11git44800a7-2

[Adam D. Barratt]

On Tue, 2016-09-20 at 20:49 +0200, Roger Kalt wrote:
> Find attached the proposed patch to form 2.9.2+2014.05.11git44800a7-2 to
> 2.9.2+2014.05.11git44800a7-2+deb8u1.
> 
> The version number has been corrected.

Thanks.

In case it wasn't clear from my previous mail, please go ahead with the
upload.

Regards,

Adam

Bug#838260: diffoscope: Reduce noise from offsets deltas in readelf(1) diffs

[Chris Lamb]

Daniel Shahaf wrote:

> Example output:

Alas I'm not very learned in ELF, so I will trust the specifics are fine,
but just to check:

> 
> .rodata#1 is 0xA70
> .rodata#2 is 0xA80

… would be displayed (when different, of course!) as *something* like:

 - .rodata#1 is 0xA70
 + .rodata#1 is 0xA71

> The actual hex values could be displayed as a tooltip on the 'lea' line,
> or appended to that line as a '# comment'

So, tooltips are not only HTML-specific that would also hide data, particularly
for a) users who do not even know they need to run their mouse over something,
b) users who generally drive their browser via a keyboard (probably more common
for users of diffoscope!) and c) users with accessibility requirements.

Anyway, great idea - love it.


Regards,

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

Bug#838260: diffoscope: Reduce noise from offsets deltas in readelf(1) diffs

[Chris Lamb]

Jérémy Bobbio wrote:

> Initially, I thought of this as a way to add image comparison as 
> felt sad not knowing any free software that could easily provide
> similar features to what GitHub offers

Pff, you don't like my existing image comparison? ;-)


Regards,

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

Bug#833848: [gnome-shell] windows hang detection dialog had bad defaults

[Michael Biebl]

Hi,

first of all, thanks a lot for being so constructive and working with
upstream and working on a fix.

Am 20.09.2016 um 17:22 schrieb Landry MINOZA:
> Will you apply it or wait a new upstream version?

I will probably wait until upstream commits this patch. In general it
seems ok enough to be cherry-picked.

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



signature.asc
Description: OpenPGP digital signature

Bug#838388: debootstrap: Fails to strap squeeze since 1.0.83

[Stephan Sürken]

Hi Julien,

On Di, 2016-09-20 at 21:09 +0200, Julien Cristau wrote:

(...)

> > It always exits here with exit code 2, without any further error
> > message (not even when using --verbose).
> > 
> There should be a log inside the target directory.

ah, sure ;).

debootstrap/debootstrap.log says:

---
gpgv: Signature made Sat Apr 25 13:01:30 2015 CEST
gpgv:using RSA key AED4B06F473041FA
gpgv: Good signature from "Debian Archive Automatic Signing Key (6.0/squeeze) 
"
gpgv: Signature made Sat Apr 25 13:05:42 2015 CEST
gpgv:using RSA key 64481591B98321F9
gpgv: Good signature from "Squeeze Stable Release Key 
"
tar: ./usr/share/man/man1/sh.1.gz: Cannot create symlink to 'dash.1.gz': File 
exists
tar: ./bin/sh: Cannot create symlink to 'dash': File exists
tar: Exiting with failure status due to previous errors
gpgv: Signature made Sat Apr 25 13:01:30 2015 CEST
gpgv:using RSA key AED4B06F473041FA
gpgv: Good signature from "Debian Archive Automatic Signing Key (6.0/squeeze) 
"
gpgv: Signature made Sat Apr 25 13:05:42 2015 CEST
gpgv:using RSA key 64481591B98321F9
gpgv: Good signature from "Squeeze Stable Release Key 
"
tar: ./lib/libacl.so.1.1.0: Cannot open: File exists
tar: ./usr/share/doc/libacl1/copyright: Cannot open: File exists
tar: ./usr/share/doc/libacl1/changelog.Debian.gz: Cannot open: File exists
tar: ./usr/share/doc/libacl1/changelog.gz: Cannot open: File exists
tar: ./lib/libacl.so.1: Cannot create symlink to 'libacl.so.1.1.0': File exists
tar: Exiting with failure status due to previous errors
---

Hth!

S

Bug#830200: transition: perl

[Niko Tyni]

On Tue, Sep 20, 2016 at 07:03:41PM +0200, gregor herrmann wrote:
> On Mon, 19 Sep 2016 16:52:21 +0100, Dominic Hargreaves wrote:
> 
> > > #834249: openbabel - there is a patch available
> > 
> > These are nearly all sorted now - just openbabel to hit sid (in
> > DELAYED at the moment) and 
> 
> openbabel was ACCEPTED today but it failed to build 
> 
> - on mips:
> "c++: internal compiler error: Segmentation fault (program cc1plus)"
> https://buildd.debian.org/status/fetch.php?pkg=openbabel=mips=2.3.2%2Bdfsg-2.4=1474379322
> 
> - on mips64el:
> "openbabel-perl.cpp:17073:86: internal compiler error: in 
> df_reg_chain_unlink, at df-scan.c:790"
> https://buildd.debian.org/status/fetch.php?pkg=openbabel=mips64el=2.3.2%2Bdfsg-2.4=1474385515

Thanks for noticing. I've filed #838394 (just one for starters) about
this and will see if it's reproducible on the porter boxes.
-- 
Niko Tyni   nt...@debian.org

Bug#838397: linuxinfo: [FTBFS on ppc and ppc64el] error: expected declaration or statement at end of input

[Fernando Seiti Furusato]

Source: linuxinfo
Severity: normal
Tags: patch

Dear Maintainer,

The package linuxinfo fails to build from source on ppc and ppc64el,
because the file linuxinfo_ppc.c is missing a closing bracket.

The patch attached just adds it.

Regards.
Fernando
--- a/linuxinfo_ppc.c
+++ b/linuxinfo_ppc.c
@@ -62,7 +62,7 @@
 		{
 			megahertz = atoi(temp_string2);
 		}
-
+		}
 		if (!(strncmp(temp_string, "bogomips", strlen("bogomips"
 		{
 			sscanf(temp_string2, "%f", );

Bug#838396: jessie-pu: package zookeeper/3.4.5+dfsg-2

[Markus Koschany]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hello,

I would like to update zookeeper in Jessie which is currently affected
by CVE-2016-5017. The security team does not intend to release a DSA
for this issue.

Please find attached the debdiff against the current version in
Jessie.

Regards,

Markus
diff -Nru zookeeper-3.4.5+dfsg/debian/changelog zookeeper-3.4.5+dfsg/debian/changelog
--- zookeeper-3.4.5+dfsg/debian/changelog	2014-03-16 21:07:30.0 +0100
+++ zookeeper-3.4.5+dfsg/debian/changelog	2016-09-18 20:14:02.0 +0200
@@ -1,3 +1,15 @@
+zookeeper (3.4.5+dfsg-2+deb8u1) jessie; urgency=high
+
+  * Team upload.
+  * Fix CVE-2016-5017:
+Lyon Yang discovered that the C client shells cli_st and cli_mt of Apache
+Zookeeper, a high-performance coordination service for distributed
+applications, were affected by a buffer overflow vulnerability associated
+with parsing of the input command when using the "cmd:" batch mode syntax.
+If the command string exceeds 1024 characters a buffer overflow will occur.
+
+ -- Markus Koschany   Sun, 18 Sep 2016 20:14:02 +0200
+
 zookeeper (3.4.5+dfsg-2) unstable; urgency=high
 
   [ tony mancill ]
diff -Nru zookeeper-3.4.5+dfsg/debian/patches/CVE-2016-5017.patch zookeeper-3.4.5+dfsg/debian/patches/CVE-2016-5017.patch
--- zookeeper-3.4.5+dfsg/debian/patches/CVE-2016-5017.patch	1970-01-01 01:00:00.0 +0100
+++ zookeeper-3.4.5+dfsg/debian/patches/CVE-2016-5017.patch	2016-09-18 20:14:02.0 +0200
@@ -0,0 +1,37 @@
+From: Markus Koschany 
+Date: Sun, 18 Sep 2016 19:57:53 +0200
+Subject: CVE-2016-5017
+
+Lyon Yang discovered that the C client shells cli_st and cli_mt of Apache
+Zookeeper, a high-performance coordination service for distributed
+applications, were affected by a buffer overflow vulnerability associated with
+parsing of the input command when using the "cmd:" batch mode syntax. If the
+command string exceeds 1024 characters a buffer overflow will occur.
+
+
+Origin: https://git-wip-us.apache.org/repos/asf?p=zookeeper.git;a=commitdiff;h=27ecf981a15554dc8e64a28630af7a5c9e2bdf4f
+---
+ src/c/src/cli.c | 10 +-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+diff --git a/src/c/src/cli.c b/src/c/src/cli.c
+index c4538a6..959dd99 100644
+--- a/src/c/src/cli.c
 b/src/c/src/cli.c
+@@ -486,7 +486,15 @@ int main(int argc, char **argv) {
+ }
+ if (argc > 2) {
+   if(strncmp("cmd:",argv[2],4)==0){
+-strcpy(cmd,argv[2]+4);
++size_t cmdlen = strlen(argv[2]);
++if (cmdlen > sizeof(cmd)) {
++fprintf(stderr,
++"Command length %zu exceeds max length of %zu\n",
++cmdlen,
++sizeof(cmd));
++return 2;
++}
++strncpy(cmd, argv[2]+4, sizeof(cmd));
+ batchMode=1;
+ fprintf(stderr,"Batch mode: %s\n",cmd);
+   }else{
diff -Nru zookeeper-3.4.5+dfsg/debian/patches/series zookeeper-3.4.5+dfsg/debian/patches/series
--- zookeeper-3.4.5+dfsg/debian/patches/series	2014-03-15 18:45:57.0 +0100
+++ zookeeper-3.4.5+dfsg/debian/patches/series	2016-09-18 20:14:02.0 +0200
@@ -4,3 +4,4 @@
 fixes/ZOOKEEPER-705
 ftbfs-gcc-4.7.diff
 fixes/ZOOKEEPER-770
+CVE-2016-5017.patch

Bug#838395: libvdpau FTCBFS: fails to pass --host to configure

[Helmut Grohne]

Source: libvdpau
Version: 1.1.1-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libvdpau fails to cross build from source, because it doesn't pass
--host to configure and thus uses the build architecture toolchain.
Replacing the explicit ./configure invocation with dh_auto_configure
fixes the cross build, because dh_auto_configure knows the right flags.
It also simplifies the rules file. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru libvdpau-1.1.1/debian/changelog 
libvdpau-1.1.1/debian/changelog
--- libvdpau-1.1.1/debian/changelog 2015-10-29 00:47:48.0 +0100
+++ libvdpau-1.1.1/debian/changelog 2016-09-20 21:39:55.0 +0200
@@ -1,3 +1,10 @@
+libvdpau (1.1.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 20 Sep 2016 21:39:43 +0200
+
 libvdpau (1.1.1-3) unstable; urgency=medium
 
   [ Luca Boccassi ]
diff --minimal -Nru libvdpau-1.1.1/debian/rules libvdpau-1.1.1/debian/rules
--- libvdpau-1.1.1/debian/rules 2015-10-29 00:47:48.0 +0100
+++ libvdpau-1.1.1/debian/rules 2016-09-20 21:39:41.0 +0200
@@ -2,9 +2,6 @@
 
 #export DH_VERBOSE=1
 
-DEB_HOST_ARCH   ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
-DEB_HOST_MULTIARCH  ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
-
 # Used to enable documentation if dependencies are available
 define cond_enable
$(shell if test -x /usr/bin/doxygen && test -x /usr/bin/dot; \
@@ -24,9 +21,8 @@
 
 override_dh_auto_configure:
dh_testdir
-   LDFLAGS="-Wl,--as-needed $$(dpkg-buildflags --get LDFLAGS)" ./configure 
\
-   --prefix=/usr --sysconfdir=/etc 
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
-   $(CONFIGURE_OPTIONS)
+   LDFLAGS="-Wl,--as-needed $$(dpkg-buildflags --get LDFLAGS)" \
+   dh_auto_configure -- $(CONFIGURE_OPTIONS)
 
 override_dh_installdocs:
dh_installdocs -X.md5

Bug#838394: openbabel: FTBFS on mips,mips64el: internal compiler errors

[Niko Tyni]

Package: openbabel
Version: 2.3.2+dfsg-2.4
Severity: serious
Control: block 830200 with -1

This package failed to build on mips and mips64el.

- on mips:
"c++: internal compiler error: Segmentation fault (program cc1plus)"
https://buildd.debian.org/status/fetch.php?pkg=openbabel=mips=2.3.2%2Bdfsg-2.4=1474379322

- on mips64el:
"openbabel-perl.cpp:17073:86: internal compiler error: in df_reg_chain_unlink, 
at df-scan.c:790"
https://buildd.debian.org/status/fetch.php?pkg=openbabel=mips64el=2.3.2%2Bdfsg-2.4=1474385515

I'm running test builds on the porter boxes to see if these are
reproducible there and to gather data for gcc bug reports.

This blocks the Perl 5.24 transition so workarounds such as temporarily
building with an older compiler may be desirable.
-- 
Niko Tyni   nt...@debian.org

Bug#819869: nvidia-legacy-check: lock during install

[Luca Boccassi]

On Sun, 2016-09-18 at 21:14 +0200, Andreas Beckmann wrote:
> On 2016-09-10 20:13, Luca Boccassi wrote:
> > Unfortunately I have not been able to reproduce the issue, so I do not
> > know if we can kill it.
> 
> You may need some special broken hardware for that ...
> 
> > Perhaps documenting it is a good idea for now, until a better solution
> > can be found.
> 
> OK, I've implemented something. After 30 seconds the preinst will output
> a message. Can you try that, installing nvidia-legacy-check should *not*
> take 30 seconds on a normal system.

Installed on desktop and laptop, no issues.

Kind regards,
Luca Boccassi


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

Bug#838393: PCA on a repository insufficient to update uploaders

[Sam Hartman]

package: mini-buildd
version: 1.0.12


Hi.
I'd expect that if I change the extra keyrings configuration in the
repository, and then prepare/check/activate the repository, then any new
uploaders would be able to upload.

I've found that I need to restart the demon (I used systemctl, although
perhaps starting/stopping the daemon in the web interface would have
been sufficient).


It looks like what's happening is that the cache mapping repository
identities to uploader keyrings is stored on the demon object in the
_uploaders field and this isn't being refreshed when a repository is
reconfiged.

You could argue that cache is a demon thing, and so it is proper
behavior, but it's very confusing.
I think it would be worth having repository reactivation trigger
refreshing that cache.


--Sam

Bug#838376: ncurses: Please compile with --enable-ext-mouse

[Sven Joachim]

On 2016-09-20 21:45 +0300, Kirill Smelkov wrote:

> On Tue, Sep 20, 2016 at 08:05:00PM +0200, Sven Joachim wrote:
>> Many of those are already enabled by default if you configure
>> --with-abi-version=6, see the INSTALL file.  Unfortunately, we cannot
>> change the ABI before the release of Debian 9, but I definitely want to
>> do it after the Stretch release.
>
> Thanks for feedback and info about --with-abi-version=... .
>
> I see about ABI change and stretch release though just wondering: with
> introduction of libncurses6* which will be there along with currently
> present libncurses5* we are not changing ABI for libncurses5 and thus
> all packages which already use libncurses won't be affected before
> explicit change to their build-depends from libncurses5-dev to
> libncurses6-dev to them.

There is no plan to introduce libncurses6-dev since the API hasn't
changed.  Also, the transition should happen via binNMUs, without the
need to change source packages.

> I mean even if we add libncurses6* packages keeping libncurses5* in
> place there also, it won't break anything. Does this maybe change
> something about the time when libncurses6 can be introduced?

Not really, the problem is that ncurses in Jessie does not provide
versioned symbols, and we are supposed to support partial upgrades
without programs going down in flames when they have loaded both
libncurses.so.5 and libncurses.so.6 in their address space.  There are
quite a few libraries in Debian which depend on libncurses5 or
libncursesw5, so this is not an hypothetical problem.

Sorry for the bad news, but this bug has been open for over twelve
years, it can wait a few more months.

If you would like to discuss which features should be enabled in the
future ncurses6 packages, that's certainly welcome.  I haven't started
working on those yet, but with the freeze approaching it's about time to
make a new git branch in our repository. :-)

Cheers,
   Sven

Bug#838387: sweethome3d: Crashes when trying to render photo of the 3D view

[Julian]

Package: sweethome3d
Version: 4.5+dfsg-3
Followup-For: Bug #838387

5.2 is affectes too: Program still crashed. I downloaded the jar from the
official website.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7efc2dc820ad, pid=19348, tid=139620738709248
#
# JRE version: Java(TM) SE Runtime Environment (8.0_45-b14) (build
1.8.0_45-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# C  [libX11.so.6+0x390ad]  XQueryExtension+0x2d
#
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /opt/manuell-installiert/sweethome3d/hs_err_pid19348.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.


(btw: ulimit says "unlimited" so the output is wrong about this)



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

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

Versions of packages sweethome3d depends on:
ii  default-jre [java6-runtime]   2:1.8-57
ii  icedtea-netx-common   1.6.2-3
ii  java-wrappers 0.1.28
ii  libbatik-java 1.8-3
ii  libfreehep-graphicsio-svg-java2.1.1-4
ii  libitext-java 2.1.7-10
ii  libjava3d-java1.5.2+dfsg-11
ii  libsunflow-java   0.07.2.svn396+dfsg-14
ii  openjdk-8-jre [java6-runtime] 8u102-b14.1-2
ii  oracle-java8-jdk [java6-runtime]  8u45

Versions of packages sweethome3d recommends:
ii  sweethome3d-furniture  1.4.2-1

sweethome3d suggests no packages.

-- no debconf information
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7efc2dc820ad, pid=19348, tid=139620738709248
#
# JRE version: Java(TM) SE Runtime Environment (8.0_45-b14) (build 1.8.0_45-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode linux-amd64 
compressed oops)
# Problematic frame:
# C  [libX11.so.6+0x390ad]  XQueryExtension+0x2d
#
# Failed to write core dump. Core dumps have been disabled. To enable core 
dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---  T H R E A D  ---

Current thread (0x7efc0c003800):  JavaThread "J3D-Renderer-1" 
[_thread_in_native, id=19371, stack(0x7efbfc78b000,0x7efbfc88c000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 
0x

Registers:
RAX=0x, RBX=0x12510006, RCX=0x7efbfc889ed8, 
RDX=0x7efbfc889ed4
RSP=0x7efbfc889e60, RBP=0x7efbfedaeae8, RSI=0x7efbfedaeae8, 
RDI=0x12510006
R8 =0x7efbfc889edc, R9 =0x7efc092b4c30, R10=0x0004, 
R11=0x2000
R12=0x7efbfc889edc, R13=0x7efbfc889ed8, R14=0x7efbfc889ed4, 
R15=0x7efc082ab500
RIP=0x7efc2dc820ad, EFLAGS=0x00010246, CSGSFS=0x002b0033, 
ERR=0x
  TRAPNO=0x000d

Top of Stack: (sp=0x7efbfc889e60)
0x7efbfc889e60:   0002 00320008
0x7efbfc889e70:    
0x7efbfc889e80:   006e005b a0fd772f66ad5800
0x7efbfc889e90:    12510006
0x7efbfc889ea0:   00010002 7efbfedaeae8
0x7efbfc889eb0:    7efc2df8aa10
0x7efbfc889ec0:   7efc082ab500 7efc2dc75e92
0x7efbfc889ed0:   7efc082ab500 7efc49226cca
0x7efbfc889ee0:   7efc0874ab60 a0fd772f66ad5800
0x7efbfc889ef0:   7efc092b4c40 00010002
0x7efbfc889f00:   12510006 7efbfed733cc
0x7efbfc889f10:    7efc086404b0
0x7efbfc889f20:   00010002 7efc0858e980
0x7efbfc889f30:    03c00100
0x7efbfc889f40:   7efc082ab500 7efbfed9d4f6
0x7efbfc889f50:    
0x7efbfc889f60:   7efc0858e980 
0x7efbfc889f70:   03c00100 7efbf35eee25
0x7efbfc889f80:    7efbf3353e28
0x7efbfc889f90:   7efc0c003800 7efbfc88a010
0x7efbfc889fa0:   7efbfc889fd0 a0fd772f66ad5800
0x7efbfc889fb0: