Bug#878674: [Pkg-javascript-devel] Bug#878674: nodejs segfaults when building d3-* with webpack

[Pirate Praveen]

On ഞായര്‍ 15 ഒക്ടോബര്‍ 2017 11:39 വൈകു, Jérémy Lal wrote:
> Do you know if any dependency is a c++ addon ?

These are the direct dependencies,

Depends:
 ${misc:Depends}
 , nodejs
 , node-acorn (>= 5.0~)
 , node-acorn-dynamic-import (>= 2.0~)
 , node-ajv (>= 5.0~)
 , node-ajv-keywords (>= 2.0~)
 , node-async (>= 0.8~)
 , node-enhanced-resolve (>= 3.4~)
 , node-escope
 , node-interpret (>= 1.0~)
 , node-json-loader (>= 0.5.4~)
 , node-json5 (>= 0.5~)
 , node-loader-runner (>= 2.3~)
 , node-loader-utils (>= 0.2~)
 , node-memory-fs (>= 0.4.1~)
 , node-mkdirp (>= 0.5~)
 , node-libs-browser (>= 2.0~)
 , node-source-map (>= 0.5.3~)
 , node-supports-color (>= 4.2.1~)
 , node-tapable (>= 0.2.7~)
 , node-uglifyjs-webpack-plugin
 , node-watchpack (>= 1.3.1~)
 , node-webpack-sources (>= 1.0.1~)
 , node-yargs (>= 6.0~)
 , node-lodash-packages
 , node-lodash

I don't think any of them is a C++ addon, probably one of their
dependencies.



signature.asc
Description: OpenPGP digital signature

Bug#878706: isenkram: Packagekit transaction flags incorrect

[Petter Reinholdtsen]

[segfault]
> The packagekit transaction flags are currently used incorrectly. See the
> below patch which fixes this bug.

Thank you for the heads up.  I'll include the change.  Where can I read
more about how to use the packagekit.TransactionFlagEnum values?

-- 
Happy hacking
Petter Reinholdtsen

Bug#790158: Upstream comment

[James Cameron]

Upstream could bring python-rsvg source into the code base; would that
be okay?

Porting from python-rsvg to gir1.2-rsvg-2.0 would also require porting
to GTK+ 2 GObject introspection.  This would break compatibility with
downloaded Sugar activities.

-- 
James Cameron
http://quozl.netrek.org/

Bug#790156: v44 already moved from python-rsvg to gir1.2-rsvg-2.0

[James Cameron]

New upstream release v44 fixed this, and was packaged, with gir-deps
of rsvg-2.0, so next step is to remove the python-rsvg dependency in
debian/rules.

-- 
James Cameron
http://quozl.netrek.org/

Bug#878104: debugfs: out-of-bounds read in ext2fs_inode_csum_verify()

