Bug#837734: mutt: tag save duplicates messages

[Antonio Radici]

Control: tag -1 +confirmed pending

On Tue, Sep 13, 2016 at 07:24:38PM -0500, Luis Mochan wrote:
> Package: mutt
> Version: 1.7.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> When I tag one or more messages in my INBOX (Maildir) and save them to
> my mbox using the command ';s' and answering '>' as the mailbox to
> save them, each tagged message is saved twice. If I save the messages
> individually they are not duplicated. This behavior started recently,
> I guess when NeoMutt replaced mutt in debian/testing.
> 

Hi Luis,
this is a known issue, there is a patch already which has been applied and that
we can backport. I'll get this fixed in the next Debian release regardless, but
it will take at least a week from now as I would like 1.7.0-5 to enter testing
first.

Bug#836531: Bugs needs reopening, fix is not a real fix (IMHO)

[Rene Engelhard]

On Wed, Sep 14, 2016 at 05:26:39AM +0200, Christoph Gutjahr wrote:
> The bug described in 836531 has been marked as fixed, but there are two

No, it hasn't. It has been reopened one week ago already,

> If libreoffice-gtk2 is now a requirement on XFCE, shouldn't the update
> process make sure that it is present?

There's no "upgrade process". apt upgrades packages, and if you didn't have
-gtk or -gtk2 installed before, apt can't know that it should install -gtk2

And as said, if you have -gtk3 installed, even if -gtk2 is there, too,
it takes precedence, so..

> The second and more important problem is that the guy submitting the
> bug report didn't make it clear that libreoffice-gtk3 was working
> perfectly fine with XFCE until a day or two ago - I've been using that

He did.

> setup for ages without problems. The actual bug is that it suddenly
> started misbehaving (the GUI being extremely slow being one fault, but
> not the only one). And since all my other GTK3 applications are working
> perfectly fine with XFCE, I don't see how this could be a general "GTK3
> vs. XFCE" problem.

> 
Well, LO does "special things" and renders stuff by itself. It's not
a "typical" Gtk application.

> Refer to bug 837356  for a report filed a few days ago about "gtk3
> being slow" - from a Gnome 3 user.

Which I wasn't able to act on, yet.

> Please reopen 836531 and/or merge it with 837356. Also, since XFCE is

It was already. One week ago.

> already (slowly) moving towards GTK3 and is indeed already shipping
> GTK3 based modules...
> 
> https://wiki.xfce.org/releng/4.14/roadmap

How useful without dates.. ;)

But good to know.

> ...libreoffice-gtk3 should of course be a fallback for XFCE.

Only when that happened. But I will revert the patch anyway, as it apparently
didn't help.

> Apologies for the lengthy mail, but I don't have an account for the
> bugtracker yet, it's 5am and I'm about to head out of town.

That might explain why you git the bug status wrong ;)

Regards,

Rene

Bug#837535: When a relay host lacks an IPv6 interface, mail heisenbounces

[Marc Haber]

On Mon, Sep 12, 2016 at 10:01:49AM +, Thaddeus H. Black wrote:
> > Full details are discussed here
> > [http://unix.stackexchange.com/q/308283/18202], where a user named
> > Rui F. Ribeiro cleverly discovers the fix.
> 
> The bug server's web archived does not seem to like the way I
> have formatted that URL.  This may work better: [1].
> 
> [1] http://unix.stackexchange.com/q/308283/18202

I would appreciate if you would report this upstream. We might apply
this patch in Debian without an exim release if upstream accepts it as
well.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#837743: lxc: Segfault (symbol size mismatch) when starting container created with "download" template

[Michael Gardner]

Package: lxc
Version: 1:2.0.4-1
Severity: important

I created an unpriviliged Ubuntu (xenial, amd64) container using "lxc-create -n 
foo -t download", and it seemed to complete with no problems. But when I try to 
start this container using "lxc-start -n foo", I get this error:

>lxc-start: Symbol `ns_info' has different size in shared object, consider 
>re-linking
>Segmentation fault

Lxc doesn't provide any more logging information or output, even when I set 
--logpriority to something high. I also tried creating a Debian (sid, amd64) 
container using the download template and got the same error.

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

Kernel: Linux 4.7.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 lxc depends on:
ii  init-system-helpers  1.44
ii  libapparmor1 2.10.95-4
ii  libc62.24-2
ii  libcap2  1:2.25-1
ii  liblxc1  1:2.0.4-1
ii  libseccomp2  2.3.1-2
ii  libselinux1  2.5-3
ii  python3  3.5.1-4
pn  python3:any  

Versions of packages lxc recommends:
ii  bridge-utils  1.5-9
ii  cgmanager 0.41-2
ii  debootstrap   1.0.83
ii  dirmngr   2.1.15-2
ii  dnsmasq-base  2.76-4
ii  gnupg 2.1.15-2
ii  iptables  1.6.0-3
ii  libpam-cgfs   2.0.3-1
ii  lxcfs 2.0.3-1
ii  openssl   1.0.2h-1
ii  rsync 3.1.1-3
ii  uidmap1:4.2-3.1

Versions of packages lxc suggests:
ii  apparmor 2.10.95-4
pn  btrfs-tools  
pn  lua5.2   
pn  lvm2 

-- no debconf information

Bug#837742: diffoscope: debian/tests/basic-command-line fails

[Mattia Rizzolo]

On Wed, Sep 14, 2016 at 04:55:44PM +1200, Michael Hudson-Doyle wrote:
> Dear Maintainer,

Hi.

> As of version 60, the basic-command-line autopkgtest fails:
> 
> https://ci.debian.net/packages/d/diffoscope/unstable/amd64/

yeah..
I forgot that I've added new bits that prints stderr...

> ... I've just noticed that this is probably fixed in git, so maybe I'm
> just asking for an upload :-)

peaking at your email address, noticing your @ubuntu.com domain and a
local part that gives away you're a canonical employer, you are probably
mostly interest at the failures at
http://autopkgtest.ubuntu.com/packages/d/diffoscope
instead.  Be aware that that's not the only thing failing there.  I
failed to debug that last time, and I wanted to actually try it again
with more time resources for the next upload.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#762311: task-laptop: drop acpi package recommendation?

[Christian PERRIER]

Quoting Bob Bib (bob...@ukr.net):
> Any opinion from the maintainers?..
> 
> -- 
> Best wishes,
> Bob
> 

I just committed the fix in git.


-- 




signature.asc
Description: PGP signature

Bug#837742: diffoscope: debian/tests/basic-command-line fails

[Michael Hudson-Doyle]

Source: diffoscope
Version: 60
Severity: important

Dear Maintainer,

As of version 60, the basic-command-line autopkgtest fails:

https://ci.debian.net/packages/d/diffoscope/unstable/amd64/

... I've just noticed that this is probably fixed in git, so maybe I'm
just asking for an upload :-)

Cheers,
mwh

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (400, 'xenial-proposed'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#837714: libarchive: CVE-2016-5418: Archive Entry with type 1 (hardlink), but has a non-zero data size file overwrite

[Salvatore Bonaccorso]

On Tue, Sep 13, 2016 at 09:41:49PM +0200, Salvatore Bonaccorso wrote:
> [0] https://security-tracker.debian.org/tracker/CVE-2016-5418
> [1] 
> https://git.centos.org/blob/rpms!libarchive.git/9952851f8b327a8c93d26a5873c190c1fb09ae6c/SOURCES!libarchive-3.1.2-CVE-2016-5418.patch;jsessionid=1dexz8h9qdewibih5aonbu3
> [2] 
> https://git.centos.org/blob/rpms!libarchive.git/9952851f8b327a8c93d26a5873c190c1fb09ae6c/SOURCES!libarchive-3.1.2-CVE-2016-5418-variation.patch;jsessionid=1dexz8h9qdewibih5aonbu3
> [3] 
> https://github.com/libarchive/libarchive/commit/dfd6b54ce33960e420fb206d8872fb759b577ad9

Please note, not (yet) clear if [3] ist the only one. The CVE relates
to https://bugzilla.redhat.com/show_bug.cgi?id=1362601 and to 
http://seclists.org/oss-sec/2016/q3/255 . 

Regards,
Salvatore

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

[Boyuan Yang]

Hello,

2016-09-12 21:34 GMT+08:00 Sean Whitton :
> Dear Boyuan,
>
> On Sun, Sep 11, 2016 at 08:48:15AM +0800, Boyuan Yang wrote:
>> > - status of lemon parser currently unclear
>>
>> This is fixed in the RFS of qevercloud before already. Of course we are
>> using the lemon parser from Debian. The bundled source code of lemon
>> is discarded in the source package. Sorry I didn't update the situation
>> on that Github thread, which is a little bit outdated.
>
> Great.
>
>> You suggested the separate packaging of qevercloudgenerator, but now we
>> seems to agree that since it is not useful for anything other than building
>> qevercloud,  it should not be packaged separately.
>
> Right.
>
>> Now the problem is focused on the separation of evernote-thrift files.
>>
>> I believe you suggested packaging thrift files alone, since the
>> separated package
>> can be used by other packages (most likely as a Build-Depend?), and to deal
>> with the FTBFS of qevercloud after the version bump of evernote-thrift, we 
>> can
>> include multiple copies. Did you suggest the coexistence of multiple versions
>> of evernote-thrift in the Debian repository, for example,
>> "evernote-thrift-1-25" and
>> "evernote-thrift-1-28"? Or if I misunderstood, it is just one package
>> "evernote-thrift"
>> but provides different versions of files inside one binary package (e.g.,
>> /usr/share/evernote/thrift/1.25/foobar and
>> /usr/share/evernote/thrift/1.28/foobar)?
>
> No, I was suggesting that you just embed the thrift files in your
> qevercloud source package, as you wanted to do originally.
>
> When I said "multiple versions in the archive" I meant copies in various
> source packages, but not in any binary packages.
>
>> Personally I am against the separated package of evernote-thrift, and
>> the main reason is that it is not useful; thrift files are technically
>> used by no one other than evernote people; developers are
>> encouraged/guided to use official Evernote SDK released by evernote,
>> which is already a generated project from the thrift files; no one
>> else is parsing thrift files by him/herself.
>
> Right.  They shouldn't be installed: just present in the qevernote
> source package for the purposes of regeneration.
>
> Could you confirm that your git repository is up-to-date with our
> discussion, so I can (finally!) do a review of your packaging, please?

Yes, they are up-to-date now. The package on debian-mentors is also
updated.


Sincerely,
Boyuan Yang

Bug#837469: nmu: dose3_5.0.1-1

[Johannes Schauer]

Hi,

Quoting Emilio Pozuelo Monfort (2016-09-14 00:47:01)
> On 11/09/16 22:04, Johannes Schauer wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: binnmu
> > 
> > nmu dose3_5.0.1-1 . ANY . unstable . -m "rebuild for camlzip 1.06-1"
> 
> Can you explain why this is needed? We don't like to blindly binNMU stuff, so
> a little explanation is always helpful.

When src:dose3 (= 5.0.1-1) was originally built, it was built with src:camlzip
(= 1.05-3) in the archive. This means that src:dose3 built libdose3-ocaml with
a dependency on the virtual package libzip-ocaml-8wtm6 on amd64 which was
provided by libzip-ocaml (= 1.05-3). Building the new src:camlzip release
1.06-1, replaced that libzip-ocaml package by a new version which now provides
libzip-ocaml-4m8e9 on amd64. As a result, no package provides
libzip-ocaml-8wtm6 anymore and libdose3-ocaml ocaml become uninstallable. You
can verify this situation here:

https://packages.debian.org/sid/libdose3-ocaml (it says Package not available
next to libzip-ocaml-8wtm6)

and here:

https://qa.debian.org/dose/debcheck/unstable_main/1473742805/packages/libdose3-ocaml.html

The situation is analogous on all other architectures than amd64.

The situation arises because OCaml packages are statically linked and
rebuilding a library requires a rebuild of all its reverse dependencies. I was
told in #debian-ocaml that usually Stéphane Glondu would schedule OCaml binNMUs
but he hasn't been on IRC for 3 days, so Mehdi Dogguy advised me to ask the
release team to schedule the required binNMU of src:dose3.

One practical consequence of libdose3-ocaml not being installable right now is,
that src:botch is currently bd-uninstallable:

https://buildd.debian.org/status/package.php?p=botch

Thank you!

cheers, josch


signature.asc
Description: signature

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

[Bob Friesenhahn]

On Wed, 14 Sep 2016, László Böszörményi wrote:


As Perl debug and libc6 debug symbols installed, I don't know which
library / executable may contain points #0 and #1. Maybe log.c itself?
At least the mentioned line in #2 is:
LockSemaphoreInfo(log_semaphore);


There were no functions added or removed between 1.3.24 and 1.3.25 and not
interfaces were changed.  If 1.3.24 still builds on the build machine, then
it is possible to test by replacing individual source files in 1.3.25 with
files from 1.3.24 and seeing when the problem goes away.  Since all tests
are failing, the problematic code would need to be used in initialization,
or somehow always encountered. Perhaps magick/utility.c would be a good
starting point.

Yes, 1.3.24 builds fine in the same environment. As previously noted
the broken change happened before 08th of August and it's not the
MAGICK_CACHE_LINE_SIZE value.


It seems that "semaphores" (pthread mutex locks or OpenMP locks 
depending on configuration, but should be pthread mutex locks in this 
configuration) are not working in the context of Perl/PerlMagick.


The crash occurs very early in initialization.  The crash is under the 
initial InitializeMagick() and when the first "semaphore" is locked. 
The log.c file was changed prior to the 1.3.24 release and semaphore.c 
has not changed since 2014.


I don't see any GraphicsMagick source code which has changed up to the 
point of the crash.  The only thing which changed in PerlMagick itself 
was the version string.


There is something suspect about the stack:

Thread 1 (Thread 0x3fffb7ff65b0 (LWP 3923)):
#0  0x000bffc8 in ?? ()
#1  0x000bffcb in ?? ()
#2  0x3fffb796b320 in InitializeLogInfo () at magick/log.c:301
#3  0x3fffb796c62c in InitializeMagick (path=0x3fffb7bf0708
"Graphics::Magick") at magick/magick.c:1117
#4  0x3fffb7bf0074 in boot_Graphics__Magick (my_perl=0x10210010,
cv=) at Magick.xs:2064

What seems suspect is that I would expect that #1 would be a decoded 
LockSemaphoreInfo() call and #0 would be a pthread_mutex_lock() call. 
These are in the same library so they should be decoded by the 
debugger equally well.  Probably pthread_mutex_lock() is also a 
function so there should be at least one more level of function calls 
on the stack.  It is as if the call went to a different library.


It may be necessary to prove where the problem is occuring by manually 
overwriting updated files in the magick directory with those from the 
previous working version until the problem goes away (assuming that it 
does).


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Bug#836531: Bugs needs reopening, fix is not a real fix (IMHO)

[Christoph Gutjahr]

Hello,

The bug described in 836531 has been marked as fixed, but there are two
problems with that:

Apparently, the fix simply involves ignoring libreoffice-gtk3 if the
user is using XFCE. I'm running XFCE, and I do not have libreoffice-
gtk2 installed - so my LibreOffice suddenly used a very ugly and
completely broken fallback that looks a lot like Windows 95.

If libreoffice-gtk2 is now a requirement on XFCE, shouldn't the update
process make sure that it is present?

The second and more important problem is that the guy submitting the
bug report didn't make it clear that libreoffice-gtk3 was working
perfectly fine with XFCE until a day or two ago - I've been using that
setup for ages without problems. The actual bug is that it suddenly
started misbehaving (the GUI being extremely slow being one fault, but
not the only one). And since all my other GTK3 applications are working
perfectly fine with XFCE, I don't see how this could be a general "GTK3
vs. XFCE" problem.

Refer to bug 837356  for a report filed a few days ago about "gtk3
being slow" - from a Gnome 3 user.

Please reopen 836531 and/or merge it with 837356. Also, since XFCE is
already (slowly) moving towards GTK3 and is indeed already shipping
GTK3 based modules...

https://wiki.xfce.org/releng/4.14/roadmap

...libreoffice-gtk3 should of course be a fallback for XFCE.

Apologies for the lengthy mail, but I don't have an account for the
bugtracker yet, it's 5am and I'm about to head out of town.

Gruß,
Christoph
-- 
Web:   http://gutjahr.free.fr/
Voice: +49 1512 0005928
Fax:   +49 7531 3611967

Bug#836381: RFS: couchapp/1.0.2+dfsg1-1

[gustavo panizzo]

On Wed, Sep 14, 2016 at 11:00:55AM +0800, gustavo panizzo wrote:
> Please wait, I missed an update to debian/watch.

Now git repo is ready to be reviewed

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

keybase: https://keybase.io/gfa


signature.asc
Description: PGP signature

Bug#836381: RFS: couchapp/1.0.2+dfsg1-1

[gustavo panizzo]

Please wait, I missed an update to debian/watch.

On Wed, Sep 14, 2016 at 10:55:40AM +0800, gustavo panizzo wrote:
> On Fri, Sep 09, 2016 at 07:26:52AM +, Gianfranco Costamagna wrote:
> > Hi
> > 
> > >ohhh, totally get it. thanks for spotting it
> > 
> > 
> > thanks for getting it ;)
> > 
> > is the only way i found to silence lintian about non-encrypted Vcs- urls
> > 
> > 
> > "https://anonscm.debian.org/cgit/collab-maint/couchapp.git;
> > 
> > and 
> > 
> > "https://anonscm.debian.org/git/collab-maint/couchapp.git;
> 
> both can be used on the browser or git clone, neither of them can be
> used to push :(
> 
> > 
> > simple as that :)
> > >i removed it as it was going to bit rot, i replaced it by README.source
> > >which sould make easier for others to follow.
> > 
> > "diferently." <-- typo
> 
> arrgghhh
> 
> > 
> > I still think Files-Excluded copyright feature is a better solution, but
> > feel free to use your best workflow :)
> > 
> > new review:
> > couchapp-1.0.2+dfsg1/debian/CHANGELOG
> > 
> > this file has been added in this upload...
> > mistake?
> its the upstream changelog, i generated it from git log
> 
> > 
> > 
> > still one license missing
> > ./couchapp/templates/vendor/couchapp/_attachments/md5.js
> > 
> > 
> > * A JavaScript implementation of the RSA Data Security, Inc. MD5 Message
> > * Digest Algorithm, as defined in RFC 1321.
> > * Version 2.1 Copyright (C) Paul Johnston 1999 - 2002.
> > * Other contributors: Greg Holt, Andrew Kepert, Ydnar, Lostinet
> > * Distributed under the BSD License
> > * See http://pajhome.org.uk/crypt/md5 for more info.
> > 
> ar, fixed. thanks
> 
> > 
> > we should be really good after this one :)
> > 
> > (sorry for being so pedantic!)
> 
> no worries, thanks for keeping pushing it
> 
> 
> --
> 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333
> 
> keybase: https://keybase.io/gfa



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

keybase: https://keybase.io/gfa

Bug#833132: steam: Steam randomly crashes

[Michael Gilbert]

control: tag -1 moreinfo

> However when I run steam in Sparky I do not get these panic messages, and
> furthermore, steam does not crash. In Sparky, when I do
[...]
> While in Sparky, I am running nouveau version: 1:1.0.12-2,
> libdrm-nouveau2:amd64 2.4.68-1

There is a libdrm-noveau2 2.4.70-1~bpo8+1 package in jessie-backports,
does that help?

Best wishes,
Mike

Bug#836381: RFS: couchapp/1.0.2+dfsg1-1

[gustavo panizzo]

On Fri, Sep 09, 2016 at 07:26:52AM +, Gianfranco Costamagna wrote:
> Hi
> 
> >ohhh, totally get it. thanks for spotting it
> 
> 
> thanks for getting it ;)
> 
> is the only way i found to silence lintian about non-encrypted Vcs- urls
> 
> 
> "https://anonscm.debian.org/cgit/collab-maint/couchapp.git;
> 
> and 
> 
> "https://anonscm.debian.org/git/collab-maint/couchapp.git;

both can be used on the browser or git clone, neither of them can be
used to push :(

> 
> simple as that :)
> >i removed it as it was going to bit rot, i replaced it by README.source
> >which sould make easier for others to follow.
> 
> "diferently." <-- typo

arrgghhh

> 
> I still think Files-Excluded copyright feature is a better solution, but
> feel free to use your best workflow :)
> 
> new review:
> couchapp-1.0.2+dfsg1/debian/CHANGELOG
> 
> this file has been added in this upload...
> mistake?
its the upstream changelog, i generated it from git log

> 
> 
> still one license missing
> ./couchapp/templates/vendor/couchapp/_attachments/md5.js
> 
> 
> * A JavaScript implementation of the RSA Data Security, Inc. MD5 Message
> * Digest Algorithm, as defined in RFC 1321.
> * Version 2.1 Copyright (C) Paul Johnston 1999 - 2002.
> * Other contributors: Greg Holt, Andrew Kepert, Ydnar, Lostinet
> * Distributed under the BSD License
> * See http://pajhome.org.uk/crypt/md5 for more info.
> 
ar, fixed. thanks

> 
> we should be really good after this one :)
> 
> (sorry for being so pedantic!)

no worries, thanks for keeping pushing it


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

keybase: https://keybase.io/gfa


signature.asc
Description: PGP signature

Bug#837650: RFS: cf-python/1.3.1-1 [ITP]

[Ben Finney]

On Wed, 2016-09-14 11:17 +1000, Ben Finney  wrote:
> Here are some comments I have for improving the packaging work:

Further:

* The source package should ideally not contain non-source forms of the
work.

  I see that there is a tree of generated documentation that is not the
  source form.

  Instead, the generated files should be removed from the Debian source
  file, and the documentation built from its source form at build time
  using upstream's build procedure for that.

  Similarly, any non-source forms should be removed and (if necessary)
  replaced with their corresponding source in a re-packaged upstream
  tarball. The Debian build should use upstream's build system for
  generating those files from their source form, and only install that
  result.

-- 
 \
  `\
_o__) Ben Finney 

