Bug#823517: jessie-pu: package nbd/1:3.8-4+deb8u3

[Wouter Verhelst]

Hi,

On Sun, Nov 20, 2016 at 06:00:37PM +, Jonathan Wiltshire wrote:
> Hi,
> 
> On Thu, May 05, 2016 at 04:43:46PM +0200, Wouter Verhelst wrote:
> > There is a forward-compatibility bug in nbd-client <= 3.9, in that it
> > incorrectly merges two flags fields when sending flags to the kernel.
> > The result of this bug is that all exports exported by nbd-server >= 3.9
> > and connected to by nbd-client <= 3.9 are all marked as read-only on the
> > client side.
> > 
> > I would like to update the package in Jessie to remedy the issue, so
> > that upon the release of Stretch, clients running Jessie can still talk
> > to servers running Stretch.
> 
> Is this still desired or should the bug be closed?

I thought I'd done this long ago, but a quick checks shows that I
didn't. Yes, it is still desirable. I'll work on it soon.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#845176: ITP: node-slash -- Convert Windows backslash paths to slash paths

[Eduard Bloch]

Hallo,
* Pirate Praveen [Mon, Nov 21 2016, 10:22:21AM]:
> Package: wnpp
> Severity: wishlist
> Owner: Pirate Praveen 
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: node-slash
>   Version : 1.0.0
>   Upstream Author : Sindre Sorhus 
> (http://sindresorhus.com)
> * URL : https://github.com/sindresorhus/slash
> * License : Expat
>   Programming Lang: JavaScript
>   Description : Convert Windows backslash paths to slash paths

I object to have this non-sense be packaged in Debian and ashamed that a
Debian Developer proposed it.

It's a waste of Debian resources, i.e. a huge overkill to wrap a trivial
one-liner, and even that one made wrong (check the "source", it's
considering non-ASCII paths as not worth being converted).

https://github.com/sindresorhus/slash/blob/master/index.js .

Best Regards,
Eduard.

Bug#842806: docker.io: Can't connect to the daemon

[Kurt Roeckx]

On Sun, Nov 20, 2016 at 07:10:43PM -0800, Tianon Gravi wrote:
> On 2 November 2016 at 00:25, Kurt Roeckx  wrote:
> > I'm guessing this is something systemd sets up, but that I might
> > need to manually set up if not using it?
> 
> Ah yeah, sounds like it -- did you install recommends when installing
> docker.io?  That should've pulled in the "cgroupfs-mount" package,
> which performs this function for sysvinit (but is a no-op for
> systemd).  Some folks also prefer to configure their cgroups manually
> via /etc/fstab (hence why that package is in Recommends instead of
> Depends), but I personally find that a bit too tedious; YMMV. :)

It's not installed.

> Any objections to lowering the severity of this bug?  This sounds like
> a system configuration issue, not necessarily a package-level issue,
> so the most we could do is maybe fuddle Depends or add a blurb in
> README.Debian. :(

Yes, sounds fine for me.


Kurt

Bug#845183: mono-gac: missing nunit assemblies prevent installation

[Stephen Kitt]

Package: mono-gac
Version: 4.6.1.3+dfsg-8
Severity: normal

Dear Maintainer,

This might be a variant of #671607, but just in case: upgrading mono
failed for me today with

Setting up mono-gac (4.6.1.3+dfsg-8) ...
! Assembly 
/usr/share/cli-common/policies.d/libnunit-core2.6.3-cil/policy.2.6.nunit.core.dll
 does not exist
! Assembly 
/usr/share/cli-common/policies.d/libnunit-core-interfaces2.6.3-cil/policy.2.6.nunit.core.interfaces.dll
 does not exist
! Assembly 
/usr/share/cli-common/policies.d/libnunit-framework2.6.3-cil/policy.2.6.nunit.framework.dll
 does not exist

There are no nunit files in /usr/share/cli-common/policies.d.

Installing libnunit-core2.6.3-cil and libnunit-framework2.6.3-cil
fixes the issue.

Regards,

Stephen


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

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

Versions of packages mono-gac depends on:
ii  mono-4.0-gac  4.6.1.3+dfsg-8

mono-gac recommends no packages.

mono-gac suggests no packages.

-- no debconf information

Bug#668899: calibre: "No internet connection" when network-manager installed but disabled

[bugreporter]

Package: calibre
Version: 2.60.0+dfsg-1
Followup-For: Bug #668899

I had the same issue with calibre after installing network-manager.
The main network connctions are controlled by classical network scripts, but
i wanted to have a GUI for VPN and other things.

It took me a while to realize the problem was not a missing program :-(
Removing network-manager fixed it.

The author is obviously not willing to change the way of testing the connection,
so may it be possible to check configured connections in the pre-install script?

Bug#845184: openconnect: Fails to connect to some juniper VPNs

[Tollef Fog Heen]

Package: openconnect
Version: 7.06-2+b2
Severity: important

It seems like some newer versions of Juniper VPNs require you to send a
(fixed!) Content-Length header.

http://lists.infradead.org/pipermail/openconnect-devel/2016-September/003951.html
has a patch and a little bit of background.

It would be great if this could go into stretch, let me know if you'd
like me to just NMU with this.

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

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

Versions of packages openconnect depends on:
ii  libc62.24-5
ii  libgnutls30  3.5.6-4
ii  libopenconnect5  7.06-2+b2
ii  libproxy1v5  0.4.13-1
ii  libxml2  2.9.4+dfsg1-2.1
ii  vpnc-scripts 0.1~git20150318-1

openconnect recommends no packages.

openconnect suggests no packages.

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#840416: xine fails to start due to missing libvdpau_i965.so

[Michal Hocko]

[Sorry for a late reply, I was offline...]

On Tue, Nov 08, 2016 at 11:28:49PM +0200, Adrian Bunk wrote:
> On Tue, Oct 11, 2016 at 02:19:37PM +0200, Michal Hocko wrote:
> > Package: xine-ui
> > Version: 0.99.9-1.2+b2
> > Severity: grave
> > 
> > I cannot seem to be able to start xine (standalone without any
> > particular file to open) due to:
> > Failed to open VDPAU backend libvdpau_i965.so: cannot open shared object 
> > file: No such file or directory
> > vo_vdpau: Can't create vdp device : No vdpau implementation.
> 
> The above is normal.

OK, I thought I was able to start xine without any file and select the
file just later. I might misremember that though.

> > X Error of failed request:  BadMatch (invalid parameter attributes)
> >   Major opcode of failed request:  151 (XVideo)
> >   Minor opcode of failed request:  17 ()
> >   Serial number of failed request:  2868
> >   Current serial number in output stream:  2868
> >...
> 
> What is the output of "xvinfo" (in the x11-utils package)?

X-Video Extension version 2.2
screen #0
  Adaptor #0: "GLAMOR Textured Video"
number of ports: 16
port base: 109
operations supported: PutImage 
supported visuals:
  depth 24, visualID 0x21
number of attributes: 5
  "XV_BRIGHTNESS" (range -1000 to 1000)
  client settable attribute
  client gettable attribute (current value is 0)
  "XV_CONTRAST" (range -1000 to 1000)
  client settable attribute
  client gettable attribute (current value is 0)
  "XV_SATURATION" (range -1000 to 1000)
  client settable attribute
  client gettable attribute (current value is 0)
  "XV_HUE" (range -1000 to 1000)
  client settable attribute
  client gettable attribute (current value is 0)
  "XV_COLORSPACE" (range 0 to 1)
  client settable attribute
  client gettable attribute (current value is 0)
maximum XvImage size: 8192 x 8192
Number of image formats: 2
  id: 0x32315659 (YV12)
guid: 59563132--0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
  id: 0x30323449 (I420)
guid: 49343230--0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)

> 
> Does "xine -V sdl" work?

Yes it does!

Thanks!
-- 
Michal Hocko

Bug#844579: console-setup: CyrAsia font missing Kazakh letter

[Baurzhan Muftakhidinov]

Although it seems like these letters are also referenced in
https://anonscm.debian.org/cgit/d-i/console-setup.git/tree/Fonts/fontcodesets

On Mon, Nov 21, 2016 at 10:32 AM, Baurzhan Muftakhidinov
 wrote:
> On Sun, Nov 20, 2016 at 4:14 AM, Cyril Brulebois  wrote:
>> Hi,
>>
>> Baurzhan Muftakhidinov  (2016-11-17):
>>> Package: console-setup
>>>
>>> Version: 1.153
>>>
>>> Dear maintainers,
>>>
>>> Recently I loaded CyrAsia font in console, and have noticed
>>> that it misses one Kazakh letter:
>>>
>>> Ұ U+04B0 Cyrillic Capital Letter Straight U with Stroke
>>> ұ U+04B1 Cyrillic Small Letter Straight U with Stroke
>>>
>>> I checked these codes in
>>> https://anonscm.debian.org/cgit/d-i/console-setup.git/tree/Fonts/fontsets/CyrAsia.256
>>>
>>> Could you please add these to CyrAsia font definition?
>>
>> I'm not sure what's involved to add support for those. Maybe it's
>> sufficient to add two lines with the codepoint to the file you
>> mentioned?
>>
>> Maybe you could try patching console-setup locally and reporting back
>> whether that fixed the bug?
>>
>>
>> KiBi.
>
> Hi,
>
> I have recompiled the package and extracted CyrAsia-Fixed16.psf.gz font.
> I can confirm that adding these two lines is enough for missing letter
> to appear in font.
>
> While we are at it, I wonder where these glyphs are taken from?
> Because in build log I see that № symbol is missing from the resulting font.
> In log file it says
>
> WARNING: U+2116: no glyph defined
>
> Also I see that currency symbols of some countries are added,
> so I would like to add Kazakh tenge as well, its code is
>
> ₸ - Unicode Character 'TENGE SIGN' (U+20B8)
>
> Thanks,

Bug#844936: python-keystonemiddleware FTBFS with openssl 1.1.0

[Adrian Bunk]

Control: retitle -1 python-keystonemiddleware FTBFS with openssl 1.1.0
Control: block 827061 by -1

Works for me with version 1.0.2j-1 of the openssl package,
and fails for me with version 1.1.0b-2 of the openssl package.

cu
Adrian

-- 

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

Bug#845185: init-system-helpers: deb-system-invoke starts disabled systemd service on package install/upgrade (backport request)

[Yury V. Zaytsev]

Package: init-system-helpers
Version: 1.22
Severity: important

Hi,

In short, on Jessie, when a systemd-only package is installed and/or 
upgraded, the service is started even when disabled, which is a very 
annoying and unsafe behavior; please refer to the original bug for the 
details: #768456. The bug was fixed and the fix has been out in the wild 
for quite some time, but, very unfortunately, it didn't make it into 
Jessie.


I'm filing this bug as discussed on #debian-systemd, requesting to kindly 
backport the relevant commit and push the new package to -updates:


https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=a4e43fcdabf7962d2a765b6b0e11a51734afb5f0

Many thanks!



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

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

Versions of packages init-system-helpers depends on:
ii  perl-base  5.20.2-3+deb8u6

init-system-helpers recommends no packages.

init-system-helpers suggests no packages.

-- no debconf information

--
Sincerely yours,
Yury V. Zaytsev

Bug#845161: udev: "mount: invalid option --" when busybox is not installed

[Martin Pitt]

Control: tag -1 grave

Hello,

Michael Biebl [2016-11-21  1:15 +0100]:
> Am 21.11.2016 um 00:50 schrieb Simon McVittie:
> > Because udev's initramfs hook now does "mount --move", it doesn't work with
> > klibc mount, which is used when busybox isn't installed:
> 
> 
> This was changed as a response to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844775
> 
> Luca, you wrote that initramfs-tools is now using mount from util-linux,
> but I can't find anything in the initramfs-tools changelog

Even if that gets fixed soon in initramfs-tools, we still need to
provide a working upgrade path. How about

--- a/debian/extra/initramfs-tools/scripts/init-bottom/udev
+++ b/debian/extra/initramfs-tools/scripts/init-bottom/udev
@@ -14,8 +14,9 @@ esac
 # Stop udevd, we'll miss a few events while we run init, but we catch up
 udevadm control --exit
 
-# move the /dev tmpfs to the rootfs
-mount -n --move /dev ${rootmnt}/dev
+# move the /dev tmpfs to the rootfs; fall back to klibc mount that does not
+# understand --move
+mount -n --move /dev ${rootmnt}/dev || mount -n -o move /dev ${rootmnt}/dev

As this breaks booting pretty hard, I'll raise to RC, and will upload
this today if there are no objections. (I also need to upload for
unbreaking some D-Bus activated services).

Thanks,

Martin

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


signature.asc
Description: PGP signature

Bug#844684: nmu: dolfin_2016.1.0-5

[Emilio Pozuelo Monfort]

On 18/11/16 05:01, Drew Parsons wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> dolfin doesn't seem to have gotten identified for autobuild against
> the new versions of swig and boost.  Please binNMU.
> 
> nmu dolfin_2016.1.0-5 . ANY . unstable . -m "Binary build against swig 3.0.10 
> and boost 1.62"

It is built against boost 1.62, and I don't see any swig transition. Why is a
rebuild needed for swig?

Cheers,
Emilio

Bug#751105: Re: netcat-openbsd: New upstream version available

[Guilhem Moulin]

On Fri, 11 Nov 2016 at 03:40:32 +0100, Guilhem Moulin wrote:
> On Thu, 10 Nov 2016 at 18:14:31 +0800, Aron Xu wrote:
>> On Thu, Nov 10, 2016 at 5:04 PM, Guilhem Moulin  wrote:
>>> Right.  Aron, if you need help with this package, would you be
>>> interested in co-maintenance?  The package is in collab-maint already so
>>> hopefully it won't be too much overhead to jump in.  Would be great to
>>> ship 1.159 (the netcat version found in OpenBSD 6.0) in Stretch :-)
>> 
>> More than happy to see someone to help, :-)
> 
> Sure :-)  I've imported upstream versions 1.109 to 1.130 (corresponding
> to OpenBSD 5.2 to 5.8), and rebased the Debian patches on top of each.
> Would you like me to push that directly into collab maint?  I can also
> create a new branch or push into another another remote if you prefer.

Just to be clear, I'm only waiting for an explicit go-ahead from you
before adding myself to Uploaders and pushing my changes to the remote
on collab-maint.

I'm not a DD yet (still a DM, currently applying for DD) so I'll need a
sponsor to upload the new version.  But if you don't have time with this
I'll surely find help on debian-mentors@l.d.o.

Thanks!
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#844490: [pkg-boost-devel] Bug#844495: Bug#844490: FTBFS with boost1.62

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Steve,

thanks for your answer:

Le 20/11/2016 à 05:12, Steve M. Robbins a écrit :
> On Wednesday, November 16, 2016 12:16:22 PM CST Thibaut Paumard
> wrote:
>> I've realized that, when acos() does not return, delta100 above
>> is always zero. I can simplify the case by simply doing 
>> acos(cos(alpha100))
>> 
>> in which case acos() also does not return. Does not look like a
>> memory leak after all.
>> 
>> However, doing just that in an isolated main function does not
>> exhibit the bug (I've also tried activating all the hardening
>> features)
> 
> So when you say "doing just that" in isolated main ... do you mean 
> doing acos(cos(alpha100)*cos(delta100)) or acos(cos(alpha100))?

The minimal test that I tried (and that does not demonstrate the bug)
is attached below. I was not yet able to make a small test case that
exhibits the bug. I'll have to start from the full program and un-knit i
t.

I've been able to gather more information though:

  - the initial failure occurred in a unit test where the Gyoto
library is used through an interpreted language (Yorick); now I have
been able to exhibit the bug also from the main gyoto executable by
increasing the resolution of the raytracing test and making it odd
(101 instead of 32) so that the ray-tracing at delta=0 occurs.

  - this indicates that even more architectures are affected. amd64
and i386 seem not to be. The complete list of architectures on which I
have been able to trigger the problem is: arm64 armel armhf mips64el
ppc64el s390x powerpc ppc64.

  - when failure occurs, delta seems to always be 0, but the reverse
is not true (sometimes delta is 0 ans acos() does not lock).

  - increasing the number of digits makes the bug bite earlier.

  - although I haven't read it in full yet, there is a thread on
debian-devel mentioning hardening of pthread locking in libc. Gyoto
does use pthreads (although the bug also shows up when using a single
thread). I'd like to see whether the bug is triggered this libc change
instead of the new version of boost, but I think I need to recompile
the older boost on a porterbox with the new libc to try this. It will
take some time, as my day job also needs attention.

  - rebuilding with boost1.62 on alpha also fails (which is also a
regression) with a different symptom, which may or may not be related:

/usr/bin/ld: .libs/Screen.o: dtp-relative relocation against dynamic
symbol
_ZGVZN5boost14multiprecision11default_ops15get_constant_piINS0_8backends
13cpp_dec_floatILj100EivRKT_vE6result

https://buildd.debian.org/status/fetch.php?pkg=gyoto&arch=alpha&ver=1.1.
1-3&stamp=1479433143


