Bug#804291: Crashes when starting after importing system VMs

[Thadeu Lima de Souza Cascardo]

Package: gnome-boxes
Version: 3.18.1-1
Severity: important

I imported my guests/domains from the system connection. After failure
to start them at all, I closed Boxes. After that, it crashes when
starting.

(gnome-boxes:7926): Libvirt.GObject-CRITICAL **:
gvir_storage_vol_get_info: assertion 'GVIR_IS_STORAGE_VOL(vol)' failed
Segmentation fault (core dumped)

Thanks for your work.
Cascardo.

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

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

Versions of packages gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  libarchive13 3.1.2-11+b1
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo-gobject21.14.4-1
ii  libcairo21.14.4-1
ii  libgdk-pixbuf2.0-0   2.32.1-1
ii  libgirepository-1.0-11.46.0-2
ii  libglib2.0-0 2.46.1-2
ii  libgtk-3-0   3.18.2-1
ii  libgtk-vnc-2.0-0 0.5.3-1.3
ii  libgudev-1.0-0   230-2
ii  libgvnc-1.0-00.5.3-1.3
ii  libosinfo-1.0-0  0.2.12-2
ii  libosinfo-bin0.2.12-2
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libsoup2.4-1 2.52.1-1
ii  libspice-client-glib-2.0-8   0.29-1+b1
ii  libspice-client-gtk-3.0-40.29-1+b1
ii  libtracker-sparql-1.0-0  1.6.0-2
ii  libusb-1.0-0 2:1.0.20-1
ii  libuuid1 2.27.1-1
ii  libvirt-bin  1.2.21-1
ii  libvirt-glib-1.0-0   0.2.2-0.1
ii  libvirt0 1.2.21-1
ii  libxml2  2.9.2+zdfsg1-4
ii  mtools   4.0.18-2
ii  tracker  1.6.0-2

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:2.4+dfsg-4

gnome-boxes suggests no packages.

-- no debconf information

Bug#804286: wwww.debian.org: Jigdo mirrors

[Brian Potkin]

Package: .debian.org
Severity: wishlist


The instructions at 
  

  
  https://www.debian.org/CD/jigdo-cd/#how   
  

  
are simplicity itself but may I suggest an addition which might enhance 
  
the use of jigdo. The advice is 
  

  
  At the prompt "Debian mirror", enter http://ftp.XY.debian.org/debian/,
  
  where XY is the two-letter code for your country (for example, us, de,
  
  uk. See the current list of available ftp.XY.debian.org locations.)   
  

  
Could we alter this to  
  

  
  At the prompt "Debian mirror", enter either http://httpredir.debian.org   
  
  or http://ftp.XY.debian.org/debian/, where XY is the two-letter code  
  
  for your country (for example, us, de, uk. See the current list of
  
  available ftp.XY.debian.org locations). The first mirror is recommended   
  
  for making best use of your bandwidth.
  

  
At the moment I am downloading DVD-4 and my line is maxed out. Very 
  
impressive. 
  

  
Regards,
  

  
Brian.



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

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
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)

Bug#802497: prepair: Fails to build with GDAL 2.0

[Sebastiaan Couwenberg]

Control: tags -1 patch

I've patched prepair to build successfully with GDAL 2.0 as
mentioned in the upstream bug report:

 https://github.com/tudelft3d/prepair/pull/23

The patch is included in the package available in git:

 
https://anonscm.debian.org/cgit/pkg-grass/prepair.git/commit/?id=e1c8e5755a4118c7b03aeaf7bc93d9084b955bca

I'm waiting for feedback from upstream before uploading a new prepair
revision with this patch.

Bug#803977: ITP: tlslite-ng -- Python SSL/TLS library

[Daniel Stender]

I've got a preliminary package ready. Manpages are missing and there are some 
import
problems with python-mock, but everything runs, though. It'll come up very 
soon, but if
somebody urgently needs it, here we go:
http://mentors.debian.net/debian/pool/main/t/tlslite-ng/tlslite-ng_0.5.1-1.dsc

Cheers,
DS
 
-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#801549: gitg: new upstream release available (3.18.0)

[Jérémy Lal]

2015-10-26 9:39 GMT+01:00 Dmitry Smirnov :

> On Sunday 25 October 2015 14:25:28 Jérémy Lal wrote:
> > I'm trying to find how to fix it.
>
> Thanks. I hope you have some ideas about it or we will just have to open
> upstream bug...
>

I haven't found why it's not building right in a sid chroot, while it
builds fine
in my user environment.

On the other hand, i'm opening quite big diffs (12000 lines) in something
like
4 seconds, and it's not crashing at all. Something else has changed - maybe
the webkit2gtk-4.0 2.11 i built and installed the other day.

Jérémy

Bug#804258: ITP: igb -- dkms source for the igb network driver

[Ben Hutchings]

On Fri, 2015-11-06 at 18:35 +0100, Clément Hermann wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Clément Hermann" 
> 
> * Package name: igb
>   Version : 5.3.3.2
>   Upstream Author : Intel Corporation
> * URL : http://sourceforge.net/projects/e1000/
> * License : GPL-2
>   Programming Lang: C
>   Description : dkms source for the igb network driver
> 
>  igb is the Linux device driver released for Intel 82575/6, 82580, I350, and
>  I210/211-based network interfaces. 
>  .
>  This driver uses the same base as the igb module included in the Linux 
> kernel,
>  with added features such as advanced multiqueue control (RSS), interrupts
>  throttle management, Large Receive Offload (LRO) and Low Latency Interrupts
>  (LLI).
>  .
>  Only use this driver if you need these specific features.
[...]

This description is inaccurate; two of the four features mentioned
actually are included in the in-tree driver.  And I don't think there'a
anything stopping Intel's maintainers from adding the remaining
features to the in-tree driver.

The justification for adding an alternate version of the driver seems
quite weak.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

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

Bug#448697: aptitude: display not correctly updated

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo help


Hello,

2007-11-01 08:06 Mario Frasca:

On 2007-1031 19:59:19, Daniel Burrows wrote:

  Do you have a multi-core machine?


multi core machine?

I don't think so, I have a old iMac ...

processor   : 0
cpu : 750CXe
temperature : 14-16 C (uncalibrated)
clock   : 500.00MHz
revision: 34.21 (pvr 0008 2215)
bogomips: 49.79
timebase: 2496
platform: PowerMac
machine : PowerMac4,1
motherboard : PowerMac4,1 MacRISC2 MacRISC Power Macintosh
detected as : 256 (iMac "Flower Power")
pmac flags  : 0010
L2 cache: 256K unified
pmac-generation : NewWorld

by the way, at office I also see the same problem, there I have the
following, which is a lot faster than what I have at home, but I don't
recognize it as a multi-core either.



2013-05-21 06:57 ri...@happyleptic.org:

I had the exact same bug that appeared also when upgrading wheezy
some years ago, and I finally get rid of it changing the TERM envvar
from xterm-256color to screen-256color-bce (I use screen).

So maybe you should have a look at your TERM as well?


Can you please confirm if this is still happening in recent
machines/systems?

Also, the problem with screen happened also with a Mac, or with any kind
of hardware?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#804290: can't follow certain redirects

[積丹尼 Dan Jacobson]

Package: midori
Version: 0.5.11-2
Severity: minor

Odd, I need to open https://t.co/9qzU9mefyz in a private browsing
window, else I get:

The page located at “(null)” cannot be found. Check the web address for 
misspelled words and try again.
URL cannot be shown

Or I have to use /usr/bin/HEAD

and then give this to midori
http://hardware.slashdot.org/story/15/11/05/2210240/ocean-mapping-robots-could-help-uncover-mysteries-of-the-deep-blue

to finally read the page.

Bug#804292: stunnel4: FTBFS with DEB_BUILD_OPTIONS=nocheck

[Daniel Schepler]

Source: stunnel4
Version: 3:5.18-1
Severity: important

>From my pbuilder build log, actually with DEB_BUILD_OPTIONS set to
"parallel=8 nocheck":

...
# Rename binary
mv /build/stunnel4-5.18/debian/stunnel4/usr/bin/stunnel
\
 /build/stunnel4-5.18/debian/stunnel4/usr/bin/stunnel4
# Move docs into proper dir
mv /build/stunnel4-5.18/debian/stunnel4/usr/share/doc/stunnel   \
 /build/stunnel4-5.18/debian/stunnel4/usr/share/doc/stunnel4
# Copy sample init script into place for dh_installinit
cp /build/stunnel4-5.18/tools/stunnel.init
/build/stunnel4-5.18/debian/stunnel4.init
cp: cannot stat '/build/stunnel4-5.18/tools/stunnel.init': No such file or
directory
debian/rules:26: recipe for target 'override_dh_auto_install' failed
make[1]: *** [override_dh_auto_install] Error 1
make[1]: Leaving directory '/build/stunnel4-5.18'
debian/rules:63: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
status 2

(This also appears to be the cause of build failures on some of the
debian-ports architectures.)
-- 
Daniel Schepler

Bug#804285: transition: ode

[Leopold Palomo-Avellaneda]

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

Dear Release Team,

I'm filing this bug for a new transition of ode (Open Dynamics Engine). 

In Debian we have a version too old (0.11.1-4.1, 2009-05-25). The package has 
been 
rewritten and a new version has been uploaded to experimental 
(0.13.1+git20150309-1). 
This version has been tested with the ode build dependencies with this result:

darkplaces: ok, built
k3d: ok, built
mokomaze: ok, built
mu-cade: ok built
ompl: ok built
pyepl: ok built
pyode: ok built
soya: too old the debian version. Upstream didn't test the new version with 
0.13.x ode
taoframework: ok, built
stormbaancoureur: ok. built
xmoto: ok, built


Ben file:

title = "ode";
is_affected = .depends ~ /\b(libode4|libode\-sp\-dev|libode1|libode1sp)\b/;
is_good = .depends ~ /\b(libode4)\b/;
is_bad = .depends ~ /\b(libode\-sp\-dev|libode1|libode1sp)\b/;



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

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

Bug#779515: Should enable the qxl kernel driver when installed

[Laurent Bigonville]

reassign 779515 linux-image-4.2.0-1-amd64
severity 779515 important
thanks

On Sun, 01 Mar 2015 18:47:54 + Ben Hutchings  
wrote:


> I've enabled the kernel's qxl driver, but disabled by default so that
> it doesn't conflict with wheezy's version of xserver-xorg-video-qxl.
>
> Please install a modprobe configuration file with the line:
>
> options qxl modeset=1
>
> (When I tried this on a VM host with virt-manager and QEMU from sid,
> the qxl driver complained of missing features, so KMS still didn't
> work. However, the fall-back to UMS still worked.)

Shouldn't the qxl kernel module be enabled by default in unstable now 
that the xserver-xorg-video-qxl package has been updated?


I quickly tested with stretch kernel and xserver-xorg-video-qxl and it 
seems to work, well actually now that Xserver is running without root 
rights, kernel qxl driver is actually required, X is not starting otherwise.


Could you please revert your patch and enable qxl by default when needed?

Cheers,

Laurent Bigonville

Bug#804284: please don't build with srcdir==builddir and srcdir!=builddir

[Andreas Cadhalpun]

Control: tags -1 moreinfo

Hi Matthias,

On 06.11.2015 23:15, Matthias Klose wrote:
> please don't build with srcdir==builddir and srcdir!=builddir.
> while it may work in this case, there is no guarantee that build
> artifacts from the srcdir==builddir build will be picked up in the 
> srcdir!=builddir build.
> 
> So please build every flavour with srcdir!=builddir.

While I understand what you want me to change, I don't understand why.
Can you be more specific about the problem you've encountered?

Best regards,
Andreas

Bug#803606: elpa-magit: pre-removal script fails: “No such file or directory” for ‘site-lisp’ entries

[Branislav Zahradník]

On Wed, 4 Nov 2015 08:20:10 +1100 Ben Finney  wrote:

On 03-Nov-2015, Rémi Vanicat wrote:
> Current elpa-magit prerm script just call a perl script from the
> emacsen-common package. What version of emacsen-common do you have?
> If it isn't 2.0.8 or latter, could you upgrade it and try again?

It is:

=
$ dpkg-query --show elpa-magit emacs24 emacsen-common
elpa-magit  2.2.2-3
emacs24 24.5+1-2
emacsen-common  2.0.8
=

That's part of the problem, as I understand it. Emacs is only partly
upgraded; when ‘emacs24’ tries to upgrade, it attempts to upgrade
‘elpa-magit’.

When that fails, the system is left in an inconsistent state:
‘elpa-magit’ cannot move beyond 2.2.2-3, but ‘emacs24’ requires that
before its upgrade is complete.

Meanwhile ‘emacsen-common’ is already at version 2.0.8, which causes
‘elpa-magit’ to fail its pre-remove (whether version 2.2.2-3 or
version 2.3.0-2). And around we go again :-)




