Bug#847050: ITP: gnome-shell-extension-log-out-button -- A GNOME Extension to add a log out button to the system activities menu

[Kyle Robbertze]

On 06/12/2016 23:34, Tobias Frost wrote:
> Hallo Kyle,
> 
> Please open up a RFS bug and also bounce this mail to the bug. 
Done
> 
> Review:
> 
> - the packaging seems fine
> 
> upstream related:
> - seems so that the gschema is not needed, is it?
No it isn't, I shall remove it
> - when disabling the extension (e.g via gnome-tweak-tool), the icon
> stays in the menu. This is bug, I guess as e.g gnome-shell-extension-
> suspendbutton does immediatly remove the button once disabled in g-t-t)
Will fix this
> - when enabling the extension via gnome-tweak-tool, the icon goes to
> the far right in my case, when reloading gnome-shell it is then placed
> in the "middle"? Is this intentional?
I can't seem to replicate this on my side. Running GNOME 2.22. The icon
is intended to be on the far right only (as it is the last icon added)

Cheers
Kyle



signature.asc
Description: OpenPGP digital signature

Bug#847224: Icedove: Cannot add description of event upon creation.

[Carsten Schoenert]

reassign 847224 calendar-exchange-provider
thanks

Hello Dario,

On Tue, Dec 06, 2016 at 12:40:55PM -0300, Dario Andres Susman wrote:
> Dear Maintainer,
> 
> When I'm trying to create a new event, the description tab is
> completely greyed out and cannot edit it.
> This only happens when I'm trying to create an event on an
> Exchange/OWA/Office365 calendar.
> If I choose to edit a local, internal calendar, the description tab is
> displayed correctly and I can edit it just fine.
> 
> I'm attaching a screenshot.

I can see this behaviour here too on a calendar that is connected to a
Exchange 2010 server, I reassign your report to the plugin that provides
the connectivity the the Exchange server as this issue seems not to be
Icedove specific.

Regards
Carsten

Bug#847206: [pkg-gnupg-maint] Bug#847206: Bug#847206: gpg-agent: can't connect to the agent: File name too long

[Werner Koch]

On Tue,  6 Dec 2016 19:07, d...@fifthhorseman.net said:

> You could work around it by creating a gnupg_home dir for your tests at
> the top level of your build tree, and it would fit within the requisite

Sandro: Assuming 2.1, you can also do this:

  GNUPGHOME=
  export GNUPGHOME
  gpgconf --create-socketdir
  [.. your test code ...]

which creates a dedicated directory below /run/user to be used for
sockets.  For cleanup you can use --remove-socketdir; use -v to see what
it actually does.


Salam-Shalom,

   Werner

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


pgpXUyu7ORr9l.pgp
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

Hi Tollef,

On 06.12.2016 17:04, Tollef Fog Heen wrote:
> ]] Ole Streicher 
> 
>> On 06.12.2016 10:37, Holger Levsen wrote:
>>> And this *is* still pretty confusing, though admitly better than it was
>>> half a year ago. 
>>
>> The current implementation has a popcon of >5000, without a single
>> complaint or confusion documented in the web within the last six months.
>> This is at least *some* empirical evidence that it is not "pretty
>> confusing", and again I would ask you to show any better empirical data
>> here to support your own point.
> 
> It's confusing enough that when I've had engineers from a provider
> install Debian for me, I have ended up with a desktop rather than server
> installation.  Should I have filed a bug about it?  Maybe.

I think you should, since this is the preferred way to let the
maintainer know about problems. This is even more true for prereleases
like alpha6 ff., since they depend on bugreports to get finished properly.

But this is not (completely) what I mean: I didn't only check for bug
reports, but also for help requests or comments. And the status is:
nobody had so much difficulties with the additional choices, that he
asked what to do. So, although the current way has been used by many
people, no difficulty was documented (with the exception I already
mentioned).

> I think it would be better if we moved most of tasksel out of the
> installer entirely and had an app store of some sort where applications
> and blends could all be better presented with screenshots and
> all. 

I disagree here: the installer is a kind-of assistent which leads you
through the installation process. It is much easier, even for me, to
follow these steps than to need to remember to start the app store
afterwards.

BTW, tasksel is able to do both: it is called from the installer, but
also max be called afterwards to change the selection if needed. IMO
this is the optimal way to interact with the user. It is just the
implementation that is hopelessly outdated.

> Again, I don't know how feasible it is to end up with a better design
> for stretch, but I don't think the current design is particularly
> scalable and should be replaced for buster.

Fully Ack. I see the current solution to integrate the Blends in Stretch
as a compromise for Stretch only; afterwards we should look to rewrite
tasksel for a better scalability.

Best regards

Ole

Bug#847305: RFS: gnome-shell-extension-log-out-button/1.0.3-1 [ITP] -- A GNOME Extension to add a log out button to the system activities menu

[Kyle Robbertze]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package
"gnome-shell-extension-log-out-button"

 * Package name: gnome-shell-extension-log-out-button
   Version : 1.0.3-1
   Upstream Author : Kyle Robbertze 
 * URL :
https://gitlab.com/paddatrapper/log-out-button-gnome-extension
 * License : GPL-3
   Section : gnome

It builds those binary packages:

  gnome-shell-extension-log-out-button - Adds a log out button to the
system action list in GNOME Shell

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

  https://mentors.debian.net/package/gnome-shell-extension-log-out-button

Alternatively, one can download the package with dget using this command:
  dget -x
https://mentors.debian.net/debian/pool/main/g/gnome-shell-extension-log-out-button/gnome-shell-extension-log-out-button_1.0.3-1.dsc

More information about gnome-shell-extension-log-out-button can be
obtained from
https://gitlab.com/paddatrapper/log-out-button-gnome-extension.

Changes since the last upload:

gnome-shell-extension-log-out-button (1.0.3-1) unstable; urgency=medium

  * Initial release (Closes #847050)

 -- Kyle Robbertze  Mon, 05 Dec 2016 08:44:45 +0200


Regards,
 Kyle Robbertze



signature.asc
Description: OpenPGP digital signature

Bug#847044: allow gitlab 8.13.6+dfsg2-1 to migrate testing

[Niels Thykier]

Julien Cristau:
> On 12/04/2016 11:18 PM, Holger Levsen wrote:
>> looking at
>> https://piuparts.debian.org/sid/fail/gitlab_8.13.6+dfsg2-1.log I see:
>>
>> 12m12.4s ERROR: WARN: Processes are running inside chroot:
>> 12m20.4s ERROR: WARN: Broken symlinks:
>> 12m55.1s ERROR: FAIL: Package purging left files on system:
>>
>> of which I'd consider the processes left running in the chroot to be
>> seriously broken.
>>
> It seems a postgresql server gets started somehow?  That does seem like
> a serious issue.
> 
> [...]
> 
> Cheers,
> Julien
> 

Indeed - it appears to be started by postgres's postinst.  I presume
this means any rdep of postgres would have this issue.

Thanks,
~Niels

Bug#847231: [debian-mysql] Bug#847231: mysql-server-core-5.7: fails to upgrade from 'jessie' - trying to overwrite /usr/share/man/man1/innochecksum.1.gz

[Lars Tangvald]

Hi,

On 12/06/2016 05:55 PM, Andreas Beckmann wrote:

Package: mysql-server-core-5.7
Version: 5.7.16-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

   Selecting previously unselected package mysql-server-core-5.7.
   (Reading database ...
(Reading database ... 17080 files and directories currently installed.)
   Preparing to unpack .../mysql-server-core-5.7_5.7.16-1_amd64.deb ...
   Unpacking mysql-server-core-5.7 (5.7.16-1) ...
   dpkg: error processing archive 
/var/cache/apt/archives/mysql-server-core-5.7_5.7.16-1_amd64.deb (--unpack):
trying to overwrite '/usr/share/man/man1/innochecksum.1.gz', which is also 
in package mysql-server-5.5 5.5.50-0+deb8u1
   dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Thanks. As you say, it looks like we're missing a breaks/replaces on the 
server-core package.


--
Lars


cheers,

Andreas


___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#847287: [Pkg-roundcube-maintainers] Bug#847287: roundcube: Roundcube 1.2.2: Remote command execution via malicious email composing

[Vincent Bernat]

 ❦  7 décembre 2016 00:30 +0100, Guilhem Moulin  :

>> Version: 1.1.4+dfsg.1-1~bpo8+1
>> […]
>> So probably it is important to update to upstream version 1.2.3
>
> Unfortunately 1.2.x has many dependencies that aren't in
> jessie-backports yet.  I personally don't have the time nor energy to
> maintain said dependencies, so we asked backports folks for an exception
> to stick to 1.1.x for the bpo version, exception which was rejected.
> I'm afraid the remaining alternative is to take remove the package from
> jessie-backports :-(

Since the problem is quite serious, could you push the fix in bpo8+2
nonetheless? Then wait a bit before asking for removal from backports to
let actual users get an updated version. It seems far better than just
leaving some people with vulnerable versions on their systems.
-- 
"Not Hercules could have knock'd out his brains, for he had none."
-- Shakespeare


signature.asc
Description: PGP signature

Bug#847040: evil-el: test suite fails under emacs25

[Dmitry Bogatov]

[2016-12-06 09:38] Sean Whitton 
> I tested `hg tip` and reported a bug upstream:
> https://bitbucket.org/lyro/evil/issues/731/test-suite-fails-with-emacs-25

Thank you. You saved me great pain.

> Once I update dh-elpa, all the elpa-* packages you list would be fixed.
> We have filed bugs against the others, and might NMU to bump
> s/emacs24/emacs25/.
>
> I have not yet updated dh-elpa because of evil-el's test suite, i.e.,
> this bug is blocking updating dh-elpa.  If the upstream fix proves to be
> very difficult and upstream is unable to provide a fix soon, we have two
> options:
>
> 1. Update dh-elpa anyway, causing evil-el to FTBFS, and bump this bug to
> RC-severity to keep evil-el out of stretch.  Not ideal, but evil-el has
> never been in testing anyway thanks to #829299.
>
> 2. Update dh-elpa and comment out the failing tests in evil-el.
>
> I don't think we should proceed with option (2) unless we are confident
> that elpa-evil works fine for everyday usage under emacs25, and #829299
> gets fixed.  (If #829299 is not fixed, option (2) achieves nothing.)
>
> I'd like to ask you to do two things:
>
> - Since you use evil, could you run elpa-evil under emacs25 for the next
>   two or three weeks for your regular usage, and report back?

I switched to emacs25 already (since this bug report). So far, no
changes.

> - Could you fix #829299 based on the private e-mails we exchanged a few
>   weeks ago, please?

I already pushed (but not released) fix for #829299 (d057d2).

Do you want me to release it right now? Or Should we wait wait for
resolution of current (#847040) bug -- either upstream releases new
version, either we are forced to disable tests.

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgpPtbGUBPKgD.pgp
Description: PGP signature

Bug#836844: eigen3: autopkgtests fail on ppc64el - solution

[TFAUCK]

Hello,
I found the missing information in POWER ISA

/To use a multiply-add to perform an IEEE or Java//
//compliant multiply, the addend must be -0.0. This//
//is necessary to insure that the sign of a zero result//
//will be correct when the product is -0.0 (+0.0 + -0.0//
//t +0.0, and -0.0 + -0.0t -0.0). When the sign of a//
//resulting 0.0 is not important, then +0.0 can be//
//used as an addend which may, in some cases,//
//avoid the need for a second register to hold a -0.0//
//in addition to the integer 0/floating-point +0.0 that//
//may already be available./

so the example shows it:

$ cat t2.c
#include "stdio.h"
#include "altivec.h"
int main() {
vector float X={ -1, 0, 0, 0 };
vector float Y={ -1, -1, -1, -2 };
vector float Z, V;
*vector float p4f_ZERO={ 0, 0, 0, 0 };**
**vector float p4f_mZERO={ -0.0, -0.0, -0.0, -0.0 };*
Z = vec_madd(X, Y, p4f_ZERO);
V = vec_madd(X, Y, p4f_mZERO);
printf("%f %f %f %f \n",Z[0], Z[1], Z[2], Z[3]);
printf("%f %f %f %f \n",V[0], V[1], V[2], V[3]);
vector float U;
U= X * Y ;
printf("%f %f %f %f \n",U[0], U[1], U[2], U[3]);
return(0);
}

$ gcc t2.c
debian@vm18:~$ ./a.out
1.00 0.00 0.00 0.00
*1.00 -0.00 -0.00 -0.00 *
1.00 -0.00 -0.00 -0.00

So the vector p4f_ZERO must be modified with a signed value of -0.0 in
order to have that function to work.

-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

Bug#847304: documentation mismatch on --recommends-section=sparql

[chrysn]

Package: dh-python
Version: 2.20160818
Severity: minor
File: /usr/bin/dh_python3

While dh_python[23] accept repeated --recommends-section=S arguments,
the dh_python3 man page describes an option with
--recommends-sections=SECTIONS (single plural argument instead of
repeated singular ones), and the dh_python2 man page does not show it at
all. The output of --help on the utilities is correct.

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

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

Versions of packages dh-python depends on:
pn  python3:any  

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  libdpkg-perl  1.18.15

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#846133: RM: ming -- RoQA; orphaned; RC-buggy; security

[Salvatore Bonaccorso]

Control: tags -1 - moreinfo

Hi Scott,

On Fri, Dec 02, 2016 at 08:51:52AM -0500, Scott Kitterman wrote:
> On Mon, 28 Nov 2016 16:59:23 +0100 =?utf-8?b?T25kxZllaiBTdXLDvQ==?= 
>  wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Dear ftp-masters,
> > 
> > please remove ming from Debian unstable, it has been unmaintained by
> > respective maintainer since 2010 and orphaned since then.  It's also
> > RC-buggy and has several security issues.
> 
> Checking reverse dependencies...
> # Broken Build-Depends:
> gnash: libming-dev
>libming-util
> 
> This will have to be resolved first.  Please remove the moreinfo tag once 
> these build-deps have been addressed.

Should have been resolved in meanwhile.

Regards,
Salvatore

Bug#847303: global: htags got SIGABRT when analyzing long line(4096 byte)

[Guoji.Ma]

Package: global
Version: 5.7.1-3
Severity: important
Tags: upstream

Dear Maintainer,

   when i used htags to generate htmls for package vortex-1.1.18.b2359.tar.gz,
I got "Aborted, ... htags: '/usr/bin/global -x --nofilter=path ".*"' failed."
The command are:
cd vortex-1.1.18.b2359
gtags
htags --suggest

In the package vortex-1.1.18.b2359, file vortex-regression-common.h and vortex-
regression-client.c have very long lines, about 4096 byte. when i delete the
lines, htags succeed.




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

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

Versions of packages global depends on:
ii  dpkg  1.18.15
ii  install-info  6.3.0.dfsg.1-1+b1
ii  libc6 2.24-7

global recommends no packages.

Versions of packages global suggests:
ii  apache2 [httpd]2.4.23-8
ii  chromium [www-browser] 53.0.2785.143-1
ii  doxygen1.8.12-1
ii  firefox-esr [www-browser]  45.5.1esr-1
ii  id-utils   4.6+git20120811-4
ii  lynx [www-browser] 2.8.9dev11-1
ii  w3m [www-browser]  0.5.3-33

Bug#846741: Pending fixes for bugs in the rkt package

[pkg-go-maintainers]

tag 846741 + pending
thanks

Some bugs in the rkt package are closed in revision
8cf6e3024d913c16e6b363926c14b86f2d595d9c in branch 'master' by Dmitry
Smirnov

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/rkt.git/commit/?id=8cf6e30

Commit message:

rules: re-build .pb.go file(s) (Closes: #846741).

Bug#844789: [Debian-science-sagemath] GAP: issue related to compressed manual.six: PATCHES

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

On 07/12/16 02:45, Ximin Luo wrote:
> However, as far as I call tell, these do not cause any failures. In
> fact, I haven't been able to reproduce these Sage GAP failures that
> this bug is supposed to be about. Could you please copy and paste the
> test failures here, so that I know what I am supposed to be looking
> for?

I could reproduce the failures with the following command, from the debian 
source folder:

$ ( cd sage; ./sage -t -d --long src/sage/interfaces/gap.py )

Right now I cannot because I deleted my former schroot environment, and the 
former procedure
seems not to work in the current one.

In fact you may want to trace it:

$ mkdir /tmp/sage-gap-debug
$ ( cd sage ; strace -o  /tmp/sage-gap-debug -ff ./sage -t -d --long 
src/sage/interfaces/gap.py ; )

You may also want to uncomment the second bottom line in 
./debian/build/usr/share/sage/ext/gap/sage.g

Keep in mind that the test launches a multitude of jobs, so we are in a sea of 
EPIPE so to speak.


Jerome


- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJYR6H9AAoJED+SGaZ/NsaLwBggAIqtu2xagq4vmxjVoKT+dt9s
Y9i/QNmybj2/qGGd/aay3RlaWvriL4plZDzhs2L8QK0FeZgzvyqpJnbI7SOngKEN
cvgYDaNOCLJbfIHjFzGvv1gq2NaJx8SP/qqVNVRcxB1yRQxaK7aYNpsDDyukojVc
eoNkL4NBs9/n9QOhTlFFvZB35pAxVSjK+wTyTyJNt/2jQkehQdMsgmn2ngiYX+G8
IhY2++xZQfF/bWrDgCj8TL4kgT6sDEA5cGSUmae6gSijDxM5h8xwbRSMHc/IEQyE
RPKVL60dts0bySbO0H9ujmRoLGP0pKugpChr+wyhHv0GhHwLMe6gqda9MKOk19Qd
yKWvecBOwcHlE5y7c9XGa/pbvF1eFI9aQsjDgyubm45pEGM0A4CRqc3hrcgE/U0y
TuWNESPdtWtDxICvUFxx3Qe6JtcZU9Djq8/i5N9N0jLgKv/MI1f9qppAB7zyn53H
HnrnQ069Gm6gRAyceqv0VRbfL3kJRDrN+XdppOKQ9MNhSwS30OTIjJ2+CDKVa/xF
ehdbyRVuYPeFWUphyX3L58S5OhQLVybbTWbRJ70z67WQoOBJlAxLaI5KYN/YsRey
SzntsmzITNIizl3dmScwKySDgdTNQ2p0nvafE4oqPBRvygZAfFan+auMoJCM4BR6
abC7SMqw2geIajoP6OIDToERk8H+aLNvTX3F8xGIN3SWkdQc3Il+fl6TB1seT9hZ
2EPiSzXvLGWcAQmDofx9HwUBMMKxU7nxFXxb8vH8l0RwA4lH6iPnZmRmI2tW/BQT
b1xOfCJACGM5+tl47lFkhMqGSZ8EfeCa8VB7oFV75PiWAckqjjy3xNxN/jsrFE4x
4C2w2qLTKmgGLotJSc4fQnyVV7wqobrUj9XZ3YKm3nfGRCjir5a9IgbzOA9vWBym
Y28uLrcB0JWUnGy3bT9PPaPxrxXcvKHXZ8H5eC0rtJckxmMtFQnh65P4UuSxUnqb
ojmvhh0EMdcabwKIoi/MqWtX5REBMeItPQxfI14pIw2GABR85sJckO4Czo8s6on8
xyc9sJEX79fhJ2fz7TLRTIp4lyC6wiksFFPkTJoZvNwTJRMnS6VUOvtHceq+liLw
YL1dJ/wmxKbBlf+qtqfyOpqNil1GQ0Orp6oHveXHfP+vD9rxaCudAV8Hz/FzGZic
HoSafZudf7Nir53vTrSaHjrbksRLPKd0YiCV0RrTJUWx6yAGG1NU1e4+AFWOo13o
nGHacTwCUbCsMYUTS8GlJufonMJ0w0SXaXYUIXVUKpgQGpNxhRw60bTajJjgR+Kk
tVTHRFZzO4fo32OH1/9b1Y/xp+eHS+z1meNBWYMUot9jMy79r/iJIxKSmeysNck=
=24lm
-END PGP SIGNATURE-

Bug#847301: libpam-krb5: PAM error message "adding faulty module pam_makedir.so (and many others)

[Duncan Hare]

Package: libpam-krb5
Version: Jessie Latest
Severity: grave
Tags: security
Justification: renders package unusable



-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l and i386

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

Bug#847302: allow creating multiple binaries from single repo

[Pirate Praveen]

package: npm2deb
severity: wishlist
version: 0.2.6-1
Control: forwarded -1 https://github.com/LeoIannacone/npm2deb/issues/46
Control: block 845227 by -1

Placeholder for upstream issue
https://github.com/LeoIannacone/npm2deb/issues/46



signature.asc
Description: OpenPGP digital signature

Bug#847287: [Pkg-roundcube-maintainers] Bug#847287: roundcube: Roundcube 1.2.2: Remote command execution via malicious email composing

[Salvatore Bonaccorso]

Hi,

On Wed, Dec 07, 2016 at 12:30:42AM +0100, Guilhem Moulin wrote:
> Hi,
> 
> On Tue, 06 Dec 2016 at 23:05:59 +, Juan Rossi wrote:
> > Version: 1.1.4+dfsg.1-1~bpo8+1
> > […]
> > So probably it is important to update to upstream version 1.2.3
> 
> Unfortunately 1.2.x has many dependencies that aren't in
> jessie-backports yet.  I personally don't have the time nor energy to
> maintain said dependencies, so we asked backports folks for an exception
> to stick to 1.1.x for the bpo version, exception which was rejected.
> I'm afraid the remaining alternative is to take remove the package from
> jessie-backports :-(

Upstream fix:

https://github.com/roundcube/roundcubemail/commit/f84233785ddeed01445fc855f3ae1e8a62f167e1

Regards,
Salvatore

Bug#835265: Debian bigs #835265

[Jörg Frings-Fürst]

archive 835265
thanks

Hi,

I don't see why this bug is unarchived.

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-54470 Lieser

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#845227: trying my JS skills

[Pirate Praveen]

Control: forwarded -1 https://github.com/lodash/lodash/issues/2868

On Mon, 5 Dec 2016 12:41:12 +0100 Paolo Greppi 
wrote:
> I am not sure what you want to achieve (and I ignore the intent of
> upstream) 

It seems much simpler than I thought, they are maintaining these in a
separate branch.

https://github.com/lodash/lodash/tree/npm-packages

We can generate all the binary packages from a single repo. Since babel
also follows a similar structure (possibly more projects), it would be a
good idea to modify npm2deb to generate multiple binaries from a single
repo.



signature.asc
Description: OpenPGP digital signature

Bug#840424: RFS: verilog-mode

[Kiwamu Okabe]

Dear Sean,

On Wed, Dec 7, 2016 at 1:14 PM, Sean Whitton  wrote:
> Looks good, but you need "Forwarded: not-needed" not "Forwarded: no".

I think "Forwarded: no" is valid, because
http://dep.debian.net/deps/dep3/ say following:

```
Forwarded (optional)

Any value other than "no" or "not-needed" means that the patch has
been forwarded upstream.
```

Best regards,
-- 
Kiwamu Okabe at METASEPI DESIGN

Bug#828371: lastpass-cli: diff for NMU version 1.0.0-1.1

[Troy Heber]

Hello Sebastian,

Thanks for driving the patch through with upsteam. I'm good with the
NMU so there is no reason to add any additional delay.

Troy

On 12/06/16 21:19, Sebastian Andrzej Siewior wrote:
> Control: tags 828371 + patch
> Control: tags 828371 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for lastpass-cli (versioned as 1.0.0-1.1) and
> uploaded it to DELAYED/4. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> Sebastian

> diff -Nru lastpass-cli-1.0.0/debian/changelog 
> lastpass-cli-1.0.0/debian/changelog
> --- lastpass-cli-1.0.0/debian/changelog   2016-10-20 16:17:08.0 
> +0200
> +++ lastpass-cli-1.0.0/debian/changelog   2016-12-06 21:10:47.0 
> +0100
> @@ -1,3 +1,10 @@
> +lastpass-cli (1.0.0-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Get it built against openssl 1.1.0 (Closes: #828371).
> +
> + -- Sebastian Andrzej Siewior   Tue, 06 Dec 2016 
> 21:10:47 +0100
> +
>  lastpass-cli (1.0.0-1) unstable; urgency=medium
>  
>* New upstream 1.0.0
> diff -Nru 
> lastpass-cli-1.0.0/debian/patches/0001-cipher-support-opaque-EVP_CIPHER_CTX.patch
>  
> lastpass-cli-1.0.0/debian/patches/0001-cipher-support-opaque-EVP_CIPHER_CTX.patch
> --- 
> lastpass-cli-1.0.0/debian/patches/0001-cipher-support-opaque-EVP_CIPHER_CTX.patch
>  1970-01-01 01:00:00.0 +0100
> +++ 
> lastpass-cli-1.0.0/debian/patches/0001-cipher-support-opaque-EVP_CIPHER_CTX.patch
>  2016-12-06 21:09:03.0 +0100
> @@ -0,0 +1,214 @@
> +From 6e4ff62df789b55b80c14b2e7b15c25154fbf9fe Mon Sep 17 00:00:00 2001
> +From: Bob Copeland 
> +Date: Mon, 5 Dec 2016 09:55:19 -0500
> +Subject: [PATCH 1/3] cipher: support opaque EVP_CIPHER_CTX
> +
> +In OpenSSL 1.1+, EVP_CIPHER_CTX can no longer be declared on
> +the stack; instead you have to declare a pointer and then
> +use _new()/_free() to allocate or free it.  These functions
> +continue to work on older OpenSSL, so switch to the new
> +method.
> +
> +Signed-off-by: Bob Copeland 
> +---
> + cipher.c | 36 +---
> + config.c | 33 +++--
> + 2 files changed, 40 insertions(+), 29 deletions(-)
> +
> +diff --git a/cipher.c b/cipher.c
> +index 71487787af5a..ebae92e0431c 100644
> +--- a/cipher.c
>  b/cipher.c
> +@@ -147,36 +147,39 @@ int cipher_rsa_encrypt(const char *plaintext,
> + 
> + char *cipher_aes_decrypt(const unsigned char *ciphertext, size_t len, const 
> unsigned char key[KDF_HASH_LEN])
> + {
> +-EVP_CIPHER_CTX ctx;
> ++EVP_CIPHER_CTX *ctx;
> + char *plaintext;
> + int out_len;
> + 
> + if (!len)
> + return NULL;
> + 
> +-EVP_CIPHER_CTX_init();
> ++ctx = EVP_CIPHER_CTX_new();
> ++if (!ctx)
> ++return NULL;
> ++
> + plaintext = xcalloc(len + AES_BLOCK_SIZE + 1, 1);
> + if (len >= 33 && len % 16 == 1 && ciphertext[0] == '!') {
> +-if (!EVP_DecryptInit_ex(, EVP_aes_256_cbc(), NULL, key, 
> (unsigned char *)(ciphertext + 1)))
> ++if (!EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, 
> (unsigned char *)(ciphertext + 1)))
> + goto error;
> + ciphertext += 17;
> + len -= 17;
> + } else {
> +-if (!EVP_DecryptInit_ex(, EVP_aes_256_ecb(), NULL, key, 
> NULL))
> ++if (!EVP_DecryptInit_ex(ctx, EVP_aes_256_ecb(), NULL, key, 
> NULL))
> + goto error;
> + }
> +-if (!EVP_DecryptUpdate(, (unsigned char *)plaintext, _len, 
> (unsigned char *)ciphertext, len))
> ++if (!EVP_DecryptUpdate(ctx, (unsigned char *)plaintext, _len, 
> (unsigned char *)ciphertext, len))
> + goto error;
> + len = out_len;
> +-if (!EVP_DecryptFinal_ex(, (unsigned char *)(plaintext + out_len), 
> _len))
> ++if (!EVP_DecryptFinal_ex(ctx, (unsigned char *)(plaintext + out_len), 
> _len))
> + goto error;
> + len += out_len;
> + plaintext[len] = '\0';
> +-EVP_CIPHER_CTX_cleanup();
> ++EVP_CIPHER_CTX_free(ctx);
> + return plaintext;
> + 
> + error:
> +-EVP_CIPHER_CTX_cleanup();
> ++EVP_CIPHER_CTX_free(ctx);
> + secure_clear(plaintext, len + AES_BLOCK_SIZE + 1);
> + free(plaintext);
> + return NULL;
> +@@ -188,7 +191,7 @@ size_t cipher_aes_encrypt_bytes(const unsigned char 
> *bytes, size_t len,
> + const unsigned char *iv,
> + unsigned char **out)
> + {
> +-EVP_CIPHER_CTX ctx;
> ++EVP_CIPHER_CTX *ctx;
> + int out_len;
> + size_t ret_len = 0;
> + unsigned char *ctext;
> +@@ -197,24 +200,27 @@ size_t cipher_aes_encrypt_bytes(const unsigned char 
> *bytes, size_t len,
> + if (!ctext)
> + ctext = xcalloc(len + AES_BLOCK_SIZE * 2 + 1, 1);
> + 
> +-EVP_CIPHER_CTX_init();
> +-if (!EVP_EncryptInit_ex(, EVP_aes_256_cbc(), NULL, key, iv))
> ++ctx = 

Bug#847289: xsane-common: xsane can no longer find USB scanner HP OfficeJet 6310

[Jörg Frings-Fürst]

severity 847289 normal
tags 847289 + moreinfo
thanks


Hello Laurent,

thank you for spending your time helping to make Debian better with
this bug report. 


Please can you attach the output of "hp-check -rt"? 


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-54470 Lieser

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#847300: vera++ new version

[128]

Package: vera++
Version: 1.2.1-2
Severity: important

Hi,

Version 1.3.0 was released almost 2 years ago.

Thanks

Bug#847044: allow gitlab 8.13.6+dfsg2-1 to migrate testing

[Julien Cristau]

On 12/04/2016 11:18 PM, Holger Levsen wrote:
> looking at
> https://piuparts.debian.org/sid/fail/gitlab_8.13.6+dfsg2-1.log I see:
> 
> 12m12.4s ERROR: WARN: Processes are running inside chroot:
> 12m20.4s ERROR: WARN: Broken symlinks:
> 12m55.1s ERROR: FAIL: Package purging left files on system:
> 
> of which I'd consider the processes left running in the chroot to be
> seriously broken.
> 
It seems a postgresql server gets started somehow?  That does seem like
a serious issue.

BTW that log is way too verbose and full of seemingly irrelevant info to
be humanly parseable, there has to be a better way of presenting that
info, or at least making the different steps clear so you're not just
scrolling through heaps of text with no apparent structure.

Cheers,
Julien

Bug#840424: RFS: verilog-mode

[Sean Whitton]

Dear Kiwamu,

On Wed, Dec 07, 2016 at 12:45:08PM +0900, Kiwamu Okabe wrote:
> Could you review it?

Looks good, but you need "Forwarded: not-needed" not "Forwarded: no".

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#847168: devscripts: debuild fails when lintian fails, regression since 2.16.9

[James McCoy]

On Tue, Dec 06, 2016 at 09:16:33AM +0100, Raphaël Hertzog wrote:
> Since debuild now relies on dpkg-buildpackage's hook to run lintian,
> a failing lintian fails the whole build process. This was not the case
> before 2.16.9. So this is either a regression or a annoying new feature.

It was an unforeseen change, but one that I think is an improvement (as
noted in #846192).

> When I work on Kali packages, I almost always get a lintian error because
> lintian doesn't know of the suite

Can't that particular issue be fixed with vendor information provided
for lintian?  That's already done for Ubuntu.

> or because my name does not appear in
> the maintainer field.

This can also be disabled in general for Kali, if that's the expected
behavior.

> I want to be informed of the errors but I don't
> want the whole build process to be stopped... I want "gbp buildpackage" to
> create my tag and I want debuild to sign my package.

While I understand that the change is unexpected, wouldn't it be better
to resolve the errors "globally" rather than just for your dev
environment?

> If you consider this a new feature, then I ask you to document how to
> configure debuild to not fail on lintian failures (possibly adding a new
> option to ignore the result of the check-command).
> 
> If you consider this a regression, then the default check hook should have
> some "|| true" added at the end or something like that (or you can also
> add a new option to ignore the result and have its default to true instead
> of false).

I can't do any of the above without pulling the execution of lintian
back into debuild.  The actual command-line being run isn't in debuild's
control (to the extent that we could do an equivalent of "|| true") and
all debuild knows is that dpkg-buildpackage failed.  It has no idea that
it was due to the check command (lintian).

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

Bug#847044: allow gitlab 8.13.6+dfsg2-1 to migrate testing

[Julien Cristau]

On 12/04/2016 11:18 PM, Holger Levsen wrote:
> and, btw, #814393 filed against piuparts.d.o "Run redis service for packages
> depending on redis-server like gitlab" is *no* reason for gitlab failing
> to install. gitlab's postinst MUST exit cleanly even if there is no
> redis service available. 
> 
I'm not sure I buy this "MUST", to be honest...

Cheers,
Julien

Bug#846711: git-build-recipe: FTBFS: Tests failures

[James McCoy]

On Tue, Dec 06, 2016 at 10:39:44AM +, Colin Watson wrote:
> […]
>   subprocess.CalledProcessError: Command '['/usr/bin/debuild', '--tgz-check', 
> '-i', '-I', '-S', '-uc', '-us']' returned non-zero exit status 29
>   }}}
>   
>   stdout: {{{
>   dpkg-buildpackage -rfakeroot -us -uc -i -I -S --check-command=lintian
>   dpkg-buildpackage: error: check-commmand 'lintian' not found
>   }}}
> […]
> 
> git-build-recipe doesn't do anything particular to ask debuild to run
> lintian here, and it doesn't expect or require a lintian check.  It used
> to be that debuild would check whether lintian was in fact installed,
> and not run it if it wasn't; indeed, its documentation still says "then
> runs lintian on the .changes file created (assuming that lintian is
> installed)", thereby claiming that that's still what it does.  But this
> was broken in devscripts 58eb4a4a5e006bf9a2589da0ef2f36aa0d81ed8c when
> changing debuild to use dpkg-buildpackage --check-command.

Indeed.  In order to fix this, I either need to move running lintian
back into debuild or dpkg needs to not error when the check command
isn't present.

A related issue I see is that the semantics of debuild's lintian hook
and dpkg-bp's check hook are different, due to this.  debuild would not
try to run lintian, but would still call the lintian hook. However, the
hook argument would be false to indicate that lintian wasn't actually
going to be run.  In other words,

diff --git i/scripts/dpkg-buildpackage.pl w/scripts/dpkg-buildpackage.pl
index 9ec0d849d..a93edfa79 100755
--- i/scripts/dpkg-buildpackage.pl
+++ w/scripts/dpkg-buildpackage.pl
@@ -366,7 +366,7 @@ if (@rootcommand and not find_command($rootcommand[0])) {
 }
 
 if ($check_command and not find_command($check_command)) {
-error(g_("check-commmand '%s' not found"), $check_command);
+$check_command = undef;
 }
 
 if ($signcommand) {

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

Bug#840424: RFS: verilog-mode

[Kiwamu Okabe]

Dear Sean,

On Wed, Dec 7, 2016 at 11:47 AM, Sean Whitton  wrote:
>> > 2. You should patch the "New versions" and "Installation" sections out
>> > of the texinfo file, as these could be confusing to Debian users who
>> > already have the package installed and will obtain new versions from
>> > us.  Don't forget a DEP-3 patch header.
>>
>> Umm... I don't think so.
>> I should not install the info file into the verilog-mode package, with your
>> advice. Because I believe that Debian source package having big patches
>> is a bad manner.
>> Already the installation of the info file is removed at the git repo.
>
> I strongly disagree.  We should install documentation with our
> packages, so that users can use learn how to use the package without an
> active Internet connection.
>
> It is perfectly normal to remove installation and upgrade information
> from documentation by means of a large patch.  For example, see these
> patches to ocrmypdf and flycheck:
>
> https://browse.dgit.debian.org/ocrmypdf.git/tree/debian/patches/patch-docs-for-Debian.patch
> https://browse.dgit.debian.org/ocrmypdf.git/tree/debian/patches/path-to-docs-for-Debian.patch
> https://browse.dgit.debian.org/flycheck.git/tree/debian/patches/patch-README-for-Debian.patch

Thanks. It's first time to see this real example for me.
I wrote a patch "texinfo-for-Debian.patch" which is passed by checking cme:

```
$ cme check dpkg-patches
cme: using Dpkg::Patches model
loading data
checking data
check done
$ cme check dpkg
cme: using Dpkg model
loading data
Reading package lists... Done
Building dependency tree
Reading state information... Done
checking data
check done
```

Could you review it?

Best regards,
-- 
Kiwamu Okabe at METASEPI DESIGN

Bug#847044: allow gitlab 8.13.6+dfsg2-1 to migrate testing

[Pirate Praveen]

On ബുധന്‍ 07 ഡിസംബര്‍ 2016 02:02 രാവിലെ, Andreas Beckmann wrote:
>>> 12m12.4s ERROR: WARN: Processes are running inside chroot:
>>> 12m20.4s ERROR: WARN: Broken symlinks:
>>> 12m55.1s ERROR: FAIL: Package purging left files on system:
>>>
>>> of which I'd consider the processes left running in the chroot to be
>>> seriously broken.
>>
>> It is a WARN and not FAIL. You can't suddenly change meaning of these
>> just before the release to make it RC.
> 
> And the actual problem for the piuparts test failing currently 
> is a ton of cruft lying around after the package was purged:
> 
> https://piuparts.debian.org/sid/fail/gitlab_8.13.6+dfsg2-1.log
> 
> 12m55.1s ERROR: FAIL: Package purging left files on system:
>   /etc/gitlab-shell/   not owned
>   /etc/gitlab-shell/config.yml not owned
>   /etc/rc0.d/K01gitlab -> ../init.d/gitlab not owned
>   /etc/rc1.d/K01gitlab -> ../init.d/gitlab not owned
>   /etc/rc2.d/S01gitlab -> ../init.d/gitlab not owned
>   /etc/rc3.d/S01gitlab -> ../init.d/gitlab not owned
>   /etc/rc4.d/S01gitlab -> ../init.d/gitlab not owned
>   /etc/rc5.d/S01gitlab -> ../init.d/gitlab not owned
>   /etc/rc6.d/K01gitlab -> ../init.d/gitlab not owned
>   /etc/systemd/system/gitlab.service -> /dev/null  not owned
>   /etc/systemd/system/gitlab.target -> /dev/null   not owned
>   /etc/systemd/system/gitlab.target.wants/ not owned
>   /etc/systemd/system/gitlab.target.wants/gitlab.service -> 
> /lib/systemd/system/gitlab.service not owned
>   /etc/systemd/system/multi-user.target.wants/gitlab.target -> 
> /lib/systemd/system/gitlab.target   not owned
>   /usr/share/gitlab-shell/.gitlab_shell_secret -> 
> /var/lib/gitlab/.gitlab_shell_secret not owned
>   /var/cache/gitlab/   not owned
>   /var/lib/gitlab/ owned by: gitlab
>   /var/lib/gitlab/.bundle/ not owned
>   /var/lib/gitlab/.bundle/config   not owned
>   /var/lib/gitlab/.gitconfig   not owned
>   /var/lib/gitlab/.gitlab_shell_secret not owned
>   /var/lib/gitlab/.gitlab_workhorse_secret not owned
>   /var/lib/gitlab/.ssh/not owned
>   /var/lib/gitlab/.ssh/authorized_keys not owned
>   /var/lib/gitlab/Gemfile.lock not owned
>   /var/lib/gitlab/db/  owned by: gitlab
>   /var/lib/gitlab/db/schema.rb not owned
>   /var/lib/gitlab/gitlab-debian.conf   not owned
>   /var/lib/gitlab/gitlab-shell-config.yml  not owned
>   /var/lib/gitlab/gitlab.yml   not owned
>   /var/lib/gitlab/nginx.conf   not owned
>   /var/lib/gitlab/public/  owned by: gitlab
>   /var/lib/gitlab/public/uploads/  not owned
>   /var/lib/gitlab/repositories/not owned
>   /var/lib/gitlab/secrets.yml  not owned
>   /var/lib/systemd/deb-systemd-helper-enabled/gitlab.service.dsh-also  not 
> owned
>   /var/lib/systemd/deb-systemd-helper-enabled/gitlab.target.dsh-also   not 
> owned
>   /var/lib/systemd/deb-systemd-helper-enabled/gitlab.target.wants/ not 
> owned
>   
> /var/lib/systemd/deb-systemd-helper-enabled/gitlab.target.wants/gitlab.service
>not owned
>   
> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/gitlab.target
> not owned
>   /var/lib/systemd/deb-systemd-helper-masked/  not owned
>   /var/lib/systemd/deb-systemd-helper-masked/gitlab.servicenot owned
>   /var/lib/systemd/deb-systemd-helper-masked/gitlab.target not owned
>   /var/log/gitlab-shell/   not owned
>   /var/log/gitlab-shell/gitlab-shell.log   not owned
>   /var/log/gitlab/ not owned
>   /var/log/gitlab/application.log  not owned
>   /var/log/gitlab/builds/  not owned
>   /var/log/gitlab/production.log   not owned
> 
> Looks like initscripts integration is not done properly.
> Empty directories could be shipped in the package - and dpkg will take care 
> of them.
> Log files should be removed.
> 
> Anyway, only leaving stuff around should qualify for an
> ignore-piuparts hint (or however it was called).
> I didn't look at the other bug about redis-server.
> Which one btw? I didn't see anything RC open.
> 
> Ideally, we will have more finegrained classification of
> piuparts results at some point ...

Please unblock this so I can upload a new version. I will fix the
cleanup issue in a future upload.




signature.asc
Description: OpenPGP digital signature

Bug#847299: tp-smapi-dkms: does not work with newer ThinkPads

[Celejar]

Package: tp-smapi-dkms
Version: 0.41-1
Severity: normal

Dear Maintainer,

I tried loading tp-smapi on my W550s - it doesn't work:

root@lila:~# modprobe tp-smapi
modprobe: ERROR: could not insert 'tp_smapi': No such device or address

Apparently, tp-smapi doesn't work on Ivy Bridge or newer chipsets, according to
various sources, including ThinkWiki:

http://www.thinkwiki.org/wiki/Tp_smapi#Model-specific_status

I suggest that this be documented, along with the suggestion that the user
consider an acpi-call based solution, such as TLP (Debian packages tlp and
acpi-call-dkms).

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

Kernel: Linux 4.8.12 (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 tp-smapi-dkms depends on:
ii  dkms  2.2.0.3-2

tp-smapi-dkms recommends no packages.

tp-smapi-dkms suggests no packages.

-- no debconf information

Bug#844605: X11 segfault with AMD GPU since 4.8.x / Firmware issue

[Ben Hutchings]

Control: reassign -1 firmware-amd-graphics
Control: forcemerge -1 838858

On Thu, 17 Nov 2016 16:04:51 +0100 Patrick Matthäi
 wrote:
[...]
> dmesg reports a firmware missmatch:
[...]
> [3.262451] radeon :01:00.0: firmware: failed to load 
> radeon/bonaire_k_smc.bin (-2)
> [3.262454] radeon :01:00.0: Direct firmware load 
> forradeon/bonaire_k_smc.bin failed with error -2
> [3.262845] radeon :01:00.0: firmware: direct-loading 
> firmwareradeon/BONAIRE_smc.bin
> [3.262846] ci_fw: mixing new and old firmware!
[...]

Missing firmware isn't a kernel bug, it's a bug in a firmware package.
(And X blowing up is probably an X driver bug.)

The missing firmware is fixed in the latest firmware-nonfree upload.

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson


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

Bug#847297: electric: Build-depends on scala but doesn't seem to use it

[Stuart Prescott]

Source: electric
Version: 9.07+dfsg-1
Severity: normal

Dear Maintainer,

The 'electric' source package build-depends on scala but does not seem
to actually use the scala compiler at all in the build. The source package
contains lots of empty directories under 'scala' and there are a few scala
source files elsewhere in the plugins. It seems unlikely that this is the
intended situation; either scala isn't needed for the build or something
has gone awry with the build and some of the package isn't being built as
intended (or I've completely missed something in the build system and build
logs!).

cheers
Stuart

Bug#846961: [Pkg-javascript-devel] Bug#846961: recent update of libjs-jquery-ui broke gitlab

[Pirate Praveen]

On 2016, ഡിസംബർ 6 3:16:09 PM IST, Andrew Lee  wrote:
>I am packaging a complax package called Open Build Service. I also got
>hitted by this.

Seems a simple fix 
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7964/diffs

You need to patch application.js to use new paths. I will update 
ruby-jquery-ui-rails to 6.0.1.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#847294: Patch

[Rafael David Tinoco]

Submitting the debdiff that handles the problems described in this bug. 



unstable_pcs_0.9.155-2.debdiff
Description: Binary data

Bug#846961: [Pkg-javascript-devel] Bug#846961: Bug#846961: recent update of libjs-jquery-ui broke gitlab

[Pirate Praveen]

On 2016, ഡിസംബർ 7 1:11:14 AM IST, Paul Gevers  wrote:
>To be honest, I don't have a clue what ruby-jquery-ui-rails is doing
>(never heard of the package before), so I can't answer that question
>yet. One thing, the latest version of upstream ruby-jquery-ui-rails is
>also embedding 1.12.1, so apparently upstream already converted what is
>required.

ruby-jquery-ui-rails is just a wrapper (rails engine in rails speak) for 
jquery-ui. It just makes it easy for rails apps to use jquery-ui via rails 
asset pipeline. It just embeds jquery-ui and set its path as a rails engine. It 
does not have any other adaptations other than setting paths for the embedded 
jquery-ui. So it does not care what jquery-ui version is shipped. They provide 
a separate VERSIONS.md file to know the mapping between jquery-ui-rails and 
jquery-ui version.

The apps that depend on ruby-jquery-ui-rails should be ported to be able to 
work using the new jquery-ui version. Ie, upstream code change is required.

As a last resort, we can remove the symlinks and use the embedded copy of 
jquery-ui. We are planning to do the same for jquery-rails as jquery 3 broke 
diaspora.( #846916).

We should coordinate updates of these packages in future.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#844789: [Debian-science-sagemath] GAP: issue related to compressed manual.six: PATCHES

[Ximin Luo]

Jerome BENOIT:
> Hello Ximin, can you strace ?
> 

Sorry, it's late and I'm being quite useless.

>> $ ./sage -c 'gap.help('SymmetricGroup', pager=False)' 
>> [..]
>> #W  corrupted 'manual.six': ##W (in stream: 
>> InputTextFile(/usr/share/gap/doc/t\

^ this was caused by me doing a typo. Look, I used single quotes twice there. 
Also the invocation is wrong, it should be 

$ ./sage -c "print(gap.help('SymmetricGroup', pager=False)[:100])"
  
  50 Group Libraries
  
  When you start GAP, it already knows several groups. Currently GAP init

which works fine.

> $ python -c 'import subprocess; subprocess.Popen(["gap", "-q"], 
> stdin=subprocess.PIPE).communicate("?SymmetricGroup")'
>
> gzip: stdout: Broken pipe
> Help: several entries match this topic - type ?2 to get match [2]
>
> [1] Reference: SymmetricGroup
> [2] Reference: SymmetricGroup (for a degree)
> [3] Reference: SymmetricGroup (for a domain)
>
> $ python -c 'import signal, subprocess; subprocess.Popen(["gap", "-q"], 
> stdin=subprocess.PIPE,   preexec_fn=lambda: signal.signal(signal.SIGPIPE, 
> signal.SIG_DFL)).communicate("?SymmetricGroup")'
> Help: several entries match this topic - type ?2 to get match [2]
>
> [1] Reference: SymmetricGroup
> [2] Reference: SymmetricGroup (for a degree)
> [3] Reference: SymmetricGroup (for a domain)
>

These examples were correct, indicating the original python bug. Another way to 
avoid the error messages is to add "2>/dev/null" to the gunzip invocation in 
GAP's src/sysfiles.c.

However, as far as I call tell, these do not cause any failures. In fact, I 
haven't been able to reproduce these Sage GAP failures that this bug is 
supposed to be about. Could you please copy and paste the test failures here, 
so that I know what I am supposed to be looking for?

I will also try tomorrow when I have a fresher mind and do a full rebuild from 
scratch.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#840424: RFS: verilog-mode

[Sean Whitton]

Dear Kiwamu,

On Wed, Dec 07, 2016 at 11:01:46AM +0900, Kiwamu Okabe wrote:
> > 2. You should patch the "New versions" and "Installation" sections out
> > of the texinfo file, as these could be confusing to Debian users who
> > already have the package installed and will obtain new versions from
> > us.  Don't forget a DEP-3 patch header.
> 
> Umm... I don't think so.
> I should not install the info file into the verilog-mode package, with your
> advice. Because I believe that Debian source package having big patches
> is a bad manner.
> Already the installation of the info file is removed at the git repo.

I strongly disagree.  We should install documentation with our
packages, so that users can use learn how to use the package without an
active Internet connection.

It is perfectly normal to remove installation and upgrade information
from documentation by means of a large patch.  For example, see these
patches to ocrmypdf and flycheck:

https://browse.dgit.debian.org/ocrmypdf.git/tree/debian/patches/patch-docs-for-Debian.patch
https://browse.dgit.debian.org/ocrmypdf.git/tree/debian/patches/path-to-docs-for-Debian.patch
https://browse.dgit.debian.org/flycheck.git/tree/debian/patches/patch-README-for-Debian.patch

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#834386: linux-image-4.6.0-1-amd64: Locks hard on boot.

[Ben Hutchings]

Nathan, I'm sorry we didn't answer this report much sooner.

Have you tried upgrading to a newer kernel version, and did that
resolve the problem?  The latest version in testing is now 4.8.7-1.

If the latest version has the same problem, does adding the kernel
parameter 'nomodeset' allow the system to boot all the way to a text-
mode login prompt?

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson



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

Bug#842458: upgrade-reports: After dist-upgrade from jessie to testing, kernel doesn't load, not a single message on screen

[Ben Hutchings]

Control: severity -1 important
Control: tag -1 moreinfo

On Sat, 29 Oct 2016 15:10:01 +0300 Pyotr  wrote: 
[...]
>* What was the outcome of this action?
>   System doesn't load. Instead of "Loading initramfs" just blinking '_'.

That message is no longer printed by default, so this doesn't tell us
how far boot progressed.

Please try the 'recovery mode' option under 'Advanced options' in the
GRUB menu.  That enables, among other things, verbose output from the
kernel and initramfs code.  Send us the boot messages (a photograph is
fine as long as the text is readable).

>* What outcome did you expect instead?
>   That system would load just like it was after fresh install.
> 
> This is probably due to my PC is being very old - Celeron 1.1 Ghz,
> 512Mb Ram, motherboard Elitegroup P6VXAT.

All Celeron processors should still be supported.  We've only dropped
support for 586-class processors (like the original Pentium).

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson



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

Bug#841883: linux-image-4.7.0-1-686: cannot boot with 4.7.8-1, stuck at loading initrd

[Ben Hutchings]

On Thu, 10 Nov 2016 21:45:54 +0800 Sharuzzaman Ahmat Raslan  wrote:
> Hi Ben,
> 
> I'm using Testing, and the package is not in testing yet.
> 
> I have seen that the migration to testing was blocked by block-udeb..
> 
> Hopefully the package can be migrated to testing soon.

testing now has 4.8.7-1; please report whether it works for you.

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson


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

Bug#840424: RFS: verilog-mode

[Kiwamu Okabe]

Hi Sean,

On Wed, Dec 7, 2016 at 8:47 AM, Sean Whitton  wrote:
> 1. I think you should tweak the copyright for Makefile.  You wrote
>
> Copyright: 2008-2013, Michael McNamara
>  2008-2013, Wilson Snyder
>
> but I think the following is more accurate:
>
> Copyright: 2008-2013 Michael McNamara and Wilson Snyder
>
> IANAL but I think there might be a legal distinction between these two,
> so it's best to follow what upstream wrote in the file header.

Fixed. And following description also has same issue, which is fixed.

```
Files: 0test.el batch_prof.el batch_test.el batch_test.pl
Copyright: 2008-2013, Michael McNamara and Wilson Snyder
```

> 2. You should patch the "New versions" and "Installation" sections out
> of the texinfo file, as these could be confusing to Debian users who
> already have the package installed and will obtain new versions from
> us.  Don't forget a DEP-3 patch header.

Umm... I don't think so.
I should not install the info file into the verilog-mode package, with your
advice. Because I believe that Debian source package having big patches
is a bad manner.
Already the installation of the info file is removed at the git repo.

Could you review the git repo, again?

Best regards,
-- 
Kiwamu Okabe at METASEPI DESIGN

Bug#847294: pcs cluster auth does not generate tokens file & hangs on find

[Rafael David Tinoco]

Package: pcs
Version: 0.9.155-1
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm working on the following Ubuntu bugs:

https://bugs.launchpad.net/ubuntu/+source/pcs/+bug/1580035
https://bugs.launchpad.net/ubuntu/+source/pcs/+bug/1580045
https://bugs.launchpad.net/ubuntu/+source/pcs/+bug/1640923
https://bugs.launchpad.net/ubuntu/+source/pcs/+bug/1640919

And bugs LP: #1640923 and LP: #1640919 should be fixed in Debian.
I'm attaching package debdiffs for both bugs as a fix suggestion.
I'm also proposing the same patch to Zesty, Yakkety & Xenial.

Upstream patch for LP: #1640919 was already accepted:
https://github.com/ClusterLabs/pcs/pull/119

## Problems Description ##

LP: #1640919 - pcs cluster auth does not generate "tokens" file

$ sudo pcs cluster auth cluster01 cluster02 -u hacluster
Password:
cluster01: Authorized
cluster02: Authorized
$ sudo ls -l /var/lib/pcsd/tokens
ls: cannot access '/var/lib/pcsd/tokens': No such file or directory

If corosync and pacemaker are stopped and /etc/corosync.conf is
removed, then /var/lib/pcsd/tokens gets created successfully.

$ systemctl stop pacemaker
$ systemctl stop corosync
$ sudo rm /etc/corosync/corosync.conf
$ sudo pcs cluster auth cluster01 cluster02 -u hacluster
Password:
cluster01: Authorized
cluster02: Authorized

ls -l /var/lib/pcsd/tokens
- -rw--- 1 root root 168 Nov 10 11:54 /var/lib/pcsd/tokens

LP: #1640919 - pcs cluster setup hangs Edit

PCS cluster setup hangs when cleaning up old cluster configurations,
apparently due to a "find" command attempting to search through a
fuse mountpoint directory (/var/lib/lxcfs/*).

$ sudo pcs cluster setup --name cluster cluster01 cluste02
Destroying cluster on nodes: cluster01, cluster02...
cluster01: Stopping Cluster (pacemaker)...
cluster02: Stopping Cluster (pacemaker)...
- ---setup hangs here

The setup seems to hang because of this line in
/usr/lib/python2.7/dist-packages/pcs/cluster.py (which attempts to
delete stale cluster configuration xml files:

os.system("find /var/lib -name '"+name+"' -exec rm -f \{\} \;")

I'm attaching the fixes soon, following the bug opening.

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYR2fHAAoJEB8C+bMrFbSZLRUQAJ9xspeoXOsBcfdMv3XSWsj5
hVJnpZsLO/XuZeSswyigMNCSqihzK1ILHBWmBzCOAOnkI8XKC65uZ4MWtFwPmt/C
QuxOEQ46XV212YfYY2+HKEJodHwf6O6dxEkLeVmkM7wbclaijPDmnFSmJTNrIDv5
OQDzUFf7XUA0Id8e3DyWG73UayEx2A449kkkbCAJZzIomykY2PE8yE8IyTMg0W+g
R4t6roEm08pqMSGLqyiRwUVQY7qiFPEO25p1fogOxKG+ZiUCd0LJiCMY5kwRMU2Q
d+rUNkBSkYRII4bMMCu0nNheDVVXsJ8S6uDHfFTTNPd7WVC4+8EXZFWj2LPZbowI
wMvC6dwAdw8yJCQtCKVkHtbyPNQaF2z1sNrsqqRGmbvxTX3L+hUS27ufm2qGKYMp
B+Zv6h7nRUIgWCYdQUZG0W3j/T2DT8oxUfvivaTp8pl3jw3tZtI+x83W8y6sovGN
oPYmsfrveuLMql7tBaKP8jy7H3C8QlzX2bfl+FXWJ2GS6eb7witEow/F7pi2NT2t
XWFfkvrrTRvrck8VhMJZDrsUoXOpo5caxHtW7UJ4tiex/Jp3As340KMi0OAMTV9X
K/ErCQs27WbRagOIwwNHDpHhsIVD9VO09xf8RXWQOyEDQnJ8gFGjw9M3X3ZkwkAn
wmR4HWvoRZ4nEdhaHU4D
=+SWU
-END PGP SIGNATURE-

Bug#847287:

[Juan Augusto Rossi]

Hi

I guess if package 1.2.3 cannot be back ported to jessie due dependencies
issues, and there is no exception that would leave jessie users to backport
manually to 1.1.7 that includes the fix

https://roundcube.net/news/2016/11/28/updates-1.2.3-and-1.1.7-released

Issue it is quite severe, I wonder if they would reconsider the exception
to stay on 1.1.X.

Regards

Juan.-

Bug#149556: links: Links doesn't use LC_ALL variable for i18n / Bug#762744: Please default output codepage to locale

[Axel Beckert]

Version: 2.11-1

Hi,

Dominique Devriese wrote:
> Links currently doesn't use the LC_ALL variable for determining what
> language to use, like _all_ other i18n'd programs do (at least all those
> using GNU gettext).

martin f krafft wrote:
> Unless -codepage is given, links seems to -dump to us-ascii by
> default. Please use LC_CTYPE for determining the right character set
> to use!

I just noticed that Links examines the LANG variable to set the UI
language. While that's neither LC_ALL nor LC_CTYPES, it's a common
variable in that context and IMHO validates to close those two bug
reports (#149556 and #762744).

Please reopen them if you disagree that examining $LANG suffices.

Tested with: env LANG=de_CH.UTF-8 xlinks2 https://axel.beckert.ch/

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

Bug#810392: fixed in 0xffff/0.6.1+git20160627-1

[Pali Rohár]

On Wednesday 07 December 2016 02:21:51 Sebastian Reichel wrote:
> Maybe just report a bug on github? It looks like the issues are
> actively checked there: https://github.com/libusb/libusb/issues

https://github.com/libusb/libusb/issues/237

-- 
Pali Rohár
pali.ro...@gmail.com


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

Bug#828457: nodejs: FTBFS with openssl 1.1.0

[Jérémy Lal]

2016-11-03 17:49 GMT+01:00 Kurt Roeckx :
> On Thu, Nov 03, 2016 at 10:42:50AM -0400, Sandro Tosi wrote:
>> On Sun, 11 Sep 2016 20:10:53 +0200 =?UTF-8?B?SsOpcsOpbXkgTGFs?=
>>  wrote:
>> > 2016-09-11 14:25 GMT+02:00 Kurt Roeckx :
>> >
>> > > tags 828457 + patch
>> > >
>> > > A patch for it is available at:
>> > > https://github.com/nodejs/node/pull/8491
>> > >
>> > >
>> > Wonderful, and thank you.
>> > I'll upload nodejs 6.x in experimental with your patch applied.
>>
>> Hello Jérémy, it looks like in 6.8.0 you decided to go in the opposite
>> direction ad "Build-Depends openssl 1.0.2 (Closes: #821403)" - is this
>> patch still something you plan to apply to the experimental version of
>> nodejs? any plan to move 6.x to unstable and/or get this bug fixed in
>> sid? thanks!
>
> Note that at least 1 problem has been pointed out in the pull
> request. And I understand that they did other changes to make it
> work, but I didn't really have time to look at it again.
>

Hello, i tried to backport the patches to node 6.9.2 - you can
actually run the tests
from the gbp repo's master-6.x branch.
Patches are in debian/patches/openssl/

I get the following failures:

not ok xxx test/parallel/test-https-agent-session-eviction
 that test just hanged so i removed it. Upon inspection the second
request does not fail.

not ok 580 parallel/test-https-agent-session-reuse
  ---
  duration_ms: 0.263
  severity: fail
  stack: |-
_tls_wrap.js:883
  this._sharedCreds.context.setTicketKeys(keys);
^

TypeError: Ticket keys length incorrect
at TypeError (native)
at Server.setTicketKeys (_tls_wrap.js:883:29)
at Server.
(/home/dev/Software/debian/nodejs/collab-maint/test/parallel/test-https-agent-session-reuse.js:31:12)
at emitTwo (events.js:106:13)
at Server.emit (events.js:191:7)
at HTTPParser.parserOnIncoming [as onIncoming] (_http_server.js:546:12)
at HTTPParser.parserOnHeadersComplete (_http_common.js:99:23)

not ok 979 parallel/test-tls-0-dns-altname
  ---
  duration_ms: 0.109
  severity: fail
  stack: |-
_tls_common.js:69
  c.context.setCert(options.cert);
^

Error: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
at Error (native)
at Object.createSecureContext (_tls_common.js:69:17)
at new Server (_tls_wrap.js:768:25)
at Object.exports.createServer (_tls_wrap.js:861:10)
at Object.
(/home/dev/Software/debian/nodejs/collab-maint/test/parallel/test-tls-0-dns-altname.js:13:18)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)

not ok 983 parallel/test-tls-alpn-server-client
  ---
  duration_ms: 0.211
  severity: fail
  stack: |-
events.js:160
  throw er; // Unhandled 'error' event
  ^

Error: socket hang up
at TLSSocket.onHangUp (_tls_wrap.js::19)
at TLSSocket.g (events.js:291:16)
at emitNone (events.js:91:20)
at TLSSocket.emit (events.js:185:7)
at endReadableNT (_stream_readable.js:974:12)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickCallback (internal/process/next_tick.js:98:9)
  ...
not ok 986 parallel/test-tls-cert-regression
  ---
  duration_ms: 0.169
  severity: fail
  stack: |-
_tls_common.js:69
  c.context.setCert(options.cert);
^

Error: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
at Error (native)
at Object.createSecureContext (_tls_common.js:69:17)
at new Server (_tls_wrap.js:768:25)
at Object.exports.createServer (_tls_wrap.js:861:10)
at test
(/home/dev/Software/debian/nodejs/collab-maint/test/parallel/test-tls-cert-regression.js:36:20)
at Object.
(/home/dev/Software/debian/nodejs/collab-maint/test/parallel/test-tls-cert-regression.js:44:1)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)

not ok 1013 parallel/test-tls-ecdh-disable
  ---
  duration_ms: 0.211
  severity: fail
  stack: |-

assert.js:85
  throw new assert.AssertionError({
  ^
AssertionError: [object Object]
at Server.exports.fail
(/home/dev/Software/debian/nodejs/collab-maint/test/common.js:426:10)
at emitOne (events.js:96:13)
at Server.emit (events.js:188:7)
at TLSSocket. (_tls_wrap.js:827:14)
at emitNone (events.js:86:13)
at TLSSocket.emit (events.js:185:7)
at TLSSocket._finishInit (_tls_wrap.js:603:8)
at TLSSocket.onhandshakedone (_tls_wrap.js:52:8)
at 

Bug#810392: fixed in 0xffff/0.6.1+git20160627-1

[Sebastian Reichel]

fixed 810392 0x/0.6.1+git20160627-1
thanks

(While I have no problem keeping this bug open for discussion the
version above does not use libusb 0.1, so the bug itself is fixed
there)

Regarding libusb1.0 bugs: For me it's exactly the other way around.
I did have some problems with libusb0.1 on USB3 ports (I did not
further analyse them, since it worked with the USB2 ports. On my
current hardware it also worked with the USB3 ports). 0x linked
against libusb1.0 works like a charm for me, since I cannot
reproduce the bug myself I did not get involved.

Maybe just report a bug on github? It looks like the issues are
actively checked there: https://github.com/libusb/libusb/issues

-- Sebastian


signature.asc
Description: PGP signature

Bug#845932: Please enable FriendlyARM NanoPi NEO

[Paul Tagliamonte]

My UART chip just showed up, so I had a chance to actually try this out
tonight!

So, hot off the presses: Success! I did need to borrow the .dtb, but it
booted and I saw d-i!

However, it appears to not like the USB or Ethernet port (tried a USB
adapter, and it didn't like that either).

saw an Ubuntu image, tried booting that, and that brought up a sane
userland with network connectivity. It's likely a matter of just teaching
d-i about the right firmware

/me digs
  paul



On Sun, Nov 27, 2016 at 2:09 PM, Vagrant Cascadian 
wrote:

> On 2016-11-27, Paul Tagliamonte wrote:
> > Awesome. I preformed these steps, but I haven't attached a Serial
> > device to it yet.
> >
> > I'll continue testing further after I hook this up to serial
>
> Looks like you may also have to borrow a .dtb from linux 4.9.x:
>
>   https://packages.debian.org/search?suite=experimental;
> section=all=armhf=contents=sun8i-h3-nanopi-neo.dtb
>
> Just copy that onto the debian-installer media in the dtbs
> directory. Not sure if it'll work, but if it does, you might want to
> request a backport of it to the linux kernel packages.
>
>
> Happy testing!
>
>
> live well,
>   vagrant
>
> > On Sun, Nov 27, 2016 at 3:25 AM, Vagrant Cascadian 
> wrote:
> >> On 2016-11-26, Paul Tagliamonte wrote:
> >>> Please enable FriendlyARM NanoPi NEO
> >>
> >> Thanks for taking a stab at it!
> >>
> >>
> >> Built a test package for you, should be available here:
> >>
> >>   deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main
> >>
> >> Install u-boot-sunxi:armhf from there, which has nanopi_neo included (in
> >> fact, all other builds are disabled).
> >>
> >>
> >> To test, you could use debian-installer's daily images:
> >>
> >>   https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-
> card-images/
> >>
> >> Download firmware.none.img.gz and partition.img.gz, and then something
> >> like (just like it says in the README*):
> >>
> >>   zcat firmware.none.img.gz partition.img.gz | dd of=/dev/mmcblk0
> >>
> >>
> >> Then, reading /usr/share/doc/u-boot-sunxi/README.Debian, you can
> install
> >> the nanopi_neo u-boot image:
> >>
> >>   dd if=/usr/lib/u-boot/nanopi_neo/u-boot-sunxi-with-spl.bin
> of=/dev/mmcblk0 bs=1024 seek=8
> >>
> >>
> >> Then you ought to be able to see u-boot load on the serial console, and
> >> if you're lucky, boot into debian-installer. You may need a USB network
> >> adapter to get very far...
> >>
> >>
> >> If the u-boot bits at least work, I'll be happy to add it to the
> >> package, and add you to our list of testers. A rough guide to testing is
> >> available here:
> >>
> >>   https://wiki.debian.org/U-boot
> >>
> >>
> >> Hmmm, now that I've written this email, some of it would be generally
> >> useful to add to the wiki page...
> >>
> >>
> >> live well,
> >>   vagrant
> >
> >
> >
> > --
> > :wq
>



-- 
:wq

Bug#844789: [Debian-science-sagemath] GAP: issue related to compressed manual.six: PATCHES

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Ximin, can you strace ?

On 07/12/16 00:27, Ximin Luo wrote:
> Ximin Luo:
>> Ximin Luo:
>>> Bill Allombert:
 On Tue, Dec 06, 2016 at 01:01:00PM +, Ximin Luo wrote:
> Bill Allombert:
> Hi all,
>
> Sorry I only just briefly scanned through the thread now. However I
> found this post relating to gzip, pipes and python:
>
> https://blog.nelhage.com/2010/02/a-very-subtle-bug/
>
> which summarises the bug report here: https://bugs.python.org/issue1652

 Yes, this is exactly the problem, and it seems it has been fixed in python 
 3,
 but not in python 2.7.

>>>
>>> Ok, good to know! The blog post also contains a work-around near the end, 
>>> which is to add
>>>
>>>   preexec_fn=lambda: signal.signal(signal.SIGPIPE, signal.SIG_DFL)
>>>
>>> as a parameter to the relevant Popen call. Presumably in this case it's 
>>> wherever Sage calls GAP. Jerome, could you test?
>>>
>>
>> Hi Bill,
>>
>> I'm not sure if the above bug is the cause of this issue. I tried to 
>> reproduce it without Sage:
>>
>> $ apt-cache policy gap
>> gap:
>>   Installed: 4r8p6-1
>>   Candidate: 4r8p6-1+sage17
>>   Version table:
>>  4r8p6-1+sage17 500
>> 500 https://debian-science.alioth.debian.org/apt sid-sage/ Packages
>>  *** 4r8p6-1 500
>> 500 http://httpredir.debian.org/debian testing/main amd64 Packages
>> 500 http://httpredir.debian.org/debian unstable/main amd64 Packages
>> 100 /var/lib/dpkg/status
>>
>> $ python -c 'import subprocess; subprocess.Popen(["gap", "-q"], 
>> stdin=subprocess.PIPE).communicate("?SymmetricGroup")'
>>
>> gzip: stdout: Broken pipe
>> Help: several entries match this topic - type ?2 to get match [2]
>>
>> [1] Reference: SymmetricGroup
>> [2] Reference: SymmetricGroup (for a degree)
>> [3] Reference: SymmetricGroup (for a domain)
>>
>> $ python -c 'import signal, subprocess; subprocess.Popen(["gap", "-q"], 
>> stdin=subprocess.PIPE,   preexec_fn=lambda: signal.signal(signal.SIGPIPE, 
>> signal.SIG_DFL)).communicate("?SymmetricGroup")'
>> Help: several entries match this topic - type ?2 to get match [2]
>>
>> [1] Reference: SymmetricGroup
>> [2] Reference: SymmetricGroup (for a degree)
>> [3] Reference: SymmetricGroup (for a domain)
>>
>> So as you can see, the bug is only to do with the extra "Broken pipe" error 
>> messages. 
> 
> And in fact, if I patch src/sysfiles.c to say "gzip 2>/dev/null -cd " instead 
> of "gunzip " then the "Broken pipe" messages go away.
> 
> The below Sage/GAP error still occurs, though:
> 
>> However Sage fails in a different way:
>>
>> $ ./sage -c 'gap.help('SymmetricGroup', pager=False)' 
>>> /usr/lib/python2.7/dist-packages/ptyprocess/ptyprocess.py(220)spawn()
>> -> if use_native_pty_fork:
>> (Pdb) c
>>> /usr/lib/python2.7/dist-packages/ptyprocess/ptyprocess.py(220)spawn()
>> -> if use_native_pty_fork:
>> (Pdb) c
>> #W  corrupted 'manual.six': ##W (in stream: 
>> InputTextFile(/usr/share/gap/doc/t\
>> ut/manual.six))
>> #W  corrupted 'manual.six': ##W (in stream: 
>> InputTextFile(/usr/share/gap/doc/c\
>> hanges/manual.six))
>> #W  corrupted 'manual.six': ##W (in stream: 
>> InputTextFile(/usr/share/gap/pkg/G\
>> APDoc/example/manual.six))
>> Help: no matching entry found
>>
> 

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJYR2F/AAoJED+SGaZ/NsaLmsgf/iApRccFu1xSil7p7Pu2y2Ed
gYlaXzqYhMjELbKYb2dWok8NRO84NeOAK62YX9K2mb28MUsXgBXzC1XHzXT8SVJy
Y3EwvvmlpZE7Pr6ULavAXud/lL65u+3VPP+rv+e4esdEnE0DfQmoAAhi6t+oRPsU
M36ksqPUPTsLcVf2ITjI5rha6FF5urMf4Ng+0kmZwrc4w/B5EdntOyXySE5fS8/e
731/NCICLL3ab5FbN7pGenQqIKOKTXMmadNoLehYrHFyg7SOw17eoub/FiM6e5aq
2ubCfCBR07KEZm2t4ooKp1Pu8lpJhx/K3TqWHAmI7QtjDh7UPUkwBfGVc8YfW+/y
X753F6X+LhlEkz9TZ9v3bk6hjG1TLQzXJ1ui8oBf9oAQxDZFnUvd53L/MwNtNPG9
fIHcgwnbQPZ8MQyi8JOMgaUvGS5aB5jhS5I0y2UivNtXn+xjRx3A8mjkJrcKRWn+
+BWTlT0F9xBtJBtnCHd6DAtEWdaYZr+8wMyiT8Cm2ifb5WrmMHwbbFjvyQ6+qLLh
i78kZDu9LwT1KZzj00BgqpJnWaJtfZDGrnLUJh3d0q2+wsxNfV3lRRwHMn0zDiH1
KO/zCILK2GP6a1bf/LG4g9uVkqm/KBsvUunv0guI4KCiQ7WmVbffwX8YX7mYyCdE
bpyxmKyryfYiXk4L5iI7FoGPsHLYqpWIo+qW0mYz2hW9oliwDzLO6TAR4F1tsXKr
tfAIXKohH9W2ntvRRavrLSP+VwwNPPiIg5no15Vuyc4ugIwMl0/hAubkCOMyKTQk
I6d7gVr3hw9BR5OOmRaqwpvqgbgqfGwVIxGB8e1+e18FzGKNqcVDa/e9k2HtbquY
xyPLXQe6W9OTvhtdxV3UQHZv5Bd9JT0D3jPEvAIvjrUzRv2DqrRkY2PHwuq5K3TR
AujF1miEcCrV8by46A5Wqv0hneRSfeVicR0n7fxqdxbSFgQvSEu9FvjUvuXZHf7P
KyU1n3aoyka+/ZuVlyp7RStKXTShmDN9rY3j5Yw/S3AkC09PBoHcf45t8pixHdFc
pqGW+qMeyLfJw9hllumMwGm85ZUDZMJfZzJOMcliUy5vMAKeboGJIILP0996J9G0
r/tsh6Fa55b3Pau19WpWOURiiQqw5T5h1Y8Dmkjg7XQyC744EkgH0onjDqEtxYgX
IU5ALHNfXj76x+Y0VXl2qCzEblZx+9Q6+nmeE+PIRcU5PX/+TeCaIoLhM3TyV1D1
3eIGWxtSXFq7MV40RNcLViZO7JtDAWnHzRmilEM4X8pvzdVIZwrHcOqLgC2S0lMh
vEQQz/SIepfYvJyg3b7VrWoXJrjSU37fEfhL2ySEzWcA2coTa9FSDgtR4cZpSGo=
=bdPo
-END PGP SIGNATURE-

Bug#847293: php-ast: does not install ast.so

[Kunal Mehta]

Package: php-ast
Version: 0.1.2-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Installing php-ast does not actually provide the ast.so file, so the extension
isn't usable.

$ apt-file list php-ast
php-ast: /etc/php/7.0/mods-available/ast.ini
php-ast: /usr/share/doc/php-ast/README.md.gz
php-ast: /usr/share/doc/php-ast/changelog.Debian.gz
php-ast: /usr/share/doc/php-ast/copyright

It should be installing a .so file to /usr/lib/php/20151012/ast.so
presumably.

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

Kernel: Linux 4.8.11-300.fc25.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages php-ast depends on:
ii  libapache2-mod-php7.0 [phpapi-20151012]  7.0.13-2
ii  php-common   1:46
ii  php7.0-cli [phpapi-20151012] 7.0.13-2

php-ast recommends no packages.

php-ast suggests no packages.

-- no debconf information

Bug#734218: spice: Please support powerpcspe (and maybe other architectures)

[Wookey]

OK. I did a test build for arm64 and it builds fine. Debian should
default to building all arches unless there is a good reason why it
won't work. So far as I am aware there is no particular reason to
restrict this package to x86, even if that's all upstream cares about.

The attached patch enables it for all architectures. We can review
failures if they are any once it is uploaded, and perhaps restrict it
to a specific set of arches if need be.

I am happy to NMU this minor fix if the maintainer is busy. 

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
diff -Nru spice-0.12.8/debian/changelog spice-0.12.8/debian/changelog
--- spice-0.12.8/debian/changelog	2016-07-26 03:07:46.0 +
+++ spice-0.12.8/debian/changelog	2016-12-07 00:31:25.0 +
@@ -1,3 +1,10 @@
+spice (0.12.8-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Enable more architectures than just x86
+
+ -- Wookey   Wed, 07 Dec 2016 00:31:25 +
+
 spice (0.12.8-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru spice-0.12.8/debian/control spice-0.12.8/debian/control
--- spice-0.12.8/debian/control	2016-07-26 03:00:47.0 +
+++ spice-0.12.8/debian/control	2016-12-07 00:20:58.0 +
@@ -23,7 +23,7 @@
 
 Package: libspice-server1
 Section: libs
-Architecture: i386 amd64
+Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -42,7 +42,7 @@
 
 Package: libspice-server1-dbg
 Section: debug
-Architecture: i386 amd64
+Architecture: any
 Priority: extra
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
@@ -59,7 +59,7 @@
 
 Package: libspice-server-dev
 Section: libdevel
-Architecture: i386 amd64
+Architecture: any
 Depends: libspice-server1 (= ${binary:Version}), ${misc:Depends}, libspice-protocol-dev (>= 0.12.10~)
 Suggests: pkg-config
 Description: Header files and development documentation for spice-server


signature.asc
Description: Digital signature

Bug#847292: proot misses the "binary loader size" fix

[Xavier Guerrin]

Package: proot
Version: 5.1.0-1.1
Severity: normal
Tags: upstream

Hello,

It seems proot 5.1.0-1.1, as found in Debian Sid as I am reporting this, is
unusable.
How to reproduce?
  $ # Work around https://github.com/proot-me/PRoot/issues/106
  $ export PROOT_NO_SECCOMP=1
  $ proot ls
  proot error: can't write the loader: Bad address
  proot error: execve("/bin/ls"): No such file or directory
  proot info: possible causes:
* the program is a script but its interpreter (eg. /bin/sh) was not found;
* the program is an ELF but its interpreter (eg. ld-linux.so) was not
found;
* the program is a foreign binary but qemu was not specified;
* qemu does not work correctly (if specified);
* the loader was not found or doesn't work.
  fatal error: see `proot --help`.
Expected outcome: this command should have listed the current directory.

A short investigation reveals that proot fails to determine the size of the
binary loader (it gets a garbage value), leading to that "can't write the
loader" error when the said garbage value is fed to write().

Fortunately, a fix is available upstream: https://github.com/proot-
me/PRoot/pull/108
And I can confirm that building the "hotfixLoader" branch makes proot usable
again.

Cheers,
Xavier.



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

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

Versions of packages proot depends on:
ii  libc6   2.24-7
ii  libtalloc2  2.1.8-1

proot recommends no packages.

proot suggests no packages.

-- no debconf information

Bug#844789: [Debian-science-sagemath] GAP: issue related to compressed manual.six: PATCHES

[Ximin Luo]

Ximin Luo:
> Ximin Luo:
>> Bill Allombert:
>>> On Tue, Dec 06, 2016 at 01:01:00PM +, Ximin Luo wrote:
 Bill Allombert:
 Hi all,

 Sorry I only just briefly scanned through the thread now. However I
 found this post relating to gzip, pipes and python:

 https://blog.nelhage.com/2010/02/a-very-subtle-bug/

 which summarises the bug report here: https://bugs.python.org/issue1652
>>>
>>> Yes, this is exactly the problem, and it seems it has been fixed in python 
>>> 3,
>>> but not in python 2.7.
>>>
>>
>> Ok, good to know! The blog post also contains a work-around near the end, 
>> which is to add
>>
>>   preexec_fn=lambda: signal.signal(signal.SIGPIPE, signal.SIG_DFL)
>>
>> as a parameter to the relevant Popen call. Presumably in this case it's 
>> wherever Sage calls GAP. Jerome, could you test?
>>
> 
> Hi Bill,
> 
> I'm not sure if the above bug is the cause of this issue. I tried to 
> reproduce it without Sage:
> 
> $ apt-cache policy gap
> gap:
>   Installed: 4r8p6-1
>   Candidate: 4r8p6-1+sage17
>   Version table:
>  4r8p6-1+sage17 500
> 500 https://debian-science.alioth.debian.org/apt sid-sage/ Packages
>  *** 4r8p6-1 500
> 500 http://httpredir.debian.org/debian testing/main amd64 Packages
> 500 http://httpredir.debian.org/debian unstable/main amd64 Packages
> 100 /var/lib/dpkg/status
> 
> $ python -c 'import subprocess; subprocess.Popen(["gap", "-q"], 
> stdin=subprocess.PIPE).communicate("?SymmetricGroup")'
> 
> gzip: stdout: Broken pipe
> Help: several entries match this topic - type ?2 to get match [2]
> 
> [1] Reference: SymmetricGroup
> [2] Reference: SymmetricGroup (for a degree)
> [3] Reference: SymmetricGroup (for a domain)
> 
> $ python -c 'import signal, subprocess; subprocess.Popen(["gap", "-q"], 
> stdin=subprocess.PIPE,   preexec_fn=lambda: signal.signal(signal.SIGPIPE, 
> signal.SIG_DFL)).communicate("?SymmetricGroup")'
> Help: several entries match this topic - type ?2 to get match [2]
> 
> [1] Reference: SymmetricGroup
> [2] Reference: SymmetricGroup (for a degree)
> [3] Reference: SymmetricGroup (for a domain)
> 
> So as you can see, the bug is only to do with the extra "Broken pipe" error 
> messages. 

And in fact, if I patch src/sysfiles.c to say "gzip 2>/dev/null -cd " instead 
of "gunzip " then the "Broken pipe" messages go away.

The below Sage/GAP error still occurs, though:

> However Sage fails in a different way:
> 
> $ ./sage -c 'gap.help('SymmetricGroup', pager=False)' 
>> /usr/lib/python2.7/dist-packages/ptyprocess/ptyprocess.py(220)spawn()
> -> if use_native_pty_fork:
> (Pdb) c
>> /usr/lib/python2.7/dist-packages/ptyprocess/ptyprocess.py(220)spawn()
> -> if use_native_pty_fork:
> (Pdb) c
> #W  corrupted 'manual.six': ##W (in stream: 
> InputTextFile(/usr/share/gap/doc/t\
> ut/manual.six))
> #W  corrupted 'manual.six': ##W (in stream: 
> InputTextFile(/usr/share/gap/doc/c\
> hanges/manual.six))
> #W  corrupted 'manual.six': ##W (in stream: 
> InputTextFile(/usr/share/gap/pkg/G\
> APDoc/example/manual.six))
> Help: no matching entry found
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#847277: [Pkg-linaro-lava-devel] Bug#847277: lava-server: fails to upgrade from jessie to jessie-backports to stretch

[Neil Williams]

tag 847277 + unreproducible
severity 847277 normal
thanks

On Tue, 06 Dec 2016 22:15:30 +0100
Andreas Beckmann  wrote:

> Package: lava-server
> Version: 2016.11-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade
> from 'jessie' to 'jessie-backports' to 'stretch'.
> It installed fine in 'jessie' and upgraded to 'jessie-backports'
> successfully, then the upgrade to 'stretch' fails.

In a jessie VM which was upgraded to jessie-backports and then to stretch, 
lava-server upgraded perfectly. We also run daily upgrade and install tests 
inside LAVA itself on our staging instance.

Downgrading until the problem can be reproduced outside piuparts.

> >From the attached log (scroll to the bottom...):  

.. unable to download log from the bug report and no attachment was received.
 
>   Setting up lava-server (2016.11-1) ...
>   Installing new version of config
> file /etc/apache2/sites-available/lava-server.conf ... Installing new
> version of config file /etc/init.d/lava-server ... Installing new
> version of config file /etc/lava-server/settings.conf ... Installing
> new version of config file /etc/lava-server/uwsgi.ini ... lavaserver
>lavaserver
>devel
>devel
>   System check identified some issues:
>   
>   WARNINGS:
>   va_scheduler_app.Notification.job_status_trigger: (fields.W901)
> CommaSeparatedIntegerField has been deprecated. Support for it
> (except in historical migrations) will be removed in Django 2.0.
> HINT: Use
> CharField(validators=[validate_comma_separated_integer_list]) instead.
> 
> cceback (most recent call last):
> File "/usr/bin/lava-server", line 77, in 
>   main()
> File "/usr/bin/lava-server", line 74, in main
>   execute_from_command_line(django_options)
> File
> "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
> line 367, in execute_from_command_line utility.execute() File
> "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
> line 359, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv) File
> "/usr/lib/python2.7/dist-packages/django/core/management/base.py",
> line 294, in run_from_argv self.execute(*args, **cmd_options) File
> "/usr/lib/python2.7/dist-packages/django/core/management/base.py",
> line 345, in execute output = self.handle(*args, **options) File
> "/usr/lib/python2.7/dist-packages/django/core/management/commands/migrate.py",
> line 86, in handle
> executor.loader.check_consistent_history(connection) File
> "/usr/lib/python2.7/dist-packages/django/db/migrations/loader.py",
> line 292, in check_consistent_history connection.alias,
> django.db.migrations.exceptions.InconsistentMigrationHistory:
> Migration lava_scheduler_app.0001_initial is applied before its
> dependency linaro_django_xmlrpc.0001_initial on database 'default'.
> heerr, r processing package lava-server (--configure): subprocess
> installed post-installation script returned error exit status 1

This looks like a partial (and broken) purge was forced before the upgrade.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgppfvIM2AdYi.pgp
Description: OpenPGP digital signature

Bug#847291: pass: should not send terminal escapes when stdout is not a terminal

[Paul Wise]

Package: pass
Version: 1.6.5-3
Severity: normal

When I do `pass | less` I get ugly terminal escapes. pass should detect
when stdout is not a terminal and disable the terminal colour escapes.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages pass depends on:
ii  gnupg   2.1.16-2
ii  gnupg2  2.1.16-2
ii  pwgen   2.07-1.1
ii  tree1.7.0-4

Versions of packages pass recommends:
ii  git 1:2.10.2-3
ii  gnupg2  2.1.16-2
ii  xclip   0.12+svn84-4

Versions of packages pass suggests:
ii  libxml-simple-perl  2.22-1
ii  perl5.24.1~rc4-1
ii  ruby1:2.3.0+4

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#847289: xsane-common: xsane can no longer find USB scanner HP OfficeJet 6310

[Laurent]

Package: xsane-common
Version: 0.998-6
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Upgrade of debian/xsane led to the situation.
Scanner used to work before upgrade.

Call to xsane ends with the following error message:
Failed to open device `hpaio:/usb/Officejet_6300_series': Invalid argument

Please note that system-printer-config shows that the same printer is installed
and enabled.

Laurent


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

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

xsane-common depends on no packages.

Versions of packages xsane-common recommends:
ii  xsane  0.998-6+b1

xsane-common suggests no packages.

Bug#847290: Recommends wrong Xen meta-packages

[Ben Hutchings]

Source: ganeti
Version: 2.15.2-6
Severity: important

ganetic currently recommends:

qemu-kvm | xen-linux-system-amd64 | xen-linux-system-686-pae

xen-linux-system-amd64 was accidentally removed a while ago and has
just been restored to the archive, but it will be a transitional
package in stretch.  ganeti should recommend xen-system-amd64 instead.

xen-linux-system-686-pae exists in wheezy only.

Ben.

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

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

Bug#810392: 0xffff: please switch to libusb 1.0

[Pali Rohár]

On Wednesday 01 June 2016 23:25:56 Pali Rohár wrote:
> On Thursday 28 April 2016 10:13:51 Pali Rohár wrote:
> > On Tuesday 15 March 2016 22:12:18 Aurelien Jarno wrote:
> > > On 2016-03-15 21:26, Pali Rohár wrote:
> > > > Aurelien, I would suggest to have libusb-dev (libusb 0.1)
> > > > package in Debian repository, because it is stable and is
> > > > working, not like new libusb-1.0-0-dev which is slow and
> > > > unusable.
> > > 
> > > I disagree with this statement, libusb 1.0 is used in many
> > > applications without any problem. Contrary to libusb 0.1, it is a
> > > maintained library, so if you encountered any bug that makes it
> > > slow, unusable or whatever, please report a bug and a testcase, I
> > > am sure we'll find a solution.
> > 
> > Looks like upstream ignores this problem and so there is no other
> > way as using working libusb 0.1 library instead that new libusb
> > 1.0 which does not work...
> 
> Ok, upstream is definitely ignoring this problem... I got no response
> about it for 3 months!
> 
> I really suggest to stay on libusb 0.1 library which is *working* and
> not forcing us to use non working slow and buggy version 1.0.

Bug for libusb 1.0 was reported at least two times. And after 8 months 
upstream libusb is totally ignoring it. It is without any (relevant) 
answer.

So I'm reverting non-working libusb 1.0 support in my 0x project.

0x will use only libusb 0.1 library which is working -- and not 
libusb 1.0 anymore.

Sorry, but I do not see any other option. As libusb 1.0 maintainers do 
not want to cooperate, I really suggest to do not remove *working* 
libusb 0.1 library as there is no replacement for it.

-- 
Pali Rohár
pali.ro...@gmail.com


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

Bug#847277: [Pkg-linaro-lava-devel] Bug#847277: lava-server: fails to upgrade from jessie to jessie-backports to stretch

[Neil Williams]

On Tue, 06 Dec 2016 22:15:30 +0100
Andreas Beckmann  wrote:

> Package: lava-server
> Version: 2016.11-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade
> from 'jessie' to 'jessie-backports' to 'stretch'.
> It installed fine in 'jessie' and upgraded to 'jessie-backports'
> successfully, then the upgrade to 'stretch' fails.

The logfile attached to the bug report fails to download. Please provide a link 
to the piuparts test log.

There is no mention of this test on 
https://piuparts.debian.org/sid/source/l/lava-server.html and no link on 
https://tracker.debian.org/pkg/lava-server


-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpXCkhsx2JOa.pgp
Description: OpenPGP digital signature

Bug#840424: RFS: verilog-mode

[Sean Whitton]

Dear Kiwamu,

On Tue, Dec 06, 2016 at 01:53:25PM +0900, Kiwamu Okabe wrote:
> Should I find a Debian Developer in
> pkg-emacsen-add...@lists.alioth.debian.org to dput the verilog-mode
> package?

Sorry, but I have a few more items...

1. I think you should tweak the copyright for Makefile.  You wrote

Copyright: 2008-2013, Michael McNamara
 2008-2013, Wilson Snyder

but I think the following is more accurate:

Copyright: 2008-2013 Michael McNamara and Wilson Snyder

IANAL but I think there might be a legal distinction between these two,
so it's best to follow what upstream wrote in the file header.

2. You should patch the "New versions" and "Installation" sections out
of the texinfo file, as these could be confusing to Debian users who
already have the package installed and will obtain new versions from
us.  Don't forget a DEP-3 patch header.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#847154: linux-image-amd64: Disabling vsyscall interface may break docker run

[Olaf Meeuwissen]

Ian Campbell writes:

> On Tue, 2016-12-06 at 14:17 +, Ben Hutchings wrote:
>> 
>> But perhas we should more explicit in this message, e.g.:
>> 
>> "This breaks (e)glibc 2.13 and earlier, which may still be installed in
>> a chroot or container environment based on Debian 7, RHEL/CentOS 6 or
>> earlier versions."
>
> That's a good idea!

And is what I actually wanted to achieve because the message as is did
not make this "obvious" for me.  Sorry for not being clear.

@Ian Thanks for the pointers, will have a look.
-- 
Olaf Meeuwissen, LPIC-2   FLOSS Engineer -- EPSON AVASYS CORPORATION
   Free Software Foundation Associate Member since 2004-01-27
Support Free Software  https://my.fsf.org/donate
Join the Free Software Foundationhttps://my.fsf.org/join

Bug#847287: [Pkg-roundcube-maintainers] Bug#847287: roundcube: Roundcube 1.2.2: Remote command execution via malicious email composing

[Guilhem Moulin]

Hi,

On Tue, 06 Dec 2016 at 23:05:59 +, Juan Rossi wrote:
> Version: 1.1.4+dfsg.1-1~bpo8+1
> […]
> So probably it is important to update to upstream version 1.2.3

Unfortunately 1.2.x has many dependencies that aren't in
jessie-backports yet.  I personally don't have the time nor energy to
maintain said dependencies, so we asked backports folks for an exception
to stick to 1.1.x for the bpo version, exception which was rejected.
I'm afraid the remaining alternative is to take remove the package from
jessie-backports :-(

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#784918: xviewg: XView crashes if _SC_OPEN_MAX > FD_SETSIZE

[Benjamin Moody]

Package: xviewg
Version: 3.2p1.4-28.1
Followup-For: Bug #784918

I assume this bug is the same as the one I've just encountered.
Specifically, XView assumes that the maximum file descriptor is
smaller than the number of bits in the 'fd_set' structure.

The former limit can be modified using the 'ulimit' shell command.  On
wheezy, this limit was 1024 by default; on jessie, it's 65536.  (Is
this a systemd thing, or was the default changed for sysvinit too?)

The latter limit is fixed by the C library; it's defined by the
constant FD_SETSIZE, which equals 1024 in glibc.

So:

1. The easy workaround is to run 'ulimit -S -n 1024' in your
   .bash_profile or whatever.

2. To actually fix xview, the GETDTABLESIZE macro should be modified
   to clamp the value to FD_SETSIZE.  I *hope* that is all that's
   needed, have not yet tested it.

3. If there's a possibility that a program actually needs more than
   1024 FDs, then you have a problem.  (Of course, this is not just
   true of xview, but of any program that uses the 'select' function.)

4. It might be appropriate for programs, or XView itself, to work
   around this issue by calling setrlimit() early in program
   execution.

Will provide a patch once I've tested it.

Bug#844789: [Debian-science-sagemath] GAP: issue related to compressed manual.six: PATCHES

[Ximin Luo]

Ximin Luo:
> Bill Allombert:
>> On Tue, Dec 06, 2016 at 01:01:00PM +, Ximin Luo wrote:
>>> Bill Allombert:
>>> Hi all,
>>>
>>> Sorry I only just briefly scanned through the thread now. However I
>>> found this post relating to gzip, pipes and python:
>>>
>>> https://blog.nelhage.com/2010/02/a-very-subtle-bug/
>>>
>>> which summarises the bug report here: https://bugs.python.org/issue1652
>>
>> Yes, this is exactly the problem, and it seems it has been fixed in python 3,
>> but not in python 2.7.
>>
> 
> Ok, good to know! The blog post also contains a work-around near the end, 
> which is to add
> 
>   preexec_fn=lambda: signal.signal(signal.SIGPIPE, signal.SIG_DFL)
> 
> as a parameter to the relevant Popen call. Presumably in this case it's 
> wherever Sage calls GAP. Jerome, could you test?
> 

Hi Bill,

I'm not sure if the above bug is the cause of this issue. I tried to reproduce 
it without Sage:

$ apt-cache policy gap
gap:
  Installed: 4r8p6-1
  Candidate: 4r8p6-1+sage17
  Version table:
 4r8p6-1+sage17 500
500 https://debian-science.alioth.debian.org/apt sid-sage/ Packages
 *** 4r8p6-1 500
500 http://httpredir.debian.org/debian testing/main amd64 Packages
500 http://httpredir.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

$ python -c 'import subprocess; subprocess.Popen(["gap", "-q"], 
stdin=subprocess.PIPE).communicate("?SymmetricGroup")'

gzip: stdout: Broken pipe
Help: several entries match this topic - type ?2 to get match [2]

[1] Reference: SymmetricGroup
[2] Reference: SymmetricGroup (for a degree)
[3] Reference: SymmetricGroup (for a domain)

$ python -c 'import signal, subprocess; subprocess.Popen(["gap", "-q"], 
stdin=subprocess.PIPE,   preexec_fn=lambda: signal.signal(signal.SIGPIPE, 
signal.SIG_DFL)).communicate("?SymmetricGroup")'
Help: several entries match this topic - type ?2 to get match [2]

[1] Reference: SymmetricGroup
[2] Reference: SymmetricGroup (for a degree)
[3] Reference: SymmetricGroup (for a domain)

So as you can see, the bug is only to do with the extra "Broken pipe" error 
messages. However Sage fails in a different way:

$ ./sage -c 'gap.help('SymmetricGroup', pager=False)' 
> /usr/lib/python2.7/dist-packages/ptyprocess/ptyprocess.py(220)spawn()
-> if use_native_pty_fork:
(Pdb) c
> /usr/lib/python2.7/dist-packages/ptyprocess/ptyprocess.py(220)spawn()
-> if use_native_pty_fork:
(Pdb) c
#W  corrupted 'manual.six': ##W (in stream: InputTextFile(/usr/share/gap/doc/t\
ut/manual.six))
#W  corrupted 'manual.six': ##W (in stream: InputTextFile(/usr/share/gap/doc/c\
hanges/manual.six))
#W  corrupted 'manual.six': ##W (in stream: InputTextFile(/usr/share/gap/pkg/G\
APDoc/example/manual.six))
Help: no matching entry found

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#847287: roundcube: Roundcube 1.2.2: Remote command execution via malicious email composing

[Juan Rossi]

Package: roundcube
Version: 1.1.4+dfsg.1-1~bpo8+1
Severity: grave
Tags: upstream security
Justification: user security hole

Dear Maintainer,

I am reporting this as it is quite important as testing and unstable versions 
of roundcube are affected (and even all the backports offered, which hopefully 
will be updated via a bug report to the backport mailing list once the packages 
are upgraded or bug patch backported):

"malicious user can execute arbitrary commands on the underlying operating 
system remotely, simply by writing an email in Roundcube 1.2.2 (>= 1.0)"

"Requirements
The vulnerability has the following requirements for exploitation:

Roundcube must be configured to use PHP’s mail() function (by default, if no 
SMTP was specified 2 )
PHP’s mail() function is configured to use sendmail (by default, see 
sendmail_path 3 )
PHP is configured to have safe_mode turned off (by default, see safe_mode 4 )
An attacker must know or guess the absolute path of the webroot
These requirements are not particular demanding which in turn means that there 
were a lot of vulnerable systems in the wild.
"

The usage of php mail function it is the default in the package.

More details about this at:

https://blog.ripstech.com/2016/roundcube-command-execution-via-email/#fn:1

So probably it is important to update to upstream version 1.2.3

Regards

Juan.-


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

Kernel: Linux 4.4.32-rh33-20161115070633.xenU.i386 (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 roundcube depends on:
ii  roundcube-core  1.1.4+dfsg.1-1~bpo8+1

roundcube recommends no packages.

roundcube suggests no packages.

Versions of packages roundcube-core depends on:
ii  dbconfig-common1.8.47+nmu3+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  libapache2-mod-php55.6.19+dfsg-0+deb8u1
ii  libmagic1  1:5.22+15-2+deb8u1
ii  php-auth   1.6.4-1
ii  php-mail-mime  1.8.9-1+deb8u1
ii  php-mail-mimedecode1.5.5-2+deb8u1
ii  php-net-smtp   1.6.2-2
ii  php-net-socket 1.0.14-1
ii  php5   5.6.19+dfsg-0+deb8u1
ii  php5-cli   5.6.19+dfsg-0+deb8u1
ii  php5-common5.6.19+dfsg-0+deb8u1
ii  php5-intl  5.6.19+dfsg-0+deb8u1
ii  php5-json  1.3.6-1
ii  php5-mcrypt5.6.19+dfsg-0+deb8u1
ii  roundcube-mysql1.1.4+dfsg.1-1~bpo8+1
ii  ucf3.0030

Versions of packages roundcube-core recommends:
ii  apache2 [httpd-cgi]  2.4.10-10+deb8u4
ii  apache2-mpm-prefork [httpd-cgi]  2.4.10-10+deb8u4
ii  php-net-ldap31.0.3-1~bpo8+1
ii  php-net-sieve1.3.2-4
ii  php5-gd  5.6.19+dfsg-0+deb8u1
ii  php5-pspell  5.6.19+dfsg-0+deb8u1

Versions of packages roundcube-core suggests:
ii  php-auth-sasl  1.0.6-1+deb8u1
pn  php-crypt-gpg  
ii  roundcube-plugins  1.1.4+dfsg.1-1~bpo8+1

-- debconf information excluded

Bug#830829: Package installation should fail without agreement of the administrator

[Tobias Schlemmer]

Hi,

I think the mentioned changes should be documented using debconfig and
unless the administrator answers „yes, do as I want“ the upgrade should
be aborted. Otherwise many systems will silently upgraded to an
unbootable state as for example in Bug#847119 .

BTW. It looks to me that the corresponding functions should be
implemented in one place for all packages together (cryptsetup, systemd
etc.) so that they cen honour the following cases:

nested /usr (with subdirectories)
bind /usr
symlinked /usr

Tobias



signature.asc
Description: OpenPGP digital signature

Bug#847286: diaspora-installer: installs world-writable files under /usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems

[Andreas Beckmann]

Package: diaspora-installer
Version: 0.6.0.0+debian4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package installs
world-writable files.

>From the attached log (scroll to the bottom...):

  ERROR: BAD PERMISSIONS
  -rw-rw-rw- 1 diaspora nogroup  1935 Dec  5 17:24 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/configurate-0.3.1/lib/configurate/lookup_chain.rb
  -rw-rw-rw- 1 diaspora nogroup73 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-diaspora-mention-1.0.0/Gemfile
  -rw-rw-rw- 1 diaspora nogroup   481 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-diaspora-mention-1.0.0/README.md
  -rw-rw-rw- 1 diaspora nogroup28 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-diaspora-mention-1.0.0/Rakefile
  -rw-rw-rw- 1 diaspora nogroup73 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-diaspora-mention-1.0.0/app/assets/javascripts/markdown-it-diaspora-mention.js
  -rw-rw-rw- 1 diaspora nogroup 22469 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-diaspora-mention-1.0.0/app/assets/javascripts/markdown-it-diaspora-mention/markdown-it-diaspora-mention.js
  -rw-rw-rw- 1 diaspora nogroup   801 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-diaspora-mention-1.0.0/lib/rails-assets-markdown-it-diaspora-mention.rb
  -rw-rw-rw- 1 diaspora nogroup68 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-diaspora-mention-1.0.0/lib/rails-assets-markdown-it-diaspora-mention/version.rb
  -rw-rw-rw- 1 diaspora nogroup   848 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-diaspora-mention-1.0.0/rails-assets-markdown-it-diaspora-mention.gemspec
  -rw-rw-rw- 1 diaspora nogroup   754 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-diaspora-mention-1.0.0/rails-assets-markdown-it-diaspora-mention.json
  -rw-rw-rw- 1 diaspora nogroup73 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-sanitizer-0.4.2/Gemfile
  -rw-rw-rw- 1 diaspora nogroup   460 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-sanitizer-0.4.2/README.md
  -rw-rw-rw- 1 diaspora nogroup28 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-sanitizer-0.4.2/Rakefile
  -rw-rw-rw- 1 diaspora nogroup59 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-sanitizer-0.4.2/app/assets/javascripts/markdown-it-sanitizer.js
  -rw-rw-rw- 1 diaspora nogroup  8864 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-sanitizer-0.4.2/app/assets/javascripts/markdown-it-sanitizer/markdown-it-sanitizer.js
  -rw-rw-rw- 1 diaspora nogroup   775 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-sanitizer-0.4.2/lib/rails-assets-markdown-it-sanitizer.rb
  -rw-rw-rw- 1 diaspora nogroup62 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-sanitizer-0.4.2/lib/rails-assets-markdown-it-sanitizer/version.rb
  -rw-rw-rw- 1 diaspora nogroup   775 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-sanitizer-0.4.2/rails-assets-markdown-it-sanitizer.gemspec
  -rw-rw-rw- 1 diaspora nogroup   708 Dec  5 17:25 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rails-assets-markdown-it-sanitizer-0.4.2/rails-assets-markdown-it-sanitizer.json


cheers,

Andreas


diaspora-installer_0.6.0.0+debian4.log.gz
Description: application/gzip

Bug#847285: xfsdump: FTBFS (could not find a current XFS handle library)

[Santiago Vila]

Package: src:xfsdump
Version: 3.1.6+nmu1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -B"
but it failed:


[...]
checking xfs/xfs.h presence... yes
checking for xfs/xfs.h... yes
checking xfs/handle.h usability... yes
checking xfs/handle.h presence... yes
checking for xfs/handle.h... yes
checking for open_by_fshandle in -lhandle... no

FATAL ERROR: could not find a current XFS handle library.
Install or upgrade the XFS library package.
Alternatively, run "make install-dev" from the xfsprogs source.
Makefile:78: recipe for target 'include/builddefs' failed
make[1]: *** [include/builddefs] Error 1
make[1]: Leaving directory '/<>/xfsdump-3.1.6+nmu1'
debian/rules:23: recipe for target '.census' failed
make: *** [.census] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


Should be easy to reproduce, as it also happens here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/xfsdump.html

Thanks.

Bug#847284: pkg-perl-autopkgtest: use.t needs to be run in a writable directory

[Niko Tyni]

Package: pkg-perl-autopkgtest
Version: 0.34
User: debian-p...@lists.debian.org
Usertags: autopkgtest
Control: affects -1 libdevel-nytprof-perl

The libdevel-nytprof-perl package recently started failing its autopkgtest
checks, as seen at

 https://ci.debian.net/packages/libd/libdevel-nytprof-perl/unstable/amd64/

 # NYTProf failed to open 'nytprof.out' for writing, error 13: Permission 
denied at /usr/lib/x86_64-linux-gnu/perl5/5.24/Devel/NYTProf.pm line 43.

This seems to be because of the fix for #837137 in pkg-perl-autopkgtest
0.34: use.t is no longer run in the package source directory, we chdir to
"/" instead. Apparently Devel::NYTProf wants to write a file to cwd when
used and now fails.

The requirement does seem sensible. I suppose we need to chdir to a
temporary directory ($ADTTMP, which is apparently called $AUTOPKGTEST_TMP
nowadays). Not sure why I didn't think of that when fixing #837137.
-- 
Niko Tyni   nt...@debian.org

Bug#847234: Please help with symlink_to_dir expression (Was: Bug#847234: r-cran-rcurl: directory vs. symlink conflict: /usr/lib/R/site-library/RCurl/examples)

[Christian Seiler]

On 12/06/2016 11:45 PM, James Cowgill wrote:
> Hi,
> 
> On 06/12/16 22:34, Christian Seiler wrote:
>> On 12/06/2016 11:22 PM, James Cowgill wrote:
>>> The version number should be the version number immediately before the
>>> one where the dpkg-maintscript stuff is added, not when the symlink was
>>> converted to a directory.
>>>
>>> In this case you probably want to use "1.95-4.8-2~" (if the bug is fixed
>>> in 1.95-4.8-2).
>>
>> I wouldn't use that version if you ever want to backport that specific
>> version of the package, it's better to specify the previous Debian
>> version directly, in this case 1.95-4.8-1.
> 
> There is actually a section in dpkg-maintscript-helper(1) about why this
> is a bad idea (it breaks local builds or anyone else who manually
> patched your package).
> 
> Note that 1.95-4.8-2~ sorts before 1.95-4.8-2~deb8+1 anyway so there is
> no issue with backports here.

Yeah, you're right. Sorry about the confusion on my part.

Regards,
Christian

Bug#847234: Please help with symlink_to_dir expression (Was: Bug#847234: r-cran-rcurl: directory vs. symlink conflict: /usr/lib/R/site-library/RCurl/examples)

[James Cowgill]

Hi,

On 06/12/16 22:34, Christian Seiler wrote:
> On 12/06/2016 11:22 PM, James Cowgill wrote:
>> The version number should be the version number immediately before the
>> one where the dpkg-maintscript stuff is added, not when the symlink was
>> converted to a directory.
>>
>> In this case you probably want to use "1.95-4.8-2~" (if the bug is fixed
>> in 1.95-4.8-2).
> 
> I wouldn't use that version if you ever want to backport that specific
> version of the package, it's better to specify the previous Debian
> version directly, in this case 1.95-4.8-1.

There is actually a section in dpkg-maintscript-helper(1) about why this
is a bad idea (it breaks local builds or anyone else who manually
patched your package).

Note that 1.95-4.8-2~ sorts before 1.95-4.8-2~deb8+1 anyway so there is
no issue with backports here.

James



signature.asc
Description: OpenPGP digital signature

Bug#847234: Please help with symlink_to_dir expression (Was: Bug#847234: r-cran-rcurl: directory vs. symlink conflict: /usr/lib/R/site-library/RCurl/examples)

[Christian Seiler]

On 12/06/2016 11:22 PM, James Cowgill wrote:
> Hi,
> 
> On 06/12/16 21:36, Andreas Tille wrote:
>> On Tue, Dec 06, 2016 at 07:06:39PM +0100, Andreas Beckmann wrote:
>>> Package: r-cran-rcurl
>>> Version: 1.95-4.8-1
>>> Severity: serious
>>> User: debian...@lists.debian.org
>>> Usertags: piuparts
>>>
>>> ...
>>> >From the attached log (usually somewhere in the middle...):
>>>
>>> 2m19.9s INFO: dirname part contains a symlink:
>>>   /usr/lib/R/site-library/RCurl/examples/CIS (r-cran-rcurl) != 
>>> /usr/share/doc/r-cran-rcurl/examples/CIS (?)
>>> /usr/lib/R/site-library/RCurl/examples -> 
>>> ../../../../share/doc/r-cran-rcurl/examples
>>>   /usr/lib/R/site-library/RCurl/examples/CIS/cis.R (r-cran-rcurl) != 
>>> /usr/share/doc/r-cran-rcurl/examples/CIS/cis.R (?)
>>> /usr/lib/R/site-library/RCurl/examples -> 
>>> ../../../../share/doc/r-cran-rcurl/examples
>>> ...
>>
>> I tried to fix this the following way.  In the Jessie package
>> r-cran-rcurl_1.95-4.3-1+deb8u1_amd64.deb the examples link is:
>>
>>
>> $ readlink /usr/lib/R/site-library/RCurl/examples 
>> ../../../../share/doc/r-cran-rcurl/examples
>>
>>
>> Since in the package in unstable examples is a directory I tried
>> to fix the upgrade path by
>>
>>
>> $ cat debian/maintscript
>> symlink_to_dir /usr/lib/R/site-library/RCurl/examples 
>> ../../../../share/doc/r-cran-rcurl/examples 1.95-4.3-1
> 
> The version number should be the version number immediately before the
> one where the dpkg-maintscript stuff is added, not when the symlink was
> converted to a directory.
> 
> In this case you probably want to use "1.95-4.8-2~" (if the bug is fixed
> in 1.95-4.8-2).

I wouldn't use that version if you ever want to backport that specific
version of the package, it's better to specify the previous Debian
version directly, in this case 1.95-4.8-1.

Regards,
Christian

Bug#828577: The patch is upstream

[Hon Ching(Vicky) Lo]

On Sun, 2016-11-20 at 18:04 +0100, Pierre Chifflier wrote:
> On Thu, Nov 17, 2016 at 07:47:56PM -0500, Hon Ching(Vicky) Lo wrote:
> > On Thu, 2016-11-17 at 16:29 -0500, Hon Ching(Vicky) Lo wrote:
> > > Hi
> > > 
> > > The patch is upstream:
> > > https://sourceforge.net/p/trousers/tpm-tools/ci/6fb8a3c5ad3bc6e62f6895a4fcf3540faa29b4f2/
> > > 
> > > 
> > > Thanks,
> > > Vicky
> > 
> > The patch above is based off the latest code in tpm-tools 1.3.9.  Please
> > rebase to tpm-tools 1.3.9 to pick up the patch instead.  Thanks!
> > 
> 
> Hi,
> 
> Version 1.3.9 does not fix the build with OpenSSL 1.1. It still fails
> with the following error:
> 
> gcc -DHAVE_CONFIG_H -I. -I../..  -I../../include -D_LINUX -Wdate-time 
> -D_FORTIFY_SOURCE=2  -g -O2 
> -fdebug-prefix-map=/home/pollux/DEBIAN/TPM-TOOLS/tpm-tools=. 
> -fstack-protector-strong -Wformat -Werror=format-security -m64 -Wall 
> -Wno-unused -Wno-implicit-function-declaration -Wreturn-type -Wsign-compare 
> -c -o data_import.o data_import.c
> data_import.c: In function ‘readX509Cert’:
> data_import.c:375:26: error: dereferencing pointer to incomplete type 
> ‘EVP_PKEY {aka struct evp_pkey_st}’
>   if ( EVP_PKEY_type( pKey->type ) != EVP_PKEY_RSA ) {
>   ^~
> In file included from /usr/include/openssl/asn1.h:24:0,
>  from /usr/include/openssl/rsa.h:16,
>  from data_import.c:34:
> data_import.c: In function ‘createRsaPubKeyObject’:
> data_import.c:694:34: error: dereferencing pointer to incomplete type ‘RSA 
> {aka struct rsa_st}’
>   int  nLen = BN_num_bytes( a_pRsa->n );
>   ^
> Makefile:524: recipe for target 'data_import.o' failed
> 
> OpenSSL decided not to allow access to these fields anymore. At this
> point, I have no idea on how to fix this.
> 
> Best regards,
> Pierre
> 
Hi Pierre,


OpenCryptoki builds the TPM token that can communicate with a TPM.
Thus, the PKCS#11 support in tpm-tools wasn't necessary.  The build
in version 1.3.9 does not include the pkcs#11 support by default.
If Debian enables that support by default, please disable it.


Thanks,
Vicky

Bug#847283: quilt-el: copyright file missing after upgrade (policy 12.5)

[Andreas Beckmann]

Package: quilt-el
Version: 0.63-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

a test with piuparts revealed that your package misses the copyright
file after an upgrade, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.

This was observed on the following upgrade paths:

  wheezy -> jessie (no package in jessie, keeping wheezy version
  installed) -> stretch

>From the attached log (scroll to the bottom...):

3m38.6s ERROR: WARN: Inadequate results from running adequate!
  quilt-el: missing-copyright-file /usr/share/doc/quilt-el/copyright

3m43.4s DUMP: 
  MISSING COPYRIGHT FILE: /usr/share/doc/quilt-el/copyright
  # ls -lad /usr/share/doc/quilt-el
  drwxr-xr-x 2 root root 40 Sep 15 10:31 /usr/share/doc/quilt-el
  # ls -la /usr/share/doc/quilt-el/
  total 0
  drwxr-xr-x   2 root root   40 Sep 15 10:31 .
  drwxr-xr-x 294 root root 6060 Sep 15 10:31 ..


Additional info may be available here:
https://wiki.debian.org/MissingCopyrightFile

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


cheers,

Andreas


quilt-el_0.63-5.log.gz
Description: application/gzip

Bug#747839: lcms2: build libiccjpeg packages

[Thomas Weber]

On Tue, Dec 06, 2016 at 11:23:51PM +0100, Thomas Weber wrote:
> > Just to add more information to the bug report: the Gentoo developer who
> > tried to get libiccjpeg into lcms also tried (and apparently failed) to
> > get it into libjpeg-turbo:
> > https://sourceforge.net/p/libjpeg-turbo/mailman/message/30387709/
> > 
> > Thomas
> 
> Hi Michael, 
> I am currently discussing a possible inclusion of iccjpeg into
> libjpeg-turbo.[1] He seems to be willing to include it, subject to some
> conditions. The biggest hurdle to me seems to be a renaming of the
> functions. You know your upstreams better than I do - how likely is it
> that they would drop their specific copy of iccjpeg, use libjepg-turbo
> and adapt their code for the new API?
> 
>   Thomas
And of course I forgot the URL, sorry about that:
[1] 
https://sourceforge.net/p/libjpeg-turbo/mailman/libjpeg-turbo-devel/thread/20161203235259.g7ppkifz2h6ljfqr%40t61/#msg35530221

Bug#825887: mnemosyne: does not start due to removal of WebKit from python-qt4

[Felix Gruber]

Mnemosyne 2.4 has been released today [1].
I've tried to package it and you can find my changes to the debian directory on 
GitHub [2].
Unfortunately, mnemosyne 2.4 fails to start as it depends on QtWebEngine which 
isn't packaged yet (see #841830).

[1] https://groups.google.com/forum/#!topic/mnemosyne-proj-users/YE5-bMfOp4Y
[2] https://github.com/felgru/mnemosyne

Bug#847282: imagemagick-doc: fails to upgrade wheezy -> jessie -> stretch

[Andreas Beckmann]

Package: imagemagick-doc
Version: 8:6.9.6.6+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'wheezy' to 'jessie' to 'stretch'.
It installed fine in 'wheezy', and upgraded to 'jessie' successfully,
but then the upgrade to 'stretch' failed.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../imagemagick-doc_8%3a6.9.6.6+dfsg-1_all.deb ...
  dpkg-maintscript-helper: error: directory '/usr/share/doc/imagemagick-doc' 
contains files not owned by package imagemagick-doc:all, cannot switch to 
symlink
  dpkg: error processing archive 
/var/cache/apt/archives/imagemagick-doc_8%3a6.9.6.6+dfsg-1_all.deb (--unpack):
   subprocess new pre-installation script returned error exit status 1


Let's see what we have there:

# ls -la /usr/share/doc/imagemagick-doc
total 176
drwxr-xr-x   4 root root   220 Dec  6 22:15 .
drwxr-xr-x 117 root root  2500 Dec  6 22:16 ..
-rw-r--r--   1 root root   991 Aug 16 12:13 NEWS.Debian.gz
-rw-r--r--   1 root root 31950 Aug 16 12:13 changelog.Debian.gz
-rw-r--r--   1 root root 77347 Oct 25  2014 changelog.gz
-rw-r--r--   1 root root 42835 Aug 16 12:13 copyright
drwxr-xr-x   3 root root  1040 Dec  6 22:15 images
lrwxrwxrwx   1 root root21 Apr  7  2016 images.dpkg-backup -> 
../imagemagick/images
-rw-r--r--   1 root root 18947 Aug 25 12:05 index.html
drwxr-xr-x   5 root root  1340 Dec  6 22:15 www
lrwxrwxrwx   1 root root18 Apr  7  2016 www.dpkg-backup -> 
../imagemagick/www

# dpkg -S /usr/share/doc/imagemagick-doc/*
imagemagick-doc: /usr/share/doc/imagemagick-doc/NEWS.Debian.gz
imagemagick-doc: /usr/share/doc/imagemagick-doc/changelog.Debian.gz
imagemagick-doc: /usr/share/doc/imagemagick-doc/changelog.gz
imagemagick-doc: /usr/share/doc/imagemagick-doc/copyright
imagemagick-doc: /usr/share/doc/imagemagick-doc/images
dpkg-query: no path found matching pattern 
/usr/share/doc/imagemagick-doc/images.dpkg-backup
imagemagick-doc: /usr/share/doc/imagemagick-doc/index.html
imagemagick-doc: /usr/share/doc/imagemagick-doc/www
dpkg-query: no path found matching pattern 
/usr/share/doc/imagemagick-doc/www.dpkg-backup


So it's probably the .dpkg-backup files left from the wheezy->jessie upgrade
that are now causing problems.


cheers,

Andreas


imagemagick-doc_8:6.9.6.6+dfsg-1.log.gz
Description: application/gzip

Bug#846731: Bug#775434: Bug#846731: Bug#775434: libbio-scf-perl: FTBFS on mips64el, ppc64el, s390x - tests

[gregor herrmann]

On Wed, 07 Dec 2016 00:11:25 +0200, Niko Tyni wrote:

> The attached patch fixes this for me on sid/amd64.
> 
> Eyeballs and/or testing would be welcome. Tagging just #846731 for now,
> but I expect the bugs are about the same issue and should probably
> be merged.

I can confirm that with this patch the build failures I've been
seeing goes away.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: B.B. King and Eric Clapton


signature.asc
Description: Digital Signature

Bug#847234: Please help with symlink_to_dir expression (Was: Bug#847234: r-cran-rcurl: directory vs. symlink conflict: /usr/lib/R/site-library/RCurl/examples)

[James Cowgill]

Hi,

On 06/12/16 21:36, Andreas Tille wrote:
> On Tue, Dec 06, 2016 at 07:06:39PM +0100, Andreas Beckmann wrote:
>> Package: r-cran-rcurl
>> Version: 1.95-4.8-1
>> Severity: serious
>> User: debian...@lists.debian.org
>> Usertags: piuparts
>>
>> ...
>> >From the attached log (usually somewhere in the middle...):
>>
>> 2m19.9s INFO: dirname part contains a symlink:
>>   /usr/lib/R/site-library/RCurl/examples/CIS (r-cran-rcurl) != 
>> /usr/share/doc/r-cran-rcurl/examples/CIS (?)
>> /usr/lib/R/site-library/RCurl/examples -> 
>> ../../../../share/doc/r-cran-rcurl/examples
>>   /usr/lib/R/site-library/RCurl/examples/CIS/cis.R (r-cran-rcurl) != 
>> /usr/share/doc/r-cran-rcurl/examples/CIS/cis.R (?)
>> /usr/lib/R/site-library/RCurl/examples -> 
>> ../../../../share/doc/r-cran-rcurl/examples
>> ...
> 
> I tried to fix this the following way.  In the Jessie package
> r-cran-rcurl_1.95-4.3-1+deb8u1_amd64.deb the examples link is:
> 
> 
> $ readlink /usr/lib/R/site-library/RCurl/examples 
> ../../../../share/doc/r-cran-rcurl/examples
> 
> 
> Since in the package in unstable examples is a directory I tried
> to fix the upgrade path by
> 
> 
> $ cat debian/maintscript
> symlink_to_dir /usr/lib/R/site-library/RCurl/examples 
> ../../../../share/doc/r-cran-rcurl/examples 1.95-4.3-1

The version number should be the version number immediately before the
one where the dpkg-maintscript stuff is added, not when the symlink was
converted to a directory.

In this case you probably want to use "1.95-4.8-2~" (if the bug is fixed
in 1.95-4.8-2).

See dpkg-maintscript-helper(1) prior-version section.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#747839: lcms2: build libiccjpeg packages

[Thomas Weber]

> Just to add more information to the bug report: the Gentoo developer who
> tried to get libiccjpeg into lcms also tried (and apparently failed) to
> get it into libjpeg-turbo:
> https://sourceforge.net/p/libjpeg-turbo/mailman/message/30387709/
> 
>   Thomas

Hi Michael, 
I am currently discussing a possible inclusion of iccjpeg into
libjpeg-turbo.[1] He seems to be willing to include it, subject to some
conditions. The biggest hurdle to me seems to be a renaming of the
functions. You know your upstreams better than I do - how likely is it
that they would drop their specific copy of iccjpeg, use libjepg-turbo
and adapt their code for the new API?

Thomas

Bug#775434: Bug#846731: Bug#775434: libbio-scf-perl: FTBFS on mips64el, ppc64el, s390x - tests

[Niko Tyni]

tag 846731 patch
thanks

On Sun, Dec 04, 2016 at 05:52:10PM +0200, Niko Tyni wrote:
> On Sat, Dec 03, 2016 at 04:40:53PM +0100, gregor herrmann wrote:
> > On Wed, 26 Oct 2016 13:26:42 +0100, Iain Lane wrote:
> > 
> > > On Thu, Jan 15, 2015 at 05:17:10PM +, James Cowgill wrote:
> > 
> > > > libbio-scp-perl FTBFS on mips64el, ppc64el, and s390x with similar
> > > > testsuite failures:
> > 
> > > > Although I haven't investigated this, the build produces many pointer
> > > > casting warnings which seem likely to have caused these errors:
> > > > 
> > > > SCF.xs: In function 'XS_Bio__SCF_get_scf_pointer':
> > > > SCF.xs:57:20: warning: cast from pointer to integer of different size 
> > > > [-Wpointer-to-int-cast]
> > > >   ret_val = newSViv((int)scf_data);

> GCC started to default to PIE between the latest perl upload and the
> one before that. I think that made it use different memory locations,
> so the cast to int now overflows.

The attached patch fixes this for me on sid/amd64.

Eyeballs and/or testing would be welcome. Tagging just #846731 for now,
but I expect the bugs are about the same issue and should probably
be merged.
-- 
Niko Tyni   nt...@debian.org
>From 5e57fc339478e5204d0465b63ff5a5e927a565ad Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Wed, 7 Dec 2016 00:02:25 +0200
Subject: [PATCH] Fix overflowing casts from pointer to integer

This fixes test failures on 64-bit platforms using memory addresses over
2**32, like those where Perl is built as PIE (position independent
executable).

Bug-Debian: https://bugs.debian.org/846731
---
 SCF.xs | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/SCF.xs b/SCF.xs
index a55879b..10a88bd 100644
--- a/SCF.xs
+++ b/SCF.xs
@@ -54,7 +54,7 @@ char *file_name
 	/* Reading SCF file, into internal structure */
 	if ( (scf_data = read_scf(file_name)) == NULL )
 		croak("get_scf_pointer(...) : failed on read_scf(%s)\n", file_name);
-	ret_val = newSViv((int)scf_data);
+	ret_val = newSViv(PTR2IV(scf_data));
 	RETVAL = ret_val;
 	OUTPUT:
 	RETVAL
@@ -77,20 +77,20 @@ FILE *file_handle
 	croak("get_scf_fpointer(...) : failed on mfreopen(...)\n");
 	if ( (scf_data = mfread_scf(mf)) == NULL )
 		croak("get_scf_fpointer(...) : failed on fread_scf(...)\n");
-	ret_val = newSViv((int)scf_data);
+	ret_val = newSViv(PTR2IV(scf_data));
 	RETVAL = ret_val;
 	OUTPUT:
 	RETVAL
 
 void
 scf_free(scf_pointer)
-int scf_pointer
+long scf_pointer
 CODE:
 	scf_deallocate((Scf *)scf_pointer);
 
 SV *
 get_comments(scf_pointer)
-int scf_pointer
+long scf_pointer
 	CODE:
 	Scf *scf_data = (Scf *)scf_pointer;
 	SV *ret_val;
@@ -102,7 +102,7 @@ int scf_pointer
 
 void
 set_comments(scf_pointer, comments)
-int scf_pointer
+long scf_pointer
 char *comments
 	CODE:
 	Scf *scf_data = (Scf *)scf_pointer;
@@ -115,7 +115,7 @@ char *comments
 
 SV * 
 scf_write(scf_pointer, file_name)
-int scf_pointer
+long scf_pointer
 char *file_name
 	CODE:
 	Scf *scf_data = (Scf *)scf_pointer;
@@ -129,7 +129,7 @@ char *file_name
 	
 SV * 
 scf_fwrite(scf_pointer, file_handle)
-int scf_pointer
+long scf_pointer
 FILE *file_handle
 	CODE:
 mFILE *mf;
@@ -152,7 +152,7 @@ FILE *file_handle
 
 SV *
 get_from_header(scf_pointer, what)
-int scf_pointer
+long scf_pointer
 int what
 	CODE:
 	/* what = { 0 samples, 1 bases, 2 version, 3 sample size, 4 code_set } */
@@ -176,7 +176,7 @@ int what
 
 SV *
 get_at(scf_pointer, index, what)
-int scf_pointer
+long scf_pointer
 int index
 int what
 	CODE:
@@ -234,7 +234,7 @@ int what
 
 void 
 set_base_at(scf_pointer, index, what, value)
-int scf_pointer
+long scf_pointer
 int index
 int what
 char value
@@ -247,7 +247,7 @@ char value
 
 void
 set_at(scf_pointer, index, what, value)
-int scf_pointer
+long scf_pointer
 int index
 int what
 unsigned int value
-- 
2.10.2

Bug#847281: openrc: Fix Hurd bug and compiler warnings

[Svante Signell]

Source: openrc
Version: 0.22-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

Thanks for the update of openrc to the latest upstream release and the solution
of reboot/halt problems on GNU/Linux. Hopefully the problems with the transit
file are gone now.

Upgrading to that package on GNU/Hurd (as well as 0.21-4) revealed that
/proc/mounts has to be used for mountinfo, not /proc/self/mounts, not present on
Hurd. 0060-mountinfo.c.patch addresses this problem.
0061-fix-compiler-warnings.patch fixes CPPFLAGS and removes unused variables.
0062-fix-compiler-warnings.patch fixes indentation issues making the compiler
issue a warning. Please review these changes to make sure I've made the right
corrections.
Finally 0063-fix-compiler-warnings.patch fixes warnings about unused variables
on glibc-based systems using the already defined macro _unused in helpers.h.

Thanks!Index: openrc-0.22/src/rc/mountinfo.c
===
--- openrc-0.22.orig/src/rc/mountinfo.c
+++ openrc-0.22/src/rc/mountinfo.c
@@ -323,9 +323,13 @@ find_mounts(struct args *args)
 	int netdev;
 	RC_STRINGLIST *list;
 
+#ifdef __GNU__ /* /proc/self/mounts does not exist on GNU/Hurd */
+	if ((fp = fopen("/proc/mounts", "r")) == NULL)
+		eerrorx("/proc/mounts: %s", strerror(errno));
+#else
 	if ((fp = fopen("/proc/self/mounts", "r")) == NULL)
-		eerrorx("getmntinfo: %s", strerror(errno));
-
+		eerrorx("/proc/self/mounts: %s", strerror(errno));
+#endif
 	list = rc_stringlist_new();
 
 	buffer = xmalloc(sizeof(char) * PATH_MAX * 3);
Index: openrc-0.22/mk/os-GNU.mk
===
--- openrc-0.22.orig/mk/os-GNU.mk
+++ openrc-0.22/mk/os-GNU.mk
@@ -11,5 +11,5 @@
 SFX=		.GNU.in
 PKG_PREFIX?=	/usr
 
-CPPFLAGS+=	-D_BSD_SOURCE -D_XOPEN_SOURCE=700 -DMAXPATHLEN=4096 -DPATH_MAX=4096
+CPPFLAGS+=	-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=700 -DMAXPATHLEN=4096 -DPATH_MAX=4096
 LIBDL=		-Wl,-Bdynamic -ldl
Index: openrc-0.22/mk/os-Linux.mk
===
--- openrc-0.22.orig/mk/os-Linux.mk
+++ openrc-0.22/mk/os-Linux.mk
@@ -11,7 +11,7 @@
 SFX=		.Linux.in
 PKG_PREFIX?=	/usr
 
-CPPFLAGS+=	-D_BSD_SOURCE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=700
+CPPFLAGS+=	-D_DEFAULT_SOURCE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=700
 LIBDL=		-Wl,-Bdynamic -ldl
 
 ifeq (${MKSELINUX},yes)
Index: openrc-0.22/src/lsb2rcconf/GNUmakefile
===
--- openrc-0.22.orig/src/lsb2rcconf/GNUmakefile
+++ openrc-0.22/src/lsb2rcconf/GNUmakefile
@@ -5,7 +5,7 @@ COMPRESS_MAN ?= yes
 STRIP_BINARY ?= yes
 #EXAMPLES ?= yes
 
-STDFLAG ?= -D_BSD_SOURCE
+STDFLAG ?= -D_DEFAULT_SOURCE
 CSECFLAGS ?= -fstack-protector-all -Wall --param ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fstack-check -DPARANOID
 CFLAGS ?= -march=native -pipe -O2 -std=c99
 CFLAGS += $(CSECFLAGS) $(STDFLAG)
Index: openrc-0.22/src/librc/librc.c
===
--- openrc-0.22.orig/src/librc/librc.c
+++ openrc-0.22/src/librc/librc.c
@@ -61,7 +61,6 @@ ls_dir(const char *dir, int options)
 	struct dirent *d;
 	RC_STRINGLIST *list = NULL;
 	struct stat buf;
-	size_t l;
 	char file[PATH_MAX];
 	int r;
 
@@ -559,7 +558,6 @@ rc_service_exists(const char *service)
 {
 	char *file;
 	bool retval = false;
-	size_t len;
 	struct stat buf;
 
 	if (!service) {
Index: openrc-0.22/src/librc/librc-depend.c
===
--- openrc-0.22.orig/src/librc/librc-depend.c
+++ openrc-0.22/src/librc/librc-depend.c
@@ -1495,7 +1495,7 @@ rc_deptree_update(RC_DT_FLAGS flags)
 	char *line = NULL;
 	size_t len = 0;
 	char *depend, *depends, *service, *type, *nosys, *onosys;
-	size_t i, k, l;
+	size_t i, k;
 	bool retval = true;
 	const char *sys = rc_sys();
 	struct utsname uts;
Index: openrc-0.22/src/rc/start-stop-daemon.c
===
--- openrc-0.22.orig/src/rc/start-stop-daemon.c
+++ openrc-0.22/src/rc/start-stop-daemon.c
@@ -468,7 +468,7 @@ run_stop_schedule(const char *exec, cons
 if (tkilled == 0) {
 	if (progressed)
 		printf("\n");
-		eerror("%s: no matching processes found", applet);
+	eerror("%s: no matching processes found", applet);
 }
 return tkilled;
 			}
@@ -696,17 +696,17 @@ int main(int argc, char **argv)
 		if (sscanf(tmp, "%d", ) != 1)
 			eerror("%s: invalid nice level `%s' (SSD_NICELEVEL)",
 			applet, tmp);
-		if ((tmp = getenv("SSD_IONICELEVEL"))) {
-			int n = sscanf(tmp, "%d:%d", , );
-			if (n != 1 && n != 2)
-eerror("%s: invalid ionice level `%s' (SSD_IONICELEVEL)",
-applet, tmp);
-			if (ionicec == 0)
-ioniced = 0;
-			else if (ionicec == 3)
-ioniced = 7;
-			ionicec <<= 13; /* class shift */
-		}
+	if ((tmp = getenv("SSD_IONICELEVEL"))) {
+		int n = sscanf(tmp, "%d:%d", , );
+		if (n != 1 && n != 2)

Bug#845982: cwltool accesses internet -- missing dependency

[Kevin Murray]

Hi Ghis,

On 11:39 06/12, Ghislain Vaillant wrote:
> On Sun, 4 Dec 2016 11:08:35 +1100 Kevin Murray  wrote:
> I can do it if time is limited for you. I am dealing with a different chain of
> package dependencies which would require keepalive being packaged too.

That would be great, the pre-Christmas rush is well and truly upon me at work,
so time is very limited at the moment.

Thanks heaps,

Kevin

---
Kevin Murray

Bug#847280: qpdfview: Debian version is 3 releases behind, missing important features

[Nemo Inis]

Package: qpdfview
Version: 0.4.14-1
Severity: important

Dear Maintainer,

qpdfview 0.4.17 has been released. Could we replace the 0.4.14 version we have
in Debian?

Thanks for great work!



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

Kernel: Linux 4.7.0-1-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, 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 qpdfview depends on:
ii  hicolor-icon-theme0.15-1
ii  libc6 2.24-5
ii  libcups2  2.2.1-2
ii  libgcc1   1:6.2.0-13
ii  libgl1-mesa-glx [libgl1]  12.0.4-2
ii  libpoppler-qt5-1  0.48.0-2
ii  libqt5concurrent5 5.7.1~20161021+dfsg-6
ii  libqt5core5a  5.7.1~20161021+dfsg-6
ii  libqt5dbus5   5.7.1~20161021+dfsg-6
ii  libqt5gui55.7.1~20161021+dfsg-6
ii  libqt5printsupport5   5.7.1~20161021+dfsg-6
ii  libqt5sql55.7.1~20161021+dfsg-6
ii  libqt5sql5-sqlite 5.7.1~20161021+dfsg-6
ii  libqt5svg55.7.1~20161021-2
ii  libqt5widgets55.7.1~20161021+dfsg-6
ii  libqt5xml55.7.1~20161021+dfsg-6
ii  libstdc++66.2.0-13
ii  zlib1g1:1.2.8.dfsg-2+b3

Versions of packages qpdfview recommends:
pn  qpdfview-djvu-plugin   
pn  qpdfview-ps-plugin 
pn  qpdfview-translations  

qpdfview suggests no packages.

-- no debconf information

Bug#843163: Bug#847221: Processed: Re: Bug#847221: debsums: false positive missing file in open-vm-tools-desktop package - encoding issue?

[Bernd Zeimetz]

severity 843163 serious
thanks

@debhelper maintainers:
As people seem to think that the wrongly produced md5sum file is a
serious issue, I'm rising the severity of that bug, too.


On 12/06/2016 10:41 PM, Andreas Beckmann wrote:
> On 2016-12-06 17:47, Niko Tyni wrote:
>> I see src:open-vm-tools fiddles with the entry in debian/rules,
>> removing the first backslash at the start of the line but not
>> touching the doubled one.  This seems to be wrong. While the result
>> does pass 'dpkg --verify', it only does so because the file name
>> doesn't match

So why does dpkg --verify not complain about missing files then?



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#847279: debian-edu-artwork: leaves diversion after upgrade from jessie

[Andreas Beckmann]

Package: debian-edu-artwork
Version: 0.901-3
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to remove some
diversions after upgrading from jessie and removing the package
afterwards.

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

0m53.6s ERROR: FAIL: Installed diversions (dpkg-divert) not removed by purge:
  diversion of /usr/share/kde4/apps/plasma-desktop/init/10-desktop-base.js to 
/usr/share/kde4/apps/plasma-desktop/init/10-desktop-base.js.edu-diverted by 
debian-edu-artwork


The test did the following:
  setup minimal jessie chroot
  install $package/jessie
  distupgrade stretch
  remove $package
  purge $package

cheers,

Andreas


debian-edu-artwork_0.901-3.log.gz
Description: application/gzip

Bug#814929: Pending fixes for bugs in the libdata-uuid-libuuid-perl package

[pkg-perl-maintainers]

tag 814929 + pending
thanks

Some bugs in the libdata-uuid-libuuid-perl package are closed in
revision d0bb299eeea16c6f2fead57bb5e3fa4f0dca163c in branch 'master'
by Niko Tyni

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libdata-uuid-libuuid-perl.git/commit/?id=d0bb299

Commit message:

Add a UUID length sanity check when decoding base64 strings

This fixes test failures on platforms where references stringify
to 12 hex digits.

Closes: #814929

Bug#847278: Pending fixes for bugs in the libdata-uuid-libuuid-perl package

[pkg-perl-maintainers]

tag 847278 + pending
thanks

Some bugs in the libdata-uuid-libuuid-perl package are closed in
revision 9f9db4579bd84106998c40a468e1b4cd83eae48c in branch 'master'
by Niko Tyni

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libdata-uuid-libuuid-perl.git/commit/?id=9f9db45

Commit message:

Fix a use of uninitialized memory in new_uuid()

Closes: #847278

Bug#847221: Processed: Re: Bug#847221: debsums: false positive missing file in open-vm-tools-desktop package - encoding issue?

[Andreas Beckmann]

Control: reopen -1

On 2016-12-06 20:22, Bernd Zeimetz wrote:
> Version: 2:10.1.0-4449150-1

Nope, the change in 2:10.1.0-4449150-1 is not sufficient:

On 2016-12-06 17:47, Niko Tyni wrote:
> I see src:open-vm-tools fiddles with the entry in debian/rules,
> removing the first backslash at the start of the line but not
> touching the doubled one.  This seems to be wrong. While the result
> does pass 'dpkg --verify', it only does so because the file name
> doesn't match


Andreas

Bug#842951: [pkg-cryptsetup-devel] Bug#842951: Falsely identifies origin of a key file

[Jonas Meurer]

Hi Martin,

Am 16.11.2016 um 15:40 schrieb martin f krafft:
> also sprach Jonas Meurer  [2016-11-14 19:01 +0100]:
>>> I think the reason for the confusion is that the "crypt" device is
>>> actually a PV for the fishbowl LVM VG, and the root filesystem is
>>> just an LV there, so it's not encrypted per se, but it's part of an
>>> encrypted volume group…
>>
>> Can you give a bit more context here? In particular the shell script
>> trace before and after the part that you parsed would be helpful. Could
>> you send me the full shell script trace with 'set -x' enabled (and
>> KEYFILE_PATTERN temporarely removed again)?
> 
> Here you go, hope this helps. more info below.

Indeed, it helped a lot.


> [...]
> + key=/boot/nvme0n1.luks
> + printf %s fishbowl-root
> + tr   \n
> + grep -Fxq crypt
> + stat -c %m -- /boot/nvme0n1.luks
> + [ / != / ]
> + node_is_in_crypttab fishbowl-root
> + [ -f /etc/crypttab ]
> + [ 1 -gt 0 ]
> + sed -rn s/^\s*([^#]\S*)\s.*/\1/p /etc/crypttab
> + grep -Fxq fishbowl-root
> + return 1
> + echo cryptsetup: WARNING: crypt's key file /boot/nvme0n1.luks is not on an 
> encrypted root FS, skipped
> cryptsetup: WARNING: crypt's key file /boot/nvme0n1.luks is not on an 
> encrypted root FS, skipped
> + return 1
> [...]
> 
>> For some reason, 'node_is_in_crypttab fishbowl-root' expands to
>> false. Is 'fishbowl-root' the name of your unlocked dm-crypt
>> device or a the name of your LVM logical volume?
> 
> The setup is as follows:
> 
>   /boot is on LV /dev/mapper/fishbowl-root
>   The fishbowl VG is on PV /dev/mapper/crypt
>   /dev/mapper/crypt is a dm-crypt mapping on top of /dev/nvme0n1p3
> 
> So to answer your question: 'root' is the LV in VG 'fishbowl', which
> sits on PV 'crypt', which is the unlocked dm-crypt device
> corresponding to the SSD.

The problem was with the following test condition for the key file:

if printf '%s' "$rootdevs" | tr ' ' '\n' | grep -Fxq "$target"; ...

it didn't didn't detect root parent devices. This is fixed now:

if printf '%s' "$OPTIONS" | tr ',' '\n' |grep -Fxq "rootdev"; ...

Could you give updated packages a try? You can find them at
https://people.debian.org/~mejo/debian/mejo-unstable/. Along with some
other changes, they should have fixed the issue you revealed.

In order to test whether the script works as expected now, you'll have
to remove the KEYFILE_PATTERN stuff again. The script now should fail
with the correct message:

cryptsetup: WARNING: root target crypt uses a key file, skipped

Cheers,
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#847135: openconnect: vpn connection mtu too big

[Martin]

Please would you consider packaging the newer version as I doubt I'll be
the only person to hit this and the new version does make it all simply
work.

The current packaged version seems to drop packets with it's MTU, I see
missed sequences in the packet trace and retransmissions but I never get
the missed packets back. The connections either drop or sit there
waiting...


Though the new version seems to ignore the interface mtu setting when
choosing the MTU, it does seems to work which makes me very happy.

interfaces:
2: wlp58s0:  mtu 1280 qdisc mq state UP
mode DORMANT group default qlen 1000
3: vpn0:  mtu 1401 qdisc
pfifo_fast state UP mode DEFAULT group default qlen 500

I would have expected the vpn connection to have a smaller mtu than that
of the network interface it was running over.

Also I wouldn't be surprised if our VPN end point had firewalls that
prevented easy MTU discovery.

Thanks,
M

Bug#847234: Please help with symlink_to_dir expression (Was: Bug#847234: r-cran-rcurl: directory vs. symlink conflict: /usr/lib/R/site-library/RCurl/examples)

[Andreas Tille]

Hi,

On Tue, Dec 06, 2016 at 07:06:39PM +0100, Andreas Beckmann wrote:
> Package: r-cran-rcurl
> Version: 1.95-4.8-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> ...
> >From the attached log (usually somewhere in the middle...):
> 
> 2m19.9s INFO: dirname part contains a symlink:
>   /usr/lib/R/site-library/RCurl/examples/CIS (r-cran-rcurl) != 
> /usr/share/doc/r-cran-rcurl/examples/CIS (?)
> /usr/lib/R/site-library/RCurl/examples -> 
> ../../../../share/doc/r-cran-rcurl/examples
>   /usr/lib/R/site-library/RCurl/examples/CIS/cis.R (r-cran-rcurl) != 
> /usr/share/doc/r-cran-rcurl/examples/CIS/cis.R (?)
> /usr/lib/R/site-library/RCurl/examples -> 
> ../../../../share/doc/r-cran-rcurl/examples
> ...

I tried to fix this the following way.  In the Jessie package
r-cran-rcurl_1.95-4.3-1+deb8u1_amd64.deb the examples link is:


$ readlink /usr/lib/R/site-library/RCurl/examples 
../../../../share/doc/r-cran-rcurl/examples


Since in the package in unstable examples is a directory I tried
to fix the upgrade path by


$ cat debian/maintscript
symlink_to_dir /usr/lib/R/site-library/RCurl/examples 
../../../../share/doc/r-cran-rcurl/examples 1.95-4.3-1


but this does not fix the situation.  Seems I have missinterpreted the manpage

   man dpkg-maintscript-helper

and I'm now asking for a hint how to do the maintainer script correctly.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#846648: another data point

[Robert Lange]

Debian stretch with chromium 55.0.2883.75-1 (and only chromium) pulled
in from unstable. With a brand new profile (i.e., by deleting
.cache/chromium and .config/chromium and starting Chromium) Chromium
aw-snaps on gfycat.com with very high probability. I occasionally also
see gmail aw-snap, but it's not consistent. When an aw-snap occurs, it
does not seem to affect other tabs.


Stack trace:

libpng warning: iCCP: known incorrect sRGB profile
Received signal 11 SEGV_MAPERR fffd503afed7
#0 0x55f8a1a8d77e 
#1 0x55f8a1a8db39 
#2 0x7fca07207100 
#3 0x55f8a025af21 
#4 0x55f8a0260ffa 
#5 0x55f8a02610bb 
#6 0x55f8a5c0f612 
#7 0x55f8a12cf952 
#8 0x55f8a1ae7495 
#9 0x55f8a1b13c21 
#10 0x55f8a1aae629 
#11 0x55f8a1aafd9d 
#12 0x55f8a1ab0240 
#13 0x55f8a1ab0e99 
#14 0x55f8a1ace66a 
#15 0x55f8a1aeb296 
#16 0x55f8a1ae7322 
#17 0x7fca071fd464 start_thread
#18 0x7fc9fc6229df clone
  r8:   r9: fffd503afecf r10: e9c46ecdadef r11:
0011bb10e749bd95
 r12:  r13: 7fc9e5cb9548 r14: 7fc9e5cb9540 r15:
e9c46ecdadef
  di: 16393e5b0f70  si: 0013  bp: 0006  bx:
fffd503afecf
  dx: fffd503afecf  ax: fffd503afecf  cx: 16393ef75fa0  sp:
7fc9e5cb94a0
  ip: 55f8a025af21 efl: 00010286 cgf: 002b0033 erf:
0005
 trp: 000e msk:  cr2: fffd503afed7
[end of stack trace]

Bug#846648: Raising severity

[Sebastian Andrzej Siewior]

On 2016-12-03 10:19:56 [+0100], Yves-Alexis Perez wrote:
> I'm not sure if it's the same issue than in 845785 so I'm not reopening that
> bug, but rather raising the severity of this one. I can confirm chromium still
> crashes here and there, sometime randomly, sometimes consistently.

It looks like the same thing.

Thread 34 "Chrome_InProcRe" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc78b7700 (LWP 5208)]
0x5ae4cdaf in SkPictureGpuAnalyzer::analyzePicture(SkPicture const*) ()
(gdb) bt
#0  0x5ae4cdaf in SkPictureGpuAnalyzer::analyzePicture(SkPicture 
const*) ()
#1  0x5934e644 in 
blink::PaintController::commitNewDisplayItems(blink::LayoutSize const&) ()
…
#26 0x7fffecfed9df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105
(gdb) disassemble 
Dump of assembler code for function 
_ZN20SkPictureGpuAnalyzer14analyzePictureEPK9SkPicture:
   0x5ae4cda0 <+0>: test   %rsi,%rsi
   0x5ae4cda3 <+3>: je 0x5ae4cdb5 
<_ZN20SkPictureGpuAnalyzer14analyzePictureEPK9SkPi
   0x5ae4cda5 <+5>: mov(%rsi),%rax
   0x5ae4cda8 <+8>: push   %rbx
   0x5ae4cda9 <+9>: mov%rdi,%rbx
   0x5ae4cdac <+12>:mov%rsi,%rdi
=> 0x5ae4cdaf <+15>:callq  *0x48(%rax)
   0x5ae4cdb2 <+18>:add%eax,(%rbx)
   0x5ae4cdb4 <+20>:pop%rbx
   0x5ae4cdb5 <+21>:repz retq 
End of assembler dump.
(gdb) info registers 
rax0x0  0
rbx0x7fffc78b59d0   140736541186512
rcx0x67c7129645711360
rdx0x67c01f57129645711861
rsi0x29f0ddfa8870   46114493073520
rdi0x29f0ddfa8870   46114493073520
rbp0x7fffc78b59d0   0x7fffc78b59d0
rsp0x7fffc78b5950   0x7fffc78b5950
r8 0x95 149
r9 0x95002f 639950127151
r100x67c01f57129645711861
r110x1c0877f48c70   30822697831536
r120x1c0877e36b98   30822696709016
r130x7fffc78b5cb0   140736541187248
r140x1d1034b88680   31955441190528
r150x1c0878192ba0   30822700231584
rip0x5ae4cdaf   0x5ae4cdaf 

eflags 0x10202  [ IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0

and the function:

| void SkPictureGpuAnalyzer::analyzePicture(const SkPicture* picture) {
| if (!picture) {
| return;
| }
| 
| fNumSlowPaths += picture->numSlowPaths();
| }

So we do have the NULL pointer check but somehow the ->numSlowPaths
function is NULL. Trying it again and again it explodes at a different
spot. Sometimes even in the TC malloc allocater. I rebuilt it even with
"gcc version 6.2.0 20160901 (Debian 6.2.0-3)" including all its deps
from 20160905T103837Z and it still explodes. Same for current gcc-5.

> Regards,

Sebastian

Bug#847277: Acknowledgement (lava-server: fails to upgrade from jessie to jessie-backports to stretch)

[Andreas Beckmann]

also reproducible on a plain jessie -> stretch upgrade

Bug#847278: libdata-uuid-libuuid-perl: new_uuid() returns uninitialized memory for version 1

[Niko Tyni]

Package: libdata-uuid-libuuid-perl
Version: 0.05-2
Severity: important
Tags: patch
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=119149

Running t/basic.t under valgrind shows uses of uninitialized values,
as seen below. This seems to be due to a typo in new_uuid(): there's a
'ggdefault' label, which should presumably be the 'default' case for
switch.

Proposed patch attached. 

  1..50
  ok 1 - use Data::UUID::LibUUID;
  ok 2 - new_uuid_string
  ==25364== Use of uninitialised value of size 8
  ==25364==at 0x55A0121: _itoa_word (_itoa.c:180)
  ==25364==by 0x55A4889: vfprintf (vfprintf.c:1636)
  ==25364==by 0x565286B: __vsprintf_chk (vsprintf_chk.c:83)
  ==25364==by 0x56527BC: __sprintf_chk (sprintf_chk.c:31)
  ==25364==by 0x775E722: sprintf (stdio2.h:33)
  ==25364==by 0x775E722: uuid_unparse_x (unparse.c:56)
  ==25364==by 0x7559874: XS_Data__UUID__LibUUID_new_uuid_string 
(LibUUID.xs:223)
  ==25364==by 0x1DC0AF: Perl_pp_entersub (pp_hot.c:3987)
  ==25364==by 0x1D45D5: Perl_runops_standard (run.c:41)
  ==25364==by 0x15A6E8: S_run_body (perl.c:2488)
  ==25364==by 0x15A6E8: perl_run (perl.c:2411)
  ==25364==by 0x13385C: main (perlmain.c:116)
  ==25364== 
  ==25364== Conditional jump or move depends on uninitialised value(s)
  ==25364==at 0x55A0128: _itoa_word (_itoa.c:180)
  ==25364==by 0x55A4889: vfprintf (vfprintf.c:1636)
  ==25364==by 0x565286B: __vsprintf_chk (vsprintf_chk.c:83)
  ==25364==by 0x56527BC: __sprintf_chk (sprintf_chk.c:31)
  ==25364==by 0x775E722: sprintf (stdio2.h:33)
  ==25364==by 0x775E722: uuid_unparse_x (unparse.c:56)
  ==25364==by 0x7559874: XS_Data__UUID__LibUUID_new_uuid_string 
(LibUUID.xs:223)
  ==25364==by 0x1DC0AF: Perl_pp_entersub (pp_hot.c:3987)
  ==25364==by 0x1D45D5: Perl_runops_standard (run.c:41)
  ==25364==by 0x15A6E8: S_run_body (perl.c:2488)
  ==25364==by 0x15A6E8: perl_run (perl.c:2411)
  ==25364==by 0x13385C: main (perlmain.c:116)
  ==25364== 
  ==25364== Conditional jump or move depends on uninitialised value(s)
  ==25364==at 0x55A4991: vfprintf (vfprintf.c:1636)
  ==25364==by 0x565286B: __vsprintf_chk (vsprintf_chk.c:83)
  ==25364==by 0x56527BC: __sprintf_chk (sprintf_chk.c:31)
  ==25364==by 0x775E722: sprintf (stdio2.h:33)
  ==25364==by 0x775E722: uuid_unparse_x (unparse.c:56)
  ==25364==by 0x7559874: XS_Data__UUID__LibUUID_new_uuid_string 
(LibUUID.xs:223)
  ==25364==by 0x1DC0AF: Perl_pp_entersub (pp_hot.c:3987)
  ==25364==by 0x1D45D5: Perl_runops_standard (run.c:41)
  ==25364==by 0x15A6E8: S_run_body (perl.c:2488)
  ==25364==by 0x15A6E8: perl_run (perl.c:2411)
  ==25364==by 0x13385C: main (perlmain.c:116)
  ==25364== 
  ==25364== Conditional jump or move depends on uninitialised value(s)
  ==25364==at 0x55A3851: vfprintf (vfprintf.c:1636)
  ==25364==by 0x565286B: __vsprintf_chk (vsprintf_chk.c:83)
  ==25364==by 0x56527BC: __sprintf_chk (sprintf_chk.c:31)
  ==25364==by 0x775E722: sprintf (stdio2.h:33)
  ==25364==by 0x775E722: uuid_unparse_x (unparse.c:56)
  ==25364==by 0x7559874: XS_Data__UUID__LibUUID_new_uuid_string 
(LibUUID.xs:223)
  ==25364==by 0x1DC0AF: Perl_pp_entersub (pp_hot.c:3987)
  ==25364==by 0x1D45D5: Perl_runops_standard (run.c:41)
  ==25364==by 0x15A6E8: S_run_body (perl.c:2488)
  ==25364==by 0x15A6E8: perl_run (perl.c:2411)
  ==25364==by 0x13385C: main (perlmain.c:116)
  ==25364== 
  ==25364== Conditional jump or move depends on uninitialised value(s)
  ==25364==at 0x55A38D2: vfprintf (vfprintf.c:1636)
  ==25364==by 0x565286B: __vsprintf_chk (vsprintf_chk.c:83)
  ==25364==by 0x56527BC: __sprintf_chk (sprintf_chk.c:31)
  ==25364==by 0x775E722: sprintf (stdio2.h:33)
  ==25364==by 0x775E722: uuid_unparse_x (unparse.c:56)
  ==25364==by 0x7559874: XS_Data__UUID__LibUUID_new_uuid_string 
(LibUUID.xs:223)
  ==25364==by 0x1DC0AF: Perl_pp_entersub (pp_hot.c:3987)
  ==25364==by 0x1D45D5: Perl_runops_standard (run.c:41)
  ==25364==by 0x15A6E8: S_run_body (perl.c:2488)
  ==25364==by 0x15A6E8: perl_run (perl.c:2411)
  ==25364==by 0x13385C: main (perlmain.c:116)
  ==25364== 
  ok 3 - new_uuid_string(1)
 
-- 
Niko Tyni   nt...@debian.org

Bug#845354: [nemo] Nemo does not mounts partition

[Margarita Manterola]

Control: reassign 845354 cinnamon 3.0.7-2
Control: reassign 845357 cinnamon 3.0.7-2
Control: merge 845764 845357 845354

Hola Vladislav!

> Nemo refuses to mount partition, that is on the same hard disk, where the
> system is.
> When I press left mouse button on the partition's label, there appears pop
> up winnow with text:
> "Could not mount partitionName
> Not authorized to perform operation"
> Below is only "OK" button.

This was caused by a recent change in policykit that failed to notify any
dependending programs of the change.  We are going to upload a fix soon, but in
the meantime you can work around it by editing
/usr/share/applications/cinnamon-polkit-gnome-authentication-agent-1.desktop
Replacing:
  Exec=/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
With:
  Exec=/usr/lib/polkit-gnome-authentication-agent-1

-- 
Regards,
Marga

Bug#845553: kmail: Properties of a folder will only come up once

[Nancy Anthracite]

So you were able to reproduce it!!! THANK YOU!

Nancy Anthracite

On Tuesday, December 6, 2016 8:10:40 PM EST Maximiliano Curia wrote:
> Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=373363
> Control: tag -1 + patch pending
> 
> ¡Hola Nancy!
> 
> I've added a patch for the akonadi version in Debian, this should be part of 
> the next akonadi upload.
> 
> Happy hacking,
>