Test case that does not demonstrate the bug:
8<--8<8<
#include 
#include 

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

  double alpha=0.5, delta=0.;


boost::multiprecision::number
>
alpha100=alpha, delta100=delta, a;
  a=acos(cos(alpha100));

  std::cerr << a << std::endl;

  return 0;
}
8<--8<8<

Kind regards, Thibaut.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYMrgeAAoJEJOUU0jg3ChAopwQAJ+S3WPrCeDP7H+2AEOH3Veu
2KceQvYbsdOa8bextckXoZLcB0vlxNAMblk1OlbpYt2gR3PPtl7zo6yVpoXdLpAt
gXIHPA2NLGdJn+mA+4S74Jxai2I3NgE7g2/In3li5Fz5UWd4BUKkwFP6PJ98KBum
DFdst1KdLeUXTCmVI5w5AMJ9Ht+Jmo0VIqNd5b3H5oND6ublo/WlW69U3CXq/mgx
+NAzJ7QY3bWs5DmVu8IO19msCwcjzj+B8YpVUr6awuwU+ltAZOeXh/EK5vIliK/D
VYcz8YcDeWj1AAYamjq7JHE4KUk2qjv2IaETFB5gt6u56zinTxxxRjUozL2ey/tc
+zbbC0MamxoeP3ouwDmRDo7i9RFZPKsB1JOzdcIfZvczOkglQEBPwR+q6X3ooZPP
zVQVJY/RdY/2U4/QCcWB6DBPxkRu4Gx3bwY8Twaq2LqtRgMdw+NO/hFNovMkm54g
UgXA3NMHmt1IUL6AKFdeQewKunNXsgN/+v/ysxkwXvlSwmAlWxdB4+x0P1CcxzPJ
v47T/gv2lrCd0JMoMWjEG7hIhOYP9Hr6J4dFSwUmsdmhfeZAXZmbfN090dZJNvu6
3PYC/QxgNk/rgC3k2S6g3zWqz6rpWbVkONIzokL2wknWmYtaOc6FsRaGfsDu792N
ZzLWeBSV2egLCqdFnQjG
=yU0n
-END PGP SIGNATURE-

Bug#845186: systemd: does not respect ctrl-c running into timeout when starting or stopping services

[Martin Steigerwald]

Package: systemd
Version: 232-5
Severity: normal

Dear Martin, dear Michael, dear Maintainers,

as I added a removable LUKS crypto device to fstab like in

/dev/mapper/someluksdevice /mnt/somemountpoint  btrfs   
noatime,autodefrag,compress=lzo  0   0

I forgot to add "noauto".

Consequently systemd ran into a timeout of 90 seconds that was not
interruptible.

On the other hand atopacctd from experimental right now does not respond to
SIGTERM properly at the moment, again leading into a 90 seconds timeout,
that again is not interruptible with Ctrl-C.


Actual results

Pointless waiting. I know the action is not going to succeed. I know this
*better* than systemd. Frustration cause I get the impression systemd tries
to control me while I think it should be the other way around.


Expected results

When I press Ctrl-C when systemd runs into a timeout, I expect systemd
to execute my command as soon as possible. Cause actually I know better
than systemd in that cases and waiting for the completion of the timeout
is pointless.

I have some understanding that systemd may not allow Ctrl-C in all circum-
stances, since it may be possible that someone tries to hack the boot
process by just pressing Ctrl-C, but when systemd notices that it runs
into a timeout and displaying so I expect it to give an option to tell it
to stop waiting pointlessly.


I think this is an upstream issue. Feel free to forward it. I don´t feel
like arguing with systemd upstream myself given my past experiences on
systemd developer mailinglist, please respect that.

Thank you,
Martin

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3
ii  libapparmor12.10.95-6
ii  libaudit1   1:2.6.7-1
ii  libblkid1   2.29-1
ii  libc6   2.24-5
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-2
ii  libgcrypt20 1.7.3-2
ii  libgpg-error0   1.25-1
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-1
ii  libkmod223-1
ii  liblz4-10.0~r131-2
ii  liblzma55.2.2-1.2
ii  libmount1   2.29-1
ii  libpam0g1.1.8-3.3
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.6-3
ii  libsystemd0 232-5
ii  mount   2.29-1
ii  util-linux  2.29-1

Versions of packages systemd recommends:
ii  dbus1.10.12-1
ii  libpam-systemd  232-5

Versions of packages systemd suggests:
ii  policykit-10.105-17
ii  systemd-container  232-5
ii  systemd-ui 3-4

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.125
ii  udev 232-5

-- Configuration Files:
/etc/systemd/resolved.conf changed [not included]

-- no debconf information

Bug#844887: salmon: FTBFS: ld: final link failed: Nonrepresentable section on output

[Emilio Pozuelo Monfort]