[Theodore Ts'o]

tags 878104 +pending
thanks

Thanks for reporting this bug.  I've checked the following bug fix
into the e2fsprogs tree.

- Ted

commit d1ccc6e58bf80d07c131f074f1222a67c82bc6af
Author: Theodore Ts'o 
Date:   Mon Oct 16 00:28:45 2017 -0400

libext2fs: fix potential memory access overrun in ext2fs_inode_csum()

If the superblock has a revision level of 0, then s_inode_size is
undefined, and the actual inode size is 128 bytes.  This is handled by
the EXT2_INODE_SIZE() helper macro.  If s_inode_size is maliciously
set to a large value, and the s_rev_level is 0, then this could result
in an illegal memory pointer dereference.

Addresses-Debian-Bug: #878104
Reported-by: Jakub Wilk 
Signed-off-by: Theodore Ts'o 

diff --git a/lib/ext2fs/csum.c b/lib/ext2fs/csum.c
index e67850fa4..093da04fe 100644
--- a/lib/ext2fs/csum.c
+++ b/lib/ext2fs/csum.c
@@ -632,7 +632,7 @@ static errcode_t ext2fs_inode_csum(ext2_filsys fs, 
ext2_ino_t inum,
 {
__u32 gen;
struct ext2_inode_large *desc = inode;
-   size_t size = fs->super->s_inode_size;
+   size_t size = EXT2_INODE_SIZE(fs->super);
__u16 old_lo;
__u16 old_hi = 0;
 

Bug#876409: Acknowledgement (RFP: libpowercap - Bindings, abstractions, and utilities for the Linux power capping framework)

[Connor Imes]

retitle 876409 ITP: powercaputils - Utilities and library for accessing the 
powercap Linux kernel feature
owner 876409 cki...@ubuntu.com
severity 876409 wishlist

thanks

Bug#878714: python-keyring: [PATCH] Install the keyring executable

[Ville Skyttä]

Package: python-keyring
Version: 10.4.0-1
Severity: wishlist

Dear Maintainer,

The keyring executable referred to by upstream documentation and
installed by its setup.py is not included in the Debian package. It
would be a useful addition; patch implementing its inclusion is
attached.

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

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

Versions of packages python-keyring depends on:
ii  python2.7.14-2ubuntu1
ii  python-dbus   1.2.4-1build3
ii  python-secretstorage  2.3.1-2

Versions of packages python-keyring recommends:
ii  python-keyrings.alt  2.2-2

Versions of packages python-keyring suggests:
ii  gnome-keyring 3.20.1-1ubuntu1
pn  libkf5wallet-bin  

-- no debconf information


0001-Install-the-keyring-executable.patch.gz
Description: application/gzip

Bug#877935: [Freedombox-pkg-team] Bug#877935: freedombox-setup: Consider switch from libnss-gw-name to systemd-resolved and libnss-resolve

[Sunil Mohan Adapa]

On Saturday 07 October 2017 07:55 PM, James Valleroy wrote:
[...]
> There is an RFA (#805266) for libnss-gw-name. The current maintainer
> mentions that systemd-resolved and libnss-resolve provide the same
> functionality as libnss-gw-name. We should consider whether to switch
> to these alternatives.

systemd-resolved's name resolution is quite well suited for FreedomBox's
purposes and we are better of using it.  The DNSSEC plan is not as great
as unbound+NetworkManager combination.  It works nicely with
NetworkManager that we are using to configure network connections.  I
don't know how well it would sit with out plan of using bind as and
authoritative server.

Here are things I found:

- Use systemd-resolved.  This is already happening because vmdebootstrap
enables both systemd-networkd and systemd-resolved unless
--no-systemd-networkd is specific (which we are not doing).  Daemon
running is good for clients that talk native systemd-resolved protocol
for making DNS queries.  This means that some of the recent images that
we have built should already be running systemd-resolved by default.
However, we need to worry about people upgrading from an older version
of FreedomBox.

- systemd-resolved does not clash ports with bind9 that we have.  Former
listens on 127.0.0.53%lo:53 and latter on 127.0.0.1:53 and :::53 and
apparently that is not a clash.  I verify both to be working fine no
matter which one starts first.

- Make /etc/resolv.conf symlink to /run/systemd/resolved/resolv.conf.
/etc/resolv.conf is useful for programs that use this file directly to
make their DNS queries.  Again vmdebootstrap does this for us during
image build.  This means that some of the recent images that we have
built should already be using systemd-resolved via /etc/resolv.conf.
Again we need think about people upgrading from older version of FreedomBox.

- Make NetworkManager use systemd-resolved.  This is necessary because
when a connection is brought up and an upstream DHCP server provides a
list of DNS servers, these must be used instead of whatever
systemd-resolved is using.  Likewise, they must be removed when a
connection is down.  In order to make this integration happen, we don't
have do anything and things are already integrated.  When NetworkManager
configuratio of 'dns=' is not specified, and if /etc/resolv.conf is
symlinked to use systemd-resolved, then NetworkManager automatically
uses systemd-resovled.  This means DNS servers from upstream DHCP
servers are added and removed from systemd-resolved by NetworkManager.

- Use libnss-resolve.  We can add this as dependency and remove
libnss-gw-name.  This will edit the /etc/nsswitch.conf such that glibc
based programs send DNS queries to systemd-resolved before even
considering /etc/resolv.conf.  This also proper DNSSEC if enabled.  When
systemd-resolved is not running, this does not cause a problem as
nsswitch is configured to fallback to usual mechanism in such a
scenario.  libnss-resolve seems to enable systemd-resolved and make
necessary changes to /etc/nsswitch.conf.

- Deal with the problem of systemd-resolved not running in chroot and
causing freedom-maker image build failures.  vmdebootstrap incorrectly
turns off predictable network names and systemd-resolved when
--no-systemd-networkd is passed.  Joseph and I are still facing this
issue the related bug has been closed as non-reproducible.  A workaround
could be that we copy host /etc/resolv.conf to chroot /etc/resolv.conf
temporarily and restore the symlink to /run/systemd/resolved/resolv.conf
when we are done.

Thanks,

-- 
Sunil

Bug#878713: ITP: golang-github-gosuri-uitable - go library to improve readability in terminal apps using tabular data

[Nobuhiro Iwamatsu]

Package: wnpp
Owner: Nobuhiro Iwamatsu 
Severity: wishlist

* Package name: golang-github-gosuri-uitable
  Version : 0.0~git20170830.36ee7e94-1
  Upstream Author :Greg Osuri 
* URL : https://github.com/gosuri/uitable
* License : Expat
  Programming Lang: go
  Description : go library to improve readability in terminal apps
using tabular data

 uitable is a go library for representing data as tables for terminal
applications.
 It provides primitives for sizing and wrapping columns to improve readability.

Bug#878626: ssh-krb5: Remove obsolete transitional package; replace with debconf prompt?

[Russ Allbery]

Colin Watson  writes:

> I'd like to remove the ssh-krb5 transitional package, since it's been
> around since 2006 and we really shouldn't need to keep transitional
> packages in the archive for over a decade.

> However, this isn't quite just a straightforward transitional package
> with only dependencies: it also has postinst code to enable
> GSSAPIAuthentication and GSSAPIKeyExchange.  When we added this
> originally in https://bugs.debian.org/390986, Russ (CCed) said:

>>  * openssh-server doesn't enable GSSAPI by default.  This is a reasonable
>>default and ideally should be a debconf prompt, but in the interim,
>>installing ssh-krb5 needs to result in a GSSAPI-enabled server.  We
>>therefore need a transitional package that will do the right thing in
>>the configuration.

> Russ, do you still think this needs to be a debconf prompt?  If so we
> should actually get round to doing it, and it would be less hideously
> ugly now that openssh-server uses ucf.

My concern at the time ssh-krb5 was made a transitional package was that,
if you just installed ssh-krb5, you got an ssh server that did not have
GSS-API enabled.  That seemed likely to break things.

Removing the transitional package *entirely* doesn't have the same
problem.  People will notice it's an obsolete package, people installing
new systems will discover it doesn't exist, and they'll then have to
install openssh-server, and in that case it makes logical sense that
they'll need to explicitly enable GSS-API.

I think it's fine to just remove the package.  It long ago served its
purpose, and the few remaining people who may be using it as a shortcut
will hopefully be able to figure out the right thing to do.

-- 
Russ Allbery (r...@debian.org)   

Bug#878712: ITP: golang-github-google-subcommands - go package for add some subcommands to single command

[Nobuhiro Iwamatsu]

Package: wnpp
Owner: Nobuhiro Iwamatsu 
Severity: wishlist

* Package name: golang-github-google-subcommands
  Version : 0.0~git20170830.ce3d4cfc
  Upstream Author : Google Inc
* URL : https://github.com/google/subcommands
* License : Apache-2.0
  Programming Lang: go
  Description : go package for add some subcommands to single command

 Subcommands is a Go package that implements a simple way for a single command
 to have many subcommands, each of which takes arguments and so forth

Bug#878710: add spaces to options

[積丹尼 Dan Jacobson]

Package: wpasupplicant
Version: 2:2.6-4
Severity: wishlist
File: /usr/share/man/man8/wpa_supplicant.8.gz

The man page has a mix of the same options with a space and the same
ones without. -cXXX and -c XXX.
Please add spaces to all of them, not only does it make the man page
more readable, it also encourages people to make neater programs, and
e.g., FFAP can isolate file names better in emacs, etc.

Bug#878273: other: anthy -- REJECT package in the NEW queue

[Chris Lamb]

Hi Osamu,

> Please do not accept anthy 1:0.3-5.1 in NEW queue.

Rejected.


Regards,

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

Bug#878711: sync man page with --help

[積丹尼 Dan Jacobson]

Package: wireless-tools
Version: 30~pre9-12+b1
Severity: wishlist
File: /usr/share/man/man8/iwlist.8.gz

# iwlist --help
Usage: iwlist [interface] scanning [essid NNN] [last]
  [interface] frequency
  [interface] channel
  [interface] bitrate
  [interface] rate
  [interface] encryption
  [interface] keys
  [interface] power
  [interface] txpower
  [interface] retry
  [interface] ap
  [interface] accesspoints
  [interface] peers
  [interface] event
  [interface] auth
  [interface] wpakeys
  [interface] genie
  [interface] modulation

But the man page only has
SYNOPSIS
   iwlist [interface] scanning
   iwlist [interface] frequency
   iwlist [interface] rate
   iwlist [interface] keys
   iwlist [interface] power
   iwlist [interface] txpower
   iwlist [interface] retry
   iwlist [interface] event
   iwlist [interface] auth
   iwlist [interface] wpakeys
   iwlist [interface] genie
   iwlist [interface] modulation
   iwlist --help
   iwlist --version

Please sync the two.

Bug#878360: debdate: Change package description to eg "Convert Gregorian dates to Debian Release dates"

[Adam Borowski]

> Elena ``of Valhalla'' wrote:
> > Of course, I agree that having a king would be pretty bad for Debian,

Why bad?  It's not like kingdoms ruled by Linus Torvalds or Larry Wall fare
worse than democracies.  And the licenses allow you to rebel by making a
fork -- kind of like the explicit right of rebellion ("rokosz") Poland had
in case a king transgresses "against freedoms".

> > altought considering what the release names are this package would refer
> > at most to a mostly harmless puppet king.

> > Chris Lamb wrote that:
> > 
> > > "Regnal" is really quite an esoteric English word these days.

I'm not a native English speaker, yet this word didn't strike me as esoteric
or obscure.

> > This was, however, precisely by design, as this method of dating is
> > quite an esoteric one that has passed in disuse (for quite a number of
> > good practical reason).
> > 
> > I've tried to look for another name for this kind of dating, but it
> > seems to me that at least on the historical articles on wikipedia
> > "regnal" is the standard name used, even in cases like the roman 
> > consules that wheren't kings (nor, during the empire, rulers).

When seeing this word used, I did not have even a shred of doubt that you're
talking about anything other than the reigning DPL.  (Until having reviewed
the package, that is.)

> > Another term that occurs in those articles is "era name", which could be
> > made to fit, altought it is less precise.

A better fit, but indeed pretty unclear.

> > So, if there is a proposal that I've missed that doesn't involve kings
> > but evokes the same feel of "out of an history wikipedia page" I would
> > be happy to hear it and change the short description, otherwise I can
> > try to use something with "era name" or keep the "regnal" one.
> > 
> > In the long description I would continue to use "regnal date" and add
> > "release date", to ease searching.

"release XXX" somewhat spoils the joke but indeed would be better.


Chris Lamb wrote:
> > I've tried to look for another name for this kind of dating, but it
> > seems to me that at least on the historical articles on wikipedia
> > "regnal" is the standard name used
> 
> I've found using or citing Wikipedia for meta things like this can be
> quite misleading; all it needs is one contributor to spend a few hours
> changing them all to the "technically correct" word!

Wikipedia is completely at mercy of any organised "group" (which might be a
single person using sock puppets) whenever there's no large enough
countergroup.  Case in point: the WW2 article praises the Soviets as best
allies, while in fact they started on the "bad" side, shot at their allies
in the middle (like, attempts to relieve the Warsaw Uprising) then ended at
hostile terms as well.

But I don't believe there's anyone with an agenda against an unloaded word
like "regnal".

> I stand by my comments that "regnal" — whilst possibly 100% correct — is
> incomprehensible to 99.9% of English speakers and highly recommend we
> don't use it. It'll only serve as a handicap when looking for this package
> I'm afraid resulting in fewer users.

I'd argue that it's a perfectly cromulent word... for when the ruler is a
person.  Which is not the case here.

> > So, if there is a proposal that I've missed that doesn't involve kings
> 
> We can surely reference "kings", etc. ironically and with a degree of
> cynicism...

Yes, Your Majesty! :p


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ I was born a dumb, ugly and work-loving kid, then I got swapped on
⠈⠳⣄ the maternity ward.

Bug#878709: debian-live: Online live-wrapper documentation is obsolete

[Daniel Lewart]

Package: debian-live
Severity: normal

Dear Maintainer,

   * What led up to the situation?

>From "Debian Live Developer Information":
https://debian-live.alioth.debian.org/
I followed the link for "live-wrapper Documentation (git)" to:
https://debian-live.alioth.debian.org/live-wrapper-doc/

   * What was the outcome of this action?

live-wrapper 0.1 documentation

   * What outcome did you expect instead?

Current live-wrapper (0.7) documentation

Thank you!
Dan

Bug#878708: geographiclib: please make the build reproducible

[Chris Lamb]

Source: geographiclib
Version: 1.49-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that geographiclib could not be built reproducibly.

This is because the documentation generates a .tag file with the
absolute build path.

Patch attached that simply disables the generation of this file as
shipping it is not useful to end users as the referenced .cpp files
are not present at that location in the binary package.


 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1969-12-31 19:00:00.0 
-0500
--- b/debian/patches/reproducible-build.patch   2017-10-15 20:43:11.882599642 
-0400
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2017-10-15
+
+--- geographiclib-1.49.orig/doc/doxyfile.in
 geographiclib-1.49/doc/doxyfile.in
+@@ -1544,7 +1544,7 @@ TAGFILES   =
+ # When a file name is specified after GENERATE_TAGFILE, doxygen will create
+ # a tag file that is based on the input files it reads.
+ 
+-GENERATE_TAGFILE   = html/GeographicLib.tag
++GENERATE_TAGFILE   =
+ 
+ # If the ALLEXTERNALS tag is set to YES all external classes will be listed
+ # in the class index. If set to NO only the inherited external classes
--- a/debian/patches/series 2017-10-15 20:30:09.291563240 -0400
--- b/debian/patches/series 2017-10-15 20:43:10.530577980 -0400
@@ -1,3 +1,4 @@
 css.patch
 privacy.patch
 disable-python-build.patch
+reproducible-build.patch

Bug#862875: RFS: libzc/0.3.1-1 [ITP] -- fast zip cracking library

[Adam Borowski]

On Fri, Sep 15, 2017 at 10:47:29PM -0400, Marc Ferland wrote:
> On Mon, Sep 11, 2017 at 4:09 PM, Andrey Rahmatullin  wrote:
> > d/copyright says "License: GPL-3" instead of GPL-3+.
> > lib/pthread_barrier.h and m4/ax_pthread.m4 should have separate entries in
> > d/copyright.
> > Otherwise the package looks good.
> 
> Fixed d/copyright and other warnings reported by 'scan-copyright' with
> latest version:
> 
> https://mentors.debian.net/debian/pool/main/libz/libzc/libzc_0.3.5-1.dsc

The package fails to build on most architectures, with a timeout in the
testsuite:

PASS: pwstream
PASS: file
PASS: basic
PASS: dictionary
PASS: plaintext
PASS: plaintext_password
FAIL: reduce
PASS: bruteforce

   zc 0.3.5: tests/test-suite.log


# TOTAL: 8
# PASS:  7
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: reduce


Running suite(s): reduce
66%: Checks: 3, Failures: 0, Errors: 1
check_reduce.c:60:E:Core:test_can_generate_next_array_from_plaintext:0: (after 
this point) Test timeout expired
FAIL reduce (exit status: 1)


Testsuite summary for zc 0.3.5

# TOTAL: 8
# PASS:  7
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ I was born a dumb, ugly and work-loving kid, then I got swapped on
⠈⠳⣄ the maternity ward.

Bug#878707: python-amqp: please make the build reproducible

[Chris Lamb]

Source: python-amqp
Version: 1.4.9-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that python-amqp could not be built reproducibly.

This is due to the generated documentation non-deterministically
orders the skip_attrs set.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/amqp/five.py  2017-10-15 20:30:33.599193127 -0400
--- b/amqp/five.py  2017-10-15 20:33:07.841817590 -0400
@@ -116,7 +116,7 @@
 BytesIO = WhateverIO = StringIO # noqa
 
 
-def with_metaclass(Type, skip_attrs=set(['__dict__', '__weakref__'])):
+def with_metaclass(Type, skip_attrs=None):
 """Class decorator to set metaclass.
 
 Works with both Python 3 and Python 3 and it does not add
@@ -125,6 +125,9 @@
 
 """
 
+if skip_attrs is None:
+skip_attrs = set(['__dict__', '__weakref__'])
+
 def _clone_with_metaclass(Class):
 attrs = dict((key, value) for key, value in items(vars(Class))
  if key not in skip_attrs)

Bug#878705: using sysctl.h is a bug

[Adam Borowski]

While it might sound like just "makers of some weird architecture no one
heard about haven't implemented this interface yet", it's not the case here.

Because of flaws of this interface, even on old architectures, trying to use
this syscall[1] printks a warning.  On the other hand, on certain kernels
other than Linux, sysctl() remains useful, thus some programs #include
sysctl.h if it exists, even when they don't actually use it (as they won't
on Linux).

The problem here is that on x32 sysctl.h exists but causes a compile error.

Thus, it's best to never #include it on Linux.



[1]. It's not removed entirely because programs compiled with very ancient
versions of glibc won't run otherwise.
-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ I was born a dumb, ugly and work-loving kid, then I got swapped on
⠈⠳⣄ the maternity ward.

Bug#877555: libgegl-dev should supply VAPI bindings

[Jeremy Bicha]

There doesn't appear to be any .vapi file generated by the build.

Thanks,
Jeremy Bicha

Bug#878706: isenkram: Packagekit transaction flags incorrect

[segfault]

Package: isenkram
Version: 0.36
Tags: patch

The packagekit transaction flags are currently used incorrectly. See the
below patch which fixes this bug.

---

>From a56e8119cee2e72201582905309644b24b08eb3d Mon Sep 17 00:00:00 2001
From: segfault 
Date: Mon, 16 Oct 2017 01:37:55 +0200
Subject: [PATCH] Fix incorrect transaction flags

Packagekit expects the transaction flags as a bit field, but in the
python bindings the flags are an enumeration.
---
 isenkramd | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/isenkramd b/isenkramd
index a3bdd39..3d700fe 100755
--- a/isenkramd
+++ b/isenkramd
@@ -232,7 +232,7 @@ class PackageKitInstaller(object):

 # Start package installation
 results = client.install_packages(
-packagekit.TransactionFlagEnum.ONLY_TRUSTED, package_ids +
[None],
+1 << packagekit.TransactionFlagEnum.ONLY_TRUSTED,
package_ids + [None],
 None, self.progress_callback, self)
 self._assert_success(results)

Bug#693230: multimail ITA update

[Robert J. Clay]

The last snapshot I was working with was from 20150922. Reviewing both
of the current upstream git repositories[1][2], there have been
updates since then (including earlier this year) so will need to
create a new snapshot and then work with that.  (But also plan to ask
upstream about if there will be an actual release any time soon.)

-- 
Robert J. Clay
rjc...@gmail.com, j...@rocasa.us
[1] https://sourceforge.net/p/multimail/code/
[2] https://github.com/wmcbrine/MultiMail

Bug#878705: opencv: FTBFS on x32: sysctl(.h) unsupported

[Aaron M. Ucko]

Source: opencv
Version: 2.4.9.1+dfsg1-2
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org

Builds of opencv for x32 (admittedly not a release architecture) have
been failing lately:

  In file included from /usr/include/x86_64-linux-gnux32/sys/sysctl.h:63:0,
   from 
/<>/opencv-3.2.0+dfsg/modules/core/src/parallel.cpp:60:
  /usr/include/x86_64-linux-gnux32/bits/sysctl.h:19:3: error: #error "sysctl 
system call is unsupported in x32 kernel"

Per sysctl(2), this interface is generally deprecated, so my
recommendation would be to steer clear of it on any Linux
architecture.  Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#878702: mutter: FTBFS on kFreeBSD: PFNEGLQUERYDMABUFFORMATSEXTPROC unknown

[Aaron M. Ucko]

"Aaron M. Ucko"  writes:

>   backends/meta-egl.c:70:3: error: unknown type name 
> 'PFNEGLQUERYDMABUFFORMATSEXTPROC'
>   backends/meta-egl.c:71:3: error: unknown type name 
> 'PFNEGLQUERYDMABUFMODIFIERSEXTPROC'

I just took a closer look myself and noticed that the same errors occur
on sh4, on which mesa is also out of date.  (It fails with assembler
errors from code that uses no inline assembly, presumably due to a
toolchain bug.) As such, my recommendation at this point is either to
version the build dependency on libegl1-mesa-dev to (>= 17~) or to
conditionalize the usage of these types on
EGL_EGLEXT_VERSION >= 20161230

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#878704: open-coarrays: FTBFS on powerpc: get_array test times out

[Aaron M. Ucko]

Source: open-coarrays
Version: 1.9.1-1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-powe...@lists.debian.org

Builds of open-coarrays for powerpc (admittedly not a release
architecture) have been failing lately:

Start 14: get_array
  E: Caught signal ‘Terminated’: terminating immediately
  debian/rules:22: recipe for target 'override_dh_auto_test' failed
  debian/rules:10: recipe for target 'build-arch' failed
  make: *** [build-arch] Terminated
  make[1]: [override_dh_auto_test] Terminated (ignored)
  Makefile:110: recipe for target 'test' failed
  make[2]: *** [test] Terminated

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#878703: Irssi: Error loading module otr/otr: libgcrypt.so.11: cannot open shared object file

[Steve Revilak]

Package: irssi-plugin-otr
Version: 1.0.2-1+b1
Severity: normal

Dear Maintainer,

I'm writing to report a problem with irssi-plugin-otr, on a new
installation of Debian 9.2 (i386).

Attempts to load the otr module within irssi fail, with what looks
like a unsatisfied shared library dependency.  Here's the result of
typing "/load otr" into irssi's input area

19:45 -!- Irssi: Error loading module otr/otr: libgcrypt.so.11: cannot open 
shared object file: No such file or directory

I would have expected irssi to respond with "Loaded module otr/otr",
or something to that effect.

Subsequent attempts to use the otr plugin (e.g., "/otr init") produce
the error message "Irssi: Unknown command: otr".

I see that debian 9.2 includes a newer version of libgcrypt, but irssi
appears to have a dependency on libgcrypt.so.11.

I tried installing the libgcrypt11-dev package.  This did not change
the behavior I've observed.

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

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

Versions of packages irssi-plugin-otr depends on:
ii  irssi1.0.2-1+deb9u2
ii  libc62.24-11+deb9u1
ii  libgcrypt20  1.7.6-2+deb9u2
ii  libotr5  4.1.1-2

irssi-plugin-otr recommends no packages.

irssi-plugin-otr suggests no packages.

-- no debconf information

Bug#841733: Transition Opencv 3.1

[Nobuhiro Iwamatsu]

Hi,


2017-10-14 4:45 GMT+09:00 Mattia Rizzolo :
> On Fri, Oct 13, 2017 at 07:09:52PM +0200, Emilio Pozuelo Monfort wrote:
>> Alright, let's go ahead with this, now that gdal is done.
>
> \o/
>
> Uploaded, and started to build.

Thanks!

>
> I've also raised all the remaining bug to RC, and poked them (also to
> get the needed sourceful uploads sorted).



>
> --
> regards,
> Mattia Rizzolo

Bset regards,
  Nobuhiro

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



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#878702: mutter: FTBFS on kFreeBSD: PFNEGLQUERYDMABUFFORMATSEXTPROC unknown

[Aaron M. Ucko]

Source: mutter
Version: 3.26.1-4
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org

Builds of mutter for kfreebsd-amd64 and kfreebsd-i386 (admittedly not
release architectures) have been failing lately with a cascade of
errors and warnings stemming from

  backends/meta-egl.c:70:3: error: unknown type name 
'PFNEGLQUERYDMABUFFORMATSEXTPROC'
  backends/meta-egl.c:71:3: error: unknown type name 
'PFNEGLQUERYDMABUFMODIFIERSEXTPROC'

I suspect builds for hurd-i386 (not a release architecture either)
would fail in the same fashion, but mutter is currently in Dep-Wait
there.  (It's waiting for libgbm-dev from recent mesa, which is in
turn waiting for libglvnd, which FTFBS on non-Linux per #870445.
However, there may well be other latent complications on that front.)

At any rate, could you please take a look and conditionalize the usage
of these symbols appropriately?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#875742: Debian mirror mirror.xtom.com.hk: unreachable

[Xiufeng Guo]

Hello,

Can you please update the page https://www.debian.org/mirror/list-full#HK

Change Type to  Push-Primary and Update frequency to whenever there are updates 
(push-triggered)

Also add ftp.hk.debian.org to Site

Regards,

David

-Original Message-
From: Peter Palfrader [mailto:wea...@debian.org] 
Sent: Monday, October 16, 2017 4:29 AM
To: Xiufeng Guo ; 875...@bugs.debian.org
Subject: Re: Bug#875742: Debian mirror mirror.xtom.com.hk: unreachable

On Sun, 15 Oct 2017, Xiufeng Guo wrote:

> Ftpsync of cron has been cancelled.

Great.  Please keep an eye on things and let us know if your mirror fails to 
update.

Cheers and good night,
weasel
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#822590: closed by Emilio Pozuelo Monfort <po...@debian.org> (Re: liblunar: depends on python-gtksourceview2 which is deprecated)

[Emilio Pozuelo Monfort]

Control: reopen -1
Control: severity -1 serious

Sorry, didn't mean to close this bug. As my message explains this
build-dependency should be dropped as we are removing pygtksourceview.

Thanks,
Emilio

Bug#878701: gjs: FTBFS on hppa: Could not initialize Javascript for GjsPrivate-1.0.gir

[Aaron M. Ucko]

Source: gjs
Version: 1.50.1-2
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-h...@lists.debian.org

Builds of gjs for hppa (admittedly not a release architecture) have
been failing lately:

  (process:8134): Gjs-ERROR **: Could not initialize Javascript
  Command '['/<>/tmp-introspectvteu5_xm/GjsPrivate-1.0', 
'--introspect-dump=/<>/tmp-introspectvteu5_xm/functions.txt,/<>/tmp-introspectvteu5_xm/dump.xml']'
 died with .
  /usr/share/gobject-introspection-1.0/Makefile.introspection:159: recipe for 
target 'GjsPrivate-1.0.gir' failed
  make[2]: *** [GjsPrivate-1.0.gir] Error 1

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#878700: needrestart: False positive with AppImage

[Richard Hector]

Package: needrestart
Version: 2.11-3
Severity: normal

Dear Maintainer,

It appears that AppImage packages mount their filesystem under /tmp/,
and needrestart may find that there are open binaries or libraries there
but be unable to find them. Sorry, I'm not sure how to word this ...

The symptom I see is that I'm asked to restart xfce4-session every time
I run needrestart, and it appears to be the NextCloud Appimage that's
triggering it.

>From sudo needrestart -v:

[main] #8534 uses obsolete /tmp/.mount_Nextcl4R40GR/usr/bin/nextcloud

I can show more of that output if needed (but would try for a minimal
case)

-- Package-specific info:
needrestart output:
Your outdated processes:
AppRun[8534]

checkrestart output:


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

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

Versions of packages needrestart depends on:
ii  dpkg   1.18.24
ii  gettext-base   0.19.8.1-2
ii  libintl-perl   1.26-2
ii  libmodule-find-perl0.13-1
ii  libmodule-scandeps-perl1.23-1
ii  libproc-processtable-perl  0.53-2
ii  libsort-naturally-perl 1.03-1
ii  libterm-readkey-perl   2.37-1
ii  perl   5.24.1-3+deb9u2
ii  xz-utils   5.2.2-1.2+b1

Versions of packages needrestart recommends:
ii  libpam-systemd  232-25+deb9u1

Versions of packages needrestart suggests:
ii  libnotify-bin  0.7.7-2

-- no debconf information

Bug#878584: [Pkg-e-devel] Bug#878584: [libevas-dev] Missing dependency for libecore-dev

[Ross Vandegrift]

On Sun, Oct 15, 2017 at 01:20:05PM +0200, Andreas Metzler wrote:
> Ross, could you apply and push the attached patch?

Hmm, two concerns about this solution:

1) lintian finds a circular dependency
  libecore-dev libector-dev libeet-dev libeeze-dev libeina-dev libemile-dev 
libevas-dev
I don't know for sure that it's a problem here, but in the past the team
has worked hard to avoid cycles.

2) Upstream doesn't really support builds against part of EFL (and
hasn't since the library merge before 1.8).  I think we generally ought
to avoid supporting scenarios that upstream doesn't.

Instead, what if all of the -dev packages were merged into
libefl-all-dev?  Sample patch is attached.  It's mildly tested:
enlightenment from experimental builds, and the resulting Depends look
correct.  What do you think?

I've pushed the accumulated fixes to:
https://github.com/rvandegrift/efl/tree/debian/experimental
I've added this patch at:
https://github.com/rvandegrift/efl/tree/debian/experimental-next

Thanks,
Ross


merge-libe-dev-pkgs.diff.gz
Description: application/gzip

Bug#790141: txaws: depends on python-gnomekeyring which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

Hi,

We are finally removing gnome-python-desktop (so python-rsvg,
python-gnomekeyring, python-wnck) so this is now RC.

Cheers,
Emilio

Bug#878699: plinth: [WIP] Add tests

[James Valleroy]

Package: plinth
Severity: wishlist

The attached patch adds tests for autopkgtest (ci.debian.net). It
includes the test suite from upstream.

Currently there is a problem which causes the test run to fail with
"Test dependencies are unsatisfiable". It tries to install fail2ban
and then start the service:

$ sudo autopkgtest-build-lxc debian sid
...
$ autopkgtest --apt-upgrade -B $(debc --list-debs) . -- lxc --sudo 
autopkgtest-sid
...
Setting up fail2ban (0.9.7-2) ...
Created symlink /etc/systemd/system/multi-user.target.wants/fail2ban.service → 
/lib/systemd/system/fail2ban.service.
Job for fail2ban.service failed because the control process exited with error 
code.
See "systemctl  status fail2ban.service" and "journalctl  -xe" for details.
invoke-rc.d: initscript fail2ban, action "start" failed.
● fail2ban.service - Fail2Ban Service
   Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor 
preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Sun 2017-10-15 
20:52:27 UTC; 4ms ago
 Docs: man:fail2ban(1)
  Process: 12570 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, 
status=255)
dpkg: error processing package fail2ban (--configure):
 subprocess installed post-installation script returned error exit status 1
>From f69bf1b563a6969b543ca7bca5da0abdb651f9d3 Mon Sep 17 00:00:00 2001
From: James Valleroy 
Date: Wed, 4 Oct 2017 22:07:33 -0400
Subject: [PATCH] Add tests

---
 debian/tests/control   | 2 ++
 debian/tests/run-tests | 7 +++
 2 files changed, 9 insertions(+)
 create mode 100644 debian/tests/control
 create mode 100755 debian/tests/run-tests

diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index ..f2fef0f8
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,2 @@
+Tests: run-tests
+Restrictions: needs-root, breaks-testbed, allow-stderr
diff --git a/debian/tests/run-tests b/debian/tests/run-tests
new file mode 100755
index ..31fa14fa
--- /dev/null
+++ b/debian/tests/run-tests
@@ -0,0 +1,7 @@
+#!/bin/sh
+set -e
+
+# show full errors in log
+export SYSTEMD_PAGER=cat
+
+python3 setup.py test
-- 
2.11.0

Bug#878677: nvidia-kernel-dkms:amd64: conftest fails with CONFIG_GCC_PLUGINS

[Luca Boccassi]

On Sun, 2017-10-15 at 19:34 +0200, Tomas Janousek wrote:
> Package: nvidia-kernel-dkms
> Version: 375.82-4
> Severity: normal
> Tags: patch
> 
> I have a vanilla kernel with CONFIG_GCC_PLUGINS,
> CONFIG_GCC_PLUGIN_STRUCTLEAK
> and CONFIG_GCC_PLUGIN_RANDSTRUCT and conftest fails because
> KBUILD_CFLAGS
> contains the following:
> 
> -fplugin=./scripts/gcc-plugins/structleak_plugin.so
> -fplugin=./scripts/gcc-plugins/randomize_layout_plugin.so
> 
> but conftest runs with a different pwd than the module build itself.
> 
> I'm attaching a patch inspired by
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.g
> it/tree/scripts/Kbuild.include?h=v4.13.7#n118
> that fixes the build.

It seems a simple enough patch so I've committed it to SVN, it will be
included in the next upload. Thanks.

Kind regards,
Luca Boccassi

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

Bug#840181: python-scour: Please use GObject introspection bindings instead of python-rsvg

[Emilio Pozuelo Monfort]

Control: severity -1 important

On Sun, 09 Oct 2016 12:55:31 +0200 Laurent Bigonville  wrote:
> Package: python-scour
> Version: 0.32-2
> Severity: normal
> Forwarded: https://github.com/scour-project/scour/issues/122
> 
> Hi,
> 
> python-rsvg is considered deprecated, could you please use the GObject
> introspection bindings instead?

We are removing python-rsvg. Since this is only a suggest, it's not RC, but you
may want to port to the gobject introspection bindings anyway.

Thanks,
Emilio

Bug#878381: please drop transitional package cweb-latex

[Julian Gilbey]

reassign 878381 ftp.debian.org
retitle 878381 RM: cweb-latex -- ROM; transitional package no longer needed
thanks

See the QA report below - this transitional package is no longer
needed in buster.

Best wishes,

   Julian

On Fri, Oct 13, 2017 at 11:48:17AM +0200, Holger Levsen wrote:
> Package: cweb-latex
> Version: 1.1.1.debian.1
> Severity: normal
> user: qa.debian@packages.debian.org
> usertags: transitional
> 
> Please drop the transitional package cweb-latex for buster,
> as it has been released with wheezy, jessie and stretch already.
> 
> Thanks for maintaining cweb-latex!
> 
> 
> -- 
> cheers,
>   Holger

Bug#790145: screenlets: depends on python-wnck which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

Hi,

We are finally removing gnome-python-desktop (so python-rsvg,
python-gnomekeyring, python-wnck) so this is now RC.

Cheers,
Emilio

Bug#790152: screenlets: depends on python-rsvg which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

Hi,

We are finally removing gnome-python-desktop (so python-rsvg,
python-gnomekeyring, python-wnck) so this is now RC.

Cheers,
Emilio

Bug#790147: hamster-applet: depends on python-wnck which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

Hi,

We are finally removing gnome-python-desktop (so python-rsvg,
python-gnomekeyring, python-wnck) so this is now RC.

Cheers,
Emilio

Bug#790149: xword: depends on python-wnck which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

Hi,

We are finally removing gnome-python-desktop (so python-rsvg,
python-gnomekeyring, python-wnck) so this is now RC.

Cheers,
Emilio

Bug#790154: dissy: depends on python-rsvg which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

Hi,

We are finally removing gnome-python-desktop (so python-rsvg,
python-gnomekeyring, python-wnck) so this is now RC.

Cheers,
Emilio

Bug#790146: gdevilspie: depends on python-wnck which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

Hi,

We are finally removing gnome-python-desktop (so python-rsvg,
python-gnomekeyring, python-wnck) so this is now RC.

Cheers,
Emilio

Bug#790162: winswitch: depends on python-rsvg which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

Hi,

We are finally removing gnome-python-desktop (so python-rsvg,
python-gnomekeyring, python-wnck) so this is now RC.

Cheers,
Emilio

Bug#790158: sugar-toolkit: depends on python-rsvg which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

Hi,

We are finally removing gnome-python-desktop (so python-rsvg,
python-gnomekeyring, python-wnck) so this is now RC.

Cheers,
Emilio

Bug#790156: sugar-calculate-activity: depends on python-rsvg which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

Hi,

We are finally removing gnome-python-desktop (so python-rsvg,
python-gnomekeyring, python-wnck) so this is now RC.

Cheers,
Emilio

Bug#828475: openssh: Please migrate to openssl1.1 in Buster

[Colin Watson]

On Sun, Oct 15, 2017 at 09:38:50PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-10-13 15:30:13 [+0100], Colin Watson wrote:
> > That's basically the last I recall hearing, and that they were trying to
> > put pressure on OpenSSL upstream.
> 
> I pinged upstream about the situation. I'm not sure if I made it worse
> or not but I read something like "adding glue code to fetch and build
> against libressl". 

Thanks.  We'll see how it goes.

> > Does it help that OpenSSH only uses libcrypto, not libssh?  If somebody
> > were to split out the headers relevant to libcrypto into a separate
> > package, then it'd be possible for openssh to build-depend on that.  (I
> > have no idea whether OpenSSL's headers are actually separable in this
> > way.)
> 
> Well it looks to me that upstream does not want to use accessor which
> are requried by openssl 1.1 because they don't need them. This is what
> it looks like to me right now. What makes you think that they would
> accept a split like that? They would never use it libssh version, they
> probably would bypass that layer if they made a protocol change which is
> not yet covered by the library. I assume here you do not plat to
> maintain that patch yourself.

What?  You've entirely misunderstood me.  OpenSSH upstream *already*
builds against only libcrypto and doesn't use libssl; I was suggesting
that keeping around just libcrypto1.0 for a while would at least allow
getting rid of libssl1.0 in Debian, although it would require
packaging-level changes in OpenSSL to ship the files required to build
against only libcrypto in a separate package.  (Compare
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828475#39.)

> I've been pointed out to another way to go I hope you like it: There is
> PKIX-SSH [0].

I dislike the idea of switching to a fork even more than the idea of
maintaining an enormous patch, I'm afraid - especially one that adds
other features, making it a one-way change.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#822589: kabikaboo: depends on python-gtksourceview2 which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

On Mon, 25 Apr 2016 16:53:34 +0200 po...@debian.org wrote:
> Source: kabikaboo
> Severity: important
> Tags: sid stretch
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs pygtksourceview
> 
> Hi,
> 
> kabikaboo depends on python-gtksourceview2, which is long deprecated
> and going to be removed from the archive. kabikaboo should switch to
> using the GObject Introspection bindings for gtksourceview,
> gir1.2-gtksource-3.0.
> 
> This would mean switching to GObject Introspection for other bindings
> as well, e.g. GLib and GTK+ 3.
> 
> For more information on GObject Introspection see [1] and [2].
> 
> Please try to do this before the Stretch release as we're going to
> try to remove it this cycle.
> 
> If you have any question don't hesitate to ask.

We are finally removing pygtksourceview, so this is now RC.

Emilio

Bug#822585: gvrng: depends on python-gtksourceview2 which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

On Mon, 25 Apr 2016 16:53:33 +0200 po...@debian.org wrote:
> Source: gvrng
> Severity: important
> Tags: sid stretch
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs pygtksourceview
> 
> Hi,
> 
> gvrng depends on python-gtksourceview2, which is long deprecated and
> going to be removed from the archive. gvrng should switch to using
> the GObject Introspection bindings for gtksourceview,
> gir1.2-gtksource-3.0.
> 
> This would mean switching to GObject Introspection for other bindings
> as well, e.g. GLib and GTK+ 3.
> 
> For more information on GObject Introspection see [1] and [2].
> 
> Please try to do this before the Stretch release as we're going to
> try to remove it this cycle.
> 
> If you have any question don't hesitate to ask.

We are finally removing pygtksourceview, so this is now RC.

Emilio

Bug#822586: cherrytree: depends on python-gtksourceview2 which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

On Mon, 25 Apr 2016 16:53:33 +0200 po...@debian.org wrote:
> Source: cherrytree
> Severity: important
> Tags: sid stretch
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs pygtksourceview
> 
> Hi,
> 
> cherrytree depends on python-gtksourceview2, which is long deprecated
> and going to be removed from the archive. cherrytree should switch to
> using the GObject Introspection bindings for gtksourceview,
> gir1.2-gtksource-3.0.
> 
> This would mean switching to GObject Introspection for other bindings
> as well, e.g. GLib and GTK+ 3.
> 
> For more information on GObject Introspection see [1] and [2].
> 
> Please try to do this before the Stretch release as we're going to
> try to remove it this cycle.
> 
> If you have any question don't hesitate to ask.

We are finally removing pygtksourceview, so this is now RC.

Emilio

Bug#822588: dreampie: depends on python-gtksourceview2 which is deprecated

[Emilio Pozuelo Monfort]

Control: severity -1 serious

On Mon, 25 Apr 2016 16:53:33 +0200 po...@debian.org wrote:
> Source: dreampie
> Severity: important
> Tags: sid stretch
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs pygtksourceview
> 
> Hi,
> 
> dreampie depends on python-gtksourceview2, which is long deprecated
> and going to be removed from the archive. dreampie should switch to
> using the GObject Introspection bindings for gtksourceview,
> gir1.2-gtksource-3.0.
> 
> This would mean switching to GObject Introspection for other bindings
> as well, e.g. GLib and GTK+ 3.
> 
> For more information on GObject Introspection see [1] and [2].
> 
> Please try to do this before the Stretch release as we're going to
> try to remove it this cycle.
> 
> If you have any question don't hesitate to ask.

We are finally removing pygtksourceview, so this is now RC.

Emilio

Bug#878698: pygtksourceview: keep out of testing

[Emilio Pozuelo Monfort]

Source: pygtksourceview
Severity: serious

It is high time that we remove pygtksourceview from testing. It's
completely dead upstream in favor of the gobject-introspection
bindings, gir1.2-gtksource-3.0. Remaining reverse dependencies
should be ported to use that.

Emilio

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Bug#877971: Additional info

[Luca Boccassi]

On Sun, 2017-10-15 at 19:10 +1100, TarotApprentice wrote:
> I ended up picking up the later driver (384.90) from Experimental
> which doesn’t seem to have this issue.
> 
> From looking on Nvidia’s web site it appears the the 375.x series are
> considered legacy so I didn’t bother raising a bug as its not likely
> to get looked at. Any idea how long before the 384.x drivers are
> going to get moved up to testing or backports?
> 
> MarkJ 

Hi,

No exact ETA but it's the next item on the TODO list:

https://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/2017-September/014678.html

Kind regards,
Luca Boccassi

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

Bug#878697: dash -n: out-of-bounds write

[Jakub Wilk]

Package: dash
Version: 0.5.8-2.5
Tags: security

dash crashes when checking syntax of some scripts:

  $ printf '%032d<<0;do %024d\n%028d\r\360\255\336' | dash -n
  Segmentation fault

GDB says it's an out-of-bounds write:

  Program received signal SIGSEGV, Segmentation fault.
  0x5656542e in parseheredoc () at ../../src/parser.c:672
  672 here->here->nhere.doc = n;
  (gdb) print here->here->nhere
  Cannot access memory at address 0xdeadf00d
  (gdb) bt
  #0  0x5656542e in parseheredoc () at ../../src/parser.c:672
  #1  0x56564540 in list (nlflag=1) at ../../src/parser.c:198
  #2  0x56564419 in parsecmd (interact=0) at ../../src/parser.c:151
  #3  0x56561ae4 in cmdloop (top=1) at ../../src/main.c:224
  #4  0x56561a4b in main (argc=2, argv=0xd694) at ../../src/main.c:178


-- System Information:
Architecture: i386

Versions of packages dash depends on:
ii  libc62.24-17
ii  debianutils  4.8.2
ii  dpkg 1.18.24

--
Jakub Wilk

Bug#878696: Debian mirror mirror.nbtelecom.com.br: broken mirror

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem may-auto-close
Control: submitter -1 mirr...@debian.org

Hi,

I was checking some things in the Debian mirror universe and noticed
a problem with your mirror:

It seems your mirror is no longer available.  It is missing a lot of
files, like all of /project for instance.  Is this intentional?


Status: 
https://mirror-master.debian.org/status/mirror-info/mirror.nbtelecom.com.br.html

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#867588: buildbot: application fails at runtime requiring sqlalchemy-migrate==0.7.2

[Charles Lepple]

So far, I have not observed any failures after removing the offending
lines ("sqlalchemy >= 0.6, <= 0.7.10" and "sqlalchemy-migrate==0.7.2")
from
/usr/lib/python2.7/dist-packages/buildbot-0.8.12.egg-info/requires.txt

Tested with buildbot 0.8.12-3.2 on stretch, with python-sqlalchemy
1.0.15+ds1-1 and python-migrate 0.10.0-7. Also installed "python-mock" and
ran the Buildbot tests with trial, though I am not sure how much of the
migration code gets exercised in the tests.

This commit to upstream seems to indicate that the newer versions of
sqlalchemy and sqlalchemy-migrate included in Debian should be compatible
with each other:

https://github.com/buildbot/buildbot/commit/222361a0e061291c9ba7fd7e6a660c7356ecd218

"Accept sqlalchemy-migrate versions 0.8 and up as compatible with
sqlalchemy version 0.8 and up."

Bug#878681: /bin/nano: Multiple files at once are opened very slowly (when user doesn't have write permissions)

[Thomas Lange]

Hello Benno,

thanks for your information and for the tip with the package manager and the 
"nopause" option for nano-2.8.0. But the problem is not so bad for me, so I can 
wait for the next Debian stable release, which contains a newer version of 
nano. Sorry for the confusion: I am the author of the bug report. I have used a 
wrong email address in the first mail (the bugreport tool sent it automatically 
from my machine via my send-only MTA, which was actually not really intended).

Thomas \(o_o)/

Bug#875742: Debian mirror mirror.xtom.com.hk: unreachable

[Peter Palfrader]

On Sun, 15 Oct 2017, Xiufeng Guo wrote:

> Ftpsync of cron has been cancelled.

Great.  Please keep an eye on things and let us know if your mirror
fails to update.

Cheers and good night,
weasel
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#878070: fmtlib: Removing header-only target is causing problem

[Eugene V. Lyubimkin]

Control: retitle -1 fmtlib: static library should be compiled with -fPIC
Control: tags -1 + confirmed pending


Hello,

On 09.10.2017 15:15, Boyuan Yang wrote:
> I saw that your recommendation is to use the static library provided. I think 
> that may not be best practice.

I agree it's not. However, fmtlib changed its major version 4 times in
the last 2½ years, so considering its small size and relative unstability (so 
far)
the package doesn't provide a shared library right now. In version 4 there are
less breaking changes than before, so I'll re-evaluate whether to add a shared
library later in the release cycle.

> As you might already know,  Debian don't really recommend using static 
> libraries. Especially after the beginning of hardening efforts in Debian [2], 
> using static libraries while building hardened binaries will encounter 
> problem 
> that the static library is not built with -fPIC. This is the current case for 
> fcitx5 using fmtlib.

Good point. The code should be definitely built with -fPIC. Thank you for
the report, will be fixed in the next upload.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#878695: xul-ext-noscript: no longer works on existing profiles since last update

[Christoph Anton Mitterer]

Package: xul-ext-noscript
Version: 5.1.2-1
Severity: grave
Tags: security
Justification: renders package unusable

Hi.


Since the upgrade to 5.1.2-1 the plugin, while still appearing in the
add-ons list (and marked enabled there), no longer seems to work.
It's "icons/menus/etc" disappeared and cannot be added back again.

It does seem to appear on fresh profiles and it works again with the existing
profiles when downgrading to 5.0.10-1

Any ideas?

tag security, since all scripts seem to be now allowed.

Cheers,
Chris.

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

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

Versions of packages xul-ext-noscript depends on:
ii  firefox56.0-2
ii  iceweasel  100

xul-ext-noscript recommends no packages.

xul-ext-noscript suggests no packages.

-- Configuration Files:
/etc/iceweasel/searchplugins/common/opensearch_html.xml [Errno 2] No such file 
or directory: '/etc/iceweasel/searchplugins/common/opensearch_html.xml'

-- no debconf information

Bug#875742: Debian mirror mirror.xtom.com.hk: unreachable

[Xiufeng Guo]

Ftpsync of cron has been cancelled.

-Original Message-
From: Peter Palfrader [mailto:wea...@debian.org] 
Sent: Monday, October 16, 2017 4:21 AM
To: Xiufeng Guo ; 875...@bugs.debian.org
Subject: Re: Bug#875742: Debian mirror mirror.xtom.com.hk: unreachable

On Sun, 15 Oct 2017, Xiufeng Guo wrote:

> Can we apply for ftp.hk.debian.org now?

Updated DNS.

Reading
https://mirror-master.debian.org/status/mirror-info/mirror.xtom.com.hk.html
I think you are still running ftpsync out of cron.

However, mirror syncs now are started when triggered by ssh.

So you should probably disable the cron'ed launches of your mirror script.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#875742: Debian mirror mirror.xtom.com.hk: unreachable

[Peter Palfrader]

On Sun, 15 Oct 2017, Xiufeng Guo wrote:

> Can we apply for ftp.hk.debian.org now?

Updated DNS.

Reading
https://mirror-master.debian.org/status/mirror-info/mirror.xtom.com.hk.html
I think you are still running ftpsync out of cron.

However, mirror syncs now are started when triggered by ssh.

So you should probably disable the cron'ed launches of your mirror
script.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#839879: mtr FTCBFS: uses build architecture tools

[Robert Woodcock]

On 10/15/2017 10:50 AM, Samuel Henrique wrote:
> ​Hello everyone,
>
> I've just applied an updated version of Helmut's patch on another
> branch[1]
> But as you can see (if you build that branch), we have a problem
> because the packages will be installed under usr/sbin instead of usr/bin.
>
> I believe this behavior is provided by
> "--sbindir=`pwd`/debian/tmp/usr/bin " and the old
> override_dh_installdirs-arch override (that is, before patching), but
> i still did not find a way of fixing this*, so anyone please feel free
> to submit the fix or point me to the right direction.
>
> I believe this is the only blocker right now for 0.92, as soon as we
> fix this, we will release the new version.
>
> * to simply pass "--sbindir=`pwd`/debian/tmp/usr/bin" on
> auto_configure didn't work, i'm still trying to understand what is
> happening, but my bet is that i need to work with
> override_dh_installdirs-arch.
>
> [1]​https://anonscm.debian.org/git/collab-maint/mtr.git/commit/?h=debian/ftcbfs-helmut=c9e2825163d171e10ff7e1b74d17819a61c92ee6
>
>
>
> -- 
> Samuel Henrique 
I'll take a stab at that in the next few days.

Also, before we release - I'm not at all sold on the value of creating a
separate mtr-packet package - I'm pretty sure I want to put that back,
but we can discuss. It's only a few kb of disk savings on the mirrors
and it's disk wasted on an installed system. Currently we have
overlapping files between the mtr and mtr-packet packages and that
wouldn't even be a problem if we just folded mtr-packet in with the mtr
and mtr-tiny packages. At minimum, we need to get back to building mtr
twice rather than three times.

Bug#870631: (entry_text_shifted) wrong coordinates given to at-spi layer from GTK3 entries

[Samuel Thibault]

Control: tags -1 + fixed-upstream patch

Hello,

Alex ARNAUD, on jeu. 03 août 2017 17:53:31 +0200, wrote:
> Forwarded: https://bugzilla.gnome.org/show_bug.cgi?id=784509

Upstream commited a fix for this bug.

Just wondering: considering that it's just a few lines (as attached to
this mail) and the following usability impact:

> It is blocking for any a11y tool making these events accessible, like 
> software magnifiers such as gnome3 zoom or compiz's ezoom with focus tracking.
> result is unreadable by visually impaired people.

how do you feel about including the patch in sid already, and about
including it stretch or even jessie?

Samuel
commit 9af088693a5087a4d82fe14305d67444755b0fcc
Author: Samuel Thibault 
Date:   Thu Oct 5 15:49:00 2017 +

a11y/entry: Fix text coords not adjusted for alloc

What is missing is the "allocation" part of x/y coordinates. Since
gtk_entry_realize doesn't call gtk_widget_set_window(priv->text_area),
the coordinates returned by gdk_window_get_origin don't include it.

This patch fixes this.

https://bugzilla.gnome.org/show_bug.cgi?id=784509

diff --git a/gtk/a11y/gtkentryaccessible.c b/gtk/a11y/gtkentryaccessible.c
index abbaef8e9e..9519b091c5 100644
--- a/gtk/a11y/gtkentryaccessible.c
+++ b/gtk/a11y/gtkentryaccessible.c
@@ -971,11 +971,14 @@ gtk_entry_accessible_get_character_extents (AtkText  
*text,
   pango_layout_index_to_pos (gtk_entry_get_layout (entry), index, _rect);
   pango_extents_to_pixels (_rect, NULL);
 
+  GtkAllocation allocation;
+  gtk_widget_get_allocation (widget, );
+
   window = gtk_widget_get_window (widget);
   gdk_window_get_origin (window, _window, _window);
 
-  *x = x_window + x_layout + char_rect.x;
-  *y = y_window + y_layout + char_rect.y;
+  *x = x_window + allocation.x + x_layout + char_rect.x;
+  *y = y_window + allocation.y + y_layout + char_rect.y;
   *width = char_rect.width;
   *height = char_rect.height;
 

Bug#876739: pyfai FTBFS: help2man: can't get `--help' info from /tmp/check_calib_0hk8odnh

[Adrian Bunk]

Control: reopen -1

On Sun, Oct 15, 2017 at 06:23:35AM +, PICCA Frederic-Emmanuel wrote:
> This problem was due to this  
> 
> python-fabio (0.5.0+dfsg-2) unstable; urgency=medium
> 
>   * d/control
> - python-qt4 -> python3-pyqt4-dbg (Closes: #876288)
> 
> Now that python-fabio was solved, it is ok to close this bug

Still FTBFS with python-fabio 0.5.0+dfsg-2:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pyfai.html

> thanks
> 
> Frederic

cu
Adrian

-- 

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

Bug#876985: nautilus-dropbox: Remove Recommends on python-gpgme

[Dr. Tobias Quathamer]

Am 27.09.2017 um 13:47 schrieb Dr. Tobias Quathamer:
> If the successor "python-pgp" can be used as well with your package,

Daniel Kahn Gillmor spotted a typo in my e-mail. The successor package
is called python-gpg.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#878694: please drop transitional package monajat

[Holger Levsen]

Package: monajat
Version: 2.6.5-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package monajat for buster,
as it has been released with wheezy, jessie and stretch already.

Thanks for maintaining monajat!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#876984: python-samba: Remove Suggests on python-gpgme

[Dr. Tobias Quathamer]

Am 27.09.2017 um 13:47 schrieb Dr. Tobias Quathamer:
> If the successor "python-pgp" can be used as well with your package,

Daniel Kahn Gillmor spotted a typo in my e-mail. The successor package
is called python-gpg.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#878693: please drop transitional package minisat2

[Holger Levsen]

Package: minisat2
Version: 1:2.2.1-5
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package minisat2 for buster,
as it has been released with wheezy, jessie and stretch already.

Thanks for maintaining minisat2!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#876983: bmap-tools: Remove Recommends on python-gpgme

[Dr. Tobias Quathamer]

Am 27.09.2017 um 13:47 schrieb Dr. Tobias Quathamer:
> If the successor "python-pgp" can be used as well with your package,

Daniel Kahn Gillmor spotted a typo in my e-mail. The successor package
is called python-gpg.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#878689: please drop transitional package qtpfsgui

[Holger Levsen]

Package: qtpfsgui
Version: 2.4.0-9
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package qtpfsgui for buster,
as it has been released with wheezy, jessie and stretch already.

Thanks for maintaining luminance-hdr!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#878691: please drop transitional package m17n-contrib

[Holger Levsen]

Package: m17n-contrib
Version: 1.7.0-2
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package m17n-contrib for buster,
as it has been released with jessie and stretch already.

Thanks for maintaining m17n-db!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#878692: please drop transitional package mingw-ocaml

[Holger Levsen]

Package: mingw-ocaml
Version: 4.01.0~20140328-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package mingw-ocaml for buster,
as it has been released with jessie and stretch already.

Thanks for maintaining mingw-ocaml!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#878688: please drop transitional packages liblua5.1-bitop0 and liblua5.1-bitop-dev

[Holger Levsen]

Package: liblua5.1-bitop0,liblua5.1-bitop-dev
Version: 1.0.2-3
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional packages liblua5.1-bitop0 and liblua5.1-bitop-dev
for buster, as they have been released with wheezy, jessie and stretch already.

Thanks for maintaining lua-bitop!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#878687: please drop transitional package libtime-modules-perl

[Holger Levsen]

Package: libtime-modules-perl
Version: 2015.103-2
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package libtime-modules-perl for buster,
as it has been released with jessie and stretch already.

Thanks for maintaining libtime-parsedate-perl!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#876984: python-samba: Remove Suggests on python-gpgme

[Dr. Tobias Quathamer]

Am 15.10.2017 um 02:46 schrieb Daniel Kahn Gillmor:
> Just to be clear, the successor supported by GnuPG upstream is
> python-gpg (or, preferably, python3-gpg), not python-pgp.

Yes, of course. Thanks for spotting this typo, I'll follow up for the
other bugs as well.

> Thanks to Tobias for his triage work in encouraging this sort of
> cleanup in debian.

:-) Thanks!

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#878690: please drop transitional package lunch

[Holger Levsen]

Package: lunch
Version: 0.4.0-2
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package lunch for buster,
as it has been released with wheezy, jessie and stretch already.

Thanks for maintaining lunch!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#878686: please drop transitional package libtest-yaml-meta-perl

[Holger Levsen]

Package: libtest-yaml-meta-perl
Version: 0.22-2
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package libtest-yaml-meta-perl for buster,
as it has been released with wheezy, jessie and stretch already.

Thanks for maintaining libtest-yaml-meta-perl!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#878674: nodejs segfaults when building d3-* with webpack

[Jérémy Lal]

2017-10-15 18:36 GMT+02:00 Pirate Praveen :

> package: nodejs
> version: 6.11.4~dfsg-1
> severity: serious
>
> I have noticed this failure when building multiple node-d3-* packages
> (node-d3-zoom for example) and also installing gitlab 9.5 using webpack.
>
> When building the same node-d3-zoom with nodejs
> 7.10.1-2nodesource1~stretch1 the build passed. Tried both in local
> installation and using sbuild.
>
> Also tested the same on my laptop and on a vm
>
> babeljs src -d lib
> src/constant.js -> lib/constant.js
> src/event.js -> lib/event.js
> src/noevent.js -> lib/noevent.js
> src/transform.js -> lib/transform.js
> src/zoom.js -> lib/zoom.js
> babeljs index.js -d lib
> index.js -> lib/index.js
> sed -i 's/.\/src/./' lib/index.js
> webpack --config debian/webpack.config.js index.js build/d3-zoom.js
> --target=web --output-library=d3-zoom --output-library-target=umd
> --module-bind 'js=babel-loader'
> debian/rules:12: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Segmentation fault
> make[1]: Leaving directory '/<>'
> debian/rules:9: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
>
> Since babel and other dependencies are still in NEW, I have setup a repo
> for packages still in NEW.
>
> I have /usr/local/bin/sbuild-babel,
> sbuild -A -s -d unstable --extra-repository='deb
> https://people.debian.org/~praveen/babel sid main'
> --extra-repository-key=/home/pravi/forge/debian/babel/repo/praveen.key.asc
> $@
>
> With nodejs from nodesource.com, the build passes, both locally and in
> sbuild. For sbuild I have to pass --extra-package option and in
> debian/rules, I have to add export NODE_PATH=/usr/lib/nodejs
>
> node-d3-geo, node-d3-scale are other packages that segfaults.
>
> All node-d3-* packages are in pkg-javascript team repo in alioth.
>
>
Do you know if any dependency is a c++ addon ?

Jérémy

Bug#781308: xfce4-settings: Some keys on keyboard don't work after installing xfce4-settings 4.12.0-1

[Gabriel Corona]

Hi,

I investigated further and for me the bug is caused by this line in
~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml:



Binding this command to another key combination fixes the problem.

I still don't know why shortcut breaks an unrelated key and why
restarting xfsettings manually fixes the issue.

-- 
Gabriel

Bug#878685: stretch-pu: package udftools/1.3-2

[Pali Rohár]

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

Package udftools in version 1.3-1 has specified incorrect path to the
pktsetup binary in the /etc/init.d/udftools init script which cause that
init script does not work at all. Binary path was changed from bin to
sbin in upstream between 1.2 and 1.3 period.

It leads to the reported bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878180

This problem is fixed in the udftools version 1.3-2 which is now
available in the sid and buster. Diff between versions 1.3-1 and 1.3-2
is attached and contains just fix for this problem. Please update
udftools to version 1.3-2 also for stretch to make /etc/init.d/udftools
init script working again in stretch.

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

Kernel: Linux 4.9.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=sk_SK.UTF-8, LC_CTYPE=sk_SK.UTF-8 (charmap=UTF-8), LANGUAGE=sk_SK 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff -Nru udftools-1.3/debian/changelog udftools-1.3/debian/changelog
--- udftools-1.3/debian/changelog   2017-01-24 00:28:05.0 +0100
+++ udftools-1.3/debian/changelog   2017-10-03 21:41:57.0 +0200
@@ -1,3 +1,9 @@
+udftools (1.3-2) unstable; urgency=low
+
+  * Fix path to pktsetup in udftools init script
+
+ -- Pali Rohár   Tue, 03 Oct 2017 21:41:57 +0200
+
 udftools (1.3-1) unstable; urgency=low
 
   * New upstream release
diff -Nru udftools-1.3/debian/udftools.init udftools-1.3/debian/udftools.init
--- udftools-1.3/debian/udftools.init   2017-01-24 00:26:46.0 +0100
+++ udftools-1.3/debian/udftools.init   2017-10-03 21:40:26.0 +0200
@@ -30,7 +30,7 @@
 
 PATH=/sbin:/bin:/usr/sbin:/usr/bin
 DESC="udftools packet writing"
-PKTSETUP=/usr/bin/pktsetup
+PKTSETUP=/usr/sbin/pktsetup
 DEFAULTFILE=/etc/default/udftools
 DEVICES=""
 NEWINTNAMES="0 1 2 3"

Bug#875742: Debian mirror mirror.xtom.com.hk: unreachable

[Xiufeng Guo]

Hello,

Can we apply for ftp.hk.debian.org now?

-Original Message-
From: Peter Palfrader [mailto:wea...@debian.org] 
Sent: Tuesday, October 10, 2017 6:59 PM
To: Xiufeng Guo ; 875742-d...@bugs.debian.org
Subject: Re: Bug#875742: Debian mirror mirror.xtom.com.hk: unreachable

On Thu, 14 Sep 2017, Xiufeng Guo wrote:

> Yes, the old server's hard drives failed, we ordered new drivers and our 
> mirror will be back in a few days.

That mirror is back.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#878681: /bin/nano: Multiple files at once are opened very slowly (when user doesn't have write permissions)

[Benno Schulenberg]

Hello Thomas,

The bug has been fixed in nano-2.8.0 and above.  In those versions,
nano will by default not show more than three such warning messages,
so there will be at most three seconds of delay before you get to
see the first file.  When you add the option "set nopauses" to your
nanorc file, then nano will not pause at all between warnings and
you will get to see the first file immediately.

So... if you want the new behavior, you could set your package manager
to allow it to install nano from "testing" instead of from "stable".

Regards,

Benno

Bug#848050: TclTLS version 1.7.13 released

[Robby]

A new TclTLS version, 1.7.13, was released in september.

Regards,
Robby

Bug#878615: hol-light: installs .pc/ files into a binary package

[Hendrik Tews]

Thanks for the note! I'll take care of it in the next version.

Hendrik

Bug#878684: python3-libxml2: Import fails in Python 3 with error about undefined symbol

[Torquil Macdonald Sørensen]

Package: python3-libxml2
Version: 2.9.4+dfsg1-5
Severity: important

python3-libmlx2 doesn't work:

$ python3
Python 3.6.3 (default, Oct  3 2017, 21:16:13) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import libxml2
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/libxml2.py", line 1, in 
import libxml2mod
ImportError: 
/usr/lib/python3/dist-packages/libxml2mod.cpython-36m-x86_64-linux-gnu.so: 
undefined symbol: _PyVerify_fd
>>>

Best regards,
Torquil Sørensen

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

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

Versions of packages python3-libxml2 depends on:
ii  libc6 2.24-17
ii  libpython3.5  3.5.4-4
ii  libpython3.6  3.6.3-1
ii  libxml2   2.9.4+dfsg1-5
ii  python3   3.6.3-1

python3-libxml2 recommends no packages.

python3-libxml2 suggests no packages.

-- no debconf information

Bug#828475: openssh: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

On 2017-10-13 15:30:13 [+0100], Colin Watson wrote:
> That's basically the last I recall hearing, and that they were trying to
> put pressure on OpenSSL upstream.

I pinged upstream about the situation. I'm not sure if I made it worse
or not but I read something like "adding glue code to fetch and build
against libressl". 

> Also, Red Hat has maintainers paid to deal with forward-porting patches
> in Fedora, whereas I'm normally doing it in my limited spare time.  I
> don't mind that for patches that are smaller or easier to handle, but in
> my assessment this one would be fiddly to deal with as time goes on; the
> GSSAPI key exchange patch we're already carrying is complicated enough
> already and has sometimes caused delays of weeks or worse in me being
> able to merge new upstream versions, so I don't want to exacerbate that
> problem.

yup. I understand that part. My part here is also covered by spare time.

> There's the more complicated question of openssh-ssh1 as well, which is
> frozen at an old upstream version now that upstream has dropped SSH1
> support.  In that case I'm prepared to cherry-pick an upstream patch and
> hunt down the necessary extra adjustments for SSH1 support, but I still
> want it upstream first to minimise my liability to making
> security-relevant mistakes.
> 
> Does it help that OpenSSH only uses libcrypto, not libssh?  If somebody
> were to split out the headers relevant to libcrypto into a separate
> package, then it'd be possible for openssh to build-depend on that.  (I
> have no idea whether OpenSSL's headers are actually separable in this
> way.)