--
 \   德不孤、必有鄰。 (The virtuous are not abandoned, |
  `\   they shall surely have neighbours.) |
_o__)—孔夫子 Confucius (551 BCE – 479 BCE) |
Ben Finney 


I'm affected by this bug as well.
I guess problem is in file:

/usr/lib/emacsen-common/packages/remove/elpa-magit

line:
  find ${elc_dir} -type l -delete

if ${elc_dir} doesn't exist, find fails. Solution:

  [ -e ${elc_dir} ] && find ${elc_dir} -type l -delete

Problem is also with other elpa packages: elpa-git-commit, elpa-magit-popup, 
elpa-with-editor

Bug#803013: systemd should not destroy application created cgroups

[Michael Biebl]

Hi Paul

Am 06.11.2015 um 01:00 schrieb paul.sz...@sydney.edu.au:
> Dear Michael,
> 
>>> I wonder how that line came to be missed on my machines: I upgraded from
>>> wheezy (which was upgraded from previous releases).
>>
>> If that line was not automatically added it probably means you had made
>> custom modifications to the file in the past.
> 
> Possible, but unlikely: the only difference between my 
>   /etc/pam.d/common-session
> file and that from the freshly installed jessie, is the
>   session optional pam_systemd.so
> line.

Well, apparently pam-auth-update was convinced you had local modifications.

If you restore the previous state and you ran
dpkg-reconfigure libpam-runtime, what do you get?


>> Not having libpam-systemd installed probably means, that your user
>> processes are not properly added to the correct cgroups.
> 
> I do have libpam-systemd installed (though not "active" because of my
> "broken" common-session file).
> 
> With my "broken" /etc/pam.d/common-session file, systemd did not create
> /sys/fs/cgroup/systemd/user.slice/user-N.slice/ directories. Why should
> the lack of those interfere with my use of cgroups? If the PAM setting
> is so important, should not it be set to required?
> 
> There is also a file
>   /etc/pam.d/common-session-noninteractive
> that does not contain the pam_systemd.so line, used for cron and sudo
> (maybe others): can cgroups be used for or from those?

I'm not sure what to do about this bug report. I'm inclined to close it,
since it doesn't look like something which we can address in systemd itself.

Cheers,
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#804287: acknowledge that one is really running in --download-only mode before asking user Y/n/?

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.7.4-1
Severity: wishlist

# aptitude --download-only install $@
[ Download Only Mode. No installations etc. will actually be performed.] <- 
Please
add a line like that to the output, else the user worries that maybe
--download-only was ignored and the following will really take place:
The following NEW packages will be installed: ...
The following packages will be upgraded: ...
The following packages are RECOMMENDED but will NOT be installed: ...
The following packages are SUGGESTED but will NOT be installed: ...
1 packages upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
Need to get 4,123 kB of archives. After unpacking 2,084 kB will be used.
Do you want to continue? [Y/n/?]

Bug#803474: src:systemd: Please use the default linker instead of gold on sparc64

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/05/2015 06:14 PM, Michael Biebl wrote:
> Am 05.11.2015 um 17:53 schrieb John Paul Adrian Glaubitz:
>> On Nov 5, 2015, at 5:31 PM, Michael Biebl 
>> wrote:
> 
>>> Depending on what actually is broken, a workaround could also
>>> be to make that functionality in gold on sparc a nop instead of
>>> generating broken code.
>> 
>> Which would probably involve much more patching and hacking than
>> just using the working linker in the first place.
> 
> Well, depending on how broken gold on sparc* actually is, wouldn't
> it be an option to simply make /usr/bin/ld.gold a symlink to
> ld.bfd? That workaround would be trivial to implement as well.

I'll try something similar now. I'll build binutils on sparc* explicitly
without gold now. Do you know whether systemd will still build fine on
systems where gold is not available at all or will it fail?

If systemd will still build fine in such cases and default to bfd, then
I'll happily patch binutils instead.

> This would have the additional benefit that this workaround would
> apply for all packages that use gold and this workaround can be
> dropped exactly when gold has been fixed.

Yeah, I'll look into that now. I have done more digging and it actually
seems that gold results in Qt5 FTBFS on sparc64 now. But I haven't fully
confirmed that now.

>>> Don't you think we should first understand what is broken and
>>> what the impact is?
>> 
>> Well, gold is missing support for SPARCs STT-REGISTER
> 
> I don't actually know what that is. Does that mean every executable
> that has been built with gold is broken on sparc?

Looks like that. I'll do some more research now.

Adrian

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

iQIcBAEBCAAGBQJWPTeQAAoJEHQmOzf1tfkT2W0P/1vlMSNxpgbhb8I5pwsgB+ux
rh0SHBe21ZiuCIvT9Ei7g0yu0Nk3zpDcr5GncfjbfRxNyQw5V4NxCkIT4sejoO5z
HQ7OyD55CKX/in2+/UBUlTOCCJya8holec/OeWAg88jIypzClWA2KX3GUnt0RczW
Kpo2+zIju914uEgHQEjVuvcMukG/2pZjWS6IrpkfBvwietaCAYtZyMlPFFs3sNhk
8+5Bcw2IcsUI/V+MiPMdYRPKouDkZezS2MwqNZKa0bxhocvztHfeufPjjxymhJBN
+9HONvo5KxYVGSTdyrMYOQrLoga6h2QfeX6fVjgzFdFngDF3fBQ0ikCLpWs8ktKQ
/JiGjeaq2SGXKlGhNuE+/hjVcSrnhWZkhKjaR+HlYDkDspc9XOsZasbSEmdUquMr
Cf27HedCfkQdGyb5l1piFpv5Vo3xDieCK9BkYlc3YLoqAbBH8z9ND7/2EqV8uN4F
4VTd1ag3Q9809t0MXYrFIyl7avTz0jq0BmatLjbnQuhxRd89a7txxH8wNiWlJIsz
GelVpOX4ZAI7g4hISgjXAPBuoi4pNHb04fT1CPR3ijYj/+7mlIADvD4Yc8e2QfNG
h8djZ6hPfMiNdjifItMzL1sd0Rldt95NuddVNNQx+zIRyFZpEqYk+5vzrsEiBRFE
gfOdT65h8tlrhqHuA9fD
=9F9W
-END PGP SIGNATURE-

Bug#804288: Does not detect a git worktree directory

[Joachim Breitner]

Package: gitg
Version: 3.17.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

when working in a directory created with "git worktree", i.e. one where
I have
$ cat .git
gitdir: /home/jojo/debian/pkg-haskell/packages/.git/worktrees/packages-7.10
running gitg behaves as if I ran it outside any git repository.

Maybe its "is this a git repo" detection logic is insufficient, and it
should maybe simply ask git.

Greetings,
Joachim

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

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

Versions of packages gitg depends on:
ii  dbus-x11 1.10.2-1
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gir1.2-peas-1.0  1.16.0-1
ii  git  1:2.6.2-1
ii  gsettings-desktop-schemas3.18.1-1
ii  libc62.19-22
ii  libcairo21.14.4-1
ii  libgdk-pixbuf2.0-0   2.32.1-1
ii  libgee-0.8-2 0.18.0-1
ii  libgirepository-1.0-11.46.0-2
ii  libgit2-glib-1.0-0   0.23.6-1
ii  libglib2.0-0 2.46.1-2
ii  libgtk-3-0   3.18.2-1
ii  libgtksourceview-3.0-1   3.18.1-1
ii  libgtkspell3-3-0 3.0.7-2
ii  libjavascriptcoregtk-4.0-18  2.10.3+dfsg1-1
ii  libjson-glib-1.0-0   1.0.4-2
ii  libpango-1.0-0   1.38.1-1
ii  libpeas-1.0-01.16.0-1
ii  libsecret-1-00.18.3-1
ii  libsoup2.4-1 2.52.1-1
ii  libwebkit2gtk-4.0-37 2.10.3+dfsg1-1

gitg recommends no packages.

gitg suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlY9PXoACgkQ9ijrk0dDIGy9fgCfeV78bsamEL5UUvncQXHKHoLT
hYoAn2fT2ZP3yIf/psD/aHDFjetnIgV8
=bYOW
-END PGP SIGNATURE-

Bug#804289: libcacard-dev: Please add libglib2.0-dev to the dependencies

[Laurent Bigonville]

Package: libcacard-dev
Version: 1:2.5.0-1a
Severity: serious

Hi,

The libcacard.pc file requires glib2.0 but the package is not declaring
any dependencies against libglib2.0-dev.

Please add it to the dependencies

Cheers,

Laurent Bigonville

-- 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.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libcacard-dev depends on:
ii  libcacard0   1:2.5.0-1a
ii  libnss3-dev  2:3.20.1-1

libcacard-dev recommends no packages.

libcacard-dev suggests no packages.

-- no debconf information

Bug#802813: osmcoastline: Fails to build with GDAL 2.0

[Sebastiaan Couwenberg]

Control: tags -1 patch

I've patched osmcoastline to build successfully with GDAL 2.0 as
mentioned in the upstream bug report:

 https://github.com/osmcode/osmcoastline/pull/16

The patch is included in the package available in git:

 
https://anonscm.debian.org/cgit/pkg-grass/osmcoastline.git/commit/?id=40bd55bcfa63afffd5cbcbd52725e03f14f185e4

I'm waiting for feedback from upstream before uploading a new
osmcoastline revision with this patch.

Bug#804295: initramfs-tools: doesn't warn/fail when dpkg triggers for update-initramfs don't actually update

[Christoph Anton Mitterer]

Package: initramfs-tools
Version: 0.120
Severity: normal


Hi.

I've just noted the following:
Processing triggers for initramfs-tools (0.120) ...
update-initramfs: /boot/initrd.img-4.2.0-1-amd64 has been altered.
update-initramfs: Cannot update. Override with -t option.

Not sure what caused it to think that I've modified it,... nevertheless.
such a status message will likely just drown in the flood of log messages
during any update.
And in such case the initramfs may stay stale, which could cause quite
some troubles,... from non booting systems up to even security issues.


I'm not sure whether it would be better to simply let the trigger use -t,
cause this may be undesired either.

Would there be a way to give a more interactive warning (e.g. debconf)?
Or does it seem reasonable in such a case to fail the trigger?

Cheers,
Chris.

Bug#804240: similar issue

[James Healy]

Hi,

I'm experiencing the same issue.

With both 1.0.25-1 (sid) and 1.0.25+git20150927-1 (experimental), the
output of sane-find-scanner detects my scanner:

# sane-find-scanner
found USB scanner (vendor=0x05ac [Apple Inc.], product=0x828f
[Bluetooth USB Host Controller]) at libusb:001:006
found USB scanner (vendor=0x03f0 [HP], product=0x7111 [Photosmart
C5300 series]) at libusb:001:010

However, with 1.0.25-1 the output of scanimage -L is blank, and with
1.0.25+git20150927-1 the output of scanimage -L is:

scanimage -L
device `hpaio:/usb/Photosmart_C5300_series?serial=MY89Q5702P054V'
is a Hewlett-Packard Photosmart_C5300_series all-in-one

Let me know if there's further debugging info I can provide.

James

Bug#803159: linux: Enable DT support for armel/orion5x arch

[Roger Shimizu]

Patch appended, to avoid any misunderstanding.
 - 0001 is both OK for sid and jessie
 - 0002 is only necessary for sid, or other 4.x kernel series (e.g.
jessie-backport)

Thank you!

Cheers,
Roger
From ecc1733be537bf5c2583b50a0664b583cf294b37 Mon Sep 17 00:00:00 2001
From: Roger Shimizu 
Date: Tue, 27 Oct 2015 22:28:43 +0900
Subject: [PATCH 1/2] [armel/orion5x] enable DT support

Signed-off-by: Roger Shimizu 
---
 debian/config/armel/config.orion5x | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/debian/config/armel/config.orion5x b/debian/config/armel/config.orion5x
index a7f4888..1e4703f 100644
--- a/debian/config/armel/config.orion5x
+++ b/debian/config/armel/config.orion5x
@@ -8,6 +8,8 @@ CONFIG_PCI=y
 CONFIG_UACCESS_WITH_MEMCPY=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CMDLINE=""
 # CONFIG_XIP_KERNEL is not set
 CONFIG_ATAGS_PROC=y
@@ -23,6 +25,7 @@ CONFIG_VFP=y
 ##
 CONFIG_MACH_DB88F5281=y
 CONFIG_MACH_RD88F5182=y
+CONFIG_MACH_RD88F5182_DT=y
 CONFIG_MACH_KUROBOX_PRO=y
 CONFIG_MACH_DNS323=y
 CONFIG_MACH_TS209=y
@@ -264,6 +267,7 @@ CONFIG_MTD=y
 # CONFIG_MTD_REDBOOT_PARTS is not set
 CONFIG_MTD_CMDLINE_PARTS=y
 # CONFIG_MTD_AFS_PARTS is not set
+CONFIG_MTD_OF_PARTS=y
 CONFIG_MTD_BLOCK=y
 CONFIG_FTL=m
 CONFIG_NFTL=m
@@ -318,6 +322,7 @@ CONFIG_MTD_CFI_STAA=m
 ## file: drivers/mtd/maps/Kconfig
 ##
 # CONFIG_MTD_COMPLEX_MAPPINGS is not set
+CONFIG_MTD_PHYSMAP_OF=y
 # CONFIG_MTD_IMPA7 is not set
 # CONFIG_MTD_INTEL_VR_NOR is not set
 # CONFIG_MTD_PLATRAM is not set
@@ -487,6 +492,11 @@ CONFIG_RTC_DRV_S35390A=y
 # CONFIG_SSB is not set
 
 ##
+## file: drivers/tty/serial/Kconfig
+##
+CONFIG_SERIAL_OF_PLATFORM=y
+
+##
 ## file: drivers/tty/serial/8250/Kconfig
 ##
 CONFIG_SERIAL_8250=y
-- 
2.1.4

From d2f7318266850e3dd87ea9b045031a3871b8a055 Mon Sep 17 00:00:00 2001
From: Roger Shimizu 
Date: Sat, 7 Nov 2015 11:35:57 +0900
Subject: [PATCH 2/2] [armel/orion5x] Enable DEBUG_LL_UART_8250, to replace
 DEBUG_ICEDCC, which is default since Linux 4.0 and hangs booting on
 armel/orion5x

Signed-off-by: Roger Shimizu 
---
 debian/config/armel/config.orion5x | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/config/armel/config.orion5x b/debian/config/armel/config.orion5x
index 1e4703f..00404b9 100644
--- a/debian/config/armel/config.orion5x
+++ b/debian/config/armel/config.orion5x
@@ -16,6 +16,13 @@ CONFIG_ATAGS_PROC=y
 CONFIG_VFP=y
 
 ##
+## file: arch/arm/Kconfig.debug
+##
+## choice: Kernel low-level debugging port
+CONFIG_DEBUG_LL_UART_8250=y
+## end choice
+
+##
 ## file: arch/arm/mach-imx/Kconfig
 ##
 # CONFIG_ARCH_MXC is not set
-- 
2.1.4

Bug#804294: boltdb: upstream version bump: 1.1.0

[Tianon Gravi]

Package: src:golang-github-boltdb-bolt
Version: 0.0~git20150715.980670a-1
X-Debbugs-CC: Alexandre Viau 

It'd be really excellent if we could get a bump to the recent 1.1.0
release, especially since it adds support for architectures like
arm64. :)

As usual, willing to do the bump work myself as a team upload if you'd prefer!

I've tested the following patch, and it builds successfully.  I also
tested reverse dependencies via ratt and they all build successfully
too, so I think this is a major win:

diff --git a/debian/changelog b/debian/changelog
index 13963ae..fd83aec 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+golang-github-boltdb-bolt (1.1.0-1) UNRELEASED; urgency=medium
+
+  * Update to 1.1.0 upstream release.
+
+ -- Tianon Gravi   Wed, 04 Nov 2015 15:14:31 -0800
+
 golang-github-boltdb-bolt (0.0~git20150715.980670a-1) unstable; urgency=low

   * Initial release. (Closes: #781321)
diff --git a/debian/rules b/debian/rules
index 02f4969..b530be5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,4 +13,4 @@ override_dh_auto_install:
  rm -rf --verbose $(TMP)/*/usr/bin

 override_dh_auto_test:
- dh_auto_test -- -timeout 12000s
+ dh_auto_test -- -short
diff --git a/debian/watch b/debian/watch
new file mode 100644
index 000..6aad255
--- /dev/null
+++ b/debian/watch
@@ -0,0 +1,3 @@
+version=3
+opts=filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/bolt-$1\.tar\.gz/ \
+  https://github.com/boltdb/bolt/tags .*/v([\d\.]+)\.tar\.gz

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#803977: ITP: tlslite-ng -- Python SSL/TLS library

[Daniel Stender]

I've seen that there's some recent development going on at tlslite [1] and it's
not officially stated that this is the successor of the original package, so it
would be best to package this as the fork like it is with binaries 
"python{,3}-tlslite-ng".

[1] https://github.com/trevp/tlslite

DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#595888: closed by "Manuel A. Fernandez Montecelo" <manuel.montez...@gmail.com> (Re: provide feedback when forbidding packages)

[積丹尼 Dan Jacobson]

OK they should first do a an aptitude search to see what their pattern
matches before then using it with forbid-version. OK I guess.

Bug#804101: 's problem still very much there

[積丹尼 Dan Jacobson]

P.S., what was this new release all about?
$ debdiff /var/cache/apt/archives/phpmyadmin_4%3a4.5.1-*
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Version: [-4:4.5.1-2-] {+4:4.5.1-3+}

Bug#803975: libcrypt-ssleay-perl: Uses SSLv3_client_method()

[gregor herrmann]

On Fri, 06 Nov 2015 22:07:25 +0100, Kurt Roeckx wrote:

> On Fri, Nov 06, 2015 at 09:22:04PM +0200, Niko Tyni wrote:
> > As discussed on IRC, it looks to me like there's no code support for
> > HTTPS_VERSION in 0.73_04 anymore. It seems to be just a leftover in
> > the docs.
> > 
> > The upstream code in 0.73_04 now uses SSLv23_client_method() with
> >  SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3
> > by default, and with
> >  SSL_OP_ALL | SSL_OP_NO_SSLv2
> > if the (currently undocumented) environment variable
> > CRYPT_SSLEAY_ALLOW_SSLv3 is set.
> > 
> > This seems to be pretty much we want, so I think uploading 0.73_04 is
> > the way to fix this bug. The docs could be improved a bit of course.
> 
> Yes, that looks good to me.

Thanks everybody; uploaded.


Cheers,
gregor

PS: Bug filed about the doc inconsistencies:
https://rt.cpan.org/Ticket/Display.html?id=108520

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Janis Joplin: Maybe


signature.asc
Description: Digital Signature

Bug#804282: [duplicity] missing versioned dependency on lockfile

[Alexander Zangerl]

On Fri, 06 Nov 2015 23:37:37 +0200, Török Edwin writes:
>I had version 1:0.8-2 of python-lockfile installed.

arrrgh! i forgot to specify the epoch in the version
dependency...(1:0.8 is greater than 0.9 as far as
dpkg is concerned)

sorry about that, i'll upload a fixed version in the
next hour.

>the stale lockfile bug is still there [1].

...and i don't think you'll see any improvement there until
duplicity stops using python-lockfile altogether, which is marked
deprecated by its developers.

regards
az


-- 
Alexander Zangerl + GPG Key 0xB963BD5F + http://snafu.priv.at/
"The first rule of magic is simple.  Don't waste your time waving your
hands and hoping when a rock or a club will do." -- McCloctnik the Lucid


signature.asc
Description: Digital Signature

Bug#804283: RFS: igb/5.3.3.2-1 [ITP] -- out of tree Intel Gigabit Ethernet driver.

[Paul Wise]

On Sat, Nov 7, 2015 at 5:39 AM, Clement Hermann wrote:

> The package is needed because the in-tree driver doesn't have advanced 
> features such as interrupt throttle,
> multiqueue or Large Receive Offload.

Has Intel sent these features for inclusion in Linux mainline?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#779515: Should enable the qxl kernel driver when installed

[Ben Hutchings]

On Sat, 2015-11-07 at 00:24 +0100, Laurent Bigonville wrote:
> reassign 779515 linux-image-4.2.0-1-amd64
> severity 779515 important
> thanks
> 
> On Sun, 01 Mar 2015 18:47:54 + Ben Hutchings  
> wrote:
> 
>  > I've enabled the kernel's qxl driver, but disabled by default so that
>  > it doesn't conflict with wheezy's version of xserver-xorg-video-qxl.
>  >
>  > Please install a modprobe configuration file with the line:
>  >
>  > options qxl modeset=1
>  >
>  > (When I tried this on a VM host with virt-manager and QEMU from sid,
>  > the qxl driver complained of missing features, so KMS still didn't
>  > work. However, the fall-back to UMS still worked.)
> 
> Shouldn't the qxl kernel module be enabled by default in unstable now 
> that the xserver-xorg-video-qxl package has been updated?
[...]

Only if xserver-xorg-video-qxl in jessie works properly with KMS.  Is
that the case?

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

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

Bug#804297: graphviz: dot on mipsel fails with emit.c:3873: bezier_bb: Assertion `bz.size > 0' failed

[Johannes Schauer]

Package: graphviz
Version: 2.38.0-10
Severity: important
Control: block 804296 by -1

Hi,

I ran into this problem when building my package botch on mipsel:

https://buildd.debian.org/status/fetch.php?pkg=botch=mipsel=0.17-2=1446862050

dot -T png buildgraph1.dot > buildgraph1.png
dot: emit.c:3873: bezier_bb: Assertion `bz.size > 0' failed.
Aborted
Makefile:14: recipe for target 'buildgraph1.png' failed
make[2]: *** [buildgraph1.png] Error 134
make[2]: Leaving directory '/«PKGBUILDDIR»/doc/wiki'
Makefile:89: recipe for target 'doc' failed
make[1]: *** [doc] Error 2
make[1]: Leaving directory '/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
debian/rules:6: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2

botch uses dot to generate a png from a dot file which fails with:

dot: emit.c:3873: bezier_bb: Assertion `bz.size > 0' failed.

but also only on mipsel. The other architectures build just fine.

The problem can be trigged by the most minimal input:

$ echo -ne 'digraph G {A -> B}' | dot
dot: emit.c:3873: bezier_bb: Assertion `bz.size > 0' failed.
Aborted

To reproduce this problem, on a porter box do the following:

$ ssh etler.debian.org
josch@etler:~$ mysid=sid$RANDOM
josch@etler:~$ schroot -b -c sid -n $mysid
josch@etler:~$ dd-schroot-cmd -c $mysid apt-get update
josch@etler:~$ dd-schroot-cmd -c $mysid apt-get upgrade
josch@etler:~$ dd-schroot-cmd -c $mysid apt-get install graphviz
josch@etler:~$ schroot -r -c $mysid
(sid_mipsel-dchroot)josch@etler:~$ echo -ne 'digraph G {A -> B}' | dot
dot: emit.c:3873: bezier_bb: Assertion `bz.size > 0' failed.
Aborted
(sid_mipsel-dchroot)josch@etler:~$ logout
josch@etler:~$ schroot -e -c $mysid
josch@etler:~$ logout

Thanks!

cheers, josch

Bug#804100: RFS: rhythmbox-plugin-alternative-toolbar/0.14.0-1~debian [ITP]

[foss.freedom]

Gianfranco,

  as you have recommended I have revamped the package.  This has been
uploaded to mentors.debian.net

dget -x 
http://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.14.1-1.dsc


 The package now just uses the Github tarball - I no longer build this
separately.

 The change log has a close statement with the ITP WNPP bug number

 The control description and extended description fields have been
reworked.

 In terms of the my Githhub repository - again as you have recommended, the
debian subfolder and gentoo subfolders are now in their own branches.  This
should make maintenance  of the package easier moving forward.

thanks

David (fossfreedom)

On 6 November 2015 at 13:50, Gianfranco Costamagna <
costamagnagianfra...@yahoo.it> wrote:

> Hi,
>
> >"Description: Show or hide the main toolbar for Rhythmbox"
> >
> >Maybe something like this is better?
> >
> >"Description: a Rhythmbox 3.x plugin that provides an enhanced toolbar
> capability.
> >  A compact toolbar with enhanced song seek capabilities.
> >  A revised graphical interface using the Gnome Headerbar is also
> available.
> >
> >  A new simpler sidebar with refreshed icons is optionally available."
>
>
> yes, the problem is the extended description, that should have something
> (look at some packages in the archive for references)
>
> >The Git tarball as far as I understand it is a snapshot of the particular
> commit - e.g. v0.14.1
>
>
> yes, the tag
> >This tarball would include all the sourcetree files including the files
> you said I shouldnt include in the debian package - the .git folder, the
> tar.gz file etc.
>
>
> there arent any tar.gz or git files AFAIK (well, one single tar.gz file
> but we can leave with it).
>
> I would suggest you moving gentoo and debian in separate branches, to
> avoid the need to release a new upstream release when a packaging bug is
> fixed.
>
> I can live with some useless files in the source tarball, as long as no
> repackage is needed (and it seems to be not the case)
>
>
> >Maybe I'm just building the debian package in the wrong manner.  I'm
> doing the following at the moment:
> >
> >
> >git clone https://github.com/fossfreedom/alternative-toolbar
> >
> >cd alternative-toolbar
> >
> >dch -i
> >
> >   add the new upstream version and change log
> >
> >cd ..
> >
> >cd rhythmbox-plugin-alternative-toolbar-0.14.1
> >
> >dh_make --createorig
> >
> >debuild -S -k0x[gpg key]
> >
> >
> >should I miss out the dh_make --createorig step that creates the package
> tarball but instead download the GitHub tag tarball (.tar.gz file) and
> rename it >appropriately?
>
>
> yes.
>
> download the tarball (uscan does this for you when you have a watch file)
>
>
> call it something like
>
> rhythmbox-plugin-alternative-toolbar_0.14.1.orig.tar.gz
>
>
> extract, copy the debian directory inside (if you start to have a separate
> branch)
>
> debuild -S or dpkg-buildpackage -S  or whatever
>
> live happy :)
>
> >Then within the folder rhythmbox-plugin-alterative-toolbar-0.14.1 delete
> the files and folders you have recommended that should not packaged?
>
> nope, they are a few kb of files, you can leave them
>
> >I thought debuild would then complain because the package contents no
> longer match the tarball contents - or is there a debuild option here that
> can help?
>
>
> this is true for modifications, not for deletions.
>
> >thanks
>
>
> yw
>
> G.
>
>
> On 6 November 2015 at 12:35, Gianfranco Costamagna <
> costamagnagianfra...@yahoo.it> wrote:
>
> Hi,
> >
> >
> >>I've never heard of pyflakes and pyflakes3 - so thanks for introducing
> me to these tools.  I've run these and they no longer throw errors out.
> >
> >
> >wonderful
> >>I've run your PEP8 command.  The vast majority of the PEP8 issues have
> now been addressed.  For some reason it is picking out whitespace issues
> with documentation >comments.
> >
> >
> >well, they are many false positive in the above tools :)
> >
> >>There are one-or-two slightly too long PEP8 lines left.  I've left these
> since the readability is important.
> >
> >
> >sure, not a problem at all
> >>The find statement is worrying me.  All the translations have been
> exported directly from launchpad.net where the application is actually
> translated by the >wonderful launchpad translation team.  I dont really
> have any control as to the output from launchpad.
> >
> >
> >fine then :)
> >
> >>Is there a way to "cleanup" these translation po's ?  A quick google
> didnt reveal much.
> >
> >
> >I guess not, maybe poedit fills the files when updating, but I don't know
> about another way, you can leave them
> >>With regards to the source package - I've introduced a cleanup script on
> the git project called "debian_cleanup.sh" - this removes the .git folder,
> .idea folder, >the install.sh and the tar.gz file you asked me to remove.
> >
> >
> >sorry but I fail to understand what is the problem in using the git tag
> 