On Sat, 19 Nov 2016 20:40:14 +0200 Adrian Bunk  wrote:
> Control: reassign -1 release.debian.org
> Control: severity -1 normal
> Control: retitle -1 nmu: libgff_1.0-1
> Control: affects -1 src:salmon
> Control: user release.debian@packages.debian.org
> Control: usertag -1 binnmu
> 
> On Sat, Nov 19, 2016 at 07:49:46AM +0100, Lucas Nussbaum wrote:
> >...
> > Relevant part (hopefully):
> > > /usr/bin/ld: 
> > > /usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libgff.a(GFaSeqGet.cpp.o):
> > >  relocation R_X86_64_32 against `.rodata.str1.1' can not be used when 
> > > making a shared object; recompile with -fPIC
> > > /usr/bin/ld: final link failed: Nonrepresentable section on output
> > > collect2: error: ld returned 1 exit status
> >...
> 
>  nmu libgff_1.0-1 . ANY . unstable . -m "recompile static libraries with PIE"

You need to Cc the target package when reassigning so that they get this mail
and not just a "processed..." one.

Scheduled.

Cheers,
Emilio

Bug#823517: jessie-pu: package nbd/1:3.8-4+deb8u3

[Wouter Verhelst]

On Mon, Nov 21, 2016 at 09:06:17AM +0100, Wouter Verhelst wrote:
> Hi,
> 
> On Sun, Nov 20, 2016 at 06:00:37PM +, Jonathan Wiltshire wrote:
> > Hi,
> > 
> > On Thu, May 05, 2016 at 04:43:46PM +0200, Wouter Verhelst wrote:
> > > There is a forward-compatibility bug in nbd-client <= 3.9, in that it
> > > incorrectly merges two flags fields when sending flags to the kernel.
> > > The result of this bug is that all exports exported by nbd-server >= 3.9
> > > and connected to by nbd-client <= 3.9 are all marked as read-only on the
> > > client side.
> > > 
> > > I would like to update the package in Jessie to remedy the issue, so
> > > that upon the release of Stretch, clients running Jessie can still talk
> > > to servers running Stretch.
> > 
> > Is this still desired or should the bug be closed?
> 
> I thought I'd done this long ago, but a quick checks shows that I
> didn't. Yes, it is still desirable. I'll work on it soon.

Built package is in incoming. Not sure why I didn't do it earlier, as
the patch was right there. Oh well.

Sorry for keeping this open so long (and thanks for poking me ;-)

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#845187: systemd: pressing ctrl-alt-delete repeatedly to force immediate reboot leads to systemd getting stuck with something

[Martin Steigerwald]

Package: systemd
Version: 232-5
Severity: normal

Dear Martin, dear Michael, dear Maintainers-

I noticed by pressing Ctrl-Alt-Delete repeatedly quickly at the 90 seconds
timeout for stopping a service that didn´t seem to agree with being stopped
at shutdown that systemd did initiate an immediate reboot.

This does no longer work. Systemd still says it triggers an immediate reboot
but then seems to be stuck. I waited for a while but there was not output.

I could let it sit for a little more and also provide a screenshot of what
is displayed on screen, what I have seen so far didn´t give me a hint what is
getting stuck there.

Maybe there is some debugging stuff I can activate before doing so? If so,
can I also tell systemd to store the debugging stuff in a while before
actually shutting down the laptop? Otherwise important information may have
been scrolled out of the visible screen already.

Thank you,
Martin

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3
ii  libapparmor12.10.95-6
ii  libaudit1   1:2.6.7-1
ii  libblkid1   2.29-1
ii  libc6   2.24-5
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-2
ii  libgcrypt20 1.7.3-2
ii  libgpg-error0   1.25-1
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-1
ii  libkmod223-1
ii  liblz4-10.0~r131-2
ii  liblzma55.2.2-1.2
ii  libmount1   2.29-1
ii  libpam0g1.1.8-3.3
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.6-3
ii  libsystemd0 232-5
ii  mount   2.29-1
ii  util-linux  2.29-1

Versions of packages systemd recommends:
ii  dbus1.10.12-1
ii  libpam-systemd  232-5

Versions of packages systemd suggests:
ii  policykit-10.105-17
ii  systemd-container  232-5
ii  systemd-ui 3-4

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.125
ii  udev 232-5

-- Configuration Files:
/etc/systemd/resolved.conf changed [not included]

-- no debconf information

Bug#827339: Please revert patch for cmd, and fix default pattern

[Patrick Matthäi]

Am 18.11.2016 um 17:51 schrieb Stephan Sürken:
> Hi,
>
> On Fr, 2016-11-18 at 17:01 +0100, Patrick Matthäi wrote:
>> Am 17.11.2016 um 18:52 schrieb Stephan Sürken:
>>> Hi Patrick,
>>>
>>> On Do, 2016-11-17 at 15:40 +0100, Patrick Matthäi wrote:
>>> (...)
 Then the question is, why it does not work on Jessies grep?
>>> did you overlook my comment? Or are my findings wrong?
>>>
>>> Thx!
>>>
>>> S
>> Ah now I get it. You have adjusted the C code of apt-dater, to detect
>> errors without using HTML.
> not quite. I rather fixed the default pattern being used when the user
> does not configure one.
>
>> But we have got still the problem, that the default grep syntax (also
>> your fixed grep syntax) from "typescript" produces a more or less
>> silent
>> "syntax error", like from the beginning of this report.
> afaict, my patch just fixes each and every aspect of this bug report
> ;).
>
> Hth,
>
> S

Ok so adding patch
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827339#34 and drop
current patch 01-grep-syntax-error ?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#845183: mono-gac: missing nunit assemblies prevent installation

[Jo Shields]

On 21/11/16 08:25, Stephen Kitt wrote:
> Package: mono-gac
> Version: 4.6.1.3+dfsg-8
> Severity: normal
> 
> Dear Maintainer,
> 
> This might be a variant of #671607, but just in case: upgrading mono
> failed for me today with
> 
> Setting up mono-gac (4.6.1.3+dfsg-8) ...
> ! Assembly 
> /usr/share/cli-common/policies.d/libnunit-core2.6.3-cil/policy.2.6.nunit.core.dll
>  does not exist
> ! Assembly 
> /usr/share/cli-common/policies.d/libnunit-core-interfaces2.6.3-cil/policy.2.6.nunit.core.interfaces.dll
>  does not exist
> ! Assembly 
> /usr/share/cli-common/policies.d/libnunit-framework2.6.3-cil/policy.2.6.nunit.framework.dll
>  does not exist
> 
> There are no nunit files in /usr/share/cli-common/policies.d.
> 
> Installing libnunit-core2.6.3-cil and libnunit-framework2.6.3-cil
> fixes the issue.

I think I know what the bug might be here.
/var/lib/dpkg/info/libnunit-core2.6.3-cil.postrm should be part of
/var/lib/dpkg/info/libnunit-core2.6.3-cil.prerm - as-is, the postrm
*could* get called in an order where /usr/share/cli-common/policy-remove
fails (e.g. when uninstalling all of mono), so the `rm
/usr/share/cli-common/packages.d/$POLICY.installcligac` never gets
called due to the `set -e`

This bug could well be 10 years old. Huh.

Bug#634262: arpwatch-ng status

[Florian Schlichting]

Hi Afif,

On Sat, Nov 19, 2016 at 12:59:44AM -0800, Afif Elghraoui wrote:
> * The site for arpwatch-ng () is
> down. I was able to find a snapshot of it from earlier this year
> (3/2016) at archive.org:
> 
> http://web.archive.org/web/20160321213852/http://freequaos.host.sk/arpwatch/
> 
> * From the above link, I was able to download the latest release, 1.7.

in 2014 when I created the Debian git repo, I also created an
'upstream-ng' branch so I (or someone else - I never got to it) could
step through the development of arpwatch-ng in a little more detail and
decide if that's a better upstream to base the Debian package on. You
can still find that branch on github:

https://github.com/fschlich/Debian-arpwatch/commits/upstream-ng

Feel free to make use of any of it and push it to the git.d.o repo's
upstream branch if you see fit - I'm glad if it's of use to anybody!

> *  redirects to
> , and freecode is frozen since
> 2014[1]. It looks like the only way to contact upstream is to see
> whether freecode site support can help.
> 
> ...or fork the project again.

I think the arpwatch-ng upstream is as dead as the arpwatch one. There
are a few more repos and patches on github, but it doesn't look like
anybody has stepped up to pick up the pieces. Still I think arpwatch
continues to be useful, and if you find the time to look into the
arpwatch-ng work and find it to be sensible, please go forth and upload
a Debian package based on it!

Florian

Bug#845188: bugs.debian.org: Please provide "Content-Disposition: attachment; filename=[..]" headers

[Chris Lamb]

Package: bugs.debian.org
Version: 2.54+dfsg-7
Severity: wishlist

Hi,

Saving attachments is currently quite ugly. For example:

  $ wget 
https://bugs.debian.org/cgi-bin/bugreport.cgi\?att\=1\;bug\=804063\;filename\=reproducible.patch\;msg\=10

… downloads this to a file called:

  bugreport.cgi?att=1;bug=804063;filename=reproducible.patch;msg=10

This can be especially annoying due to the use of "?" and ";" shell
metacharacters.

Providing the HTTP "Content-Disposition" header of "reproducible.patch"
here would instruct clients to (attempt to) save the file to that name.


Regards,

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

Bug#826297: patch

[Martin Pitt]

Control: tag -1 pending

Hello Dan,

thanks! Applied with slightly adjusted wording:

  https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=1b7ba57

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

Bug#842254: [pkg-golang-devel] Bug#842254: Bug#842254: Bug#842254: Bug#842254: Bug#842254: please allow to use gccgo on architectures providing golang

[Michael Hudson-Doyle]

On 21 November 2016 at 17:22, Tianon Gravi  wrote:

> On 20 November 2016 at 19:45, Michael Hudson-Doyle
>  wrote:
> > Check out mwhudson/add-gccgo-go in the golang-defaults repo :)
>
> Nice!  My only question after taking a look at the diff is whether our
> "gccgo-go" relation on "golang-any" should be "(>=
> ${source:Version})", same as our "golang-go" relation?


Um, yes, I guess so. Pushed.

>> To be clear, you're talking about adding a new "gccgo-go" virtual
> >> binary package to "src:golang-defaults" which satisfies requests for
> >> "golang-go" via Provides (and thus also provides "/usr/bin/go" via
> >> alternatives or Conflicts)?
> >
> > I took out the Provides: bit for now, it seemed a bit icky, but yes.
>
> Yeah, agreed, especially since switching to "golang-any" is supposed
> to be the official way package maintainers can advertize that they
> support gccgo properly.
>
> I wonder how many packages currently depend on "golang-go" explicitly
> rather than "golang-any".


mwhudson@aeglos:~$ chdist grep-dctrl-sources sid -FBuild-Depends -w
golang-go -sPackage | wc -l
665
mwhudson@aeglos:~$ chdist grep-dctrl-sources sid -FBuild-Depends -w
golang-any -sPackage | wc -l
155

So we're getting there. On the other hand:

mwhudson@aeglos:~$ chdist grep-dctrl-packages sid -FDepends -w golang-any
-sPackage | wc -l
6
mwhudson@aeglos:~$ chdist grep-dctrl-packages sid -FDepends -w golang-go
-sPackage | wc -l
632

Most of those 632 should probably not depend on either really, and some are
of course ok. The number dropped by 20 or so when I updated my sid chdist
so that's good :)

>> Will this simplify the logic behind "golang-any"?
> >
> > Yeah. Actually, more than I had realised! Also pushed to my branch.
>
> Very nice; love how much simpler this is in that regard!  Cheers!
>

Yeah, it's nice to get rid of that junk!

Cheers,
mwh

PS: 800 odd golang packages, that seems like a lot?

Bug#845179: FTBFS with super-fresh cython -- seems to carry pre-cythoned sources which get rebuilt during clean

[Tanguy Ortolo]

Yaroslav Halchenko, 2016-11-21 00:27-0500:

While preparing for upload of fresh cython (0.25.2~b0-1) and running build of
rdepends python-aiohttp failed to build with

so you can see that clean does recythonizing, which modifies shipped with
upstream tarball slixmpp-1.2.1/slixmpp/stringprep.c


Well, I am not surprised that generating it again with a newer version 
of Cython results in something a bit different. :-)

Thanks for catching this!


as a quick&dirty solution (besides cleansing the sources pkg) I think you
could make use of  dh_autoreconf so it memorizes changed files


I already had the case with a package written in Vala and shipped with 
pre-generated C file: what I did then was simply to delete these files 
during clean. This is simple, and good enough since missing files are 
not an issue if they are not actually needed. I think I will do the same 
here.


Cyrthonizing at clean is silly, but this seems to be a known limitation 
of the current integration of Cython and distutils… I guess we will have 
to deal with it, as the only consequence will be using the CPU for 
nothing.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#845189: apport-retrace: retrace broken for native installed pacakge

[Ritesh Raj Sarraf]

Package: apport-retrace
Version: 2.20.3-1
Severity: important

I need to find time to debug this properly. In an sandbox env, with
"system" as the sandbox type, retrace picks system config and then tries
to determine the libs and corresponding package. But, it is failing
miserably.

Before anything else, need to check with upstream first.

rrs@learner:/var/crash$ apport-retrace -S system --cache 
~/.cache/apport/retrace/ --stdout /var/crash/_usr_bin_calibre.1000.crash 
invalid /etc/os-release: Does not contain NAME and VERSION_ID
I do not have permission to write to /var/lib/debtags/
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0.0.0 is needed, but 
cannot be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libXcomposite.so.1.0.0 is needed, but cannot 
be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libicuio.so.57.1 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /usr/lib/python2.7/dist-packages/PyQt5/QtXml.x86_64-linux-gnu.so is 
needed, but cannot be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libXinerama.so.1.0.0 is needed, but cannot 
be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqjpeg.so is 
needed, but cannot be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0.5000.2 is needed, but 
cannot be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libgraphite2.so.3.0.1 is needed, but cannot 
be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libxcb-present.so.0.0.0 is needed, but 
cannot be mapped to a package
Uninstalled is True
WARNING: /usr/lib/python2.7/dist-packages/PyQt5/QtWidgets.x86_64-linux-gnu.so 
is needed, but cannot be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libepoxy.so.0.0.0 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5.7.1 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libwebp.so.6.0.1 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /lib/x86_64-linux-gnu/libc-2.24.so is needed, but cannot be mapped to 
a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.7.1 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /lib/x86_64-linux-gnu/ld-2.24.so is needed, but cannot be mapped to a 
package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.7.1 is needed, but cannot 
be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libxslt.so.1.1.29 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /usr/lib/calibre/calibre/plugins/progress_indicator.so is needed, but 
cannot be mapped to a package
Uninstalled is True
WARNING: /usr/lib/python2.7/dist-packages/PyQt5/QtWebKit.x86_64-linux-gnu.so is 
needed, but cannot be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libxcb-xkb.so.1.0.0 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /lib/x86_64-linux-gnu/libz.so.1.2.8 is needed, but cannot be mapped to 
a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0.0.0 is needed, but cannot 
be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libpcre16.so.3.13.3 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /usr/lib/python2.7/dist-packages/PyQt5/QtHelp.x86_64-linux-gnu.so is 
needed, but cannot be mapped to a package
Uninstalled is True
WARNING: /usr/lib/calibre/calibre/plugins/monotonic.so is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libQt5Test.so.5.7.1 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2 is needed, but 
cannot be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0 is needed, but cannot 
be mapped to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libQt5Svg.so.5.7.1 is needed, but cannot be 
mapped to a package
Uninstalled is True
WARNING: /lib/x86_64-linux-gnu/libudev.so.1.6.5 is needed, but cannot be mapped 
to a package
Uninstalled is True
WARNING: /usr/lib/x86_64-linux-gnu/libtdb.so.1.3.11 is need

Bug#845161: udev: "mount: invalid option --" when busybox is not installed

[Simon McVittie]

On Mon, 21 Nov 2016 at 09:50:39 +0100, Martin Pitt wrote:
> Michael Biebl [2016-11-21  1:15 +0100]:
> > Am 21.11.2016 um 00:50 schrieb Simon McVittie:
> > > Because udev's initramfs hook now does "mount --move", it doesn't work 
> > > with
> > > klibc mount, which is used when busybox isn't installed:
> > 
> > 
> > This was changed as a response to
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844775
> > 
> > Luca, you wrote that initramfs-tools is now using mount from util-linux,
> > but I can't find anything in the initramfs-tools changelog

For what it's worth, initramfs-tools in Debian hasn't changed since April,
and appears to use "mount -o move" unconditionally in its own files
(for example in /init, to move /run to /root/run). So it might be best to
just revert that change and stick to "mount -o move", which is known to
work in both busybox and klibc mount.

I can't help wondering why we support three different mount
implementations here, rather than mandating a preferred implementation.

For what it's worth, dracut appears to install the "full-fat" util-linux
mount binary from the host system rather than trying to use statically
linked or otherwise minimal binaries.

> -# move the /dev tmpfs to the rootfs
> -mount -n --move /dev ${rootmnt}/dev
> +# move the /dev tmpfs to the rootfs; fall back to klibc mount that does not
> +# understand --move
> +mount -n --move /dev ${rootmnt}/dev || mount -n -o move /dev ${rootmnt}/dev

This looks fine as a short-term answer.

Longer-term, it would be great if we had a specification for how a
suitable mount implementation for the initramfs must behave, or a consensus
on which mount implementations had to be supported, or even a requirement
that potential mount implementors (klibc or busybox or util-linux) define
a mount_move() shell function or something.

(An alternative long-term direction would be defaulting to dracut, which
has the advantage of not being Debian-specific.)

S

Bug#844684: nmu: dolfin_2016.1.0-5

[Drew Parsons]

On Mon, 2016-11-21 at 09:54 +0100, Emilio Pozuelo Monfort wrote:
> On 18/11/16 05:01, Drew Parsons wrote:
> > 
> > dolfin doesn't seem to have gotten identified for autobuild against
> > the new versions of swig and boost.  Please binNMU.
> > 
> It is built against boost 1.62, and I don't see any swig transition.
> Why is a
> rebuild needed for swig?

Oh yeah, you're right about boost. My system was unable to upgrade to
boost 1.62 and wanted to remove dolfin if I try to force it. So I
thought the problem was a a dolfin dependency, but the actual conflict
was with libboost-1.61-dev.  There must have been a lag when the 1.62
upload wasn't complete so I couldn't replace 1.61. So I've got the
boost upgrade completed now, thanks for the clarification.

The swig dependency is real. dolfin has a tight dependency on swig
because of bug#675207. So 
python-dolfin Depends: swig3.0 (>= 3.0.7), swig3.0 (<< 3.0.8~)

We need that tight dependency updated.

Is there a way to declare the tight dependency so that it gets picked
up by the autobuilders automatically? I gather it's not as
straightforward as normal library dependencies, since it's not a
question of SONAME compatibility.

Drew

Bug#845176: ITP: node-slash -- Convert Windows backslash paths to slash paths

[Pirate Praveen]

On Monday 21 November 2016 01:41 PM, Eduard Bloch wrote:
> I object to have this non-sense be packaged in Debian and ashamed that a
> Debian Developer proposed it.
> 
> It's a waste of Debian resources, i.e. a huge overkill to wrap a trivial
> one-liner, and even that one made wrong (check the "source", it's
> considering non-ASCII paths as not worth being converted).

Are you volunteering to maintain a bundled upstream project that
includes all these small modules?



signature.asc
Description: OpenPGP digital signature

Bug#845190: ITP: node-babel-types -- Babel Types is a Lodash-esque utility library for AST nodes

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-babel-types
  Version : 6.19.0
  Upstream Author : Sebastian McKenzie 
* URL : https://babeljs.io/
* License : Expat
  Programming Lang: JavaScript
  Description : Babel Types is a Lodash-esque utility library for
AST nodes



signature.asc
Description: OpenPGP digital signature

Bug#799759: Status freerdp2 (was: Re: freerdp)

[Mike Gabriel]

Hi Jörg, hi all,

On  Sa 19 Nov 2016 13:38:44 CET, Jörg Frings-Fürst wrote:


Hello,

I'm the maintainer of remmina at Debian.

The release 1.1.2 has no upstream support since one year and it is so
buggy that I think to remove them from stretch.


Now my opinion is to pack the new rc - release to experimental.
Therefore I need the new freerdp - release into experimental too.

Also I see the RFH bug for freerdp. You you want I can do the work and
add me as uploader.

I wish a nice weekend.

CU
Jörg


I just got in touch with my upstream contact again (Bernhard Miklautz).

The main show stopper at the moment is (and has been for a while now),  
that freerdp (be it the current v1.x or upcoming v2) does not build  
against openssl 1.1, yet.


The required changes are non-trivial and it may be possible that we  
have to remove freerdp from Debian stretch completely, if upstream  
does not get that solved within the next couple of weeks/months.


The estimated effort for updating the freerdp2 code base (current  
master on github.com/FreeRDP/FreeRDP) is 1 person for 2 weeks.


Mike

--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpVK4Zhf2JgI.pgp
Description: Digitale PGP-Signatur

Bug#845161: udev: "mount: invalid option --" when busybox is not installed

[Luca Boccassi]

On Mon, 2016-11-21 at 10:01 +, Simon McVittie wrote:
> On Mon, 21 Nov 2016 at 09:50:39 +0100, Martin Pitt wrote:
> > Michael Biebl [2016-11-21  1:15 +0100]:
> > > Am 21.11.2016 um 00:50 schrieb Simon McVittie:
> > > > Because udev's initramfs hook now does "mount --move", it doesn't work 
> > > > with
> > > > klibc mount, which is used when busybox isn't installed:
> > > 
> > > 
> > > This was changed as a response to
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844775
> > > 
> > > Luca, you wrote that initramfs-tools is now using mount from util-linux,
> > > but I can't find anything in the initramfs-tools changelog
> 
> For what it's worth, initramfs-tools in Debian hasn't changed since April,
> and appears to use "mount -o move" unconditionally in its own files
> (for example in /init, to move /run to /root/run). So it might be best to
> just revert that change and stick to "mount -o move", which is known to
> work in both busybox and klibc mount.
> 
> I can't help wondering why we support three different mount
> implementations here, rather than mandating a preferred implementation.
> 
> For what it's worth, dracut appears to install the "full-fat" util-linux
> mount binary from the host system rather than trying to use statically
> linked or otherwise minimal binaries.

Hello Simon, Martin and Michael,

First of all, sorry for the breakage!

The context is a squashfs and liveboot/build based ISO. When rebasing
from Jessie to Stretch I encountered this issue as described in the
original bug. Booting was broken. I tracked it down to the mount in the
init-bottom/udev script. Changing from -o move to --move fixed it.

I don't pick the mount utility in any of my scripts or configs, so I do
not know when or where the change happened, could have been anytime
since Jessie was released. But I am 100% sure that it's the util-linux
one being used in this case, as proved by the fact that --move fixed the
boot process.

Of course as you all pointed out this won't work with klibc mount and it
needs to be fixed. But please if possible don't revert, as it will break
again virtual filesystem based images.

> > -# move the /dev tmpfs to the rootfs
> > -mount -n --move /dev ${rootmnt}/dev
> > +# move the /dev tmpfs to the rootfs; fall back to klibc mount that does not
> > +# understand --move
> > +mount -n --move /dev ${rootmnt}/dev || mount -n -o move /dev ${rootmnt}/dev
> 
> This looks fine as a short-term answer.
> 
> Longer-term, it would be great if we had a specification for how a
> suitable mount implementation for the initramfs must behave, or a consensus
> on which mount implementations had to be supported, or even a requirement
> that potential mount implementors (klibc or busybox or util-linux) define
> a mount_move() shell function or something.
> 
> (An alternative long-term direction would be defaulting to dracut, which
> has the advantage of not being Debian-specific.)

Martin, for completeness I just tested the change above and as expected
everything still works on squashfs + liveboot, so +1 from me :-)

Simon, having a standardised approach would be very welcome indeed!
Having all implementations of mount offer the same options would be an
easy starting point I guess, but having a well-defined spec as you
suggested would be even better.

Thank you all for your help.

Kind regards,
Luca Boccassi


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

Bug#843898: Something to try

[Tobias Hansen]

On 11/21/2016 01:57 AM, Sebastian P. Luque wrote:
> On Sun, 20 Nov 2016 21:01:08 +,
> Tobias Hansen  wrote:
> 
> [...]
> 
>>> $ ls -alh ~/.local/lib/python2.7/site-packages/backports/ total 12K
>>> drwxr-xr-x 3 sluque sluque 4.0K Oct 30 16:16 .  drwx-- 20 sluque
>>> sluque 4.0K Oct 30 16:18 ..  drwxr-xr-x 2 sluque sluque 4.0K Oct 30
>>> 16:16 configparser
> 
>> What happens if you rename that for a moment? Does it fix the problem?
> 
> No; same result.
> 

What do you get if you run this:
python -c "import sys; print sys.path"

What exactly did you try? Could you try renaming the whole folder
~/.local/lib/python2.7/site-packages ?

Bug#845157: systemd: loading compressed modules no longer works

[M G Berberich]

Hello,

Am Sonntag, den 20. November schrieb Michael Biebl:
> Am 20.11.2016 um 23:21 schrieb M G Berberich:
> > Package: systemd
> > Version: 232-3
> > Severity: normal
> > 
> > 
> > Dear Maintainer,
> > 
> > with the last update compressed modules are no longer loaded during
> > boot. Compressed modules can be loaded by modprobe.
> 
> From which version did you upgrade which still worked?

From 231-9 to 232-3
2016-11-20 systemd:amd64 (231-9, 232-3)

> Were other parts of the system upgraded as well, like for example libkmod2

No.
But libkmod was held on 22-1, because debian libkmod does not support
compressed modules.
Upgrading to (a modified) 23-1 did solve the problem.
There seems to be some incompatibility between 22-1 and 23-1 that is
not reflected in the libraries major-number.

> >   systemd[1]: systemd-modules-load.service: Main process exited, 
> > code=exited, status=1/FAILURE
> >   systemd[1]: Failed to start Load Kernel Modules.
> >   systemd[1]: systemd-modules-load.service: Unit entered failed state.
> >   systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
> > 
> 
> systemd-modules-load uses libkmod2 to load the kernel modules.
> 
> src/modules-load/modules-load.c did not really change between v231 and v232

Sorry for the inconvinience
bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“  | m...@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | 

Bug#845091: mpd starts pulseaudio even when configured not to use it

[Max Kellermann]

On 2016/11/20 11:08, Juha Jäykkä  wrote:
> When mpd runs, it also runs pulseaudio. This is not just unnecessary, but 
> also causes weird
> unwanted side-effects like muting of Master volume channel in alsa (which mpd 
> is also not
> configured to use).

This bug report should be moved to libpulse.  MPD does not launch
PulesAudio, and it doesn't even have any code which would be able to
do that.

Bug#845191: libhtml-parser-perl: please make the build reproducible (buildpath)

[Daniel Shahaf]

Source: libhtml-parser-perl
Version: 3.72-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that libhtml-parser-perl could not be built reproducibly.

Specifically, for some values of the path to the root of the source tree
(such as '/tmp/tmp.tnegvZNHVC/foobar'), the HTML::Entities man page had
the following header:

.TH libhtml-parser-perl-3.72::blib::lib::HTML::Entities 3pm "2016-07-06" "perl 
v5.24.1" "User Contributed Perl Documentation"

Patch attached; it results in:

.TH HTML::Entities 3pm "2016-07-06" "perl v5.24.1" "User Contributed Perl 
Documentation"

Cheers,

Daniel

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

[[[
diff --git a/debian/rules b/debian/rules
index 6861f47..0549a40 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,7 +10,8 @@ TMP = $(CURDIR)/debian/$(PACKAGE)
 
 override_dh_auto_build:
dh_auto_build
-   pod2man --utf8 --section 3pm $(CURDIR)/blib/lib/HTML/Entities.pm > 
$(CURDIR)/blib/man3/HTML::Entities.3pm
+   pod2man --utf8 --section 3pm --name=HTML::Entities \
+   $(CURDIR)/blib/lib/HTML/Entities.pm > 
$(CURDIR)/blib/man3/HTML::Entities.3pm
 
 override_dh_fixperms:
dh_fixperms
]]]

Bug#845142: adwaita-qt: Please build also for Qt4

[Jonas Smedegaard]

Quoting Dmitry Shachnev (2016-11-21 08:13:12)
> On Sun, Nov 20, 2016 at 07:38:57PM +0100, Jonas Smedegaard wrote:
>> adwaita-qt supports building against either Qt4 or Qt5, yet the Debian
>> package has it built only against Qt5.
>>
>> This is a problem, since not all applications have yet migrated to Qt5.
>> In particular, Scribus stil uses Qt4 and is a) related to visual design
>> and b) without an equivalent in the GTK+ realm, both reasons for it
>> needing something like adwaita-qt when used in mostly-GTK+ environments.
>
> OK, I can do this, but only for Stretch.
> 
> For Buster, we have a plan to remove Qt 4 from archive [1], and I will 
> do my best to remove Qt 4 dependencies from my packages.

Obviously when Qt4 truly is getting phased out, so should it be for this 
package as well :-)

Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#845192: adns: FTBFS on x32 with weird testsuite failures

[Thorsten Glaser]

Source: adns
Version: 1.5.0~rc1-1
Severity: important
Justification: fails to build from source

This is kinda annoying as gpg2 now Build-Depends on this package ☹

https://buildd.debian.org/status/fetch.php?pkg=adns&arch=x32&ver=1.5.0%7Erc1-1&stamp=1479288073

If I run the build manually, in a network-enabled cowbuilder,
I get these errors instead:

-cutting here may damage your screen surface-
make -C regress check
make[1]: Entering directory '/tmp/buildd/adns-1.5.0~rc1/regress'
longdomsrch0 ptrbaddom2 datapluscname unknown-flags-init tcpallfail 
manyptrwrongrty bogus-sortlist ndots -simple --- ./case-tcpblockwr.err  
2014-10-19 23:07:03.0 +
+++ output-tcpblockwr.err   2016-11-21 10:38:04.763819191 +
@@ -0,0 +1,4 @@
+adns test harness: program did unexpected:
+ select max=7 rfds=[5,6] wfds=[] efds=[6] to=0.00
+was expecting:
+ select max=7 rfds=[5,6] wfds=[] efds=[6] to=21.69155
--- ./case-tcpblockwr.out   2014-10-19 23:07:01.0 +
+++ output-tcpblockwr.out   2016-11-21 10:38:04.763819191 +
@@ -48,58 +48,57 @@
 test.iwj.relativity.greenend.org.uk. flags 2 type PTR(checked): Domain invalid 
for particular DNS query type; nrrs=0; cname=$; owner=$; ttl=604800
 test.iwj.relativity.greenend.org.uk. flags 2 type PTR(checked): Domain invalid 
for particular DNS query type; nrrs=0; cname=$; owner=$; ttl=604800
 adns debug: TCP connected (NS=172.18.45.2)
-test.iwj.relativity.greenend.org.uk. flags 2 type A(-): No such data; nrrs=0; 
cname=$; owner=$; ttl=59
-test.iwj.relativity.greenend.org.uk. flags 2 type NS(raw): OK; nrrs=1; 
cname=$; owner=$; ttl=59
+test.iwj.relativity.greenend.org.uk. flags 2 type A(-): No such data; nrrs=0; 
cname=$; owner=$; ttl=14
+test.iwj.relativity.greenend.org.uk. flags 2 type NS(raw): OK; nrrs=1; 
cname=$; owner=$; ttl=14
  ns0.relativity.greenend.org.uk
-test.iwj.relativity.greenend.org.uk. flags 2 type CNAME(-): No such data; 
nrrs=0; cname=$; owner=$; ttl=59
-test.iwj.relativity.greenend.org.uk. flags 2 type SOA(raw): OK; nrrs=1; 
cname=$; owner=$; ttl=59
+test.iwj.relativity.greenend.org.uk. flags 2 type CNAME(-): No such data; 
nrrs=0; cname=$; owner=$; ttl=14
+test.iwj.relativity.greenend.org.uk. flags 2 type SOA(raw): OK; nrrs=1; 
cname=$; owner=$; ttl=14
  ns0.relativity.greenend.org.uk hostmaster.relativity.greenend.org.uk 42 3600 
120 6604800 60
-test.iwj.relativity.greenend.org.uk. flags 2 type PTR(raw): No such data; 
nrrs=0; cname=$; owner=$; ttl=59
-test.iwj.relativity.greenend.org.uk. flags 2 type HINFO(-): No such data; 
nrrs=0; cname=$; owner=$; ttl=59
-test.iwj.relativity.greenend.org.uk. flags 2 type MX(raw): No such data; 
nrrs=0; cname=$; owner=$; ttl=59
-test.iwj.relativity.greenend.org.uk. flags 2 type TXT(-): No such data; 
nrrs=0; cname=$; owner=$; ttl=59
-test.iwj.relativity.greenend.org.uk. flags 2 type RP(raw): No such data; 
nrrs=0; cname=$; owner=$; ttl=59
-test.iwj.relativity.greenend.org.uk. flags 2 type NS(+addr): OK; nrrs=1; 
cname=$; owner=$; ttl=59
+test.iwj.relativity.greenend.org.uk. flags 2 type PTR(raw): No such data; 
nrrs=0; cname=$; owner=$; ttl=14
+test.iwj.relativity.greenend.org.uk. flags 2 type HINFO(-): No such data; 
nrrs=0; cname=$; owner=$; ttl=14
+test.iwj.relativity.greenend.org.uk. flags 2 type MX(raw): No such data; 
nrrs=0; cname=$; owner=$; ttl=14
+test.iwj.relativity.greenend.org.uk. flags 2 type TXT(-): No such data; 
nrrs=0; cname=$; owner=$; ttl=14
+test.iwj.relativity.greenend.org.uk. flags 2 type RP(raw): No such data; 
nrrs=0; cname=$; owner=$; ttl=14
+test.iwj.relativity.greenend.org.uk. flags 2 type NS(+addr): OK; nrrs=1; 
cname=$; owner=$; ttl=14
  ns0.relativity.greenend.org.uk ok 0 ok "OK" ( INET 172.18.45.6 )
-test.iwj.relativity.greenend.org.uk. flags 2 type MX(+addr): No such data; 
nrrs=0; cname=$; owner=$; ttl=59
-test.iwj.relativity.greenend.org.uk. flags 2 type SOA(822): OK; nrrs=1; 
cname=$; owner=$; ttl=59
+test.iwj.relativity.greenend.org.uk. flags 2 type MX(+addr): No such data; 
nrrs=0; cname=$; owner=$; ttl=14
+test.iwj.relativity.greenend.org.uk. flags 2 type SOA(822): OK; nrrs=1; 
cname=$; owner=$; ttl=14
  ns0.relativity.greenend.org.uk hostmas...@relativity.greenend.org.uk 42 3600 
120 6604800 60
-test.iwj.relativity.greenend.org.uk. flags 2 type RP(822): No such data; 
nrrs=0; cname=$; owner=$; ttl=59
-test.iwj.relativity.greenend.org.uk. flags 2 type A(-): No such data; nrrs=0; 
cname=$; owner=$; ttl=59
-test.iwj.relativity.greenend.org.uk. flags 2 type NS(raw): OK; nrrs=1; 
cname=$; owner=$; ttl=59
+test.iwj.relativity.greenend.org.uk. flags 2 type RP(822): No such data; 
nrrs=0; cname=$; owner=$; ttl=14
+test.iwj.relativity.greenend.org.uk. flags 2 type A(-): No such data; nrrs=0; 
cname=$; owner=$; ttl=14
+test.iwj.relativity.greenend.org.uk. flags 2 type NS(raw): OK; nrrs=1; 
cname=$; owner=$; ttl=14
  ns0.relativity.greenend.org.uk
-test.iwj.relativity.greenend.org.uk. flags 2 type CNAME(-): No such data; 
nrrs=0; cname=$; owner=$

Bug#730420: logrotate: Please mark as multi-arch: foreign

[Elrond]

Hi,


On Sun, Nov 24, 2013 at 23:34:22 +0100, Stefan Fritsch wrote:
> Package: logrotate
> Version: 3.8.6-1
> Severity: wishlist
> 
> There is no reason why logrotate would not work even for daemons from a
> foreign architecture.  But in order to be able to install daemons
> packages that depend on logrotate from a foreign architecture, logrotate
> has to be 'multi-arch: foreign'.

This just affected me and I forced things.

So: What is the current status of this?


Cheers

Elrond

Bug#827339: Please revert patch for cmd, and fix default pattern

[Stephan Sürken]

Hi Patrick,

On Mo, 2016-11-21 at 10:12 +0100, Patrick Matthäi wrote:

(...)

> > S
> Ok so adding patch
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827339#34 and drop
> current patch 01-grep-syntax-error ?

sure, that would be my suggestion.

For your Debian patch, you should maybe only use the "entity fixes" of
my patch (not the additions to the regex of my personal liking which
are also in there ;).

@Thomas:

Of course upstream should fix this too, eventually.

Thx!

S

Bug#845161: udev: "mount: invalid option --" when busybox is not installed

[Simon McVittie]

On Mon, 21 Nov 2016 at 10:16:50 +, Luca Boccassi wrote:
> The context is a squashfs and liveboot/build based ISO.
...
> I don't pick the mount utility in any of my scripts or configs, so I do
> not know when or where the change happened, could have been anytime
> since Jessie was released. But I am 100% sure that it's the util-linux
> one being used in this case, as proved by the fact that --move fixed the
> boot process.

I believe this was considered to be a bug in live-boot-initramfs-tools
(and its fork open-infrastructure-system-boot): l-b-i-t and o-i-s-b added
/root/bin to $PATH, causing the to-be-booted system's util-linux /bin/mount
to be used instead of the initramfs's busybox or klibc mount.
A kernel and initramfs-tools maintainer stated in
 that this
is not supportable - I believe his position was that every command must
either run in the initramfs with $PATH entirely from the initramfs,
or run chrooted into the to-be-booted system with $PATH entirely from
the to-be-booted system, but never a mixture of the two.

This was fixed as #823069 for l-b-i-t and as #832752 for o-i-s-b. Both
bugs were treated as having 'critical' severity.

> Of course as you all pointed out this won't work with klibc mount and it
> needs to be fixed. But please if possible don't revert, as it will break
> again virtual filesystem based images.

My understanding is that if you build your images
with live-boot-initramfs-tools (>= 1:20160511) or with
open-infrastructure-system-boot (>= 20160601-1), both of which are
available in testing, then reverting the udev change altogether
(consistently using mount -o move everywhere) should be harmless.

S

Bug#845194: amd64-microcode: please make the early initramfs image reproducible

[Chris Lamb]

Source: amd64-microcode
Version: 3.20160316.2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps fileordering toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] on behalf of the
Tails operating system [1], I noticed that amd64-microcode generates
a prepended initramfs image that is not reproducible.

Patch attached.

 [0] https://reproducible-builds.org/
 [1] https://tails.boum.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/initramfs.hook b/debian/initramfs.hook
index d250719..b290d21 100755
--- a/debian/initramfs.hook
+++ b/debian/initramfs.hook
@@ -89,9 +89,18 @@ EFWCD="${EFWD}/d/kernel/x86/microcode"
 EFWF="${EFWCD}/AuthenticAMD.bin"
 
 mkdir -p "${EFWCD}" && \
- find "${AUCODE_FW_DIR}/." -maxdepth 1 -type f -print0 | xargs -0 -r cat 
2>/dev/null >"${EFWF}" && \
+ find "${AUCODE_FW_DIR}/." -maxdepth 1 -type f -print0 | LC_ALL=C sort -z | 
xargs -0 -r cat 2>/dev/null >"${EFWF}" && \
+ # if SOURCE_DATE_EPOCH is set, try and create a reproducible image
+ if [ "${SOURCE_DATE_EPOCH}" != "" ]; then
+# ensure that no timestamps are newer than $SOURCE_DATE_EPOCH
+find "${EFWD}" -newermt "@${SOURCE_DATE_EPOCH}" -print0 | \ 
+xargs -0r touch --no-dereference --date="@${SOURCE_DATE_EPOCH}"
+
+# --reproducible requires cpio >= 2.12
+cpio --usage | grep -qs -- "--reproducible" && 
cpio_reproducible="--reproducible"
+ fi && \
  test -s "${EFWF}" && \
- ( cd "${EFWD}/d" ; find . -print0 | sort -z | cpio --null -R 0:0 -H newc -o 
--quiet > "${EFWE}" ) \
+ ( cd "${EFWD}/d" ; find . -print0 | LC_ALL=C sort -z | cpio --null 
$cpio_reproducible -R 0:0 -H newc -o --quiet > "${EFWE}" ) \
 && prepend_earlyinitramfs "${EFWE}" || {
 [ -d "${EFWD}" ] && rm -fr "${EFWD}"
 echo "E: amd64-microcode: failed to create or prepend the early initramfs 
to the initramfs" >&2

Bug#845078: [pkg-gnupg-maint] Bug#845078: Links against libadns1 with limited security support

[Werner Koch]

On Sun, 20 Nov 2016 10:03, a...@sigxcpu.org said:

> libadns1 has limited security support in Debian so I wonder if this is a
> good choice for dirmngr. Please consider using another resolver by

Due to the unresponsive ADNS upstream maintainer, we are evaluating
other options than ADNS.  We have two reasons to use our own resolver:

 - Avoids the use of the Windows API.  However, that can be changed with
   some effort.

 - To enable TOR based DNS.  That currently works only on Windows
   because there we can and need to use a patch version of ADNS :-(.

We actually don't make use of the async features of ADNS.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpG_wuNq_F3E.pgp
Description: PGP signature

Bug#845195: Imagemagick (jessie and older) buffer overlfow

[Bastien ROUCARIES]

Package: src:imagemagick
version: 8:6.8.9.9-5+deb8u5
Severity: grave
Tags: patch security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
control: found -1 8:6.7.7.10-5+deb7u7

Found by code review a buffer overflow in imagemagick tiff file handling

Upstream commit 58cf5bf4fade82e3b510e8f3463a967278a3e410

Bug#844928: python-keystoneclient FTBFS with openssl 1.1.0

[Adrian Bunk]

Control: retitle -1 python-keystoneclient FTBFS with openssl 1.1.0
Control: block 827061 by -1

Works for me with version 1.0.2j-1 of the openssl package,
and fails for me with version 1.1.0b-2 of the openssl package.

cu
Adrian

-- 

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

Bug#845196: Check return of write function

[Bastien ROUCARIES]

Package: src:imagemagick
version: 8:6.8.9.9-5+deb8u5
Severity: important
Tags: patch security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
control: found -1 8:6.7.7.10-5+deb7u7

Imagemagick write path does not check return of fputc.

Therefore it could return success of conversion instead of faillure.

This could be a problem for php-magick

Bastien

Bug#845197: libssh-4 and libssh-dev have different libssl-dependencies

[Mihai Moldovan]

Package: libssh-4
Version: 0.7.3-1
Source: libssh

On Debian Unstable, libssh-4 is built against and (automatically) depends upon
libssl1.0.2 - the corresponding dev-package for libssl1.0.2 is libssl1.0-dev.

Its corresponding dev-package libbsh-dev hard-depends upon libssl-dev (which is
OpenSSL 1.1, not 1.0.)

This is an inconsistency that shouldn't be there.

It gets worse when trying to install apache2-dev for instance, which depends
upon libssl1.0-dev | libssl-dev (< 1.1).

libssl1.0-dev (pulled in by apache2-dev) and libssl-dev (pulled in by
libssh-dev) conflict. Boom.

I suggest changing the dependency of libssh-dev also to "libssl1.0-dev |
libssl-dev (< 1.1)".


---

This is currently not a problem on stretch, as libssl-dev is still part of
OpenSSL 1.0 there, but might get problematic if stretch decides to also ship
OpenSSL 1.1. I currently do not see it happen, so regard Stretch/Testing as
unaffected.


Best regards,



Mihai



signature.asc
Description: OpenPGP digital signature

Bug#845198: Check validity of extend during TIFF file reading

[Bastien ROUCARIES]

Package: src:imagemagick
version: 8:6.8.9.9-5+deb8u5
Severity: important
Tags: patch security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
control: found -1 8:6.7.7.10-5+deb7u7

This will avoid a buffer overflow

Found during git tree review

origin; 
https://github.com/ImageMagick/ImageMagick/commit/2bb6941a2d557f26a2f2049ade466e118eeaab91

Bug#845172: manpages-dev: no function protypes in example from mbstowcs(3)

[Michael Kerrisk (man-pages)]

Upstream maintainer here.

I added the missing include.

But I am unsure what to do about the other point (regarding gcc
-Wconversion). There is an analogous situation with islower() and
similar functions, where the solution is described by an update I
recently added for the upcoming upstream release

   The standards require that the argument c for these  functions  is
   either  EOF  or a value that is representable in the type unsigned
   char.  If the argument c is of type  char,  it  must  be  cast  to
   unsigned char, as in the following example:

   char c;
   ...
   res = toupper((unsigned char) c);

   This  is necessary because char may be the equivalent signed char,
   in which case a byte where the  top  bit  is  set  would  be  sign
   extended  when converting to int, yielding a value that is outside
   the range of unsigned char.

However, we don't have a similar solution for iswlower(), because
there is no "(unsigned wchar_t)" cast. And casting to (wint_t) seems
incorrect to me, because if wchar_t is a signed type smaller than
wint_t, then sign extension could occur.

I could be wrong, but it seems like an implementation bug that one of
these types is signed and the other is unsigned.

Cheers,

Michael

Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'

[Santiago Vila]

On Sat, 19 Nov 2016, Matthias Klose wrote:

> > It's unlikely a hardware problem because the build was made in a
> > virtual machine and the build was tried twice. This is written
> > in the bug report itself.
> > 
> > This is a lot more likely to be a bug which happens randomly,
> > for example, a bug in the Makefile.
> > 
> > Such bugs *do* exist, just see
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841096
> > 
> > for a very simple example.
> > 
> > 
> > In this case, there is absolutely zero evidence that it's a hardware
> > problem and not a bug which happens randomly.
> > 
> > Do you always close bugs which happen randomly just because you can't
> > reproduce them yourself, or can you acknowledge the fact that not all
> > packages either always build or always fail?
> > 
> > (I can give a lot more examples of packages which fail to build
> > randomly if you are interested).
> 
> it might not be "hardware" problem, but with all this "virtual overhead" a
> corruption with some file system or something else.  Yes, I intend to close 
> such
> bug reports,

It's completely ok to close a report which happens because of hardware
problems. However, that's not the kind of randomness I was talking
about.

I refer, for example, to randomness which happens when some Makefile
expect the output of "find" to be in a certain order.

[ Please read the link I posted before ]

There is no canonical order for the output of "find", so different
filesystem ordering does not mean the system is misconfigured or that
there is corruption in the filesystem.

> because GCC itself retries to build these files, and apparently it
> succeeded to build it (or else you wouldn't see this message).  That might be 
> a
> real bug, but then GCC is the wrong package to file a bug report for.

What would be the right package for a bug in one of GCC Makefiles, then?

What if Lucas was able to reproduce this in two different machines and
the failure and the error message was the same? Would you discard
"filesystem corruption" as the "most likely reason" in such case?

[ Or maybe you are claiming that GCC Makefiles are 100% bug-free and
  absolutely perfect and any evidence in contrary *must* be an error?
  I really hope that's not what you meant here. ]

Thanks.

Bug#845199: dolibarr broken after upgrading from 3.5.8+dfsg1-1 to 4.0.2+dfsg4-1 and purging php5 packages

[Jean-Marc]

Package: dolibarr
Version: 4.0.2+dfsg4-1
Severity: important

Dear Maintainer,

On Sunday, November the 20th, I ran a dist-upgrade.
It came with an upgrade of Dolibarr.
Install went fine.
I started Dolibarr and was re-directed to the update page.
I ran all the steps, step by step, to update from 3.5 to 4.0 and everything 
went fine.
After the update, I did a quick tour of the application (clients, providers, 
bank accounts, ..).
And evrything was looking fine.

After that, I ran an autoremove cleaning up the following packages:
libfpdi-php:amd64 (1.4.1-1), php-fpdf:amd64 (3:1.8.1.dfsg-2), 
php7.0-mbstring:amd64 (7.0.12-1), php5-cli:amd64 (5.6.26+dfsg-1), 
php5-readline:amd64 (5.6.26+dfsg-1), php5-json:amd64 (1.3.9-1), 
libapache2-mod-php5:amd64 (5.6.26+dfsg-1), libfpdf-tpl-php:amd64 (1.2-2), 
libonig4:amd64 (6.1.2-1), php5-curl:amd64 (5.6.26+dfsg-1), php5-ldap:amd64 
(5.6.26+dfsg-1), php-mbstring:amd64 (1:7.0+46), php5:amd64 (5.6.26+dfsg-1), 
libpoppler61:amd64 (0.44.0-3), php-mail-mime:amd64 (1.10.0-2), libqdbm14:amd64 
(1.8.78-6+b5)

And Dolibarr stops working.

I just code the PHP code instead of the application login page.

Tell me if I can help solving this issue.


Jean-Marc


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

Kernel: Linux 4.8.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 dolibarr depends on:
ii  fonts-dejavu-core   2.37-1
ii  javascript-common   11
ii  libapache2-mod-php  1:7.0+46
ii  libapache2-mod-php7.0 [libapache2-mod-php]  7.0.12-1
ii  libjs-jquery3.1.1-1
ii  libjs-jquery-cookie 11-3
ii  libjs-jquery-flot   0.8.3+dfsg-1
ii  libjs-jquery-ui 1.12.1+dfsg-1
ii  libnusoap-php   0.9.5-3
ii  libphp-adodb5.20.7-1
ii  php-cli 1:7.0+46
ii  php-curl1:7.0+46
ii  php-gd  1:7.0+46
ii  php-ldap1:7.0+46
ii  php-pclzip  2.8.2-4
ii  php-tcpdf   6.2.12+dfsg2-1
ii  php7.0-cli [php-cli]7.0.12-1
ii  php7.0-curl [php-curl]  7.0.12-1
ii  php7.0-gd [php-gd]  7.0.12-1
ii  php7.0-ldap [php-ldap]  7.0.12-1
ii  php7.0-mysql [php-mysqli]   7.0.12-1
ii  ttf-dejavu-core 2.37-1
ii  xdg-utils   1.1.1-1

Versions of packages dolibarr recommends:
ii  apache2 [httpd]   2.4.23-7
ii  default-mysql-client  1.0.1
ii  default-mysql-server  1.0.1

Versions of packages dolibarr suggests:
ii  firefox-esr [www-browser]  45.5.0esr-1
ii  midori [www-browser]   0.5.11-ds1-4
pn  php-geoip  
ii  w3m [www-browser]  0.5.3-32

-- no debconf information

Bug#758808: LVM timeout because of thin-check

[Philipp Marek]

I believe I know _what_'s taking so long, at least in my case: a crashed 
machine leaves thin-lvm dirty, needing a thin-check on the next boot.

That's taking too long, and so I run into the systemd timeout; when I get 
dropped into the recovery shell, I can run "vgchange -ay", wait for it to 
complete, and continue the boot normally via "mount -a" and .


So, if only the timeout would be longer

Bug#845200: libnet-dns-perl: Setting $/ to "\r\n" breaks Net::DNS

[Benoit Panizzon]

Package: libnet-dns-perl
Version: 0.81-2+deb8u1
Severity: normal

Dear Net::DNS Maintainer.

I'm not so sure this is a bug or some kind of expected behaviour.

I was coding some email application and for that I needed to set the 'line 
ending'
$/ to "\r\n".

As I wanted to enhance that application by querying RBL Blacklists I started
using Net::DNS which I use in a lot of other applications.

It turned out, that Net::DNS always sent the requestst to 127.0.0.1 or ::1 
instead
of the nameservers found in /etc/resolv.conf of the name passed via
$res->nameservers() list.

If I specified an IP Address in $res->nameservers that worked fine, but as DNS 
tents
mostly support ipv6 I wanted to avoid using ip addresses in favour of hostnames.

Some more debugging revealed that $res->nameservers also failed to resolve the 
name-
server because it send the requests to 'localhost'.

So I re-made a simple example to figure out what causes the issue.

It turned out to be setting $/ to "\r\n";

--- snipp 
#!/usr/bin/perl
use strict;
use warnings;
use Net::DNS;

$/ = "\r\n";

my $host = "www.google.com.";
 
my $res = Net::DNS::Resolver->new ( debug => 1) ;
$res->udp_timeout(3);
$res->tcp_timeout(3);
my $dnsquery = $res->search("$host");

if ($dnsquery) {
   foreach my $rr ( $dnsquery->answer ) {
  next unless $rr->type eq "A";
  warn "Found an A record!\n";
   }
} else {
   if ( !$res->errorstring =~ /NXDOMAIN/ ) {
   warn "query failed: ", $res->errorstring, "\n";
   } else {
warn "Domain not found!\n";
   }
}
--- snapp ---

this fails until you comment out the $/ line.

I don't know if the root cause might be, that /etc/resolv.conf cannot be read 
anymore.

-Benoit-

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

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

Versions of packages libnet-dns-perl depends on:
ii  libc6   2.19-18+deb8u6
ii  libdigest-hmac-perl 1.03+dfsg-1
ii  libio-socket-inet6-perl 2.72-1
ii  libnet-ip-perl  1.26-1
ii  perl5.20.2-3+deb8u6
ii  perl-base [perlapi-5.20.2]  5.20.2-3+deb8u6

libnet-dns-perl recommends no packages.

libnet-dns-perl suggests no packages.

-- no debconf information

Bug#844021: libnative-platform-java 0.11-4 is not compatible with programs built with 0.10*

[Vincent Danjean]

Package: libnative-platform-java
Followup-For: Bug #844021

  Hi,

  As already explained, as libnative-platform-java changed its ABI, the new
version does not work with (all) programs wrote for the previous version.
  In Debian, gradle is the only one reverse dependency of
libnative-platform-java (i.e. it is the only package that directly uses
libnative-platform-java).

  gradle 2.13 do not work with libnative-platform-java 0.11 (at least, not all
features of gradle can be used when libnative-platform-java 0.11 is intalled)
  But gradle 3.1 (currently in unstable) works with (and even requires)
libnative-platform-java 0.11.

  So, to close this bug, I propose this small patch:
diff --git a/debian/control b/debian/control
index 27cb23f..3b95fdd 100644
--- a/debian/control
+++ b/debian/control
@@ -19,6 +19,7 @@ Package: libnative-platform-java
 Architecture: all
 Depends: libnative-platform-jni (>= ${source:Version}), ${misc:Depends}
 Suggests: libnative-platform-java-doc
+Breaks: gradle (<< 3.1), libgradle-core-java (<< 3.1)
 Description: Java bindings for various native APIs
  A collection of cross-platform Java APIs for various native APIs.
  Supports OS X, Linux, Solaris and Windows.

  Applying it will ensure that, (when gradle and libnative-platform-java will
be migrated to testing) if a user does a partial upgrade from stable to
testing, it will not keep a (old) gradle with a (incompatible) new
libnative-platform-java package.

  Regards,
Vincent


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

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

Versions of packages libnative-platform-java depends on:
ii  libnative-platform-jni  0.10+dfsg-2

libnative-platform-java recommends no packages.

libnative-platform-java suggests no packages.

-- no debconf information

Bug#845201: Lintian updates for Rust packaging in /usr/share/cargo/registry

[Josh Triplett]

Package: lintian
Version: 2.5.49
Severity: wishlist

I'm currently working on tools and automation to package Rust packages
(called "crates").  The current plan for doing so involves packaging the
upstream crate source in a subdirectory of /usr/share/cargo/registry/.
This results in a couple of lintian issues, and I'd like to address
those in lintian rather than adding overrides to a large number of
packages.

Can you please exclude files under /usr/share/cargo/registry/ from the
following lintian checks?

- extra-license-file (the upstream crate source includes licenses).
- package-contains-vcs-control-file (some crates include .gitignore or
  .gitattributes files, and I've seen package build systems that read
  .gitignore at build time).

Thanks,
Josh Triplett

Bug#845202: Better check for bufferoverflow for TIFF handling

[Bastien ROUCARIES]

Package: src:imagemagick
version: 8:6.8.9.9-5+deb8u5
Severity: important
Tags: patch security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
control: found -1 8:6.7.7.10-5+deb7u7

commit c668a174e039905b4df1aaea96fcf087b8526575
Author: Cristy 
Date:   Wed Jul 6 08:15:57 2016 -0400

Improve buffer flow sanity check for TIFF

origin: upstream,
https://github.com/ImageMagick/ImageMagick/commit/f8877abac8e568b2f339cca70c2c3c1b6eaec288
bug-debian:

(cherry picked from commit f8877abac8e568b2f339cca70c2c3c1b6eaec288)

Bug#845203: strip-nondeterminism: Please support normalising NTFS timestamps in zip files

[Chris Lamb]

Package: strip-nondeterminism
Version: 0.028-1
Severity: wishlist

Hi,

(Forwarding message)

"""
If you do this twice:

  7z u -tzip $some_zip $some_path/$some_file
  strip-nondeterminism --timestamp $some_zip

and then diffoscope the two results I *expect* them to be
indentical, but I get this for each folder of $some_path:

│ @@ -68,15 +68,15 @@
│disk number on which file begins:   disk 1
│apparent file type: binary
│Unix file attributes (040755 octal):drwxr-xr-x
│MS-DOS file attributes (10 hex):dir 
│  
│The central-directory extra field contains:
│- A subfield with ID 0x000a (PKWARE Win32) and 32 data bytes.  The first
│ -20 are:   00 00 00 00 01 00 18 00 80 58 28 6d e8 43 d2 01 80 58 28 6d.
│ +20 are:   00 00 00 00 01 00 18 00 00 8a 4d b2 ea 43 d2 01 00 8a 4d b2.
│  
│There is no file comment.

and this for $some_file:

│There are an extra -36 bytes preceding this file.
│ @@ -51129,15 +51129,15 @@
│disk number on which file begins:   disk 1
│apparent file type: binary
│Unix file attributes (100644 octal):-rw-r--r--
│MS-DOS file attributes (00 hex):none
│  
│The central-directory extra field contains:
│- A subfield with ID 0x000a (PKWARE Win32) and 32 data bytes.  The first
│ -20 are:   00 00 00 00 01 00 18 00 80 58 28 6d e8 43 d2 01 80 58 28 6d.
│ +20 are:   00 00 00 00 01 00 18 00 00 8a 4d b2 ea 43 d2 01 00 8a 4d b2.
│  
│There is no file comment.

However, if I pass `-mtc=off` to 7z, all is fine. That
disables "NTFS timestamps for files: Modification time, Creation
time, Last access time". So it seems strip-nondeterminism is not
aware of this timestamp at the moment.
"""


Regards,

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

Bug#845082: numexpr FTBFS on ppc64el: test failures

[Breno Leitao]

On 11/20/2016 07:41 AM, Adrian Bunk wrote:
> 
> Lots of failures like:
> 

Yes. I just tried it here, and more than 40 tests failed.

It is usually off by 1, and I am wondering if we are being bite by a similar
issue I found on OpenJDK, where there are math inconsistency when using
optimization higher than O1.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386

Anyway, we are looking at this problem.

Bug#845204: CVE-2016-8678: heap-based buffer overflow in IsPixelMonochrome

[Bastien ROUCARIES]

Package: src:imagemagick
version: 8:6.9.6.2+dfsg-2
Severity: important
Tags: patch security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
control: found -1 8:6.7.7.10-5+deb7u7
control: found -1 8:6.8.9.9-5+deb8u5
control: tags -1 + fixed-upstream

Bug#845205: Incompatible with MariaDB 10.1

[Matt Li]

Package: exim4
Version: 4.88~RC4-2
X-Debbugs-CC: pkg-mysql-ma...@lists.alioth.debian.org

It appears that exim4 from exim4-daemon-heavy is now linked to 
libmariadbclient.so.18 which does not exist in MariaDB 10.1 - only 
libmysqlclient.so.18 is provided.

/usr/sbin/exim4: error while loading shared libraries: libmariadbclient.so.18: 
cannot open shared object file: No such file or directory

Manually symlinking to libmysqlclient.so.18 results in:

/usr/sbin/exim4: /usr/lib/libmariadbclient.so.18: version `libmariadbclient_18' 
not found (required by /usr/sbin/exim4)