Bug#832077: Info received (emacs clutter screen on windows switch)

[Yasushi SHOJI]

On Thu, 08 Sep 2016 10:38:09 +0900,
Leon Meier wrote:
> 
> By the way, I don't know who is the culprit: libgtk-3-0, emacs, or
> someone else. So please consider my found / nofound tags just as
> additional information on my configuration rather as a bug source
> hint. Sorry about that.

https://mail.gnome.org/archives/commits-list/2016-May/msg06553.html

I found this commit on Gtk+. So I assume this is an intended change
for Gtk+ 3.22, no?
--
   yashi

Bug#837741: pithos: Won't start without gir1.2-notify0.7 installed

[D. Jackson Peacock]

Package: pithos
Version: 1.1.2-1
Severity: important

Dear Maintainer,
Recently pithos started hanging on start-up with the following exception:

Traceback (most recent call last):
  File "/usr/share/pithos/pithos/pithos.py", line 1112, in do_command_line
self.do_activate()
  File "/usr/share/pithos/pithos/pithos.py", line 1119, in do_activate
self.window = NewPithosWindow(self, self.options)
  File "/usr/share/pithos/pithos/pithos.py", line 1053, in NewPithosWindow
window.finish_initializing(builder, options)
  File "/usr/share/pithos/pithos/pithos.py", line 165, in 
finish_initializing
load_plugins(self)
  File "/usr/share/pithos/pithos/plugin.py", line 92, in load_plugins
plugin = plugins[name] = load_plugin(name, window)
  File "/usr/share/pithos/pithos/plugin.py", line 67, in load_plugin
module = __import__('pithos.plugins.'+name)
  File "/usr/share/pithos/pithos/plugins/notify.py", line 24, in 
gi.require_version('Notify', '0.7')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 102, in 
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Notify not available

Installing gir1.2-notify-0.7 solved the problem, however this package is not a
required dependancy of pithos, just a recommended package.


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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.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 pithos depends on:
ii  gir1.2-gst-plugins-base-1.0  1.8.3-1
ii  gir1.2-gstreamer-1.0 1.8.3-1
ii  gir1.2-gtk-3.0   3.21.5-3
ii  gstreamer1.0-plugins-bad 1.8.2-1+b2
ii  gstreamer1.0-plugins-good1.8.3-1+b1
ii  python3-gi   3.20.1-1
ii  python3-gi-cairo 3.20.1-1
ii  python3-pkg-resources26.1.1-1
pn  python3:any  

Versions of packages pithos recommends:
pn  gir1.2-appindicator3-0.1   
pn  gir1.2-keybinder-3.0   
ii  gir1.2-notify-0.7  0.7.6-2
pn  gnome-icon-theme-symbolic  
pn  python3-dbus   
pn  python3-pylast 

pithos suggests no packages.

-- no debconf information

Bug#837537: "Mkdir: file exists" error if any debootstrap file download failed

[Boyuan Yang]

Hello,

2016-09-12 20:06 GMT+08:00 Stephan Sürken :
>> I upgraded my Debian build machine to sid for latest 1.0.18 and found
>> it
>> impossible to create any dir chroots.
> (...)
>
> do I understand you correctly that the rollback mechanism can bring
> mini-buildd into that state in case debootstrap fails to work properly
> due to network problems?

Well not really. I just find it strange that when creating a dir chroot,
the debootstrap will fail silently immediately after one package falis
to download *once*. The dir-chroot creating process should either fail
immediately or re-run the debootstrap process again with a warning
sent to the logger,
but it just continued as if everything is fine *until* the mkdir error
happens (which is due to the unclean exit of debootstrap, maybe?)


Thanks,
Boyuan Yang

Bug#837740: apt: apt-timer disabled during upgrade

[Olaf Meeuwissen]

Package: apt
Version: 1.3~rc4
Severity: important

Dear Maintainer,

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.6\.0-1-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Enable "1";
APT::Periodic::Verbose "2";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradable-Packages "1";
APT::Periodic::AutocleanInterval "1";
APT::Periodic::Download-Upgradeable-Packages-Debdelta "1";
APT::Periodic::Unattended-Upgrade "2";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Default-Release "testing";
APT::Get "";
APT::Get::AutomaticRemove "true";
APT::Get::Purge "true";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 

Bug#837739: ITP: haskell-polynomial -- haskell types and functions for working with polynomials

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: haskell-polynomial
  Version : 0.7.2
  Upstream Author : James Cook 
* URL : https://hackage.haskell.org/package/polynomial
* License : public domain
  Programming Lang: Haskell
  Description : haskell types and functions for working with polynomials

I am packaging this as a dependency of haskell-secret-sharing, another
ITP of mine.

I intend to maintain this as part of the Haskell team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#837738: Fails to start, Invalid property: GtkScrolledWindow.propagate-natural-height

[Michael Biebl]

Package: nautilus
Version: 3.21.92-1
Severity: grave

When running nautilus, one get's

(nautilus:28168): Gtk-CRITICAL **: Error building template class
'NautilusToolbar' for an instance of type 'NautilusToolbar': .:194:52
Invalid property: GtkScrolledWindow.propagate-natural-height
Segmentation fault



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

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

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.23-1
ii  gsettings-desktop-schemas  3.21.4-2
ii  gvfs   1.29.92-1
ii  libatk1.0-02.21.90-2
ii  libc6  2.24-2
ii  libcairo-gobject2  1.14.6-1+b1
ii  libcairo2  1.14.6-1+b1
ii  libexempi3 2.3.0-2
ii  libexif12  0.6.21-2
ii  libgail-3-03.21.5-3
ii  libgdk-pixbuf2.0-0 2.35.5-1
ii  libglib2.0-0   2.49.7-1
ii  libglib2.0-data2.49.7-1
ii  libgnome-autoar-0-00.1.1-4
ii  libgnome-desktop-3-12  3.21.92-1
ii  libgtk-3-0 3.21.5-3
ii  libnautilus-extension1a3.21.92-1
ii  libpango-1.0-0 1.40.2-1
ii  libselinux12.5-3
ii  libtracker-sparql-1.0-01.9.1-2
ii  libx11-6   2:1.6.3-1
ii  nautilus-data  3.21.92-1
ii  shared-mime-info   1.7-1

Versions of packages nautilus recommends:
ii  gnome-sushi  3.21.91-1
ii  gvfs-backends1.29.92-1
ii  librsvg2-common  2.40.16-1

Versions of packages nautilus suggests:
ii  brasero3.12.1-2
ii  eog3.20.4-1
ii  evince [pdf-viewer]3.21.4-1
ii  okular [pdf-viewer]4:16.04.2-1
ii  totem  3.21.91-1
ii  tracker1.9.1-2
ii  vlc [mp3-decoder]  2.2.4-3+b4
ii  vlc-nox [mp3-decoder]  2.2.4-3+b4
ii  xdg-user-dirs  0.15-2
ii  xpdf [pdf-viewer]  3.04-1+b1

-- no debconf information

Bug#669119: In ip-up.d if fail then try again after 3s.

[Stefan Monnier]

>   Don't know why but my PPP interface sometimes isn't working right away and
> needs some time to settle, so sometimes when ddclient runs from
> /etc/ppp/ip-up.d/ddclient it is unable to set the new IP.
>   My workaround was to add a "sleep 3" in /etc/default/ddclient.

I see the same problem here (running Debian stable on an OrangePi box).
More specifically, /etc/ppp/ip-up.d/ddclient almost never works for me,
and in that script ddclient returns the following:

WARNING:  cannot connect to www.dnsdynamic.org:80 socket: IO::Socket::INET: 
Bad hostname 'www.dnsdynamic.org'
FAILED:   updating : Could not connect to www.dnsdynamic.org.

Same with freedns.afraid.org.  I changed that file to end with

(sleep 10; /usr/sbin/ddclient -syslog -ip $PPP_LOCAL)&

and it seems to have fixed my problem, so it looks like the ip-up.d
script is run "too early" (i.e. before the DNS is properly setup).


Stefan


PS: BTW, this ddclient script is brittle.  E.g. the line

if [ ! $if = $PPP_IFACE ]; then

should be replaced with something like

if [ ! "x$if" = "x$PPP_IFACE" ]; then

Bug#837737: ITP: haskell-secret-sharing -- implementation of an (m, n)-threshold secret sharing scheme

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: haskell-secret-sharing
  Version : 1.0.0.3
  Upstream Author : Peter Robinson 
* URL : http://monoid.at/#Code
* License : LGPL-2.1
  Programming Lang: Haskell
  Description : implementation of an (m,n)-threshold secret sharing scheme

I'm packaging this as a library dependency of keysafe, another ITP of
mine.