Bug#804296: botch: dot assertion failed when building docs on mipsel

[Johannes Schauer]

Source: botch
Version: 0.17-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

on mipsel the following error happens:

dot -T png buildgraph1.dot > buildgraph1.png
dot: emit.c:3873: bezier_bb: Assertion `bz.size > 0' failed.
Aborted
Makefile:14: recipe for target 'buildgraph1.png' failed
make[2]: *** [buildgraph1.png] Error 134
make[2]: Leaving directory '/«PKGBUILDDIR»/doc/wiki'
Makefile:89: recipe for target 'doc' failed
make[1]: *** [doc] Error 2
make[1]: Leaving directory '/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
debian/rules:6: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

full log:

https://buildd.debian.org/status/fetch.php?pkg=botch=mipsel=0.17-2=1446862050

Bug#804240: libsane: scanning does not work with HPLIP backend

[Jörg Frings-Fürst]

Hello Raphaël,
hello James,

I have check the difference between the 1.0.25-1 and
1.0.25+git20150927-1.

So I found one wrongly removed patch. A version with the re-enabled
patch was uploaded to mentors[1]. Can you build and test this version?

If you need I can build the package for Jessie, Stretch or Sid [amd64,
i386]. 


Thanks 

CU
Jörg


[1] 
http://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.25-2.dsc

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

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

Jörg Frings-Fürst
D-54526 Niederkail

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

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





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

Bug#804256: lintian: false positive postrm-should-call-ldconfig

[Jörg Frings-Fürst]

tags 804256 - moreinfo
thanks


Hello Adam,


Am Freitag, den 06.11.2015, 17:45 + schrieb Adam D. Barratt:
> Control: tags -1 + moreinfo
> 
[...]
> 
> Is the package in question available somewhere? 2.5.37 already
> contained
> this change:
> 
> + [NT] Accept an "activate-noawait ldconfig" trigger instead of
>   explicit calls to "ldconfig".
> 

Yes, but only the source at mentors[1].


> Regards,
> 
> Adam
> 

CU
Jörg

[1] 
http://mentors.debian.net/debian/pool/main/h/homer/homer_0.26.0~svn3080-1.dsc


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

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

Jörg Frings-Fürst
D-54526 Niederkail

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

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





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

Bug#804148: fix memory leak

[Andrew Starr-Bochicchio]

Thanks for your work on this. I'll get it uploaded sometime tomorrow.
On Nov 6, 2015 11:21 PM, "Ulrik Sverdrup"  wrote:

> Package: libkeybinder0
> Version: 0.3.0-3
> Followup-For: Bug #804148
>
> Dear Maintainer,
>
> Fixed in upstream version 0.3.1
>
> https://github.com/engla/keybinder/releases
>

Bug#726732: marked as done (pyflakes: Split Python 2 and Python 3 dependencies)

[Alexandre Detiste]

Le vendredi 6 novembre 2015, 23:03:04 Debian Bug Tracking System a écrit :
> Your message dated Fri, 06 Nov 2015 23:00:39 +
> with message-id 
> and subject line Bug#726732: fixed in pyflakes 1.0.0-2
> has caused the Debian Bug report #726732,
> regarding pyflakes: Split Python 2 and Python 3 dependencies
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 
> 

Hi,

When doing "apt install pyflakes -t unstable",

I got this error once; then on a second attempt with "apt-get -f install" it 
succeeded, because pyflakes=1.0.0-2 was there.

Maybe you need to add some some "Breaks":

-

Préparation du dépaquetage de .../python-pyflakes_1.0.0-2_all.deb ...
Dépaquetage de python-pyflakes (1.0.0-2) ...
dpkg: erreur de traitement de l'archive 
/var/cache/apt/archives/python-pyflakes_1.0.0-2_all.deb (--unpack) :
 tentative de remplacement de « 
/usr/lib/python2.7/dist-packages/pyflakes/test/test_other.py », qui appartient 
aussi au paquet pyflakes 1.0.0-1
Sélection du paquet python3-pyflakes précédemment désélectionné.
Préparation du dépaquetage de .../python3-pyflakes_1.0.0-2_all.deb ...
Dépaquetage de python3-pyflakes (1.0.0-2) ...
dpkg: erreur de traitement de l'archive 
/var/cache/apt/archives/python3-pyflakes_1.0.0-2_all.deb (--unpack) :
 tentative de remplacement de « 
/usr/lib/python3/dist-packages/pyflakes/test/test_other.py », qui appartient 
aussi au paquet pyflakes 1.0.0-1
Préparation du dépaquetage de .../pyflakes_1.0.0-2_all.deb ...
Dépaquetage de pyflakes (1.0.0-2) sur (1.0.0-1) ...


>From http://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/po/fr.po:

msgid "trying to overwrite '%.250s', which is also in package %.250s %.250s"
msgstr ""
"tentative de remplacement de « %.250s », qui appartient aussi au paquet "
"%.250s %.250s"

Bug#804298: RFS: hello/1.0-1 [ITP] -- homer

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

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

   Package name: homer
   Version : 0.26.0~svn3080-1
   Upstream Author : Thomas Volkert 
   URL : http://www.homer-conferencing.com
   License : GPL-2+
   Section : video

  It builds those binary packages:

homer - Video conferencing system
    homer-dbg  - Debug files for homer

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

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


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

dget -x 
http://mentors.debian.net/debian/pool/main/h/homer/homer_0.26.0~svn3080-1.dsc

  Changes since the last upload:


  * Initial release (Closes: #787333, LP: #1074135)


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

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

Jörg Frings-Fürst
D-54526 Niederkail

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

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





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

Bug#804211: mime-support: Please add decoding and encoding support for xz

[Charles Plessy]

Control: tag -1 pending

Le Fri, Nov 06, 2015 at 09:40:33AM +0100, Nicolas Schier a écrit :
> 
> could you please add decoding and encoding support for xz archives?  I
> attach a patch that works for me.

Applied, thank you !

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#789721: smartmontools- upstream 6.4 available

[Christoph Anton Mitterer]

Package: smartmontools
Version: 6.3+svn4002-2+b3
Followup-For: Bug #789721


Hey.

Anything new here? 6.3 is more than a year old and 6.4 contains
quite interesting patches that e.g. make new USB/SATA bridges
work, like:
https://www.smartmontools.org/changeset/4011
(or could you cherry pick this)

Apparently also better support for the very popular
Samsung Evo 8xx series of SSDs.

Other newly supported bridges include:
- USB: ViPowER USB3.0 Storage (0x0350:0x0038)
- USB: Buffalo DriveStation HD-LBU2 (0x0411:0x01ea)
- USB: Toshiba Stor.E Basics; (0x0480:0xa00e)
- USB: Toshiba Canvio Desktop (0x0480:0xd011)
- USB: Samsung M3 Portable USB 3.0 (0x04e8:0x61b3)
- USB: Iomega (0x059b:0x0575)
- USB: Genesys Logic GL3310 (0x05e3:0x0731)
- USB: Freecom HD (0x07ab:0xfcd6)
- USB: Apricorn SATA Wire (0x0984:0x0040)
- USB: WD My Passport (0x1058:0x0830)
- USB: WD My Book: Merge entries, add 0x1058:0x0900, 0x1058:0x1104
- USB: Initio (0x13fd:0x3940)
- USB: Super Top (0x14cd:0x6116): change to -d sat
- USB: JMicron (0x152d:0x2590) (ticket #550)
- USB: ASMedia ASM1053/1153 (0x174c:0x1[01]53)
- USB: Verbatim Pocket Hard Drive (0x18a5:0x0237)
- USB: Verbatim External Hard Drive (0x18a5:0x0400)
- USB: VIA VL701 (0x2109:0x0701)
- USB: Unknown (0x2537:0x106[68])
- USB: Hitachi Touro Mobile (0x4971:0x1020)
- USB: Samsung D3 Station 4TB (0x04e8:0x6125) (ticket #549)
- USB: Seagate Backup Plus USB 3.0 (0x0bc2:0xa003)
- USB: Seagate Backup Plus Desktop USB 3.0 5TB (0x0bc2:0xab31)
- USB: JMicron (0x152d:0x3569) (ticket #546)
- USB: Buffalo Drivestation Duo (0x0411:0x01ce)
- USB: Toshiba Canvio Basics (0x0480:0x0201, 0xa00d)
- USB: Toshiba Stor.E Basics (0x0480:0xa00c)
- USB: Toshiba Canvio ALU (0x0480:0xa100)
- USB: Toshiba Canvio Desktop (0x0480:0xd000)
- USB: Samsung S2 Portable (0x04e8:0x1f0a)
- USB: Samsung S3 Portable (0x04e8:0x61c8)
- USB: LaCie Rugged Triple Interface (0x059f:0x100c)
- USB: Initio (0x13fd:0x3910)
- USB: ASMedia (0x174c:0x5516)
- USB: Innostor IS611 (0x1f75:0x0611)
- USB: Seagate FreeAgent XTreme (0x0bc2:0x3101)
- USB: Seagate Expansion Portable (0x0bc2:0x232[01])
- USB: Seagate Expansion External (0x0bc2:0x3321)
- USB: Seagate FreeAgent GoFlex (0x0bc2:0x5070, 0x50a7, 0x6121)
- USB: Seagate Slim Portable Drive (0x0bc2:0xab00) (ticket #517)
- USB: Seagate Backup Plus Slim (0x0bc2:0xab21)
- USB: ADATA HD650 (0x125f:0xa35a)
- USB: JMicron JMS567 (0x152d:0x3562) (ticket #508)
- USB: Innostor IS621 (0x1f75:0x0621) (ticket #517)
- USB: SanDisk SDCZ80 Flash Drive (0x0781:0x5580)
- USB: WD My Passport: Merge entries, add 0x1058:0x0810
- USB: WD Elements Desktop: Merge entries, add 0x1058:0x107c
- USB: WD Elements: Merge entries
- USB: JMicron JMS539 (0x152d:0x0539): 2.06 and 28.03 support SAT
- USB: JMicron JMS567 (0x152d:0x0567) (ticket #504)
- USB: JMicron JMS566 (0x152d:0x2566)
- USB: Hitachi Touro (0x4971:0x1014)
- USB: Prolific PL2571, PL2771, PL2775 (0x067b:0x2.7.)



Cheers,
Chris.

Bug#804266: [Pkg-mozext-maintainers] Bug#804266: Please use signed plugins for Adblock Plus and so on

[Julien Aubin]

Hello,

Yes this could be definitely a fix as long as you have a way to identify
that the file comes from the package manager and is unaltered.

2015-11-06 23:05 GMT+01:00 Benjamin Drung :

> Am Freitag, den 06.11.2015, 20:06 +0100 schrieb Julien Aubin:
> > As of Firefox 44 / Iceweasel 44 unsigned plugins won't be allowed
> > anymore. Currently the Adblock Plus package in Debian archive (and
> > actually every other XPI plugin) are not signed. So could you please
> > fix this before Firefox 44 / Iceweasel 44 ships ?
>
> How should that work?
>
> We build all packages from source and require the power to change the
> code (e.g., for bug or security fixes). The signing key needs to be
> accessible when building. So should we create a signing key and add
> that to the package? That would defeat the purpose.
>
> IMO Iceweasel should trust the package manager and what it installs
> into the system.
>
> --
> Benjamin Drung
> Debian & Ubuntu Developer
>
>
>

Bug#804299: smartmontools: update-smart-drivedb downloads unauthenticated data from the web

[Christoph Anton Mitterer]

Package: smartmontools
Version: 6.3+svn4002-2+b3
Severity: important
Tags: security


Hi.

The update-smart-drivedb downloads unauthenticated data
from the web (drive.h).

Put apart, that the it wouldn't be the first time, that
the corresponding parser has problems which may lead to
exploits, even if it correctly parses everything and just
the right syntax would be accepted, then this could be
still used to cause damage, namely when the respective
SMART command mustn't be used with a specific drive.
(There are apparently some which cause damage.)


I think update-smart-drivedb should be removed alltogether
from Debian, as it circumvents the package management system
and thereby and security support, which is generally bad.

Instead, if there's a new drivedb.h, then a package update
should be made.


But as long as there's no proper authentication (and I'm
not talking about https), this should definitely go away.


Cheers,
Chris.

Bug#804302: libclamunrar6: dependency on libclamunrar6

[Jamil Djadala]

Package: libclamunrar6
Version: 0.98.5-1
Severity: wishlist

Dear Maintainer,

please increase dependency on libclamunrar6 to recommends, if i install
clamav, i expect it to able to scan all files.

regards,
Jamil Djadala   


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

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

Versions of packages libclamunrar6 depends on:
ii  libc6   2.19-18+deb8u1
ii  libclamav6  0.98.7+dfsg-0+deb8u1

libclamunrar6 recommends no packages.

libclamunrar6 suggests no packages.

-- no debconf information

Bug#802432: fixed, can be closed.

[Jos van Wolput]

Dear Maintainer,

Issue fixed in version linux-image-4.3.0-trunk-amd64 (4.3-1~exp1).
Bug #802432 can be closed.

-- System Information:
Debian Release: sid + experimental
Architecture: amd64 (x86_64)
Kernel: linux-image-4.3.0-trunk-amd64
Systemd: 227-2

Kind regards,
Jos v.Wolput

Bug#804240: libsane: scanning does not work with HPLIP backend

[Raphael Hertzog]

Hi,

On Sat, 07 Nov 2015, Jörg Frings-Fürst wrote:
> So I found one wrongly removed patch. A version with the re-enabled
> patch was uploaded to mentors[1]. Can you build and test this version?

Yes, it works!

Thank you.
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#804091: Artemis - Java 8 support

[Afif Elghraoui]

Hi, Dr. Page,

On الجمعـة  6 تشرين الثاني 2015 01:33, Andrew Page wrote:
> For the past year or so we have had no dedicated software developer for 
> Artemis. We hope to fill this position in the new year however there is a 
> very long backlog of feature requests and bugs to get through.
> We would welcome any pull requests on GitHub which allow for Java 8 support.
> 

Thanks for your prompt response. I'll see what we can do.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#728753: mock: should create mock system group and directories

[Taylor Braun-Jones]

What's the status of this bug? I was just hit by this bug only to and was
surprised to discover that the bug report is actually quite old. Happy to
test any fixes.

Taylor

Bug#803013: systemd should not destroy application created cgroups

[paul . szabo]

Dear Michael,

 I wonder how that line came to be missed on my machines ...
> If you restore the previous state and you ran
> dpkg-reconfigure libpam-runtime, what do you get?

Running
  dpkg-reconfigure libpam-runtime
asks me nicely:

  PAM configuration
  
  Pluggable Authentication Modules (PAM) determine how authentication,
  authorization, and password changing are handled on the system, as
  well as allowing configuration of additional actions to take when
  starting user sessions.
  
  Some PAM module packages provide profiles that can be used to
  automatically adjust the behavior of all PAM-using applications on the
  system.  Please indicate which of these behaviors you wish to enable.
  
  PAM profiles to enable:
  
 [*] Unix authentication
 [ ] Register user sessions in the systemd control group hierarchy
 [ ] GNOME Keyring Daemon - Login keyring management
 [ ] Inheritable Capabilities Management
  


There is no indication that I should, or must, select "do systemd".

>> There is also a file
>>   /etc/pam.d/common-session-noninteractive
>> that does not contain the pam_systemd.so line, used for cron and sudo
>> (maybe others): can cgroups be used for or from those?

I wonder.

> I'm not sure what to do about this bug report. I'm inclined to close
> it, since it doesn't look like something which we can address in
> systemd itself.

I believe my patch would make systemd more robust, that may help to
prevent future recurrences of this bug.

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Bug#804183: dbus fails to start, circular inclusion of *.dpkg-bak

[Holger Schramm]

Hi,

I cannot reproduce the bug. After making the update I had no *.bak files
and no problems.

Perhaps there were problems during the update with aptitude o. sth?

-- 
Holger

Bug#804148: fix memory leak

[Ulrik Sverdrup]

Package: libkeybinder0
Version: 0.3.0-3
Followup-For: Bug #804148

Dear Maintainer,

Fixed in upstream version 0.3.1

https://github.com/engla/keybinder/releases

Bug#804301: ITP: bruteforce-luks -- Try to find the password of a LUKS encrypted volume

[Paulo Roberto Alves de Oliveira (aka kretcheu)]

Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)" 

* Package name: bruteforce-luks
  Version : 1.1
  Upstream Author : 
Guillaume.LE.VAILLANT.
* URL : https://github.com/glv2/bruteforce-luks
* License : (GPL-3+)
  Programming Lang: (C)
  Description : Try to find the password of a LUKS encrypted volume

 The program tries to decrypt at least one of the key slots by trying
 all the possible passwords. It is especially useful if you know
 something about the password (i.e. you forgot a part of your password but still
 remember most of it). Finding the password of a volume without knowing
 anything about it would take way too much time (unless the password is really
 short and/or weak).

Bug#804239: [uscan] Failure when basename is in query string

[Osamu Aoki]

Hi,

On Fri, Nov 06, 2015 at 01:48:49PM +, Robie Basak wrote:
> Package: devscripts
> Version: 2.15.8
> 
> If the download URL is a query string, such as
> http://www.example.com/download?file=package-version.tar.gz, then uscan
> ends up downloading the file as package-version.download which
> subsequently causes mk-origtargz to fail with something like:
> 
> Parameter ../package-version.download does not look like a tar archive or a 
> zip file. at /usr/bin/mk-origtargz line 330.
> 
> As far as I can tell, this makes uscan unusable for me for mysql-5.6.
> More specifics for my case:
> 
> http://dev.mysql.com/downloads/mysql/5.6.html?os=src lists opaque link
> URLs for the actual upstream tarballs (eg.
> http://dev.mysql.com/downloads/file/?id=459308) but does have links with
> versions embedded for the gpg files (eg.
> http://dev.mysql.com/downloads/gpg/?file=mysql-5.6.27.tar.gz) and I know
> how to construct a link for a corresponding release tarball (eg.
> http://dev.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.27.tar.gz).
> 
> So it appeared to me that I could coax uscan into working with this
> scheme and came up with the following:
> 
> opts=downloadurlmangle=s/\/downloads\/gpg\/?\?file=(mysql-([\d\.]*).tar.gz)/\/get\/Downloads\/MySQL-5.6\/$1/,pgpsigurlmangle=s/\/get\/Downloads\/MySQL-5.6\/(mysql-([\d\.]*).tar.gz)/\/downloads\/gpg\/?file=$1/
>  \
> http://dev.mysql.com/downloads/mysql/5.6.html?os=src 
> /downloads/gpg/\?file=mysql-([\d\.]*).tar.gz
> 
> This works to find the available versions and does download and gpg verify
> the release tarball correctly. However it then fails with:
> 
> Parameter ../mysql-5.6-5.6.27.download does not look like a tar archive or a 
> zip file. at /usr/bin/mk-origtargz line 330.
> uscan: error: mk-origtargz --package mysql-5.6 --version 5.6.27 --compression 
> gzip --directory .. --copyright-file debian/copyright 
> ../mysql-5.6-5.6.27.download gave error exit status 255
> 
> AFAICT the cause is the following snippet in uscan:
> 
> # Remove HTTP header trash
> if ($site =~ m%^https?://%) {
> $newfile_base =~ s/\?.*$//;
> # just in case this leaves us with nothing
> if ($newfile_base eq '') {
> $newfile_base = "$pkg-$newversion.download";
> }
> }

This is ugly workaround which may be better to be replaced with error if
there is no filenamemangle rule defined to make $newfile_base

> It seems to me that the "just in case" handling will always cause a
> future failure because mk-origtargz will always reject this name. I
> haven't tested this but if instead of .download it used .tar.gz then it
> would work in my case.
> 
> I haven't found any way of working around this but suggestions
> appreciated. In the meantime I'm filing this bug because:

Did you try filenamemangle which can generate filename from the full
href string.

   filenamemangle=rules
   Normalize the downloaded tarball filename string
   -.tar.gz from the selected href string.

   If this option doesn't exist, the default upstream tarball filename
   is found by taking the last component of the URL and removing
   everything after any '?'

(Yes, I should install release version of uscan to test this by my self
... but your help to check this is most appreciated.  I think this part
of code is problematic.)

At least, warning should be printed out by uscan.  I will work on
together with #526450 and #803948.

Osamu


Osamu

Bug#784768: libhiredis-dev: Transition to cmake 3.2

[Tom Lee]

Tags: +confirmed +pending

A fix for this is forthcoming.

Bug#804304: libqt4pas: support for ppc64 architecture (trivial)

[Paul Gevers]

Source: libqt4pas
Version: 2.5-14
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Looking at the build logs¹ for libqt4pas on the ppc64 architecture, it should
be trivial to support libqt4pas there again. The only requirements seems to be
an updated symbols file. I prepared the patch (untested, but looks fine) which
you can find attached to this report as git commit diffs against your git
archive. Please let me know if you want me to commit directly and if you want
me to handle this with an NMU.

By the way: as this package now depends on fpc to build, wouldn't it make sense
to request removal of the old binaries on architectures where fpc hasn't been
bootstrapped?

Also, would it make sense for you to join the Pascal Package Team (on Alioth):
https://alioth.debian.org/projects/pkg-pascal/ and/or transfer you package to
the team maintenance?

¹https://buildd.debian.org/status/fetch.php?pkg=libqt4pas=ppc64=2.5-14=1442125805

- -- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (60, 'unstable'), (50, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-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)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJWPZ88AAoJEJxcmesFvXUK/uAIAMNiedf8gVAtrQ0Jr6KR6d6V
9EGPId0ilIG2PnWTyT6NoP38BbCBJ6NbDjISFM1XgsvW8EZqCR0YOnEeYDgKbmtc
1L07xu2DglIMJNb5ht6IaRt2usYHYgo443DViDwgBQOwF2mzqLQu3LZuesL9wWxP
bMjwRtqIPcRzZc7JM/5Dp1FHDGksD1Jew7SvFMORi6dPG+MvPfvi0SZ4ghz+tOGV
4udPh0v9kIPg+XmGg1O2axLJ8BFqjThQ4m/WNv8fJ7YNuVqInoVwiqnKKu1Qwwsu
0HOLdhMJpO8KtESdaCWQ4y+1c1mYJn72WHDOI3eG7ma7zNHATF6Xfq8olINUPAQ=
=YJ0c
-END PGP SIGNATURE-
>From 13b6f01bbb904362d75afd0ea7f5c3302e717d3e Mon Sep 17 00:00:00 2001
From: Paul Gevers 
Date: Sat, 7 Nov 2015 07:33:28 +0100
Subject: [PATCH 1/2] Update symbols file for ppc64 support

---
 debian/libqt4pas5.symbols | 142 +++---
 1 file changed, 71 insertions(+), 71 deletions(-)

diff --git a/debian/libqt4pas5.symbols b/debian/libqt4pas5.symbols
index c690c3f..4206ba0 100644
--- a/debian/libqt4pas5.symbols
+++ b/debian/libqt4pas5.symbols
@@ -7726,7 +7726,7 @@ libQt4Pas.so.5 libqt4pas5 #MINVER#
  QX11Info_setAppUserTime@Base 2.4
  QX11Info_visual@Base 2.4
  QtVersion@Base 2.4
- (arch=!powerpc)_Z24copyQStringToPWideStringRK7QStringPv@Base 2.5
+ (arch=!powerpc !ppc64)_Z24copyQStringToPWideStringRK7QStringPv@Base 2.5
  (optional=templinst)_Z30copyPtrIntArrayToQListTemplateIP13QGraphicsItemEvPvR5QListIT_E@Base 2.4
  (optional=templinst)_Z30copyPtrIntArrayToQListTemplateIP13QStandardItemEvPvR5QListIT_E@Base 2.4
  (optional=templinst)_Z30copyPtrIntArrayToQListTemplateIP15QTreeWidgetItemEvPvR5QListIT_E@Base 2.4
@@ -7759,8 +7759,8 @@ libQt4Pas.so.5 libqt4pas5 #MINVER#
  (optional=templinst)_Z37copyQListTemplateToPtrIntArrayWithNewI15QWebHistoryItemEvR5QListIT_EPv@Base 2.4
  (optional=templinst)_Z37copyQListTemplateToPtrIntArrayWithNewI18QWebSecurityOriginEvR5QListIT_EPv@Base 2.4
  (optional=templinst)_Z37copyQListTemplateToPtrIntArrayWithNewI9QFileInfoEvR5QListIT_EPv@Base 2.4
- (arch=armel armhf powerpc)_ZN10QByteArrayD1Ev@Base 2.5
- (arch=armel armhf powerpc)_ZN10QByteArrayD2Ev@Base 2.5
+ (arch=armel armhf powerpc ppc64)_ZN10QByteArrayD1Ev@Base 2.5
+ (arch=armel armhf powerpc ppc64)_ZN10QByteArrayD2Ev@Base 2.5
  _ZN10QDrag_hook11qt_metacallEN11QMetaObject4CallEiPPv@Base 2.4
  _ZN10QDrag_hook11qt_metacastEPKc@Base 2.4
  _ZN10QDrag_hook16staticMetaObjectE@Base 2.4
@@ -7979,7 +7979,7 @@ libQt4Pas.so.5 libqt4pas5 #MINVER#
  _ZN15QLCDNumber_hookD0Ev@Base 2.4
  _ZN15QLCDNumber_hookD1Ev@Base 2.4
  _ZN15QLCDNumber_hookD2Ev@Base 2.4
- (arch=amd64 armel armhf i386 powerpc sparc)_ZN15QListWidgetItem18setBackgroundColorERK6QColor@Base 2.5
+ (arch=amd64 armel armhf i386 powerpc ppc64 sparc)_ZN15QListWidgetItem18setBackgroundColorERK6QColor@Base 2.5
  _ZN15QScrollBar_hook11qt_metacallEN11QMetaObject4CallEiPPv@Base 2.4
  _ZN15QScrollBar_hook11qt_metacastEPKc@Base 2.4
  _ZN15QScrollBar_hook16staticMetaObjectE@Base 2.4
@@ -8427,120 +8427,120 @@ libQt4Pas.so.5 libqt4pas5 #MINVER#
  _ZN32QAbstractTextDocumentLayout_hookD1Ev@Base 2.4
  _ZN32QAbstractTextDocumentLayout_hookD2Ev@Base 2.4
  (optional=templinst)_ZN5QListI11QModelIndexE13detach_helperEi@Base 2.4
- (optional=templinst|arch=armel armhf powerpc)_ZN5QListI11QModelIndexED1Ev@Base 2.5
- (optional=templinst|arch=armel armhf powerpc)_ZN5QListI11QModelIndexED2Ev@Base 2.5
+ (optional=templinst|arch=armel armhf powerpc ppc64)_ZN5QListI11QModelIndexED1Ev@Base 2.5
+ (optional=templinst|arch=armel armhf powerpc ppc64)_ZN5QListI11QModelIndexED2Ev@Base 2.5
  (optional=templinst)_ZN5QListI12QPrinterInfoE13detach_helperEi@Base 2.4
- (optional=templinst|arch=armel armhf 

Bug#804081: lightdm-gtk-greeter-settings does not build reproducibly

[James Lu]

Hi Christian,

I've made the changes in setup.py to sort the fields in
installation_config in the Git tree. However, when running the build
multiple times, the output .deb's from the different tries still don't
have the same checksum. debbindiff seems to be pointing out timestamp
differences in the a bunch of things (output is attached), though I
haven't tested the builds with the official reproducible builds
toolchain yet.

Also, is making the build reproducible important enough to get its own
upload? Or should I wait for the release/big change?

The section is fixed in Git too (now says x11).

Best,
James
gl@midnight:~/packages/lightdm-gtk-greeter-settings/lightdm-gtk-greeter-settings-1.2.0$
 debbindiff ../lightdm-gtk-greeter-settings_1.2.0-2~_all.deb 
../test1/lightdm-gtk-greeter-settings_1.2.0-2~_all.deb
--- ../lightdm-gtk-greeter-settings_1.2.0-2~_all.deb
+++ ../test1/lightdm-gtk-greeter-settings_1.2.0-2~_all.deb
├── metadata
│ @@ -1,3 +1,3 @@
│  rw-r--r-- 0/0  4 Nov  7 03:24 2015 debian-binary
│ -rw-r--r-- 0/0   2470 Nov  7 03:24 2015 control.tar.gz
│ -rw-r--r-- 0/0  77552 Nov  7 03:24 2015 data.tar.xz
│ +rw-r--r-- 0/0   2469 Nov  7 03:24 2015 control.tar.gz
│ +rw-r--r-- 0/0  77536 Nov  7 03:24 2015 data.tar.xz
├── control.tar.gz
│   ├── control.tar
│   │   ├── tar --full-time -tvf {}
│   │   │ @@ -1,5 +1,5 @@
│   │   │ -drwxr-xr-x root/root 0 2015-11-07 03:24:58 ./
│   │   │ --rwxr-xr-x root/root   185 2015-11-07 03:24:58 ./postinst
│   │   │ --rwxr-xr-x root/root   429 2015-11-07 03:24:58 ./prerm
│   │   │ --rw-r--r-- root/root  4937 2015-11-07 03:24:58 ./md5sums
│   │   │ --rw-r--r-- root/root   644 2015-11-07 03:24:58 ./control
│   │   │ +drwxr-xr-x root/root 0 2015-11-07 03:24:48 ./
│   │   │ +-rwxr-xr-x root/root   185 2015-11-07 03:24:48 ./postinst
│   │   │ +-rwxr-xr-x root/root   429 2015-11-07 03:24:48 ./prerm
│   │   │ +-rw-r--r-- root/root  4937 2015-11-07 03:24:48 ./md5sums
│   │   │ +-rw-r--r-- root/root   644 2015-11-07 03:24:48 ./control
│   │   ╵
│   ╵
├── data.tar.xz
│   ├── data.tar
│   │   ├── tar --full-time -tvf {}
│   │   │ @@ -1,108 +1,108 @@
│   │   │ -drwxr-xr-x root/root 0 2015-11-07 03:24:58 ./
│   │   │ -drwxr-xr-x root/root 0 2015-11-07 03:24:53 ./usr/
│   │   │ -drwxr-xr-x root/root 0 2015-11-07 03:24:54 ./usr/lib/
│   │   │ -drwxr-xr-x root/root 0 2015-11-07 03:24:54 ./usr/lib/python3/
│   │   │ -drwxr-xr-x root/root 0 2015-11-07 03:24:54 
./usr/lib/python3/dist-packages/
│   │   │ -drwxr-xr-x root/root 0 2015-11-07 03:24:54 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/
│   │   │ +drwxr-xr-x root/root 0 2015-11-07 03:24:48 ./
│   │   │ +drwxr-xr-x root/root 0 2015-11-07 03:24:43 ./usr/
│   │   │ +drwxr-xr-x root/root 0 2015-11-07 03:24:43 ./usr/lib/
│   │   │ +drwxr-xr-x root/root 0 2015-11-07 03:24:43 ./usr/lib/python3/
│   │   │ +drwxr-xr-x root/root 0 2015-11-07 03:24:43 
./usr/lib/python3/dist-packages/
│   │   │ +drwxr-xr-x root/root 0 2015-11-07 03:24:43 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/
│   │   │  -rw-r--r-- root/root  8159 2015-05-21 02:46:25 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/Config.py
│   │   │ --rw-r--r-- root/root   211 2015-11-07 03:24:53 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/installation_config.py
│   │   │ +-rw-r--r-- root/root   211 2015-11-07 03:24:43 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/installation_config.py
│   │   │  -rw-r--r-- root/root 10229 2015-05-21 02:46:25 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/PositionEntry.py
│   │   │  -rw-r--r-- root/root  5796 2015-05-21 02:46:25 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/IconEntry.py
│   │   │  -rw-r--r-- root/root  2817 2015-05-21 02:46:25 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/__init__.py
│   │   │  -rw-r--r-- root/root 13631 2015-05-21 02:46:25 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/IconChooserDialog.py
│   │   │  -rw-r--r-- root/root  7520 2015-05-21 02:46:25 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/OptionGroup.py
│   │   │  -rw-r--r-- root/root  4927 2015-05-21 02:46:25 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/MonitorsGroup.py
│   │   │  -rw-r--r-- root/root 22874 2015-05-21 02:46:25 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/GtkGreeterSettingsWindow.py
│   │   │  -rw-r--r-- root/root 12548 2015-05-21 02:46:25 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/IndicatorPropertiesDialog.py
│   │   │  -rw-r--r-- root/root 12726 2015-05-21 02:46:25 
./usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/OptionEntry.py
│   │   │  -rw-r--r-- root/root 29779 2015-05-21 02:46:25 

Bug#804300: mirror submission for debian-mirror.sakura.ne.jp

[Hideki Yamane]

Package: mirrors
Severity: wishlist

Submission-Type: new
Site: debian-mirror.sakura.ne.jp
Aliases: ftp.jp.debian.org
Type: leaf
Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc s390x sparc 
Archive-ftp: /debian/
Archive-http: /debian/
Archive-rsync: debian/
Backports-ftp: /debian-backports/
Backports-http: /debian-backports/
Backports-rsync: debian-backports/
IPv6: yes
Archive-upstream: hanzubon.jp
Backports-upstream: hanzubon.jp
Updates: push
Maintainer: Hideki Yamane 
Country: JP Japan
Location: Ishikari, Hokkaido
Sponsor: Sakura Internet, Inc. http://www.sakura.ad.jp

Bug#698980: Packaging work on ‘inform’ for Debian

[Ben Finney]

Howdy Jan,

Than you for working on the ‘inform’ package for Debian
.

I am interested in helping or continuing with this work. Do you still
have the VCS repository used for this packaging work? Where can I
clone or fork it from?

The license grant for both the compiler and standard library have
recently changed; the recipient can now choose the terms of the
Artistic License 2.0. This makes recent upstream versions of the work
free software, I think.

Are you interested in assisting me in some way to get recent versions
of Inform packaged for Debian?

Hoping you are well, and looking forward to your response.

-- 
 \   “The most common of all follies is to believe passionately in |
  `\the palpably not true. It is the chief occupation of mankind.” |
