Bug#816688: /usr/bin/debsign: debsign ignores input it gets in its environment variables

[Sebastian Kuzminsky]

Package: devscripts
Version: 2.15.3
Severity: normal
File: /usr/bin/debsign

debsign overwrites the values of its input environment variables with empty
strings at startup, thus making them useless.

All environment variables listed in $VARS get this treatment.

I discovered this while trying to pass a GPG key id in the DEBSIGN_KEYID
environment variable.  My specified keyid gets ignored.



-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.17.26
ii  libc62.19-18+deb8u3
ii  perl 5.20.2-3+deb8u3
ii  python3  3.4.2-2
pn  python3:any  

Versions of packages devscripts recommends:
ii  at  3.1.16-1
ii  curl7.38.0-4+deb8u3
ii  dctrl-tools 2.23
ii  debian-keyring  2015.04.10
ii  dput0.9.6.4
ii  equivs  2.0.9
ii  fakeroot1.20.2-1
ii  file1:5.22+15-2+deb8u1
ii  gnupg   1.4.18-7
ii  libdistro-info-perl 0.14
ii  libencode-locale-perl   1.03-1
ii  libjson-perl2.61-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libparse-debcontrol-perl2.005-4
ii  libsoap-lite-perl   1.11-1
ii  liburi-perl 1.64-1
ii  libwww-perl 6.08-1
ii  lintian 2.5.30+deb8u4
ii  man-db  2.7.0.2-5
ii  patch   2.7.5-1
ii  patchutils  0.3.3-1
ii  python3-debian  0.1.27
ii  python3-magic   1:5.22+15-2+deb8u1
ii  sensible-utils  0.0.9
ii  strace  4.9-2
ii  unzip   6.0-16+deb8u2
ii  wdiff   1.2.2-1
ii  wget1.16-1
ii  xz-utils5.1.1alpha+20120614-2+b3

Versions of packages devscripts suggests:
ii  bsd-mailx [mailx]8.1.2-0.20141216cvs-2
ii  build-essential  11.7
pn  cvs-buildpackage 
pn  debbindiff   
pn  devscripts-el
ii  gnuplot  4.6.6-2
ii  gpgv 1.4.18-7
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.07-1
ii  libnet-smtp-ssl-perl 1.01-3
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
ii  mutt 1.5.23-3
ii  openssh-client [ssh-client]  1:6.7p1-5+deb8u1
pn  svn-buildpackage 
ii  w3m  0.5.3-19

-- no debconf information

Bug#813916: transition: gdal

[Sebastiaan Couwenberg]

On 03-03-16 21:44, Sebastiaan Couwenberg wrote:
> On 03-03-16 20:13, Sebastiaan Couwenberg wrote:
>> On 03-03-16 19:12, Emilio Pozuelo Monfort wrote:
>>> On 01/03/16 20:18, Sebastiaan Couwenberg wrote:
 On 01-03-16 19:50, Emilio Pozuelo Monfort wrote:
> On 19/02/16 14:08, Sebastiaan Couwenberg wrote:
>> On 12-02-16 19:05, Emilio Pozuelo Monfort wrote:
>>> On 12/02/16 18:52, Sebastiaan Couwenberg wrote:
 On 12-02-16 18:28, Emilio Pozuelo Monfort wrote:
> On 06/02/16 17:43, Bas Couwenberg wrote:
>> Package: release.debian.org
>> For the Debian GIS team I'd like to transition to the recently 
>> released
>> GDAL 1.11.4. Only the packages using C++ symbols need to be rebuilt.
>>
>> GDAL 2.0.2 was released along with 1.11.4, but we still don't have
>> support for GDAL 2.0 in all reverse dependencies. Since the 
>> transition
>> to GDAL 1.11.3, support for GDAL 2.0 was added to all reverse
>> depedencies except Fiona [0]. Upstream has recently included changes 
>> for
>> GDAL 2.0, but these differ from the initial GDAL 2.0 changes 
>> available
>> as a patch in #802808. The improved GDAL 2.0 changes are entangled 
>> with
>> other changes for the upcoming Fiona 1.7 release, which I've not been
>> able to successfully backport. This will not be a blocker for the 
>> GDAL
>> 2.0 transition, as discussed with the maintainer on the debian-gis 
>> list
>> [1].
>>
>> Because the transition for GDAL 1.11.4 is ready now, I'd like to do 
>> that
>> first before preparing the transition to GDAL 2.0. All reverse
>> dependencies rebuilt successfully with GDAL 1.11.4, the summary of
>> rebuilds is included below.
>>
>
> This would get entangled with the openmpi transition, so it will have 
> to wait.
> After openmpi, I'm thinking about doing libpng, but we'll see.

 Waiting for openmpi is no problem, but if the libpng transition is 
 going
 to happen first, I think it's better to use that time the prepare the
 transition to GDAL 2.0 instead of 1.11.4. Last week the last blocker 
 was
 resolved [0], so we're also pretty much ready to transition to GDAL 
 2.0.
 The 2.0 packages will have to pass the NEW queue again, because of the
 delay that will cause I've opted to transition to 1.11.4 which is 
 ready now.

 If you can confirm that the libpng transition is going to happen first,
 I'll upload the packages for GDAL 2.0 to experimental, and we can 
 switch
 to that in unstable after the libpng transition and the new gdal has
 passed NEW.
>>>
>>> Sure, let's do that.
>>
>> The GDAL 2.0.2 packages are available in experimental and ready for
>> transition.
>>
>> libgdal-grass (2.0.2-1) not available in experimental yet, liblas and
>> grass need to be rebuilt with GDAL 2.0 before it can be built too,
>> because the SOVERSION is included in the binary package it builds the
>> package will have to pass the NEW queue after upload first. To get it
>> passed the NEW queue, I'll rebuild liblas & grass with gdal
>> (2.0.2-1-1~exp2) from experimental and upload all three to experimental 
>> too.
>>
>> All reverse dependencies build successfully with GDAL 2.0.
>>
>>
>> Transition: gdal
>>
>>  libgdal1i (1.11.3+dfsg-3) -> libgdal20 (2.0.2+dfsg-1)
>>  libgdal.so.1-1.11.3   -> gdal-abi-2-0-2
>>
>> The status of the most recent rebuilds is as follows.
>>
>>  dans-gdal-scripts (0.23-4)   OK
>>  fiona (1.6.3-2)  OK
>>  gazebo(6.5.0+dfsg-2) OK
>>  gmt   (5.2.1+dfsg-3) OK
>>  imposm(2.6.0+ds-2)   OK
>>  libcitygml(2.0-1)OK
>>  liblas(1.8.0-7)  OK
>>  libosmium (2.6.0-1)  OK
>>  mapcache  (1.4.0-4)  OK
>>  mapnik(3.0.9+ds-1)   OK
>>  mapserver (7.0.0-9)  OK
>>  merkaartor(0.18.2-5) OK
>>  mysql-workbench   (6.3.4+dfsg-3) OK
>>  ncl   (6.3.0-6)  OK
>>  node-srs  (0.4.8+dfsg-2) OK
>>  openscenegraph(3.2.1-9)  OK
>>  osmium(0.0~20160124-b30afd3-1)   OK
>>  osrm  (4.9.1+ds-1~exp2)  OK
>>  postgis   (2.2.1+dfsg-2)  

Bug#816687: -switch: Please use ifquery in init script

[Adam Heath]

Package: openvswitch-switch
Version: 2.3.0+git20140819-3
Severity: minor

In /etc/init.d/openvswitch-switch, the function network_interfaces does 
a manual parse of /etc/network/interfaces.  This prevents it from 
finding interfaces defined in /etc/network/interfaces.d. Please switch 
to use "ifquery --allow ovs --list" instead; that program has existed 
since 2012.

Bug#816652: RFS: compiz/1:0.9.12.2 [ITP:722451]

[James Cowgill]

Hi,

[I've added Jean-Philippe in case he wants to weigh in]

On Thu, 2016-03-03 at 19:58 +0100, Vincent Auboyneau wrote:
> On Thu, Mar 03, 2016 at 03:03:11PM +, James Cowgill wrote:
> > > The first step is getting compiz back in debian. It has been cleaned up,
> > > and polished with the last version of upstream.  I have followed the
> > > previous advice of Adam Borowski, and set the jpeg and png deps strait.
> > Sounds good, assuming it can easily be used with an existing DE in
> > Debian (I used to use compiz but I think I've forgotten how it all
> > worked).
>
> The obvious prime target is the mate desktop, which is growing in users,
> and has become an official ubuntu flavour, so they recently added a
> plugin for better integration.
> This is also, according to several professional in this area, the most
> accessible desktop available for some impaired users, partly because it
> provides stability.

Ok I'm fine with compiz being reintroduced into Debian.

> > > there is the question of the source format, should it be 3(native) or
> > > quilted?
> > 3.0 (quilt)
> > 
> > Native is intended for projects developed by Debian itself. These are
> > usually infastructure type projects (like dpkg, debhelper, etc). Most
> > packages should not be native.
> if using quilt, i need to generate a orig.tar.gz, so how'd you proceed
> with that? just tar the thing, rename it?

In a normal package, the orig.tar.gz should (if possible) be identical
to the upstream release version. You probably want this file:

https://launchpad.net/compiz/0.9.12/0.9.12.2/+download/compiz-0.9.12.2.tar.bz2

BUT, I have noticed that instead of using patches, Ubuntu has been
creating "fake" upstream releases when fixing bugs. This isn't great
since the latest bugfixes are now only found in Ubuntu and aren't
easily split out for other distributions. The best solution is to try
and get a new release of compiz with these fixes and then persuade
Ubuntu developers to ship patches in debian/patches rather than
manually patching the source. The ideal change flow should be
Upstream -> Debian -> Ubuntu.

The alternatives to that don't look nice. You could move the diff
between ubuntu and upstream into debian/patches, but it looks massive.

> > > Another issue, that is pending resolve, is a couple lintian errors:
> > > compiz-dev: package-contains-cmake-private-file 
> > > usr/share/cmake-3.0/FindCompiz.cmake
> > > compiz-dev: package-contains-cmake-private-file 
> > > usr/share/cmake-3.0/FindOpenGLES2.cmake
> > > Are those critical? or is it ok till resolution?
> > You're not allowed to ship files in /usr/share/cmake-* because that
> > directory is internal to cmake. Things will also break when cmake gets
> > upgraded - infact what you're doing is already broken in sid.
> > 
> > You should try and use CMake config files if possible, although they
> > can be a bit fiddly to setup. For now you could either drop those
> > files, or move them to some other directory (which will not
> > automatically be searched).
> > 
> > See:
> > https://lintian.debian.org/tags/package-contains-cmake-private-file.html
> I've already sent a mail to this part's creator, as it is indeed fiddly.

Ok, hopefully that can be sorted - it has to be removed for the moment
though.

> > > As for functionnal tests, compiz is used by ~20 people, and is ready
> > > from sid to jessie-backports.
> > > I await more instructions and pieces of sound advice, of which i know
> > > debian people have plenty.
> > > 
> > > project is uploaded to alioth:
> > > https://alioth.debian.org/projects/compiz/
> > > git clone git+ssh://$u...@git.debian.org/git/pkg-a11y/compiz.git
> > I've only had a brief look but there a few obvious issues:
> >  - Needs "de-ubuntifying" (changelogs, control, etc)
> I have been told (by a DD) that changelog "mixing" was ok, since ubuntu
> was already using it as a project changelog (not just deb changelog),
> and debian's additions would only affect last entry.
> What do you suggest?

OK, in that case leaving those entries should be fine. I did notice the
Debian version number is earlier than the Ubuntu version in the
changelog which isn't going to work properly - maybe that can be fixed
with a new upstream release :)

> >  - Maintainer field needs sorting out. Who exactly is working on this?
> >    - Also you don't own the ITP - are you working together?
> I work with Jean-philippe yes. we could transfer ownership indeed.

You don't need to transfor ownership if everyone involved is ok with
what's going on.

You should remove the XSBC-Original-Maintainer field, and replace the
Uploaders field with the other people working on compiz.

Looking over the ITP, two teams were mentioned: pkg-a11y and compiz. If
the packaging is being done by a team then the Maintainer field should
be set to a sutible mailing list. Has it been decided which team compiz
will live under?

Relevant policy info:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Maintainer

Bug#434235: mutt -H ignores Content-Type:

[Kevin J. McCarthy]

FYI.  This is fixed upstream in https://dev.mutt.org/hg/mutt/rev/a4d885bb36ab

Bug#743744: mutt: S/MIME: mismatching documentation and supported algorithms for encryption (smime_encrypt_with)

[Kevin J. McCarthy]

FYI.  This was fixed upstream in https://dev.mutt.org/hg/mutt/rev/1235dd48ef3f

Bug#816497: aptitude: problems with (un)markauto

[Manuel A. Fernandez Montecelo]

2016-03-03 09:18 Jörg-Volker Peetz:

Hi Manual,

Manuel A. Fernandez Montecelo wrote on 03/03/16 02:57:

Control: tags -1 + moreinfo


Hi Jörg,





Seems to work fine around here:

 # aptitude -F '%M %p' search '~n^gnupg2$~ramd64'
 A gnupg2

 # aptitude markauto '~n^gnupg2$~ramd64'
 No packages will be installed, upgraded, or removed.
 0 packages upgraded, 0 newly installed, 0 to remove and 92 not upgraded.
 Need to get 0 B of archives. After unpacking 0 B will be used.

 # aptitude -F '%M %p' search '~n^gnupg2$~ramd64'
 A gnupg2

 # aptitude unmarkauto '~n^gnupg2$~ramd64'
 No packages will be installed, upgraded, or removed.
 0 packages upgraded, 0 newly installed, 0 to remove and 92 not upgraded.
 Need to get 0 B of archives. After unpacking 0 B will be used.

 # aptitude -F '%M %p' search '~n^gnupg2$~ramd64'
   gnupg2


thanks for looking into this. I should've been more specific.

On my system the output stays unchanged and always says:

# aptitude -F '%M %p' search '~n^gnupg2$~ramd64'
A gnupg2

And I think the difference is that on my system the package gnupg2 has the
additional new attribute "Auto-New-Install" set to "yes" in the file
/var/lib/aptitude/pkgstates.
Indeed, for any package with this new attribute in var/lib/aptitude/pkgstates
"aptitude (un)markauto" doesn't work.
For a package without this new attribute "(un)markauto" still works here.


Uhm, that's an interesting hint, thanks.  I will look into this in the
next days.



Regarding the interaction between aptitude and apt-mark, I thought that at least
the (un)markauto actions of aptitude were written to the apt database.


It does rely on apt for this, at least after the packages are installed.
Changes in (un)markauto should be reflected in:

 /var/lib/apt/extended_states


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#800780: mutt: folder-hook: current mailbox shortcut '^' is unset

[Kevin J. McCarthy]

The warning for this is new in 1.5.24, but the behavior has been the
same for 9 years.  A leading '^' in a folder-hook or mbox-hook expands
to "current mailbox", not "beginning of line".

See https://dev.mutt.org/doc/manual.html#mailbox-hook
and https://dev.mutt.org/trac/ticket/3788

If you need beginning on line, the best way is to use parenthesis:
  folder-hook (^buildd$) source .muttrc.buildd

Bug#816607: void EncoderStrategy::AppendToBitStream(LONG, LONG): Assertion `bitpos >=0' failed

[Sjors Gielen]

I forgot to mention, to compile this testcase:

g++ test_dcmtk.cpp -O0 -g -o test_dcmtk -rdynamic -ldcmdata -ldcmimage
-ldcmimgle -ldcmjpeg -ldcmnet -ldcmpstat -ldcmqrdb -ldcmsr -ldcmtls -lijg12
-lijg16 -lijg8 -lofstd -ldcmjpls -loflog -I/usr/include -DHAVE_CONFIG_H

It ignores any arguments given at runtime.

Op do 3 mrt. 2016 om 23:09 schreef Sjors Gielen :