I intend to maintain it as part of the Haskell team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#837736: ITP: haskell-dice-entropy-conduit -- cryptographically secure n-sided dice rolls and random sampling

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: haskell-dice-entropy-conduit
  Version : 1.0.0.1
  Upstream Author : Peter Robinson 
* URL : http://monoid.at/#Code
* License : LGPL-2.1
  Programming Lang: Haskell
  Description : cryptographically secure n-sided dice rolls and random 
sampling

I'm packaging this as a dependency of haskell-secret-sharing, a
dependency of keysafe, another ITP of mine.

I intend to maintain it as part of the Haskell team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#837735: O: smlnj

[James McCoy]

Package: wnpp
Severity: normal

I don't have the time to maintain this anymore, especially as I don't actively
use it.  The package description is:

Description: Standard ML of New Jersey interactive compiler
 SML/NJ is an implementation of the Standard ML programming language.
 Standard ML has many features, including type safety, polymorphism,
 algebraic data types with pattern matching, higher-order functions,
 and a sophisticated module system. It is especially well-suited for
 writing compilers and other language processors.

Bug#836153: mutter: FTBFS on non-Linux: No package 'wayland-server' found

[Jeremy Bicha]

Control: tags -1 +pending -help

I think this is mostly fixed with 3.21.92-1

https://tracker.debian.org/media/packages/m/mutter/changelog-3.21.92-1

I didn't realize a bug had been filed about this or I would have
closed it in the changelog.

It still doesn't build on non-Linux because of a missing dependency
but I added that to the next gtk3 update. Since there will be a new
mutter upload next week, we'll see if mutter builds then.

By the way, the only two packages in Debian that use mutter are
gnome-shell and budgie-desktop, both of which are Linux-only.

Jeremy

Bug#837650: RFS: cf-python/1.3.1-1 [ITP]

[Ben Finney]

Howdy Klaus,

Thank you for working on this package.

Here are some comments I have for improving the packaging work:

* When removing code, just remove it. You are tracking the work in a
VCS, there is generally no reason to commit changes that comments out
lines of code.

  So, in ‘debian/patches/’, the
  ‘0001-Remove-check-for-python-version.patch’ and
  ‘0003-Patch-sphinx-config-to-avoid-network-access-and-add-.patch’
  changes (actually, the Git commits you used to generate those files)
  should not comment any code lines but instead remove those lines.

* Wow, hard-coding a man page in a Python string literal is a fragile
way to store the document.

  Have you discussed with upstream the feasibility of moving those to
  their own first-class source documents, and reading from there at run
  time? Python ‘pkg_resources’ has functionality to locate and read a
  file installed as part of the package.

* In ‘debian/copyright’, please don't obfuscate the email addresses of
copyright holders. It's a needless barrier to getting useable contact
information for legal purposes.

* Is there a good reason to omit the “Upstream-Maintainer” field in the
header of the ‘debian-copyright’ file? There seems to be an obvious
single maintainer contact for this code base.

* The ‘cf/etc/udunits/’ tree looks like a bundled third-party work. Per
Debian Policy §4.13, should this work not be packaged separately and
listed as a dependency?