_o__)—Henry L. Mencken |
Ben Finney 


signature.asc
Description: PGP signature

Bug#740611: A revised description

[Benda Xu]

Hi Justin,

Thank you for your input.

I suggest update the description as

 OpenRC is a dependency based init system. It provides support for System V
 init, for booting, changing runlevels, starting and stopping services, and
 shutting down.

 Originally written as a Gentoo project, OpenRC aims at being
 platform-agnostic.  It works equally well on Linux, BSD and Hurd.  It
 supports the traditional init system in Debian in addition to many
 alternatives.  OpenRC is implemented in C in a small, simple and
 efficient way, making it easy to understand, extend and reuse.

@Thomas, @Roger: Comments?

Benda

Bug#802917: do not migrate denyhosts to testing: who will do security support?

[Salvatore Bonaccorso]

Hi Jan-Pascal and Helmut,

On Mon, Oct 26, 2015 at 09:23:19PM +0100, Jan-Pascal van Best wrote:
> Hi Helmut,
> 
> Thanks for showing some care for this package. The main reason for me to
> want to support denyhosts was the possibility of the synchronisation
> server. I have since written a (AGPL licensed) replacement for the
> original, closed source, server, starting from Anne Bezemer's suggestion
> in Debian bug#622697.
> 
> I may consider offering to do the security support for denyhosts for at
> least the stretch support period, but I'm not sure what that would mean
> exactly. Is the main work in following CNEs for the package and fixing
> them for Debian (and preferably upstream as well)?
> 
> Another possibility might be to work with fail2ban upstream to also
> support my, or another, synchronisation server, but I'm not sure if they
> would be willing to accept patches to that effect.
> 
> >  * Your upload reintroduces security bug #692229.
> You're right. I checked whether all Debian patches had been implemented
> upstream, must have missed this one.
> 
> >  * Due to the removal of denyhosts from Debian, the following bugs were
> >closed by the ftp masters:
> >
> >#395565 #436417 #497485 #514024 #529089 #546772 #597956 #567209 #611756
> >#622697 #643031 #720130 #729322 #731963
> >
> >Please evaluate which of them need to be reopened or failing that
> >reopen all of them.
> Of course, I was planning to do that.