This did not occur in the last testing build 4.87-3+b1.

Bug#818372: tex-common: Trigger fails on initial install of tex-common

[Norbert Preining]

Hi Jan,

> I have two debian testing machines where tex-common failed on first install
> (installing texlive-full) and dpkg--configure fixed it. See attached logs.

Hmm, thanks for the logs, but there are some things missing. Do you have
the *full* console log available?

I cannot reproduce this issue in unstable, and I am also surprised.

The only way this can happen is that the trigger for tex-common is
executed *before* the configure step, and for that I would like
to see the whole console output.

In my case I see a 
COnfiguring tex-common ...
...
...
Processing triggers for tex-common ...
and all works out nicely.

All the best

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#845199: dolibarr broken after upgrading from 3.5.8+dfsg1-1 to 4.0.2+dfsg4-1 and purging php5 packages

[Raphael Hertzog]

Hello,

On Mon, 21 Nov 2016, Jean-Marc wrote:
> On Sunday, November the 20th, I ran a dist-upgrade.
> It came with an upgrade of Dolibarr.
> Install went fine.
> I started Dolibarr and was re-directed to the update page.
> I ran all the steps, step by step, to update from 3.5 to 4.0 and everything 
> went fine.
> After the update, I did a quick tour of the application (clients, providers, 
> bank accounts, ..).
> And evrything was looking fine.
> 
> After that, I ran an autoremove cleaning up the following packages:
> libfpdi-php:amd64 (1.4.1-1), php-fpdf:amd64 (3:1.8.1.dfsg-2), 
> php7.0-mbstring:amd64 (7.0.12-1), php5-cli:amd64 (5.6.26+dfsg-1), 
> php5-readline:amd64 (5.6.26+dfsg-1), php5-json:amd64 (1.3.9-1), 
> libapache2-mod-php5:amd64 (5.6.26+dfsg-1), libfpdf-tpl-php:amd64 (1.2-2), 
> libonig4:amd64 (6.1.2-1), php5-curl:amd64 (5.6.26+dfsg-1), php5-ldap:amd64 
> (5.6.26+dfsg-1), php-mbstring:amd64 (1:7.0+46), php5:amd64 (5.6.26+dfsg-1), 
> libpoppler61:amd64 (0.44.0-3), php-mail-mime:amd64 (1.10.0-2), 
> libqdbm14:amd64 (1.8.78-6+b5)
> 
> And Dolibarr stops working.
> 
> I just code the PHP code instead of the application login page.