Well it looks to me that upstream does not want to use accessor which
are requried by openssl 1.1 because they don't need them. This is what
it looks like to me right now. What makes you think that they would
accept a split like that? They would never use it libssh version, they
probably would bypass that layer if they made a protocol change which is
not yet covered by the library. I assume here you do not plat to
maintain that patch yourself.

I've been pointed out to another way to go I hope you like it: There is
PKIX-SSH [0]. I am not sure if you are aware about that project but it
was news to me. I knew only about dropbear as an alternative server.
So, PKIX-SSH. This is an OpenSSH fork that compiles against OpenSSL 1.1.
Some features over OpenSSH:
- X.509 public key algorithms (legacy and RFC 6187).
- fine tuning of allowed algorithms
- FIPS (work with OpenSSL, Red Hat or Solaris fips-validated
  crypto-libraries)
- keys from engine (cryptographic loadable module)
- EC keys from PKCS#11 module  (secure token)
- LDAP based X.509 certificate store in addition to OpenSSL file and
  directory based. Used to build certificate chain.

So from what I could find out is that that forks follows upstream and
targets enterprices as a replacement of ssh.com (tectia-ssh).

I tried to build it as a Debian package and noticed that you have a few
patches on top. The gssapi patch is the largest one and from the
description it does not look like it goes upstream any time. The pkix
maintainer on the hand said the he would accept patches. So I have no
idea if he takes it all but it does not look that bad actually :)