From security team point of view: If all the previously open security
bugs get's fixed, and both maintainer (hey! ;-)) and upstream remain
active and on track when issues appear I guess we will be fine to have
as well denyhosts in stretch.

OTOH, there is fail2ban which is actively developped as well, and so I
guess much widely used, so it would be possibly better to concentrate
the work effort on fail2ban. Helmut is right here, that it's hard to
get all the bits right already, so if we can avoid in the end having
to maintain both denyhosts and fail2ban that might be preferable.

have you spoken/contacted fail2ban upstream to bring your ideas about
the synchronisation server?

Please only close this bug in case we would be sure that denyhosts
should go in stretch and all the items raised by Helmut are addressed.

Regards,
Salvatore


signature.asc
Description: PGP signature

Bug#804303: pyflakes: please provide pyflakes3 binary packages

[Alexandre Detiste]

Package: pyflakes
Version: 1.0.0-2
Severity: normal

Hi,

Dear maintainer,

Please provide a pyflakes3 binary package with

/usr/share/doc/pyflakes3/changelog.Debian.gz
/usr/share/doc/pyflakes3/copyright
/usr/share/doc/pyflakes3/changelog.gz
/usr/share/man/man1/pyflakes3.1.gz
/usr/bin/pyflakes3

The 'pyflakes' binary package would depends on this new package,
to ensure that current users of /usr/bin/pyflakes3
that does Depends on 'pyflakes' doesn't immediatly FTFBS.

Projects that needs /usr/bin/pyflakes3 could then adjust their
depedencies & be build without pulling in Python2.

Alexandre Detiste



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

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

Versions of packages pyflakes depends on:
ii  python-pyflakes   1.0.0-2
ii  python3-pyflakes  1.0.0-2
pn  python3:any   
pn  python:any

pyflakes recommends no packages.

pyflakes suggests no packages.

-- no debconf information

Bug#804283: RFS: igb/5.3.3.2-1 [ITP] -- out of tree Intel Gigabit Ethernet driver.

[Vincent Bernat]

 ❦  7 novembre 2015 09:23 +0800, Paul Wise  :

>> The package is needed because the in-tree driver doesn't have
>> advanced features such as interrupt throttle, multiqueue or Large
>> Receive Offload.
>
> Has Intel sent these features for inclusion in Linux mainline?

Intel also maintains the drivers for their wired cards in
mainline. However, for some reason (unknown for me), they have always
restricted the features of those drivers.
-- 
Debian package sponsoring guidelines:
 http://vincent.bernat.im/en/debian-package-sponsoring.html


signature.asc
Description: PGP signature

Bug#804305: Difficulties moving a domain elsewhere

[martin f krafft]

Package: vmm
Version: 0.6.0-1
Severity: minor

example.org and example.com are hosted locally and managed by vmm.

f...@example.org is an alias to f...@example.com, a user account.

I now want to move example.com to another server. However, I cannot
remove the domain because f...@example.com still exists. And I cannot
remove the user because an alias still points to it. So now I have
to remove the alias, remove user, remove domain and then recreate
the alias, which is a bit painful.

Wouldn't a warning do instead?

Thanks for your consideration,

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

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


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#804009: [Pkg-libvirt-maintainers] Bug#804009: libvirt-bin: exception when deleting a vm

[Guido Günther]