* Can you include a ‘debian/README.source’ explaining how you collated
the various parts and changes you've made from the upstream source?

  In particular, the procedure for making ‘debian/*.1’ and
  ‘debian/test_file.nc’ should be described, along with rationales that
  can be later re-visited if upstream policies change.

-- 
 \
  `\
_o__) Ben Finney 

Bug#836412: Fwd: RE: qtwebengine on armhf

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 12 de septiembre de 2016 7:54:07 P. M. ART Sandro Knauß wrote:
> Control: reassign -1 qtdeclarative-opensource-src
> Control: tags -1 +patch
> 
> Hey,
> 
> it would be great to add the patch to qtdeclerative

It's backporting a patch, so please feel free to do the commits and ping me to 
check them.

> and enable the tests, as
> upstream points out, this would may have helped here.

Please go ahead and make them work, we will be happy to have them working :)


-- 
Quote me as saying I was mis-quoted.
 -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#586360: netcfg/get_hostname

[Nye Liu]

With DCHP ENABLED:

I have tried:

Null string:
d-i netcfg/hostname string 
d-i netcfg/get_hostname string 

Seen false:
d-i netcfg/hostname seen false
d-i netcfg/get_hostname seen false

The only workaround seems to be to remove priority=critical from the kernel
command line (annoying, since there is no easy way to automate this short
of making your own iso or editing grub.cfg in your tftp netboot server)

There is an annoying side effect to this though; d-i netcfg/get_domain
is ignored, and the user always has to enter the domain.

Bug#837734: mutt: tag save duplicates messages

[Luis Mochan]

Package: mutt
Version: 1.7.0-1
Severity: normal

Dear Maintainer,

When I tag one or more messages in my INBOX (Maildir) and save them to
my mbox using the command ';s' and answering '>' as the mailbox to
save them, each tagged message is saved twice. If I save the messages
individually they are not duplicated. This behavior started recently,
I guess when NeoMutt replaced mutt in debian/testing.

Best regards,
Luis


-- Package-specific info:
NeoMutt  (1.7.0)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.6.0-1-amd64 (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.0-1' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20160822 (Debian 6.2.0-1) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-wQLglL/mutt-1.7.0=. -fPIE 
-fstack-protector-strong -Wformat -Werror=format-security' 'LDFLAGS=-fPIE -pie 
-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-wQLglL/mutt-1.7.0=. -fPIE 
-fstack-protector-strong -Wformat -Werror=format-security

Compile options:
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME 
+DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK 
-SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_GETADDRINFO 
+HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR 
+HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP +HAVE_RESIZETERM +HAVE_START_COLOR 
+HAVE_TYPEAHEAD +HAVE_WC_FUNCS +ICONV_NONTRANS +USE_COMPRESSED +USE_DOTLOCK 
+USE_FCNTL -USE_FLOCK -USE_FMEMOPEN -USE_GNU_REGEX +USE_GSS +USE_HCACHE 
+USE_IMAP +USE_NOTMUCH +USE_NNTP +USE_POP +USE_SASL +USE_SETGID +USE_SIDEBAR 
+USE_SMTP +USE_SSL_GNUTLS -USE_SSL_OPENSSL 
-DOMAIN
MIXMASTER="mixmaster"
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"

patch-compress-neomutt
patch-cond-date-neomutt
patch-fmemopen-neomutt
patch-ifdef-neomutt
patch-index-color-neomutt
patch-initials-neomutt
patch-keywords-neomutt
patch-limit-current-thread-neomutt
patch-lmdb-neomutt
patch-multiple-fcc-neomutt
patch-nested-if-neomutt
patch-new-mail-neomutt
patch-nntp-neomutt
patch-notmuch-neomutt
patch-progress-neomutt
patch-quasi-delete-neomutt
patch-sidebar-neomutt
patch-skip-quoted-neomutt
patch-smime-encrypt-self-neomutt
patch-status-color-neomutt
patch-timeout-neomutt
patch-tls-sni-neomutt

To learn more about NeoMutt, visit: http://www.neomutt.org/
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email at: 


-- System Information:

Bug#837733: openssh-server: debconf "openssh-server/permit-root-login" provides no way of specifiying "PermitRootLogin yes"

[Nye Liu]

Package: openssh-server
Version: 1:7.3p1-1
Severity: wishlist
Tags: d-i

Dear Maintainer,

It is well established that openssh-server/permit-root-login is a NOOP
(the result is always "PermitRootLogin prohibit-password"), but 
it would be nice to be able to specify "PermitRootLogin yes".

Yes, it is not recommended, but it is the only way to allow
logins to preseeded d-i autoinstalled hosts if adding a local user
automatically is disabled.

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

Kernel: Linux 4.6.3-x86_64-linode70 (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 openssh-server depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.58
ii  dpkg   1.18.10
ii  init-system-helpers1.42
ii  libaudit1  1:2.3.2-2
ii  libc6  2.24-1
ii  libcomerr2 1.42.12-1.1
ii  libgssapi-krb5-2   1.14.3+dfsg-1
ii  libkrb5-3  1.14.3+dfsg-1
ii  libpam-modules 1.1.8-3.2
ii  libpam-runtime 1.1.8-3.2
ii  libpam0g   1.1.8-3.2
ii  libselinux12.3-2
ii  libssl1.0.21.0.2h-1
ii  libsystemd0229-6
ii  libwrap0   7.6.q-24
ii  lsb-base   4.1+Debian12
ii  openssh-client 1:7.3p1-1
ii  openssh-sftp-server1:7.3p1-1
ii  procps 1:3.3.8-2
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages openssh-server recommends:
ii  libpam-systemd  229-6
ii  ncurses-term5.9+20130608-1
ii  xauth   1:1.0.7-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
pn  ssh-askpass   
pn  ufw   

-- Configuration Files:
/etc/pam.d/sshd changed [not included]

-- debconf information excluded

Bug#837732: ifupdown: ifup & ifdown crash if multiple interfaces are listed in no-scripts

[Michael Hudson-Doyle]

Package: ifupdown
Version: 0.8.10ubuntu1
Severity: important
Tags: patch

Dear Maintainer,

This was reported in Ubuntu as
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1618726 but is present
in sid too.

Quoting from that report:


This is a trivially reproducible crash in ifup/ifdown, with a patch attached.

Steps to reproduce:
1) echo no-scripts foo bar >> /etc/network/interfaces
2) ifup baz

Expected results:
Unknown interface baz

Actual results:
Segmentation fault (core dumped)

It's irrelevant whether the second interface is on the same no-scripts line or 
separate one. This will crash just the same:
echo no-scripts foo >> /etc/network/interfaces
echo no-scripts bar >> /etc/network/interfaces


I'm attaching a patch based on the one the reporting user provided.

Cheers,
mwh


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (400, 'xenial-proposed'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ifupdown depends on:
ii  adduser  3.113+nmu3ubuntu4
ii  init-system-helpers  1.29ubuntu2
ii  iproute2 4.3.0-1ubuntu3
ii  libc62.23-0ubuntu3
ii  lsb-base 9.20160110ubuntu0.2

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.3-5ubuntu12.1

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-1+2ubuntu1
pn  rdnssd  

-- no debconf information
>From 74c10be956dc95d7368345445a21e1b8066ab537 Mon Sep 17 00:00:00 2001
From: Richard Laager 
Date: Wed, 14 Sep 2016 11:51:29 +1200
Subject: [PATCH] Fix a crash when multiple interfaces are specified for
 no-scripts.

---
 config.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.c b/config.c
index c14f625..bfade0f 100644
--- a/config.c
+++ b/config.c
@@ -395,7 +395,7 @@ static void add_to_list(char ***list, int *count, const char *item) {
 		perror("realloc");
 		exit(1);
 	}
-	*list[*count - 1] = strdup(item);
+	(*list)[*count - 1] = strdup(item);
 	if (!(*list)[*count - 1]) {
 		perror("strdup");
 		exit(1);
-- 
2.7.4

Bug#795976: reopening 795976

[Jelmer Vernooij]

On Fri, Sep 09, 2016 at 12:04:09PM +0300, Dmitry Shachnev wrote:
> Hi Jelmer,
> 
> On Sun, May 15, 2016 at 06:29:21PM +, Jelmer Vernooij wrote:
> > reopen 795976
> > thanks
> 
> Should this bug be still open?
> 
> Sphinx build should be reproducible. It FTBFS on reproducible-builds.org
> because of some problem with WebKit, but that is an unrelated issue, and
> I have disabled the tests in the current packaging Git.

Feel free to close it again; I don't see my comment explaining why I reopened 
it at the time. :-/

Jelmer

Bug#837731: ITP: otf2 -- Open Trace Format 2

[Andreas Beckmann]

Package: wnpp
Severity: wishlist
Owner: Andreas Beckmann 
Control: block 789050 with -1

* Package name: otf2
  Version : 2.0
  Upstream Author : 
Copyright (c) 2009-2012, RWTH Aachen University, Germany
Copyright (c) 2009-2012, Gesellschaft fuer numerische Simulation mbH
 Braunschweig, Germany
Copyright (c) 2009-2014, Technische Universitaet Dresden, Germany
Copyright (c) 2009-2012, University of Oregon, Eugene, USA
Copyright (c) 2009-2014, Forschungszentrum Juelich GmbH, Germany
Copyright (c) 2009-2014, German Research School for Simulation Sciences 
GmbH,
 Juelich/Aachen, Germany
Copyright (c) 2009-2013, Technische Universitaet Muenchen, Germany
All rights reserved.
* URL : http://www.vi-hps.org/projects/score-p/
* License : BSD-3-Clause
  Programming Lang: (C, C++)
  Description : Open Trace Format 2

OTF2 is a standard trace format used by several high-performance tools,
which supports multiple streams.


OTF2 is the successor to the Open Trace Format (OTF), which is
packaged as src:otf


I need OTF2 as a dependency for packaging Score-P.


Andreas

Bug#837412: transition: liblouis

[Samuel Thibault]

Hello,

Emilio Pozuelo Monfort, on Wed 14 Sep 2016 00:42:45 +0200, wrote:
> On 11/09/16 13:55, Samuel Thibault wrote:
> > liblouis 3.0.0 bumped ABI and thus soname, there are only two packages
> > that need a rebuild: liblouixml and liblouisutdml,

> Go ahead.

liblouis 3.0.0-3 is now in sid, binNMUs can be scheduled with
--extra-depends "liblouis-dev (>= 3.0.0)"

Thanks,
Samuel

Bug#837730: postgresql: Debian should package pglogical

[cloos]

Package: postgresql-9.5
Version: 9.5.4-1
Severity: wishlist
File: postgres

pglogical  provides
very useful replication capabilities lacking from pg and does so in an
arguably better way than packages like slony.

Also, its capabilities are likely to get upstreamed over the next few
pg releases.

Compiling it locally works, but required re-compilation every time
debian's postgresql package updates, so it is vastly better if debian
packages it and recompiles it whenever postgresql itself is compiled.

It should be a very straightforward addition.

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

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

Versions of packages postgresql-9.5 depends on:
ii  libc6  2.24-2
ii  libgssapi-krb5-2   1.14.3+dfsg-2
ii  libldap-2.4-2  2.4.42+dfsg-2+b2
ii  libpam0g   1.1.8-3.3
ii  libpq5 9.6~rc1-1
ii  libssl1.0.21.0.2h-1
ii  libxml22.9.4+dfsg1-2
ii  locales2.24-2
ii  postgresql-client-9.5  9.5.4-1
ii  postgresql-common  175
ii  ssl-cert   1.0.38
ii  tzdata 2016f-1

Versions of packages postgresql-9.5 recommends:
ii  postgresql-contrib-9.5  9.5.4-1
ii  sysstat 11.3.5-1

Versions of packages postgresql-9.5 suggests:
pn  locales-all  

-- no debconf information

Bug#837729: ITP: cube -- generic tool for displaying a multi-dimensional performance space

[Andreas Beckmann]

Package: wnpp
Severity: wishlist
Owner: Andreas Beckmann 
Control: block 789050 with -1

* Package name: cube
  Version : 4.3.4
  Upstream Author : Forschungszentrum Juelich GmbH, Germany
German Research School for Simulation Sciences GmbH,
Juelich/Aachen, Germany
* URL : http://www.scalasca.org/software/cube-4.x/download.html
* License : BSD-3-Clause
  Programming Lang: (C, C++)
  Description : generic tool for displaying a multi-dimensional performance 
space

 Cube, which is used as performance report explorer for Scalasca and
 Score-P, is a generic tool for displaying a multi-dimensional
 performance space consisting of the dimensions (i) performance metric,
 (ii) call path, and (iii) system resource. Each dimension can be
 represented as a tree, where non-leaf nodes of the tree can be
 collapsed or expanded to achieve the desired level of granularity. In
 addition, Cube can display multi-dimensional Cartesian process
 topologies.

 The Cube 4.x series report explorer and the associated Cube4 data
 format is provided for Cube files produced with the Score-P performance
 instrumentation and measurement infrastructure or the Scalasca version
 2.x trace analyzer (and other compatible tools). However, for backwards
 compatibility, Cube 4.x can also read and display Cube 3.x data. 


I need Cube as a dependency for packaging Score-P.


Andreas

Bug#837123: [anna] segfault in wheezy installer

[Vincent McIntyre]

On Tue, Sep 13, 2016 at 11:03:19PM +0200, Aurelien Jarno wrote:

...

> > If all of that makes no difference, what would be the next step?
> 
> What would be interesting would be to try to reproduce the issue in
> qemu or virtualbox, with as many things as possible close to your
> system.
> 

Just to clarify - you mean try to run the installer using a qemu VM
as the target for installation? I can certainly try that.

More details.
The target system is pxe booted and next-server takes it to a (debian)
system running tftpd-hpa. The defaults.cfg has lots of boot targets
but the one I have been testing with is the netboot image, in manual
install mode. The only boot options it is given are 
 'append vga=normal initrd=yadayada'
It also falls over if I feed it a preseed file, where we use
 'append auto=true priority=critical vga=normal initrd=yadayda 
  url=blahdeblah'

> Also you might want to use the console (alt+f2) to run wget by hand and
> see if the issue happen with all hosts or only some of them.

I tried to wget pages from a few web sites from the alt+f2 console.
It segfaulted every time when I used a DNS name in the URL,
but worked if I used an IP address in the URL.
ping does the same thing; segfaults only when using domain names.

If I put an entry in /etc/hosts and try to access that hostname,
wget and ping also segfault, until I add this line to nsswitch.conf:

  hosts: files dns

Then they both work for that hostname.
The only other nsswitch.conf lines are for passwd, group & shadow.

> > My concern is there's a segfault still lurking in the stretch
> > version. If we can squash it here that fix could be forward-ported.
> 
> This is very unlikely, as both debian-installer and glibc are quite
> different in stretch and do not use the shared library reduction
> anymore.

Ok that's good to know.

Bug#837727: gnome-shell-extension-top-icon-plus: Not installable with gnome-shell >= 3.21.92

[Michael Biebl]

Control: reassign gnome-shell-extension-top-icons-plus 15-2


On Wed, 14 Sep 2016 01:20:14 +0200 bi...@debian.org wrote:
> Source: gnome-shell-extension-top-icon-plus
> Version: 15-2
> Severity: serious
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: gnome-shell-3-22
> 
> Hi,
> 
> your package gnome-shell-extension-top-icon-plus declares a strictly
> versioned dependency on gnome-shell. We've uploaded gnome-shell
> 3.21.92 to unstable, which makes gnome-shell-extension-top-icon-plus
> uninstallable.
> 
> In the past, it was necessary to explicitly declare supported
> gnome-shell versions in metadata.json. This was lifted in gnome-shell
> 3.21.92 [1].
> 
> "Nowadays, the user interface has mostly stabilized with most changes
> happening under the hood. As a result, extensions written for
> previous versions of GNOME Shell are very much expected to keep
> working on updates, if it wasn't for the version check that requires
> a version bump in the extension metadata. There has been a setting to
> disable that check for a while, but it's existence isn't widely known
> (hence the common perception that "everything breaks on updates").
> While there is still some risk that an out-of-date extension can be
> enabled without error, but fails spectacularly later (where we cannot
> catch the exception), it is reasonably small by now when compared to
> the ~95% of extensions that can be "unbroken", so swap the default
> value to disable version checks by default."
> 
> As a result, you could drop the gnome-shell << XXX version limitation
> altogether. The Debian release cycle is pretty long though, so we
> don't know yet if the gnome-shell version in Buster will actually be
> compatible with your extension today. We will release Stretch with
> GNOME Shell 3.22, so my recommendation would be to use gnome-shell
> (<< 3.23) as upper limt.
> 
> Modifications for metadata.json are no longer required.
> 
> Regards, Michael
> 
> [1] https://git.gnome.org/browse/gnome-shell/commit/?id=5e0e3e


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



signature.asc
Description: OpenPGP digital signature

Bug#837728: RM: heimdal/1.7~git20150920+dfsg-4

[Jelmer Vernooij]

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

Please remove the heimdal source package from testing. As maintainers,
we believe that Heimdal is not in a good enough state to be included in
a stable release.

There is still some activity in the upstream Git master branch. However:

* The last regular release (1.5) was in 2011, last RC was in 2012
* No security releases since Jan 2012, despite various recent security
  releases for MIT Kerberos since and occasional security releases while Heimdal
  was active
* There is no noticeable QA happening upstream. Tests fail on 32 bit,
  regressions have been introduced.
* Nobody upstream is interested in release management; we have asked
  about this on the development list multiple times.

I have filed bugs against the packages that depend on Heimdal to
either switch to building against Heimdal OR MIT or to drop their
Heimdal dependencies altogether.

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

Kernel: Linux 4.7.0-1-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#837593: gnome-shell-extension-redshift: Not compatible with gnome-shell 3.21.x/3.22

[Michael Biebl]

There are some recent updates:

In the past, it was necessary to explicitly declare supported
gnome-shell versions in metadata.json. This was lifted in gnome-shell
3.21.92 [1].

"Nowadays, the user interface has mostly stabilized with most changes
happening under the hood. As a result, extensions written for
previous versions of GNOME Shell are very much expected to keep
working on updates, if it wasn't for the version check that requires
a version bump in the extension metadata. There has been a setting to
disable that check for a while, but it's existence isn't widely known
(hence the common perception that "everything breaks on updates").
While there is still some risk that an out-of-date extension can be
enabled without error, but fails spectacularly later (where we cannot
catch the exception), it is reasonably small by now when compared to
the ~95% of extensions that can be "unbroken", so swap the default
value to disable version checks by default."

As a result, you could drop the gnome-shell << XXX version limitation
altogether. The Debian release cycle is pretty long though, so we
don't know yet if the gnome-shell version in Buster will actually be
compatible with your extension today. We will release Stretch with
GNOME Shell 3.22, so my recommendation would be to use gnome-shell
(<< 3.23) as upper limt.

Modifications for metadata.json are no longer required.

Regards, Michael

[1] https://git.gnome.org/browse/gnome-shell/commit/?id=5e0e3e

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



signature.asc
Description: OpenPGP digital signature

Bug#837594: gnome-shell-extension-autohidetopbar: Not compatible with gnome-shell 3.21.x/3.22

[Michael Biebl]

There are some recent updates:

In the past, it was necessary to explicitly declare supported
gnome-shell versions in metadata.json. This was lifted in gnome-shell
3.21.92 [1].

"Nowadays, the user interface has mostly stabilized with most changes
happening under the hood. As a result, extensions written for
previous versions of GNOME Shell are very much expected to keep
working on updates, if it wasn't for the version check that requires
a version bump in the extension metadata. There has been a setting to
disable that check for a while, but it's existence isn't widely known
(hence the common perception that "everything breaks on updates").
While there is still some risk that an out-of-date extension can be
enabled without error, but fails spectacularly later (where we cannot
catch the exception), it is reasonably small by now when compared to
the ~95% of extensions that can be "unbroken", so swap the default
value to disable version checks by default."

As a result, you could drop the gnome-shell << XXX version limitation
altogether. The Debian release cycle is pretty long though, so we
don't know yet if the gnome-shell version in Buster will actually be
compatible with your extension today. We will release Stretch with
GNOME Shell 3.22, so my recommendation would be to use gnome-shell
(<< 3.23) as upper limt.

Modifications for metadata.json are no longer required.

Regards, Michael

[1] https://git.gnome.org/browse/gnome-shell/commit/?id=5e0e3e

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

Bug#837592: gnome-shell-extension-suspend-button: Not compatible with gnome-shell 3.21.x/3.22

[Michael Biebl]

There are some recent updates:

In the past, it was necessary to explicitly declare supported
gnome-shell versions in metadata.json. This was lifted in gnome-shell
3.21.92 [1].

"Nowadays, the user interface has mostly stabilized with most changes
happening under the hood. As a result, extensions written for
previous versions of GNOME Shell are very much expected to keep
working on updates, if it wasn't for the version check that requires
a version bump in the extension metadata. There has been a setting to
disable that check for a while, but it's existence isn't widely known
(hence the common perception that "everything breaks on updates").
While there is still some risk that an out-of-date extension can be
enabled without error, but fails spectacularly later (where we cannot
catch the exception), it is reasonably small by now when compared to
the ~95% of extensions that can be "unbroken", so swap the default
value to disable version checks by default."

As a result, you could drop the gnome-shell << XXX version limitation
altogether. The Debian release cycle is pretty long though, so we
don't know yet if the gnome-shell version in Buster will actually be
compatible with your extension today. We will release Stretch with
GNOME Shell 3.22, so my recommendation would be to use gnome-shell
(<< 3.23) as upper limt.

Modifications for metadata.json are no longer required.

Regards, Michael

[1] https://git.gnome.org/browse/gnome-shell/commit/?id=5e0e3e


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



signature.asc
Description: OpenPGP digital signature

Bug#837595: gnome-shell-pomodoro: Not compatible with gnome-shell 3.21.x/3.22

[Michael Biebl]

There are some recent updates:

In the past, it was necessary to explicitly declare supported
gnome-shell versions in metadata.json. This was lifted in gnome-shell
3.21.92 [1].

"Nowadays, the user interface has mostly stabilized with most changes
happening under the hood. As a result, extensions written for
previous versions of GNOME Shell are very much expected to keep
working on updates, if it wasn't for the version check that requires
a version bump in the extension metadata. There has been a setting to
disable that check for a while, but it's existence isn't widely known
(hence the common perception that "everything breaks on updates").
While there is still some risk that an out-of-date extension can be
enabled without error, but fails spectacularly later (where we cannot
catch the exception), it is reasonably small by now when compared to
the ~95% of extensions that can be "unbroken", so swap the default
value to disable version checks by default."

As a result, you could drop the gnome-shell << XXX version limitation
altogether. The Debian release cycle is pretty long though, so we
don't know yet if the gnome-shell version in Buster will actually be
compatible with your extension today. We will release Stretch with
GNOME Shell 3.22, so my recommendation would be to use gnome-shell
(<< 3.23) as upper limt.

Modifications for metadata.json are no longer required.

Regards, Michael

[1] https://git.gnome.org/browse/gnome-shell/commit/?id=5e0e3e
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Bug#837691: ITP: node-cropper -- A simple jQuery image cropping plugin

[Pirate Praveen]

On 2016, സെപ്റ്റംബർ 13 11:41:44 PM IST, Antonio Terceiro  
wrote:
 instead of node-*

This is a npm module. But anyway it needs gulp packaged or mimicking its 
functionality to generate libjs-*. Hence I have stopped working on it.

Bug#831509: [pkg-cryptsetup-devel] Bug#831509: cryptsetup fails to unlock volumes with accented letters passwords

[Guilhem Moulin]

Hi Andre,

On Sat, 16 Jul 2016 at 15:02:40 -0300, Andre wrote:
> During the installation process of setting up my operating system, I
> chose as the default keyboard layout the Portuguese (Brazilian), then
> set up the encryption of disk volumes and then set an encryption
> password using accented characters.

FWIW, this what the cryptsetup(8) manpage says about this:

Character encoding: If you enter a passphrase with special symbols,
the passphrase can change depending character encoding.  Keyboard
settings can also change, which can make blind input hard or
impossible.  For example, switching from some ASCII 8-bit variant to
UTF-8 can lead to a different binary encoding and hence different
passphrase seen by cryptsetup, even if what you see on the terminal
is exactly the same.  It is therefore highly recommended to select
passphrase characters only from 7-bit ASCII, as the encoding for
7-bit ASCII stays the same for all ASCII variants and UTF-8.

Perhaps we should make the installer print a warning if the user enters
non 7-bit ASCII characters?

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#837542: mate-power-manager: segfault (infinite recursion) after changing brightness with brightness keys

[Maarten Aertsen]

Package: mate-power-manager
Version: 1.14.0-2
Followup-For: Bug #837542

Dear Maintainer,

I can reproduce this bug on this Dell XPS 13 9343 as described by
Samuel. I'm available to provide additional information if required.

best regards, Maarten

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

Kernel: Linux 4.6.0-1-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)

Versions of packages mate-power-manager depends on:
ii  dbus-x111.10.10-1
ii  libatk1.0-0 2.21.90-2
ii  libc6   2.23-5
ii  libcairo-gobject2   1.14.6-1+b1
ii  libcairo2   1.14.6-1+b1
ii  libcanberra-gtk3-0  0.30-3
ii  libcanberra00.30-3
ii  libdbus-1-3 1.10.10-1
ii  libdbus-glib-1-20.106-1
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.49.6-1
ii  libgnome-keyring0   3.12.0-1+b1
ii  libgtk-3-0  3.21.5-3
ii  libmate-desktop-2-171.14.1-1
ii  libmate-panel-applet-4-11.14.2-1
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.40.2-1
ii  libpangocairo-1.0-0 1.40.2-1
ii  libstartup-notification00.12-4
ii  libunique-3.0-0 3.0.2-2
ii  libupower-glib3 0.99.4-3
ii  libx11-62:1.6.3-1
ii  libxext62:1.3.3-1
ii  libxrandr2  2:1.5.0-1
ii  libxrender1 1:0.9.9-2
ii  mate-notification-daemon [notification-daemon]  1.14.1-1
ii  mate-power-manager-common   1.14.0-2
ii  notification-daemon 3.20.0-1
ii  policykit-1 0.105-16
ii  systemd 231-4
ii  upower  0.99.4-3

mate-power-manager recommends no packages.

Versions of packages mate-power-manager suggests:
ii  mate-polkit  1.14.0-1

-- no debconf information

Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org

[Don Armstrong]

Control: affects -1 reportbug

On Tue, 13 Sep 2016, Holger Levsen wrote:
> On Tue, Sep 13, 2016 at 03:24:49PM -0700, Don Armstrong wrote:
> > Package: bugs.debian.org
> 
> I think this is the wrong package and should rather be handled by
> reportbug…

bugs.debian.org controls whether pseudopackage exist at all; reportbug
is responsible for what reportbug outputs as possible pseudopackages.

> > Does anyone have a strong objection to this?
>  
> I think I have a strong opinion on it, but not a strong objection ;p
> 
> also as said already: src:general has some useful bugs, which we cant really
> sensibly reassign.

That's true. There are some bugs which affect lots of packages, but
don't really belong to a single one of them. general is as good a place
as any to coordinate those bugs.

Maybe just changing this text:

   Please enter the name of the package in which you have found a
   problem, or type 'other' to report a more general problem. If you
   don't know what package the bug is in, please contact
   debian-u...@lists.debian.org for assistance.

To something like:

   Please enter the name of the package in which you have found a
   problem, If you don't know what package the bug is in, please contact
   debian-u...@lists.debian.org for assistance. Type 'other' to report a
   problem in a pseudopackage.

would help address this problem?

-- 
Don Armstrong  https://www.donarmstrong.com

They say when you embark on a journey
of revenge
dig two graves.
They underestimate me.
 -- a softer world #560
http://www.asofterworld.com/index.php?id=560

Bug#837724: libsasl2-modules-gssapi-heimdal: removal of heimdal from testing

[Jelmer Vernooij]

Package: libsasl2-modules-gssapi-heimdal
Severity: normal

FYI: Because of the state of upstream Heimdal, the Heimdal packagers are in
the process of requesting the removal of Heimdal from testing. Please
consider dropping the libsasl2-modules-gssapi-heimdal package.

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

Kernel: Linux 4.7.0-1-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#827195: evince plugin won't open postscript

[Jason Crain]

On Wed, Sep 14, 2016 at 12:17:47AM +0200, Leon Meier wrote:
> A file which cannot be opened is, e.g.,
> http://www.math.chalmers.se/~palbin/rickard.ps
> 
> The browser hangs for a few minutes, then the blank tab is displayed.
> 
> In fact, no postscript file can be opened from the browser.

Firefox apparently does not implement whatever GTK3 support the plugin
needs.  I might need to poke a couple upstream bug reports so that the
plugin at least shows an error message instead of freezing.

It does work reasonably well in epiphany browser.

Bug#837579: user-mode-linux: FTBFS with bindnow and PIE enabled

[Balint Reczey]

Control: tags -1 patch

Hi Ritesh,

On 09/12/2016 08:18 PM, Ritesh Raj Sarraf wrote:
> Control: tag -1 +help
> 
> 
> Hello Balint,
> 
> 
> On Mon, 2016-09-12 at 16:42 +0200, Balint Reczey wrote:
>> During a rebuild of all packages in sid, your package failed to build on
>> amd64 with patched GCC and dpkg.
> 
>> The rebuild tested if packages are ready for a transition
>> enabling PIE and bindnow for amd64.
> 
> 
> I have tried enabling hardening flags before but that never helped. And I did
> not look very deep into it.
> 
> hardening=+all also modifies LDFLAGS which breaks the UML kernel build.
> 
> So today, I tried with just the below, but lintian still complains.
> 
> rrs@chutzpah:~/Community/Packaging/user-mode-linux (master)$ git diff
> diff --git a/debian/rules b/debian/rules
> index e29da82..802eb1e 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -15,6 +15,10 @@ tmpmodules:=$(debian)/uml-modules
>  DEB_HOST_ARCH?=$(shell dpkg-architecture -qDEB_HOST_ARCH)
>  #SUBARCH?=$(shell uname -m)
>  
> +export DEB_BUILD_MAINT_OPTIONS = hardening=+pie,+bindnow
> +#DPKG_EXPORT_BUILDFLAGS = 1
> +#include /usr/share/dpkg/buildflags.mk
> +
>  ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
>  KBUILDVARS := CFLAGS_KERNEL=-O1
>  endif
> 
> 
> If you have any suggestions on working around it, please do share on this bug
> report.
> 
> 
>> For more information about the changes to sid's dpkg and GCC please
>> visit:
>>  https://wiki.debian.org/Hardening/PIEByDefaultTransition
> 
>> Relevant part (hopefully):
>> ...
>>   LD  init/built-in.o
>> /usr/bin/ld: arch/um/drivers/built-in.o: relocation R_X86_64_32 against
>> `.rodata.str1.1' can not be used when making a shared object; recompile
>> with -fPIC
>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>> ...
> 
> I've tagged this bug report as "help".

The following patch fixes the build for me with the changed GCC and also
builds fine with the original GCC 6:

@@ -16,9 +16,11 @@
 #SUBARCH?=$(shell uname -m)

 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
-KBUILDVARS := CFLAGS_KERNEL=-O1
+CFLAGS_KERNEL += -O1
 endif

+KBUILDVARS := CFLAGS_KERNEL="$(CFLAGS_KERNEL)" CC="$(CC) -no-pie"
LD="$(LD) -no-pie"
+
 # development only targets
 #
 copy-config:


> 
> BTW, do you know if the regular linux images of Debian are Hardening enabled ?

If you mean PIE, no, but there are some hardening options enabled AFAIK
thus I can't answer that question briefly.

Cheers,
Balint





signature.asc
Description: OpenPGP digital signature

Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org

[Holger Levsen]

On Tue, Sep 13, 2016 at 03:24:49PM -0700, Don Armstrong wrote:
> Package: bugs.debian.org

I think this is the wrong package and should rather be handled by
reportbug…

> Does anyone have a strong objection to this?
 
I think I have a strong opinion on it, but not a strong objection ;p

also as said already: src:general has some useful bugs, which we cant really
sensibly reassign.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#837469: nmu: dose3_5.0.1-1

[Emilio Pozuelo Monfort]

Hi,

On 11/09/16 22:04, Johannes Schauer wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu dose3_5.0.1-1 . ANY . unstable . -m "rebuild for camlzip 1.06-1"

Can you explain why this is needed? We don't like to blindly binNMU stuff, so a
little explanation is always helpful.

Cheers,
Emilio

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

[GCS]

Hi Bob, Niko,

On Tue, Sep 13, 2016 at 11:15 PM, Bob Friesenhahn
 wrote:
> On Tue, 13 Sep 2016, László Böszörményi wrote:
>> On Tue, Sep 13, 2016 at 10:42 PM, Niko Tyni  wrote:
>>> This package is failing to build on ppc64el, but built successfully
>>> in the past.
>> This is known and working with upstream to find the root cause.
> A backtrace from a core dump is needed.
 I'm not that good with gdb, but as a first shot this may give you more idea.
-- cut --
Core was generated by `/usr/bin/perl t/zlib/write.t '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000bffc8 in ?? ()
[...]
(gdb) thread apply all bt

Thread 1 (Thread 0x3fffb7ff65b0 (LWP 3923)):
#0  0x000bffc8 in ?? ()
#1  0x000bffcb in ?? ()
#2  0x3fffb796b320 in InitializeLogInfo () at magick/log.c:301
#3  0x3fffb796c62c in InitializeMagick (path=0x3fffb7bf0708
"Graphics::Magick") at magick/magick.c:1117
#4  0x3fffb7bf0074 in boot_Graphics__Magick (my_perl=0x10210010,
cv=) at Magick.xs:2064
#5  0x100e1960 in Perl_pp_entersub (my_perl=0x10210010) at pp_hot.c:3272
#6  0x100d8d88 in Perl_runops_standard (my_perl=0x10210010) at run.c:41
#7  0x10046f18 in Perl_call_sv (my_perl=0x10210010,
sv=0x1023ab78, flags=13) at perl.c:2779
#8  0x10049c3c in Perl_call_list (my_perl=0x10210010,
oldscope=, paramList=0x10213248) at perl.c:4995
#9  0x1001e3e0 in S_process_special_blocks
(my_perl=0x10210010, floor=39, fullname=0x1023c100 "BEGIN",
gv=0x1023a980, cv=0x1023ab78) at op.c:8916
#10 0x1003e028 in Perl_newATTRSUB_x (my_perl=0x10210010,
floor=39, o=, proto=, attrs=,
block=, o_is_gv=false) at op.c:8845
#11 0x100422b0 in Perl_utilize (my_perl=0x10210010,
aver=, floor=, version=,
idop=,
arg=) at op.c:6069
#12 0x1007f784 in Perl_yyparse (my_perl=0x10210010,
gramtype=) at perly.y:351
#13 0x1004ee1c in S_parse_body (xsinit=0x1001d490 ,
env=0x0, my_perl=0x10210010) at perl.c:2306
#14 perl_parse (my_perl=0x10210010, xsinit=0x1001d490 ,
argc=, argv=, env=0x0) at perl.c:1626
#15 0x1001d178 in main (argc=, argv=, env=) at perlmain.c:114
-- cut --

As Perl debug and libc6 debug symbols installed, I don't know which
library / executable may contain points #0 and #1. Maybe log.c itself?
At least the mentioned line in #2 is:
LockSemaphoreInfo(log_semaphore);

> There were no functions added or removed between 1.3.24 and 1.3.25 and not
> interfaces were changed.  If 1.3.24 still builds on the build machine, then
> it is possible to test by replacing individual source files in 1.3.25 with
> files from 1.3.24 and seeing when the problem goes away.  Since all tests
> are failing, the problematic code would need to be used in initialization,
> or somehow always encountered. Perhaps magick/utility.c would be a good
> starting point.
 Yes, 1.3.24 builds fine in the same environment. As previously noted
the broken change happened before 08th of August and it's not the
MAGICK_CACHE_LINE_SIZE value.

Cheers,
Laszlo/GCS

Bug#837412: transition: liblouis

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 11/09/16 13:55, Samuel Thibault wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> liblouis 3.0.0 bumped ABI and thus soname, there are only two packages
> that need a rebuild: liblouixml and liblouisutdml, both of which rebuild
> fine with liblouis 3.0.0.  I have already uploaded it to experimental,
> it builds fine on all archs (I just had to do it by hand on a porterbox
> for mipsel, because the experimental apt resolver (apt-cudf) on the
> mipsel buildds seems to be broken and aba didn't answer about it yet, it
> will not be a problem in sid anyway)

Go ahead.

Cheers,
Emilio

Bug#837199: transition: armadillo

[Emilio Pozuelo Monfort]

On 13/09/16 20:12, Sebastiaan Couwenberg wrote:
> On 09/13/2016 07:51 PM, Emilio Pozuelo Monfort wrote:
>> On 10/09/16 11:35, Sebastiaan Couwenberg wrote:
>>> On 09/10/2016 02:11 AM, Kumar Appaiah wrote:
 armadillo has already been uploaded to unstable. While the reverse
 dependencies should build with a binNMU, I have not tested them and
 will test it in the next couple of days.
>>>
>>> Because gdal needs to be rebuilt for the armadillo transition to unblock
>>> the vtk6 rebuild for the openmpi transition, I've also done a round of
>>> rebuilds to assess the impact.
>>>
>>> Fortunately the number of reverse dependencies for armadillo is limited,
>>> and all packages rebuilt successfully:
>>>
>>>  gdal (2.1.1+dfsg-4) OK
>>>  gnss-sdr (0.0.8-1)  OK
>>>  mlpack   (2.0.2-1)  OK
>>>  seer (1.1.1-2)  OK
>>>
>>>  pktools  (2.6.7-2)  OK
>>>
>>> I'd like to have gdal (2.1.1+dfsg-4) migrate to testing to get the two
>>> RC bugfixes into stretch, before binNMUs for the armadillo rdeps are
>>> scheduled.
>>
>> I scheduled everything but gdal. Let's see if gdal migrates tonight once 
>> perl is
>> old enough.
> 
> Thanks for waiting with the gdal binNMU, I appreciate that a lot.
> 
> I really hope having perl migrate will be sufficient, the gdal situation
> in testing has caused several RC bugs and a thread on -devel :-(

It just went in. I have now nmu'ed it for the armadillo transition.

Cheers,
Emilio

Bug#762311: task-laptop: drop acpi package recommendation?

[Bob Bib]

Any opinion from the maintainers?..

--
Best wishes,
Bob

Bug#814558: libglib2.0-0-dbg: GDB backtrace decoration broken

[vrishab in]

Steps to reproduce:

1. Open gedit.
2. kill -11 $(pgrep gedit)
3. gdb /usr/bin/gedit gedit.core.file
4. 'bt' in gdb

Bug#814558: libglib2.0-0-dbg: GDB backtrace decoration broken

[vrishab in]

This happens in i386 only. Not in amd64.

bugs@sid-reportbug:/cores$ uname -a
Linux sid-reportbug 4.7.0-1-686-pae #1 SMP Debian 4.7.2-1 (2016-08-28) i686
GNU/Linux

bugs@sid-reportbug:/cores$ gdb /usr/bin/rhythmbox /cores/core.rhythmbox.2444
GNU gdb (Debian 7.11.1-2) 7.11.1
..
..
Reading symbols from /usr/bin/rhythmbox...Reading symbols from
/usr/lib/debug/.build-id/dd/26a5bd23cb7bb34ba548b8f6f6e94b2a124109.debug...done.
done.
[New LWP 2444]
[New LWP 2445]
[New LWP 2446]
[New LWP 2448]
[New LWP 2466]
[New LWP 2625]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
btCore was generated by `rhythmbox'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb775dd5d in ?? ()
[Current thread is 1 (Thread 0xb2f8b500 (LWP 2444))]
(gdb) bt
Python Exception  
returned a result with an error set:
#0  0x in #1  0x in  ()
(gdb) q

Bug#833477: chromium: Chromecast device not found after update to 52.

[Bob Smith]

On Mon, 12 Sep 2016 12:27:27 +0200 Anthony Callegaro  wrote:
> Hey Michael,
> 
> I just tested with the latest Chromium 53.0.2785.92-3 in unstable and
> the result is the same.
> 
> Downgrading back to 51.0.2704.79-1 I can see our offices Nexus Player again.
> 
> Let me know what options I should enable to help troubleshooting this.
> 
> Cheers
> LeTic

Fix:
1. chrome://flags/
2. Default -> Disabled
Media Router Mac, Windows, Linux, Chrome OS
Enables Chrome to access external presentation-type displays and use them for 
presenting web content. #media-router
3. Casting will now work so long as you have the official extension installed

The built-in casting seems to block google's extension.  Only solution so far 
is to disable the new built-in casting.  As far as I know, the built-in 
streaming will never work with Chromium.  Linux users are now forced to Chrome 
or Chromium+disabled built-in casting+extension.

Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org

[Don Armstrong]

Package: bugs.debian.org
Severity: minor
Control: affects -1 general


On Tue, 13 Sep 2016, Russ Allbery wrote:
> Holger Levsen  writes:
> > I'd close this bug again, but I gave up on caring about bugs in the
> > "general" pseudo package…
> 
> Should we just disable the general pseudo-package? Is it serving a
> sufficient useful purpose to warrant the constant (if somewhat slow)
> stream of misdirected bug reports?

I personally don't have a problem with disabling it or turning it into
an auto responder which tells the submitter to communicate with
debian-user or another mailing list to figure out the appropriate
package and/or pseudopackage.

Does anyone have a strong objection to this?

-- 
Don Armstrong  https://www.donarmstrong.com

"A one-question geek test. If you get the joke, you're a geek: Seen on
a California license plate on a VW Beetle: 'FEATURE'..."
 -- Joshua D. Wachs - Natural Intelligence, Inc.

Bug#827953: maxima: Uses too much memory to build

[Camm Maguire]

Greetings, and thanks so much!

It appears that all is working as intended, that gc is triggered and
keeping the active heap to about 2.8Gb (or 3.9Gb with relocatable copy
area) of a detected max of 5.3Gb (see core pages, and physical memory).
At the end of this experiment, the rss of this process as viewed from a
separate shell should confirm these figures.  So I do not think gcl is
expanding into swap here.

As for the /proc/meminfo, all I can say is that the build employs many
other programs as well.  Might be interesting to correlate this figure
with the various stages of the build.  In other words, how much just to
run the debian/rules build target, etc.

Santiago Vila  writes:

> On Mon, 25 Jul 2016, Camm Maguire wrote:
>
>> If this is happening, then it is indeed a bug.  The intent is to use
>> physical ram only by default unless the application itself insists on
>> more.  Going into swap by default obviously defeats the performance goal
>> of expanding the memory anyway.  You can look into this by
>> 
>> gcl
>> >(room t)
>> 
>> and
>> 
>> maxima
>> (..) :lisp (room t)
>> (..) :lisp (setq si::*notify-gbc* t)
>> (..) run_testsuite();
>> (..) :lisp (room t)
>> 
>> If you can post the results for this on the 4/4 machine you describe
>> above I can see if we have a problem.
>
> Sorry for the late reply.
>
> I attach the results for maxima, on a machine with 6GB RAM and 4GB swap.
>
> I don't know how to interpret the results. In addition to the test you
> requested, when I do this
>
> grep "Committed_AS:" /proc/meminfo
>
> I get this before running maxima:
>
> Committed_AS: 254276 kB
>
> and this after the test finished, before exiting maxima:
>
> Committed_AS:6878284 kB
>
> I guess this does still not explain why Committed_AS: grows so much
> when I'm actually trying to build the Debian package.
>
> Thanks.
>
> (sid)buildd@skywalker1:~$ maxima
>
> Maxima 5.38.0 http://maxima.sourceforge.net
> using Lisp GNU Common Lisp (GCL) GCL 2.6.12
> Distributed under the GNU Public License. See the file COPYING.
> Dedicated to the memory of William Schelter.
> The function bug_report() provides bug reporting information.
> (%i1) (%i1) :lisp (room t)
> 
> 1828/182888.8% CONS FIXNUM SHORT-FLOAT LONG-FLOAT 
> BIT-VECTOR PATHNAME SPICE
>  220/220 99.8% ARRAY CHARACTER PACKAGE HASH-TABLE VECTOR 
> RANDOM-STATE CCLOSURE CLOSURE
>   67/67  56.7% STRING BIGNUM RATIO COMPLEX
>  399/399 98.8% STRUCTURE
>1/1   65.2% STREAM
>   46/46  99.4% CFUN CFDATA
>  592/592 99.8% SFUN SYMBOL READTABLE GFUN VFUN AFUN
>
> 6400/6400  contiguous (30 blocks)
>  1173337   hole
>  216/216 99.9% relocatable
>
>   3153 pages for cells
>
>   9769 total pages in core
>   9769 current core maximum pages
>216 pages reserved for gc
>3519614 pages available for adding to core
>  35556 pages reserved for core exhaustion
>
>3565155 maximum pages
>
>
> Key:
>
> WS: words per struct
> UP: allocated pages
> MP: maximum pages
> FI: fraction of cells in use on allocated pages
> GC: number of gc triggers allocating this type
>
> word size:64 bits
> page size:4096 bytes
> heap start:   0xE81000
> heap max :0x368365000
> shared library start: 0x0
> cstack start: 0x0
> cstack mark offset:   0 bytes
> cstack direction: downward
> cstack alignment: 32 bytes
> cstack max:   16001 bytes
> immfix start: 0x8000
> immfix size:  4611686018427387904 fixnums
> physical memory:  1299534 pages
> (%i1) (%i1) :lisp (setq si::*notify-gbc* t)
> 
> T
> (%i1) (%i1) run_testsuite();
> Running tests in rtest_rules: 103/103 tests passed
> Running tests in rtestnset: 597/597 tests passed
> Running tests in rtest1: 180/180 tests passed (not counting 1 expected errors)
> Running tests in rtest1a: 27/27 tests passed
> Running tests in rtest2: 144/144 tests passed (not counting 2 expected errors)
> Running tests in rtest4: 93/93 tests passed
> Running tests in rtest5: 
> ** Problem 78 ***
> Input:
> describe(sin)
>
>
> Result:
>
> error-catch
>
> This differed from the expected result:
> true
> start address -T 0x28ee010 start address -T 0x291e650 start address -T 
> 0x2925ce0 start address -T 0x292a1a0 start address -T 0x292e660 start address 
> -T 0x2936f20 start address -T 0x293c010 start address -T 0x293fb70 
> 79/80 tests passed
>
> The following 1 problem failed: (78)
> Running tests in rtest6: 39/39 tests passed
> Running tests in rtest6a: 62/62 tests passed
> Running tests in rtest6b: 16/16 tests passed
> Running tests in rtest7: 85/85 tests passed
> Running tests in rtest9: 89/89 tests passed
> Running tests in rtest9a: 76/76 tests passed
> Running tests in rtest10: 62/62 tests passed 

Bug#837722: vim: Debian sid vim8 should compile with Python2 support

[Xiaoge Su]

Package: vim
Version: 2:8.0.0003-1
Severity: normal

Dear Maintainer,

It seems with the most recent vim8.0 package, the support of Python2 is not 
enabled
when compiling. This makes several vim plugins I am using broken, including 
power-
line and YouCompleteMe. It is strange to see that Python2 support is dropped.

- Xiaoge

-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.gtk3
/usr/bin/vim is /usr/bin/vim.gtk3
/usr/bin/gvim is /usr/bin/vim.gtk3

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

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

Versions of packages vim depends on:
ii  libacl1  2.2.52-3
ii  libc62.24-2
ii  libgpm2  1.20.4-6.2
ii  libselinux1  2.5-3
ii  libtinfo56.0+20160625-1
ii  vim-common   2:8.0.0003-1
ii  vim-runtime  2:8.0.0003-1

vim recommends no packages.

Versions of packages vim suggests:
ii  exuberant-ctags [ctags]  1:5.9~svn20110310-11
pn  vim-doc  
pn  vim-scripts  

-- no debconf information

Bug#827195: evince plugin won't open postscript

[Leon Meier]

found browser-plugin-evince/3.21.4-1
thanks

The used version of firefox-esr is 45.3.0esr-1~deb8u1

A file which cannot be opened is, e.g.,
http://www.math.chalmers.se/~palbin/rickard.ps

The browser hangs for a few minutes, then the blank tab is displayed.

In fact, no postscript file can be opened from the browser.

Bug#837693: remmina: random segfaults

[Jörg Frings-Fürst]

Hello Marco,

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

The status of the package is at the moment unsubstantial:

 * Release 1.1.2 does not support by upstream and
 * Release 1.2.0 has a lot of bugs and is unusable.


I take a look at your bug this week.


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#835840: Bug#835841, #835840

[Jörg Frings-Fürst]

Hello Giovanni,

First many thanks for your explanations.

Am Mittwoch, den 07.09.2016, 13:22 +0200 schrieb Giovanni Panozzo:
> Remmina 1.2.0 is working quite well.
> 
Quite well? I see just now 271 open issues[1]. 
.  
> We have more than 5000 happy users on the Ubuntu's 'remmina-next'
> PPA, 
> with remmina version 1.2.0~rcgit-15.
> https://launchpad.net/~remmina-ppa-team/+archive/ubuntu/remmina-next
> 
5000? And how much unhappy user? From where you have the counter?

> Unfortunately
> 
> - Remmina 1.2.0 depends on FreeRDP 2.0, which is not currently
> released 
> and not in official in Debian. It also will shortly depend on libssh 
> 0.7, which is not in Debian 8.
> 

FreeRDP with 647 open issues[2]? Not released and so much bugs does not
conform to Debian standards of quality and stability. 


> - We currently provide only binaries for remmina 1.2.X for Ubuntu
> via 
> the "remmina-next" PPA. In fedora you can find remmina 1.2.X in
> COPR, 
> and in Arch remmina 1.2.X is in AUR, which are maintained by their 
> official fedora and arch remmina package maintainers.
> 
> We, the remmina project team, have no current plan and time to
> release 
> our remmina 1.2.X .deb packages for Debian, including the
> dependencies 
> freerdp 2.0 and libssh 0.7.
> 
I have time, but not interested.

> If someone can help in building and maintaining some kind of
> external 
> .deb unofficial remmina repository for debian, he is welcome.
> 
> See also https://github.com/FreeRDP/Remmina/issues/977
> 
> Also please read the discussion here:
> https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/1619094
> 

I'm not the maintainer of Remmina at Ubuntu. I Ubuntu want to get the
version from your ppa into there release then they must done the work.
I
waiting with the work for a stable release.


> For more info on Remmina: https://github.com/FreeRDP/Remmina/wiki
> 


Conclusion: 

Remmina 1.1.x is 
 * currently not maintained by upstream.
 * in a heavy bug status

Remmina 1.2.x 
 * depends on not released packages
 * has to much bugs.

Both versions are IMHO not in a status to get a release candidate for
the next Debian stable release.


CU
Jörg


[1] https://github.com/FreeRDP/Remmina/issues
[2] https://github.com/FreeRDP/FreeRDP/issues

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


smime.p7s
Description: S/MIME cryptographic signature

Bug#819448: Is this fixed by new version?

[Tomasz Rybak]

Hello.
I've just uploaded new version of PyOpenCL to unstable.
Can you check whether this issue is still present with new version?

Thanks in advance.

-- 
Tomasz Rybak, Debian Maintainer 
GPG: A481 824E 7DD3 9C0E C40A  488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak

Bug#837721: screenfetch: Screenfetch assumes CPU freq is be an interger.

[screenfetch assumes interger value for CPU frequency]

Package: screenfetch
Version: 3.6.5-1
Severity: normal

Dear Maintainer,

   * What led up to the situation? Running the command screenfetch without any 
options
   * What exactly did you do (or not do) that was effective (or
 ineffective)? This happens whenever the script calls for CPU info.
   * What was the outcome of this action? "[[ ! ]] /usr/bin/screenfetch: line 
817: [: 2415.7: integer expression expected"
   * What outcome did you expect instead? No error.

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

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

screenfetch depends on no packages.

Versions of packages screenfetch recommends:
ii  scrot  0.8-13

screenfetch suggests no packages.

-- no debconf information

Bug#836592: jessie-pu: package gdcm/2.4.4-3

[Adam D. Barratt]

On Sun, 2016-09-11 at 20:41 +0200, Julien Cristau wrote:
> On Fri, Sep  9, 2016 at 17:33:08 +0100, Adam D. Barratt wrote:
> 
> > On Fri, 2016-09-09 at 17:08 +0200, Gert Wollny wrote:
[...]
> > > At the beginning of the build log one can even see that the library is 
> > > correctly detected in the JRE ppc64el sub-directory, but later it wants 
> > > ppc64 only and I can't find the according code in the gdcm VTK java 
> > > module definition.
> > 
> > I was wondering if this might be a similar issue to javatool's #833572
> > (now fixed in p-u), but I don't know either gdcm or Java packaging in
> > general well enough to immediately point to a solution I'm afraid.
> > 
> After apt-get build-dep gdcm:
> 
> (jessie_ppc64el-dchroot)jcristau@plummer:~$ rgrep ppc64/libjawt /usr/lib/
> /usr/lib/vtk-5.8/VTKTargets-release.cmake:  
> IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE 
> "vtkGraphics;vtkFilteringJava;/usr/lib/jvm/default-java/jre/lib/ppc64/libjawt.so"
> /usr/lib/vtk-5.8/VTKTargets-release.cmake:  
> IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE 
> "vtkRendering;vtkGraphicsJava;vtkImagingJava;/usr/lib/jvm/default-java/jre/lib/ppc64/libjawt.so"
> /usr/lib/vtk-5.8/VTKTargets-release.cmake:  
> IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE 
> "vtkCharts;vtkViewsJava;/usr/lib/jvm/default-java/jre/lib/ppc64/libjawt.so"
> /usr/lib/vtk-5.8/VTKConfig-Java.cmake:SET(VTK_JAVA_AWT_LIBRARY 
> "/usr/lib/jvm/default-java/jre/lib/ppc64/libjawt.so")

A test build of vtk on a porter box results in the correct paths, so
I've scheduled a binNMU. Then we can try rebuilding gdcm against that.

Regards,

Adam

Bug#800634: [Pkg-opencl-devel] OpenCL architectures

[Tomasz Rybak]

On Mon, 2016-07-04 at 10:16 +0200, Tomasz Rybak wrote:
> This is repost - I've sent this mail last week, but it seems to
> disappear.
> 
> There is bug against PyOpenCL to build it for more architectures (in
> CC):
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800634
> 

Thanks for all the comments.
It tooks some time but I resumed work on PyOpenCL package
and uploaded new version with many architectures to experimental.
Please test it.

BTW - I also intend to upload PyCUDA with armhf to experimental,
but need to work on cross-compilation of it.

Best regards.

-- 
Tomasz Rybak, Debian Maintainer 
GPG: A481 824E 7DD3 9C0E C40A  488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak

Bug#827936: [Po4a-devel] Bug#827936: po4a: please implement support for Ruby document format

[Francesco Poli]

On Tue, 13 Sep 2016 00:52:12 +0200 Martin Quinson wrote:

> > Are you willing to convert my tests to a proper test integrated in po4a
> > test infrastructure?
> > I really hope you are, since I am not knowledgeable enough to do so by
> > myself...
> 
> Yes I am.

That's wonderful news! Thank you so much!

> But that's 10 years since the last time I added something
> into the t/ directory, so I have to check again. Times are really
> packed right now for me, so po4a will have to way a few days/weeks.
[...]

No need to apologize or explain personal commitments: waiting some
days or weeks is more than acceptable!  :-)
It's just that I hadn't heard back from you and I needed confirmation
that you were willing to work on this aspect...

Thanks again for your helpfulness!


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


pgpQns9oERbPq.pgp
Description: PGP signature

Bug#837720: override: gnupg1:utils/extra

[Daniel Kahn Gillmor]

Package: ftp.debian.org
Severity: normal

ftp.debian.org has an override for binary packages that are build from
the gnupg1 source package:

  gpgv1: Override says utils - important, .deb says utils - extra
gnupg1-curl: Override says utils - optional, .deb says utils - extra

the source package is correct, they should both be extra.  gnupg1 is
headed for legacy status, supporting people with unusual requirements,
and definitely nothing that should be close to the core of the
operating system.

Please drop the overrides from ftp.debian.org for this package,
thanks!

--dkg

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

[Bob Friesenhahn]

On Tue, 13 Sep 2016, László Böszörményi wrote:


On Tue, Sep 13, 2016 at 10:42 PM, Niko Tyni  wrote:

This package is failing to build on ppc64el, but built successfully
in the past. As seen at
 https://buildd.debian.org/status/logs.php?pkg=graphicsmagick=ppc64el
it regressed with 1.3.24+hg20160808-1, and the version currently in
sid is still failing. It looks like this is preventing migration to testing.

This is known and working with upstream to find the root cause.


A backtrace from a core dump is needed.


The list of toolchain package versions in the build logs suggests that
the regression might be due to the switch to GCC 6.

Definitely not. A code change in GraphicsMagick triggers it. I could
tighten it down, but don't know the exact cause yet.


There were no functions added or removed between 1.3.24 and 1.3.25 and 
not interfaces were changed.  If 1.3.24 still builds on the build 
machine, then it is possible to test by replacing individual source 
files in 1.3.25 with files from 1.3.24 and seeing when the problem 
goes away.  Since all tests are failing, the problematic code would 
need to be used in initialization, or somehow always encountered. 
Perhaps magick/utility.c would be a good starting point.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Bug#834249: openbabel: FTBFS in testing

[gregor herrmann]

Control: tag -1 + patch

On Sat, 13 Aug 2016 20:05:36 +0200, Santiago Vila wrote:

> Package: openbabel
> Version: 2.3.2+dfsg-2.3
> Severity: serious
> 
> --
> /<>/openbabel-2.3.2+dfsg/src/alias.cpp: In static member
> function 'static bool OpenBabel::AliasData::LoadFile(O
> penBabel::AliasData::SmartsTable&)':
> /<>/openbabel-2.3.2+dfsg/src/alias.cpp:273:9: error:
> reference to 'shared_ptr' is ambiguous
>  shared_ptr psp(new OBSmartsPattern);
> ^~
> --

Also fails in sid.

Looks like a typical GCC6-induced error.
The build succeeds with -std=gnu++98. Patch attached.


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Rolling Stones: Sweetblack
diff -Nru openbabel-2.3.2+dfsg/debian/changelog openbabel-2.3.2+dfsg/debian/changelog
--- openbabel-2.3.2+dfsg/debian/changelog	2016-08-02 11:44:00.0 +0200
+++ openbabel-2.3.2+dfsg/debian/changelog	2016-09-13 22:58:23.0 +0200
@@ -1,3 +1,11 @@
+openbabel (2.3.2+dfsg-2.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "FTBFS in testing": build with -std=gnu++98.
+(Closes: #834249)
+
+ -- gregor herrmann   Tue, 13 Sep 2016 22:58:23 +0200
+
 openbabel (2.3.2+dfsg-2.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru openbabel-2.3.2+dfsg/debian/rules openbabel-2.3.2+dfsg/debian/rules
--- openbabel-2.3.2+dfsg/debian/rules	2014-09-20 14:29:56.0 +0200
+++ openbabel-2.3.2+dfsg/debian/rules	2016-09-13 22:58:23.0 +0200
@@ -11,6 +11,7 @@
 export CFLAGS   := $(shell dpkg-buildflags --get CFLAGS) $(CPPFLAGS)
 export CXXFLAGS := $(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS)
 export LDFLAGS  := $(shell dpkg-buildflags --get LDFLAGS)
+export DEB_CXXFLAGS_MAINT_APPEND = -std=gnu++98
 
 DH_AUTO_CONFIGURE_OPTS := -DCMAKE_BUILD_TYPE=None \
   -DPYTHON_BINDINGS=ON -DPERL_BINDINGS=ON \


signature.asc
Description: Digital Signature

Bug#837123: [anna] segfault in wheezy installer

[Aurelien Jarno]

On 2016-09-10 11:30, Vincent McIntyre wrote:
> On Fri, Sep 09, 2016 at 03:59:17PM +0200, Aurelien Jarno wrote:
> > 
> > I don't talk about the software running on your DNS servers, but
> > rather how they behave when they get queried. It might depends on
> > many other things, like if your network has IPv6 or not.
> > 
> > Note that's only one explanation, not sure it's the right one, but
> > given I am unable to reproduce the issue, it's the only one that
> > come to my mind.
> 
> Thank you for explaining. I am struggling with this idea since AFAIK
> the DNS servers have not been changed in the last six months or more
> so I can think of no reason for the behaviour to have changed.

Thanks for the details, that's an important information.

> That history is what makes me think something must have changed in
> the installer around the time of the last point release (May).
> But from what you say that isn't the case.

The installer did change, and has been built against a new libc which
includes changes to the resolver, fixing security issues. I am not aware
of any issue introduced by these patches (this libc is used on regular
systems, not only in debian-installer), except #816669 which involves
IPv6 and has different symptoms.

> You've given me a few things to try out
>  - tell DHCP to supply different DNS servers (running bind)
>  - make sure all ipv6 related options are disabled
>and no ipv6 DNS entries exist for the target host
>  - make sure all ipv6 related options are enabled
>and valid ipv6 DNS entries exist for the target host
> 
> Also I can try installing oldstable with the jessie installer.
>  
> If all of that makes no difference, what would be the next step?

What would be interesting would be to try to reproduce the issue in
qemu or virtualbox, with as many things as possible close to your
system.

Also you might want to use the console (alt+f2) to run wget by hand and
see if the issue happen with all hosts or only some of them.

> I assume I'd have to build a debug version of the installer
> and try to get a backtrace?

I don't know if it's really something doable, especially the wheezy
installer use a shared library reduction system to strip some symbols 
from the shared libraries.

> My concern is there's a segfault still lurking in the stretch
> version. If we can squash it here that fix could be forward-ported.

This is very unlikely, as both debian-installer and glibc are quite
different in stretch and do not use the shared library reduction
anymore.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#837656: icedove: apparmor still blocking local movemail

[Carsten Schoenert]

tags 837656 pending
thanks

On Tue, Sep 13, 2016 at 03:16:13PM +0200, Carsten Schoenert wrote:
> > 1: 
> > https://git.launchpad.net/apparmor-profiles/commit/?id=f8ed397c22306dc89559bcb83dfc760400f76543
> 
> Really appreciated, I will do so, thanks!

Adopted and commited.
https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git/commit/?id=7a1ec746bb0bc66778ebefae961384273fbb22cf

Regards
Carsten

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

[GCS]

On Tue, Sep 13, 2016 at 10:42 PM, Niko Tyni  wrote:
> This package is failing to build on ppc64el, but built successfully
> in the past. As seen at
>  https://buildd.debian.org/status/logs.php?pkg=graphicsmagick=ppc64el
> it regressed with 1.3.24+hg20160808-1, and the version currently in
> sid is still failing. It looks like this is preventing migration to testing.
 This is known and working with upstream to find the root cause.

> The list of toolchain package versions in the build logs suggests that
> the regression might be due to the switch to GCC 6.
 Definitely not. A code change in GraphicsMagick triggers it. I could
tighten it down, but don't know the exact cause yet.

Regards,
Laszlo/GCS

Bug#836566: Fix committed for #836566 and probably #836566

[Jens Reyer]

control: tag -1 + pending

On 13.09.2016 21:18, Jens Reyer wrote:
> jreyer-guest pushed a commit to branch master
> in repository wine.
> 
> commit 8103285d2870713930df7004a2afa292902461af
> Author: Jens Reyer 
> Date:   Tue Sep 13 21:17:02 2016 +0200
> 
> Generate the correct SERVER_PROTOCOL_VERSION.
> 
> Closes: #836911
> Closes in stable: #836566
> 
> SERVER_PROTOCOL_VERSION is used to check if the running server's
> and the client's version match. It is set in
> include/wine/server_protocol.h (currently 515), and increased by
> 1 by make_requests. But we clean server_protocol.h because it is
> generated, so SERVER_PROTOCOL_VERSION in Debian is always 1.
> 
> To fix this retrieve SERVER_PROTOCOL_VERSION on upstream import
> before server_protocol.h is cleaned, and store it (decreased by
> 1) in request.patch. make_request will then regenerate
> server_protocol.h with the correct SERVER_PROTOCOL_VERSION.

I'm quite sure #836566 (src:wine-development) will be fixed by this.

For #836566 (src:wine) I only assume so. If I'm right the issue in
src:wine will be fixed by the new wine-development, because version
mismatches will then be detected like this:

$ wine --version
wine-1.8.4 (Debian 1.8.4-1)
$ wine-development --version
wine-1.9.18 (Debian 1.9.18-2~local1)
$ winecfg &
$ winecfg-development
wine client error:0: version mismatch 1/515.
Your wineserver binary was not upgraded correctly,
or you have an older one somewhere in your PATH.
Or maybe the wrong wineserver is still running?

However Erik's answer in
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836566#20
might indicate that I'm on the wrong trail here. Unfortunately I got no
answer for my followup question yet.

Better ways to solve this are welcome.

jre

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

[Niko Tyni]

Package: graphicsmagick
Version: 1.3.25-1
Severity: serious

This package is failing to build on ppc64el, but built successfully
in the past. As seen at
 https://buildd.debian.org/status/logs.php?pkg=graphicsmagick=ppc64el
it regressed with 1.3.24+hg20160808-1, and the version currently in
sid is still failing. It looks like this is preventing migration to testing.

The list of toolchain package versions in the build logs suggests that
the regression might be due to the switch to GCC 6.

The build log shows segfaults or something like that in PerlMagick/ .

  PERL_DL_NONLAZY=1 PERL_USE_UNSAFE_INC=1 "/usr/bin/perl" 
"-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef 
*Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" t/*.t 
t/bzlib/*.t t/jbig/*.t t/jng/*.t t/jpeg/*.t t/png/*.t t/ps/*.t t/tiff/*.t 
t/ttf/*.t t/wmf/*.t t/x/*.t t/xfig/*.t t/zlib/*.t
  t/blob.t .. 
  1..1
  Failed 1/1 subtests 
  t/bzlib/read.t  
  1..2
  Failed 2/2 subtests 
  [...]
  Test Summary Report
  ---
  t/blob.t(Wstat: 11 Tests: 0 Failed: 0)
Non-zero wait status: 11
Parse errors: Bad plan.  You planned 1 tests but ran 0.
  [...]
  Files=32, Tests=0,  1 wallclock secs ( 0.08 usr  0.04 sys +  0.56 cusr  0.17 
csys =  0.85 CPU)
  Result: FAIL
  Failed 32/32 test programs. 0/0 subtests failed.
  Makefile:993: recipe for target 'test_dynamic' failed
  make[5]: *** [test_dynamic] Error 255
  
-- 
Niko Tyni   nt...@debian.org 

Bug#835325: O: gnarwl

[Bernhard Schmidt]

Control: owner -1 !
Control: retitle -1 ITA: gnarwl -- Email autoresponder based on LDAP

On Wed, Aug 24, 2016 at 02:52:49PM +0200, Alessandro De Zorzi wrote:
> Package: wnpp
> Severity: normal
> 
> 
> Gnarwl upstream author not relase new version from some years.
> 
> Due to lack interest, I orphan gnarwl.

Unfortunately I'm in a position where I will need gnarwl on Debian for a
few more years to come (and I'm running a local version with a fix for
#703369 anyway).

I intend to adopt this package and import the only known fixes from
https://github.com/fln/gnarwl . I queried on the postfix ml a couple of
months back whether someone knew any other development happening and got
no response.

Bernhard


signature.asc
Description: Digital signature

Bug#834597: kgb-bot: FTBFS in testing

[Adrian Bunk]

On Thu, Aug 18, 2016 at 06:22:54PM +0200, gregor herrmann wrote:
>...
> Hm, I guess we should think about a release?

Yes, it would be good if you could make a release.

> Cheers,
> gregor

Thanks
Adrian

-- 

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

Bug#837718: perl-doc: "perldoc -f rmdir" recommends legacy File::Path::rmtree instead of File::Path::remove_tree

[Daniel Kahn Gillmor]

Package: perl-doc
Version: 5.22.2-3
Severity: minor

perldoc should be consistent about the interfaces it recommends.
File::Path suggests that remove_tree is preferred and rmtree is
legacy.  "perldoc -f rmdir" suggests that rmtree is preferred.

0 dkg@alice:~/tmp$ perldoc -f rmdir | cat
rmdir FILENAME
rmdir   Deletes the directory specified by FILENAME if that directory is
empty. If it succeeds it returns true; otherwise it returns
false and sets $! (errno). If FILENAME is omitted, uses $_.

To remove a directory tree recursively ("rm -rf" on Unix) look
at the "rmtree" function of the File::Path module.

0 dkg@alice:~/tmp$ perldoc File::Path | head -n31
NAME
File::Path - Create or remove directory trees

VERSION
This document describes version 2.09 of File::Path, released 2013-01-17.

SYNOPSIS
  use File::Path qw(make_path remove_tree);

  make_path('foo/bar/baz', '/zug/zwang');
  make_path('foo/bar/baz', '/zug/zwang', {
  verbose => 1,
  mode => 0711,
  });

  remove_tree('foo/bar/baz', '/zug/zwang');
  remove_tree('foo/bar/baz', '/zug/zwang', {
  verbose => 1,
  error  => \my $err_list,
  });

  # legacy (interface promoted before v2.00)
  mkpath('/foo/bar/baz');
  mkpath('/foo/bar/baz', 1, 0711);
  mkpath(['/foo/bar/baz', 'blurfl/quux'], 1, 0711);
  rmtree('foo/bar/baz', 1, 1);
  rmtree(['foo/bar/baz', 'blurfl/quux'], 1, 1);

  # legacy (interface promoted before v2.06)
  mkpath('foo/bar/baz', '/zug/zwang', { verbose => 1, mode => 0711 });
  rmtree('foo/bar/baz', '/zug/zwang', { verbose => 1, mode => 0711 });
0 dkg@alice:~/tmp$ 

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

Kernel: Linux 4.7.0-rc7-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 perl-doc depends on:
ii  perl  5.22.2-3

perl-doc recommends no packages.

Versions of packages perl-doc suggests:
ii  groff-base1.22.3-8
ii  man-db [man-browser]  2.7.5-1

-- no debconf information

Bug#837138: Pending fixes for bugs in the libnet-easytcp-perl package

[pkg-perl-maintainers]

tag 837138 + pending
thanks

Some bugs in the libnet-easytcp-perl package are closed in revision
a5e265f0ded84a91a251275fbc91ca96f1b220ad in branch 'master' by Niko
Tyni

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libnet-easytcp-perl.git/commit/?id=a5e265f

Commit message:

Fix and declare autopkgtest support

The distribution is called EasyTCP but the module inside is Net::EasyTCP.

Closes: #837138

Bug#837673: mutt: PGP prompt message is confusing on de_DE.UTF-8 locale

[Antonio Radici]

Control: tag -1 +pending

On Tue, Sep 13, 2016 at 03:11:25PM +0300, Dmitry Shachnev wrote:
> I believe this regression was introduced in version 1.7.0-2. In previous
> versions, the message was in English, and keys matching English names worked
> fine. I.e. I was able to use (p)-(c) sequence to disable signing.

The root cause is the switch to gpgme, the messages are not properly translated
there so it defaults to English. I'm working on a fix.

Bug#837717: debian-maintainers: Annual ping for Guilhem Moulin

[Guilhem Moulin]

Package: debian-maintainers
Severity: normal

Hi there,

This is my annual ping.  I'm still active in Debian, so please keep my
key in the DM keyring.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#837716: removal of heimdal from testing

[Jelmer Vernooij]

Package: libpam-heimdal
Severity: normal

Dear maintainer,

FYI: Because of the state of upstream heimdal, the Heimdal maintainers are in 
the
process of having Heimdal removed from stretch. Please consider dropping the
libpam-heimdal package.

For details, see the RC bugs reported against the Heimdal source package.

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

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

Bug#837547: pristine-tar commit fails if tarball contains German umlauts

[Carsten Schoenert]

On Tue, Sep 13, 2016 at 07:41:09PM +0200, Tomasz Buchert wrote:
 
> pristine-tar changes the locale to "C" almost immediately. The comment reads:
> "Force locale to C since tar may output utf-8 filenames differently depending 
> on the locale."
> So it doesn't seem that changing locales will help here.

Otherwise I would be a little bit scared. ;)

> I tried again and it works perfectly to me. What about your filesystem?

Hmm, that's all normal ext4 systems. I also tried a yet on a Jessie
system, but excately the same error.
And I wont believe it's a filesystem error, that's quite impossible that
the issue is related to the file system on all three machines.

> I tried with the older version (1.33) and on a different machine, and
> it still works. We need somebody else to reproduce it for us.

Yes, I've done the same down to 1.33 on the jessie/testing system. All
the same here. The error is all the same.

So now I was using option -k to see if there is something abnormal. And
yes, the manifest file has already that broken naming.

carsten@stretch:/tmp  $ grep -rw "303" */manifest
pristine-tar.fbAnsJPkxo/manifest:libraries/Shielding_Cabinets.pretty/W\303\274rth_36503505_50x50mm.kicad_mod
pristine-tar.fbAnsJPkxo/manifest:libraries/Shielding_Cabinets.pretty/W\303\274rth_36103605_60x60mm.kicad_mod
pristine-tar.fbAnsJPkxo/manifest:libraries/Shielding_Cabinets.pretty/W\303\274rth_36103505_50x50mm.kicad_mod
pristine-tar.fbAnsJPkxo/manifest:libraries/Shielding_Cabinets.pretty/W\303\274rth_36103205_20x20mm.kicad_mod
pristine-tar.fbAnsJPkxo/manifest:libraries/Shielding_Cabinets.pretty/W\303\274rth_36503205_20x20mm.kicad_mod
pristine-tar.fbAnsJPkxo/manifest:libraries/Shielding_Cabinets.pretty/W\303\274rth_36503255_25x25mm.kicad_mod
pristine-tar.fbAnsJPkxo/manifest:libraries/Shielding_Cabinets.pretty/W\303\274rth_36103255_25x25mm.kicad_mod
pristine-tar.fbAnsJPkxo/manifest:libraries/Shielding_Cabinets.pretty/W\303\274rth_36503305_30x30mm.kicad_mod
pristine-tar.fbAnsJPkxo/manifest:libraries/Shielding_Cabinets.pretty/W\303\274rth_36503605_60x60mm.kicad_mod
pristine-tar.fbAnsJPkxo/manifest:libraries/Shielding_Cabinets.pretty/W\303\274rth_36103305_30x30mm.kicad_mod