> Hello Matthieu,
>
> A test case is attached. It allocates an uncompressed 1165 by 1434 pixel
> 16-bit image, and writes a relatively small set of pixels while still
> reproducing the issue.
>
> It then fills a DcmFileFormat wih the values required to store it as a
> valid Dicom JPEG-LS image. During the dcmff.saveFile() call, the assertion
> failure happens:
>
> test_dcmtk: /home/sjors/src/charls-1.0/encoderstrategy.h:81: void
> EncoderStrategy::AppendToBitStream(LONG, LONG): Assertion `bitpos >=0'
> failed.
>
> Hopefully this will allow you to reproduce as well. I know about three
> fixes/workarounds (I don't know which one applies):
> 1. The patch dcmtk applied, which returns before the assertion is ever
> checked,
> 2. Calling Flush() again if bitpos is still lower than 0, or
> 3. Increasing the amount of iterations in Flush() so that bitpos cannot be
> lower than 0 after returning from that function.
>
> Maybe some input from the CharLS developers would be useful here.
>
> Sjors
>
> Op do 3 mrt. 2016 om 22:37 schreef Sjors Gielen :
>
>> Hello Mathieu,
>>
>> I have a working test-case, but as it contains an uncompressed image, it
>> is currently 7 MB. I'm trying to make it smaller before I'll upload it, and
>> hope to have that done by tomorrow. It uses CharLS through DCMTK – which,
>> on Debian, uses system CharLS, not the DCMTK-shipped one.
>>
>> I have been using the patch you linked as a workaround in the past, but
>> upstream CharLS has expressed doubts over the patch as committed to DCMTK's
>> shipped CharLS. I haven't verified these doubts myself, but the patch is
>> not applied to CharLS upstream either. See:
>> http://charls.codeplex.com/workitem/10742 and
>> https://github.com/team-charls/charls/blob/master/src/encoderstrategy.h#L83
>> .
>>
>> Interestingly, in the first link above, upstream says the problem is
>> linked in this changeset:
>> https://github.com/team-charls/charls/commit/c7cf959f348f8e0c47f1197c89ef959372c572e9
>>  –
>> I can see that that changeset adds a test, but not that it fixes the actual
>> issue upstream...
>>
>> Sjors
>>
>> Op do 3 mrt. 2016 om 21:15 schreef Mathieu Malaterre :
>>
>>> Control: tags -1 moreinfo
>>>
>>> Dear OP,
>>>
>>> Since you did not provide material to reproduce the issue, did you try
>>> the proposed patch ?
>>>
>>>
>>> http://git.dcmtk.org/?p=dcmtk.git;a=commitdiff;h=d885abd90ef90f6566555298064190561ff0412a
>>>
>>> Unless some kind of sample file is provided I cannot possibly include
>>> a fix for the next upload.
>>>
>>

Bug#816686: jessie-pu: package systemd/215-17+deb8u4

[Michael Biebl]

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

Dear release team,

a few fixes have piled up in our systemd jessie branch, so I'd like to
make a stable upload for 8.4.

The annotated changelog is:

systemd (215-17+deb8u4) stable; urgency=medium

  [ Martin Pitt ]
  * debian/udev.prerm: Add missing "deconfigure" action. (Closes: #809744)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=jessie=966a8a4098478e13694e054b90c3567474293d37

  * udev.postinst: Don't call addgroup with --quiet, so that if the "input"
group already exists as a non-system group you get a sensible error
message. Some broken tutorials forget the --system option.
(Closes: #769948, LP: #1455956)
  * systemd.postinst: Drop the --quiet from the addgroup calls as well, same
reason as above. (Closes: #762275)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=jessie=22dbdc16557cd294a24bf0ed319e93c6788409e1

  [ Michael Biebl ]
  * Make sure all swap units are ordered before the swap target. This avoids
that swap devices are being stopped prematurely during shutdown.
(Closes: #805133)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=jessie=c4793975137d5d522fee104b7dab94a79547effd

This is a rather important fix. Software might need the swap space on
shutdown. Not having it around might lead to corrupt data.

This fix has been in unstable/testing for a while.

  * Only skip the filesystem check for /usr if the /run/initramfs/fsck-usr
flag file exists. Otherwise we break booting with dracut which uses
systemd inside the initramfs. (Closes: #810748)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=jessie=447f0bc15b247550bc50306e1c6000a56d8d68b0

Without this fix, having split-usr and dracut installed will result in
an unbootable system. The fix has been in unstable/testing for a while.

  * Fix --network-interface in systemd-nspawn to not fail when modifying an
existing link. (Closes: #813696)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=jessie=df6ebb6fa044c71e38a585e1bbd4d1dc0907d993

Obvious bug fix. Not a terribly important bug, but we had users asking for
an explit backport/cherry-pick of this upstream fix an I see no good
reason why no. Low/No regression potential.

 -- Michael Biebl   Thu, 03 Mar 2016 19:51:22 +0100

Full debdiff is attached.

Please let me know if I can proceed with the upload.

Regards,
Michael


-- 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.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index e7f31e9..974bbb0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,26 @@
+systemd (215-17+deb8u4) stable; urgency=medium
+
+  [ Martin Pitt ]
+  * debian/udev.prerm: Add missing "deconfigure" action. (Closes: #809744)
+  * udev.postinst: Don't call addgroup with --quiet, so that if the "input"
+group already exists as a non-system group you get a sensible error
+message. Some broken tutorials forget the --system option.
+(Closes: #769948, LP: #1455956)
+  * systemd.postinst: Drop the --quiet from the addgroup calls as well, same
+reason as above. (Closes: #762275)
+
+  [ Michael Biebl ]
+  * Make sure all swap units are ordered before the swap target. This avoids
+that swap devices are being stopped prematurely during shutdown.
+(Closes: #805133)
+  * Only skip the filesystem check for /usr if the /run/initramfs/fsck-usr
+flag file exists. Otherwise we break booting with dracut which uses
+systemd inside the initramfs. (Closes: #810748)
+  * Fix --network-interface in systemd-nspawn to not fail when modifying an
+existing link. (Closes: #813696)
+
+ -- Michael Biebl   Thu, 03 Mar 2016 19:51:22 +0100
+
 systemd (215-17+deb8u3) stable; urgency=medium
 
   * Fix namespace breakage due to incorrect path sorting. (Closes: #787758)
diff --git a/debian/patches/Skip-filesystem-check-if-already-done-by-the-initram.patch b/debian/patches/Skip-filesystem-check-if-already-done-by-the-initram.patch
index 70ab1ed..851d1a6 100644
--- a/debian/patches/Skip-filesystem-check-if-already-done-by-the-initram.patch
+++ b/debian/patches/Skip-filesystem-check-if-already-done-by-the-initram.patch
@@ -1,35 +1,48 @@
-From: Michael Biebl 
-Date: Mon, 13 Apr 2015 19:34:23 +0200
+From: Nis Martensen 
+Date: Tue, 19 Jan 2016 22:01:43 +0100
 Subject: Skip filesystem check if already done by the initramfs
 
 Newer versions of initramfs-tools already fsck and mount / and /usr in
 the initramfs. Skip the filesystem check in 

Bug#753809: Bugs seems to have gone.

[Gert Wollny]

Hi, 

after resolving the locking problem with the communication and testing
up-and downloading to and Orthanc server I can not confirm the bug,
that is, after a round-trip the images don't contain any bogus tags. 

This holds for the combination of Ginkgo CADx and Orthanc available
from jessy, and for the current Debian/sid version of Orthanc in
combination of Ginkgo CADx as of [1]. 

Best, 
Gert

[1] https://github.com/gerddie/ginkgocadx/commit/eb1bc1

Bug#816654: youtube-dl: SSL error with vimeo URLs

[Matt Taggart]

Rogério Brito writes:
> I don't know. Things work perfectly fine for me:
> 
> 
> youtube-dl https://player.vimeo.com/video/156377457
> [vimeo] 156377457: Downloading webpage
> [vimeo] 156377457: Extracting information
> [vimeo] 156377457: Downloading JSON metadata
> [vimeo] 156377457: Downloading m3u8 information
> [download] Destination: Saving_Midtown_-_San_Francisco_Renters_on_Strike-1563
> 77457.mp4
> [download]   3.5% of 392.61MiB at  2.43MiB/s ETA 02:35^C
> ERROR: Interrupted by user
> 
> 
> On the other hand, the error that you're seeing is *very* similar to the
> error that some people have reported on a project of which I am upstream
> (coursera-dl).
> 
> What version of Python are you using?  I suspect that if you are using the
> package from unstable on an earlier release, with Python 2.7.x with x < 9,
> then that may be related with the bug that I'm seeing upstream.

Yes I installed the unstable youtube-dl on jessie.

> If not, then I sincerely don't know.  I plan on moving youtube-dl to Python
> 3 on my next upload and if I recall correctly, the SSL stuff in Python >=
> 3.4 works well (and was backported to late versions of Python 2.7).

It would be nice to have a jessie backport (and maybe jessie update as has 
been done in the past) that works, even if the backport requires a little 
tweaking to the source package to make it work.

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#737498: [PATCH v2] patch: when importing from email, RFC2047-decode From/Subject headers

[timeless]

Julien Cristau  wrote:
>
>> > Reported at https://bugs.debian.org/737498
>>
>> You should probably immediately relay such reports upstream.

You should actually file a bug in bz.mercurial-scm.org for this issue,
you should be able to change the bts bug to link to it.
Once you do that, you should use the issue number in the commit
description (see check-commit).

Bug#797778: Please package pyroute2 >= 0.3.10

[Vincent Bernat]

 ❦ 22 février 2016 07:22 +0100, Jérémy Bobbio  :

> I also would like to see an updated version of pyroute2 in Debian as I'd
> like to use it to fiddle with ipsets.

Same here. 0.3.16 has been released last week. Also happy to help if needed.
-- 
Wrinkles should merely indicate where smiles have been.
-- Mark Twain


signature.asc
Description: PGP signature

Bug#494506: Aptitude could expose 'replaces' rules to operator

[Manuel A. Fernandez Montecelo]

Control: severity -1 wishlist
Control: tags -1 + wontfix


Hi Richard,

2008-08-10 08:58 Richard Kettlewell:

Package: aptitude
Version: 0.4.11.9-1

The upgrade here is from 14.0.1-2+b1 of the various sox packages to 
14.1.0-1.


In this upgrade, libsox-fmt-ogg disappears, its functionality subsumed 
into libsox-fmt-base.  The latter package has a Replaces: header 
indicating this.


The output from Aptitude is:

-
$ sudo aptitude dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
The following packages are BROKEN:
 libsox-fmt-ogg
The following NEW packages will be installed:
 libsndfile1{a} libsox0a{a} libwavpack1{a}
The following packages will be REMOVED:
 libsox0{a}
The following packages will be upgraded:
 libsox-fmt-alsa libsox-fmt-base libsox-fmt-mp3 sox
4 packages upgraded, 3 newly installed, 1 to remove and 0 not upgraded.
Need to get 0B/794kB of archives. After unpacking 922kB will be used.
The following packages have unmet dependencies:
 libsox-fmt-ogg: Depends: libsox0 (>= 14.0.0) but it is not installable
The following actions will resolve these dependencies:

Remove the following packages:
libsox-fmt-ogg

Score is 119

Accept this solution? [Y/n/q/?]
-

Now Aptitude *is* reaching the right conclusion here, but it *looks* 
like it's decided to disable .ogg support!  Only after manually 
inspecting the new package does it become clear that the -base package 
should support this functionality now.


So it would be clearer to the user that it's OK to proceed if it 
indicated somehow that the package it was going to remove was replaced 
by one it was keeping.


ttfn/rjk



2008-08-11 14:15 Daniel Burrows:

On Sun, Aug 10, 2008 at 08:58:03AM +0100, Richard Kettlewell 
 was heard to say:

The upgrade here is from 14.0.1-2+b1 of the various sox packages to
14.1.0-1.

In this upgrade, libsox-fmt-ogg disappears, its functionality subsumed
into libsox-fmt-base.  The latter package has a Replaces: header
indicating this.


 Actually, it doesn't.  It has a Replaces: header indicating that it
overwrites some files in libsox-fmt-ogg, but it doesn't fully replace
the package (see Policy section 7.6).  aptitude shouldn't tell you that
the package is being replaced, because it might just be that some files
moved from one package to another.


As the original maintainer said here, the Replaces in the package
relationships simply means that some package takes control of *some*
files from other package, but it doesn't mean that the package as a
whole is replaced by other.

The replaced files can be because of a friendly "take-over" of files
(e.g. foo-common taking files previously from foo), in which case the
package names are often related, but also it can happen in many other
situations.

Sometimes files can be moved from one package to the other, e.g. from
"foo-plugins-bad" to "foo-plugins-good", in which case -good has to add
a Breaks/Replaces on the old version of "foo-plugins-good", but the
upgrade probably involves upgrading both packages at the same time to
the later version, so aptitude saying that "*-good replaces *-bad" while
the user sees that both are upgraded would cause confusion.



 That said, aside from this specific case it probably would be a good
idea to give the user a note when a package is being fully replaced.


In the RPM world has a Obsoletes relationship that means that one
package fully replaces another, but there's no such thing in the Debian
world at the moment.  (I learnt that recently, because APT implements
Obsolete relationships because of apt-rpm).


In summary, I think that trying to show this information *by default*
would clutter the interface, probably would not be able to explain a
good portion of cases and would cause more confusion than clarity in
many cases.


That said, in the prompt

 Accept this solution? [Y/n/q/?]

one can press '?' (for general help) or 'o' to explain the solution and
'w libsox-fmt-ogg' for explanations about why packages are currently
kept in the system (maybe this one doesn't help in the case of
upgrades).

I don't have a good example right now with "Replaces", but if I try to
remove aptitude-common, it goes like this:

Accept this solution? [Y/n/q/?] o
aptitude depends upon aptitude-common (= 0.7.7-1)
1)-> Removing aptitude

aptitude-dbgsym depends upon aptitude (= 0.7.7-1)
2)-> Removing aptitude-dbgsym



In the upgrade that you had, it would say something like:

libsox-fmt-base v2 breaks libsox-fmt-ogg v1
libsox-fmt-base v2 replaces libsox-fmt-ogg v1


which I think that it's already more or less what is requested here
(although I don't know if it was implemented in 0.4 / 2008).


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#741147: mutt: Mutt generated smime signatures fail verification in icedove/thunderbird

[Kevin J. McCarthy]

This was fixed upstream in https://dev.mutt.org/hg/mutt/rev/428a92464d5b

Note that fix requires $smime_sign_digest_alg to have a "-md %d" added
to it, so the header matches the actual digest used.

The digest algorithm can be set with $smime_sign_digest_alg.
See contrib/smime.rc.

Bug#802812: gstreamer0.10 0.10.36-1.5 MIGRATED to testing

[Micha Lenk]

Hi,

Given Debian bug #802812 is open, the migration of gstreamer0.10 0.10.36-1.5 to 
testing just one day after its removal seems to be unintended.

Cheers,
Micha

P.S. Sorry for the TOFU, but at least my mail should be self-contained.


On 3. März 2016 17:39:11 MEZ, Debian testing watch  
wrote:
>FYI: The status of the gstreamer0.10 source package
>in Debian's testing distribution has changed.
>
>  Previous version: (not in testing)
>  Current version:  0.10.36-1.5
>
>-- 
>This email is automatically generated once a day.  As the installation
>of
>new packages into testing happens multiple times a day you will receive
>later changes on the next day.
>See https://release.debian.org/testing-watch/ for more information.

-- 
Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail gesendet.

Bug#677687: Mutt crashes while managing attachments

[Kevin J. McCarthy]

Just an FYI that this was fixed upstream in
https://dev.mutt.org/hg/mutt/rev/f99561e22a99.

-Kevin

Bug#803165: But still present in 45.0~b5-1 from experimental

[Oleksandr Gavenko]

But still present in 45.0~b5-1 from experimental.

-- 
http://defun.work/

Bug#815864: (no subject)

[Barry Warsaw]

Ignore the last patch.  This one is better because it no longer forces
python3.5-venv to Depends on virtualenv.  With 8.0.3-3, python-pip-whl
contains all the necessary wheels.
diff --git a/debian/changelog b/debian/changelog
index 469d204..7e3dcaf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+python3.5 (3.5.1-6ubuntu3~test0) UNRELEASED; urgency=medium
+
+  * d/patches/ensurepip-disabled.diff: Provide more debugging when the
+ensurepip command fails.
+  * d/patches/ensurepip-wheels.diff: Update for compatibility with latest
+python-pip packages.
+  * d/control.in: Update python-pip-whl version dependency.
+
+ -- Barry Warsaw   Mon, 29 Feb 2016 16:45:06 -0500
+
 python3.5 (3.5.1-6ubuntu2) xenial; urgency=medium
 
   * python3.5-venv: Drop the dependency on python-pip-whl, depend on
diff --git a/debian/control.in b/debian/control.in
index 3999830..e63ee59 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -38,7 +38,7 @@ Architecture: any
 Multi-Arch: allowed
 Priority: @PRIO@
 Depends: @PVER@ (= ${binary:Version}),
- python-pip-whl (>= 8.0.2-7), ${shlibs:Depends}, ${misc:Depends}
+ python-pip-whl (>= 8.0.3-3), ${shlibs:Depends}, ${misc:Depends}
 Breaks: python3-pip (<< 1.5.6-4)
 Description: Interactive high-level object-oriented language (pyvenv binary, version @VER@)
  Python is a high-level, interactive, object-oriented language. Its @VER@ version
diff --git a/debian/patches/ensurepip-disabled.diff b/debian/patches/ensurepip-disabled.diff
index 7fbc575..1226e2e 100644
--- a/debian/patches/ensurepip-disabled.diff
+++ b/debian/patches/ensurepip-disabled.diff
@@ -1,10 +1,8 @@
 # DP: Disable ensurepip for the system installation, only enable it for virtual environments.
 
-Index: b/Lib/ensurepip/__init__.py
-===
 --- a/Lib/ensurepip/__init__.py
 +++ b/Lib/ensurepip/__init__.py
-@@ -8,6 +8,34 @@ import tempfile
+@@ -8,6 +8,34 @@
  
  __all__ = ["version", "bootstrap"]
  
@@ -39,7 +37,7 @@ Index: b/Lib/ensurepip/__init__.py
  
  # pip currently requires ssl support, so we try to provide a nicer
  # error message when that is missing (http://bugs.python.org/issue19744)
-@@ -68,6 +96,11 @@ def bootstrap(*, root=None, upgrade=Fals
+@@ -68,6 +96,11 @@
  
  Note that calling this function will alter both sys.path and os.environ.
  """
@@ -51,11 +49,9 @@ Index: b/Lib/ensurepip/__init__.py
  if altinstall and default_pip:
  raise ValueError("Cannot use altinstall and default_pip together")
  
-Index: b/Lib/venv/__init__.py
-===
 --- a/Lib/venv/__init__.py
 +++ b/Lib/venv/__init__.py
-@@ -254,7 +254,24 @@ class EnvBuilder:
+@@ -252,7 +252,28 @@
  # intended for the global Python environment
  cmd = [context.env_exe, '-Im', 'ensurepip', '--upgrade',
  '--default-pip']
@@ -65,7 +61,9 @@ Index: b/Lib/venv/__init__.py
 +# following command will produce an unhelpful error.  Let's make it
 +# more user friendly.
 +try:
-+subprocess.check_output(cmd, stderr=subprocess.STDOUT)
++subprocess.check_output(
++cmd, stderr=subprocess.STDOUT,
++universal_newlines=True)
 +except subprocess.CalledProcessError:
 +print("""\
 +The virtual environment was not created successfully because ensurepip is not
@@ -76,7 +74,9 @@ Index: b/Lib/venv/__init__.py
 +
 +You may need to use sudo with that command.  After installing the python3-venv
 +package, recreate your virtual environment.
-+""")
++
++Failing command: {}
++""".format(cmd))
 +sys.exit(1)
  
  def setup_scripts(self, context):
diff --git a/debian/patches/ensurepip-wheels.diff b/debian/patches/ensurepip-wheels.diff
index 930e013..aae0dac 100644
--- a/debian/patches/ensurepip-wheels.diff
+++ b/debian/patches/ensurepip-wheels.diff
@@ -1,5 +1,3 @@
-Index: b/Lib/ensurepip/__init__.py
-===
 --- a/Lib/ensurepip/__init__.py
 +++ b/Lib/ensurepip/__init__.py
 @@ -1,3 +1,4 @@
@@ -7,7 +5,7 @@ Index: b/Lib/ensurepip/__init__.py
  import os
  import os.path
  import pkgutil
-@@ -8,13 +9,9 @@ import tempfile
+@@ -8,13 +9,9 @@
  __all__ = ["version", "bootstrap"]
  
  
@@ -22,7 +20,7 @@ Index: b/Lib/ensurepip/__init__.py
  try:
  import ssl
  except ImportError:
-@@ -26,8 +23,8 @@ else:
+@@ -26,8 +23,9 @@
  pass
  
  _PROJECTS = [
@@ -30,10 +28,11 @@ Index: b/Lib/ensurepip/__init__.py
 -("pip", _PIP_VERSION),
 +"setuptools",
 +"pip",
++"pkg_resources",
  ]
  
  
-@@ -45,7 +42,10 @@ def version():
+@@ -45,7 +43,10 @@
  """
  Returns a string specifying the bundled version of pip.
  """
@@ -45,7 +44,7 @@ Index: b/Lib/ensurepip/__init__.py
  
  def _disable_pip_configuration_settings():
  # We deliberately ignore 

Bug#618342: aptitude: inconsistent behaviour with apt-cache on non-readable sources.list file

[Manuel A. Fernandez Montecelo]

Control: severity -1 wishlist
Control: tags -1 + wontfix


Hi Mika,

2011-03-14 14:10 Michael Prokop:

Package: aptitude
Version: 0.6.3-3.2
Severity: normal


/etc/apt/sources.list.d/foo.list contains something like:

 deb https://$USER:$PASSWD@$MIRROR internal main

and because of confidential information ($USER/$PASSWD) the file is
read-only for root (600).


Another reply was already posted a few years ago with a workaround /
better way to achieve this.

I guess that you solved the problem in some other after these years, but
for the record...



Now running:

 % apt-cache search foobar
 lxmusic - The minimalist music player for LXDE
 man2html - browse man pages in your web browser

works as expected, since the package information of the $MIRROR
above is available in /var/lib/dpkg/status accessible for anyone
anyway. Running strace shows that the file is being read but
apt-cache doesn't care too much:

 open("/etc/apt/sources.list.d/foo.list", O_RDONLY) = -1 EACCES (Permission 
denied)


Now apt-cache doesn't behave as described above:

 $ apt-cache search aptitude
 E: Could not open file /etc/apt/sources.list.d/04-debian-debug.sources - open 
(13: Permission denied)
 E: Malformed stanza 1 in source list 
/etc/apt/sources.list.d/04-debian-debug.sources (type)
 E: The list of sources could not be read.
 W: You may want to run apt-get update to correct these problems
 E: The package cache file is corrupted



Running aptitude fails with:

 % aptitude search foobar
 E: Opening /etc/apt/sources.list.d/foo.list - ifstream::ifstream (13: 
Permission denied)
 E: Opening /etc/apt/sources.list.d/foo.list - ifstream::ifstream (13: 
Permission denied)
 E: The list of sources could not be read.

I consider this inconsistent with apt-cache's behaviour (without
judging who's right :)).

It would be nice if aptitude either doesn't error out or if that's
not an option provide a way how to ignore that error.


aptitude search does quite a few things extra compared with apt-cache
search due to the use of patterns, which includes searching for
auto-flags, holds, forbid versions, origin, user-tags, relationships of
packages (depends, rdepends, conflicts), is garbage (not required by any
other installed package; which involves many structures needed in
typical conflict resolutions), or if is obsolete (cannot be downloaded),
among others.

Comparing apt and aptitude search is not an apple-to-apple comparison,
and that they behave in behaviours and errors is nothing surprising.
(Funnily enough, they don't diverge in behaviour by now).


Even if perhaps reading the source.list* is not strictly needed
(intuitively I don't think so, but I didn't check carefully), it has to
initialize a vast amount of data structures and classes, including its
own and libapt's, some of which require initializing source lists, or
might be needed later for the vast majority of operations that can be
done with aptitude.  The initialisation code used in "search" is the
same as when initialising other parts of aptitude, without having
separate code paths for some of the operations which don't need 100% of
the structures initialised.

So I am sorry, but don't think that it's a net gain for aptitude to
address this bug, and have to duplicate code or complicate the
implementation (both of which can lead to new problems and are of some
maintenance burden) because of this specific problem, which seems quite
a corner case.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#816654: youtube-dl: SSL error with vimeo URLs

[Rogério Brito]

Hi there, Matt.

On Mar 03 2016, Matt Taggart wrote:
(...)
> WARNING: Failed to download m3u8 information:CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)>
> ERROR: unable to download video data:CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)>
> 
> 
> This started maybe a week ago, maybe something changed with vimeo?

I don't know. Things work perfectly fine for me:


youtube-dl https://player.vimeo.com/video/156377457
[vimeo] 156377457: Downloading webpage
[vimeo] 156377457: Extracting information
[vimeo] 156377457: Downloading JSON metadata
[vimeo] 156377457: Downloading m3u8 information
[download] Destination: 
Saving_Midtown_-_San_Francisco_Renters_on_Strike-156377457.mp4
[download]   3.5% of 392.61MiB at  2.43MiB/s ETA 02:35^C
ERROR: Interrupted by user


On the other hand, the error that you're seeing is *very* similar to the
error that some people have reported on a project of which I am upstream
(coursera-dl).

What version of Python are you using?  I suspect that if you are using the
package from unstable on an earlier release, with Python 2.7.x with x < 9,
then that may be related with the bug that I'm seeing upstream.

If not, then I sincerely don't know.  I plan on moving youtube-dl to Python
3 on my next upload and if I recall correctly, the SSL stuff in Python >=
3.4 works well (and was backported to late versions of Python 2.7).


Regards,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#814951: bug#13414: [Werner Koch] Re: [pkg-gnupg-maint] Bug#814951: libassuan: add libassuan-mingw-w64-dev for cross-building to Windows targets

[Peter Rosin]

Hi!

On 2016-03-02 08:23, Daniel Kahn Gillmor wrote:
> On Mon 2016-02-22 22:03:49 +0100, Peter Rosin wrote:
>> The libtool patch from https://debbugs.gnu.org/13414 is better than the
>> debian patch from https://bugs.debian.org/814951 in every aspect that I
>> can see and should indeed help.
>>
>> For reference, the libtool patch was committed here
>> http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=a5a4944fbb2bbd
>>
>> (three years old, released one year ago in 2.4.3)
> 
> It sounds like you're saying that the libtool patch should already be
> committed and running effectively in libtool 2.4.3 or later.

Yes.

> however, debian had libtool 2.4.2-1.11 up until 2016-02-07, when
> 2.4.6-0.1 entered debian.  But Andreas's bug report of FTBFS on unstable
> [0] came 12 days after 2.4.6 entered unstable and 6 days after 2.4.6
> transitioned to testing [1].  So something in the libtool upstream
> changes either didn't have the desired effect, or something else is
> wrong in debian that i'm unaware of.

Have you checked if libassuan has been libtoolized with 2.4.6? Mind you,
that is not automatically the case just because debian ships 2.4.6. Most
libraries carry a bundled copy of the libtool version they were
libtoolized with by the library maintainer prior to the library release.
Some distributions automatically relibtoolizes its packages, some don't.

> for now, i've gone ahead with the simple patch (moving EXPORTS to the
> first line of the file) for libassuan, but i'll be happy to drop that
> patch when libtool is effectively fixed :)

Please check the libtool version in the relevant version of libassuan.

Cheers,
Peter

Bug#816315: #816315 - uwsgi - please support ruby2.3

[Christian Hofstaedtler]

Jonas,

May I suggest dropping the exact ruby version from the package name,
so it doesn't have to go through NEW for 2.4, 2.5, ...?

I see uwsgi-plugin-rbthreads already doesn't encode the version in
the package name.

Many thanks,
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#794326: openssl debian-arm64 does not enable ARMv8 Hardware Extension by default

[Yangzheng Bai]

Ubuntu wily (15.10) openssl package uses debian-targets.patch, in line 24,

${no_asm} should be changed to ${aarch64_asm}:linux64

For performance reasons on ARM64 Server SoC.

Thanks,
Yangzheng BAI
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Bug#794326: Performance issue for arm64 libssl.so.1.0.0

[Yangzheng Bai]

Dear Maintainer,

We found the same issue during performance test on Ubuntu 15.10 Wily with
AMD A1100 Seattle SoC (ARM64 arch).

For debian-arm64 arch, please change ${no_asm} to {$aarch64_asm}

Thanks,
Yangzheng BAI

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

Bug#816685: postfix: logcheck (maybe something else)

[Cristian Ionescu-Idbohrn]

Package: postfix
Version: 3.0.4-5
Severity: normal

I see these logcheck reports:

Mar  3 20:09:05  postfix/smtpd[]: disconnect from 
localhost[127.0.0.1] ehlo=1 mail=1 rcpt=3 data=1 quit=1 commands=7

endlessly, after upgrading :(

Syslog scenaio is:

Mar  3 21:19:20  fetchmail[11625]: 1 message for  at 
.
Mar  3 21:19:20  postfix/smtpd[30207]: connect from 
localhost[127.0.0.1]
Mar  3 21:19:20  postfix/smtpd[30207]: E453D6C0C1: 
client=localhost[127.0.0.1]
Mar  3 21:19:20  postfix/cleanup[30210]: E453D6C0C1: 
message-id=
Mar  3 21:19:20  postfix/cleanup[30210]: E453D6C0C1: 
resent-message-id=
Mar  3 21:19:21  fetchmail[11625]: reading message 
@some-smtp-server:1 of 1 (5760 header octets) (2476 body octets) flushed
Mar  3 21:19:21  postfix/qmgr[380]: E453D6C0C1: 

Bug#816684: Useless in Debian

[David Prévot]

Package: php-zend-search
Version: 2.0.0~rc6-1
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

I recently packaged php-zend-search as used by owncloud-search, but
owncloud is going away, see #816376. There is a priori little point to
release php-zend-search in a stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#793672: DPkg::Post-Invoke hook output gets slightly messed up when using progress bar

[Antonio Ospite]

On Thu, 3 Mar 2016 17:48:23 -0300
Tomasz Nitecki  wrote:

> retitle 793672 DPkg::Post-Invoke hook output gets slightly messed up when 
> using progress bar
> reassign 793672 apt
> thanks
> 
> 
> Hey,
>

Hi Tomasz,

> I believe that this issue is not limited to how-can-i-help, but it will 
> actually
> mess up any output coming from DPkg::Post-Invoke hook.
>

I suspected it was a more general issue, thanks for confirming it.

> Sample script that outputs a few line of text during post-invoke:
> 
> /etc/apt/apt.conf.d/99outputest:
> DPkg{Post-Invoke {"echo '1st line\n2nd line\n3rd line\n4th line'";};};
> 
> When run with progress bar, progress bar output will corrupt the script 
> output.
> 
> What's interesting, is that when run for the first time, it will work fine. 
> Only
> second and subsequent calls will corrupt output (this also applies to 
> how-can-i-help
> output corruption from the original report).
> 
> BTW, Nowadays, you can simply run 'apt ...' instead of setting 
> 'pkg::Progress-Fancy'.
> 

JFYI, the progress bar is enabled by default only for apt, it still
has to enabled explicitly using Dpkg::Progress-Fancy to also work in
apt-get and aptitude (after the fix for #816520 gets packaged).

Ciao ciao,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#816683: RFS: cloudabi-utils/0.8-1 [ITP]

[Ed Schouten]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "cloudabi-utils"
 Package name: cloudabi-utils
 Version : 0.8-1
 Upstream Author : Ed Schouten 
 URL : https://nuxi.nl/
 License : 2-clause BSD license
 Section : misc

It builds those binary packages:
 cloudabi-utils - Utilities for spawning CloudABI processes
 libcloudabi-dev - Native ports of CloudABI functions (development files)
 libcloudabi0 - Native ports of CloudABI functions (shared library)

To access further information about this package, please visit the following 
URL:
 http://mentors.debian.net/package/cloudabi-utils

Alternatively, one can download the package with dget using this command:
 dget -x 
http://mentors.debian.net/debian/pool/main/c/cloudabi-utils/cloudabi-utils_0.8-1.dsc

- End of boilerplate ;-) -

To summarize, cloudabi-utils is a package that provides a utility called
cloudabi-run that you can use to start CloudABI programs. CloudABI is a secure
POSIX-like runtime built around the concept of capability-based security.

In order to make the startup process secure, cloudabi-run cannot start the
requested program directly. It first has to jump through a tiny 'proxy' program
called cloudabi-reexec to ensure it has already entered CloudABI's sandbox.
cloudabi-reexec itself is a CloudABI program. This tool has to be built with a
cross compiler for CloudABI and linked against CloudABI's C library. All of
these components are fully BSD and MIT licensed:

- Toolchain: Clang, LLVM, LLD, Binutils
- C runtime library: LLVM's compiler-rt
- C library: https://github.com/NuxiNL/cloudlibc
- cloudabi-reexec: 
https://github.com/NuxiNL/cloudabi-ports/blob/master/packages/cloudabi-reexec/cloudabi-reexec.c

Now the problem is as follows: I don't think it's realistic that we'll be able
to build cloudabi-reexec as part of this Debian package. I don't have any
intent on including packages for CloudABI's C library in Debian, for example.
For this reason I've including a precompiled binary. The README explicitly
states where this binary came from. A package that I wrote for FreeBSD also
uses these precompiled binaries:

https://www.freshports.org/sysutils/cloudabi-utils

My question is, is this all right according to Debian's project guidelines? If
not, is there anything I can do to address this?

Thanks,
 Ed Schouten

Bug#816682: live-installer: Inaccessible utility

[Jean-Philippe MENGUAL]

Package: live-installer
Version: 49
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

I run the ;iveCD, with MATE flavour. Then I run the installer from the desktop
icon.

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

Just run orca, the screen reader. It will speak, in gnome and MATE flavours.
For instance, move on the desktop with arrow keys, you'll have the icons
spoken.

   * What was the outcome of this action?

Once run, nothing happens. Orca stays quite. Doesn't read any widget.

   * What outcome did you expect instead?

Should speak. Indeed:
- the installer is GTK-based;
- the accessibility stack is here, as the desktop is running;
- Orca, at-spi, etc are running.

So probably a "pipe" issue.

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

Best regards,


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

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

Bug#800845: autopkgtest: Add support for nested VMs

[Christian Seiler]

Hi,

replying to IRC:

>  chris_se: I think the setup should go into adt-virt-qemu, not 
> setup-testbed
>  setup-testbed is used for lxc or openstack instances too
>  and it's not a strict requirement to run it
>  chris_se: but I'm fine with mopping this up myself
>  chris_se: i. e. install the rule and call udevadm trigger to run it
>  so that it works without rebooting

So yes, I think you're right that it's better for adt-virt-qemu to
configure this, but I think we can even do it better:

 - DON'T add the drive to the qemu command
 - create the rule
 - udevadm control -R (because otherwise we might fall in the 3s
   window where udev doesn't reload the config)
 - update-initramfs -k all -u (to support reboots)
 - use qemu's monitor to add the drive

This way, the wrong symlinks will never be created (because the
drive won't exist at initial boot without the udev rule) and we can
guarantee that this doesn't cause any weird problems.

I've created a patch that does just that and tested it: with
setup-testbed from current git master it properly installs the udev
rule, *then* adds the drive, and we have:

 - /dev/baseimage exists
 - /dev/disk/by-{part,}uuid/* don't point to the baseimage disk.

Patch is attached.

Would still like to hear a comment about the CPU issue.

Regards,
Christian
From e2aaf0c2d0386d62bc9929f0b84e00cdc706c8f3 Mon Sep 17 00:00:00 2001
From: Christian Seiler 
Date: Thu, 3 Mar 2016 22:10:27 +0100
Subject: [PATCH] adt-virt-qemu: Implement support for nested base images.

This adds initial support for nested base images to be passed into the
test environment, so that nested VMs may be used in tests.

A read-only copy of the first image without the overlay is passed to
the VM with a hardware serial number BASEIMAGE. adt-virt-qemu installs
udev rules that create a symbolic link /dev/baseimage for that drive
the first time the testbed is booted. Also, the symlink priority for
that drive is lowered, because the same file system UUIDs will be
present on both the first drive and the readonly baseimage drive.

Closes: #800845
---
 debian/changelog |  4 
 virt-subproc/adt-virt-qemu   | 25 +
 virt-subproc/adt-virt-qemu.1 |  5 +
 3 files changed, 34 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 36ee620..85a5571 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 autopkgtest (3.19.4) UNRELEASED; urgency=medium
 
+  [ Martin Pitt ]
   * setup-commands/setup-testbed: Ensure that removing cruft does not remove
 cloud-init. (LP: #1539126)
   * setup-commands/setup-testbed: Purge lxd and lxc.
@@ -14,6 +15,9 @@ autopkgtest (3.19.4) UNRELEASED; urgency=medium
 lxc-start-ephemeral got deprecated by that. This now supports reboots in
 ephemeral mode.
 
+  [ Christian Seiler ]
+  * adt-virt-qemu: Implement support for nested base images. (Closes: #800845)
+
  -- Martin Pitt   Tue, 23 Feb 2016 18:21:51 +0100
 
 autopkgtest (3.19.3) unstable; urgency=medium
diff --git a/virt-subproc/adt-virt-qemu b/virt-subproc/adt-virt-qemu
index 965e3e8..d676708 100755
--- a/virt-subproc/adt-virt-qemu
+++ b/virt-subproc/adt-virt-qemu
@@ -175,6 +175,30 @@ def login_tty_and_setup_shell():
 term.send(b'\nexit\n')
 VirtSubproc.expect(term, b'\nlogout', 10)
 
+def setup_baseimage():
+'''setup /dev/baseimage in VM'''
+
+term = VirtSubproc.get_unix_socket(os.path.join(workdir, 'ttyS1'))
+
+# Setup udev rules for /dev/baseimage; set link_priority to -1024 so
+# that the duplicate UUIDs of the partitions will have no effect.
+term.send(b'''mkdir -p -m 0755 /etc/udev/rules.d ; printf '# Created by adt-virt-qemu\\n%s\\n%s\\n' 'KERNEL=="vd*[!0-9]", ENV{ID_SERIAL}=="BASEIMAGE", OPTIONS+="link_priority=-1024", SYMLINK+="baseimage", MODE="0664"' 'KERNEL=="vd*[0-9]",  ENV{ID_SERIAL}=="BASEIMAGE", OPTIONS+="link_priority=-1024"' > /etc/udev/rules.d/61-baseimage.rules\n''')
+VirtSubproc.expect(term, b'#', 10)
+# Reload udev to make sure the rules take effect (udev only auto-
+# rereads rules every 3 seconds)
+term.send(b'udevadm control -R\n')
+# Update the initramfs to include the new udev rules (to support
+# reboots properly)
+term.send(b'update-initramfs -k all -u\n')
+VirtSubproc.expect(term, b'#', 60)
+
+monitor = VirtSubproc.get_unix_socket(os.path.join(workdir, 'monitor'))
+
+# Add the base image as an additional drive
+monitor.send(('drive_add 0 file=%s,if=none,readonly=on,serial=BASEIMAGE,id=drive-baseimage\n' % args.image[0]).encode())
+VirtSubproc.expect(monitor, b'(qemu)', 10)
+monitor.send(b'device_add virtio-blk-pci,drive=drive-baseimage,id=virtio-baseimage\n')
+VirtSubproc.expect(monitor, b'(qemu)', 10)
 
 def setup_shared(shared_dir):
 '''Set up shared dir'''
@@ -501,6 +525,7 @@ def hook_open():
 # files; let QEMU run with the deleted inode
 os.unlink(overlay)
 

Bug#816681: redmine: French debconf templates translation

[Julien Patriarca]

Package: redmine
Version: N/A
Severity: wishlist
Tags: patch l10n


Please find attached the french debconf templates translation, proofread by the
debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.



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

Kernel: Linux 4.3.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
# Translation of redmine debconf templates to French
# Copyright (C) 2010 Debian French l10n team 
# This file is distributed under the same license as the redmine package.
#
# Translators:
# Jérémy Lal , 2010.
# Christian Perrier , 2010.
# Julien Patriarca , 2016
msgid ""
msgstr ""
"Project-Id-Version: redmine 0.9.0-1\n"
"Report-Msgid-Bugs-To: redm...@packages.debian.org\n"
"POT-Creation-Date: 2016-02-15 08:38-0200\n"
"PO-Revision-Date: 2016-02-22 10:22+0100\n"
"Last-Translator: Julien Patriarca \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.6.10\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: string
#. Description
#: ../templates:1001
msgid "Redmine instances to be configured or upgraded:"
msgstr "Instances Redmine qui seront configurées ou mises à jour :"

#. Type: string
#. Description
#: ../templates:1001
msgid "Space-separated list of instances identifiers."
msgstr ""
"Veuillez indiquer, séparés par des espaces, les identifiants des instances à "
"mettre à jour ou configurer. "

#. Type: string
#. Description
#: ../templates:1001
msgid ""
"Each instance has its configuration files in /etc/redmine//"
msgstr ""
"Les fichiers de configuration de chaque instance sont conservés dans /etc/"
"redmine//."

#. Type: string
#. Description
#: ../templates:1001
msgid ""
"To deconfigure an instance, remove its identifier from this list. "
"Configuration files and data from removed instances will not be deleted "
"until the package is purged, but they will be no longer managed "
"automatically."
msgstr ""
"Pour désinstaller une instance, il faut supprimer son identifiant de cette "
"liste. Les fichiers de configuration ainsi que les données des instances "
"supprimées, ne seront pas effacés tant que le paquet n'a pas été purgé, mais "
"ils ne seront plus gérés automatiquement."

#. Type: select
#. Description
#: ../templates:2001
msgid "Default redmine language:"
msgstr "Langue par défaut de Redmine :"

#~ msgid "redmine-${dbtype} package required"
#~ msgstr "Paquet redmine-${dbtype} indispensable"

#~ msgid ""
#~ "Redmine instance ${instance} is configured to use database type "
#~ "${dbtype}, but the corresponding redmine-${dbtype} package is not "
#~ "installed."
#~ msgstr ""
#~ "L'instance Redmine ${instance} est configurée pour utiliser une base de "
#~ "données de type ${dbtype}, mais le paquet correspondant redmine-${dbtype} "
#~ "n'est pas installé."

#~ msgid "Configuration of instance ${instance} is aborted."
#~ msgstr "La configuration de l'instance ${instance} est interrompue."

#~ msgid ""
#~ "To finish that configuration, please install the redmine-${dbtype} "
#~ "package, and reconfigure redmine using:"
#~ msgstr ""
#~ "Pour terminer cette configuration, veuillez installer le paquet redmine-"
#~ "${dbtype}, puis reconfigurez redmine à l'aide de la commande suivante:"

#~ msgid "dpkg-reconfigure -plow redmine"
#~ msgstr "dpkg-reconfigure -plow redmine"

#~ msgid "Redmine package now supports multiple instances"
#~ msgstr "Gestion de plusieurs instances de Redmine"

#~ msgid ""
#~ "You are migrating from an unsupported version. The current instance will "
#~ "be now called the \"default\" instance. Please check your web server "
#~ "configuration files, see README.Debian."
#~ msgstr ""
#~ "Vous êtes en train de faire migrer Redmine depuis une version non gérée. "
#~ "L'instance actuelle va désormais s'appeler « default ». Veuillez vérifier "
#~ "la configuration du serveur web en vous aidant des indications du "
#~ "fichier /usr/share/doc/redmine/README.Debian."

#~ msgid "Redmine instances to be deconfigured:"
#~ msgstr "Instances Redmine qui seront déconfigurées :"

#~ msgid "Configuration files for these instances will be removed."
#~ msgstr ""
#~ "Les fichiers de configuration pour les instances déconfigurées seront "
#~ "supprimés."

#~ msgid "Database (de)configuration will be asked accordingly."
#~ msgstr ""
#~ "La 

Bug#793672: DPkg::Post-Invoke hook output gets slightly messed up when using progress bar

[Tomasz Nitecki]

retitle 793672 DPkg::Post-Invoke hook output gets slightly messed up when using 
progress bar
reassign 793672 apt
thanks


Hey,

I believe that this issue is not limited to how-can-i-help, but it will actually
mess up any output coming from DPkg::Post-Invoke hook.

Sample script that outputs a few line of text during post-invoke:

/etc/apt/apt.conf.d/99outputest:
DPkg{Post-Invoke {"echo '1st line\n2nd line\n3rd line\n4th line'";};};

When run with progress bar, progress bar output will corrupt the script output.

What's interesting, is that when run for the first time, it will work fine. Only
second and subsequent calls will corrupt output (this also applies to 
how-can-i-help
output corruption from the original report).

BTW, Nowadays, you can simply run 'apt ...' instead of setting 
'pkg::Progress-Fancy'.


Regards,
T.




signature.asc
Description: OpenPGP digital signature

Bug#816680: debian-security-support: postinst script hangs when /etc/pam.d/su optimized

[Aide Ordi 49]

Package: debian-security-support
Version: 2015.04.04~deb7u1
Severity: wishlist

Dear Maintainer,

postinst script takes the risk to call su to invoke check-support-status
as the user 'debian-security-support', but hangs when the line
'auth sufficient pam_rootok.so' is missing or disabled in /etc/pam.d/su.

To avoid possible configuration conflict and provide a hint to sysadmin
when postinst interfere with /etc/pam.d/su rules, please add a preinst
script to the package.

For example, the script debian-security-support.preinst could look
like this:

#!/bin/sh
## Check if /etc/pam.d/su allows root to login as another user
## without prompting for password. If no, abort installation logging an
## error to help sysadmin to fix the problem.

case $1 in
  install|upgrade)
  if ! grep -qE '^\s*auth\s+sufficient\s+pam_rootok\.so' /etc/pam.d/su;
  then
echo "'auth sufficient pam_rootok.so' not found in /etc/pam.d/su" |\
logger -st "/usr/bin/dpkg --configure $DPKG_MAINTSCRIPT_PACKAGE"
exit 1
  fi
  ;;
esac

Regards,
Mederic Claassen

Bug#753809: [Debian-med-packaging] Bug#753809: ginkgocadx, orthanc and sending/receiving data

[Gert Wollny]

Hi, 

it seems is is a threading and locking problem and has nothing to do
with the actual dicom code, i.e. Orthanc is sending the move request
answer, but Ginkgo timeouts somewhere with a lock hold, and when it
finally reads the answer, Orthanc already hung up. 

My bad, because I tried to clean up threading. It will be fun to debug
this ... 

On the other hand, within Debian/jessie the dicom I used survived the
round-trip Ginkgo-Orthanc server without adding any bogus tag, i.e.
these versions seem to be okay.

Best, 
Gert 


 

Bug#785714: kexec-tools is broken when using systemd, danger of filesystem corruption

[Khalid Aziz]

On 03/03/2016 12:10 PM, Daniel Baumann wrote:
> On 2016-03-03 01:33, Khalid Aziz and Shuah Khan wrote:
>> I have not been able to reproduce this bug and that has been the
>> limiting factor in being able to fix it.
> 
> I can reliably reproduce it on unmodified, standard/default sid minimal
> install with / on raid1. i'll check tomorrow if i can also reproduce it
> without mdadm (i used to have the problem too without mdadm, but last
> checked a few weeks ago, thus rechecking to confirm).
> 

Hi Daniel,

Is this issue happening for you on jessie or sid? Your original bug
report said Debian 8.0, so I have been focusing on jessie.

--
Khalid

Bug#693230: Bug#806572: RFS: multimail/0.50~20150922-1 [ITA]

[Robert James Clay]

Hi Mattia!

On Wednesday, March 02, 2016 01:16:20 PM Mattia Rizzolo wrote:
> On Sat, Jan 09, 2016 at 10:38:47AM -0500, Robert James Clay wrote:
> > Hi Tobias!
> > 
> > On Thursday, January 07, 2016 05:54:29 AM Tobias Frost wrote:
> > > On Tue, 05 Jan 2016 18:08:55 -0500 Robert James Clay 
> > > 
> > > wrote:
> > > > On Tuesday, January 05, 2016 04:27:48 AM Tobias Frost wrote:
> [ anticipation of work that will be done... ]
> 
> How's going with this?

   I'm afraid that I got rather heavily tied up in other things and so haven't 
been able to work on this as much as I'd like...  Should I perhaps temporarily 
close the RFS bug and reopen it when I have an updated version of the package 
done and uploaded to mentors?  (Note that the next package update will also 
include a new snapshot.)


> Several weeks passed and we haven't heard back from you, this is just a
> gentle ping :)

   And I appreciate that!





RJ Clay
j...@rocasa.us

Bug#815734: ess: FTBFS: doc/newfeat.texi:29: Argument of @gobblespaces has an extra }.

[Martin Maechler]

Thanks a lot, Dirk (and Kurt) !
Martin

On Thu, Mar 3, 2016 at 2:41 PM, Dirk Eddelbuettel  wrote:
>
> Ok, the obvious fix of fattening the source directory with a working copy of
> texinfo.tex did the trick.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> ___
> ESS-Debian mailing list
> ess-deb...@r-project.org
> https://stat.ethz.ch/mailman/listinfo/ess-debian
>

Bug#816679: icedove: Please rename icedove to thunderbird

[Sylvestre Ledru]

Package: icedove
Severity: normal

Just like with bug #815006, the same will happen for Thunderbird.

The rationale is the same as for Iceweasel. The main difference
is that Thunderbird is now a community-driven project.
R. Kent James, Chair, Thunderbird Council, agrees that Icedove changes
and track records matches the expectations of the Thunderbird Council.

Just like with Iceweasel, the packaging work is excellent,
patches are forwarded upstream when relevant, the specific patches
applied to Icedove are clean and makes sense.

There is no reason to keep the icedove branding.

Sylvestre

Bug#816357: jedit: FTBFS: XThis.java:128: error: cannot find symbol [..] NotSerializableException

[Markus Koschany]

Am 03.03.2016 um 05:03 schrieb tony mancill:
> Control: -1 tag  + confirmed
> Control: -1 owner tmanc...@debian.org
> 
> On 02/29/2016 11:05 PM, Chris Lamb wrote:
>> Source: jedit
>> Version: 5.3.0+dfsg-1
>> Severity: serious
>> Justification: fails to build from source
> 
>>   [javac] 
>> /home/lamby/temp/cdt.20160301065925.cu0iTWjXkj/jedit-5.3.0+dfsg/org/gjt/sp/jedit/bsh/XThis.java:128:
>>  error: cannot find symbol
>>   [javac]throw new NotSerializableException();
> 
> Thanks for the bug report.  Looks like we have a bit of porting for the
> latest bsh upload.
> 

Sorry for the inconvenience. If there is more involved than importing
the missing class, please let me know and I try to fix it.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#813916: transition: gdal

[Sebastiaan Couwenberg]

On 03-03-16 20:13, Sebastiaan Couwenberg wrote:
> On 03-03-16 19:12, Emilio Pozuelo Monfort wrote:
>> On 01/03/16 20:18, Sebastiaan Couwenberg wrote:
>>> On 01-03-16 19:50, Emilio Pozuelo Monfort wrote:
 On 19/02/16 14:08, Sebastiaan Couwenberg wrote:
> On 12-02-16 19:05, Emilio Pozuelo Monfort wrote:
>> On 12/02/16 18:52, Sebastiaan Couwenberg wrote:
>>> On 12-02-16 18:28, Emilio Pozuelo Monfort wrote:
 On 06/02/16 17:43, Bas Couwenberg wrote:
> Package: release.debian.org
> For the Debian GIS team I'd like to transition to the recently 
> released
> GDAL 1.11.4. Only the packages using C++ symbols need to be rebuilt.
>
> GDAL 2.0.2 was released along with 1.11.4, but we still don't have
> support for GDAL 2.0 in all reverse dependencies. Since the transition
> to GDAL 1.11.3, support for GDAL 2.0 was added to all reverse
> depedencies except Fiona [0]. Upstream has recently included changes 
> for
> GDAL 2.0, but these differ from the initial GDAL 2.0 changes available
> as a patch in #802808. The improved GDAL 2.0 changes are entangled 
> with
> other changes for the upcoming Fiona 1.7 release, which I've not been
> able to successfully backport. This will not be a blocker for the GDAL
> 2.0 transition, as discussed with the maintainer on the debian-gis 
> list
> [1].
>
> Because the transition for GDAL 1.11.4 is ready now, I'd like to do 
> that
> first before preparing the transition to GDAL 2.0. All reverse
> dependencies rebuilt successfully with GDAL 1.11.4, the summary of
> rebuilds is included below.
>

 This would get entangled with the openmpi transition, so it will have 
 to wait.
 After openmpi, I'm thinking about doing libpng, but we'll see.
>>>
>>> Waiting for openmpi is no problem, but if the libpng transition is going
>>> to happen first, I think it's better to use that time the prepare the
>>> transition to GDAL 2.0 instead of 1.11.4. Last week the last blocker was
>>> resolved [0], so we're also pretty much ready to transition to GDAL 2.0.
>>> The 2.0 packages will have to pass the NEW queue again, because of the
>>> delay that will cause I've opted to transition to 1.11.4 which is ready 
>>> now.
>>>
>>> If you can confirm that the libpng transition is going to happen first,
>>> I'll upload the packages for GDAL 2.0 to experimental, and we can switch
>>> to that in unstable after the libpng transition and the new gdal has
>>> passed NEW.
>>
>> Sure, let's do that.
>
> The GDAL 2.0.2 packages are available in experimental and ready for
> transition.
>
> libgdal-grass (2.0.2-1) not available in experimental yet, liblas and
> grass need to be rebuilt with GDAL 2.0 before it can be built too,
> because the SOVERSION is included in the binary package it builds the
> package will have to pass the NEW queue after upload first. To get it
> passed the NEW queue, I'll rebuild liblas & grass with gdal
> (2.0.2-1-1~exp2) from experimental and upload all three to experimental 
> too.
>
> All reverse dependencies build successfully with GDAL 2.0.
>
>
> Transition: gdal
>
>  libgdal1i (1.11.3+dfsg-3) -> libgdal20 (2.0.2+dfsg-1)
>  libgdal.so.1-1.11.3   -> gdal-abi-2-0-2
>
> The status of the most recent rebuilds is as follows.
>
>  dans-gdal-scripts (0.23-4)   OK
>  fiona (1.6.3-2)  OK
>  gazebo(6.5.0+dfsg-2) OK
>  gmt   (5.2.1+dfsg-3) OK
>  imposm(2.6.0+ds-2)   OK
>  libcitygml(2.0-1)OK
>  liblas(1.8.0-7)  OK
>  libosmium (2.6.0-1)  OK
>  mapcache  (1.4.0-4)  OK
>  mapnik(3.0.9+ds-1)   OK
>  mapserver (7.0.0-9)  OK
>  merkaartor(0.18.2-5) OK
>  mysql-workbench   (6.3.4+dfsg-3) OK
>  ncl   (6.3.0-6)  OK
>  node-srs  (0.4.8+dfsg-2) OK
>  openscenegraph(3.2.1-9)  OK
>  osmium(0.0~20160124-b30afd3-1)   OK
>  osrm  (4.9.1+ds-1~exp2)  OK
>  postgis   (2.2.1+dfsg-2) OK
>  pprepair  (0.0~20150624-82a2019-1)   OK
>  prepair   (0.7-4)OK
>  qlandkartegt  (1.8.1+ds-4)   OK
>  

Bug#737498: [PATCH v2] patch: when importing from email, RFC2047-decode From/Subject headers

[Julien Cristau]

On Thu, Mar  3, 2016 at 12:49:22 -0600, Matt Mackall wrote:

> On Thu, 2016-03-03 at 18:55 +0100, Julien Cristau wrote:
> > # HG changeset patch
> > # User Julien Cristau 
> > # Date 1457026459 -3600
> > #  Thu Mar 03 18:34:19 2016 +0100
> > # Node ID 6c153cbad4a032861417dbba9d1d90332964ab5f
> > # Parent  549ff28a345f595cad7e06fb08c2ac6973e2f030
> > patch: when importing from email, RFC2047-decode From/Subject headers
> > 
> > I'm not too sure about the Subject part: it should be possible to use
> > the charset information from the email (RFC2047 encoding and the
> > Content-Type header), but mercurial seems to use its own encoding
> > instead (in the test, that means the commit message ends up as ""
> > if the import is done without --encoding utf-8).  Advice welcome.
> > 
> > Reported at https://bugs.debian.org/737498
> 
> You should probably immediately relay such reports upstream.
> 
Indeed.  I spent some time tidying https://bugs.debian.org/src:mercurial
today, and out of the remaining bugs (other than this one), one is a
packaging issue, three are 6 year old zeroconf extension issues (I know
nothing of that extension), another one is a 6 year old demandimport
performance issue which should probably just be closed at this point,
and the rest are either already forwarded to hg bz, or marked wontfix.

New attempt at a fix below which should address your comments, changes
in v2:
- moved decoding to new mercurial.mail.headdecode function
- fall back to utf-8 and latin1 instead of ascii
- rename parts variable to uparts as it contains unicode objects

Thanks,
Julien

# HG changeset patch
# User Julien Cristau 
# Date 1457026459 -3600
#  Thu Mar 03 18:34:19 2016 +0100
# Node ID 981e5fd56a9973e0069173b5f6c03639d9e176aa
# Parent  e00e57d836535aadcb13337613d2f891492d8e04
patch: when importing from email, RFC2047-decode From/Subject headers

Reported at https://bugs.debian.org/737498

diff --git a/mercurial/mail.py b/mercurial/mail.py
--- a/mercurial/mail.py
+++ b/mercurial/mail.py
@@ -332,3 +332,21 @@ def mimeencode(ui, s, charsets=None, dis
 if not display:
 s, cs = _encode(ui, s, charsets)
 return mimetextqp(s, 'plain', cs)
+
+def headdecode(s):
+'''Decodes RFC-2047 header'''
+uparts = []
+for part, charset in email.Header.decode_header(s):
+if charset is not None:
+try:
+uparts.append(part.decode(charset))
+continue
+except UnicodeDecodeError:
+pass
+try:
+uparts.append(part.decode('UTF-8'))
+continue
+except UnicodeDecodeError:
+pass
+uparts.append(part.decode('ISO-8859-1'))
+return encoding.tolocal(u' '.join(uparts).encode('UTF-8'))
diff --git a/mercurial/patch.py b/mercurial/patch.py
--- a/mercurial/patch.py
+++ b/mercurial/patch.py
@@ -31,6 +31,7 @@ from . import (
 diffhelpers,
 encoding,
 error,
+mail,
 mdiff,
 pathutil,
 scmutil,
@@ -210,8 +211,8 @@ def extract(ui, fileobj):
 try:
 msg = email.Parser.Parser().parse(fileobj)
 
-subject = msg['Subject']
-data['user'] = msg['From']
+subject = msg['Subject'] and mail.headdecode(msg['Subject'])
+data['user'] = msg['From'] and mail.headdecode(msg['From'])
 if not subject and not data['user']:
 # Not an email, restore parsed headers if any
 subject = '\n'.join(': '.join(h) for h in msg.items()) + '\n'
diff --git a/tests/test-import-git.t b/tests/test-import-git.t
--- a/tests/test-import-git.t
+++ b/tests/test-import-git.t
@@ -822,4 +822,27 @@ Test corner case involving copies and mu
   > EOF
   applying patch from stdin
 
+Test email metadata
+
+  $ hg revert -qa
+  $ hg --encoding utf-8 import - < From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
+  > Subject: [PATCH] =?UTF-8?q?=C5=A7=E2=82=AC=C3=9F=E1=B9=AA?=
+  > 
+  > diff --git a/a b/a
+  > --- a/a
+  > +++ b/a
+  > @@ -1,1 +1,2 @@
+  >  a
+  > +a
+  > EOF
+  applying patch from stdin
+  $ hg --encoding utf-8 log -r .
+  changeset:   2:* (glob)
+  tag: tip
+  user:Rapha\xc3\xabl Hertzog  (esc)
+  date:* (glob)
+  summary: \xc5\xa7\xe2\x82\xac\xc3\x9f\xe1\xb9\xaa (esc)
+  
+
   $ cd ..

Bug#816678: Useless in Debian

[David Prévot]

Package: php-cssmin
Version: 3.0.4-1
Severity: serious


[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

I recently packaged php-cssmin  as used by owncloud, but owncloud is
going away, see #816376. There is a priori little point to release
php-cssmin in a stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#816677: Useless in Debian

[David Prévot]

Package: php-pdfparser
Version: 0.9.25+dfsg-1
Severity: serious


[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

I recently packaged php-pdfparser as used by owncloud-search, but
owncloud is going away, see #816376. There is a priori little point to
release php-pdfparser in a stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David



signature.asc
Description: PGP signature

Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11

[Jose M Calhariz]

One more iteration.

On 01/03/16 22:35, Mattia Rizzolo wrote:
> On Tue, Mar 01, 2016 at 09:11:58PM +, Jose M Calhariz wrote:
>> On 28/02/16 23:00, Mattia Rizzolo wrote:
>>> On Wed, Feb 24, 2016 at 09:41:32PM +, Jose M Calhariz wrote:
>>> * I just noticed sawfish.preinst removes /var/lib/sawfish that you are
>>>   creating in sawfish.dirs.  ???
>> I believe the directory /var/lib/sawfish is necessary.  So cleaning
>> sawfish.preinst
> ok.
>
>>> * in d/rules, is the ACLOCAL variable still needed?  if not get rid of
>>>   it (test building without works)
>> I tried to used automake instead of automake1.11 and worked for my
>> machine (i386).
> As a QA guy I like when I see old stuff being dropped from the archive,
> so also avoiding hardcoding and fixing with automake1.11 will also help
> remove automake1.11 when the time will come :)
>
>>> after this, back to what lintian knows:
>>>
>>> * spelling-error-in-changelog unusuable unusable
>> This is a misspell on the bug report title, so preserving the error and
>> add an lintian-override for it.
> brr, how ugly!
>
> no, please revert that commit, retitle the bug report if you care and
> fix the typo in the changelog.  Also, there is no need at all that the
> changelog entries for bug fix are the same of the bug reports...
> Surely the most nice thing would be to retitle the bug report and fix
> the changelog, adding a lintian override is just plain wrong here.

I misread the title of the bug report, so you are right.


>> I will work on the following tomorrow.
> Thanks for showing the progress, appreciated as usual :)
>
>>> * non-empty-dependency_libs-in-la-file + incorrect-libdir-in-la-file
>>>   these are caused just because of a typo in the target name of
>>>   override_dh_auto_install; I'll let you discover the typo and fix it.

Done.

>>> * sawfish: maintainer-script-without-set-e (all the maintscripts)

I don't get that error and my lintian is updated.

>>> * sawfish-lisp-source: script-not-executable 
>>> usr/share/sawfish/lisp/sawfish/cfg/main.jl
>>>   there actually is an override, but the file is named wrongly and so
>>>   not picked up by dh_lintian.  maybe you also want to add an override
>>>   for the sawfish-data one.

Done

>
>




signature.asc
Description: OpenPGP digital signature

Bug#813359: xserver-xorg-input-aiptek: Compilation fails due to API change in xorg

[Tobias Schlemmer]

Package: xserver-xorg-input-aiptek
Version: 1:1.4.1-1
Followup-For: Bug #813359

Hi,

I got the driver to get compiled. The extra arguments are not used any more and
have been removed from xorg.

I attach a patch that soves the  problem.





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

lrwxrwxrwx 1 root root 13 Feb  4  2012 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Feb  9 12:12 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-
diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-
diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-
diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted
/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-
diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-
diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-
diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-
diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-
diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-
diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-
diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-
diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib
/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0
by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-
diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-
diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-
diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-
diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-
diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-
diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to /usr/lib/mesa-
diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so
by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-
diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386
-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-
diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted
/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-
diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1 to /usr/lib/mesa-
diverted/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-
diverted/x86_64-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-
diverted/x86_64-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-
diverted/i386-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to /usr/lib/mesa-
diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-
diverted/x86_64-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of 

Bug#810968: [debian-mysql] Bug#810968: Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)

[Otto Kekäläinen]

Hello Lennart!

I asked core developers to review this and got this reply:

  It's probably alright for 10.0. But it's not completely suitable for 10.1.
  As contributor mentioned himself that there's a problem with this patch:
  "When mysqld is called without mysqld_safe".

  I'd rather simplify this script to something like (not tested):
  if [ -x /var/run/mysqld/mysqld.pid ]; then
$MYADMIN flush-logs || exit 1
  fi

What do you think?

I know your patch would fix an identified issue, but I am also afraid
of any regressions that might be introduced due to this very central
init file change, so I won't be including your patch just yet.

Bug#816676: Useless in Debian

[David Prévot]

Package: php-dropbox
Version: 1.0.0-4
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

I packaged php-dropbox as used by owncloud, but owncloud is going away,
see #816376. There is a priori little point to release php-dropbox in a
stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#780940: hdparm freezes the system's start up

[Alex Mestiashvili]

Dear Víctor,
do you have a chance to test the new upstream release of hdparm ? it is not
yet in the Debian distribution, but the source is available here:

 http://anonscm.debian.org/cgit/collab-maint/hdparm.git

You will need to clone the repository and build the package.

Thank you in advance,
Alex

Bug#816635: RFS: memtailor/1.0~git20160302-1

[Anton Gladky]

Uploaded.


2016-03-03 16:44 GMT+01:00 Doug Torrance :

> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
>   I am looking for a sponsor for my package "memtailor"
>
>  * Package name: memtailor
>Version : 1.0~git20160302-1
>Upstream Author : Bjarke Hammersholt Roune 
>  * URL : https://github.com/Macaulay2/memtailor
>  * License : BSD-3-clause
>Section : libs
>
>   It builds those binary packages:
>
>   libmemtailor-dev - C++ library of special purpose memory allocators
> (developer tools
>   libmemtailor0 - C++ library of special purpose memory allocators (shared
> library)
>
>   To access further information about this package, please visit the
> following URL:
>
>   http://mentors.debian.net/package/memtailor
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x
> http://mentors.debian.net/debian/pool/main/m/memtailor/memtailor_1.0~git20160302-1.dsc
>
>   Or, via git:
>
> https://anonscm.debian.org/git/debian-science/packages/memtailor.git
>
>   Changes since the last upload:
>
>   memtailor (1.0~git20160302-1) unstable; urgency=medium
>
> * New upstream release.
>   - Now maintained by Macaulay2 developers.
> * debian/control
>   - Bump Standards-Version to 3.9.7.
>   - Update Homepage.
>   - Use https protocol for Vcs-Browser.
>   - Drop libmemtailor-dbg package in favor of automatically generated
> memtailor-dbgsym.
> * debian/copyright
>   - Update Source.
> * debian/libmemtailor0.symbols
>   - Add MEMTAILOR_VERSION_STRING.
> * debian/patches
>   - Remove directory; patches applied upstream.
> * debian/rules
>   - Remove override_dh_strip target; no longer needed.
>   - Update get-orig-source target.
>   - Update GTEST_PATH in override_dh_auto_configure target.
>   - Add --enable-shared to override_dh_auto_configure target.
>   - Enable all hardening flags.
>
>-- Doug Torrance   Thu, 03 Mar 2016 09:11:23
> -0500
>
>   Regards,
>Doug Torrance
>
>

Bug#816675: Useless in Debian

[David Prévot]

Package: php-streams
Version: 0.2-1
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]


I recently packaged php-streams as used by owncloud, but owncloud is
going away, see #816376. There is a priori little point to release
php-streams in a stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#816674: Useless in Debian

[David Prévot]

Package: php-patchwork-jsqueeze
Version: 2.0.3-1
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

I recently packaged php-patchwork-jsqueeze as used by owncloud, but
owncloud is going away, see #816376. There is a priori little point to
release php-patchwork-jsqueeze in a stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#816673: Useless in Debian

[David Prévot]

Package: php-kit-pathjoin
Version: 1.1.2-1
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

I recently packaged php-kit-pathjoin as used by owncloud-news, but
owncloud is going away, see #816376. There is a priori little point to
release php-kit-pathjoin in a stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#816671: krfb does not save all settings in config file

[Jürgen Bausa]

Package: krfb
Version: 4:4.14.2-1
Severity: important

Dear Maintainer,

I configured krfb to be enabled and specified a password for access. However, 
next time krfb
starts up, it is disabled again. This i very anoying as I run krfb as 
autostart. I can only
use it, if manually enable it on every log-in.

The version from wheezy did not have this problem.

The bug is also reported at:

https://bugs.kde.org/show_bug.cgi?id=340411

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

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

Versions of packages krfb depends on:
ii  kde-runtime4:4.14.2-2
ii  libc6  2.19-18+deb8u3
ii  libkdecore54:4.14.2-5
ii  libkdeui5  4:4.14.2-5
ii  libkdnssd4 4:4.14.2-5
ii  libktpcommoninternalsprivate7  0.8.1-4
ii  libktpmodelsprivate7   0.8.1-4
ii  libktpwidgetsprivate7  0.8.1-4
ii  libqt4-dbus4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtgui4  4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libstdc++6 4.9.2-10
ii  libtelepathy-qt4-2 0.9.4+dfsg-3
ii  libvncserver0  0.9.9+dfsg2-6.1+deb8u1
ii  libx11-6   2:1.6.2-3
ii  libxdamage11:1.1.4-2+b1
ii  libxext6   2:1.3.3-1
ii  libxtst6   2:1.2.2-1+b1

krfb recommends no packages.

Versions of packages krfb suggests:
ii  khelpcenter4  4:4.14.2-2
ii  krdc  4:4.14.1-1

-- no debconf information

Bug#816670: synaptic: Please make Synaptic better accessible

[Jean-Philippe MENGUAL]

Package: synaptic
Version: 0.83+b1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I try Synaptic to remove more easily a suite (libreoffice). I use it on MATE, 
Orca. 

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

1. Enter libreoffice in the field.
2. Run the search 
3. With tab, move to the table displaying the results.
4. Move between columns /ith left arrow key.
5. 1st column: the package status (I guess); shen the column where the!e's the
packages name.

   * What was the outcome of this action?

Between 1st and this column, Orca doesn't say any relevant info. I hear "Image".

   * What outcome did you expect instead?

Should say if the package is marked and more explicitly its status (installed,
removed, etc). For this, just bind labels to widgets.

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

Thanks,

Regards,

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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.13-1
ii  libapt-inst2.0   1.2.3
ii  libapt-pkg5.01.2.3
ii  libatk1.0-0  2.18.0-1
ii  libc62.21-9
ii  libcairo-gobject21.14.6-1
ii  libcairo21.14.6-1
ii  libept1.5.0  1.1+nmu3
ii  libgcc1  1:5.3.1-8
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libglib2.0-0 2.46.2-3
ii  libgnutls30  3.4.9-2
ii  libgtk-3-0   3.18.8-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libstdc++6   5.3.1-8
ii  libvte-2.91-00.42.4-1
ii  libx11-6 2:1.6.3-1
ii  libxapian22v51.2.22-3
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages synaptic recommends:
ii  libgtk2-perl   2:1.2498-1
ii  policykit-10.105-14.1
ii  rarian-compat  0.8.1-6
ii  xdg-utils  1.1.1-1

Versions of packages synaptic suggests:
pn  apt-xapian-index 
ii  deborphan1.7.28.8-0.3
pn  dwww 
ii  menu 2.1.47
pn  software-properties-gtk  
ii  tasksel  3.34

-- no debconf information

Bug#816669: libc6 causes crash of IRSSI due to IPv6

[Loke_AF]

Package: libc6
Version: 2.19-18+deb8u3
Severity: important

Dear Maintainer,

this is my first bug report so apologies in advance if I mess (have messed) 
something.

IRRSI 0.8.17 started crashing with: "res_query.c:262: __libc_res_nquery: 
Assertion `(hp != ((void )0)) && (hp2 != ((void )0))' failed."
Problem persisted on every restart of IRSSI after 2 - 35min at random.