Hi,
On Wed, Nov 04, 2015 at 01:43:44PM +0530, Ritesh Raj Sarraf wrote:
> Package: libvirt-bin
> Version: 1.2.20-1
> Severity: normal
> 
> When deleting the VM, along with its file image, I am shown the
> following error message in a pop-up.
> 
> 
> `
> Errors encountered while removing certain storage devices.
> 
> cannot unlink file '/var/lib/libvirt/images/debian8.qcow2': Success
> Traceback (most recent call last):
>   File "/usr/share/virt-manager/virtManager/delete.py", line 182, in 
> _async_delete
> self._async_delete_path(conn, path, meter)
>   File "/usr/share/virt-manager/virtManager/delete.py", line 228, in 
> _async_delete_path
> vol.delete(0)
>   File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3361, in delete
> if ret == -1: raise libvirtError ('virStorageVolDelete() failed', 
> vol=self)
> libvirtError: cannot unlink file '/var/lib/libvirt/images/debian8.qcow2': 
> Success

The "Success" means that virFileRemove failed to set a proper errno.

> At one end, it says "Success" but also reports error.
> Lookng at the datastore, the VM file is not deleted.
> 
> 
> 
> rrs@learner:~$ sudo ls /var/lib/libvirt/images/ -l
> [sudo] password for rrs: 
> total 3768528
> -rw--- 1 root root 8591507456 Nov  4 13:32 debian8.qcow2
> 2015-11-04 / 13:43:10 ♒♒♒  ☺


Assuming your're using qemu:///system

Can you provide a bit of config information:

  virsh pool-dumpxml default
  virsh vol-dumpxml --pool  default debian8.qcow2

Can you also try to delete via vol-delete:

  virsh vol-delete --pool  default debian8.qcow2

That should fail as well. If it does please do a:

  grep libvirtd /var/log/syslog
  journalctl -u libvirtd.service

Cheers,
 -- Guido

Bug#749647: Ping

[Marco d'Itri]

On Nov 06, Dima Kogan  wrote:

> Hi. Can we talk about this again? Should I Cc -devel, or is the
I hope not.

> reassignment to 'general' enough?
It would be totally wrong.

> The argument for guile in default 'make' is as before. And also the
So I suppose that the arguments for not doing this are still valid as 
well.

> current situation is misleading to users. The main feature of make 4.0
> is guile support. A user who wants this goes to 'apt-get install make',
> sees 4.x being installed, and happily attempts to use this shiny new
> guile support, only to discover that their Makefiles do not work as
> expected.
How many packages in Debian actually use guile makefiles?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#803115: flash-kernel: please provide an option to disable creation of backup files

[Ian Campbell]

On Mon, 2015-10-26 at 21:37 -0400, Eric Cooper wrote:
> I'd like an option (configurable in /etc/default/flash-kernel ideally)
> to prevent flash-kernel from creating .bak files for uImage, uInitrd,
> and dtb, in order to same space on my system.  I'm willing to live
> dangerously and keep a serial and JTAG cable handy :-)

This looks like it should be a reasonably simple change to
backup_and_install() (and README and the template /e/d/f-k file).
Patches would be welcomed.
Thanks,
Ian.

Bug#804163: etckeeper should use locale independent character classes in regular expressions

[Kristjan Räts]

Antoine Beaupré wrote:
> 
> Do you think you could provide a patch that would fix this for you or a
> way to reproduce the issue?
> 

Works-for-me quality patch is below.

To reproduce:
* Generate locale data for et_EE.UTF-8 (needed only once).
* Set the environment variable LC_COLLATE to et_EE.UTF-8 (ISO encodings like
  ISO-8895-15, ISO-8895-4 or something similar will give same error).
* Execute any etckeeper command (I suggest 'etckeeper unclean' as it should
  perform only reads) and observe the bug.


Best regards,

Kristjan


--- /usr/bin/etckeeper.orig  2015-11-05 14:03:15.642317316 +0200
+++ /usr/bin/etckeeper2015-11-05 14:04:14.630314191 +0200
@@ -75,7 +75,7 @@
command=pre-install
 fi

-if echo "$command" | egrep -q '[^-a-z_]'; then
+if echo "$command" | egrep -q '[^-[:lower:]_]'; then
echo "etckeeper: invalid command $command" >&2
exit 1
 fi
@@ -120,7 +120,7 @@
perl -e '
$dir=shift;
print join "\n", grep { ! -d $_ && -x $_ }
-   grep /^\Q$dir\/\E[-a-zA-Z0-9]+$/,
+   grep /^\Q$dir\/\E[-[:alnum:]]+$/,
glob "$dir/*";
' "$1"
 }

Bug#804209: wheezy-pu: package fuse-exfat/0.9.7-2+deb7u1

[Sven Hoexter]

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

Hi,
since exfat-utils and fuse-exfat share the same code base, but are released
as seperate source packages, I've now prepared updates for fuse-exfat as well
to fix the issues found by The Fuzzing Project.

Changes: 
 fuse-exfat (0.9.7-2+deb7u1) wheezy; urgency=medium
 .
   * Add d/patches/check-sector-and-cluster-size. Fix for
 https://github.com/relan/exfat/issues/5 found and reported by
 The Fuzzing Project.
   * Add d/patches/detect-infinite-loop. Fix for
 https://github.com/relan/exfat/issues/6 found and reported by
 The Fuzzing Project.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=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)
diff -u fuse-exfat-0.9.7/debian/gbp.conf fuse-exfat-0.9.7/debian/gbp.conf
--- fuse-exfat-0.9.7/debian/gbp.conf
+++ fuse-exfat-0.9.7/debian/gbp.conf
@@ -2,0 +3 @@
+debian-branch = wheezy-updates
diff -u fuse-exfat-0.9.7/debian/changelog fuse-exfat-0.9.7/debian/changelog
--- fuse-exfat-0.9.7/debian/changelog
+++ fuse-exfat-0.9.7/debian/changelog
@@ -1,3 +1,14 @@
+fuse-exfat (0.9.7-2+deb7u1) wheezy; urgency=medium
+
+  * Add d/patches/check-sector-and-cluster-size. Fix for
+https://github.com/relan/exfat/issues/5 found and reported by
+The Fuzzing Project.
+  * Add d/patches/detect-infinite-loop. Fix for
+https://github.com/relan/exfat/issues/6 found and reported by
+The Fuzzing Project.
+
+ -- Sven Hoexter   Fri, 06 Nov 2015 08:20:29 +0100
+
 fuse-exfat (0.9.7-2) unstable; urgency=low
 
   * Switch from dh compat level 8 to 9.
diff -u fuse-exfat-0.9.7/debian/patches/series fuse-exfat-0.9.7/debian/patches/series
--- fuse-exfat-0.9.7/debian/patches/series
+++ fuse-exfat-0.9.7/debian/patches/series
@@ -2,0 +3,2 @@
+check-sector-and-cluster-size
+detect-infinite-loop
only in patch2:
unchanged:
--- fuse-exfat-0.9.7.orig/debian/patches/check-sector-and-cluster-size
+++ fuse-exfat-0.9.7/debian/patches/check-sector-and-cluster-size
@@ -0,0 +1,49 @@
+Patch for https://github.com/relan/exfat/issues/5
+See also:
+https://blog.fuzzing-project.org/25-Heap-overflow-and-endless-loop-in-exfatfsck-exfat-utils.html
+Index: exfat-utils/libexfat/mount.c
+===
+--- exfat-utils.orig/libexfat/mount.c
 exfat-utils/libexfat/mount.c
+@@ -172,6 +172,24 @@ int exfat_mount(struct exfat* ef, const
+ 		exfat_error("exFAT file system is not found");
+ 		return -EIO;
+ 	}
++	/* sector cannot be smaller than 512 bytes */
++if (ef->sb->sector_bits < 9)
++{
++exfat_close(ef->dev);
++exfat_error("too small sector size: 2^%hhd", ef->sb->sector_bits);
++free(ef->sb);
++return -EIO;
++}
++/* officially exFAT supports cluster size up to 32 MB */
++if ((int) ef->sb->sector_bits + (int) ef->sb->spc_bits > 25)
++{
++exfat_close(ef->dev);
++exfat_error("too big cluster size: 2^(%hhd+%hhd)",
++ef->sb->sector_bits, ef->sb->spc_bits);
++free(ef->sb);
++return -EIO;
++}
++
+ 	if (ef->sb->version.major != 1 || ef->sb->version.minor != 0)
+ 	{
+ 		exfat_close(ef->dev);
+@@ -187,16 +205,6 @@ int exfat_mount(struct exfat* ef, const
+ 		exfat_error("unsupported FAT count: %hhu", ef->sb->fat_count);
+ 		return -EIO;
+ 	}
+-	/* officially exFAT supports cluster size up to 32 MB */
+-	if ((int) ef->sb->sector_bits + (int) ef->sb->spc_bits > 25)
+-	{
+-		exfat_close(ef->dev);
+-		free(ef->sb);
+-		exfat_error("too big cluster size: 2^%d",
+-(int) ef->sb->sector_bits + (int) ef->sb->spc_bits);
+-		return -EIO;
+-	}
+-
+ 	ef->zero_cluster = malloc(CLUSTER_SIZE(*ef->sb));
+ 	if (ef->zero_cluster == NULL)
+ 	{
only in patch2:
unchanged:
--- fuse-exfat-0.9.7.orig/debian/patches/detect-infinite-loop
+++ fuse-exfat-0.9.7/debian/patches/detect-infinite-loop
@@ -0,0 +1,48 @@
+Patch for https://github.com/relan/exfat/issues/6
+See also:
+https://blog.fuzzing-project.org/25-Heap-overflow-and-endless-loop-in-exfatfsck-exfat-utils.html
+Index: exfat-utils/libexfat/mount.c
+===
+--- exfat-utils.orig/libexfat/mount.c
 exfat-utils/libexfat/mount.c
+@@ -27,17 +27,32 @@
+ 
+ static uint64_t rootdir_size(const struct exfat* ef)
+ {
+-	uint64_t clusters = 0;
++uint32_t clusters = 0;
++uint32_t clusters_max = le32_to_cpu(ef->sb->cluster_count);
+ 	cluster_t rootdir_cluster = le32_to_cpu(ef->sb->rootdir_cluster);
+ 
+-	while 

Bug#801110: cvs-fast-export: Segfaults with rcs file found in glide repo

[Anthony Fok]

tags 801110 + confirmed
forwarded 801110 https://gitlab.com/esr/cvs-fast-export/issues/2
thanks

Hello Guillem,

On Tue, Oct 6, 2015 at 5:42 AM, Guillem Jover  wrote:
> Package: cvs-fast-export
> Version: 1.34-1
> Severity: important
>
> Hi!
>
> I was playing with this package to see if it could generate a better
> conversion than git-cvsimport or cvs2git, and found that it segfaults
> or SIGILLs (depending on the optimization level) with the attached file
> which is present in the glide CVS repository.
>
> cvs seems to cope fine with it being there, and none of the other
> converters have an issue either. In addition IMO an application should
> never segfault (or SIGILL) when confronted with apparently bogus data. :)
>
> Thanks,
> Guillem

Thank you very much for your bug report.  With your description,
I was able to reproduce the segfault with these commands:

  $ cvssync anonym...@glide.cvs.sourceforge.net:/cvsroot/glide glide3x
  $ find glide3x | cvs-fast-export >glide3x.fi
  cvs-fast-export: warning - no master branch generated
  Segmentation fault
  $

And I have forwarded your report upstream.  Hope Eric will have time
to look at it in the near future.  :-)

Cheers,
Anthony

Bug#784070: mdadm: diff for NMU version 3.3.2-5.1

[Yann Soubeyrand]

On Thu, 5 Nov 2015 14:17:11 -0600 Bryan Christ  wrote:
> I'll be glad to test this if someone will provide me instructions on how to
> apply the fixes.  I've downloaded all the files from here:
> 
> http://mentors.debian.net/debian/pool/main/m/mdadm/
> 
> I have also extracted mdadm_3.3.2-5.1.dsc with this:
> 
> dpkg-source -x mdadm_3.3.2-5.1.dsc
> 
> It's pretty unclear what to do next.  A few steps of instructions would be
> helpful.

Make sure to install the build-essential package plus all the build
dependencies listed in the .dsc file (Build-Depends: debhelper (>=
6.0.7~), po-debconf, groff-base), then execute the command
dpkg-buildpackage -us -uc inside the source tree you extracted earlier
using dpkg-source -x.

If you want to learn more about package building you can refer to
https://www.debian.org/doc/manuals/maint-guide/build.en.html.

Cheers

Yann

Bug#691412: patch for the ntpd bug 2174

[Robie Basak]

On Mon, Feb 23, 2015 at 05:03:16PM +0100, Roland Lammel wrote:
> This patch is already included upstream in 4.2.8p1 (actually 4.2.7).

stretch is on 1:4.2.8p4+dfsg-3 now so does that mean this is fixed?


signature.asc
Description: Digital signature

Bug#411914: rubber: cannot compile latex files that were compiled successully with version in sarge.

[Hilmar Preusse]

On 21.02.07 Faheem Mitha (fah...@email.unc.edu) wrote:

Hi,

https://bugs.debian.org/411914

> When trying to compile a file (mg.tex), I get the following traceback.
> This worked fine with the version in sarge (0.99.8-1).
> 
> mono.tex is a file included in mg.tex (\include{mono}).
> 
> I can give further information if necessary.
> 
Looks like a duplicate of #402150. Is it meanwhile solved?

If not: would be nice if you could provide some source code for
problem reproduction.

Hilmar
-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#709438: BUG #709438 - krusader: incorrect resize of queue manager window

[Nikola]

Hi Max,
I will spare some time next week to check it out.

Tell me something , if I install debian stable and change repos to
experinmental ,then i only need to install krusader and verify the issue is
fixed ?

BR,
Nikola


On Thu, Nov 5, 2015 at 11:35 AM, Maximiliano Curia  wrote:

> Hi,
>
> On 19/08/15 22:48, Nikola wrote:
> > Patch that fix this behaviour
> I've uploaded a new version of krusader to experimental, (a preview of the
> kf5 version), there have been some upstream changes in the queue manager
> window, but I'm not completly sure if the changes cover the same ones
> covered in this patch. If possible, could you test the newer version's
> queue manager window?
>
> Happy hacking,
>

Bug#766806: Now fixed upstream, patches attached

[Nutchanon Wetchasit]

Control: tags -1 + fixed-upstream

Hello everyone,

Both bugs I mentioned earlier are now fixed upstream.

Attached files are the accepted patches (with DEP-3 header), they all were
originally tested on mate-power-manager 1.8.0+dfsg1-2~bpo70+1
(Debian/wheezy-backports):

* 1005_make-idle-handler-always-use-configured-brightness.patch
  This fixes the symptom that AC backlight level was mistakenly applied when
  booted using DC power.

  Patch URL: 
  Upstream commit URL:


* 1006_acknowledge-ac-brightness-gsettings-event-on-dc-power.patch
  This fixes the symptom that backlight level while on DC power doesn't
  follow the change of brightness slider in `mate-power-preferences`.

  Patch URL: 
  Upstream commit URL:


Hope these solve all of the reported issues.

Regards,
Nutchanon

P.S. If one want to set the backlight level with no regard of power mode,
unchecking "Reduce backlight brightness" under Battery Power tab
of Power Management Preferences should now do the trick (with the patches
applied, backlight level would follow the brightness slider under
AC Power tab exactly).


1005_make-idle-handler-always-use-configured-brightness.patch
Description: Binary data


1006_acknowledge-ac-brightness-gsettings-event-on-dc-power.patch
Description: Binary data

Bug#804091: Artemis - Java 8 support

[Andrew Page]

Hi Afif,
For the past year or so we have had no dedicated software developer for 
Artemis. We hope to fill this position in the new year however there is a very 
long backlog of feature requests and bugs to get through.
We would welcome any pull requests on GitHub which allow for Java 8 support.
Regards,
Andrew Page



On 6 Nov 2015, at 06:04, Afif Elghraoui  wrote:

> Hello, Artemis developers,
> I'm contacting you on behalf of the Debian Med team. We have recently
> packaged Artemis for Debian, but our Java group is conducting a
> transition to Java 8 for Debian's next release and has reported that
> Artemis fails to build from source with it. The report is quoted  at the
> end of this message and is also viewable online at
> .
> 
> I understand from your commit log that you do not  support Java 8 [1]. I
> was wondering how your plans are for the future. Perhaps the information
> below may be helpful to you.
> 
> 
> Many thanks and regards
> Afif
> 
> 
> 1.
> https://github.com/sanger-pathogens/Artemis/commit/9bc9e3bdcebef3e2267e9ff8e4dbfdecf87596c6
> 
> -- 
> Afif Elghraoui | عفيف الغراوي
> http://afif.ghraoui.name
> 
> On الأربعاء  4 تشرين الثاني 2015 13:35, Emmanuel Bourg wrote:
>> Package: artemis
>> Version: 16.0.0+dfsg-1
>> Severity: important
>> User: debian-j...@lists.debian.org
>> Usertags: openjdk-8-transition
>> 
>> Dear Maintainer,
>> 
>> artemis fails to build with OpenJDK 8, there is a conflict with the sort()
>> method in FastVector and the newly added sort() method in the java.util.List
>> interface in Java 8 (the return type isn't the same):
>> 
>>
>> /home/ebourg/packaging/artemis/uk/ac/sanger/artemis/util/FastVector.java:94: 
>> error: sort(Comparator) in FastVector cannot implement sort(Comparator> super E>) in List
>>  public FastVector sort(final Comparator cmp)
>>^
>>  return type FastVector is not compatible with void
>>  where E is a type-variable:
>>E extends Object declared in interface List
>>/home/ebourg/packaging/artemis/uk/ac/sanger/artemis/io/KeyVector.java:37: 
>> error: sort(Comparator) in FastVector cannot implement sort(Comparator> super E>) in List
>>public class KeyVector extends FastVector
>>   ^
>>  return type FastVector is not compatible with void
>>  where E is a type-variable:
>>E extends Object declared in interface List
>> 
>> 
>> You can test the build with OpenJDK 8 by installing default-jdk/0.53 from 
>> experimental.
>> 
>> Emmanuel Bourg
>> 
>> ___
>> Debian-med-packaging mailing list
>> debian-med-packag...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>> 
> 

-
Dr Andrew Page
Principal Computer Programmer,
Pathogen Informatics, Wellcome Trust Sanger Institute
Email: a...@sanger.ac.uk
Phone: +44 (0)1223 834244 Ext: 7554











--
 The Wellcome Trust Sanger Institute is operated by Genome Research
 Limited, a charity registered in England with number 1021457 and a
 company registered in England with number 2742969, whose registered
 office is 215 Euston Road, London, NW1 2BE.

Bug#801193: linux: No drm_driver.set_busid() implementation provided by nv_drm_driver [nvidia]

[Arturo Borrero Gonzalez]

On 5 November 2015 at 17:13, Andreas Beckmann  wrote:
> Version: 304.128-1
>
> On 2015-10-16 12:09, Andreas Beckmann wrote:
>> On 2015-10-16 10:55, Arturo Borrero Gonzalez wrote:
>>> Package nvidia-legacy-304xx-kernel-dkms Version: 304.125-2
>>
>> You'll probably need 304.128 (currently being prepared).
>
> I assume this is fixed in the new version.
>

yeah thanks.

-- 
Arturo Borrero González

Bug#804150: gnome-flashback: windows move very slowly

[Dmitry Shachnev]

Hi Joachim,

On Fri, Nov 06, 2015 at 08:30:12AM +0100, Joachim Schmidt wrote:
> I do not have to switch to an other window manager, it's enough to switch to
> "classic" or "normal" gnome mode. This problem only occur in "flashback"
> mode.
> 
> window moves very slowly means: it can not follow my mouse moves

You filed this bug against gnome-flashback package. It is a helper application
for the Flashback session, and it has nothing to do with windows moving.

It may be an issue with Metacity (the default WM used in GNOME Flashback), but
I wanted you to test a different WM to check if the issue is specific to
Metacity. Mutter uses a similar codebase to is a good choice to test with.

--
Dmitry Shachnev

Bug#803779: Same behavior

[Floris]

I can confirm this bug.

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

Floris

Bug#804184:

[intrigeri]

Jason Hernandez wrote (06 Nov 2015 04:32:48 GMT) :
> Hello -It looks like the name of the binaries has changed as a result of 
> including all supported languages in the same 
> build.https://blog.torproject.org/blog/tor-browser-55a4-hardened-released
> torbrowser-launcher tries to download this URL (on a machine with en_US 
> default).https://dist.torproject.org/torbrowser/5.5a4-hardened/tor-browser-linux64-5.5a4-hardened_en-US.tar.xz

Yes, this will become a problem once 5.5 is stable, but in the meantime:

> It looks like it should 
> download 
> https://dist.torproject.org/torbrowser/5.5a4-hardened/tor-browser-linux64-5.5a4-hardened_ALL.tar.xz
>  
> instead

No, it should download 5.0.4.

Cheers,
-- 
intrigeri

Bug#763774: Annual ping for Gianfranco Costamagna

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On Fri, 6 Nov 2015 08:03:43 -0200 Eriberto Mota 
wrote:
> Closing this bug.
> 
> Gianfranco Costamagna is a DD since 2015-08-01.


true story, I even changed my GPG key in the meanwhile :)

thanks for closing this one!

cheers,

G.

> 
> Thanks,
> 
> Eriberto
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWPHz4AAoJEPNPCXROn13ZIB8P/i9aBuLSZ6B/oe7n4Ww09c+V
unfwWqYvHdf89QjsVSf+X/hWiE9aRzE/w6jhaoQkkB6Nc5eA+6ahmiuLzc0bOiKI
AQzpQP6qfS7MIKYk32b5uXBtdgpg5E+PGIzSXTTFQbkQ4EvOHAl0/qshu7yWCCGF
3Y9QfvI9l060d84K7XNvoHqTF1CUvmP3a/wGrmehhBqHOKFGacYcDJloxTrECxf+
3jU8q6JoI99mupKTNbh1akyIveVNTJfyqbxArXBPn1B+6jkvjs5WmefrEiLtRqM6
U/7Uih+3wG9x7zYN5hptYY3CSZ3jMtSaTRd2o5GXajoxLdiRXoYPCqmKmhf/eugl
MM0eEswOoUEIzWszwEukFnadCfkytL1L0xQcWvRg7O0HontiWW12yHxwYnQT8L5z
3cmJe42stkOUifJWVtMgI2eZeBQzO8Ngkw8NcE/oO/Tfd8aff3lU8ORlRV34z8vp
uMyATc0qymgar9CjFbCez0m3McUVJKKzDPDaEppTqQrPA5mgAUPthNuMBKaLi9F/
qdEUmtxjnkJSl9wrgHViPiqJ1GFpTYkRqit27p9W9AYj/zPgzOW6aS76+kHT70fz
NUZAtqarav+qV8LUhaTMrlQg/5uTPLnsopg+XqjoCZFUBumjbXb/Q7K31zM4APLk
Q8fCA2FMdiRtDWIhc1cU
=KfeD
-END PGP SIGNATURE-

Bug#804215: Program received signal SIGSEGV, Segmentation fault.

[Mathieu Malaterre]

Package: gimagereader
Version: 3.1.2-1
Severity: important

I cannot open a JPEG file using gimagereader, it segfault.

Steps:

$ gdb gimagereader-gtk
GNU gdb (Debian 7.10-1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gimagereader-gtk...(no debugging symbols found)...done.
(gdb) r 20151106_074002.jpg
Starting program: /usr/bin/gimagereader-gtk 20151106_074002.jpg
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

** (gimagereader-gtk:15617): WARNING **: Couldn't register with
accessibility bus: Did not receive a reply. Possible causes include:
the remote application did not send a reply, the message bus security
policy blocked the reply, the reply timeout expired, or the network
connection was broken.
[New Thread 0x7fffe491e700 (LWP 15622)]
[New Thread 0x7fffe411d700 (LWP 15623)]
[New Thread 0x7fffe35aa700 (LWP 15625)]
[New Thread 0x7fffe2da9700 (LWP 15626)]
[New Thread 0x7fffe1cb0700 (LWP 15627)]
Error opening data file /usr/share/tesseract-ocr/tessdata/eng.traineddata
Please make sure the TESSDATA_PREFIX environment variable is set to
the parent directory of your "tessdata" directory.
Failed loading language 'eng'
Tesseract couldn't load any languages!
[New Thread 0x7fffd1a46700 (LWP 15628)]
[New Thread 0x7fffd1245700 (LWP 15629)]
[Thread 0x7fffd1245700 (LWP 15629) exited]

Program received signal SIGSEGV, Segmentation fault.
0x7729b961 in Gtk::Widget::get_allocation() const () from
/usr/lib/x86_64-linux-gnu/libgtkmm-3.0.so.1
(gdb) bt
#0  0x7729b961 in Gtk::Widget::get_allocation() const () from
/usr/lib/x86_64-linux-gnu/libgtkmm-3.0.so.1
#1  0x555ac12c in Displayer::setZoom(Displayer::Zoom) ()
#2  0x555ac6be in Displayer::setRotation(double) ()
#3  0x555ad431 in Displayer::renderImage() ()
#4  0x555adafa in Displayer::setSource(Source*) ()
#5  0x5557d5b4 in MainWindow::onSourceChanged(Source*) ()
#6  0x55589ea5 in SourceManager::selectionChanged() ()
#7  0x76496518 in
Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#8  0x74e57244 in ?? () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x74e71a46 in g_signal_emit_valist () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x74e7212f in g_signal_emit () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x75e38bcc in gtk_tree_selection_select_path () from
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0x75e38cb1 in gtk_tree_selection_select_iter () from
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#13 0x5558ba9c in
SourceManager::addSources(std::vector > const&) ()
#14 0x555807bd in
Application::on_open(std::vector > const&, Glib::ustring
const&) ()
#15 0x769bcabb in
Gio::Application_Class::open_callback(_GApplication*, _GFile**, int,
char const*) () from /usr/lib/x86_64-linux-gnu/libgiomm-2.4.so.1
#16 0x7fffee50afb0 in ffi_call_unix64 () from
/usr/lib/x86_64-linux-gnu/libffi.so.6
#17 0x7fffee50aa18 in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#18 0x74e57d65 in g_cclosure_marshal_generic_va () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x74e57244 in ?? () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x74e71a46 in g_signal_emit_valist () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x74e7212f in g_signal_emit () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#22 0x7556f882 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#23 0x769b9e88 in
Gio::Application::local_command_line_vfunc(char**&, int&) () from
/usr/lib/x86_64-linux-gnu/libgiomm-2.4.so.1
#24 0x769ba0dd in
Gio::Application_Class::local_command_line_vfunc_callback(_GApplication*,
char***, int*) () from /usr/lib/x86_64-linux-gnu/libgiomm-2.4.so.1
#25 0x7556fa8a in g_application_run () from
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#26 0x55579eda in main ()
(gdb)




For reference:

$ apt-cache policy gimagereader tesseract-ocr-fra
gimagereader:
  Installed: 3.1.2-1+b1
  Candidate: 3.1.2-1+b1
  Version table:
 *** 3.1.2-1+b1 0
500 

Bug#802912: nmu: openmw_0.36.1-1

[bret curtis]

On Mon, Oct 26, 2015 at 8:10 PM, Emilio Pozuelo Monfort 
wrote:

> On 26/10/15 18:30, Scott Howard wrote:
> > On Mon, Oct 26, 2015 at 5:12 AM, Emilio Pozuelo Monfort
> >  wrote:
> >> On 25/10/15 02:27, Scott Howard wrote:
> >>> Package: release.debian.org
> >>> Severity: normal
> >>> User: release.debian@packages.debian.org
> >>> Usertags: binnmu
> >>>
> >>> nmu openmw_0.36.1-1 . ANY . unstable . -m "rebuild against new
> libbullet"
> >>>
> >>> The maintainer (Bret Curtis) is busy but asked me to request this
> binNMU
> >>>
> >>> Game crashes because it was compiled against an old libbullet. More
> info:
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801914
> >>> https://forum.openmw.org/viewtopic.php?f=2=3053
> >>
> >> Sounds like you need a library transition.
> >>
> >> Emilio
> >
> > Yes, but the discussion on the libbullet transition went another way:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790988#35
>
> As you can see in that bug report, there already was a bullet transition
> for the
> GCC 5 / libstdc++6 breaks.
>
> The problem is that openmw 0.36.1-1+b2 was built against bullet
> 2.83.5+dfsg-2,
> but upgrading bullet to 2.83.6+dfsg-1 breaks openmw. That means bullet
> broke the
> ABI and needs a transition.
>
> Cheers,
> Emilio
>

As of today:
   openmw: flagged for removal in 7.6 days

is there any way to prevent it's removal and having to go through the whole
ITP again?

Is there anything being done about bullet?

Cheers,
Bret

Bug#803569: jessie-pu: package exim4/4.84-8+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2015-11-05 at 16:09 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2015-10-31 at 14:33 +0100, Andreas Metzler wrote:
> > I would like to fix 803562 in jessie. Exim's MIME checking ACL
> > (available in exim4-daemon-heavy)  was found to not correctly handle
> > some broken MIME containers. Jessie contains most of the fixes, but
> > some additional issues were found later.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#750173: libopenvg1-mesa: Crashes when playing video after upgrade from 10.1.2-1 to 10.1.4-1

[Andreas Boll]

Control: tag -1 moreinfo
Control: reassign -1 libgl1-mesa-dri 10.1.4-1
Control: retitle -1 libgl1-mesa-dri: [i965] Crashes when playing video after 
upgrade from
10.1.2-1 to 10.1.4-1

Is this still an issue with a newer graphic stack (newer mesa, kernel,
libdrm and xserver-xorg-video-intel)?

Thanks,
Andreas

On Sat, Jun 07, 2014 at 09:39:22PM +0200, Josef Kufner wrote:
> Dne 7.6.2014 13:46, Josef Kufner wrote:
> > I downgraded Linux kernel to verison 3.13 (package
> > linux-image-3.13-1-686-pae:i386 3.13.10-1) and so far everything works fine.
> 
> Update: Not so fine. Playing video on Youtube and having paused 0AD triggered 
> the bug. However it is the most stable combination I found so far.
> 
> 
> Xorg.log:
> 
> [ 51638.576] (EE) intel(0): Failed to submit batch buffer, expect rendering 
> corruption: Invalid argument.
> 
> dmesg:
> 
> Jun  7 21:29:12 rybicka kernel: [51656.712077] [ cut here 
> ]
> Jun  7 21:29:12 rybicka kernel: [51656.712123] WARNING: CPU: 1 PID: 4043 at 
> /build/linux-J9OhPJ/linux-3.13.10/drivers/gpu/drm/i915/intel_display.c:922 
> assert_pll+0x6a/0x70 [i915]()
> Jun  7 21:29:12 rybicka kernel: [51656.712125] PLL state assertion failure 
> (expected on, current off)
> Jun  7 21:29:12 rybicka kernel: [51656.712173] Modules linked in: 
> rpcsec_gss_krb5 nfsv4 dns_resolver cpufreq_userspace cpufreq_conservative 
> cpufreq_powersave bnep rfcomm autofs4 snd_hrtimer snd_seq_midi 
> snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device binfmt_misc 
> ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_DSCP ipt_REJECT xt_tcpudp 
> xt_limit nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack iptable_filter 
> iptable_mangle ip_tables x_tables nf_conntrack_ftp nf_conntrack hdaps 
> input_polldev visor usbserial cpufreq_stats nfsd auth_rpcgss oid_registry 
> nfs_acl nfs lockd sunrpc fscache aes_i586 loop fuse parport_pc ppdev lp 
> parport iTCO_wdt iTCO_vendor_support snd_hda_codec_analog joydev coretemp 
> pcmcia kvm_intel kvm evdev psmouse serio_raw pcspkr btusb bluetooth arc4 
> i2c_i801 yenta_socket pcmcia_rsrc iwl3945 pcmcia_core iwlegacy lpc_ich 
> mac80211 mfd_core cfg80211 wmi snd_hda_intel snd_hda_codec i915 thinkpad_acpi 
> snd_hwdep snd_pcm_oss snd_mixer_oss nvram battery snd_pcm snd_page_alloc 
> snd_timer rfkill drm_kms_hel
> Jun  7 21:29:12 rybicka kernel: er snd ac drm tpm_tis soundcore tpm 
> i2c_algo_bit acpi_cpufreq i2c_core video processor button ext4 crc16 mbcache 
> jbd2 sha256_generic cbc dm_crypt dm_mod sd_mod crc_t10dif sr_mod 
> crct10dif_generic cdrom crct10dif_common ata_generic ahci libahci ata_piix 
> libata scsi_mod thermal thermal_sys ehci_pci uhci_hcd ehci_hcd e1000e ptp 
> pps_core usbcore usb_common
> Jun  7 21:29:12 rybicka kernel: [51656.712207] CPU: 1 PID: 4043 Comm: Xorg 
> Not tainted 3.13-1-686-pae #1 Debian 3.13.10-1
> Jun  7 21:29:12 rybicka kernel: [51656.712207] Hardware name: LENOVO 
> 88986CG/88986CG, BIOS 7LETB0WW (2.10 ) 01/21/2008
> Jun  7 21:29:12 rybicka kernel: [51656.712212]  0009 c140bd8e f2657b90 
> c104d45e f87f7384 f2657ba8 0fcb f87f5cc0
> Jun  7 21:29:12 rybicka kernel: [51656.712215]  039a f87a56ca f87a56ca 
> 0001 0001  f6e18000 c104d4b3
> Jun  7 21:29:12 rybicka kernel: [51656.712218]  0009 f2657b90 f87f7384 
> f2657ba8 f87a56ca f87f5cc0 039a f87f7384
> Jun  7 21:29:12 rybicka kernel: [51656.712219] Call Trace:
> Jun  7 21:29:12 rybicka kernel: [51656.712225]  [] ? 
> dump_stack+0x3e/0x4e
> Jun  7 21:29:12 rybicka kernel: [51656.712228]  [] ? 
> warn_slowpath_common+0x7e/0xa0
> Jun  7 21:29:12 rybicka kernel: [51656.712245]  [] ? 
> assert_pll+0x6a/0x70 [i915]
> Jun  7 21:29:12 rybicka kernel: [51656.712259]  [] ? 
> assert_pll+0x6a/0x70 [i915]
> Jun  7 21:29:12 rybicka kernel: [51656.712261]  [] ? 
> warn_slowpath_fmt+0x33/0x40
> Jun  7 21:29:12 rybicka kernel: [51656.712277]  [] ? 
> assert_pll+0x6a/0x70 [i915]
> Jun  7 21:29:12 rybicka kernel: [51656.712295]  [] ? 
> intel_crtc_load_lut+0x19a/0x1b0 [i915]
> Jun  7 21:29:12 rybicka kernel: [51656.712301]  [] ? 
> drm_fb_helper_setcmap+0x23d/0x3b0 [drm_kms_helper]
> Jun  7 21:29:12 rybicka kernel: [51656.712312]  [] ? 
> drm_framebuffer_unreference+0x31/0x50 [drm]
> Jun  7 21:29:12 rybicka kernel: [51656.712322]  [] ? 
> drm_modeset_unlock_all+0x20/0x40 [drm]
> Jun  7 21:29:12 rybicka kernel: [51656.712325]  [] ? 
> fb_set_cmap+0x54/0x120
> Jun  7 21:29:12 rybicka kernel: [51656.712327]  [] ? 
> fb_pan_display+0xba/0x170
> Jun  7 21:29:12 rybicka kernel: [51656.712330]  [] ? 
> fbcon_set_palette+0x80/0x160
> Jun  7 21:29:12 rybicka kernel: [51656.712332]  [] ? 
> fbcon_switch+0x352/0x4e0
> Jun  7 21:29:12 rybicka kernel: [51656.712336]  [] ? 
> redraw_screen+0x13b/0x1e0
> Jun  7 21:29:12 rybicka kernel: [51656.712338]  [] ? 
> fbcon_blank+0x1db/0x280
> Jun  7 21:29:12 rybicka kernel: [51656.712341]  [] ? 
> do_unblank_screen+0x9e/0x1b0
> Jun  7 21:29:12 rybicka kernel: [51656.712344]  [] ? 
> complete_change_console+0x49/0xd0
> 

Bug#777861: gauche-c-wrapper: ftbfs with GCC-5

[Jens Thiele]

Matthias Klose  writes:

> you could use -P, or fix the parsing.

a first minimal hackish patch (not using -P)
likely this is not really good enough yet (but yes it compiles and
passes the tests)

Maybe a version using -P just using the last n lines of the cpp output
would be better?

Index: gauche-c-wrapper-0.6.1/src/c-parser.c
===
--- gauche-c-wrapper-0.6.1.orig/src/c-parser.c
+++ gauche-c-wrapper-0.6.1/src/c-parser.c
@@ -1668,6 +1668,7 @@ ScmObj Scm_ParseMacroCode(ScmObj in, Scm
 {
 static ScmObj trigger_line = SCM_FALSE;
 ScmObj line_str;
+ScmObj next_line_str; /* one line look-ahead */
 
 /* skip the first line '# 1 ""' */
 Scm_ReadLineUnsafe(SCM_PORT(in));
@@ -1682,7 +1683,20 @@ ScmObj Scm_ParseMacroCode(ScmObj in, Scm
 }
 }
 
-while (!SCM_EOFP(line_str = Scm_ReadLineUnsafe(SCM_PORT(in {
+line_str = Scm_ReadLineUnsafe(SCM_PORT(in));
+next_line_str = Scm_ReadLineUnsafe(SCM_PORT(in));
+while (!SCM_EOFP(line_str)) {
+/* skip lines starting with "# " and join with following line */
+while (!SCM_EOFP(next_line_str)
+   && (SCM_STRING_LENGTH(next_line_str)>2)
+   && (Scm_StringRef(SCM_STRING(next_line_str),0,0)==35)
+   && (Scm_StringRef(SCM_STRING(next_line_str),1,0)==32)) {
+next_line_str = Scm_ReadLineUnsafe(SCM_PORT(in));
+if (!SCM_EOFP(next_line_str)) {
+line_str = Scm_StringAppend2(SCM_STRING(line_str), 
SCM_STRING(next_line_str));
+next_line_str = Scm_ReadLineUnsafe(SCM_PORT(in));
+}
+}
 if (SCM_NULLP(macro_list)) {
 Scm_Error("[bug] lost macro body");
 } else {
@@ -1691,6 +1705,8 @@ ScmObj Scm_ParseMacroCode(ScmObj in, Scm
 Scm_FilenameSet(SCM_CAAR(pos_name_args));
 Scm_LineNumberSet(SCM_INT_VALUE(SCM_CDAR(pos_name_args)));
 parse_macro_body(SCM_CADR(pos_name_args), SCM_CDDR(pos_name_args), 
line_str);
+line_str = next_line_str;
+next_line_str = Scm_ReadLineUnsafe(SCM_PORT(in));
 }
 }
 

Bug#804217: virt-viewer: Please package version 2.0

[Johannes Ranke]

Package: virt-viewer
Version: 1.0-1
Severity: normal

Dear Maintainer,

As the changelog for version 2.0 lists some fixes for various crashes
and memory leaks

https://virt-manager.org/download/

I think the new version should be provided in Debian. Unfortunately,
this involves packaging new versions of spice-gtk and spice-protocol as
well.

Kind regards,

Johannes Ranke


-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (10, 'unstable'), (5, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 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 virt-viewer depends on:
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-18+deb8u1
ii  libcairo-gobject2   1.14.0-2.1
ii  libcairo2   1.14.0-2.1
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u3
ii  libglib2.0-02.42.1-1
ii  libgtk-3-0  3.14.5-1+deb8u1
ii  libgtk-vnc-2.0-00.5.3-1.3
ii  libgvnc-1.0-0   0.5.3-1.3
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libspice-client-glib-2.0-8  0.29-1
ii  libspice-client-gtk-3.0-4   0.29-1
ii  libvirt01.2.9-9+deb8u1
ii  libxml2 2.9.1+dfsg1-5

virt-viewer recommends no packages.

Versions of packages virt-viewer suggests:
ii  netcat-openbsd [netcat]  1.105-7
ii  netcat-traditional [netcat]  1.10-41

-- no debconf information

Bug#804216: ITP: r-cran-biasedurn -- GNU R Biased Urn model distributions

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-biasedurn
  Version : 1.06.1
  Upstream Author : Agner Fog 
* URL : http://cran.r-project.org/web/packages/BiasedUrn
* License : GPL
  Programming Lang: R
  Description : GNU R Biased Urn model distributions
 Statistical models of biased sampling in the form of univariate and
 multivariate noncentral hypergeometric distributions, including
 Wallenius' noncentral hypergeometric distribution and Fisher's
 noncentral hypergeometric distribution (also called extended
 hypergeometric distribution). See vignette("UrnTheory") for explanation
 of these distributions.


This package solves a new (Build-)Dependency of r-cran-epir and will
be maintained by the Debian Med team at
   svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-biasedurn/trunk/

Bug#804210: Invalid documentation for return value of sscanf

[Mathieu Malaterre]

Package: manpages-dev
Version: 3.74-1

Currently `man sscanf`` reads as:

[...]
RETURN VALUE
   These functions return the number of input items successfully
matched and assigned, which can be fewer than provided for, or even
zero in the event of an early matching failure.
[...]

This is incorrect in case a read failure occurs before the first
receiving argument. cppreference reads as (suggested change):

[...]
Return value

Number of receiving arguments successfully assigned, or EOF if read
failure occurs before the first receiving argument was assigned.
[...]

ref: http://en.cppreference.com/w/cpp/io/c/fscanf

example:

[...]
int i;
int n = sscanf( "ABC", "ABCD%d",  ); // n -> EOF
[...]

Bug#804211: mime-support: Please add decoding and encoding support for xz

[Nicolas Schier]

Package: mime-support
Version: 3.59
Severity: wishlist
Tags: patch


Dear Maintainers,

could you please add decoding and encoding support for xz archives?  I
attach a patch that works for me.

Kind regards,
Nicolas
diff --git a/run-mailcap b/run-mailcap
index 2c25e9a..27c9cd0 100755
--- a/run-mailcap
+++ b/run-mailcap
@@ -43,9 +43,9 @@ sub Usage {
 print STDERR "  any standard mime type designation in the form / -- if\n";
 print STDERR "  not specified, it will be determined from the filename extension\n\n";
 print STDERR "Encoding:\n";
-print STDERR "  how the file (and type) has been encoded (only \"gzip\", \"bzip\", \"bzip2\"\n";
-print STDERR "  and \"compress\" are supported) -- if not specified, it will be determined\n";
-print STDERR "  from the filename extension\n\n";
+print STDERR "  how the file (and type) has been encoded (only \"gzip\", \"bzip\", \"bzip2,\"\n";
+print STDERR "  \"xz\" and \"compress\" are supported) -- if not specified, it will be\n";
+print STDERR "   determined from the filename extension\n\n";
 
 exit ($error ? 1 : 0);
 }
@@ -59,6 +59,7 @@ sub EncodingForFile {
 if ($file =~ m/\.gz$/)  { $encoding = "gzip";   }
 if ($file =~ m/\.bz$/)  { $encoding = "bzip";   }
 if ($file =~ m/\.bz2$/) { $encoding = "bzip2";  }
+if ($file =~ m/\.xz$/)  { $encoding = "xz"; }
 if ($file =~ m/\.Z$/)   { $encoding = "compress";   }
 
 print STDERR " - file \"$file\" has encoding \"$encoding\"\n" if $debug && $encoding;
@@ -210,6 +211,12 @@ sub DecodeFile {
 } else {
 $res = system "bzip2 -dc <\Q$efile\E >\Q$tmpfile\E";
 }
+} elsif ($encoding eq "xz") {
+if ($efile eq '-') {
+$res = system "xz -d >\Q$tmpfile\E";
+} else {
+$res = system "xz -dc <\Q$efile\E >\Q$tmpfile\E";
+}
 } elsif ($encoding eq "compress") {
 if ($efile eq '-') {
 $res = system "uncompress >\Q$tmpfile\E";
@@ -246,6 +253,12 @@ sub EncodeFile {
 } else {
 $res = system "gzip -c \Q$dfile\E >\Q$efile\E";
 }
+} elsif ($encoding eq "xz") {
+if ($efile eq '-') {
+$res = system "xz < \Q$dfile\E";
+} else {
+$res = system "xz < \Q$dfile\E >\Q$efile\E";
+}
 } elsif ($encoding eq "compress") {
 if ($efile eq '-') {
 $res = system "compress <\Q$dfile\E";
diff --git a/run-mailcap.man b/run-mailcap.man
index 156ee7c..5232508 100644
--- a/run-mailcap.man
+++ b/run-mailcap.man
@@ -41,7 +41,9 @@ are
 .B bzip
 (.bz),
 .B bzip2
-(.bz2), and
+(.bz2),
+.B xz
+(.xz), and
 .B compress
 (.Z).  A filename of "-" can be used to mean "standard input", but
 then a mime-type

Bug#804212: pulseaudio: Build with soxr support

[Frederik Himpe]

Package: pulseaudio
Version: 7.0-1
Severity: wishlist

Pulseaudio 7 now supports soxr as a resampler, but Debian's pulseaudio is built
without soxr support. I discovered this problem because pulseaduio started to
crash for me when I selected a soxr resampler:

https://bugs.freedesktop.org/show_bug.cgi?id=92780



-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.11-desktop+ (SMP w/4 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 pulseaudio depends on:
ii  adduser   3.113+nmu3
ii  libasound21.0.29-1
ii  libasound2-plugins1.0.29-1
ii  libc6 2.19-22
ii  libcap2   1:2.24-12
ii  libdbus-1-3   1.10.2-1
ii  libfftw3-single3  3.3.4-2
ii  libgcc1   1:5.2.1-23
ii  libice6   2:1.0.9-1+b1
ii  libltdl7  2.4.2-1.11
ii  liborc-0.4-0  1:0.4.24-1
ii  libpulse0 7.0-1
ii  libsm62:1.2.2-1+b1
ii  libsndfile1   1.0.25-9.1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libstdc++65.2.1-23
ii  libsystemd0   227-2
ii  libtdb1   1.3.7-1
ii  libudev1  227-2
ii  libwebrtc-audio-processing-0  0.1-3
ii  libx11-6  2:1.6.3-1
ii  libx11-xcb1   2:1.6.3-1
ii  libxcb1   1.10-3+b1
ii  libxtst6  2:1.2.2-1+b1
ii  lsb-base  9.20150917
ii  pulseaudio-utils  7.0-1
ii  udev  227-2

Versions of packages pulseaudio recommends:
ii  pulseaudio-module-x11  7.0-1
ii  rtkit  0.11-4

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-3+b2
pn  pavumeter

-- Configuration Files:
/etc/pulse/daemon.conf changed [not included]

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = soxr-mq
; resample-method = trivial
; 

Bug#797694: Info received (lxc-clone fails because overlay filesystem doesn't exist)

[Étienne Bersac]

Hi,

I can mount an overlay file system on stretch with :

# ls
l  m  u  w
# mount -t overlay overlay -o lowerdir=l,upperdir=u,workdir=w m
#


However, lxc-clone fails:

# lxc-clone --snapshot --orig legacy-ci-env --new _test
lxc_container: bdev.c: overlayfs_mount: 2237 No such device - overlayfs:
error mounting /var/lib/lxc/legacy-ci-env/rootfs onto
/usr/lib/x86_64-linux-gnu/lxc/rootfs options
upperdir=/var/lib/lxc/_test/delta0,lowerdir=/var/lib/lxc/legacy-ci-env/rootfs,workdir=/var/lib/lxc/_test/olwork
clone failed
#

It looks like lxc-clone tries to use overlayfs instead of new overlay.

On Sat, Oct 17, 2015 at 2:33 AM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   bersac...@gmail.com
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Daniel Baumann 
>
> If you wish to submit further information on this problem, please
> send it to 797...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 797694: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797694
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#792204: Setting default CPU to ultrasparc for -m32 on sparc64 does not work

[John Paul Adrian Glaubitz]

Control: tags -1 patch

On 11/05/2015 11:10 PM, John Paul Adrian Glaubitz wrote:
> But, surprise, surprise, gcc-5 with bi-arch enabled works fine on
> sparc64 now. Hence, please update the patch
> debian/patches/sparc-force-cpu.diff and remove the "DISABLED" in line
> 18.

Attaching a patch for now.

Interestingly, the future symbols still seem to be missing in
lib32stdc++6 which I find rather odd.

Hmm.

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/patches/sparc-force-cpu.diff.orig	2015-11-06 10:11:52.0 +0100
+++ debian/patches/sparc-force-cpu.diff	2015-11-06 10:14:46.604668582 +0100
@@ -15,7 +15,7 @@
 +val=ultrasparc
 +			fi
 +			;;
-+		DISABLEDsparc64-*-linux*)
++		sparc64-*-linux*)
 +			if test "$option" = cpu_32; then
 +val=ultrasparc
 +			fi

Bug#792204: Setting default CPU to ultrasparc for -m32 on sparc64 does not work

[John Paul Adrian Glaubitz]

On 11/06/2015 10:21 AM, John Paul Adrian Glaubitz wrote:
> Interestingly, the future symbols still seem to be missing in
> lib32stdc++6 which I find rather odd.

Ok, back to the drawing board. Apparently sparc-force-cpu.diff doesn't
have any influence anymore. "-mcpu=ultrasparc" is never passed according
to the build logs.

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

Bug#804179: Permit building with older libtool versions to ease backports

[Michael Tokarev]

05.11.2015 22:57, Michael Tokarev wrote:
> 05.11.2015 22:13, dann frazier wrote:
>> Package: qemu
>> Version: 1:2.4+dfsg-4
>> Severity: wishlist
>> Tags: patch
>>
>> diff --git a/debian/changelog b/debian/changelog
>> index 760b87e..985bd2e 100644
>> --- a/debian/changelog
>> +++ b/debian/changelog
>> @@ -1,3 +1,10 @@
>> +qemu (1:2.4+dfsg-5) UNRELEASED; urgency=medium
>> +
>> +  * control-in: Permit building with older libtool versions to ease
>> +backporting to releases where libtool-bin wasn't yet split out.

Even with that in place, are you thinking about backorting
current qemu (in stretch) to debian release prior jessie?
Are you targetting wheezy?  Note that libtool-bin package is
in jessie already, and backporting qemu to wheezy and before
is a somewhat difficult procedure, since we'll have to backport
all the libvirt stack on the way.

> Since libcacard package has been split out of qemu,
> libtool isn't needed to build qemu anymore.  Next
> release wont build-depend on libtool.

BTW, the same tweak might be needed for libcacard now,
as it is too build-depends on libtool-bin.  But it might
be easier to disable cacard support in backport instead.

Thanks,

/mjt

Bug#804213: phpmyadmin: You must invoke apache2-maintscript-helper with an unmodified environment when sourcing it

[Igor Kowasz]

Package: phpmyadmin
Version: 4:4.5.1-2
Severity: grave
Justification: renders package unusable

There is a bug that occured today while upgrading phpmyadmin (and apache2, so I
can't really say it's not apache bug).

It is now unpossible to install nor upgrade phpmyadmin. It occured to me on
daily upgrade.

apt-get log:

dbconfig-common: flushing administrative password
You must invoke apache2-maintscript-helper with an unmodified environment when
sourcing it
dpkg: błąd przetwarzania pakietu phpmyadmin (--configure):
 podproces zainstalowany skrypt post-installation zwrócił kod błędu 1
Wystąpiły błędy podczas przetwarzania:
 javascript-common
 phpmyadmin
E: Sub-process /usr/bin/dpkg returned an error code (1)




-- 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.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages phpmyadmin depends on:
ii  dbconfig-common1.8.55
ii  debconf [debconf-2.0]  1.5.57
ii  libapache2-mod-php55.6.14+dfsg-1
ii  libjs-sphinxdoc1.3.1-7
ii  perl   5.20.2-6
ii  php-gettext1.0.11-1
ii  php-seclib 1.0.0-2
ii  php5   5.6.14+dfsg-1
ii  php5-json  1.3.7-1
ii  php5-mcrypt5.6.14+dfsg-1
ii  php5-mysql 5.6.14+dfsg-1
ii  ucf3.0030

Versions of packages phpmyadmin recommends:
ii  apache2 [httpd]  2.4.17-2+b1
ii  mysql-client 5.6.25-4
ii  mysql-client-5.6 [virtual-mysql-client]  5.6.25-4
ii  php-tcpdf6.0.093+dfsg-1
ii  php5-gd  5.6.14+dfsg-1

Versions of packages phpmyadmin suggests:
ii  firefox [www-browser]42.0~linuxmint1+betsy
ii  google-chrome-beta [www-browser] 47.0.2526.49-1
ii  links [www-browser]  2.12-1+b1
ii  mysql-server 5.6.25-4
ii  mysql-server-5.6 [virtual-mysql-server]  5.6.25-4
ii  w3m [www-browser]0.5.3-25+b1

-- debconf information:
  phpmyadmin/dbconfig-upgrade: true
  phpmyadmin/dbconfig-install: true
  phpmyadmin/internal/skip-preseed: false
  phpmyadmin/database-type: mysql
* phpmyadmin/reconfigure-webserver: apache2
  phpmyadmin/upgrade-backup: true
  phpmyadmin/mysql/method: Unix socket
  phpmyadmin/db/app-user: phpmyadmin
  phpmyadmin/db/dbname: phpmyadmin
  phpmyadmin/mysql/admin-user: root
  phpmyadmin/missing-db-package-error: abort
  phpmyadmin/install-error: retry
  phpmyadmin/setup-username: admin
  phpmyadmin/internal/reconfiguring: false
  phpmyadmin/purge: false
  phpmyadmin/remote/host:
* phpmyadmin/dbconfig-reinstall: true
  phpmyadmin/upgrade-error: abort
  phpmyadmin/remote/port:
* phpmyadmin/dbconfig-remove: true
  phpmyadmin/remove-error: retry
  phpmyadmin/remote/newhost:
  phpmyadmin/passwords-do-not-match:

Bug#804214: mysql-server-core-5.5: Mysql 5.5.46 freezes under load

[Eriksson, Ulric]

Package: mysql-server-core-5.5
Version: 5.5.44-0+deb7u1
Severity: important

Dear Maintainer,

Last week, we upgraded two of our database servers from version
5.5.44-0+deb7u1 to 5.5.46-0+deb7u1. After the upgrade, we started
experiencing unpredictable freezes, where the database became
unresponsive. In this state, it was not possible to connect to it,
list processes or even shut it down normally. The only way to get
out of this state was to kill -9 mysqld, start up again and let it
do crash recovery. This happened several times on both servers,
usually at least once per day, usually at heavy load. The longest
a server went without a crash was 40 hours.

We established a 24/7 schedule to babysit the system, so that it
was possible to detect outages early. We also worked with consultants
from Percona who suggested several options for tuning the system,
none of which were effective in preventing the freezing.

There were no performance problems before or during the outages.

Eventually we decided that a downgrade to 5.5.44 was necessary.
This was done on November 3rd and the databases have been stable
since.

Mysql configuration files:

ueriksson@gib-ca-db01:~$ more /etc/mysql/my.cnf
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[isamchk]
key_buffer_size = 16M

[mysql]
default-character-set = utf8

[mysqld]
basedir = /usr
bind-address = 0.0.0.0
character-set-server = utf8
datadir = /var/lib/mysql
default-storage-engine = INNODB
expire_logs_days = 14
innodb_file_per_table
key_buffer_size = 16M
log-error = /var/log/mysql/mysql.log
long_query_time = 1
max_allowed_packet = 16M
max_binlog_size = 100M
max_connections = 151
myisam_recover = BACKUP
table_open_cache = 4000
pid-file = /var/run/mysqld/mysqld.pid
port = 3306
query_cache_limit = 1M
#query_cache_size = 16M
skip-external-locking
slow_launch_time = 1
socket = /var/run/mysqld/mysqld.sock
#thread_cache_size = 8
thread_stack = 256K
tmpdir = /tmp
transaction-isolation = READ-COMMITTED
user = mysql
#thread_cache_size=64


new_changes

innodb_buffer_pool_instances=8
innodb_stats_on_metadata=OFF
thread_cache_size=1000
query_cache_size=0
query_cache_type=0
innodb_flush_method=O_DIRECT

[mysqld_safe]
log-error = /var/log/mysql/mysql.log
nice = 0
socket = /var/run/mysqld/mysqld.sock

[mysqldump]
max_allowed_packet = 16M
quick
quote-names


!includedir /etc/mysql/conf.d/

ueriksson@gib-ca-db01:~$ more /etc/mysql/conf.d/common.cnf
[mysqld]
bind-address = 0.0.0.0
datadir = /data/mysql
tmpdir = /data/tmp
max_connections = 2000
expire_logs_days = 14
#thread_cache_size = 64
log-bin-trust-function-creators = 1

ueriksson@gib-ca-db01:~$ more /etc/mysql/conf.d/compress.cnf
[mysqld]
innodb_file_format = Barracuda
innodb_old_blocks_time = 1000

ueriksson@gib-ca-db01:~$ more /etc/mysql/conf.d/memory.cnf
[mysqld]
# innodb tweak params
innodb_buffer_pool_size = 51G
innodb_log_file_size = 1800M
innodb_log_buffer_size = 16M

ueriksson@gib-ca-db01:~$ more /etc/mysql/conf.d/replication.cnf
[mysqld]
server-id = 11
auto-increment-increment = 1
auto-increment-offset = 1

log-slave-updates = true
log_bin = /data/log/mysql-bin.log
binlog-format = row
replicate-wild-ignore-table = mysql.%
replicate-wild-ignore-table = performance_schema.%
# Skip some errors
# 1396 = user error
# 1133 = set password error


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

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

Versions of packages mysql-server-core-5.5 depends on:
ii  libaio1 0.3.109-3
ii  libc6   2.13-38+deb7u8
ii  libgcc1 1:4.7.2-5
ii  libstdc++6  4.7.2-5
ii  libwrap07.6.q-24
ii  zlib1g  1:1.2.7.dfsg-13

mysql-server-core-5.5 recommends no packages.

mysql-server-core-5.5 suggests no packages.

-- no debconf information

Bug#804214:

[Eriksson, Ulric]

Please note that although reportbug put 5.5.44-0+deb7u1 as the
offending version, since that is what we are currently running,
it was 5.5.46-0+deb7u1 that caused the problems we experienced.

Bug#804149: CVE-2015-5602: Unauthorized privilege escalation in sudoedit

[Raphael Hertzog]

Control: forwarded -1 http://bugzilla.sudo.ws/show_bug.cgi?id=707

On Thu, 05 Nov 2015, Laurent Bigonville wrote:
> Apparently a security has been disclosed (CVE-2015-5602) allowing users
> to open files with sudoedit that is not supposed to using a symlinks,
> see: https://www.exploit-db.com/exploits/37710/
> 
> Upstream has released a new fixed version by no following the symlinks
> by default.
> 
> But according to this comment[0], this is not fixing the issue
> completely.

It's really a combination of a specific sudoers configuration
(allowing the edition via root of files possibly under the user's
control) and a lack of checks for this specific case in sudoedit.

I doubt that many systems have such a setup but sudo is not really
helping the administrator to notice their mistake. And depending
on what files the configuration allows to edit, even the patched
1.8.15 does not help...

I left a comment on the upstream ticket:
http://bugzilla.sudo.ws/show_bug.cgi?id=707

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#799122: [Pkg-xen-devel] Bug#799122: xen-hypervisor-4.4-amd64: Networking of domUs stops working after a few minutes

[Ian Campbell]

Control: reassign -1 src:linux 3.16.7-ckt11-1+deb8u5
Control: found -1 4.1.3-1~bpo8+1

On Thu, 2015-11-05 at 19:16 +0100, Arne Klein wrote:
> > > We tested the current lenny kernel linux-image-3.16.0-4-amd64 as well
> > > as the backport linux-image-4.1.0-0.bpo.1-amd64 on the dom0 as well
> > > as the domU.
> > 
> > (I suppose you meant s/lenny/jessie/ ;-)
> 
> Oops, yes :)
> 
> > These are kernel ABI versions, the package release versions are things
> > like 3.16.7-ckt17-1 or 4.2.5-1~bpo8+1, which yu can either get from
> > dpkg or from /proc/version (at the end, before the date, I think).
> > 
> > If you can let me know the versions then I can more sensibly reassign
> > this to the kernel packages. It will also give some baselines to see
> > what if any fixes we do or don't have.
> 
> Thank you. The tested versions on dom0 and domU in which the problem 
> occurs are:
> 4.1.3-1~bpo8+1
> 3.16.7-ckt11-1+deb8u5

Thanks, reassigning to src:linux and letting the BTS know about these
versions.

Did you only test the matches pairs (i.e. 4.1.3 in both dom0+domU and
likewise 3.1.6.7 in both) or did you also test old and new in some
combinations? (If not then don't worry, it's probably not relevant, but
if you already have the info we may as well add it to the mix).

> I posted the problem also to the xen-user mailing list, but did not get 
> a reply there.
> 
> And I have to update one of the observations: It seems that not all 
> domUs started after the problem occurs for the first time are broken.
> After several restarts (without any changes) one of the domUs started
> working again.

I think hadn't understood this aspect of the report, are you saying
that after one domUs networking stops (with the "Guest Rx stalled" in
dom0) that some other domUs started afterwards (but per the above not
all as you first though) do not have networking from the moment they
are started? Do those new domUs also result in the stall message in
dom0?

When this happens to one domU is also there an impact on other already
running domU's or does the secondary failure only apply to new domUs?

Ian.

Bug#803396: options for developers who don't want to use debian.org XMPP

[Rhonda D'Vine]

 Hi,

* Daniel Pocock  [2015-10-29 17:09:36 CET]:
> If a developer has their own XMPP account elsewhere or simply doesn't
> want to use it, any requests to be in their roster will simply not be
> responded to.  Should we provide an option to automatically reject
> requests sent to accounts that are not used or automatically give some
> reply scripted by the developer?

 I think a forward possibility would be useful.  The LDAP already has a
field for Jabber ID.  I guess it might make sense to forward things to
there; I'm not sure if it's possible to send stuff back somehow then
though.

 Also, if it gets implemented that stuff gets forwarded there people
should be explicitly made aware that this will happen beforehand so that
they can decide if they want to remove the entry from ldap or not.
Maybe a flag might make sense - or a new field that explicitly states
"xmpp messages forwarded to" like we have for "email forwarded to" right
now?

 Just some thoughts,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#804149: squeeze update of sudo?

[Raphael Hertzog]

Hello Bdale,

the Debian LTS team would like to fix the security issues which are
currently open in the Squeeze version of sudo:
https://security-tracker.debian.org/tracker/CVE-2015-5602

Would you like to take care of this yourself (once a proper
fix is available upstream)?

If yes, please follow the workflow we have defined here:
http://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-...@lists.debian.org
(via a debdiff, or with an URL pointing to the the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/