I don't how this manifest file is created but there is probably
something working not well.

If I try to follow the command while working with verbose or debuging
messages this part is not vissible.

Regards
Carsten

Bug#809847: ipcalc doesn't support IPv6

[Antoine Beaupré]

Package: ipcalc
Version: 0.41-4
Followup-For: Bug #809847

Considering how unmaintained the perl-based ipcalc is, wouldn't it
make sense to update to the C version which has more features?

thanks for considering this!

a.

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (1, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages ipcalc depends on:
ii  perl  5.20.2-3+deb8u6

ipcalc recommends no packages.

ipcalc suggests no packages.

-- no debconf information

Bug#837715: Debain installer fails on Gigabyte MP30-AR1 (ARM64 X-Gene1)

[Phil Endecott]

Package: debian-installer

I've been asked to file this bug to track my attempts to install 
Debian on my MP30-AR1.  This is an ARM64 board with an X-Gene 1 
processor.  Please see this mailing list thread for more details:

  https://lists.debian.org/debian-arm/2016/09/msg00022.html

In summary, this board is virtually identical to the MP30-AR0 
except that it is supplied with UEFI, not U-Boot, in its boot 
flash.  Apparently there are various known issues that prevent 
the Debian installer from running, including bugs in the 
device tree and lack of ACPI support in the Debian kernel.  
On the other hand, both the CentOS and Ubuntu installers run 
and install working systems.

The other distributions' installers that do work are:
  http://mirror.centos.org/altarch/7.2.1603/isos/aarch64/
  
http://ports.ubuntu.com/ubuntu-ports/dists/yakkety/main/installer-arm64/current/images/netboot/
 (dated 2016-08-28 01:23)

Neither is running a particularly new kernel (4.2 and 4.4 respectively) 
so either they've backported required fixes or the problems are in the 
configuration (or conceivably GRUB, I suppose.)  The Ubuntu kernel 
seems to use device tree while the CentOS one uses ACPI.

The Debian installer fails as follows:

EFI stub: Booting Linux Kernel...
ConvertPages: Incompatible memory types
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
OSBootEvent = Success
L3c Cache: 8MB
[ 0.00] Booting Linux on physical CPU 0x0
[ 0.00] Linux version 4.6.0-1-arm64 (debian-ker...@lists.debian.org) (gcc 
version 5.4.0 20160609 (Debian 5.4.0-4) ) #1 SMP Debian 4.6.2-2 (2016-06-25)
[ 0.00] Boot CPU: AArch64 Processor [500f0001]
[ 0.00] earlycon: uart8250 at MMIO32 0x1c02 (options '')
[ 0.00] bootconsole [uart8250] enabled
[ 0.00] efi: Getting EFI parameters from FDT:
[ 0.00] EFI v2.40 by American Megatrends
[ 0.00] efi: ACPI 2.0=0x807ff43000 ESRT=0x807e161e18 SMBIOS 3.0=0x807e161c18
[ 0.00] Moving initrd from [4079b0f000-407ac457c3] to [7e0ac9000-7e1bff7c3]
[ 0.00] Unhandled fault: synchronous external abort (0x9610) at 
0xffbffe63e078
[ 0.00] Internal error: : 9610 [#1] SMP
[ 0.00] Modules linked in:
[ 0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0-1-arm64 #1 Debian 
4.6.2-2
[ 0.00] Hardware name: Gigabyte X-Gene MP30-AR0 board (DT)
[ 0.00] task: ff8008b88800 ti: ff8008b78000 task.ti: 
ff8008b78000
[ 0.00] PC is at __memcpy+0x100/0x180
[ 0.00] LR is at copy_from_early_mem+0x6c/0x94


Cheers,  Phil.

Bug#837714: libarchive: CVE-2016-5418: Archive Entry with type 1 (hardlink), but has a non-zero data size file overwrite

[Salvatore Bonaccorso]

Source: libarchive
Version: 3.2.1-2
Severity: grave
Tags: security upstream patch

Hi,

the following vulnerability was published for libarchive.

CVE-2016-5418[0]:
|Archive Entry with type 1 (hardlink), but has a non-zero data size
|file overwrite

This corresponds to [1] and [2], which is upstream as [3].

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-5418
[1] 
https://git.centos.org/blob/rpms!libarchive.git/9952851f8b327a8c93d26a5873c190c1fb09ae6c/SOURCES!libarchive-3.1.2-CVE-2016-5418.patch;jsessionid=1dexz8h9qdewibih5aonbu3
[2] 
https://git.centos.org/blob/rpms!libarchive.git/9952851f8b327a8c93d26a5873c190c1fb09ae6c/SOURCES!libarchive-3.1.2-CVE-2016-5418-variation.patch;jsessionid=1dexz8h9qdewibih5aonbu3
[3] 
https://github.com/libarchive/libarchive/commit/dfd6b54ce33960e420fb206d8872fb759b577ad9

Please adjust the affected versions in the BTS as needed. jessie
version has not been checked yet, but is probably similar affected.

Regards,
Salvatore

Bug#837713: liblockdep-dev should have liblockdep4.6 or whatever release as it depends

[shirish शिरीष]

Package: liblockdep-dev
Version: 4.6.4-1
Severity: normal

Dear Maintainer,
I just filed #837710 and realized it soon that the missing symlink
lives in liblockdep4.6 which is NOT a dependancy of liblockdep-dev .
It should either be depends or if not depends then at least in
recommends so that liblockdep4.6 or whatever version of liblockdep is,
gets pulled in and there is no need to file broken symlink bugs.

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

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

-- no debconf information

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

Bug#837609: RFS: budgie-desktop/10.2.7-1

[foss.freedom]

Hi Gianfranco,

  many thanks for reviewing this revised package.

(I'll make sure I use "plain text mode" for gmail from now on)

1. I've completely redone the copyright file - obviously alot of the
files Ikey has updated to 2016 (but not all) so this is reflected in
the new copyright + a couple of double copyrighters such as Josh Klar.

I ran licensecheck as well - where the files where marked as
"generated" and did not have a .vala equivalent I have not added these
to the copyright.  These are by-products of the make distcheck process
upstream uses.

2. I re-raised the generated files question here upstream:

https://github.com/solus-project/budgie-desktop/issues/588

"
I seem to remember we had this conversation before, getting deja vu
anyway :) That's how the Vala+autotools stuff works. The only way for
me to workaround it is to forcibly delete the stamps, which in turn
breaks distcheck. We don't use any conditionals in the Vala code for
exactly this reason, we know the .c files aren't being regenerated, so
the conditionals would never work (they don't make it to the .c..)

We could try to hack the .c's out it, but I think the time would be
best spent on rewriting to C for 10.3, as we need to fix all those odd
issues (like not being able to have proper relro plugins), then we can
just drop all the .vala anyway. I'd like to see what Debian makes of
that proposition, because I think we're all a bit sick of Vala in
Budgie Desktop by now anyway, right? :)"

3. I've added the libaccountservice-dev to the changelog.

I've also rerun check-all-the-things and this looks similar to the
results of budgie-desktop-10.2.6

Cheers

David

On 13 September 2016 at 10:57, Gianfranco Costamagna
 wrote:
> control: owner -1 !
> control: tags -1 moreinfo
>
> Hi,(please don't use html in mail, when possible)
>
>
>>budgie-desktop:
>
> 1) lots of missing copyrights, e.g.
> Copyright (C) 2015-2016 Solus Project
>
> Copyright 2014 Josh Klar  (original Budgie work, prior to 
> Budgie 10)
>
> 2) I see a lot of autogenerated files:
>
> "/* main.c generated by valac 0.32.1, the Vala compiler"
>
> are you sure you are rebuilding them in Debian builds?
>
> grep generated . -Ri |grep vala |grep -v "do not" |wc -l
> 57
>
> 3) added dependency not mentioned in changelog
> + libaccountsservice-dev,
>
> other stuff seems good
>
> G.

Bug#837710: liblockdep-dev: adequate reports broken symlink of liblockdep.so

[Ben Hutchings]

On Tue, 2016-09-13 at 19:18 +, shirish शिरीष wrote:
> Package: liblockdep-dev
> Version: 4.6.4-1
> Severity: normal
> Usertags: broken-symlink adequate
> User: debian...@lists.debian.org
> 
> Dear Maintainer,
> 
> Adequate reported broken symlink in liblockdep-dev
> 
> liblockdep-dev:amd64: broken-symlink
> /usr/lib/x86_64-linux-gnu/liblockdep.so -> liblockdep.so.4.6
> 
> I went to the relevant directory to see if this indeed was true and
> sure enough there isn't a liblockdep.so.4.6
> 
> > ┌─[shirish@debian] - [/usr/lib/x86_64-linux-gnu] - [10182]
> └─[$] ls -l liblockdep.*
> 
> -rw-r--r-- 1 root root 52902 Jul 19 01:27 liblockdep.a
> lrwxrwxrwx 1 root root17 Jul 19 01:27 liblockdep.so -> liblockdep.so.4.6

This package should depend on liblockdep4.6 which does contain that file.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


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

Bug#837712: xemacs21: FTBFS with bindnow and PIE enabled

[Balint Reczey]

Source: xemacs21
Version: 21.4.24-2
Severity: important
User: bal...@balintreczey.hu
Usertags: pie-bindnow-20160906
Justification: FTBFS on amd64 with extra hardening

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64 with patched GCC and dpkg.

The rebuild tested if packages are ready for a transition
enabling PIE and bindnow for amd64.

For more information about the changes to sid's dpkg and GCC please
visit:
 https://wiki.debian.org/Hardening/PIEByDefaultTransition

Relevant part (hopefully):
...
Loading /<>/lisp/loadhist.elc...
Loading /<>/lisp/loaddefs.elc...
Loading site-load...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name xemacs
Testing for Lisp shadows ...
GNUmakefile:103: recipe for target 'xemacs.dmp' failed
make[3]: *** [xemacs.dmp] Segmentation fault
make[3]: *** Deleting file 'xemacs.dmp'
...

The full build log is available from:
 
https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/with-pie-bindnow/xemacs21_21.4.24-2_unstable_pie-bindnow.log.gz

The patch used in Ubuntu disabling PIE probably fixes the problem.

Thanks,
Balint

Bug#837711: libmathlib2-dev: Please build libmathlib.a with -fPIC

[Balint Reczey]

Source: libmathlib2-dev
Version: 20061220+dfsg3-3
Severity: important
User: bal...@balintreczey.hu
Usertags: pie-bindnow-20160906
Justification: makes paw FTBFS with extra hardening
Affects: paw

Dear Maintainers,

During a rebuild of all packages in sid, paw
failed to build on amd64 with patched GCC and dpkg. The root
cause seems to be that libmathlib.a is shipped as a non-PIC library.

The rebuild tested if packages are ready for a transition
enabling PIE and bindnow for amd64 (and selected architectures).

For more information about the changes to sid's dpkg and GCC please
visit:
 https://wiki.debian.org/Hardening/PIEByDefaultTransition

Relevant part of paw's build log:
...
set -e ; \
[ -d /<>/shlib ] || exit 0 ; \
gfortran /<>/build/pawlib/paw/programs/0pamain.o \
`cernlib -G X11 pawlib` -Wl,-E -o
/<>/bin/pawX11.static;\
gfortran /<>/build/pawlib/paw/programs/0pamainm.o \
`cernlib -G Motif pawlib` -Wl,-E -o
/<>/bin/paw++.static
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libmathlib.a(besi064.o):
relocation R_X86_64_32S against `.rodata' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libmathlib.a(besj064.o):
relocation R_X86_64_32S against `.rodata.str1.8' can not be used when
making a shared object; recompile with -fPIC
...

The full build log is available from:
 
https://people.debian.org/~rbalint/build-logs/pie-bindnow-20160906/paw_2.14.04.dfsg.2-9_amd64.build.gz

Thanks,
Balint

Bug#821481: PHP 7.0 support

[Michael-John Turner]

Hi

FYI, there is an upstream bug report open for PHP 7.0 support:
https://jira.z-hub.io/projects/ZP/issues/ZP-804

Cheers, MJ
-- 
Michael-John Turner * m...@mjturner.net * http://mjturner.net/

Bug#837710: liblockdep-dev: adequate reports broken symlink of liblockdep.so

[shirish शिरीष]

Package: liblockdep-dev
Version: 4.6.4-1
Severity: normal
Usertags: broken-symlink adequate
User: debian...@lists.debian.org

Dear Maintainer,

Adequate reported broken symlink in liblockdep-dev

liblockdep-dev:amd64: broken-symlink
/usr/lib/x86_64-linux-gnu/liblockdep.so -> liblockdep.so.4.6

I went to the relevant directory to see if this indeed was true and
sure enough there isn't a liblockdep.so.4.6

┌─[shirish@debian] - [/usr/lib/x86_64-linux-gnu] - [10182]
└─[$] ls -l liblockdep.*

-rw-r--r-- 1 root root 52902 Jul 19 01:27 liblockdep.a
lrwxrwxrwx 1 root root17 Jul 19 01:27 liblockdep.so -> liblockdep.so.4.6

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

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

-- no debconf information


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

Bug#783266: New upstream release of d-push (2.3.1)

[Michael-John Turner]

Hi,

I see there's been another major release made (2.3, along with the first
patch release, 2.3.1). There are now unofficial packages available (see
[1]), which could provide a starting point for getting the latest version
into stretch. I'm not sure that 16 packages is ideal though!

If the maintainer of d-push no longer wants to maintain it, I'd gladly take
a look at packaging the latest release and getting the RC bugs resolved.
PHP 7.0 support may need to wait until a later patch of the 2.3.x branch
though, as I believe it's not yet available upstream.

[1] https://wiki.z-hub.io/display/ZP/Installation

Cheers, MJ
-- 
Michael-John Turner * m...@mjturner.net * http://mjturner.net/