[0] http://roumenpetrov.info/secsh/

Sebastian

Bug#878317: pygobject: FTBFS on sparc64 due to SIGBUS in testsuite

[James Clarke]

Control: tags -1 fixed-upstream

On Thu, Oct 12, 2017 at 07:27:39PM +0100, James Clarke wrote:
> Source: pygobject
> Version: 3.24.1-3
> Tags: upstream patch
> Forwarded: https://bugzilla.gnome.org/show_bug.cgi?id=788894
> User: debian-sp...@lists.debian.org
> Usertags: sparc64
> X-Debbugs-Cc: debian-sp...@lists.debian.org
>
> Hi,
> Currently, pygobject FTBFS on sparc64 due to performing an unaligned
> access during test_callback_scope_call_array_inout and thus crashing
> with SIGBUS. The above upstream bug report has a patch attached which
> fixes this and allows the package to build.

Upstream have now committed (a slightly modified to reflect post-3.24
changes version of) this patch.

Regards,
James

Bug#878683: src:lxc: FTBFS on x32

[Adam Borowski]

Package: src:lxc
Version: 1:2.0.8-3
Severity: important
Tags: patch
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid that x32 fails to build on x32.  It has an assumption that fields
of struct timespec are longs -- that's true on most architectures but not on
any added after kernel devs decided that the Y2038 bug should be fixed.

There's also a plan to change time_t on old 32-bit architectures, so it's
likely this failure would extend to more archs soon.

Here's a patch.  Unlike tv_sec, tv_nsec can't ever exceed 10⁹ thus a cast to
(long) is simple and correct.


Meow!
-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: x32 (x86_64)

Kernel: Linux 4.14.0-rc4-debug-00260-ga9ead0e01cab (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- lxc-2.0.8.orig/src/lxc/log.c
+++ lxc-2.0.8/src/lxc/log.c
@@ -154,7 +154,7 @@ int lxc_unix_epoch_to_utc(char *buf, siz
seconds = (time->tv_sec - d_in_s - h_in_s - (minutes * 60));
 
/* Make string from nanoseconds. */
-   ret = snprintf(nanosec, LXC_NUMSTRLEN64, "%ld", time->tv_nsec);
+   ret = snprintf(nanosec, LXC_NUMSTRLEN64, "%ld", (long)time->tv_nsec);
if (ret < 0 || ret >= LXC_NUMSTRLEN64)
return -1;
 

Bug#878682: RFS: bitz-server/1.0.0-5

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "bitz-server"


   Package name: bitz-server
   Version : 1.0.0-4
   Upstream Author : Uditha Atukorala 
   URL : https://github.com/uditha-atukorala/bitz-server
   License : GPL-3+
   Section : net

  It builds those binary packages:

   bitz-server - ICAP server (RFC 3507) implementation in C++
 bitz-server-doc - ICAP server (RFC 3507) implementation in C++ (Documentation)
 libicap-dev - ICAP server (RFC 3507) implementation in C++ (development files)
 libicap1   - ICAP server (RFC 3507) implementation in C++ (library files)



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

  https://mentors.debian.net/package/bitz-server


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

dget -x 
https://mentors.debian.net/debian/pool/main/b/bitz-server/bitz-server_1.0.0-5.dsc
git: 
https://anonscm.debian.org/cgit/collab-maint/bitz-server.git?h=release%2F1.0.0-5

  
  Changes since the last upload:

  * Renew symbols files.



  Regards,
   Jörg Frings-Fürst


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

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

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB
Wire:  @joergfringsfuerst
Skype: joergpenguin
Ring:  jff

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#877888: closed by Brian Potkin <claremont...@gmail.com> (Re: Bug#877888: cups-bsd: lpq and lp ignore the PRINTER environment variable)

[Sanjoy Mahajan]

> Thanks for doing that. As it happens, cups 2.2.5 is now in unstable so I
> re-tested. None of the issues we both observed appear to be present in
> this version. I have not looked closely to find the cause of the fix but
> it is a good note on which to close this report.

Maybe it was this commit?



-Sanjoy

Bug#878681: /bin/nano: Multiple files at once are opened very slowly (when user doesn't have write permissions)

[machine]

Package: nano
Version: 2.7.4-1
Severity: normal
File: /bin/nano

Dear maintainer,

I think that I have found a bug in GNU nano from the stable branch. If a normal 
user (not root) tries to open nano with more than one file at once, for which 
the current user (who executes nano) does not have write permissions, then the 
files will be opened, but very slowly. If you pass, for example, 10 filenames 
as argument, it takes about 10 seconds until you can edit the first file.

For example, create a new directory with some files somewhere in the file 
system (in this example, I'll use $HOME):
cd && mkdir demo && cd demo && touch {1,2,3,4,5,6}.test && chmod 444 
*.test

Now try to open all files at once for which you doesn't have write permissions 
because of chmod 444:
nano *

You'll notice, that the files are opened, but very slowly. Now change the 
permissions back to 644 (so that the current user has write permissions) and do 
it again (or use sudo nano *). You'll notice, that the problem doesn't appear 
if the user has write permissions:
chmod 644 *.test && nano *

This is my first bug report. I hope that I have explained everything correctly 
and that it helps you. Many Thanks!

Thomas \(o_o)/

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

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

Versions of packages nano depends on:
ii  libc6 2.24-11+deb9u1
ii  libncursesw5  6.0+20161126-1+deb9u1
ii  libtinfo5 6.0+20161126-1+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

nano recommends no packages.

Versions of packages nano suggests:
pn  spell  

-- no debconf information

Bug#863164: ITP: pydub -- Manipulate audio with a simple and easy high level interface

[Josue Ortega]

Hi,
Thanks for sharing your work!, I have uploaded the package, by now it
should be in NEW

Best Regards

---
Josue Ortega
«Happy Hacking»
http://josueortega.org

signature.asc
Description: PGP signature

Bug#878680: sqlite3: CVE-2017-15286: NULL pointer dereference in tableColumnList

[Salvatore Bonaccorso]

On Sun, Oct 15, 2017 at 08:25:55PM +0200, Salvatore Bonaccorso wrote:
> Attaching the poc.db.

... and if I claim that, I should do.

Now really attached.

Regards,
Salvatore


CVE-2017-15286-poc.db.xz
Description: application/xz

Bug#878680: sqlite3: CVE-2017-15286: NULL pointer dereference in tableColumnList

[Salvatore Bonaccorso]

Source: sqlite3
Version: 3.20.1-1
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for sqlite3.

CVE-2017-15286[0]:
| SQLite 3.20.1 has a NULL pointer dereference in tableColumnList in
| shell.c because it fails to consider certain cases where
| `sqlite3_step(pStmt)==SQLITE_ROW` is false and a data structure is
| never initialized.

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-2017-15286
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15286
[1] https://github.com/Ha0Team/crash-of-sqlite3/blob/master/poc.md
[2] http://www.sqlite.org/src/info/5d0ceb8dcdef92cd

Attaching the poc.db.

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#878679: Please remove me from uploaders

[Vincent Fourmond]

Package: imagemagick
Version: 8:6.9.7.4+dfsg-16
Severity: minor

  Dear imagemagick maintainers,

  Please remove me from the uploaders, I obviously haven't contributed
to imagemagick in a very long time, it makes no sense for me to still
be listed as uploader. I prefer to let you do the modification, I'm
too out of touch with the current state of the packages.

  Thanks,

  Vincent

Bug#878678: reportbug: [PATCH] Store SMTP password with libsecret if available

[Ville Skyttä]

Package: reportbug
Version: 7.1.7ubuntu1
Severity: wishlist

Dear Maintainer,

Attached is a 'git am'able patch that adds support for storing SMTP
passwords with libsecret if available. When stored this way, SMTP
passwords don't need to be specified at all in reportbugrc.

-- Package-specific info:
** Environment settings:
EDITOR="emacs"
PAGER="less"
DEBEMAIL="ville.sky...@iki.fi"
DEBFULLNAME="Ville Skytt\udcc3\udca4"
INTERFACE="text"

** /home/scop/.reportbugrc:
reportbug_version "7.1.7ubuntu1"
mode novice
ui text
smtphost "smtp.gmail.com:587"
smtpuser "vsky...@gmail.com"
smtppasswd 
smtptls
no-cc

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

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

Versions of packages reportbug depends on:
ii  apt1.5
ii  python33.6.3-0ubuntu2
ii  python3-reportbug  7.1.7ubuntu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
pn  debconf-utils   
pn  debsums 
pn  dlocate 
ii  emacs25-bin-common  25.2+1-6
ii  file1:5.32-1
ii  gir1.2-gtk-3.0  3.22.21-0ubuntu1
ii  gir1.2-vte-2.91 0.48.4-0ubuntu1
ii  gnupg   2.1.15-1ubuntu8
pn  postfix | exim4 | mail-transport-agent  
ii  python3-gi  3.24.1-2build1
ii  python3-gi-cairo3.24.1-2build1
pn  python3-gtkspellcheck   
pn  python3-urwid   
ii  xdg-utils   1.1.1-1ubuntu2

Versions of packages python3-reportbug depends on:
ii  apt1.5
ii  file   1:5.32-1
ii  python33.6.3-0ubuntu2
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.18.1-1

python3-reportbug suggests no packages.

-- no debconf information


0001-submit.py-Store-SMTP-password-with-libsecret-if-avai.patch.gz
Description: application/gzip

Bug#839879: mtr FTCBFS: uses build architecture tools

[Samuel Henrique]

​Hello everyone,

I've just applied an updated version of Helmut's patch on another branch[1]
But as you can see (if you build that branch), we have a problem because
the packages will be installed under usr/sbin instead of usr/bin.

I believe this behavior is provided by "--sbindir=`pwd`/debian/tmp/usr/bin
" and the old override_dh_installdirs-arch override (that is, before
patching), but i still did not find a way of fixing this*, so anyone please
feel free to submit the fix or point me to the right direction.

I believe this is the only blocker right now for 0.92, as soon as we fix
this, we will release the new version.

* to simply pass "--sbindir=`pwd`/debian/tmp/usr/bin" on auto_configure
didn't work, i'm still trying to understand what is happening, but my bet
is that i need to work with override_dh_installdirs-arch.

[1]​
https://anonscm.debian.org/git/collab-maint/mtr.git/commit/?h=debian/ftcbfs-helmut=c9e2825163d171e10ff7e1b74d17819a61c92ee6



-- 
Samuel Henrique