The condition that triggered it was "an IPv6 address was configured but no 
default route was available".
Once IPv6 was properly working again, the problem dissappeared.

Contents of /etc/resolv.conf:
search ovh.net
nameserver 2001:41d0:3:1c7::1
nameserver 213.186.33.99



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

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

Versions of packages libc6 depends on:
ii  libgcc1  1:4.9.2-10

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.56
pn  glibc-doc  
ii  locales-all [locales]  2.19-18+deb8u3

-- debconf information:
  glibc/upgrade: true
  glibc/restart-failed:
* libraries/restart-without-asking: true
  glibc/disable-screensaver:
  glibc/restart-services: vsftpd postfix cron

Bug#808125: Re : Bug #808125 - libreoffice-base: c/p from calc to create table, character_data does not exist on postgresql

[Stéphane Aulery]

Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ac2505632c96b2653aea2d65178053d1ad9430ef

tdf#92538 use proper schema name for type names

It will be available in 5.2.0.

--
Stéphane Aulery

Bug#816668: RM: spork -- ROM; obsoleted by rails4 / ruby-spring; dead upstream

[Christian Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

spork was a preloading rspec runner. The rails community has moved
on to use "spring", which more or less does the same thing but is
"officially sanctioned".

spork upstream development appears to have ceased in 2014 and we
think it's been broken by rails 4.

Once this bug reaches you, all rdeps should be gone from unstable.

Please remove it from unstable.

Thanks,
Christian
(wearing my pkg-ruby-extras hat)

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#816667: www.debian.org: please make the documentation from dbconfig-common available

[Paul Gevers]

Package: www.debian.org
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

As suggested by Paul Wise in a response to an e-mail to debian-admin@l.d.o, I
would like to have the content that currently lives here:
https://people.debian.org/~seanius/policy/dbapp-policy.html/
https://people.debian.org/~seanius/policy/dbconfig-common.html/
https://people.debian.org/~seanius/policy/dbconfig-common-design.html
to be extracted from the dbconfig-common binary package and made available on
https://www.debian.org/doc/devel-manuals or in the ../packaging-manuals. The
current webpages are out-dated and seanius is retired from Debian so won't
update anymore.

The documentation can be found at
/usr/share/doc/dbconfig-common/dbapp-policy.html/
/usr/share/doc/dbconfig-common/dbconfig-common.html/
/usr/share/doc/dbconfig-common/dbconfig-common-design.html
when one has installed the dbconfig-common package. There are also pdf and ps
versions available.

Thanks in advance.

Paul

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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJW2JPFAAoJEJxcmesFvXUKV+IH/1N4XjAzTdwtvo7c9DtormTA
1X3OKNh5/xxBCVj0T4V2LiTGultJxbcyIQ5QAd+H/iYuCFVJoFhXXg3K4JXg3V0e
nTvz637qO2/OZDQHYSuoVb24VGqCRxFhod50N19kzHV3iUbbGfJNPOHJUV4HcPK+
ZUxi1cIj3VykJBzMVneZoeP+60oLteWVTMC1c9UruEi6I960Oy6ZPqEAH/UyIOJ+
091eJqy3eSMQgYjHDEgqlJXxXZCNr1/rjuwWGZdrNy5FM3hLRzECUiIu8fc6miWc
Qwssm5eBu/774QsGQhS5Af3v+XPiujpofFCnAj2lJKTHB8WJpUQk+BqYcMg+t0M=
=FbFM
-END PGP SIGNATURE-

Bug#760591: Close 760591 760869

[Stéphane Aulery]

Le 03/03/2016 19:54, Stéphane Aulery a écrit :


Le 03/03/2016 18:43, B a écrit :

On Thu, 3 Mar 2016 18:27:19 +0100 (CET)
Stéphane Aulery  wrote:

I too can't reproduce it in 5.0.5.2; IIRC, it was fixed 2 versions
away from the one of the bug report.


Ok. I close them.

--
Stéphane Aulery

Bug#811377: Adopting Sysvinit

[Simon Richter]

Hi,

On 01.03.2016 16:20, Ben Hutchings wrote:

>> Could you please grant me the upload permission?  I am in the Debian
>> maintainer database with key 8E192076 and fingerprint:

>>   C3A5 0484 0B67 8260 DA12  766A D25D 611C 8E19 2076

> I'm not a maintainer for sysvinit, so I leave the decision to the
> previous maintainers.

It seems Ben's mail didn't make it to the maintainers' mailing list. I'm
going to poke a few people individually now.

   Simon



signature.asc
Description: OpenPGP digital signature

Bug#816666: Useless in Debian

[David Prévot]

Package: php-securitylib
Version: 1.0.0-1
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

I recently packaged php-securitylib as used by php-randomlib, as used by
owncloud, but owncloud is going away, see #816376 (so is php-randomlib,
see #816658). There is a priori little point to release php-securitylib
in a stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#816665: Useless in Debian

[David Prévot]

Package: php-punic
Version: 1.6.3-1
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

I recently packaged php-punic as used by owncloud, but owncloud is going
away, see #816376.  There is a priori little point to release php-punic
in a stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#816664: Useless in Debian

[David Prévot]

Package: libjs-soundmanager2
Version: 2.97a.20150601+dfsg-1
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing. ]

I recently packaged libjs-soundmanager2 as used by owncloud-music, but
owncloud is going away, see #816376. There is a priori little point to
release libjs-soundmanager2 in a stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#816663: linux-image-4.4.0-1-amd64: fails to suspend. xfs filesystem blocks suspend.

[Anders Hammarquist]

Package: src:linux
Version: 4.4.2-3
Severity: important

xfs updates in 4.4 cause suspend to fail. See discussion at
http://www.linuxquestions.org/questions/slackware-14/unable-to-suspend-or-hibernate-with-a-4-4-0-kernel-4175563710/

-- Package-specific info:
** Version:
Linux version 4.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160205 (Debian 5.3.1-8) ) #1 SMP Debian 4.4.2-3 (2016-02-21)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.4.0-1-amd64 root=/dev/mapper/vg0-root ro 
usbcore.autosuspend=1

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[ 2922.813564]  81585bc1  a040b2cf 
8802311c6740
[ 2922.813573] Call Trace:
[ 2922.813580]  [] ? schedule+0x31/0x80
[ 2922.813639]  [] ? xfsaild+0x5af/0x600 [xfs]
[ 2922.813648]  [] ? __schedule+0x2e8/0x900
[ 2922.813707]  [] ? xfs_trans_ail_cursor_first+0x90/0x90 
[xfs]
[ 2922.813715]  [] ? kthread+0xcd/0xf0
[ 2922.813723]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.813729]  [] ? ret_from_fork+0x3f/0x70
[ 2922.813737]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.813743] xfsaild/dm-10   S 0001 0   856  2 0x
[ 2922.813751]  880231674200 8800ba68ef40 880231518000 
880231517ec8
[ 2922.813759]  880231674200  88022e368c40 

[ 2922.813767]  81585bc1  a040b2cf 
880231674200
[ 2922.813775] Call Trace:
[ 2922.813782]  [] ? schedule+0x31/0x80
[ 2922.813842]  [] ? xfsaild+0x5af/0x600 [xfs]
[ 2922.813850]  [] ? __schedule+0x2e8/0x900
[ 2922.813910]  [] ? xfs_trans_ail_cursor_first+0x90/0x90 
[xfs]
[ 2922.813917]  [] ? kthread+0xcd/0xf0
[ 2922.813925]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.813931]  [] ? ret_from_fork+0x3f/0x70
[ 2922.813939]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.813944] xfsaild/dm-12   S 0001 0   865  2 0x
[ 2922.813952]  8800ba68ef40 8800ba68e340 8800ba624000 
8800ba623ec8
[ 2922.813960]  8800ba68ef40  880231501840 

[ 2922.813968]  81585bc1  a040b2cf 
8800ba68ef40
[ 2922.813977] Call Trace:
[ 2922.813985]  [] ? schedule+0x31/0x80
[ 2922.814044]  [] ? xfsaild+0x5af/0x600 [xfs]
[ 2922.814052]  [] ? __schedule+0x2e8/0x900
[ 2922.814112]  [] ? xfs_trans_ail_cursor_first+0x90/0x90 
[xfs]
[ 2922.814119]  [] ? kthread+0xcd/0xf0
[ 2922.814127]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814133]  [] ? ret_from_fork+0x3f/0x70
[ 2922.814141]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814146] xfsaild/dm-4S 0001 0   866  2 0x
[ 2922.814153]  8800ba68e340 8800ba62c540 8802312d 
8802312cfec8
[ 2922.814161]  8800ba68e340  8800ba2b0cc0 

[ 2922.814169]  81585bc1  a040b2cf 
8800ba68e340
[ 2922.814178] Call Trace:
[ 2922.814185]  [] ? schedule+0x31/0x80
[ 2922.814244]  [] ? xfsaild+0x5af/0x600 [xfs]
[ 2922.814252]  [] ? __schedule+0x2e8/0x900
[ 2922.814312]  [] ? xfs_trans_ail_cursor_first+0x90/0x90 
[xfs]
[ 2922.814320]  [] ? kthread+0xcd/0xf0
[ 2922.814328]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814334]  [] ? ret_from_fork+0x3f/0x70
[ 2922.814342]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814348] xfsaild/dm-14   S 0001 0   914  2 0x
[ 2922.814356]  8800ba62c540 88023128b180 8800ba56 
8800ba55fec8
[ 2922.814364]  8800ba62c540  880231534b40 

[ 2922.814372]  81585bc1  a040b2cf 
8800ba62c540
[ 2922.814380] Call Trace:
[ 2922.814387]  [] ? schedule+0x31/0x80
[ 2922.814446]  [] ? xfsaild+0x5af/0x600 [xfs]
[ 2922.814454]  [] ? __schedule+0x2e8/0x900
[ 2922.814514]  [] ? xfs_trans_ail_cursor_first+0x90/0x90 
[xfs]
[ 2922.814522]  [] ? kthread+0xcd/0xf0
[ 2922.814530]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814536]  [] ? ret_from_fork+0x3f/0x70
[ 2922.814544]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814548] xfsaild/dm-6S 88023bd15900 0   915  2 0x
[ 2922.814556]  88023128b180 880232234d80 880231144000 
880231143ec8
[ 2922.814564]  88023128b180  880231534bc0 
881f9800
[ 2922.814572]  81585bc1  a040b2cf 
88023128b180
[ 2922.814580] Call Trace:
[ 2922.814588]  [] ? schedule+0x31/0x80
[ 2922.814647]  [] ? xfsaild+0x5af/0x600 [xfs]
[ 2922.814708]  [] ? xfs_trans_ail_cursor_first+0x90/0x90 
[xfs]
[ 2922.814716]  [] ? kthread+0xcd/0xf0
[ 2922.814723]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814730]  [] ? ret_from_fork+0x3f/0x70
[ 2922.814737]  [] ? kthread_create_on_node+0x190/0x190

[ 2922.814786] Restarting kernel threads ... done.
[ 2922.815680] Restarting tasks ... done.
[ 2922.870902] video LNXVIDEO:00: Restoring backlight state
[ 

Bug#813916: transition: gdal

[Sebastiaan Couwenberg]

On 03-03-16 19:12, Emilio Pozuelo Monfort wrote:
> On 01/03/16 20:18, Sebastiaan Couwenberg wrote:
>> On 01-03-16 19:50, Emilio Pozuelo Monfort wrote:
>>> On 19/02/16 14:08, Sebastiaan Couwenberg wrote:
 On 12-02-16 19:05, Emilio Pozuelo Monfort wrote:
> On 12/02/16 18:52, Sebastiaan Couwenberg wrote:
>> On 12-02-16 18:28, Emilio Pozuelo Monfort wrote:
>>> On 06/02/16 17:43, Bas Couwenberg wrote:
 Package: release.debian.org
 For the Debian GIS team I'd like to transition to the recently released
 GDAL 1.11.4. Only the packages using C++ symbols need to be rebuilt.

 GDAL 2.0.2 was released along with 1.11.4, but we still don't have
 support for GDAL 2.0 in all reverse dependencies. Since the transition
 to GDAL 1.11.3, support for GDAL 2.0 was added to all reverse
 depedencies except Fiona [0]. Upstream has recently included changes 
 for
 GDAL 2.0, but these differ from the initial GDAL 2.0 changes available
 as a patch in #802808. The improved GDAL 2.0 changes are entangled with
 other changes for the upcoming Fiona 1.7 release, which I've not been
 able to successfully backport. This will not be a blocker for the GDAL
 2.0 transition, as discussed with the maintainer on the debian-gis list
 [1].

 Because the transition for GDAL 1.11.4 is ready now, I'd like to do 
 that
 first before preparing the transition to GDAL 2.0. All reverse
 dependencies rebuilt successfully with GDAL 1.11.4, the summary of
 rebuilds is included below.

>>>
>>> This would get entangled with the openmpi transition, so it will have 
>>> to wait.
>>> After openmpi, I'm thinking about doing libpng, but we'll see.
>>
>> Waiting for openmpi is no problem, but if the libpng transition is going
>> to happen first, I think it's better to use that time the prepare the
>> transition to GDAL 2.0 instead of 1.11.4. Last week the last blocker was
>> resolved [0], so we're also pretty much ready to transition to GDAL 2.0.
>> The 2.0 packages will have to pass the NEW queue again, because of the
>> delay that will cause I've opted to transition to 1.11.4 which is ready 
>> now.
>>
>> If you can confirm that the libpng transition is going to happen first,
>> I'll upload the packages for GDAL 2.0 to experimental, and we can switch
>> to that in unstable after the libpng transition and the new gdal has
>> passed NEW.
>
> Sure, let's do that.

 The GDAL 2.0.2 packages are available in experimental and ready for
 transition.

 libgdal-grass (2.0.2-1) not available in experimental yet, liblas and
 grass need to be rebuilt with GDAL 2.0 before it can be built too,
 because the SOVERSION is included in the binary package it builds the
 package will have to pass the NEW queue after upload first. To get it
 passed the NEW queue, I'll rebuild liblas & grass with gdal
 (2.0.2-1-1~exp2) from experimental and upload all three to experimental 
 too.

 All reverse dependencies build successfully with GDAL 2.0.


 Transition: gdal

  libgdal1i (1.11.3+dfsg-3) -> libgdal20 (2.0.2+dfsg-1)
  libgdal.so.1-1.11.3   -> gdal-abi-2-0-2

 The status of the most recent rebuilds is as follows.

  dans-gdal-scripts (0.23-4)   OK
  fiona (1.6.3-2)  OK
  gazebo(6.5.0+dfsg-2) OK
  gmt   (5.2.1+dfsg-3) OK
  imposm(2.6.0+ds-2)   OK
  libcitygml(2.0-1)OK
  liblas(1.8.0-7)  OK
  libosmium (2.6.0-1)  OK
  mapcache  (1.4.0-4)  OK
  mapnik(3.0.9+ds-1)   OK
  mapserver (7.0.0-9)  OK
  merkaartor(0.18.2-5) OK
  mysql-workbench   (6.3.4+dfsg-3) OK
  ncl   (6.3.0-6)  OK
  node-srs  (0.4.8+dfsg-2) OK
  openscenegraph(3.2.1-9)  OK
  osmium(0.0~20160124-b30afd3-1)   OK
  osrm  (4.9.1+ds-1~exp2)  OK
  postgis   (2.2.1+dfsg-2) OK
  pprepair  (0.0~20150624-82a2019-1)   OK
  prepair   (0.7-4)OK
  qlandkartegt  (1.8.1+ds-4)   OK
  qmapshack (1.5.1-1)  OK
  rasterio  (0.31.0-2) OK
  saga  (2.2.3+dfsg-1) OK

Bug#785714: kexec-tools is broken when using systemd, danger of filesystem corruption

[Daniel Baumann]

On 2016-03-03 01:33, Khalid Aziz and Shuah Khan wrote:

I have not been able to reproduce this bug and that has been the
limiting factor in being able to fix it.


I can reliably reproduce it on unmodified, standard/default sid minimal 
install with / on raid1. i'll check tomorrow if i can also reproduce it 
without mdadm (i used to have the problem too without mdadm, but last 
checked a few weeks ago, thus rechecking to confirm).


Regards,
Daniel

Bug#816652: RFS: compiz/1:0.9.12.2 [ITP:722451]

[Vincent Auboyneau]

On Thu, Mar 03, 2016 at 06:55:28PM +0100, Vincent Auboyneau wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
>  Dear mentors, fellow debian lovers,
> 
>  I think it's time to re-empower some users, who like fancyness in their
>  desktop, with compiz!
>  Compiz also addresses a matter of accessibility, with its integration of
>  many visual adaptation features, so it would be a significant addition
>  to our impaired users.
> 
>  BTW, a couple new a11y features have also been pushed to upstream, hoping 
> they
>  take it into consideration.
>  I rather concentrate on the Mate desktop, and plan on releasing an
>  accessibility enabling package lot, called mate-accessibility (see
>  http://git.hypra.fr/hypra/mate-accessibility), to facilitate several
>  configuration profiles for different impairments.
> 
>  The first step is getting compiz back in debian. It has been cleaned up,
>  and polished with the last version of upstream.  I have followed the
>  previous advice of Adam Borowski (on ITP), and set the jpeg and png deps
>  strait.
> 
>  As for functionnal tests, compiz is used by myself, and approx ~20 people, 
> and
>  is ready from sid to jessie(-backports).
>  I await more instructions and pieces of sound advice, of which i know
>  debian people have plenty.
> 
>   I am looking for a sponsor for my package "compiz"
> 
>  * Package name: compiz
>Version : 1:0.9.12.2
>Upstream Author : multiple (see AUTHORS)
>  * URL : https://launchpad.net/compiz
>  * Licenses: GPL/LGPL/MIT
>Section : x11
> 
>   It builds those binary packages:
> 
>  compiz - OpenGL window and compositing manager
>  compiz-core - OpenGL window and compositing manager
>  compiz-dev - OpenGL window and compositing manager - development files
>  compiz-gnome - OpenGL window and compositing manager - GNOME window decorator
>  compiz-mate - OpenGL window and compositing manager - MATE integration
>  compiz-plugins - OpenGL window and compositing manager - plugins
>  compiz-plugins-default - OpenGL window and compositing manager - default 
> plugins
>  compiz-plugins-extra - transitional dummy package
>  compiz-plugins-main - transitional dummy package
>  compiz-plugins-main-default - transitional dummy package
>  compiz-plugins-main-dev - transitional dummy package
>  compizconfig-settings-manager - Compiz configuration settings manager
>  libcompizconfig0 - Settings library for plugins - OpenCompositing Project
>  libcompizconfig0-dev - Development file for plugin settings - 
> OpenCompositing Project
>  libdecoration0 - Compiz window decoration library
>  libdecoration0-dev - Compiz window decoration library - development files
>  python-compizconfig - Compizconfig bindings for Python
> 
>  To access further information about this package, please visit the following 
> URL:
>  http://mentors.debian.net/package/compiz
> 
>  project is also uploaded to alioth in pkg-a11y section:
>  https://alioth.debian.org/projects/compiz/
>  git clone git+ssh://$u...@git.debian.org/git/pkg-a11y/compiz.git
> 
>  To check out built packages, and the mate-accessibility pkgs:
>  http://debian.hypra.fr/debian/import_key (use sid for last version)
> 
>  Alternatively, one can download the package with dget using this command:
>   dget -x 
> http://mentors.debian.net/debian/pool/main/c/compiz/compiz_0.9.12.2.dsc

Following replies:
On Thu, Mar 03, 2016 at 03:03:11PM +, James Cowgill wrote:
> Hi,
> 
> > The first step is getting compiz back in debian. It has been cleaned up,
> > and polished with the last version of upstream.  I have followed the
> > previous advice of Adam Borowski, and set the jpeg and png deps strait.
> 
> Sounds good, assuming it can easily be used with an existing DE in
> Debian (I used to use compiz but I think I've forgotten how it all
> worked).
The obvious prime target is the mate desktop, which is growing in users,
and has become an official ubuntu flavour, so they recently added a
plugin for better integration.
This is also, according to several professional in this area, the most
accessible desktop available for some impaired users, partly because it
provides stability.
> 
> > there is the question of the source format, should it be 3(native) or
> > quilted?
> 
> 3.0 (quilt)
> 
> Native is intended for projects developed by Debian itself. These are
> usually infastructure type projects (like dpkg, debhelper, etc). Most
> packages should not be native.
if using quilt, i need to generate a orig.tar.gz, so how'd you proceed
with that? just tar the thing, rename it?
> 
> > Another issue, that is pending resolve, is a couple lintian errors:
> > compiz-dev: package-contains-cmake-private-file 
> > usr/share/cmake-3.0/FindCompiz.cmake
> > compiz-dev: package-contains-cmake-private-file 
> > usr/share/cmake-3.0/FindOpenGLES2.cmake
> > Are those critical? or is it ok till resolution?
> 
> You're not allowed to ship files in /usr/share/cmake-* because that
> directory 

Bug#737498: [PATCH RFC] patch: when importing from email, RFC2047-decode From/Subject headers

[Matt Mackall]

On Thu, 2016-03-03 at 18:55 +0100, Julien Cristau wrote:
> # HG changeset patch
> # User Julien Cristau 
> # Date 1457026459 -3600
> #  Thu Mar 03 18:34:19 2016 +0100
> # Node ID 6c153cbad4a032861417dbba9d1d90332964ab5f
> # Parent  549ff28a345f595cad7e06fb08c2ac6973e2f030
> patch: when importing from email, RFC2047-decode From/Subject headers
> 
> I'm not too sure about the Subject part: it should be possible to use
> the charset information from the email (RFC2047 encoding and the
> Content-Type header), but mercurial seems to use its own encoding
> instead (in the test, that means the commit message ends up as ""
> if the import is done without --encoding utf-8).  Advice welcome.
> 
> Reported at https://bugs.debian.org/737498

You should probably immediately relay such reports upstream.

> diff --git a/mercurial/patch.py b/mercurial/patch.py
> --- a/mercurial/patch.py
> +++ b/mercurial/patch.py
> @@ -201,19 +201,28 @@ def extract(ui, fileobj):
>  # (this heuristic is borrowed from quilt)
>  diffre = re.compile(r'^(?:Index:[ \t]|diff[ \t]|RCS file: |'
>  r'retrieving revision [0-9]+(\.[0-9]+)*$|'
>  r'---[ \t].*?^\+\+\+[ \t]|'
>  r'\*\*\*[ \t].*?^---[ \t])', re.MULTILINE|re.DOTALL)
> +def decode_header(header):

FYI, names with underbars are against our coding convention, contrib/check-
commit ought to warn about this.

> +if header is None:
> +return None
> +parts = []
> +for part, charset in email.Header.decode_header(header):
> +if charset is None:
> +charset = 'ascii'

This will almost certainly explode on some emails. We should probably do
something like this:

- attempt to decode based on header garbage
- attempt to decode with UTF-8
- assume Latin-1 (not ascii)

> +parts.append(part.decode(charset))
> +return encoding.tolocal(u' '.join(parts).encode('utf-8'))

Using Unicode objects outside of encoding.py is strongly discouraged. If you
must, it'd be great to unambiguously mark them all with a leading u on the
variable name. This isn't a good fit for encoding.py since it uses a third
encoding besides UTF-8 and local. Probably belongs in mail.py.

-- 
Mathematics is the supreme nostalgia of our time.

Bug#760591: Bug#760869: Bug #760869 libreoffice-calc: Sometimes replaces all instances instead of choosen cellspresent anymore

[Stéphane Aulery]

Hello B,

Le 03/03/2016 18:43, B a écrit :

On Thu, 3 Mar 2016 18:27:19 +0100 (CET)
Stéphane Aulery  wrote:

Whao, for a bug originated on 2014-09-08… A slight ignition delay? ;-p)


The maintainer is (a little) overwhelmed by the amount of bugs to follow 
in parallel to the LO publishing rhythm which is fast. so, I do a full 
review.


Even older bugs with reports on Debian and LO tracker are not yet fixed, 
or are new bugs for upstream. I have no qualms at all forward, you never 
know.




I too can't reproduce it in 5.0.5.2; IIRC, it was fixed 2 versions
away from the one of the bug report.


Ok. I close them.


> And, please, for the sake of understanding when very old bugs, include
> the original bug's text.

Ok, thanks for yours help.

Regards,

--
Stéphane Aulery

Bug#816662: ITP: ruby-memfs -- MemFs provides an in-memory fake file system that can be used for tests

[Sebastien Badia]

Package: wnpp
Severity: wishlist
Owner: Sebastien Badia 

* Package name: ruby-memfs
  Version : 0.5.0
  Upstream Author : Simon Courtois 
* URL : https://github.com/simonc/memfs
* License : MIT
  Programming Lang: Ruby
  Description : MemFs provides an in-memory fake file system that can be 
used for tests

 MemFs is greatly inspired by the awesome FakeFs.
 The main goal of MemFs is to be 100% compatible with the Ruby libraries like 
FileUtils.

This package is a new BD of ruby-simple-navigation package, and it
intended to be maintain inside the ruby-team.

Cheers,

Seb

Bug#816491: c99 & strdup

[Jörg Frings-Fürst]

tags 816491 - moreinfo + pending
thanks

Hi Dann, 
Hi Florian,

I have a bugfix release uploaded to my mentor.

Thanks for your work.

CU Jörg

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

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

Jörg Frings-Fürst
D-54538 Bausendorf

Threema: SYR8SJXB

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

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



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

Bug#816612: systemd: Assertion failure, systemd stopped responding

[Michael Biebl]

Am 03.03.2016 um 19:26 schrieb Michael Biebl:
> Control: tags -1 upstream fixed-upstream
> Control: forwarded -1 https://github.com/systemd/systemd/issues/2676
> 
> 
> Hi Sam,
> 
> Am 03.03.2016 um 14:47 schrieb Sam Morris:
>> Package: systemd
>> Version: 229-2
>> Severity: important
>>
>> systemd seems to have stopped reponding to requests. The journal
>> contains:
>>
>>  Mar 03 13:08:24 wintermute systemd[1]: Reloading.
>>  Mar 03 13:08:24 wintermute systemd[1]: Assertion 'e->key == 
>> i->next_key' failed at ../src/basic/hashmap.c:634, function 
>> hashmap_iterate_in_internal_order().
> 
> This seems to be an upstream issue and looks like it was already filed
> upstream at https://github.com/systemd/systemd/issues/2676
> 
> Would be great if you can test the fix from
> https://github.com/systemd/systemd/pull/2702

On a second look, in your case systemd is segfaulting, the upstream bug
report is about resolved. So it might be another incarnation of a
related issue.
In any case, would be great if you can raise that upstream directly.


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



signature.asc
Description: OpenPGP digital signature

Bug#816661: RM: ruby-gsl [arm64 powerpc ppc64el s390x] -- ROM; wrong mathematic results

[Christian Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

ruby-gsl is a math library and as such has an extensive testsuite.
This testsuite fails due to rounding and other issues on the
mentioned architectures.

We've tried some things to get this stuff fixed, but for now we
don't really know what else to do to unbreak those archs.

Please remove the old binaries from unstable so ruby-gsl can
migrate on the archs where it produces correct results.

Thank you,
Christian
(wearing my pkg-ruby-extras hat)
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#816659: RM: mdpress -- ROM; dead upstream, broken with new ruby-redcarpet

[Cédric Boutillier]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

Could you please remove mdpress from the archive? It is unmaintained
upstream, and completely broken with the current (and future) version(s)
of ruby-redcarpet. It has no reverse dependencies and low popcon score.

Thanks in advance

Cédric

Bug#816660: FTBFS: ArgumentError: wrong number of arguments (given 0, expected 1)

[Antonio Terceiro]

Package: ruby-activerecord-deprecated-finders
Version: 1.0.4-1
Severity: serious
Tags: upstream
Justification: Fails to build from source
Forwarded: https://github.com/rails/activerecord-deprecated_finders/issues/27

┌──┐
│ Run tests for ruby2.3 from debian/ruby-tests.rake│
└──┘

RUBYLIB=/home/terceiro/src/debian/pkg-ruby-extras/build-area/ruby-activerecord-deprecated-finders-1.0.4/debian/ruby-activerecord-deprecated-finders/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=debian/ruby-activerecord-deprecated-finders/usr/share/rubygems-integration/all:/home/terceiro/.gem/ruby/2.3.0:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
 ruby2.3 -S rake -f debian/ruby-tests.rake
/usr/bin/ruby2.3 -I"lib:test"  
"/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" 
"test/associations_test.rb" "test/calculate_test.rb" 
"test/default_scope_test.rb" "test/dynamic_methods_test.rb" 
"test/find_in_batches_test.rb" "test/finder_options_test.rb" 
"test/finder_test.rb" "test/scope_test.rb" "test/scoped_test.rb" 
"test/update_all_test.rb" "test/with_scope_test.rb" 
Run options: --seed 13090

# Running:

..E.EE..

Finished in 0.331967s, 204.8398 runs/s, 370.5190 assertions/s.

  1) Error:
associations#test_0005_translates hash scope options into scopes:
ArgumentError: wrong number of arguments (given 0, expected 1)
/usr/lib/ruby/vendor_ruby/active_record/relation/spawn_methods.rb:41:in 
`instance_exec'
/usr/lib/ruby/vendor_ruby/active_record/relation/spawn_methods.rb:41:in 
`merge!'
/usr/lib/ruby/vendor_ruby/active_record/relation/spawn_methods.rb:33:in 
`merge'

/home/terceiro/src/debian/pkg-ruby-extras/build-area/ruby-activerecord-deprecated-finders-1.0.4/lib/active_record/deprecated_finders/association_builder.rb:24:in
 `block in to_proc'

/usr/lib/ruby/vendor_ruby/active_record/associations/association_scope.rb:191:in
 `instance_exec'

/usr/lib/ruby/vendor_ruby/active_record/associations/association_scope.rb:191:in
 `eval_scope'

/usr/lib/ruby/vendor_ruby/active_record/associations/association_scope.rb:155:in
 `block (2 levels) in add_constraints'

/usr/lib/ruby/vendor_ruby/active_record/associations/association_scope.rb:154:in
 `each'

/usr/lib/ruby/vendor_ruby/active_record/associations/association_scope.rb:154:in
 `block in add_constraints'

/usr/lib/ruby/vendor_ruby/active_record/associations/association_scope.rb:141:in
 `each'

/usr/lib/ruby/vendor_ruby/active_record/associations/association_scope.rb:141:in
 `each_with_index'

/usr/lib/ruby/vendor_ruby/active_record/associations/association_scope.rb:141:in
 `add_constraints'

/usr/lib/ruby/vendor_ruby/active_record/associations/association_scope.rb:39:in 
`scope'

/usr/lib/ruby/vendor_ruby/active_record/associations/association_scope.rb:5:in 
`scope'
/usr/lib/ruby/vendor_ruby/active_record/associations/association.rb:97:in 
`association_scope'
/usr/lib/ruby/vendor_ruby/active_record/associations/association.rb:86:in 
`scope'

/usr/lib/ruby/vendor_ruby/active_record/associations/collection_association.rb:423:in
 `scope'

/usr/lib/ruby/vendor_ruby/active_record/associations/collection_proxy.rb:37:in 
`initialize'
/usr/lib/ruby/vendor_ruby/active_record/relation/delegation.rb:106:in `new'
/usr/lib/ruby/vendor_ruby/active_record/relation/delegation.rb:106:in 
`create'

/usr/lib/ruby/vendor_ruby/active_record/associations/collection_association.rb:39:in
 `reader'

/usr/lib/ruby/vendor_ruby/active_record/associations/builder/association.rb:115:in
 `comments'

/home/terceiro/src/debian/pkg-ruby-extras/build-area/ruby-activerecord-deprecated-finders-1.0.4/test/associations_test.rb:49:in
 `block (2 levels) in '
/usr/lib/ruby/vendor_ruby/minitest/test.rb:108:in `block (3 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:205:in `capture_exceptions'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:105:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:256:in `time_it'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:104:in `block in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:331:in `on_signal'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:276:in `with_info_handler'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:103:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:778:in `run_one_method'
/usr/lib/ruby/vendor_ruby/minitest.rb:305:in `run_one_method'
/usr/lib/ruby/vendor_ruby/minitest.rb:293:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:292:in `each'
/usr/lib/ruby/vendor_ruby/minitest.rb:292:in `block in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:331:in `on_signal'

Bug#816612: systemd: Assertion failure, systemd stopped responding

[Michael Biebl]

Control: tags -1 upstream fixed-upstream
Control: forwarded -1 https://github.com/systemd/systemd/issues/2676


Hi Sam,

Am 03.03.2016 um 14:47 schrieb Sam Morris:
> Package: systemd
> Version: 229-2
> Severity: important
> 
> systemd seems to have stopped reponding to requests. The journal
> contains:
> 
>   Mar 03 13:08:24 wintermute systemd[1]: Reloading.
>   Mar 03 13:08:24 wintermute systemd[1]: Assertion 'e->key == 
> i->next_key' failed at ../src/basic/hashmap.c:634, function 
> hashmap_iterate_in_internal_order().

This seems to be an upstream issue and looks like it was already filed
upstream at https://github.com/systemd/systemd/issues/2676

Would be great if you can test the fix from
https://github.com/systemd/systemd/pull/2702

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#816658: Useless in Debian

[David Prévot]

Package: php-randomlib
Version: 1.1.0-1
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

I recently packaged php-randomlib as used by owncloud, but owncloud is
going away anyway, see #816376.  There is a priori little point to
release php-randomlib in a stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#816656: override: libxapian22v5:libs/optional

[Laurent Bigonville]

Package: ftp.debian.org
Severity: normal

Hi,

Now that apparently the override file for aptitude has been changed and
that it has the priority optional, I guess that libxapian22v5 priority
of libxapian22v5 can also be lowered to optional too.

Cheers,

Laurent Bigonville

Bug#816657: Interchange upstream v5.10.0 now available

[Robert James Clay]

Package: interchange
Severity: wishlist

Version v5.10.0 of Interchange was released [1] on 6 January 2016 and is
now available as any of the following archives:

interchange-5.10.0.tar.bz2
interchange-5.10.0.tar.gz
interchange-5.10.0.tar.xz

See also http://ftp.icdevgroup.org/interchange/5.10/WHATSNEW for what's new in 
the release.

I request that the Interchange Debian package be updated using  the new
release.




Robert James Clay
j...@rocasa.us, rjc...@gmail.com

[1] http://ftp.icdevgroup.org/interchange/5.10/tar/

Bug#816655: 3.0: End of life

[David Prévot]

Package: phpbb3
Version: 3.0.14-1
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

Upstream announced that the end of life of the 3.0 branch happened a few
months ago [EOL]. Unless someones steps up to maintain it [#767667],
this package shouldn’t be shipped with the next Debian stable release.

EOL: https://www.phpbb.com/community/viewtopic.php?f=14=2302466
#767667: https://bugs.debian.org/767667

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#813916: transition: gdal

[Emilio Pozuelo Monfort]

On 01/03/16 20:18, Sebastiaan Couwenberg wrote:
> On 01-03-16 19:50, Emilio Pozuelo Monfort wrote:
>> On 19/02/16 14:08, Sebastiaan Couwenberg wrote:
>>> On 12-02-16 19:05, Emilio Pozuelo Monfort wrote:
 On 12/02/16 18:52, Sebastiaan Couwenberg wrote:
> On 12-02-16 18:28, Emilio Pozuelo Monfort wrote:
>> On 06/02/16 17:43, Bas Couwenberg wrote:
>>> Package: release.debian.org
>>> For the Debian GIS team I'd like to transition to the recently released
>>> GDAL 1.11.4. Only the packages using C++ symbols need to be rebuilt.
>>>
>>> GDAL 2.0.2 was released along with 1.11.4, but we still don't have
>>> support for GDAL 2.0 in all reverse dependencies. Since the transition
>>> to GDAL 1.11.3, support for GDAL 2.0 was added to all reverse
>>> depedencies except Fiona [0]. Upstream has recently included changes for
>>> GDAL 2.0, but these differ from the initial GDAL 2.0 changes available
>>> as a patch in #802808. The improved GDAL 2.0 changes are entangled with
>>> other changes for the upcoming Fiona 1.7 release, which I've not been
>>> able to successfully backport. This will not be a blocker for the GDAL
>>> 2.0 transition, as discussed with the maintainer on the debian-gis list
>>> [1].
>>>
>>> Because the transition for GDAL 1.11.4 is ready now, I'd like to do that
>>> first before preparing the transition to GDAL 2.0. All reverse
>>> dependencies rebuilt successfully with GDAL 1.11.4, the summary of
>>> rebuilds is included below.
>>>
>>
>> This would get entangled with the openmpi transition, so it will have to 
>> wait.
>> After openmpi, I'm thinking about doing libpng, but we'll see.
>
> Waiting for openmpi is no problem, but if the libpng transition is going
> to happen first, I think it's better to use that time the prepare the
> transition to GDAL 2.0 instead of 1.11.4. Last week the last blocker was
> resolved [0], so we're also pretty much ready to transition to GDAL 2.0.
> The 2.0 packages will have to pass the NEW queue again, because of the
> delay that will cause I've opted to transition to 1.11.4 which is ready 
> now.
>
> If you can confirm that the libpng transition is going to happen first,
> I'll upload the packages for GDAL 2.0 to experimental, and we can switch
> to that in unstable after the libpng transition and the new gdal has
> passed NEW.

 Sure, let's do that.
>>>
>>> The GDAL 2.0.2 packages are available in experimental and ready for
>>> transition.
>>>
>>> libgdal-grass (2.0.2-1) not available in experimental yet, liblas and
>>> grass need to be rebuilt with GDAL 2.0 before it can be built too,
>>> because the SOVERSION is included in the binary package it builds the
>>> package will have to pass the NEW queue after upload first. To get it
>>> passed the NEW queue, I'll rebuild liblas & grass with gdal
>>> (2.0.2-1-1~exp2) from experimental and upload all three to experimental too.
>>>
>>> All reverse dependencies build successfully with GDAL 2.0.
>>>
>>>
>>> Transition: gdal
>>>
>>>  libgdal1i (1.11.3+dfsg-3) -> libgdal20 (2.0.2+dfsg-1)
>>>  libgdal.so.1-1.11.3   -> gdal-abi-2-0-2
>>>
>>> The status of the most recent rebuilds is as follows.
>>>
>>>  dans-gdal-scripts (0.23-4)   OK
>>>  fiona (1.6.3-2)  OK
>>>  gazebo(6.5.0+dfsg-2) OK
>>>  gmt   (5.2.1+dfsg-3) OK
>>>  imposm(2.6.0+ds-2)   OK
>>>  libcitygml(2.0-1)OK
>>>  liblas(1.8.0-7)  OK
>>>  libosmium (2.6.0-1)  OK
>>>  mapcache  (1.4.0-4)  OK
>>>  mapnik(3.0.9+ds-1)   OK
>>>  mapserver (7.0.0-9)  OK
>>>  merkaartor(0.18.2-5) OK
>>>  mysql-workbench   (6.3.4+dfsg-3) OK
>>>  ncl   (6.3.0-6)  OK
>>>  node-srs  (0.4.8+dfsg-2) OK
>>>  openscenegraph(3.2.1-9)  OK
>>>  osmium(0.0~20160124-b30afd3-1)   OK
>>>  osrm  (4.9.1+ds-1~exp2)  OK
>>>  postgis   (2.2.1+dfsg-2) OK
>>>  pprepair  (0.0~20150624-82a2019-1)   OK
>>>  prepair   (0.7-4)OK
>>>  qlandkartegt  (1.8.1+ds-4)   OK
>>>  qmapshack (1.5.1-1)  OK
>>>  rasterio  (0.31.0-2) OK
>>>  saga  (2.2.3+dfsg-1) OK
>>>  sumo  (0.25.0+dfsg1-2)   OK
>>>  thuban(1.2.2-9)  OK
>>>  vtk6  (6.2.0+dfsg1-7) 

Bug#816654: youtube-dl: SSL error with vimeo URLs

[Matt Taggart]

Package: youtube-dl
Version: 2016.02.22-1

When attempting to download from vimeo I am getting the following error:


$ youtube-dl https://player.vimeo.com/video/156377457
[vimeo] 156377457: Downloading webpage
[vimeo] 156377457: Extracting information
[vimeo] 156377457: Downloading JSON metadata
[vimeo] 156377457: Downloading m3u8 information
WARNING: Failed to download m3u8 information: 
ERROR: unable to download video data: 


This started maybe a week ago, maybe something changed with vimeo?

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#816125: libsdl1.2debian: Remove DirectFB dependency

[Manuel A. Fernandez Montecelo]

Hi Javier,

2016-02-27 18:14 Javier Cantero:

Package: libsdl1.2debian
Version: 1.2.15+dfsg1-2
Severity: wishlist

Dear Maintainer,

Due to the current status of DirectFB (the project seems dead) and also
the status of the debian package (currently unfit for release), can I
suggest that future releases drop the dependency by not compiling SDL
1.2 with DirectFB support?

Thank you for your time and consideration.


I had some hope that we wouldn't have to touch libsdl1.2 much, but the
migration to libsdl2 is not going as fast as I would like / expect.

So I guess that it's better to drop this dependency at some point before
the freeze.

If this becomes more high priority for some reason, e.g. because of a
pending RM of libdirectfb, please let us know.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#816653: call_trans2qfilepathinfo: SMB_VFS_LSTAT failing when asterisk in name

[Arthur Marsh]

Package: samba
Version: 2:4.3.3+dfsg-2+b1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Trying to share a filesystem where some directories and files have an
asterisk in their name (originally reported as bug #816650 against cifs-utils)

When trying to view the contents of a directory containing an asterisk in its
name mounted via cifs I get "not a directory" errors.

Samba log shows:

[2016/03/04 04:10:39.992885,  3] ../source3/smbd/trans2.c:5549(call_trans2qfilep
athinfo)
  call_trans2qfilepathinfo: TRANSACT2_QPATHINFO: level = 512
[2016/03/04 04:10:39.993073,  3] ../source3/smbd/trans2.c:5655(call_trans2qfilep
athinfo)
  call_trans2qfilepathinfo: SMB_VFS_LSTAT of amarsh04/Minami_Kuribayashi,_Miyuki
_Hashimoto,_Faylan,_Aki_Misato,_yozuca,_rino-Super☆Affection failed (No such fi
le or directory)
[2016/03/04 04:10:39.993163,  3] ../source3/smbd/error.c:82(error_packet_set)
  NT error packet at ../source3/smbd/trans2.c(5657) cmd=50 (SMBtrans2) NT_STATUS
_OBJECT_NAME_NOT_FOUND

the character after 'yozuca' and before the comma is supposed to be an 
asterisk.

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

This used to work and I am unsure when it broke.

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.5.0-rc6+ (SMP w/1 CPU core; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages samba depends on:
ii  adduser   3.113+nmu3
ii  dpkg  1.18.4
ii  libbsd0   0.8.2-1
ii  libc6 2.21-9
ii  libcap2   1:2.24-12
ii  libldb1   2:1.1.26-1
ii  libpam-modules1.1.8-3.2
ii  libpam-runtime1.1.8-3.2
ii  libpopt0  1.16-10
ii  libpython2.7  2.7.11-4
ii  libtalloc22.1.5-2
ii  libtdb1   1.3.8-1
ii  libtevent00.9.28-1
ii  libwbclient0  2:4.3.3+dfsg-2+b1
ii  lsb-base  9.20160110
ii  procps2:3.3.11-3.0nosystemd1
ii  python2.7.11-1
ii  python-dnspython  1.12.0-1
ii  python-samba  2:4.3.3+dfsg-2+b1
pn  python2.7:any 
ii  samba-common  2:4.3.3+dfsg-2
ii  samba-common-bin  2:4.3.3+dfsg-2+b1
ii  samba-libs2:4.3.3+dfsg-2+b1
ii  tdb-tools 1.3.8-1
ii  update-inetd  4.43

Versions of packages samba recommends:
ii  attr1:2.4.47-2
ii  logrotate   3.8.7-2
ii  samba-dsdb-modules  2:4.3.3+dfsg-2+b1
ii  samba-vfs-modules   2:4.3.3+dfsg-2+b1

Versions of packages samba suggests:
ii  bind9  1:9.9.5.dfsg-12.1
ii  bind9utils 1:9.9.5.dfsg-12.1
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p4+dfsg-3+b1
pn  smbldap-tools  
ii  winbind2:4.3.3+dfsg-2+b1

-- debconf-show failed

Bug#813692: ejabberd: Failed RPC connection to the node ejabberd@mercurius: timeout

[Philipp Huebner]

Am 03.03.2016 um 18:32 schrieb Dominik George:
>> Since I haven't heard back from you and nobody else has reported
>> anything similar, I assume this issue is closed.
>>
>> You're welcome to re-open this bugreport if you need further assistance.
> 
> Can you imagine there are people with a dayjob and a life?

Now who is rude here?

>> I cannot help you if you don't work with me.
> 
> And please stop being so rude.

It was not my intention to be rude, I merely wanted to state that fact
as this is not the first time you opened a bug against ejabberd (which
was none) and then didn't get back to me when I pointed out what the
cause of your problem was. (#806998)

> As a side note, I am also helping you fix a possible issue with your package.
> 
> Reopening the bug - don't close it again unless it is solved, and give users 
> an appropriate amount of time to provide information!

I'm sorry, I assumed a whole month was an appropriate amount of time.
Next time I'll wait another month.

But please stop telling long term voluntary maintainers and Debian
Developers who are donating their free time here what to do and what not
to do, that is quite disrespectful and discouraging.

Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#737498: [PATCH RFC] patch: when importing from email, RFC2047-decode From/Subject headers

[Julien Cristau]

# HG changeset patch
# User Julien Cristau 
# Date 1457026459 -3600
#  Thu Mar 03 18:34:19 2016 +0100
# Node ID 6c153cbad4a032861417dbba9d1d90332964ab5f
# Parent  549ff28a345f595cad7e06fb08c2ac6973e2f030
patch: when importing from email, RFC2047-decode From/Subject headers

I'm not too sure about the Subject part: it should be possible to use
the charset information from the email (RFC2047 encoding and the
Content-Type header), but mercurial seems to use its own encoding
instead (in the test, that means the commit message ends up as ""
if the import is done without --encoding utf-8).  Advice welcome.

Reported at https://bugs.debian.org/737498

diff --git a/mercurial/patch.py b/mercurial/patch.py
--- a/mercurial/patch.py
+++ b/mercurial/patch.py
@@ -201,19 +201,28 @@ def extract(ui, fileobj):
 # (this heuristic is borrowed from quilt)
 diffre = re.compile(r'^(?:Index:[ \t]|diff[ \t]|RCS file: |'
 r'retrieving revision [0-9]+(\.[0-9]+)*$|'
 r'---[ \t].*?^\+\+\+[ \t]|'
 r'\*\*\*[ \t].*?^---[ \t])', re.MULTILINE|re.DOTALL)
+def decode_header(header):
+if header is None:
+return None
+parts = []
+for part, charset in email.Header.decode_header(header):
+if charset is None:
+charset = 'ascii'
+parts.append(part.decode(charset))
+return encoding.tolocal(u' '.join(parts).encode('utf-8'))
 
 data = {}
 fd, tmpname = tempfile.mkstemp(prefix='hg-patch-')
 tmpfp = os.fdopen(fd, 'w')
 try:
 msg = email.Parser.Parser().parse(fileobj)
 
-subject = msg['Subject']
-data['user'] = msg['From']
+subject = decode_header(msg['Subject'])
+data['user'] = decode_header(msg['From'])
 if not subject and not data['user']:
 # Not an email, restore parsed headers if any
 subject = '\n'.join(': '.join(h) for h in msg.items()) + '\n'
 
 # should try to parse msg['Date']
diff --git a/tests/test-import-git.t b/tests/test-import-git.t
--- a/tests/test-import-git.t
+++ b/tests/test-import-git.t
@@ -820,6 +820,29 @@ Test corner case involving copies and mu
   >  a
   > +b
   > EOF
   applying patch from stdin
 
+Test email metadata
+
+  $ hg revert -qa
+  $ hg --encoding utf-8 import - < From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
+  > Subject: [PATCH] =?UTF-8?q?=C5=A7=E2=82=AC=C3=9F=E1=B9=AA?=
+  > 
+  > diff --git a/a b/a
+  > --- a/a
+  > +++ b/a
+  > @@ -1,1 +1,2 @@
+  >  a
+  > +a
+  > EOF
+  applying patch from stdin
+  $ hg --encoding utf-8 log -r .
+  changeset:   2:* (glob)
+  tag: tip
+  user:Rapha\xc3\xabl Hertzog  (esc)
+  date:* (glob)
+  summary: \xc5\xa7\xe2\x82\xac\xc3\x9f\xe1\xb9\xaa (esc)
+  
+
   $ cd ..

Bug#816652: RFS: compiz/1:0.9.12.2 [ITP:722451]

[Vincent Auboyneau]

Package: sponsorship-requests
Severity: wishlist

 Dear mentors, fellow debian lovers,

 I think it's time to re-empower some users, who like fancyness in their
 desktop, with compiz!
 Compiz also addresses a matter of accessibility, with its integration of
 many visual adaptation features, so it would be a significant addition
 to our impaired users.

 BTW, a couple new a11y features have also been pushed to upstream, hoping they
 take it into consideration.
 I rather concentrate on the Mate desktop, and plan on releasing an
 accessibility enabling package lot, called mate-accessibility (see
 http://git.hypra.fr/hypra/mate-accessibility), to facilitate several
 configuration profiles for different impairments.

 The first step is getting compiz back in debian. It has been cleaned up,
 and polished with the last version of upstream.  I have followed the
 previous advice of Adam Borowski (on ITP), and set the jpeg and png deps
 strait.

 As for functionnal tests, compiz is used by myself, and approx ~20 people, and
 is ready from sid to jessie(-backports).
 I await more instructions and pieces of sound advice, of which i know
 debian people have plenty.

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

 * Package name: compiz
   Version : 1:0.9.12.2
   Upstream Author : multiple (see AUTHORS)
 * URL : https://launchpad.net/compiz
 * Licenses: GPL/LGPL/MIT
   Section : x11

  It builds those binary packages:

 compiz - OpenGL window and compositing manager
 compiz-core - OpenGL window and compositing manager
 compiz-dev - OpenGL window and compositing manager - development files
 compiz-gnome - OpenGL window and compositing manager - GNOME window decorator
 compiz-mate - OpenGL window and compositing manager - MATE integration
 compiz-plugins - OpenGL window and compositing manager - plugins
 compiz-plugins-default - OpenGL window and compositing manager - default 
plugins
 compiz-plugins-extra - transitional dummy package
 compiz-plugins-main - transitional dummy package
 compiz-plugins-main-default - transitional dummy package
 compiz-plugins-main-dev - transitional dummy package
 compizconfig-settings-manager - Compiz configuration settings manager
 libcompizconfig0 - Settings library for plugins - OpenCompositing Project
 libcompizconfig0-dev - Development file for plugin settings - OpenCompositing 
Project
 libdecoration0 - Compiz window decoration library
 libdecoration0-dev - Compiz window decoration library - development files
 python-compizconfig - Compizconfig bindings for Python

 To access further information about this package, please visit the following 
URL:
 http://mentors.debian.net/package/compiz

 project is also uploaded to alioth in pkg-a11y section:
 https://alioth.debian.org/projects/compiz/
 git clone git+ssh://$u...@git.debian.org/git/pkg-a11y/compiz.git

 To check out built packages, and the mate-accessibility pkgs:
 http://debian.hypra.fr/debian/import_key (use sid for last version)

 Alternatively, one can download the package with dget using this command:
  dget -x 
http://mentors.debian.net/debian/pool/main/c/compiz/compiz_0.9.12.2.dsc

-- 
Ksamak
hypra.fr Team


pgpeJOQXouU9B.pgp
Description: PGP signature

Bug#816651: Useless in Debian

[David Prévot]

Package: php-json-patch
Version: 0.1.0-2
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

I recently packaged php-json-patch as used by php-opencloud as used by
owncloud, but owncloud version 7 that is going away anyway, see #816376.
There is a priori little point to release it in a stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#816650: cifs-utils: problems dealing with directory on cifs containing an asterisk in its name

[Arthur Marsh]

Package: cifs-utils
Version: 2:6.4-1
Followup-For: Bug #816650

Dear Maintainer,

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

On the cifs-mounted filesystem when doing an strace of the ls command:

openat(AT_FDCWD, ".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, 0x1b1ec40, 32768)   = -1 ENOTDIR (Not a directory)

On the remote system, doing an strace of the ls command from the same
directory:

openat(AT_FDCWD, ".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
getdents64(3, /* 6 entries */, 32768)   = 320

Samba log of the server shows:

[2016/03/04 04:10:39.992885,  3] ../source3/smbd/trans2.c:5549(call_trans2qfilep
athinfo)
  call_trans2qfilepathinfo: TRANSACT2_QPATHINFO: level = 512
[2016/03/04 04:10:39.993073,  3] ../source3/smbd/trans2.c:5655(call_trans2qfilep
athinfo)
  call_trans2qfilepathinfo: SMB_VFS_LSTAT of amarsh04/Minami_Kuribayashi,_Miyuki
_Hashimoto,_Faylan,_Aki_Misato,_yozuca,_rino-Super☆Affection failed (No such fi
le or directory)
[2016/03/04 04:10:39.993163,  3] ../source3/smbd/error.c:82(error_packet_set)
  NT error packet at ../source3/smbd/trans2.c(5657) cmd=50 (SMBtrans2) NT_STATUS
_OBJECT_NAME_NOT_FOUND

So would this be more likely to be an error with samba?


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


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

Kernel: Linux 4.5.0-rc6+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages cifs-utils depends on:
ii  libc6 2.21-9
ii  libcap-ng00.7.7-1+b1
ii  libkeyutils1  1.5.9-8
ii  libkrb5-3 1.13.2+dfsg-5
ii  libtalloc22.1.5-2
ii  libwbclient0  2:4.3.3+dfsg-2+b1
ii  samba-common  2:4.3.3+dfsg-2

Versions of packages cifs-utils recommends:
ii  keyutils  1.5.9-8
ii  winbind   2:4.3.3+dfsg-2+b1

Versions of packages cifs-utils suggests:
ii  smbclient  2:4.3.3+dfsg-2+b1

-- no debconf information

Bug#760591: Bug #760591 - libreoffice-calc: Mouse copy is wrong

[Bzzzz]

On Thu, 3 Mar 2016 18:37:28 +0100 (CET)
Stéphane Aulery  wrote:

This one is _very_ old too (2014 too).

As I did not wrote a follow-up, consider it closed.

And, please, for the sake of understanding when very old bugs, include
the original bug's text.

Regards,

JY

> Hello B,
> 
> Can you reproduce this bug with a newer version (backports) please?
> 
> Regards,
> 

Bug#760869: Bug #760869 libreoffice-calc: Sometimes replaces all instances instead of choosen cellspresent anymore

[Bzzzz]

On Thu, 3 Mar 2016 18:27:19 +0100 (CET)
Stéphane Aulery  wrote:

Whao, for a bug originated on 2014-09-08… A slight ignition delay? ;-p)

I too can't reproduce it in 5.0.5.2; IIRC, it was fixed 2 versions
away from the one of the bug report.

Regards,

JY

> tags 760869 + moreinfo
> stop
> 
> 
> Hello B,
> 
> I can't reproduce this bug with LO 5.0.5. The following report
> describe that the checkbox "Limit to selection only" is cleared after
> replace:
> 
> https://bugs.documentfoundation.org/show_bug.cgi?id=44837
> 
> Does it be what you are describing?
> 
> Regards,
> 

Bug#813692: ejabberd: Failed RPC connection to the node ejabberd@mercurius: timeout

[Dominik George]

Control: reopen -1

> Since I haven't heard back from you and nobody else has reported
> anything similar, I assume this issue is closed.
> 
> You're welcome to re-open this bugreport if you need further assistance.

Can you imagine there are people with a dayjob and a life?

> I cannot help you if you don't work with me.

And please stop being so rude.

As a side note, I am also helping you fix a possible issue with your package.

Reopening the bug - don't close it again unless it is solved, and give users 
an appropriate amount of time to provide information!

-nik

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

Dominik George · Mobil: +49-151-61623918

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

LPIC-3 Linux Enterprise Professional (Security)

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

Bug#760591: Bug #760591 - libreoffice-calc: Mouse copy is wrong

[Stéphane Aulery]

Hello B,

Can you reproduce this bug with a newer version (backports) please?

Regards,

-- 
Stéphane Aulery

Bug#760869: Bug #760869 libreoffice-calc: Sometimes replaces all instances instead of choosen cellspresent anymore

[Stéphane Aulery]

tags 760869 + moreinfo
stop


Hello B,

I can't reproduce this bug with LO 5.0.5. The following report describe that 
the checkbox "Limit to selection only" is cleared after replace:

https://bugs.documentfoundation.org/show_bug.cgi?id=44837

Does it be what you are describing?

Regards,

-- 
Stéphane Aulery

Bug#816650: cifs-utils: problems dealing with directory on cifs containing an asterisk in its name

[Arthur Marsh]

Package: cifs-utils
Version: 2:6.4-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

A long time back I found that a directory on a cifs mounted file system
(also running Debian, but 32 bit) could be made current directory,
but attempts to access files within it failed.

The filesystem is mounted as:

//192.168.1.104/homes on /mnt/homes type cifs 
(rw,relatime,vers=1.0,cache=strict,username=root,domain=VICTORIA,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.104,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,echo_interval=60,actimeo=1)

and there are 2 directories under /mnt/homes containing commas and an 
asterisk in their names:

Ayane,_Kanako_Ito,_CooRie,_Minami_Kuribayashi,_Hiromi_Sato,_nao,_Faylan,_Yozuca*-New_Game
Minami_Kuribayashi,_Miyuki_Hashimoto,_Faylan,_Aki_Misato,_yozuca*,_rino-Super☆Affection

if I do:

ls /mnt/homes/amarsh04/Ayane*Game
ls: reading directory 
'/mnt/homes/amarsh04/Ayane,_Kanako_Ito,_CooRie,_Minami_Kuribayashi,_Hiromi_Sato,_nao,_Faylan,_Yozuca*-New_Game':
 Not a directory

If I do:

$ cd /mnt/homes/amarsh04/Ayane*Game
amarsh04@am64:/mnt/homes/amarsh04/Ayane,_Kanako_Ito,_CooRie,_Minami_Kuribayashi,_Hiromi_Sato,_nao,_Faylan,_Yozuca*-New_Game$
 ls
ls: reading directory '.': Not a directory

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

being able to use file and directory names that include such characters.


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


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

Kernel: Linux 4.5.0-rc6+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages cifs-utils depends on:
ii  libc6 2.21-9
ii  libcap-ng00.7.7-1+b1
ii  libkeyutils1  1.5.9-8
ii  libkrb5-3 1.13.2+dfsg-5
ii  libtalloc22.1.5-2
ii  libwbclient0  2:4.3.3+dfsg-2+b1
ii  samba-common  2:4.3.3+dfsg-2

Versions of packages cifs-utils recommends:
ii  keyutils  1.5.9-8
ii  winbind   2:4.3.3+dfsg-2+b1

Versions of packages cifs-utils suggests:
ii  smbclient  2:4.3.3+dfsg-2+b1

-- no debconf information

Bug#816619: ITP: python-neovim-gui -- Simple nvim gui implemented using Gtk

[Víctor Cuadrado Juan]

On Thu, 3 Mar 2016 16:43:19 +0100 Víctor Cuadrado Juan 
wrote:
> This package depends on the pygobject python module, which remains to
> be packaged (and there's no ITP open yet).

It is provided by the python-gi package:
/usr/lib/python2.7/dist-packages/pygobject-3.18.2.egg-info


-- 
Víctor Cuadrado juan

E-Mail: , OpenPGP-Key-ID: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.

Bug#804966: Dropping initscripts dependency from procps now possible.

[Andreas Henriksson]

Hello Craig Small!

Since the upload of init-system-helpers 1.29 it's now practically
possible to drop the initscripts dependency for packages which
only previously needed it because of LSB header declaration.

I've just uploaded util-linux without an initscripts dependency
myself which now makes procps the only package depending on
initscripts in a regular sid debootstrap.

Please note that when dropping initscripts dependency you should also
make sure that init-system-helpers are guaranteed to be updated to
>= 1.29~ or your maintainer script call to update-rc.d could fail. The
easiest way to accomplish this is to simply depend on
init-system-helpers (>= 1.29~).

Regards,
Andreas Henriksson

Bug#816576: One additional data point

[Andreas Kloeckner]

GDM/Wayland seems to be partially at fault, since switching to lightdm
makes the issue go away for the time being.

Andreas