You seem to have libapache2-mod-php7.0 installed. But is the apache module
correctly enabled?

Please show the output of:
$ ls -lR /etc/apache2

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#827604: linux-image-4.6.0-1-amd64: Only mounts XFS drive as read-only

[David McMackins]

I haven't received any further notifications on this bug. This has
remained an issue for me for all Linux versions higher than 4.5.


Happy Hacking,

David E. McMackins II
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.gnu.org www.fsf.org

On 06/18/2016 11:51 AM, Ben Hutchings wrote:
> It looks like systemd is failing to remount David's filesystems as
> read/write on Linux 4.6, but not on 4.5.
> 
> Can you suggest how to get a log that would help diagnose this?
> 
> Ben.
> 
> On Sat, 2016-06-18 at 09:44 -0500, David McMackins wrote:
>> Package: src:linux
>> Version: 4.6.2-1
>> Severity: important
>>
>> Dear Maintainer,
>>
>> All of the releases of Linux 4.6 in Debian Sid so far have failed to
>> mount my primary disk in read-write mode. I have not tested my other XFS
>> disks, because failure to correctly mount all my OS partitions causes
>> numerous other daemons to fail to start (for instance, NetworkManager).
>>
>> I'm not really educated on managing the kernel, so I'm not sure what
>> logs I'm supposed to be providing here. It should be noted that I can
>> only look at historical logs (if they're even kept), because I can only
>> submit this report while falling back to Linux 4.5.
>>
>> Let me know what information I can provide to accelerate the resolution
>> of this big problem for me.
> 
> 

Bug#818113: python-paho-mqtt inclusion in Debian mosquitto package

[Maciej Delmanowski]

Hello,

Are there any plans to include the paho-mqtt Python library in the mosquitto
Debian package for Stretch? The #818113 bug is a few months old, but I cannot
find any entry about inclusion of paho-mqtt in the mosquitto source package
Changelog:

http://metadata.ftp-master.debian.org/changelogs/main/m/mosquitto/unstable_changelog

Best Regards,
Maciej Delmanowski

Bug#845206: CVE-2016-8677: memory allocate failure in AcquireQuantumPixels

[Bastien ROUCARIES]

Package: src:imagemagick
version: 8:6.9.6.2+dfsg-2
Severity: important
Tags: patch security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
control: found -1 8:6.7.7.10-5+deb7u7
control: found -1 8:6.8.9.9-5+deb8u5
control: tags -1 + fixed-upstream


https://blogs.gentoo.org/ago/2016/10/07/imagemagick-memory-allocate-failure-in-acquirequantumpixels-quantum-c/
Fixed by: 
https://github.com/ImageMagick/ImageMagick/commit/6e48aa92ff4e6e95424300ecd52a9ea453c19c60

Bug#845109: RM: ifeffit [arm64 armel powerpc] -- ANAIS; not built for NMU

[Stuart Prescott]

Control: tags -1 moreinfo

The key piece of missing information seems to be that one of the build-deps is 
pgplot5 which is in non-free and that non-free packages aren't available to 
the contrib buildds.

> See http://bugs.debian.org/690282 -- the buildds cannot build packages like
> ifeffit. It'd be great if that were solved at the infrastructure end but I
> can't see that happening for stretch any more than for wheezy or jessie.

To finish this off, it is the removal of the binary packages for which we have 
no hardware to build them that is requested:

ifeffit python-ifeffit libifeffit-perl [arm64 armel powerpc]

With that (and a discussion on IRC), ScottK's concerns are resolved.

cheers
Stuart

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

Bug#843898: Something to try

[Sebastian P. Luque]

On Sun, 20 Nov 2016 19:57:53 -0600,
Sebastian P. Luque  wrote:

> On Sun, 20 Nov 2016 21:01:08 +,
> Tobias Hansen  wrote:

> [...]

>>> $ ls -alh ~/.local/lib/python2.7/site-packages/backports/ total 12K
>>> drwxr-xr-x 3 sluque sluque 4.0K Oct 30 16:16 .  drwx-- 20 sluque
>>> sluque 4.0K Oct 30 16:18 ..  drwxr-xr-x 2 sluque sluque 4.0K Oct 30
>>> 16:16 configparser

>> What happens if you rename that for a moment? Does it fix the
>> problem?

> No; same result.

I just tried a different approach, and it's revealing:

$ python -s
Python 2.7.12+ (default, Sep  1 2016, 20:27:38) 
[GCC 6.2.0 20160927] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from backports.shutil_get_terminal_size import get_terminal_size

Why on Earth did moving ~/.local/lib/python2.7/site-packages/backports
not have the same effect is beyond me.

-- 
Seb

Bug#845205: [debian-mysql] Bug#845205: Incompatible with MariaDB 10.1

[Robie Basak]

On Mon, Nov 21, 2016 at 11:48:56PM +1100, Matt Li wrote:
> It appears that exim4 from exim4-daemon-heavy is now linked to 
> libmariadbclient.so.18 which does not exist in MariaDB 10.1 - only 
> libmysqlclient.so.18 is provided.
> 

Where are you getting MariaDB 10.1 from? Debian currently only ships
MariaDB 10.0, right?

Bug#845205: [debian-mysql] Bug#845205: Incompatible with MariaDB 10.1

[Rene Engelhard]

[ Not a exim maintainer ]

Hi,

On Mon, Nov 21, 2016 at 11:48:56PM +1100, Matt Li wrote:
> Package: exim4
> Version: 4.88~RC4-2
> X-Debbugs-CC: pkg-mysql-ma...@lists.alioth.debian.org
> 
> It appears that exim4 from exim4-daemon-heavy is now linked to 
> libmariadbclient.so.18 which does not exist in MariaDB 10.1 - only 
> libmysqlclient.so.18 is provided.

And? MariaDB in Debian is 10.0 *and* it has a libmariadbclient18 package
which exim4-daemon-heavy depends on. So where's the bug? Did you hack the
depdencdies somehow?

MariaDB 10.1 isn't in Debian and if it was and it changed names one would
need a rebuild.

> /usr/sbin/exim4: error while loading shared libraries: 
> libmariadbclient.so.18: cannot open shared object file: No such file or 
> directory

As said, exim4-daemon-heavy depends on libmariadbclient18, so how did you
get into this?

> Manually symlinking to libmysqlclient.so.18 results in:
> 
> /usr/sbin/exim4: /usr/lib/libmariadbclient.so.18: version 
> `libmariadbclient_18' not found (required by /usr/sbin/exim4)

Of course, symlinking is always a a bad idea.

> This did not occur in the last testing build 4.87-3+b1.

Of course, because it was built against libmysqclient, not libmariadbclient:

exim4 (4.88~RC1-1) experimental; urgency=low
[...]
  * B-d on default-libmysqlclient-dev.
[...]

 -- Andreas Metzler   Sun, 25 Sep 2016 15:44:00 +0200

Still not a bug. (default-libmysqlclient-dev) is libmariadbclient
(see https://packages.debian.org/stretch/default-libmysqlclient-dev)

Regards,

Rene

Bug#647404: Help Desk!!

[Lothrop, Virginia M.]

Your password Will Expire In TWO {2} Days Current Staff Should

Log On To IT By CLICK HERE 
 
 
 To Validate Your E-mail.


Regards,
IT Service Provider Team.

Bug#843898: Something to try

[Tobias Hansen]

On 11/21/2016 01:03 PM, Sebastian P. Luque wrote:
> On Sun, 20 Nov 2016 19:57:53 -0600,
> Sebastian P. Luque  wrote:
> 
>> On Sun, 20 Nov 2016 21:01:08 +,
>> Tobias Hansen  wrote:
> 
>> [...]
> 
 $ ls -alh ~/.local/lib/python2.7/site-packages/backports/ total 12K
 drwxr-xr-x 3 sluque sluque 4.0K Oct 30 16:16 .  drwx-- 20 sluque
 sluque 4.0K Oct 30 16:18 ..  drwxr-xr-x 2 sluque sluque 4.0K Oct 30
 16:16 configparser
> 
>>> What happens if you rename that for a moment? Does it fix the
>>> problem?
> 
>> No; same result.
> 
> I just tried a different approach, and it's revealing:
> 
> $ python -s
> Python 2.7.12+ (default, Sep  1 2016, 20:27:38) 
> [GCC 6.2.0 20160927] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 from backports.shutil_get_terminal_size import get_terminal_size
> 
> Why on Earth did moving ~/.local/lib/python2.7/site-packages/backports
> not have the same effect is beyond me.
> 

So I guess we can close the bug. The problem is that different backport
packages can conflict with each other. The only thing we could think
about is if python-backports-shutil-get-terminal-size could be changed
to be more robust against that. Looks like a task for upstream.

Best,
Tobias

Bug#746005: Still FTBFS with lilypond 2.19-50

[Dr. Tobias Quathamer]

Am 16.11.2016 um 10:44 schrieb Antonio Ospite:

Hi Tobias,

I've been talking with Don and some lilypond devs, sorry for not keeping
you in the loop I didn't realize you were one of the maintainers, here
is my updated notes:
https://ao2.it/tmp/lilypond-guile2/NOTES_2016-11-10.txt

The eight patches at https://ao2.it/tmp/lilypond-guile2/ should fix the
FTBFS, I guess Don hasn't had the chance to add them to the debian
package yet, let me know how they work out.

However, even if the build succeeds there are still some encoding
issues:
http://lists.gnu.org/archive/html/lilypond-devel/2016-11/msg00076.html

The full thread starts at:
http://lists.gnu.org/archive/html/lilypond-devel/2016-11/msg00030.html


Hi Antonio,

thanks a lot for your work on this! I've read the thread and it seems 
that there's a small possibility to get lilypond back into Debian. At 
least the build proceeds much further with your patches.


Unfortunately, the build still fails (with current upstream 2.19.51). 
I'd like to try again with your latest set of patches, which you've just 
mentioned on lilypond-devel. Could you provide them on your webpage?


Regards,
Tobias




signature.asc
Description: OpenPGP digital signature

Bug#845206: CVE-2016-8677: memory allocate failure in AcquireQuantumPixels

[Salvatore Bonaccorso]

Hi,

On Mon, Nov 21, 2016 at 01:51:52PM +0100, Bastien ROUCARIES wrote:
> Package: src:imagemagick
> version: 8:6.9.6.2+dfsg-2
> Severity: important
> Tags: patch security
> X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
> control: found -1 8:6.7.7.10-5+deb7u7
> control: found -1 8:6.8.9.9-5+deb8u5
> control: tags -1 + fixed-upstream
> 
> 
> https://blogs.gentoo.org/ago/2016/10/07/imagemagick-memory-allocate-failure-in-acquirequantumpixels-quantum-c/
> Fixed by: 
> https://github.com/ImageMagick/ImageMagick/commit/6e48aa92ff4e6e95424300ecd52a9ea453c19c60

Isn't this fixed already in 8:6.9.6.2+dfsg-1? What do I miss?

Regards,
Salvatore

Bug#842352: geoclue-2.0: geoclue segfault very frequently

[Laurent Bigonville]

On Sat, 29 Oct 2016 20:39:20 +0530 Ritesh Raj Sarraf  wrote:

> And here's the stacktrace from coredumpctl

I cannot reproduce this on my machine.

Could you please install the package with the debug symbols of glib 
(libglib2.0-0-dbg) and geoclue-2.0 package (geoclue-2.0-dbgsym) and post 
a new backtrace?


Thanks

Laurent Bigonville

Bug#845207: CMST and ConnMan stopped working after last sid update

[George Vasiliou (GMAIL)]

Package: cmst

Hello,
Under Debian 8 Sid 32bits with LXDE i updated yesterday my system.
On the next reboot i got the following error by cmst:

CMST: Unable to create an interface to connman on the system bus.
CMST will not be able to communicate with connman.

As a result , my wifi was dead and not able to get connected to my home
wlan (i'm using rtl8723se on laptop).

Looking at apt log, a lot of libqt5 libs in which cmst depends on have been
upgraded yesterday.

It is not clear to me if i should file this bug as a cmst bug or as a
libqt5 bug.

In any case i didn't try to operate connman by command line to verify if i
can establish a wifi connection.
I noticed though that packages libgnutls30 and libxtables11 which connman
depends on, have also been upgraded yesterday.

As a workaround i succeed to connect in my wifi network by purging connman
(but not cmst) and editing my /etc/network/interfaces file according to
Debian Wiki Command Line Section (https://wiki.debian.org/WiFi/HowToUse) .

Maybe i should reinstall connman and use a different tool than cmst or
manage connman by command line to verify if connman works ok - not tried
yet.

Regards
George V.

Bug#833865: jessie-pu: package youtube-dl/2014.08.05-1+deb8u1

[Holger Levsen]

retitle 840839 youtube-dl: please package new upstream version 2016.11.18
thanks

On Sun, Nov 20, 2016 at 02:23:42PM -0500, Antoine Beaupré wrote:
> The thing is, at this point I doubt anybody can even *use* the version
> in jessie: youtube doesn't work and while there are other sites
> supported, I think it's safe to assume that's what most people use it
> for.

while this is true and somewhat migated by youtube-dl in jessie-bpo it's
now also the case that sometimes downloading videos from youtune fails
with 2016.06.25-2~ :-/


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#845207: CMST and ConnMan stopped working after last sid update

[George Vasiliou (GMAIL)]

Sorry, i forgot to attach the apt log file of yesterday to have a look of
all the files upgraded.
I have to point out that before yesterday evening upgrade, everything was
working ok with cmst and connman.
Start-Date: 2016-11-21  00:38:07
Commandline: apt-get upgrade
Upgrade: 
libreoffice-wiki-publisher:i386 (1.2.0+LibO5.2.3~rc3-1, 1.2.0+LibO5.2.3-2), 
libportmidi0:i386 (1:184-2.2, 1:217-4), 
libreoffice-math:i386 (1:5.2.3~rc3-1+b1, 1:5.2.3-2), 
libmpx2:i386 (6.2.0-13, 6.2.1-4), 
exim4-base:i386 (4.88~RC4-2, 4.88~RC5-1), 
libgcj17:i386 (6.2.0-13, 6.2.1-4), 
iso-codes:i386 (3.70-1, 3.71-1), 
xserver-xorg-input-synaptics:i386 (1.8.3-2, 1.9.0-1), 
libreoffice-script-provider-js:i386 (1:5.2.3~rc3-1, 1:5.2.3-2), 
xserver-xorg-video-r128:i386 (6.10.1-1, 6.10.1-2), 
libreoffice-report-builder-bin:i386 (1:5.2.3~rc3-1+b1, 1:5.2.3-2), 
libservlet3.1-java:i386 (8.0.38-2, 8.0.39-1), 
icedove:i386 (1:45.4.0-1, 1:45.5.0-1), 
libseccomp2:i386 (2.3.1-2, 2.3.1-2.1), 
libao4:i386 (1.1.0-3, 1.2.2-1), 
libclutter-1.0-0:i386 (1.26.0+dfsg-1, 1.26.0+dfsg-2), 
libreoffice-sdbc-postgresql:i386 (1:5.2.3~rc3-1+b1, 1:5.2.3-2), 
libgroupsock8:i386 (2016.11.06-1, 2016.11.17-1), 
iptables:i386 (1.6.0-4, 1.6.0+snapshot20161117-1), 
libdrm-nouveau2:i386 (2.4.71-1, 2.4.73-1), 
xserver-xorg-video-amdgpu:i386 (1.1.2-1, 1.2.0-1), 
linux-libc-dev:i386 (4.8.5-1, 4.8.7-1), 
libspeechd2:i386 (0.8.5-3, 0.8.5-4), 
oxygen-icon-theme:i386 (5:5.27.0-1, 5:5.28.0-1), 
libdiscid0:i386 (0.6.1-5, 0.6.1-6), 
qt5-gtk-platformtheme:i386 (5.7.1~20161021+dfsg-5, 5.7.1~20161021+dfsg-6), 
gir1.2-clutter-1.0:i386 (1.26.0+dfsg-1, 1.26.0+dfsg-2), 
lxpanel-data:i386 (0.8.2-1, 0.9.0-1), 
libproxy1v5:i386 (0.4.13-1, 0.4.13-1.1), 
va-driver-all:i386 (1.7.3-1, 1.7.3-2), 
libgnutls-openssl27:i386 (3.5.6-2, 3.5.6-7), 
libreoffice-java-common:i386 (1:5.2.3~rc3-1, 1:5.2.3-2), 
p7zip:i386 (16.02+dfsg-1, 16.02+dfsg-2), 
git-man:i386 (1:2.10.2-2, 1:2.10.2-3), 
libsystemd0:i386 (232-3, 232-5), 
libvisual-0.4-plugins:i386 (1:0.4.0+dfsg1-9, 1:0.4.0+dfsg1-10), 
libreoffice-base:i386 (1:5.2.3~rc3-1+b1, 1:5.2.3-2), 
libzmq5:i386 (4.2.0-1, 4.2.0-2), 
gstreamer1.0-plugins-good:i386 (1.10.0-1, 1.10.1-1), 
libreoffice-core:i386 (1:5.2.3~rc3-1+b1, 1:5.2.3-2), 
cpp-6:i386 (6.2.0-13, 6.2.1-4), 
libpsl5:i386 (0.14.0-1, 0.15.0-1), 
libofa0:i386 (0.9.3-12, 0.9.3-13), 
libgda-5.0-common:i386 (5.2.4-2, 5.2.4-3), 
binutils:i386 (2.27.51.20161108-1, 2.27.51.20161118-2), 
libgpg-error0:i386 (1.24-2, 1.25-1), 
xserver-xorg-video-trident:i386 (1:1.3.7-1+b2, 1:1.3.7-2), 
libitm1:i386 (6.2.0-13, 6.2.1-4), 
lightdm-gtk-greeter:i386 (2.0.1-2, 2.0.2-1), 
at-spi2-core:i386 (2.22.0-3, 2.22.0-4), 
gdebi-core:i386 (0.9.5.7, 0.9.5.7+nmu1), 
libqt5dbus5:i386 (5.7.1~20161021+dfsg-5, 5.7.1~20161021+dfsg-6), 
xserver-xorg-input-libinput:i386 (0.20.0-1, 0.22.0-1), 
git:i386 (1:2.10.2-2, 1:2.10.2-3), 
exim4-daemon-light:i386 (4.88~RC4-2, 4.88~RC5-1), 
libqt5widgets5:i386 (5.7.1~20161021+dfsg-5, 5.7.1~20161021+dfsg-6), 
libfbclient2:i386 (3.0.1.32609.ds4-9, 3.0.1.32609.ds4-10), 
gstreamer1.0-plugins-bad:i386 (1.10.0-1, 1.10.1-1), 
libip6tc0:i386 (1.6.0-4, 1.6.0+snapshot20161117-1), 
udev:i386 (232-3, 232-5), 
libcilkrts5:i386 (6.2.0-13, 6.2.1-4), 
gstreamer1.0-plugins-base:i386 (1.10.0-1, 1.10.1-1), 
xfce4-panel:i386 (4.12.1-1, 4.12.1-2), 
libasan3:i386 (6.2.0-13, 6.2.1-4), 
libquadmath0:i386 (6.2.0-13, 6.2.1-4), 
libreoffice-librelogo:i386 (1:5.2.3~rc3-1, 1:5.2.3-2), 
libassuan0:i386 (2.4.3-1, 2.4.3-2), 
gcc-6-base:i386 (6.2.0-13, 6.2.1-4), 
gdebi:i386 (0.9.5.7, 0.9.5.7+nmu1), 
xserver-xorg-video-savage:i386 (1:2.3.8-1+b1, 1:2.3.8-2), 
python3-uno:i386 (1:5.2.3~rc3-1+b1, 1:5.2.3-2), 
debianutils:i386 (4.8, 4.8.1), 
libudev1:i386 (232-3, 232-5), 
rsyslog:i386 (8.22.0-2+b1, 8.23.0-1), 
libgcc1:i386 (1:6.2.0-13, 1:6.2.1-4), 
libreoffice-script-provider-python:i386 (1:5.2.3~rc3-1, 1:5.2.3-2), 
libreoffice-style-galaxy:i386 (1:5.2.3~rc3-1, 1:5.2.3-2), 
libreoffice-base-core:i386 (1:5.2.3~rc3-1+b1, 1:5.2.3-2), 
libiptc0:i386 (1.6.0-4, 1.6.0+snapshot20161117-1), 
libdrm-amdgpu1:i386 (2.4.71-1, 2.4.73-1), 
libinput-bin:i386 (1.5.0-1, 1.5.1-1), 
libreoffice-ogltrans:i386 (1:5.2.3~rc3-1+b1, 1:5.2.3-2), 
dpkg:i386 (1.18.14, 1.18.15), 
libtiff5:i386 (4.0.6-3, 4.0.7-1), 
libreoffice-impress:i386 (1:5.2.3~rc3-1+b1, 1:5.2.3-2), 
libqt5gui5:i386 (5.7.1~20161021+dfsg-5, 5.7.1~20161021+dfsg-6), 
libva1:i386 (1.7.3-1, 1.7.3-2), 
libao-common:i386 (1.1.0-3, 1.2.2-1), 
python3-speechd:i386 (0.8.5-3, 0.8.5-4), 
libgcc-6-dev:i386 (6.2.0-13, 6.2.1-4), 
p7zip-full:i386 (16.02+dfsg-1, 16.02+dfsg-2), 
libubsan0:i386 (6.2.0-13, 6.2.1-4), 
iceweasel:i386 (45.4.0esr-2, 45.5.0esr-1), 
g++-6:i386 (6.2.0-13, 6.2.1-4), 
exim4-config:i386 (4.88~RC4-2, 4.88~RC5-1), 
libatspi2.0-0:i386 (2.22.0-3, 2.22.0-4), 
libmplex2-2.1-0:i386 (1:2.1.0+debian-4+b1, 1:2.1.0+debian-5), 
libzvbi0:i386 (0.2.35-12, 0.2.35-13), 
libdvbpsi10:i386 (1.3.0-4, 1.3.0-5), 
libgfortran3:i386 (6.2.0-13, 6.2.1-4), 
libgda-5.0-4:i386 (5.2.4-2+b1, 5.2.4-3), 
libproxy-tools:i386 (0.4.1

Bug#845209: Switch to clang-3.9

[Yuri D'Elia]

Package: clang-defaults
Severity: wishlist

Clang 3.9 is the latest release of clang, which is already available on
unstable. Is there any reason to keep depending on 3.8 as the default?

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

Kernel: Linux 4.8.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)

Bug#840741: http-icons: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: http-icons
> Version: 0~20041010-1
> Tags: patch

There hasn't seem to be any update on this bug in 38 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#792854: isc-dhcp-client: Dhclient fails to set hostname

[Иван Прокудин]

Hello!

I've also faced the bug. And it's also mentioned here: 
http://blog.schlomo.schapiro.org/2013/11/setting-hostname-from-dhcp-in-debian.html
 .

It's caused incorrect if in file /sbin/dhclient-script

I've made a patch that fixed the issue for me:

--- /root/dhclient-script   2016-11-20 07:05:32.145715966 +0300
+++ /sbin/dhclient-script   2016-11-20 07:31:06.581734208 +0300
@@ -98,10 +98,9 @@
 if [ -z "$current_hostname" ] ||
[ "$current_hostname" = '(none)' ] ||
[ "$current_hostname" = 'localhost' ] ||
-   [ "$current_hostname" = "$old_host_name" ]; then
-   if [ "$new_host_name" != "$old_host_name" ]; then
-   hostname "$new_host_name"
-   fi
+   ([ "$current_hostname" = "$old_host_name" ] &&
+   [ "$new_host_name" != "$old_host_name" ]); then
+   hostname "$new_host_name"
 fi
 fi
 }

Will be glad if debian includes it in a package resolving the issue.

With best regards, Ivan.


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

Bug#845161: udev: "mount: invalid option --" when busybox is not installed

[Luca Boccassi]

On Mon, 2016-11-21 at 11:01 +, Simon McVittie wrote:
> On Mon, 21 Nov 2016 at 10:16:50 +, Luca Boccassi wrote:
> > The context is a squashfs and liveboot/build based ISO.
> ...
> > I don't pick the mount utility in any of my scripts or configs, so I do
> > not know when or where the change happened, could have been anytime
> > since Jessie was released. But I am 100% sure that it's the util-linux
> > one being used in this case, as proved by the fact that --move fixed the
> > boot process.
> 
> I believe this was considered to be a bug in live-boot-initramfs-tools
> (and its fork open-infrastructure-system-boot): l-b-i-t and o-i-s-b added
> /root/bin to $PATH, causing the to-be-booted system's util-linux /bin/mount
> to be used instead of the initramfs's busybox or klibc mount.
> A kernel and initramfs-tools maintainer stated in
>  that this
> is not supportable - I believe his position was that every command must
> either run in the initramfs with $PATH entirely from the initramfs,
> or run chrooted into the to-be-booted system with $PATH entirely from
> the to-be-booted system, but never a mixture of the two.
> 
> This was fixed as #823069 for l-b-i-t and as #832752 for o-i-s-b. Both
> bugs were treated as having 'critical' severity.
> 
> > Of course as you all pointed out this won't work with klibc mount and it
> > needs to be fixed. But please if possible don't revert, as it will break
> > again virtual filesystem based images.
> 
> My understanding is that if you build your images
> with live-boot-initramfs-tools (>= 1:20160511) or with
> open-infrastructure-system-boot (>= 20160601-1), both of which are
> available in testing, then reverting the udev change altogether
> (consistently using mount -o move everywhere) should be harmless.

And you are indeed right! I had the previous version. I just checked
with the latest and it works with the -o mount on the squashfs image.

I do think it's nice to support all mount utilities available, but given
it was a bug to use the util-linux one and there is a workaround
personally I don't mind if the udev script is reverted to the previous
behaviour.

Thanks for pointing out my mistake, and sorry again for the noise.

Kind regards,
Luca Boccassi


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

Bug#845206: [Pkg-gmagick-im-team] Bug#845206: CVE-2016-8677: memory allocate failure in AcquireQuantumPixels

[Bastien ROUCARIES]

control: notfound -1 8:6.9.6.2+dfsg-1

On Mon, Nov 21, 2016 at 2:19 PM, Salvatore Bonaccorso  wrote:
> Hi,
>
> On Mon, Nov 21, 2016 at 01:51:52PM +0100, Bastien ROUCARIES wrote:
>> Package: src:imagemagick
>> version: 8:6.9.6.2+dfsg-2
>> Severity: important
>> Tags: patch security
>> X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
>> control: found -1 8:6.7.7.10-5+deb7u7
>> control: found -1 8:6.8.9.9-5+deb8u5
>> control: tags -1 + fixed-upstream
>>
>>
>> https://blogs.gentoo.org/ago/2016/10/07/imagemagick-memory-allocate-failure-in-acquirequantumpixels-quantum-c/
>> Fixed by: 
>> https://github.com/ImageMagick/ImageMagick/commit/6e48aa92ff4e6e95424300ecd52a9ea453c19c60
>
> Isn't this fixed already in 8:6.9.6.2+dfsg-1? What do I miss?
>
> Regards,
> Salvatore
>
> ___
> Pkg-gmagick-im-team mailing list
> pkg-gmagick-im-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team

Bug#845203: Example output

[u]

FWIW, one can see the contents of those header fields as follows (only
visible on directories as it looks like):

@unzip -ZTv $some_zip@

Example output:

entral directory entry #1:
---

  chrome/

  offset of local header from start of archive:   0
  (h) bytes
  file system or operating system of origin:  Unix
  version of encoding software:   6.3
  minimum file system compatibility required: Unix
  minimum software version required to extract:   2.0
  compression method: none (stored)
  file security status:   not encrypted
  extended local header:  no
  file last modified on (DOS date/time):  2016 Nov 21 12:48:18
  32-bit CRC value (hex): 
  compressed size:0 bytes
  uncompressed size:  0 bytes
  length of filename: 7 characters
  length of extra field:  0 bytes
  length of file comment: 0 characters
  disk number on which file begins:   disk 1
  apparent file type: binary
  Unix file attributes (040700 octal):drwx--
  MS-DOS file attributes (10 hex):dir

  There is a local extra field with ID 0x5855 (old Info-ZIP Unix/OS2/NT) and
  8 data bytes (GMT modification/access times only).

  There is no file comment.

Bug#845210: blhc: FTBFS: Failed 1/1 test programs. 54/216 subtests failed.

[Chris Lamb]

Source: blhc
Version: 0.07-0.1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

blhc fails to build from source in unstable/amd64:

  […]

  # checking './t/logs/arch-avr32'...
  # '
  # expected: 'checking './t/logs/bad-ldflags'...
  # LDFLAGS missing (-Wl,-z,relro): gcc -o test test-a.o test-b.o test-c.o 
-ltest
  # LDFLAGS missing (-Wl,-z,relro): gcc -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -o test test-a.o test-b.o 
test-c.o
  # LDFLAGS missing (-Wl,-z,relro): gcc -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -o test test-a.o test-b.o 
test-c.o test.h
  # checking './t/logs/empty'...
  # No compiler commands!
  # checking './t/logs/arch-avr32'...
  # CFLAGS missing (-fstack-protector-strong): gcc -D_FORTIFY_SOURCE=2 -g -O2 
-Wformat -Wformat-security -Werror=format-security -Wall -c test.c
  # checking './t/logs/debian-hardening-wrapper'...
  # HARDENING WRAPPER: no checks possible, aborting
  # '
  
  #   Failed test './t/logs/arch-i386 ./t/logs/arch-amd64 ./t/logs/arch-avr32 
./t/logs/ignore-flag --ignore-arch-flag i386:-fstack-protector-strong 
--ignore-arch-flag mipsel:-Werror=format-security (exit code)'
  #   at t/tests.t line 40.
  #  got: '255'
  # expected: '8'
  
  #   Failed test './t/logs/arch-i386 ./t/logs/arch-amd64 ./t/logs/arch-avr32 
./t/logs/ignore-flag --ignore-arch-flag i386:-fstack-protector-strong 
--ignore-arch-flag mipsel:-Werror=format-security (output)'
  #   at t/tests.t line 45.
  #  got: 'Undefined subroutine &Dpkg::Arch::debarch_to_debtriplet 
called at ./bin/blhc line 1032.
  # checking './t/logs/arch-i386'...
  # '
  # expected: 'checking './t/logs/arch-i386'...
  # LDFLAGS missing (-pie): gcc -fPIE -Wl,-z,relro -Wl,-z,now -o test test.o
  # checking './t/logs/arch-amd64'...
  # CFLAGS missing (-fstack-protector-strong): gcc -D_FORTIFY_SOURCE=2 -g -O2 
-fPIE -Wformat -Wformat-security -Werror=format-security -Wall -c test.c
  # LDFLAGS missing (-pie): gcc -fPIE -Wl,-z,relro -Wl,-z,now -o test test.o
  # checking './t/logs/arch-avr32'...
  # CFLAGS missing (-fstack-protector-strong): gcc -D_FORTIFY_SOURCE=2 -g -O2 
-Wformat -Wformat-security -Werror=format-security -Wall -c test.c
  # checking './t/logs/ignore-flag'...
  # CFLAGS missing (-g): gcc-O2 -fstack-protector-strong -Wformat 
-Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -c test-b.c
  # CFLAGS missing (-O2): gcc -g -fstack-protector-strong -Wformat 
-Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -c test-c.c
  # '
  
  #   Failed test './t/logs/arch-i386 ./t/logs/arch-amd64 ./t/logs/arch-avr32 
./t/logs/ignore-line --ignore-arch-line "i386:gcc .+ -fPIE .+" 
--ignore-arch-line "mipsel:gcc .+ -Wl,-z,relro -Wl,-z,now .+" (exit code)'
  #   at t/tests.t line 40.
  #  got: '255'
  # expected: '8'
  
  #   Failed test './t/logs/arch-i386 ./t/logs/arch-amd64 ./t/logs/arch-avr32 
./t/logs/ignore-line --ignore-arch-line "i386:gcc .+ -fPIE .+" 
--ignore-arch-line "mipsel:gcc .+ -Wl,-z,relro -Wl,-z,now .+" (output)'
  #   at t/tests.t line 45.
  #  got: 'Undefined subroutine &Dpkg::Arch::debarch_to_debtriplet 
called at ./bin/blhc line 1032.
  # checking './t/logs/arch-i386'...
  # '
  # expected: 'checking './t/logs/arch-i386'...
  # LDFLAGS missing (-pie): gcc -fPIE -Wl,-z,relro -Wl,-z,now -o test test.o
  # checking './t/logs/arch-amd64'...
  # CFLAGS missing (-fstack-protector-strong): gcc -D_FORTIFY_SOURCE=2 -g -O2 
-fPIE -Wformat -Wformat-security -Werror=format-security -Wall -c test.c
  # LDFLAGS missing (-pie): gcc -fPIE -Wl,-z,relro -Wl,-z,now -o test test.o
  # checking './t/logs/arch-avr32'...
  # CFLAGS missing (-fstack-protector-strong): gcc -D_FORTIFY_SOURCE=2 -g -O2 
-Wformat -Wformat-security -Werror=format-security -Wall -c test.c
  # checking './t/logs/ignore-line'...
  # CFLAGS missing (-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security): ./prepare-script gcc test-a.c test-b.c test-c.c
  # CPPFLAGS missing (-D_FORTIFY_SOURCE=2): ./prepare-script gcc test-a.c 
test-b.c test-c.c
  # LDFLAGS missing (-Wl,-z,relro): ./prepare-script gcc test-a.c test-b.c 
test-c.c
  # CFLAGS missing (-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security): ./prepare-script gcc test-a.c
  # CPPFLAGS missing (-D_FORTIFY_SOURCE=2): ./prepare-script gcc test-a.c
  # LDFLAGS missing (-Wl,-z,relro): ./prepare-script gcc test-a.c
  # CFLAGS missing (-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security): ./prepare-script gcc test-b.c
  # CPPFLAGS missing (-D_FORTIFY_SOURCE=2): ./prepare-script gcc test-b.c
  # LDFLAGS missing (-Wl,-z,relro): ./prepare-script gcc test-b.c
  # CFLAGS missing (-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security): ./pr

Bug#845211: link-grammar: FTBFS: /usr/bin/ld: cannot find -lncurses

[Chris Lamb]

Source: link-grammar
Version: 5.3.11-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

link-grammar fails to build from source in unstable/amd64:

  […]

  gcc -DPACKAGE_NAME=\"link-grammar\" -DPACKAGE_TARNAME=\"link-grammar\" 
-DPACKAGE_VERSION=\"5.3.11\" -DPACKAGE_STRING=\"link-grammar\ 5.3.11\" 
-DPACKAGE_BUGREPORT=\"link-gram...@googlegroups.com\" -DPACKAGE_URL=\"\" 
-DPACKAGE=\"link-grammar\" -DVERSION=\"5.3.11\" -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSTDC_HEADERS=1 
-DHAVE_STRNDUP=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_FORK=1 -DHAVE_VFORK=1 
-DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_PRCTL=1 
-DHAVE_LOCALE_T_IN_LOCALE_H=1 -DHAVE_MKLIT=1 -DHAVE_LIBSTDC__=1 
-DHAVE_HUNSPELL=1 -DHUNSPELL_DICT_DIR=\"/usr/share/myspell/dicts\" 
-DHAVE_EDITLINE=1 -DHAVE_WIDECHAR_EDITLINE=1 -DHAVE_REGEXEC=1 
-DHAVE_PYTHON=\"2.7\" -DHAVE_MAYBE_UNINITIALIZED=1 -DVERSION=\"5.3.11\" 
-DDICTIONARY_DIR=\"/usr/share/link-grammar\" -I.  -I.. -I.. -Wstrict-prototypes 
-Wmissing-prototypes -Wnested-externs -Wold-style-definition  -Wall -Wextra 
-Wsign-compare -Werror-implicit-function-declaration -Wpointer-arith 
-Wwrite-strings -Wmissing-declarations -Wpacked -Wswitch-enum 
-Wmissing-format-attribute -Wstrict-aliasing -Winit-self 
-Wno-missing-field-initializers -Wno-unused-parameter -Wno-attributes 
-Wno-long-long -Winline -I/usr/include/hunspell -I/usr/include/editline 
-Wdate-time -D_FORTIFY_SOURCE=2 -DUSE_PTHREADS=1 -DUSE_SAT_SOLVER=1  -g -O2 
-fdebug-prefix-map=«BUILDDIR»=. -fstack-protector-strong -Wformat 
-Werror=format-security -O3 -std=c11 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE 
-D_DEFAULT_SOURCE -c -o parser-utilities.o parser-utilities.c
  /bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=«BUILDDIR»=. -fstack-protector-strong -Wformat 
-Werror=format-security -O3 -std=c11 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE 
-D_DEFAULT_SOURCE -fno-strict-aliasing -Wl,-z,relro -Wl,-z,now -Wl,-O1 
-Wl,--as-needed -o link-parser link-parser.o command-line.o lg_readline.o 
parser-utilities.o ../link-grammar/liblink-grammar.la -ledit -lncurses -lbsd   
-lminisat  -lstdc++ 
  libtool: link: gcc -g -O2 -fdebug-prefix-map=«BUILDDIR»=. 
-fstack-protector-strong -Wformat -Werror=format-security -O3 -std=c11 
-D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -D_DEFAULT_SOURCE 
-fno-strict-aliasing -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-O1 -o 
.libs/link-parser link-parser.o command-line.o lg_readline.o parser-utilities.o 
 -Wl,--as-needed ../link-grammar/.libs/liblink-grammar.so -ledit -lncurses 
-lbsd -lminisat -lstdc++
  /usr/bin/ld: cannot find -lncurses
  collect2: error: ld returned 1 exit status
  Makefile:469: recipe for target 'link-parser' failed
  make[2]: *** [link-parser] Error 1
  make[2]: Leaving directory '«BUILDDIR»/link-parser'
  Makefile:539: recipe for target 'all-recursive' failed
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory '«BUILDDIR»'
  dh_auto_build: make -j9 returned exit code 2
  debian/rules:7: recipe for target 'build' failed
  make: *** [build] Error 2

  […]

The full build log is attached.


Regards,

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


link-grammar.5.3.11-2.unstable.amd64.log.txt.gz
Description: Binary data

Bug#845199: dolibarr broken after upgrading from 3.5.8+dfsg1-1 to 4.0.2+dfsg4-1 and purging php5 packages

[Raphael Hertzog]

On Mon, 21 Nov 2016, Jean-Marc wrote:
> > Please show the output of:
> > $ ls -lR /etc/apache2
> 
> To not make the report too big and unreadable, I do not copy the output.
> But I suppose you want to know if /etc/apache2/mods-enabled contains a 
> symlink to activate php7 module.
> 
> I found this in /etc/apache2/mods-available:
> [...]
> -rw-r--r-- 1 root root  867 oct 15 17:11 php7.0.conf
> -rw-r--r-- 1 root root  102 oct 15 17:11 php7.0.load
> 
> But no link related to them into /etc/apache2/mods-enabled.
> 
> Something missing in the php7 install.
> Or something removing this in php5 purge.
> 
> Do you know the right way to activate php7 ?

Run "a2enmod php7.0"

But this should be done automatically by the installation of
libapache2-mod-php7.0.

I guess that it was not done because php5 was still enabled and the two
are conflicting. But when php5 got removed, nothing enabled php7.0...

I'm putting PHP maintainers in copy. Dear PHP maintainers, is there no
mechanism that could be put in place for this? Given the new versioning
scheme, this problem is likely to become more frequent...

Feel free to reassign this bug to track a possible solution to this
problem. It might require to modify packages in jessie to make sure
that the package removal activates something (via trigger or some other
hook mechanism).

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#844579: console-setup: CyrAsia font missing Kazakh letter

[Anton Zinoviev]

On Sun, Nov 20, 2016 at 12:14:33AM +0100, Cyril Brulebois wrote:
> 
> I'm not sure what's involved to add support for those. Maybe it's
> sufficient to add two lines with the codepoint to the file you
> mentioned?

Yes, it is sufficient, provided there is enough space in the font (only 256 
glyphs can be included).

On Mon, Nov 21, 2016 at 10:32:46AM +0500, Baurzhan Muftakhidinov wrote:
>
> >> Recently I loaded CyrAsia font in console, and have noticed
> >> that it misses one Kazakh letter:
> >>
> >> Ұ U+04B0 Cyrillic Capital Letter Straight U with Stroke
> >> ұ U+04B1 Cyrillic Small Letter Straight U with Stroke
>
> Also I see that currency symbols of some countries are added,
> so I would like to add Kazakh tenge as well, its code is
> 
> ₸ - Unicode Character 'TENGE SIGN' (U+20B8)

This is how you can check that there haven't been problems with space in 
the fonts (after you compile the package):

grep 'no space in the font' Fonts/*.log

If you see no such warnings, then everything is ok.  I've tried this myself 
and it seems there is enough space in the fonts for these three additional 
symbols.  So, go ahead and add them!

> While we are at it, I wonder where these glyphs are taken from?
> Because in build log I see that № symbol is missing from the resulting font.
> In log file it says
> 
> WARNING: U+2116: no glyph defined
 
The glyphs come from the fonts in the directory Fonts/bdf.  This particular 
warning means that no suitable source font includes this glyph, so it has 
been impossible to support it in the generated console font.

Anton Zinoviev

Bug#823367: intent to NMU

[Davide G. M. Salvetti]

>  RV == Rémi Vanicat [2016-11-20]

RV> Hello, I intent to nmu auctex for those 3 bugs, with the attached
RV> patch:

Fine with me, thanks for your work.  While you are at it, I think you
could also drop emacs23 support (just remove emacs23 wherever it
occurs).

-- 
Regards,
Davide

Bug#845213: Suspend exception processing if there are too many exceptions

[Bastien ROUCARIES]

Package: src:imagemagick
version: 8:6.8.9.9-5+deb8u5
Severity: grave
Tags: patch security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
control: found -1 8:6.7.7.10-5+deb7u7


Avoid a DOS by better checking overflow


https://github.com/ImageMagick/ImageMagick/commit/0474237508f39c4f783208123431815f1ededb76

Bug#845212: Fix out of bound read in viff file handling

[Bastien ROUCARIES]

Package: src:imagemagick
version: 8:6.8.9.9-5+deb8u5
Severity: important
Tags: patch security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
control: found -1 8:6.7.7.10-5+deb7u7



bug: https://github.com/ImageMagick/ImageMagick/issues/129
bug-ubuntu: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1545183

(cherry picked from commit 76ac0460463c7f4eab8e58a5dd5cbb2bb012ccd3)

Bug#845061: yasnippet: Broken with emacs25

[Sean Whitton]

Hello Alberto,

On Mon, Nov 21, 2016 at 08:24:31AM +0100, Alberto Luaces wrote:
> actually I am in the process of packaging the most recent version with
> dh_elpa, so I guess I can fix this soon.

Ah.  I actually asked Barak A. Pearlmutter if I could adopt the package
on behalf of the pkg-emacsen team.  Maybe you'd like to help me with the
adoption?

https://anonscm.debian.org/cgit/pkg-emacsen/pkg/yasnippet.git/

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844908:

[Arturo Borrero Gonzalez]

merge 844421
thanks

Bug#845194: amd64-microcode: please make the early initramfs image reproducible

[Henrique de Moraes Holschuh]

On Mon, Nov 21, 2016, at 09:18, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] on behalf of the
> Tails operating system [1], I noticed that amd64-microcode generates
> a prepended initramfs image that is not reproducible.

So far so good, but...

> Patch attached.

It depends on SOURCE_DATE_EPOCH.  Is that going to be appropriately set
in every relevant situation?

Because the early initramfs is going to be (re?)generated at package
*install* / upgrade time.  So, it is not only at package build time...

Also, if the admin calls "update-initramfs", it will re-create the early
initramfs, and SOURCE_DATE_EPOCH is not going to be appropriately set at
that time.

For the intel-microcode package, I changed iucode-tool (v2.1 and later)
to set the dates to the latest microcode included in the image, which
makes it always reproducible as long as the same set of microcode is
used.  Unfortunately, this is not so trivial to do for amd64-microcode,
because we don't parse the microcode.

Maybe it it would be better to hard-code the value of SOURCE_DATE_EPOCH
at package build time into the hook script?  It would then *always* use
that date to create any early initramfs...

-- 
  Henrique de Moraes Holschuh 

Bug#845214: ITP: fonts-go -- high-quality WGL4 TrueType fonts for Go project

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: "ChangZhuo Chen (陳昌倬)" 

* Package name: fonts-go
  Version : 0~20161116
  Upstream Author : Name 
* URL : https://blog.golang.org/go-fonts
* License : BSD-3-clause
  Programming Lang: fonts
  Description : high-quality WGL4 TrueType fonts for Go project

 The Go font family includes proportional and fixed width faces in
 normal, bold, and italic renderings. It is designed for technical uses,
 particularly programming.

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#845205: [debian-mysql] Bug#845205: Incompatible with MariaDB 10.1

[Otto Kekäläinen]

Hello!

Debian contains at the moment MariaDB 10.0. Please don't file bugs
against packages that are from 3rd party repos and not from
Debian.org.

2016-11-21 14:48 GMT+02:00 Matt Li :
> Package: exim4
> Version: 4.88~RC4-2
> X-Debbugs-CC: pkg-mysql-ma...@lists.alioth.debian.org
>
> It appears that exim4 from exim4-daemon-heavy is now linked to 
> libmariadbclient.so.18 which does not exist in MariaDB 10.1 - only 
> libmysqlclient.so.18 is provided.
>
> /usr/sbin/exim4: error while loading shared libraries: 
> libmariadbclient.so.18: cannot open shared object file: No such file or 
> directory
>
> Manually symlinking to libmysqlclient.so.18 results in:
>
> /usr/sbin/exim4: /usr/lib/libmariadbclient.so.18: version 
> `libmariadbclient_18' not found (required by /usr/sbin/exim4)
>
> This did not occur in the last testing build 4.87-3+b1.

Bug#844242: RFS: terminology/0.9.1-0.1 [RC] [NMU]

[Ross Vandegrift]

On Fri, Nov 18, 2016 at 05:04:02PM +, Gianfranco Costamagna wrote:
> Hi Ross, can you please fix and answer if  you want to maintain or not
> the package?

I've uploaded an updated package to:
https://mentors.debian.net/debian/pool/main/t/terminology/terminology_0.9.1-1.dsc

New changelog:

 [ Ross Vandegrift ]
 * New upstream release
   - Fix for "CVE-2015-8971: Escape Sequence Command Execution
 vulnerability" (Closes: #843434)
 * fix-minus-signs-manpage.patch: drop patch, fixed upstream
 * use-system-lz4.patch: defuzz
 * fix-del-backspace-key.patch: defuzz
 * Provide x-terminal-emulator alternative (Closes: #774111)
 * debian/copyright: remove unused ltmain.sh paragraph
 * Add gbp.conf and notes on usage in README.source
 * Enable build hardening options
 * Suggest libemotion-players for media support (Closes: #773057, #766705)
 * Reformat package descriptions (Closes: #779494, #782082)
 * Use secure Vcs- URLs in debian/control
 * Bump Standards-Version to 3.9.8
 * New Maintainer.  Thanks to Anthony for original work. (Closes: #844244)

 [ Nicolas Braud-Santoni ]
 * Normalize links and use HTTPS

Thanks!

Ross

Bug#845216: fails to upgrade/install

[Brent S. Elmer]

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

I tried to upgrade and got an error.  Then I removed the package and tried to
install and got an error.

Selecting previously unselected package emacs-goodies-el.
(Reading database ... 477704 files and directories currently installed.)
Preparing to unpack .../emacs-goodies-el_36.2_all.deb ...
Unpacking emacs-goodies-el (36.2) ...
Processing triggers for install-info (6.3.0.dfsg.1-1+b1) ...
Setting up emacs-goodies-el (36.2) ...
Install emacsen-common for emacs23
emacsen-common: Handling install of emacsen flavor emacs23
Wrote /etc/emacs23/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs23/site-lisp/debian-startup.elc
Install emacsen-common for emacs24
emacsen-common: Handling install of emacsen flavor emacs24
Wrote /etc/emacs24/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
Install emacs-goodies-el for emacs23
install/emacs-goodies-el: Handling emacs23, logged in /tmp/elc_xITXzf.log
Building autoloads for emacs23 in /usr/share/emacs23/site-lisp/emacs-goodies-el
ERROR: install script from emacs-goodies-el package failed
dpkg: error processing package emacs-goodies-el (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 emacs-goodies-el

Not all changes and updates succeeded. For further details of the failure,
please expand the 'Details' panel below.



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

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

Versions of packages emacs-goodies-el depends on:
ii  bash   4.4-2
ii  dpkg   1.18.15
ii  emacs  46.1
ii  emacs23 [emacsen]  23.4+1-4
ii  emacs24 [emacsen]  24.5+1-7
ii  emacs25 [emacsen]  25.1+1-2
ii  emacsen-common 2.0.8
ii  install-info   6.3.0.dfsg.1-1+b1

Versions of packages emacs-goodies-el recommends:
ii  perl-doc  5.24.1~rc3-3
ii  wget  1.18-4

emacs-goodies-el suggests no packages.

-- no debconf information

Bug#844081: Which FS was this run on?

[Christian Geier]

Hi,
what filesystem did you run this on?

The issue here is, that mtimes that should change, didn't (at least not
as far as python is concerned), event though there is a sleep(0.01)
(which does not *have* to be accurate, but usually is a bit larger)
between reading the mtime, modifying the data and re-reading the mtime .

Best regards,
Christian Geier

Bug#845217: contributors.debian.org: Broken ftp.debian.org "extra info" DDPO link

[Christos Trochalakis]

Package: nm.debian.org
Severity: normal

Hello,

Τhe "extra info" link for the ftp.debian.org source (fingerprint
identifier) points to:

https://qa.debian.org/developer.php?login=&comaint=yes

instead of:

https://qa.debian.org/developer.php?gpg_key=&comaint=yes

Bug#845209: Switch to clang-3.9

[Mattia Rizzolo]

Control: reassign -1 src:llvm-defaults

On Mon, Nov 21, 2016 at 02:44:12PM +0100, Yuri D'Elia wrote:
> Package: clang-defaults

Please double-check package names before filing bugs.

> Severity: wishlist
> 
> Clang 3.9 is the latest release of clang, which is already available on
> unstable. Is there any reason to keep depending on 3.8 as the default?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature