Bug#1053542: src/javax/annoation/* license

[Taylor Smock]

It looks like the only annotations we use are @Nonnull and @Nullable. We 
/could/ just strip the concurrent annotations out while we figure out 
what to do (hopefully none of the plugins depend on the 
javax.annotation.concurrent package).



The original problem was that /all/ javax.annotation.* files were marked 
as CC-BY-2.5. Which confused me, since the license of the jar file we 
are using was Apache 2.0.


On 10/6/23 6:49 AM, Sebastiaan Couwenberg wrote:

On 10/6/23 14:33, Taylor Smock wrote:
@Thorsten Alteholz: Can you please explain /why/ you think those 
files have the CC-BY-2.5 license?


All the javax.annotation.concurrent sources are CC-BY-2.5, see:


https://sources.debian.org/src/josm/0.0.svn18822%2Bdfsg-1/src/javax/annotation/concurrent/GuardedBy.java/ 



https://sources.debian.org/src/josm/0.0.svn18822%2Bdfsg-1/src/javax/annotation/concurrent/Immutable.java/ 



https://sources.debian.org/src/josm/0.0.svn18822%2Bdfsg-1/src/javax/annotation/concurrent/NotThreadSafe.java/ 



https://sources.debian.org/src/josm/0.0.svn18822%2Bdfsg-1/src/javax/annotation/concurrent/ThreadSafe.java/ 



These all have:

 /*
  * Copyright (c) 2005 Brian Goetz
  * Released under the Creative Commons Attribution License
  *   (http://creativecommons.org/licenses/by/2.5)
  * Official home: http://www.jcip.net
  */

Kind Regards,

Bas

Bug#1053542: src/javax/annoation/* license

[Taylor Smock]

@Thorsten Alteholz: Can you please explain /why/ you think those files 
have the CC-BY-2.5 license?


We are currently using the JSR305 annotations ( 
https://mvnrepository.com/artifact/com.google.code.findbugs/jsr305 ) 
which has an Apache 2.0 license. What it /looks/ like to me is that 
someone decided that everything in the javax/annotation directory had a 
CC-BY-2.5 license. I wasn't able to find any information on that via a 
quick search, but maybe you have more context on that.



Thanks,

Taylor

Bug#1052201: fftw3: baseline violation: Unconditionally enabled NEON for armhf

[Julian Taylor]

On 19.09.23 02:17, Boyuan Yang wrote:



According to https://wiki.debian.org/ArchitectureSpecificsMemo#armhf , NEON 
instructions
are not guaranteed on armhf platform. However, your debian/rules explicitly 
enabled NEON
support in armhf build. This should be a violation to architecture baseline.

Please consider fixing this issue. Ubuntu is providing an example patch for it, 
and it
can be used as a reference (patch attached).



fftw3 uses runtime feature detection, neon instructions are only used 
when the hardware supports it.

Bug#1036972: abiword: can't find type1 fonts from package xfonts-scalable

[Taylor Alexander Brown]

Package: abiword
Version: 3.0.4~dfsg-3
Severity: normal
X-Debbugs-Cc: py4...@teom.net

Dear Maintainer,

   * What led up to the situation?

 Because of the arbitrary removal of Type 1 font support in LibreOffice 5.3+
 I have been looking for an alternative word processor which retains 
support.

 Examples of Type 1 fonts I would like to continue using include Bitstream
 Charter and Courier 10 Pitch from package xfonts-scalable.

 AbiWord 3.0.2 on Debian 9 (stretch) supported these fonts, but they are
 missing in AbiWord 3.0.4 on Debian 11 (bullseye).

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

 I installed the package abiword expecting to find the above-mentioned 
fonts,
 however they are missing from the font selection menu.

 Steps I tried which were not effective include:
 - Reinstalling the package xfonts-scalable,
 - Manually refreshing the font cache both as user and as root,
 - Creating symbolic links to the relevant .pfb files in 
~/.local/share/fonts

 I was able to verify that the aforementioned fonts show up in fc-list and
 xfontsel and continue to appear in other applications such as GIMP which
 support Type 1 fonts.

   * What was the outcome of this action?

 None of these actions made the fonts available in AbiWord.

   * What outcome did you expect instead?

 I had hoped that one of these actions would make the fonts available in
 AbiWord.


Much Appreciated,

Taylor Alexander Brown


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

Kernel: Linux 5.10.0-23-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages abiword depends on:
ii  abiword-common  3.0.4~dfsg-3
ii  gsfonts 1:8.11+urwcyr1.0.7~pre44-4.5
ii  libabiword-3.0  3.0.4~dfsg-3
ii  libc6   2.31-13+deb11u6
ii  libdbus-1-3 1.12.24-0+deb11u1
ii  libdbus-glib-1-20.110-6
ii  libgcc-s1   10.2.1-6
ii  libgcrypt20 1.8.7-6
ii  libglib2.0-02.66.8-1
ii  libgnutls30 3.7.1-5+deb11u3
ii  libgoffice-0.10-10  0.10.48-1
ii  libgsf-1-1141.14.47-1
ii  libgtk-3-0  3.24.24-4+deb11u3
ii  libjpeg62-turbo 1:2.0.6-4
ii  libloudmouth1-0 1.5.3-6
ii  libots0 0.5.0-6
ii  libpng16-16 1.6.37-3
ii  librdf0 1.0.17-1.1+b1
ii  libreadline88.1-1
ii  librevenge-0.0-00.0.4-6+b1
ii  libsoup2.4-12.72.0-2
ii  libstdc++6  10.2.1-6
ii  libtelepathy-glib0  0.24.1-3
ii  libtidy5deb12:5.6.0-11
ii  libwmf0.2-7 0.2.8.4-17
ii  libwpd-0.10-10  0.10.3-1
ii  libwpg-0.3-30.3.3-1
ii  libxml2 2.9.10+dfsg-6.7+deb11u4
ii  zlib1g  1:1.2.11.dfsg-2+deb11u2

Versions of packages abiword recommends:
ii  abiword-plugin-grammar 3.0.4~dfsg-3
ii  aspell-en [aspell-dictionary]  2018.04.16-0-1
ii  fonts-liberation   1:1.07.4-11
ii  poppler-utils  20.09.0-3.1+deb11u1

abiword suggests no packages.

-- no debconf information

Bug#1025729: evolution-data-server: Gmail OAuth2: "Access blocked: GNOME Evolution’s request is invalid"

[James Taylor]

Package: evolution-data-server
Version: 3.30.5-1+deb10u2
Severity: important

Dear Maintainer,

Google deprecated a type of OAuth flow in Feb 28, 2022. This was fixed and 
addressed upstream
shortly after at 
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/388 and
the fix was included in version 3.44.2. However, Google has recently begun 
blocking
the old format. My Oauth2 token expired December 7th, 2022 so I can no longer 
access
my gmail account from evolution. A suitably recent version is available in 
Testing.

But the software is now partially unusable for the stable releases. I hope this 
is the
right channel for this. I wanted to note this upstream bug down here so you are 
aware
of the need to include the fixes in stable and oldstable.

Reproducing: Attempt to log in to a gmail account using OAuth2


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

Kernel: Linux 4.19.0-22-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages evolution-data-server depends on:
ii  evolution-data-server-common  3.30.5-1+deb10u2
ii  gnome-keyring 3.28.2-5
ii  libc6 2.28-10+deb10u2
ii  libcamel-1.2-62   3.30.5-1+deb10u2
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libdb5.3  5.3.28+dfsg1-0.5
ii  libebackend-1.2-103.30.5-1+deb10u2
ii  libebook-1.2-19   3.30.5-1+deb10u2
ii  libebook-contacts-1.2-2   3.30.5-1+deb10u2
ii  libecal-1.2-193.30.5-1+deb10u2
ii  libedata-book-1.2-25  3.30.5-1+deb10u2
ii  libedata-cal-1.2-29   3.30.5-1+deb10u2
ii  libedataserver-1.2-23 3.30.5-1+deb10u2
ii  libedataserverui-1.2-23.30.5-1+deb10u2
ii  libgcr-base-3-1   3.28.1-1
ii  libgcr-ui-3-1 3.28.1-1
ii  libgdata220.17.9-3
ii  libglib2.0-0  2.58.3-2+deb10u4
ii  libgoa-1.0-0b 3.30.1-2
ii  libgtk-3-03.24.5-1
ii  libgweather-3-15  3.28.2-2
ii  libical3  3.0.4-3
ii  libldap-2.4-2 2.4.47+dfsg-3+deb10u7
ii  libpango-1.0-01.42.4-8~deb10u1
ii  libsecret-1-0 0.18.7-1
ii  libsoup2.4-1  2.64.2-2
ii  libxml2   2.9.4+dfsg1-7+deb10u5

evolution-data-server recommends no packages.

Versions of packages evolution-data-server suggests:
ii  evolution  3.30.5-1.1

-- no debconf information

Bug#1010356: closed by David Kalnischkies (Re: Bug#1010356: apt: PATH messed up by apt eg starting with /usr/local/sbin in PATH)

[Nick Taylor]

Hi

Many thanks and apologies - several googles didn't find this answer!!!

Nick


On 29/04/2022 13:39, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the apt package:

#1010356: apt: PATH messed up by apt eg starting with /usr/local/sbin in PATH

It has been closed by David Kalnischkies .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact David Kalnischkies 
 by
replying to this email.

Bug#1010356: apt: PATH messed up by apt eg starting with /usr/local/sbin in PATH

[Nick Taylor]

Package: apt
Version: 2.2.4
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   My postinstall fails to find a called script in /usr/local/sbin

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 
Test using dpkg directly - note PATH shown in DEBUG line:

root@TSB-168:/home/am43# dpkg -i 
itrackbox-bluetooth-3.2.1-20220429.112606.7359946.deb 
(Reading database ... 32911 files and directories currently installed.)
Preparing to unpack itrackbox-bluetooth-3.2.1-20220429.112606.7359946.deb ...
/var/lib/dpkg/info/itrackbox-bluetooth.prerm DEBUG 
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Unpacking itrackbox-bluetooth (3.2.1-20220429.112606.7359946) over 
(3.2.1-20220429.112313.7c03e96) ...
Setting up itrackbox-bluetooth (3.2.1-20220429.112606.7359946) ...
/var/lib/dpkg/info/itrackbox-bluetooth.postinst DEBUG 
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

and same package via apt:

root@TSB-168:/home/am43# apt install --reinstall 
./itrackbox-bluetooth-3.2.1-20220429.112313.7c03e96.deb 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'itrackbox-bluetooth' instead of 
'./itrackbox-bluetooth-3.2.1-20220429.112313.7c03e96.deb'
The following packages will be DOWNGRADED:
  itrackbox-bluetooth
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Need to get 0 B/8308 B of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 /home/am43/itrackbox-bluetooth-3.2.1-20220429.112313.7c03e96.deb 
itrackbox-bluetooth armhf 3.2.1-20220429.112313.7c03e96 [8308 B]
dpkg: warning: downgrading itrackbox-bluetooth from 
3.2.1-20220429.112606.7359946 to 3.2.1-20220429.112313.7c03e96
(Reading database ... 32911 files and directories currently installed.)
Preparing to unpack .../itrackbox-bluetooth-3.2.1-20220429.112313.7c03e96.deb 
...
/var/lib/dpkg/info/itrackbox-bluetooth.prerm DEBUG /usr/sbin:/usr/bin:/sbin:/bin
Unpacking itrackbox-bluetooth (3.2.1-20220429.112313.7c03e96) over 
(3.2.1-20220429.112606.7359946) ...
Setting up itrackbox-bluetooth (3.2.1-20220429.112313.7c03e96) ...
/var/lib/dpkg/info/itrackbox-bluetooth.postinst DEBUG 
/usr/sbin:/usr/bin:/sbin:/bin
root@TSB-168:/home/am43#

   * What was the outcome of this action?

   My postinst script fails unless I call scripts using full path

   * What outcome did you expect instead?

   PATH should not be messed with


-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/itrack.list present, but not submitted) --


-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.4.106-itb3.03 (PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2021.1.1
ii  gpgv2.2.27-2+deb11u1
ii  libapt-pkg6.0   2.2.4
ii  libc6   2.31-13+deb11u3
ii  libgcc-s1   10.2.1-6
ii  libgnutls30 3.7.1-5
ii  libseccomp2 2.5.1-1+deb11u1
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-7

Versions of packages apt recommends:
ii  ca-certificates  20210119

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.20.9
ii  gnupg2.2.27-2+deb11u1
pn  powermgmt-base   

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_GB.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#1001449: array indexing broken

[Julian Taylor]

Package: bpftrace
Version: 0.11.3-5
Tags: patch fixed-upstream

array indexing in bpftrace in debian stable is broken it always indexes 
with 0:

Example:

#!/usr/bin/env bpftrace
#include 
#include 
kprobe:tcp_connect
{
  $sk = ((struct sock *) arg0);
  if ($sk->__sk_common.skc_family == AF_INET6) {
  $d0 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[0];
  $d1 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[1];
  $d2 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[2];
  $d3 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[3];
  printf("%X %X %X %X\n", $d0, $d1, $d2, $d3);
  }
}

$ bpftrace tcpconnect.bt
$ curl -v http://[:::127.0.0.1]

output:
Attaching 1 probe...
0 0 0 0


expected:
0 0  17F


This has been fixed upstream with this patch:
https://github.com/iovisor/bpftrace/pull/1457

Bug#990220: wrong code generation for bpftrace

[Julian Taylor]

Package: llvm-toolchain-11
Version: 1:11.0.1-2
Tags: patch

bpftrace in debian testing suffers from a code generation bug in llvm11:

https://github.com/iovisor/bpftrace/issues/1305  


To reproduce run:
apt-get install bpftrace
/usr/sbin/tcpconnect.bt

connect to a https site.
the DPORT column will contain wrong values (13429)

This was fixed in llvm12, see
https://reviews.llvm.org/D88525
https://bugs.llvm.org/show_bug.cgi?id=47591

A patch is available here: https://reviews.llvm.org/D91833

Bug#968599: ca-certificates: update-ca-certificates breaks on custom certs in folder starting with 1 or 2

[Julian Taylor]

Package: ca-certificates
Version: 20200601
Severity: normal

Dear Maintainer,

when installing certificates into /usr/share/ca-certificates with a
folder starting with a 1 the postinst
script mangles and disables the custom certificates.

The problem is this sed in the postinst

  (echo $CERTS_ENABLED | tr ',' '\n'; \
   echo $CERTS_AVAILABLE | tr ',' '\n') | \
    sed -e 's/^[[:space:]]*//' | \
    sort | uniq -c | \
    sed -e 's/^[[:space:]]*2[[:space:]]*//' \
    -e 's/^[[:space:]]*1[[:space:]]*/!/' \
    >> /etc/ca-certificates.conf

-e 's/^[[:space:]]*1[[:space:]]*/!/' matches the 1and1 folder and thus
converts it to
!and1/cert.crt e.g.:

$ echo -e "1and1/ca.crt\n1and1/ca.crt" | uniq -c | sed -e
's/^[[:space:]]*//' | sed -e 's/^[[:space:]]*2[[:space:]]*//' -e
's/^[[:space:]]*1[[:space:]]*/!/'
!and1/ca.crt

Probably the sed should use -e 's/^[[:space:]]*1[[:space:]]\+/!/' or
even better use better ways to create the difference e.g.
https://stackoverflow.com/a/13038235

-- System Information:
Debian Release: bullseye/sid

-- 
Julian Taylor

System Administrator
Automation Services

1&1 Mail & Media Development & Technology GmbH | Brauerstraße 48 | 76135 
Karlsruhe | Germany
Phone: +49 721 91374 6334
E-Mail: julian.tay...@1und1.de | Web: www.1und1.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452

Geschäftsführer: Alexander Charles, Thomas Ludwig, Jan Oetjen, Sascha Vollmer


Member of United Internet

Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen 
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten 
Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, 
diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise 
auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient of this e-mail, you are hereby notified that saving, 
distribution or use of the content of this e-mail in any way is prohibited. If 
you have received this e-mail in error, please notify the sender and delete the 
e-mail.

Bug#885212: libmatheval: please migrate to guile-2.2

[Julian Taylor]

On 28.04.20 01:14, Rob Browning wrote:
> 
> I think we probaly either need to address this soon, or consider
> removing libmatheval from Debian.
> 
> Sometimes it's sufficient to just update the build dependency from say
> guile-2.0-dev to guile-3.0-dev and adjust some of the related versions
> in configure.ac (or configure.in), but in this case it looks like more
> might be required.
> 
> When I make those adjutments to 3.0 with the current package I see some
> SCM related type errors which I suspect are problems with the
> types/prototypes in the library, i.e. int is (and was) not
> (transparently) interchangable with SCM.
> 
> I may investigate further myself if I have time, but please don't rely
> on that.
> 
> Thanks
> 

I had checked it briefly a while ago and it is not a simple build
dependency update. There were to many api changes that need to be
adapted and at the time I didn't find a good migration guide.
Unfortunately upstream also seems to be dead. I can try to have another
look this weekend, but I may likely not find the time to port it myself
in which case I would favor removal assuming dependencies can be
migrated to something else.

Bug#693587: bind9: stop resolving

[Jimmy Taylor]

I was seeing this same issue on Ubuntu 18.04.4 running BIND 9.11.3.

DNSSEC enabled, and after restarting the system BIND wouldn't resolve addresses 
until I restarted the daemon. I verified DNSSEC-Validation was set to auto and 
that time was sync'd properly.

The issue was resolved, for me, by adding the ISC repository and updating to 
9.14.10.
https://launchpad.net/~isc/+archive/ubuntu/bind

Just thought I would provide some feedback, as this lead me to a solution, 
albeit on a downstream distribution.

​On Thu, 16 Jan 2020 17:49:39  0100 Marco d'Itri  wrote:
> On Jan 16, Bernhard Schmidt  wrote:
>
> > Since we finally have 9.15 in experimental, could you please try this
> > and give feedback?
> Testing.
>
> BTW, you need to clean up after /usr/share/bind9/:
>
> root@bongo:~


---

Jimmy Taylor
Network Systems Engineer
MCSE, CCNA, JNCIA

Bug#951152: new archmage version breaks keepass2 documentation build

[Julian Taylor]

On 11.02.20 22:13, Mikhail Gusarov wrote:
> Hi Julian,
> 
> On 11 Feb 2020, at 21:25, Julian Taylor wrote:
> 
>> For keepass I only need to be able to build html files from the chm
>> source directory, the package has no compiled chm file one can use the
>> current cli functions on.
> 
> Please try
> https://github.com/dottedmag/archmage/commit/c8f186dff0c8da56590e900cc2a32b39e19bf08b
> 
> 
> - if it works, then I'll cut a new release and a package.
> 

it is working great, thanks



signature.asc
Description: OpenPGP digital signature

Bug#951152: new archmage version breaks keepass2 documentation build

[Julian Taylor]

On 11.02.20 21:20, Mikhail Gusarov wrote:
> Hello Julian,
> 
> On 11 Feb 2020, at 20:23, Julian Taylor wrote:
> 
>> The new archmage version breaks the documentation build of the keepass2
>> package. This is due to the (maybe accidental) removal of the availity
>> to render html files from chm sources.
> 
> Fun. While reworking pychm I had a careful look of all dependencies to see
> what subsets of API do they use, but it never occurred to me that there
> might be programs out there that use (never guaranteed to be stable) innards
> of Archmage.
> 
> Keepass packaging definitely needs to stop doing this. What's missing from
> Archmage CLI if I reimplement HTML generation from unpacked CHM files tree?
> 

I'll gladly remove the usage of the module functions when the cli
provides this functionality. Currently (and in the past) it requires a
compiled chm to extract from.

For keepass I only need to be able to build html files from the chm
source directory, the package has no compiled chm file one can use the
current cli functions on.

Bug#951152: new archmage version breaks keepass2 documentation build

[Julian Taylor]

Package: archmage
Version:  1:0.4.1-2
Severity: important
Tags: patch

The new archmage version breaks the documentation build of the keepass2
package.
This is due to the (maybe accidental) removal of the availity to render
html files from chm sources.

I have filed patch upstream to restore that ability:
https://github.com/dottedmag/archmage/pull/17

As it is required to update keepass2 and remove its python2 dependency,
could it be considered to add it to the package if upstream does not
react soon?

From 7591fd2427ebef2585347c7c567aa038a1fcab66 Mon Sep 17 00:00:00 2001
From: Julian Taylor 
Date: Sun, 9 Feb 2020 19:31:45 +0100
Subject: [PATCH] restore ability to render html from chm templates

add back the ability to export htlm files from chm templates via:

python3 -c 'import archmage.CHM; archmage.CHM.CHMFile("chmdir").process_templates("output")'

Closes gh-16
---
 archmage/CHM.py | 45 -
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/archmage/CHM.py b/archmage/CHM.py
index 93b0591..fbd37c4 100644
--- a/archmage/CHM.py
+++ b/archmage/CHM.py
@@ -82,16 +82,24 @@ class CHMFile:
 return self.cache['entries']
 
 def _entries(self):
-def get_name(chmfile, ui, out):
-path = ui.path.decode('utf-8')
-if path != '/':
-out.append(path)
-return chmlib.CHM_ENUMERATOR_CONTINUE
+if self._chm is None:
+entries = []
+for root, dirs, files in os.walk(self.sourcename):
+for f in files:
+fn = '/'.join((root.lstrip(self.sourcename), f))
+entries.append(fn)
+return entries
+else:
+def get_name(chmfile, ui, out):
+path = ui.path.decode('utf-8')
+if path != '/':
+out.append(path)
+return chmlib.CHM_ENUMERATOR_CONTINUE
 
-out = []
-if chmlib.chm_enumerate(self._chm, chmlib.CHM_ENUMERATE_ALL, get_name, out) == 0:
-sys.exit('UnknownError: CHMLIB or PyCHM bug?')
-return out
+out = []
+if chmlib.chm_enumerate(self._chm, chmlib.CHM_ENUMERATE_ALL, get_name, out) == 0:
+sys.exit('UnknownError: CHMLIB or PyCHM bug?')
+return out
 
 # retrieves the list of HTML files contained into the CHM file, **in order**
 # (that's the important bit).
@@ -327,14 +335,17 @@ class CHMEntry(object):
 
 def read(self):
 """Read CHM entry content"""
-result, ui = chmlib.chm_resolve_object(self.parent._chm, self.name.encode('utf-8'))
-if result != chmlib.CHM_RESOLVE_SUCCESS:
-return None
-
-size, content = chmlib.chm_retrieve_object(self.parent._chm, ui, 0, ui.length)
-if size == 0:
-return None
-return content
+if self.parent._chm:
+result, ui = chmlib.chm_resolve_object(self.parent._chm, self.name.encode('utf-8'))
+if result != chmlib.CHM_RESOLVE_SUCCESS:
+return None
+
+size, content = chmlib.chm_retrieve_object(self.parent._chm, ui, 0, ui.length)
+if size == 0:
+return None
+return content
+else:
+return open(self.parent.sourcename + self.name).read()
 
 def lower_links(self, text):
 """Links to lower case"""
-- 
2.20.1




signature.asc
Description: OpenPGP digital signature

Bug#943144: keepass2: Python2 removal in sid/bullseye

[Julian Taylor]

On 23.10.19 04:33, mo...@debian.org wrote:
> Source: keepass2
> Version: 2.43+dfsg-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html


The python2 dependency cannot be removed right now as the documentation
build with the python3 compatible archmage tool does not support
building html sources from chm sources anymore.

But I have filed a patch upstream to restore the functionality.
https://github.com/dottedmag/archmage/pull/17

I'll wait a bit for an upstream answer before proceeding further.

Bug#949536: New upstream version 2.44 - please package

[Julian Taylor]

On 21.01.20 20:24, Marc Meledandri wrote:
> Package: keepass2
> Version: 2.43+dfsg-1
> 
> Dear Maintainer,
> 
> Please package KeePass 2.44. List of fixes and improvements:
> https://keepass.info/news/n200120_2.44.html
> 
> Thanks!
> 

It appears the new python3 compatible archmage tool does not allow
creating html files from chm source files anymore [0].

So the documentation cannot be built anymore. I'll wait a bit for an
upstream reply and if this does not work probably remove the
documentation from keepass until a fix is available.

[0] https://github.com/dottedmag/archmage/issues/16

Bug#842541: Why keepass2 opens TCP ports

[Julian Taylor]

On 27.01.20 07:30, Felix Dörre wrote:
> Hi,
> 
> I found out, why keepass2 opens TCP ports. However on my system, keepass
> opens two TCP ports:
> 
> The older one (that is already reported in this bug report) comes from
> strange behavior in mono itself. I opened a pull request against mono to
> fix it: https://github.com/mono/mono/pull/18583
> 
> The newer one that presumable got added in the meantime is an IPC
> implementation that does things like keeping keepass single-instance and
> sending other events to a currently running instance (e.g. triggering
> auto-typing). I consider this feature a security risk and would rather
> not have it in my password manager. I've added a pull request to the
> debian repository to deactivate this feature:
> https://salsa.debian.org/dotnet-team/keepass2/merge_requests/1
> 
> With these two changes, keepass2 seems tame now and does not open TCP
> ports anymore on my system.
> 


I agree a tcp port for this rather simple usecase is overkill, it could
be replaced with a unix domain socket/fifo in $XDG_RUNTIME_DIR or some
other ipc method.

I would prefer to not hard disable it by commenting the code, but rather
either make it configurable or replace it with a unix domain socket/fifo.

I am sure upstream would also accept such a patch.

Bug#942359: Please provide libfftw3-long3 on all platforms

[Julian Taylor]

On 15.10.19 08:47, Ole Streicher wrote:
> Package:libfftw3-long3
> Version: 3.3.8-2
> Severity: wishlist
> 
> Hi,
> 
> I have a package (cubature) that generates an include file (clencurt.h)
> with a small helper program during build. This helper program uses the
> "long double" version of libfftw (libfftw3-long3).
> 
> Unfortunately, libfftw3-long3 is only available on some architectures
> and is missing on armel, armhf, mipsel and some ports. It seems that
> these are the architectures where sizeof(long double) == sizeof(long),
> which make the a separate "long double" version redundant.
> 
> However, the missing "long double" version breaks programs that use the
> "long" version of the API. I could in principle rewrite the helper
> program to support both; however this requires a lot of renaming and is
> not really suitable for a Debian patch.
> 
> Therefore, I would ask to provide a "long double" version on all
> machines which support the "long double" C data type.
> 

This would require disabling the testsuite on these architectures as
with no real long doubles they will likely fail (which I think is the
original reason the package is not built, but I'd have to look it up).

Imo it is also dangerous to provide a long double numerical library on
platforms that do not really support it. You likely will just get wrong
results.

I think it would be better to just not build cubature on these platforms
depending on how significant the long double support is.
Have you engaged with upstream to check if they want to make long double
support optional?



signature.asc
Description: OpenPGP digital signature

Bug#896008: Improve performance of dynamic loader Patch

[Taylor, Eric - Eric]

I've attached a patch that will resolve this issues.


NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.


link-sort.diff
Description: link-sort.diff

Bug#925910: mate-desktop: 'Dead zone' on large screen with multi-screen display

[Jasper Taylor]

Package: mate-desktop
Version: 1.20.4-2
Severity: important
Tags: upstream

Dear Maintainer,
Expected behaviour:

To be able to place a window anywhere on either screen

Actual behaviour:

Trying to drag a window to the centre of the larger screen reveals that there
is a 'no-go area' and if you drag right across it, the window snaps to the
other side when exiting this area.

Steps to reproduce the behaviour:

  * Connect two screens to your PC, one wider (in pixels) than the other.
  * Open mate-display-properties. Set the narrower screen as primary, and
position it above or below the wider screen, so the centres of the two screens
are vertically aligned.
  * Apply and click to keep the new arrangement.
  * Now drag the mate-display-properties window (or any small window) across
the larger screen. It cannot be placed in the centre but will snap from one
side to the other.
  * If the left or right sides of the two screens are vertically aligned, the
problem does not occur.

I thought this might be a LightDM problem but it does not occur in Cinnamon or
Xfce desktop so I figure it must be mate-desktop.

Also reported as https://github.com/mate-desktop/mate-desktop/issues/359



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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mate-desktop depends on:
ii  hicolor-icon-theme0.17-2
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-8
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-1
ii  libgtk-3-03.24.5-1
ii  libmate-desktop-2-17  1.20.4-2
ii  libpango-1.0-01.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libstartup-notification0  0.12-6
ii  libxrandr22:1.5.1-1
ii  mate-desktop-common   1.20.4-2

Versions of packages mate-desktop recommends:
ii  mate-user-guide  1.20.2-1

Versions of packages mate-desktop suggests:
ii  mate-desktop-environment  1.20.0+5

-- no debconf information

Bug#826187: Fwd: xfce4 second monitor does not wake up after suspend, with kernel 4.5.0-1 or 4.5.0-2

[Jasper Taylor]

Package: xfce4
Version: 4.12.5
Followup-For: Bug #826187

Dear Maintainer,

If I suspend the session using the 'log out' dialogue, or if it suspends due to
a period of inactivity, then it restarts properly with both screens. But I have
a power management setting to suspend the session on closing the laptop lid. If
I do this, then reopen the lid and hit the power button to resume the session,
I get the exact bug described by the OP -- the external monitor starts up but
the built-in screen of the laptop does not. In my layout the external monitor
is above the built-in screen, and if the pointer is moved to the bottom, it
shows at the top of the laptop screen but nothing else is displayed there. The
pointer cannot be moved further down.

The taskbar widget showing the workspaces still behaves as if the laptop screen
were part of the desktop area. If the display settings dialogue is open on the
external monitor when the machine suspends, or if it can be opened after
resuming, the laptop screen starts working normally again. However, it may open
on the non-working laptop screen (as shown by the workspace thumbnail) in which
case the only way to restart the screen is to log out.



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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4 depends on:
ii  gtk2-engines-xfce3.2.0-4
ii  libxfce4ui-utils 4.12.1-3
ii  thunar   1.8.4-1
ii  xfce4-appfinder  4.12.0-2
ii  xfce4-panel  4.12.2-1
ii  xfce4-pulseaudio-plugin  0.4.1-1
ii  xfce4-session4.12.1-6
ii  xfce4-settings   4.12.4-1
ii  xfconf   4.12.1-1
ii  xfdesktop4   4.12.4-2
ii  xfwm44.12.5-1

Versions of packages xfce4 recommends:
ii  desktop-base  10.0.0
ii  tango-icon-theme  0.8.90-7
ii  thunar-volman 0.9.1-1
ii  xfce4-notifyd 0.4.3-1
ii  xorg  1:7.7+19

Versions of packages xfce4 suggests:
pn  gtk3-engines-xfce
ii  xfce4-goodies4.12.6
ii  xfce4-power-manager  1.6.1-1

-- no debconf information

Bug#922049: libpam-poldi: ed25519 support patch

[Eric Taylor]

Dear Maintainer,

I've wrote and tested the attached patches. They seem seem to resolve this
issue. They also add infrastructure to make it easier to add support for
different signing algorithms.
diff --git a/src/util/simplelog.c b/src/util/simplelog.c
index 07191d9..5bed40d 100644
--- a/src/util/simplelog.c
+++ b/src/util/simplelog.c
@@ -228,7 +228,7 @@ static gpg_error_t
 internal_log_write (log_handle_t handle, log_level_t level,
 		const char *fmt, va_list ap)
 {
-  gpg_error_t err;
+  gpg_error_t err = 0;
 
   assert (handle->backend != LOG_BACKEND_NONE);
 
@@ -270,7 +270,6 @@ internal_log_write (log_handle_t handle, log_level_t level,
 	}
 	  
   vsyslog (LOG_MAKEPRI (LOG_AUTH, syslog_priority), fmt, ap);
-  err = 0;
 }
   else if (handle->backend == LOG_BACKEND_STREAM
 	   || handle->backend == LOG_BACKEND_FILE)
@@ -314,7 +313,6 @@ internal_log_write (log_handle_t handle, log_level_t level,
   vfprintf (stream, fmt, ap);
   putc ('\n', stream);
 
-  err = 0;
 }
 
   return err;
diff --git a/src/pam/auth-method-localdb/Makefile.am b/src/pam/auth-method-localdb/Makefile.am
index c033f16..ac528b0 100644
--- a/src/pam/auth-method-localdb/Makefile.am
+++ b/src/pam/auth-method-localdb/Makefile.am
@@ -11,7 +11,7 @@
 # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
 # or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
 # License for more details.
-# 
+#
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, write to the Free Software
 # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
diff --git a/src/pam/auth-method-localdb/auth-localdb.c b/src/pam/auth-method-localdb/auth-localdb.c
index d73808d..f9041f7 100644
--- a/src/pam/auth-method-localdb/auth-localdb.c
+++ b/src/pam/auth-method-localdb/auth-localdb.c
@@ -1,18 +1,18 @@
 /* auth-localdb.c - localdb authentication method for Poldi.
Copyright (C) 2004, 2005, 2007, 2008, 2009 g10 Code GmbH
- 
+
This file is part of Poldi.
- 
+
Poldi is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
- 
+
Poldi is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.
- 
+
You should have received a copy of the GNU General Public License
along with this program; if not, see
.  */
@@ -33,15 +33,17 @@
 
 #include "scd/scd.h"
 #include "util/support.h"
+#include "util/key-types.h"
+#include "util/debugTools.h"
 #include "auth-support/ctx.h"
 #include "auth-support/wait-for-card.h"
 
 #include "usersdb.h"
 #include "key-lookup.h"
 
-
 
 #if 0
+
 /* Currently, the localdb method doesn't require a special cookie. */
 
 static gpg_error_t
@@ -79,6 +81,7 @@ auth_method_localdb_auth_do (poldi_ctx_t ctx,
   size_t challenge_n;
   size_t response_n;
   gcry_sexp_t key;
+  key_types key_type;
   gpg_error_t err;
   char *card_username;
   const char *username;
@@ -143,8 +146,24 @@ auth_method_localdb_auth_do (poldi_ctx_t ctx,
   if (err)
 goto out;
 
+  /* Retrieve key type */
+  err = get_key_type(_type, key);
+  if(err) {
+//unsupported crypto
+log_msg_error (ctx->loghandle,
+   "Unsupported Key Type\n");
+
+   goto out;
+ }
+  /*Print out key type if debug is enabled */
+  if (ctx->debug) {
+log_msg_debug (ctx->loghandle,
+   "Key Type "
+   "`%s'", key_type_to_str(key_type));
+  }
+
   /* Generate challenge.  */
-  err = challenge_generate (, _n);
+  err = challenge_generate (, _n, key_type);
   if (err)
 {
   log_msg_error (ctx->loghandle,
@@ -154,7 +173,7 @@ auth_method_localdb_auth_do (poldi_ctx_t ctx,
 }
 
   /* Let card sign the challenge.  */
-  err = scd_pksign (ctx->scd, "OPENPGP.3",
+  err = scd_pksign (ctx->scd, "OPENPGP.3", key_type,
 		challenge, challenge_n,
 		, _n);
   if (err)
@@ -165,8 +184,47 @@ auth_method_localdb_auth_do (poldi_ctx_t ctx,
   goto out;
 }
 
+  /*DEBUG LOG S Expressions */
+  if (ctx->debug) {
+char outBuff[4096];
+gcry_sexp_t sexp_signature = NULL;
+
+switch (key_type)
+{
+  case kType_rsa:
+  err = gcry_sexp_build (_signature, NULL, "(sig-val(rsa(s%b)))",
+   response_n,response);
+break;
+
+  case kType_ecc_Ed25519:
+  err = gcry_sexp_build (_signature, NULL, "(sig-val(eddsa(r%b)(s%b)))",
+ (int)response_n/2, response,
+ (int)response_n/2, response + response_n/2);
+break;
+
+  default:
+err = GPG_ERR_CONFIGURATION;
+}//switch
+//log public key
+//log_msg_debug(ctx->loghandle, "%s","Public_KEY");
+

Bug#923425: Correction to original bug info

[Nick Taylor]

The statement:

The links are located in the folder  /media/MyBook/Hostshare/GIFS

needs to be corrected to say

The links are located in the folder  /media/MyBook/Hostshare/GIFS/GIFLINKS

Thanks
Nick Taylor

Bug#923425: Chase gives incorrect file path

[Nick Taylor]

Package: chase
Version: 0.5.2


When the link is in a different folder than the target file, the
resultant path to the target file given by chase turns out to be incorrect.
Here is a transcript:

In this example, the files are located in the folder 
/media/MyBook/Hostshare/GIFS
The links are located in the folder  /media/MyBook/Hostshare/GIFS

cd /media/MyBook/Hostshare/GIFS/GIFLINKS
/media/MyBook/Hostshare/GIFS/GIFLINKS$ chase achtagDu6Blo
chase: /media/MyBook/Hostshare/GIFS/GIFLINKS/IJa7b9jy.gif: No such file or 
directory

The filename IJa7b9jy.gif does exist in the folder 
/media/MyBook/Hostshare/GIFS, but
not in  /media/MyBook/Hostshare/GIFS/GIFLINKS

I am using Debian GNU/Linux 9.7 (stretch) kernel 4.9.0-8-amd64 and (Debian 
GLIBC 2.24-11+deb9u3) 2.24




 

Bug#922055: sddm: SDDM is not conversing properly with pam and poldi

[Eric Taylor]

Package: sddm
Version: 0.18.0-1
Severity: normal

Dear Maintainer,

SDDM doesn't seem to fully support PAM conversations. When attempting to use 
the poldi pam module for OpenpPGP cards SDDM seems to deadlock when when poldi 
sends/request more information during the login process. I have gotten pam and 
poldi to  
successfully work with the gdm and slim desktop managers.
 
I found a bug for this on github: https://github.com/sddm/sddm/issues/693

and an open pull request that seems to fix this: 
https://github.com/sddm/sddm/pull/776

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages sddm depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.70
ii  libc6   2.28-6
ii  libgcc1 1:8.2.0-16
ii  libpam0g1.1.8-4
ii  libqt5core5a5.11.3+dfsg-2
ii  libqt5dbus5 5.11.3+dfsg-2
ii  libqt5gui5  5.11.3+dfsg-2
ii  libqt5network5  5.11.3+dfsg-2
ii  libqt5qml5  5.11.3-2
ii  libqt5quick55.11.3-2
ii  libstdc++6  8.2.0-16
ii  libsystemd0 240-5
ii  libxcb-xkb1 1.13.1-2
ii  libxcb1 1.13.1-2
ii  qml-module-qtquick2 5.11.3-2
ii  x11-common  1:7.7+19
ii  xserver-xorg [xserver]  1:7.7+19

Versions of packages sddm recommends:
ii  haveged  1.9.1-6
ii  libpam-systemd   240-5
ii  sddm-theme-debian-maui [sddm-theme]  0.18.0-1

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.14.5-1
pn  qtvirtualkeyboard-plugin  

-- debconf-show failed

Bug#922049: libpam-poldi: No Support for ed25519 keys

[Eric Taylor]

Package: libpam-poldi
Version: 0.4.2+git20161115.553060d-1
Severity: normal

Dear Maintainer,

There seems to be no ed25519 support. I receive an authentication 
failed: General error when attempting to use an ed25519 key. Using an RSA key 
works
correctly.  


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages libpam-poldi depends on:
ii  libc6  2.28-6
ii  libgcrypt201.8.4-5
ii  libgpg-error0  1.35-1
ii  libksba8   1.3.5-2
ii  scdaemon   2.2.12-1

Versions of packages libpam-poldi recommends:
ii  gnupg  2.2.12-1

libpam-poldi suggests no packages.

-- debconf-show failed

Bug#921678: sddm-theme-debian-maui: After a recent system update the file background-nologo.svg disappeared

[Eric Taylor]

Package: sddm-theme-debian-maui
Version: 0.18.0-1
Severity: minor

Dear Maintainer,

After a recent system update My SDDM screen lost its image and became all gray. 
I checked:
/usr/share/sddm/themes/debian-maui/theme.conf 

It listed the background file:
background=/usr/share/desktop-base/active-theme/login/background-nologo.svg

I followed this file path and found that the file no longer existed. The only 
files in the login folder are:
background-withlogo.svg
background.svg

I changed the line in the theme.conf to match:
background=/usr/share/desktop-base/active-theme/login/background.svg

and sddm started displaying an image again.

I believe the package that was recently moved from unstable into testing 
updated these file: desktop-base 10.0.0
 


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages sddm-theme-debian-maui depends on:
ii  desktop-base  10.0.0

Versions of packages sddm-theme-debian-maui recommends:
ii  sddm  0.18.0-1

sddm-theme-debian-maui suggests no packages.

-- debconf-show failed

-- debsums errors found:
debsums: changed file /usr/share/sddm/themes/debian-maui/theme.conf (from 
sddm-theme-debian-maui package)

Bug#919929: blis breaks python-scipy autopkgtest

[Julian Taylor]

On 29.01.19 12:01, Graham Inggs wrote:
> Hi Paul
> 
> On 2019/01/20 21:09, Paul Gevers wrote:
>> With a recent upload of blis the autopkgtest of python-scipy fails in
>> testing when that autopkgtest is run with the binary packages of blis
>> from unstable. It passes when run with only packages from testing. In
>> tabular form:
>>     pass    fail
>> blis   from testing    0.5.1-5
>> python-scipy   from testing    1.1.0-2
>> all others from testing    from testing
> 
> From testing's test logs [1], python-scipy 1.1.0-2 passed with
> blis/0.5.1-5 on 2019-01-21 05:22:48 UTC.  It then passed with
> blis/0.5.1-6 and blis/0.5.1-7, but failed with blis/0.5.1-7 on
> 2019-01-27 17:55:32 UTC.
> 
> From unstable's test logs [2], python-scipy 1.1.0-2 seems to have many
> intermittent failures since 2018-12-02.
> 
> I'm unsure what to do with this bug, perhaps re-assign to python-scipy
> only?

I am confused, scipy does not use blis.
It tests libblas, openblas and atlas but blis was so far I know never
configured as a blas source in the tests.
Unless something has changed with those packages that they pull blis
this might be a false positive.

If blis is ready enough to be used prime time, let me know we can add it
to numpy's and scipy's testsuites.

Bug#915738: rules workaround

[Julian Taylor]

this rules change should disable unrolling for fortran on s390x.
I'm currently checking if we can upload a new upstream without breaking
rdeps, if not I'll add this to 1.11.0

build-python%:
ifeq ($(DEB_HOST_ARCH),s390x)
# gcc bug 906198
NPY_DISTUTILS_APPEND_FLAGS=1 FOPT="-fno-unroll-loops" python$*
setup.py config_fc --noarch build;
NPY_DISTUTILS_APPEND_FLAGS=1 FOPT="-fno-unroll-loops"
python$*-dbg setup.py config_fc
else
python$* setup.py config_fc --noarch build;
python$*-dbg setup.py config_fc
endif



signature.asc
Description: OpenPGP digital signature

Bug#918812: lvm2: "Failed to parse thin params" from vgchange et al on boot into latest kernel

[Grant Taylor]

Package: lvm2
Version: 2.02.168-2
Severity: normal

Dear Maintainer,

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

Not sure about the severity; as luck would have it my system can boot,
but many volumes were rendered entirely unavailable so for some this
would be a showstopper.

This issue appears to be specific to the use of thin provisioned
logical volumes.  Non-thin volumes even in the same vg come up just
fine.

   * What led up to the situation?

Automated update to kernel 4.9.0-8-amd64.  The latest stable lvm2
package version 2.02.168-2 was on the system.

This combination does not work.  Apparently the thin params in
question originate out of the kernel's dm ioctl, yielding the error in
the headline from lvs, vgchange, etc.

Also, most of the tools segfault starting after I ran vgchange -ay
manually to try and activate the missing volumes.  Unclear why they
didn't segfault starting from the first run.

Non-thin volumes were activated properly at initramfs time.  So I was
able to poke around and ultimately fix things by updating lvm2.

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

I built the lvm2 packages from testing, installed those, and now it
works.  The only missing build-dep was debhelper, satisfied from
backports.  The system info below reflects my self-built testing
backport of lvm2, which is version 2.03.02-1.

Notably I did not install a newer thin-provisioning-tools, just the
packages from building lvm2.

BTW this lvm2-vs-kernel breakage issue, including debian having "old"
lvm2 tools, is the subject of one of Linus's patented gentle
discussions on lkml, wherein he is adament that 'NOBODY gets to say
"oh, you should just update user land tools"'.*  So it would be nice
for the deb lvm team to either mask this issue by somehow guaranteeing
compatibility of shipped versions and/or applying all due pressure
upstream to eliminate this sort of breakage.

* https://lore.kernel.org/lkml/1ec0a220-d5b0-1c27-e63b-c4d3f4ce9...@torlan.ru/T/



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

Kernel: Linux 4.9.0-8-amd64 (SMP w/12 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 lvm2 depends on:
ii  dmeventd  2:1.02.155-1
ii  dmsetup   2:1.02.155-1
ii  libaio1   0.3.110-3
ii  libblkid1 2.29.2-1+deb9u1
ii  libc6 2.24-11+deb9u3
ii  libdevmapper-event1.02.1  2:1.02.155-1
ii  libdevmapper1.02.12:1.02.155-1
ii  libreadline5  5.2+dfsg-3+b1
ii  libselinux1   2.6-3+b3
ii  libsystemd0   232-25+deb9u6
ii  libudev1  232-25+deb9u6
ii  lsb-base  9.20161125

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.6.1-4+b1

lvm2 suggests no packages.

-- debconf-show failed

Bug#916781: slack-desktop: Segmentation fault

[Eric Taylor]

Package: slack-desktop
Version: 3.3.3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   When trying to run slack I recive a segmentation fault.
   It seems to be related to libnode. I ran valgrind slack and get:
==14607== Process terminating with default action of signal 11 (SIGSEGV)
==14607==  Bad permissions for mapped region at address 0xDBF060
==14607==at 0xDBF060: ??? (in /usr/lib/slack/slack)
==14607==by 0x710F071: 
node::http2::Http2Session::Callbacks::Callbacks(bool) (in 
/usr/lib/slack/libnode.so)
==14607==by 0x710F134: ??? (in /usr/lib/slack/libnode.so)
==14607==by 0x5853399: call_init.part.0 (dl-init.c:72)
==14607==by 0x5853495: call_init (dl-init.c:118)
==14607==by 0x5853495: _dl_init (dl-init.c:119)
==14607==by 0x58450C9: ??? (in /lib/x86_64-linux-gnu/ld-2.28.so)




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

Kernel: Linux 4.18.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)
LSM: AppArmor: enabled

Versions of packages slack-desktop depends on:
pn  apt-transport-https  
ii  gconf-service3.2.6-5
ii  gconf2   3.2.6-5
ii  gvfs-bin 1.38.1-1
ii  libappindicator1 0.4.92-7
ii  libcurl4 7.62.0-1
ii  libgcrypt20  1.8.4-4
ii  libgtk2.0-0  2.24.32-3
ii  libnotify4   0.7.7-3
ii  libnss3  2:3.41-1
ii  libsecret-1-00.18.6-3
ii  libudev1 239-15
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  python   2.7.15-3
ii  xdg-utils1.1.3-1

slack-desktop recommends no packages.

slack-desktop suggests no packages.

-- debconf-show failed

Bug#912557: Removal of British hyphenation patterns from TeX Live

[Philip Taylor]

h English hyphenation patterns will be of zero concern.
-- 
  
  Philip Taylor
  

Bug#907335: similar issue

[Julian Taylor]

this problem probably has the same python change as cause as this issue:

https://github.com/PyCQA/pycodestyle/issues/786
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908700

Bug#897496: python-pathlib: diff for NMU version 1.0.1-2.1

[Julian Taylor]

Control: tags 897496 + pending
Control: tags 897496 + patch
Control: user debian-rele...@lists.debian.org
Control: usertags 897496 + bsp-2018-10-de-karlsruhe

Dear maintainer,

I've prepared an NMU for python-pathlib (versioned as 1.0.1-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
diff -Nru python-pathlib-1.0.1/debian/changelog
python-pathlib-1.0.1/debian/changelog
--- python-pathlib-1.0.1/debian/changelog   2015-06-25 10:02:25.0
+0200
+++ python-pathlib-1.0.1/debian/changelog   2018-10-27 19:02:33.0
+0200
@@ -1,3 +1,11 @@
+python-pathlib (1.0.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * socket-test-fix.patch:
+Adapt testcase to work with python2 exception type (Closes: #897496)
+
+ -- Julian Taylor   Sat, 27 Oct 2018
19:02:33 +0200
+
 python-pathlib (1.0.1-2) unstable; urgency=medium

   * Enable reproducible build py patching generation of manpage
diff -Nru python-pathlib-1.0.1/debian/patches/series
python-pathlib-1.0.1/debian/patches/series
--- python-pathlib-1.0.1/debian/patches/series  1970-01-01
01:00:00.0 +0100
+++ python-pathlib-1.0.1/debian/patches/series  2018-10-27
18:59:43.0 +0200
@@ -0,0 +1 @@
+socket-test-fix.patch
diff -Nru python-pathlib-1.0.1/debian/patches/socket-test-fix.patch
python-pathlib-1.0.1/debian/patches/socket-test-fix.patch
--- python-pathlib-1.0.1/debian/patches/socket-test-fix.patch   1970-01-01
01:00:00.0 +0100
+++ python-pathlib-1.0.1/debian/patches/socket-test-fix.patch   2018-10-27
19:02:33.0 +0200
@@ -0,0 +1,18 @@
+Description: adapt test exception to python2
+Author: Julian Taylor 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897496
+Bug: https://bitbucket.org/pitrou/pathlib/issues/32
+
+Index: python-pathlib-1.0.1/test_pathlib.py
+===
+--- python-pathlib-1.0.1.orig/test_pathlib.py
 python-pathlib-1.0.1/test_pathlib.py
+@@ -1687,7 +1687,7 @@ class _BasePathTest(object):
+ self.addCleanup(sock.close)
+ try:
+ sock.bind(str(P))
+-except OSError as e:
++except (OSError, socket.error) as e:
+ if "AF_UNIX path too long" in str(e):
+ self.skipTest("cannot bind Unix socket: " + str(e))
+ self.assertTrue(P.is_socket())

Bug#880245: New version of statsmodels is out possibly fixing important bug - any volunteer

[Julian Taylor]

On 10/26/18 11:33 PM, Andreas Tille wrote:
> Hi Yaroslav,
> 
> On Fri, Oct 26, 2018 at 08:59:57AM -0400, Yaroslav Halchenko wrote:
>>
>>> I guess this went out of your focus.  I tried my best to update Git[1] to
>>> version 0.9.0.  The package build process stumbles about doc creation:
>>
>> THANKS!
> 
> You (and all other Uploaders) are welcome.
>  
>>> #../tools/examples_rst.py
>>> ../tools/fold_toc.py build/html/index.html
>>> Traceback (most recent call last):
>>>   File "../tools/fold_toc.py", line 12, in 
>>> doc = open(filename, encoding='utf8').read()
>>
>> so the script now is python3. adjust shebang?
> 
> Only adjusting shebang is not sufficient.  The file tools/fold_toc.py
> is definitely Python2.  I tried:
> 
> $ 2to3 -w fold_toc.py 
> RefactoringTool: Skipping optional fixer: buffer
> RefactoringTool: Skipping optional fixer: idioms
> RefactoringTool: Skipping optional fixer: set_literal
> RefactoringTool: Skipping optional fixer: ws_comma
> RefactoringTool: No changes to fold_toc.py
> RefactoringTool: Files that need to be modified:
> RefactoringTool: fold_toc.py
> 
> 
> But for whatever reason it is not changed automatically.  Am I missing
> something?
> 
> 
>> alternative might work to patch it with smth like
>>
>>   from io import open
> 
> I have not tried this yet.
> 
> Any further hint (preferably somebody else taking over)?
> 
> Kind regards
> 
> Andreas.
> 


I have pushed an update to git that fixes the build for me and filed
https://github.com/statsmodels/statsmodels/pull/5348 for the problem.

Bug#880245: New version of statsmodels is out possibly fixing important bug - any volunteer

[Julian Taylor]

On 10/26/18 11:33 PM, Andreas Tille wrote:
> Hi Yaroslav,
> 
> On Fri, Oct 26, 2018 at 08:59:57AM -0400, Yaroslav Halchenko wrote:
>>
>>> I guess this went out of your focus.  I tried my best to update Git[1] to
>>> version 0.9.0.  The package build process stumbles about doc creation:
>>
>> THANKS!
> 
> You (and all other Uploaders) are welcome.
>  
>>> #../tools/examples_rst.py
>>> ../tools/fold_toc.py build/html/index.html
>>> Traceback (most recent call last):
>>>   File "../tools/fold_toc.py", line 12, in 
>>> doc = open(filename, encoding='utf8').read()
>>
>> so the script now is python3. adjust shebang?
> 
> Only adjusting shebang is not sufficient.  The file tools/fold_toc.py
> is definitely Python2.  I tried:
> 
> $ 2to3 -w fold_toc.py 
> RefactoringTool: Skipping optional fixer: buffer
> RefactoringTool: Skipping optional fixer: idioms
> RefactoringTool: Skipping optional fixer: set_literal
> RefactoringTool: Skipping optional fixer: ws_comma
> RefactoringTool: No changes to fold_toc.py
> RefactoringTool: Files that need to be modified:
> RefactoringTool: fold_toc.py
> 
> 
> But for whatever reason it is not changed automatically.  Am I missing
> something?
> 
> 
>> alternative might work to patch it with smth like
>>
>>   from io import open
> 
> I have not tried this yet.
> 
> Any further hint (preferably somebody else taking over)?
> 
> Kind regards
> 
> Andreas.
> 

I'll have a look at the issue now.

Bug#903579: cythonize at build patch

[Julian Taylor]

tags -1 + patch
forwarded -1 https://github.com/matplotlib/basemap/issues/436
user debian-rele...@lists.debian.org
usertags -1 + bsp-2018-10-de-karlsruhe
thanks

Attached a patch which cythonizes the files during the package build and
fixes the README issue.
I have also filed an upstream bug.
diff --git a/debian/control b/debian/control
index 06cb00d..c8982f1 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Maintainer: Sandro Tosi 
 Uploaders:
  Debian Python Modules Team ,
 Build-Depends:
+ cython3,
  debhelper (>= 8.0.0),
  dh-python,
  libgeos-dev,
diff --git a/debian/docs b/debian/docs
index 45b0503..e502992 100644
--- a/debian/docs
+++ b/debian/docs
@@ -1,2 +1,2 @@
 FAQ
-README
+README.md
diff --git a/debian/rules b/debian/rules
index 392e96f..118d944 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,11 +10,13 @@ LIB := $$(python -c "from distutils.command.build import build ; from distutils.
 override_dh_auto_install:
 	set -e ; \
 	for python in $(PY2VERS); do \
+		cython3 -2 src/*pyx; \
 		$$python setup.py install --prefix $(CURDIR)/debian/python-mpltoolkits.basemap/usr --install-layout=deb; \
 		$$python-dbg setup.py install --prefix $(CURDIR)/debian/python-mpltoolkits.basemap-dbg/usr --install-layout=deb; \
 	done
 	set -e ; \
 	for python in $(PY3VERS); do \
+		cython3 -3 src/*pyx; \
 		$$python setup.py install --prefix $(CURDIR)/debian/python3-mpltoolkits.basemap/usr --install-layout=deb; \
 		$$python-dbg setup.py install --prefix $(CURDIR)/debian/python3-mpltoolkits.basemap-dbg/usr --install-layout=deb; \
 	done

Bug#912020: keepass2: Exception prevents start : System.Exception: Magic number is wrong: 542

[Julian Taylor]

what is the value  of the $TERM environment variable?

try if this works:

TERM=xterm keepass2

Bug#911988: reintroduce fixed python2 package for rdepends

[Julian Taylor]

tags 911988 + patch
thanks

Ops I forgot to adapt a runtime check, attached a fixed debdiff
diff --git a/debian/changelog b/debian/changelog
index f266461..a94e1bb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+txtorcon (18.0.2-3) unstable; urgency=medium
+
+  * reintroduce fixed Python 2 package needed by reverse dependencies
+do not install python3 files to avoid failure during installation
+add fix-controller-py3check.patch to correct the python3 runtime check
+Closes: #911271
+
+ -- Julian Taylor   Fri, 26 Oct 2018 22:30:43 
+0200
+
 txtorcon (18.0.2-2) unstable; urgency=medium
 
   * No longer builds a Python 2 package (Closes: #905253)
diff --git a/debian/control b/debian/control
index 0eac5fa..a20741c 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,14 @@ Build-Depends: debhelper (>= 9),
dh-python,
graphviz,
lsof,
+   python-all,
+   python-geoip,
+   python-ipaddress,
+   python-mock,
+   python-repoze.sphinx.autointerface,
+   python-setuptools,
+   python-sphinx,
+   python-twisted,
python3-all,
python3-geoip,
python3-mock,
@@ -21,6 +29,29 @@ Vcs-Browser: 
https://salsa.debian.org/pkg-privacy-team/txtorcon
 Vcs-Git: https://salsa.debian.org/pkg-privacy-team/txtorcon.git
 Homepage: https://github.com/meejah/txtorcon
 
+Package: python-txtorcon
+Architecture: all
+Depends: python-geoip,
+ python-ipaddress,
+ python-twisted,
+ python-zope.interface,
+ ${misc:Depends},
+ ${python:Depends}
+Suggests: tor
+Provides: ${python:Provides}
+Description: Twisted-based asynchronous Tor control protocol implementation 
(Python 2)
+ txtorcon main feature is to present an asynchronous API to speak the Tor
+ client protocol in Python. It also provides abstractions to track and get
+ updates about Tor's state and current configuration (including writing it to
+ Tor or disk), along with helpers to asynchronously launch slave instances of
+ Tor including Twisted endpoint support.
+ .
+ Twisted is an event-driven networking engine written in Python and Tor is an
+ onion-routing network designed to improve people's privacy and anonymity on 
the
+ Internet.
+ .
+ This package contains the Python 2 module.
+
 Package: python3-txtorcon
 Architecture: all
 Depends: python3-geoip,
diff --git a/debian/patches/fix-controller-py3check.patch 
b/debian/patches/fix-controller-py3check.patch
new file mode 100644
index 000..3e38df3
--- /dev/null
+++ b/debian/patches/fix-controller-py3check.patch
@@ -0,0 +1,20 @@
+Description: adapt python3 check for missing file
+Author: Julian Taylor 
+
+The file is not installed in python2 to avoid pycompile trying to compile it
+with python2.
+For this the runtime check needs to be adapted.
+
+Index: txtorcon/txtorcon/controller.py
+===
+--- txtorcon.orig/txtorcon/controller.py
 txtorcon/txtorcon/controller.py
+@@ -42,7 +42,7 @@ from .interface import ITor
+ try:
+ from .controller_py3 import _AsyncOnionAuthContext
+ HAVE_ASYNC = True
+-except SyntaxError:
++except Exception:
+ HAVE_ASYNC = False
+ 
+ if sys.platform in ('linux', 'linux2', 'darwin'):
diff --git a/debian/patches/series b/debian/patches/series
index ed80250..6bfd16d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+fix-controller-py3check.patch
 disable_test_for_invalid_geoip.patch
 remove-privacy-infringing-buttons.patch
 remove-privacy-infringing-JS.patch
diff --git a/debian/rules b/debian/rules
index a334f92..aa0b193 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@
 export PYBUILD_NAME=txtorcon
 
 %:
-   dh $@ --with=python3,sphinxdoc --buildsystem=pybuild
+   dh $@ --with=python2,python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_build:
PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -bhtml docs/ 
docs/_build/html # HTML generator
@@ -11,17 +11,28 @@ override_dh_auto_build:
 
 override_dh_auto_install:
dh_auto_install -O--buildsystem=pybuild
+   # don't install py3 files in py2 as they don't compile during 
installation
+   find debian/python-txtorcon/ -name controller_py3.py -delete
+   mkdir -p debian/python-txtorcon/usr/share/doc/python-txtorcon
mkdir -p debian/python3-txtorcon/usr/share/doc/python3-txtorcon
set -e && \
+   for data_src in README.rst TODO examples; do \
+   mv debian/python-txtorcon/usr/share/txtorcon/$$data_src \
+   debian/python-txtorcon/usr/share/doc/python-txtorcon; \
+   done
+   set -e && \
for data_src in README.rst TODO examples; do \
mv debian/python3-txtorcon/usr/share/txtorcon/$$data_src \
debian/python3-txtorcon/us

Bug#911271: txtorcon patch submitted

[Julian Taylor]

I have submitted a patch to reintroduce the patch in txtorcon:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911988

Bug#911988: reintroduce fixed python2 package for rdepends

[Julian Taylor]

Package: txtorcon
Version:  18.0.2-2
Severity: important

The removal of the python2 package in #905253 due to a packaging bug
made its reverse dependencies RC buggy.
As upstream still supports python2 [0], it is tested in the package
build and its rdepends and buster will still ship with python2 please
reintroduce the python2 package.

Attached a debdiff that fixes the installation of the python3 only file
in the python2 package.


[0] https://github.com/meejah/txtorcon
diff --git a/debian/changelog b/debian/changelog
index f266461..b644918 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+txtorcon (18.0.2-3) unstable; urgency=medium
+
+  * reintroduce fixed Python 2 package needed by reverse dependencies
+Closes: #911271
+
+ -- Julian Taylor   Fri, 26 Oct 2018 22:30:43 
+0200
+
 txtorcon (18.0.2-2) unstable; urgency=medium
 
   * No longer builds a Python 2 package (Closes: #905253)
diff --git a/debian/control b/debian/control
index 0eac5fa..a20741c 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,14 @@ Build-Depends: debhelper (>= 9),
dh-python,
graphviz,
lsof,
+   python-all,
+   python-geoip,
+   python-ipaddress,
+   python-mock,
+   python-repoze.sphinx.autointerface,
+   python-setuptools,
+   python-sphinx,
+   python-twisted,
python3-all,
python3-geoip,
python3-mock,
@@ -21,6 +29,29 @@ Vcs-Browser: 
https://salsa.debian.org/pkg-privacy-team/txtorcon
 Vcs-Git: https://salsa.debian.org/pkg-privacy-team/txtorcon.git
 Homepage: https://github.com/meejah/txtorcon
 
+Package: python-txtorcon
+Architecture: all
+Depends: python-geoip,
+ python-ipaddress,
+ python-twisted,
+ python-zope.interface,
+ ${misc:Depends},
+ ${python:Depends}
+Suggests: tor
+Provides: ${python:Provides}
+Description: Twisted-based asynchronous Tor control protocol implementation 
(Python 2)
+ txtorcon main feature is to present an asynchronous API to speak the Tor
+ client protocol in Python. It also provides abstractions to track and get
+ updates about Tor's state and current configuration (including writing it to
+ Tor or disk), along with helpers to asynchronously launch slave instances of
+ Tor including Twisted endpoint support.
+ .
+ Twisted is an event-driven networking engine written in Python and Tor is an
+ onion-routing network designed to improve people's privacy and anonymity on 
the
+ Internet.
+ .
+ This package contains the Python 2 module.
+
 Package: python3-txtorcon
 Architecture: all
 Depends: python3-geoip,
diff --git a/debian/rules b/debian/rules
index a334f92..aa0b193 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@
 export PYBUILD_NAME=txtorcon
 
 %:
-   dh $@ --with=python3,sphinxdoc --buildsystem=pybuild
+   dh $@ --with=python2,python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_build:
PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -bhtml docs/ 
docs/_build/html # HTML generator
@@ -11,17 +11,28 @@ override_dh_auto_build:
 
 override_dh_auto_install:
dh_auto_install -O--buildsystem=pybuild
+   # don't install py3 files in py2 as they don't compile during 
installation
+   find debian/python-txtorcon/ -name controller_py3.py -delete
+   mkdir -p debian/python-txtorcon/usr/share/doc/python-txtorcon
mkdir -p debian/python3-txtorcon/usr/share/doc/python3-txtorcon
set -e && \
+   for data_src in README.rst TODO examples; do \
+   mv debian/python-txtorcon/usr/share/txtorcon/$$data_src \
+   debian/python-txtorcon/usr/share/doc/python-txtorcon; \
+   done
+   set -e && \
for data_src in README.rst TODO examples; do \
mv debian/python3-txtorcon/usr/share/txtorcon/$$data_src \
debian/python3-txtorcon/usr/share/doc/python3-txtorcon; 
\
done
+   chmod 644 
debian/python-txtorcon/usr/share/doc/python-txtorcon/examples/*.py
chmod 644 
debian/python3-txtorcon/usr/share/doc/python3-txtorcon/examples/*.py
+   rm -r debian/python-txtorcon/usr/share/txtorcon
rm -r debian/python3-txtorcon/usr/share/txtorcon
 
 override_dh_compress:
dh_compress -Xlaunch_tor_with_simplehttpd.py -O--buildsystem=pybuild
 
 override_dh_auto_test:
+   PYTHONPATH=. trial --reporter=text test
PYTHONPATH=. trial3 --reporter=text test

Bug#906215: further issues

[Julian Taylor]

Also with this patch foolscap is still currently failing a test.
I have filed an issue upstream:
https://github.com/warner/foolscap/issues/42

Bug#911271: [Pkg-privacy-maintainers] Bug#911271: foolscap: (Build) Depends on non existing python-txtorcon

[Julian Taylor]

On 18.10.18 14:31, Julian Taylor wrote:
> On 18.10.18 14:28, Antoine Beaupré wrote:
>> On 2018-10-18 13:26:28, Julian Taylor wrote:
>>> On 18.10.18 01:07, Antoine Beaupré wrote:
>>>> On 2018-10-18 00:16:15, Sebastian Andrzej Siewior wrote:
>>>>> Package: foolscap
>>>>> Version: 0.13.1-1
>>>>> Severity: serious
>>>>>
>>>>> txtorcon does not build the Python2 variant (python-txtorcon) since its
>>>>> last upload, only the python3 one (python3-txtorcon) remains.
>>>>>
>>>>> As of now the package can't be built due to missing packages.
>>>>
>>>> Seems to me foolscap should be ported to python rather than to force
>>>> txtorcon to support a (soon to be) obsolete version of python. :)
>>>>
>>>
>>> foolscap is based on twisted which seems to have gotten python3 support
>>> recently. First one has to check if foolscap can work with python3 twisted.
>>>
>>> Please do not remove python2 packages from the bottom up, start from the
>>> dependency leaves and work down instead of just breaking everything above.
>>> txtorcon still supports python2 according to their github page.
>>
>> If you look at the txtorcon removal, you'll see it fixed RC bugs about
>> the py2 version, so it was not just a gratitious change...
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905253
>>
>> A.
>>
> 
> that bug looks more like a packaging error or fixable installation error
> than a bug in the py2 version.
> removing the py2 package making other packages rc buggy looks like
> overkill without prior consultation of reverse dependencies.
> 

sorry I may have been a bit brief. The bug you are referencing is the
error output of the pycompile step during package installation. The
python2 package installs a python3 only file (not the py3.py ending) so
it fails.
This can be caused by either upstreams installer incorrectly installing
py3 files in the py2 variant (as upstream installation usually does not
have this pycompile step a stray py3 file does not harm much) or less
likely the package installs the file in the wrong package.
In any case the fix should be simple, the package can take care to not
install py3 files in the py2 package. I can help by providing a patch if
this solution is acceptable.

Regardless we should check if foolscap can also use python3.
But even if that is possible I still would like to keep the python2
version as foolscap and twisted only so recently got py3 support users
will still need the python2 versions for a while until those that had to
wait for migration can migrate.

Bug#911271: [Pkg-privacy-maintainers] Bug#911271: foolscap: (Build) Depends on non existing python-txtorcon

[Julian Taylor]

On 18.10.18 14:28, Antoine Beaupré wrote:
> On 2018-10-18 13:26:28, Julian Taylor wrote:
>> On 18.10.18 01:07, Antoine Beaupré wrote:
>>> On 2018-10-18 00:16:15, Sebastian Andrzej Siewior wrote:
>>>> Package: foolscap
>>>> Version: 0.13.1-1
>>>> Severity: serious
>>>>
>>>> txtorcon does not build the Python2 variant (python-txtorcon) since its
>>>> last upload, only the python3 one (python3-txtorcon) remains.
>>>>
>>>> As of now the package can't be built due to missing packages.
>>>
>>> Seems to me foolscap should be ported to python rather than to force
>>> txtorcon to support a (soon to be) obsolete version of python. :)
>>>
>>
>> foolscap is based on twisted which seems to have gotten python3 support
>> recently. First one has to check if foolscap can work with python3 twisted.
>>
>> Please do not remove python2 packages from the bottom up, start from the
>> dependency leaves and work down instead of just breaking everything above.
>> txtorcon still supports python2 according to their github page.
> 
> If you look at the txtorcon removal, you'll see it fixed RC bugs about
> the py2 version, so it was not just a gratitious change...
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905253
> 
> A.
> 

that bug looks more like a packaging error or fixable installation error
than a bug in the py2 version.
removing the py2 package making other packages rc buggy looks like
overkill without prior consultation of reverse dependencies.

Bug#911271: [Pkg-privacy-maintainers] Bug#911271: foolscap: (Build) Depends on non existing python-txtorcon

[Julian Taylor]

On 18.10.18 01:07, Antoine Beaupré wrote:
> On 2018-10-18 00:16:15, Sebastian Andrzej Siewior wrote:
>> Package: foolscap
>> Version: 0.13.1-1
>> Severity: serious
>>
>> txtorcon does not build the Python2 variant (python-txtorcon) since its
>> last upload, only the python3 one (python3-txtorcon) remains.
>>
>> As of now the package can't be built due to missing packages.
> 
> Seems to me foolscap should be ported to python rather than to force
> txtorcon to support a (soon to be) obsolete version of python. :)
> 
> A.
> 

foolscap is based on twisted which seems to have gotten python3 support
recently. First one has to check if foolscap can work with python3 twisted.

Please do not remove python2 packages from the bottom up, start from the
dependency leaves and work down instead of just breaking everything above.
txtorcon still supports python2 according to their github page.

Bug#904289: libgo build failure with GCC trunk 20181004

[Ian Lance Taylor]

On Mon, Oct 8, 2018 at 8:59 PM, Matthias Klose  wrote:
> On 08.10.2018 11:47, Svante Signell wrote:
>> On Fri, 2018-10-05 at 21:10 +0200, Svante Signell wrote:
>>> On Fri, 2018-10-05 at 01:38 +0200, Matthias Klose wrote:
 Hi Svante,

 please have a look at the recent libgo build failure with GCC trunk
 20181004 after the libgo merge.  Please could you update the
 patches and send them upstream again?
>>>
>>> Well I don't really know where to submit the patches to upstream, but
>>> here they are. Cc:ing the gcc-snapshot bug 904...@bugs.debian.org
>>> too.
>>
>> Hi again,
>>
>> Seems like more changes were needed this time: Attached are three
>> updated patches:
>> src_libgo_go_syscall.diff
>> add-gnu-to-libgo-headers.diff
>> add-gnu-to-libgo-test-headers.diff
>
> Thanks for the update, but please could you send *all* the patches to
> gcc-patc...@gcc.gnu.org, and maybe CC Ian?  Patches really have to be ready to
> be applied upstream, and not to some Debian package.
>
> Please see https://gcc.gnu.org/contribute.html how to contribute.  libgo might
> be a bit different, because the source is maintained in golang, and then
> imported into GCC.

The absolute best way to contribute to the libgo and gcc/go/gofrontend
directories is to use Gerrit, following the process described at
https://golang.org/doc/contribute.html.

But sending patches to gcc-patc...@gcc.gnu.org and CC'ing me is also
OK.  Yes, in general the patches have to apply to GCC trunk.

Thanks.

Ian

Bug#901004: tinyproxy conffile moved

[George Taylor]

Package: tinyproxy
Version: 1.8.4-2
Severity: Normal

After upgrading to stretch, tinyproxy silently fails to start. This is
due to inconsistencies in references to the configuration file:

tinyproxy_1.8.4-2.debian.tar contains the file 'tinyproxy.maintscript'
which moves the file:
mv_conffile /etc/tinyproxy.conf /etc/tinyproxy/tinyproxy.conf 1.8.4-2~ tinyproxy

But also the file 'init' which still references the old location:
CONFIG=/etc/tinyproxy.conf

Updating CONFIG or adding a symlink causes tinyproxy to run normally again.

Bug#900316: [kde-plasma-desktop] KDE plasma taskbar icons corrupted with graphical glitches on mouse over

[Jesse Taylor]

It looks like Debian Bug #900149 
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900149> might be 
related.


Current Sid repo installs:

   xorg-server-core 1.20.0-2

   mesa-va-drivers 18.0.4-1

Apparently xorg 1.20 has problems with mesa 18.0.4 ... The following bug 
reports mention patches that appears to resolve the issue with xorg/mesa:


   *FS#58549 <https://bugs.archlinux.org/task/58549>**- [xorg-server]
   plasmashell freezes* (archlinux.org)

   *Bug 106351* <https://bugs.freedesktop.org/show_bug.cgi?id=106351> -
   *Freezes with plasmashell and steam client* (freedeskop.org)

Here are a link to the patches that resolved the issues there:

   [1/2] loader_dri3: Wait for pending swaps to complete before
   drawable_fini. <https://patchwork.freedesktop.org/patch/220544/>
   [2/2] loader_dri3: Variant 2: Wait for pending swaps to complete
   before drawable_fini. <https://patchwork.freedesktop.org/patch/221465/>

Maybe these patches will resolve both my problem and bug 900149?

Thanks,

Jesse Taylor

Bug#896060: python3-scipy: New upstream version available

[Julian Taylor]

On 19.04.2018 02:22, Jan Medlock wrote:
> Package: python3-scipy
> Version: 0.19.1-2
> Severity: minor
> 
> Dear Maintainer,
> Upstream released version 1.0.0 on 25 October 2017.
> 
> In particular, new differential-equation and optimization solvers have
> been added.
> 
> Please let me know if I can help.
> 


Unfortunately scipy.weave needs to be packaged first or all reverse
dependencies removed as it has been removed from scipy itself.
https://github.com/scipy/weave

Bug#894204: libpython3.7-stdlib: Still having same issue with libpython 3.7.0~b3-1

[Jesse Taylor]

Package: libpython3.7-stdlib
Version: 3.7.0~b3-1
Followup-For: Bug #894204

Dear Maintainer,

   * Trying to upgrade from testing -> sid 
   * Tried dist-upgrade and also just installing libpython3.7 directly.
   * Same as original report.
   * No error, since bug report said would be resolved with upload of 
libpython3.7


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

Kernel: Linux 4.15.0-2-amd64 (SMP w/8 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)
LSM: AppArmor: enabled

Versions of packages libpython3.7-stdlib depends on:
ii  libbz2-1.01.0.6-8.1
ii  libc6 2.27-2
ii  libdb5.3  5.3.28-13.1+b1
ii  libffi6   3.2.1-8
ii  liblzma5  5.2.2-1.3
ii  libmpdec2 2.4.2-1
ii  libncursesw5  6.1-1
iu  libpython3.7-minimal  3.7.0~b3-1
ii  libreadline7  7.0-3
ii  libsqlite3-0  3.22.0-2
ii  libtinfo5 6.1-1
ii  mime-support  3.60

libpython3.7-stdlib recommends no packages.

libpython3.7-stdlib suggests no packages.

Bug#892055: ITP: keepass2-plugin-keepasshttp -- KeePass plugin to expose password entries securely over HTTP

[Julian Taylor]

Package: wnpp
Severity: wishlist
Owner: Julian Taylor <jtaylor.deb...@googlemail.com>

* Package name: keepass2-plugin-keepasshttp
  Version : 1.8.4.2
  Upstream Author : Perry Nguyen <pfngu...@hanhuy.com>
* URL : https://github.com/pfn/keepass
* License : GPL3
  Programming Lang: C#
  Description : KeePass plugin to expose password entries securely over HTTP

 KeePassHttp is a plugin for KeePass 2.x and provides a secure means of
 exposing KeePass entries via HTTP for clients to consume.
 Features:
  - returns all matching entries for a given URL 
  - updates entries
  - secure exchange of entries
  - notifies user if entries are delivered
  - user can allow or deny access to single entries
  - works only if the database is unlocked
  - request for unlocking the database if it is locked while connecting
  - searches in all opened databases (if user activates this feature)
  - Whenever events occur, the user is prompted either by tray notification or
requesting interaction (allow/deny/remember).



signature.asc
Description: OpenPGP digital signature

Bug#889810: [Pkg-tcltk-devel] Bug#889810: tk: 'wish' gives console error message; tclsh can't find package Tk

[Jasper Taylor]

Hi Sergei,

On Wed, 7 Feb 2018 13:36:47 +0300 Sergei Golovan wrote:
> tags 889810 + moreinfo
> thanks
>
> Hi Jasper,
>
> On Wed, Feb 7, 2018 at 12:35 PM, Jasper Taylor wrote:
> > Package: tk
> > Version: 8.6.0+9
> > Severity: important
> >
> > Dear Maintainer,
> >
> > I found I could not run my Tk-based application. I was starting it 
with a tclsh
> > script which then executed "package require Tk" and this command 
was raising an

> > error: "Can't find package Tk".
> >
> > When running 'wish' from the command line a console error message 
appears as

> > follows:
> >
> >>application-specific initialization failed: Can't find a usable 
tk.tcl in the

> > following directories:
> >> /usr/local/lib/tcl8.6/tk8.6 /usr/local/lib/tk8.6 /usr/lib/>tk8.6
> > /usr/lib/tk8.6 /lib/tk8.6 /usr/library
>
> Judging by a lot of /usr/local in the output I'd say that you have 
some locally

> installed Tcl/Tk distribution and `wish' is actually
> `/usr/local/bin/wish'. Can you check
> this? Does /usr/bin/wish run properly when a full path is specified?

Thanks for looking at my problem. I don't have anything relevant under 
/usr/local -- the search paths are built into the package.


I also have access to a Debian system with tk 8.6.0+8 installed. On this 
system, I run tclsh and type


set auto_path

and get

/usr/share/tcltk/tcl8.6 /usr/share/tcltk /usr/lib /usr/local/lib/tcltk 
/usr/local/share/tcltk /usr/lib/tcltk/x86_64-linux-gnu /usr/lib/tcltk 
/usr/lib/tcltk/tcl8.6


and then running

package require Tk

returns 8.6.2 and opens a toplevel Tk window.

Now on my own system with tk 8.6.0+9I run tclsh and type

set auto_path

and get

/usr/local/lib/tcl8.6 /usr/local/lib /usr/lib

If I then type

set auto_path {/usr/share/tcltk/tcl8.6 /usr/share/tcltk /usr/lib 
/usr/local/lib/tcltk /usr/local/share/tcltk 
/usr/lib/tcltk/x86_64-linux-gnu /usr/lib/tcltk /usr/lib/tcltk/tcl8.6}


(so it is the same as it was in 8.6.0+8) then

package require Tk

it returns 8.6.6 and opens a toplevel window. I have added a line to my 
script to set the auto_path to the old value and my application now runs 
OK, although tk and wish should not need this.

Cheers
    Jasper

>
> Cheers!
> --
> Sergei Golovan
>
>

Bug#889810: tk: 'wish' gives console error message; tclsh can't find package Tk

[Jasper Taylor]

Package: tk
Version: 8.6.0+9
Severity: important

Dear Maintainer,

I found I could not run my Tk-based application. I was starting it with a tclsh
script which then executed "package require Tk" and this command was raising an
error: "Can't find package Tk".

When running 'wish' from the command line a console error message appears as
follows:

>application-specific initialization failed: Can't find a usable tk.tcl in the
following directories:
>/usr/local/lib/tcl8.6/tk8.6 /usr/local/lib/tk8.6 /usr/lib/>tk8.6
/usr/lib/tk8.6 /lib/tk8.6 /usr/library
>
>
>
>This probably means that tk wasn't installed properly.

but Wish then appears to start normally.



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

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

Versions of packages tk depends on:
ii  tcl8.6.0+9
ii  tk8.6  8.6.6-1+b1

tk recommends no packages.

tk suggests no packages.

-- no debconf information

Bug#881658: twipot315, your recent order 599394 Be4q

[Taylor Marie]

What is amazon?

On Mon, Nov 13, 2017 at 5:41 PM Amazon FinalNotice 
wrote:

> * welcome to amazon*
>
>
> 
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: debhelper Version: 10.10.7 Severity: serious Justification:
> breaks reverse-dependencies. Hello, I tried to rebuild libguestfs in
> ubuntu, and I found that commit broke dh_install for packages using regex
> like: usr/include/guestfs.h usr/lib/*-*/libguestfs.a
> usr/lib/*-*/libguestfs.so usr/lib/*-*/libguestfs.la
> usr/lib/*-*/pkgconfig/* ending up in: dh_install -X.la -X.so.owner
> -Xbindtests -X/usr/lib/go/ -X/usr/lib/go- -Xpackages.orig -Xetc/php.d \
> --fail-missing dh_install: Please use dh_missing
> --list-missing/--fail-missing instead dh_install: This feature will be
> removed in compat 12. dh_install: libguestfs-dev missing files: usr/lib/*-*/
> libguestfs.la dh_install: libguestfs-gobject-dev missing files:
> usr/lib/*-*/libguestfs-gobject-*.la dh_install: php-guestfs missing files:
> /etc/php.d dh_install: missing files, aborting I reverted that commit and
> uploaded in Ubuntu, I didn't check the debian package, but should be
> affected by the same bug (build ongoing here , will finish/fail hopefully
> in some minutes)
> https://anonscm.debian.org/git/debhelper/debhelper.git/commit/dh_install?id=874410ef1389fe2a62c9361c75915c8541828b93
> http://debomatic-amd64.debian.net/distribution#unstable/libguestfs/1.36.10-1/buildlog

Bug#879868: Orphan libcue

[Taylor LeMasurier-Wren]

Package: libcue

I wish to orphan this package because I no longer actively use Debian and I
don't plan on working on packages for now.

Bug#876639: libgo11: Please consider backport "libgo: use gc's arch names as the default GOARCHs on MIPS"

[Ian Lance Taylor]

Matthias Klose  writes:

> On 24.09.2017 11:36, Shengjing Zhu wrote:
>> Package: libgo11
>> Version: 7.2.0-5
>> Severity: wishlist
>> Tags: upstream
>> X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
>> 
>> Dear Maintainer,
>> 
>> Currently the pkg-go team uses gccgo to build Go packages on MIPS*
>> archs. However currently version of gccgo has different GOARCH name for
>> MIPS*.
>> 
>> Bug is reported at https://github.com/golang/go/issues/18031
>> And the fix is applied in trunk,
>> https://github.com/gcc-mirror/gcc/commit/074bbd7b6a221b0446c73b3f4c2e1bf6cc7b2634
>> 
>> We currently need tricky way to build Go packages on MIPS*(as described
>> in https://github.com/golang/go/issues/18031#issuecomment-318574018 )
>> 
>> So I think backport this fix in gccgo can be really helpful.
>
> Is this commit good enough for the gcc-7-branch?
>
> CCing Ian, if that could be backported in GCC to the gcc-7-branch.

It should be fine to backport that to GCC 7.

Ian

Bug#863672: performance critical libyuv built with Os

[Julian Taylor]

Package: firefox
Version:  53.0.is.52.0.2-1
Severity: normal


libyuv which is a performance critical library for firefix is built with
-Os which is horrible for performance for it.
In particular row_common.cc which contains the generic parts of the
color transformation code:

See:
https://buildd.debian.org/status/fetch.php?pkg=firefox=amd64=53.0.is.52.0.2-1=1492644908=0

/usr/bin/g++ -std=gnu++11 -o row_common.o -c  ...   -fPIC
-DMOZILLA_CLIENT -include
/PKGBUILDDIR/build-browser/mozilla-config.h -MD -MP -MF
.deps/row_common.o.pp -Wdate-time -D_FORTIFY_SOURCE=2 -Wall
-Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual
-Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code
-Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat
-Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations
-Wno-error=array-bounds -fno-lifetime-dse -fstack-protector-strong
-Wformat -Werror=format-security -fno-schedule-insns2 -fno-lifetime-dse
-fno-delete-null-pointer-checks -fno-exceptions -fno-strict-aliasing
-fno-rtti -ffunction-sections -fdata-sections -fno-exceptions
-fno-math-errno -pthread -pipe  -g -freorder-blocks -Os
-fomit-frame-pointer
/PKGBUILDDIR/media/libyuv/source/row_common.cc


The problematic part is the YuvPixel function which is called in loops
and in turn calls tiny clamp functions.
Os disables inlining so this causes massive overhead.
This is the top cpu profile on sites which e.g. display videos.
  17.25%  libxul.so   [.] YuvPixel▒
   6.58%  libxul.so   [.] Clamp   ▒
   6.46%  libxul.so   [.] clamp255

The problem is not as bad as it looks as this generic code is only
executed on machines that do not have SSSE3, AVX2 or NEON (see
convert_argb.cc)
But there are still plenty useful cpus that do not have these
instruction sets and are crippled by the compiler flags used.

Is it possible to compile this library with O3 to allow the compiler to
vectorize it with the best available generic instruction set (e.g. SSE2
on x64).

cheers,
Julian Taylor



signature.asc
Description: OpenPGP digital signature

Bug#860063: fsolve docs should state that it cannot solve over- or under-determined problems

[Julian Taylor]

On 11.04.2017 03:07, James Van Zandt wrote:
> Package: python-scipy
> Version: 0.18.1
> 
> 
> I have a MATLAB program that uses fsolve() from the optimization
> toolbox.  I found that scipy offers a similar function.  I spent a fair
> amount of time translating my program into Python, only to discover that
> the scipy implementation (unlike the MATLAB one) requires that the
> number of functions and the number of variables be equal.  The
> documentation for the underlying minpack programs (hybrd and hybrj)
> makes this clear, but the scipy documentation does not.  It should.  I
> suggest the attached patch. 
> 
> (It might also be a good idea to add a mention of leastsq, which can
> handle an over- or under-determined problem.)
> 
> - Jim Van Zandt
> 

hi,
this is an upstream issue.
Please report it here:
https://github.com/scipy/scipy/

cheers,
Julian

Bug#859019: your mail

[Julian Taylor]

On 04.04.2017 20:18, Ivo De Decker wrote:
> Control: severity -1 normal
> 
> Hi,
> 
> On Sat, Apr 01, 2017 at 01:18:08PM +0200, Julian Taylor wrote:
>> severity 859019 serious
>> thanks
>>
>> the issues are very much RC, stretch should not be stuck with a .0 numpy
>> release.
> 
> Just stating that won't make it RC. If you want your upload unblocked, the
> proper way to do that is to file an unblock request with an explanation, not
> by filing random RC bugs for stuff that is not RC. Do not inflate the severity
> of this bug again.

do you prefer separate bugs for each issue?
Imo thats just a waste of time.
The unblock request will be filed when it's passed its unstable cooking
time.

Bug#859019: (no subject)

[Julian Taylor]

severity 859019 serious
thanks

the issues are very much RC, stretch should not be stuck with a .0 numpy
release.

Bug#859019: new bugfix release available

[Julian Taylor]

Package: python-numpy
Version:  1:1.12.0-2
Severity: serious

hi,
A new bug release is available for numpy. It is almost exclusively regression 
fixes in 1.12.0 and should be included in stretch.
In case you want to go with backports I have marked the issues I consider 
important.

* `#8483 `__: BUG: Fix wrong future 
nat warning and equiv type logic error...

important (already in debian package)
* `#8489 `__: BUG: Fix wrong masked 
median for some special cases

* `#8490 `__: DOC: Place np.average 
in inline code
* `#8491 `__: TST: Work around 
isfinite inconsistency on i386

important
* `#8494 `__: BUG: Guard against 
replacing constants without '_' spec in f2py.
* `#8524 `__: BUG: Fix mean for float 
16 non-array inputs for 1.12
* `#8571 `__: BUG: Fix calling python 
api with error set and minor leaks for...

important
* `#8602 `__: BUG: Make iscomplexobj 
compatible with custom dtypes again
* `#8618 `__: BUG: Fix undefined 
behaviour induced by bad __array_wrap__

important
* `#8648 `__: BUG: Fix 
MaskedArray.__setitem__
* `#8659 `__: BUG: PPC64el machines 
are POWER for Fortran in f2py
* `#8665 `__: BUG: Look up methods on 
MaskedArray in `_frommethod`
* `#8674 `__: BUG: Remove extra digit 
in binary_repr at limit

important
* `#8704 `__: BUG: Fix deepcopy 
regression for empty arrays.

important
* `#8707 `__: BUG: Fix ma.median for 
empty ndarrays

cheers,
Julian



signature.asc
Description: OpenPGP digital signature

Bug#663169: Very Urgent :

[Bronwyn Taylor]

An urgent proposal please contact this email: mrswangjua...@gmail.com​​​

Bug#857029: thunderbird: tries to migrate nonexistent ~/.icedove due to unintended meaning of "\ #" syntax

[Chris Taylor]

On Wed, 08 Mar 2017 13:54:04 +0200 jim_p  wrote:

Package: thunderbird
Version: 1:45.7.1-2
Followup-For: Bug #857029

To the ones that removed the comment parts and made it work again. Can you
please write a patch for it or paste the corrected file in pastebin?
I removed the comment parts but the message shows up again.

And please merge it with bug #857032.




I placed a patch in bug #856490 (where this issue was introduced), but 
here it is again.


It worked for me, so...

Good luck! :-)
--- /usr/bin/thunderbird-broken 2017-03-08 09:06:55.057957903 +
+++ /usr/bin/thunderbird2017-03-08 09:07:31.442581553 +
@@ -193,9 +193,9 @@
 # is a state we can't solve on our own !!! The user needs to interact and
 # has probably an old or otherwise used Thunderbird installation. Which one
 # is the correct one to use?
-elif { [ -d "${ID_PROFILE_FOLDER}" ] || [ -L "${ID_PROFILE_FOLDER}" ]; } && \  
 # .icedove exists as folder or symlink
- { [ -d "${TB_PROFILE_FOLDER}" ] || [ -L "${TB_PROFILE_FOLDER}" ]; } && \  
 # .thunderbird exists as folder or symlink
-   [ "$(readlink -e "${TB_PROFILE_FOLDER}")" != "${ID_PROFILE_FOLDER}" ]; 
then  # compare if canonical name of both folders equal
+elif { [ -d "${ID_PROFILE_FOLDER}" ] || [ -L "${ID_PROFILE_FOLDER}" ]; } && \
+ { [ -d "${TB_PROFILE_FOLDER}" ] || [ -L "${TB_PROFILE_FOLDER}" ]; } && \
+   [ "$(readlink -e "${TB_PROFILE_FOLDER}")" != "${ID_PROFILE_FOLDER}" ]; 
then
 
 output_debug "There is already a folder or symlink '${TB_PROFILE_FOLDER}', 
will do nothing."
 output_debug "Please investigate by yourself! Some more information below."

Bug#856490: Thunderbird fails to start

[Chris Taylor]

On Tue, 7 Mar 2017 21:48:00 +0100 Andrea Stacchiotti 
 wrote:

Indeed, this "fix" is a nightmare (replying to this bug report has been
a nontrivial task).

My Thunderbird refuses to start if I have:
* Neither .icedove nor .thunderbird
* Only .thunderbird

And the migration somehow put a .thunderbird inside the .icedove when I
put an empty .icedove folder.

Sorry for the annoyed tone, but this has made Thunderbird completely
non-functional, unless I directly start
"/usr/lib/thunderbird/thunderbird-bin".

Package version: 1:45.7.1-2




I've attached a patch that fixes it, at least for me.
It appears that the comments at the end of lines 196 and 197 (and 
possibly 198 so I've removed it too) are breaking the elif, by making it 
read the next line as a comment too (because of the \ telling it to 
ignore the newline). Either way, bash doesn't like this syntax, don't do 
it! :-)


HTH,
Chris
--- /usr/bin/thunderbird-broken 2017-03-08 09:06:55.057957903 +
+++ /usr/bin/thunderbird2017-03-08 09:07:31.442581553 +
@@ -193,9 +193,9 @@
 # is a state we can't solve on our own !!! The user needs to interact and
 # has probably an old or otherwise used Thunderbird installation. Which one
 # is the correct one to use?
-elif { [ -d "${ID_PROFILE_FOLDER}" ] || [ -L "${ID_PROFILE_FOLDER}" ]; } && \  
 # .icedove exists as folder or symlink
- { [ -d "${TB_PROFILE_FOLDER}" ] || [ -L "${TB_PROFILE_FOLDER}" ]; } && \  
 # .thunderbird exists as folder or symlink
-   [ "$(readlink -e "${TB_PROFILE_FOLDER}")" != "${ID_PROFILE_FOLDER}" ]; 
then  # compare if canonical name of both folders equal
+elif { [ -d "${ID_PROFILE_FOLDER}" ] || [ -L "${ID_PROFILE_FOLDER}" ]; } && \
+ { [ -d "${TB_PROFILE_FOLDER}" ] || [ -L "${TB_PROFILE_FOLDER}" ]; } && \
+   [ "$(readlink -e "${TB_PROFILE_FOLDER}")" != "${ID_PROFILE_FOLDER}" ]; 
then
 
 output_debug "There is already a folder or symlink '${TB_PROFILE_FOLDER}', 
will do nothing."
 output_debug "Please investigate by yourself! Some more information below."

Bug#852202: systemd 232-13 aborts during upgrade and subsequent boots

[David Taylor]

Hi Michael,

On Sun, 22 Jan 2017, Michael Biebl wrote:

Am 22.01.2017 um 18:20 schrieb David Taylor:

On Sun, 22 Jan 2017, Michael Biebl wrote:

Am 22.01.2017 um 14:14 schrieb David Taylor:


I built the systemd_232-13 package locally from source, so I'm not 
sure how useful the core file would be to you.  I have reproduced the

backtrace below.


If you built 232-13 from source, can you cherry-pick the upstream patch
and see if that fixes your issue? We might then cherry-pick that patch
in the official package as well.
I can prepare packages if you prefer that.


I cherry-picked the two commits referenced by the upstream issue #4747: 


d112eae7da77899be245ab52aa1747d4675549f1 device: Avoid calling unit_free(NULL) 
in device setup logic (#4748)
c9d5c9c0e19eea79ca0f09fe58e5c0b76b8001e2 core: make unit_free() accept NULL 
pointers

They have resolved the problem -- 232-13 plus those two patches is now 
running successfully on my machine.



The above bug report suggests a problem with unicode partition labels.
Do you have such a partition?


I didn't think so, but double-checking in /dev/disk/by-partlabel shows I do
have an NTFS partition with the label †††:

# ls -l /dev/disk/by-partlabel/
total 0
lrwxrwxrwx 1 root root 10 Jan 22 13:19
††† -> ../../sdb3


Ah, ok. So this is a dual boot system, I assume.


Yes, dual boot with Windows 10.


Is /dev/sdb3 the partition holding the actual Windows 10 system? [1]
suggests that the partition layout is System | MSR | Windows | Recovery


Yes, it's the main Windows partition.


If you boot Windows, what's the partion label shown there? Is it the
default label created by the Windows installer?


blkid shows:

/dev/sdb1: LABEL="SYSTEM" UUID="5C7A-5FAE" TYPE="vfat" PARTLABEL="EFI system 
partition" PARTUUID="8bc4e64e-f2b7-47da-8048-ab445242bf
/dev/sdb2: PARTLABEL="Microsoft reserved partition" 
PARTUUID="dd5c4d6d-dd1b-4908-b83e-e6b44d12ca63"
/dev/sdb3: LABEL="win550s" UUID="886450D76450C998" TYPE="ntfs" 
PARTLABEL="†††" PARTUUID="77178a46-30b6-11e5-9bd1-5ce0c5c724c2"

Windows displayes the volume label as win550s (which I set, manually when 
installing).

For some reason the GPT partition label has been set to †††, 
although the two other Windows partitions have sensible partition labels.


--
David Taylor

Bug#852202: systemd 232-13 aborts during upgrade and subsequent boots

[David Taylor]

On Sun, 22 Jan 2017, Michael Biebl wrote:


Control: tags -1 + moreinfo

Am 22.01.2017 um 14:14 schrieb David Taylor:

Currently running systemd_231-9, first experienced this problem when
trying to upgrade to 232-8, 232-13 is still giving the same problem.


Upgrading from -9 to -8? I guess you mistyped this.
What is the first version you encountered the problem? Which version was
still working fine? Were other changes made to the system?


No typo - the first failed upgrade was from 231-9 to 232-8.  Nothing 
else changed at that time (except other package upgrades, but they seem 
irrelevant, given that downgrading to 231-9 leaves a working system and 
upgrading to either 232-8 or 232-13 leaves it failing to boot.)



During upgrade or boot systemd aborts due to an assertion failure:

Broadcast message from systemd-journald@ (Sun 2017-01-22 12:59:45 GMT):
systemd[1]: Caught , dumped core as pid 1535.
Message from syslogd@ Jan 22 12:59:45 ...
 systemd[1]: Caught , dumped core as pid 1535.

Broadcast message from systemd-journald@ (Sun 2017-01-22 12:59:45 GMT):
systemd[1]: Freezing execution.
Message from syslogd@deb550s at Jan 22 12:59:45 ...
 systemd[1]: Freezing execution.

syslog shows:

systemd[1]: Assertion 'u' failed at ../src/core/unit.c:521, function 
unit_free(). Aborting.

A similar problem appears to have been fixed upstream:
https://github.com/systemd/systemd/issues/4747


Can you attach the core file (should be found at /core) from the crash
with the exact systemd version you were using.


I built the systemd_232-13 package locally from source, so I'm not sure how 
useful the core file would be to you.  I have reproduced the backtrace below.

If you need any more details (or feel the core would still be useful) let me
know.

Reading symbols from /bin/systemd...Reading symbols from 
/usr/lib/debug/.build-id/24/30880e7d50808599be7bb2bafe54dab1a14bb8.debug...done.
done.
[New LWP 5370]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/lib/systemd/systemd --system --deserialize 19'.
Program terminated with signal SIGABRT, Aborted.

(gdb) bt
#0  0x7f7f747302f7 in kill () at ../sysdeps/unix/syscall-template.S:84
#1  0x560a0a3188aa in crash (sig=6) at ../src/core/main.c:189
#2  
#3  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#4  0x7f7f7473140a in __GI_abort () at abort.c:89
#5  0x7f7f75ebd4c2 in log_assert_failed (text=, file=, line=,
   func=) at ../src/basic/log.c:795
#6  0x560a0a3838c1 in unit_free (u=) at 
../src/core/unit.c:521
#7  0x560a0a32c4a0 in device_setup_unit.lto_priv.274 
(m=m@entry=0x560a0ab5e800, dev=dev@entry=0x560a0ac26690,
   path=path@entry=0x560a0ac2cef0 "/dev/disk/by-partlabel/", '†' , main=main@entry=false)
   at ../src/core/device.c:369
#8  0x560a0a32cc20 in device_process_new.lto_priv.276 (m=0x560a0ab5e800, 
dev=0x560a0ac26690) at ../src/core/device.c:420
#9  0x560a0a36bf15 in device_enumerate.lto_priv.149 (m=0x560a0ab5e800) at 
../src/core/device.c:689
#10 0x560a0a360a1f in manager_enumerate (m=) at 
../src/core/manager.c:1141
#11 0x560a0a312389 in manager_startup (fds=0x560a0ab5f2d0, 
serialization=, m=0x560a0ab5e800)
   at ../src/core/manager.c:1269
#12 main (argc=4, argv=) at ../src/core/main.c:1774



The above bug report suggests a problem with unicode partition labels.
Do you have such a partition?


I didn't think so, but double-checking in /dev/disk/by-partlabel shows I do
have an NTFS partition with the label †††:

# ls -l /dev/disk/by-partlabel/
total 0
lrwxrwxrwx 1 root root 10 Jan 22 13:19 ††† -> 
../../sdb3
lrwxrwxrwx 1 root root 10 Jan 22 13:19 EFI\x20system\x20partition -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jan 22 13:19 Microsoft\x20reserved\x20partition -> 
../../sdb2

I'm not sure where that PARTLABEL came from (I definitely didn't choose 
it), but the filesystem is part of a Windows 10 install.



Can you reproduce the problem reliably? Do you know how we can reproduce
the problem?


Yes, the problem occurs every time I upgrade the package (or reboot with 
the upgraded package installed).  I assume you could reboot it by 
creating an NTFS filesystem with PARTLABEL="†††††††"


--
David Taylor

Bug#852202: systemd 232-13 aborts during upgrade and subsequent boots

[David Taylor]

Package: systemd
Version: 232-13
Severity: critical
Justification: breaks the whole system

Currently running systemd_231-9, first experienced this problem when
trying to upgrade to 232-8, 232-13 is still giving the same problem.

During upgrade or boot systemd aborts due to an assertion failure:

Broadcast message from systemd-journald@ (Sun 2017-01-22 12:59:45 GMT):
systemd[1]: Caught , dumped core as pid 1535.
Message from syslogd@ Jan 22 12:59:45 ...
 systemd[1]: Caught , dumped core as pid 1535.

Broadcast message from systemd-journald@ (Sun 2017-01-22 12:59:45 GMT):
systemd[1]: Freezing execution.
Message from syslogd@deb550s at Jan 22 12:59:45 ...
 systemd[1]: Freezing execution.

syslog shows:

systemd[1]: Assertion 'u' failed at ../src/core/unit.c:521, function 
unit_free(). Aborting.  

A similar problem appears to have been fixed upstream:
https://github.com/systemd/systemd/issues/4747

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3
ii  libapparmor12.11.0-1
ii  libaudit1   1:2.6.7-1
ii  libblkid1   2.29-1
ii  libc6   2.24-8
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-3
ii  libgcrypt20 1.7.5-2
ii  libgpg-error0   1.26-1
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-4
ii  libkmod223-2
ii  liblz4-10.0~r131-2
ii  liblzma55.2.2-1.2
ii  libmount1   2.29-1
ii  libpam0g1.1.8-3.5
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.6-3
ii  libsystemd0 232-13
ii  mount   2.29-1
ii  util-linux  2.29-1

Versions of packages systemd recommends:
ii  dbus1.10.14-1
ii  libpam-systemd  232-13

Versions of packages systemd suggests:
ii  policykit-10.105-17
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.126
ih  udev 232-13

-- no debconf information

Bug#851685: awscli impossible version requirements

[Edwin Taylor]

Package: awscli
Version: 1.11.13-1

After upgrading to 1.11.13-1, the aws command has been failing like this:

$ aws ec2 describe-instances
'AWSHTTPSConnection' object has no attribute 'ssl_context'

To work around this, I downgraded to version 1.4.2, but this produced 
the following output:


$ aws --version
Traceback (most recent call last):
  File "/usr/bin/aws", line 15, in 
import awscli.clidriver
  File "/usr/share/awscli/awscli/clidriver.py", line 33, in 
from awscli.arguments import CustomArgument
  File "/usr/share/awscli/awscli/arguments.py", line 42, in 
from botocore.parameters import ListParameter, StructParameter
ImportError: No module named 'botocore.parameters'

The final workaround I found was to edit the file /usr/bin/aws and 
remove the "3" from the first line "#!/usr/bin/python3".  This allowed 
the aws command to work.


I may have been using an unusual or unsupported mixture of package 
versions, as I haven't seen anyone else report the "ssl_context" bug, 
but I thought I would document this problem here for the record, along 
with my workaround.  Also for the record, here are the versions of some 
other packages I have installed:


python-bcdoc0.12.2-1
python-botocore0.62.0-1
python3-bcdoc0.12.2-1
python3-botocore1.4.70-1
python-colorama0.3.2-1
python3-colorama0.3.7-1
python-pyasn10.1.7-1
python3-pyasn10.1.9-2
python-rsa3.1.4-1+deb8u1
python3-rsa3.1.4-1+deb8u1
python2.7.13-1
python33.4.2-2

Thank you for packaging this software, and I hope the information I have 
provided is helpful for reproducing the bug, or at least helps people 
work around it.



--
hivehome.com 



Hive | London | Cambridge | Houston | Toronto
The information contained in or attached to this email is confidential and 
intended only for the use of the individual(s) to which it is addressed. It 
may contain information which is confidential and/or covered by legal 
professional or other privilege. The views expressed in this email are not 
necessarily the views of Centrica plc, and the company, its directors, 
officers or employees make no representation or accept any liability for 
their accuracy or completeness unless expressly stated to the contrary. 
Hive is the trading name of Centrica Connected Home Limited (company no: 
5782908), registered in England and Wales with its registered office at 
Millstream, Maidenhead Road, Windsor, Berkshire SL4 5GD.

Bug#850789: Patch upload not showing up in deferred queue

[Taylor Kline]

Ooh okay. Thank you 

So how do non-DDs help out with providing patches?


On Jan 10, 2017 6:06 PM, "Sean Whitton" <spwhit...@spwhitton.name> wrote:

Dear Taylor,

On Tue, Jan 10, 2017 at 05:37:33PM -0600, Taylor Kline wrote:
> I uploaded a patch for Python3 about ~15 hours ago, but it's not
> showing up on https://ftp-master.debian.org/deferred.html

It's because you're not a Debian Developer.

--
Sean Whitton

Bug#850789: Patch upload not showing up in deferred queue

[Taylor Kline]

It's not useful for me to spare the maintainer(s) the work?  I figured if
I could do the footwork and let the maintainer just review and approve the
patch, they would be happy.

On Jan 10, 2017 5:45 PM, "Matthias Klose" <d...@debian.org> wrote:

On 11.01.2017 00:37, Taylor Kline wrote:
> I uploaded a patch for Python3 about ~15 hours ago, but it's not
> showing up on https://ftp-master.debian.org/deferred.html
>
> Attempting to upload again does indicate that it should have
> successfully uploaded:
> 

> $ dput -e 10 python3-defaults_3.5.1-4.1_amd64.changes
> Trying to upload package to ftp-master (ftp.upload.debian.org)
> Package has already been uploaded to ftp-master on ftp.upload.debian.org
> Nothing more to do for python3-defaults_3.5.1-4.1_amd64.changes
> 

>
> Does it take > 15 hours for an upload to show up? Is there something I
> am missing?

please don't upload this package.  You filed a bug report with severity
wishlist
today, so you should give maintainers a chance to react to it.

Thanks, Matthias

Bug#850789: Patch upload not showing up in deferred queue

[Taylor Kline]

I uploaded a patch for Python3 about ~15 hours ago, but it's not
showing up on https://ftp-master.debian.org/deferred.html

Attempting to upload again does indicate that it should have
successfully uploaded:

$ dput -e 10 python3-defaults_3.5.1-4.1_amd64.changes
Trying to upload package to ftp-master (ftp.upload.debian.org)
Package has already been uploaded to ftp-master on ftp.upload.debian.org
Nothing more to do for python3-defaults_3.5.1-4.1_amd64.changes


Does it take > 15 hours for an upload to show up? Is there something I
am missing?

Thanks,
-Taylor Kline

Bug#850789: nmudiff

[Taylor Kline]

I think my nmudiff did not come through because of file size. Here's a
link to a gist that has the nmudiff output:

https://gist.github.com/jkdf2/da2ee2dc60a4e0ce0860220ffb461e32

Bug#849521:

[Taylor Kline]

Thank you 

On Tue, Jan 10, 2017 at 9:49 AM, JCF Ploemen  wrote:
> your watch file issue is caused by the presence of a colon in the url,
> at the start of every filename:
> https://dl.bintray.com/novik65/generic/:ruTorrent-3.7.zip
>
> Once you account for that things start moving on the uscan front.

Bug#850789: Patch submitted

[Taylor Kline]

Hi again!

I believe I have uploaded my patch and it should show up here:

https://ftp-master.debian.org/deferred.html

This is one of my first contributions to the Debian packaging efforts
and I would greatly appreciate constructive criticism.

Thanks and hope this helps with the maintenance efforts 
-Taylor

Bug#850789: python3: Python3 should look out for new versions upstream

[Taylor Kline]

Package: python3
Version: 3.5.1-4
Severity: wishlist

Hello!

Some updates to Python 3.5 have been missed and there is also now a
major release of Python 3.6 that hasn't gotten much attention.

I understand the debian/watch file exists to helpfully keep track of the
release of new upstream versions.

I will help out by providing a debian/watch file :) on its way shortly.

-Taylor

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

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

Versions of packages python3 depends on:
ii  dh-python  2.20160818
ii  libpython3-stdlib  3.5.1-4
ii  python3-minimal3.5.1-4
ii  python3.5  3.5.2-9

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc   
pn  python3-tk
pn  python3-venv  

-- no debconf information

Bug#849013: rewrite nvidia-detect

[Taylor Kline]

umm disregard my accidentally sent email that clearly shows I am just
learning how to use the mailing list.

I didn't do an extensive code review but it did detect my Optimus setup:

Find the NVIDIA driver version for Debian Stretch.
Checking PCI ID: 8086191b is not a valid NVIDIA device ID. Ignoring this PCI ID.
Checking PCI ID: 10de139b Found: GM107M [GeForce GTX 960M]

WARNING! This looks like a NVIDIA Optimus GPU,
maybe you prefeer a Bumblebee setup, or try
the experimental NVIDIA Prime support in 370 >

Your GPU(s) are supported by Nvidia driver version(s):
375xx
It is recommanded to install the following Debian package:
nvidia-driver

On Mon, Jan 9, 2017 at 3:52 PM, Floris  wrote:
> I made a rewrite of the nvidia-detect script.
>
> - The script is compatible with sh, bash and dash.
> - It is easy to add or remove supported Debian and NVIDIA versions.
> - Use the -d switch to mimic a Debian version.
> - support for multiple NVIDIA GPUs (or as PCI-ID on the command line)
> - No new dependencies, only pciutils
> - Try to detect NVIDIA Optimus (Unfortunately I doesn't have a device to
> test this)
>
> I'm only scripting as a hobby, so feel free to correct and teach me new
> things!
>
> Floris

Bug#849521: RFS: rutorrent/3.7-1 [ITP] -- A front-end for the rTorrent torrent client

[Taylor Kline]

Hi!

Thanks a lot for taking a look over the package.

As this is my first package, forgive me if I need a little
hand-holding here, especially with regards to the filesystem hierarchy
and safe permissions:

> I'm not overly joyed by seeing the symlink farm in /etc pointing
> to /usr/share though. This is simply wrong as the files are
> not configuration files (which is why they don't live in
> /etc to begin with). Whatever needs these files should IMHO
> be fixed up to look for the in the correct location (so
> you can drop the symlinks).
>
> Making /usr/share/ruTorrent world-writable is the main issue though.
> This will never end well. You need to think about security and
> how you manage permissions somehow. This is in my opinion a
> blocker for uploading your package.

So ruTorrent/share/settings, ruTorrent/share/torrents, and
ruTorrent/share/users are all supposed to be "accessible for reading
and writing for both rtorrent and webserver users."

This is why I placed them in /usr/share/ruTorrent/{settings, torrents,
users} and gave world-writable permissions.

But this was mostly just guesswork based on the filesystem hierarchy
standard manpages. Could you give me some advice on the correct
placement and permissions of such files that should be modifiable by
both the web-server and the user who is running the rtorrent CLI?

[Note: rTorrent != ruTorrent]

Reference: 
https://github.com/Novik/ruTorrent/wiki/Config#multiuser-and-singleuser-configuration

> Not sure but if nginx has '*-available' '*-enabled' configuration
> pattern but I think it does and then maybe there's a way to
> provide a snippet for '*-available' that a user can in normal
> cases just enable. This should simplify for the user over having
> to read up and manually configure nginx.

Great idea. So just placing an nginx config file in rutorrent.examples
and suggesting that the user create a symlink from
/etc/nginx/sites-enabled to this file if they wish to use nginx +
default configuration?

Thanks so much for your help,
-Taylor

Bug#850295: bumblebee-nvidia: TLP causes: [ERROR]Cannot access secondary GPU - error: Could not enable discrete graphics card

[Taylor Kline]

Package: bumblebee-nvidia
Version: 3.2.1-13
Severity: normal

Fix is documented here:
https://github.com/Bumblebee-Project/Bumblebee/issues/829

Patch needed for TLP upstream:
https://github.com/linrunner/TLP/issues/244

Filed a bug here for reference so that others can see it and manually
patch until fixed upstream on TLP.

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

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

Versions of packages bumblebee-nvidia depends on:
ii  bumblebee   3.2.1-13
ii  glx-alternative-nvidia  0.7.4
ii  nvidia-driver   375.26-1
ii  nvidia-kernel-dkms  375.26-1

bumblebee-nvidia recommends no packages.

bumblebee-nvidia suggests no packages.

-- no debconf information

Bug#850293: tlp: Conflicts with Bumblebee, disabling GPU until reboot

[Taylor Kline]

Package: tlp
Version: 0.9-1
Severity: normal

Hello,

There is a known bug with TLP that it will conflict with Bumblebee, the
manager for laptops supporting Nvidia Optimus.

Bug is reported upstream: https://github.com/linrunner/TLP/issues/244.
Filed here for reference purposes.

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

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

Versions of packages tlp depends on:
ii  hdparm   9.50+ds-1
ii  init-system-helpers  1.46
ii  iw   4.9-0.1
ii  pciutils 1:3.5.2-1
ii  rfkill   0.5-1
ii  usbutils 1:007-4
ii  wireless-tools   30~pre9-12

Versions of packages tlp recommends:
ii  ethtool1:4.8-1
ii  linux-tools4.8+77
ii  smartmontools  6.5+svn4324-1
ii  tlp-rdw0.9-1

Versions of packages tlp suggests:
ii  acpi-call-dkms  1.1.0-3
ii  tp-smapi-dkms   0.42-1

-- Configuration Files:
/etc/default/tlp changed:
TLP_ENABLE=1
TLP_DEFAULT_MODE=AC
DISK_IDLE_SECS_ON_AC=0
DISK_IDLE_SECS_ON_BAT=2
MAX_LOST_WORK_SECS_ON_AC=15
MAX_LOST_WORK_SECS_ON_BAT=60
SCHED_POWERSAVE_ON_AC=0
SCHED_POWERSAVE_ON_BAT=1
NMI_WATCHDOG=0
ENERGY_PERF_POLICY_ON_AC=performance
ENERGY_PERF_POLICY_ON_BAT=powersave
DISK_DEVICES="sda sdb"
DISK_APM_LEVEL_ON_AC="254 254"
DISK_APM_LEVEL_ON_BAT="128 128"
SATA_LINKPWR_ON_AC=max_performance
SATA_LINKPWR_ON_BAT=min_power
AHCI_RUNTIME_PM_TIMEOUT=15
PCIE_ASPM_ON_AC=performance
PCIE_ASPM_ON_BAT=powersave
RADEON_POWER_PROFILE_ON_AC=high
RADEON_POWER_PROFILE_ON_BAT=low
RADEON_DPM_STATE_ON_AC=performance
RADEON_DPM_STATE_ON_BAT=battery
RADEON_DPM_PERF_LEVEL_ON_AC=auto
RADEON_DPM_PERF_LEVEL_ON_BAT=auto
WIFI_PWR_ON_AC=off
WIFI_PWR_ON_BAT=on
WOL_DISABLE=Y
SOUND_POWER_SAVE_ON_AC=0
SOUND_POWER_SAVE_ON_BAT=1
SOUND_POWER_SAVE_CONTROLLER=Y
BAY_POWEROFF_ON_BAT=0
BAY_DEVICE="sr0"
RUNTIME_PM_ON_AC=on
RUNTIME_PM_ON_BAT=auto
RUNTIME_PM_ALL=1
RUNTIME_PM_BLACKLIST="01:00.0"
RUNTIME_PM_DRIVER_BLACKLIST="nvidia nouveau"
USB_AUTOSUSPEND=1
USB_BLACKLIST_WWAN=1
RESTORE_DEVICE_STATE_ON_STARTUP=0


-- no debconf information

Bug#850053: linux-image-4.8.0-2-amd64: CPU Frequency stuck at 800MHz with Intel_pstate governor

[Taylor Kline]

Package: src:linux
Version: 4.8.11-1
Severity: important

Hello,

First off, I'll mention that it's quite possible that this was fixed upstream
and has made its way to 4.9 based on this thread:
https://bugzilla.kernel.org/show_bug.cgi?id=90041

However, filing this for reference: in 4.8, the CPU frequency when using the
intel_pstate (default) governor appears to stick at 800MHz on at
least some devices. Based on the bug report above, many Dell users are
affected, even on the latest Dell BIOS. I am affected on my Dell XPS 15
9550.

-- Package-specific info:
** Version:
Linux version 4.8.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1 (2016-12-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-amd64 
root=UUID=dd944d4d-f213-4352-a856-5609e81803be ro quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[4.393517] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input8
[4.393596] ACPI: Video Device [PEGP] (multi-head: no  rom: yes  post: no)
[4.393691] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0a/LNXVIDEO:01/input/input10
[4.393768] [drm] Initialized i915 1.6.0 20160711 for :00:02.0 on minor 0
[4.396449] fbcon: inteldrmfb (fb0) is primary device
[4.401211] pstore: using zlib compression
[4.401232] pstore: Registered efi as persistent store backend
[4.402672] Intel(R) Wireless WiFi driver for Linux
[4.402673] Copyright(c) 2003- 2015 Intel Corporation
[4.402793] iwlwifi :02:00.0: enabling device ( -> 0002)
[4.406937] iwlwifi :02:00.0: firmware: failed to load 
iwlwifi-8000C-24.ucode (-2)
[4.406940] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-8000C-24.ucode failed with error -2
[4.406962] iwlwifi :02:00.0: firmware: failed to load 
iwlwifi-8000C-23.ucode (-2)
[4.406965] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-8000C-23.ucode failed with error -2
[4.416089] iwlwifi :02:00.0: firmware: direct-loading firmware 
iwlwifi-8000C-22.ucode
[4.416997] iwlwifi :02:00.0: loaded firmware version 22.361476.0 
op_mode iwlmvm
[4.424081] dcdbas dcdbas: Dell Systems Management Base Driver (version 
5.6.0-3.2)
[4.475408] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC 
8260, REV=0x208
[4.477488] iwlwifi :02:00.0: L1 Enabled - LTR Disabled
[4.478126] iwlwifi :02:00.0: L1 Enabled - LTR Disabled
[4.533480] snd_hda_intel :00:1f.3: enabling device ( -> 0002)
[4.582406] intel_rapl: Found RAPL domain package
[4.582411] intel_rapl: Found RAPL domain core
[4.582420] intel_rapl: Found RAPL domain uncore
[4.582426] intel_rapl: Found RAPL domain dram
[4.597737] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: 
(null)
[4.627695] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[4.628344] thermal thermal_zone10: failed to read out thermal zone (-5)
[4.704525] iwlwifi :02:00.0 wlp2s0: renamed from wlan0
[4.838578] input: DLL06E4:01 06CB:7A13 Touchpad as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-8/i2c-DLL06E4:01/0018:06CB:7A13.0001/input/input11
[4.838937] hid-multitouch 0018:06CB:7A13.0001: input,hidraw0: I2C HID v1.00 
Mouse [DLL06E4:01 06CB:7A13] on i2c-DLL06E4:01
[4.876474] random: crng init done
[5.709081] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[5.725821] Console: switching to colour frame buffer device 240x67
[5.744499] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3266: 
line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
[5.744503] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[5.744506] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[5.744508] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[5.744510] snd_hda_codec_realtek hdaudioC0D0:inputs:
[5.744513] snd_hda_codec_realtek hdaudioC0D0:  Headset Mic=0x18
[5.744515] snd_hda_codec_realtek hdaudioC0D0:  Headphone Mic=0x1a
[5.744518] snd_hda_codec_realtek hdaudioC0D0:  Internal Mic=0x12
[5.754284] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[5.767607] input: HDA Intel PCH Headphone Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input13
[5.770093] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[5.770250] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[5.770376] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input16
[5.840386] [drm] RC6 on
[5.908332] bbswitch: loading out-of-tree module taints kernel.
[5.908426] bbswitch: module verification failed: signature and/or required 
key missing - 

Bug#849593: libfftw3-single3: dependencies in shlibs file not tight enough (Was: Bug#849589: ardour: undefined symbol: fftwf_make_planner_thread_safe)

[Julian Taylor]

On 30.12.2016 18:17, Ghislain Vaillant wrote:
>> The goal is for dpkg-shlibdeps to generate a dependency like
>> "libfftw3-single3 (>= 3.3.5)" for any package which uses
>> fftwf_make_planner_thread_safe. This is needed otherwise you may get a
>> linker error like ardour does, and it's is done by using the symbols or
>> shlibs systems as described in policy 8.6.
> 
> I am personally not familiar with the symbols stuff, so it would be up
> to somewhat from the team or yourself to provide a patch for this issue.
> 

A symbol file for fftw3 would be good, I never did it as it a fair bit
of work as the symbols are arch specific. At the time it wasn't really
necessary as fftw did not add new public symbols in ages, this was not
the case for the last update which I did not do.

Stricter shlibs is simple, though it may make some backward installs a
bit more tedious as you need to pull fftw3 too, but not a really big
deal. I may be able to look into it soon.

Note the majority of symbols fftw3 exports are private, a patch I made a
while back to only export the real public ones (FFTW_EXTERN marked ones)
was rejected upstream.

cheers,
Julian

Bug#849622: lintian: unexpected description-starts-with-leading-spaces

[Taylor Kline]

Thanks, Niels, for the awesome explanation. I was able to correct my
package easily with this guidance.

I think a more indicative error message, if technically feasible, might be:

"The package's extended description is indented with >1 leading space (line X)"

Bug#849521: Package updated

[Taylor Kline]

Removed moreinfo tag since I have corrected or overrode all lintian
errors/warnings.

Rationale for my changes should be evident from the email exchanges above.

Looking forward to any feedback and potential sponsorship  thanks so much!

-Taylor

Bug#849521: Assistance with packaging ruTorrent

[Taylor Kline]

> Remove the file from the tarball, you shouldn't use it anyway, use the
> libjs-jquery-flot package instead.

Oh, nice! Thank you for pointing that out! Got it :)

> > 2. Two source-is-missing errors that are false positives because of a long
> > line in the source file.
> Why do you think they are false positives? Very long lines aren't usually
> user-editable.

They are false positives because the long lines are strings with HTML tags, i.e.

   ""

> > But if I create a
> >
> >   debian/rutorrent.lintian-overrides
> >
> > with the contents:
> >
> >   rutorrent source: source-is-missing plugins/extsearch/init.js
> >
> > then I get an error:
> >
> >   rutorrent: malformed-override Override of source-is-missing for package
> > type source (expecting binary)
> >
> > How can I successfully override these?
> debian/rutorrent.lintian-overrides contains overrides for the rutorrent
> binary package. The manual says "If the override is for a source package,
> you have to place it at debian/source/lintian-overrides or
> debian/source.lintian-overrides (the former path is preferred)."

Now I continue to get the lintian error and then have a warning:

  rutorrent source: unused-override source-is-missing plugins/extsearch/init.js

 any idea why lintian will not use the override?

- ACTUALLY, GOT IT --
I left the above for future reference for anyone else confused, but I
had to copy the entire line:

  rutorrent source: source-is-missing plugins/extsearch/init.js line
length is 288 characters (>256)

Looks like lintian is very particular in this way.

Now I just have my questions from part 3 remaining  I was actually
able to drop-in a excanvas and libphp-snoopy, so it's only
libjs-jquery that I cannot drop in version 3 without breaking the
entire system. I would really like to push forward with including
jquery v1.11.2 in the missing-sources if possible.

Thanks so much for your help so far.

-Taylor

Bug#849622: lintian: unexpected description-starts-with-leading-spaces

[Taylor Kline]

Package: lintian
Version: 2.5.49
Severity: normal

Hi,

Although my debian/control file looks as such:

...
Suggests: nginx
Description:front-end for the rTorrent torrent client
   ruTorrent is a web front-end for rTorrent designed to emulate the
   ...

I am getting a W: rutorrent: description-starts-with-leading-spaces

I don't think this makes sense as I have zero spaces between
"Description:" and "front-end"

Thanks for your attention,
-Taylor

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

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

Versions of packages lintian depends on:
ii  binutils  2.27.51.20161201-1
ii  bzip2 1.0.6-8
ii  diffstat  1.61-1
ii  file  1:5.29-2
ii  gettext   0.19.8.1-1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.30
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.18
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc4-1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-1+b1
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.24.1~rc4-1
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2

Versions of packages lintian recommends:
ii  dpkg 1.18.18
ii  libperlio-gzip-perl  0.19-1+b2
ii  perl 5.24.1~rc4-1
ii  perl-modules-5.24 [libautodie-perl]  5.24.1~rc4-1

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.18
ii  libhtml-parser-perl3.72-3
pn  libtext-template-perl  

-- no debconf information

Bug#849521: Assistance with packaging ruTorrent

[Taylor Kline]

Hello JavaScript Team,

I have a package pending with a Request for Sponsorship (my first package),
and I am blocked with the following lintian errors:

1. A source-is-missing error:

  js/jquery.flot.js line length is 3134 characters (>512)

This one occurs because the library flot (https://github.com/flot/flot),
which does not have a later release from the included release in 2014, has
an inlined function of 3134 characters:
https://github.com/flot/flot/blob/master/jquery.flot.js

Any tips on a good way to correct this?

---

2. Two source-is-missing errors that are false positives because of a long
line in the source file.

But if I create a

  debian/rutorrent.lintian-overrides

with the contents:

  rutorrent source: source-is-missing plugins/extsearch/init.js

then I get an error:

  rutorrent: malformed-override Override of source-is-missing for package
type source (expecting binary)

How can I successfully override these?

---

3. embedded-javascript-library warnings because upstream has packaged their
dependencies. The dependency versions are very old, for example:

Based on the md5sum of jquery.js, upstream is using jQuery v1.11.2.

libjs-jquery is 3.1.1-2, two major versions ahead, thus I doubt I can drop
in this replacement and test thoroughly enough to ship it with any
confidence that there won't be many run-time bugs.

And if I can't drop in a replacement, I would feel quite a hindrance to the
developer bothering him with updating his JavaScript dependencies that
currently work just fine.

I have noticed that, for example, the "wordpress" package has overrides:
# Opportunistic replacement is in place but the Debian version does
# not match the wordpress version
wordpress: embedded-javascript-library
usr/share/wordpress/wp-includes/js/jquery/jquery.form.js please use
libjs-jquery-form
wordpress: embedded-javascript-library
usr/share/wordpress/wp-includes/js/jquery/jquery.form.min.js please use
libjs-jquery-form
...

Is it acceptable for me to do the same, at least for the time being?

---

Package can be seen here:

  https://mentors.debian.net/package/rutorrent

and the associated RFS:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849521

Bug#849521: RFS: rutorrent/3.7-1 [ITP] -- A front-end for the rTorrent torrent client

[Taylor Kline]

Thank you for your prompt attention! I will email the JS mailing list.

On Wed, Dec 28, 2016 at 4:28 AM, Sean Whitton <spwhit...@spwhitton.name>
wrote:

> control: tag -1 +moreinfo
>
> Dear Taylor,
>
> Thanks for this package.  Looks interesting.
>
> On Tue, Dec 27, 2016 at 11:26:30PM -0500, Taylor Kline wrote:
> > lintian is throwing the following 'serious' errors that I haven't been
> entirely
> > sure what to do with:
> >
> >   jquery.flot.js source missing - this file has an inlined function of
> 3134
> > characters. Unfortunately this cannot be corrected in a straightforward
> manner
> > because the flot library has not been maintained since 2014.
>
> It would violate DFSG if you didn't include the source.  The upload
> would be rejected by the ftp-masters.  So you need to replace this file
> with something that has source code.  The Debian javascript team might
> be able to help.
>
> > There are also a few warnings about using embedded js libraries. The
> versions
> > included are much older than the libjs versions available in the Debian
> > packaging system. Thus it may take some conversations with upstream to
> > integrate these wishlist items.
>
> You need to have these conversations with upstream before this can go
> into Debian: all Debian packages need to use the packaged versions of
> libraries.
>
> If you're able to resolve these issues, please remove the moreinfo tag
> from this bug.
>
> --
> Sean Whitton
>

Bug#848303: Versions

[Taylor Kline]

I received a warning when installing v2.7.9-1 on Debian Stretch.

grave bugs of electrum (→ 2.7.9-1) 
 b1 - #848303 - electrum: Transactions not accepted by network
Summary:
 electrum(1 bug)

Any idea why this occurs when this bug is not applicable to this version?

Bug#849521: RFS: rutorrent/3.7-1 [ITP] -- A front-end for the rTorrent torrent client

[Taylor Kline]

Package: sponsorship-requests
Severity: wishlist

Hello fine mentors,

I am looking for a sponsor for "rutorrent"

Package name: rutorrent
Version : 3.7-1
Upstream Author : Novik <novi...@gmail.com>
URL : https://github.com/Novik/ruTorrent
License : GPL-3
Section : net

---

It installs the files for the front-end in:

  /etc/ruTorrent  - server files

  /usr/share/ruTorrent  - user-set configuration files chmod'd to a+rwX

I also provided a detailed manpage for the configuration, including how to
configure from scratch using nginx.

lintian is throwing the following 'serious' errors that I haven't been
entirely sure what to do with:

  jquery.flot.js source missing - this file has an inlined function of 3134
characters. Unfortunately this cannot be corrected in a straightforward
manner because the flot library has not been maintained since 2014.

The other two errors are because the source files have lines longer than
expected (288 characters and 553 characters), but these are just long lines.

I also was not able to create an override for any of these lintian errors;
overriding any of these generated an error that source-is-missing was
expecting binary files and I gave it source files.

There are also a few warnings about using embedded js libraries. The
versions included are much older than the libjs versions available in the
Debian packaging system. Thus it may take some conversations with upstream
to integrate these wishlist items.

I am also experiencing a small error with 'watch.' uscan -vv outputs:

  uscan debug: Checking href :S2EngEditor.zip
  uscan debug: Checking href :S2SteamPatch.zip
  uscan debug: Checking href :plugins-3.6.tar.gz
  uscan debug: Checking href :plugins/
  uscan debug: Checking href :ruTorrent-3.7.zip
  uscan debug: Checking href :rutorrent-3.6.tar.gz
  uscan warn: In debian/watch no matching files for watch line
https://dl.bintray.com/novik65/generic/
ru[tT]orrent[-_]?(\d[\-+\.:\~\da-zA-Z]*)(?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)

I'm not sure why:
  ru[tT]orrent@ANY_VERSION@@ARCHIVE_EXT@
would not match any of these files.

---

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

  https://mentors.debian.net/package/rutorrent


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

  dget -x
https://mentors.debian.net/debian/pool/main/r/rutorrent/rutorrent_3.7-1.dsc

---

This closes this ITP:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671744

---

This is my first package! I did my best to follow all policy, and I foresee
no problems continuing to maintain it!

Regards,
Taylor Kline

Bug#671744: ITP: rutorrent

[Taylor Kline]

Since this has had no activity since 2013, I have packaged version 3.7 and
will be uploading it with a request for sponsorship soon.

Bug#848198: fonts-noto-color-emoji

[Taylor Kline]

Yikes, that is quite a hassle. I am CC'ing the Debian Fonts Task force and
maybe someone from there has some suggestion on how to deal with the
nototools dependency in order to build the NotoColorEmoji.ttf.

Also I think it's true based on the GitHub repo (
https://github.com/googlei18n/noto-emoji) that only the NotoColorEmoji
source exists. But that is ok, right, I mean who needs black & white?

On Thu, Dec 22, 2016 at 6:19 PM, Ming-ting “Yao” Wei <medical...@gmail.com>
wrote:

> Hi,
>
> I am packing that but progressing slowly because there's need to upload
> build dependency (nototools, #848206) to build from source and I might need
> to handle the documentation of the package.
>
> I can do a rename of this ITP to include the fallback version of the
> emoji. Should we do that? (Also I can't find the source of Noto Emoji
> despite of the redistributable ttf.)
>
> Yao Wei, sending this on a phone
>
> On 23 Dec 2016, at 04:17, Taylor Kline <taylor.kl...@utexas.edu> wrote:
>
> Hello Yao,
>
> Are you progressing with packaging fonts-noto-color-emoji? I filed an RFP:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849042
>
> and a fonts-noto wishlist item:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849127
>
> before discovering your intent to package filed on 15 December.
>
> Thanks,
> -Taylor
>
>

Bug#849163: packaging-tutorial: Give source for dh popularity

[Taylor Kline]

Package: packaging-tutorial
Severity: wishlist

Hello,

First off, thanks for the outstanding tutorial.

The chart of the market share for dh as compared to the other packaging
helpers only goes until 2012. Providing a source that can be used for
current information would be very helpful to confirm dh's relevance or
see a new contender in the space.

Thanks for your consideration!
-Taylor

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

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

Bug#816509: nltk RFA

[Taylor Kline]

Hello,

I'm curious why this RFA is still open, as it seemed like there were many
interested parties. (Just starting to learn about the Debian packaging
process.)

-Taylor

Bug#848198: fonts-noto-color-emoji

[Taylor Kline]

Hello Yao,

Are you progressing with packaging fonts-noto-color-emoji? I filed an RFP:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849042

and a fonts-noto wishlist item:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849127

before discovering your intent to package filed on 15 December.

Thanks,
-Taylor

Bug#849127: fonts-noto: Inclusion of NotoColorEmoji font.

[Taylor Kline]

Package: fonts-noto
Version: 20161116-1
Severity: wishlist

Hello,

I submitted an RFP for a fonts-noto-emoji here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849042

It would be perfect if the NotoColorEmoji font could be integrated into
the fonts-noto metapackage.

Thanks for all of your work.
-Taylor

-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  fontconfig 2.11.0-6.7   amd64generic font configuration librar
ii  libfreetype6:a 2.6.3-3+b1   amd64FreeType 2 font engine, shared li
ii  libfreetype6:i 2.6.3-3+b1   i386 FreeType 2 font engine, shared li
ii  libxft2:amd64  2.3.2-1  amd64FreeType-based font drawing libra

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

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

Versions of packages fonts-noto depends on:
ii  fonts-noto-hinted  20161116-1

Versions of packages fonts-noto recommends:
ii  fonts-noto-cjk   1:1.004+repack2-1
ii  fonts-noto-mono  20161116-1
ii  fonts-noto-unhinted  20161116-1

fonts-noto suggests no packages.

-- no debconf information

Bug#849123: reportbug: Tab autocompletion inefficient with large number of results.

[Taylor Kline]

Package: reportbug
Version: 6.6.6
Severity: minor

Hello,

Immediately upon launching reportbug, it prompts the user for a package name. 
Pressing  for autocompletion after typing 0 or very few characters results 
in an indefinite freeze of the reportbug package.

Contrast this with the behavior of apt:

$ sudo apt install 

Display all 52343 possibilities? (y or n)

reportbug should have this similar behavior rather than freezing.

-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /home/taylor/.reportbugrc:
reportbug_version "6.6.6"
mode novice
ui text
email "taylor.kl...@utexas.edu"
no-cc
header "X-Debbugs-CC: taylor.kl...@utexas.edu"
smtphost reportbug.debian.org

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

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

Versions of packages reportbug depends on:
ii  apt   1.4~beta2
ii  python-reportbug  6.6.6
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4-daemon-light [mail-transport-agent]  4.88~RC6-1
ii  file   1:5.29-1
ii  gnupg  2.1.16-3
ii  python-gtk22.24.0-5.1
pn  python-gtkspellcheck   
pn  python-urwid   
pn  python-vte 
ii  xdg-utils  1.1.1-1

Versions of packages python-reportbug depends on:
ii  apt   1.4~beta2
ii  file  1:5.29-1
ii  python-debian 0.1.29
ii  python-debianbts  2.6.1
pn  python:any

python-reportbug suggests no packages.

-- no debconf information

Bug#849042: RFP: fonts-noto-emoji -- "No Tofu" emoji font

[Taylor Kline]

Package: wnpp
Severity: wishlist

* Package name: fonts-noto-emoji
  Upstream Author : googlei18n
* URL : https://github.com/googlei18n/noto-emoji
* License : SIL Open Font License v1.1 (fonts) and Apache v2.0 (tools 
and image resources).
  Programming Lang: Python, C
  Description : "No Tofu" emoji font

Emoji are an extremely common form of expression in modern
communication, yet the present options for displaying them in Debian are
hacky at best. For example, this effort
https://github.com/googlei18n/noto-emoji will display emoji correctly in
Firefox but will only be black-and-white system-wide (so not in Chrome). 
Similarly,
ttf-ancient-fonts can be installed for very ugly, B emoji.

The best solution I've currently found is based on this post:
http://stdio.tumblr.com/post/114082931782
and involves: downloading NotoColorEmoji.ttf from the noto-fonts Android
git repository, copying it to /usr/share/fonts/truetype/, and creating a
/etc/fonts/conf.d/01-notoemoji.conf with the contents:




  

  Noto Color Emoji


  true

  



However, NotoColorEmoji can be built from its source at
https://github.com/googlei18n/noto-emoji and it has a very friendly
license. It would be great to have the NotoColorEmoji font as a Debian
package to be easily installed and automatically configured.

Bug#849013: nvidia-detect: Nvidia Optimus Technology device(s) not detected incl. GTX 960M

[Taylor Kline]

Package: nvidia-detect
Version: 375.20-4
Severity: normal

Dear Maintainer,

Output of nvidia-detect does not show a GTX 960M:

$ nvidia-detect 
No NVIDIA GPU detected.

I am able to see the device as recommended at
http://forums.debian.net/viewtopic.php?p=603924#p603924 via:

$ lspci -vnn | grep '\''[030[02]\]'
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics
530 [8086:191b] (rev 06) (prog-if 00 [VGA controller])
01:00.0 3D controller [0302]: NVIDIA Corporation GM107M [GeForce GTX
960M] [10de:139b] (rev ff) (prog-if ff)

Here's a helpful output I would expect:
Detected NVIDIA GPUs:
$GTX 960M$
It is recommended to install the
bumblebee-nvidia and primus
packages according to https://wiki.debian.org/Bumblebee.

Thanks for your consideration.


-- Package-specific info:
uname -a:
Linux frozencustard 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64 
GNU/Linux

/proc/version:
Linux version 4.8.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1 (2016-12-02)

lspci 'VGA compatible controller [0300]':
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 
[8086:191b] (rev 06) (prog-if 00 [VGA controller])
Subsystem: Dell HD Graphics 530 [1028:06e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

dmesg:

Device node permissions:
crw-rw+ 1 root video 226,   0 Dec 21 14:18 /dev/dri/card0
crw-rw  1 root video 226,  64 Dec 21 14:18 /dev/dri/controlD64
crw-rw+ 1 root video 226, 128 Dec 21 14:18 /dev/dri/renderD128
video:x:44:taylor

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   25 Dec 21 13:17 /etc/alternatives/glx -> 
/usr/lib/nvidia/bumblebee
lrwxrwxrwx 1 root root   51 Dec 21 13:17 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   48 Dec 21 13:17 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   48 Dec 21 13:17 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Dec 21 13:17 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Dec 21 13:17 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   57 Dec 21 13:17 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   57 Dec 21 13:17 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   54 Dec 21 13:17 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 Dec 21 13:17 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   42 Dec 21 13:17 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Dec 21 13:17 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   32 Dec 21 13:17 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   23 Dec 21 13:15 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   50 Dec 21 13:15 
/etc/alternatives/nvidia--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libEGL.so.1
lrwxrwxrwx 1 root root   52 Dec 21 13:15 
/etc/alternatives/nvidia--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.1
lrwxrwxrwx 1 root root   57 Dec 21 13:15 
/etc/alternatives/nvidia--libEGL_nvidia.so.0-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libEGL_nvidia.so.0
lrwxrwxrwx 1 root root   59 Dec 21 13:15 
/etc/alternatives/nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libEGL_nvidia.so.0
lrwxrwxrwx 1 root root   49 Dec 21 13:15 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   49 Dec 21 13:15 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Dec 21 13:15 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvid

Bug#844479: zeromq3: zeromq 4.2.0 breaks tango

[Julian Taylor]

On 04.12.2016 14:14, Luca Boccassi wrote:
> 
>> But on how to fix this. Given [0] you seem to be just passing out the
>> pointer to your internal buffer written without padding out to the user
>> via zmq_msg_data (?)
>>
>> The documentation of that function states that you must not access
>> zmq_msg_t directly, so if nobody actual does do so regardless zmq can
>> change this structure and stay compatible?
>> If so can zmq insert alignment padding between the message headers and
>> the payload so zmq_msg_data returns aligned data?
> 
> This is an interesting suggestion so I had a look, but unfortunately I
> don't think it can be done.
> 
> The pointer returned points directly to the buffer as it was written by
> the TCP/IPC socket read. Since it's being written as it is received,
> there is no way at that stage to know what's header and what's payload,
> and insert padding. The actual decoding of the data is done at a later
> stage, when it's too late to get away with just adjusting pointers.
> 

Thanks for the explanation. It is probably better to focus on fixing
tango then.

> 
>> This would be very good for compatibility, on non-x86 arches it might
>> even be better for performance. Unaligned access can be very slow on
>> some of the less powerful cpus.
>>
>> (Also even on x86 you can get into alignment issues due to these
>> buffers, in particular with numerical applications where
>> auto-vectorization by the compilers is involved)
>>
>> [0] http://lists.zeromq.org/pipermail/zeromq-dev/2016-November/031096.html
> 
> Ultimately, performance-wise, this change from Jens allow one less
> malloc and copy per message (it became effectively a zero-copy receive
> from the point of view of userspace), and I'd be extremely surprised if
> the cost of unalignment would out-weight the gains.
> 

You have to consider that when the payload consists of a lot of data
that has alignment requirements e.g. lots of integers or floats every
access to the payload buffer is unaligned. With expensive unaligned
access you might be better of copying to an aligned buffer than working
on this buffer directly.
But then on x86 unaligned access is almost free, so it most likely is a
net plus in performance on the majority of systems.
A benchmark on e.g. ARM, should this platform be relevant to ZMQ, would
be interesting to see if adjusting payload alignment for a potential ZMQ
3.1 is worthwhile to look at.

cheers,
Julian Taylor