Bug#873673: stretch-pu: package pymad/0.9-1

[Jamie Wilkinson]

OK cool, thanks for the advice!

On 30 August 2017 at 15:42, Adam D. Barratt 
wrote:

> Control: tags -1 + moreinfo
>
> On Wed, 2017-08-30 at 11:05 +1000, Jamie Wilkinson wrote:
> > Version 0.9 of pymad contains a corruption bug that wasn't fixed until
> > 0.10.
> >
> > Stretch contains this bug, and is reported as debian bug #873160.
> >
> > Can you please pull pymad 0.10-1 into stretch?
>
> That's not something the Release Team can simply do, no. There always
> needs to be an upload for a package to get to proposed-updates.
>
> > If that is not possible, I can provide a text patch (identical to the
> > content at
> > https://github.com/jaqx0r/pymad/pull/9/commits/
> 5fa450e1cd561a16160458fb2e3af9bc75d4c3e4?diff=unified#diff-
> ff655086caf5ecffa7b506ef5c50410c ) to be applied for a NMU to 0.9-1.
>
> If you want to go that route, please provide the source debdiff for a
> package versioned as 0.9-1+deb9u1 with a changelog distribution of
> "stretch", containing the above patch and built against and tested on
> stretch.
>
> Regards,
>
> Adam
>
>

Bug#869200: Adequate still reports netdata as having obsolete conffile , maybe an adequate bug ?

[shirish शिरीष]

reopen 869200
thanks

Dear Federico Ceratto,
Adequate still reports the obsolete conffiles even after the upgrade.

[$] apt-cache policy netdata

netdata:
  Installed: 1.7.0+dfsg-1
  Candidate: 1.7.0+dfsg-1
  Version table:
 *** 1.7.0+dfsg-1 600
600 http://httpredir.debian.org/debian buster/main amd64 Packages
  1 http://httpredir.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status


─[$] adequate netdata | head -2
netdata: obsolete-conffile /etc/netdata/python.d/nginx_log.conf
netdata: obsolete-conffile /etc/netdata/python.d/gunicorn_log.conf

I have no idea whether it's adequate which is at fault or netdata.
Although would have to state that bugs/false positives for adequate
have been surprisingly small.

-- 
  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#873673: stretch-pu: package pymad/0.9-1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2017-08-30 at 11:05 +1000, Jamie Wilkinson wrote:
> Version 0.9 of pymad contains a corruption bug that wasn't fixed until
> 0.10.
> 
> Stretch contains this bug, and is reported as debian bug #873160.
> 
> Can you please pull pymad 0.10-1 into stretch?

That's not something the Release Team can simply do, no. There always
needs to be an upload for a package to get to proposed-updates.

> If that is not possible, I can provide a text patch (identical to the
> content at
> https://github.com/jaqx0r/pymad/pull/9/commits/5fa450e1cd561a16160458fb2e3af9bc75d4c3e4?diff=unified#diff-ff655086caf5ecffa7b506ef5c50410c
>  ) to be applied for a NMU to 0.9-1.

If you want to go that route, please provide the source debdiff for a
package versioned as 0.9-1+deb9u1 with a changelog distribution of
"stretch", containing the above patch and built against and tested on
stretch.

Regards,

Adam

Bug#870618: libfreetype6-dev: Remove freetype-config

[Steve Langasek]

Hi Hugh,

I'm taking a look at these patches now, prompted by the fact that Ubuntu's
incomplete multiarch transition for libfreetype6-dev has broken at least one
reverse-dependency in contrib (astromenace).

On Thu, Aug 03, 2017 at 12:12:43PM +, Hugh McMaster wrote:
> Package: libfreetype6-dev
> Version: 2.8-0.2
> Severity: wishlist

> Dear Maintainer,

> The package libfreetype6-dev is still not multi-arch compatible.

> In #666761, you stated that you will not accept patches that remove
> freetype- config, as the interface is used by reverse dependencies.

> This is no longer the case. I have examined all 41 reverse dependencies and
> none of them use freetype-config anymore.

It sounds like you've only looked at runtime dependencies.  The primary
concern is with packages that *build*-depend on libfreetype6-dev; there are
far more than 41 of those, I count 243 in main alone.

Are you willing to do a rebuild test of these reverse-dependencies against
libfreetype6-dev with freetype-config removed, to verify that none of them
regress?

> Please remove this interface from the package, so that we can move forward
> with marking libfreetype6-dev as Multi-Arch: same.

> Also, freetype2/freetype/config/ftconfig.h conflicts between arches and
> will need a resolution.  Matthias Klose suggested one possible patch in
> #666761.

That particular patch is the one in Ubuntu which regresses the astromenace
build.  I think I prefer your solution:

On Mon, Aug 28, 2017 at 02:49:22AM +, Hugh McMaster wrote:

> --- debian/rules  2017-08-27 17:59:43.522265000 +1000
> +++ debian/rules  2017-08-27 19:46:36.0 +1000
> @@ -83,6 +83,7 @@
>   dh_auto_build -D $(ft2demos_u) -- TOP_DIR=../$(freetype_u) \
>   OBJ_DIR=../$(freetype_u)/objs
>  endif
> + sed -i 's/\(\#define SIZEOF_LONG\).*/\1 __SIZEOF_LONG__/' 
> $(freetype_u)/builds/unix/ftconfig.h
>  
>  override_dh_auto_clean:
>   rm -f unpack-stamp patch-stamp

I would prefer to see this as a patch to the source, not as post-processing
from debian/rules.  However, that means a bit of fiddling in
builds/unix/configure.ac, so I'm ok to proceed with this approach for now.

> --- debian/libfreetype6-dev.install   2017-08-27 19:46:36.0 +1000
> +++ debian/libfreetype6-dev.install   2017-08-27 19:51:15.455532188 +1000
> @@ -1,8 +1,6 @@
> -usr/bin/freetype-config
>  usr/include/
>  usr/lib/*/*.so
>  usr/lib/*/*.la
>  usr/lib/*/*.a
>  usr/lib/*/pkgconfig/
>  usr/share/aclocal/
> -/usr/share/man/man1/freetype-config.1

This still needs checking to be sure it doesn't regress
reverse-build-dependencies.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#873627: udisks2 in sid apparently left me with a borked system in plasma(?)

[Daniel Schaal]

I'm experiencing the same issue. I attached the log output and the 
backtrace of the coredump.


After installing the missing plugins (libblockdev-* packages) it 
complains about, I don't get this issue anymore.


syslog output:
-
Starting Disk Manager...
udisks daemon version 2.7.2 starting
failed to load module mdraid: libbd_mdraid.so.2: cannot open shared 
object file: No such file or directory

Cannot load the part plugin: The 'sgdisk' utility is not available
failed to load module fs: libbd_fs.so.2: cannot open shared object file: 
No such file or directory
Error initializing libblockdev library: Failed to load plugins 
(g-bd-init-error-quark, 0)
traps: udisksd[2390] trap int3 ip:7f77dd711921 sp:7ffce682cbd0 error:0 
in libglib-2.0.so.0.5306.0[7f77dd6c1000+111000]

Started Process Core Dump (PID 2395/UID 0).
udisks2.service: Main process exited, code=dumped, status=5/TRAP
Failed to start Disk Manager.
udisks2.service: Unit entered failed state.
udisks2.service: Failed with result 'core-dump'.
--

Backtrace:
-
#0  _g_log_abort (breakpoint=breakpoint@entry=1) at 
../../../../glib/gmessages.c:554
#1  0x7fd1ff261f41 in g_log_writer_default (log_level=6, 
log_level@entry=G_LOG_LEVEL_ERROR, fields=fields@entry=0x7ffc32a375a0, 
n_fields=n_fields@entry=3, user_data=user_data@entry=0x0)

at ../../../../glib/gmessages.c:2628
#2  0x7fd1ff2604be in g_log_structured_array 
(log_level=G_LOG_LEVEL_ERROR, fields=0x7ffc32a375a0, n_fields=3) at 
../../../../glib/gmessages.c:1941
#3  0x7fd1ff2607b7 in g_log_structured (log_domain=0x55ea532e0c08 
"udisks", log_level=G_LOG_LEVEL_ERROR) at ../../../../glib/gmessages.c:1768

#4  0x55ea532d8e9b in udisks_log ()
#5  0x55ea532ad74f in ?? ()
#6  0x7fd1ff538510 in g_object_new_internal 
(class=class@entry=0x55ea53e38c00, params=params@entry=0x7ffc32a38060, 
n_params=n_params@entry=4) at ../../../../gobject/gobject.c:1821
#7  0x7fd1ff53a4e0 in g_object_new_valist 
(object_type=94464918131104, first_property_name=, 
var_args=var_args@entry=0x7ffc32a381b0) at 
../../../../gobject/gobject.c:2104
#8  0x7fd1ff53a859 in g_object_new (object_type=, 
first_property_name=) at ../../../../gobject/gobject.c:1624

#9  0x55ea532add55 in udisks_daemon_new ()
#10 0x55ea532aceab in ?? ()
#11 0x7fd1ff83de74 in connection_get_cb (source_object=out>, res=0x55ea53e41030, user_data=0x55ea53e34e70) at 
../../../../gio/gdbusnameowning.c:487
#12 0x7fd1ff801fd3 in g_task_return_now (task=0x55ea53e41030) at 
../../../../gio/gtask.c:1145
#13 0x7fd1ff8029f6 in g_task_return (task=0x55ea53e41030, 
type=) at ../../../../gio/gtask.c:1203
#14 0x7fd1ff830b92 in bus_get_async_initable_cb 
(source_object=0x55ea53e42070, res=, 
user_data=0x55ea53e41030) at ../../../../gio/gdbusconnection.c:7302
#15 0x7fd1ff801fd3 in g_task_return_now (task=0x55ea53e41100) at 
../../../../gio/gtask.c:1145
#16 0x7fd1ff802009 in complete_in_idle_cb (task=0x55ea53e41100) at 
../../../../gio/gtask.c:1159
#17 0x7fd1ff259dd5 in g_main_dispatch (context=0x55ea53e34200) at 
../../../../glib/gmain.c:3148
#18 g_main_context_dispatch (context=context@entry=0x55ea53e34200) at 
../../../../glib/gmain.c:3813
#19 0x7fd1ff25a1a0 in g_main_context_iterate 
(context=0x55ea53e34200, block=block@entry=1, dispatch=dispatch@entry=1, 
self=) at ../../../../glib/gmain.c:3886
#20 0x7fd1ff25a4b2 in g_main_loop_run (loop=0x55ea53e341d0) at 
../../../../glib/gmain.c:4082

#21 0x55ea532acc21 in main ()
---

Thanks,
Daniel

Bug#873686: watcher: French debconf translation update

[Alban Vidal]

Package: watcher
Version: 0.30.0-5
Severity: wishlist
Tags: patch l10n

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

Best regards

Alban Vidal
# Translation of watcher debconf templates to French.
# Copyright (C) 2013, 2017, French l10n team 

# This file is distributed under the same license as the Watcher package.
#
# Translators:
# Julien Patriarca , 2013.
# Alban Vidal , 2017.
msgid ""
msgstr ""
"Project-Id-Version: watcher 0.30.0-5\n"
"Report-Msgid-Bugs-To: watc...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 12:24+\n"
"PO-Revision-Date: 2017-08-24 20:02+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 2.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid "Set up a database for Watcher?"
msgstr "Voulez-vous installer une base de données pour Watcher ?"

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
"No database has been set up for Watcher to use. Before continuing, you "
"should make sure you have the following information:"
msgstr ""
"Aucune base de données n’est configurée que Watcher puisse utiliser. Avant "
"de continuer, assurez-vous de disposer des informations suivantes :"

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" – le type de base de données que vous souhaitez utiliser ;\n"
" – le nom d'hôte du serveur de base de données (ce serveur doit accepter les "
"connexions TCP depuis cette machine) ;\n"
" – un nom d'utilisateur et un mot de passe pour accéder à cette base de "
"données."

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Si certains de ces prérequis sont manquants, ignorez cette option et "
"exécutez l'application avec la prise en charge de SQLite standard."

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"watcher\"."
msgstr ""
"Vous pouvez modifier ce réglage plus tard en lançant « dpkg-reconfigure -"
"plow watcher »."

#. Type: string
#. Description
#: ../watcher-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nom d'hôte du serveur d'authentification :"

#. Type: string
#. Description
#: ../watcher-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Veuillez indiquer le nom d'hôte de votre serveur d'authentification. En "
"général, c'est également le nom d'hôte de votre Service d'Identité "
"d'OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../watcher-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nom du projet (« tenant ») sur le serveur d'authentification :"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../watcher-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr ""
"Veuillez indiquer le nom du projet (« tenant ») sur le serveur "
"d’authentification."

#. Type: string
#. Description
#: ../watcher-common.templates:5001
msgid "Authentication server username:"
msgstr "Nom d'utilisateur pour le serveur d'authentification :"

#. Type: string
#. Description
#: ../watcher-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Veuillez indiquer le nom d'utilisateur à utiliser sur le serveur "
"d'authentification."

Bug#873685: webalizer: French debconf translation update

[Alban Vidal]

Package: webalizer
Version: 2.23.08-2
Severity: wishlist
Tags: patch l10n

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

Best regards

Alban Vidal
# Translation of webalizer debconf templates to French.
# Copyright (C) 2003, 2006, 2017, French l10n team 

# This file is distributed under the same license as the webalizer package.
#
# Translators:
# Christian Perrier , 2003.
# Gregory Colpart , 2006.
# Alban Vidal , 2017.
msgid ""
msgstr ""
"Project-Id-Version: webalizer 2.23.08-2\n"
"Report-Msgid-Bugs-To: webali...@packages.debian.org\n"
"POT-Creation-Date: 2013-11-17 23:24+0100\n"
"PO-Revision-Date: 2017-08-24 19:40+0200\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
"X-Generator: Lokalize 2.0\n"

#. Type: note
#. Description
#: ../templates:1001
msgid "Upgrading from a version < 2.01.6"
msgstr "Mise à niveau depuis une version inférieure à 2.01.6"

#. Type: note
#. Description
#: ../templates:1001
msgid ""
"WARNING: If you're upgrading from a version < 2.01.6, see /usr/share/doc/"
"webalizer/README.FIRST.gz for details on upgrading your old data!!"
msgstr ""
"ATTENTION : si vous mettez à niveau le programme depuis une version "
"inférieure à 2.01.6, veuillez consulter /usr/share/doc/webalizer/README."
"FIRST.gz pour obtenir des informations sur la méthode de mise à niveau de "
"vos anciennes données."

#. Type: note
#. Description
#: ../templates:2001
msgid "Upgrading from a version < 2.01.10-30"
msgstr "Mise à niveau depuis une version inférieure à 2.01.10-30"

#. Type: note
#. Description
#: ../templates:2001
msgid ""
"WARNING: This release will move webalizer.conf file to /etc/webalizer  "
"directory.  New features have been included, too. Please read README.FIRST."
"gz, README.gz and new examples/sample.conf.gz in /usr/share/doc/webalizer "
"directory."
msgstr ""
"ATTENTION : cette version déplace le fichier webalizer.conf vers le "
"répertoire /etc/webalizer. De nouvelles fonctionnalités apparaissent "
"également. Veuillez lire les fichiers README.FIRST.gz, README.gz et le "
"nouveau fichier examples/sample.conf.gz, situés dans le répertoire /usr/share/"
"doc/webalizer."

#. Type: string
#. Description
#: ../templates:3001
msgid "Directory to put the output in:"
msgstr ""
"Veuillez indiquer le répertoire où sera stockée la sortie de webalizer :"

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Generate a default configuration file ?"
msgstr "Voulez-vous générer un fichier de configuration par défaut ?"

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"Note that webalizer always parses the default configuration, so if you plan "
"on using more than one configuration or using the -c parameter, you probably "
"want to say No here."
msgstr ""
"Notez que webalizer va toujours analyser le fichier de configuration par "
"défaut, donc si vous prévoyez d'utiliser plus d'un fichier de configuration "
"ou d'utiliser le paramètre -c, vous voulez probablement répondre « Non » à "
"cette question."

#. Type: string
#. Default
#: ../templates:5001
msgid "Usage Statistics for[ hostname will be appended ]"
msgstr "Statistiques d'utilisation de [ NomDeMachine ]"

#. Type: string
#. Description
#: ../templates:5002
msgid "Title of the reports webalizer will generate:"
msgstr "Veuillez indiquer le titre des rapports créés par webalizer :"

#. Type: string
#. Description
#: ../templates:5002
msgid "(your system's hostname will be appended to it)"
msgstr ""
"(Le nom d'hôte de votre machine sera ajouté à ce titre à la place de "
"[ NomDeMachine ])"

#. Type: string
#. Description
#: ../templates:6001
msgid "Webserver's rotated log filename:"
msgstr "Veuillez indiquer le nom du journal du serveur web après rotation :"

#. Type: boolean
#. Description
#: ../templates:7001
msgid "Enable DNSCache Option?"
msgstr "Voulez-vous activer l'option DNSCache ?"

#. Type: boolean
#. Description
#: ../templates:7001
msgid ""
"Speed up name resolving with the DNSCache option enabled. See /usr/share/doc/"
"webalizer/DNS.README.gz for more information."
msgstr ""
"Choisir l'option DNSCache accélère la résolution de noms. Veuillez lire le "
"fichier /usr/share/doc/webalizer/DNS.README.gz pour plus d'informations."

Bug#873684: slapd fails to upgrade if SLAPD_CONF is an empty directory

[Ryan Tandy]

Package: slapd
Version: 2.4.44+dfsg-1

Preparing to unpack .../slapd_2.4.44+dfsg-5+deb9u1_amd64.deb ...
Saving current slapd configuration to /var/backups/slapd-2.4.44+dfsg-5...
slapcat: bad configuration directory!
dpkg: error processing archive 
/var/cache/apt/archives/slapd_2.4.44+dfsg-5+deb9u1_amd64.deb (--unpack):
subprocess new pre-installation script returned error exit status 1
 Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.44+dfsg-5+deb9u1... 
done.

The ppolicy upgrade check (for upgrades from pre-2.4.43) wants to 
slapcat the config database so that it can check for an instance of 
ppolicy, but an empty directory is not a valid config.


I guess the only sane thing to do there is ignore slapcat failure. The 
service won't start if the config is broken, but it might be disabled 
another way, and shouldn't prevent upgrading slapd (might be required in 
order to upgrade unrelated packages).


Should avoid dump_config at all in preinst if we don't actually need it, 
but that's an optimization rather than a bugfix.

Bug#873683: slapd.prerm prints an error on remove if SLAPD_CONF doesn't exist

[Ryan Tandy]

Package: slapd
Version: 2.4.44+dfsg-4
Severity: minor

Removing slapd (2.4.45+dfsg-1) ...
[warn] No configuration file was found for slapd at /etc/ldap/slapd.conf. ... 
(warning).
 Dumping to /var/backups/slapd-2.4.45+dfsg-1:
grep: /etc/ldap/slapd.d/cn=config/olcDatabase*.ldif: No such file or directory

The error is not fatal and doesn't prevent the package being removed, 
it's just annoying. Upgrades are not affected, they just treat a missing 
config directory as a clean install.

Bug#853285: closed by Clint Adams <cl...@debian.org> (Bug#853285: fixed in ghc 8.0.2-3)

[Helmut Grohne]

On Tue, Aug 29, 2017 at 10:44:51PM +0100, James Clarke wrote:
> I believe is this because haskell-devscripts-minimal is arch:all, so any
> architecture information does not propagate through. If my understanding is
> correct, making haskell-devscripts-minimal an arch:any package and using a
> :native Build-Depends on haskell-devscripts-minimal would fix this, but I'm
> sure Helmut can clarify?

All of that is correct. Still I don't see that as a good solution for
several reasons:

 * After doing so, every package that uses haskell-devscripts-minimal
   (or haskell-devscripts) will have to annotate its build dependency
   with :native. There are lots of reverse dependencies. I am still
   hoping for a way that causes less churn in the archive.

 * The obvious alternative is to just mark it Multi-Arch: foreign. This
   is not a new idea indeed #769377. Unfortunately it is wrong, because
   the tools in there are architecture-dependent (via exposing ghc
   stuff). From what I learned with pkg-config, cmake and others, I
   guess we'll mark it M-A:foreign anyway and document how to avoid
   issues with architecture-awareness, but this certainly needs more
   work.

 * We'll likely need ghc-for-build and ghc-for-host for a proper
   solution. Since ghc depends on gcc, we also need gcc-for-build and
   gcc-for-host. The latter was blocked by waiting for
   binutils-for-build and binutils-for-host until very recently. Making
   that work for gcc will be a little more work. Any volunteers? ;)

Helmut

Bug#873682: slapd fails to stop if SLAPD_CONF is empty directory

[Ryan Tandy]

Package: slapd
Version: 2.4.21-1

Originally reported in Ubuntu: https://bugs.launchpad.net/bugs/1702290

If SLAPD_CONF exists and is a directory, but cn=config.ldif is not 
present inside it, slapd fails to stop. This can prevent the package 
from being removed/purged until the directory is deleted by hand.


Removing slapd (2.4.45+dfsg-1) ...
sed: can't read /etc/ldap/slapd.d/cn=config.ldif: No such file or directory
invoke-rc.d: initscript slapd, action "stop" failed.
dpkg: error processing package slapd (--remove):
subprocess installed pre-removal script returned error exit status 2

Bug#873681: ruby-rest-client tests fail if global proxy is set in environment

[Steve Langasek]

Package: ruby-rest-client
Version: 2.0.2-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch autopkgtest

The Ubuntu autopkgtest infrastructure uses an http proxy for Internet
access, which means ruby-rest-client automatically picks up the proxy from
the enviroment and uses it.  Unfortunately, the upstream tests don't *pass*
if a global proxy is set.

Attached is a patch that has been applied to Ubuntu to mock the environment
for two autopkgtests that are sensitive to this environment setting.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ruby-rest-client-2.0.2/debian/patches/proxy-proof-tests.patch 
ruby-rest-client-2.0.2/debian/patches/proxy-proof-tests.patch
--- ruby-rest-client-2.0.2/debian/patches/proxy-proof-tests.patch   
1969-12-31 16:00:00.0 -0800
+++ ruby-rest-client-2.0.2/debian/patches/proxy-proof-tests.patch   
2017-08-29 21:15:28.0 -0700
@@ -0,0 +1,30 @@
+Description: Fix tests to pass cleanly when http_proxy is set in the env
+ An autopkgtest environment may have a global proxy set for access to the
+ Internet.  Our tests should not fail if this is the case.  Mock the
+ environment so that we're not inadvertently testing the wrong thing.
+Author: Steve Langasek 
+
+Index: ruby-rest-client-2.0.2/spec/unit/request_spec.rb
+===
+--- ruby-rest-client-2.0.2.orig/spec/unit/request_spec.rb
 ruby-rest-client-2.0.2/spec/unit/request_spec.rb
+@@ -579,6 +579,9 @@
+ end
+ 
+ it "creates a non-proxy class if a proxy url is not given" do
++  allow(ENV).to receive(:[]).with("HTTP_PROXY").and_return(nil)
++  allow(ENV).to receive(:[]).with("http_proxy").and_return(nil)
++  allow(ENV).to receive(:[]).with("NETRC").and_return(nil)
+   expect(@proxy_req.net_http_object('host', 80).proxy?).to be_falsey
+ end
+ 
+@@ -592,6 +595,9 @@
+ end
+ 
+ it "sets proxy on a per-request basis" do
++  allow(ENV).to receive(:[]).with("HTTP_PROXY").and_return(nil)
++  allow(ENV).to receive(:[]).with("http_proxy").and_return(nil)
++  allow(ENV).to receive(:[]).with("NETRC").and_return(nil)
+   expect(@proxy_req.net_http_object('some', 80).proxy?).to be_falsey
+ 
+   req = RestClient::Request.new(:method => :put, :url => 
'http://some/resource', :payload => 'payload', :proxy => 'http://example.com')
diff -Nru ruby-rest-client-2.0.2/debian/patches/series 
ruby-rest-client-2.0.2/debian/patches/series
--- ruby-rest-client-2.0.2/debian/patches/series2017-07-25 
23:24:23.0 -0700
+++ ruby-rest-client-2.0.2/debian/patches/series2017-08-29 
21:04:31.0 -0700
@@ -1,2 +1,3 @@
 disable-network-tests.patch
 no-git-in-gemspec.patch
+proxy-proof-tests.patch

Bug#873466: jessie-pu: package unbound/1.4.22-3+deb8u3

[Robert Edmonds]

Adam D. Barratt wrote:
> On Mon, 2017-08-28 at 00:38 -0400, Robert Edmonds wrote:
> > I'd like to update jessie's unbound with a fix for the same RFC 5011
> > issue described in #873371 for stretch, fast-tracked via the *-updates
> > mechanism due to the time component of the bug. Please see attached a
> > debdiff for unbound 1.4.22-3+deb8u3.
> > 
> > The fix for jessie requires an additional patch adding the root zone
> > trust anchor KSK-2017 to the unbound-anchor utility. This change is
> > nearly identical to a freeze exemption approved for stretch, #855635.
> 
> Please go ahead.

Uploaded. Thanks!

-- 
Robert Edmonds
edmo...@debian.org

Bug#873680: gaupol: Gtk-WARNING warnings in gaupol

[shirish शिरीष]

Package: gaupol
Version: 1.2-1
Severity: normal

Dear Maintainer,

I get the following message each time I start gaupol and get constant
reminders on the console  -

(python3:12069): Gtk-WARNING **: Allocating size to
GtkApplicationWindow 0x55e19b4ea2c0 without calling
gtk_widget_get_preferred_width/height(). How does the code know the
size to allocate?

Please fix the issue.


-- System Information:
Debian Release: buster/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)
Foreign Architectures: i386

Kernel: Linux 4.12.0-1-amd64 (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 gaupol depends on:
ii  gir1.2-glib-2.0  1.50.0-2
ii  gir1.2-gst-plugins-base-1.0  1.12.2-1
ii  gir1.2-gstreamer-1.0 1.12.2-1
ii  gir1.2-gtk-3.0   3.22.18-1
ii  gstreamer1.0-plugins-good1.12.2-1
ii  python3  3.5.3-3
ii  python3-aeidon   1.2-1
ii  python3-gi   3.22.0-2+b1
ii  python3-gi-cairo 3.22.0-2+b1

Versions of packages gaupol recommends:
ii  gir1.2-gtkspell3-3.0   3.0.9-1
ii  gstreamer1.0-libav 1.12.2-1
ii  gstreamer1.0-plugins-bad   1.12.2-1+b1
ii  gstreamer1.0-plugins-ugly  1.12.2-1
ii  python3-chardet3.0.4-1
ii  python3-enchant1.6.7-1

Versions of packages gaupol suggests:
ii  mplayer  2:1.3.0-6+b3
ii  mpv  0.26.0-3
ii  vlc  2.2.6-3+b1

-- 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#806514: ITP: fontmath -- collection of objects that implement fast font, glyph, etc.

[Yao Wei]

Control: retitle -1 ITP: fontmath -- collection of objects that implement fast 
font, glyph, etc.
Control: owner -1 !

I am going to fulfill the dependency of glyphsLib (#868005), and this is
one of the missing puzzles.

On Sat, 28 Nov 2015 18:43:33 +0900 Hideki Yamane  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Hideki Yamane 
> 
> * Package name: fontmath
>   Version : 0.2~20151123
>   Upstream Author : Tal Leming 
> * URL : https://github.com/typesupply/fontMath
> * License : MIT
>   Programming Lang: Python
>   Description : collection of objects that implement fast font, glyph, 
> etc.
> 
>  A set of objects for performing math operations on font data.
> 
> 


signature.asc
Description: PGP signature

Bug#873679: dislocker: libdislocker* renamed without transition packages

[Giovani Augusto Ferreira]

Package: src:dislocker
Version: 0.7.1-1
Severity: serious

The libdislocker* packages were renamed without following
the guidelines at https://wiki.debian.org/RenamingPackages
and this will cause failures during upgrade.

This RC bug is to prevent migration to testing until the new
Debian revision exits the NEW queue and resolves this.

Best regards,

Giovani

Bug#868005: RFP: glyphsLib -- Library for opening and converting Glyphs font sources

[Yao Wei]

Control: retitle -1 ITP: glyphsLib -- Library for opening and converting Glyphs 
font sources
Control: owner -1 !
Control: block -1 by 806503 806513 806514 870878

I would like to upload this after uploading the dependencies.

On Mon, 10 Jul 2017 22:01:38 -0700 James Godfrey-Kittle  
wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: glyphsLib
>   Version : 1.7.5
>   Upstream Author : Google Internationalization Team
> * URL : https://github.com/googlei18n/glyphsLib
> * License : Apache-2.0
>   Programming Lang: Python
>   Description : Library for opening and converting Glyphs font sources
> 
> This library can open and manipulate Glyphs font source files
> (.glyphs), and provides a tool for exporting these sources to the UFO
> format.
> 
> 


signature.asc
Description: PGP signature

Bug#806503: ITP: mutatormath -- calculation of piecewise linear interpolations in n-dimensions with masters

[Yao Wei]

Control: owner -1 !
Control: retitle -1 mutatormath -- calculation of piecewise linear 
interpolations in n-dimensions with masters

Hi,

I am going to fulfill the dependency for glyphslib (#868005). This is
one of them.

Yao Wei

On Sat, 28 Nov 2015 12:45:39 +0900 Hideki Yamane  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Hideki Yamane 
> 
> * Package name: mutatormath
>   Version : 0.0.1~20151122
>   Upstream Author : Erik van Blokland 
> * URL : https://github.com/LettError/MutatorMath
> * License : BSD-3-clause
>   Programming Lang: Python
>   Description : calculation of piecewise linear interpolations in 
> n-dimensions with masters
> 
>  MutatorMath is a Python library for the calculation of piecewise linear
>  interpolations in n-dimensions with any number of masters. 
>  It was developed for interpolating data related to fonts, but if can handle
>  any arithmetic object.
> 
> 


signature.asc
Description: PGP signature

Bug#867132: firmware-iwlwifi: Bluetooth does not work but WiFi does with Intel 7265 (rev 59)

[Benjamin Downey]

The Lenovo Yoga model is 80V6000PUS

(and roger on not putting it against firmware packages in the future)

On Sun, Aug 27, 2017 at 1:15 PM, Ben Hutchings  wrote:

> Control: reassign -1 src:linux 4.9.30-2+deb9u2
> Control: retitle -1 Missing Bluetooth device on Lenovo Yoga - ideapad
> driver bug?
> Control: tag -1 moreinfo
>
> On Mon, 03 Jul 2017 22:52:12 -0400 Benjamin Downey  nisila.com> wrote:
> [...]
> > Using a lenovo yoga with an intel 7265 wifi chip and kernel
> 4.9.30-2, bluetooth
> > does not work while wifi works. This is the same issue as in Ubuntu
> > Bug#1643455. The hardware works in windows on this machine.
>
> Please be more specific.  Which Lenovo Yoga model?
>
> (Also, please file driver/kernel bugs with 'reportbug kernel', not
> against firmware packages.)
>
> Ben.
>
> --
> Ben Hutchings
> Teamwork is essential - it allows you to blame someone else.
>

Bug#806513: ITP: defcon -- set of UFO based objects for use in font editing applications

[魏銘廷]

retitle 806513 ITP: defcon -- set of UFO based objects for use in font editing 
applications
owner 806513 !
thanks

Since its dependency ufolib is going to be uploaded soon, I am going to
package this.

Yao Wei


signature.asc
Description: PGP signature

Bug#873623: sudo: occasionally stalls infinitely instead of running command

[Bob Proulx]

Alban Browaeys wrote:
> This is likely sssd related.
> 
> I upgraded both today (sssd to 1.15.3-1) and "sudo ls" output was empty.
>
> Local workaround was to comment out "sss" on /etc/nsswitch.conf "sudoers:"
> sudoers:files sss
> to
> sudoers:files #sss

While sss might be involved additionally I reproduce the problem on my
system and I do not have sssd installed at all.  The sudo problem is
independent of sssd.  There is no sssd installed on my system which
also exhibits the sudo hang problem.

Bob

Bug#873677: wslay: FTBFS on kFreeBSD: epoll is required

[Aaron M. Ucko]

Source: wslay
Version: 1.0.1~39-g6abacc1-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of wslay for kFreeBSD and the Hurd (admittedly not release
architectures) have been failing:

  -- Looking for include file sys/epoll.h
  -- Looking for include file sys/epoll.h - not found
  CMake Error at examples/CMakeLists.txt:6 (message):
epoll is required

Please either allow wslay to fall back to traditional poll or restrict
its Architecture field to linux-any so that autobuilders for other
architectures don't bother trying to build it.

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#873676: breezy: FTBFS: test_unicode_commit_message_is_filename fails in C locale

[Aaron M. Ucko]

Source: breezy
Version: 3.0.0~bzr6753-1
Severity: serious
Justification: fails to build from source

Builds of breezy under the traditional C locale (as on the
autobuilders, implicitly) have been failing as detailed below.  Please
try arranging for debian/rules to export LC_ALL=C.UTF-8, which should
be available by default (via libc-bin) these days.

Thanks!

==
ERROR: 
breezy.tests.blackbox.test_commit.TestCommit.test_unicode_commit_message_is_filename
--
Traceback (most recent call last):
testtools.testresult.real._StringException: log: {{{
19.942  run brz: ['init']
19.942  breezy version: 3.0.0dev1
19.943  brz arguments: [u'init']
19.960  creating repository in 
file:///tmp/testbzr-qu2rYD.tmp/breezy.tests.blackbox.test_commit.TestCommit.test_unicode_commit_message_is_filename/work/.bzr/.
19.965  creating branch  in 
file:///tmp/testbzr-qu2rYD.tmp/breezy.tests.blackbox.test_commit.TestCommit.test_unicode_commit_message_is_filename/work/
19.983  trying to create missing lock 
'/tmp/testbzr-qu2rYD.tmp/breezy.tests.blackbox.test_commit.TestCommit.test_unicode_commit_message_is_filename/work/.bzr/checkout/dirstate'
19.984  opening working tree 
'/tmp/testbzr-qu2rYD.tmp/breezy.tests.blackbox.test_commit.TestCommit.test_unicode_commit_message_is_filename/work'
20.000  opening working tree 
'/tmp/testbzr-qu2rYD.tmp/breezy.tests.blackbox.test_commit.TestCommit.test_unicode_commit_message_is_filename/work'
20.004  output:
'Created a standalone tree (format: 2a)\n'
20.005  run brz: ['add']
20.005  breezy version: 3.0.0dev1
20.005  brz arguments: [u'add']
20.015  opening working tree 
'/tmp/testbzr-qu2rYD.tmp/breezy.tests.blackbox.test_commit.TestCommit.test_unicode_commit_message_is_filename/work'
20.027  skip control directory '.bzr'
20.027  creating config directory: 
'/tmp/testbzr-qu2rYD.tmp/breezy.tests.blackbox.test_commit.TestCommit.test_unicode_commit_message_is_filename/home/breezy'
20.032  output:
'adding "?"\n'
20.032  run brz: ['commit', '-m', u'\u20ac']
20.032  breezy version: 3.0.0dev1
20.032  brz arguments: [u'commit', u'-m', u'\u20ac']
20.044  opening working tree 
'/tmp/testbzr-qu2rYD.tmp/breezy.tests.blackbox.test_commit.TestCommit.test_unicode_commit_message_is_filename/work'
}}}

Traceback (most recent call last):
  File 
"/<>/build/lib.linux-aarch64-2.7/breezy/tests/blackbox/test_commit.py",
 line 144, in test_unicode_commit_message_is_filename
out, err = self.run_bzr(['commit', '-m', file_name])
  File "/<>/build/lib.linux-aarch64-2.7/breezy/tests/__init__.py", 
line 2021, in run_bzr
working_dir=working_dir,
  File "/<>/build/lib.linux-aarch64-2.7/breezy/tests/__init__.py", 
line 1923, in _run_bzr_autosplit
encoding=encoding, stdin=stdin, working_dir=working_dir,
  File "/<>/build/lib.linux-aarch64-2.7/breezy/tests/__init__.py", 
line 1965, in _run_bzr_core
args)
  File "/<>/build/lib.linux-aarch64-2.7/breezy/tests/__init__.py", 
line 2301, in apply_redirected
return a_callable(*args, **kwargs)
  File "/<>/build/lib.linux-aarch64-2.7/breezy/commands.py", line 
1309, in run_bzr_catch_user_errors
return run_bzr(argv)
  File "/<>/build/lib.linux-aarch64-2.7/breezy/commands.py", line 
1199, in run_bzr
ret = run(*run_argv)
  File "/<>/build/lib.linux-aarch64-2.7/breezy/commands.py", line 
755, in run_argv_aliases
return self.run(**all_cmd_args)
  File "/<>/build/lib.linux-aarch64-2.7/breezy/commands.py", line 
779, in run
return self._operation.run_simple(*args, **kwargs)
  File "/<>/build/lib.linux-aarch64-2.7/breezy/cleanup.py", line 
136, in run_simple
self.cleanups, self.func, *args, **kwargs)
  File "/<>/build/lib.linux-aarch64-2.7/breezy/cleanup.py", line 
165, in _do_with_cleanups
result = func(*args, **kwargs)
  File "/<>/build/lib.linux-aarch64-2.7/breezy/builtins.py", line 
3616, in run
ui.ui_factory.show_warning(warning_msg)
  File "/<>/build/lib.linux-aarch64-2.7/breezy/ui/text.py", line 
343, in show_warning
self.stderr.write("bzr: warning: %s\n" % msg)
  File "/usr/lib/python2.7/codecs.py", line 369, in write
data, consumed = self.encode(object, self.errors)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u20ac' in position 
50: ordinal not in range(128)

--
Ran 27984 tests in 608.241s

FAILED (errors=1, known_failure_count=64)

-- 
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#873675: libexecs: FTBFS w/GCC 7: null where non-null expected

[Aaron M. Ucko]

Source: libexecs
Version: 1.0-1
Severity: serious
Tags: upstream
Justification: fails to build from source

Builds of libexecs with GCC 7 (the default version nowadays) have been
failing:

  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-Werror -Wall -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c noshell.c  -fPIC 
-DPIC -o .libs/noshell.o
  noshell.c: In function 'coprocess_common':
  noshell.c:82:7: error: argument 1 null where non-null expected 
[-Werror=nonnull]
 execvpe(path, argv, envp);
 ^
  In file included from noshell.c:5:0:
  /usr/include/unistd.h:593:12: note: in a call to function 'execvpe' declared 
here
   extern int execvpe (const char *__file, char *const __argv[],
  ^~~
  cc1: all warnings being treated as errors
  Makefile:512: recipe for target 'noshell.lo' failed

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#873674: libdazzle: FTBFS: 'ascii' codec can't decode byte 0xe2

[Aaron M. Ucko]

Source: libdazzle
Version: 3.25.5-1
Severity: serious
Justification: fails to build from source

Builds of libdazzle under the traditional C locale (as on the
autobuilders, implicitly) have been failing as detailed below.  Please
try arranging for debian/rules to export LC_ALL=C.UTF-8, which should
be available by default (via libc-bin) these days.

Thanks!

Building documentation for libdazzle
Traceback (most recent call last):
  File "/usr/share/meson/meson", line 37, in 
sys.exit(main())
  File "/usr/share/meson/meson", line 34, in main
return mesonmain.run(sys.argv[1:], launcher)
  File "/usr/share/meson/mesonbuild/mesonmain.py", line 297, in run
sys.exit(run_script_command(args[1:]))
  File "/usr/share/meson/mesonbuild/mesonmain.py", line 264, in 
run_script_command
return cmdfunc(cmdargs)
  File "/usr/share/meson/mesonbuild/scripts/gtkdochelper.py", line 218, in run
options.mode)
  File "/usr/share/meson/mesonbuild/scripts/gtkdochelper.py", line 166, in 
build_gtkdoc
gtkdoc_run_check(fixref_cmd, abs_out)
  File "/usr/share/meson/mesonbuild/scripts/gtkdochelper.py", line 51, in 
gtkdoc_run_check
p, out = Popen_safe(cmd, cwd=cwd, stderr=subprocess.STDOUT)[0:2]
  File "/usr/share/meson/mesonbuild/mesonlib.py", line 522, in Popen_safe
o, e = p.communicate(write)
  File "/usr/lib/python3.5/subprocess.py", line 790, in communicate
stdout = self.stdout.read()
  File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 16994: 
ordinal not in range(128)
Warning: You are using 'ANSI_X3.4-1968' which is not a a Unicode-compatible 
locale.
You might see errors if you use UTF-8 strings as filenames, as strings, or as 
file contents.
Please switch to a UTF-8 locale for your platform.

-- 
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#837809: [drm:si_dpm_set_power_state [radeon]] *ERROR* si_restrict_performance_levels_before_s

[Ben Hutchings]

On Tue, 2017-08-29 at 15:57 +, Deucher, Alexander wrote:
> > -Original Message-
> > > > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > Sent: Tuesday, August 29, 2017 6:43 AM
> > To: 837...@bugs.debian.org
> > Cc: Deucher, Alexander
> > Subject: [drm:si_dpm_set_power_state [radeon]] *ERROR*
> > si_restrict_performance_levels_before_s
> > 
> > The message still occurs with Stretch kernel 4.9.0-3-amd64.
> > 
> > [  +0.000192] fbcon: radeondrmfb (fb0) is primary device
> > [  +0.179799] [drm:si_dpm_set_power_state [radeon]] *ERROR*
> > si_restrict_performance_levels_before_s
> > [  +0.122488] Console: switching to colour frame buffer device 480x135
> > [  +0.087282] radeon :01:00.0: fb0: radeondrmfb frame buffer device
> > [  +0.094945] [drm] Initialized radeon 2.48.0 20080528 for :01:00.0
> > on minor 0
> > 
> > The message is created in drivers/gpu/drm/radeon/si_dpm.c
> > if si_restrict_performance_levels_before_switch fails.
> > 
> > My graphics adapter is
> > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
> > [AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 250X] (prog-if 00 [VGA
> > controller])
> > 
> > xset dpms force standby
> > works fine on my system.
> > 
> 
> Are you actually experiencing any problems other than the
> message?  In most cases the message is harmless.

Spurious error messages are also bugs, of course.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names
taken.



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

Bug#872658: pspresent: should drop the obsolete "Suggests:" list

[Jamie Wilkinson]

Probably best to drop this package from the archive then.

On 20 August 2017 at 06:29, Vincent Lefevre  wrote:

> Package: pspresent
> Version: 1.3-4+b2
> Severity: minor
>
> pspresent currently has:
>
> Suggests: chaksem | prosper | foiltex
>
> These are LaTeX packages to produce presentations, and prosper is
> now a transitional dummy package since the class is now provided
> by TeX Live.
>
> This list is not helpful, and is even misleading because:
>   * chaksem is very old and seems no longer maintained upstream;
>   * prosper is now in TeX Live;
>   * foiltex is also quite old and seems no longer maintained upstream
> (and it is non-free);
>   * there is a better alternative: beamer (in TeX Live), which most
> people probably use.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500,
> 'testing'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages pspresent depends on:
> ii  ghostscript-x  9.21~dfsg-1
> ii  libc6  2.24-14
> ii  libx11-6   2:1.6.4-3
> ii  libxinerama1   2:1.1.3-1+b3
>
> pspresent recommends no packages.
>
> Versions of packages pspresent suggests:
> pn  chaksem | prosper | foiltex  
>
> -- no debconf information
>

Bug#873160: python-pymad: pymad in stretch decodes to noise

[Jamie Wilkinson]

Bug 873673 contains the request to the release team.

On 30 August 2017 at 10:01, Jamie Wilkinson  wrote:

> ... The version you filed the bug against is 0.10-1 but in the body of the
> text you say it's 0.9 yeah.  0.10 fixes a decode-to-noise bug. :)
>
> I'll see if the release team would like to promote 0.10-1 to stretch.
>
> On 25 August 2017 at 15:18, Marc Dahn  wrote:
>
>> Package: python-pymad
>> Version: 0.10-1
>> Severity: grave
>> Justification: renders package unusable
>>
>> Dear Maintainer,
>>
>> When decoding at least several MP3 files (including at 22050 kHz
>> single-channel and 44100 kHz dual-channel, non-VBR), python-pymad in
>> stretch generates fairly horrific sound (chr-chr-chr) at least on i386.
>> If one looks at the decoded bytes, there's a clear overabundance of
>> zeroes, but in the one case I looked at they even included a string .
>> "7/email/encoders.py", so it's probably not just an integer format
>> issue.
>>
>> The good news is:  The version currently in testing, 0.10-1, fixes
>> the problem, so it's probably not worth further investigating this
>> particular issue.  It *would* be good if the fix could somehow slip
>> into stable, though.
>>
>>
>> -- System Information:
>> Debian Release: 9.1
>>   APT prefers proposed-updates
>>   APT policy: (500, 'proposed-updates'), (500, 'stable')
>> Architecture: i386 (x86_64)
>>
>> Kernel: Linux 4.12.2 (SMP w/4 CPU cores)
>> Locale: LANG=C, LC_CTYPE=de_DE.ISO-8859-1 (charmap=ISO-8859-1),
>> LANGUAGE=C (charmap=ISO-8859-1)
>> Shell: /bin/sh linked to /bin/bash
>> Init: sysvinit (via /sbin/init)
>>
>> Versions of packages python-pymad depends on:
>> ii  libc62.24-11+deb9u1
>> ii  libmad0  0.15.1b-8
>> ii  python   2.7.13-2
>>
>> python-pymad recommends no packages.
>>
>> python-pymad suggests no packages.
>>
>> -- no debconf information
>>
>
>

Bug#856717: ImportError: /usr/lib/python2.7/dist-packages/madmodule.so: undefined symbol: Py_InitModule4_64

[Jamie Wilkinson]

I can reproduce this in 0.10-1 as well.

On 4 March 2017 at 20:46, Mathieu Malaterre  wrote:

> Package: python-pymad-dbg
> Version: 0.9-1+b1
> Severity: normal
>
> It seems like the -dbg package is not build correctly. Steps:
>
> mathieu@maester $ apt-cache policy python-pymad-dbg
> python-pymad-dbg:
>   Installed: 0.9-1+b1
>   Candidate: 0.9-1+b1
>   Version table:
>  *** 0.9-1+b1 0
> 100 http://ftp.fr.debian.org/debian/ unstable/main amd64 Packages
> 100 /var/lib/dpkg/status
> mathieu@maester $ python-dbg
> Python 2.7.9 (default, Jun 29 2016, 13:13:01)
> [GCC 4.9.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import mad
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: /usr/lib/python2.7/dist-packages/madmodule.so: undefined
> symbol: Py_InitModule4_64
> [41842 refs]
> >>>
>
> Thanks
>
>
> -- System Information:
> Debian Release: 8.4
>   APT prefers stable
>   APT policy: (700, 'stable'), (100, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/8 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 python-pymad-dbg depends on:
> ii  python-pymad  0.7-1
>
> python-pymad-dbg recommends no packages.
>
> python-pymad-dbg suggests no packages.
>
> -- no debconf information
>

Bug#873673: stretch-pu: package pymad/0.9-1

[Jamie Wilkinson]

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

Hello,

Version 0.9 of pymad contains a corruption bug that wasn't fixed until 0.10.

Stretch contains this bug, and is reported as debian bug #873160.

Can you please pull pymad 0.10-1 into stretch?

If that is not possible, I can provide a text patch (identical to the content 
at 
https://github.com/jaqx0r/pymad/pull/9/commits/5fa450e1cd561a16160458fb2e3af9bc75d4c3e4?diff=unified#diff-ff655086caf5ecffa7b506ef5c50410c
 ) to be applied for a NMU to 0.9-1.

Thanks.

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

Kernel: Linux 4.11.0-2-686 (SMP w/1 CPU core)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Bug#873672: firefox-esr: "accept-language" HTTP header is incorrectly send by default

[Yvan Masson]

Package: firefox-esr
Version: 52.3.0esr-2
Severity: important

Dear Maintainers,

After a standard Debian net-install using French locale, the Firefox
HTTP header "accept-language" is correctly set to "fr, fr-fr, en-us, en"
(as seen in intl.accept_languages in about:config).

However, the *sent* value is "en-US,en;q=0.5" (as seen in any website
that show visitors' HTTP headers). I believe this is an important
usability problem for non-english speakers, that is why I set the
severity to "important".

The simplest solution to this problem is to open Firefox Preferences and
to go to "Content" -> "Languages" -> "Choose" to change languages to any
order, validate, and then re-change the order back to the right one.

On my setup, I can confirm this simply by starting Firefox with a blank
profile.

Please do not hesitate to ask if I can provide more information, or if I
should report this upstream (I could no find a similar bug report there).

Best regards,
Yvan

-- Package-specific info:

-- Extensions information
Name: Application Update Service Helper
Location: ${PROFILE_EXTENSIONS}/aushel...@mozilla.org.xpi
Status: enabled

Name: Français Language Pack locale
Location:
/usr/lib/firefox-esr/browser/extensions/langpack...@firefox-esr.mozilla.org.xpi
Package: firefox-esr-l10n-fr
Status: enabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: Privacy Badger
Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpn...@jetpack.xpi
Status: enabled

Name: Thème par défaut theme
Location:
/usr/lib/firefox-esr/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox-esr
Status: enabled

Name: Web Compat
Location: ${PROFILE_EXTENSIONS}/webcom...@mozilla.org.xpi
Status: enabled

-- Plugins information
Name: GNOME Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3.1))
Location: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-8-plugin:amd64
Status: enabled

Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: disabled


-- Addons package information
ii  firefox-esr52.3.0esr-2  amd64Mozilla Firefox web browser
- Ext
ii  firefox-esr-l1 52.3.0esr-2  all  French language package for
Firef
ii  gnome-shell3.22.3-3 amd64graphical shell for the
GNOME des
ii  icedtea-8-plug 1.6.2-3.1amd64web browser plugin based on
OpenJ
ii  rhythmbox-plug 3.4.1-3  amd64plugins for rhythmbox music
playe

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.2
ii  fontconfig2.12.3-0.2
ii  libasound21.1.3-5
ii  libatk1.0-0   2.24.0-1
ii  libc6 2.24-14
ii  libcairo-gobject2 1.14.10-1
ii  libcairo2 1.14.10-1
ii  libdbus-1-3   1.11.16+really1.10.22-1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-6
ii  libfontconfig12.12.3-0.2
ii  libfreetype6  2.8-0.2
ii  libgcc1   1:7.2.0-1
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.53.4-3
ii  libgtk-3-03.22.18-1
ii  libgtk2.0-0   2.24.31-2
ii  libhunspell-1.6-0 1.6.1-2
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.16-1
ii  libnss3   2:3.31-1
ii  libpango-1.0-01.40.6-1
ii  libsqlite3-0  3.19.3-3
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++67.2.0-1
ii  libvpx4   1.6.1-3
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3
ii  zlib1g1:1.2.8.dfsg-5

firefox-esr recommends no packages.

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-3
ii  libgssapi-krb5-2   1.15.1-2
pn  mozplugger 

-- no 

Bug#873646: RM? FTBFS with Java 9, 1 rdep is RoQA, abandoned upstream

[Emmanuel Bourg]

Le 29/08/2017 à 20:54, Chris West a écrit :

> [echo] Running Registry tests ...
> [java] Exception in thread "main" java.lang.VerifyError: (class: 
> org/apache/commons/modeler/RegistryTestCase, method: suite signature: 
> ()Ljunit/framework/Test;) Illegal type in constant pool
> [java]at java.base/java.lang.Class.forName0(Native Method)
> [java]at java.base/java.lang.Class.forName(Class.java:292)
> [java]at 
> junit.runner.StandardTestSuiteLoader.load(StandardTestSuiteLoader.java:11)

Hum that's weird, that might be a JDK bug. I guess removing the suite()
method from RegistryTestCase will fix this.


> Please can we just remove it?

In Debian libquartz-java was using it before the version 1.8. In the
wild there are OW2 EasyBeans, Apache Geode and SnappyData still using
it. I have no strong opinion but I lean toward keeping the package just
in case it helps future packaging work.

Emmanuel Bourg

Bug#873671: latest version is 0.6-2

[Takeshi Soejima]

Package: r-cran-rpostgresql
Version: 0.4-1

I wish to update the package to the latest version 0.6-2 in CRAN.

Bug#873576: ruby-rest-client: FTBFS without network access

[Steve Langasek]

Package: ruby-rest-client
Followup-For: Bug #873576

Control: user ubuntu-de...@lists.ubuntu.com
Control: usertags -1 origin-ubuntu artful ubuntu-patch
Control: tags -1 patch

It appears there is already a patch applied to disable network tests, and it
just needs extending with the set of newly-added network-dependent tests. 
Please find attached a debdiff to do this.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ruby-rest-client-2.0.2/debian/patches/disable-network-tests.patch 
ruby-rest-client-2.0.2/debian/patches/disable-network-tests.patch
--- ruby-rest-client-2.0.2/debian/patches/disable-network-tests.patch   
2017-07-25 23:24:23.0 -0700
+++ ruby-rest-client-2.0.2/debian/patches/disable-network-tests.patch   
2017-08-29 17:14:19.0 -0700
@@ -1,11 +1,15 @@
 From: Matthias Klose 
-Last-Update: 2016-03-16
+From: Steve Langasek 
+Last-Update: 2017-08-29
 Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818459
+Bug-Debian: https://bugs.debian.org/873576
 Forwarded: no
 
 a/spec/integration/request_spec.rb
-+++ b/spec/integration/request_spec.rb
-@@ -10,96 +10,7 @@ describe RestClient::Request do
+Index: ruby-rest-client-2.0.2/spec/integration/request_spec.rb
+===
+--- ruby-rest-client-2.0.2.orig/spec/integration/request_spec.rb
 ruby-rest-client-2.0.2/spec/integration/request_spec.rb
+@@ -10,96 +10,7 @@
end
  
describe "ssl verification" do
@@ -103,3 +107,73 @@
end
  
describe "timeouts" do
+@@ -113,15 +24,6 @@
+ raise_error(RestClient::Exceptions::OpenTimeout))
+ end
+ 
+-it "raises ReadTimeout when it hits a read timeout via :read_timeout" do
+-  request = RestClient::Request.new(
+-:method => :get,
+-:url => 'https://www.mozilla.org',
+-:read_timeout => 1e-10,
+-  )
+-  expect { request.execute }.to(
+-raise_error(RestClient::Exceptions::ReadTimeout))
+-end
+   end
+ 
+ end
+Index: ruby-rest-client-2.0.2/spec/integration/httpbin_spec.rb
+===
+--- ruby-rest-client-2.0.2.orig/spec/integration/httpbin_spec.rb
 ruby-rest-client-2.0.2/spec/integration/httpbin_spec.rb
+@@ -40,48 +40,6 @@
+   end
+ 
+   describe '.execute' do
+-it 'sends a user agent' do
+-  data = execute_httpbin_json('user-agent', method: :get)
+-  expect(data['user-agent']).to match(/rest-client/)
+-end
+-
+-it 'receives cookies on 302' do
+-  expect {
+-execute_httpbin('cookies/set?foo=bar', method: :get, max_redirects: 0)
+-  }.to raise_error(RestClient::Found) { |ex|
+-expect(ex.http_code).to eq 302
+-expect(ex.response.cookies['foo']).to eq 'bar'
+-  }
+-end
+-
+-it 'passes along cookies through 302' do
+-  data = execute_httpbin_json('cookies/set?foo=bar', method: :get)
+-  expect(data).to have_key('cookies')
+-  expect(data['cookies']['foo']).to eq 'bar'
+-end
+-
+-it 'handles quote wrapped cookies' do
+-  expect {
+-execute_httpbin('cookies/set?foo=' + CGI.escape('"bar:baz"'),
+-method: :get, max_redirects: 0)
+-  }.to raise_error(RestClient::Found) { |ex|
+-expect(ex.http_code).to eq 302
+-expect(ex.response.cookies['foo']).to eq '"bar:baz"'
+-  }
+-end
+-
+-it 'sends basic auth' do
+-  user = 'user'
+-  pass = 'pass'
+-
+-  data = execute_httpbin_json("basic-auth/#{user}/#{pass}", method: :get, 
user: user, password: pass)
+-  expect(data).to eq({'authenticated' => true, 'user' => user})
+-
+-  expect {
+-execute_httpbin_json("basic-auth/#{user}/#{pass}", method: :get, 
user: user, password: 'badpass')
+-  }.to raise_error(RestClient::Unauthorized) { |ex|
+-expect(ex.http_code).to eq 401
+-  }
+-end
++# all removed; accessing the network
+   end
+ end

Bug#738298: ITA

[Rodrigo Siqueira Jordão]

I am studying Debian package and I want to adopt pdfrw.

I am already working to update the package and I will be able to  
upload a new version soon.


--
Rodrigo Siqueira
Graduate Student
Department of Computer Science
University of São Paulo

Bug#870128: libgpuarray: broken autopkgtests

[Steve Langasek]

Control: tags -1 patch
Control: user ubuntu-de...@lists.ubuntu.com
Control: usertags -1 ubuntu-patch

On Mon, Aug 28, 2017 at 11:37:05PM -0700, Steve Langasek wrote:
> Hi Ghislain,
> 
> On Sun, Jul 30, 2017 at 01:16:14PM +0100, Ghislain Vaillant wrote:
> 
> > Indeed, which allows running the upstream test suite on our CPU-based
> > builders. This is better than the default autopkgtest-pkg-python, which
> > does nothing but testing the import of the Python module.
> 
> > Your assessment is wrong. pocl is a **CPU** implementation of OpenCL,
> > so the tests should run in principle. The issue is that the test suite
> > does not skip tests for which a specific compute must be satisfied by
> > the environment, such as CUDA and float16. The rest of the tests runs
> > fine.
> 
> Ah, thanks for the clarification.
> 
> > The old basic does nothing. For such package, testing whether the
> > import is successful is hardly testing at all.
> 
> Fair enough.
> 
> >> I am filing this bug because failing autopkgtests are considered blockers
> >> for inclusion of a package in the Ubuntu release.  Newer versions of
> >> libgpuarray might not be included in Ubuntu releases until this is
> >> resolved.
> 
> > I believe this is wrong. How can we provide upstream with meaningful
> > logs without enabling the tests in the first place? I can keep the old
> > autopkgtest-pkg-python to satisfy Ubuntu's policy, but what good would
> > it make?
> 
> Well, you can generate whatever logs you want, the issue is when
> known-bad tests are treated as a *failure* of the autopkgtest.  This
> prevents the autopkgtests from being used for continuous integration,
> because there is no signal to say when the test results are good.
> 
> If the testing framework supports marking these tests as XFAIL as part of
> the autopkgtest, or otherwise skipping them when run on unsuitable hardware,
> I think that would be preferable.
> 
> Attached is a patch that appears to achieve this here.

And here is a more complete patch that should let the tests pass on all
architectures, not just on amd64.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libgpuarray-0.6.9/debian/patches/series 
libgpuarray-0.6.9/debian/patches/series
--- libgpuarray-0.6.9/debian/patches/series 1969-12-31 16:00:00.0 
-0800
+++ libgpuarray-0.6.9/debian/patches/series 2017-08-28 23:19:34.0 
-0700
@@ -0,0 +1 @@
+skip-cuda-tests
diff -Nru libgpuarray-0.6.9/debian/patches/skip-cuda-tests 
libgpuarray-0.6.9/debian/patches/skip-cuda-tests
--- libgpuarray-0.6.9/debian/patches/skip-cuda-tests1969-12-31 
16:00:00.0 -0800
+++ libgpuarray-0.6.9/debian/patches/skip-cuda-tests2017-08-29 
17:04:37.0 -0700
@@ -0,0 +1,158 @@
+Description: skip those tests that we know will fail on opencl
+ Some of the upstream tests require CUDA in order to run.  Skip these tests
+ instead of treating them as errors when called in a non-CUDA environment.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/870128
+
+Index: libgpuarray-0.6.9/pygpu/tests/test_elemwise.py
+===
+--- libgpuarray-0.6.9.orig/pygpu/tests/test_elemwise.py
 libgpuarray-0.6.9/pygpu/tests/test_elemwise.py
+@@ -2,6 +2,7 @@
+ import numpy
+ from mako.template import Template
+ 
++from nose.plugins.skip import SkipTest
+ from unittest import TestCase
+ from pygpu import gpuarray, ndgpuarray as elemary
+ from pygpu.dtypes import dtype_to_ctype, get_common_dtype
+@@ -43,7 +44,10 @@
+ c, g = gen_gpuarray((50,), dtype, ctx=context, cls=elemary)
+ 
+ out_c = op(c)
+-out_g = op(g)
++try:
++out_g = op(g)
++except gpuarray.GpuArrayException:
++raise SkipTest("skipping test on this hardware")
+ 
+ assert out_c.shape == out_g.shape
+ assert out_c.dtype == out_g.dtype
+@@ -123,7 +127,10 @@
+   cls=elemary)
+ 
+ out_c = op(ac, bc)
+-out_g = op(ag, bg)
++try:
++out_g = op(ag, bg)
++except gpuarray.GpuArrayException:
++raise SkipTest("skipping test on this hardware")
+ 
+ assert out_c.shape == out_g.shape
+ assert out_c.dtype == out_g.dtype
+@@ -147,7 +154,10 @@
+ # TODO: currently, we use old Numpy semantic and tolerate more case.
+ # So we can't test that we raise the same error
+ return
+-out_g = op(ag, bg)
++try:
++out_g = op(ag, bg)
++except gpuarray.GpuArrayException:
++raise SkipTest("skipping test on this hardware")
+ 
+ assert out_g is ag
+ assert numpy.allclose(out_c, numpy.asarray(out_g), atol=1e-6)
+Index: libgpuarray-0.6.9/pygpu/tests/test_gpu_ndarray.py

Bug#873160: python-pymad: pymad in stretch decodes to noise

[Jamie Wilkinson]

... The version you filed the bug against is 0.10-1 but in the body of the
text you say it's 0.9 yeah.  0.10 fixes a decode-to-noise bug. :)

I'll see if the release team would like to promote 0.10-1 to stretch.

On 25 August 2017 at 15:18, Marc Dahn  wrote:

> Package: python-pymad
> Version: 0.10-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> When decoding at least several MP3 files (including at 22050 kHz
> single-channel and 44100 kHz dual-channel, non-VBR), python-pymad in
> stretch generates fairly horrific sound (chr-chr-chr) at least on i386.
> If one looks at the decoded bytes, there's a clear overabundance of
> zeroes, but in the one case I looked at they even included a string .
> "7/email/encoders.py", so it's probably not just an integer format
> issue.
>
> The good news is:  The version currently in testing, 0.10-1, fixes
> the problem, so it's probably not worth further investigating this
> particular issue.  It *would* be good if the fix could somehow slip
> into stable, though.
>
>
> -- System Information:
> Debian Release: 9.1
>   APT prefers proposed-updates
>   APT policy: (500, 'proposed-updates'), (500, 'stable')
> Architecture: i386 (x86_64)
>
> Kernel: Linux 4.12.2 (SMP w/4 CPU cores)
> Locale: LANG=C, LC_CTYPE=de_DE.ISO-8859-1 (charmap=ISO-8859-1), LANGUAGE=C
> (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/bash
> Init: sysvinit (via /sbin/init)
>
> Versions of packages python-pymad depends on:
> ii  libc62.24-11+deb9u1
> ii  libmad0  0.15.1b-8
> ii  python   2.7.13-2
>
> python-pymad recommends no packages.
>
> python-pymad suggests no packages.
>
> -- no debconf information
>

Bug#873486: fcitx can not be start after upgrade to Debian buster

[王钢林]

Hello, everyone.


Updated message! Restart the Debain maybe OK sometimes, but maybe not 
work sometimes...



I find a very strange thing about  the Debian buster including the 
fcitx. If the computer is turn on and the system start up, many unusual 
thing will happen. Such as the fcitx can not be used, the splash window 
is not showed at the center of screen, and so on. But if I restart the 
computer (not turn off and turn on), everything maybe OK, or maybe still 
unusual


It is so strange! So I think it is a bug of Debian buster. But I do not 
known which package should be debug, so I don't known how to report this 
bug. :(



Best regards

Gulfstream



在 2017年08月28日 18:32, Shengjing Zhu 写道:

Control: tags -1 moreinfo

Please run fcitx-diagnose and paste the result here.

Thanks

On Mon, Aug 28, 2017 at 5:51 PM, gulfstream  wrote:

Package: fcitx
Version: 1:4.2.9.1-6
Severity: grave



Hi!

I upgraded my Debian to buster yesterday. Then the fcitx can not be used now. 
When I run it, the messages are get as blew:

wgl@athena:~$ fcitx
wgl@athena:~$ (INFO-6096 
/build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon 
ConfigFile:fcitx-autoeng.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-chttrans.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-clipboard.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-fullwidth-char.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-imselector.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-keyboard.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-punc.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-quickphrase.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-remote-module.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-spell.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-unicode.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-dbus.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-freedesktop-notify.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-ipc.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-googlepinyin.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-kimpanel-ui.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-lua.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-vk.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-x11.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-xim.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-xkb.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-xkbdbus.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-pinyin-enhance.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-pinyin.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-sunpinyin.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-table.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-classic-ui.conf
(INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load 
Addon ConfigFile:fcitx-notificationitem.conf
(ERROR-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/ime.c:432) 
fcitx-keyboard-cm-mmuock already exists
(WARN-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/frontend/xim/xim.c:161) Please 
set XMODIFIERS.


The fcitx works fine when the Debian is stretch before I upgrade to buster.

Could you resolve this problem? Thank you very much!



Best regards,
Gulfstream




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

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_CN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to 

Bug#873623: sudo: occasionally stalls infinitely instead of running command

[Alban Browaeys]

Package: sudo
Version: 1.8.21-1
Followup-For: Bug #873623

This is likely sssd related.

I upgraded both today (sssd to 1.15.3-1) and "sudo ls" output was empty.
Local workaround was to comment out "sss" on /etc/nsswitch.conf "sudoers:"
sudoers:files sss
to
sudoers:files #sss

Hinted from "pkexec strace -f sudo ls" output:
connect(4, {sa_family=AF_UNIX, sun_path="/var/lib/sss/pipes/sudo"}, 110) = -1 
ECONNREFUSED (Connection refused)


Best regards,
Alban



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

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

Versions of packages sudo depends on:
ii  libaudit1   1:2.7.7-1+b2
ii  libc6   2.24-17
ii  libpam-modules  1.1.8-3.6
ii  libpam0g1.1.8-3.6
ii  libselinux1 2.6-3+b2
ii  lsb-base9.20170808

sudo recommends no packages.

sudo suggests no packages.

-- Configuration Files:
/etc/sudoers [Errno 13] Permission non accordée: '/etc/sudoers'
/etc/sudoers.d/README [Errno 13] Permission non accordée: 
'/etc/sudoers.d/README'

-- no debconf information

Bug#873627: udisks2 in sid apparently left me with a borked system in plasma(?)

[Ben Caradoc-Davies]

udisks2 2.7.2-1 also severely impacted the functionality of thunar on 
sid. All filesystems were shown in the sidebar, including things like 
binfmt (about 20-30 or so filsystems). Removable devices were not shown, 
and no eject icon was shown when removable devices were mounted at the 
command line. Workaround was to downgrade to 2.6.5-2. Before filing a 
separate bug report, I will see if the fix for this issue resolves the 
thunar issues.


Downgrade and hold procedure for the benefit of other readers:

I added the following to /etc/apt/source.list:
deb http://snapshot.debian.org/archive/debian/20170827T034402Z/ sid main

Then ran the following to downgrade and hold:

apt-get update
apt-get install udisks2=2.6.5-2 libudisks2-0=2.6.5-2
apt-mark hold udisks2 libudisks2-0

A system restart was required.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#873663: syncthing: Missing service files for discovery and relay service

[Alexandre Viau]

Really? Did you install the syncthing-discosrv and syncthing-relaysrv
packages?

These files are not shipped in the syncthing package.



signature.asc
Description: OpenPGP digital signature

Bug#873670: supertuxkart: Segmentation Fault in MusicInformation::isPlaying

[Ben Longbons]

Package: supertuxkart
Version: 0.9.2+dfsg-2
Severity: important

Dear Maintainer,

For me, this occurred during extended play, in story mode, during the
3rd grand prix "to the moon and back", at the very start of the last
race (huh ...  STK keeps grand prix progress on crash), but it is
(naturally) not reproducible.

Unlike most SEGVs, this is a call through a NULL function pointer.

$ coredumpctl gdb supertuxkart
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
   PID: 27135 (supertuxkart)
   UID: 1000 (ben)
   GID: 1000 (ben)
Signal: 11 (SEGV)
 Timestamp: Tue 2017-08-29 15:43:51 PDT (9min ago)
  Command Line: /usr/games/supertuxkart
Executable: /usr/games/supertuxkart
 Control Group: /user.slice/user-1000.slice/session-5.scope
  Unit: session-5.scope
 Slice: user-1000.slice
   Session: 5
 Owner UID: 1000 (ben)
   Boot ID: b567089063994f90b206df689d65a202
Machine ID: a9f5005691f11289cd92098b52b4f3f9
  Hostname: joyplim
   Storage: 
/var/lib/systemd/coredump/core.supertuxkart.1000.b567089063994f90b206df689d65a202.27135.150404663100.lz4
   Message: Process 27135 (supertuxkart) of user 1000 dumped core.

Stack trace of thread 27135:
#0  0x n/a (n/a)

GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/games/supertuxkart...(no debugging symbols 
found)...done.
[New LWP 27135]
[New LWP 27163]
[New LWP 27149]
[New LWP 27147]
[New LWP 27148]
[New LWP 27153]
[New LWP 27159]
[New LWP 27146]
[New LWP 27158]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

warning: Could not find DWO CU 
gallivm/.libs/lp_bld_debug.dwo(0x705e1d0e169ca1fe) referenced by CU at offset 
0x14078a9 [in module 
/usr/lib/debug/.build-id/62/a543423306e4787e29a78fbd94c9a2cdf8ff3d.debug]

warning: Could not find DWO CU 
gallivm/.libs/lp_bld_misc.dwo(0x3f68ad1a054cd591) referenced by CU at offset 
0x1422424 [in module 
/usr/lib/debug/.build-id/62/a543423306e4787e29a78fbd94c9a2cdf8ff3d.debug]
Core was generated by `/usr/games/supertuxkart'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
[Current thread is 1 (Thread 0x7f44fc0ea800 (LWP 27135))]
(gdb) bt
#0  0x in ?? ()
#1  0x55f45bc06cc6 in MusicInformation::isPlaying() const ()
#2  0x55f45be1f811 in WorldStatus::update(float) ()
#3  0x55f45be1a9aa in World::update(float) ()
#4  0x55f45be0d7ec in LinearWorld::update(float) ()
#5  0x55f45be1c31c in World::updateWorld(float) ()
#6  0x55f45be06e90 in MainLoop::run() ()
#7  0x55f45bbc3f96 in main ()
(gdb) up
#1  0x55f45bc06cc6 in MusicInformation::isPlaying() const ()
(gdb) disassemble
Dump of assembler code for function _ZNK16MusicInformation9isPlayingEv:
   0x55f45bc06cb0 <+0>: push   rbx
   0x55f45bc06cb1 <+1>: movrbx,rdi
   0x55f45bc06cb4 <+4>: movrdi,QWORD PTR [rdi+0x98]
   0x55f45bc06cbb <+11>:test   rdi,rdi
   0x55f45bc06cbe <+14>:je 0x55f45bc06cca 
<_ZNK16MusicInformation9isPlayingEv+26>
   0x55f45bc06cc0 <+16>:movrax,QWORD PTR [rdi]
   0x55f45bc06cc3 <+19>:call   QWORD PTR [rax+0x40]
=> 0x55f45bc06cc6 <+22>:test   al,al
   0x55f45bc06cc8 <+24>:jne0x55f45bc06ce8 
<_ZNK16MusicInformation9isPlayingEv+56>
   0x55f45bc06cca <+26>:movrdi,QWORD PTR [rbx+0xa0]
   0x55f45bc06cd1 <+33>:xoreax,eax
   0x55f45bc06cd3 <+35>:test   rdi,rdi
   0x55f45bc06cd6 <+38>:je 0x55f45bc06ce8 
<_ZNK16MusicInformation9isPlayingEv+56>
   0x55f45bc06cd8 <+40>:movrax,QWORD PTR [rdi]
   0x55f45bc06cdb <+43>:poprbx
   0x55f45bc06cdc <+44>:movrax,QWORD PTR [rax+0x40]
   0x55f45bc06ce0 <+48>:jmprax
   0x55f45bc06ce2 <+50>:nopWORD PTR [rax+rax*1+0x0]
   0x55f45bc06ce8 <+56>:poprbx
   0x55f45bc06ce9 <+57>:ret
End of assembler dump.

(as usual, RIP is pointing to where it *would* be if the function returned)

-- System Information:
Debian 

Bug#873505: Acknowledgement (mailman: Runner crashes when processing incoming email)

[Pete Donnell]

Apologies, turns out that this is a duplicate of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838288


Applying the patch included there fixed it.

Bug#873557: mbedtls: possible authentication bypass

[James Cowgill]

On 29/08/17 00:09, James Cowgill wrote:
> I think this is the commit which fixes this, but I have not checked yet:
> https://github.com/ARMmbed/mbedtls/commit/31458a18788b0cf0b722acda9bb2f2fe13a3fb32

In addition, this commit must be applied before that one:
https://github.com/ARMmbed/mbedtls/commit/d15795acd5074e0b44e71f7ede8bdfe1b48591fc

I created a test certificate chain for this (before I realized upstream
already had one) which I have attached. The bug can be reproduced using
mbedtls's test programs (available from manually built source).

First, start a server:
programs/ssl/ssl_server2 crt_file=test-certs/chain.pem 
key_file=test-certs/child.key

Then run the child like this:
programs/ssl/ssl_client2 server_name=Child server_addr=localhost 
auth_mode=optional

Currently, the client will claim that the certificate validated. This is
quite astounding since I didn't even give the client a list of trusted
CAs!
> . Verifying peer X.509 certificate... ok

After applying the patches the client will correctly fail the
certificate validation.

James


test-certs.tar.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#873669: xerces-c: New upstream release 3.2.0

[Roger Leigh]

Source: xerces-c
Severity: normal

https://marc.info/?l=xerces-c-users=150396606201867=2

Note that this release includes a replacement of the autotools build
with CMake.  The autotools build still exists, but the CMake build
includes pkg-config and cmake configuration, and also builds and run
the unit tests correctly on all platforms, which was tested
extensively during the development (the autotools unit tests fail due
to erroneous newlines in the output, which can vary depending upon the
compiler and other unknowns).  In practice, this means the cmake build
is preferable if you would like to switch and enable the unit tests as
part of the package build.

The CMake build also conditionally enables C++11 features including
use of char16_t string literals.  This means you can use u"string"
literals wherever XMLCh* is used, making the API much easier to use.
This is fully backward compatible (though some packages may be making
buggy assumptions about XMLCh==uint16 and relying upon implicit
casts).

The release includes a rather large number of bugfixes.  While it's
API compatible with 3.1.4 and earlier, it has a new soname and will
require a rebuild of all reverse dependencies.


Regards,
Roger

Bug#873668: fetchmail: Wrong octets number displayed after 2-GB-threshold

[Andreas Schmidt]

Package: fetchmail
Version: 6.3.26-3
Severity: minor

Dear Maintainer,

while looking at /var/log/syslog, I just noticed something peculiar:

***
fetchmail[1236]: 5796 messages (5796 seen) for x...@xxx.xxx at xxx.xxx.xxx
(-2074178329 octets).
fetchmail[1236]: 4401 messages (4401 seen) for y...@yyy.yyy at yyy.yyy.yyy
(83482249 octets).
***

In the first line, a negative number of octets is displayed while the second
line shows a sane value. I keep most mails (except spam and MDNs) received in
the first account, and apparently I've hit the 2-GB-threshold some time ago, so
the mailbox size can't be calculated correctly any longer. Could you do some
magic, please, so the correct size is shown again -- or do I really have no
other choice than starting to delete old mails? :-)

Best regards

Andreas



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

Kernel: Linux 4.12.0-1-amd64 (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 fetchmail depends on:
ii  adduser   3.116
ii  debianutils   4.8.2
ii  libc6 2.24-17
ii  libcomerr21.43.5-1
ii  libgssapi-krb5-2  1.15.1-2
ii  libk5crypto3  1.15.1-2
ii  libkrb5-3 1.15.1-2
ii  libssl1.1 1.1.0f-5
ii  lsb-base  9.20170808

Versions of packages fetchmail recommends:
ii  ca-certificates  20170717

Versions of packages fetchmail suggests:
pn  fetchmailconf   
ii  postfix [mail-transport-agent]  3.2.2-1
ii  resolvconf  1.79

-- Configuration Files:
/etc/default/fetchmail changed [not included]

-- no debconf information

Bug#873667: casacore: Changes needed for python3.6 compatibility

[Steve Langasek]

Package: casacore
Version: 2.3.0-3
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

In Ubuntu, we discovered that python-casacore was failing to build from
source on i386 after casacore had been rebuilt for the python3.6 transition. 
Surprisingly, the reason for this was that casacore's python3 detection - on
all architectures - had failed against python3.6 and instead linked
everything against libpython2.7.  Things nevertheless continued to work,
except on i386 where python-casacore loading libpython2.7 into a running
python3.6 process caused a segfault.

The amazing thing was that this managed to work anywhere else.

I've applied the attached patch to casacore in Ubuntu to add python3.6 to
the search path, fixing the misbuild.  Of course, the problem will recur
when python3.7 comes out, so a better upstream fix would be nice.

Filing this bug as important, but please note that python3.6 is coming soon
in Debian at which point this should be considered serious.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru casacore-2.3.0/debian/patches/fix-python3.6-detection.patch 
casacore-2.3.0/debian/patches/fix-python3.6-detection.patch
--- casacore-2.3.0/debian/patches/fix-python3.6-detection.patch 1969-12-31 
16:00:00.0 -0800
+++ casacore-2.3.0/debian/patches/fix-python3.6-detection.patch 2017-08-29 
14:58:08.0 -0700
@@ -0,0 +1,20 @@
+Description: add support for python3.6
+ The python3 detection code only correctly picks up listed versions of
+ python3 on Debian/Ubuntu.  Otherwise it incorrectly falls back to
+ /usr/bin/python and python2.7!
+Author: Steve Langasek 
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1710532
+
+Index: casacore-2.3.0/python3/CMakeLists.txt
+===
+--- casacore-2.3.0.orig/python3/CMakeLists.txt
 casacore-2.3.0/python3/CMakeLists.txt
+@@ -18,7 +18,7 @@
+ endif()
+ 
+ # Detect the python properties
+-set(Python_ADDITIONAL_VERSIONS 3.5 3.4)
++set(Python_ADDITIONAL_VERSIONS 3.6 3.5 3.4)
+ 
+ find_package(Python REQUIRED)
+ 
diff -Nru casacore-2.3.0/debian/patches/series 
casacore-2.3.0/debian/patches/series
--- casacore-2.3.0/debian/patches/series2017-07-04 03:09:42.0 
-0700
+++ casacore-2.3.0/debian/patches/series2017-08-29 14:54:46.0 
-0700
@@ -9,3 +9,4 @@
 Fix-compilation-for-GNU-Hurd.patch
 Fix-too-small-int-type-for-memory-on-32-bit-machines.patch
 Fix-FTBFS-tStatisticsUtilities-tLatticeStatistics-and-tLC.patch
+fix-python3.6-detection.patch

Bug#873302: openvpn: openssl 1.1 tls version support

[Bernhard Schmidt]

On 28.08.2017 18:43, Kurt Roeckx wrote:

Hi,

>>> Source: openvpn
>>> Version: 2.4.3-4
>>> Severity: important
>>> Tags: patch
>>>
>>> Hi,
>>>
>>> The attached patch add supports for the new way of setting up the
>>> minimum and maximum supported TLS version in OpenSSL.
>>>
>>> This is marked as important because if you switch to openssl 1.1.0
>>> the defaults minimum version in Debian is currently TLS 1.2 and
>>> you can't override it with the options that you're currently using
>>> (and are deprecated).
>>
>> Thanks a lot. Could you please submit this as patch to the openvpn-devel
>> ML (https://sourceforge.net/p/openvpn/mailman/openvpn-devel/)? The devs
>> are pretty active there and I'd like to have patches like this upstream.
> 
> I really don't want to subscribe to a list just to post a patch.
> 
> What about creating a github pull request?

In OpenVPN all patches need to go through the mailinglist, see
https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation .

The list is well moderated so you might just send it to
openvpn-de...@lists.sourceforge.net .

IME it does not make sense for us to forward this patch to the ML, I'm
sure there will be follow-up questions regarding compatibility, usecases
etc.

Bernhard

Bug#851825: ethtool: ifdown/ifup sequence fails if offload_tx off is set in iface stanza

[Ben Hutchings]

Control: tag -1 moreinfo

On Thu, 19 Jan 2017 06:55:44 +0100 Daniel Reichelt  
wrote:
> Package: ethtool
> Version: 1:4.8-1
> Severity: normal
> 
> Hi,
> 
> in network/interfaces I have set the option "offload_tx off" for eth0. This
> causes `ifdown eth0 ; ifup eth0` to fail when offloading already
> was set to off.
> 
> The culprit is ethtool, which inconsistently exits 0 or 1 when offloading is
> enabled/disabled repeatedly:
[...]

I can't reproduce this.  What driver is used for eth0 (ethtool -i shows
this)?

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.



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

Bug#873666: libxalan-c111: Patch to correct erroneous assumptions about XMLCh type

[Roger Leigh]

Package: libxalan-c111
Version: 1.11-6
Severity: important
Tags: patch

The attached patch corrects some broken assumptions about the nature of 
XMLCh* in the xalan source.


See https://issues.apache.org/jira/browse/XALANC-773

This is required for xerces 3.2.0 where XMLCh == char16_t.


Regards,
Roger
diff -urN xalan-c-1.11.orig/c/src/xalanc/PlatformSupport/DirectoryEnumerator.hpp xalan-c-1.11/c/src/xalanc/PlatformSupport/DirectoryEnumerator.hpp
--- xalan-c-1.11.orig/c/src/xalanc/PlatformSupport/DirectoryEnumerator.hpp	2012-03-19 16:18:10.0 +
+++ xalan-c-1.11/c/src/xalanc/PlatformSupport/DirectoryEnumerator.hpp	2017-08-09 12:05:08.604342028 +0100
@@ -84,7 +84,7 @@
 const XalanDOMChar*
 getName() const
 {
-return name;
+return const_cast(reinterpret_cast([0]));
 }
 
 /**
@@ -261,7 +261,7 @@
 #pragma warning(disable: 4244)
 theHandleType   theSearchHandle =
 _wfindfirst(
-const_cast(theConversionFunction(theFullSearchSpec)),
+reinterpret_cast(const_cast(theConversionFunction(theFullSearchSpec))),
 );
 #pragma warning(pop)
 
diff -urN xalan-c-1.11.orig/c/src/xalanc/PlatformSupport/DOMStringHelper.cpp xalan-c-1.11/c/src/xalanc/PlatformSupport/DOMStringHelper.cpp
--- xalan-c-1.11.orig/c/src/xalanc/PlatformSupport/DOMStringHelper.cpp	2012-03-19 16:18:10.0 +
+++ xalan-c-1.11/c/src/xalanc/PlatformSupport/DOMStringHelper.cpp	2017-08-09 12:05:08.604342028 +0100
@@ -868,7 +868,7 @@
 const XalanDOMChar* theRHS)
 {
 #if defined(XALAN_USE_WINDOWS_COLLATION)
-return _wcscoll_l(theLHS, theRHS, s_locale);
+return _wcscoll_l(reinterpret_cast(theLHS), reinterpret_cast(theRHS), s_locale);
 #else
 return doCollationCompare(
 theLHS,
diff -urN xalan-c-1.11.orig/c/src/xalanc/PlatformSupport/XalanFileOutputStream.cpp xalan-c-1.11/c/src/xalanc/PlatformSupport/XalanFileOutputStream.cpp
--- xalan-c-1.11.orig/c/src/xalanc/PlatformSupport/XalanFileOutputStream.cpp	2012-03-19 16:18:10.0 +
+++ xalan-c-1.11/c/src/xalanc/PlatformSupport/XalanFileOutputStream.cpp	2017-08-09 12:05:08.604342028 +0100
@@ -123,7 +123,7 @@
 
 #if defined(XALAN_WINDOWS)
 HandleType  theFileHandle = CreateFileW(
-theFileName.c_str(),
+reinterpret_cast(theFileName.c_str()),
 GENERIC_WRITE,
 0,
 0,

Bug#866843: New maintainer for chkrootkit

[Marcos Fouces]

Hello

I close this bug as chkrootkit is currently maintained by the Debian 
pkg-security tools team.

Bug#873309: stretch-pu: package request-tracker4/4.4.1-3+deb9u3

[Dominic Hargreaves]

On Sun, Aug 27, 2017 at 02:41:22PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2017-08-26 at 12:40 +0100, Dominic Hargreaves wrote:
> > A regression was discovered in the latest security patch update for
> > RT which can cause incorrect UTF-8 encoded passwords to cause an
> > application error. This is not in itself considered a security
> > problem.
> > 
> > The attached debdiff applies a patch which has been included in the
> > official upstream releases including the security fixes.
> 
> With the changelog finalised with a distribution of "stretch", please go
> ahead.

Thanks, now uploaded. I took a chance and hoped that source-only
uploads were accepted for stretch-proposed-updates - we'll see...

Bug#873310: jessie-pu: package request-tracker4/4.2.8-3+deb8u3

[Dominic Hargreaves]

On Sun, Aug 27, 2017 at 02:21:46PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2017-08-26 at 12:41 +0100, Dominic Hargreaves wrote:
> > A regression was discovered in the latest security patch update for
> > RT which can cause incorrect UTF-8 encoded passwords to cause an
> > application error. This is not in itself considered a security
> > problem.
> > 
> > The attached debdiff applies a patch which has been included in the
> > official upstream releases including the security fixes.
> 
> +request-tracker4 (4.2.8-3+deb8u3) UNRELEASED; urgency=medium
> 
> With the distribution set to "jessie", please go ahead.

Thanks, now uploaded.

Bug#873665: Cannot install steam (related to libgl1-mesa-dri:i386, libllvm4.0:i386)

[Jannis Teunissen]

Source: steam
Version: 1.0.0.54-2
Severity: important

Dear Maintainer,

   * What led up to the situation?

Trying to install steam

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

Here are the commands I tried followed by the errors:

1. apt install steam

The following packages have unmet dependencies:
steam:i386 : Depends: libgl1-mesa-dri:i386 but it is not going to be installed

2. apt install libgl1-mesa-dri:i386

libgl1-mesa-dri:i386 : Depends: libllvm4.0:i386 (>= 1:4.0~) but it is not going 
to be installed

3. apt install libllvm4.0:i386

The following packages will be REMOVED:
  doxygen libclang-common-4.0-dev libclang1-4.0 libclc-amdgcn libclc-r600
  libgl1-mesa-dri libllvm4.0 libxatracker2 mesa-opencl-icd mesa-va-drivers
  mesa-vdpau-drivers task-desktop task-xfce-desktop vdpau-driver-all xorg
  xserver-xorg-video-all xserver-xorg-video-vmware

Removing these packages seems like a bad idea.

   * What was the outcome of this action?

Didn't work

   * What outcome did you expect instead?

That steam would be installed.

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

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

Bug#853285: closed by Clint Adams <cl...@debian.org> (Bug#853285: fixed in ghc 8.0.2-3)

[John Paul Adrian Glaubitz]

On 08/29/2017 11:44 PM, James Clarke wrote:

I believe is this because haskell-devscripts-minimal is arch:all, so any
architecture information does not propagate through. If my understanding is
correct, making haskell-devscripts-minimal an arch:any package and using a
:native Build-Depends on haskell-devscripts-minimal would fix this, but I'm
sure Helmut can clarify?


I was discussing this issue at DebConf and I had the idea to try changing the
dependency of haskell-devscripts-minimal on GHC from "ghc" to "ghc:native",
but, unfortunately, dpkg doesn't support these qualifiers in the Depends field.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#853285: closed by Clint Adams <cl...@debian.org> (Bug#853285: fixed in ghc 8.0.2-3)

[James Clarke]

On 29 Aug 2017, at 22:16, John Paul Adrian Glaubitz 
 wrote:
> On 08/29/2017 11:12 PM, Gianfranco Costamagna wrote:
>>> Here's an updated patch for 8.0.2-9.
>> committed (I don't even know how to test it properly) on git, but obviously 
>> not uploaded.
> 
> Thanks! You can easily test it by performing a regular GHC testbuild on a 
> porterbox as
> well as a cross-build by just passing "--host=armhf" on the sbuild command 
> line.
> 
> Unfortunately, as previously explained, one still has to preinstall 
> haskell-devscripts-minimal
> in the build chroot used for cross-compiling (this is a limitation of dpkg 
> that I will
> file a bug report for), but at least bootstrapping GHC for a new architecture 
> is much
> easier now.

I believe is this because haskell-devscripts-minimal is arch:all, so any
architecture information does not propagate through. If my understanding is
correct, making haskell-devscripts-minimal an arch:any package and using a
:native Build-Depends on haskell-devscripts-minimal would fix this, but I'm
sure Helmut can clarify?

James

Bug#873627: udisks2 in sid apparently left me with a borked system in plasma(?)

[Diederik de Haas]

This is essentially a +1 message and downgrading udisks2 + libudisks2-0 to the 
testing version fixed it for me too

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

Bug#873644: please check whether wiki page regarding caff is still correct

[Guilhem Moulin]

Hi,

On Tue, 29 Aug 2017 at 20:44:41 +0200, Marc Haber wrote:
> the Wiki page on https://keyring.debian.org/creating-key.html mentions
> that some lines from ~/.gnupg/gpg.conf need to be copied to
> ~/.caff/gnupghome/gpg.conf to avoid my caff signatures being SHA-1.

(X-Debbugs-Cc'ing keyring-ma...@debian.org, which according to the
footer is the address to use to report problems with that page.)
 
> Otoh, current caff versions in unstable don't seem to write
> ~/.caff/gnupghome/gpg.conf at all.
> 
> Is the information from the wiki, on a rather sensitive place about key
> generation for DDs, still current? I think some clarification is needed,
> but I do not have the deep caff knowledge needed to judge that.

Oops I updated https://wiki.debian.org/caff but forgot about the page on
keyring.d.o.  Indeed ~/.caff/gnupghome/gpg.conf is no longer needed
since signing-party 2.3:

  - if the file exists then it needs to be kept up-to-date;
  - if it doesn't exist then gpg(1) options that are known to be safe
for caff(1), including ‘cert-digest-algo’, are taken from
~/.gnupg/gpg.conf.  

So new caff users don't have to create ~/.caff/gnupghome/gpg.conf :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#873664: gladish fails to configure jack without python-xdg installed but python-xdg is not a dependency

[mchristias]

Package: gladish
Version: 1+dfsg0-5.1
Severity: normal

Dear Maintainer,

To reproduce the bug:
1) Open gladish
2) Choose from menu: Studio --> New Studio
3) Give any name and press 
4) Choose from menu: Tools --> Configure Jack

A window should appear with jack configuration but nothing happens, so the
user can not configure jack.
If you start gladish from a terminal and follow the same steps, after
clicking "Configure Jack" this message appears:

JACK configure request
Traceback (most recent call last):
  File "/usr/bin/ladi-control-center", line 28, in 
from laditools import _gettext_domain
  File "/usr/lib/python2.7/dist-packages/laditools/__init__.py", line 25, in 

from .config import LadiConfiguration
  File "/usr/lib/python2.7/dist-packages/laditools/config.py", line 22, in 

from xdg import BaseDirectory as basedir
ImportError: No module named xdg

After installing python-xdg, gladish shows jack configuration normally.
So, perhaps python-xdg should be a dependency or, at least, a recommendation 
for gladish?


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

Kernel: Linux 4.9.0-3-amd64 (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 gladish depends on:
ii  ladish1+dfsg0-5.1
ii  libart-2.0-2  2.3.21-2
ii  libatk1.0-0   2.22.0-1
ii  libatkmm-1.6-1v5  2.24.2-2
ii  libc6 2.24-11+deb9u1
ii  libcairo2 1.14.8-1
ii  libcairomm-1.0-1v51.12.0-1+b1
ii  libdbus-1-3   1.10.18-1
ii  libdbus-glib-1-2  0.108-2
ii  libflowcanvas5v5  0.7.1+dfsg0-0.4
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.50.3-2
ii  libglibmm-2.4-1v5 2.50.0-1
ii  libgnomecanvas2-0 2.30.3-3
ii  libgnomecanvasmm-2.6-1v5  2.26.0-2+b1
ii  libgtk2.0-0   2.24.31-2
ii  libgtkmm-2.4-1v5  1:2.24.5-1
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libpangoft2-1.0-0 1.40.5-1
ii  libpangomm-1.4-1v52.40.1-3
ii  libsigc++-2.0-0v5 2.10.0-1
ii  libstdc++66.3.0-18

Versions of packages gladish recommends:
ii  laditools  1.1.0-2

gladish suggests no packages.

-- no debconf information



Michalis Christias

Bug#849505: transition: nodejs

[Sebastiaan Couwenberg]

On 06/25/2017 01:15 PM, Jonathan Wiltshire wrote:
> Now stretch is released we can deal with this.
> 
> On Wed, Dec 28, 2016 at 12:49:33AM +0100, Jérémy Lal wrote:
>> Transition should have minimal impact on these addons.
>> Most other pure Node.js modules should be okay - they either
>> are already compatible with Node.js 6 or have upstream updates
>> providing that compatibility.
> 
> This sounds rather, well, hopeful. Please stage the transition in
> experimental first, and test/fix reverse dependencies. Then come back and
> we'll schedule a time to do it in unstable.
> 
> (Transitions should really be ready to go by the time they come to us;
> they should also be able to happen quickly, because a blocked transition
> holds up all sorts of other work.)

Jérémy, the transition was started by the upload of nodejs to unstable,
but you've not replied to the above yet.

Can you confirm that all reverse dependencies build successfully with
the new nodejs in unstable?

If so, the binNMUs can be scheduled to move this transition along.

I just uploaded a new upstream release of node-mapnik, that won't need
an NMU now, but the other rdeps still do.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#853285: closed by Clint Adams <cl...@debian.org> (Bug#853285: fixed in ghc 8.0.2-3)

[John Paul Adrian Glaubitz]

Hi Gianfranco!

On 08/29/2017 11:12 PM, Gianfranco Costamagna wrote:

Here's an updated patch for 8.0.2-9.


committed (I don't even know how to test it properly) on git, but obviously not 
uploaded.


Thanks! You can easily test it by performing a regular GHC testbuild on a 
porterbox as
well as a cross-build by just passing "--host=armhf" on the sbuild command line.

Unfortunately, as previously explained, one still has to preinstall 
haskell-devscripts-minimal
in the build chroot used for cross-compiling (this is a limitation of dpkg that 
I will
file a bug report for), but at least bootstrapping GHC for a new architecture 
is much
easier now.


(I don't think it is worth an upload)


No problem.


Please forward the patches upstream whenever possible!


Most of the patches are already upstreamed, I think there is only one that 
might be
missing. I'll have another look.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#873663: syncthing: Missing service files for discovery and relay service

[Achim Schaefer]

Package: syncthing
Version: 0.14.36+ds1-2
Severity: normal

Dear Maintainer,

the changes in the release are the service files for the dicovery and relay 
server.
Both are part of the installed package.
As well the new directories ate not created.
The user is missing as well.

Thanks

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

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

Versions of packages syncthing depends on:
ii  init-system-helpers  1.49
ii  libc62.24-17

syncthing recommends no packages.

syncthing suggests no packages.

-- no debconf information

Bug#873634: missing module files libbd_*.so

[Amaury Pouly]

> apt install libblockdev-crypto2 libblockdev-mdraid2 libblockdev-part2
> libblockdev-fs2 libblockdev-loop2 libblockdev-swap2
>
I missed the fact that I also needed to install 'gdisk', otherwise it 
fails with

Cannot load the part plugin: The 'sgdisk' utility is not available

This is odd because https://tracker.debian.org/news/866785 mentions 
gdisks is no longer recommended by the package but is still needed?

Bug#853285: closed by Clint Adams <cl...@debian.org> (Bug#853285: fixed in ghc 8.0.2-3)

[Gianfranco Costamagna]

Hello,


>Here's an updated patch for 8.0.2-9.


committed (I don't even know how to test it properly) on git, but obviously not 
uploaded.
(I don't think it is worth an upload)

Please forward the patches upstream whenever possible!
thanks

G.

Bug#873608: patch

[Paul Tagliamonte]

Whoops, I only just read the comment about this not being standard in
armhf. I misread that and also assumed it was standard (likely because,
as a Coretex-A* user, I always had it), so this patch will likely be
inappropriate (or incomplete). Maybe this patch plus an AND on an
ENABLE_NEON or something, which is disabled by default in the packaging.

  Paul


On Tue, Aug 29, 2017 at 04:10:30PM -0400, Paul Tagliamonte wrote:
> tags 873608 + patch
> thanks
> 
> Attached is a patch that will enable neon if arm_neon.h is present. I
> didn't upstream this or anything, I figure you have a better
> relationship with them, but this ought to fix the ftbfs.
> 
> I'm running a test build now, but it's past the old ftbfs point
> 
>   Paul
> 
> -- 



-- 

Bug#873661: Switch back to default GCC

[Michael Biebl]

Source: systemd
Version: 234-2.3
Severity: normal

Due to bug in GCC-7 on mips64el, which caused test-suite failures,
systemd was switched to GCC-6 to work around that issue.

Once #871514 is fixed, we should drop
export CC = gcc-6
export CXX = g++-6
from debian/rules again.


-- Package-specific info:

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

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

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 234-2.3

-- no debconf information

Bug#873634: missing module files libbd_*.so

[Amaury Pouly]

Same problem here. Tracking down the missing files, I found that 
installing the following packages solves the problem:


apt install libblockdev-crypto2 libblockdev-mdraid2 libblockdev-part2 
libblockdev-fs2 libblockdev-loop2 libblockdev-swap2

Bug#873498: Should depend on "gnupg | gnupg2 | gpg"

[Sean Whitton]

control: tag -1 -moreinfo

Hello Yuri,

On Tue, Aug 29 2017, Yuri D'Elia wrote:

> I currently have an equivs package that provides gnupg2 while depending
> only on gpg to satisfy existing packages, and had no problems. I'm not
> sure what the description intends about "secret keys", since I can
> generate and manipulate secret keys as usual.

Okay, thanks for the feedback.  Will test.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#873659: libhypre-2.11.1-3: Hypre-2.11.1-3 wont install properly

[Gary L. Roach]

Package: libhypre-2.11.1-3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Attempted to install hypre using aptitude install hypre-2.11.1
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Uninstalled package, purged package. ran apt-get clean.
   * What was the outcome of this action?
The installation still only installed /usr/share/doc, 
/var/cache/apt/archives/libhypre-2.11.1_2.11.1-3amd64.deb and
/var/lib/dpkg/info. The actual library was never installed.
   * What outcome did you expect instead?
A viable installation.

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


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

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

Bug#873660: calibre: uses outdated mspack with security problems

[Jonatan Nyberg]

Package: calibre
severity: important

Dear Maintainer,

Kovid Goyal just fixed some sexurity bugs. It is important to update
calibre as soon as possible.

Links:
https://bugs.launchpad.net/calibre/+bug/1713716
https://github.com/kovidgoyal/calibre/commit/181f5952949156812285d47a03
07e482619cf7d0

Kind regards,
Jonatan

Bug#866337: kASLR breaks resume from hibernation on Thinkpad X220i

[Frank DeMarco]

Hi,

Adding nokaslr to the kernel options also fixes hibernation on my Dell
Latitude E6400 laptop. Without that option, it hangs on wake up.

In /etc/default/grub I changed

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

to

GRUB_CMDLINE_LINUX_DEFAULT="quiet nokaslr"

and ran update-grub

Bug#873634: missing module files libbd_*.so

[Miguel A. Vallejo]

Same problem here. The only solution I found was to return to the
previous version (2.6.5-2).

Bug#862380: Any news?

[Andreas Tille]

Hi Michael,

any news about this?  You said you would like to care for the package.
If it turns out that the real solution takes longer why not applying the
originally suggested patch and continue from a somehow working package?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#860055: Inquiry about packaging progress

[Marcus Poller]

Dear Stefan,

gentle ping? What's the status of your packaging work? I'ld love to use this 
package.

Cheers,
Marcus

Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!

[Francesco Poli]

Control: found -1 systemd/234-2.3


On Sat, 31 Dec 2016 16:10:13 +0100 Francesco Poli wrote:

[...]
> On Fri, 30 Dec 2016 19:37:48 +0100 Michael Biebl wrote:
> 
> > On Sat, 13 Feb 2016 22:02:02 +0100 Francesco Poli
> >  wrote:
> [...]
> > > Hello again,
> > > have you found a way to reproduce the bug?
> > > 
> > 
> > Unfortunately I have not. Can you still reproduce the issue with v232?
> 
> Yes, I have just reproduced the bug.
> I lost control of my X session, then I regained control of my box
> (since I had scheduled a "killall -TERM fluxbox" with at(1)).
> The misbehavior seems to be identical to the one I experienced when I
> originally reported the bug.

Is there any progress on this issue?
Did you manage to reproduce it?
Have you pinpointed its cause?

I have just tested version 234-2.3 of systemd (currently in Debian
testing) and I again reproduced the issue.

Please let me know.
Thanks for your time!



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


pgp11StKxhA26.pgp
Description: PGP signature

Bug#873608: patch

[Paul Tagliamonte]

tags 873608 + patch
thanks

Attached is a patch that will enable neon if arm_neon.h is present. I
didn't upstream this or anything, I figure you have a better
relationship with them, but this ought to fix the ftbfs.

I'm running a test build now, but it's past the old ftbfs point

  Paul

-- 
Description: When building for armhf, enable NEON
 NEON is part of the armhf baseline, so this will always be enabled on
 armhf.
Author: Paul Tagliamonte 
Bug-Debian: https://bugs.debian.org/873608
Origin: vendor
Last-Update: 2017-08-29

--- uhd-3.10.2.0.orig/host/lib/convert/CMakeLists.txt
+++ uhd-3.10.2.0/host/lib/convert/CMakeLists.txt
@@ -67,6 +67,8 @@ IF(HAVE_ARM_NEON_H AND (${CMAKE_SIZEOF_V
 ${CMAKE_CURRENT_SOURCE_DIR}/convert_with_neon.cpp
 ${CMAKE_CURRENT_SOURCE_DIR}/convert_neon.S
 )
+
+SET ( CMAKE_CXX_FLAGS "-mfpu=neon" )
 ENDIF()
 
 

Bug#872749: [Pkg-lirc-maint] Bug#872749: lircd logs all messages twice

[Jörg Frings-Fürst]

Hi Alec,

Am Montag, den 21.08.2017, 16:59 +0200 schrieb Alec Leamas:
> 
> On 21/08/17 16:50, Jörg Frings-Fürst wrote:
> > Am Montag, den 21.08.2017, 09:32 +0200 schrieb Alec Leamas:
> > > On 21/08/17 09:04, Jörg Frings-Fürst wrote:
> > > > > > Aug 20 20:38:21 merkur lircd[2361]: lircd-0.9.4c[2361]: Error: 
> > > > > > Cannot glob
> > > > > > /sys/class/rc/rc0/input[0-9]*/event[0-9]*
> > > > > > Aug 20 20:38:21 merkur lircd-0.9.4c[2361]: Error: Cannot glob
> > > > > > /sys/class/rc/rc0/input[0-9]*/event[0-9]*
> > > > > > 
> > > > > 
> > > > > I cannot reproduce this, neither on sid (0.10.0) nor stretch (0.9.4c).
> > > > > Is there some local configuration involved?
> > > > > 
> > > > 
> > > > The same can see you at[1]. So it the local configuration. Hans and I
> > > > don't change any lirc[d] config files.
> > > 
> > > If this a configuration issue, it's likely to be about syslog or
> > > possibly systemd configuration. You are using journalctl to examine the
> > > logs, right?
> > > 
> > 
> > [...]
> > Never. I use (r)syslog.
> 
> As a starter,  what happens if you use journalctl to inspect the logs?  
> Still same error?  We need to establish the difference between your 
> setup and those I use...
> 
Its the same (log all twice):


Aug 29 05:41:28 merkur lircd[4494]: lircd-0.10.0[4494]: Error: Cannot glob 
/sys/class/rc/rc0/input[0-9]*/event[0-9]*
Aug 29 05:41:28 merkur lircd-0.10.0[4494]: Error: Cannot glob 
/sys/class/rc/rc0/input[0-9]*/event[0-9]*
Aug 29 05:41:29 merkur lircd[4494]: lircd-0.10.0[4494]: Error: Cannot glob 
/sys/class/rc/rc0/input[0-9]*/event[0-9]*
Aug 29 05:41:29 merkur lircd-0.10.0[4494]: Error: Cannot glob 
/sys/class/rc/rc0/input[0-9]*/event[0-9]*



> Cheers!
> 
> --alec
> 

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
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#873658: synergy uses wrong compatibility layer of Avahi

[Jörg Frings-Fürst]

Package: synergy
Version: 1.8.8-stable+dfsg.1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

at startup I get this messages:


[quote]
Aug 29 05:41:22 merkur synergy[7432]: *** WARNING *** The program 'synergy'
uses the Apple Bonjour compatibility layer of Avahi.
Aug 29 05:41:22 merkur synergy[7432]: *** WARNING *** Please fix your
application to use the native API of Avahi!
Aug 29 05:41:22 merkur synergy[7432]: *** WARNING *** For more information see

Aug 29 05:41:22 merkur synergy[7432]: *** WARNING *** The program 'synergy'
called 'DNSServiceRegister()' which is not supported (or only supported
partially) in the Apple Bonjour compatibility layer of Avahi.
Aug 29 05:41:22 merkur synergy[7432]: *** WARNING *** Please fix your
application to use the native API of Avahi!
Aug 29 05:41:22 merkur synergy[7432]: *** WARNING *** For more information see

[/quote]


CU
Jörg



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

Kernel: Linux 4.12.0-1-amd64 (SMP w/6 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 synergy depends on:
ii  libavahi-compat-libdnssd1  0.6.32-2
ii  libc6  2.24-14
ii  libcurl3-gnutls7.55.0-1
ii  libgcc11:7.2.0-1
ii  libqt4-network 4:4.8.7+dfsg-11
ii  libqtcore4 4:4.8.7+dfsg-11
ii  libqtgui4  4:4.8.7+dfsg-11
ii  libssl1.1  1.1.0f-4
ii  libstdc++6 7.2.0-1
ii  libx11-6   2:1.6.4-3
ii  libxext6   2:1.3.3-1+b2
ii  libxi6 2:1.7.9-1
ii  libxinerama1   2:1.1.3-1+b3
ii  libxrandr2 2:1.5.1-1
ii  libxtst6   2:1.2.3-1
ii  openssl1.1.0f-4

synergy recommends no packages.

synergy suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlmlx9sACgkQCfifPIyh
0l0inRAArPLY7+UxjcBThW/O4C6wE3WbqYp+WO22N74UY0mh6Na0bZQdSQO0gbN3
fWyG0aRie3beGPU4wsXOIfmkKUeX8M904/WbvaEKFE7C2DpNmqaHYwsPZswK+G0D
PNDO1MrvQsjZlz1qsrYYBTNsTRfyTWJLryBVUAO/+5HNyhzrlRAi3m0HKqi1BOFw
rDQ79OU37chauoWgA514CSEVgQ+MRtix6Whk2bn1dg8anKLQDQ6A+Y5jX52ZREYe
k9+SCNHIuudZ8bwVFnnXua8P20gJ1wc3Hf6/8IsBAHQlK6ev/eI5dFU/A+29X5JH
nDCzPf9ZnuyNmMejDnVFhAWwp5XAjiMro2vuqI07RTaJeq8RTuL2Grlyg+f3oUoM
ZbokWSma6GutbBitb63rpJJR/vNzb2ZceOSSIHBPIzT7rwrSMPeUClmQD9QJrNYC
d7SGdbWtpIX8qpnZeNDSm+B/TgNWd42CUqo9Q2k19BT0dCks9GaQld3iKc69UUci
ATyd+TRxwY6ME2lODOydTKQB4LPgSP7IlHy3sYRv+DLQQ40ChagCj5XfflNFeTGE
iRydsvV1M9AhM3H5maiql4mTen5f6XFyxkZ9XAJq2r06eVRxxqczLt/cqtqETT3k
XvYKQb7nnQFaSbmyMuW2BXFgiHFJA+glUzfw2cOqQD2n+pCkqjQ=
=qLXj
-END PGP SIGNATURE-

Bug#868021: ffcall: diff for NMU version 1.13-0+nmu1

[Sébastien Villemot]

Dear Frédéric,

On Tue, 11 Jul 2017 11:25:11 +0200 =?UTF-8?B?RnLDqWTDqXJpYw==?= Bonnard 
 wrote:
> Package: src:ffcall
> Version: 1.10+cvs20100619-4
> Severity: normal
> Tags: patch pending
> 
> Dear maintainer,
> 
> I've prepared diff for a NMU for ffcall (versioned as 1.13-0+nmu1) in the
> attached patch but feel free to use the patch as you want.
> The goal was initially to fix the FTBFS impacting mlpcap on ppc64el
> https://buildd.debian.org/status/fetch.php?pkg=mlpcap=ppc64el=0.9-16=1485552538=0
> 
> config.log would show :
> configure:4214: gcc -o conftest -g -O2 
> -fdebug-prefix-map=/build/mlpcap-gmmM7n/mlpcap-0.9=. -fstack-protector-strong 
> -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro conftest.
> c -lcallback  -lpcap  >&5
> /usr/lib/gcc/powerpc64le-linux-gnu/6/../../../powerpc64le-linux-gnu/libcallback.so:
>  undefined reference to `tramp_r'
> 
> But this upload could fix other bugs as well.
> 
> Looking at ffcal upstream, I see that there a much newer version of ffcall 
> namely
> 1.13 which contains amongst other ppc64el improvements which fixed the build
> of mlpcap (tested).
> I tried to change the bare minimum of the packaging so that we have something 
> close
> to 1.10+cvs20100619-4 but still building. Here are the changes I made :
> debian/patches : I've updated fix-powerpcspe.patch, and 
> Fix_MIPS_N32_test.patch : please
>  review them.
>  I've disabled ppc64el-elfv2.patch as ppc64el support should 
>be good in 1.13.
>  I've also commented 0001-fix-callback-on-x86_64.patch as it 
>should be
>  fixed upstream : 
>https://www.bountysource.com/issues/20684153-segfault
> debian/rules :   autoreconf failed as is, so I added gnulib-m4 to aclocal 
> path and removed
>  skipping of libtoolize.
> debian/libffcall1.symbols : some symbols seem local (__*) so no need to check 
> them I
>  think. There were some new additions.
> debian/watch :   I updated the repo URL which seemed to not work anymore at 
> all (server not found)

Thanks for your patch. I am currently working on updating ffcall, based
on what you did (unless Christoph Egger is faster than me!).

However, could you please give a detailed explanation of what your
updated Fix_MIPS_N32_test.patch does? You modified several assembly
files, and this needs explaining for non-mips-specialists.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


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

Bug#812826: xim problem

[Sean Whitton]

control: forwarded -1 https://github.com/ibus/ibus/issues/1847
control: outlook -1 workaround: pkill -u $USER ibus-daemon; 
IBUS_ENABLE_SYNC_MODE=0 ibus-daemon --xim --daemonize

Hello Osamu,

On Tue, Aug 29 2017, Osamu Aoki wrote:

> Yes.  But if ibus related libraries are available it uses such library
> to pass input instead of using xim.  If ibus related libraries aren't
> available, ibus use xim to pass keyboard input.

Okay.

I finally found a workaround:

pkill -u $USER ibus-daemon; IBUS_ENABLE_SYNC_MODE=0 ibus-daemon --xim 
--daemonize

-- 
Sean Whitton

Bug#873627: Request bug reassign

[Fjfj109]

Hi, could you please reclassify this bug as "serious", thanks

Bug#873657: O: python-py -- Advanced Python development support library (Python 2)

[Sebastian Ramacher]

Package: wnpp
Severity: normal

I intend to orphan the python-py package. I no longer have any interest in it.

The package description is:
 The Codespeak py lib aims at supporting a decent Python development process
 addressing deployment, versioning and documentation perspectives. It includes:
 .
  * py.path: path abstractions over local and Subversion files
  * py.code: dynamic code compile and traceback printing support

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Didier 'OdyX' Raboud]

Le mardi, 29 août 2017, 17.46:22 h CEST Thorsten Glaser a écrit :
> Leave /usr/bin/nodejs there for at least one more release.

I'll just note for the purpose of the TC discussion that as of nodejs 
6.11.2~dfsg-3 (the version currently in unstable) , the /usr/bin/nodejs → node 
symlink still exists, so at this point, I don't consider there is material for 
a TC decision either way, but it's an important conversation to be had.

Jérémy: could you maybe clarify your plan and your rationale? This would help 
putting everyone on common grounds.

Cheers,
OdyX

Bug#868936: vlc: port to libupnp-1.8

[Sebastian Ramacher]

Control: clone -1 -2
Control: reassign -2 libupnp1.8-dev 1:1.8.2-1
Control: retitle -2 libupnp1.8-dev: Please take over libupnp-dev
Control: block -1 by -2

As the title says, please take over libupnp-dev and coordinate the transition
with the release team.

Cheers

On 2017-08-29 21:05:27, Uwe Kleine-König wrote:
> Control: reassign -1 vlc 2.2.6-4
> 
> Hello,
> 
> On Fri, Jul 28, 2017 at 05:05:35PM +0200, Jean-Baptiste Kempf wrote:
> > Hello Sebastian, Bugreporters,
> > 
> > On Fri, 21 Jul 2017, at 14:58, Sebastian Ramacher wrote:
> > > > On Thu, Jul 20, 2017 at 02:34:42PM +0200, Sebastian Ramacher wrote:
> > > > > > currently there are two versions of libupnp in the archive 
> > > > > > (libupnp6 and
> > > > > > libupnp-1.8-10). To be able to remove libupnp6 (i.e. the older of 
> > > > > > the
> > > > > > two) it is necessary to port vlc (and all other rdepends) to
> > > > > > libupnp-1.8.
> > > > > > 
> > > > > > The patch below implements this for vlc. With this applied I can 
> > > > > > still
> > > > > > playback videos with vlc.
> > > > > 
> > > > > As long as the adoption to upnp 1.8 requires to add -1.8 everywhere 
> > > > > (are we
> > > > > supposed to change it to -1.9 next month with the next upstream 
> > > > > release?), this
> > > > > was explicitly NAKed upstream.
> > > > 
> > > > Which upstream? vlc I suppose? Do you have a link to the discussion
> > > > handy?
> > > 
> > > Yes, vlc upstream. This was over IRC and I don't have logs. But I'm sure
> > > J-B will repeat it if necessary (CCed)
> > 
> > Sure.
> > 
> > Since when releasing a new version of a library requires changing all
> > the includes and all the pkg-config detection?
> > 
> > SO names are done to notate API/ABI changes within a library and
> > PKG-CONFIG files are done to show where to find the includes folder and
> > how to link.
> > 
> > If you do a moderate breaking change, you change the API, the ABI, and
> > bump the library version name majorly. And people linking against you
> > will need to adapt, when they bump the requirements. This was done for
> > almost every minor C/C++ library, since forever.
> > 
> > So, sorry, but this way of renaming the headers folder name and changing
> > the .pc files is completely backward; and sorry, totally not justified,
> > because it's justified for complete rewrites, not for a moderate change.
> 
> OK, libupnp-1.8 was fixed in 1.8.2, I added the updated patch at the end
> of the mail. I hope it is acceptable as is now. I'm rereassigning back
> to vlc accordingly.
> 
> One thing I'd like to point out to prevent surprises: Theoretically
> libupnp should also compile and work on Windows. Depending on how much
> you (vlc) care about your Windows port you might want to evaluate that
> first. I quickly tried to compile libupnp on Windows which failed, but
> the same is true for the 1.6 branch, so this might just be me being
> unable to use the Windows compiler.
> 
> Best regards
> Uwe
> 
> From 7ccf2d2ed3dcc23bbd6f2a3dbf6ba428fc641d1f Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= 
> Date: Wed, 19 Jul 2017 17:26:52 +0200
> Subject: [PATCH] Port vlc to libupnp-1.8
> 
> ---
>  debian/changelog  |  6 ++
>  debian/control|  2 +-
>  debian/patches/0014-port-to-libupnp-1.8.patch | 94 
> +++
>  debian/patches/series |  1 +
>  4 files changed, 102 insertions(+), 1 deletion(-)
>  create mode 100644 debian/patches/0014-port-to-libupnp-1.8.patch
> 
> diff --git a/debian/changelog b/debian/changelog
> index 767b9c2567eb..7476b8575930 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,9 @@
> +vlc (2.2.6-5) UNRELEASED; urgency=medium
> +
> +  * port to libupnp-1.8
> +
> + -- Uwe Kleine-König   Tue, 29 Aug 2017 18:48:43 +
> +
>  vlc (2.2.6-4) unstable; urgency=medium
>  
>* debian/upstream: Add DEP-12 metadata.
> diff --git a/debian/control b/debian/control
> index c9ae459a5545..84bcaa7e9eb6 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -86,7 +86,7 @@ Build-Depends: autopoint,
> libtheora-dev (>= 1.0),
> libtwolame-dev (>= 0.3.8),
> libudev-dev [linux-any],
> -   libupnp-dev,
> +   libupnp1.8-dev,
> libv4l-dev [linux-any],
> libva-dev [kfreebsd-any linux-any],
> libvcdinfo-dev (>= 0.7.22),
> diff --git a/debian/patches/0014-port-to-libupnp-1.8.patch 
> b/debian/patches/0014-port-to-libupnp-1.8.patch
> new file mode 100644
> index ..8e842412cd0c
> --- /dev/null
> +++ b/debian/patches/0014-port-to-libupnp-1.8.patch
> @@ -0,0 +1,94 @@
> +--- a/modules/services_discovery/upnp.cpp
>  b/modules/services_discovery/upnp.cpp
> +@@ -80,7 +80,7 @@
> + /*
> +  * Local prototypes
> +  */
> +-static int Callback( Upnp_EventType event_type, void* p_event, void* 
> 

Bug#870006: Acknowledgement (xserver-xorg: X60 libreboot Xorg hangs reproducibly after upgrade to stretch)

[Michael Kesper]

Dear maintainers,

The issue could be resolved by building and installing coreboot from git head.
Now only the boot password needs to be entered blind.
Feel free to close this bug.

Best wishes
Michael 

Bug#873655: ntirpc: FTBFS on kFreeBSD: in_pktinfo unknown

[Aaron M. Ucko]

Source: ntirpc
Version: 1.4.4-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of ntirpc for kfreebsd-amd64 and kfreebsd-i386 (admittedly not
release architectures) have been failing:

  /«PKGBUILDDIR»/src/svc_internal.h:135:20: error: field 'x' has incomplete type
struct in_pktinfo x;

I suspect the hurd-i386 build would have failed in the same fashion if
not stymied altogether by the absence of libjemalloc-dev there.
Please either accommodate architectures lacking in_pktinfo or limit
ntirpc's Architecture field accordingly.

BTW, I also noticed a lot of noise from redefinitions of (S)LIST_* and
(S)TAILQ_*.  Please consider either explicitly clearing out old
definitions or renaming these macros to avoid clashing with the
existing definitions.

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#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Thorsten Glaser]

On Tue, 29 Aug 2017, Didier 'OdyX' Raboud wrote:

> I'm quite convinced that large parts of the Node.js ecosystem will cope well 
> without any /usr/bin/nodejs available in stretch.
> 
> So I'm not convinced it's really worth the trouble to keep it around for 
> another stable release; I'd probably be fine with a swap of the setup we had 

We might have users who might have scripts invoking nodejs,
users who wish for these scripts to not break just from
upgrading from one release to the other with no way to
make things work on both releases for the interim/migration
period.

So, please keep it.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**Besuchen Sie uns auf der dmexco!**
13. und 14. September 2017, Messe Köln,** Halle 7.1, Stand E042**
Digital Marketing Exposition & Conference
[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

Wir empfehlen unseren Vortrag
"Wettbewerbsanalyse im Handel: Preisvergleich online und offline"
am 13. September, 18:00 Uhr im Speaker's Forum / Broadway

*

**Visit us at dmexco!**
September 13th and 14th, 2017, Messe Köln,** Hall 7.1, Booth E042**
Digital Marketing Exposition & Conference
[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

We recommend our presentation
"Competitor analysis in retail: price comparison online and offline"
on September 13th, at 6 pm at the Speaker's Corner / Broadway

*

Bug#872569: RFS: kadu/4.3-0.1 [RC]

[Andrey Rahmatullin]

On Tue, Aug 29, 2017 at 08:22:28PM +0200, Mateusz Łukasik wrote:
> If parallel is more than 1 (-j1) when is this FTFBS. I will try fix that.
Actually you shouldn't fix that if the package works with -J but fails
with -j.
Please send the nmudiff to the original bug and I will sponsor this.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#873654: python-py-zipkin: Incomplete debian/copyright?

[Chris Lamb]

Source: python-py-zipkin
Version: 0.9.0-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Olivier Sallou 

Hi,

I just ACCEPTed python-py-zipkin from NEW but noticed it was missing 
attribution in debian/copyright for at least Twitter, Inc.

(This is not exhaustive so please check over the entire package 
carefully and address these on your next upload.)


Best wishes,

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

Bug#868936: vlc: port to libupnp-1.8

[Uwe Kleine-König]

Control: reassign -1 vlc 2.2.6-4

Hello,

On Fri, Jul 28, 2017 at 05:05:35PM +0200, Jean-Baptiste Kempf wrote:
> Hello Sebastian, Bugreporters,
> 
> On Fri, 21 Jul 2017, at 14:58, Sebastian Ramacher wrote:
> > > On Thu, Jul 20, 2017 at 02:34:42PM +0200, Sebastian Ramacher wrote:
> > > > > currently there are two versions of libupnp in the archive (libupnp6 
> > > > > and
> > > > > libupnp-1.8-10). To be able to remove libupnp6 (i.e. the older of the
> > > > > two) it is necessary to port vlc (and all other rdepends) to
> > > > > libupnp-1.8.
> > > > > 
> > > > > The patch below implements this for vlc. With this applied I can still
> > > > > playback videos with vlc.
> > > > 
> > > > As long as the adoption to upnp 1.8 requires to add -1.8 everywhere 
> > > > (are we
> > > > supposed to change it to -1.9 next month with the next upstream 
> > > > release?), this
> > > > was explicitly NAKed upstream.
> > > 
> > > Which upstream? vlc I suppose? Do you have a link to the discussion
> > > handy?
> > 
> > Yes, vlc upstream. This was over IRC and I don't have logs. But I'm sure
> > J-B will repeat it if necessary (CCed)
> 
> Sure.
> 
> Since when releasing a new version of a library requires changing all
> the includes and all the pkg-config detection?
> 
> SO names are done to notate API/ABI changes within a library and
> PKG-CONFIG files are done to show where to find the includes folder and
> how to link.
> 
> If you do a moderate breaking change, you change the API, the ABI, and
> bump the library version name majorly. And people linking against you
> will need to adapt, when they bump the requirements. This was done for
> almost every minor C/C++ library, since forever.
> 
> So, sorry, but this way of renaming the headers folder name and changing
> the .pc files is completely backward; and sorry, totally not justified,
> because it's justified for complete rewrites, not for a moderate change.

OK, libupnp-1.8 was fixed in 1.8.2, I added the updated patch at the end
of the mail. I hope it is acceptable as is now. I'm rereassigning back
to vlc accordingly.

One thing I'd like to point out to prevent surprises: Theoretically
libupnp should also compile and work on Windows. Depending on how much
you (vlc) care about your Windows port you might want to evaluate that
first. I quickly tried to compile libupnp on Windows which failed, but
the same is true for the 1.6 branch, so this might just be me being
unable to use the Windows compiler.

Best regards
Uwe

From 7ccf2d2ed3dcc23bbd6f2a3dbf6ba428fc641d1f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= 
Date: Wed, 19 Jul 2017 17:26:52 +0200
Subject: [PATCH] Port vlc to libupnp-1.8

---
 debian/changelog  |  6 ++
 debian/control|  2 +-
 debian/patches/0014-port-to-libupnp-1.8.patch | 94 +++
 debian/patches/series |  1 +
 4 files changed, 102 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/0014-port-to-libupnp-1.8.patch

diff --git a/debian/changelog b/debian/changelog
index 767b9c2567eb..7476b8575930 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+vlc (2.2.6-5) UNRELEASED; urgency=medium
+
+  * port to libupnp-1.8
+
+ -- Uwe Kleine-König   Tue, 29 Aug 2017 18:48:43 +
+
 vlc (2.2.6-4) unstable; urgency=medium
 
   * debian/upstream: Add DEP-12 metadata.
diff --git a/debian/control b/debian/control
index c9ae459a5545..84bcaa7e9eb6 100644
--- a/debian/control
+++ b/debian/control
@@ -86,7 +86,7 @@ Build-Depends: autopoint,
libtheora-dev (>= 1.0),
libtwolame-dev (>= 0.3.8),
libudev-dev [linux-any],
-   libupnp-dev,
+   libupnp1.8-dev,
libv4l-dev [linux-any],
libva-dev [kfreebsd-any linux-any],
libvcdinfo-dev (>= 0.7.22),
diff --git a/debian/patches/0014-port-to-libupnp-1.8.patch 
b/debian/patches/0014-port-to-libupnp-1.8.patch
new file mode 100644
index ..8e842412cd0c
--- /dev/null
+++ b/debian/patches/0014-port-to-libupnp-1.8.patch
@@ -0,0 +1,94 @@
+--- a/modules/services_discovery/upnp.cpp
 b/modules/services_discovery/upnp.cpp
+@@ -80,7 +80,7 @@
+ /*
+  * Local prototypes
+  */
+-static int Callback( Upnp_EventType event_type, void* p_event, void* 
p_user_data );
++static int Callback( Upnp_EventType event_type, const void* p_event, void* 
p_user_data );
+ 
+ const char* xml_getChildElementValue( IXML_Element* p_parent,
+   const char*   psz_tag_name );
+@@ -325,7 +325,7 @@
+ /*
+  * Handles all UPnP events
+  */
+-static int Callback( Upnp_EventType event_type, void* p_event, void* 
p_user_data )
++static int Callback( Upnp_EventType event_type, const void* p_event, void* 
p_user_data )
+ {
+ services_discovery_t* p_sd = ( services_discovery_t* ) p_user_data;
+ 

Bug#873630: RFS: python-qtpy/1.3.1-1

[Herbert Fortes]

Hi Ghislain Vaillant,

> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for the following package:
> 
> * Package name: python-qtpy
>   Version : 1.3.1-1
>   Upstream Author : The Spyder Development Team
> * URL : https://github.com/spyder-ide/qtpy
> * License : Expat
>   Section : python
> 
> Please check out the package by visiting the following URL:
> 
>   https://anonscm.debian.org/git/python-modules/packages/python-qtpy.git
> 
> Changes since last upload:
> 
>   * Switch from git-dpm to gbp
>   * Source new releases from PyPI
>   * New upstream version 1.3.1
>   * Add new install dependency on pyqt5.qtopengl
>   * Bump standards version to 4.1.0
> 
> Regards,
> Ghis
> 

I am checking the package by repo.

Please update debian/copyright file.

Bug#868778: monit: Invalid CSRF check when using monit web page

[mart...@tildeslash.com]

> On 29 Aug 2017, at 21:10, Sergey B Kirpichev  wrote:
> 
> On Tue, Aug 29, 2017 at 08:58:44PM +0200, mart...@tildeslash.com wrote:
>> According to the output, the installed Monit version is 5.20.0 (first 
>> version with CSRF protection). The CSRF cookie in 5.20.0 was position 
>> dependent 
>> (https://bitbucket.org/tildeslash/monit/issues/495/invalid-csrf-check). The 
>> problem was fixed in Monit 5.21.0.
> 
> Correct me, if I'm wrong.  Workarround is (no-upgrade-solution): using
> a dedicated TLD for monit?

Yes, dedicated FQDN for monit that will filtering out other cookies might solve 
the problem (provided no other cookie will be injected, for example by proxy).

Bug#855259: nodejs: FTBFS on alpha architecture

[Aaron M. Ucko]

Source: nodejs
Version: 6.11.2~dfsg-3
Followup-For: Bug #855259

FTR, I'm seeing inappropriate use of the flags -m32, -msse2,
-mfpmath=sse, and -mmmx by the embedded copy of libv8 on alpha, hppa,
and sparc64.  None of these are release architectures, and if
supporting them is infeasible, so be it.  However, in that case, I
would encourage you to restrict nodejs's Architecture field so that
these architectures' autobuilders don't bother trying to build nodejs
or even install its build dependencies.

For that matter, per Policy 4.13, you really ought to use a separately
packaged build of libv8 if at all possible.  However, I see that the
latest packaged version is pretty old -- 3.14.5.8 vs. nodejs's
embedded 5.1.281.

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#868778: monit: Invalid CSRF check when using monit web page

[Sergey B Kirpichev]

On Tue, Aug 29, 2017 at 08:58:44PM +0200, mart...@tildeslash.com wrote:
> According to the output, the installed Monit version is 5.20.0 (first version 
> with CSRF protection). The CSRF cookie in 5.20.0 was position dependent 
> (https://bitbucket.org/tildeslash/monit/issues/495/invalid-csrf-check). The 
> problem was fixed in Monit 5.21.0.

Correct me, if I'm wrong.  Workarround is (no-upgrade-solution): using
a dedicated TLD for monit?

Bug#873652: nodejs: FTBFS on non-Linux: 'NativeHandle' does not name a type

[Aaron M. Ucko]

Source: nodejs
Version: 6.11.2~dfsg-3
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

Builds of nodejs for kFreeBSD and the Hurd (admittedly not release
architectures) have been failing:

  ../deps/v8/src/base/platform/mutex.h:62:3: error: 'NativeHandle' does not 
name a type
 NativeHandle& native_handle() {

Could you please take a look and ensure that the build system
recognizes both OSes as POSIX-compliant?

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#774172: rar: symlink directory traversal

[Salvatore Bonaccorso]

This should be fixed in 5.21 upstream:

+   Version 5.21
+
+   1. While previous versions could produce RAR5 volumes of slightly
+  smaller than requested size sometimes, such situation is less
+  likely now. In most cases volume size equals to specified by user.
+
+   2. Now by default RAR skips symbolic links with absolute paths
+  in link target when extracting. You can enable creating such links
+  with -ola switch.
+
+  Such links pointing to directories outside of extraction destination
+  directory can present a security risk. Enable their extraction only
+  if you are sure that archive contents is safe, such as your own backup.

the first version in unstable containging the fix should be 2:5.3.b2-1.

Regards,
Salvatore

Bug#873653: O: flask-silk -- FamFamFam Silk icon set for Flask applications (Python 2)

[Sebastian Ramacher]

Package: wnpp
Severity: normal

I intend to orphan the flask-silk package. I no longer have any interest in it.

The package description is:
 Flask-Silk is a Flask extension that provides the icons from the FamFamFam
 Silk icon set for Flask applications, blueprints and other extensions. It also
 allows one to serve custom icons replacing or extending those from the
 FamFamFam Silk icon set.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#873650: obnam: backup raises UnicodeDecodeError

[Max Hofer]

Package: obnam
Version: 1.22-1
Severity: important

Dear Maintainer,

after updating to the newest version of python-cliapp which should have fixed 
#873298
the 'backup' command spamms the console output with following messages:

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 41: 
ordinal not in range(128)
Logged from file backup_plugin.py, line 397
Traceback (most recent call last):
  File "/usr/lib/python2.7/logging/__init__.py", line 861, in emit
msg = self.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 734, in format
return fmt.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 476, in format
raise e

The backup continues until the end. Exit code was 0. The log files shows a
successful backup:

$ tail -11 /var/log/obnam.log
2017-08-29 20:50:00 INFO Backup performance statistics:
2017-08-29 20:50:00 INFO * files found: 26553
2017-08-29 20:50:00 INFO * files backed up: 482
2017-08-29 20:50:00 INFO * uploaded chunk data: 116075735 bytes (110 MiB)
2017-08-29 20:50:00 INFO * total uploaded data (incl. metadata): 116075735 
bytes (110 MiB)
2017-08-29 20:50:00 INFO * total downloaded data (incl. metadata): 36032115 
bytes (34 MiB)
2017-08-29 20:50:00 INFO * transfer overhead: 36032115 bytes (34 MiB)
2017-08-29 20:50:00 INFO * duration: 35.5528030396 s (36s)
2017-08-29 20:50:00 INFO * average speed: 3.1136348688 MiB/s
2017-08-29 20:50:00 INFO Backup finished.
2017-08-29 20:50:00 INFO obnam version 1.22 ends normally

I classified the bug as Iportant since I#m not sure if I should trust the log
file and exit code 0.


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

Kernel: Linux 4.9.13-min (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.utf8), LANGUAGE=en_US.utf8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages obnam depends on:
ii  gnupg 2.1.23-2
ii  libc6 2.24-17
ii  python2.7.13-2
ii  python-cliapp 1.20170827-1
ii  python-fuse   2:0.2.1-14
ii  python-larch  1.20151025-1
ii  python-paramiko   2.0.0-1
ii  python-tracing0.9-1
ii  python-ttystatus  0.34-1
ii  python-yaml   3.12-1+b1

obnam recommends no packages.

obnam suggests no packages.

-- no debconf information

Bug#873651: O: flask-openid -- OpenID support for Flask applications

[Sebastian Ramacher]

Package: wnpp
Severity: normal

I intend to orphan the flask-openid package. I no longer have any interest in
it.

The package description is:
 Flask-OpenID is an extension to Flask to add OpenID based authentication. It
 supports OpenID 2.x and has basic support for the Simple Registration (SReg)
 and Attribute Exchange (AX) extensions.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#873649: O: flask-babel -- internationalization and localization support for Flask

[Sebastian Ramacher]

Package: wnpp
Severity: normal

I intend to orphan the flask-babel package. I no longer have any interest in it.

The package description is:
 Flask-Babel is an extension to Flask that adds internationalization and
 localization support. It has a friendly interface to gettext translations and
 supports date formatting with timezones.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature